0. 基本要點

• 運輸層是為相互通信的應用進程提供邏輯通信。
• 端口和套接字的意義
• 什么是無連接UDP
• 什么是面向連接的TCP
• 在不可靠的網絡上實現可靠傳輸的工作原理，停止等待協議和ARQ協議
• TCP的滑動窗口、流量控制、擁塞控制和連接管理

1. 運輸層協議概述

• 為什么需要運輸層？
  通信真正的端點并不是主機而是主機中的進程，IP協議幫助我們將分組數據發送到對應的主機，但是這個分組還是停留在了網絡層，IP協議并不知道需要將分組數據交付給主機中的哪一個應用或者哪一個進程，而運輸層的作用在于，一方面為上層應用層提供進程的端到端通信服務，一方面屏蔽了下面網絡核心的細節，在邏輯上好像兩個進程實體之間存在一條端到端的邏輯通信通道。
• 運輸層的兩個功能：復用和分用

運輸層.PNG

• 運輸層和網絡層的區別：
  1. 網絡層為主機之間提供邏輯通信，運輸層為進程之間提供端到端的邏輯通信
  2. 運輸層還要對報文進行差錯檢測，網絡層只檢驗頭部部分

2. TCP和UDP

• UDP傳輸的是UDP報文段，在傳送數據之前不需要建立連接
• TCP提供面向連接的服務，傳送數據前要建立連接，傳送結束后要釋放連接，TCP 不提供廣播和多播服務，因為TCP要保證可靠的連接，因此增加很多相應的開銷，協議首部會相對較大，同時也占用很多處理機的資源

• 端口：標志本計算機應用層的各個進程與運輸層交互的層間接口，為了找到對方計算機中的應用進程。因為進程在不同的操作系統中的進程標識符是不同的，因此用標識符來識別進程是行不通的。

  1. 服務器使用的端口號：系統端口號:0-1023 登記端口號：1024-49151
     常見端口號：FTP：21， TELNET：23， SMTP：25
     DNS：55，TFTP：69，HTTP：80
     SNMP：161 SMP（trap）：162 ，HTTPS：443

  2. 客戶端使用端口號：短暫端口號 49152-65535

3. UDP協議

• UDP是無連接的，UDP不需要維持復雜的連接狀態表，它盡最大努力交付
• UDP是面向報文的，這里注意：UDP對于應用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界，應用層交給UDP多長的報文，UDP就封裝多長的報文，因此，用戶需要選擇合適的報文長度，否則交給IP層后，過長會導致分片，太短會造成首部相對長度太大，降低IP層的效率。
• UDP沒有擁塞控制，網絡擁塞不會降低源主機的發送效率。在一些實時應用中，如ＩＰ電話允許存在一定程度的丟包，但不允許太大延時。
• UDP支持一對一，一對多，多對多交互通信
• UDP首部開銷小，只有8個字節，每個字段的長度都是兩個字節，源端口+目的端口+長度+校驗和

4. TCP協議

4.1 TCP協議特點

• TCP協議是面向連接的，使用時建立連接，使用完畢釋放連接
• 每個TCP連接只有連個端點，也就是說TCP連接是點對點，一對一的
• TCP提供可靠的交付，無差錯，不丟失，不重復，并且按序到達
• TCP提供全雙工的通信，TCP允許進程任何時候都發送數據，TCP兩端設有發送緩存和接收緩存，TCP會在合適的時候讀取緩存或者將緩存中的數據發送出去。
• TCP面向字節流，注意TCP并不關心進程一次將多少緩存發送到TCP的緩存，UPD發送的報文長度由進程指定，而TCP則是根據對方給的窗口值和當前網絡擁塞情況而決定一個報文段包含多少字節。如果緩存數據塊過長，TCP劃分短一些，過短就積累足夠多的字節構成報文段發送出去。

4.2 套接字

• 套接字是一個抽象的概念：socket = （IP地址：端口號），TCP連接：{套接字}：{套接字}，同一個IP地址可以有多個不同的TCP連接，同一個端口號也可以出現在多個不同的TCP連接中。

4.3 可靠傳輸的工作原理

基本原理：當出現差錯時讓發送方重新傳輸出錯的數據，同時在收方來不及處理數據時，及時告知發送方降低發送速率。

