《網絡協議從入門到底層原理》筆記（六）傳輸層（UDP、TCP、流量控制、擁塞控制、建立連接、釋放連接）

網絡層是為主機之間提供邏輯通信；傳輸層為應用進程之間提供端到端的邏輯通信。

邏輯通信”的意思是“好像是這樣通信，但事實上並非真的這樣通信”。從IP層來說，通信的兩端是兩台主機。但“兩台主機之間的通信”這種說法還不夠清楚。嚴格地講，兩台主機進行通信就是兩台主機中的應用進程互相通信。從運輸層的角度看，通信的真正端點並不是主機而是主機中的進程。也就是說，端到端的通信是應用進程之間的通信。
即“主機 A 的某個進程和主機 B 上的另一個進程進行通信”。簡稱為“計算機之間通信”。

傳輸層有兩個主要協議：

• TCP（Transmission Control Protocol），傳輸控制協議
• UDP（User Datagram Protocol），用戶數據報協議

 

 TCP 傳送的數據單位協議是 TCP 報文段(segment)。
 UDP 傳送的數據單位協議是 UDP 報文或用戶數據報。

第一章 UDP協議

UDP 只在 IP 的數據報服務之上增加了很少一點的功能：

• 復用和分用的功能
• 差錯檢測的功能

 

1.1 UDP特點

UDP 是無連接的，發送數據之前不需要建立連接，因此減少了開銷和發送數據之前的時延。
UDP 使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持復雜的連接狀態表。
UDP 是面向報文的。UDP 對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。UDP 一次交付一個完整的報文。

UDP 沒有擁塞控制，因此網絡出現的擁塞不會使源主機的發送速率降低。這對某些實時應用是很重要的。很適合多媒體通信的要求。
UDP 支持一對一、一對多、多對一和多對多的交互通信。
UDP 的首部開銷小，只有 8 個字節，比 TCP 的 20 個字節的首部要短。

1.2 UDP數據格式

 UDP長度（Length）占16位：首部的長度 + 數據的長度

UDP檢驗和（Checksum）

檢驗和的計算內容：偽首部 + 首部 + 數據
偽首部：僅在計算檢驗和時起作用，並不會傳遞給網絡層

UDP端口（Port）

UDP首部中端口是占用2字節
可以推測出端口號的取值范圍是：0~65535
客戶端的源端口是臨時開啟的隨機端口
防火牆可以設置開啟\關閉某些端口來提高安全性

常用命令：

• netstat –an：查看被占用的端口
• netstat –anb：查看被占用的端口、占用端口的應用程序
• telnet 主機 端口：查看是否可以訪問主機的某個端口
• 安裝telnet：控制面板 – 程序 – 啟用或關閉Windows功能 – 勾選“Telnet Client” – 確定

第二章 TCP協議

TCP 是面向連接的運輸層協議，在無連接的、不可靠的 IP 網絡服務基礎之上提供可靠交付的服務。為此，在 IP 的數據報服務基礎之上，增加了保證可靠性的一系列措施。

2.1 TCP特點

TCP 是面向連接的運輸層協議。
每一條 TCP 連接只能有兩個端點 (endpoint)，每一條 TCP 連接只能是點對點的（一對一）。
TCP 提供可靠交付的服務。
TCP 提供全雙工通信。

面向字節流

• TCP 中的“流”(stream) 指的是流入或流出進程的字節序列。
• “面向字節流”的含義是：雖然應用程序和 TCP 的交互是一次一個數據塊，但 TCP 把應用程序交下來的數據看成僅僅是一連串無結構的字節流。

TCP的幾個要點：

•     可靠傳輸
•     流量控制
•     擁塞控制
•     連接管理（建立連接、釋放連接）

2.2 TCP數據格式

數據偏移

• 占4位，取值范圍是二進制 0b0101 ~ 0b1111（5~15）
• 數據偏移 * 4 = 首部長度（Header Length）
• 首部長度是 20 ~ 60 字節

保留字段

• 占6位，目前全為0
• TCP 關於保留字段的細節：有些資料中，TCP首部的 保留(Reserved)字段 占3位，標志(Flags) 字段占9位（Wireshark中也是如此）

