TCP的三次握手與四次揮手圖文詳解

背景描述

通過網路模型中的IP層的介紹，我們知道網路層，可以實現兩個主機之間的通訊。但是這並不具體，因為，真正進行通訊的實體是在主機中的進程，是一個主機中的一個進程與另外一個主機中的一個進程在交換資料。IP協定雖然能把資料包文送到目的主機，但是並沒有交付給主機的具體應用進程。而端到端的通訊才應該是應用進程之間的通訊。

UDP，在傳送資料前不需要先建立連線，遠地的主機在收到UDP報文後也不需要給出任何確認。雖然UDP不提供可靠交付，但是正是因為這樣，省去和很多的開銷，使得它的速度比較快，比如一些對實時性要求較高的服務，就常常使用的是UDP。對應的應用層的協定主要有 DNS,TFTP,DHCP,SNMP,NFS 等。

TCP，提供面向連線的服務，在傳送資料之前必須先建立連線，資料傳送完成後要釋放連線。因此TCP是一種可靠的的運輸服務，但是正因為這樣，不可避免的增加了許多的開銷，比如確認，流量控制等。對應的應用層的協定主要有 SMTP,TELNET,HTTP,FTP 等。

常用的熟知埠號

TCP的概述

TCP把連線作為最基本的物件，每一條TCP連線都有兩個端點，這種斷點我們叫作通訊端（socket），它的定義為埠號拼接到IP地址即構成了通訊端，例如，若IP地址為192.3.4.16 而埠號為80，那麼得到的通訊端為192.3.4.16:80。

TCP報文首部

1. 源埠和目的埠，各占2個位元組，分別寫入源埠和目的埠；
2. 序號，佔4個位元組，TCP連線中傳送的位元組流中的每個位元組都按順序編號。例如，一段報文的序號欄位值是 301 ，而攜帶的資料共有100欄位，顯然下一個報文段（如果還有的話）的資料序號應該從401開始；
3. 確認號，佔4個位元組，是期望收到對方下一個報文的第一個資料位元組的序號。例如，B收到了A傳送過來的報文，其序列號欄位是501，而資料長度是200位元組，這表明B正確的收到了A傳送的到序號700為止的資料。因此，B期望收到A的下一個資料序號是701，於是B在傳送給A的確認報文段中把確認號置為701；
4. 資料偏移，占4位元，它指出TCP報文的資料距離TCP報文段的起始處有多遠；
5. 保留，占6位，保留今後使用，但目前應都位0；
6. 緊急URG，當URG=1，表明緊急指標欄位有效。告訴系統此報文段中有緊急資料；
7. 確認ACK，僅當ACK=1時，確認號欄位才有效。TCP規定，在連線建立後所有報文的傳輸都必須把ACK置1；
8. 推播PSH，當兩個應用進程進行互動式通訊時，有時在一端的應用進程希望在鍵入一個命令後立即就能收到對方的響應，這時候就將PSH=1；
9. 復位RST，當RST=1，表明TCP連線中出現嚴重差錯，必須釋放連線，然後再重新建立連線；
10. 同步SYN，在連線建立時用來同步序號。當SYN=1，ACK=0，表明是連線請求報文，若同意連線，則響應報文中應該使SYN=1，ACK=1；
11. 終止FIN，用來釋放連線。當FIN=1，表明此報文的傳送方的資料已經傳送完畢，並且要求釋放；
12. 視窗，占2位元組，指的是通知接收方，傳送本報文你需要有多大的空間來接受；
13. 檢驗和，占2位元組，校驗首部和資料這兩部分；
14. 緊急指標，占2位元組，指出本報文段中的緊急資料的位元組數；
15. 選項，長度可變，定義一些其他的可選的引數。

TCP連線的建立（三次握手）

最開始的時候用戶端和伺服器都是處於CLOSED狀態。主動開啟連線的為用戶端，被動開啟連線的是伺服器。

1. TCP伺服器進程先建立傳輸控制塊TCB，時刻準備接受客戶進程的連線請求，此時伺服器就進入了LISTEN（監聽）狀態；
2. TCP客戶進程也是先建立傳輸控制塊TCB，然後向伺服器發出連線請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP用戶端進程進入了 SYN-SENT（同步已傳送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶資料，但需要消耗掉一個序號。
3. TCP伺服器收到請求報文後，如果同意連線，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要為自己初始化一個序列號 seq=y，此時，TCP伺服器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶資料，但是同樣要消耗一個序號。
4. TCP客戶進程收到確認後，還要向伺服器給出確認。確認報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連線建立，用戶端進入ESTABLISHED（已建立連線）狀態。TCP規定，ACK報文段可以攜帶資料，但是如果不攜帶資料則不消耗序號。
5. 當伺服器收到用戶端的確認後也進入ESTABLISHED狀態，此後雙方就可以開始通訊了。
   

為什麼TCP用戶端最後還要傳送一次確認呢？

