TCP報文結構

?

• 源端口和目的端口：各占2個字節(jié)，分別寫入源端口號和目的端口號。

• 序號：占4個字節(jié)。序號使用mod運算。TCP是面向字節(jié)流的，在一個TCP連接中傳送的字節(jié)流中的每一個字節(jié)都按順序編號。故該字段也叫做“報文段序號”。

• 確認序號：占4個字節(jié)，是期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號。若確認序號=N,則表明：到序號N-1為止的所有數(shù)據(jù)都已正確收到。

• 數(shù)據(jù)偏移：占4位，表示TCP報文段的首部長度。注意，“數(shù)據(jù)偏移”的單位是32位字(即以4字節(jié)長的字為計算單位)。故TCP首部的最大長度為60字節(jié)。

• 保留：占6位，保留為今后使用，目前置為0；

• 緊急URG：當URG=1，表明緊急指針字段有效。這時發(fā)送方TCP就把緊急數(shù)據(jù)插入到本報文段數(shù)據(jù)的最前面，而在緊急數(shù)據(jù)后面的數(shù)據(jù)仍是普通數(shù)據(jù)。

• 確認ACK：當ACK=1時，確認字段才有效。當ACK=0時，確認號無效。TCP規(guī)定，在連接建立后所有傳送的報文段都必須把ACK置1。

• 推送PSH：接收方TCP收到PSH=1的報文段，就盡快地交付給接收應用進程，而不再等到整個緩存都填滿了后再向上交付。

• 復位RST：當RST=1時，表明TCP連接中出現(xiàn)嚴重差錯，必須釋放連接，然后再重新建立運輸連接。

• 同步SYN：在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文段。對方若同意建立連接，則應在響應的報文段中使SYN=1和ACK=1。故SYN置為1，就表示這是一個連接請求和連接接收報文。

• 終止FIN：用來釋放連接。當FIN=1時，表明此報文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢，并要求釋放運輸連接。

• 窗口：占2個字節(jié)。窗口值作為接收方讓發(fā)送方設置其發(fā)送窗口的依據(jù)。

• 檢驗和：占2字節(jié)。檢驗和字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分。和UDP數(shù)據(jù)報一樣，在計算檢驗和時，也要在TCP報文段的前面加上12字節(jié)的偽首部。偽首部的格式與UDP用戶數(shù)據(jù)報的偽首部一樣，但要將偽首部第四個字段中的17 改為6(協(xié)議號)，把第5字段中的UDP長度改為TCP長度。

• 緊急指針：占2字節(jié)。緊急指針僅在URG=1時才有意義，它指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)。

TCP三次握手

整個流程為：

客戶端主動打開，發(fā)送連接請求報文段，將SYN標識位置為1，Sequence Number置為x(TCP規(guī)定SYN=1時不能攜帶數(shù)據(jù)，x為隨機產(chǎn)生的一個值)，然后進入SYN_SEND狀態(tài)

服務器收到SYN報文段進行確認，將SYN標識位置為1，ACK置為1，Sequence Number置為y，Acknowledgment Number置為x+1，然后進入SYN_RECV狀態(tài)，這個狀態(tài)被稱為半連接狀態(tài)

客戶端再進行一次確認，將ACK置為1(此時不用SYN)，Sequence Number置為x+1，Acknowledgment Number置為y+1發(fā)向服務器，最后客戶端與服務器都進入ESTABLISHED狀態(tài)

為什么在第3步中客戶端還要再進行一次確認呢？

這主要是為了防止已經(jīng)失效的連接請求報文段突然又傳回到服務端而產(chǎn)生錯誤的場景：所謂"已失效的連接請求報文段"是這樣產(chǎn)生的。正常來說，客戶端發(fā)出連接請求，但因為連接請求報文丟失而未收到確認。于是客戶端再次發(fā)出一次連接請求，后來收到了確認，建立了連接。數(shù)據(jù)傳輸完畢后，釋放了連接，客戶端一共發(fā)送了兩個連接請求報文段，其中第一個丟失，第二個到達了服務端，沒有"已失效的連接請求報文段"。

現(xiàn)在假定一種異常情況，即客戶端發(fā)出的第一個連接請求報文段并沒有丟失，只是在某些網(wǎng)絡節(jié)點長時間滯留了，以至于延誤到連接釋放以后的某個時間點才到達服務端。本來這個連接請求已經(jīng)失效了，但是服務端收到此失效的連接請求報文段后，就誤認為這是客戶端又發(fā)出了一次新的連接請求。于是服務端又向客戶端發(fā)出請求報文段，同意建立連接。假定不采用三次握手，那么只要服務端發(fā)出確認，連接就建立了。

