1

クライアントが SSL サーバーに再接続すると、SSL セッション キャッシュにより、そのクライアントが以前に使用したものと同じ暗号化合意を再計算する必要がなくなります (必要な通信ラウンド トリップも 2 回から 1 回に減少します)。

ただし、websocket プロトコルでは、正当な理由 (エラーが発生したか、ユーザーがブラウザー/アプリケーション タブ/ウィンドウを閉じたなど) がない限り、クライアントは決して websocket サーバーから切断してはならないと規定されています (?)。したがって、Websocket が SSL レイヤーの上に確立されると、サーバーは、特に通知されない限り、Websocket 接続が有効であると単純に想定できます。

さらに、Websocket サーバーは多数の同時接続を処理できる必要があり、SSL セッション キャッシュはすべての接続 (?) ごとに保存する必要があるため、この場合、これらのキャッシュを実装するとパフォーマンスが低下する可能性があります。メモリのオーバーヘッドですよね？

ごめん; これは複数の単純な質問かもしれませんが、これらの問題に対する私の理解が十分かどうかを確認したかったのです。

4

1 に答える 1

1

良い、

ソフトウェアアーキテクチャに依存する可能性があると思います。100 ページのサイトがあり、ユーザーがページ間を頻繁に移動するとします。それらの多くは、特別な目的のために websocket を持っていますが、そのページが表示されている間だけ有効に保たれます。WebSocket を頻繁に閉じたり開いたりしているので、キャッシュは理にかなっています。

一方、1 ページしかないサイトで Websocket を開く場合もあります。コンテンツは WebSocket および Ajax リクエストによって管理されますが、WebSocket はセッション全体を通じて維持されます。この場合、WebSocket の SSL をキャッシュしてもあまり意味がありません。

したがって、最終的には、実装に依存すると言えます。既にサイトがある場合は、その動作を分析し、キャッシュのニーズを調整する必要があります。一方、新しいサイトの設計を開始する場合は、さまざまなシナリオの長所と短所を知っておくと、より優れた効率的な設計を構築するのに役立つ場合があります。

よろしく

于 2013-05-31T08:22:59.400 に答える