最近把個人博客搭建好了露筒，鏈接在這里：tobe的囈語，文章會先在博客和公眾號更新~ 大家多多收藏啊
上一次講了 UDP 協(xié)議纵刘，從這次開始邀窃，就要講 TCP 協(xié)議了，因為 TCP 協(xié)議涉及到的東西很多假哎，一篇文章概括不完瞬捕，所以我把 TCP 協(xié)議的內(nèi)容分成好幾個部分，逐個擊破舵抹。
TCP 報文段結(jié)構(gòu)
一談到 TCP 協(xié)議肪虎，大家最先想到的詞就是「面向連接」和「可靠」。沒錯惧蛹，TCP 協(xié)議的設(shè)計就是為了能夠在客戶端和服務(wù)器之間建立起一個可靠連接扇救。
在講連接過程之前刑枝，我們先來看看 TCP 的報文段結(jié)構(gòu)，通過這個結(jié)構(gòu)迅腔，我們可以知道 TCP 能夠提供什么信息：
這里有幾點是需要注意的：
- TCP 協(xié)議需要一個四元組（源IP装畅，源端口，目的IP沧烈，目的端口）來確定連接掠兄，這要和 UDP 協(xié)議區(qū)分開。多說一句锌雀，IP 地址位于 IP 報文段蚂夕，TCP 報文段是不含 IP 地址信息的。
- 基本 TCP 頭部的長度是 20 字節(jié)腋逆，但是由于「選項」的長度是不確定的婿牍，所以需要「首部長度」字段明確給出頭部長度。這里要注意的是惩歉，首部長度字段的單位是 32bit等脂，也就是 4 字節(jié)，所以該字段的最小值是 5撑蚌。
- 標橙色的字段（確認序號慎菲，接收窗口大小，ECE锨并，ACK）用于「回復(fù)」對方，舉個例子睬棚，服務(wù)器收到對方的數(shù)據(jù)包后第煮，不單獨發(fā)一個數(shù)據(jù)包來回應(yīng)，而是稍微等一下抑党，把確認信息附在下一個發(fā)往客戶端的數(shù)據(jù)幀上包警，也就是捎帶技術(shù)。
- 窗口大小是一個 16 位無符號數(shù)底靠，也就是說窗口被限制在了 65535 字節(jié)害晦，也就限制了 TCP 的吞吐量性能，這對一些高速以及高延遲的網(wǎng)絡(luò)不太友好（可以想想為什么）暑中。所幸 TCP 額外提供了窗口縮放（Window Scale）選項壹瘟，允許對這個值進行縮放。
下面是 8 個標志位的含義鳄逾，有的協(xié)議比較舊稻轨，可能沒有前兩個標志位：
標志位雖然很多，但是如果放到具體場景里來看的話雕凹，就很容易理解他們的作用了殴俱。
TCP 三次握手
三次握手就是為了在客戶端和服務(wù)器間建立連接政冻，這個過程并不復(fù)雜，但里面有很多細節(jié)需要注意线欲。
這張圖就是握手的過程明场，可以看到客戶端與服務(wù)器之間一共傳遞了三次消息，這三次握手其實就是兩臺機器之間互相確認狀態(tài)李丰，我們來一點一點看苦锨。
第一次握手
首先是客戶端發(fā)起連接，第一個數(shù)據(jù)包將 SYN 置位（也就是 SYN = 1）嫌套，表明這個數(shù)據(jù)包是 SYN 報文段（也被稱為段 1）逆屡。這一次發(fā)送的目的是告訴服務(wù)器，自己的初始序列號是 client_isn 踱讨，還有一個隱含的信息在圖里沒有表現(xiàn)出來魏蔗，那就是告知服務(wù)端自己想連接的端口號。除了這些痹筛，客戶端還會發(fā)送一些選項莺治，不過這跟三次握手沒多大關(guān)系，暫且按下不表帚稠。
段 1 里最需要注意的就是這個client_isn 谣旁，也就是初始序列號∽淘纾「RFC0793[1]」指出:
When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours.
翻譯過來就是榄审，初始序列號是一個 32 位的（虛擬）計數(shù)器，而且這個計數(shù)器每 4 微秒加 1杆麸，也就是說搁进，ISN 的值每 4.55 小時循環(huán)一次。這個舉措是為了防止序列號重疊昔头。
但即使這樣還是會有安全隱患——因為初始 ISN 仍然是可預(yù)測的饼问，惡意程序可能會分析 ISN ，然后根據(jù)先前使用的 ISN 預(yù)測后續(xù) TCP 連接的 ISN揭斧，然后進行攻擊莱革，一個著名的例子就是「The Mitnick attack[2]」 。這里摘一段原文：
Mitnick sent SYN request to X-Terminal and received SYN/ACK response. Then he sent RESET response to keep the X-Terminal from being filled up. He repeated this for twenty times. He found there is a pattern between two successive TCP sequence numbers. It turned out that the numbers were not random at all. The latter number was greater than the previous one by 128000.
所以為了讓初始序列號更難預(yù)測讹开，現(xiàn)代系統(tǒng)常常使用半隨機的方法選擇初始序列號盅视，詳細的方法就不在這里展開了。
第二次握手
當服務(wù)器接收到客戶端的連接請求后旦万，就會向客戶端發(fā)送 ACK 表示自己收到了連接請求左冬，而且，服務(wù)器還得把自己的初始序列號告訴客戶端纸型，這其實是兩個步驟拇砰，但是發(fā)送一個數(shù)據(jù)包就可以完成梅忌，用的就是前面說的捎帶技術(shù)。圖里的 ACK = client_isn + 1 是指確認號字段的值除破，要注意和 ACK 標志位區(qū)分開牧氮。
ACK 字段其實也有不少需要注意的點，不過這個跟滑動窗口一塊講比較直觀瑰枫，這里就先不提了踱葛。
這里重點強調(diào)一下，當一個 SYN 報文段到達的時候光坝，服務(wù)器會檢查處于 SYN_RCVD 狀態(tài)的連接數(shù)目是否超過了 tcp_max_syn_backlog 這個參數(shù)尸诽，如果超過了，服務(wù)器就會拒絕連接盯另。當然性含，這個也會被黑客所利用，「SYN Flood」就是個很好的例子鸳惯。因為服務(wù)器在回復(fù) SYN-ACK 后商蕴，會等待客戶端的 ACK ，如果一定時間內(nèi)沒有收到芝发，認為是丟包了绪商，就重發(fā) SYN-ACK，重復(fù)幾次后才會斷開這個連接辅鲸，linux 可能要一分鐘才會斷開格郁，所以攻擊者如果制造一大批 SYN 請求而不回復(fù)，服務(wù)器的 SYN 隊列很快就被耗盡独悴，這一段時間里理张，正常的連接也會得不到響應(yīng)。
服務(wù)器的這種狀態(tài)稱為靜默（muted）绵患。為了抵御 SYN Flood 攻擊，服務(wù)器可以采用「SYN cookies」悟耘，這種思想是落蝙，當 SYN 到達時，并不直接為其分配內(nèi)存暂幼，而是把這條連接的信息編碼并保存在 SYN-ACK 報文段的序列號字段筏勒，如果客戶端回復(fù)了，服務(wù)器再從 ACK 字段里解算出 SYN 報文的重要信息（有點黑魔法的感覺了）旺嬉，驗證成功后才為該連接分配內(nèi)存管行。這樣，服務(wù)器不會響應(yīng)攻擊者的請求邪媳，正常連接則不會受到影響捐顷。
但 SYN cookies 本身有一些限制荡陷，并不適合作為默認選項，有興趣可以自行 Google迅涮。
第三次握手
這是建立 TCP 連接的最后一步废赞，經(jīng)過前兩次握手，客戶端（服務(wù)器）已經(jīng)知道對方的滑動窗口大小叮姑，初始序列號等信息了唉地，這不就完了嗎？為什么還要第三次握手传透？
這是因為服務(wù)器雖然把數(shù)據(jù)包發(fā)出去了耘沼，但他還不知道客戶端是否收到了這個包，所以服務(wù)器需要等待客戶端返回一個 ACK朱盐，表明客戶端收到了數(shù)據(jù)群嗤，至此，連接完成托享。
連接建立后骚烧，進入傳輸數(shù)據(jù)的階段，這里就涉及到很多很多技術(shù)闰围，我會另寫文章赃绊。
四次揮手
有了三次握手的基礎(chǔ)，四次揮手就比較容易理解了：
四次揮手的過程其實很簡單羡榴，就是服務(wù)器和客戶端互相發(fā)送 FIN 和 ACK 報文段碧查，告知對方要斷開連接。
四次揮手里值得關(guān)注的一點就是 TIME_WAIT 狀態(tài)校仑，也就是說主動關(guān)閉連接的一方忠售，即使收到了對方的 FIN 報文，也還要等待 2MSL 的時間才會徹底關(guān)閉這條連接迄沫。（這里面的 MSL 指的是最大段生成期稻扬，指的是報文段在網(wǎng)絡(luò)中被允許存在的最長時間。）可為什么不直接關(guān)閉連接呢羊瘩？
一個原因是泰佳，第四次揮手的 ACK 報文段不一定到達了服務(wù)器，為了不讓服務(wù)器一直處于 LAST_ACK 狀態(tài)（服務(wù)器會重發(fā) FIN尘吗，直到收到 ACK）逝她，客戶端還得等一會兒，看看是否需要重發(fā)睬捶。假如真的丟包了黔宛，服務(wù)器發(fā)送 FIN ，這個 FIN 報文到達客戶端時不會超過 2MSL（一來一回最多 2MSL）擒贸，這時候客戶端這邊的 TCP 還沒關(guān)掉臀晃，還能重發(fā) ACK觉渴。
另一個原因是，經(jīng)過 2MSL 之后积仗，網(wǎng)絡(luò)中與該連接相關(guān)的包都已經(jīng)消失了疆拘，不會干擾新連接。我們來看一個例子：假如客戶端向服務(wù)器建立了新的連接寂曹，舊連接中某些延遲的數(shù)據(jù)堅持到了新連接建立完畢哎迄，而且序列號剛好還在滑動窗口內(nèi)，服務(wù)器就誤把它當成新連接的數(shù)據(jù)包接收隆圆，如下圖所示：
2MSL 機制就避免了這種情況漱挚。
關(guān)于 TIME_WAIT 還有很多有意思的地方，我覺得可以單獨再寫一篇文章了渺氧，這里就不再多說旨涝。
感覺寫的有點亂了，因為 TCP 的知識確實是有點多侣背，希望各位讀者不要介意白华。
