👨?🎓博主主頁：爪哇貢塵拾Miraitow
📆傳作時間：🌴2022年1月4日🌴
📒內容介紹：最近在學習計算機網路所以會時不時更新有關內容
📚參考資料：王道考研計算機網路 度娘
🔗參考鏈接：👉TCP報文段的首部格式
?簡言以勵：列位看官，且將新火試新茶，詩酒趁年華
📝內容較多有問題希望能夠不吝賜教🙏
🎃 歡迎點贊 👍 收藏 ?留言 📝

TCP的三次握手和四次揮手，可以說是老生常談的經典問題了，通常也作為各大公司常見的面試考題，我覺得想要清楚理解，還是要從TCP報文段首部格式說起

TCP的介紹

傳輸控制協議（TCP，Transmission Control Protocol）是為了在不可靠的互聯網路上提供可靠的端到端位元組流而專門設計的一個傳輸協議，

TCP報文段首部格式

首部固定部分各欄位意義如下：

①源埠和目的埠 : 各占2個位元組，分別寫入源埠和目的埠，

② 序號 :占4位元組，序號范圍是【0，2^32 - 1】，共2^32（即4294967296）個序號，在TCP連接中傳送的位元組流中的每一個位元組都按順序編號，本欄位表示本報文段所發送資料的第一個位元組的序號
例如，一報文段的序號是201，而接待的資料共有100位元組，這就表明：本報文段的資料的第一個位元組的序號是201，最后一個位元組的序號是300，顯然，下一個報文段（如果還有的話）的資料序號應當從301開始，即下一個報文段的序號欄位值應為401，這個欄位的序號也叫“報文段序號”，

③ 確認號 :占4位元組，是期望收到對方下一個報文段的第一個資料位元組的序號，
例如，B正確收到了A發送過來的一個報文段，其序號欄位值是501，而資料長度是200位元組（序號501~700），這表明B正確收到了A發送的到序號700為止的資料，因此，B期望收到A的下一個資料序號是701，于是B在發送給A的確認報文段中把確認號置為701，注意，現在確認號不是501，也不是700，而是701，
簡而言之：若確認號為= N，則表明：到序號N-1為止的所有資料都已正確收到，

④資料偏移 : 占4位，它指出TCP報文段的資料起始處距離TCP報文段的起始處有多遠，這個欄位實際上是指出TCP報文段的首部長度，由于首部中還有長度不確定的選項欄位，因此資料偏移欄位是必要的，但應注意，“資料偏移”的單位是32位字（即以4位元組的字為計算單位），由于4位二進制數能表示的最大十進制數字是15(最大的四位二進制1111)，因此資料偏移的最大值是60位元組，這也是TCP首部的最大位元組（即選項長度不能超過40位元組因為有20位元組的固定首部），

⑤緊急URG: 當URG=1時，表明緊急指標欄位有效，它告訴系統此報文段中有緊急資料，應盡快發送（相當于高優先級的資料），而不要按原來的排隊順序來傳送，
例如，我們發送檔案好好的，突然接收方說我沒辦法接受檔案了，快停止，發送方收到資訊就會趕快停止，發送方叫停需要發送命令，就會進入TCP快取中，因為我們的URG設定為1，就需要盡快發送，說白了就是允許插隊，不用去排隊

當URG置為1時，發送應用行程就告訴發送方的TCP有緊急資料要傳送，于是發送方TCP就把緊急資料插入到本報文段資料的最前面，而在緊急資料后面的資料仍然是普通資料，這時要與首部中緊急指標（Urgent Pointer）欄位配合使用，

⑥確認ACK（ACKnowledgment）: 僅當ACK = 1時確認號欄位才有效，當ACK = 0時確認號無效，TCP規定，在連接建立后所有的傳送的報文段都必須把ACK置為1，

⑦推送 PSH（PuSH） :當兩個應用行程進行互動式的通信時，有時在一端的應用行程希望在鍵入一個命令后立即就能收到對方的回應，在這種情況下，TCP就可以使用推送（push）操作，這時，發送方TCP把PSH置為1，并立即創建一個報文段發送出去，接收方TCP收到PSH=1的報文段，就盡快地（即“推送”向前）交付接收應用行程，而不用再等到整個快取都填滿了后再向上交付，

