前言：適逢期中考。。。。
本文參考自很多文章、課本、PPT等（其實仔細觀察你會發現很多文字甚至圖片都是一致的），如有雷同，純屬不巧合（抱拳）

三、運輸層

3.1 概述和運輸層服務

3.1.1 運輸層和網路層的關係

• 網路層提供了 主機 之間的邏輯通訊。而運輸層為執行在 不同主機上的程序 提供邏輯通訊。
• 運輸層協議只工作在端系統上。
• 運輸協議能提供的服務受制於底層網路協議的服務模型。
• 網路層協議，即 IP 協議，其服務模型是 盡力而為交付服務 ，但不做任何的保證。是 不可靠服務 。
• 參照書上以東西海岸兩個家庭互相寫信的經典例子
  
  • 程序 = 堂兄弟姐妹
  • 主機 = 家庭
  • 運輸層協議 = Ann 和 Bill（孩子裡收信發信的大哥大姐），分發到兄弟姐妹中，將信從一個人（程序）送到另一個人
  • 網路層協議 = 郵政服務，將信從一個家庭（主機）傳給另一個家庭
  • 運輸層協議只工作在主機（端系統）中 = Ann 和 Bill 只在家工作，將信拿到門口的郵箱
  • 多種運輸層協議，多種服務模型 = Ann 和 Bill 外出，Susan 和 Harvey來收信發信，結果年齡太小，收發郵件次數少，也老丟信
  • 運輸層服務受制於網路層服務 = 郵政大哥若三天來一次，Ann和Bill就不可能兩天收發一次信
  • 運輸層協議能為應用程式提供可靠資料傳輸服務 = 若郵政大哥把信弄髒弄丟弄混，Ann 和 Bill 可以清理整理信件，或者讓對方下次重新發一次
  • 運輸層協議能確保應用程式報文不受入侵讀取 = 儘管郵政大哥可能被別人騙或者強行看了信件，Ann 和 Bill 也能規定加密方式對信的內容進行加解密，弟弟妹妹們只需要看信的內容
  • 多路分解 = Bill 和 Ann從郵遞大哥拿到信件，看收信人名字（埠號），然後分別交到他們手上
  • 多路複用 = Bill 和 Ann從弟弟妹妹手裡拿到信件，幫他們裝填信封寫上資訊

3.1.2 因特網運輸層概述

• UDP 提供了一種不可靠、無連線的服務。
• TCP 提供了一種可靠的、面向連線的服務。
• 程序到程序的資料交付和差錯檢測是兩種最低限度的運輸層服務，也是 UDP 能提供的僅有的兩種服務。

3.2 多路複用與多路分解

• 多路分解： 將運輸層報文段中的資料交付到正確的套接字。
• 多路複用： 在源主機從不同的套接字中收集資料塊，併為每個資料塊封裝上首部資訊從而生成報文段，然後將報文傳遞到網路層。
• 運輸層多路複用要求：
  
  • 套接字有唯一識別符號。
  • 每個報文段有特殊字元（埠號）來指示該報文段所要交付到的套接字。
  • 埠號：一個 16 位元的數，在 0 ~ 65535 之間。其中 0 ~ 1023 是周知埠號，是受限制的。

3.2.1 無連線的多路複用與多路分解

• 一個 UDP 套接字由（目的IP地址，目的埠號）標識。注意是用來標識，不是隻有這兩個相關欄位，還有源埠號、源IP地址欄位。源埠號和目的埠號按傳遞方向反轉
• 通常，應用程式的客戶端讓運輸層自動地分配埠號，而伺服器則分配一個特定的埠號。

3.2.2 面向連線的多路複用與多路分解

TCP 套接字是由一個四元組（源 IP 地址，源埠號，目的 IP 地址，目的埠號）來標識的。

3.3 無連線運輸：UDP

