點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

來源：22j.co/bVws

通過上一篇中?網絡模型中的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報文首部

• 源端口和目的端口，各占2個字節，分別寫入源端口和目的端口；

• 序號，占4個字節，TCP連接中傳送的字節流中的每個字節都按順序編號。例如，一段報文的序號字段值是 301 ，而攜帶的數據共有100字段，顯然下一個報文段（如果還有的話）的數據序號應該從401開始；

• 確認號，占4個字節，是期望收到對方下一個報文的第一個數據字節的序號。例如，B收到了A發送過來的報文，其序列號字段是501，而數據長度是200字節，這表明B正確的收到了A發送的到序號700為止的數據。因此，B期望收到A的下一個數據序號是701，于是B在發送給A的確認報文段中把確認號置為701；

• 數據偏移，占4位，它指出TCP報文的數據距離TCP報文段的起始處有多遠；

• 保留，占6位，保留今后使用，但目前應都位0；

• 緊急URG，當URG=1，表明緊急指針字段有效。告訴系統此報文段中有緊急數據；

• 確認ACK，僅當ACK=1時，確認號字段才有效。TCP規定，在連接建立后所有報文的傳輸都必須把ACK置1；

• 推送PSH，當兩個應用進程進行交互式通信時，有時在一端的應用進程希望在鍵入一個命令后立即就能收到對方的響應，這時候就將PSH=1；

• 復位RST，當RST=1，表明TCP連接中出現嚴重差錯，必須釋放連接，然后再重新建立連接；

• 同步SYN，在連接建立時用來同步序號。當SYN=1，ACK=0，表明是連接請求報文，若同意連接，則響應報文中應該使SYN=1，ACK=1；

• 終止FIN，用來釋放連接。當FIN=1，表明此報文的發送方的數據已經發送完畢，并且要求釋放；

• 窗口，占2字節，指的是通知接收方，發送本報文你需要有多大的空間來接受；

• 檢驗和，占2字節，校驗首部和數據這兩部分；

• 緊急指針，占2字節，指出本報文段中的緊急數據的字節數；

• 選項，長度可變，定義一些其他的可選的參數。

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

最開始的時候客戶端和服務器都是處于CLOSED狀態。主動打開連接的為客戶端，被動打開連接的是服務器。

• TCP服務器進程先創建傳輸控制塊TCB，時刻準備接受客戶進程的連接請求，此時服務器就進入了LISTEN（監聽）狀態；

• TCP客戶進程也是先創建傳輸控制塊TCB，然后向服務器發出連接請求報文，這是報文首部中的同部位SYN=1，同時選擇一個初始序列號 seq=x ，此時，TCP客戶端進程進入了 SYN-SENT（同步已發送狀態）狀態。TCP規定，SYN報文段（SYN=1的報文段）不能攜帶數據，但需要消耗掉一個序號。

• TCP服務器收到請求報文后，如果同意連接，則發出確認報文。確認報文中應該 ACK=1，SYN=1，確認號是ack=x+1，同時也要為自己初始化一個序列號 seq=y，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。這個報文也不能攜帶數據，但是同樣要消耗一個序號。

• TCP客戶進程收到確認后，還要向服務器給出確認。確認報文的ACK=1，ack=y+1，自己的序列號seq=x+1，此時，TCP連接建立，客戶端進入ESTABLISHED（已建立連接）狀態。TCP規定，ACK報文段可以攜帶數據，但是如果不攜帶數據則不消耗序號。

• 當服務器收到客戶端的確認后也進入ESTABLISHED狀態，此后雙方就可以開始通信了。

為什么TCP客戶端最后還要發送一次確認呢？

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

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

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

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

數據傳輸完畢后，雙方都可釋放連接。最開始的時候，客戶端和服務器都是處于ESTABLISHED狀態，然后客戶端主動關閉，服務器被動關閉。

• 客戶端進程發出連接釋放報文，并且停止發送數據。釋放數據報文首部，FIN=1，其序列號為seq=u（等于前面已經傳送過來的數據的最后一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。TCP規定，FIN報文段即使不攜帶數據，也要消耗一個序號。

• 服務器收到連接釋放報文，發出確認報文，ACK=1，ack=u+1，并且帶上自己的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處于半關閉狀態，即客戶端已經沒有數據要發送了，但是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。

• 客戶端收到服務器的確認請求后，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送連接釋放報文（在這之前還需要接受服務器發送的最后的數據）。

• 服務器將最后的數據發送完畢后，就向客戶端發送連接釋放報文，FIN=1，ack=u+1，由于在半關閉狀態，服務器很可能又發送了一些數據，假定此時的序列號為seq=w，此時，服務器就進入了LAST-ACK（最后確認）狀態，等待客戶端的確認。

• 客戶端收到服務器的連接釋放報文后，必須發出確認，ACK=1，ack=w+1，而自己的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP連接還沒有釋放，必須經過2?*?MSL（最長報文段壽命）的時間后，當客戶端撤銷相應的TCB后，才進入CLOSED狀態。

• 服務器只要收到了客戶端發出的確認，立即進入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個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。

想知道更多？掃描下面的二維碼關注我

后臺回復"書"，獲取近百本電子書入口

【精彩推薦】

• 超清晰的DNS入門指南

• 深入理解Java Stream流水線

• 干掉Swagger,試試這個

• 干掉GuavaCache：Caffeine才是本地緩存的王

• 如何用ELK搭建TB級的日志系統

• 深度好文：Linux系統內存知識

• 日志系統新貴Loki，確實比笨重的ELK輕

• 日志采集系統都用到哪些技術？

• 面試官：為什么HashMap的加載因子是0.75？

• 原創|OpenAPI標準規范
  

點個贊+在看，少個 bug?????

總結

以上是生活随笔為你收集整理的两张动图，彻底明白TCP的三次握手与四次挥手的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。