恥ずかしいですが、UbuntuシステムへのSSH接続に対して誤って永続的な帯域幅制限を設定したようです。
ファイルを転送するとき~からscpsftpダウンロード速度は、またはリモートサーバー経由で2MB / sに制限されますrsync。ファイルを転送するとき到着アップロード速度が無制限のリモートサーバーです。同じネットワーク上の異なるコンピュータ、同じリモートサーバーから同じファイルを転送して、ダウンロード帯域幅を完全に飽和させることができます。
これは約3週間前から始まり、以前は数年間このリモートサーバーから頻繁にファイルを転送してきました。時々私はrsyncダウンロード速度を制限するために「フラグ」を使用します--bwlimit。
それ可能飲酒中に他のメカニズムを介して帯域幅を制限しましたが、これを行ったことは覚えておらず、コマンド履歴にこれを示すものは見つかりませんでした。
ルータのQOS設定を何度も確認しましたが、完全に無効になりました。ルータの残りの設定インターフェイス（Tomato FWIWを実行しています）を詳しく見ましたが、役に立ちませんでした。
特定のコンピュータのダウンロード速度を制限する要因は何ですか？
私が確認したこと：
ioniceまたは使用法nice- 使用法
wondershaper - 使用法
trickle - ルーターの設定
確認する必要があるものやデバッグ方法について他のアイデアがある人はいますか？
ベストアンサー1
最近の私の使命は、アプリケーションサーバーと特定の単一IP間のトラフィックが160kb /秒で転送されるのに対し、両方のシステムの他のすべてのトラフィックが10〜100Mbits /秒である理由を確認することでした。
制限は、互いに通信する 2 つのエンドポイントに固有です。
私はすべての明らかなトラフィック形成とトラフィック制御ソリューションを確認しましたが、成功しませんでした。
最後に、いくつかのパケットキャプチャを分析した後、ECNフラグはこれら2つのエンドポイント間の転送にのみ設定されることを確認しました。
クライアントは明示的な輻輳通知（ECN）を要求し、すべてのSYNパケットに輻輳エクスペリエンス（CE）を設定し、サーバーが輻輳を軽減するために転送速度を低下させることがわかりました。 CEマークは、差別化されたサービスフィールドの有効な数値に設定されます。
次のコマンドを使用して、Linuxサーバー設定（/proc/sys/net/ipv4/tcp_ecn）を確認できます。
sysctl -a | grep _ecn
次のコマンドを使用してtcp_ecnを設定します。
sysctl net.ipv4.tcp_ecn=2
可能な値は次のとおりです。
0 - ECNが無効になります。 ECNが開始または承認されていません。
1 - 着信接続要求に対してECNを有効にし、発信接続試行に対してECNを要求します。
2 - 着信接続要求に対してECNを有効にしますが、発信接続に対してECNを要求しません。デフォルト：2
CEコードが実際に送信されていることを確認するためにtcpdumpとWireSharkを使用しました。
tcpdumpを使用してキャプチャを開始し、それをpcapファイルに保存してキャプチャ要求を開始し、Ctl + cを使用してキャプチャを停止します。
tcpdump -I any -w my_capture.pcap
その後、WireSharkでこのpcapを開き、フィルタを使用してこれが発生するかどうかを確認できます。
ECNを使用するすべてのパケット：
tcp.flag.ecn==1
すべての転送輻輳パケット:
ip.dsfield.ecn==3
これがこの特定の問題を解決するかどうかはわかりませんが、OPはいくつかの可能性を要求しました。何を確認するのかわからないこの記事を読んでいる人は、この情報が役に立つと思い、設定ファイルの確認に数日を費やさないことを願っています。
最後にサーバーtcp_ecnを0に設定すると、帯域幅はすぐに正常範囲に戻りました。これは、クライアントが SYN パケットから CE フラグを送信する理由を確認する際の一時的な修正です。私はこれがいくつかのシステムがECNを使用するようにネゴシエートする方法である可能性があることを読みましたが、これは別のトピックです。