この質問に答えるために理解する必要があるのは、WebSocketの作成プロセス全体で基盤となるTCP接続がどのように正確に進化するかということだと思います。WebSocket接続のスティッキーな部分は、基盤となるTCP接続自体であることがわかります。WebSocketのコンテキストでの「セッション」の意味がわかりません。
大まかに言うと、「WebSocket接続」を開始するには、クライアントがHTTP GETリクエストをHTTPサーバーに送信する必要がありますが、リクエストにはUpgradeヘッダーフィールドが含まれています。ここで、この要求が発生するためには、クライアントがHTTPサーバーへのTCP接続を確立している必要があります（これは明らかかもしれませんが、ここでこれを明示的に指摘することが重要だと思います）。後続のHTTPサーバー応答は、同じTCP接続を介して送信されます。
ここで、サーバーの応答が送信された後、クライアントまたはサーバーのいずれかによってアクティブに閉じられていない場合でも、TCP接続は開いている/生きていることに注意してください。
さて、RFC 6455、WebSocket標準によると、セクション4.1の終わりに：
サーバーの応答が上記のように検証された場合、WebSocket接続が確立され、
WebSocket接続がOPEN状態にある
と言われます。
ここから、最初のHTTP GET（アップグレード）要求を送信する前にクライアントによって開始されたものと同じTCP接続が開いたままになり、今後は全二重WebSocket接続のトランスポート層として機能することを読みました。そして、これは理にかなっています！
あなたの質問に関して、これは、ロードバランサーが最初のHTTP GET（アップグレード）要求が行われる前、つまり、2つの通信エンドポイント間でWebSocket接続の作成に関与する唯一のTCP接続が確立される前にのみ役割を果たすことを意味します。その後、TCP接続は確立されたままになり、その間のネットワークデバイスによって「リダイレクト」されることはありません。
セッションの用語では、TCP接続がセッションを定義していると結論付けることができます。WebSocket接続が有効である（つまり、終了されていない）限り、WebSocket接続は、定義上、独自のセッションを提供し、有効です。このセッションを変更できるものはありません。ただし、この図で言えば、2つの独立したWebSocket接続は同じセッションを共有できません。
「セッション」で他の何かを参照した場合、それはおそらくアプリケーション層によって導入されたセッションであり、そのセッションについてコメントすることはできません。
コメントに関して編集します。
つまり、ロードバランサーはTCP接続に関与していないということです。
いいえ、少なくとも一般的にはそうではありません。クライアント接続の試行をどうするかを決定できるという意味で、TCP接続の確立に確実に影響を与える可能性があります。詳細は、ロードバランサーの正確なタイプによって異なります（*、以下を参照）。重要：2つのエンドポイント間で接続が確立された後、ロードバランサーをエンドポイントとは見なしませんが、WebSocketクライアントとWebSocketサーバーを参照します。2つのエンドポイントは、WebSocket接続の存続期間中は変更されません。 。ロードバランサーは*まだネットワークパスにある可能性がありますが、影響を与えなくなったと見なすことができます。
したがって、全二重接続はクライアントとエンドサーバーの間にありますか？
はい！
***負荷分散にはさまざまな種類があります。タイプによって、2つのエンドポイント間の接続確立後のロードバランサーの役割は異なります。例：
- 負荷分散がDNSベースで行われる場合、ロードバランサーは最終的なTCP接続にまったく関与しません。どのホストに直接接続する必要があるかをクライアントに通知するだけです。
- ロードバランサーがAWSのレイヤー4ELBのように機能する場合（ドキュメントはこちら）、いわばTCP接続をプロキシします。したがって、クライアントは実際にはELB自体をサーバーと見なします。ただし、ELBはパッケージを変更せずに両方向に転送するだけです。したがって、それはまだ透過的にTCP接続に深く関わっています。この場合、実際には2つの永続的なTCP接続が関係しています。1つはユーザーからELBへ、もう1つはELBからサーバーへの接続です。これらは、WebSocket接続の存続期間中は永続的です。