受信者はTCPウィンドウサイズを64,512に制限します
事実（虚偽の記述を特定してください）： 80ミリ秒離れた2つのサイト間に100 Mbpsの接続があります これは、おそらく最大100 Mbps * 0.08秒= 1,000,000バイトまでの大きなTCPウィンドウサイズの恩恵を受けることができる長い太った接続です。 両方のマシンでWindows Server 2012が実行されています。「ウィンドウ自動調整レベルの受信」は両方で正常です。「ウィンドウスケーリングヒューリスティック」は両方で無効になっています。 一方で「iperf -s」を実行し、もう一方で「iperf -c」を実行しました。転送は5 Mbpsで発生しました。私は同じ結果を別の方向に向かって得ます。 双方は、SYNでのTCPスライディングウィンドウのサポートをアドバタイズしました。 受信者は、「no shift」（0x000）のTCPウィンドウスケール値を使用して、全体の実行中に64,512バイト（0xFC00）のTCPウィンドウサイズを要求しました。 ネットワークは、より大きなウィンドウサイズを処理できました（以下のシーケンス図を参照） 受信機は、ネットワークがサポートするよりもウィンドウを小さくしました この接続はIPSEC VPN内で発生しています。トンネルインターフェイスのMTUは、両方向で1400バイトに削減されます。 質問 受信機がウィンドウを小さくしているのはなぜですか？ 非回答 ネットワークが壊れています 同じネットワークで実行されているLinuxマシンは、TCPウィンドウを1.5メガバイトまで開き、帯域幅の6倍でデータを送信します ウィンドウスケーリングヒューリスティックが有効になっています ウィンドウスケーリングヒューリスティックは無効です（以下の「netsh interface tcp show heuristics」の出力を参照） 受信ウィンドウの自動調整レベルは正常ではありません 受信ウィンドウの自動調整レベルは正常です（以下の「netsh interface tcp show global」の出力を参照） これは、ESXi内の仮想マシンではうまく機能しません。 同じホストで実行されている仮想Linuxマシンで6倍のパフォーマンスが得られます。 更新 2015年6月12日午後4時30分（PDT） 接続の片側にLinuxを配置することで、テストを変更しました。案の定、LinuxがWindows Server 2012にデータを送信するとき、Windowsは小さすぎるTCP受信ウィンドウ（64,512バイト）を提供します。 WindowsからLinuxにデータを送信すると、Linuxは十分に大きいTCP受信ウィンドウ（1,365,120バイト）を提供します。ただし、Windowsは送信中に最大で最大60,000バイトに送信を制限します。 更新2 2015年6月13日午後3:00 PDT …