performance - SSL SNI 检查期间的 haproxy 队列时间 (qtime)

Question

我们使用 haproxy 1.5.14 作为 HTTP 的负载平衡器以及多个域主机名的 HTTPS 端点。对于 HTTPS 端点，我们使用 SSL NI header 检查来找出正确的后端节点。

在我当前存在多个 https 端点的安装中，我注意到后端 qtime stat vaue 非常高 (200-300ms)，这让我很不安。 qcur(当前队列长度)同时为零。我们是否基本上在 haproxy 端将所有请求减慢了 200ms-300ms？ (不确定我是否正确理解了 qtime 的这个值)如果是 - 我肯定正在寻找优化它的方法。

此行为仅在 HTTPS 后端而非 HTTP 后端观察到。我想知道这是否是用于确定正确后端节点的前端 SNI header 检查的结果。在 SSL SNI 检查期间，请求会留在队列中吗？

我们当前的配置(仅适用于 HTTPS 端点):

global
      log         127.0.0.1 local2
      chroot      /var/lib/haproxy
      pidfile     /var/run/haproxy.pid
      maxconn     40000
      ulimit-n    100000
      user        haproxy
      group       haproxy
      daemon
      stats socket /var/lib/haproxy/stats

defaults
      mode                    http
      log                     global
      option                  httplog
      option                  dontlognull
      option http-server-close
      retries                 3
      timeout http-request    1s
      timeout queue           1m
      timeout connect         3s
      timeout client          1m
      timeout server          30s
      timeout http-keep-alive 2s
      timeout check           3s
      maxconn                 40000

frontend https-in *:443
    mode tcp
            option tcplog
            option socket-stats

            tcp-request inspect-delay 5s
            tcp-request content accept if { req_ssl_hello_type 1 }

            use_backend foo-ssl if { req_ssl_sni -m beg foo }
            use_backend bar-ssl if { req_ssl_sni -m beg bar }

backend foo-ssl *:443
    balance leastconn
    mode tcp
            option ssl-hello-chk

            server foo1 x.x.x.x:443 maxconn 10000 check
            server foo2 x.x.x.x:443 maxconn 10000 check

backend bar-ssl *:443
    balance leastconn
    mode tcp
            option ssl-hello-chk

            server bar1 x.x.x.x:443 maxconn 10000 check
            server bar2 x.x.x.x:443 maxconn 10000 check

Answer 1

这不应该发生，或者这意味着您的客户端需要很长时间才能使用 SNI 发送 SSL hello，这也不是预期的。您应该进行网络捕获 (tcpdump)，并在 haproxy 进程上运行 strace -tt 以了解时间丢失的位置。