13

私は最近、小さな EC2 インスタンス (m1.small) で 1 秒あたり約 2,000 の新しい接続要求を処理することがテストされている Node.js ベースの Web ソケット サーバーをセットアップしました。m1.small インスタンスのコストと、複数のインスタンスを HAProxy などの WebSocket 対応プロキシ サーバーの背後に置く機能を考慮すると、結果には非常に満足しています。

ただし、SSL を使用したテストをまだ行っていないことに気付き、いくつかの SSL オプションを調べました。プロキシ サーバーで SSL 接続を終了することが理想的であることが明らかになりました。これは、プロキシ サーバーがトラフィックを検査し、X-Forward-For などのヘッダーを挿入して、サーバーが要求の送信元の IP を認識できるようにするためです。

そこで、私は Pound、stunnel、スタッドなどの多くのソリューションを調べました。これらはすべて、443 で着信接続を終了できるようにし、ポート 80 で HAProxy に渡し、次に接続を Web サーバーに渡します。しかし残念なことに、c1.medium (高 CPU) インスタンス上の SSL ターミネーション プロキシ サーバーにトラフィックを送信すると、すべての CPU リソースが非常に速く消費され、1 秒あたり 50 リクエスト程度しか消費されないことがわかりました。上記の 3 つのソリューションをすべて使用してみましたが、いずれも OpenSSL に依存していると思われるのとほぼ同じように動作しました。64 ビットの非常に大きな High CPU インスタンス (c1.xlarge) を使用してみましたが、パフォーマンスはコストに比例してしか変化しないことがわかりました。したがって、EC2 の料金に基づくと、1 秒あたり 200 件の SSL リクエストに対して約 600 ペンス/月を支払う必要があります。1 秒あたり 000 件の非 SSL リクエスト。1 秒あたり 1,000 または 10,000 のリクエストを受け入れることを計画し始めると、前者の価格は経済的にすぐに実行不可能になります。

また、Node.js の https サーバーを使用して SSL を終了しようとしましたが、パフォーマンスは Pound、stunnel、およびスタッドと非常に似ていたため、そのアプローチに対する明らかな利点はありません。

だから私が誰かに助けてもらいたいのは、SSL接続を提供するために吸収しなければならないこのばかげたコストを回避する方法をアドバイスすることです. ハードウェアは SSL の暗号化と復号化用に設計されているため、SSL ハードウェア アクセラレータのほうがはるかに優れたパフォーマンスを提供すると聞いていますが、現在すべてのサーバーに Amazon EC2 を使用しているため、個別のデータがない限り、SSL ハードウェア アクセラレータを使用することはできません。物理サーバーを備えたセンター。私は、Amazon、Google、Facebook などの企業が SSL 経由ですべてのトラフィックを提供する方法を理解するのに苦労しています。SSL のコストが非常に高い場合です。そこにはもっと良い解決策があるはずです。

アドバイスやアイデアをいただければ幸いです。

ありがとうマット

4

4 に答える 4

5

さまざまな EC2 インスタンスで利用可能な CPU パワーについてはあまり知りませんが、問題は TLS 終端プロキシ ソフトウェアの選択ではなく、その構成にあると思います。構成がなければ、(非常に) 遅いものを含め、サポートするすべての暗号スイートをすべて提供すると思います。また、クライアントが最も気に入ったものを選択できるようにすることもあるでしょう。

すべての TLS 暗号スイートが同じように生まれるわけではありません。鍵交換や暗号自体に起因するものなど、CPU コストが他よりも高いものもあります。使用するソフトウェアに応じて、サーバーが受け入れる暗号の文字列を指定する方法 (およびサーバーにそれを要求させる方法) が必要です。OpenSSL の場合、これらは次のように機能します: http://www.openssl.org/docs/apps/ciphers.html#CIPHER_STRINGS

速度を重視する場合は、少なくとも Diffie-Hellmann (非楕円曲線の種類) のキー交換を使用する暗号を使用していないことを確認してください。DH 鍵交換を使用して暗号スイートを無効にするには、文字列が!DHある時点で含まれていることを確認してください。たとえば、openssl ciphers -v 'HIGH:!aNULL:!DH:!ECDH'.

この文字列は、通常の Diffie-Hellman 鍵交換と楕円曲線 Diffie-Hellmann 鍵交換の両方を無効にします。OpenSSL のバージョンによっては、おそらく RSA 鍵交換のみが残ります。

暗号に関しては、意図した EC2 ハードウェアでテストする必要があります。ハードウェア アクセラレーションがなければ、少なくともこのベンチマークによると、AES256 よりも AES128 よりも RC4 を優先する必要があります。

また、この素晴らしい投稿を読むことをお勧めします。特に、DH が TLS ハンドシェイク パフォーマンスに与える影響を示す啓発的な最初の図です。

最後に、TLS セッション キャッシングを使用していることを確認してください。これにより、CPU も節約されます。

于 2012-06-20T23:25:15.620 に答える
0

また、これを効果的に行う方法も考えています。AWS ssl の終了は非常に遅いですが、パフォーマンスを改善する方法があるかもしれません。スタッドは有望に思えましたが、あなたが言及したように、CPU コストも大きくなります。

于 2012-02-27T18:13:06.050 に答える
0

Node.js の https サーバーのパフォーマンスは、Pound、stunnel、およびスタッドに非常に似ており、そのアプローチには明確な利点はありません。

于 2012-02-06T09:59:52.007 に答える