シナリオ：多数のWindowsクライアントが、大規模なファイル（FTP / SVN / HTTP PUT / SCP）を約100〜160ms離れたLinuxサーバーに定期的にアップロードしています。オフィスには1Gbit / sの同期帯域幅があり、サーバーはAWSインスタンスであるか、米国DCで物理的にホストされています。
最初のレポートは、新しいサーバーインスタンスへのアップロードが、可能な限りはるかに遅いというものでした。これは、テストと複数の場所で発生しました。クライアントは、Windowsシステムからホストへの安定した2-5Mbit / sを確認していました。
私はiperf -s、AWSインスタンスで、次にオフィスのWindowsクライアントから始めました。
iperf -c 1.2.3.4
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55185
[ 5] 0.0-10.0 sec 6.55 MBytes 5.48 Mbits/sec
iperf -w1M -c 1.2.3.4
[ 4] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 55239
[ 4] 0.0-18.3 sec 196 MBytes 89.6 Mbits/sec
後者の数値は、その後のテスト（Vagaries of AWS）で大幅に変化する可能性がありますが、通常は70〜130Mbit / sであり、ニーズを十分に満たしています。セッションをWiresharkingすると、次のことがわかります。
iperf -cWindows SYN-ウィンドウ64kb、スケール1-Linux SYN、ACK：ウィンドウ14kb、スケール：9（* 512）
iperf -c -w1MWindows SYN-Windows 64kb、スケール1-Linux SYN、ACK：ウィンドウ14kb、スケール：9
リンクがこの高いスループットを維持できることは明らかですが、ウィンドウサイズを明示的に設定して使用する必要がありますが、実際のアプリケーションではほとんどできません。TCPハンドシェイクはそれぞれの場合に同じ開始点を使用しますが、強制されたものはスケーリングします
逆に、同じネットワーク上のLinuxクライアントからiperf -c（システムのデフォルト85kbを使用して）ストレートに：
[ 5] local 10.169.40.14 port 5001 connected with 1.2.3.4 port 33263
[ 5] 0.0-10.8 sec 142 MBytes 110 Mbits/sec
強制なしで、期待どおりに拡張します。これは、介在するホップやローカルのスイッチ/ルーターに存在するものではなく、Windows 7と8のクライアントにも同様に影響するようです。自動チューニングに関する多くのガイドを読みましたが、これらは通常、スケーリングを完全に無効にして、ひどいホームネットワーキングキットを回避することに関するものです。
誰がここで何が起こっているのか教えてくれて、それを修正する方法を教えてもらえますか？（できれば、GPOを介してレジストリに固執することができます。）
ノート
問題のAWS Linuxインスタンスには、次のカーネル設定が適用されていsysctl.confます：
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216
サーバーエンドでdd if=/dev/zero | ncリダイレクトを使用し/dev/nullて、iperf他の可能性のあるボトルネックを除外および削除しましたが、結果はほぼ同じです。用いた試験ncftp（Cygwinの、ネイティブのWindows、Linux）のそれぞれのプラットフォーム上で上記iperfのテストとほぼ同じ方法で、スケール。
編集
ここで、関連する可能性のある別の一貫したものを見つけました。
これは1MBキャプチャの最初の1秒で、ズームインされています。ウィンドウが拡大し、バッファーが大きくなると、スロースタートの動作を確認できます。デフォルトのウィンドウiperfテストが完全に平坦化する時点で、まさにこの0.2秒の小さなプラトーがあります。もちろん、これはめまいがするほどの高さにスケーリングしますが、スケーリングする前にスケーリングにこの一時停止があることは興味深いです（値は1022バイト* 512 = 523264です）。
更新-6月30日。
さまざまな回答のフォローアップ：
- CTCPの有効化-これは違いはありません。ウィンドウのスケーリングは同じです。（これを正しく理解している場合、この設定により、輻輳ウィンドウが到達できる最大サイズではなく、拡大される割合が増加します）
- TCPタイムスタンプを有効にします。-ここでも変更はありません。
- Nagleのアルゴリズム-それは理にかなっており、少なくとも問題の兆候としてグラフ内の特定のブリップをおそらく無視できることを意味します。
- pcapファイル：Zipファイルはこちらから入手できます：https ://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.zip（bittwisteと匿名、150MBに抽出されます）比較のために各OSクライアントから1つ）
更新2-6月30日
O、カイルの提案の操作に従って、ctcpを有効にし、煙突オフロードを無効にしました：TCPグローバルパラメータ
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : enabled
Initial RTO : 3000
Non Sack Rtt Resiliency : disabled
しかし、悲しいことに、スループットに変化はありません。
ただし、ここには原因/結果に関する質問があります。グラフは、サーバーからクライアントへのACKに設定されたRWIN値のものです。Windowsクライアントでは、クライアントの制限されたCWINがそのバッファーでさえも満たされないため、Linuxはこの値をその下限を超えてスケーリングしないと思いますか？Linuxが人為的にRWINを制限している他の理由はありますか？
注：私はECNを有効にすることを試みました。変化はありません
更新3-6月31日。
ヒューリスティックおよびRWIN自動調整を無効にしても、変更はありません。デバイスマネージャータブを介して機能調整を公開するソフトウェアを使用して、Intelネットワークドライバーを最新（12.10.28.0）に更新しました。カードは82579VチップセットオンボードNICです-（realtekまたは他のベンダーのクライアントからさらにテストを行います）
しばらくNICに注目して、次のことを試しました（ほとんどの場合、ありそうもない犯人を除外します）。
- 受信バッファーを256から2kに増やし、送信バッファーを512から2kに増やします（両方とも最大）-変更なし
- すべてのIP / TCP / UDPチェックサムオフロードを無効にしました。- 変化なし。
- 大量送信オフロードの無効化-Nada。
- IPv6、QoSスケジューリングをオフにしました-Nowt。
更新3-7月3日
Linuxサーバー側を排除しようとして、Server 2012R2インスタンスを起動し、iperf（cygwin binary）とNTttcpを使用してテストを繰り返しました。
でiperf、私は明示的に指定する必要がありました-w1m上で、両方の接続が〜5Mbit / sのを超える規模となる前に両側。（ちなみに、私はチェックすることができ、91msのレイテンシで〜5MbitsのBDPはほぼ正確に64kbです。限界を見つけてください...）
ntttcpバイナリはそのような制限を示しました。ntttcpr -m 1,0,1.2.3.5サーバーとntttcp -s -m 1,0,1.2.3.5 -t 10クライアントで使用すると、スループットが大幅に向上します。
Copyright Version 5.28
Network activity progressing...
Thread Time(s) Throughput(KB/s) Avg B / Compl
====== ======= ================ =============
0 9.990 8155.355 65536.000
##### Totals: #####
Bytes(MEG) realtime(s) Avg Frame Size Throughput(MB/s)
================ =========== ============== ================
79.562500 10.001 1442.556 7.955
Throughput(Buffers/s) Cycles/Byte Buffers
===================== =========== =============
127.287 308.256 1273.000
DPCs(count/s) Pkts(num/DPC) Intr(count/s) Pkts(num/intr)
============= ============= =============== ==============
1868.713 0.785 9336.366 0.157
Packets Sent Packets Received Retransmits Errors Avg. CPU %
============ ================ =========== ====== ==========
57833 14664 0 0 9.476
8MB / sは、明示的に大きなウィンドウで取得するレベルでそれを上げますiperf。奇妙なことに、1273個のバッファーで80MB = 64kBのバッファーを再び使用します。さらなるWiresharkは、クライアントが満足しているように見える、サーバー（スケールファクター256）から戻ってくる良い可変RWINを示しています。したがって、おそらくntttcpは送信ウィンドウを誤って報告しています。
更新4-7月3日
@karyheadのリクエストで、ここでhttps://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07-03.zipでさらにテストを行い、いくつかのキャプチャを生成しました 。
iperfWindowsから以前と同じLinuxサーバーへの2つの追加（1.2.3.4）：1つは128kソケットサイズでデフォルトの64kウィンドウ（再び〜5Mbit / sに制限されます）と1MBが送信ウィンドウでデフォルトが8kbソケットですサイズ。（より高いスケール）ntttcp同じWindowsクライアントからServer 2012R2 EC2インスタンス（1.2.3.5）への1つのトレース。ここでは、スループットが適切にスケーリングされます。注：NTttcpは、テスト接続を開く前にポート6001で奇妙なことを行います。そこで何が起こっているのか分かりません。/dev/urandomCygwinを使用して、ほぼ同一のLinuxホスト（1.2.3.6）に20MBをアップロードする1つのFTPデータトレースncftp。再び制限があります。パターンは、Windows Filezillaを使用した場合とほぼ同じです。
iperfバッファの長さを変更すると、時系列グラフに予想される差が生じますが（より多くの垂直セクション）、実際のスループットは変わりません。
netsh int tcp set global timestamps=enabled