⑧復位RST（ReSeT） :當RST=1時，表名TCP連接中出現了嚴重錯誤（如由于主機崩潰或其他原因），必須釋放連接，然后再重新建立傳輸連接，RST置為1還用來拒絕一個非法的報文段或拒絕打開一個連接，

⑨同步SYN（SYNchronization） : 在連接建立時用來同步序號，當SYN=1而ACK=0時，表明這是一個連接請求報文段，對方若同意建立連接，則應在回應的報文段中使SYN=1和ACK=1，因此SYN置為1就表示這是一個連接請求或連接接受報文，(后面三次握手的時候具體來看)

⑩終止FIN（FINis）：用來釋放一個連接，當FIN=1時，表明此報文段的發送發的資料已發送完畢，并要求釋放運輸連接，(后面四次揮手的時候具體來看)

視窗 ：占2位元組，視窗值是【0，2^16-1】之間的整數，視窗指的是發送本報文段的一方的接受視窗（而不是自己的發送視窗），視窗值告訴對方：從本報文段首部中的確認號算起，接收方目前允許對方發送的資料量（以位元組為單位），之所以要有這個限制，是因為接收方的資料快取空間是有限的，總之，視窗值作為接收方讓發送方設定其發送視窗的依據，

例如，發送了一個報文段，其確認號是701，視窗欄位是1000.這就是告訴對方：“從701算起，我（即發送方報文段的一方）的接收快取空間還可接受1000個位元組資料（位元組序號是701~1700），你在給我發資料時，必須考慮到這一點，”

簡而言之：視窗欄位明確指出了現在允許對方發送的資料量，視窗值經常在動態變化，

檢驗和 :占2位元組，檢驗首部+資料，檢驗時要加上12B偽首部，第四個欄位為6

緊急指標 ：占2位元組，緊急指標僅在URG=1時才有意義，它指出本報文段中的緊急資料的位元組數（緊急資料結束后就是普通資料） ，因此，在緊急指標指出了緊急資料的末尾在報文段中的位置，當所有緊急資料都處理完時，TCP就告訴應用程式恢復到正常操作，值得注意的是，即使視窗為0時也可以發送緊急資料，

選項 (長度可變)：最大報文段MSS,視窗擴大，時間戳，選擇確認；

TCP連接管理

TCP連接傳輸三個階段

TCP連接的建立采用客戶服務器方式(c/s)，主動發起連接建立的應用行程叫做客戶，而被動等待連接建立的應用行程叫服務器

TCP的三次握手

TCP的三次握手

剛開始客戶端和客戶端都處于關閉的CLOSED狀態，先是服務端主動監聽某個埠，處于LISTEN狀態

ROUND 1：客戶端會隨機初始化序列號 ISN（c）對應上圖的seq=x將序列號置于TCP首部的【序號】欄位中，同時把SYN標志位置為1，表示SYN報文，接著把第一個SYN報文發送給服務器端，表示服務器發起連接，之后客戶端處于SYN_Send 狀態，

注意：該報文不包括應用層資料 并且此時的ACK是為0，因為客戶端此時沒有收到服務器端發出的報文段因為此時客戶端不知道期待什么所以確認號是沒意義的 ，前面我們也說過了，只有接受請求報文和確認請求報文SYN才為1

ROUND 2：：服務器收到客戶端的 SYN 報文之后，會以自己的 SYN 報文作為應答，并且也是指定了自己的初始化序列號 ISN(s)對應上圖的seq=y，同時會把客戶端的 ISN + 1 對應上圖的ack=x+1作為 ack的值，表示自己已經收到了客戶端的 SYN，此時服務器處于 SYN_REVD 的狀態，

注意：該報文不包括應用層資料 ，因為我們說過了SYN兩種情況下才為1，分別是連接請求和連接請求的確認，所以我們現在是連接請求的接受SYN就是1，從二次握手以后連接，已經建立好了，就不需要SYN了，接下來的連接SYN都為0,當連接建立以后ACK為1，我們的確認號ack就有效了，之所以ack=x+1，就是因為我們接下來期待的收到的下一個欄位為發送端之前發送的X欄位+1

