web-dev-qa-db-ja.com

RHEL NginxSSLと非SSLのパフォーマンスには大きな違いがあります。

Nginx1.8リバースプロキシを設定中です。

要するに-

HTMLコンテンツのHTTPトラフィックの処理は、HTTPSよりも最大50倍高速です。

ProxyPass HTTPトラフィックの処理は、HTTPSよりも最大7倍高速です。

OSはRHEL7です

ハードウェア：

2 core VMWare Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz
cpu MHz         : 1897.802
cache size      : 15360 KB
bogomips        : 3795.60
1 Gbit network card

ベンチマーククライアントは、1ホップ離れたApacheベンチで、1ミリ秒のpingを実行します。 Apacheベンチは、実行時に次のTLSプロトコルを使用します。

TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

サーバーSSL証明書2048ビットRSA。 OCSPステープリングがオンになっており、検証されています。

/etc/sysctl.confには

net.ipv4.ip_local_port_range=1024 65000
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_fin_timeout=15
net.core.netdev_max_backlog=4096
net.core.rmem_max=16777216
net.core.somaxconn=4096
net.core.wmem_max=16777216
net.ipv4.tcp_max_syn_backlog=20480
net.ipv4.tcp_max_tw_buckets=400000
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_syn_retries=2
net.ipv4.tcp_synack_retries=2
net.ipv4.tcp_wmem=4096 65536 16777216
vm.min_free_kbytes=65536

/etc/security/limits.confには

nginx   soft    nofile  65536
nginx   hard    nofile  65536

Nginxはで構成されています

server {
  listen 443 ssl deferred backlog=1024;
  listen 80 deferred backlog=1024;

  server_name SERVERNAME;

  client_max_body_size 10m;

  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate path_to_/certificateAndChain.cer;
  ssl_certificate path_to_/certificateAndChain.cer;
  ssl_certificate_key path_to_/private.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers "EECDH+AES:EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES128-GCM-SHA256:AES128+EECDH:D$
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:32m;
  ssl_session_timeout 1m;

  #resolver 8.8.8.8 8.8.8.4 valid=1m;
  #resolver_timeout 5s;

  location / {
   proxy_pass_header Server;
   proxy_set_header Host $http_Host;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $remote_addr;
   proxy_set_header X-Scheme $scheme;
   proxy_connect_timeout 43200000;
   proxy_read_timeout 43200000;
   proxy_send_timeout 43200000;
   proxy_buffering off;
   proxy_http_version 1.1;
   proxy_set_header Connection "";

   proxy_pass http://IPADDRESS/;

  }

  location /localtest {
    root /var/www/localtest;
    index index.html;
  }
}

実績：

ローカルHTMLコンテンツHTTPの提供

