聊聊TCP鏈接耗時的那些事兒

在互聯網後端平常開發接口的時候中，無論你使用的是C、Java、PHP仍是Golang，都避免不了須要調用mysql、redis等組件來獲取數據，可能還須要執行一些rpc遠程調用，或者再調用一些其它restful api。 在這些調用的底層，基本都是在使用TCP協議進行傳輸。這是由於在傳輸層協議中，TCP協議具有可靠的鏈接，錯誤重傳，擁塞控制等優勢，因此目前應用比UDP更普遍一些。
相信你也必定聽聞過TCP也存在一些缺點，那就是老生常談的開銷要略大。可是各路技術博客裏都在單單說開銷大、或者開銷小，而少見不給出具體的量化分析。不客氣一點，這都是養分不大的廢話。通過平常工做的思考以後，我更想弄明白的是，開銷到底多大。一條TCP鏈接的創建須要耗時延遲多少，是多少毫秒，仍是多少微秒？能不能有一個哪怕是粗略的量化估計？固然影響TCP耗時的因素有不少，好比網絡丟包等等。我今天只分享我在工做實踐中遇到的比較高發的各類狀況。

一正常TCP鏈接創建過程

要想搞清楚TCP鏈接的創建耗時，咱們須要詳細瞭解鏈接的創建過程。在前文《圖解Linux網絡包接收過程》中咱們介紹了數據包在接收端是怎麼被接收的。數據包從發送方出來，通過網絡到達接收方的網卡。在接收方網卡將數據包DMA到RingBuffer後，內核通過硬中斷、軟中斷等機制來處理（若是發送的是用戶數據的話，最後會發送到socket的接收隊列中，並喚醒用戶進程）。

在軟中斷中，當一個包被內核從RingBuffer中摘下來的時候，在內核中是用struct sk_buff結構體來表示的(參見內核代碼include/linux/skbuff.h)。其中的data成員是接收到的數據，在協議棧逐層被處理的時候，經過修改指針指向data的不一樣位置，來找到每一層協議關心的數據。

對於TCP協議包來講，它的Header中有一個重要的字段-flags。以下圖：

經過設置不一樣的標記爲，將TCP包分紅SYNC、FIN、ACK、RST等類型。客戶端經過connect系統調用命令內核發出SYNC、ACK等包來實現和服務器TCP鏈接的創建。在服務器端，可能會接收許許多多的鏈接請求，內核還須要藉助一些輔助數據結構-半鏈接隊列和全鏈接隊列。咱們來看一下整個鏈接過程：

在這個鏈接過程當中，咱們來簡單分析一下每一步的耗時

• 客戶端發出SYNC包：客戶端通常是經過connect系統調用來發出SYN的，這裏牽涉到本機的系統調用和軟中斷的CPU耗時開銷

• SYN傳到服務器：SYN從客戶端網卡被髮出，開始「跨過山和大海，也穿過人山人海......」，這是一次長途遠距離的網絡傳輸

• 服務器處理SYN包：內核經過軟中斷來收包，而後放到半鏈接隊列中，而後再發出SYN/ACK響應。又是CPU耗時開銷

• SYC/ACK傳到客戶端：SYC/ACK從服務器端被髮出後，一樣跨過不少山、可能不少大海來到客戶端。又一次長途網絡跋涉

• 客戶端處理SYN/ACK：客戶端內核收包並處理SYN後，通過幾us的CPU處理，接着發出ACK。一樣是軟中斷處理開銷

• ACK傳到服務器：和SYN包，同樣，再通過幾乎一樣遠的路，傳輸一遍。 又一次長途網絡跋涉

• 服務端收到ACK：服務器端內核收到並處理ACK，而後把對應的鏈接從半鏈接隊列中取出來，而後放到全鏈接隊列中。一次軟中斷CPU開銷

• 服務器端用戶進程喚醒：正在被accpet系統調用阻塞的用戶進程被喚醒，而後從全鏈接隊列中取出來已經創建好的鏈接。一次上下文切換的CPU開銷

以上幾步操做，能夠簡單劃分爲兩類：

• 第一類是內核消耗CPU進行接收、發送或者是處理，包括系統調用、軟中斷和上下文切換。它們的耗時基本都是幾個us左右。具體的分析過程能夠參見《一次系統調用開銷到底有多大？》、《軟中斷會吃掉你多少CPU？》、《進程/線程切換會用掉你多少CPU？》這三篇文章。