• 停止等待協議（最簡單的協議，實際運輸層并沒有采用）：發送完一個分組后停止發送，等待對方的確認，收到確認后再發送下一個分組，如果收不到對方確認，超時重傳，而產生超時重傳的原因可能是收方的確認丟失了，也可能是發送方發送的分組出錯或者丟失，因此對于收方，對于重傳的分組，假如是已經收到過的分組，此時需要執行丟棄重復分組，向發送方發送確認的動作。對于可能遲到的確認，發送方執行收下丟棄的處理。這種自動重傳的協議我們稱之為ARQ（Automatic Repeat request）協議。
• ARQ協議最大的缺點是信道利用率太低，要一直等待來回往返的確認RTT時間，如果往返時間大于分組發送時間Td，那么信道利用率是非常低的。因此未來提高傳輸效率，采用流水線發送，也就是連續ARQ協議和滑動窗口協議。
• 連續ARQ協議與go-back-N

4.4 TCP報文段首部

TCP頭部.PNG

有幾個比較重要的概念：

• 序號：占4個字節，一個TCP連接中的傳輸的字節流都要按順序編號，比如一個報文字節序號為301，攜帶100個字節數據，那么該報文中第一個字節的序號為301，最后一個字節為400，下一個報文的序號字段值應為401
• 確認號：占4個字節，是期望收到對方下一個報文段的第一個數據字節的序號。比如B正確收到了A發來的501-700的數據，那么B發送給A的確認報文中確認號位701，確認號=N，則表明到序號N-1為止所有數據都正確收到。
• 窗口：窗口值告訴對方從本報文首部確認號算起，接收方目前允許對方發送的數據量，（接收方的緩存是有限的）。B返回給A確認號701，窗口字段為1000，也就是告訴對方，從701開始，我的接收緩存空間還可接收1000個字節數據，你在發送數據時，必須考慮這一點。窗口字段明確指出現在允許對方發送的數據量，窗口值經常在動態變化。
• 選項：最大報文段長度MSS，窗口擴大項，時間戳（可處理**TCP序號超過2^32的情況，防止序號繞回）

5. TCP的可靠傳輸的實現

TCP 滑動窗口協議

以字節為單位的滑動窗口：發送方A的發送窗口，接收方B的接收窗口

• 發送方緩存：發送緩存用于存放準備發送的數據和已經發送但尚未收到確認的數據
• 發送窗口：發送窗口是發送緩存的一部分，已經確認的數據應當從發送緩存中刪除，因此發送緩存和發送窗口的后沿是重合的（注意發送程序需要控制寫入緩存的速率，太快會導致緩存沒有存放數據的空間，因為發送的數據可能還未被確認）
• 接收緩存存放：按序到達但還沒有被應用接收的數據和未按序到達的數據
• 接收窗口：如果收到分組出錯，就要丟棄，如果接收應用程序來不及接收數據，接收緩存會被填滿，接收窗口會被減小為零，如果能夠及時處理，接收窗口就可以增大，接收窗口動態調整，并反饋給發送方，以通知發送方調整發送速率。
• 發送窗口兩個決定因素：1.B的接收窗口作為參考 2.根據網絡擁塞情況適當減小發送窗口數值
• 整個發送過程可以描述為：
  1. A可以將窗口內的數據都發送出去，在此期間不需要收到B的確認情況，凡是沒有得到確認的已發送數據暫時保留，以便超時重傳。
  2. B接收窗口對按序收到的數據的最高序號給出確認，如果B確認收到這些數據，就將接收窗口向前移動，并給A發送確認，A收到確認后，就將發送窗口向前移動。
  3. 如果A一直發送數據，一直到整個發送窗口內的數據發送完畢，也沒有收到B的確認，那么A的發送窗口已滿，則需要停止發送，經過一段時間（超時）重傳這部分數據，直到收到B的確認，就可以向前移動窗口了。
• 超時重傳的時間選擇
  1. 過短，引起不必要的重傳，過長，空閑時間增大，降低效率
  2. 自適應算法，記錄報文段往返時間RTT（報文發出到收到確認之間的時間），通過測量RTT，獲得一個加權平均往返時間RTTs
     新RTTs = （1-α）*舊RTTs + α * 新RTT樣本（α通常為0.125）
     則超時重傳時間RTO為：RTO= RTTs + 4 * RTTd（RTT的偏差加權平均值）
  3. Kam算法：在計算加權平均RTTs的時候，只要報文段重傳了，就不采用其往返時間樣本。

