fragen stichworte

RHEL Nginx SSL im Vergleich zu Nicht-SSL-Leistung großer Unterschied.

Ich bin dabei, einen Nginx 1.8-Reverse-Proxy einzurichten.

In Kürze -

Bereitstellen von HTML-Inhalten Der HTTP-Verkehr ist bis zu 50-mal schneller als HTTPS.

Der ProxyPass-HTTP-Verkehr ist bis zu 7x schneller als HTTPS.

Betriebssystem ist RHEL7

Hardware:

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

Benchmarking-Client ist Apache-Bank, 1 Sprung entfernt, Ping 1ms. Die Apache-Bank verwendet bei der Ausführung das folgende TLS-Protokoll:

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

Server-SSL-Zertifikat 2048-Bit-RSA. OCSP-Heftung ist aktiviert und überprüft.

/etc/sysctl.conf hat

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 hat

nginx   soft    nofile  65536
nginx   hard    nofile  65536

Nginx ist mit

konfiguriert
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;
  }
}

Tatsächliche Ergebnisse:

Bereitstellung von lokalem HTML-Inhalt 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

Proxying to Apache, 1ms Ping, 1 Hop entfernt.

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

antworten

Benchmarks sind Lügen, sie spiegeln nicht die Realität wider, sind aber möglicherweise ein nützliches Instrument, um Engpässe zu erkennen. Aber man muss die Benchmarks verstehen. Da Sie wesentliche Details auslassen, die zum Verständnis der Benchmark-Ergebnisse erforderlich sind, kann es sein, dass Sie nicht wirklich verstehen, was die Benchmark-Ergebnisse beeinflussen könnte.

Es fehlen insbesondere Informationen zur Größe der Testnutzlast und detaillierte Informationen zur CPU-Auslastung für Server und Client. Es kann also sein, dass Sie auf dem Client oder auf dem Server bereits CPU-Limits erreichen. Es könnte auch hauptsächlich ein Problem der mehr Rundreisen sein, die Sie für die Anfragen benötigen. Lassen Sie uns die Aspekte von HTTP im Vergleich zu HTTPS genauer erklären:

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

Sie haben die Verwendung von 200 gleichzeitigen Anforderungen konfiguriert. Die Größe der Anfrage ist unbekannt, so dass wir davon ausgehen können, dass es nur eine minimale Nutzlast gibt. Sie verwenden auch kein HTTP-Keep-Alive, was bedeutet, dass für jede Anforderung eine neue TCP-Verbindung hergestellt wird. Ich bezweifle, dass Apache Bench einen TLS-Session-Resume durchführt, so dass jedes Mal ein vollständiger Handshake stattfindet. Was gibt Ihnen:

  • HTTP: 1 RTT für den TCP-Handshake und ein weiterer RTT für eine minimale HTTP-Anforderung und Antwort. Dies kann auch das Schließen der Verbindung beinhalten (implementierungsabhängig). Dies bedeutet 2 RTT und minimale Datenübertragung.
  • HTTPS fügt hinzu:

    • 2 RTT für einen vollständigen TLS-Handshake und wahrscheinlich auch 1 RTT für das TLS-Herunterfahren. Nur wegen einer Gesamtmenge von 5 RTT für HTTPS gegenüber 2 RTT für einfaches HTTP sollten Sie einen erheblichen Leistungsabfall feststellen, d. H. Von etwa 13000 req/s auf 5200 req/s (d. H. 2/5).
    • Die übertragenen Daten für den TLS-Handshake allein können sogar größer sein als die, die Sie als Nutzlast in Ihrer einfachen HTTP-Anforderung haben. (Bearbeiten: Je nach Antwort variiert die Größe Ihrer Antworten zwischen 60 Byte und 50 KB, sodass dies wahrscheinlich nicht der Fall ist relevant).
    • Es gibt jedoch auch viele Berechnungen für den TLS-Handshake, sowohl auf Client- als auch auf Serverseite. Und weil Sie ECDHE verwenden, erfahren Sie mehr unter https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/.

Die Berechnungen während des TLS-Handshakes erfordern viel CPU-Zeit. Deshalb wäre es wichtig gewesen, Informationen über die CPU-Last bereitzustellen. Es kann sein, dass Sie das Maximum der CPU erreichen, entweder auf dem Server oder auf dem Client. Bitte beachten Sie auch, dass die Apache-Bank Single-Threading ist. Daher reicht es aus, die Leistung eines einzelnen CPU-Kerns zu maximieren, selbst wenn die anderen nicht verwendet werden. Und selbst wenn Sie mehrere Threads verwenden, dauert die Berechnung immer noch Zeit. Die Verwendung von openssl speed spiegelt nicht wider, was wirklich innerhalb des TLS-Handshakes gemacht wird. Außerdem wird nur die maximale Geschwindigkeit mit einem einzelnen Thread getestet, nicht mit mehreren parallelen Berechnungen und sämtlichem damit verbundenem Cache-Trash.

Obwohl dies ein interessanter Maßstab für das Mögliche ist, spiegelt es in den meisten Fällen die Realität nicht wider. Tatsache ist, dass TLS die Leistung erheblich reduzieren kann, aber mit dem üblichen HTTP-Verkehr werden Sie größere Anforderungen haben, HTTP bleibt am Leben und die Wiederverwendung von TLS-Sitzungen kann die Auswirkungen des kostspieligen TLS-Handshakes reduzieren.

Wenn der Benchmark jedoch in Bezug auf die Serverleistung und nicht auf die Clientleistung begrenzt ist, spiegelt das Setup möglicherweise Server wider, die für das Tracking verwendet werden, wobei Sie möglicherweise nur eine kleine Antwort (z. B. 1x1 Pixel) von vielen verschiedenen Standorten ohne jegliche Art haben der Wiederverwendung von TLS-Sitzungen oder HTTP bleibt erhalten.

Die FIRST-HTTPS-Anfrage ist aufgrund der TLS-Verhandlung wirklich langsamer und Ihr Benchmark testet das nur.

Ein Real-Life-Client wird eine Menge Anfragen stellen (eine für die HTML-Seite und mehrere für js/css/images).

Bei TLS-Sitzungstickets wird diese TLS-Verhandlung nach der ersten Anfrage übersprungen.

Bis zum Ablauf des Sitzungstickets werden HTTPS-Anfragen nur ein wenig langsamer als http sein. Aber wenn Sie SPDY oder HTTP2 verwenden, dann wird https wenn SCHNELLER sein, dass http.