web-dev-qa-db-ja.com

Windows TCPウィンドウスケーリングヒットプラトーが早すぎます

シナリオ：大きなファイル（FTP/SVN/HTTP PUT/SCP）を最大100〜160ミリ秒離れたLinuxサーバーに定期的にアップロードする多くのWindowsクライアントがあります。 1 Gbit/sの同期帯域幅がオフィスにあり、サーバーはAWSインスタンスであるか、米国のDCで物理的にホストされています。

最初のレポートでは、新しいサーバーインスタンスへのアップロードは、実際よりもはるかに遅いという報告がありました。これは、テストと複数の場所から退屈しました。クライアントは、Windowsシステムからホストに対して2〜5Mビット/秒の安定性を示していました。

AWSインスタンスでiperf -sを開始し、次にオフィスの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

後者の数値は、後続のテスト（AWSのVagaries）で大きく異なる可能性がありますが、通常は70〜130Mbit/sであり、これは私たちのニーズを十分に満たしています。セッションをWireshharkingして、私は見ることができます：

  • iperf -c Windows SYN-ウィンドウ64kb、スケール1-Linux SYN、ACK：ウィンドウ14kb、スケール：9（* 512） iperf window scaling with default 64kb Window
  • iperf -c -w1M Windows SYN-Windows 64kb、スケール1-Linux SYN、ACK：ウィンドウ14kb、スケール：9 iperf window scaling with default 1MB Window

リンクがこの高いスループットを維持できることは明らかですが、それを使用するにはウィンドウサイズを明示的に設定する必要があります。これは、ほとんどの実際のアプリケーションでは許可されていません。 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テストとほぼ同じ方法でスケーリングされます。

編集する

私はここで関連するかもしれない別の一貫したものを見つけました： enter image description here

これは、拡大された1MBキャプチャの最初の1秒です。ウィンドウが拡大し、バッファが大きくなると、 Slow Start の動作がわかります。デフォルトのウィンドウのiperfテストが永久に平坦化する時点で、この〜0.2秒の小さな高原正確にがあります。もちろん、これはディジエの高さに合わせてスケーリングされますが、スケーリングの一時停止（値は1022バイト* 512 = 523264）が行われる前に不思議です。

更新-6月30日。

さまざまな対応のフォローアップ：

  • CTCPを有効にする-これは違いがありません。ウィンドウのスケーリングは同じです。 （私がこれを正しく理解している場合、この設定は、輻輳ウィンドウが到達できる最大サイズではなく、輻輳ウィンドウが拡大される速度を上げます）
  • TCP timestamps。-ここでも変更なし。
  • Nagleのアルゴリズム-これは理にかなっており、少なくとも、グラフの特定のメッセージを問題の兆候として無視できることを意味します。
  • pcapファイル：ここにあるZipファイル： https://www.dropbox.com/s/104qdysmk01lnf6/iperf-pcaps-10s-Win%2BLinux-2014-06-30.Zip （bittwisteで匿名化） 、比較のために各OSクライアントから1つあるため、最大150MBに抽出します）

アップデート2-6月30日

O、Kyle提案の操作に従って、ctcpを有効にし、煙突のオフロードを無効にしました：TCP Global Parameters

----------------------------------------------
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自動チューニングを無効にしても変更はありません。デバイスマネージャーのタブを介して機能の微調整を公開するソフトウェアを使用して、インテルネットワークドライバーを最新（12.10.28.0）に更新しました。カードは82579VチップセットオンボードですNIC realtekまたは他のベンダーのクライアントからさらにテストを行います）

NIC=しばらくの間、次のことを試みました（ほとんどの場合、ありそうもない原因を除外するだけです）。

アップデート3-7月3日

Linuxサーバー側を排除しようとして、Server 2012R2インスタンスを起動し、iperf（cygwinバイナリ）と---（NTttcp を使用してテストを繰り返しました。

