計算機網絡系列--運輸層

計算機網絡 – 運輸層

運輸層協議概述

進程之間的通信

1. 什麼是運輸層？

   網絡層是解決主機與主機之間的通信，例如我的手機和你的手機之間的數據連通。但是手機中有微信，qq，王者榮耀，你一邊更新王者榮耀一遍發微信，你的手機同時接收的數據包，怎麼知道這些包是微信的還是王者的呢？這就是運輸層做的事情：提供進程之間的通信。

2. 和網絡層以及應用層的關係？

   運輸層是提供一條進程之間的邏輯線路，讓進程之間去通信，是比網絡層更上層的協議。在路由轉發中只涉及到網絡層。同時運輸層也是用戶感知的最底層，他是直接和應用層進行連接。

運輸層兩個重要協議

1. 概述

   兩個比較重要的協議。但是要注意和網絡層的協議區分開。這裏的協議指的是端對端的，是應用和主機端口之間的通信協議，而不是在路由轉發中的協議。

2. UDP

   用戶數據報協議。無連接而且不可靠，因爲受到數據報不需要回復。但是優點是開銷小。

3. TCP

   傳輸控制協議。面向連接且可靠的，但是缺點是開銷比較大。而且連接的特性決定了不能進行廣播和多播。

運輸層的端口

1. 什麼是端口？

   這個其實很好理解。因爲運輸層是應用程序和主機之間的邏輯通信，所以每個應用程序應該有一個標識，就像IP地址一樣，不然怎麼知道數據報給哪個應用呢。所以主機拿到數據報，解析一下端口號，例如80，然後就把數據給80這個端口，然後使用這個端口的應用程序就可以拿到數據了。但是有一個點是要注意的：端口是固定的但是應用程序是動態的，所以也就保證了應用程序不斷切換，例如後臺殺死重建啊什麼的，但是依然可以接收到數據。只要使用同一個端口即可。

2. 運輸層端口和鏈路層的端口有什麼區別？

   運輸層的端口是隻有本都意義的，在互聯網上沒有任何意義。而鏈路層的路由器上面的端口是硬件端口，是不同設備之間的連接。而運輸層的端口只是爲了標識應用程序。

3. 兩大類端口

   • 服務端使用的端口：服務端嘛，就是要穩定，不然一直換端口別人就受不了了。所以服務端的端口特點就是穩定，數值也比較少。
   • 客戶端的端口：數值比較大，但是不穩定，所以數量多。

用戶數據報協議UDP

概述

1. UDP有什麼作用：

   UDP十分簡單。我們知道，應用程序把數據報給到傳輸層，而UDP只是吧應用程序給的數據報加個頭部就給網絡層去轉發了。頭部主要是標記源端口和目的端口，以及檢驗正確性。

2. UDP的特點：

   • 他是不可靠的。因爲只是把數據加個頭就發過去，也沒有錯誤重發什麼的。所以只是儘量交付，而不是可靠交付。
   • UDP是無連接的。這個從他的工作原理可以看出來。
   • UDP是面向報文的。UDP主要就是處理報文然後給網絡層去轉發。
   • UDP沒有擁塞控制。因爲沒有重發，也就不需要擁塞控制了。

   但是

   • UDP開銷比較小。因爲沒有花裏胡哨的工作。
   • UDP的速度比較快，不用去創建連接直接就可以用了。
   • UDP支持一對多或者多對多。

UDP頭部

1. 組成：三部分：源端口目的端口，長度和校驗碼
2. 僞頭部：用於創建檢驗碼用的，僞頭部主要是源IP地址，目的IP地址，協議字段值以及UDP的長度。

傳輸控制協議TCP概述

什麼是TCP

這裏只簡單講一下關於TCP的一些特點，具體的實現原理後面還有好多好多節去學習。簡單來說，TCP是一個運輸層的協議，他是面向連接的，和UDP不一樣。TCP是建立一個連接，然後源源不斷地發送數據過去。要注意的是這個連接是虛擬的，不是真實的物理連接。

