検討中のアプリケーション（サーバー）には接続されているクライアントがたくさんあります。クライアントのすべてのメッセージを処理し、2つの出力メッセージを送信します。出力メッセージは順次生成され、ソケットに書き込まれます。私は時々、クライアントからの2番目の出力メッセージが長時間遅延することを観察しました。理由を理解しようとしています。
以下は、クライアントがキャプチャしたアプリケーションとクライアント間のフィルタ処理されたTCPフローです。
- 14908はクライアントが入力したメッセージです。 14910 および 15337 は 2 つの出力メッセージです。
- 14910 遅延がありません。しかし、15337は約40ms遅れます。
- 私が見ることができるように、15337パケットはack 15336が受信されるまで送信されません。
ソケットが EWOULDBLOCK または EAGAIN を返さない場合、アプリケーションはパケットを TCP 層に送信します。 ＃14908に公開されたウィンドウが1424で、＃15336（len = 229）がEWOULDBLOCKに送信されるべきではないため、ソケットがブロックされていないとします。
もしそうなら、TCP層が承認＃15336まで＃15337転送を遅らせる原因を理解するのに役立ちますか？
ベストアンサー1
14908はクライアントが入力したメッセージです。 14910 および 15337 は 2 つの出力メッセージです。
14910はクライアントへの応答です。明らかにPSHフラグが設定されているので、サーバーはすぐにそれを送信します。その後、サーバーはクライアントからACKを待ってから15337を送信します。
14910 遅延がありません。しかし、15337は約40ms遅れます。
これは、ACK（15336）がクライアントからサーバーに移動し、サーバーでそれを処理し、次のパケットがサーバーからクライアントに移動するのにかかる時間です。
私が見ることができるように、15337パケットはack 15336が受信されるまで送信されません。
正しい。これは通常TCPがどのように機能するかです。
それでは、これらの遅延の原因が何であるかを理解するのに役立ちますか？
お客様は、明確な回答を提供するのに十分な情報を提供していません。また、キャプチャされた画像ではなくフィルタ処理されたキャプチャ画像を提供することで、私たちの理解を制限しています。
パケット15337とパケット15756の間にはほぼ同じ時間差があることがわかります（わずかに短い、それぞれ39.87msおよび39.93ms）。この交換間のパケット数の差は419ですが、最初の交換のパケット数は426です。
したがって、最良の推測は、この「遅延」が、クライアントがサーバーにACKを送信することと、サーバーから到着する次のパケット間で多くの異なるトラフィックを送受信する結果であることです。
パケットキャプチャがなく、他のトラフィックが何であるかを知らせることができないため、詳細を知ることはできません。また、クライアントがどのようなハードウェアで実行されているのか、クライアントにどのくらいの負荷がかかるのかはわかりません。ただし、これらの詳細はすべてこのウェブサイトの範囲外です。