摘要：但是它不會(huì)發(fā)送的。先大概說(shuō)下流量控制是根據(jù)接收方的窗口大小來(lái)感知我這次能夠傳多少數(shù)據(jù)給對(duì)方滑動(dòng)窗口擁塞控制而擁塞控制主要是避免網(wǎng)絡(luò)擁塞，它考慮的問(wèn)題更多。

做為一個(gè)有追求的程序員，不能只滿足增刪改查，我們要對(duì)系統(tǒng)全方面無(wú)死角掌控。掌握了這些基本的網(wǎng)絡(luò)知識(shí)后，相信一方面日常排錯(cuò)中會(huì)事半功倍，另一方面日常架構(gòu)中不得不考慮的高并發(fā)問(wèn)題，理解了這些底層協(xié)議也是會(huì)如虎添翼。

本文不會(huì)單純給大家講講TCP三次握手、四次揮手就完事了。如果只是哪樣的話，我直接貼幾個(gè)連接就完事了。我希望把實(shí)際工作中的很多點(diǎn)能夠串起來(lái)講給大家。當(dāng)然為了文章完整，我依然會(huì)從 三次握手 起頭。

不管是三次握手、還是四次揮手，他們都是完成了TCP不同狀態(tài)的切換。進(jìn)而影響各種數(shù)據(jù)的傳輸情況。下面從三次握手開(kāi)始分析。

本文圖片有部分來(lái)自網(wǎng)絡(luò)，若有侵權(quán)，告知即焚

來(lái)看看三次握手的圖，估計(jì)大家看這圖都快看吐了，不過(guò)為什么每次面試、回憶的時(shí)候還是想不起呢？我再來(lái)抄抄這鍋剩飯吧！

首先當(dāng)服務(wù)端處于 listen 狀態(tài)的時(shí)候，我們就可以再客戶端發(fā)起監(jiān)聽(tīng)了，此時(shí)客戶端會(huì)處于 SYN_SENT 狀態(tài)。服務(wù)端收到這個(gè)消息會(huì)返回一個(gè) SYN 并且同時(shí) ACK 客戶端的請(qǐng)求，之后服務(wù)端便處于 SYN_RCVD 狀態(tài)。這個(gè)時(shí)候客戶端收到了服務(wù)端的 SYN&ACK，就會(huì)發(fā)送對(duì)服務(wù)端的 ACK，之后便處于 ESTABLISHED 狀態(tài)。服務(wù)端收到了對(duì)自己的 ACK 后也會(huì)處于 ESTABLISHED 狀態(tài)。

經(jīng)常在面試中可能有人提問(wèn)：為什么握手要3次，不是2次或者4次呢？

首先說(shuō)4次握手，其實(shí)為了保證可靠性，這個(gè)握手次數(shù)可以一直循環(huán)下去；但是這沒(méi)有一個(gè)終止就沒(méi)有意義了。所以3次，保證了各方消息有來(lái)有回就足夠了。當(dāng)然這里可能有一種情況是，客戶端發(fā)送的 ACK 在網(wǎng)絡(luò)中被丟了。那怎么辦？

其實(shí)大部分時(shí)候，我們連接建立完成就會(huì)立刻發(fā)送數(shù)據(jù)，所以如果服務(wù)端沒(méi)有收到 ACK 沒(méi)關(guān)系，當(dāng)收到數(shù)據(jù)就會(huì)認(rèn)為連接已經(jīng)建立；

如果連接建立后不立馬傳輸數(shù)據(jù)，那么服務(wù)端認(rèn)為連接沒(méi)有建立成功會(huì)周期性重發(fā) SYN&ACK 直到客戶端確認(rèn)成功。

