Windows7上のTCP/IPがウォームアップに500回送信するのはなぜですか？

Question

Windows 7のZeroMQで、奇妙で説明できない現象が見られました.TCP経由でメッセージを送信しています。 _{（またはinproc、ZeroMQはWindowsでシグナリングに内部的にTCPを使用するため）。}

この現象は、最初の500個のメッセージが遅く到着し、遅く到着し、待ち時間が着実に増加するという現象です。次に、CPU /ネットワークの競合によって引き起こされるスパイクを除き、レイテンシが低下し、メッセージが一貫して高速に到着します。

問題は、ここで説明されています。https://github.com/zeromq/libzmq/issues/1608

それは一貫して500件のメッセージです。遅れなく送信すると、メッセージは一括送信されるので、数千回の送信を超える現象が見られます。センドを遅らせるとグラフがよりはっきり見えます。センド間で50〜100ミリ秒も遅らせることさえ変わらない。

メッセージのサイズも無関係です。私は10バイトメッセージと10Kメッセージでテストしましたが、同じ結果が得られました。

最大レイテンシは常に2ミリ秒（2,000マイクロ秒）です。

Linuxボックスでは、この現象はありません。

私たちがやってみたいのは、この初期のカーブを取り除くことです。そのため、通常の低レイテンシ（約20-100usec）で新鮮な接続を維持します。

---

更新：問題は、のみのWindows 上を発生するようWindowsの10も8上に表示されません。

Answer 1

原因と回避策が見つかりました。これは、受信側でのバッファリングに起因するWindows 7（少なくとも）上のすべてのTCPアクティビティに関する一般的な問題です。あなたは "TCP slow start"の下の行にいくつかのヒントを見つけることができます。

新しい接続で、または接続がアイドル（150msec以上）の場合、受信バッファが着信パケットをバッファし、は、受信バッファがいっぱいになるまで、またはがアプリケーションにこれらを提供しない一部のタイムアウトが終了します（不明です）。

私たちがインタースレッドシグナリング用にTCPソケットを使用しているZeroMQの回避策は、新しい信号ペアに関するデータのダミーチャンクを送信することです。これは、TCPスタックを強制的に「正常に」動作させ、約100〜150マイクロ秒の一貫した待ち時間を見せます。

これは一般的に有用かどうかわかりません。ほとんどのアプリケーションでは、受信時に少し待つのが有益です。そのため、TCPスタックは呼び出し元のアプリケーションにもっと多くを提供できます。

しかし、小さなメッセージをたくさん送信するアプリでは、この回避策が役立ちます。

接続がアイドル状態の場合、スロースタートが再度発生するため、接続が重大な場合は100ミリ秒ごとにハートビートする必要があることに注意してください。