TCPストリームの輻輳ウィンドウを観察したいので、vethペアとブリッジを介して互いに接続された2つのノード（Linuxネームスペースを使用）があります。
帯域幅を10mbpsに制限するために、各インターフェイスはキュー長1000パケットのhtb qdiscを使用しています。
それからiperfそれらの間でセッションを確立しました。
ビットレートがqdiscが形成する帯域幅に適応することがわかる。
ただし、pcapファイルとキュー削除カウンタを確認すると、結果として削除や再送信がまったくないように見えます。
2番目のストリームを開始すると、両方とも5mbpsの公平な共有を取得します。
どうなりますか？輻輳制御が信号を受信できない場合、TCP はどのようにトラフィックのサイズを変更しますか?私は何を逃したことがありませんか？
答え1
そして、TCPの小さなキュー機能が実際に動作しているのを見たようです。単一システム内では、TCPコンパクトキューはqdiscおよびデバイスバッファで待機しているパケットをデフォルト値の128 KBに制限します。
その制限に達すると、TCPは実際にはバッファオーバーフローなしで調整されます。
これは、ドロップを取得する3つのVMです。分離シミュレーションカーネル）一緒に - 送信者、「ルーター」と受信者。
netem待ち時間や限られた帯域幅をシミュレートするために使用するときに別のコンピュータ/VMを使用する理由がある可能性があることを曖昧に覚えています。全体的にこれは良いアプローチのようです。