image.png

傳輸層處于一個關鍵位置，向上為應用層服務，是用戶功能中的最底層，向下處于通信部分的最高層。由于網(wǎng)絡層協(xié)議不可靠，傳輸層需要提供一個可靠的協(xié)議保證應用程序之間的信息傳遞。

（一）服務

image.png

如上圖所示，傳輸層提供以下服務：

• 端到端的通信：網(wǎng)絡層提供的是主機之間的邏輯通信，而傳輸層提供應用進程之間的邏輯通信；
  - 1.在主機中使用端口標識不同的應用進程，應用進程通過端口將報文傳給傳輸層；
  - 2.采用套接字的方式標識同一臺主機中的不同應用進程，套接字=（主機IP地址，端口號）。
• 復用與分用：不同的應用程序都可以使用同一個傳輸層協(xié)議傳輸數(shù)據(jù)，接收方的傳輸層在收到剝?nèi)笪氖撞亢竽軌虬堰@些數(shù)據(jù)交給正確的進程；
• 差錯檢查：對收到的報文進行差錯檢測；
• 提供兩種不同協(xié)議：面向連接的TCP和無連接的UDP。

（二）UDP協(xié)議

UDP協(xié)議是無連接協(xié)議，它很簡潔，只包括兩個基本服務：復用與分用和差錯控制。它有以下4個優(yōu)點：

• 不用建立連接：由于傳輸前不用建立連接，因此時延短，速度快；
• 無連接狀態(tài)：不用保持連接狀態(tài)，也不需要跟蹤一些參數(shù)，因此可以支持更多活動客戶機；
• 分組首部開銷小：首部僅8B的開銷；
• 應用層能更好地控制要發(fā)送的數(shù)據(jù)和時間：UDP報文可以隨時發(fā)送，不需要考慮擁塞控制，更加靈活。

1.UDP報文格式

image.png

（三）TCP協(xié)議

TCP協(xié)議是有連接協(xié)議，相比UDP協(xié)議，它需要提供更多功能，它有以下幾個特點：

• 面向連接：傳輸前先建立連接；
• 點對點：每條TCP連接只能有兩個端點；
• 可靠的交付：保證傳送的數(shù)據(jù)無差錯、不丟失、不重復且有序；
• 全雙工通信：為了能讓通信雙方的應用進程在任何時候都能發(fā)送數(shù)據(jù)，連接的兩端都設有緩存區(qū)域存放臨時數(shù)據(jù)；
• 面向字節(jié)流：TCP把應用程序交給的數(shù)據(jù)視為一連串無結構的字節(jié)流。

1. TCP報文段

image.png

2. TCP連接管理

兩個端點使用TCP協(xié)議時，要經(jīng)歷三個階段：建立連接、數(shù)據(jù)傳送和連接釋放。這有點類似于兩個人打電話，先撥號，再聊天，最后掛斷電話。但是TCP協(xié)議在建立連接和釋放連接時，稍微有些復雜，因為它要解決三個問題：

• 接收雙方都知道對方的存在；
• 約定一些參數(shù)，方便數(shù)據(jù)傳遞；
• 可以對數(shù)據(jù)資源進行分配。

2.1 建立連接

TCP建立連續(xù)協(xié)議需要“三次握手”才能相互確認對方的存在。

image.png

image.png

2.2 連接釋放

如果需要斷開兩個進程之間的連接，則需要“四次揮手”。

image.png

TCP連接建立和釋放的總結：

image.png

3. 可靠傳輸

TCP協(xié)議將數(shù)據(jù)以字節(jié)流的方式在發(fā)送端與接收端之間傳輸，要對每個字節(jié)進行編號，方便接收端向發(fā)送端確認信息，如果接收端收到的字節(jié)流不連續(xù)，那么它將會計算出丟失的字節(jié)序號，反饋給發(fā)送端，讓發(fā)送端重傳。

3.1 序號

發(fā)送端現(xiàn)在緩存區(qū)中，將字節(jié)流從0開始編號，然后再分組組成多個報文依次發(fā)送。如下圖：第一個報文的序號是0，第二個報文的序號是3。