• 第二類是網絡傳輸，當包被從一臺機器上發出之後，中間要通過各式各樣的網線、各類交換機路由器。因此網絡傳輸的耗時相比本機的CPU處理，就要高的多了。根據網絡遠近通常在幾ms~到幾百ms不等。。

1ms就等於1000us，所以網絡傳輸耗時比雙端的CPU開銷要高1000倍左右，甚至更高可能還到100000倍。因此，在正常的TCP鏈接的創建過程當中，通常能夠考慮網絡延時便可。一個RTT指的是包從一臺服務器到另一臺服務器的一個來回的延遲時間。因此從全局來看，TCP鏈接創建的網絡耗時大約須要三次傳輸，再加上少量的雙方CPU開銷，總共大約比1.5倍RTT大一點點。不過從客戶端視角來看，只要ACK包發出了，內核就認爲鏈接是創建成功了。因此若是在客戶端打點統計TCP鏈接創建耗時的話，只須要兩次傳輸耗時-既1個RTT多一點的時間。（對於服務器端視角來看同理，從SYN包收到開始算，到收到ACK，中間也是一次RTT耗時）

二TCP鏈接創建時的異常狀況

上一節能夠看到在客戶端視角，在正常狀況下一次TCP鏈接總的耗時也就就大約是一次網絡RTT的耗時。若是全部的事情都這麼簡單，我想個人此次分享也就沒有必要了。事情不必定老是這麼美好，總會有意外發生。在某些狀況下，可能會致使鏈接時的網絡傳輸耗時上漲、CPU處理開銷增長、甚至是鏈接失敗。如今咱們說一下我在線上遇到過的各類溝溝坎坎。

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多預留一些端口號、改用長鏈接均可以。

2）半/全鏈接隊列滿

若是鏈接創建的過程當中，任意一個隊列滿了，那麼客戶端發送過來的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 times the 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」。犧牲一個用戶的訪問請求，要比把整個站都搞崩了仍是要強的。

三TCP鏈接耗時實測

我寫了一段很是簡單的代碼，用來在客戶端統計每建立一個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

1）正常狀況
注意：不管是客戶端仍是服務器端都不要選擇有線上服務在跑的機器，不然你的測試可能會影響正經常使用戶訪問

首先個人客戶端位於河北懷來的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連接創建啥的各類網絡包傳輸都要快不少。要儘量避免長途跨地區機房的調用狀況出現。

2）鏈接隊列溢出

測試完了跨地區、跨機房和跨機器。此次爲了快，直接和本機創建鏈接結果會咋樣呢？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左右比較正常。

四結論

TCP鏈接創建異常狀況下，可能須要好幾秒，一個壞處就是會影響用戶體驗，甚至致使當前用戶訪問超時都有可能。另一個壞處是可能會誘發雪崩。因此當你的服務器使用短鏈接的方式訪問數據的時候，必定要學會要監控你的服務器的鏈接創建是否有異常狀態發生。若是有，學會優化掉它。固然你也能夠採用本機內存緩存，或者使用鏈接池來保持長鏈接，經過這兩種方式直接避免掉TCP握手揮手的各類開銷也能夠。

再說正常狀況下，TCP創建的延時大約就是兩臺機器之間的一個RTT耗時，這是避免不了的。可是你能夠控制兩臺機器之間的物理距離來下降這個RTT，好比把你要訪問的redis儘量地部署的離後端接口機器近一點，這樣RTT也能從幾十ms削減到最低可能零點幾ms。

最後咱們再思考一下，若是咱們把服務器部署在北京，給紐約的用戶訪問可行嗎？ 前面的咱們同機房也好，跨機房也好，電信號傳輸的耗時基本能夠忽略（由於物理距離很近），網絡延遲基本上是轉發設備佔用的耗時。可是若是是跨越了半個地球的話，電信號的傳輸耗時咱們可得算一算了。 北京到紐約的球面距離大概是15000千米，那麼拋開設備轉發延遲，僅僅光速傳播一個來回（RTT是Rround trip time，要跑兩次），須要時間 = 15,000,000 *2 / 光速 = 100ms。實際的延遲可能比這個還要大一些，通常都得200ms以上。創建在這個延遲上，要想提供用戶能訪問的秒級服務就很困難了。因此對於海外用戶，最好都要在當地建機房或者購買海外的服務器。