UDP的首部 中有個兩個字節（16位）的字段記錄了整個UDP報文段的長度（首部+數據）。
但是，TCP的首部 中僅僅有個 4 位（數據偏移）的字段記錄了 TCP報文段的首部長度，並沒有字段記錄TCP報文段的數據長度。

•  UDP首部中占16位的長度字段是冗余的，純粹是為了保證首部是32位對齊
•  TCP\UDP的數據長度，完全可以由IP數據包（網絡層）的首部推測出來
•  傳輸層的數據長度 = 網絡層的總長度 - 網絡層的首部長度 - 傳輸層的首部長度（首部長度固定）

檢驗和（ CheckSum）

跟UDP一樣，TCP檢驗和的計算內容：偽首部 + 首部 + 數據
偽首部：占用12字節，僅在計算檢驗和時起作用，並不會傳遞給網絡層

標志位（Flags）URG、ACK、PSH、RST、SYN、FIN

URG（Urgent）

•  當 URG = 1 時，緊急指針字段才有效。表明當前報文段中有緊急數據，應優先盡快傳送

ACK（Acknowledgment）

• 當 ACK = 1 時，確認號字段才有效
• 當 ACK =0 時，確認號無效。

PSH（Push）

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

RST（Reset）

• 當 RST = 1 時，表明連接中出現嚴重差錯（如由於主機崩潰或其他原因），必須釋放連接，然后再重新建立連接

SYN（Synchronization）

• 當 SYN = 1、ACK = 0 時，表明這是一個建立連接的請求
• 若對方同意建立連接，則回復 SYN = 1、ACK = 1

FIN（Finish）

• 當 FIN = 1 時，表明數據已經發送完畢，要求釋放連接

序號、確認號、窗口

序號（Sequence Number）

• 占4字節
• 首先，在傳輸過程的每一個字節都會有一個編號
• 在建立連接后，序號代表：這一次傳給對方的TCP數據部分的第一個字節的編號

確認號（Acknowledgment Number）

• 占4字節
• 在建立連接后，確認號代表：期望對方下一次傳過來的TCP數據部分的第一個字節的編號(客戶端瀏覽器希望服務器)

窗口（Window）

• 占2字節
• 這個字段有流量控制功能，用以告知對方下一次允許發送的數據大小（字節為單位）

2.3 可靠傳輸

ARQ（Automatic Repeat–reQuest）協議，自動重傳請求

自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數據鏈路層和傳輸層的錯誤糾正協議之一。它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現可靠的信息傳輸。如果發送方在發送后一段時間之內沒有收到確認幀，它通常會重新發送。ARQ包括停止等待ARQ協議和連續ARQ協議。

停止等待ARQ協議

停止等待協議是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就停止發送，等待對方確認（回復ACK）。如果過了一段時間（超時時間后），還是沒有收到 ACK 確認，說明沒有發送成功（停止等待），需要重新發送（超時重傳），直到收到確認后再發下一個分組；

在停止等待協議中，若接收方收到重復分組，就丟棄該分組，但同時還要發送確認；

 

確認丟失

若 B 所發送的對 M1 的確認丟失了，那么 A 在設定的超時重傳時間內不能收到確認，但 A 並無法知道：是自己發送的分組出錯、丟失了，或者 是 B 發送的確認丟失了。因此 A 在超時計時器到期后就要重傳 M1。
假定 B 又收到了重傳的分組 M1。這時 B 應采取兩個行動：

1. 丟棄這個重復的分組 M1，不向上層交付。
2. 向 A 發送確認。不能認為已經發送過確認就不再發送，因為 A 之所以重傳 M1 就表示 A 沒有收到對 M1 的確認。

確認遲到
傳輸過程中沒有出現差錯，但 B 對分組 M1 的確認遲到了。
A 會收到重復的確認。對重復的確認的處理很簡單：收下后就丟棄。
B 仍然會收到重復的 M1，並且同樣要丟棄重復的 M1，並重傳確認分組。

停止等待ARQ的太低，可以使用連續ARQ+滑動窗口協議進行改進。

連續ARQ協議+滑動窗口協議

基本思想：

• 發送方一次可以發出多個分組。
• 使用滑動窗口協議控制發送方和接收方所能發送和接收的分組的數量和編號。
• 每收到一個確認，發送方就把發送窗口向前滑動。
• 接收方一般采用累積確認的方式。
• 采用回退N（Go-Back-N）方法進行重傳。

