问Linux:由于客户端hello延迟，SSL握手速度慢

EN

在研究一个同时受影响的代理集群的问题时，我发现了在建立SSL连接时的奇怪行为。

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

该问题似乎是由TCP 3路握手结束和代理发送Client Hello之间的延迟引起的。在此之后，握手正常完成，没有延迟。

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

到api.twitter.com (2.4秒延迟)：

到graph.facebook.com (延迟28.4秒)：

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

一些事实/考虑：

• 这个问题暂时发生在一天中的特定时间(大约1000小时和1700小时)，影响到所有的宿主，并在30分钟左右消失。稍后，同时
• 这可能是外部原因(可能是网络)，但是tcpdump输出似乎将责任归咎于本地服务器。
• CPU、负载、内存和所有其他受监视的性能指标当时都是正常的。
• 它影响所有SSL远程主机。
• 影响连接的随机，有些行为正常，但许多是极其缓慢。
• 吞吐量(握手后)似乎不受影响。
• 一旦问题发生，到同一远程主机的SSL连接将始终保持快速。
• 使用curl和openssl s_client connect进行了测试，结果相同。

什么需要澄清：

1. 是什么造成了当地的这种拖延呢？
2. 会不会是在愚弄我？
3. 我还能研究哪些其他性能指标/统计数据/命令来进一步排除延迟的原因？
4. 是否有任何网络因素(MTU、接收缓冲区、碎片)可以证明这种行为是正当的？
5. 我怎样才能找到证据来澄清这是否是我的服务器之外的网络问题？

软件版本

• 红帽企业Linux服务器第5.11版(Tikanga)
• OpenSSL 0.9.8e-fips-rhel501 2008年7月1日
• 内核2.6.18-416.el5 #1 SMP 10月26日12:04:18 x86_64 2016

编辑: strace information

下面的答案推荐了几个房间，听到了这些缓慢的声音：

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()调用是快速的。