前言

傳輸層是面向通訊部分的最頂層，是面向應用的最底層。面向通訊部分，距離傳輸層最近的網路層，因此本文會將傳輸層與網路層在必要時候進行對比。

傳輸層作用：

網路層提供的是主機之間的邏輯通訊，而傳輸層提供的是通訊雙方的程序之間的邏輯通訊。傳輸層為應用遮蔽了底層複雜的網路通訊邏輯，簡單易用。

如上圖所示，網路層提供主機之間的通訊，傳輸層提供程序間的通訊，有埠標誌通訊的目標進行。

差錯檢測：

網路層的檢錯檢測只是對網路層的首部進行檢驗是否出差錯，不檢驗資料部分。運輸層需要對報文進行差錯檢測。

傳輸層主要協議：

傳輸層主要的協議分別：1、UDP協議；2、TCP協議。兩個通訊端之間傳輸資料的單位叫做：傳輸協議資料單元。在UDP中為：UDP使用者資料包、在TCP中為TCP報文段。

1：UDP是無連線的通訊協議，因此沒有連線管理，在一些場景下非常高效，實時性要求高的場景下使用UDP協議，並且可以自行實現一些可靠傳輸邏輯實現可靠傳輸。UDP支援廣播與多播。UDP特點如下：面向無連線的，盡最大努力交付，面向報文的，UDP沒有擁塞控制，UDP支援一對一，一對多以及多多對的互動通訊，UDP首部開銷很小。雖然UDP沒有擁塞控制，但是當很多主機向網路傳送高速率的視訊流時，網路就可能傳送擁塞，導致大家都無法正常接收，因此不適用擁塞控制的UDP可能會發生嚴重的擁塞問題。UDP首部結構圖：

2：TCP是面向連線的服務，在傳輸資料之前必須建立連線，通訊完畢釋放連線，TCP不提供廣播與多播服務；由於TCP提供可靠的，面向連線的傳輸服務，因此需要增加許多開銷，例如：確認、流量控制、計時器以及連線管理等。使用確認與重傳機制就可以在不可靠的網路通道實現可靠傳輸。

備註：

當運輸層採用的是TCP協議時候，儘管下面的網路是不可靠的，但是會盡最大努力交付，這種邏輯通訊通道就是一條全雙工的可靠通道。當傳輸層使用UDP時候，下面是一條不可靠的通道。

TCP可靠傳輸原理

TCP下面的網路所提供的傳輸是不可靠的，因此為了提供可靠傳輸就需要採取措施保證可靠傳輸。理想的傳輸條件兩個：

1、傳輸通道不會產生差錯；

2、不管傳送方以多快的速度傳送資料，接收方總是來得及接受並處理資料。

但是實際上，網路無法滿足理想的傳輸條件，因此就需要使用可靠傳輸協議：當接收方遇見差錯資料時，讓傳送方重新發送這些出錯的資料；同時當接收方無法及時處理髮送方傳送資料時候，及時告訴傳送方降低傳送資料的速度。這樣不可靠的通道就可以實現可靠傳輸了。

停止等待協議：

停止等待協議就是每傳送一個分組就停止傳送，等待對方確認。在等待收到對方的確認之後再發下一個資料包。

TCP傳輸資料時，無差錯情況下存在如下兩種情況，分別是確認正常收到與確認丟失，如下所示：

當接收到端發出去的確認丟失時候，傳送端的計時器會啟動超時重傳，再一次傳送該資料包。

TCP傳輸資料時，傳送資料包出差錯情況下存在如下兩種情況，分別是接收到收到一個損壞的資料包，另一種是資料包丟失。兩種處理情況分別如下：

當收到一個損壞的資料包時候，接收方會丟棄什麼也不做，等待發送端超時重傳。另一種情況就是資料包丟失，此時也是觸發超時重傳。

TCP傳輸資料時，確認資料包的遲到丟失，傳送方的處理如下兩種。

如果接收方的確認資料包丟失的話，客戶端會觸發超時重傳機制，傳送方再次傳送該資料包，接收到重複接收到該資料包直接丟棄，並再次傳送該資料包的確認。如果接收到接收到資料之後傳送的確認遲到了，此時客戶端會觸發超時重傳，並且接收方再次傳送報文，接收方發現重複丟失，直接丟失並且向傳送方傳送確認。當傳送端接收到遲到的確認之後，會直接丟失什麼也不做。過程如上圖所示。

停止等待協議需要注意如下三點：

a：傳送方傳送一個分組之後必須保留已經發送的分組，在超時重傳時候使用，當收到確認時候可以丟失該資料包。