• 選擇 UDP 的原因：
  
  • 關於何時、傳送什麼資料的應用層控制更為精細。
  • 無需連線建立。
  • 無連線狀態。
  • 分組首部開銷小。
  • 用 UDP 建立可靠資料傳輸機制可以在應用層中實現。

3.3.1 UDP 報文結構

首部只有 4 個欄位，每個欄位 2 位元組 16 位。其中，長度指示了 UDP 報文段中的首部加資料的位元組數。

3.3.2 UDP 檢驗和

檢驗和 是 UDP 的差錯檢測機制。其實現方法是：
1. 將 UDP 報文按 16 位元進行分組。
2. 先取前面兩個16位元數字進行加運算，有溢位記得回捲，即溢位位加到最低位再進行加運算
3. 2中得到的數再跟下一個16位元數字進行加運算，直到報文末端
4. 將最終得到的 16 位元的數按位取反即為檢驗和。

• 注：計算之前的檢驗和為 0
• 如果傳輸沒有出錯，則在接收方處計算的的檢驗和將是 11111111111111。若不是，則資料有錯。

3.4 可靠資料傳輸原理

3.4.1 構造可靠資料傳輸協議

• 經完全可靠通道的可靠資料傳輸 rdt1.0
  
  • 有限狀態機
  • 有完全可靠的通道，接收方就不需要提供任何反饋資訊給傳送方
• 經具有位元差錯通道的可靠資料傳輸 rdt2.0
  
  • 自動重傳請求協議（ARQ，又叫停等協議）
  • 處理位元差錯還需三種協議功能：
    
    • 差錯檢測。需要利用額外的位元（組原中海明碼、奇偶校驗碼之類）
    • 接收方反饋。肯定確認ACK（收到了），否定確認NAK（請再傳一遍），接收方沒收到確認就不能傳送（停等協議）
      
      • 考慮ACK、NAK分組受損的可能性，在資料分組中新增新欄位，分組序號0和1（向前取模）
    • 重傳。接收方收到有差錯分組時，傳送方重傳該分組。
• 經具有位元差錯的丟包通道的可靠資料傳輸 rdt3.0（ 位元交替協議）
  
  • 傳送方負責檢測和回覆丟包工作，對每一個分組維護一個定時器。如果在一個時間段內沒收到ACK，則判定為丟包，重傳分組，這也引入了冗餘資料分組的可能性（時延很大的情況）
  • 

3.4.2 流水線可靠資料傳輸

• rdt 3.0 是一個功能正確的協議，但是由於它是一個停等協議，大部分的時間都浪費在等待確認上面，所以效能不好。
• 解決這種特殊效能問題的一個簡單的方法是：不使用停等方式執行，允許傳送方傳送多個分組而無需等待確認。這種技術被稱為 流水線。
• 要使用流水線技術，則須：
  
  • 增加序號範圍。因為要傳送多個分組，而每個傳輸中的分組必須有一個單獨的序號。
  • 協議的傳送方和接收方兩端必須能快取多個分組。傳送方至少得能快取那些已傳送但未確認的分組，而接收方或許也需要快取那些已經正確接收的分組。
  • 所需序號的範圍和對緩衝的要求取決於資料傳輸協議如何處理丟失、損壞及延時過大的分組。
  • 流水線的差錯恢復有兩種基本方法：
    
    • 回退 N 步
    • 選擇重傳
• 

3.4.3 回退 N 步（GBN，又叫滑動視窗協議）

• 在 回退 N 步協議 中，允許傳送方傳送多個分組而不需等待確認，但它也受限於在流水線中未確認的分組數不能超過某個最大允許數 N。
  
