第6章 傳輸層(詳解TCP的三次握手與四次揮手)

第6章 傳輸層

傳輸層簡介

傳輸層爲網絡應用程序提供了一個接口，而且可以對網絡傳輸提供了可選的錯誤檢測、流量控制和驗證功能。TCP/IP傳輸層包含不少有用的協議，可以提供數據在網絡傳輸所需的必要尋址信息。但尋址和路由只是傳輸層的部分功能。tcp/ip的開發者知道你他們須要在網際層上添加另一層，並經過這一層提供的額外必要特性來使用IP。傳輸層協議須要提供如下功能：

• 爲網絡應用程序提供接口：也就是爲應用程序提供訪問網絡的途徑。設計者但願不只僅可以向目的計算機傳遞數據，還可以向目的計算機上的特定程序傳遞數據。
• 多路複用/多路分解機制：這裏的多路複用表示從不一樣應用程序和計算機接收數據，再把數據傳遞到目的計算機上的接收程序。換句話說，傳輸層必須可以同時支持多個網絡程序和管理傳遞給網際層的數據流。在接收端，傳輸層必須可以從網際層接收數據，把他轉發到多個程序，這種功能被稱爲多路分解，它可讓一臺計算機同時支持多個網絡程序，好比一個WEB瀏覽器、一個E-mail客戶端和一個文件共享應用程序。多路複用/多路分解的另外一個做用是可讓一個應用程序同時保持與多臺計算機的鏈接。
• 錯誤檢測、流量控制和驗證：協議系統須要一種全面的機制來確保發送端與接收端之間的數據傳輸。

最後一項是變化最多的。質量保證一般會在收益與代價之間尋找平衡。精心的質量保證系統會提升傳輸的可靠性，但須要以增長網絡流量和處理時間爲代價。對於大多數應用程序來講，這種額外的保證並不值得。所以傳輸層提供了兩種到達網絡的方式，他們都具備支持應用程序所必須的接口和多路複用/多路分解功能，但在質量保證方面所採用的方法有很大不一樣，以下所示：

• 傳輸控制協議（TCP）：TCP提供了完善的錯誤控制和流量控制，可以確保數據正確傳輸，它是一個面向鏈接的協議。
• 用戶數據報協議（UDP）：UDP只提供了很是基本的錯誤檢測，用於不須要TCP精細控制功能的場合，它是一個無鏈接的協議。

面向鏈接的協議和無鏈接的協議

爲了針對不一樣狀況提供不一樣程序的質量保證，傳輸層提供了兩種不一樣的協議原型

• 面向鏈接的協議：會在通訊計算機之間創建並維護一個鏈接，而且在通訊過程當中監視鏈接的狀態。換句話說，經過網絡傳輸的每一個數據包都會有一個確認，發送端計算機會記錄狀態信息來確保每一個數據包都被正確無誤地接收了，而且在須要時會重發數據。當數據傳輸結束以後，發送端和接收端計算機會以適當方式關閉鏈接。
• 無鏈接的協議：以單向方式向目的發送數據報，不承擔通知目的計算機關於數據發送的職責。目的計算機接收到數據後也不須要向源計算機返回狀態信息。

端口和套接字

在TCP/IP系統中，應用程序能夠使用端口號經過TCP或UDP指定數據目的地。端口是一個預約義的內部地址，充當從應用程序到傳輸層或是從傳輸層到應用程序之間的通路。

進一步觀察傳輸層這種與應用程序相關的尋址體制，就會發現TCP和UDP數據實際是被髮送到一個套接字上的。套接字是一個由IP地址和端口號組成的地址。例如，套接字地址111.121.131.141.21指向IP地址爲111.121.131.141的計算機的端口21。

下面的例子裏展現了一臺計算機如何經過套接字訪問目的計算機上的一個應用程序。

服務	TCP端口號	簡要描述
tcpmux	1	TCP端口服務多路複用器
compressnet	2	管理工具
ftp	21	文件傳輸協議控制
ssh	22	安全shell
smtp	25	簡單郵件傳輸協議
http	80	WWW服務

服務	UDP端口號	簡要描述
echo	7	回顯
discard	9	拋棄或空
domain	53	域名服務程序（DNS）
systat	11	用戶
daytime	13	時間
qotd	17	每日引用

