上一次講了 UDP 協(xié)議，從這次開(kāi)始，就要講 TCP 協(xié)議了，因?yàn)?TCP 協(xié)議涉及到的東西很多，一篇文章概括不完，所以我把 TCP 協(xié)議的內(nèi)容分成好幾個(gè)部分，逐個(gè)擊破。

TCP 報(bào)文段結(jié)構(gòu)

一談到 TCP 協(xié)議，大家最先想到的詞就是「面向連接」和「可靠」。沒(méi)錯(cuò)，TCP 協(xié)議的設(shè)計(jì)就是為了能夠在客戶(hù)端和服務(wù)器之間建立起一個(gè)可靠連接。

在講連接過(guò)程之前，我們先來(lái)看看 TCP 的報(bào)文段結(jié)構(gòu)，通過(guò)這個(gè)結(jié)構(gòu)，我們可以知道 TCP 能夠提供什么信息：

這里有幾點(diǎn)是需要注意的：

• TCP 協(xié)議需要一個(gè)四元組(源IP，源端口，目的IP，目的端口)來(lái)確定連接，這要和 UDP 協(xié)議區(qū)分開(kāi)。多說(shuō)一句，IP 地址位于 IP 報(bào)文段，TCP 報(bào)文段是不含 IP 地址信息的。
• 基本 TCP 頭部的長(zhǎng)度是 20 字節(jié)，但是由于「選項(xiàng)」的長(zhǎng)度是不確定的，所以需要「首部長(zhǎng)度」字段明確給出頭部長(zhǎng)度。這里要注意的是，首部長(zhǎng)度字段的單位是 32bit，也就是 4 字節(jié)，所以該字段的最小值是 5。
• 標(biāo)橙色的字段(確認(rèn)序號(hào)，接收窗口大小，ECE，ACK)用于「回復(fù)」對(duì)方，舉個(gè)例子，服務(wù)器收到對(duì)方的數(shù)據(jù)包后，不單獨(dú)發(fā)一個(gè)數(shù)據(jù)包來(lái)回應(yīng)，而是稍微等一下，把確認(rèn)信息附在下一個(gè)發(fā)往客戶(hù)端的數(shù)據(jù)幀上，也就是捎帶技術(shù)。
• 窗口大小是一個(gè) 16 位無(wú)符號(hào)數(shù)，也就是說(shuō)窗口被限制在了 65535 字節(jié)，也就限制了 TCP 的吞吐量性能，這對(duì)一些高速以及高延遲的網(wǎng)絡(luò)不太友好(可以想想為什么)。所幸 TCP 額外提供了窗口縮放(Window Scale)選項(xiàng)，允許對(duì)這個(gè)值進(jìn)行縮放。

下面是 8 個(gè)標(biāo)志位的含義，有的協(xié)議比較舊，可能沒(méi)有前兩個(gè)標(biāo)志位：

標(biāo)志位雖然很多，但是如果放到具體場(chǎng)景里來(lái)看的話(huà)，就很容易理解他們的作用了。

三次握手

三次握手就是為了在客戶(hù)端和服務(wù)器間建立連接，這個(gè)過(guò)程并不復(fù)雜，但里面有很多細(xì)節(jié)需要注意。

這張圖就是握手的過(guò)程，可以看到客戶(hù)端與服務(wù)器之間一共傳遞了三次消息，這三次握手其實(shí)就是兩臺(tái)機(jī)器之間互相確認(rèn)狀態(tài)，我們來(lái)一點(diǎn)一點(diǎn)看。

1. 第一次握手

首先是客戶(hù)端發(fā)起連接，第一個(gè)數(shù)據(jù)包將 SYN 置位(也就是 SYN = 1)，表明這個(gè)數(shù)據(jù)包是 SYN 報(bào)文段(也被稱(chēng)為段 1)。這一次發(fā)送的目的是告訴服務(wù)器，自己的初始序列號(hào)是 client_isn ，還有一個(gè)隱含的信息在圖里沒(méi)有表現(xiàn)出來(lái)，那就是告知服務(wù)端自己想連接的端口號(hào)。除了這些，客戶(hù)端還會(huì)發(fā)送一些選項(xiàng)，不過(guò)這跟三次握手沒(méi)多大關(guān)系，暫且按下不表。

段 1 里最需要注意的就是這個(gè)client_isn ，也就是初始序列號(hào)?！窻FC0793^1」指出：

翻譯過(guò)來(lái)就是，初始序列號(hào)是一個(gè) 32 位的(虛擬)計(jì)數(shù)器，而且這個(gè)計(jì)數(shù)器每 4 微秒加 1，也就是說(shuō)，ISN 的值每 4.55 小時(shí)循環(huán)一次。這個(gè)舉措是為了防止序列號(hào)重疊。

但即使這樣還是會(huì)有安全隱患——因?yàn)槌跏?ISN 仍然是可預(yù)測(cè)的，惡意程序可能會(huì)分析 ISN ，然后根據(jù)先前使用的 ISN 預(yù)測(cè)后續(xù) TCP 連接的 ISN，然后進(jìn)行攻擊，一個(gè)著名的例子就是「The Mitnick attack^2」 。這里摘一段原文：

所以為了讓初始序列號(hào)更難預(yù)測(cè)，現(xiàn)代系統(tǒng)常常使用半隨機(jī)的方法選擇初始序列號(hào)，詳細(xì)的方法就不在這里展開(kāi)了。

2. 第二次握手

當(dāng)服務(wù)器接收到客戶(hù)端的連接請(qǐng)求后，就會(huì)向客戶(hù)端發(fā)送 ACK表示自己收到了連接請(qǐng)求，而且，服務(wù)器還得把自己的初始序列號(hào)告訴客戶(hù)端，這其實(shí)是兩個(gè)步驟，但是發(fā)送一個(gè)數(shù)據(jù)包就可以完成，用的就是前面說(shuō)的捎帶技術(shù)。圖里的 ACK = client_isn + 1 是指確認(rèn)號(hào)字段的值，要注意和 ACK 標(biāo)志位區(qū)分開(kāi)。