iperfを使用すると、接続が〜5Mbit/sを超える前に、-w1mをboth側で明示的に指定する必要がありました。 （ちなみに、私は確認でき、91ミリ秒のレイテンシで約5Mビットの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は、サーバーから戻ってくる適切な可変RWIN（スケールファクタ256）を示しています。したがって、ntttcpが送信ウィンドウを誤って報告している可能性があります。

アップデート4-7月3日

@karyheadのリクエストに応じて、さらにテストを行い、さらにいくつかのキャプチャを生成しました。ここでは https://www.dropbox.com/s/dtlvy1vi46x75it/iperf%2Bntttcp%2Bftp-pcaps-2014-07 -03.Zip

  • さらに2つのiperfs、両方ともWindowsから以前と同じLinuxサーバーへ（1.2.3.4）：1つは128kソケットサイズとデフォルトの64kウィンドウ（再び〜5Mbit/sに制限）と1MB送信ウィンドウとデフォルトの8kbソケットサイズ。 （より高いスケール）
  • 同じWindowsクライアントからServer 2012R2 EC2インスタンス（1.2.3.5）への1つのntttcpトレース。ここでは、スループットが適切にスケーリングされます。注：NTttcpは、テスト接続を開く前に、ポート6001で奇妙な動作をします。そこで何が起こっているのかわかりません。
  • 1つのFTPデータトレース。Cygwinncftpを使用して、ほぼ同じLinuxホスト（1.2.3.6）に20MBの/dev/urandomをアップロードします。再び限界があります。パターンは、Windows Filezillaを使用してもほとんど同じです。

iperfバッファーの長さを変更すると、時系列グラフに予想される違いが生じます（より多くの垂直セクション）が、実際のスループットは変わりません。

windowsnetworkingtcp
50
SmallClanger

Windows 7/8クライアントで複合TCP（CTCP）を有効にしてみましたか？.

読んでください：

高BDP送信のための送信側のパフォーマンスの向上

http://technet.Microsoft.com/en-us/magazine/2007.01.cableguy.aspx

...

これらのアルゴリズムはsmall BDPsおよびより小さな受信ウィンドウサイズに適しています。ただし、TCP大きな受信ウィンドウサイズの接続と大きなBDPを使用している場合（高速に配置された2つのサーバー間でデータを複製するなど）- 100ms往復時間のWANリンク、これらのアルゴリズム接続の帯域幅を完全に利用するのに十分な速さで送信ウィンドウを増加させない。

これらの状況でTCP接続の帯域幅をより有効に利用するために、次世代TCP/IPスタックには、複合TCP（CTCP）が含まれています。CTCP詳細送信ウィンドウを積極的に増やします受信ウィンドウサイズとBDPが大きい接続。CTCPは、遅延の変動と損失を監視することにより、これらのタイプの接続のスループットを最大化しようとします。さらに、CTCPはその動作を保証します他のTCP接続に悪影響を与えません。

...

CTCPは、Windows Server 2008を実行しているコンピューターではデフォルトで有効になっており、Windows Vistaを実行しているコンピューターではデフォルトで無効になっています。 netsh interface tcp set global congestionprovider=ctcpコマンドでCTCPを有効にできます。 netsh interface tcp set global congestionprovider=noneコマンドでCTCPを無効にすることができます。

2014年6月30日編集

cTCPが本当に「オン」になっているかどうかを確認する

> netsh int tcp show global

つまり.

enter image description here

POは言った：

これを正しく理解している場合、この設定は、輻輳ウィンドウが最大サイズではなく拡大されたレートを増やします到達できる

CTCPは送信ウィンドウを積極的に増やします

http://technet.Microsoft.com/en-us/library/bb878127.aspx

複合TCP