TCP的特點

1. 他是面向連接的
2. 他是點對點的，不能一對多或者多對多等
3. 他可以提供可靠交付
4. 提供全雙工通信（兩邊都可以互發信息）
5. 面向字節流

什麼是面向字節流

這個是TCP工作原理的重點，雖然不難，但是一定要懂。

TCP不是像UDP那樣從用戶那裏拿數據報然後一個個發送，TCP是把這些數據看成流，在緩衝區合成一整塊，然後根據網絡狀況，分割後加上TCP頭部發送。所以說TCP是面向字節流的，因爲他沒有數據包的概念，用戶的數據都看成流。這樣的好處是TCP可以根據網絡情況進行恰當地切割，防止擁塞。

TCP的連接

1. TCP不是和UDP一樣用端口作爲點對象，而是使用socket也就是套接字爲端點。套接字是什麼？這個也很好理解，就是 IP+端口號。這個就可以唯一標識一個TCP連接了。
2. TCP的連接是由軟件所提供的一種抽象，不是真正真正真正的連接。

可靠傳輸的工作原理

怎樣纔是可靠的？

前面講到TCP是可靠的，但是爲什麼TCP是可靠的？原理是什麼？這一小節就比較詳細地展開。這裏要講一個點，都說可靠可靠，那到底滿足什麼樣的條件纔是可靠的？

1. 在網絡傳輸的過程中不會出現數據的損壞或者丟失。
2. 無論發送方用怎麼樣的速率去傳輸，接收方始終可以一直接受。

滿足上述兩個條件就可以實現可靠運輸了。但是這兩個條件和讓你拿着一把刀去搶劫銀行一樣，看似好像很微妙，事實上就是喫太多作業太少成天幻想。所以我們要做的就是如何用協議去實現這樣的特性，把不可靠的網絡環境，實現可靠的數據傳輸。

停止等待協議

是什麼？

1. TCP對應用程序來的數據緩存後進行切割後，分成一個個數據報進行轉發，每一個數據報轉發給對方後就停下來，對方收到後就發送ACK告訴自己收到了，這個時候就可以發送第二個了。
2. 如果發送的數據損壞了，或者數據在傳輸的時候人間蒸發了，這個時候對方什麼也不做。自己就會等，等到一點時間沒回復再繼續發送一次，這就是超時重傳。
3. 如果對方給自己的確認ACK丟失或者遲到了了怎麼辦？自己還是按照超時重傳再發一份，如果收到重複的數據就丟棄就行。對方收到重複的數據包也是直接丟棄。
4. 當網絡情況不好的時候，那麼就會一直重發，達到一定的次數就說明當前網絡不可用，停止發送。

自動重傳請求：上述步驟自動完成就是ARQ自動重傳請求。ARQ實現了在不可靠的網絡上進行可靠的數據傳輸。

缺點

信道利用率很低。每次都要等，特別是網絡狀況不好的時候，效率會變得極低。

連續ARQ協議

爲什麼有這個協議？

我們可以發現就是前面的停止等待協議效率太慢了，傻傻的。一個發送出去了，沒收到回覆就是什麼都不做，乾等，所以我們可以改善這個情況。這裏就要引入一個概念：流水線傳輸。不斷地一個個發送，不用去等待回覆後纔可以繼續發送。

如何實現

1. 在上文的停止等待協議的基礎上，不進行等待，不斷地進行發送，用一個滑動窗口來記錄。當收到對方的ACK的時候就把窗口往前移動一點。例如有123456789 共九個包，現在發送了1234，這個時候窗口就是1234，這個時候收到了數據包1 的ACK，那麼窗口就變成234，以此類推。
2. 接收方主要是採用累積確認的方式，只發送按序的最後一個確認。例如現在發了12345共五個包過去，然後第4個炸了，那麼接受方只返回到第三的ACK，而45就會進行超時重傳。好處是不用一直髮送確認ACK，缺點是沒辦法實時監控每個包的發送情況。
3. 如果發生錯誤，上文講到會回退到45重傳，這就是G-back-N。接收方只返回按序正確的最後一個ACK，剩下的就等待超時重傳。缺點是當網絡不好的時候就是一個災難，會一直回退，導致效率極低。