ACK 字段其實(shí)也有不少需要注意的點(diǎn)，不過(guò)這個(gè)跟滑動(dòng)窗口一塊講比較直觀，這里就先不提了。

這里重點(diǎn)強(qiáng)調(diào)一下，當(dāng)一個(gè) SYN 報(bào)文段到達(dá)的時(shí)候，服務(wù)器會(huì)檢查處于 SYN_RCVD 狀態(tài)的連接數(shù)目是否超過(guò)了 tcp_max_syn_backlog 這個(gè)參數(shù)，如果超過(guò)了，服務(wù)器就會(huì)拒絕連接。當(dāng)然，這個(gè)也會(huì)被黑客所利用，「SYN Flood」就是個(gè)很好的例子。因?yàn)榉?wù)器在回復(fù) SYN-ACK 后，會(huì)等待客戶(hù)端的 ACK ，如果一定時(shí)間內(nèi)沒(méi)有收到，認(rèn)為是丟包了，就重發(fā) SYN-ACK，重復(fù)幾次后才會(huì)斷開(kāi)這個(gè)連接，linux 可能要一分鐘才會(huì)斷開(kāi)，所以攻擊者如果制造一大批 SYN 請(qǐng)求而不回復(fù)，服務(wù)器的 SYN 隊(duì)列很快就被耗盡，這一段時(shí)間里，正常的連接也會(huì)得不到響應(yīng)。

服務(wù)器的這種狀態(tài)稱(chēng)為靜默(muted)。為了抵御 SYN Flood 攻擊，服務(wù)器可以采用「SYN cookies」，這種思想是，當(dāng) SYN 到達(dá)時(shí)，并不直接為其分配內(nèi)存，而是把這條連接的信息編碼并保存在 SYN-ACK 報(bào)文段的序列號(hào)字段，如果客戶(hù)端回復(fù)了，服務(wù)器再?gòu)?ACK 字段里解算出 SYN 報(bào)文的重要信息(有點(diǎn)黑魔法的感覺(jué)了)，驗(yàn)證成功后才為該連接分配內(nèi)存。這樣，服務(wù)器不會(huì)響應(yīng)攻擊者的請(qǐng)求，正常連接則不會(huì)受到影響。

但 SYN cookies 本身有一些限制，并不適合作為默認(rèn)選項(xiàng)，有興趣可以自行 Google。

3. 第三次握手

這是建立 TCP 連接的最后一步，經(jīng)過(guò)前兩次握手，客戶(hù)端(服務(wù)器)已經(jīng)知道對(duì)方的滑動(dòng)窗口大小，初始序列號(hào)等信息了，這不就完了嗎?為什么還要第三次握手?

這是因?yàn)榉?wù)器雖然把數(shù)據(jù)包發(fā)出去了，但他還不知道客戶(hù)端是否收到了這個(gè)包，所以服務(wù)器需要等待客戶(hù)端返回一個(gè) ACK，表明客戶(hù)端收到了數(shù)據(jù)，至此，連接完成。

連接建立后，進(jìn)入傳輸數(shù)據(jù)的階段，這里就涉及到很多很多技術(shù)，我會(huì)另寫(xiě)文章。

四次揮手

有了三次握手的基礎(chǔ)，四次揮手就比較容易理解了：

四次揮手的過(guò)程其實(shí)很簡(jiǎn)單，就是服務(wù)器和客戶(hù)端互相發(fā)送 FIN 和 ACK 報(bào)文段，告知對(duì)方要斷開(kāi)連接。

四次揮手里值得關(guān)注的一點(diǎn)就是 TIME_WAIT 狀態(tài)，也就是說(shuō)主動(dòng)關(guān)閉連接的一方，即使收到了對(duì)方的 FIN 報(bào)文，也還要等待 2MSL 的時(shí)間才會(huì)徹底關(guān)閉這條連接。(這里面的 MSL 指的是最大段生成期，指的是報(bào)文段在網(wǎng)絡(luò)中被允許存在的最長(zhǎng)時(shí)間。)可為什么不直接關(guān)閉連接呢?

一個(gè)原因是，第四次揮手的 ACK 報(bào)文段不一定到達(dá)了服務(wù)器，為了不讓服務(wù)器一直處于 LAST_ACK 狀態(tài)(服務(wù)器會(huì)重發(fā) FIN，直到收到 ACK)，客戶(hù)端還得等一會(huì)兒，看看是否需要重發(fā)。假如真的丟包了，服務(wù)器發(fā)送 FIN ，這個(gè) FIN 報(bào)文到達(dá)客戶(hù)端時(shí)不會(huì)超過(guò) 2MSL(一來(lái)一回最多 2MSL)，這時(shí)候客戶(hù)端這邊的 TCP 還沒(méi)關(guān)掉，還能重發(fā) ACK。

另一個(gè)原因是，經(jīng)過(guò) 2MSL 之后，網(wǎng)絡(luò)中與該連接相關(guān)的包都已經(jīng)消失了，不會(huì)干擾新連接。我們來(lái)看一個(gè)例子：假如客戶(hù)端向服務(wù)器建立了新的連接，舊連接中某些延遲的數(shù)據(jù)堅(jiān)持到了新連接建立完畢，而且序列號(hào)剛好還在滑動(dòng)窗口內(nèi)，服務(wù)器就誤把它當(dāng)成新連接的數(shù)據(jù)包接收，如下圖所示：

2MSL 機(jī)制就避免了這種情況。