運輸層位於應用層和網絡層之間，是分層的網絡體系結構的重要部分，該層爲運行在不同主機上的應用進程提供直接的通信服務起着至關重要的作用。
一、概述和運輸層服務
運輸層協議爲運行在不同主機上的應用進程之間提供了邏輯通信功能。在發送端，運輸層將從發送應用程序進程接受到的報文轉換成運輸層報文段，運輸層將這些報文傳遞給網絡層，網絡層將其封裝爲網絡層分組並向目的地發送。
1、運輸層和網絡層的關係
運輸層協議只工作在端系統中，在端系統中，運輸層協議將來自應用進程的報文移動到網絡邊緣，反過來也是一樣，但對有關這些報文在網絡核心如何移動不作任何規定。運輸協議能夠提供的某些服務常常受制於底層網絡層協議的服務模型，如果網絡層協議不能爲主機間發送的傳輸層報文段提供延遲或帶寬保證，那麼傳輸層協議就不能爲進程間發送的應用消息提供延遲或帶寬保證。然而，即使底層網絡協議不能在網絡層提供相應的服務，傳輸層協議也可以提供某些服務。
2、因特網運輸層協議
因特網網絡層協議名字爲IP，即網絡協議。IP爲主機之間提供了邏輯通信，IP的服務模型是盡力而爲交付服務，它會盡最大努力在通信的主機間交付報文，但它不做任何保證，如不確保報文段的交付，不保證報文段的按需交付，不保證報文段中數據的完整性，因而IP爲稱爲不可靠服務。
UDP和TCP最基本的責任是，將端系統間IP的交付服務擴展爲運行在端系統上的兩個進程間的交付服務。將主機間交付擴展到進程間交付被稱爲運輸層的多路複用與多路分解。進程到進程間的數據交付和差錯檢查是兩種最低限度的運輸層服務，也是UDP提供的僅有的兩種服務。TCP則提供了幾種附加服務，首先他提供可靠數據傳輸，通過使用流量控制、序號、確認和定時器，TCP將兩個端系統間的不可靠的IP服務轉換成了一種進程間的可靠數據傳輸服務，此外TCP還提供擁塞控制，來防止任何一條TCP連接用過多流量來淹沒通信主機之間的鏈路和交換設備
二、多路複用與多路分解
當計算機中的運輸層從底層的網絡接收數據時，它需要將所接收到的數據定向到不同的進程，每個進程有一個或多個套接字，它相當於從網絡向進程傳遞數據和從進程向網絡傳遞數據的門戶。將運輸層報文段中的數據交付到正確的套接字的工作稱爲多路分解。在源主機從不同套接字中收集數據塊，併爲每個數據塊封裝上首部信息從而生成報文段，然後將報文段傳遞到網絡層，所有這些工作稱爲多路複用。
套接字有唯一的標識符，而每個報文段有特殊字段來指示該報文段要交付到的套接字，多路複用可以藉助這兩個特點來展開工作。上述的特殊字段是源端口號字段和目的端口號字段。端口號是一個16比特的數，其大小在0~65535之間，0~1023範圍的端口號稱爲周知端口號，是受限制的，它們會保留給HTTP的80和FTP的21之類的周知應用協議使用。從上面不難推斷出多路分解的執行流程，它可以藉助報文段中的目的端口號將其定向到對應的套接字，然後報文中的數據通過套接字進入其所連接的進程。
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後進入擁塞避免狀態。