送信を防止する既存のアルゴリズムTCPピアがネットワークを圧倒することは、スロースタートおよび輻輳回避と呼ばれます。これらのアルゴリズムは、送信ウィンドウと呼ばれる送信者が送信できるセグメントの量を増やします。接続で最初にデータを送信するとき、および失われたセグメントから回復するとき。スロースタートは、送信ウィンドウを1つずつ増やしますTCP受信した各確認応答セグメントのセグメント（TCP Windowsの場合XPおよびWindows Server 2003）または確認済みの各セグメントの場合（TCP for Windows VistaおよびWindows Server 2008の場合）。輻輳回避により、確認応答されたデータのフルウィンドウごとに1つのフルウィンドウでウィンドウを送信するTCPセグメント.

これらのアルゴリズムは、LANメディアの速度およびTCPウィンドウサイズが小さい場合に適しています。ただし、TCP接続があり、受信ウィンドウサイズが大きく、帯域幅が大きい場合、 -delayプロダクト（高帯域幅および高遅延）、たとえば、高速リンクを介して配置された2つのサーバー間でデータを複製するWAN 100 ms往復時間のリンク、これらのアルゴリズムは送信を増加させない接続の帯域幅を完全に利用するのに十分な速度のウィンドウ。たとえば、1ギガビット/秒（Gbps）の場合WAN 100 msの往復時間（RTT）のリンク） 送信ウィンドウが最初に増加するまでに最大で1時間かかります受信者によってアドバタイズされている大きなウィンドウサイズと、次の場合に回復するある失われたセグメントです。

帯域幅をより有効に活用する of TCPこれらの状況での接続、次世代TCP/IPスタックには複合TCP（CTCP）が含まれます。CTCP受信ウィンドウサイズが大きく、帯域幅遅延製品が大きい接続の送信ウィンドウをさらに積極的に増やします。CTCPは、これらのタイプの接続のスループットを最大化しようとします遅延の変動と損失の監視。CTCPは、その動作も保証します他のTCP接続に悪影響を与えません。

Microsoftの内部で実施されたテストでは、50ミリ秒のRTTを使用した1 Gbps接続で、大容量ファイルのバックアップ時間がほぼ半分に短縮されました。帯域幅遅延積が大きい接続では、パフォーマンスがさらに向上します。 CTCPと受信ウィンドウの自動チューニングは連携してリンクの利用率を高め、大きな帯域幅遅延の製品接続のパフォーマンスを大幅に向上させることができます。

15
Pat

問題の明確化：

TCPには2つのウィンドウがあります。

  • 受信ウィンドウ：バッファに残っているバイト数。これは、レシーバーによって課されるフロー制御です。 TCPヘッダー内のウィンドウサイズとウィンドウスケーリング係数で構成されているため、wiresharkで受信ウィンドウのサイズを確認できます。TCP接続は受信ウィンドウをアドバタイズしますが、一般的に気になるのはデータの大部分を受信するものです。あなたの場合、クライアントがサーバーにアップロードしているので、それは「サーバー」です
  • 混雑ウィンドウ。これは、送信者によって課されるフロー制御です。これはオペレーティングシステムによって維持され、TCPヘッダーには表示されません。データの送信速度を制御します。

指定したキャプチャファイル内。受信バッファーがオーバーフローしないことがわかります。

enter image description here

私の分析では、送信ウィンドウ（つまり、輻輳制御ウィンドウ）が十分に開いていないため、RWINのRWINを満たすことができません。受信機。つまり、受信者は「Give me More」と言って、Windowsが送信者の場合、送信速度が十分ではありません。

これは、上のグラフでRWINが開いたままであり、往復時間が0.09秒、RWINが500,000バイト以下であることから、帯域幅遅延積による最大スループットが（500000 /0.09）* 8 =〜42 Mbit/s（そしてLinuxキャプチャの勝利で約〜5しか得られません）。

それを修正するには？