image.png

3.2 確認

TCP報文中的確認字段用于發(fā)送端與接收端之間確認報文信息。根據(jù)上圖，如果A、B兩個進程之間進行信息傳遞，當B收到第一個報文段，那么他將會向A發(fā)送字段為3的確認號，也就是說，確認號是期望收到對方的下一個報文段的數(shù)據(jù)的第一個字節(jié)的序號。

3.3 重傳

根據(jù)不同情況將重傳分為兩類：超時和冗余ACK。

3.1 超時

B每接收到一個報文段都會向A發(fā)送確認信息，但是如果A在一定時間內(nèi)接收不到B的確認信息，那么就要重傳這一報文段。
由于互聯(lián)網(wǎng)網(wǎng)絡情況變化很大，A等待的時間不能記為固定值，這樣會導致傳輸速率低效，需要自適應算法，將一個報文發(fā)出的時間，以及收到相應確認的時間作差，結果記為往返時間RTT，多次記錄RTT并進行加權平均計算：

image.png

第一次重傳時間根據(jù)加權平均RTT計算：

image.png

之后使用下面方式計算：

image.png

3.2 冗余ACK

如果A向B發(fā)送1，2，3，4，5個報文段，但是第2個報文段丟失，B接收到1，3，4，5個報文段，于是B向A發(fā)送3個對1號報文段的冗余ACK。當A收到對1號報文段的3個冗余ACK時，就立即執(zhí)行重傳。
也就是說，每當接收方接收到比期望序號大的失序報文段到達時，就發(fā)送一個冗余ACK，指明下一個期望字段的序號。

4. 流量控制

發(fā)送方與接收方兩端都設有緩存區(qū)，但如果發(fā)送法的發(fā)送速度與接收方處理數(shù)據(jù)速度不一致的話，緩存區(qū)將有溢出的可能，因此使用流量控制防止數(shù)據(jù)溢出。

在流量控制方面，接收方要隨時告訴發(fā)送方能夠接受多少字段，方便發(fā)送方調(diào)整報文段長度，保證接收方的緩存區(qū)不會溢出。

image.png

5. 擁塞控制

為防止過多數(shù)據(jù)注入網(wǎng)絡造成網(wǎng)絡堵塞，因此用擁塞控制發(fā)送方發(fā)送速率。
雖然流量控制與擁塞控制都是控制發(fā)送方發(fā)送數(shù)據(jù)的速率，但是擁塞控制從全局角度著眼，涉及所有的主機、路由器，而流量控制只是在兩個端點之間進行數(shù)據(jù)傳輸量的控制。

因此擁塞控制中，要求發(fā)送方維護兩個窗口：接收窗口和擁塞窗口。

• 接收窗口（rwnd）：接收端根據(jù)自己接收緩存大小，將最新窗口值反饋給發(fā)送端；
• 擁塞窗口（cwnd）：發(fā)送方根據(jù)自己估算的網(wǎng)絡擁塞程度設置窗口值。

因此發(fā)送窗口的取值為：發(fā)送窗口的上限值=min[rwnd, cwnd]

5.1 慢開始和擁塞避免

發(fā)送方采用慢開始算法與擁塞避免算法相結合發(fā)送數(shù)據(jù)。

• 慢開始：在開始發(fā)送TCP報文段時，將cwnd=1，也就最大報文段長度MSS，每當收到一個對新報文段的確認后，cwnd+=MSS，使cwnd逐步增大。
• 擁塞避免：發(fā)送端每經(jīng)過一個RTT就增加一個MSS大小，也就是cwnd+=1，使cwnd放慢增長速度，如果出現(xiàn)網(wǎng)絡擁塞，那么則從慢開始門限（ssthresh）開始，另ssthresh=cwnd/2；

image.png

image.png

5.2 快重傳和快恢復

• 快重傳：快重傳使用冗余ACK來實現(xiàn)。

• 快恢復：當遇到擁塞時，另ssthresh=cwnd/2

  
  
  image.png