ROUND 3：：客戶端收到 SYN 報文之后，會發送一個 ACK 報文，當然，也是一樣把服務器的 ISN + 1 作為 ACK 的值，表示已經收到了服務端的 SYN 報文，此時客戶端處于 establised 狀態，
服務器收到 ACK 報文之后，也處于 establised 狀態，此時，雙方以建立起了鏈接，

Ps:
(1)SYN=1表示該報文不攜帶資料，但消耗一個序號 seq=x，seq=x是客戶端的初始化序列號，因為tcp是面向位元組流的
(2)SYN=1 表示該報文不攜帶資料，但消耗一個序號 seq=y，seq=y是服務器的初始化序列號，ACK=1是一個確認號
ack=x+1，表示服務器下次接收到的序號希望是x+1，然后服務器進入到SYN-RCVD等待的狀態
(3)ACK=1是一個確認號，seq=x+1是上一次服務器回應的序號要求，ack=y+1表示客戶下一次接收到的序號希望是y+1

tcp通信需要確保雙方都具有資料收發的能力，得到ACK回應則認為對方具有資料收發的能力，因此雙方都要發送SYN確保對方具有通信的能力，第一次握手是客戶端發送SYN，服務端接收，服務端得出客戶端的發送能力和服務端的接收能力都正常；第二次握手是服務端發送SYN+ACK，客戶端接收，客戶端得出客戶端發送接收能力正常，服務端發送接收能力也都正常，但是此時服務器并不能確認客戶端的接收能力是否正常；第三次握手客戶端發送ACK，服務器接收，服務端才能得出客戶端發送接收能力正常，服務端自己發送接收能力也都正常，

大白話來談TCP的三次握手

舉兩個栗子🌰

村里有個貧困的人叫老許，一直單身沒有物件，這一天好友老王來給他介紹物件，但是老許還在睡覺

👴 老王：老許！老許！我是老王，你能聽到嗎？
👨?🦳 老許猛的驚醒一聽是老王的聲音：老王！老王！我是老許，我能聽到你說話，你能聽到我說話嘛！！
👴 老王一聽，嗯，這是老許的聲音：老許！我能聽到，我給你說個事，

“老許你要老婆不要！”
老許連忙穿上衣服，激動的跑出門了，

上面就是簡單的三次握手建立連接然后傳輸資料的程序，是不是很有趣！！

再來個栗子🌰：
我們大家都寫過💌情書，我們要怎么知道對方的答案就要經歷這些

將小明當作客戶端，小紅當作服務器端，兩人寫信告白：
第一次握手：
小明寫信告訴小紅：我喜歡你很久了，可不可以和我在一起，
第二次握手：
小紅收到信以后寫信告訴小明：我知道了，其實我也喜歡你，
此時小紅并不確定小明是否收到了告白信（因為我們的表白信在傳送的時候可能被那些傳信的人，攔截了，你們上學的時候遇到這樣的嘛！哈哈），然后就等待
第三次握手：
小明打開信很開心回信：我知道了，那我們在一起吧，

此時才真正建立戀愛的關系，
這樣你才算和對方完成，男女朋友才經常做的事情，別想太多，就是膩歪膩歪！！！！！

看到這里不知道大家有啥疑惑沒有，如果沒有我們來看看這個問題

①為什么是三次握手？不是兩次，四次？

我們學完了可能就會說，因為三次握手才能保證雙方具有接收和發送的能力，emmmm，這樣說好像是沒毛病，但是比較片面，并沒說出主要的原因

主要原因：是防止失效的連接請求報文段被服務端接收，從而產生錯誤，
注意：失效的連接請求：若客戶端向服務端發送的連接請求丟失，客戶端等待應答超時后就會再次發送連接請求，此時，上一個連接請求就是『失效的』，
a. 若建立連接只需兩次握手，客戶端并沒有太大的變化，仍然需要獲得服務端的應答后才進入ESTABLISHED狀態，而服務端在收到連接請求后就進入ESTABLISHED狀態，
此時如果網路擁塞，客戶端發送的連接請求遲遲到不了服務端，客戶端便超時重發請求，如果服務端正確接收并確認應答，雙方便開始通信，通信結束后釋放連接，此時，如果那個失效的連接請求抵達了服務端，由于只有兩次握手，服務端收到請求就會進入ESTABLISHED狀態，等待發送資料或主動發送資料，但此時的客戶端早已進入CLOSED狀態，服務端將會一直等待下去，這樣浪費服務端連接資源，

