私の理解では、netfilterのhashlimitモジュールはリーキーバケットアルゴリズムを実装することになっています...私は以下のiptables構成を使用しています
iptables -A INPUT -s 207.[...] -m hashlimit --hashlimit-above 34722b/s \
--hashlimit-burst 600m --hashlimit-name hashlimitTable1 \
--hashlimit-htable-expire 604800000 -j DROP
これは 700 MB の単一の大きなダウンロードには完璧に機能しますが、ダウンロードが完了してから 3 時間待ってから別のダウンロードを実行すると、ルールはすぐに一致し (バーストなし)、帯域幅が約 34kB/秒に制限されます。
cat /proc/net/ipt_hashlimit/hashlimitTable1最初の大きなダウンロード後の番組の調査
This seems to represent the burst "bucket" size
and it does go down and reach 0 after 600 MB
have been downloaded, but it never increases
no matter how long I wait.
|
|
604555 0.0.0.0:0->0.0.0.0:0 4194304000 0 1931967
hashlimit は「リーキー バケット」アルゴリズムを実装していませんか? それとも私の設定が間違っているのでしょうか?
からman 8 iptables-extensions|grep -e 'hashlimit-burst amount' -A 7
--hashlimit-burst amount
Maximum initial number of packets to match: this number gets
recharged by one every time the limit specified above is not
reached, up to this number; the default is 5. When byte-based
rate matching is requested, this option specifies the amount of
bytes that can exceed the given rate. This option should be
used with caution -- if the entry expires, the burst value is
reset too.
これは、期待される動作が正しいことを示していますが、ルールが逆の観点から一致していることを確認する必要があるかもしれません。
iptables -A INPUT -s 207.[...] -m hashlimit --hashlimit-upto 34722b/s \
--hashlimit-burst 600m --hashlimit-name hashlimitTable1 \
--hashlimit-htable-expire 604800000 -j ACCEPT;
iptables -A INPUT -s 207.[...] -j DROP;
残念ながら、19 分以上 1KiBps という途方もなく低い速度でダウンロードする場合でも、まったく同じ動作が観察されますwget --limit-rate=1024 http://207.[...]/testFile.binが、トークンの最大数はゼロを超えることはなく、ダウンロードなしでさらに 1 時間待機した後の帯域幅は依然として約 34KBps に制限されます...
有効期限、ガベージ コレクション間隔、htable-size、htable-max は問題に影響を及ぼさないことを確認しました。有効期限を 10 秒などの非常に短い値に設定すると、明らかにバーストがリセットされますが、平均帯域幅に違反することになります。