再說(shuō)為什么2次握手不行呢？2次握手我們可以想象是沒(méi)有三次握手最后的 ACK, 在實(shí)際中確實(shí)會(huì)出現(xiàn)客戶端發(fā)送 ACK 服務(wù)端沒(méi)有收到的情況（上面的情況一），那么這是否說(shuō)明兩次握手也是可行的呢？ 看下情況二，2次握手當(dāng)服務(wù)端發(fā)送消息后，就認(rèn)為建立成功，而恰巧此時(shí)又沒(méi)有數(shù)據(jù)傳輸。這就會(huì)帶來(lái)一種資源浪費(fèi)的情況。比如：客戶端可能由于延時(shí)發(fā)送了多個(gè)連接情況，當(dāng)服務(wù)端每收到一個(gè)請(qǐng)求回復(fù)后就認(rèn)為連接建立成功，但是這其中很多求情都是延時(shí)產(chǎn)生的重復(fù)連接，浪費(fèi)了很多寶貴的資源。

因此綜上所述，從資源節(jié)省、效率3次握手都是最合適的。話又回來(lái)三次握手的真實(shí)意義其實(shí)就是協(xié)商傳輸數(shù)據(jù)用的：序列號(hào)與窗口大小。

下面我們通過(guò)抓包再來(lái)看一下真實(shí)的情況是否如上所述。

20:33:26.583598 IP 192.168.0.102.58165 > 103.235.46.39.80: Flags [S], seq 621839080, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1050275400 ecr 0,sackOK,eol], length 0
20:33:26.660754 IP 103.235.46.39.80 > 192.168.0.102.58165: Flags [S.], seq 1754967387, ack 621839081, win 8192, options [mss 1452,nop,wscale 5,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,sackOK,eol], length 0
20:33:26.660819 IP 192.168.0.102.58165 > 103.235.46.39.80: Flags [.], ack 1754967388, win 4096, length 0

抓包： sudo tcpdump -n host www.baidu.com -S

S 表示 SYN
. 表示 ACK
P 表示 傳輸數(shù)據(jù)
F 表示 FIN

揮手，就是說(shuō)數(shù)據(jù)傳完了，同志們?cè)僖?jiàn)！

這里有個(gè)問(wèn)題需要注意下，其實(shí)客戶端、服務(wù)端都能夠主動(dòng)發(fā)起關(guān)閉操作，誰(shuí)調(diào)用 close() 就先發(fā)送關(guān)閉的請(qǐng)求。當(dāng)然一般的流程，發(fā)起建立連接的一方會(huì)主動(dòng)發(fā)起關(guān)閉請(qǐng)求（http中）。

關(guān)于4次揮手的過(guò)程，我就不多解釋了，這里有兩個(gè)重要的狀態(tài)我需要解釋下，這都是我親自經(jīng)歷過(guò)的線上故障，close_wait 與 time_wait。

先給大家一個(gè)命令，統(tǒng)計(jì)tcp的各種狀態(tài)情況。下面表格內(nèi)容就來(lái)自這個(gè)命令的統(tǒng)計(jì)。

netstat -n | awk "/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}"

大量的CLOSE_WAIT 這個(gè)在我之前的一篇文章 線上大量CLOSE_WAIT原因分析 已經(jīng)有過(guò)介紹，它會(huì)導(dǎo)致大量的socket無(wú)法釋放。而每個(gè)socket都是一個(gè)文件，是會(huì)占用資源的。這個(gè)問(wèn)題主要是代碼問(wèn)題。它出現(xiàn)在被動(dòng)關(guān)閉的一方（習(xí)慣稱為server）。

大量的TIME_WAIT 這個(gè)問(wèn)題在日常中經(jīng)?？吹剑髁恳桓呔统霈F(xiàn)大量的該情況。該狀態(tài)出現(xiàn)在主動(dòng)發(fā)起關(guān)閉的一方。該狀態(tài)一般等待的時(shí)間設(shè)為 2MSL后自動(dòng)關(guān)閉，MSL是Maximum Segment Lifetime，報(bào)文最大生存時(shí)間，如果報(bào)文超過(guò)這個(gè)時(shí)間，就會(huì)被丟棄。處于該狀態(tài)下的socket也是不能被回收使用的。線上我就遇到這種情況，每次大流量的時(shí)候，每臺(tái)機(jī)器處于該狀態(tài)的socket就多達(dá)10w+，遠(yuǎn)遠(yuǎn)比處于 Established 狀態(tài)的socket多的多，導(dǎo)致很多時(shí)候服務(wù)響應(yīng)能力下降。這個(gè)一方面可以通過(guò)調(diào)整內(nèi)核參數(shù)處理，另一方面避免使用太多的短鏈接，可以采用連接池來(lái)提升性能。另外在代碼層面可能是由于某些地方?jīng)]有關(guān)閉連接導(dǎo)致的，也需要檢查業(yè)務(wù)代碼。