1. 計算機A經過一個熟知的端口向計算機B上的應用程序發起一個鏈接。熟知端口是由互聯網數字分配機構（IANA）分配給特定程序的端口。上表列出了一些熟知的TCP和UDP端口。熟知的端口與IP地址組合以後就構成了計算機A的目的套接字。鏈接請求包含着一個數據字段，告訴計算機B使用什麼套接字向計算機A返回信息，這也就是計算機A的源套接字地址。
2. 計算機B經過熟知端口接收到來自計算機A的請求，向做爲計算機A源地址的套接字發送一個響應。這個套接字就成爲計算機B上的應用程序向計算機A上的應用程序發送消息的目的地址

多路複用/多路分解

套接字尋址系統使得TCP和UDP可以執行傳輸層另外一個重要任務：多路複用和多路分解。多路複用是指多個來源的數據導向一個輸出，而多路分解是把一個來源接收的數據發送到多個輸出。

多路傳輸/多路分解分解讓TCP/IP協議棧較低層的協議沒必要關心哪一個程序在傳輸數據。與應用程序相關的操做都由傳輸層完成了，數據經過一個與應用程序無關的管道在傳輸層與網際層之間傳遞。

多路複用和多路分解的關鍵在於套接字地址。套接字的地址包含了IP地址與端口號，爲特定計算機上的特定應用程序提供了一個惟一的標識。全部客戶端計算機使用熟知的TCP端口21鏈接到FTP服務器，但針對每臺我的計算機的目的套接字是不一樣的。相似地，運行於這臺FTP服務器上所有網絡應用程序都使用服務器的IP地址，但只有FTP服務程序使用由IP地址和TCP端口號21組成的套接字地址

理解TCP和UDP

本章前面提到，TCP是個面向鏈接的協議，提供了全面的錯誤控制和流量控制。UDP是個無鏈接協議，錯誤控制也簡單得多。能夠這樣說，TCP是爲了可靠性，而UDP是爲了速度。必需要支持交互會話的應用程序，好比Talnet和FTP，就會使用TCP。而本身實現錯誤檢測或不須要過多錯誤控制的應用程序會傾向於使用UDP。

軟件開發人員在設計網絡應用程序時能夠選擇使用TCP或UDP做爲傳輸協議。UDP的控制機制雖然比較簡單，但這並非它的缺點。首先，較簡單的質量控制並不必定意味着低質量。對於大多數應用程序來講，TCP提供的錯誤檢測與控制是徹底沒有必要的。在一些須要控制錯誤和流量控制的狀況下，有些開發人員更願意在應用程序自己內提供這些控制功能，從而能夠根據實際須要進行控制，並使用較簡單的UDP進行網絡訪問。例如，應用層的遠程過程調用RPC協議可以支持複雜的應用程序，但RPC開發人員有時傾向於在傳輸層使用UDP，而且利用應用程序提供錯誤控制和流量控制，而不是使用速度較慢的TCP鏈接

TCP：面向鏈接的傳輸協議

它包括如下重要特性：

• 面向流的處理：TCP以流的方式處理數據。換句話說，TCP能夠一個字節一個字節地接收數據，而不是一次接收一個預約義格式的數據塊。TCP把接收到的數據組成長度不定的段，再傳遞到網際層。
• 從新排序：若是數據以錯誤的順序到達目的，TCP模塊可以對數據從新排序來恢復原始順序。
• 流量控制：TCP的流量控制特性可以確保數據傳輸不會超過目的計算機接受數據的能力。因爲現實世界裏會有各類不一樣的應用環境，處理器速度和緩存區大小的差異也可能很大，因此這種流控制能力是很是重要的。
• 優先級與安全：國防部對TCP的規範要求能夠爲TCP鏈接設置可選的安全級別和優先級，但不少TCP實現並無提供這些安全和優先級特性。
• 適當的關閉：TCP像重視創建鏈接同樣重視關閉鏈接的工做，以確保在鏈接關閉以前，全部數據段都被髮送和接收了。

1.TCP數據格式