• 基序號（base）為最早的未確認分組的序號。
• 下一個序號（nextseqnum）為下一個待發分組的的序號。
• N 常被稱為 視窗長度，GBN 協議也常被稱為 滑動視窗協議。
• GBN 的傳送方必須響應三種類型的事件：
  
  • 上層的呼叫：若視窗未滿，則產生一個分組將其傳送。
  • 收到一個 ACK：對序號為 n 的分組的確認採取 累積確認，表明接收方已正確接收到包括 n 的序號在內的 n 的以前的所有分組。
  • 超時事件：只使用一個定時器，即最早的已傳送但未被確認的分組所使用的定時器。如果出現超時，則傳送方重傳所有已傳送但還未被確認的分組。如果收到一個 ACK，但仍有已傳送但未被確認的分組，則重啟定時器。如果沒有已傳送但未確認的分組，該定時器被終止。
• GBN正常傳輸時
  
  • 
• GBN丟失幀時
  
  • 

3.4.4 選擇重傳（SR）

• GBN 也存在一些效能問題，單個分組的錯誤會引起大量分組的重傳。
• 選擇重傳 通過讓傳送方僅重傳那些它懷疑在接收方出錯的分組而避免了不必要的重傳。
• 下圖是選擇重傳發送方和接收方的序號空間：
  
  • 
• SR 傳送方的事件和動作：
  
  • 從上層接收資料： 檢查下一個可用於該分組的序號，若在傳送方的視窗內，則將資料打包傳送。
  • 超時： 定時器再次用來防止丟失分組。但是現在每個分組必須得有單獨的定時器。
  • 收到 ACK：倘若該分組序號在視窗內，則 SR 傳送方將那個被確認的分組標記為已接收。如果該分組的序號等於send_base，則視窗基序號向前移動到具有最小序號的未確認分組處。如果視窗移動了並且該序號落在視窗內的未傳送分組，則傳送這些分組。
• SR 接收方將確認一個正確接收的分組而不管其是否按序。
• SR 接收方的事件和動作：
  
  • 序號在 [rcv_base, rcv_base + N -1] 內的分組被正確接收：在此情況下，收到的分組落在接收方的視窗內，一個選擇 ACK 被回送給傳送方。如果該分組以前沒收到過，則快取該分組。如果該分組的序號等於接收視窗的基序號，則該分組及以前快取的序號連續的分組交付給上層。
  • 序號在 [rcv_base - N, rcv_base - 1] 內的分組被正確接收： 產生一個 ACK，即使該分組是接收方以前已確認過的分組。
  • 其他情況：忽略該分組。
• 視窗長度必須小於或等於序號空間大小的一半。
• 
• 問題
  
  • 
  • 接收方：在(a)和(b)兩種情況下接收方沒有發現差別!
  • 在 (a)中不正確地將新的冗餘的當為新的，而在(b)中不正確地將新的當作冗餘的

3.5 面向連線的運輸：TCP

3.5.1 TCP 連線

特點

• TCP是面向連線的
  通訊前需要建立連線，通訊結束需要釋放連線。
• TCP提供可靠交付服務
  所謂『可靠』指的是：TCP傳送的資料無重複、無丟失、無錯誤、與傳送端順序一致。
• TCP是面向位元組流的
  所謂『面向位元組流』指的是：TCP以位元組為單位。雖然傳輸的過程中資料被劃分成一個個資料報，但這只是為了方便傳輸，接收端最終接受到的資料將與傳送端的資料一模一樣。
• TCP提供全雙工通訊
  所謂『全雙工通訊』指的是：TCP的兩端既可以作為傳送端，也可以作為接收端。
• 一條TCP連線的兩端只能有兩個端點
  TCP只能提供點到點的通訊，而UDP可以任意方式的通訊。

TCP連線與套接字

• 什麼是『TCP連線』？
  TCP連線是一種抽象的概念，表示一條可以通訊的鏈路。
  每條TCP連線有且僅有兩個端點，表示通訊的雙方。且雙發在任意時刻都可以作為傳送者和接收者。
• 什麼是『套接字』？
  一條TCP連線的兩端就是兩個套接字。
  套接字=IP地址:埠號。
  因此，TCP連線=（套接字1，套接字2）=（IP1:埠號1，IP2:埠號2）

