ビッグIP孤立接続
私はこのレベルでのネットワーキングについて危険であると十分に知っていることを前もって述べさせてください。ですから、私が愚かなことを言うなら、親切にしてください。
3台のApacheサーバーの前でBigIPロードバランサーを使用しています。 3つのApacheサーバーはすべて同じ物理マシン（Linuxを実行）上にあり、3つの異なる仮想IPアドレスのポート80にバインドされていますが、それがこの問題に関与しているとは思いません。同じクライアントが毎回同じWEBサーバーを取得するようにLBを構成し、LBによって提供されるCookieを介して制御します。
LBを経由してアプリケーションにアクセスすると、ブラウザが回転するだけで戻ってこないページが表示されることがあります（5〜15％の確率で）。それぞれのWEBサーバーに直接アクセスしても、それはわかりません。 WireSharkを使用して、PC、LB、およびLBを介してヒットしていたWEBサーバーで何が起こっているかを調べたところ、次のことがわかりました。
1）ほとんどの場合、PCがLBにヒットするために使用したポートは、LBがWEBサーバーにヒットするために使用したポートでした。これは「正常」だと思いました。問題を再現した3回すべて、ポートが異なっていました（たとえば、PC/LB間で1234、LB/WEB間で2345）。しかし、それらが異なっていたすべての時間で問題が発生したわけではありません。これは赤いニシンかもしれません。
2）PC <-> LB通信は、1260バイト長のパケットを使用します。 LB-> WEBパケットは1260バイトですが、LB <-WEBパケットは1260の倍数です。WEBが2520バイトをLBに送信すると、LBは2x1260バイトのパケットでそれを受信し、1つのACKのみを送信します。次に、2x1260バイトのパケットをPCに送り返し、PCから1つのACKを受信します。 2520が2x1260に分割される理由も、PCが1つのACKのみを送信することを知っている理由もわかりません。これも赤ニシンかもしれません…。
3）ある時点で、WEBサーバーはACKを受信しないLBにデータを送信し、このデータシーケンスを開始したパケットを再送信します。なぜ再送信が行われるのかはわかりませんが、0.6秒しか経過していないため、タイムアウトになることはありません（可能性はあると思いますが、可能性は低いようです）。さらに、元のWEB-> LBパケットは5040バイト（4x1260）でしたが、再送信は1260のみです。LBは元の5040送信から4パケットすべてを受信しましたが、何らかの理由でACKを送信しませんでした。 LBが送信された5040バイトを処理できたときもありますが、正常に確認応答されたため、送信されたパケットの長さが問題であるようには見えません。ただし、これらのパケットはいずれもLBからPCに返送されませんでした。
4）ただし、データの最初の1260チャンクのみがWEBからLBに再送信されます。わずかな遅延（0.4秒）があり、最初の1260チャンクから開始して、データの2回目の再送信がありますが、今回はすべての4x1260パケットが再送信されます。ただし、LBによって返送されたACKは、そのうちの1つが明らかに2回再送信された場合でも、5つすべての再送信されたパケットに対するものです（これは、WireSharkによって示される相対シーケンス番号に基づいています。返送されたACKはseqと同じです。 2番目の再送パケットのシーケンス番号が最初の再送パケットと同じであっても、最初の再送パケットの番号+ 5x1260）。これは本当に悪いようです。
5）何よりも悪いのは、ポートがすべて台無しになることだと思います。元の会話ポートは次のとおりです。
PC <-> LB == 2723
LB <-> WEB == 2722
その会話の中で混ざり合っているのは、次のようなものです。
PC <-> LB == 2722
LB <-> WEB == 2723
寄り目で十分でしたが、パケットの内容に基づいて、会話が思ったポートで行われていることを確認しました（ugh）。 2番目の会話は正常に完了します（実際、このポートのセットには2つの会話があり、どちらも正常に完了します）。最初の（中止された？）再送信パケットが送信された後、4x1260再送信の2番目のセットが送信される前に、会話があります。
PC <-> LB == 2722
LB <-> WEB == 2722
そのため、ポート2722での元のLB <-> WEB会話が中断されます。私はこれが議定書の下で許可されているとは思いませんでした。このポートでは、どちらの方向にもFINまたはSYNは送信されません。この新しく開始された会話のためにLB-> WEBから送信されたシーケンス番号は、私が期待しているものです。 WEBからLBへのACKのシーケンス番号は正しいですが、ACKはオフになっています（正確に1260まで）。
4x1260が再送信された後、WEBは別の新しい1260チャンクのデータを送信し、そのすべてが元の要求からの応答であるため、この2番目の会話は決して行われないようです（パケット内のデータを調べることによって決定されます）。 ）。次に、LBはACKを送り返します。これは、元の会話（最後のACK + 4x1260 + 1260）から予想されるものです。
だから、私は何が起こっているのかについての手がかりを持っていますが、なぜそれが起こるのか分かりません、そして確かにそれを修正する方法についての手がかりはありません。ここからどこへ行くの？
編集：私はちょうど何かを思い出しました。 WEBからLBへの4x1260の再送信の途中で、LBは私が予想するよりも正確に100バイト多いACKを送り返します。ただし、新しいデータの最初の1260パケットが送信された後、LBは正確に本来あるべきACKを送り返します（つまり、それ自体が修正されます）。それがどのように起こり得るのか、それが何を意味するのか、あるいはそれが意味があるとしても、私にはわかりません。
Tcpポートは、クライアント上、およびBIG-IPのサーバー側（現在はWebサーバーのクライアント）で必要に応じて変更されます。 BIG-IPがクライアントとサーバーへの完全に別個のTCP接続を処理するため、これは予想される動作です。
プロキシはクライアントとサーバー間の個別の接続を処理するため、通常のTCPの動作は、接続のクライアント側とサーバー側で異なる動作をします。何TCPプロファイル適用すると、プロキシのどちら側に適用するか（接続のクライアント側とサーバー側に異なるプロファイルを適用することも、両方に同じプロファイルを適用することもできます。使用例とネットワーク環境に応じて、あなた次第です）は、実際にネットワーク上にあるデータを変更します。確認応答が送信される時間と回数および頻度。
再送信は一般的であり、tcpスタックがネットワークの輻輳を処理する方法は、接続のクライアント側とサーバー側の両方で配置されているスタックによって異なります。ここでも、クライアント-> BIG-IP->サーバーのシナリオでは、2つのクライアントと2つのサーバーがあります。
見た動作を診断するには、キャプチャ全体を確認する必要があります。
ここでは、TCPポートが問題になるとは思わないでください。
詳細がないので、カスタムプロファイルの代わりにストックtcpプロファイルが有効になっていて、アプリケーションで正常に動作しなかったと思います。カスタムプロファイルを利用し、TCPフローおよび輻輳制御アルゴリズムがどのように機能するか、およびTCPプロファイルのどの設定が特定の場合にうまく機能しないか）についての知識を持っている人を雇うことを強くお勧めしますアプリケーション。数年前にBIG-IP TCPプロファイルで10部構成のシリーズを作成しました（それ以降、すべての変更で更新を使用できますが、それでも優れた情報源です）。役立ちます： https://devcentral.f5.com/articles/investigating-the-ltm-tcp-profile-nagles-algorithm
私が目立つのは、Webサーバーが同じマシン上にあり、異なるIPアドレスを使用していることです。すべてのサーバーを1つのボックスに配置した場合、負荷分散では実際には何も得られません。
パケットで説明する内容の一部は正常に見えます。 Wiresharkの「エキスパート情報」および「フォローTCPストリーム」機能を使用しましたか？これらは、TCP接続の高レベルのビューを表示します。 Wiresharkがすべてのパケットをキャプチャしているとは限らないことに注意してください（特にギガビットイーサネットを使用している場合）。
問題については、すべてのWebサービスが同じボックス上にあるという事実によって明らかにされたLBのバグが発生している可能性があります。つまり、3つのIPアドレスがすべて同じMACアドレスを持っているということです。 LBがMACアドレスを使用して接続を追跡する場合、3つのサーバーIPアドレスを混乱させ、パケットを間違った場所に転送する可能性があります。