由于現(xiàn)在客戶端并沒有發(fā)出連接建立的請求，因此不會理會服務端的確認，也不會向服務端發(fā)送數(shù)據(jù)，但是服務端卻以為新的傳輸連接已經(jīng)建立了，并一直等待客戶端發(fā)來數(shù)據(jù)，這樣服務端的許多資源就這樣白白浪費了。

采用三次握手的辦法可以防止上述現(xiàn)象的發(fā)生。比如在上述的場景下，客戶端不向服務端的發(fā)出確認請求，服務端由于收不到確認，就知道客戶端并沒有要求建立連接。

TCP四次揮手

TCP三次握手是TCP連接建立的過程，TCP四次揮手則是TCP連接釋放的過程。下面是TCP四次揮手的流程圖：

?當客戶端沒有數(shù)據(jù)再需要發(fā)送給服務端時，就需要釋放客戶端的連接，這整個過程為：

客戶端發(fā)送一個報文給服務端(沒有數(shù)據(jù))，其中FIN設置為1，Sequence Number置為u，客戶端進入FIN_WAIT_1狀態(tài)

服務端收到來自客戶端的請求，發(fā)送一個ACK給客戶端，Acknowledge置為u+1，同時發(fā)送Sequence Number為v，服務端年進入CLOSE_WAIT狀態(tài)

服務端發(fā)送一個FIN給客戶端，ACK置為1，Sequence置為w，Acknowledge置為u+1，用來關閉服務端到客戶端的數(shù)據(jù)傳送，服務端進入LAST_ACK狀態(tài)

客戶端收到FIN后，進入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給服務端，Acknowledge置為w+1，Sequence Number置為u+1，最后客戶端和服務端都進入CLOSED狀態(tài)

為什么建鏈接要3次握手，斷鏈接需要4次揮手？

• 對于建鏈接的3次握手，主要是要初始化Sequence Number 的初始值。通信的雙方要互相通知對方自己的初始化的Sequence Number(縮寫為ISN：Inital Sequence Number)——所以叫SYN，全稱Synchronize Sequence Numbers。也就上圖中的 x 和 y。這個號要作為以后的數(shù)據(jù)通信的序號，以保證應用層接收到的數(shù)據(jù)不會因為網(wǎng)絡上的傳輸?shù)膯栴}而亂序(TCP會用這個序號來拼接數(shù)據(jù))。

• 對于4次揮手，其實你仔細看是2次，因為TCP是全雙工的，所以，發(fā)送方和接收方都需要Fin和Ack。只不過，有一方是被動的，所以看上去就成了所謂的4次揮手。如果兩邊同時斷連接，那就會就進入到CLOSING狀態(tài)，然后到達TIME_WAIT狀態(tài)。下圖是雙方同時斷連接的示意圖(你同樣可以對照著TCP狀態(tài)機看)：

使用Wireshark抓包驗證TCP三次握手過程

為了加深對TCP三次握手的理解，抓包看一下TCP三次握手的過程。

抓包下來的內(nèi)容為：

這里多說一句，由于wireshark抓包針對的是網(wǎng)卡，因此只要某張網(wǎng)卡上有網(wǎng)絡訪問，就會有數(shù)據(jù)包，這會導致Wireshark的抓包結果里面會有大量數(shù)據(jù)包，而大多數(shù)都不是想要的，這種情況可以使用Wireshark的過濾規(guī)則。我這里由于知道目標ip，因此使用的是"ip.src == xxx.xxx.xxx.xxx or ip.dst == xxx.xxx.xxx.xxx"這條規(guī)則只過濾特定的ip。

從抓包結果看來，整個過程符合TCP三次握手的預期：

客戶端發(fā)送SYN給服務端

服務端返回SYN+ACK給客戶端

客戶端確認，返回ACK給服務端

至于Sequence Number和Acknowledge Number就不看了，但是注意，前面說了Sequence Number是隨機產(chǎn)生的一個值，但是這里確是0，不光這里是0，抓其他的任何包這個值都是0。但其實這里并不是真的0，而是Wireshark為了顯示更好閱讀，使用了relative sequence number相對序號，Sequence Number具體值我們也是可以看到的：

第一個紅框就是上面說的relative sequence number，第二個紅框就是Sequence Number的真實值0xc978aa7e，轉換為十進制為3380128382，就是隨機產(chǎn)生的Sequence Number。

順便能看到，下一個數(shù)據(jù)包就是HTTP的數(shù)據(jù)包，因為TCP三次握手已完成，連接建立，正式傳輸應用層數(shù)據(jù)，傳輸?shù)腍TTP內(nèi)容大小為704字節(jié)。

來自：https://www.cnblogs.com/kaleidoscope/p/9701117.html

總結

以上是生活随笔為你收集整理的tcp 三次握手与四次挥手_TCP三次握手与四次挥手详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。