知りません。 interface tcp set global congestionprovider=ctcp送信ウィンドウ（輻輳ウィンドウの別の用語）が増えるため、私にとって正しいことのように思えます。あなたはそれが機能していないと言いました。だから念のために：

  1. これを有効にした後、再起動しましたか？
  2. Chimneyオフロードはオンですか？もしそうなら、実験としてそれをオフにしてみてください。これが有効になっているときに正確に何がオフロードされるのかはわかりませんが、送信ウィンドウの制御がその1つである場合、多分これが有効になっているとcongestionproviderは効果がありません...私は推測しているだけです...
  3. また、これはWindows 7より前のバージョンかもしれませんが、HKEY_LOCAL_MACHINE-System-CurrentControlSet-Services-AFD-ParametersのDefaultSendWindowとDefaultReceiveWindowと呼ばれる2つのレジストリキーを追加して試してみてください。これらが機能する場合でも、おそらくctcpがオフになっているはずです。
  4. さらに別の推測として、チェックアウトしてみてくださいnetsh interface tcp show heuristics。私はそれがRWINかもしれないと思うが、それは言っていないので、それが送信ウィンドウに影響を与える場合に備えて、それを無効/有効にすることで遊ぶかもしれない。
  5. また、ドライバーがテストクライアントで最新であることを確認してください。たぶん何かが壊れています。

ネットワークドライバーが何らかの書き換え/変更を行っている可能性を排除するために、オフロード機能をすべてオフにしてこれらすべての実験を試みます（オフロードが無効になっている間はCPUを監視してください）。 TCP_OFFLOAD_STATE_DELEGATED構造体 は、少なくともCWndオフロードが可能であることを意味するようです。

12
Kyle Brandt

@Patと@Kyleによる素晴らしい情報がここにあります。 TCP受信ウィンドウと送信ウィンドウの@Kyleの 説明 に間違いなく注意を払ってください。これについて混乱があったと思います。問題をさらに混乱させるために、iperfは用語受信、送信、または全体のスライディングウィンドウに関して、あいまいな用語の一種である_-w_設定の「TCPウィンドウ」。実際に行うことは、_-c_（クライアント）インスタンスおよびソケットは、_-s_（サーバー）インスタンスのバッファーを受信します。_src/tcp_window_size.c_の場合：

_if ( !inSend ) {
    /* receive buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_RCVBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
} else {
    /* send buffer -- set
     * note: results are verified after connect() or listen(),
     * since some OS's don't show the corrected value until then. */
    newTCPWin = inTCPWin;
    rc = setsockopt( inSock, SOL_SOCKET, SO_SNDBUF,
                     (char*) &newTCPWin, sizeof( newTCPWin ));
}
_

カイルが言及するように、問題はLinuxボックスの受信ウィンドウにあるのではありませんが、送信者は送信ウィンドウを十分に開いていません。それが十分に速く開かないということではなく、64kでキャップするだけです。

Windows 7のデフォルトのソケットバッファーサイズは64kです。 [〜＃〜] msdn [〜＃〜] でのスループットに関連するソケットバッファーサイズについてドキュメントが言っていることは次のとおりです

TCP Windowsソケットを使用する接続を介してデータを送信する場合、十分な量のデータを未送信（送信済みだが未確認）に保つことが重要ですTCP in最高のスループットを達成するための順序です。TCP接続で最高のスループットを達成するために未処理のデータ量の理想的な値は、理想的な送信バックログ（ISB）サイズと呼ばれます。ISB値は、 TCP接続の帯域幅遅延積と、受信者のアドバタイズされた受信ウィンドウ（および一部はネットワークの輻輳の量）の関数。

わかりました、何とか何とか何とか何とか、今ここに行きます：

一度に1つのブロックまたは非ブロックの送信要求を実行するアプリケーションは、通常、Winsockによる内部送信バッファリングに依存して、適切なスループットを実現します。特定の接続の送信バッファ制限は、SO_SNDBUFソケットオプションによって制御されます。ブロッキングおよびノンブロッキングの送信方法の場合、送信バッファの制限により、TCPで未処理に保持されるデータの量が決まります。接続のISB値が送信バッファーの制限より大きい場合、接続で達成されるスループットは最適ではありません。