TCP三次握手

PS：TCP協議中，主動發起請求的一端稱為『客戶端』，被動連線的一端稱為『服務端』。不管是客戶端還是服務端，TCP連線建立完後都能傳送和接收資料。

起初，伺服器和客戶端都為CLOSED狀態。在通訊開始前，雙方都得建立各自的傳輸控制塊（TCB）。
伺服器建立完TCB後遍進入LISTEN狀態，此時準備接收客戶端發來的連線請求。

第一次握手

客戶端向服務端傳送連線請求報文段。該報文段的頭部中SYN=1，ACK=0，seq=x。請求傳送後，客戶端便進入SYN-SENT狀態。

• PS1：SYN=1，ACK=0表示該報文段為連線請求報文。
• PS2：x為本次TCP通訊的位元組流的初始序號。
  TCP規定：SYN=1的報文段不能有資料部分，但要消耗掉一個序號。

第二次握手

服務端收到連線請求報文段後，如果同意連線，則會發送一個應答：SYN=1，ACK=1，seq=y，ack=x+1。
該應答傳送完成後便進入SYN-RCVD狀態。

• PS1：SYN=1，ACK=1表示該報文段為連線同意的應答報文。
• PS2：seq=y表示服務端作為傳送者時，傳送位元組流的初始序號。
• PS3：ack=x+1表示服務端希望下一個資料報傳送序號從x+1開始的位元組。

第三次握手

當客戶端收到連線同意的應答後，還要向服務端傳送一個確認報文段，表示：服務端發來的連線同意應答已經成功收到。
該報文段的頭部為：ACK=1，seq=x+1，ack=y+1。
客戶端發完這個報文段後便進入ESTABLISHED狀態，服務端收到這個應答後也進入ESTABLISHED狀態，此時連線的建立完成！

為什麼連線建立需要三次握手，而不是兩次握手？

防止失效的連線請求報文段被服務端接收，從而產生錯誤。

PS：失效的連線請求：若客戶端向服務端傳送的連線請求丟失，客戶端等待應答超時後就會再次傳送連線請求，此時，上一個連線請求就是『失效的』。

若建立連線只需兩次握手，客戶端並沒有太大的變化，仍然需要獲得服務端的應答後才進入ESTABLISHED狀態，而服務端在收到連線請求後就進入ESTABLISHED狀態。此時如果網路擁塞，客戶端傳送的連線請求遲遲到不了服務端，客戶端便超時重發請求，如果服務端正確接收並確認應答，雙方便開始通訊，通訊結束後釋放連線。此時，如果那個失效的連線請求抵達了服務端，由於只有兩次握手，服務端收到請求就會進入ESTABLISHED狀態，等待發送資料或主動傳送資料。但此時的客戶端早已進入CLOSED狀態，服務端將會一直等待下去，這樣浪費服務端連線資源。

三次握手後

傳送方通過套接字向TCP的傳送快取中傳輸資料，當資料達到最大報文段長（MSS）時TCP就將快取加上一個TCP首部形成報文段傳送給接收方的TCP接收快取。

TCP四次揮手

TCP連線的釋放一共需要四步，因此稱為『四次揮手』。
我們知道，TCP連線是雙向的，因此在四次揮手中，前兩次揮手用於斷開一個方向的連線，後兩次揮手用於斷開另一方向的連線。

第一次揮手

若A認為資料傳送完成，則它需要向B傳送連線釋放請求。該請求只有報文頭，頭中攜帶的主要引數為：
FIN=1，seq=u。此時，A將進入FIN-WAIT-1狀態。

• PS1：FIN=1表示該報文段是一個連線釋放請求。
• PS2：seq=u，u-1是A向B傳送的最後一個位元組的序號。

第二次揮手

B收到連線釋放請求後，會通知相應的應用程式，告訴它A向B這個方向的連線已經釋放。此時B進入CLOSE-WAIT狀態，並向A傳送連線釋放的應答，其報文頭包含：
ACK=1，seq=v，ack=u+1。