• 源端口（16位）：分配給源計算機上的應用程序的端口號
• 目的端口（16位）：分配給目的計算機上的應用程序的端口號
• 序列號（32位）：當SYN標記不爲1時，這是當前數據分段第一個字節的序列號；若是SYN的值是1，這個字段的值就是初始序列值（ISN），用於對序列號進行同步，這時第一個字節的序列號比這個字段的值大1（也就是ISN加1）
• 確認號（32位）：用於確認已經接收到的數據分段，其值是接收計算機即將接收的下一個序列號，也就是下一個接收到的字節的序列號加1。
• 數據偏移（4位）：這個字段表示報頭的長度，也就是告訴接收端的TCP軟件數據從何開始。這個值的單位是32位的字
• 保留（6位）：保留字段，爲TCP未來的發展預留空間，目前必須所有是0。
• 控制標記（分別佔用1位）：控制標記用於表示數據分段的特殊信息
  • URG: 爲1時表示當前數據分段是緊急的，也會讓「緊急指針」字段的值有意義。
  • ACK: 爲1時表示「確認號」字段是有意義的。
  • PSH: 爲1時讓TCP軟件把目前收到的所有數據都經過管道傳遞給接收應用程序
  • RST: 爲1時會重置鏈接
  • SYN：爲1時表示序列號將被同步，說明這是一個鏈接的開始。請參見稍後介紹的三次握手
  • FIN：爲1時表示發送端計算機已經沒有數據須要發送了。這個標記用於關閉一個鏈接
• 窗口（16位）：用於流量控制的參數。它定義了發送端計算機的發送序列號能夠超過最後一個已肯定序列號的數量。也就是說，發送方沒必要等待每一個數據段被確認接收以後才發送下一個數據分段，容許已經確認接收的序列號與正在發送的序列號有必定的差異，但必須在適當範圍之中
• 校驗和（16位）：用於檢驗數據分段的完整性。接收端計算機會根據接收到的數據分段計算校驗和，而且把結構與這個字段的值進行比較。TCP和UDP在計算校驗和時包含一個具備IP地址的僞報頭。
• 緊急指針（16位）：這是一個偏移量指針，指向標記緊急信息開始的序列號
• 選項：指定一些可選設置中的某一項
• 填充：額外填充的0，以確保數據從32位字的邊界開始
• 數據：數據分段中的數據

2.TCP鏈接

TCP的功能之一是爲應用程序提供訪問網絡的接口。這個接口是經過TCP端口提供的，而爲了經過端口提供鏈接，必須打開TCP與應用程序的接口。TCP支持如下兩種打開狀態。

• 被動打開：某個應用程序進程通知TCP準備經過TCP端口接收鏈接，這樣就會打開TCP到應用程序的鏈接，從而爲參與鏈接請求作準備
• 主動打開：程序要求TCP發起與另外一臺計算機（處於被動打開狀態）的鏈接，這就是主動打開狀態，實際上TCP能夠對一個處於主動打開狀態的計算機初發起鏈接，已解決兩臺計算機可能同時嘗試創建鏈接的問題。

在一般狀況下，想接收鏈接的應用程序（好比FTP服務器）會把自身及其TCP端口置於被動打開狀態。在客戶端計算機上，FTP客戶端的TCP狀態通常是關閉的，直到用戶發起一個從FTP客戶端到FTP服務器的鏈接，這對於客戶端來講就是主動打開的。處於主動打開狀態的計算機上的TCP軟件會開始一些用於創建鏈接的信息交換，這種信息交換被稱爲「三次握手」，稍後詳細介紹

TCP發送的數據分段的長度是不定的。在一個數據分段內，每字節數據都被分配一個序列號。接收端計算機必須爲接收到的每一個字節數據都發送一確認信號。所以TCP通訊是一種傳輸與確認的系統。TCP報頭中的「序列號」和「確認號」字段讓通訊的TCP軟件可以按期更新傳輸的狀態。

實際上，數據分段中並非爲每一個字節都單獨編了一個序列號。而是在報頭的「序列號」字段指定了數據分段第一個字節的序列號。

若是數據分段被成功接收，接受端計算機會利用「確認號」字段告訴發送端計算機它接收到哪一個字節。在確認消息中，「確認號」字段的值是已接收的最後一個序列號加1.換句話說，「確認號」字段中的值是計算機準備接收的下一個序列號。

3.創建鏈接

爲了讓序列/確認系統正常工做，計算機必須對序列號進行同步。換句話說，計算機B必須知道計算機A的初始化序列號（ISN）。計算機A也必須知道計算機B使用什麼ISN開始傳輸數據。

這個序列號的同步過程被稱爲三次握手。三次握手老是發生在TCP鏈接創建的初期，其步驟以下：

