web-dev-qa-db-ja.com

SSLはどのくらいのオーバーヘッドを課しますか？

確かな答えはありませんが、一般的な答えはありますか 大きさの推定値 SSLの暗号化オーバーヘッドと暗号化されていないソケット通信の近似値アプリケーションレベルの処理をカウントするのではなく、通信処理と通信時間についてのみ説明しています。

更新

HTTPS対HTTPについての質問 がありますが、私はスタックの下位を見ることに興味があります。

（混乱を避けるために「大きさの順序」というフレーズを置き換えました。正式なCompSciの意味ではなく、非公式の専門用語として使用していました。もちろん、Ihad本当のオタクとして、10進数ではなく2進数を考えていたでしょう！;-)

更新

コメントのリクエストごとに、永続的な接続を介した適切なサイズのメッセージ（1k〜10kの範囲）について話していると仮定します。したがって、接続のセットアップとパケットのオーバーヘッドは重大な問題ではありません。

performancesocketsssloverhead
164
joel.neely

大きさのオーダー：ゼロ。

つまり、TLSを追加しても、スループットが半分になったり、それに似たものになったりすることはありません。 "duplicate" question への回答は、アプリケーションのパフォーマンスに重点を置いており、SSLオーバーヘッドと比較してどうですか。この質問は、特にアプリケーション処理を除外し、非SSLとSSLのみを比較しようとしています。最適化の際にパフォーマンスのグローバルな視点をとることは理にかなっていますが、それはこの質問が尋ねているものではありません。

SSLの主なオーバーヘッドはハンドシェイクです。そこで、高価な非対称暗号化が行われます。ネゴシエーションの後、比較的効率的な対称暗号が使用されます。そのため、多くの接続が行われているHTTPSサービスに対してSSLセッションを有効にすると非常に役立ちます。長期間有効な接続の場合、この「最終結果」はそれほど重要ではなく、セッションはそれほど有用ではありません。

興味深い逸話 GoogleがHTTPSを使用するようにGmailを切り替えたとき、追加のリソースは必要ありませんでした。ネットワークハードウェア、新しいホストはありません。 CPU負荷が約1％増加しただけです。

173
erickson

2番目の@erickson：純粋なデータ転送速度のペナルティはごくわずかです。最新のCPUは、数百MBit/sの暗号化/ AESスループットに達します。したがって、リソースに制約のあるシステム（携帯電話）を使用している場合を除き、TLS/SSLはデータをスリングするのに十分高速です。

ただし、暗号化を行うと、キャッシュと負荷分散がはるかに難しくなることに注意してください。これにより、パフォーマンスが大幅に低下する可能性があります。

ただし、接続のセットアップは、多くのアプリケーションにとって本当に重要なものです。低帯域幅、高パケット損失、高遅延接続（田舎のモバイルデバイス）では、TLSで必要な追加のラウンドトリップにより、何かが遅くなり、使用できなくなります。

たとえば、一部の社内Webアプリにアクセスするための暗号化要件を削除する必要がありました。中国から使用する場合は使用できません。

39
max

（更新で指定したように）接続セットアップをカウントしないと仮定すると、選択した暗号に強く依存します。ネットワークのオーバーヘッド（帯域幅の観点から）はごくわずかです。 CPUオーバーヘッドは暗号化によって支配されます。モバイルCore i5では、シングルコアのRC4で1秒あたり約250 MBを暗号化できます。 （最大のパフォーマンスを得るには、RC4を選択する必要があります。） AESは低速で、約50 MB /秒の「のみ」を提供します。そのため、正しい暗号を選択すると、1 Gbit回線を完全に使用していても、現在の単一のコアを暗号オーバーヘッドでビジー状態に保つことはできません。 [編集：RC4は安全ではないため、使用しないでください。ただし、AESハードウェアサポートは現在多くのCPUに存在しているため、このようなプラットフォームではAES暗号化が非常に高速になります。]

ただし、接続の確立は異なります。実装に応じて（例えば、TLS false startのサポート）、ラウンドトリップが追加され、顕著な遅延を引き起こす可能性があります。さらに、最初の接続確立で高価な暗号化が行われます（上記のCPUは、4096ビットキーを愚かに使用した場合は1コアあたり1秒あたり14接続のみを受け入れ、2048ビットキーを使用した場合は100接続を受け入れます）。後続の接続では、以前のセッションが頻繁に再利用され、高価な暗号化が回避されます。

要約すると、

確立された接続で転送：

  • 遅延：ほとんどなし
  • CPU：無視できる
  • 帯域幅：無視できる

最初の接続の確立：

  • 遅延：追加の往復
  • 帯域幅：数キロバイト（証明書）
  • クライアントのCPU：中
  • サーバーのCPU：高

後続の接続確立：

  • 遅延：追加の往復（1つまたは複数が実装に依存するかどうかは不明）
  • 帯域幅：無視できる
  • CPU：ほとんどなし
11
Jan Schejbal