64kウィンドウを使用した最新のiperfテストの平均スループットは5.8Mbpsです。これは、すべてのビットをカウントするWiresharkのStatistics> Summaryからです。おそらく、iperfはTCP 5.7Mbpsのデータスループットをカウントしています。FTPテストでも5.6Mbpsと同じパフォーマンスが見られます。

64kの送信バッファーと91msのRTTでの理論上のスループットは... 5.5Mbpsです。私には十分近い。

1MBウィンドウのiperfテストを見ると、tputは88.2Mbps（TCP dataの場合は86.2Mbps）です。1MBウィンドウの理論的なtputは87.9Mbpsです。ここでも、政府にとって十分に近い作業。

これが示すのは、送信ソケットバッファが送信ウィンドウを直接制御し、反対側からの受信ウィンドウと組み合わせてスループットを制御することです。アドバタイズされた受信ウィンドウにはスペースがあるため、レシーバーによる制限はありません。

ちょっと待って、この自動調整ビジネスはどうですか？ Windows 7はこれらを自動的に処理しませんか？前述のように、Windowsは受信ウィンドウの自動スケーリングを処理しますが、送信バッファーも動的に処理できます。 MSDNページに戻りましょう。

TCPの動的送信バッファリングがWindows 7およびWindows Server 2008 R2に追加されました。デフォルトでは、アプリケーションがSO_SNDBUFを設定しない限り、TCPの動的送信バッファリングが有効になりますストリームソケットのソケットオプション。

_SO_SNDBUF_オプションを使用する場合、iperfは_-w_を使用するため、動的送信バッファリングは無効になります。ただし、_-w_を使用しない場合、_SO_SNDBUF_は使用されません。動的送信バッファリングはデフォルトでオンになっているはずですが、以下を確認できます。

_netsh winsock show autotuning
_

ドキュメントはあなたがそれを無効にすることができると言います：

_netsh winsock set autotuning off
_

しかし、それは私にはうまくいきませんでした。レジストリを変更して、これを0に設定する必要がありました。

_HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters\DynamicSendBufferDisable_

これを無効にしても役に立たないと思います。参考までに。

受信ウィンドウに十分なスペースがあるLinuxボックスにデータを送信するときに、送信バッファーのスケーリングがデフォルトの64kを超えないのはなぜですか？すばらしい質問です。 Linuxカーネルにも自動チューニングがありますTCPスタック。T-Painとカニエが一緒に自動チューニングデュエットを行うように、それはちょうどいい音ではないかもしれません。おそらくこれら2つの自動チューニングにいくつかの問題があるTCPスタックは互いに通信します。

別の人 はあなたと同じような問題を抱えており、レジストリの編集でそれを修正して、デフォルトの送信バッファサイズを増やすことができました。残念ながら、それはもう機能していないようです。少なくとも私が試したときは機能しませんでした。

この時点で、Windowsホストの送信バッファサイズが制限要因であることは明らかだと思います。動的に適切に成長していないように見えるので、どうすればよいですか。

あなたはできる：

  • 送信バッファ、つまりウィンドウオプションを設定できるアプリケーションを使用する
  • ローカルLinuxプロキシを使用する
  • リモートのWindowsプロキシを使用しますか？
  • Microsofhahahahahahahaでケースを開く
  • ビール

免責事項：私はこれを調査するのに何時間も費やしてきましたが、私の知る限り、そしてgoogle-fuにとっては正しいことです。しかし、私は母の墓に誓うつもりはありません（彼女はまだ生きています）。

5
karyhead

TCPスタックを調整しても、Winsockレイヤーにボトルネックがある可能性があります。Winsock（レジストリの補助関数ドライバー）を構成すると、アップロード速度に大きな違いがあることがわかりました（ Windows 7のサーバーへのデータのプッシュ）マイクロソフトは、非ブロッキングソケットの自動チューニングのTCP自動チューニング-ブラウザーが使用するソケットの種類だけです;-)のバグを認識しています。

DefaultSendWindowのDWORDキーを追加して、BDP以上に設定します。 256000を使用しています。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\AFD\Parameters\DefaultSendWindow