1. 計算機A發送一個數據分段，其中的參數是：
   SYN = 1
   ACK = 0
   序列號 = X (X是計算機A的ISN)
   處於主動打開狀態的計算機（計算機A）發送一個數據分段，其中SYN爲1，ACK爲0.SYN是同步（syncchronize）的縮寫，它表示在嘗試創建一個鏈接。第一個數據分段的報頭還包含初始序列號（ISN），標記了計算機將傳輸的第一個字節的序列號。也就是說，要發送給計算機B的第1個字節的序列號是ISN加1
2. 計算機B接受到計算機A的數據分段，返回一個數據分段，其中的參數是：
   SYN = 1
   ACK = 1 (確認號字段將包含一個值)
   序列號 = Y (Y是計算機B的ISN)
   確認號 = M + 1 (其中M是從計算機A接收到的最後一個序列號)
3. 計算機A向計算機B發送一個數據分段，確認收到計算機B的ISN：
   SYN = 0
   ACK = 1
   序列號 = 序列中下一個號碼 (M+1)
   確認號 = N + 1 (其中N是從計算機B接收到的最後一個序列號)

在這三次握手完成以後，鏈接就被打開了，TCP模塊就利用序列和確信機制發送和接收數據。

爲何須要「三次握手」

在謝希仁的《計算機網絡》中是這樣說的，爲了防止已失效的鏈接報文段又發送到了服務器端，從而產生錯誤
在書中同時舉了一個例子：「已失效的鏈接報文段」產生在這樣一種狀況下：client發出的第一個鏈接請求報文段並無消失，而是在某個網絡結點長時間的滯留了，以至於延誤到釋放之後的時間纔到達server。原本這是一個早已失效的報文段。但server收到此失效的鏈接請求報文段以後，就誤覺得是client再次發過來的一個新的鏈接請求。假設沒有「三次握手」，那麼只要server發出確認，新的鏈接就創建了。因爲如今client並無發出創建鏈接的請求，所以不會理睬server的確認，也不會向server發送數據。但server卻覺得新的運輸鏈接已經創建了，並一直等待client發來數據。這樣，server的資源就白白浪費了。

4.TCP流量控制

TCP報頭中的「窗口」字段爲鏈接提供了一種流量控制機制，其目的是防止發送端計算機不要發送得太快，以免接收端計算機來不及處理接收到的數據而致使數據丟失。TCP使用的流量控制方法被稱爲「滑動窗口」方法。接收端計算機利用「窗口」字段來定義一個超過最後一個已確認序列號的序列號「窗口」。在這個範圍內的序列號才容許發送端計算機進行發送。發送端計算機在沒有接收到下一個確認消息以前不能發送超過這個窗口的序列號。

5.關閉鏈接

當須要關閉鏈接時，計算機開始關閉過程，計算機A發送一個數據分段，其中的FIN標記設置爲1。以後應用程序進入「結束--等待」狀態。在這個狀態中，計算機A的TCP軟件繼續接收數據分段，並處理已經在序列中的數據分段，但再也不從應用程序接收數據了。當計算機B接收到FIN數據分段時，它返回對FIN的確認信息，而後發送剩餘的數據分段，通知本地應用程序接收到了FIN消息。計算機B向計算機A發送一個FIN數據分段，計算機A會返回確認消息，鏈接就被關閉了。

四次揮手的表述

1. 計算機A發送一個FIN標誌，此時計算機A進入FIN_WAIT狀態
2. 計算機B收到了FIN報文段，向計算機A返回一個ACK字段，告訴A我贊成你的關閉請求
3. 計算機B繼續處理剩餘數據，處理完向A發送FIN報文段，請求關閉鏈接，同時B進入LAST_ACK狀態
4. 計算機A接收到B發送的FIN報文段，向B發送ACK報文段，而後主機1進入TIME_WAIT狀態；主機B收到後，就關閉鏈接了。A等待2MSL後依然沒有收到回覆，A也能夠關閉鏈接了。

UDP: 無鏈接傳輸協議

雖然UDP有時被認爲沒有錯誤檢驗功能，但實際上它可以執行基本的錯誤檢驗，所以，能夠說UDP具備有限的錯誤檢驗功能。UDP數據報中包含一個檢驗和，接收端計算機能夠利用它來檢驗數據的完整性（通常狀況下，這個校驗和檢查是可選的，並且可以被接收端計算機禁用以加快對接收數據的處理）。UDP數據報中有個一個僞報頭，包含了數據報的目的地址，從而提供了發現數據報錯誤傳輸的手段。另外，若是UDP接收模塊接收到一個發給未激活或未定義UDP端口的數據報，它會返回一個ICMP消息，通知源計算機這個端口是不可到達的。

