RHEL Nginx SSL与非SSL性能差异巨大。

我正在build立一个Nginx 1.8反向代理。

简而言之 –

提供HTML内容HTTPstream量比HTTPS快达50倍。

提供ProxyPass HTTPstream量比HTTPS快7倍。

操作系统是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

基准testing客户端是Apache板凳，1跳，ping 1ms。 Apache平台在运行时使用以下TLS协议：

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

服务器SSL证书2048位RSA。 OCSP装订已打开并经过validation。

/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

Nginxconfiguration有

 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

基准是谎言，不反映现实，但可能是检测瓶颈的有用工具。但是你必须了解基准。鉴于您忽略了理解基准testing结果所需的基本细节，您可能并不真正了解可能会影响基准testing结果的因素。

特别是有关testing负载的大小和服务器和客户端详细的CPU负载信息的信息都丢失了。因此，您可能已经达到客户端或服务器上的CPU限制。这也可能主要是您需要更多的往返旅程的问题。我们来更详细地解释HTTP和HTTPS的各个方面：

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

您已configuration使用200个并发请求。请求的大小是未知的，所以我们可以假设只有最小的有效载荷。你也没有使用HTTP保持活着，这意味着每个请求都会有一个新的TCP连接。我怀疑，阿帕奇板凳正在做TLS会话恢复，以便每次都会有一个完整的握手。哪个给你：

用于TCP握手的HTTP：1 RTT和用于最小HTTP请求和响应的另一个RTT。这可能还包括已closures的连接（取决于实现）。这意味着2 RTT和最小的数据传输。
HTTPS在此之上增加：
- 2 RTT为完整的TLS握手，可能还有1 RTT的TLS关机。仅仅因为HTTPS总数为5 RTT，普通HTTP总数为2 RTT，你应该看到性能大幅下降，即从13000 req / s到5200 req / 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内核的性能。即使你使用multithreading计算仍然需要时间。使用openssl speed并不能反映TLS握手内部真正完成的内容，它也只用一个线程来testing最大速度，而不是多个并行计算和所有caching垃圾等。

因此，虽然这可能是一个有趣的基准，看看有什么可能的，但在大多数情况下并不能反映现实。事实上，TLS可以大大降低性能，但是对于普通的HTTPstream量，您将拥有更大的请求，HTTP保持活跃状态并且TLS会话重用，这些都可以减less昂贵的TLS握手的影响。

但是，如果基准实际上限于服务器性能，而不是客户端性能，则该设置可能反映了用于跟踪的服务器，在这些服务器上，可能只有来自许多不同站点的小响应（即1×1像素），而没有任何types的TLS会话重用或HTTP保持活着。

由于TLS协商，FIRST https请求确实比较慢，而且您的基准testing只能testing该请求。

一个真实的客户端会提出很多请求（一个是html页面，一个是js / css / images）。

使用TLS会话票据，该TLS协商在第一个请求之后被跳过。

在会话票证到期之前，https请求将只是一个慢一点的http。但是，如果你使用SPDY或HTTP2，那么HTTPS会更快。