b：分組與確認分組進行編號，這樣才能明確傳送的資料包與確認資料包的對應關係。

c：傳送端超時重傳的時間設定，通常應該比分組傳輸的平均往返時間設定更長一些。設定的時間過長的話，通訊的效率就會很低，但是如果設定的時間過短的話，就會導致大量的不必要的重傳。超時重傳的時間設定還需要結合當時網路的擁塞程度設定。

但是停止等待協議也存在缺點：就是通道利用率太低，如下圖所示：

為了提高通道利用率，傳送方可以不適用低效率的停止等待協議，而是採用流水線傳輸。流水線傳輸就是傳送方連續傳送多個分組，不必沒法玩一個分組就停止等待確認。這樣就可以保證通道上一直有資料在傳送。顯然這種方式可以提高通道的利用率。

當使用流水線傳輸時，就需要使用下面的連續ARQ協議與滑動視窗協議。

連續ARQ（Automatic Repeat reQuest）協議：指傳送方維持著一個一定大小的傳送視窗，位於傳送視窗內的所有分組都可連續傳送出去，而中途不需要等待對方的確認。這樣通道的利用率就提高了。而傳送方每收到一個確認就把傳送視窗向前滑動一個分組的位置。

連續ARQ協議規定，傳送方沒接受到一個確認，就會把傳送視窗向前滑動一個分組的位置。接收方一般採用積累確認的方式，也就是說接收方不必對接收到的分組逐個傳送確認，對於按序到達的最後一個分組傳送確認即可（注意：按序到達的分組的最後一個）。這就表示之前的所有的分組都已經正確收到。這樣也存在問題：例如傳送方報送的資料包序號分別是：1，2，3，4，5；但是接收到接收到了：1，2，4，5；此時接收端只能對1，2傳送確認（實際是對2傳送確認，表示2之前的資料包都已經正確接收到），這個就叫做：Go-Back-N問題。表示需要回退重發已經發過的N個分組，可見，當網路環境比較差的時候，自動ARQ會帶來負面影響。

而滑動視窗協議比較複雜，是TCP協議精髓所在。

超時重傳時間的選擇

上面已經提過，當在指定的時間沒有收到資料包的確認時候就需要觸發超時重傳以達到可靠傳輸，但是超時重傳的時間選擇是一個複雜的問題。TCP採用一種自適應演算法，它記錄一個報文段的發出時間，以及收到的確認時間，這兩個時間差則是報文段的往返時間RTT。TCP保留了RTT的一個加權平均往返時間RTTs（又叫做平滑的往返時間）。

TCP的流量控制

一般來說，我們都希望資料傳輸的快一些，但是如果傳送方傳送的過快，接收方就可能來不及接收，這就造成資料的丟失。所謂的流量控制就是讓傳送方的傳送速率不要太快，要讓接收方來得及接收。

當傳送方向接收方傳送資料時候，在建立連線時候接收方會告訴傳送方：“接收方當前的接收視窗大小，即rwnd大小”，因此傳送方的傳送視窗就不能超過接收方的rwnd大小。此處注意：TCP的視窗單位是位元組，不是報文段。在協商rwnd時候容易傳送死鎖，因此需要考慮處理情況，具體如下：傳送方項接收方傳送報文一段時間之後，接受方回饋的rwnd大小為0，此時傳送方的傳送視窗大小則需要調整為0；隨著接收方資料的處理，有了接受的空間，接收方調整rwnd不為0之後，此時接收方需要通知傳送方調整發送視窗並且傳送資料，但是由於通知rwnd不為0的資料包丟失了，此時就會陷入死鎖，即：接收方等待發送方的rwnd不為0的資料包，而接收方等待發送方傳送資料。為了解決這個問題需要如下方案：

為了解決rwnd=0選入死鎖問題，TCP為傳送方設定一個持續計時器，只要傳送方接收到rwnd=0時候，就啟動該計時器，每當計時器超時的時候便會發送一個探測報文段，而接收方接收到這個探測報文段時候就會將自己當前的rwnd傳送給傳送方，這樣就可以打破死鎖的僵局了。

如何提高TCP的傳輸效率

如何控制TCP傳送報文段的時機決定了TCP的傳輸效率問題，其實就是TCP何時將快取區的資料傳送出去，TCP傳輸效率解決方案：

1、最大報文段長度；

2、應用程序指明發送，即TCP支援推送的方式，PUSH方式；

3、設定一個計時器，當計時器到期則傳送出去。