---

下圖：A為發送方，B為接受方

現在假設每一組數據是100個字節，代表一個數據段的數據，每一組給一個編號

SACK 選擇性確認

在TCP通信過程中，如果發送序列中間某個數據包丟失（比如1、2、3、4、5中3丟失了）
TCP會通過重傳最后確認的分組后續的分組（最后確認的是2，會重傳3、4、5）
這樣原先已經正確傳輸的分組也可能重復發送（比如4、5），降低了TCP性能
為改善上述情況，發展出了 SACK（Selective acknowledgment，選擇性確認）技術

• 告訴發送方哪些數據丟失，哪些數據已經提前收到
• 使TCP只重新發送丟失的包（比如3），不用發送后續所有的分組（比如4、5）

SACK信息會放在TCP首部的選項部分

• Kind：占1字節。值為5代表這是SACK選項
• Length：占1字節。表明SACK選項一共占用多少字節
• Left Edge：占4字節，左邊界
• Right Edge：占4字節，右邊界

一對邊界信息需要占用8字節，由於TCP首部的選項部分最多40字節，所以

• SACK選項最多攜帶4組邊界信息
• SACK選項的最大占用字節數 = 4 * 8 + 2 （加上kind和length）= 34 < 40 符合

上圖的意思，發送方 給 接收方 發了1 - 1000 的10個包，其中棕色的包代表傳過去了，白色的包代表丟失了，此時開啟了SACK選項的話，接收方 給 發送方確認收到M2包， TCP首部中可選部分會記錄，收到了
Letf Edge = 301,Right Edge = 401,
Letf Edge = 501,Right Edge = 601,
Letf Edge = 701,Right Edge = 801,
Letf Edge = 901,Right Edge = 1001,
發送方收到之后就知道M3,M5,M7,M9包修飾，就會重傳這幾個包

 

思考題：

1、若有個包重傳了N次還是失敗，會一直持續重傳到成功為止么？
答：這個取決於系統設置，有的系統設置重傳5次還未成功就會發生eset報文（RST）斷開連接

2、為什么選擇在傳輸層將數據分成多段，而不是網絡層或者數據鏈路層？
答：因為可以提高重傳性能。
可靠傳輸是在傳輸層進行控制的，網絡層和數據鏈路層不保證可靠傳輸。
如果在傳輸層不分段，若丟包，整個傳輸層的數據都需要重傳
如果在傳輸層分段， 若丟包，只重傳丟包的一段數據即可

3、如果接收窗口最多能接收4個包，但發送方只發了2個包，接收方如何確定后面還有沒有2個包？

答：等待一定時間后沒有第3個包，就會返回確認收到2個包給發送方

2.4 流量控制

流量控制是點對點、端對端，兩台設備之間的。

一般說來，我們總是希望數據傳輸得更快一些。但如果發送方把數據發送得過快，接收方就可能來不及接收，這就會造成數據的丟失。

• 接收方只能把收到的數據包丟掉，大量的丟包會極大着浪費網絡資源
• 所以要進行流量控制

什么是流量控制？

流量控制 (flow control) 就是讓發送方的發送速率不要太快，既要讓接收方來得及接收，也不要使網絡發生擁塞。

原理

利用滑動窗口機制。

• 通過確認報文中窗口字段來控制發送方的發送速率
• 發送方的發送窗口大小不能超過接收方給出窗口大小
• 當發送方收到接收窗口的大小為0時，發送方就會停止發送數據

 rwind = receive window = 接收窗口

有一種特殊情況 死鎖

B （接收方）向 A（發送方）發送了零窗口的報文段后不久，B 的接收緩存又有了一些存儲空間。於是 B 向 A 發送了 rwnd = 400 的報文段。
但這個報文段在傳送過程中丟失了。A 一直等待收到 B 發送的非零窗口的通知，而 B 也一直等待 A 發送的數據。
如果沒有其他措施，這種互相等待的死鎖局面將一直延續下去。
為了解決這個問題，TCP 為每一個連接設有一個持續計時器 (persistence timer)。

解決方案：