• PS1：ACK=1：除TCP連線請求報文段以外，TCP通訊過程中所有資料報的ACK都為1，表示應答。
• PS2：seq=v，v-1是B向A傳送的最後一個位元組的序號。
• PS3：ack=u+1表示希望收到從第u+1個位元組開始的報文段，並且已經成功接收了前u個位元組。
  A收到該應答，進入FIN-WAIT-2狀態，等待B傳送連線釋放請求。

第二次揮手完成後，A到B方向的連線已經釋放，B不會再接收資料，A也不會再發送資料。但B到A方向的連線仍然存在，B可以繼續向A傳送資料。

第三次揮手

當B向A發完所有資料後，向A傳送連線釋放請求，請求頭：FIN=1，ACK=1，seq=w，ack=u+1。B便進入LAST-ACK狀態。

第四次揮手

A收到釋放請求後，向B傳送確認應答，此時A進入TIME-WAIT狀態。該狀態會持續2MSL時間，若該時間段內沒有B的重發請求的話，就進入CLOSED狀態，撤銷TCB。當B收到確認應答後，也便進入CLOSED狀態，撤銷TCB。

為什麼A要先進入TIME-WAIT狀態，等待2MSL時間後才進入CLOSED狀態？

為了保證B能收到A的確認應答。
若A發完確認應答後直接進入CLOSED狀態，那麼如果該應答丟失，B等待超時後就會重新發送連線釋放請求，但此時A已經關閉了，不會作出任何響應，因此B永遠無法正常關閉。

TCP連線概括

客戶機端TCP傳送一個特殊報文段，不包含應用層資料，但首部的SYN置1，並選擇一個起始序號client_isn放置到該報文序號欄位中。伺服器接收後為該TCP建立分配TCP快取和變數，併發送允許報文段，SYN置1，確認號為client_isn+1，序號段中則是自己的初始序號server_isn，客戶端收到這個報文後也會分配快取和變數。併發送第三個報文，SYN置0，確認欄位為server_isn+1，目的是確認資訊。這個過程被稱作三次握手。連線終止時客戶端發出FIN置1的報文，伺服器也發揮FIN置1報文，客戶端確認後雙方釋放資源。

3.5.2 TCP 報文段結構

• 16 位元的 源埠號 和 16 位元的目的 埠號。用於多路分解和多路複用。
• 32 位元的 序號（sequence number）欄位。一個報文段的序號 是該報文段資料欄位首位元組的序號。
• 32 位元的 確認號（Acknowledgement number）欄位。主機 A　填充進報文段的確認號是主機 A 期望從主機 B 收到的下一位元組的序號
• 16 位元的 接收視窗（Receive window）欄位。用於指示接收方願意接收的位元組數量。
• 4 位元的 首部長度（header length）欄位。指示了以 32 位元的字為單位的 TCP 首部長度。
• 可變與變長的 選項（options）欄位。用於傳送方與接收方協商最大報文段長度時，或在高速網路環境下作用視窗調節因子時使用。
• 6 位元的 標誌（flag）欄位。
  
  • ACK 是對成功接收一個報文段的確認。
  • RST、SYN 和 FIN 用於連線的建立和拆除。
  • PSH 被設定時，指示接收方應立即將資料交給上層。
  • URG 位元用來指示報文段裡存在著被髮送端上層實體置為“緊急”的資料。緊急的最後一個位元組由 16 位元的 緊急資料指標（Urgent data pointer）欄位 指出。
  • 注：在實踐中，PSH 、URG 和 緊急資料指標 並不 使用。

3.5.3 往返時間的估計與超時

• 如何設定TCP 超時值
  
  • 應大於RTT：但RTT是變化的
  • 太短: 過早超時，不必要的重傳
  • 太長: 對報文段的丟失響應太慢