上面兩個(gè)狀態(tài)一定要牢記發(fā)生在哪一方，這方便我們快速定位問(wèn)題。

最后這里還是放上揮手時(shí)的抓包數(shù)據(jù)：

20:33:26.750607 IP 192.168.0.102.58165 > 103.235.46.39.80: Flags [F.], seq 621839159, ack 1754967720, win 4096, length 0
20:33:26.827472 IP 103.235.46.39.80 > 192.168.0.102.58165: Flags [.], ack 621839160, win 776, length 0
20:33:26.827677 IP 103.235.46.39.80 > 192.168.0.102.58165: Flags [F.], seq 1754967720, ack 621839160, win 776, length 0
20:33:26.827729 IP 192.168.0.102.58165 > 103.235.46.39.80: Flags [.], ack 1754967721, win 4096, length 0

不多不少，剛好4次。

網(wǎng)絡(luò)上有一張TCP狀態(tài)機(jī)的圖，我覺(jué)得太復(fù)雜了，用自己的方式搞個(gè)簡(jiǎn)單點(diǎn)的容易理解的。我從兩個(gè)角度來(lái)說(shuō)明狀態(tài)的變更。

一個(gè)是客戶端

一個(gè)是服務(wù)端

看下面兩張圖的時(shí)候，請(qǐng)一定結(jié)合上面三次握手、四次揮手的時(shí)序圖一起看，加深理解。

客戶端狀態(tài)變更

通過(guò)這張圖，大家是否能夠清晰明了的知道 TCP 在客戶端上的變更情況了呢？

服務(wù)端狀態(tài)變更

這一張圖描述了 TCP 狀態(tài)在服務(wù)端的變遷。

我們常說(shuō)TCP是面向連接的，UDP是無(wú)連接的。那么TCP這個(gè)面向連接主要解決的是什么問(wèn)題呢？

這里繼續(xù)把三次握手的抓包數(shù)據(jù)貼出來(lái)分析下：

20:33:26.583598 IP 192.168.0.102.58165 > 103.235.46.39.80: Flags [S], seq 621839080, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 1050275400 ecr 0,sackOK,eol], length 0
20:33:26.660754 IP 103.235.46.39.80 > 192.168.0.102.58165: Flags [S.], seq 1754967387, ack 621839081, win 8192, options [mss 1452,nop,wscale 5,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,nop,sackOK,eol], length 0
20:33:26.660819 IP 192.168.0.102.58165 > 103.235.46.39.80: Flags [.], ack 1754967388, win 4096, length 0

上面我們說(shuō)到 TCP 的三次握手最重要的就是協(xié)商傳輸數(shù)據(jù)用的序列號(hào)。那這個(gè)序列號(hào)究竟有些什么用呢？這個(gè)序號(hào)能夠幫助后續(xù)兩端進(jìn)行確認(rèn)數(shù)據(jù)包是否收到，解決順序、丟包問(wèn)題；另外我們還可以看到有一個(gè) win 字段，這是雙方交流的窗口大小，這在每次傳輸數(shù)據(jù)過(guò)程中也會(huì)攜帶。主要是告訴對(duì)方，我窗口是這么大，別發(fā)多了或者別發(fā)太少。

總結(jié)下，TCP的幾個(gè)特點(diǎn)是：

順序問(wèn)題，依靠序號(hào)

丟包問(wèn)題，依靠序號(hào)

流量控制，依靠滑動(dòng)窗口

擁塞控制，依靠擁塞窗口+滑動(dòng)窗口

連接維護(hù)，三次握手/四次揮手

這個(gè)問(wèn)題其實(shí)應(yīng)該很好理解。由于數(shù)據(jù)在傳輸前我們已經(jīng)有序號(hào)了，這里注意一下這個(gè)序號(hào)是隨機(jī)的，重復(fù)的概率極地，避免了程序發(fā)生亂入的可能性。