為了解決這個問題， TCP 為每一個連接設有一個持續計時器  (persistence timer) 。只要 TCP 連接的一方收到對方的零窗口通知，就啟動該持續計時器。

• 若持續計時器設置的時間到期，就發送一個零窗口探測報文段（僅攜帶 1 字節的數據），而對方就在確認這個探測報文段時給出了現在的窗口值。
• 若窗口仍然是零，則收到這個報文段的一方就重新設置持續計時器。
• 若窗口不是零，則死鎖的僵局就可以打破了。

2.5 擁塞控制

詳細內容參見：https://www.cnblogs.com/wkfvawl/p/12813103.html

在某段時間，若對網絡中某資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞。這種現象稱為擁塞 (congestion)。圖中兩個鏈路匯合到R3前 700 + 600M 大於1000M的帶寬。

最壞結果：系統崩潰。

擁塞控制

• 防止過多的數據注入到網絡中
• 避免網絡中的路由器或鏈路過載

擁塞控制是一個全局性的過程，產生原因

• 點緩存的容量太小；
• 鏈路的容量不足；
• 處理機處理的速率太慢；
• 擁塞本身會進一步加劇擁塞；

根本是： ∑ 對資源需求  > 可用資源   網絡能夠承受現有的網絡負荷。

• 涉及到所有的主機、路由器 （動態問題）
• 以及與降低網絡傳輸性能有關的所有因素
• 是大家共同努力的結果

相比而言，流量控制是點對點通信的控制

擁塞控制方法

• 慢開始（slow start，慢啟動）
• 擁塞避免（congestion avoidance）
• 快速重傳（fast retransmit）
• 快速恢復（fast recovery）

幾個概念

• MSS（Maximum Segment Size）：

每個段最大的數據部分大小（在建立連接時確定）

一般是 MTU(最大傳輸單元 數據鏈路層1500) - 20 （網絡層首部）- 20（傳輸層TCP首部 也有可能是32） = 1460

實際大小，需要發送方和接收方雙方協商。

• cwnd（congestion window）：擁塞窗口
• rwnd（receive window）：接收窗口
• swnd（send window）：

發送窗口 swnd = min(cwnd, rwnd)

• 當rwnd < cwnd時，是接收方的接收能力限制發送窗口的最大值
• 當cwnd < rwnd時，則是網絡的擁塞限制發送窗口的最大值

慢開始

目的：用來確定網絡的負載能力或擁塞程度。
算法的思路：由小到大逐漸增大擁塞窗口數值。

 

接收窗口(cwnd)的初始值比較小, 然后隨着數據包被接收方確認(收到一個ACK), cwnd就成倍增長(指數級)

擁塞避免

• ssthresh(slow start threshold): 慢開始閾值, cwnd達到閾值后, 以線性方式增加
• 擁塞避免(加法增大)：擁塞窗口緩慢增大, 以防止網絡過早出現擁塞
• 乘法減小：只要網絡出現擁塞, 把ssthresh減為擁塞峰值的一半, 同時執行慢開始算法(cwnd又恢復到初始值)
• 當網絡出現頻繁擁塞時, ssthresh值就下降的很快

快速重傳

接收方: 每收到一個失序的分組后就立即發出重復確認, 使發送方及時知道有分組沒有到達, 而不要等待自己發送數據時才進行確認
發送方: 只要連續收到三個重復確認（總共4個相同的確認），就應當立即重傳對方尚未收到的報文段, 而不必繼續等待重傳計時器到期后再重傳

快速恢復

1. 當發送發連續接收到三個確認時，就執行乘法減小算法，把慢啟動開始門限（ssthresh）減半，但是接下來並不執行慢開始算法。
2. 此時不執行慢啟動算法，而是把cwnd設置為ssthresh的一半， 然后執行擁塞避免算法，使擁塞窗口緩慢增大

2.6 序列號、確認號

先明確幾個概念：

序列號(sequence number)：seq序號，占32位，用來標識從TCP源端向目的端發送的字節流，發起方發送數據時對此進行標記。

確認號（acknowledgement number）：ack序號，占32位，只有ACK標志位為1時，確認序號字段才有效，ack=seq+1。

序列號是想告訴對方現在數據包發送到哪里了。

確認號是告訴對方我已經收到多少了，請接下了發送多少

