2

このリンクの指示に従いました: How do you get Amazon's ELB with HTTPS/SSL to work with Web Sockets? Websocket で動作するように ELB をセットアップします (TCP モードで ELB を 443 から 8443 に転送します)。現在、wss でこの問題が発生しています。サーバーはメッセージ 1 を送信しますが、クライアントはそれを受信しません。数秒後、サーバーはメッセージ 2 を送信し、クライアントは両方のメッセージを受信します (両方のメッセージは約 30 バイトです)。問題をかなり簡単に再現できます。サーバー上で iptable でポート フォワーディングを設定し、クライアントがサーバー (ポート 443) に直接接続している場合、問題は発生しません。また、問題は wss にのみ発生するようです。ws は正常に動作します。

サーバーはjetty8を実行しています。

EC2 フォーラムをチェックしましたが、実際には何も見つかりませんでした。誰かが同じ問題を見たことがあるかどうか疑問に思っています。

ありがとう

4

2 に答える 2

2

あなたの説明から、これはELBのバッファリングの問題である可能性が高いです。簡単な調査によると、これが実際に問題であることが示唆されています。

ELBドキュメントから：

フロントエンド接続とバックエンド接続の両方に TCP を使用すると、ロード バランサーはヘッダーを変更せずにリクエストをバックエンド インスタンスに転送します。この構成では、セッション スティッキまたは X-Forwarded-* ヘッダー用の Cookie も挿入されません。

フロントエンド接続とバックエンド接続の両方に HTTP (レイヤー 7) を使用する場合、ロード バランサーはリクエストのヘッダーを解析し、接続を終了してから、登録されたインスタンスにリクエストを再送信します。これは、Elastic Load Balancing によって提供されるデフォルトの設定です。

AWS フォーラムから:

これは HTTP/HTTPS 固有のものですが、構成可能ではないと思いますが、確かだとは言えません。ポート 80 で単純な TCP モードで ELB を使用してみることをお勧めします。これは、バッファリングなしでクライアントにトラフィックを渡すだけであり、その逆も同様です。

さらに測定を行って、この遅延がメッセージ サイズにどのように依存するかを確認できますか?

さて、私はあなたがすでに何をし、何が失敗し、何が失敗しなかったのか完全にはわかりません. ただし、ドキュメントとフォーラムの投稿から、ソリューションはフロントエンドとバックエンドの両方に TCP/SSL (レイヤー 4) ELB タイプを使用しているようです。

于 2013-03-07T13:54:22.167 に答える
0

これは「ネーグルのアルゴリズム」に共鳴します...TCPスタックは、トラフィックを減らすためにネットワーク経由で送信する前にリクエストをバンドルするように構成できます。これは症状を説明しますが、試してみる価値があります

于 2016-02-04T00:58:19.903 に答える