• TCP採用超時/重傳機制處理報文段丟失
• 估計往返時間
  
  • 報文段的樣本RTT：SampleRTT
  • SampleRTT 均值：EstimatedRTT
  • EstimatedRTT=0.875∗EstimeatedRTT+0.125∗SampleRTT
• 設定和管理超時重傳時間
  
  • TimeoutInterval=EstimatedRTT+4∗DevRTT
  • 超時間隔 = 估計RTT + 4*偏差RTT

3.5.4 可靠資料傳輸

PS：網路層傳輸的資料單元為『資料報』，傳輸層的資料單元為『報文段』，為了方便起見可以統稱為『分組』。

• 三種情況
  
  • A向B傳送一個報文段，序號92，包含8位元組，交給IP後開始等待一個來自B的確認號為100的報文段。然而確認報文段丟失，超時，A又重發相同報文段。B收到後對比序號發現已經收到過該報文段的一些位元組，於是B的TCP確認後，將報文段重複的位元組丟棄
  • 
  • A連續發了兩個報文段，92，8和100，20（序號和位元組）。B收到兩個報文段併發送確認100和200。超時前沒有一個確認到達A，超時後A重傳92，8的報文，重啟定時器。只要第二個報文的ACK在新的超時以前發生到達，第二個報文就不會重傳。
  • 
  • 和上面一種一樣，A傳送兩個報文段，第一個報文段的確認在網路丟失，但是超時之前收到了第二個報文段的確認報文。因為累積確認機制，A知道B已經收到第二個以及之前的報文，不會重傳了
  • 
• 超時間隔加倍
  
  • 實際大多數情況下，每次TCP重傳時會將下次超時間隔設為先前的兩倍
  • 當定時器在另外兩個事件（收到上層應用資料，收到ACK）中的任意一個啟動時，超時間隔又從估計RTT和偏差RTT推算得到。比如一個報文段第一次超時1s，重發，第二次超時就是2s，第三次4s…但是當收到該報文確認時，超時間隔又重置，算是一種擁塞控制
• 快速重傳
  
  • 傳送方挨個傳送大量報文段，如果一個丟失，很可能引起一個接一個冗餘ACK（即重複的ACK，上面說過，A連續發了序號為1，2，3，4，5的報文，若B沒收到2，卻收到了3，4，5，則對2之後的報文都發送確認號為2的ACK）。如果TCP傳送方接收到對相同資料的3個冗餘ACK，它把這當做一種指示，說明這個重複確認報文段後面的報文都丟失了。一旦收到3個冗餘ACK，TCP執行快速重傳，即在該報文段的定時器過期之前重傳丟失的報文段
  • 
• 回退N步 or 選擇重傳
  
  • TCP確認是累積式的，正確接收但失序的報文段是不會被接收方逐個確認的，像GBN風格
  • 但是TCP和GBN有顯著區別
    
    • 許多TCP實現會將正確接收但失序的報文段快取起來
    • GBN不僅重傳未確認分組，還會重傳之後所有分組，TCP只傳一個或不傳（若其後面的ACK超時前到來）
  • 選擇確認，允許接收方有選擇地確認失序報文段，而不是累積確認最後一個正確接收的有序報文段。該機制與選擇重傳機制結合（跳過重傳已確認報文段），TCP看起來像SR
  • TCP的差錯恢復機制是GBN協議和SR協議的混合體

3.5.5 流量控制

• 什麼是流量控制？
  如果傳送者傳送過快，接收者來不及接收，那麼就會有分組丟失。為了避免分組丟失，控制傳送者的傳送速度，使得接收者來得及接收，這就是流量控制。
  流量控制是一個速度匹配服務，傳送方傳送速率與接收方程式讀取速率相匹配
• 流量控制的目的？
  流量控制根本目的是防止分組丟失，它是構成TCP可靠性的一方面。
