HTTPとHTTPSのパフォーマンス 質問する

これに対する答えは非常に簡単です。Webサーバーのパフォーマンスをプロファイルして、特定の状況でパフォーマンスがどの程度低下しているかを確認します。HTTPサーバーと HTTPS サーバーのパフォーマンスを比較するツールはいくつかあり (JMeter や Visual Studio が思い浮かびます)、非常に使いやすいです。

Web サイト、ハードウェア、ソフトウェア、ネットワーク構成の性質に関する情報がなければ、誰も意味のある回答を提供することはできません。

他の人が言っているように、暗号化によってある程度のオーバーヘッドが発生しますが、それは以下の要素に大きく依存します。

• ハードウェア
• サーバーソフトウェア
• 動的コンテンツと静的コンテンツの比率
• クライアントからサーバーまでの距離
• 典型的なセッションの長さ
• など（私のお気に入り）
• クライアントのキャッシュ動作

私の経験では、動的コンテンツを多く扱うサーバーでは、暗号化にかかる時間 (SSL オーバーヘッド) がコンテンツ生成時間に比べてわずかであるため、HTTPS による影響は少なくなる傾向があります。

メモリに簡単にキャッシュできる、比較的小規模な静的ページ セットの提供に重点を置くサーバーでは、オーバーヘッドがはるかに高くなります (あるケースでは、「イントラネット」でスループットが半分になりました)。

編集: 他の何人かが指摘した点の 1 つは、SSL ハンドシェイクが HTTPS の主なコストであるということです。これは正しいです。そのため、「一般的なセッションの長さ」と「クライアントのキャッシュ動作」が重要になります。

非常に短いセッションが多数ある場合、ハンドシェイクの時間が他のパフォーマンス要因を圧倒することになります。セッションが長くなると、セッションの開始時にハンドシェイクのコストが発生しますが、後続のリクエストのオーバーヘッドは比較的低くなります。

クライアント キャッシュは、大規模なプロキシ サーバーから個々のブラウザー キャッシュまで、いくつかのステップで実行できます。通常、HTTPS コンテンツは共有キャッシュにキャッシュされません (ただし、一部のプロキシ サーバーは中間者タイプの動作を利用してこれを実現できます)。多くのブラウザーは、現在のセッションの HTTPS コンテンツをキャッシュし、多くの場合は複数のセッションにまたがってキャッシュします。キャッシュしない、またはキャッシュが少ないと、クライアントは同じコンテンツをより頻繁に取得することになります。その結果、同じ数のユーザーにサービスを提供するために、より多くのリクエストと帯域幅が必要になります。