其次，UDP沒有像TCP那樣提供數據的從新排序功能。在大型網絡上，數據分段可能會通過不一樣的路徑，因爲路由器緩存而產生明顯延時，這時從新排序功能是很是有意義的。而在局域網上，雖然UDP沒有從新排序功能，但通常不會致使不可靠的接收。

UDP協議的主要用途是把數據報傳遞給應用層。UDP協議的功能簡單，其報頭結構也很簡單。UDP不會從新傳輸丟失或損壞的數據報、從新排列混亂的接收數據、消除重複的數據報、確認數據報的接收、創建或是終止鏈接。它主要是在程序沒必要使用TCP鏈接開銷的狀況下發送和接收數據報的一種方式。若是上述功能對於應用程序來講是必需的，它能夠本身提供這些功能。

UDP頭包含4個16位字段

• 源端口： 這個字段佔據UDP報頭的前16位，一般包含發送數據報的應用程序所使用的UDP端口。接收端的應用程序利用這個字段的值做爲發送響應的目的地址。這個字段是可選的。發送端的應用程序不是必定要把本身的端口寫在這個字段上。若是發送端的應用程序不寫入其端口號，就應該把這個字段全置0。顯然，若是這個字段沒有包含有效的端口地址，接收端的應用程序就不能發送響應。而後有時這可能正是咱們想要的功能，好比單向消息就不須要響應
• 目的端口：這16位字段包含的端口地址是接收端計算機上UDP軟件使用的端口
• 長度：這16位字典以字節爲單位表示UDP數據報的長度。這個長度包括了UDP報頭和UDP數據載荷。由於UDP報頭的長度是8字節，因此這個值最小是8。
• 校驗和：這個16位字段能夠校驗數據在傳輸過程當中是否損壞。校驗和是對二進制數據串執行特殊計算而獲得的結果。對於UDP來講，校驗和是基於僞報頭、UDP報頭、UDP數據和填充的0而計算的。源計算機生成校驗和，目的計算機對它進行檢驗，讓客戶端用程序可以判斷數據報是否完整。

因爲實際的UDP報頭並不包含源IP地址或目標IP地址，數據報可能會被傳輸到錯誤的計算機或服務。校驗和使用部分數據來自於從IP報頭（被稱爲僞報頭）提取的值，這個僞報頭包含了目的IP地址信息，讓接收段計算機可以判斷UDP數據報是否被錯誤支付。

防火牆和端口

防火牆是一個系統，保護局域網不被來自Internet的未受權用戶攻擊。「防火牆」的基本特性就是阻斷對特定TCP和UDP端口的訪問。實際上，「防火牆」一詞有時具備動詞特性，表示關閉對端口的訪問。

例如，爲了發起與服務器的安全Shell（SSH）會話，客戶端計算機必須向SSH的熟知端（TCP22）發起一個請求。若是擔憂外部入侵者會經過SSH訪問咱們的服務器，一種方法是配置服務器來中止使用端口22。這樣一來，服務器就關閉了SSH的應用，但也禁止了局域網中的合法用戶使用SSH來完成正常操做。

另外一種方法是安裝防火牆，而且配置防火牆來阻斷對TCP端口22的訪問，這樣作的結果是，局域網中的用戶可以在防火牆以內自由地訪問服務器上的TCP端口22，而局域網以外的網絡用戶就不能訪問服務器的TCP端口22，也就不能經過SSH訪問服務器了。事實上，這時Internet上的用戶不能經過SSH訪問局域網中的任何計算機。

場景中使用SSH的TCP端口22做爲示例。防火牆一般會阻斷可能產生安全威脅的任何或所有端口。網絡管理員通常會阻斷對所有端口的訪問，除了必須的端口，好比處理E-mail的端口。在鏈接Internet的計算機上，好比Web服務器，一般會在外部放置一個防火牆，從而避免對這臺對這臺計算機的訪問致使對局域網的非法訪問

---

2017/4/3 更新

昨晚在騰訊筆試題中又遇到了幾道三次握手的題目，很遺憾沒有作對，現再繼續整理一下TCP通訊過程，如圖所示：

三次握手各個狀態的解釋以下：

