Question

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

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

此行为仅在HTTPS后端上观察，而不在HTTP后端上观察到。我想知道这是否是前端SNI标头检查的结果，用于确定正确的后端节点。在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问候语，这也不是很理想。您应该进行网络捕获（tcpdump），并在haproxy进程上运行strace -tt以了解时间丢失的位置。

SSL SNI期间的haproxy队列时间（qtime）

1 个答案: