運輸層位於應用層和網路層之間，是分層的網路體系結構的重要部分，該層為執行在不同主機上的應用程序提供直接的通訊服務起著至關重要的作用。

一、概述和運輸層服務

運輸層協議為執行在不同主機上的應用程序之間提供了邏輯通訊功能。在傳送端，運輸層將從傳送應用程式程序接受到的報文轉換成運輸層報文段，運輸層將這些報文傳遞給網路層，網路層將其封裝為網路層分組並向目的地傳送。

1、運輸層和網路層的關係

運輸層協議只工作在端系統中，在端系統中，運輸層協議將來自應用程序的報文移動到網路邊緣，反過來也是一樣，但對有關這些報文在網路核心如何移動不作任何規定。運輸協議能夠提供的某些服務常常受制於底層網路層協議的服務模型，如果網路層協議不能為主機間傳送的傳輸層報文段提供延遲或頻寬保證，那麼傳輸層協議就不能為程序間傳送的應用訊息提供延遲或頻寬保證。然而，即使底層網路協議不能在網路層提供相應的服務，傳輸層協議也可以提供某些服務。

2、因特網運輸層協議

因特網網路層協議名字為IP，即網路協議。IP為主機之間提供了邏輯通訊，IP的服務模型是盡力而為交付服務，它會盡最大努力在通訊的主機間交付報文，但它不做任何保證，如不確保報文段的交付，不保證報文段的按需交付，不保證報文段中資料的完整性，因而IP為稱為不可靠服務。

UDP和TCP最基本的責任是，將端系統間IP的交付服務擴充套件為執行在端系統上的兩個程序間的交付服務。將主機間交付擴充套件到程序間交付被稱為運輸層的多路複用與多路分解。程序到程序間的資料交付和差錯檢查是兩種最低限度的運輸層服務，也是UDP提供的僅有的兩種服務。TCP則提供了幾種附加服務，首先他提供可靠資料傳輸，通過使用流量控制、序號、確認和定時器，TCP將兩個端系統間的不可靠的IP服務轉換成了一種程序間的可靠資料傳輸服務，此外TCP還提供擁塞控制

二、多路複用與多路分解

當計算機中的運輸層從底層的網路接收資料時，它需要將所接收到的資料定向到不同的程序，每個程序有一個或多個套接字，它相當於從網路向程序傳遞資料和從程序向網路傳遞資料的門戶。將運輸層報文段中的資料交付到正確的套接字的工作稱為多路分解。在源主機從不同套接字中收集資料塊，併為每個資料塊封裝上首部資訊從而生成報文段，然後將報文段傳遞到網路層，所有這些工作稱為多路複用。

套接字有唯一的識別符號，而每個報文段有特殊欄位來指示該報文段要交付到的套接字，多路複用可以藉助這兩個特點來展開工作。上述的特殊欄位是源埠號欄位和目的埠號

1、無連線的多路複用與多路分解

一個UDP套接字是有一個二元組（源埠號和目的埠號）全面標識的，該二元組包含一個目的IP地址和一個目的埠號，因此會出現多個不同報文段通過相同的目的套接字被定位到相同的目的程序。源埠的用途則是可以作為“返回地址“的一部分

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

TCP套接字是由一個四元組（源IP地址，源埠號，目的IP地址，目的埠號）來標識的。與UDP不同的是，兩個具有不同源IP地址或源埠號的到達TCP報文將被定向到兩個不同的套接字，除非TCP報文攜帶了初始建立連線的請求。

3、Web伺服器與TCP

連線套接字與程序之間並非總是有著一一對應的關係，事實上，當今的高效能Web伺服器通常只使用一個程序，但是為每個新的客戶連線建立一個具有新連線套接字的新執行緒，因此在任意的給定時間內都可能有許多連線套接字連線到相同的程序。

三、無連線運輸：UDP

除了複用/分解功能及少量的差錯檢測外，它幾乎沒有對IP增加別的東西。UDP有如下優點：

• 關於傳送什麼資料以及何時傳送的應用層控制更加精細；TCP的擁塞控制機制會遏制運輸層TCP的傳送方；
• 無需建立連線；因此不會引入建立連線的時延；這也是DNS執行在UDP而不是TCP的原因；
• 無連線狀態；TCP需要在端系統中維護連線狀態，包括接受和傳送快取，擁塞控制機制引數以及序號及確認號的引數；
• 分組首部開銷小；UDP僅有8位元組的開銷，TCP報文段則有20位元組的首部開銷；

1、UDP報文結構欄位

UDP報文結構如上圖所示，應用層資料會佔用UDP報文段的資料欄位，如對於DNS來說，資料欄位要麼包含一個查詢報文要麼包含一個響應報文。長度欄位指示了在UDP報文段中的位元組數（首部+資料）；接收方使用校驗和來檢查該報文段中是否出現了差錯，計算校驗和時，除了UDP報文段以外還包括了IP首部的一些欄位

2、UDP校驗和

UDP校驗和提供了差錯檢查功能，也就是用來確認UDP報文段從源到達目的地移動時，其中的位元是否發生了變化。傳送方的UDP報文對報文段中的所有16位元字的和進行反碼運算，求和時遇到的任何溢位都會被回捲。反碼運算就是將所有的0換成1，所有的1換成0

許多鏈路層協議也提供了錯差檢測，但並不能保證所有鏈路都進行提供了差錯檢測，即如果端到端資料傳輸服務要提供錯查檢測，UDP就必須在端到端基礎上在運輸層提供錯查檢測，這就是系統設計上的端到端原則。

四、可靠資料傳輸原理

下圖為可靠資料傳輸服務模型框架，在該框架中為上層實體提供的服務抽象是：資料可以通過一條可靠的通道進行傳輸，而實現這種服務的抽象是可靠資料傳輸協議的職責。由於可靠資料傳輸協議的下層協議也許是不可靠的，所以這是一項困難的任務。在本節中，我們僅考慮單項資料傳輸的情況，暫不考慮雙向資料傳輸（全雙工資料傳輸）。

1、構造可靠資料傳輸協議

1.1、經完全可靠通道的可靠資料傳輸：rdt1.0

首先考慮最簡單的情況，即底層通道是完全可靠的，我們稱該協議為rdt1.0，該協議本身是簡單的，這裡我們定義rdt1.0傳送方和接收方的有限狀態機（FSM），FSM會定義傳送方和接收方的操作。圖中的傳送方和接收方的FSM每個都只有一個狀態，箭頭描述了從一個狀態變遷到另一個狀態，引起變遷的事件顯示在橫線上方，事件發生所採取的動作顯示在橫線的下方。FSM的初始狀態使用虛線表示。

rdt的傳送端通過rdt_send(data)事件接受來自較高層的資料，產生一個包含該資料的分組，並將分組傳送到通道中，rdt_send(data)實際上是由較高層應用過程呼叫產生的。在接收端，rdt通過rdt_rcv(packet)事件從底層通道接受一個分組，從分組取出資料，並將資料上傳給較高層，dt_rcv(packet)事件實際上是由較低層協議的過程呼叫產生的。

1.2、經具有位元差錯通道的可靠資料傳輸：rdt2.0

①底層通道更為實際的模型是分組中的位元可能受損的模型，在分組的傳輸、傳播或快取過程中，這種位元差錯通常出現在網路的物理部件中。在通常情況下，報文接受者在聽到理解並記下每句話時可能會說OK，在聽到含糊不清的話時，他可能要求你重複那句容易誤解的話，這種口述報文協議使用了肯定確認與否定確認。在計算機網路環境中，基於這樣重傳機制的可靠資料傳輸協議稱為自動重傳請求協議（Automatic Repeat reQuest，ARQ）。ARQ協議中需要另外三種協議來處理存在位元差錯的情況：

• 差錯檢測：首先需要一種機制使得接收方檢測何時出現了位元差錯，這些技術要求有額外的位元從傳送方傳送到接收方，這些畢業被彙集在rdt2.0資料分組的分組檢驗和欄位中；
• 接收方反饋：傳送發需要了解接收方情況的唯一途徑就是讓接收方提供明確的反饋資訊給傳送方，類似於口述回答的肯定回答（ACK）和否定回答（NAK），rdt2.0協議將從接受方向傳送方回送ACK和NAK分組，理論上可以使用一個位元長即0表示NAK，1表示ACK
• 重傳：接收方收到有差錯的分組時，傳送方將重傳該分組文；

②rdt2.0的傳送端有兩種狀態：等待上層呼叫或等待ACK或NAK。需要注意的是，當傳送方處於等待ACK或NAK狀態時，它不能從上層獲得更多的資料。因此，傳送方將不會發送一塊新資料，除非傳送方確信接受方已經正確接受當前分組，由於這種行為，rdt2.0這樣的協議被稱為停等協議。rdt2.0接收方的FSM仍然只有單一狀態，分組到達時，要麼回答ACK要麼回答NAK，者取決於收到的分組是否受損。

③看起來rdt2.0可以運行了，但是它存在一個致命的缺陷，就是沒有考慮到ACK或NAK分組受損的可能性。其難點在於如果一個ACK或NAK分組受損，傳送方無法知道接收方是否正確接受了上一塊傳送的資料，這裡考慮三種可能性：

• 考慮在口述報文的情況下，由於不理解接收方的回覆，說話者可能會問“你說什麼”，情況是接收者不明白說話者是沒接受到自己的回答還是不明白；
• 第二種情況是增加足夠的校驗和位元位，使傳送方不僅可以檢測差錯，還可以恢復差錯，對於產生差錯但不丟失分組的通道，可以直接解決問題；
• 第三種情況是傳送方收到含糊不清的ACK或NAK分組時，只需重傳當前分組即可，然而這種方法在傳送方到接收方的通道中引入了冗餘分組，冗餘分組的困難在於接受方不知道它上次傳送的ACK或NAK分組是否被髮送方正確地收到，因此它無法知道接受到的分組是新的還是一次重傳

解決新問題的簡單方法是在資料分組中新增一個新的欄位，讓傳送方對其資料分組編號，即將傳送資料分組的序號放在該欄位。接收方只需要檢查序號及可以確定收到的分組是否一次重傳

1.3、經具有位元差錯的丟包通道的可靠資料傳輸：rdt3.0

假定除了位元受損外，底層通道還會丟包，則協議現在需要處理兩個問題，怎樣檢測丟包以及發生丟包後該做些什麼？有很多方法用於解決丟包問題，這裡我們讓傳送方負責檢測和恢復丟包工作。假定傳送方傳輸一個分組，該分組或接收方對該分組的ACK發生了丟失，這樣傳送方是接受不到響應的，這種情況下發送方會等待一段時間並重新發送分組。通常是傳送方和接收方之間的一個往返時延加上接收方處理一個分組所需要的時間。

為了實現基於時間的重傳機制，需要一個倒計數定時器，在一個給定的時間量過期後，可中斷髮送方。因此傳送方需要做到：①每次傳送一個分組時啟動一個定時器；②響應定時器中斷；③終止定時器。綜上，因為分組序號會在0和1之間交替，所以rdt3.0也被稱為位元交替協議

2、流水線可靠資料傳輸協議

rdt3.0是一個功能正確的協議，但在今天的高速網路中，其效能因其停等協議會有一定的影響。我們定義傳送方的利用率U=(L/R)/(RTT+L/R)，其中R為傳送速率，L為分組長，計算髮現在停等協議的情況下，效率是非常低的。

如果不以停等方式執行，允許傳送方傳送多個分組而無需等待，其利用率將大大提高。因為許多從傳送方向接受方輸送的分組可以看作是填充到一條流水線中，故這種技術被稱為流水線。它會對可靠資料傳輸協議帶來如下影響：

• 必須增加序號範圍，因為每個輸送中的分組必須有一個唯一的序號；
• 協議的傳送方和接收方兩端也許不得不快取多個分組，傳送方最低限度應當能緩衝那些已傳送但沒有確認的分組，接收方需要快取那些以正確接受的分組；
• 所需序號的範圍和對緩衝的要求取決於資料傳輸協議如何處理丟失、損壞及延時過大的分組。

解決流水線的差錯恢復有兩種基本方法：回退N步（Go-Back-N，GBN）和選擇重傳（Selective Repeat，SR）

3、回退N步

在回退N步協議中，允許傳送方傳送多個分組而不需要等待確認，但它也受限於在流水線中未確認分組數不能超過某個最大允許數N。這裡我們定義基序號base為最早未確認分組的序號，下一個序號nextSeqnum定義為最小未使用序號，則序號分為可以劃分為：[0,base-1]已傳送並確認，[base,nextSeqnum-1]對應已傳送未確認，[nextSeqnum,base+N-1]對應即將被髮送的分組，大於等於base+N的序號不可用直到被確認的分組已經得到確認。隨著協議的執行，GBN協議的序號空間向前滑動，因此N被稱為視窗長度，GBN協議被稱為滑動視窗協議。

GBN的傳送方必須響應三種類型的事件：

• 上層的呼叫：當上層呼叫時，傳送方首先檢查傳送視窗是否已滿，如果視窗未滿則產生一個分組並將其傳送，如果視窗已滿傳送方只需將資料返回給上層並指示視窗已滿。在實際中，傳送方會快取這些資料，或者使用同步機制允許上層在視窗不滿時再次呼叫。
• 收到一個ACK，在GBN協議中，對序號為n的分組確認採取累積確認的方式，表明接收方已經接收到序號為n的且以前包括n在內的所有分組。
• 超時事件，如果出現超時，傳送方將重傳所有已傳送但還未被確認過的分組。

4、選擇重傳

選擇重傳協議通過讓傳送方僅重傳那些它懷疑在接收方出錯的分組而避免了不必要的重傳，按需重傳要求接收方逐個確認正確接受的分組。SR接受方將確認一個正確接收的分組而不管其是否按序，失序的分組將被快取直到所有丟失分組皆被收到為止。

當我們面對有限序號範圍的實現時，傳送方和接收方視窗間缺乏同步會產生嚴重的後果，比如無法確認超出視窗長度的序號是重傳還是初次傳輸。所以視窗長度比序號空間小1時協議無法工作。此外考慮分組重新排序的情況，通道可被看成基本上是在快取分組，並在將來任意時刻自然地釋放這些分組，由於序號可以被重新使用，所以要十分小心。實際中採用的方法是確保一個序號不被重新使用，直到傳送方確信任何先前傳送序號為x的分組都不在網路中為止。

五、面向連線的運輸：TCP

1、TCP連線

TCP被稱為是面向連線的，這是因為在一個應用程序可以開始向另一個應用程序傳送資料之前，這兩個程序必須先相互握手，即它們必須相互發送某些預備報文段，以建立確保資料傳輸的引數。TCP協議只在端系統中執行，而不在中間的網格元素中執行，所以中間的網格元素不會維持TCP的連線狀態，事實上，中間路由器對TCP連線完全視而不見，它們看到的是資料報而不是連線。

TCP連線提供的是全雙工服務：如果一臺主機上的程序A與另一臺主機上的程序B存在一條TCP連線，那麼應用層資料就可以從程序B流向程序A的同時，也可以從程序A流向程序B。TCP的連線是點對點的，即在單個傳送方與單個接收方之間連線。

客戶程序通過套接字傳遞資料流，一旦建立起連線，TCP將這些資料引導到該連線的傳送快取裡，傳送快取是發起三次握手期間設定的快取之一，TCP會在它方便的時候以報文段的形式將資料傳遞到網路層。TCP可以從快取中取出並放入報文段中的資料數量受限於最大報文長度（MSS）。MSS通常根據最初確定的由本地傳送主機發送的最大鏈路層幀長度（即最大傳輸單元MTU）來設定，設定該MSS要保證一個TCP報文段加上TCP/IP首部長度（通常40個位元組）將適合單個鏈路層幀。乙太網和PPP鏈路層協議都具有1500位元組的MTU，因此MSS的典型值為1460位元組。注意MSS是指在報文段裡應用層資料的最大長度，並不包括首部TCP報文段。

TCP為每塊客戶資料配上一個TCP首部，從而形成多個TCP報文段。這些報文段被下傳給網路層，網路層將其分別封裝在網路層IP資料報中，然後這些IP資料報被髮送到網路中。

2、TCP報文段結構

TCP報文段由首部欄位和一個數據欄位組成，資料欄位包含一塊應用資料。MSS限制了報文段資料欄位的最大長度，當TCP傳送一個大檔案時，TCP通常將該檔案劃分為長度為MSS的若干塊。

TCP報文段的首部包括源埠號，目的埠號，用於多路複用/分解來自或送到上層應用的資料。TCP首部也包括檢驗和欄位，以及如下欄位：

• 32位元的序號欄位(sequence number field)和32位元的確認號欄位(acknowledgment number field)；
• 16位元的接受視窗欄位(ewceive window field)，用於流量控制，指示接收方願意接受的位元組數量；
• 4位元的首部長度欄位(header length field)，該欄位指示了以32位元的字為單位的TCP首部長度；由於TCP選項欄位，TCP的首部長度是可變的；
• 可選與變長的選項欄位(options field)，用於用於傳送方或接收方協商最大報文段長度，或在高速網路環境下用作視窗調節因子；
• 6位元的標誌欄位(flag field)，ACK位元用於指示確認欄位中的值是有效的，RST、SYN與FIN位元用於連線建立和拆除，還有其他如PSH、URG和緊急資料指標位元；

2.1、序號和確認號

TCP報文段中首部中兩個最重要的欄位是序號欄位與確認號欄位，這兩個欄位是TCP可靠傳輸服務的關鍵部分。一個報文段的序號是該報文段首位元組的位元組流編號。由於TCP是全雙工的，因此主機A在向主機B傳送資料時，也許也接受來自主機B的資料，從主機B到達的每個報文段中都有一個序號用於從B流向A的資料，主機A填充進報文段的確認號是主機A期望從主機B收到的下一位元組的序號

舉個例子，假設主機A收到來自主機B的一個包含位元組0到535的報文段和另一個包含位元組900到1,000的段。由於某些原因，主機A還沒有收到位元組536到899的報文段。在這個例子中，主機A仍在等待位元組536(及以後的位元組)，以便重新構建主機B的資料流。因此，A到B的下一個報文段將在確認號欄位中包含536。由於TCP只對流中第一個缺失的位元組以內的位元組進行確認，所以TCP被稱為提供是累積確認

最後一個例子也帶來了一個重要而微妙的問題。主機A在收到第二段(位元組536至899)之前收到了第三段(位元組900至1000)。因此，第三段失序到達。當主機在TCP連線中接收到失序的段時該怎麼辦？開發人員有兩種選擇：(1)接收方立即丟棄失報文段(2)接收方保留失序的位元組，並等待缺失的位元組來填補空缺。後一種選擇對網路頻寬而言更有效率，也是實踐中採取的方法。

2.2、學習案例-略

3、往返時間的估計與超時

TCP採用超時/重傳機制來處理報文段的丟失問題，其實現最明顯的問題是超時間隔長度的設定。

3.1、估計往返時間

大多數TCP的實現僅在某個時刻做一次SamoleRTT測量，而不是每個傳送的報文段測量一個SampleRTT，也就是說在任意時刻，僅為一個已傳送的但目前尚未被確認的報文段估算SampleRTT，從而產生一個接近每個RTT的新SampleRTT值。另外，TCP決不為已被重傳的報文段計算SampleRTT，它僅為傳輸一次的報文段測量SampleRTT。

由於路由器的擁塞和端系統負載的變化，報文段的SampleRTT值會隨之變動，TCP維持一個SampleRTT均值（稱為EstimatedRTT），一旦獲取一個新SampleRTT，TCP就會根據下列公式來更新EstimatedRTT：EstimatedRTT=(1-α)*EstimatedRTT+α*SampleRTT，α的推薦值是0.125

除了估算RTT外，測量RTT的變化也是有價值的，RTT偏差DevRTT的公式為DevRTT = (1 –β)*DevRTT + β•|SampleRTT–EstimatedRTT|，β的推薦值為0.125

3.2、設定和管理重傳超時間隔

超時間隔不應該比EstimatedRTT大太多，因此要求將超時間隔設為EstimatedRTT加上一定的餘量，當SampleRTT值波動大時，餘量應該大些；當波動較小時，餘量小些，綜上：TimeoutInterval=EstimatedRTT+4*DevRTT，推薦的初始TimeoutInterval值為1秒，當出現超時後，TimeoutInterval值將加倍，以免即將被確認的後繼報文段過早出現超時，一旦收到報文段並更新EstimetedRTT，將使用上述公式再次計算TimeoutInterval

4、可靠資料傳輸

TCP在IP不可靠的盡力而為為服務建立了一種可靠資料傳輸服務。TCP的可靠資料傳輸服務確保了一個程序從其接受快取中讀出的資料流是無損壞、無間隙、非冗餘和按序的資料流，即該位元組流與連線的另一方端系統發出的位元組流是完全相同的。

考慮TCP傳送方高度簡化的描述，TCP傳送方有3個與傳送和重傳有關的主要事件：從上層應用程式接受資料，定時器超時和收到ACK。

4.1、一些有趣的情況

考慮第一種場景，主機A向主機B傳送一個報文段，假設這個報文段的序號為92，包含8位元的資料。傳送完這個報文段後，主機A等待來自主機B編號為100的回覆報文段。雖然在B處收到了來自A的報文段，但從B到A的確認報文丟失了。在這種情況下，就會發生超時事件，主機A重新發送相同的報文段。當主機B收到重傳的報文段時，它將從序列號中觀察到該段包含已經收到的資料。因此，主機B中的TCP將丟棄重傳報文段中的位元組。

考慮第二種場景，主機A連續傳送了兩個報文段。第一個報文段的序列號為92，資料為8個位元組，第二個報文段的序列號為100，資料為20個位元組。假設這兩個報文段都完好無損地到達B處，B為每個報文段分別傳送一個確認。第一個確認報文的確認號是100; 第二個確認報文的確認號是120。 假設現在兩個確認報文段都沒有在超時之前到達主機A。當超時事件發生時，主機A重新發送序列號為92的第一段，並重新啟動定時器。只要第二段的ACK在新的超時之前到達，第二段將不會被重新發送。

考慮第三種場景，假設主機A傳送了兩個報文段，第一段的確認報文在網路中丟失了，但就在超時事件之前，主機A收到了一個確認號為120的報文確認，因此主機A知道主機B已經通過位元組119收到了所有的東西，所以主機A不重新發送這兩個段中的任何一個。

4.2、超時間隔加倍

每當超時事件發生時，TCP重傳具有最小序號的還未被確認的報文段，並且每次TCP重傳時都會將下一次的超時間隔設定為先前值的兩倍，而不是從EstimatedRTT和DevRTT推算出值。然而，每當定時器在另外兩個事件：收到上層應用的資料和收到ACK中的任意一個啟動時，TimeoutInterval由最近的EstimatedRTT和DevRTT的值得到。

4.3、快速重傳

超時觸發重傳存在的問題之一是超時週期可能比較長。 當一個段丟失時，這個長的超時週期迫使傳送方延遲重發丟失的資料包，從而增加了端到端延遲。這種情況下。傳送方可以在超時事件發生之前，通過冗餘ACK來檢測資料包丟失的情況。冗餘ACK就是再次確認某個報文段的ACK，傳送方先前已經受到過該報文段的確認。

如果TCP傳送方對同一個資料收到了三次重複的ACK，它就會認為這表明被確認過三次的報文段之後的報文段已經丟失。一旦收到三個冗餘的ACK，TCP就會執行快速重傳，即在該報文段的定時器過期之前重傳丟失的報文段。

4.4、回退N步還是選擇重傳

TCP的是累積確認的，正確接收但是失序的報文段並是不會被接收方逐個確認的。因此TCP傳送方只需要維護一個已傳送但未被確認的位元組的最小序列號和下一個要傳送的位元組的序列號。從這個意義上說，TCP看起來很像GBN風格的協議。但是TCP和Go-Back-N之間有一些明顯的區別。GBN會重傳確認異常後的同組報文段而TCP最多重傳一個。

會TCP提出的一種修改意見是選擇重傳，允許TCP接收器選擇性地確認無序段，而不是僅僅累積確認最後一個正確接收的有序段。當與選擇性重傳相結合時，TCP看起來很像我們的通用SR協議。因此，TCP的錯誤恢復機制可能最好被歸類為GBN和SR協議的混合體。

5、流量控制

TCP連線的兩邊的主機都為連線預留了一個接收緩衝區。當TCP連線接收到正確且按順序的位元組時，它將資料放入接收緩衝區。相關的應用程式程序將從這個緩衝區中讀取資料。如果應用程式讀取資料的速度很慢，那麼傳送者很容易因為傳送過快的資料而溢位連線的接收緩衝區，TCP為其應用程式提供了流量控制服務，以消除傳送者使接收方溢位緩衝區的可能性。因此，流量控制是一種速度匹配服務--將傳送方傳送的速度與接收方應用的讀取速度進行匹配。

TCP通過讓傳送方維護一個稱為接受視窗的變數來提供流量控制，接收視窗用於給傳送方一個指示，該接收方還有多少可用的快取空間。考慮一種情況，主機B接受主機A傳送的資料，且恰好該資料傳送完成後主機B的快取空間被佔滿，在主機B清空完快取後，主機A會不知道主機B已經有了新的快取空間。為了解決這個問題，TCP規範中要求：當主機B的接受視窗為0時，主機A繼續傳送只有一個位元組資料的報文段，這些報文段會被接收方確認，最終快取將開始清空，並且確認報文中將包含一個非0的接受視窗值。

6、TCP連線管理

1、三次握手：

• 第一步：客戶端的TCP首先向伺服器端的TCP傳送一個特殊的TCP報文，報文段的首部一個標誌位（SYN位元）被置為1，因此該報文被稱為SYN報文段。此外客戶會隨機的選擇一個初始序號（client_isn），並將該初始序號放置在SYN報文段的序號欄位中，該報文段最終會被封裝在一個IP資料報中，併發送給伺服器
• 第二步：包含SYN報文的IP資料到達伺服器後，伺服器會從該資料報中提取出SYN報文段，為該TCP連線分配TCP快取和變數，並向該客戶TCP傳送允許連線的報文段。這個允許連線的報文段首部中包含3個重要的資訊：①SYN位元會被置為1，②首部的確認號欄位會被置為clinet_isn+1，③最後伺服器選擇自己的初始序號(server_isn)並將其放置在報文段首部的序號欄位中。這個被允許連線的報文段被稱為SYNACK報文段
• 第三步：在收到SUNACK報文段後，客戶也要給該連線分配快取和變數，併發送另外一個報文段，該報文段對伺服器允許連線的報文段進行了確認（通過將server_isn+1放置到TCP報文段首部的確認欄位中來完成此項工作）。連線建立後，SYN位元被置為0，且這一步可以攜帶客戶到伺服器的資料

2、4次揮手：參與一條TCP連線的兩個程序中的任意一個都能終止該連線

• 如客戶端發起關閉連線請求，該TCP報文首部的一個標誌位即FIN位元被置為1；
• 伺服器接受到該報文後，會向傳送方回送一個確認段報文；
• 隨後，伺服器傳送它自己的終止報文段，FIN位元被置為1；
• 客戶對伺服器的終止報文段進行確認，完成後兩端用於該連線的所有資源都會被釋放；

3、相關的連線狀態

4、考慮連線異常的情況，主機會發送一個特殊的重置報文段，該TCP報文段將RST標誌位置為1，以提示傳送方無匹配的報文套接字；針對UDP連線不匹配的情況，主機會返回一個ICMP資料報

六、擁塞控制原理

1、擁塞原因及代價

1、考慮最簡單的擁塞情況：兩臺傳送主機A和B，連線兩端間的路由器（無窮大快取）和一段容量為R的共享式輸出鏈路，當兩臺主機的傳送速率超過R/2時，路由器中的平均排隊分組就會無限延長，源與目的地之間的平均時延也會變為無窮大。即當分組的到達速率接近鏈路容量時，分組經歷巨大的排隊時延。

2、兩個傳送方和一臺擁有優先快取的路由器：當分組到達一個已滿的快取時會被丟棄，而如果包含有運輸層報文段的分組在路由器中被丟棄，那麼它會被髮送方重傳。在傳送方確認了一個分組已經丟失時才重傳的情況下，傳送方必須執行重傳以彌補因為快取而丟棄的分組。而當傳送方提前發生超時並重傳在佇列中已經被推遲但還未被丟失的分組情況下（接收方已經接受到了該分組的初始版本所以重傳分組會被丟棄），傳送方子遇到大時延時所進行的不必要重傳會引起路由器利用其鏈路頻寬來轉發不必要的分組副本

3、4個傳送方和具有有限快取的多臺路由器及多跳路徑：4臺主機發送分組，每臺都通過交疊的兩跳路徑傳輸，考慮主機A-主機C以及主機D-主機B的連線共享路由器R1，並與B-D連線共享路由器R2，當A-C連線與B-D連線在路由器R2上為有限快取空間進行競爭時，且當B-D的連線通過越來越大時，A-C的連線會越來越擁堵，直到吞吐量趨向於0。即當一個分組沿一條路徑被丟棄時，每個上游路由器用於轉發該分組到丟棄該分組而使用的傳輸容量最終被浪費了。

2、擁塞控制方法

在最寬泛的級別上，可以根據網路層是否為運輸層擁塞控制提供了顯式幫助，來區分擁塞控制的方法：

• 端到端擁塞控制：在端到端的擁塞控制方法中，網路層沒有為運輸層擁塞控制提供顯式支援。

• 網路輔助的擁塞控制：在網路輔助的擁塞控制中，路由器向傳送方提供關於網路中擁塞狀態的顯式反饋資訊。

對於網路輔助的擁塞控制，擁塞資訊從網路反饋到傳送方通常有兩種方式：①直接反饋資訊由網路路由器傳送給對方；②路由器標記或更新從傳送方流向接收方的分組中的某個欄位來指示擁塞的產生。

七、TCP擁塞控制

TCP必須使用端到端擁塞控制而不是網路輔助的擁塞控制，因為IP層不向端系統提供顯式的網路擁塞反饋。TCP所採用的方法是讓每一個傳送方根據所感知到的網路擁塞程度來限制其向連線傳送流量的速率。TCP傳送方如果感知沒有擁塞，那麼TCP傳送方就會增加其傳送速率；如果傳送方認為路徑上存在擁塞，那麼傳送方就會降低其傳送速率。但是這種方法會帶來三個問題。第一，TCP傳送方如何限制其傳送的速率？其次，TCP傳送方如何感知到在本身和目的地之間存在擁塞？第三，傳送方應該用什麼演算法來改變其傳送速率？

1、執行在傳送方的TCP擁塞控制機制跟蹤一個額外的變數，即擁塞視窗（cwnd），它對一個TCP傳送方能向網路中傳送流量的速率進行了限制。考慮TCP接受的快取足夠大，即忽略接受視窗的限制，當出現過度的用擁塞時，路徑上的一臺或多臺路由器的快取會溢位，引起一個數據包被丟失，丟棄的資料報會引起傳送方的丟包事件（超時或收到3個冗餘的ACK），傳送方就會認為在傳送方到接收方的路徑上出現 了擁塞的指示。

2、當網路中沒有出現擁塞時，TCP接收端會將收到對以前未確認報文段的確認，TCP將這些確認的到達作為一切正常的指示，並使用確認來增加視窗（傳輸速率）的長度。TCP使用確認來增大它的擁塞視窗長度，因而TCP是自計時的。TCP是如何確定它應當傳送的速率呢？TCP使用下列指導性原則：

• 一個丟失的報文段意味著擁塞，因此當丟失報文段時應當降低TCP傳送方的速率；
• 一個確認報文段指示該網路正在向接收方交付傳送方的報文段，因此當對先前未確認報文段的確認到達時，能夠增加發送方的速率；
• 頻寬探測；為探測擁塞控制開始出現的速率，TCP傳送方增加它的傳輸速率，從該速率探測直到開始出現擁塞；

3、TCP擁塞控制演算法：①慢啟動；②擁塞避免；③快速恢復。慢啟動和擁塞避免是TCP的強制部分，快速恢復是推薦部分，對於TCP傳送方並非是必須的；

1、慢啟動

當一條TCP連線開始時，cwnd的值通常初始置為一個MSS的較小值，因而初始傳送速率大約為MSS/RTT。TCP傳送方希望迅速找到可用頻寬的數量，因此在慢啟動狀態，cwmd的值以一個MSS開始並且每當傳輸的報文段首次被確認就增加一個MSS，隨著傳送報文段指數級的增長，MSS也會不斷的翻番。因此TCP傳送速率起始慢，但在慢啟動階段後呈指數增長。增長如何結束？①如果存在一個由超時指示的丟包事件，TCP傳送方會將cwnd設定為1並重新開始慢啟動過程，並將慢啟動閾值ssthresh設定為cwnd/2；②當cwnd的值等於ssthresh（原先的cwnd/2）時，慢啟動結束並且轉移到擁塞避免模式；③當檢測到3個冗餘的ACK，TCP執行一種快速重傳並進入快速恢復狀態；

2、擁塞避免

一旦進入擁塞避免的狀態，cwnd的值大約是上次遇到用擁塞時值的一半，因此TCP採用了一種較為保守的方法，每個RTT只將cwnd的值增加一個MSS，通用的方法就是對於TCP傳送方如論何時到達一個新的確認，就將cwnd增加一個MSS位元組。何時結束線性的增長呢？與慢啟動的情況一樣，cwnd的值被設定為一個MSS，當丟包事件出現時，ssthresh的值被更新為cwnd值的一半，並進入快速恢復狀態

3、快速恢復

在快速恢復中，對於引起TCP進入快速恢復狀態的缺失報文段，每收到一個重複的ACK，cwnd的值增加一個MSS，最終當對丟失報文段的一個ACK到達時，TCP在降低cwnd後進入擁塞避免狀態。