ダウンロードのWinsock設定を変更すると役立つ場合があります-DefaultReceiveWindowのキーを追加します。

Fiddler プロキシとコマンドを使用してクライアントとサーバーのソケットバッファーサイズを調整することにより、さまざまなソケットレベル設定を試すことができます。

prefs set fiddler.network.sockets.Server_SO_SNDBUF 65536 

fiddler.network.sockets.Client_SO_SNDBUF
fiddler.network.sockets.Client_SO_RCVBUF
fiddler.network.sockets.Server_SO_SNDBUF
fiddler.network.sockets.Server_SO_RCVBUF
4
LeslieM

回答のすべての分析を読んだので、この問題は、Windows7/2008R2、つまりWindows 6.1を実行している可能性があるようです

Windows 6.1のネットワークスタック（TCP/IPとWinsock）にはひどい欠陥があり、6.1の最初のリリースから何年にもわたって修正プログラムが長年にわたって解決されたバグとパフォーマンスの問題のホスト全体がありました。

これらの修正プログラムを適用する最善の方法は、support.Microsoft.comのすべての関連ページを手動でふるいにかけ、ネットワークスタックの修正プログラムのLDRバージョンを手動で要求してダウンロードすることです（これらの修正プログラムは数十あります）。

関連する修正プログラムを見つけるには、www.bing.comで次の検索クエリを使用する必要がありますsite:support.Microsoft.com 6.1.7601 tcpip.sys

また、LDR/GDRホットフィックストレインがWindows 6.1でどのように機能するかを理解する必要があります。

私は通常、Windows 6.1のLDR修正（ネットワークスタック修正だけでなく）の独自のリストを維持しており、遭遇したすべてのWindows 6.1サーバー/クライアントにこれらの修正を積極的に適用していました。新しいLDRホットフィックスを定期的にチェックすることは、非常に時間のかかる作業でした。

幸いなことに、Microsoftは新しいOSバージョンでのLDRホットフィックスの実行を停止し、バグフィックスはMicrosoftの自動更新サービスを通じて利用可能になりました。

[〜＃〜] update [〜＃〜]：Windows7SP1の多くのネットワークバグのほんの一例- https：// support。 Microsoft.com/en-us/kb/2675785

UPDATE 2：これは、SYNパケットの2回目の再送信後にウィンドウスケーリングを強制するnetshスイッチを追加する別の修正プログラムです（デフォルトでは、ウィンドウスケーリングは無効になっています） 2 SYNパケットが再送信されます） https://support.Microsoft.com/en-us/kb/2780879

3
Christoph Wegener

これは少し古い投稿だと思いますが、他の人の役に立つかもしれません。

つまり、「受信ウィンドウの自動チューニング」を有効にする必要があります。

netsh int tcp set global autotuninglevel=normal

CTCPは、上記を有効にしないと何も意味しません。

「Receive Window Auto-Tuning」を無効にすると、64KBのパケットサイズでスタックし、高ブロードバンド接続での長いRTTに悪影響を及ぼします。 「制限された」および「非常に制限された」オプションを試すこともできます。

非常に良いリファレンス： https://www.duckware.com/blog/how-windows-is-killing-internet-download-speeds/index.html

1
spricer

Windowsクライアント（Windows 7）でも同様の問題が発生していました。私はあなたが経験したほとんどのデバッグを行い、Nagleアルゴリズムを無効にし、TCP Chimney Offloading、およびその他の多くのTCP関連する設定変更を行いました。任意の効果。

最後にそれを修正したのは、AFDサービスのレジストリのデフォルトの送信ウィンドウを変更することでした。問題はafd.sysファイルに関連しているようです。私はいくつかのクライアントをテストしましたが、アップロードが遅いものもあれば、そうでないものもありますが、すべてWindows 7マシンでした。動作が遅いマシンには、同じバージョンのAFD.sysがありました。レジストリの回避策は、AFD.sysの特定のバージョンがインストールされているコンピューターで必要です（バージョン番号を思い出さないでください）。