標志位（Flags）：共6個，即URG、ACK、PSH、RST、SYN、FIN等。具體含義如下：

• URG：緊急指針（urgent pointer）有效。
• ACK：確認序號有效。（為了與確認號ack區分開，我們用大寫表示）
• PSH：接收方應該盡快將這個報文交給應用層。
• RST：重置連接。
• SYN：發起一個新連接。（synchronous建立聯機）
• FIN：釋放一個連接。

客戶端與服務器從建立連接到發送數據的完整流程如下圖

下面的說明解釋都以相對為例

第一步建立連接，客戶端向服務器發送SYN，數據部分為0，建立連接是沒有數據部分，只有頭部信息。

發送方：seq = 0，len = 0

 第二步，接收方：ack = 0 + 1

 第三步，發送方為了響應上一次的ack，客戶端給回服務器的響應中，seq為1。發送方期望下一次的響應從1開始，所以ack = 1

 第三步和第四步都是客戶端向服務器發送信息，所以seq和ack相同，不同的是第四步數據部分不為0

 第五步到第八步皆為服務端向客戶端發送信息，所以ack皆為上一次接收到的數據長度k + 1。
不同之處在於每次請求的seq為上一次的長度加上本次數據長度。

第N個包的序號 =  前面N-1個包的總長度 + 1

 

 

 

 第九步客戶端的ack為前幾次服務器數據之和 + 1，而seq為上一次發送數據長度 + 1

 總結：

 

2.7 建立連接

三次握手

看過上面的序列號和確認號的知識后，建立連接的三次握手機制便很好理解了。

• CLOSED：client處於關閉狀態
• LISTEN：server處於監聽狀態，等待client連接
• SYN-RCVD：表示server接受到了SYN報文，當收到client的ACK報文后，它會進入到 ESTABLISHED 狀態
• SYN-SENT：表示client已發送SYN報文，等待server的第2次握手
• ESTABLISHED：表示連接已經建立

狀態變化：

• 客戶端和服務器同時屬於closed狀態，表示沒有連接關系。
• 客戶端發送請求，客戶端打開發送(SYN-sent)狀態，同時服務器打開監聽(Listen)狀態；
• 服務器在接收到客戶端的請求時，服務器切換為回復(SYN-recvd)狀態；
• 客戶端在接收到服務器的響應時，客戶端切換為穩定連接(Estab-lished)狀態的同時發送第二次數據包。
• 服務器在接收到客戶端的第二次數據時，服務器切換為穩定連接(Estab-lished)狀態。
• 雙方建立穩定連接后，開始正常通信數據。

前2次握手的特點？

SYN 都設置為1
數據部分的長度都為0
TCP頭部的長度一般是32字節（TCP頭部至少是20字節，還有40字節是可以變化的）

• 固定頭部：20字節
• 選項部分：12字節

雙方會交換確認一些信息

•  比如MSS、是否支持SACK（選擇性確認）、Window scale（窗口縮放系數） 等
•  這些數據都放在了TCP頭部的選項部分中（12字節）

為什么建立連接的時候，要進行3次握手？2次不行么？
主要目的：防止server端一直等待，浪費資源
如果建立連接只需要2次握手，可能會出現的情況：

    假設client發出的第一個連接請求報文段，因為網絡延遲，在連接釋放以后的某個時間才到達server，本來這是一個早已失效的連接請求，但server收到此失效的請求后，誤認為是client再次發出的一個新的連接請求，於是server就向client發出確認報文段，同意建立連接。如果不采用“3次握手”，那么只要server發出確認，新的連接就建立了。由於現在client並沒有真正想連接服務器的意願，因此不會理睬server的確認，也不會向server發送數據。但server卻以為新的連接已經建立，並一直等待client發來數據，這樣，server的很多資源就白白浪費掉了

采用 “三次握手” 的辦法可以防止上述現象發生

    例如上述情況，client沒有向【server的確認】發出確認，server由於收不到確認，就知道client並沒有要求建立連接

如果第3次握手失敗了，會怎么處理？

• 此時server的狀態為 SYN-RCVD，若等不到client的 ACK，server會重新發送 SYN+ACK 包
• 如果server多次重發 SYN+ACK 都等不到client的 ACK，就會發送 RST包，強制關閉連接

