Otimizando a terminação SSL HAProxy (com o backend Nginx no Ubuntu)

Question

Como posso otimizar os back-ends HAProxy com Terminação SSL para Nginx no Ubuntu?

A configuração funciona bem e é encaminhada corretamente. No entanto, quando eu executo Terminação SSL com HAProxy, há um grande impacto no desempenho (testes abaixo). A chave é rsa de 4096 bits. O HAProxy força o HTTPS para verificação, depois encerra o SSL e comunica o HTTP para servidores Nginx de backend. Servidores Nginx são idênticos e servem múltiplas páginas estáticas, por exemplo, 192.168.1.xx / page1.html, 192.168.1.xx / page2.html, etc. (incluímos o NodeJS para a integridade do meu sistema, mas apenas adiciona um atraso de < 1ms. NodeJS pode ser ignorado.)

Aqui estão as configurações, configurações e testes atuais. Cada máquina virtual (VM) está executando o Ubuntu 14.04 e pode ter uma quantidade variável de CPUs & RAM.

• HAProxy (1.5.14): 192.168.1.10
• Nginx-1: 192.168.1.20
• Nginx-2: 192.168.1.21
• Nginx-3: 192.168.1.22
• NodeJS-1: 192.168.1.30

Aqui está a configuração do HAProxy:

    global
            maxconn 40000
            tune.ssl.default-dh-param 2048
            log /dev/log    local0
            log /dev/log    local1 notice
            chroot /var/lib/haproxy
            stats socket /run/haproxy/admin.sock mode 660 level admin
            stats timeout 30s
            user haproxy
            group haproxy

            # Default SSL material locations
            ca-base /etc/ssl/certs
            crt-base /etc/ssl/private

            # Default ciphers to use on SSL-enabled listening sockets.
            # For more information, see ciphers(1SSL). This list is from:
            #  https://hynek.me/articles/harding-your-web-servers-ssl-ciphers/
            ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
            ssl-default-bind-options no-sslv3


    defaults
            option forwardfor
            option http-server-close
            stats enable
            stats uri /stats
            stats realm Haproxy\ Statistics
            stats auth user:password
            log     global
            mode    http
            option  httplog
            option  dontlognull
            timeout connect 5000
            timeout client 50000
            timeout server 50000
            errorfile 400 /etc/haproxy/errors/400.http
            errorfile 403 /etc/haproxy/errors/403.http
            errorfile 408 /etc/haproxy/errors/408.http
            errorfile 500 /etc/haproxy/errors/500.http
            errorfile 502 /etc/haproxy/errors/502.http
            errorfile 503 /etc/haproxy/errors/503.http
            errorfile 504 /etc/haproxy/errors/504.http


    frontend www-http
            bind 192.168.1.10:80
            reqadd X-Forwarded-Proto:\ http
            default_backend www-backend

    frontend www-https
            bind 192.168.1.10:443 ssl crt /etc/ssl/private/company.pem
            reqadd X-Forwarded-Proto:\ https
            use_backend node-backend if { path_beg /socket.io }
            default_backend www-backend

    backend www-backend
            redirect scheme https if !{ ssl_fc }
            server www-1 192.168.1.20:80 check
            server www-2 192.168.1.21:80 check
            server www-3 192.168.1.22:80 check

    backend node-backend
            server node-1 192.168.1.30:8888 check