• 如何實現流量控制？
  由滑動視窗協議（連續ARQ協議，如GBN和SR）實現，TCP讓傳送方維護一個稱為接收視窗rwnd的變數，用於給傳送方指示接收方還有多少可用快取。因為是全雙工通訊，雙方都維護接收視窗變數。B把rwnd值放入給A的報文段接收視窗欄位中，通知A自己還有多少快取空間，A控制未確認的資料量小於rwnd，即傳送方的傳送視窗不可以大於接收方發回的視窗大小。
  滑動視窗協議既保證了分組無差錯、有序接收，也實現了流量控制。
• 流量控制引發的死鎖
  考慮一種特殊的情況，就是接收方若沒有快取足夠使用，就會發送零視窗大小的報文，此時傳送放將傳送視窗設定為0，停止傳送資料。之後接收方有足夠的快取，傳送了非零視窗大小的報文，但是這個報文在中途丟失的，傳送者一直等待下去，而接收者以為傳送者已經收到該應答，等待接收新資料，這樣雙方就相互等待，從而產生死鎖。
• 持續計時器
  為了避免流量控制引發的死鎖，TCP使用了持續計時器。每當傳送者收到一個零視窗的應答後就啟動該計時器。時間一到便主動傳送報文詢問接收者的視窗大小。若接收者仍然返回零視窗，則重置該計時器繼續等待；若視窗不為0，則表示應答報文丟失了，此時重置傳送視窗後開始傳送，這樣就避免了死鎖的產生。
• 一條TCP連線每一側主機都設定了快取，當TCP連線收到正確有序的位元組後，將資料放入快取，應用從快取中讀取。若應用較忙，傳送方傳送太快太多，可能會造成快取溢位
• TCP傳送方因為IP網路的擁塞而降速（超時間隔加倍），屬於擁塞控制，不屬於流量控制，雖然都是降速
• UDP無流量控制，快取溢位就溢位了

3.6 擁塞控制

3.6.1 擁塞原因與代價

• 丟包一般是當前網路擁塞時由於路由器快取溢位引起，因此分組重傳能作為網路擁塞的徵兆，但分組重傳無法解決網路擁塞
• 擁塞原因與代價
  
  • 情況一：兩個傳送方和一臺無窮大快取的路由器
    
    • 容量為R的共享式輸出鏈路上傳輸
    • 當傳送速率超過R/2時，路由器的排隊分組就會無限增加，源和目的平均時延變成無窮大
  • 情況二：兩個傳送方和一臺有限快取的路由器
    
    • 分組到達一個已滿的快取時會被丟棄，傳送方必須執行重傳以補償因為快取溢位丟棄的分組
    • 傳送方遇到高時延時，進行的不必要重傳引起路由器轉發不必要的分組副本
  • 情況三：4個傳送方和具有優先快取的多臺路由器及多條路徑
    
    • 當一個分組沿一條路徑被丟棄時，每個上游路由器用於轉發該分組到丟棄該分組使用的傳輸容量被浪費
• 擁塞控制 和 流量控制 的區別？
  
  1. 擁塞控制：擁塞控制是作用於網路的，它是防止過多的資料注入到網路中，避免出現網路負載過大的情況；
  2. 流量控制：流量控制是作用於接收者的，它是控制傳送者的傳送速度從而使接收者來得及接收。
• 擁塞控制的目的？
  
  1. 緩解網路壓力
  2. 保證分組按時到達

3.6.2 擁塞控制方法

• 擁塞控制可以分為端到端的和網路輔助兩種，對應網路層是否為運輸層擁塞機制提供顯式幫助。TCP是端到端的擁塞機制，因為其網路下層IP協議並不提供擁塞機制。按照前面說的，首先TCP可以通過控制擁塞視窗的值控制傳送方流量，通過超時和連收3個冗餘ACK判斷網路擁塞，如果出現就縮小視窗，否則就趁機放大視窗利用空閒頻寬。

3.7 TCP擁塞控制