2.8 釋放連接

釋放連接是在建立連接的基礎上，由客戶端發起的連接釋放，ACK為1，因為在前面客戶端與服務器有進行過數據的轉發

四次揮手

 

為什么釋放連接的時候，要進行4次揮手？
TCP是全雙工模式，通信是雙方的

第1次揮手：當主機1發出FIN報文段時

• 表示主機1告訴主機2，主機1已經沒有數據要發送了，但是，此時主機1還是可以接受來自主機2的數據

第2次揮手：當主機2返回ACK報文段時

• 表示主機2已經知道主機1沒有數據發送了，但是主機2還是可以發送數據到主機1的

第3次揮手：當主機2也發送了FIN報文段時

•  表示主機2告訴主機1，主機2已經沒有數據要發送了

第4次揮手：當主機1返回ACK報文段時

•  表示主機1已經知道主機2沒有數據發送了。隨后正式斷開整個TCP連接

兩邊通道全關掉，才會進入CLOSED狀態

前兩次是客戶端要求結束關系，但是這不影響服務器后面發送數據給客戶端，客戶端進行確認

后兩次是服務器要求結束關系，這次就是真的結束關系了

狀態解讀

• FIN-WAIT-1：表示想主動關閉連接
  • 向對方發送了FIN報文，此時進入到FIN-WAIT-1狀態
• CLOSE-WAIT：表示在等待關閉
  • 當對方發送FIN給自己，自己會回應一個ACK報文給對方，此時則進入到CLOSE-WAIT狀態
  • 在此狀態下，需要考慮自己是否還有數據要發送給對方，如果沒有，發送FIN報文給對方
• FIN-WAIT-2：只要對方發送ACK確認后，主動方就會處於FIN-WAIT-2狀態，然后等待對方發送FIN報文
• CLOSING：一種比較罕見的例外狀態
  • 表示你發送FIN報文后，並沒有收到對方的ACK報文，反而卻也收到了對方的FIN報文
  • 如果雙方幾乎在同時准備關閉連接的話，那么就出現了雙方同時發送FIN報文的情況，也即會出現CLOSING狀態
  • 表示雙方都正在關閉連接
• LAST-ACK：被動關閉的一方在發送FIN報文之后，最后等待對方的ACK報文
  • 當收到ACK報文后，即可進入CLOSED狀態了
• TIME-WAIT：表示收到了對方的FIN報文, 並發送出了ACK報文，就等2MSL后即可進入CLOSED狀態了
  • 如果FIN-WAIT-1狀態下，收到了對方同時帶FIN標志和ACK標志的報文時
    • 可以直接進入到TIME-WAIT狀態，而無須經過FIN-WAIT-2狀態
• CLOSED: 關閉狀態
• 由於有些狀態的時間比較短暫, 所以很難用netstat命令看到, 比如SYN-RCVD、FIN-WAIT-1等
• 

細節

◼ TCP/IP協議棧在設計上，允許任何一方先發起斷開請求。這里演示的是client主動要求斷開

◼ client發送ACK后，需要有個TIME-WAIT階段，等待一段時間后，再真正關閉連接

一般是等待2倍的MSL（Maximum Segment Lifetime，最大分段生存期）

✓ MSL是TCP報文在Internet上的最長生存時間

✓ 每個具體的TCP實現都必須選擇一個確定的MSL值，RFC 1122建議是2分鍾

為什么客戶端最后還要等待2MSL？

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

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

◼ 如果client發送ACK后馬上釋放了，然后又因為網絡原因，server沒有收到client的ACK，server按照傳統就會重發FIN

這時可能出現的情況是

① client沒有任何響應，服務器那邊會干等，甚至多次重發FIN，浪費資源

② client有個新的應用程序剛好分配了同一個端口號，新的應用程序收到FIN后馬上開始執行斷開連接的操作，本來它可能是想跟server建立連接的

抓包

有時候在使用抓包工具的時候，有可能只會看到 “3次“揮手
這其實是將第2、3次揮手合並了

當server接收到client的FIN時，如果server后面也沒有數據要發送給client了
這時，server就可以將第2、3次揮手合並，同時告訴client兩件事

• 已經知道client沒有數據要發
• server已經沒有數據要發了