HKLM\CurrentControlSet\Services\AFD\Parameters

追加-DWORD-DefaultSendWindow

値-10進数-1640960

その値は私がここで見つけたものでした： https://helpdesk.egnyte.com/hc/en-us/articles/201638254-Upload-Speed-Slow-over-WebDAV-Windows-

私は適切な値を使用すると思います、あなたはそれを使ってあなた自身でそれを計算するべきです：

例えば。アドバタイズされたアップロード：15 Mbps = 15,000 Kbps

（15000/8）* 1024 = 1920000

クライアントソフトウェアは通常、レジストリのこの設定をオーバーライドする必要がありますが、そうでない場合はデフォルト値が使用されます。AFD.sysファイルの一部のバージョンでは、デフォルト値が非常に低いようです。

私はほとんどのMS製品に遅いアップロードの問題（IE、Mini-redirector（WebDAV）、Windows Explorerを介したFTPなど）があったことに気づきました。サードパーティソフトウェア（例：Filezilla）を使用するとき、同じスローダウンはありませんでした。

AFD.sysはすべてのWinsock接続に影響するため、この修正はFTP、HTTP、HTTPSなどに適用する必要があります...

また、この修正は上記のどこかに記載されていたので、だれでも機能するのであればそれを信用したくありませんが、このスレッドには非常に多くの情報が含まれていて、見落とされているのではないかと心配しました。

1
jjspierx

まあ、私も同じような状況に遭遇しました（私の質問 here ）。結局、TCPスケーリングヒューリスティックを無効にし、手動で自動調整プロファイルを設定する必要がありました。 CTCPを有効にします。

# disable heuristics
C:\Windows\system32>netsh interface tcp set heuristics wsh=disabled
Ok.

# enable receive-side scaling
C:\Windows\system32>netsh int tcp set global rss=enabled
Ok.

# manually set autotuning profile
C:\Windows\system32>netsh interface tcp set global autotuning=experimental
Ok. 

# set congestion provider
C:\Windows\system32>netsh interface tcp set global congestionprovider=ctcp
Ok.
0
André Fernandes

これは魅力的なスレッドで、Win7/iperfを使用して長いファットパイプのスループットをテストしてきた問題と完全に一致します。

Windows 7のソリューションは、iperfサーバーとクライアントの両方で次のコマンドを実行することです。

netsh interface tcp set global autotuninglevel = experimental

注意：これを行う前に、自動チューニングの現在のステータスを記録してください。

netsh interface tcp show global

Receive Window Auto-Tuning Level：disabled

次に、パイプの両端でiperfサーバー/クライアントを実行します。

テスト後に自動調整値をリセットします。

netsh interface tcp set global autotuninglevel =

   autotuninglevel - One of the following values:
                     disabled: Fix the receive window at its default
                         value.
                     highlyrestricted: Allow the receive window to
                         grow beyond its default value, but do so
                         very conservatively.
                     restricted: Allow the receive window to grow
                         beyond its default value, but limit such
                         growth in some scenarios.
                     normal: Allow the receive window to grow to
                         accomodate almost all scenarios.
                     experimental: Allow the receive window to grow
                         to accomodate extreme scenarios.
0
wicksee

コメントするのに十分なポイントがないので、代わりに「回答」を投稿します。私は同様/同一の問題であると思われるものを持っています（serverfaultの質問 here を参照）。私の（そしておそらくあなたの）問題は、Windows上のiperfクライアントの送信バッファーです。 64 KBを超えることはありません。 Windowsは、プロセスによって明示的にサイズが設定されていない場合、動的にバッファを拡張することになっています。しかし、そのダイナミックな成長は起こっていません。

「遅い」Windowsケースで最大500,000バイトのウィンドウが開いていることを示すウィンドウスケーリンググラフについてはわかりません。 5 Mbpsに制限されていることを考えると、このグラフは最大64,000バイトしか開かないことが予想されました。

0
Chris Stankevitz