ab -c200 -n20000 http://SERVERNAME/localtest/index.html
Requests per second:    12751.64 [#/sec] (mean)
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    4   2.3      4      11
Processing:     2   12   7.3      9      96
Waiting:        1   10   7.7      7      96
Total:          2   16   6.6     14     100

HTTPS：

Requests per second:    252.28 [#/sec] (mean)
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       12  651 288.1    694    1470
Processing:     0  141 134.4    101    1090
Waiting:        0  101 124.3     65    1089
Total:         15  792 276.7    809    1641

Apacheへのプロキシ、1ms ping、1ホップ離れています。

HTTP

Requests per second:    1584.88 [#/sec] (mean)
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   2.3      1       8
Processing:     4  141 309.6     30    1244
Waiting:        4  141 309.7     29    1244
Total:         10  143 310.3     31    1248

HTTPS

Requests per second:    215.99 [#/sec] (mean)
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       14 1131 622.3   1137    2030
Processing:     4  474 413.2    313    1814
Waiting:        1  399 405.6    257    1679
Total:         26 1605 769.6   1699    3306
nginxsslredhathttphttps
3
arecki

ベンチマークは嘘であり、現実を反映していませんが、ボトルネックを検出するための便利なツールである可能性があります。ただし、ベンチマークを理解する必要があります。ベンチマークの結果を理解するために必要な重要な詳細を省略していることを考えると、ベンチマークの結果に影響を与える可能性のあるものを実際には理解していない可能性があります。

特に、テストペイロードのサイズに関する情報と、サーバーとクライアントの詳細なCPU負荷情報が欠落しています。したがって、クライアントまたはサーバーですでにCPU制限に達している可能性があります。また、主に、リクエストに必要な往復の問題である可能性もあります。 HTTPとHTTPSの側面について詳しく説明しましょう。

ab -c200 -n20000 http：//SERVERNAME/localtest/index.html

200の同時リクエストを使用するように構成しました。リクエストのサイズは不明であるため、ペイロードは最小限であると想定できます。また、HTTPキープアライブを使用していないため、リクエストごとに新しいTCP接続があります。ApacheベンチがTLSセッション再開を行っているため、毎回完全なハンドシェイクが行われるとは思えません。それはあなたに与えます：

  • HTTP：TCPハンドシェイク用の1つのRTTと、最小限のHTTP要求および応答用の別のRTT。これには、すでに接続が閉じられている場合もあります（実装によって異なります）。これは、2つのRTTと最小限のデータ転送を意味します。

  • HTTPSはこれに加えて：

    • 完全なTLSハンドシェイクの場合は2RTT、TLSシャットダウンの場合はおそらく1RTT。 HTTPSの合計5RTTとプレーンHTTPの2RTTのおかげで、パフォーマンスが大幅に低下するはずです。つまり、約13000 req/sから5200req/s（つまり、2/5）になります。
    • TLSハンドシェイクだけで転送されるデータは、単純なHTTPのみのリクエスト内のペイロードとして持っているデータよりも大きい場合があります（編集：コメントに基づいて、応答のサイズは60バイトから50kbまで変化するため、これはおそらくそれほど関係ありません）。
    • ただし、クライアント側とサーバー側の両方で、TLSハンドシェイクの計算もたくさんあります。また、ECDHEを使用しているため、これについては、 https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/ を参照してください。

TLSハンドシェイク中の計算には多くのCPU時間が必要であるため、CPU負荷に関する情報を提供することが重要でした。サーバーまたはクライアントのいずれかで、CPUが実行できる最大値に到達しているだけの可能性があります。また、Apacheベンチはシングルスレッドであるため、他のCPUコアがアイドル状態であっても、単一のCPUコアのパフォーマンスを最大化するのに十分であることに注意してください。また、複数のスレッドを使用している場合でも、計算には時間がかかります。 openssl speedの使用は、TLSハンドシェイク内で実際に行われることを反映していません。また、複数の計算を並行して実行したり、すべてのキャッシュのトラッシングなどを行ったりすることなく、単一のスレッドで最大速度のみをテストします。

したがって、これは何が可能かを確認するための興味深いベンチマークかもしれませんが、ほとんどの場合、現実を反映していません。事実、TLSはパフォーマンスを大幅に低下させる可能性がありますが、一般的なHTTPトラフィックでは、リクエストが大きくなり、HTTPが存続し、TLSセッションが再利用されるため、コストのかかるTLSハンドシェイクの影響が軽減されます。

ただし、ベンチマークが実際にサーバーのパフォーマンスに制限されており、クライアントのパフォーマンスに制限されていない場合、セットアップは追跡に使用されるサーバーを反映​​している可能性があります。この場合、TLSセッションを一切行わずに、さまざまなサイトからの応答が小さい（1x1ピクセル）場合があります。再利用またはHTTPは存続します。

7
Steffen Ullrich

TLSネゴシエーションのため、最初のhttps要求は非常に遅く、ベンチマークはそれをテストするだけです。

実際のクライアントは多くのリクエストを行います（1つはhtmlページ用、いくつかはjs/css/images用）。

TLSセッションチケットでは、そのTLSネゴシエーションは最初の要求の後でスキップされます。

セッションチケットの有効期限が切れるまで、httpsリクエストはhttpよりも少し遅くなります。ただし、SPDYまたはHTTP2を使用している場合、httpsはそのhttpよりも高速になります。

0
Tom