• TCP必須用端到端擁塞控制，因為IP層不向端系統提供顯式網路擁塞反饋
• TCP讓每一個傳送方根據感知到的擁塞程度限制其傳送速率
  
  • 如何限制其傳送速率？
    
    • 維護擁塞視窗cwnd值（注意流量控制使用接收視窗rwnd值）
    • 傳送方未確認資料量 <= min { cwnd , rwnd }
  • 如何感知它到目的地路徑存在擁塞？
    
    • 丟包：超時或收到3個冗餘ACK
• TCP是自計時的，使用確認來觸發增大它的擁塞視窗長度（及其傳輸速率）
• TCP傳送方如何確定傳送速率？
  
  • 一個丟失的報文意味著擁塞，當丟失報文段時應當降低速率（當前速度不能正常交付，得慢點）
  • 先前未確認報文段的確認到達時，增加發送方速率（當前速度能夠正常交付，說明可以再快點）
  • 頻寬探測（試探）：TCP傳送方增加速率，丟包，從該速率後退，再往前探測….（因為擁塞情況是波動的，得盡力保持在最高速率）

TCP擁塞控制演算法

• 慢啟動演算法 和 擁塞避免演算法
• 傳送方維護一個傳送視窗，傳送視窗的大小取決於網路的擁塞情況和接收視窗的大小，傳送視窗是動態變化的。
• 傳送方還維護一個慢啟動門限
  傳送視窗 < 慢啟動門限：使用慢啟動演算法
  傳送視窗 > 慢啟動門限：使用擁塞避免演算法
  傳送視窗 = 慢啟動門限：使用慢啟動演算法或擁塞避免演算法
• 演算法的具體過程：
  
  1. 慢啟動
     
     • 一開始cwnd只設為一個MSS的較小值（這就是『慢』，不過瞬間指數級加速）
     • 收到一個確認，cwnd增加一個MSS ——> 每過一個RTT，cwnd翻番，傳送速率翻倍（1，2，4…每次發的也多一個）
     • 丟包（擁塞）結束慢啟動
       
       • 將ssthresh（慢啟動閾值）設定為cwnd/2，cwnd置為1重新開始慢啟動
       • 當cwnd=ssthresh時，結束慢啟動，TCP轉移到擁塞避免模式
       • 收到3個冗餘ACK，執行快速重傳，進入快速恢復模式
  2. 擁塞避免
     
     • 進入擁塞避免狀態，cwnd值是上次遇到擁塞時的一半
     • 每個RTT只將cwnd值增加一個MSS/cwnd位元組
     • 丟包，結束擁塞避免
       
       • 超時：ssthresh更新為cwnd的一半，cwnd置為1個MSS，返回慢啟動狀態
       • 冗餘ACK：ssthresh更新為cwnd的一半，cwnd值減半，進入快速恢復狀態
  3. 快速恢復
     
     • 快速恢復中，每個冗餘ACK，cwnd 增加一個MSS，當丟失報文的ACK到達時，TCP降低cwnd，進入擁塞避免狀態
     • 超時：同慢啟動和擁塞避免
• 總體上來說，如果沒有擁塞，TCP每收到一個正常的確認報文，就將視窗擴大一個MSS（最大報文段），也就是多發一個報文，如果出現擁塞就將視窗大小縮小一半。該演算法稱作加性增，乘性減。
  首先，因為在開始階段視窗初值一般僅為一個MSS，這樣在很長一段時間內速率會很低，而可用頻寬可能很大，為了儘快探明最大可用頻寬，啟動階段每經過一個RTT，視窗值就增大一倍，直到出現一個報文丟失，這個特殊過程才結束。該過程稱作慢啟動。其次，遇到一個超時事件的時候，TCP將視窗值設成1個MSS，並慢啟動到丟失報文前視窗值的一半。但是收到3個冗餘ACK的時候並不慢啟動而是直接減半，這種行為叫快速恢復。