Aqui está o teste ApacheBench (ab) para um dos servidores Nginx:

    $ ab -c 200 -n 10000 http://192.168.1.20/

    Server Software:        nginx/1.4.6
    Server Hostname:        192.168.1.20
    Server Port:            80

    Document Path:          /
    Document Length:        3130 bytes

    Concurrency Level:      200
    Time taken for tests:   2.257 seconds
    Complete requests:      10000
    Failed requests:        0
    Total transferred:      33720000 bytes
    HTML transferred:       31300000 bytes
    Requests per second:    4430.21 [#/sec] (mean)
    Time per request:       45.145 [ms] (mean)
    Time per request:       0.226 [ms] (mean, across all concurrent requests)
    Transfer rate:          14588.55 [Kbytes/sec] received

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        4   27 104.3     16    1187
    Processing:     4   18   8.2     16     358
    Waiting:        3   18   7.9     16     334
    Total:          9   45 105.8     32    1225

    Percentage of the requests served within a certain time (ms)
      50%     32
      66%     41
      75%     43
      80%     44
      90%     49
      95%     52
      98%     55
      99%     57
     100%   1225 (longest request)

Aqui está o teste ApacheBench (ab) para o HAProxy com http:

    $ ab -c 200 -n 10000 http://192.168.1.10/

    Server Software:        nginx/1.4.6
    Server Hostname:        192.168.1.10
    Server Port:            80

    Document Path:          /
    Document Length:        3130 bytes

    Concurrency Level:      200
    Time taken for tests:   1.918 seconds
    Complete requests:      10000
    Failed requests:        0
    Total transferred:      33720000 bytes
    HTML transferred:       31300000 bytes
    Requests per second:    5215.09 [#/sec] (mean)
    Time per request:       38.350 [ms] (mean)
    Time per request:       0.192 [ms] (mean, across all concurrent requests)
    Transfer rate:          17173.14 [Kbytes/sec] received

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        3   18   3.5     18      32
    Processing:     7   20   3.5     19      36
    Waiting:        7   20   3.4     19      36
    Total:         15   38   4.2     37      57

    Percentage of the requests served within a certain time (ms)
      50%     37
      66%     38
      75%     39
      80%     40
      90%     44
      95%     46
      98%     50
      99%     51
     100%     57 (longest request)

Aqui está o teste ApacheBench (ab) para o HAProxy com https:

    $ ab -c 200 -n 10000 https://192.168.1.10/

    Server Software:        nginx/1.4.6
    Server Hostname:        192.168.1.10
    Server Port:            443
    SSL/TLS Protocol:       TLSv1,DHE-RSA-AES256-SHA,2048,256

    Document Path:          /
    Document Length:        3130 bytes

    Concurrency Level:      200
    Time taken for tests:   566.303 seconds
    Complete requests:      10000
    Failed requests:        0
    Total transferred:      33720000 bytes
    HTML transferred:       31300000 bytes
    Requests per second:    17.66 [#/sec] (mean)
    Time per request:       11326.069 [ms] (mean)
    Time per request:       56.630 [ms] (mean, across all concurrent requests)
    Transfer rate:          58.15 [Kbytes/sec] received

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:      483 8982 3326.6  11090   14031
    Processing:    16 2255 3313.0     43   11399
    Waiting:       14 2186 3253.3     35   11252
    Total:       5648 11237 879.1  11212   22732

    Percentage of the requests served within a certain time (ms)
      50%  11212
      66%  11274
      75%  11308
      80%  11321
      90%  11395
      95%  11641
      98%  11847
      99%  14063
     100%  22732 (longest request)

Aqui está o teste do OpenSSL na VM HAProxy.

    $ openssl speed rsa

                      sign    verify    sign/s verify/s
    rsa  512 bits 0.000081s 0.000006s  12314.6 179042.8
    rsa 1024 bits 0.000277s 0.000017s   3603.7  60563.8
    rsa 2048 bits 0.001852s 0.000058s    539.8  17231.3
    rsa 4096 bits 0.013793s 0.000221s     72.5   4517.4

Portanto, a forma como estou a ver é que o HAProxy não pode superar o teste de velocidade openssl de 72,5 sinais / s, 4517,4 verificar / s. No entanto, o HAProxy com terminação SSL está executando cerca de 17 solicitações / s. É claro que podemos obter uma chave menor para melhorar o desempenho geral, mas isso não resolve o problema (se houver um problema) do aumento da velocidade de ~ 4,5x do teste de velocidade do openssl para o HAProxy.

Então, dada esta informação, existe uma configuração HAProxy ideal que irá aumentar o desempenho? Estou sentindo falta de algo em geral, por exemplo: quando um usuário visita uma página pela primeira vez, ela só precisa "assinar" uma vez e todas as solicitações simultâneas para a página são apenas "verificar". Se esse é o caso, então o teste AB não está medindo adequadamente isso (me corrija se eu estiver errado). E, para que isso ocorra, o usuário tem que visitar o mesmo servidor Nginx? Em caso afirmativo, isso requer sessões em bastão?

Em tentativas de responder a minhas próprias perguntas, tentei adicionar sessões em destaque nesta postagem: HAProxy com SSL e sessões adesivas e usei o Siege para testar com vários URLs. No entanto, ainda não houve um aumento no desempenho.

    $ siege -c 100 -r 10 -b -f urls.txt

    Transactions:               1000 hits
    Availability:             100.00 %
    Elapsed time:              22.56 secs
    Data transferred:           2.84 MB
    Response time:              2.17 secs
    Transaction rate:          44.33 trans/sec
    Throughput:             0.13 MB/sec
    Concurrency:               96.06
    Successful transactions:        1000
    Failed transactions:               0
    Longest transaction:            8.96
    Shortest transaction:           0.16

Onde urls.txt é

    URL=https://192.168.1.10/
    $(URL)
    $(URL)page1.html
    $(URL)page2.html

Então, estou preso a esse desempenho? Alguns locais mencionam uma taxa de solicitação similar de ~ 75 ms / solicitação para chaves de 4096 bits. link

Ou, o meu HAProxy está mal configurado e está processando o SSL 2x em algum lugar? ServerFault: / questions / 574582 / nginx-ssl-encerramento-lento

    

Answer 1

Uma coisa a considerar é que muitos clientes HTTP (incluindo navegadores) tentam amortizar o custo do handshake SSL em várias solicitações HTTP. Ou seja, eles fazem uma conexão TCP com o servidor, executam o handshake SSL e reutilizam essa conexão TCP (com sua sessão SSL) para várias solicitações / respostas, em vez de executar um handshake SSL por solicitação.

Para habilitar esse tipo de cenário / teste em sua configuração, você pode incluir a opção de linha de comando -k para ab , para suas solicitações HTTP frontend .

Outra consideração é o uso da configuração option http-server-close HAproxy. Isso diz a haproxy para fazer uma nova conexão TCP de backend, por solicitação HTTP de frontend; isso pode adicionar seus próprios 40-100ms (se não mais), dependendo da rede backend. Se você permitiu que o HAproxy mantenha essas conexões TCP de backend abertas, isso também pode reduzir a latência por solicitação relatada por ab .

Dependendo do número de sessões SSL que você prevê, também é possível aumentar a alocação de memória para o armazenamento em cache da sessão SSL (configuração tune.ssl.cachesize do HAproxy, talvez em conjunto com tune.ssl.lifetime para aumentar o tempo limite do cache e aumentar a probabilidade de reutilização do cache de sessão) permitiria sessões SSL mais resumidas (e handshakes SSL mais rápidos / menos computacionalmente intensivos).

Mas eu acho que os números relatados por ab , ao usar keep-alive ( -k ), demonstrarão melhor a eficácia da reutilização da mesma sessão SSL (via mesma conexão TCP) para muitas solicitações HTTP.

Espero que isso ajude!

    

Answer 2

Compare maçãs com maçãs.

Seu% de referência openssl speed rsa provavelmente não mede o tempo de DHE, porque ele não usa chaves efêmeras. Isso significa que você testa um algoritmo menos seguro em comparação com um algoritmo DHE. O último é mais lento, por outro lado, fornece sigilo perfeito para a frente (PFS).

Mas o DHE é um navegador bastante antigo, ineficaz e moderno, geralmente usa um ECDHE melhor (ou até ECDSA).

Acho que você deve configurar o seu benchmark ab para impor o ECDHE-RSA-AES128-SHA256. Eu acho que você deve programar seu benchmark openssl para usar um loop de openssl s_client -cipher ECDHE-RSA-AES128-SHA256 (em vez de openssl speed simplista).