采用“三次握手”的辦法可以防止上述現象發生 ，例如上述情況，客戶端沒有向服務器端的確認發出確認，服務器由于收不到確認，就知道客戶端并沒有要求建立連接，

②三次握手可以攜帶資料嗎？

第一次、第二次握手不可以攜帶資料，而第三次握手是可以攜帶資料的，假設第一次可以攜帶資料，如果有人惡意攻擊服務器，每次都在第一次握手中的SYN報文放入大量資料，重復發送大量SYN報文，此時服務器會花費大量記憶體空間來緩沖這些報文，服務器就更容易被攻擊了

TCP的四次揮手

在介紹“四次揮手之前先看個例子”

舉個栗子

還是上面的小明和小紅，現在他們兩個處于熱戀狀態

戀愛之后，小明和小紅經常打電話煲電話粥，依舊將小明當作客戶端，小紅當作服務器端，小明跟小紅說話，
第一次揮手：
小明說：我說完了，也不早了，該睡覺了，
第二次揮手：
小紅還不想睡還想繼續說：好的，我知道了，我還沒說完，
小紅繼續吧啦吧啦，說完情話之后
第三次揮手：
小紅告訴小明：我說完了，
第四次揮手：
小明收到后告訴小紅：好的，我知道了，但是小明也不舍得掛電話，等了2MSL之后小明才掛斷了，
如果此時小紅說完，等了2MSL，小明一直不出聲，這個時候就會重新說一次：我說完了，直到收到小明最后的回復，才掛斷電話，

那么我們回歸TCP的"揮手”

ROUND 1：
客戶端打算關閉連接，此時發送一個TCP首部FIN標志位被設定為1的報文，也就是FIN報文，之后客戶端進入FIN_WAIT_1狀態
ROUND 2：
服務器收到該報文以后，就向客戶端發送ACK應答報文，接著服務器進入CLOSE_WAIT狀態，這樣客戶端到服務器這個方向的連接就釋放了–半關閉狀態，此時客戶端器不用給予回復，因為主機已經結束通話了，只需要等到服務器客戶端告訴自己他也要結束
ROUND 3：
服務器端發完資料，就會發出連接釋放報文段，主動關閉TCP連接，之所以第二次和第三次的ack是一樣的，是因為客戶端沒有發送資料，所以ack期待的下一個報文段不變
ROUND 4：
客戶端回送一個確認報文段，在等到時間，再等到時間等待計時器設定的2MSL（最長報文段壽命）后，連接徹底關閉

看到這里不知道大家有啥疑惑沒有，如果沒有我們來看看這些問題

①為什么我們第一次連接已經釋放了，可是最后還能回送一個報文段那？

這個問題是我在學習的程序中，彈幕上提到的問題，我也有些疑惑其實，斷了連接只是不發送資料而已，但是對服務器還是要回復的，在CLOSED狀態之前，都不能算是真正的關閉

② 為什么客戶端發送ACK之后不直接關閉，而要等待一陣子才關閉

這個是面試的高頻考點，這其中的原因就是，要確保服務器是否已經收到了我們的 ACK 報文，如果沒有收到的話，服務器會重新發 FIN 報文給客戶端，客戶端再次收到 ACK 報文之后，就知道之前的 ACK 報文丟失了，然后再次發送 ACK 報文，至于 TIME_WAIT 持續的時間至少是一個報文的來回時間，一般會設定一個計時，如果過了這個計時沒有再次收到 FIN 報文，則代表對方成功就是 ACK 報文，此時處于 CLOSED 狀態，

------🎃 歡迎點贊 👍 收藏 ?留言 📝-----
<-----希望大家假期🐟快🎊🎊🎊🎊🎊----->
<------------🍻2022新年快樂🥂----------->
<----------?2022大家一起加油?---------->