WebSocketRFCのロードバランシングの使用に関する一般的な考慮事項。
コンセプト
WebSocket RFC接続は、次の2つの異なる方法で実行されます。
通常のWebSocket接続（1）：あらゆる種類の仲介者またはロードバランサーを介してルーティングでき、通常のHTTPリクエストのように動作します。
2つのABAPシステム間の接続（2） ： <sap-h2> ALPN拡張フィールドの存在に依存します。SAP Webディスパッチャはこのファイルをサポートしているため、この種の接続を処理できます。このような接続の負荷分散にSAPWebDispatcherを使用する場合、個々の論理WebSocket RFC接続は負荷分散の決定の対象となり、最も適切なアプリケーションサーバーに転送されます。つまり、着信HTTP/2接続はアプリケーションサーバー間で分割されます。同じことが通常のHTTP/2接続にも当てはまります。
他の仲介者は、ほとんどの場合、 <sap-h2> ALPN拡張フィールドをサポートしていません。フィールドが存在しない場合、クライアントとして機能するABAPシステムは、多重化されていない通常のWebSocket接続にフォールバックします。WebSocket RFC接続ごとに少なくとも3つの追加のネットワークラウンドトリップが必要になるため、これにはパフォーマンスの低下があります。ただし、ロードバランシングは、すべての「論理」WebSocketRFC接続に対して個別に機能するようになりました。
その結果、負荷分散WebSocket RFC接続は、個々の「論理」WebSocketRFC接続のレベルですべてのロードバランサーと連携します。ただし、各WebSocket RFC接続のネットワークラウンドトリップを排除する多重化は、ロードバランサーとしてSAPWebDispatcherでのみ機能します。
接続のアンバンドリング
複数のTCP接続を使用するとネットワークスループットが向上するため、単一のHTTP/2接続を介して2つのBAPシステム間のすべてのトラフィックを多重化することが最適でない場合があります。
プロファイルパラメータicm/client_multiplex_thresholdを使用すると、「論理」接続を単一の「物理」接続にバンドルする前に、設定された数までの「物理」HTTP/2接続を並行して使用するようにABAPサーバに指示することができます。この設定がなくても、要求が発生したときに最初の接続が新しい「論理」接続を開くことができない状態になっている場合、ABAPサーバクライアントが新しい「物理」接続を開くことがあります。したがって、2つのシステム間には常に1つの「物理的な」HTTP/2接続しかないという事実に頼ることはできません。
