0

これは私の質問hereのフォローアップです。ここでは、HTTPS と HTTP リクエストのクエリ時間に大きな違いがあることを発見しました。サーバーまでの距離が大きいほど、この違いは大きくなりました。

このハンドシェイクのオーバーヘッドについて、わかりやすい説明を見つけました。そして、それを実際に解決することはできませんが、それ以降のリクエストでは、キープアライブと組み合わせて SSL セッションを使用することが重要です。キープアライブがオンになっています。ただし、SSL ID はリクエストごとに異なります (jetty を使用してssl_session_id プロパティを読み取っています)。

この質問に従って、サーバーだけでなくクライアントも変更する必要があることがわかりましたが、まだ混乱しており、確信が持てません (この質問に対する答えは確実に聞こえないようです)。

ブラウザの場合: API に対して JavaScript クエリを実行する場合、どうにかしてそれを有効にする必要がありますか?

Jetty の場合:こちらで説明されているように、jetty の allowRenegotiate 設定もオフにする必要がありますか? しかし、これにはいくつかのセキュリティへの影響があるように見えます。現在、許可が安全かどうかは完全にはわかりません ( docsから取得):

SSL 再ネゴシエーションを許可するかどうかを設定します。CVE-2009-3555 は、再ネゴシエーションによる SSL/TLS の脆弱性を発見しました。JVM で CVE-2009-3555 が修正されていない場合、再ネゴシエーションは許可されません。CVE-2009-3555 は Sun Java 1.6 で修正され、u19 では再交渉が禁止され、u22 では RFC5746 が適用されました。

4

1 に答える 1

0

あなたが実際に何を求めているのかよくわかりません。HTTPS はオーバーヘッドが大きいため、常に HTTP よりも遅くなります。

ただし、応答時間を短縮するためにおそらくできることがあります。たとえば、ほとんどのオペレーティング システムは、小さすぎる tcp の初期輻輳サイズを使用しています。これにより、TCP ハンドシェイクのためだけに追加のラウンドトリップが発生します。通常、ラウンドトリップ時間は 20 ミリ秒から最大数秒の間 (海外のサーバーへのネットワークが遅い) であるため、SSL 接続の確立にかかる時間を大幅に改善できます。

Linux システムについては、https: //lwn.net/Articles/427104/ をご覧ください。カーネル >2.6.39 または >3.x で十分です。

于 2013-04-11T15:14:47.807 に答える