Назад | Перейти на главную страницу

RHEL Nginx SSL по сравнению с производительностью без SSL - огромная разница.

Я настраиваю обратный прокси-сервер Nginx 1.8.

Коротко -

Обслуживание HTML-содержимого. HTTP-трафик до 50 раз быстрее, чем HTTPS.

HTTP-трафик ProxyPass обслуживается до 7 раз быстрее, чем HTTPS.

ОС - 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

Клиент для тестирования - это тест Apache, на расстоянии 1 прыжок, ping 1 мс. При работе на стенде Apache используется следующий протокол TLS:

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

SSL-сертификат сервера 2048-битный RSA. OCSP Stapling включен и проверен.

/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, пинг 1 мс, 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

Тесты - это ложь, они не отражают реальности, но могут быть полезным инструментом для обнаружения узких мест. Но вы должны понимать тесты. Учитывая, что вы опускаете важные детали, необходимые для понимания результатов теста, возможно, вы действительно не понимаете, что может повлиять на результаты теста.

В частности, отсутствует информация о размере тестовой полезной нагрузки и подробная информация о загрузке процессора для сервера и клиента. Таким образом, возможно, вы уже достигли пределов ЦП на клиенте или на сервере. Это также может быть в основном проблемой, связанной с тем, что вам нужно больше запросов и обратно. Давайте объясним аспекты HTTP и HTTPS более подробно:

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

Вы настроили использование 200 одновременных запросов. Размер запроса неизвестен, поэтому мы можем предположить, что будет только минимальная полезная нагрузка. Вы также не используете HTTP keep alive, что означает, что для каждого запроса будет новое TCP-соединение. Я сомневаюсь, что скамья apache возобновляет сеанс TLS, чтобы каждый раз было полное рукопожатие. Что дает вам:

  • HTTP: 1 RTT для установления связи TCP и еще один RTT для минимального HTTP-запроса и ответа. Это также может включать уже закрытое соединение (зависит от реализации). Это означает 2 RTT и минимальную передачу данных.

  • HTTPS добавляет к этому:

    • 2 RTT для полного подтверждения TLS и, возможно, также 1 RTT для завершения TLS. Просто из-за того, что всего 5 RTT для HTTPS против 2 RTT для обычного HTTP, вы должны увидеть большое падение производительности, то есть примерно с 13000 запросов в секунду до 5200 запросов в секунду (т. Е. 2/5).
    • Переданные данные только для рукопожатия TLS могут даже быть больше, чем у вас есть в качестве полезной нагрузки в вашем простом HTTP-запросе (изменить: в зависимости от одобрения размер ваших ответов варьируется от 60 байт до 50 КБ, поэтому это, вероятно, не так актуально).
    • Но тогда у вас также есть много вычислений для рукопожатия TLS, как на стороне клиента, так и на стороне сервера. И еще об этом, потому что вы используете ECDHE, см. https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/.

Вычисления во время установления связи TLS требуют много процессорного времени, поэтому было бы важно предоставить информацию о загрузке процессора. Может случиться так, что вы просто используете максимум, на который способен ЦП, либо на сервере, либо на клиенте. Также обратите внимание, что тест apache является однопоточным, поэтому его будет достаточно, чтобы максимально увеличить производительность одного ядра процессора, даже если остальные не работают. И даже если вы используете несколько потоков, вычисления все равно требуют времени. С помощью openssl speed не отражает того, что на самом деле делается внутри рукопожатия TLS, а также проверяет только максимальную скорость с одним потоком, а не с несколькими параллельными вычислениями и всем задействованным удалением кеша и т. д.

Таким образом, хотя это может быть интересный тест, чтобы увидеть, что возможно, в большинстве случаев он не отражает реальности. Дело в том, что TLS может значительно снизить производительность, но с обычным HTTP-трафиком у вас будут большие запросы, HTTP-сохранение активности и повторное использование сеанса TLS, которые уменьшают влияние дорогостоящего рукопожатия TLS.

Но если тест на самом деле ограничен производительностью сервера, а не производительностью клиента, настройка может отражать серверы, используемые для отслеживания, где у вас может быть только небольшой ответ (например, 1x1 пиксель) от множества разных сайтов без какого-либо сеанса TLS. повторное использование или поддержка HTTP.

Запрос FIRST https действительно медленнее из-за согласования TLS, и ваш тест тестирует только это.

Реальный клиент будет делать много запросов (один для html-страницы и несколько для js / css / images).

С билетами сеанса TLS это согласование TLS пропускается после первого запроса.

До истечения срока действия билета на сеанс запросы https будут немного медленнее, чем запросы http. Но если вы используете SPDY или HTTP2, то https, если будет БЫСТРЕЕ, чем http.