一句話，主要防止已經失效的連線請求報文突然又傳送到了伺服器，從而產生錯誤。

如果使用的是兩次握手建立連線，假設有這樣一種場景，用戶端傳送了第一個請求連線並且沒有丟失，只是因為在網路結點中滯留的時間太長了，由於TCP的用戶端遲遲沒有收到確認報文，以為伺服器沒有收到，此時重新向伺服器傳送這條報文，此後用戶端和伺服器經過兩次握手完成連線，傳輸資料，然後關閉連線。此時此前滯留的那一次請求連線，網路通暢了到達了伺服器，這個報文字該是失效的，但是，兩次握手的機制將會讓用戶端和伺服器再次建立連線，這將導致不必要的錯誤和資源的浪費。

如果採用的是三次握手，就算是那一次失效的報文傳送過來了，伺服器端接受到了那條失效報文並且回復了確認報文，但是用戶端不會再次發出確認。由於伺服器收不到確認，就知道用戶端並沒有請求連線。

TCP連線的釋放（四次揮手）

資料傳輸完畢後，雙方都可釋放連線。最開始的時候，用戶端和伺服器都是處於ESTABLISHED狀態，然後用戶端主動關閉，伺服器被動關閉。

1. 用戶端進程發出連線釋放報文，並且停止傳送資料。釋放資料包文首部，FIN=1，其序列號為seq=u（等於前面已經傳送過來的資料的最後一個位元組的序號加1），此時，用戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即使不攜帶資料，也要消耗一個序號。
2. 伺服器收到連線釋放報文，發出確認報文，ACK=1，ack=u+1，並且帶上自己的序列號seq=v，此時，伺服器端就進入了CLOSE-WAIT（關閉等待）狀態。TCP伺服器通知高層的應用進程，用戶端向伺服器的方向就釋放了，這時候處於半關閉狀態，即用戶端已經沒有資料要傳送了，但是伺服器若傳送資料，用戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3. 用戶端收到伺服器的確認請求後，此時，用戶端就進入FIN-WAIT-2（終止等待2）狀態，等待伺服器傳送連線釋放報文（在這之前還需要接受伺服器傳送的最後的資料）。
4. 伺服器將最後的資料傳送完畢後，就向用戶端傳送連線釋放報文，FIN=1，ack=u+1，由於在半關閉狀態，伺服器很可能又傳送了一些資料，假定此時的序列號為seq=w，此時，伺服器就進入了LAST-ACK（最後確認）狀態，等待用戶端的確認。
5. 用戶端收到伺服器的連線釋放報文後，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，用戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連線還沒有釋放，必須經過2∗

5. MSL（最長報文段壽命）的時間後，當用戶端復原相應的TCB後，才進入CLOSED狀態。
6. 伺服器只要收到了用戶端發出的確認，立即進入CLOSED狀態。同樣，復原TCB後，就結束了這次的TCP連線。可以看到，伺服器結束TCP連線的時間要比用戶端早一些。

為什麼用戶端最後還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP允許不同的實現可以設定不同的MSL值。

第一，保證用戶端傳送的最後一個ACK報文能夠到達伺服器，因為這個ACK報文可能丟失，站在伺服器的角度看來，我已經傳送了FIN+ACK報文請求斷開了，用戶端還沒有給我回應，應該是我傳送的請求斷開報文它沒有收到，於是伺服器又會重新傳送一次，而用戶端就能在這個2MSL時間段內收到這個重傳的報文，接著給出回應報文，並且會重新啟動2MSL計時器。

第二，防止類似與“三次握手”中提到了的“已經失效的連線請求報文段”出現在本連線中。用戶端傳送完最後一個確認報文後，在這個2MSL時間中，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣新的連線中不會出現舊連線的請求報文。

為什麼建立連線是三次握手，關閉連線確是四次揮手呢？

建立連線的時候， 伺服器在LISTEN狀態下，收到建立連線請求的SYN報文後，把ACK和SYN放在一個報文裡傳送給用戶端。
而關閉連線時，伺服器收到對方的FIN報文時，僅僅表示對方不再傳送資料了但是還能接收資料，而自己也未必全部資料都傳送給對方了，所以己方可以立即關閉，也可以傳送一些資料給對方後，再傳送FIN報文給對方來表示同意現在關閉連線，因此，己方ACK和FIN一般都會分開傳送，從而導致多了一次。

如果已經建立了連線，但是用戶端突然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，用戶端如果出現故障，伺服器不能一直等下去，白白浪費資源。伺服器每收到一次用戶端的請求後都會重新復位這個計時器，時間通常是設定為2小時，若兩小時還沒有收到用戶端的任何資料，伺服器就會傳送一個探測報文段，以後每隔75分鐘傳送一次。若一連傳送10個探測報文仍然沒反應，伺服器就認為用戶端出了故障，接著就關閉連線。

Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx

本文永久更新連結地址：https://www.linuxidc.com/Linux/2018-08/153658.htm