Linux：由於客戶端 hello 延遲導致 SSL 握手緩慢

在調查影響同時受到影響的代理集群的問題時，我發現在建立 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. Wireshark 會不會騙我？
3. 我可以查看哪些其他性能指標/統計資訊/命令來進一步解決延遲的原因？
4. 是否有任何網路因素（MTU、接收緩衝區、碎片）可以證明這種行為是合理的？
5. 我如何找到證據來澄清這是否是我的伺服器外部的網路問題？

軟體版本：

• 紅帽企業 Linux 伺服器版本 5.11 (Tikanga)
• OpenSSL 0.9.8e-fips-rhel5 2008 年 7 月 1 日
• 核心 2.6.18-416.el5 #1 SMP 10 月 26 日星期三 12:04:18 EDT 2016 x86_64 x86_64 x86_64 GNU/Linux

編輯：strace資訊

按照以下答案的建議做了一些 straces，擷取了這些緩慢的呼叫：

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()同一跟踪中的其他此類呼叫很快。

您可以嘗試使用 strace 執行 curl 命令，以查看它們“掛起”的系統呼叫。我發現這些事情有時與 DNS 查找（或反向 DNS 查找）有關

strace curl https://[...]

引用自：https://serverfault.com/questions/840427