本文作者張彥飛，原題“聊聊TCP連線耗時的那些事兒”，有少許改動。
1、引言
對於基於網際網路的通訊應用（比如IM聊天、推送系統），資料傳遞時使用TCP協議相對較多。這是因為在TCP/IP協議簇的傳輸層協議中，TCP協議具備可靠的連線、錯誤重傳、擁塞控制等優點，所以目前在應用場景上比UDP更廣泛一些。
相信你也一定聽聞過TCP也存在一些缺點，能常都是老生常談的開銷要略大。但是各路技術部落格裡都在單單說開銷大、或者開銷小，而少見不給出具體的量化分析。不客氣的講，類似論述都是沒什麼營養的廢話。
經過日常工作的思考之後，我更想弄明白的是，TCP的開銷到底有多大，能否進行量化。一條TCP連線的建立需要耗時延遲多少，是多少毫秒，還是多少微秒？能不能有一個哪怕是粗略的量化估計？當然影響TCP耗時的因素有很多，比如網路丟包等等。我今天只分享我在工作實踐中遇到的比較高發的各種情況。
寫在前面：得益於Linux核心的開源，本文中所提及的底層以及具體的核心級程式碼例子，都是以Linux系統為例。
學習交流：
- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架原始碼：https://github.com/JackJiang2...（備用地址點此）
（本文已同步釋出於：http://www.52im.net/thread-32...）
2、系列文章
本文是系列文章中的第11篇，本系列文章的大綱如下：
《不為人知的網路程式設計(一)：淺析TCP協議中的疑難雜症(上篇)》
《不為人知的網路程式設計(二)：淺析TCP協議中的疑難雜症(下篇)》
《不為人知的網路程式設計(三)：關閉TCP連線時為什麼會TIME_WAIT、CLOSE_WAIT》
《不為人知的網路程式設計(四)：深入研究分析TCP的異常關閉》
《不為人知的網路程式設計(五)：UDP的連線性和負載均衡》
《不為人知的網路程式設計(六)：深入地理解UDP協議並用好它》
《不為人知的網路程式設計(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網路程式設計(八)：從資料傳輸層深度解密HTTP》
《不為人知的網路程式設計(九)：理論聯絡實際，全方位深入理解DNS》
《不為人知的網路程式設計(十)：深入作業系統，從核心理解網路包的接收過程(Linux篇)》
《不為人知的網路程式設計(十一)：從底層入手，深度分析TCP連線耗時的祕密》（本文）
《不為人知的網路程式設計(十二)：徹底搞懂TCP協議層的KeepAlive保活機制》
《不為人知的網路程式設計(十三)：深入作業系統，徹底搞懂127.0.0.1本機網路通訊》
《不為人知的網路程式設計(十四)：拔掉網線再插上，TCP連線還在嗎？一文即懂！》
3、理想情況下的TCP連線耗時分析
要想搞清楚TCP連線的耗時，我們需要詳細瞭解連線的建立過程。
在前文《深入作業系統，從核心理解網路包的接收過程(Linux篇)》中我們介紹了資料包在接收端是怎麼被接收的：資料包從傳送方出來，經過網路到達接收方的網路卡；在接收方網路卡將資料包DMA到RingBuffer後，核心經過硬中斷、軟中斷等機制來處理（如果傳送的是使用者資料的話，最後會傳送到socket的接收佇列中，並喚醒使用者程式）。
在軟中斷中，當一個包被核心從RingBuffer中摘下來的時候，在核心中是用struct sk_buff結構體來表示的（參見核心程式碼include/linux/skbuff.h）。其中的data成員是接收到的資料，在協議棧逐層被處理的時候，通過修改指標指向data的不同位置，來找到每一層協議關心的資料。
對於TCP協議包來說，它的Header中有一個重要的欄位-flags。
如下圖：
通過設定不同的標記位，將TCP包分成SYNC、FIN、ACK、RST等型別：
1）客戶端通過connect系統呼叫命令核心發出SYNC、ACK等包來實現和伺服器TCP連線的建立；
2）在伺服器端，可能會接收許許多多的連線請求，核心還需要藉助一些輔助資料結構-半連線佇列和全連線佇列。
我們來看一下整個連線過程：
在這個連線過程中，我們來簡單分析一下每一步的耗時：
1）客戶端發出SYNC包：客戶端一般是通過connect系統呼叫來發出SYN的，這裡牽涉到本機的系統呼叫和軟中斷的CPU耗時開銷；
2）SYN傳到伺服器：SYN從客戶端網路卡被髮出，開始“跨過山和大海，也穿過人山人海......”，這是一次長途遠距離的網路傳輸；
3）伺服器處理SYN包：核心通過軟中斷來收包，然後放到半連線佇列中，然後再發出SYN/ACK響應。又是CPU耗時開銷；
4）SYC/ACK傳到客戶端：SYC/ACK從伺服器端被髮出後，同樣跨過很多山、可能很多大海來到客戶端。又一次長途網路跋涉；
5）客戶端處理SYN/ACK：客戶端核心收包並處理SYN後，經過幾us的CPU處理，接著發出ACK。同樣是軟中斷處理開銷；
6）ACK傳到伺服器：和SYN包，一樣，再經過幾乎同樣遠的路，傳輸一遍。 又一次長途網路跋涉；
7）服務端收到ACK：伺服器端核心收到並處理ACK，然後把對應的連線從半連線佇列中取出來，然後放到全連線佇列中。一次軟中斷CPU開銷；
8）伺服器端使用者程式喚醒：正在被accpet系統呼叫阻塞的使用者程式被喚醒，然後從全連線佇列中取出來已經建立好的連線。一次上下文切換的CPU開銷。
以上幾步操作，可以簡單劃分為兩類：
第一類：是核心消耗CPU進行接收、傳送或者是處理，包括系統呼叫、軟中斷和上下文切換。它們的耗時基本都是幾個us左右；
第二類：是網路傳輸，當包被從一臺機器上發出以後，中間要經過各式各樣的網線、各種交換機路由器。所以網路傳輸的耗時相比本機的CPU處理，就要高的多了。根據網路遠近一般在幾ms~到幾百ms不等。
1ms就等於1000us，因此網路傳輸耗時比雙端的CPU開銷要高1000倍左右，甚至更高可能還到100000倍。
所以：在正常的TCP連線的建立過程中，一般考慮網路延時即可。
PS：一個RTT指的是包從一臺伺服器到另外一臺伺服器的一個來回的延遲時間。
所以從全域性來看：TCP連線建立的網路耗時大約需要三次傳輸，再加上少許的雙方CPU開銷，總共大約比1.5倍RTT大一點點。
不過，從客戶端視角來看：只要ACK包發出了，核心就認為連線是建立成功了。所以如果在客戶端打點統計TCP連線建立耗時的話，只需要兩次傳輸耗時-既1個RTT多一點的時間。（對於伺服器端視角來看同理，從SYN包收到開始算，到收到ACK，中間也是一次RTT耗時）。
4、極端情況下的TCP連線耗時分析
上一節可以看到：在客戶端視角，正常情況下一次TCP連線總的耗時也就就大約是一次網路RTT的耗時。如果所有的事情都這麼簡單，我想我的這次分享也就沒有必要了。事情不一定總是這麼美好，意外的發生在所難免。
在某些情況下，可能會導致TCP連線時的網路傳輸耗時上漲、CPU處理開銷增加、甚至是連線失敗。本節將就我線上上遇到過的各種切身體會的溝溝坎坎，來分析一下極端情況下的TCP連線耗時情況。
4.1 客戶端connect呼叫耗時失控案例
正常一個系統呼叫的耗時也就是幾個us（微秒）左右。但是在我的《追蹤將伺服器CPU耗光的凶手!》一文中，筆者的一臺伺服器當時遇到一個狀況：某次運維同學轉達過來說該服務CPU不夠用了，需要擴容。
當時的伺服器監控如下圖：
該服務之前一直每秒抗2000左右的qps，CPU的idel一直有70%+，怎麼突然就CPU一下就不夠用了呢。
而且更奇怪的是CPU被打到谷底的那一段時間，負載卻並不高（伺服器為4核機器，負載3-4是比較正常的）。
後來經過排查以後發現當TCP客戶端TIME_WAIT有30000左右，導致可用埠不是特別充足的時候，connect系統呼叫的CPU開銷直接上漲了100多倍，每次耗時達到了2500us（微秒），達到了毫秒級別。
當遇到這種問題的時候，雖然TCP連線建立耗時只增加了2ms左右，整體TCP連線耗時看起來還可接受。但這裡的問題在於這2ms多都是在消耗CPU的週期，所以問題不小。
解決起來也非常簡單，辦法很多：修改核心引數net.ipv4.ip_local_port_range多預留一些埠號、改用長連線都可以。
4.2 TCP半/全連線佇列滿的案例
如果連線建立的過程中，任意一個佇列滿了，那麼客戶端傳送過來的syn或者ack就會被丟棄。客戶端等待很長一段時間無果後，然後會發出TCP Retransmission重傳。
拿半連線佇列舉例：
要知道的是上面TCP握手超時重傳的時間是秒級別的。也就是說一旦server端的連線佇列導致連線建立不成功，那麼光建立連線就至少需要秒級以上。而正常的在同機房的情況下只是不到1毫秒的事情，整整高了1000倍左右。
尤其是對於給使用者提供實時服務的程式來說，使用者體驗將會受到較大影響。如果連重傳也沒有握手成功的話，很可能等不及二次重試，這個使用者訪問直接就超時了。
還有另外一個更壞的情況是：它還有可能會影響其它的使用者。
假如你使用的是程式/執行緒池這種模型提供服務，比如：php-fpm。我們知道fpm程式是阻塞的，當它響應一個使用者請求的時候，該程式是沒有辦法再響應其它請求的。假如你開了100個程式/執行緒，而某一段時間內有50個程式/執行緒卡在和redis或者mysql伺服器的握手連線上了（注意：這個時候你的伺服器是TCP連線的客戶端一方）。這一段時間內相當於你可以用的正常工作的程式/執行緒只有50個了。而這個50個worker可能根本處理不過來，這時候你的服務可能就會產生擁堵。再持續稍微時間長一點的話，可能就產生雪崩了，整個服務都有可能會受影響。
既然後果有可能這麼嚴重，那麼我們如何檢視我們手頭的服務是否有因為半/全連線佇列滿的情況發生呢？
在客戶端：可以抓包檢視是否有SYN的TCP Retransmission。如果有偶發的TCP Retransmission，那就說明對應的服務端連線佇列可能有問題了。
在服務端的話：檢視起來就更方便一些了。netstat -s 可檢視到當前系統半連線佇列滿導致的丟包統計，但該數字記錄的是總丟包數。你需要再借助 watch 命令動態監控。如果下面的數字在你監控的過程中變了，那說明當前伺服器有因為半連線佇列滿而產生的丟包。你可能需要加大你的半連線佇列的長度了。
$ watch'netstat -s | grep LISTEN'
8 SYNs to LISTEN sockets ignored
對於全連線佇列來說呢，檢視方法也類似：
$ watch'netstat -s | grep overflowed'
160 timesthe listen queue of a socket overflowed
如果你的服務因為佇列滿產生丟包，其中一個做法就是加大半/全連線佇列的長度。 半連線佇列長度Linux核心中，主要受tcp_max_syn_backlog影響 加大它到一個合適的值就可以。
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
1024
echo "2048" > /proc/sys/net/ipv4/tcp_max_syn_backlog
全連線佇列長度是應用程式呼叫listen時傳入的backlog以及核心引數net.core.somaxconn二者之中較小的那個。你可能需要同時調整你的應用程式和該核心引數。
cat /proc/sys/net/core/somaxconn
128
echo "256" > /proc/sys/net/core/somaxconn
改完之後我們可以通過ss命令輸出的Send-Q確認最終生效長度：
$ ss -nlt
Recv-Q Send-Q Local Address:Port Address:Port
0 128 :80 :*
Recv-Q告訴了我們當前該程式的全連線佇列使用長度情況。如果Recv-Q已經逼近了Send-Q,那麼可能不需要等到丟包也應該準備加大你的全連線佇列了。
如果加大佇列後仍然有非常偶發的佇列溢位的話，我們可以暫且容忍。
如果仍然有較長時間處理不過來怎麼辦？
另外一個做法就是直接報錯，不要讓客戶端超時等待。
例如將Redis、Mysql等後端介面的核心引數tcp_abort_on_overflow為1。如果佇列滿了，直接發reset給client。告訴後端程式/執行緒不要痴情地傻等。這時候client會收到錯誤“connection reset by peer”。犧牲一個使用者的訪問請求，要比把整個站都搞崩了還是要強的。
5、TCP連線耗時實測分析
5.1 測試前的準備
我寫了一段非常簡單的程式碼，用來在客戶端統計每建立一個TCP連線需要消耗多長時間。
<?php
$ip= {伺服器ip};
$port= {伺服器埠};
$count= 50000;
function buildConnect($ip,$port,$num){
for($i=0;$i<$num;$i++){
$socket= socket_create(AF_INET,SOCK_STREAM,SOL_TCP);
if($socket==false) {
echo"$ip $port socket_create() 失敗的原因是:".socket_strerror(socket_last_error($socket))."\n";
sleep(5);
continue;
}
if(false == socket_connect($socket, $ip, $port)){
echo"$ip $port socket_connect() 失敗的原因是:".socket_strerror(socket_last_error($socket))."\n";
sleep(5);
continue;
}
socket_close($socket);
}
}
$t1= microtime(true);
buildConnect($ip, $port, $count);
echo(($t2-$t1)*1000).'ms';
在測試之前，我們需要本機linux可用的埠數充足，如果不夠50000個，最好調整充足。
echo "5000 65000" /proc/sys/net/ipv4/ip_local_port_range
5.2 正常情況下的測試
注意：無論是客戶端還是伺服器端都不要選擇有線上服務在跑的機器，否則你的測試可能會影響正常使用者訪問
首先：我的客戶端位於河北懷來的IDC機房內，伺服器選擇的是公司廣東機房的某臺機器。執行ping命令得到的延遲大約是37ms，使用上述指令碼建立50000次連線後，得到的連線平均耗時也是37ms。
這是因為前面我們說過的，對於客戶端來看，第三次的握手只要包傳送出去，就認為是握手成功了，所以只需要一次RTT、兩次傳輸耗時。雖然這中間還會有客戶端和服務端的系統呼叫開銷、軟中斷開銷，但由於它們的開銷正常情況下只有幾個us(微秒)，所以對總的連線建立延時影響不大。
接下來：我換了一臺目標伺服器，該伺服器所在機房位於北京。離懷來有一些距離，但是和廣東比起來可要近多了。這一次ping出來的RTT是1.6~1.7ms左右，在客戶端統計建立50000次連線後算出每條連線耗時是1.64ms。
再做一次實驗：這次選中實驗的伺服器和客戶端直接位於同一個機房內，ping延遲在0.2ms~0.3ms左右。跑了以上指令碼以後，實驗結果是50000 TCP連線總共消耗了11605ms，平均每次需要0.23ms。
線上架構提示：這裡看到同機房延遲只有零點幾ms，但是跨個距離不遠的機房，光TCP握手耗時就漲了4倍。如果再要是跨地區到廣東，那就是百倍的耗時差距了。線上部署時，理想的方案是將自己服務依賴的各種mysql、redis等服務和自己部署在同一個地區、同一個機房（再變態一點，甚至可以是甚至是同一個機架）。因為這樣包括TCP連結建立啥的各種網路包傳輸都要快很多。要儘可能避免長途跨地區機房的呼叫情況出現。
5.3 TCP連線佇列溢位情況下的測試
測試完了跨地區、跨機房和跨機器。這次為了快，直接和本機建立連線結果會咋樣呢？
Ping本機ip或127.0.0.1的延遲大概是0.02ms，本機ip比其它機器RTT肯定要短。我覺得肯定連線會非常快，嗯實驗一下。
連續建立5W TCP連線：總時間消耗27154ms，平均每次需要0.54ms左右。
嗯！？怎麼比跨機器還長很多？
有了前面的理論基礎，我們應該想到了：由於本機RTT太短，所以瞬間連線建立請求量很大，就會導致全連線佇列或者半連線佇列被打滿的情況。一旦發生佇列滿，當時撞上的那個連線請求就得需要3秒+的連線建立延時。所以上面的實驗結果中，平均耗時看起來比RTT高很多。
在實驗的過程中，我使用tcpdump抓包看到了下面的一幕。原來有少部分握手耗時3s+，原因是半連線佇列滿了導致客戶端等待超時後進行了SYN的重傳。
我們又重新改成每500個連線，sleep 1秒。嗯好，終於沒有卡的了（或者也可以加大連線佇列長度）。
結論是：本機50000次TCP連線在客戶端統計總耗時102399 ms，減去sleep的100秒後，平均每個TCP連線消耗0.048ms。比ping延遲略高一些。
這是因為當RTT變的足夠小的時候，核心CPU耗時開銷就會顯現出來了，另外TCP連線要比ping的icmp協議更復雜一些，所以比ping延遲略高0.02ms左右比較正常。
6、本文小結
TCP連線在建立異常的情況下，可能需要好幾秒，一個壞處就是會影響使用者體驗，甚至導致當前使用者訪問超時都有可能。另外一個壞處是可能會誘發雪崩。
所以當你的伺服器使用短連線的方式訪問資料的時候：一定要學會要監控你的伺服器的連線建立是否有異常狀態發生。如果有，學會優化掉它。當然你也可以採用本機記憶體快取，或者使用連線池來保持長連線，通過這兩種方式直接避免掉TCP握手揮手的各種開銷也可以。
再說正常情況下：TCP建立的延時大約就是兩臺機器之間的一個RTT耗時，這是避免不了的。但是你可以控制兩臺機器之間的物理距離來降低這個RTT，比如把你要訪問的redis儘可能地部署的離後端介面機器近一點，這樣RTT也能從幾十ms削減到最低可能零點幾ms。
最後我們再思考一下：如果我們把伺服器部署在北京，給紐約的使用者訪問可行嗎？
前面的我們同機房也好，跨機房也好，電訊號傳輸的耗時基本可以忽略（因為物理距離很近），網路延遲基本上是轉發裝置佔用的耗時。但是如果是跨越了半個地球的話，電訊號的傳輸耗時我們可得算一算了。 北京到紐約的球面距離大概是15000公里，那麼拋開裝置轉發延遲，僅僅光速傳播一個來回（RTT是Rround trip time，要跑兩次），需要時間 = 15,000,000 *2 / 光速 = 100ms。實際的延遲可能比這個還要大一些，一般都得200ms以上。建立在這個延遲上，要想提供使用者能訪問的秒級服務就很困難了。所以對於海外使用者，最好都要在當地建機房或者購買海外的伺服器。
附錄：更多網路程式設計精華資料
[1] 網路程式設計(基礎)資料：
《TCP/IP詳解 - 第17章·TCP：傳輸控制協議》
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（上）：理論基礎》
《理論經典：TCP協議的3次握手與4次揮手過程詳解》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《網路程式設計懶人入門(一)：快速理解網路通訊協議（上篇）》
《網路程式設計懶人入門(二)：快速理解網路通訊協議（下篇）》
《網路程式設計懶人入門(三)：快速理解TCP協議一篇就夠》
《網路程式設計懶人入門(四)：快速理解TCP和UDP的差異》
《網路程式設計懶人入門(五)：快速理解為什麼說UDP有時比TCP更有優勢》
《網路程式設計懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網路程式設計懶人入門(七)：深入淺出，全面理解HTTP協議》
《網路程式設計懶人入門(八)：手把手教你寫基於TCP的Socket長連線》
《網路程式設計懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網路程式設計懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《網路程式設計懶人入門(十一)：一文讀懂什麼是IPv6》
《網路程式設計懶人入門(十二)：快速讀懂Http/3協議，一篇就夠！》
《網路程式設計懶人入門(十三)：一泡尿的時間，快速搞懂TCP和UDP的區別》
《網路程式設計懶人入門(十四)：到底什麼是Socket？一文即懂！》
《技術掃盲：新一代基於UDP的低延時網路傳輸層協議——QUIC詳解》
《讓網際網路更快：新一代QUIC協議在騰訊的技術實踐分享》
《聊聊iOS中網路程式設計長連線的那些事》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（上篇）》
《IPv6技術詳解：基本概念、應用現狀、技術實踐（下篇）》
《Java對IPv6的支援詳解：支援情況、相關API、演示程式碼》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網路程式設計入門(一)：跟著動畫來學TCP三次握手和四次揮手》
《腦殘式網路程式設計入門(二)：我們在讀寫Socket時，究竟在讀寫什麼？》
《腦殘式網路程式設計入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網路程式設計入門(四)：快速理解HTTP/2的伺服器推送(Server Push)》
《腦殘式網路程式設計入門(五)：每天都在用的Ping命令，它到底是什麼？》
《腦殘式網路程式設計入門(六)：什麼是公網IP和內網IP？NAT轉換又是什麼鬼？》
《腦殘式網路程式設計入門(七)：面視必備，史上最通俗計算機網路分層詳解》
《腦殘式網路程式設計入門(八)：你真的瞭解127.0.0.1和0.0.0.0的區別？》
《腦殘式網路程式設計入門(九)：面試必考，史上最通俗大小端位元組序詳解》
《邁向高階：優秀Android程式設計師必知必會的網路基礎》
《Android程式設計師必知必會的網路通訊傳輸層協議——UDP和TCP》
《技術大牛陳碩的分享：由淺入深，網路程式設計學習經驗乾貨總結》
《可能會搞砸你的面試：你知道一個TCP連線上能發起多少個HTTP請求嗎？》
《5G時代已經到來，TCP/IP老矣，尚能飯否？》
更多同類文章 ……
[2] 網路程式設計(高階)資料：
《高效能網路程式設計(一)：單臺伺服器併發TCP連線數到底可以有多少》
《高效能網路程式設計(二)：上一個10年，著名的C10K併發連線問題》
《高效能網路程式設計(三)：下一個10年，是時候考慮C10M併發問題了》
《高效能網路程式設計(四)：從C10K到C10M高效能網路應用的理論探索》
《高效能網路程式設計(五)：一文讀懂高效能網路程式設計中的I/O模型》
《高效能網路程式設計(六)：一文讀懂高效能網路程式設計中的執行緒模型》
《高效能網路程式設計(七)：到底什麼是高併發？一文即懂！》
《IM開發者的零基礎通訊技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通訊技術入門(十一)：為什麼WiFi訊號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十二)：上網路卡頓？網路掉線？一文即懂！》
《IM開發者的零基礎通訊技術入門(十三)：為什麼手機訊號差？一文即懂！》
《IM開發者的零基礎通訊技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通訊技術入門(十五)：理解定位技術，一篇就夠》
《以網遊服務端的網路接入層設計為例，理解實時通訊的技術挑戰》
《知乎技術分享：知乎千萬級併發的高效能長連線閘道器技術實踐》
《淘寶技術分享：手淘億級移動端接入層閘道器的技術演進之路》
更多同類文章 ……
（本文已同步釋出於：http://www.52im.net/thread-32...）