6. TCP的流量控制

注意理解流量控制和擁塞控制的區別

• 流量控制：flow control，讓發送方發送速率不要太快，要讓接收方來得及接收，也就是說是一對一，發送方和接收方的協商
• 流量控制的實現：滑動窗口機制，發送方的接收窗口不能超過接收方的接收窗口，接收方在發送ACK時可向發送方發送rwnd字段，告知接收窗口的大小進行流量控制

流量控制.PNG

• 注意死鎖的產生：B向A發送了零窗口報文后，過一段時間后B有了空間并向A發送rwnd = n的報文段，但是該報文段丟失了，這個時候A在等待B，B也在等待A重新發送數據，導致了互相等待的死鎖局面。解決方法是當TCP連接的一方接到對方的零窗口通知，就啟動持續計時器，如果時間到，就發送一個零窗口探測報文段。
• TCP傳輸效率：控制TCP發送報文段的時機
  1. Nagle算法：Nagle算法就是為了盡可能發送大塊數據，避免網絡中充斥著許多小數據塊。Nagle算法的基本定義是任意時刻，最多只能有一個未被確認的小段。 所謂“小段”，指的是小于MSS尺寸的數據塊，所謂“未被確認”，是指一個數據塊發送出去后，沒有收到對方發送的ACK確認該數據已收到。

  （1）如果包長度達到MSS或者發送窗口大小的一半，則允許發送；
  （2）如果該包含有FIN，則允許發送；
  （3）設置了TCP_NODELAY選項，則允許發送；
  （4）未設置TCP_CORK選項時，若所有發出去的小數據包（包長度小于MSS）均被確認，則允許發送；
  （5）上述條件都未滿足，但發生了超時（一般為200ms），則立即發送。

  2. 糊涂窗口綜合征（silly window syndrome）

7. TCP的擁塞控制

7.1 擁塞控制與流量控制的區別

• 擁塞產生的原因：對網絡資源的需求大于可用的資源，可能是帶寬不夠，也可能是交換結點的緩存太小，也可能是發送方發送數據過快，而接受方接受數據過慢
• 擁塞控制：擁塞控制是防止過多的數據注入到網絡中，這樣使得網絡中路由器或者鏈路不至于過載，擁塞控制是一個全局性控制，涉及到所有主機、所有路由器以及降低網絡傳輸性能有關的因素，相對于流量控制，流量控制是點對點通信量的控制，是一個端到端的問題，抑制發送端發送速率，以便接收端來得及接收。
• 擁塞控制容易與流量控制搞混，實際上某些擁塞控制就是通過向發送端報告網絡情況，減緩發送速率來實現擁塞的控制
• 擁塞控制由開環控制和閉環控制兩種方法：
  1. 開環：設計網絡時充分考慮有關擁塞情況，力求網絡工作時不發送擁塞
  2. 閉環：檢測系統網絡以便檢測擁塞在何處發生何時發生，然后根據擁塞產生的信息來調整網絡運行狀態，調整狀態的操作如增大網絡某些可用資源，或減少用戶對某些資源的額需求等，調整過程也是一個動態變化的過程

7.2 TCP擁塞控制方法

TCP擁塞控制算法包括：慢開始（Slow-start），擁塞避免（congestion avoidance）,快重傳（fast retransmit）和快恢復（fast recovery）,這四個算法是配合起來使用的，以實現擁塞控制，當然這里的擁塞控制本質上是流量控制

擁塞控制.PNG

• 判斷網絡擁塞的依據：出現超時

• 慢開始：當主機開始發送數據時，并不清楚網絡的負載情況，如果將大量字節注入網絡，有可能引起網絡擁塞，那么可以先探測一下，由小到大逐漸增大擁塞窗口數值，也就是逐漸增大發送窗口。初始擁塞窗口cwnd設置不超過2-4個SMSS（sender maximum segement size）

  1. 慢開始規定，每收到一個對新的報文段的確認后，就可以將擁塞窗口增加最多一個SMSS數值，也就是每次增加量 = min（N,SMSS），N是原先未確認，但是現在剛收到確認的字節數
  2. 如圖所示，每經過一個傳輸輪次，擁塞窗口cwnd就加倍，（傳輸輪次是指往返時間RTT，就是將發送窗口中所有數據都發送出去了，并且發送方收到了對該窗口中最后一個字節的確認的這樣一個輪次）
  3. 慢開始的慢在于TCP剛開始發送時是一個試探性發送的狀態，其窗口cwnd的增長速率并不慢，是呈指數增長的。

