☰

Linux：由于客户端问候延迟导致 SSL 握手缓慢

tag-icon • tag-icon ssl performance linux-networking openssl
Linux：由于客户端问候延迟导致 SSL 握手缓慢

在调查同时受到影响的代理集群的问题时，我发现在建立 SSL 连接时存在奇怪的行为。

症状是，当影响发生时，传出的 HTTPS 请求比平时慢，我将其归结为完成 SSL 握手的速度缓慢。HTTP 请求/连接不会受到同样的影响。

该问题似乎是由于 TCP 三次握手结束与Client Hello代理发送之间的延迟导致的。此后，握手正常完成，没有延迟。

以下是一些流量捕获的示例：

至api.twitter.com（延迟 2.4 秒）： api.twitter.com

至graph.facebook.com（延迟 28.4 秒）： graph.facebook.com

即使在第二个例子中进行了重新传输，Client Hello数据包也不应该花那么长时间才能发出。

一些事实/考虑：

  • 该问题会在一天中的特定时间（大约 10:00 和 17:00）暂时发生，影响所有主机，并在约 30 分钟后同时消失
  • 这表明存在外部原因（可能是网络），但 tcpdump 输出似乎将责任归咎于本地服务器
  • 此时CPU、负载、内存等所有监控的性能指标均正常
  • 它会影响所有 SSL 远程主机
  • 随机影响连接，有些连接正常，但很多连接速度极慢
  • 握手后吞吐量似乎没有受到影响
  • 一旦问题解决，到相同远程主机的 SSL 连接就会一直保持快速
  • curl和进行了测试openssl s_client connect，结果相同

需要澄清的是：

  1. 什么原因造成当地出现这样的延误？
  2. wireshark 会欺骗我吗？
  3. 我可以研究哪些其他性能指标/统计数据/命令来进一步排除延迟的原因？
  4. 是否存在任何网络因素（MTU，接收缓冲区，碎片）可以解释这种行为？
  5. 我如何找到证据来明确这是否是服务器外部的网络问题？

软件版本：

  • Red Hat Enterprise Linux 服务器版本 5.11 (Tikanga)
  • OpenSSL 0.9.8e-fips-rhel5 2008 年 7 月 1 日
  • 内核 2.6.18-416.el5 #1 SMP 2016 年 10 月 26 日星期三 12:04:18 EDT x86_64 x86_64 x86_64 GNU/Linux

编辑：strace 信息

按照下面的答案的建议做了一些 strace，捕获了这些缓慢的调用：

strace -T -o output.strace openssl s_client -connect 104.244.42.66:443 </dev/null

connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.244.42.66")}, 16) = 0 <2.266597>
poll([{fd=4, events=POLLIN}], 1, 5000)  = 1 ([{fd=4, revents=POLLIN}]) <2.387366>
write(3, "\26\3\1\0S\1\0\0O\3\1X\342\24\3556c\354\270T\302\225[\236\317\327\305\205r\177\t/"..., 88) = 88 <0.000034>
read(3, "\26\3\1\0001\2\0", 7)          = 7 <2.556229>
read(3, "\0-\3\1\332\37\254+\240\320\236qA\375\275L\23l\340\355\205x\264\274\273\213\377\323&\345\307O"..., 47) = 47 <0.000011>
read(3, "\26\3\1\v\273", 5)             = 5 <0.000007>
(...)
read(3, "\24\3\1\0\1", 5)               = 5 <2.223115>

该poll()调用是一次反向 DNS 查找，它正在执行以下操作：

sendto(4, "\3623\1\0\0\1\0\0\0\0\0\0\00266\00242\003244\003104\7in-ad"..., 44, MSG_NOSIGNAL, NULL, 0) = 44 <0.000157>

同一跟踪中的其他此类poll()调用很快。

答案1

您可以尝试使用 strace 运行 curl 命令，看看它们在哪个系统调用上“挂起”。我发现这些事情有时与 DNS 查找（或反向 DNS 查找）有关

strace curl https://[...]

相关内容