在TCP實現中廣泛使用的演算法是Nagle，演算法過程如下：

傳送方把應用程序傳送的資料逐個位元組地傳送到TCP緩衝區，則傳送方先將第一個位元組傳送出去，然後把後面到達的位元組快取起來。當傳送方收到對一個數據包的確認之後，再將緩衝區中的所有資料組裝成一個報文段傳送出去，同事繼續快取程序傳來的資料。這種情況只有收到前一個報文段的確認才傳送下一個報文段，這對於網路比較慢時，明顯可以減少網路頻寬的使用，因此Nagle演算法還規定：當到達的資料到達傳送視窗的一半或者達到報文段的最大長度時，就立即報送出去，這樣可以提高網路的吞吐率。

TCP擁塞控制（注意與流量控制的區別：流量控制是接收方來不及處理髮送方的資料，流量控制是端與端的通訊量控制；而擁塞控制是避免大量報文段湧入網路中，導致網路中的路由器或者鏈路過載）。

如何判斷出現了網路擁塞：

隨著網路負載的增大，網路的吞吐率越來越低，這就是出現了網路擁塞。

TCP擁塞控制的一般原理：

在計算機網路中的鏈路容量（即頻寬）、交換節點中的快取以及處理機等都是網路的資源。在某段時間，若對網路中某一資源的需要超過該資源所能提供的可用部分，網路的效能就要變壞。這種情況就是擁塞；網路擁塞的條件關係如下：

網路中許多資源同時呈現不足的時候，網路的效能會明顯變壞，整個網路的效能會隨著輸入符合增大而下降。而所謂的網路擁塞控制就是防止過多的資料注入到網路中，這樣可以避免網路中的路由器或者鏈路不至於過載。

TCP擁塞控制方法：1、慢開始；2、擁塞避免；3、快重傳；4、快恢復。

（1）慢開始

下面討論的擁塞控制也是基於視窗的擁塞控制，為此，傳送方位置一個叫做擁塞視窗cwnd（congestion window）。擁塞視窗的大小取決於網路的擁塞程度，並且動態的變化，傳送方讓自己的傳送視窗等於擁塞視窗。

傳送方控制擁塞視窗的原則是：只要網路沒有出現擁塞，擁塞視窗就可以再增大一些，以便讓更多分組傳送出去，這樣可以提高網路的利用率。但是網路出現擁塞的時候，就要將擁塞視窗減小一些，以減少資料注入網路中，減緩網路擁塞。

慢開始思路如下：

當主機發送資料時候，由於不知道網路的擁塞情況，如果立即將大量資料注入網路可能會引起網路擁塞；經驗證明，最好的辦法是先探測一下網路情況，即由小到到大逐漸增大發送視窗，也就是說由小到大逐漸增大擁塞視窗數值。

慢開始所謂的慢並不是增長速度慢，而是起步慢，最開始cwnd=1，然後逐漸增長。

擁塞避免演算法思路：讓擁塞視窗cwnd緩慢增大，之前慢開始是2倍增長，此時是每一次進行+1，按照加法增大。

開重傳思路：讓傳送方儘可能早的知道個別報文的丟失；快重傳思路主要是讓接收方不要等待自己傳送資料時候進行捎帶確認，而是立即傳送確認。例如對於報文段m2收到三次重複確認，則傳送方可以確認接收方沒有收到m3,則立即重傳m3，這樣不用等待超時重傳了；這樣可以提高網路吞吐率。

快恢復：當知道只是丟失個別報文，於是不啟動慢開始，而是執行快恢復方法，此時傳送方調整門限值為擁塞視窗值的一半。如下圖4的位置就是丟失個別報文（因為受到3次確認）。

TCP的連線管理

TCP是面向連線的通訊，因此通訊之前需要進行連線的建立，通訊完成之後釋放連線。

TCP建立連線：

為什麼連線需要三次握手，而不是兩次呢？如果兩次的話可能存在伺服器佔用大量連線資源無法得以釋放。具體如下：

例如稀有兩次連線的話，會發生如下情景：

A發起連線，B接收連線，向A傳送一個確認，但是此時，確認丟失，A誤以為連線失敗。但是實際上此時A與B已經成功建立連線。此時由於A沒有感知到連線建立成功，A會繼續發起連線建立的請求，直至連線建立成功。如上過程中，那些沒有收到建立連線的ACK的連線都無法得以釋放，一直佔用伺服器資源。

連線的釋放：

Http權威指南中TCP學習筆記：

參考：計算機網路（第七版）謝希仁、 Http權威指南  David Gourley