TCP可靠傳輸小結

現在我們來小結一下如何實現可靠傳輸。

1. TCP協議通過把用戶要傳輸的數據當成流輸入在緩存區後，按照窗口以及網絡情況等適當切割並標上序號，分別發送。
2. 接收端也有一個緩存區，把接收到的包都放在緩存區中，進行校對。
3. 發送採用連續ARQ協議，不斷髮送，接受方只返回到損壞包前的序號的ACK，發送端要重傳該序號後的所有包。
4. 發送端和接收端都有類似的窗口來記錄傳輸結果，保證所有包都完整送達。按照序號來保證傳輸的可靠傳輸而不是字節。所以TCP都是基於序號而不是字節。
5. 因爲網絡情況的複雜性，所以超時重傳的時間要估算比較合理。

TCP靠着連接，然後把數據分包不斷重傳直到全部完整發送完畢，實現了在不可靠的網絡環境中，進行可靠的數據傳輸。

TCP 報文段的首部格式

頭部各字段的含義

這一小節的內容比較枯燥，而且涉及的概念比較多。有了解過http報文的可能知道頭部有很多的參數，每個參數都有獨特的意義，所以還是要過一遍。然後難懂一點的字段的解釋我會分開講一下。

先上一個圖：

頭部參數	字節數	作用
源端口和目的端口字段	各佔兩字節	端口是運輸層與應用層的服務接口。運輸層的複用和分用功能都要通過端口才能實現。
序號字段	4 字節	TCP 連接中傳送的數據流中的每一個字節都編上一個序號。序號字段的值則指的是本報文段所發送的數據的第一個字節的序號。
確認號字段	4字節	是期望收到對方的下一個報文段的數據的第一個字節的序號。
數據偏移（即首部長度）	4位	指出 TCP 報文段的數據起始處距離 TCP 報文段的起始處有多遠。“數據偏移”的單位是 32 位字（以 4 字節爲計算單位）
保留字段	6位	保留爲今後使用，但目前應置爲 0
緊急 URG	1位	當 URG =1 時，表明緊急指針字段有效。它告訴系統此報文段中有緊急數據，應儘快傳送(相當於高優先級的數據)
確認 ACK	1位	只有當 ACK=1 時確認號字段纔有效。當 ACK = 0 時，確認號無效
推送 PSH (PuSH	1位	接收 TCP 收到 PSH = 1 的報文段，就儘快地交付接收應用進程，而不再等到整個緩存都填滿了後再向上交付。
復位 RST (ReSeT)	1位	當 RST =1 時，表明 TCP 連接中出現嚴重差錯（如由於主機崩潰或其他原因），必須釋放連接，然後再重新建立運輸連接。
同步 SYN	1位	同步 SYN = 1 表示這是一個連接請求或連接接受報文。
終止 FIN (FINish)	1位	用來釋放一個連接。FIN = 1 表明此報文段的發送端的數據已發送完畢，並要求釋放運輸連接
窗口字段	2字節	用來讓對方設置發送窗口的依據，單位爲字節。
檢驗和	2字節	檢驗和字段檢驗的範圍包括首部和數據這兩部分。在計算檢驗和時，要在 TCP 報文段的前面加上 12 字節的僞首部。
緊急指針字段	2字節	指出在本報文段中緊急數據共有多少個字節（緊急數據放在本報文段數據的最前面）
選項字段	長度不定	TCP 最初只規定了一種選項，即最大報文段長度 MSS。MSS 告訴對方 TCP：“我的緩存所能接收的報文段的數據字段的最大長度是 MSS 個字節。”（這裏他的概念是不正確的，MSS說是最大報文段長度，但實際上指的是數據段而不是整個報文段）
填充字段	不定	這是爲了使整個首部長度是 4 字節的整數倍。

選項字段中包含以下其他選項：

選項	作用
窗口擴大選項	佔 3 字節，其中有一個字節表示移位值 S。新的窗口值等於 TCP 首部中的窗口位數增大到 (16 + S)，相當於把窗口值向左移動 S 位後獲得實際的窗口大小
時間戳選項	佔 10 字節，其中最主要的字段時間戳值字段（4 字節）和時間戳回送回答字段（4 字節）

| 選擇確認選項 | 接收方收到了和前面的字節流不連續的兩個字節塊。
如果這些字節的序號都在接收窗口之內，那麼接收方就先收下這些數據，但要把這些信息準確地告訴發送方，使發送方不要再重複發送這些已收到的數據 |

重點難懂字段的解析

序號，確認號，窗口值

這幾個是關係比較大的。首先我們知道tcp報是有序號的，第一個序號是指發送端發送的報文是從哪個開始，確認號是接受端返回給發送端告訴他下一個應該從哪開始。例如發送了1234，那麼序號就是1，確認號就是5。窗口值指的是接收端緩衝區的大小。告訴對方我這裏剩下多少緩衝內存了，你不要發太多我緩衝不下來。這裏序號的單位是字節。每一個字節遍一個序號

選項字段

選項字段的長度是不定的，看要發送什麼數據。根據需要改變長度。

TCP可靠傳輸的實現

上面我們已經講到他的原理，這裏更加詳細地陳述如何實現可靠傳輸。

以字節爲單位的滑動窗口

經過上面原理的講述已經可以大概瞭解這個窗口的實現。可以先跳到前面看一下。這裏說一些重點。

緩存區

• 發送緩存用來暫時存放：
  發送應用程序傳送給發送方 TCP 準備發送的數據；
  TCP 已發送出但尚未收到確認的數據。

• 接收緩存用來暫時存放：
  按序到達的、但尚未被接收應用程序讀取的數據；
  不按序到達的數據。

實現過程

發送端的構造窗口

• 根據 B 給出的窗口值，A 構造出自己的發送窗口。

• 發送窗口表示：在沒有收到 B 的確認的情況下，A 可以連續把窗口內的數據都發送出去。

• 發送窗口裏面的序號表示允許發送的序號。

• 顯然，窗口越大，發送方就可以在收到對方確認之前連續發送更多的數據，因而可能獲得更高的傳輸效率。

過程

發送端

• 應用程序把需要發送的數據放到tcp發送緩存區中

• 發送端會根據接收端的窗口大小不斷髮送包

• 已經確認收到的，窗口後沿會往前走，沒有收到確認就會一直等待，超時重傳，直到收到確認。

• 後沿往前走，窗口前沿也會往前走直到全部發送完成

接收端

• 接收端接收到數據就會放到緩存區中
• 序號連續的表示數據完好，然後窗口後沿往前走，等待數據被應用程序讀取。
• 遇到丟失的數據包，會發送確認讓發送端重新發送。
• 窗口中包含未發送確認但是已經收到的包（也包含尚未接受到的包）

下面看個圖片方便理解

注意的點

• 第一，A 的發送窗口並不總是和 B 的接收窗口一樣大（因爲有一定的時間滯後）。
• 第二，TCP 標準沒有規定對不按序到達的數據應如何處理。通常是先臨時存放在接收窗口中，等到字節流中所缺少的字節收到後，再按序交付上層的應用進程。
• 第三，TCP 要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。
• 接收方可以在合適的時候發送確認，也可以在自己有數據要發送時把確認信息順便捎帶上。
  但請注意兩點：
  • 第一，接收方不應過分推遲發送確認，否則會導致發送方不必要的重傳，這反而浪費了網絡的資源。。
  • 第二，捎帶確認實際上並不經常發生，因爲大多數應用程序很少同時在兩個方向上發送數據。

超時重傳時間的選擇

爲什麼很重要

這個點是前面我們沒有講的但是非常重要的點。因爲這個時間要把握好。如果把握不好會有什麼問題：

• 時間太長：空閒時間太長，效率差
• 時間太短：頻繁重發，浪費資源。

受什麼因素影響

網絡的情況是十分複雜的，所以導致網絡傳輸的情況變得十分複雜，所以這個時間也很難去確定，所以必須採用合適的算法來確定這個時間。

算法：加權平均往返時間

加權平均往返時間RTTs = （1-a）*舊的往返時間+a*新的往返時間

這裏一開始RTT採用第一次測得的往返時間，並以此爲基礎進行計算。這裏的a是一個係數，RFC規定是 0.125.

這樣就可以不斷地更新往返時間，得到網絡的情況，可以更好地確定超時重傳時間。

超時重傳時間RTO算法

RTO = RTTs+4*RTTd

RTTd = (1-b)*舊的RTTd+b*|RTTs-新的樣本RTT|

• RTTd是RTT 的偏差的加權平均值，一般來說第一次取RTT的一半
• b的推薦值是0.25
• 這個算法是根據網絡波動來確定重傳的時間的，如果網絡穩定，則重傳時間就接近往返時間，網絡波動越大，則超時重傳的時間約大

Karn算法

這裏還有一個問題就是：如果重傳了，然後接收到一個ack，那麼這個ack是重傳前的那個包的，還是重傳後這個包的？很難確定對吧。所以這裏就誕生了這個算法。

最初這個算法是直接丟棄重傳包樣本，但是這樣肯定不行的，會讓算法不準確。所以修正後是RTO = y*舊的RTO。這裏的y一般是2.這樣當發生重傳的時候，就會把該樣本的信息記錄下來了。

選擇確認SACK

前面我們講到累積確認的時候講到：當收到錯誤或者漏包的時候，只會發送這個錯誤的包前的確認完好的ack，剩下的都要重傳。例如收到12678。那麼會發送確認號爲3的ack，這樣的話，678也要重傳一次，就浪費資源了。所以我們可以告訴發送端說我已經收到了什麼，只需要把缺的發送給我就行。這個時候就可以用到選擇確認SACK。

上文講頭部字段的時候講到這個選項，他的最大值是40字節。每一個確認的字段，例如上面的12678例子。12段需要一個左邊界1和右邊界2,678需要左邊界6，右邊界8.所以每個要告訴發送端的已經完好的字段都需要兩個邊界：左邊界和右邊界。一個邊界需要4個字節，所以最多隻能告訴接收端4個完好的字段。

TCP可靠傳輸小結

TCP通過滑動窗口以及超時重傳算法來使得發送的數據變得非常可靠，效率也比較高。另外再通過選擇確認SACK進一步加強了性能。這三個是需要掌握的點，特別是超時重傳時間的算法和滑動窗口的原理。

TCP的流量控制

什麼是流量控制？爲什麼要進行流量控制？

流量控制這個很好理解，就是控制管道中傳輸的數據量。控制流量是爲了不讓管道發生擁塞，從而來提高效率。另一方面，如果發送端的速度太快，接收端可能會來不及接受就會導致數據的丟失。

利用滑動窗口來提高效率

前面我們講到tcp頭部有一個窗口值，可以用來記錄接收方還有多少的緩存。tcp主要就是利用這一點來保證有足夠的緩存，而不會無法接收。當接收方的的緩存滿了之後，ack’中的窗口值就是0。當接收方中的緩存多了之後，就會發送一個數據報告知發送端我有內存了，可以發送數據過來了。

這裏有一個問題：如果接收端告知可以發送數據的tcp報丟失了怎麼辦？持續計時器。

當發送端收到窗口值爲0的tcp報的時候，就會開始計時器，計時器時間到了就會發送一個試探報，數據只有一個字節。如果還是緩存滿，就重新開始計算計時器。

提高傳輸效率

相關機制

• 發送的數據長度不能太短也不能太長，參考MSS。
• 按照接收端的要求發送push報文
• 持續計時器到了，就要發送數據報，不能幹等待

糊塗窗口綜合症和Nagle算法

聽起來好高大上，其實很簡單。當緩存區還沒有數據的時候，這個時候收到一個字節是不是就會馬上發出去了？這樣就不符合上面說的效率限制了。然後接收端，如果是滿的，然後應用程序讀取了一個字節，是不是馬上就通知發送端可以發送一個字節的數據了。這樣都是會讓網絡效率降低。所以正確的方法就是：等。等到一定長度後，再進行發送。這也就是Nagle算法。

TCP的擁塞控制

擁塞原理

什麼是擁塞？

什麼是擁塞？爲什麼會發生擁塞？擁塞顧名思義就是像塞車那樣發生了堵塞。通道的能力是一定的，當網球傳輸的壓力逐漸增大的時候，那麼就會發生了堵塞，甚至路由器的緩衝隊列滿了，直接把數據報丟掉。所以這裏會有一個問題：數據傳輸慢了好多，甚至被丟包。然後會發生什麼？超時重傳。然後數據報一直髮送不過去，這邊一直重傳，就形成了惡循環。導致整個網絡癱瘓。所以一定要控制好流量。

這裏的流量控制和上文講滑動窗口的時候那個流量控制有什麼區別？上文講的流量控制是爲了避免數據太快以致於接收端無法及時接受數據。這裏是爲了避免發生擁塞而導致網絡癱瘓。但是都是同樣的手段：流量控制。

導致擁塞的原因有什麼？可以直接提高帶寬解決嗎？

擁塞控制不只是用到流量控制，導致擁塞的原因有：帶寬，路由緩存，處理機處理速度等等非常多的因素。提高某個因素的能力會把瓶頸轉移到其他的地方，所以能做的最重要一個就是控制流量。

擁塞的指標是什麼？怎麼判斷髮生了擁塞？

由於缺少緩存空間而被丟棄的分組的百分數；
平均隊列長度；
超時重傳的分組數；
平均分組時延；
分組時延的標準差，等等

• 開環控制：在網絡執行前進行預估儘量避免
• 閉環控制：實時監控控制

減少擁塞有兩種方案：一種是硬件的能力，這個只能儘量，但是提升空間小，瓶頸大，第二種就是通過算法來減少，也就是tcp要做的。

tcp的擁塞控制方法

首先來看一張圖，這張圖就講了整個tcp控制擁塞的算法：

一共有4個點：慢開始，擁塞避免，快重傳，快恢復。

概述

tcp控制擁塞的算法核心就是動態窗口。上面我們講到，發送端可以發送的最多數據報是根據接收端的緩衝區以及自身的緩衝區大小決定，但是我們不能任他無限大發送。如果每個鏈接都發送50g的數據豈不是得炸掉。所以這裏增加了一個擁塞窗口，控制可以發送的數據數量，控制流量。

因爲動態窗口需要根據情況實時調整，所以，必須得到及時的反饋，所以接收端收到數據報的時候，需要迅速把確認發送給發送端。

快重傳

這個算法要求當接收端發現缺少包的時候要及時反映給發送端。例如發送了1，2但是3丟了，此時繼續發送4，5，6，那麼接收端就要返回三個重複確認，3還沒來就發4,5,6肯定是你的3丟了，趕緊重發。然後接受端收到三個重複的，就趕緊補發3過去。

慢開始

這裏的慢開始就是一開始的窗口值要小，不能太大，然後去試探擁塞的底線。這裏一般的起點是一般是發送端一個數據報可以發送的最大長度的1~2倍。然後每一個輪次，也就一個往返，就把窗口值加倍。這裏的往返要注意一下，是要整個窗口中的數據全部往返一次，纔算是一個輪次。例如窗口的大小是8，那麼需要8的數據報都收到ack纔算是一個輪次結束。

擁塞避免

這裏有一個界限，如果一直增大下去那豈不是就指數爆炸了。所以到了一個界限：ssthresh，這個值是自己設定的。之後就是以線性慢慢增長。然後就會出現兩種情況：

1. 發生超時重傳
2. 得到三個重複的ack

首先看第一種情況，如果發生了超時重傳，則說明很可能是發生了擁塞，那麼這個時候就要迅速慢開始，把ssthresh設置當前窗口大小的1/2，然後把窗口壓縮到最初的狀態。重頭開始。第二種情況就是快恢復了。

快恢復

當收到三個重複的ack的時候，只是有可能但是可能性比較小出現了擁塞，所以就把ssthresh設置爲當前窗口的1/2，同時把當前窗口值設置爲何ssthresh一樣大。不用慢開始直接擁塞避免階段。

窗口值上限

這個上限就是前面講到的根據兩端緩存區的大小來確定了。

主動隊列管理AQM

如果發生擁塞，那麼會瞬間讓整個網絡的效率降低到很小的一個值，所以要儘量避免，多一點快恢復。

我們知道路由器的緩衝隊列長度是有限的，當滿了之後接下來的分組都會被丟棄那麼，我們可以在快滿的時候就通知慢點發送，快擁塞了。管理好這個隊列，而不能等到發生事故了在進行處理。這就是主動隊列管理。

TCP的運輸連接管理

tcp是面向連接的，所以就涉及到連接的建立釋放。那麼連接就有狀態，就涉及到有限狀態機。也就是以下三個：

連接建立

這個有個很重要的概念：三次握手。

他們建立的過程類似這樣：

• client：我要和你連接
• service：好的，你真的要連接嗎
• client：對，我真的要

然後就連接了。這個過程需要發送三個報文，也稱爲三報文握手。然後互相交換各自的信息例如窗口值 RTT等。相親的互問根底不過是爲了婚姻更幸福的生活不是嗎（此處手動滑稽）

連接釋放

釋放的話會比較麻煩一點，畢竟閃婚容易，離婚就可能和慶兄或者祥哥一樣可愛了。（哦祥哥貌似當時還沒結婚）釋放連接要進行4次握手：

• client：我不要你了我要釋放連接
• service：你真的不要我了嗎，哼，不要就滾
• service：我決定了。釋放連接
• client：好，拜拜。
• client：等待2msl時間後完全釋放連接

最後一個是一個等待時間，避免受到無效的請求。因爲進行了四次握手也成爲四報文握手。（也有叫揮手的，揮手比較好點）這樣就直接釋放連接了。這裏有幾個點要注意：

1. 客戶端請求釋放，受到服務端的確認後並沒有完全釋放連接，而是會等待服務端的下一個回覆才真正斷開。但是，還不是完全斷開，要再等兩個最大報文生存時間，網絡中完全不存在無效報文了再徹底斷開。
2. 另外等待時間也是爲了最後一個報文能到達服務端，萬一服務端反悔了就可以收到對吧，如果沒有等待2msl，就可能下一個tcp連接收到了無效的請求。

有限狀態機

通過上面的講述可以發現tcp連接存在很多的狀態。所以也就有了這個狀態機。給個圖你們感受一下：

總結

這篇文章從什麼是運輸層，運輸層的協議，到重點介紹tcp的工作原理，如何可靠傳輸，tcp報的格式，到更加深入的擁塞原理，流量控制提高傳輸效率，最後講了tcp的連接管理。

tcp是運輸層一個非常重要的協議，除了少部分使用udp，其他基本都是使用tcp，所以要對tcp的原理模清楚。另外要懂得tcp的效率問題以及出錯的擁塞問題連接問題。

運輸層是直接和我們應用層打交道的，所以瞭解清楚運輸層是有必要的。當我們需要建立一些socket連接的時候，就必須對運輸層有一定的瞭解。

好了關於運輸層就大概講這麼多，希望可以給你們有一些幫助。