由于我們每個(gè)數(shù)據(jù)包有序號(hào)，雖然發(fā)送與到達(dá)可能不是順序的，但是TCP層收到數(shù)據(jù)后，可以根據(jù)序號(hào)進(jìn)行重新排列；另外在這個(gè)排列過(guò)程中，發(fā)現(xiàn)有了1，2，3，5，6這幾個(gè)包，一檢查就知道4要么延時(shí)未到達(dá)，要么丟包了，等待重傳。

這里需要重要說(shuō)明的一點(diǎn)是。為了提升效率，TCP其實(shí)并不是收到一個(gè)包就發(fā)一個(gè)ack。那是如何ACK的呢？還是以上面為例，TCP收到了1,2,3,5,6這幾個(gè)包，它可能會(huì)發(fā)送一個(gè) ack ，seq=3 的確認(rèn)包，這樣次一次確認(rèn)了3個(gè)包。但是它不會(huì)發(fā)送 5,6 的ack。因?yàn)?沒(méi)有收到?。∫坏?延時(shí)到達(dá)或者重發(fā)到達(dá)，就會(huì)發(fā)送一個(gè) ack, seq=6，又一次確認(rèn)了3個(gè)包。

這兩個(gè)概念說(shuō)實(shí)話，讓我理解了挺長(zhǎng)時(shí)間，主要是對(duì)它們各自控制的內(nèi)容以及相互之間是否有作用一直沒(méi)有鬧清楚。

先大概說(shuō)下：

流量控制：是根據(jù)接收方的窗口大小來(lái)感知我這次能夠傳多少數(shù)據(jù)給對(duì)方；———— 滑動(dòng)窗口

擁塞控制：而擁塞控制主要是避免網(wǎng)絡(luò)擁塞，它考慮的問(wèn)題更多。根據(jù)綜合因素來(lái)覺(jué)得發(fā)多少數(shù)據(jù)給對(duì)方；———— 滑動(dòng)窗口&擁塞窗口

舉個(gè)例子說(shuō)下，比如：A給B發(fā)送數(shù)據(jù)，通過(guò)握手后，A知道B一次可以收1000的數(shù)據(jù)（B有這么大的處理能力），那么這個(gè)時(shí)候滑動(dòng)窗口就可以設(shè)置成1000。那是不是最后真的可以一次發(fā)這么多數(shù)據(jù)給B呢？還不是，這時(shí)候得問(wèn)問(wèn)擁塞窗口，老兄，現(xiàn)在網(wǎng)絡(luò)情況怎么樣？一次運(yùn)1000的數(shù)據(jù)有壓力嗎？擁塞窗口一通計(jì)算說(shuō)不行，現(xiàn)在是高峰期，最多只能有600的貨上路。最終這次傳數(shù)據(jù)的時(shí)候就是 600 的標(biāo)注。大家也可以關(guān)注抓包數(shù)據(jù)的 win 值，一直在動(dòng)態(tài)調(diào)整。

當(dāng)然另外一種情況是滑動(dòng)窗口比擁塞窗口小，雖然運(yùn)輸能力強(qiáng)，但是接收能力有限，這時(shí)候就要取滑動(dòng)窗口的值來(lái)實(shí)際發(fā)生。所以它們二者之間是有關(guān)系的。

所以具體到每次能夠發(fā)送多少數(shù)據(jù)，有這么一個(gè)公式：

LastByteSend - LastByteAcked <= min{cwnd,rwnd}

LastByteSend 是最后一個(gè)發(fā)送的字節(jié)的序號(hào)

LastByteAcked 最后一個(gè)被確認(rèn)的字節(jié)的序號(hào)

這兩個(gè)相減得到的是本次能夠發(fā)送的數(shù)據(jù)，這個(gè)數(shù)據(jù)一定小于或等于 cwnd 與 rwnd 中最小的一個(gè)值。相信大家能夠理清楚。

