本当に必要なのは、次の画像を理解するための助けだけですが、背景を説明します。
ポート 8080 でプロキシを使用するように設定され、インターネット アクセスを必要とするアプリがあります。1 日を通してランダムな時間に、アプリは接続に失敗し、停止します。原因を突き止めようとしています。FW とプロキシ URL ルールを除外しました (機能しているときは常に同じ URL にアクセスし、いずれにせよ失敗します)。問題は、プロキシ自体のパフォーマンスの問題によるネットワーク関連だと思います。原因を突き止めるために、問題が発生するたびにネットワーク キャプチャを取得しています。
次の画像を見ると、IP の詳細が削除されたスニペットが示されています。ソースが「42」の最初の行は、ポート 8080 のプロキシ (IP 35) を介して TLS 要求を行っているクライアント マシンです。注: 通常は正常に動作し、同じ URL/IP を要求しますが、今回は失敗したケースの 1 つです。下のウィンドウは、最初の緑色の行の詳細です。
強調表示された部分「次のシーケンス番号」は、35 (最後から 2 番目の行) から最後に返されたパケットの ACK と一致します。これは基本的に、35 がクライアントに送信されたすべてのデータを受信したことをクライアントに返信しているものです (これは、デバイスがデータの受信を確認したため、デバイスが起動していることを意味します (つまり、FW またはネットワークの問題はありません))。ただし、データを返送していないことに注意してください。この直後に、クライアントは TCP RST を発行します。これは私の解釈ですが、TCP スキルが少し鈍っているため、誰かに検証してもらいたいです。
クライアントはプロキシに何らかのリクエストを送信していますが、何らかの理由でプロキシが応答していません (アプリケーション層)。プロキシは TCP ACK で応答するため、ネットワーク層ではすべて正常であることを意味します。これは、データがネットワーク スタックを介してプロキシ自体に渡されるときに、接続を切断するのはプロキシであることを意味します。なぜそうなるのかはまだわかりませんが、プロキシ チームと話して調査する必要があることを伝えられるように説明を求めています (プロキシが原因ではないと考えています)。
私の主張を裏付ける他の証拠は、画像で RST の前に表示される最初の 4 行が何度も繰り返されていることです。これも、クライアントが要求を再送信しているが応答が得られず、最終的に諦めてリセットを発行することを意味します。
プロキシの前にロード バランサがあるようですが、プロキシは実際には複数のマシンです。バックエンドのマシンの 1 つに問題があり、LB がプールからノードを削除していないため、データがブラック ホールに送信されている可能性があると思います。
私はセカンドオピニオンを求めています。キャプチャに基づくと、上記の要約は正確でしょうか?
答え1
この直後にクライアントはTCP RSTを発行する。
すぐには送信されません。RST は、サーバーから最後の ACK が送信されてから 30 秒後にクライアントから送信されます。
... RSTの前の画像の最初の4行は何度も繰り返されます
これらは同じ行ではありません。ACK の値が異なります。
私の解釈では、クライアントはより大きなペイロードを持つリクエストを送信しており (したがって、これを確認するサーバーからの複数の ACK)、プロキシが応答を返すことを期待しています。 30 秒間応答がない場合、クライアントは諦めて RST で接続を閉じます。
プロキシが応答を送信しない理由は明らかではありません。プロキシの問題である可能性があります。ただし、上流サーバーの問題である可能性もあり、サーバーがクライアントに問題を伝播している可能性があります。
ただし、解釈が間違っている可能性があることに注意してください。コンテキストやパケット キャプチャがあまり提供されていないため、知識に基づいた推測になります。