1. CLOSED:起始點，在超時或者鏈接關閉時候進入此狀態，這並非一個真正的狀態，而是這個狀態圖假想起點。
2. LISTEN:服務器端等待鏈接的狀態，服務器通過socket，bind，listen函數以後進入此狀態，開始監聽客戶端發過來的鏈接請求。此稱爲應用程序被動打開（等到客戶端鏈接請求）
3. SYN_SEND:第一次握手發生階段，客戶端發起鏈接。客戶端調用connect，發送SYN給服務器端，而後進入SYN_SENT狀態，等待服務器端確認。若是服務器端不能鏈接，則直接進入CLOSED狀態。
4. SYN_RCVD:第二次握手發生階段，跟3對應，服務器端接收到了客戶端的SYN，此時服務器從LISTEN狀態進入SYN_RCVD狀態，同時服務器迴應一個ACK，而後再發送一個SYN即SYN+ACK給客戶端。
5. ESTABLISHED: 第三次握手階段，客戶端接收到服務器端的ACK包以後，也會發送一個ACK確認包，發送以後，客戶端進入ESLABLISHED狀態，代表客戶端這邊已經準備好了。TCP須要兩邊準備好了才能夠進行數據運輸。服務器端接收到客戶端的ACK後會從SYN_RCVD狀態轉移到ESTABLISHED狀態，就能夠進行後面的數據運輸了。因此，ESLABLISHED也能夠說是一個數據傳送狀態。

四次揮手各類狀態的解釋以下：

1. FIN_WAIT_1：第一次揮手。主動關閉的一方終止鏈接時，發送FIN給對方，此時進入到FIN_WAIT1狀態，而後等待對方返回ACK。
2. CLOSE_WAIT：接收到FIN以後，被動關閉的一方進入此狀態。具體動做是接收到FIN後，發送ACK。之因此叫CLOSE_WAIT能夠理解爲被動關閉的一方此時正在等待
3. FIN_WAIT_2：接收到被動方發出的ACK時，進入該狀態
4. LAST_ACK:被動方發起關閉請求，由狀態2進入該狀態，具體動做是發送FIN給主動關閉請求的一方
5. CLOSEING:表示你發送FIN報文後，並無收到對方的ACK報文，反而收到了對方的FIN報文。這種狀況主要出如今雙方几乎同時close一個socket，那麼就出現了雙方同時發送FIN報文的狀況。
6. TIME_WAIT:共有三個狀態會進入該狀態
   • 由CLOSEING進入：客戶端發起關閉請求，發送FIN以後等待服務器迴應ACK，但此時服務器端同時也發起關閉請求，也發送了FIN，且客戶端先收到FIN，後接收到ACK
   • 由FIN_WAIT_1進入：發起關閉後，發送了FIN，等待ACK的時候，正好服務器端發起請求，發送了FIN，這時客戶端接收到了先前的ACK，也收到了對方的FIN，而後發送ACK，與CLOSEING進入的狀態不一樣的是接收到FIN和ACK的前後順序，先收到ACK，後收到FIN
   • 由FIN_WAIT_2進入：這是與上面兩種狀態不一樣的狀況，主動方在完成自身發起的主動關閉請求後，接收到了對方發送過來的FIN，而後迴應ACK

相關問題

爲何TIME_WAIT狀態還須要等2MSL後才能返回到CLOSED狀態？

答：這是由於：雖然對方贊成關閉鏈接了，並且握手的4個報文也都協調和發送完畢，按理說能夠直接回到CLOSED狀態；可是由於咱們必須假想網絡是不可靠的，你沒法保證最後發送的ACK報文會必定被對方收到，所以對方處於LAST_ACK狀態下的socket可能會由於超時未收到ACK報文，而重發FIN報文，這個TIME_WAIT的做用就是用來重發可能丟失的ACK報文

爲何要有TIME_WAIT狀態？

答：

1. 防止上一次鏈接中的包，迷路從新出現，影響新鏈接（通過2msl，上一次鏈接中全部的重複包都會消失）
2. 可靠的關閉TCP鏈接。在主動關閉後發送最後一個ACK，有可能丟失，這時被動方會從新發FIN，若是這時主動方處於CLOSED狀態，就會響應rst而不是ack。因此主動方要處於TIME_WAIT狀態，而不能是CLOSED。

參考連接：
TCP三次握手和Time-Wait狀態
什麼是2MSL
TCP的三次握手以及TCP狀態轉換圖詳解
TCP狀態轉換圖詳解