那么這部分知識(shí)對(duì)于實(shí)際工作中有什么作用呢？指導(dǎo)意義就是：如果你的業(yè)務(wù)很重要、很核心一定不要混布；二是如果你的服務(wù)忽快忽慢，而確信依賴服務(wù)沒(méi)有問(wèn)題，檢查下機(jī)器對(duì)應(yīng)的網(wǎng)絡(luò)情況；三是窗口這個(gè)速度控制機(jī)制，在我們進(jìn)行服務(wù)設(shè)計(jì)的時(shí)候，非常具有參考意義。是不是有點(diǎn)消息隊(duì)列的感覺(jué)？（很多消息隊(duì)列都是勻速的，我們是否可以加一個(gè)窗口的概念來(lái)進(jìn)行優(yōu)化呢？）

到了最關(guān)鍵的地方了，精華我都是留到最后講。下面放一張網(wǎng)上找的socket操作步驟圖，畫(huà)的太好了我就直接用了。

我們假設(shè)我的服務(wù)端就是 Nginx ，我來(lái)嘗試解讀一下。當(dāng)客戶端調(diào)用 connect() 時(shí)候就會(huì)發(fā)起三次握手，這次握手的時(shí)候有幾個(gè)元素唯一確定了這次通信（或者說(shuō)這個(gè)socket），[源IP:源Port， 目的IP:目的Port] ，當(dāng)然這個(gè)socket還不是最終用來(lái)傳輸數(shù)據(jù)的socket，一旦握手完成后，服務(wù)端會(huì)在返回一個(gè) socket 專門(mén)用來(lái)后續(xù)的數(shù)據(jù)傳輸。這里暫且把第一個(gè)socket叫 監(jiān)聽(tīng)socket，第二個(gè)叫 傳輸socket 方便后文敘述。

為什么要這么設(shè)計(jì)呢？大家想一想，如果監(jiān)聽(tīng)的socket還要負(fù)責(zé)數(shù)據(jù)的收發(fā)，請(qǐng)問(wèn)這個(gè)服務(wù)端的效率如何提升？什么東西、誰(shuí)都往這個(gè)socket里邊丟，太復(fù)雜！

到了這一步，我們現(xiàn)在先停下來(lái)算算自己的服務(wù)器機(jī)器能夠有多少連接呢？這個(gè)極限又是如何一步步被突破呢？

先說(shuō) 監(jiān)聽(tīng)socket ，服務(wù)器的prot一般都是固定的，服務(wù)器的ip當(dāng)然也是固定的（單機(jī)）。那么上面的結(jié)構(gòu) [源IP:源Port， 目的IP:目的Port] 其實(shí)只有客戶端的ip與端口可以發(fā)生變化。假設(shè)客戶端用的是IPv4，那么理論連接數(shù)是：2^32(ip數(shù)) * 2^16(端口數(shù)) = 2^48。

看起來(lái)這個(gè)值蠻大的。但是真的能夠有這么多連接嗎？不可能的，因?yàn)槊恳粋€(gè)socket都需要消耗內(nèi)存；以及每一個(gè)進(jìn)程的文件描述符是有上限的。這些都限制了最終的連接數(shù)。

那么如何進(jìn)行調(diào)和呢？我知道的操作有：多進(jìn)程、多線程、IO多路服用、協(xié)程等手段組合使用。

多進(jìn)程

也就是監(jiān)聽(tīng)是一個(gè)進(jìn)程，一旦accept后，對(duì)于 傳輸socket 我們就fork一個(gè)新的子進(jìn)程來(lái)處理。但是這種方式太重，fork一個(gè)進(jìn)程、銷毀一個(gè)進(jìn)程都是特別費(fèi)事的。單機(jī)對(duì)進(jìn)程的創(chuàng)建上限也是有限制的。

多線程

線程比進(jìn)程要輕量級(jí)的多，它會(huì)共享父進(jìn)程的很多資源，比如：文件描述符、進(jìn)程空間，它就是多了一個(gè)引用。因此它的創(chuàng)建、銷毀更加容易。每一個(gè) 傳輸socket 在這里就交給了線程來(lái)處理。

但是不管是多進(jìn)程、還是多線程都存在一個(gè)問(wèn)題，一個(gè)連接對(duì)應(yīng)一個(gè)進(jìn)程或者協(xié)程。這都很難逃脫 C10K 的問(wèn)題。那么該怎么辦呢？