• 擁塞避免：因為慢開始的增長速率很快，cwnd很快就變得很大，如果增長過快就會產生網絡擁塞，所以需要一個慢開始門限。在cwnd達到門限之后，采用擁塞避免算法，使得cwnd緩慢線性增長。

  1. cwnd<ssthresh,使用慢開始算法，cwnd>ssthresh,使用擁塞避免，cwnd = ssthresh，兩者皆可
  2. 擁塞避免每經過一個RTT時間，將cwnd加1，也就是加法增大，線性規律增長；
  3. 如果當達到某一窗口大小，產生超時，發送方判斷為擁塞產生，則**調整門限值ssthresh = cwnd（當前值）/2, cwnd = 1(調整為1，進入慢開始）

• 快重傳：目的是當網絡沒有產生擁塞，但是出現個別報文段丟失，為了避免發送方認為超時進入慢開始狀態，應盡快在超時的限制時間內讓發送方盡早知道有個別報文段產生了丟失，以盡快進行重傳，這樣就不會產生超時，不會被默認為存在網絡擁塞。

  1. 快重傳算法要求立即確認，要求接受方不使用捎帶確認，而是即使收到了失序報文段也要立即發出對已收到報文段的額重復確認。
  2. 算法規定，只要連續收到3個重復確認，就知道是哪一段對方沒有收到，應道立即進行重傳

• 快恢復：承接快重傳，發送方知道已經丟失了個別報文段，執行快回復算法，調整門限ssthresh = cwnd /2,設置cwnd = ssthresh，并開始執行擁塞避免算法，也有將ssthresh = cwnd/2 +3

  TCP擁塞控制流程圖.PNG

• 注意：發送方窗口是由網絡擁塞情況和對方的接收窗口共同決定的
  發送窗口上限值 = Min{rwnd，cwnd}

• 主動隊列管理：AQM（active queue management），路由器內部隊列采用先入先出規則，如果隊列已滿，會丟棄再到達的分組，如果被動的隊滿丟棄，容易影響很多TCP連接，導致全局同步，全局通信量下降，所以采用主動隊列管理，當網絡擁塞出現某些征兆的時候，主動丟棄某些分組，隨機早期檢測就是當隊列平均隊列長度達到一定值時，按照某種概率丟棄個別分組，這樣讓擁塞控制只在某些TCP連接上出現。

8. TCP連接建立，數據傳輸和連接釋放

• TCP采用C/S模型，主動發起連接的是客戶，等待連接的是服務器

三報文握手.PNG

• A和B都各自選擇初始序列號 x，y
• SYN = 1 即SYN報文段不能攜帶數據，但要消耗一個序號
• ACK報文段可以攜帶數據，如果不攜帶數據就不消耗序號
• 為什么A最后還要再發送一個ACK？是為了防止已經失效的連接報文請求突然傳送到B，因而產生錯誤

TCP連接釋放.PNG

• B結束TCP連接的時間要早于A
• 當A處于FIN-WAIT-2狀態時，TCP處于半關閉狀態，也就是說這個時候A已經不需要發送數據給B了，但是如果B有數據想要發送，A仍然需要接收
• A接收到B釋放連接報文并返回ACK后處于TIME-WAIT狀態，還要等待2MSL才可以釋放連接
  1. 實現終止TCP全雙工連接的可靠性：假設最后的ACK丟失，服務器會重發FIN，因此客戶端需要維護狀態信息以允許重發最終的ACK（對于主動斷開連接的服務器是同樣的道理）保證A發送的最后一個ACK報文段能夠到達B
  2. 保證老的重復分節在網絡消失：保證來自先前連接的老的重復分組已經消失，2MSL（maximum segment lifetime 最長分節生命）時間足夠讓某個方向上的分組丟棄