IO多路復(fù)用

IO多路復(fù)用是什么意思呢？在上面單純的多進(jìn)程、多線程模型中，一個(gè)進(jìn)程或線程只能處理一個(gè)連接。用了IO多路復(fù)用后，我一個(gè)進(jìn)程或線程就能處理多個(gè)連接。

我們都知道 Nginx 非常高效，它的結(jié)構(gòu)是：master + worker，worker 會(huì)在 80、443端口上來(lái)監(jiān)聽(tīng)請(qǐng)求。它的worker一般設(shè)置為 cpu 的cores數(shù)，那么這么少的子進(jìn)程是如何解決超多連接的呢？這里其實(shí)每個(gè)worker就采用了 epoll 模型（當(dāng)然IO多路復(fù)用還有個(gè)select，這里就不說(shuō)了）。

處于監(jiān)聽(tīng)狀態(tài)的worker，會(huì)把所有 監(jiān)聽(tīng)socket 加入到自己的epoll中。當(dāng)這些socket都在epoll中時(shí)，如果某個(gè)socket有事件發(fā)生就會(huì)立即被回調(diào)喚醒（這涉及epoll的紅黑樹(shù)，講不清楚不細(xì)說(shuō)了）。這種模式，大大增加了每個(gè)進(jìn)程可以管理的socket數(shù)量，上限直接可以上升到進(jìn)程能夠操作的最大文件描述符。

一般機(jī)器可以設(shè)置百萬(wàn)級(jí)別文件描述符，所以單機(jī)單進(jìn)程就是百萬(wàn)連接，epoll是解決C10K的利器，很多開(kāi)源軟件用到了它。

這里說(shuō)下，并不是所有的worker都是同時(shí)處于監(jiān)聽(tīng)端口的狀態(tài)，這涉及到nginx驚群、搶自旋鎖的問(wèn)題，不再本文范圍內(nèi)不多說(shuō)。

在文章的最后，補(bǔ)充一些單機(jī)文件描述符設(shè)置的問(wèn)題。我們常說(shuō)連接數(shù)受限于文件描述符，這是為什么？

因?yàn)樵趌inux上一切皆文件，故每一個(gè)socket都是被當(dāng)作一個(gè)文件看待，那么每個(gè)文件就會(huì)有一個(gè)文件描述符。在linux中每一個(gè)進(jìn)程中都有一個(gè)數(shù)組保存了該進(jìn)程需要的所有文件描述符。這個(gè)文件描述符其實(shí)就是這個(gè)數(shù)組的 key ，它的 value 是一個(gè)指針，指向的就是打開(kāi)的對(duì)應(yīng)文件。

關(guān)于文件描述符有兩點(diǎn)注意：

它對(duì)應(yīng)的其實(shí)是一個(gè)linux上的文件

文件描述符本身這個(gè)值在不同進(jìn)程中是可以重復(fù)的

另外補(bǔ)充一點(diǎn)，單機(jī)設(shè)置的ulimit的上線受限與系統(tǒng)的兩個(gè)配置：

fs.nr_open，進(jìn)程級(jí)別
fs.file-max，系統(tǒng)級(jí)別

fs.nr_open 總是應(yīng)該小于等于 fs.file-max，這兩個(gè)值的設(shè)置也不是隨意可以操作，因?yàn)樵O(shè)置的越大，系統(tǒng)資源消耗越多，所以需要根據(jù)真實(shí)情況來(lái)進(jìn)行設(shè)置。

至此，本篇長(zhǎng)文就完結(jié)了。這跟上篇 高并發(fā)架構(gòu)的CDN知識(shí)介紹 屬于一個(gè)系列，高并發(fā)架構(gòu)需要理解的網(wǎng)絡(luò)基礎(chǔ)知識(shí)。

后面還會(huì)寫(xiě)一下 HTTP/HTTPS 的知識(shí)。然后關(guān)于高并發(fā)網(wǎng)絡(luò)相關(guān)的東西就算完結(jié)。我會(huì)開(kāi)啟下一個(gè)篇章。