運輸層（報文段）

1、運輸層概述

運輸層為執行在不同主機上的應用程序之間提供邏輯通訊功能。應用程序使用運輸層提供的邏輯通訊功能彼此傳送報文，而無需考慮承載這些報文的物理基礎。

運輸層和網路層的關係：網路層提供了主機之間的邏輯通訊，運輸層為在不同主機上的程序之間提供了邏輯通訊。運輸層協議只在主機起作用，運輸層能夠提供的服務受制於網路層協議的服務模型。

UDP和TCP的責任是將兩個端系統間IP的交付服務擴充套件到程序之間的交付服務。將主機間交付擴充套件到程序間交付被稱為多路複用和多路分解。

網路協議IP協議提供的是不可靠服務，並不能保證資料的完整性等。UDP同樣是一種不可靠服務，但可以提供程序間資料傳輸和差錯檢查兩種服務。TCP在此基礎上提供附加服務：（1）可靠資料傳輸，通過流量控制、序號、確認和定時器，TCP可以將兩個端系統間不可靠的IP服務轉為程序間的可靠資料傳輸服務。（2）擁塞控制，防止某一條TCP連線用過多流量來淹沒主機間的鏈路。

2、多路複用和多路分解

一個程序有一個或多個套接字，相當於從網路向程序傳遞資料和從程序向網路傳遞資料的門戶。運輸層實際上是將資料交付給套接字。

每個運輸層報文段中有幾個欄位，接收端運輸層會檢查這些欄位，標識出接收套接字，從而定向到該套接字。將運輸層報文段中的資料交付到正確的套接字的工作成為多路分解。源主機從不同的套接字接收資料塊，併為每個資料塊封裝上首部資訊形成報文段，並將報文段傳到網路的過程叫做多路複用。

多路複用要求：（1）套接字有唯一識別符號（2）每個報文段有特殊欄位來指示該報文段要交付到的套接字。特殊欄位是指埠號。埠號是一個16位元數，0-1023為固定埠號，如HTTP（80埠）、FTP（21埠）。

無連線的多路複用和多路分解：

clientSocket = socket(socket.AF_INET,socket.SOCK_DGRAM)生成一個UDP套接字，運輸層自動為其分配一個埠號。也可以通過bind()函式為其關聯一個特定的埠號。

UDP套接字由一個目的IP地址和一個目的埠號，如有兩個UDP報文段有不同的源IP地址和源埠，但有相同的目的IP地址和目的埠，這兩個報文段將通過相同的套接字被定向到相同的目的程序中。

面向連線的多路複用和多路分解：

與UDP不同，TCP套接字由一個四元組來標識，包括源IP，源埠，目的IP，目的埠。TCP需要建立連線，建立的方法如下：

TCP伺服器在12000埠listen，TCP客戶建立一個套接字併發送一個連線建立請求報文段，當伺服器接收到該請求時，伺服器會定位12000埠等待的程序併為其建立一個套接字，用[源IP，源埠，目的IP，目的埠]來標識，則可以建立與源埠的連線。伺服器主機可以支援很多並行的TCP套接字，每個套接字與一個程序連線，從而提供並行的服務。當今高效能的伺服器通常只有一個程序，而是為每個新客戶連線建立一個具有新套接字的執行緒。

3、UDP協議（無連線運輸）（8位元組首部）

UDP協議只對IP協議增加了多路複用和分解功能以及少量的差錯檢測。

DNS（域名系統）是運用UDP的一個例子。UDP的優勢：（1）實時性較強，TCP由於其擁塞控制實時性較弱（2）無需建立連線，沒有建立連線的時延，因此DNS執行在UDP上，HTTP執行在TCP上（3）無連線狀態，TCP需要在端系統中維護連線狀態，包括接收和傳送的快取、擁塞控制引數以及序號與確認號的引數（4）分組首部開銷小。

常見應用及其運輸協議：

3.1 UDP報文段結構

UDP報文首部包括4個欄位，每個欄位2個位元組，分別為源埠號，目的埠號，長度，檢驗和。

UDP檢驗和：差錯檢測功能

傳送方的UDP對報文段中的所有16位元字的和進行反碼運算，求和時遇到的任何溢位都被回捲（溢位後加到最後一位）。然後將該結果取反碼作為檢驗和。在接收端，如果沒有出錯，所有資料和檢驗和相加的結果為1111111111111111。

4、可靠資料傳輸原理

可靠資料傳輸協議往往建立在不可靠IP網路層協議之上。

4.1 構造可靠資料傳輸協議

（1）經完全可靠通道的可靠資料傳輸：rdt 1.0

最簡答的情況，底層訊號完全可靠，然而這在實際中不能實現

（2）經具有位元差錯通道的可靠資料傳輸：rdt 2.0

假設所有傳送的分組都可以按其傳送順序被接收。基於重傳機制的可靠資料傳輸協議稱為自動重傳請求協議（ARQ）。

ARQ協議中還需要另外三種協議功能來處理存在位元差錯的情況：差錯檢測，接收方反饋，重傳。

rdt2.0的傳送端每傳送一個分組需要等待接收端的確認訊號，這種協議被稱為停等協議。這種協議的一個關鍵問題是沒有考慮確認訊號受損的情況。解決這一問題的方法是在資料分組中新增一個新欄位，讓傳送方對其資料分組編號，即序號的概念。此為rdt2.1。rdt2.2時在rdt2.1的基礎上實現了一個沒有否定確認的可靠傳輸協議。

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

檢測丟包的方法：倒計數定時器用於實現基於時間的重傳機制。

總結可靠傳輸需要的技術：檢驗和、序號、定時器、肯定和否定確認分組。

4.2 流水線可靠資料傳輸協議

rdt3.0的最大缺陷在於它是一個停等協議。因此誕生流水線概念，傳送端不需要等待確認訊號就可以傳送下一個分組。但會帶來如下影響：必須增加序號範圍；協議雙方必須快取多個分組；序號範圍和快取大小取決於資料傳輸協議如何處理丟失、損壞及延時過大的分組。有兩種基本方法：回退N步和選擇重傳

（1）回退N步（GBN）：允許傳送端傳送多個分組，但在流水線中未被確認的分組數不能大於N，N被稱為視窗長度，GBN協議也被稱為滑動視窗協議。如果出現超時，傳送方會重傳所有已傳送但未被確認的分組，即回退N步，從而保證接收端可以按序將資料交付給上層。

（2）選擇重傳（SR）：GBN中單個分組的錯誤會引起重傳大量分組。選擇重傳協議通過讓傳送端僅重傳那些它懷疑在接收方出錯的分組。

SR中傳送端和接收端的序列空間：

傳送端事件和動作：從上層接收資料，如果下一個可用於該分組的序號不在視窗內，則要麼快取，要麼返回給上一層；每個分組都有一個定時器來防止丟失分組；收到ACK後，若該序號在視窗內，則標記為已確認，若該序號為send_base，則移動視窗到未確認分組的最小序號處。

接收端事件和動作：序號在[rcv_base,rcv_base+N-1]的分組被確認，若該分組序號不為rcv_base則快取，若該序號為rcv_base則將連續的分組交付給上層，並移動視窗。序號在[rcv_base-N,rcv_base-1]的分組被接收，則返回一個ACK，即使該分組已經確認過了。

SR協議會產生接收方不能確定新到的分組是一個新的分組還是一次重傳，因此要求視窗長度必須小於或等於序號空間大小的一半。

4、TCP協議（面向連線的運輸）（20位元組首部）

TCP之所謂是面向連線的，是因為兩個程序間通訊前要先相互握手，且TCP提供全雙工服務。TCP連線的組成包括：客戶端主機上的快取、變數和套接字，服務端上的快取、變數和套接字。

4.1 TCP報文段結構

源埠和目的埠，各佔兩個位元組；

序號seq，4個位元組，TCP傳送的位元組流中每個位元組都要編號；

確認號ack，4個位元組，期望傳送方下一個報文的第一個資料位元組的序號；

2個位元組的接收視窗欄位，用於流量控制；

4位元的首部長度，通常為空；

可選與變長的選項欄位，用於傳送方和接收方協商最大報文段長度時，或在高速網路環境下用於視窗調節因子使用；

6位元的標誌欄位：緊急URG，表明此報文中有緊急資料，緊急資料的最後一個位元組的指標由緊急指標指出；確認ACK，表明該報文段為已成功接收報文段的確認；PSH=1時，表明接收方應立即將資料報交給上層；復位RST，當RST=1時，表明TCP連接出現錯誤，必須釋放連線；同步SYN，在建立連線時用來同步序號。當SYN=1，ACK=0時表明是連線請求報文；響應報文為SYN=1，ACK=1；終止FIN，用來釋放連線；

檢驗和，2位元組；緊急指標，2位元組；選項。

序號和確認號：TCP把資料看做有序無結構的位元組流，用序號對每個傳輸的位元組進行編號。由於TCP是全雙工服務，在主機A向主機B傳送報文的同時A也會接收B傳送的報文，確認號則是接收方希望傳送方傳送的下一位元組的序號。例如A已收到B傳送的序號為0-535的所有位元組，則A會在發給B的報文段的確認號中填入536。如果A在收到536-899之前收到900-1000，則確認號仍為536，這叫TCP的累積確認。

4.2 往返時間的估計和超時

TCP採用超時/重傳的機制來處理丟失的報文段，但超時間隔長度的設定是個問題。往返時間（RTT）

報文段的樣本RTT（SampleRTT）表示從某報文段被髮出到接收到確認的時間。TCP在某些時刻做一次SampleRTT測量，從而維持一個平均的RTT（EstimatedRTT），EstimatedRTT = (1-a)*EstimatedRTT+a*SampleRTT，a一般取0.125。同時定義RTT偏差DevRTT，DevRTT = (1-b)DevRTT+b*|EstimatedRTT - SampleRTT|，b取0.25。

重傳時間TimeoutInterval=EstimatedRTT+4*DevRTT，初始的重傳時間取1秒。

4.3 可靠資料傳輸

TCP的定時器管理過程只使用單一的重傳定時器。

首先給出TCP高度簡化的描述：傳送方只用超時來恢復報文段的丟失。傳送方有3個與傳送和重傳有關的事件：（1）TCP從應用程式接收資料，並編號交給IP，若定時器未啟動則啟動定時器（2）超時，則重傳超時的報文段，並重啟定時器（3）收到確認，採用累積確認，，所以當前確認號之前的所有報文段都已被接收，若仍有未確認的報文段，重啟定時器。累積確認詳見書圖3.36。

超時間隔加倍：TCP每次重傳都會將下一次超時間隔設為當前值的兩倍，而不是通過EstimatedRTT設定。這是一種簡單的擁塞控制。

快速重傳：超時間隔加倍會增加端到端時延。而由於接收端累積確認，在未收到期望序號報文段時會不斷的傳送相同的ACK確認號，此為冗餘ACK。當接收端收到3個冗餘ACK時，TCP就執行快速重傳，在定時器過期前重傳丟失的報文段。

4.4 流量控制

TCP為其應用程式提供流量控制服務以消除傳送方使接收方快取溢位的可能性。TCP的流量控制通過接收視窗來實現，用於給傳送方表明接收方還有多少可用的快取空間。接收視窗用rwnd表示，有一個情況：A向B通訊，當B快取滿了的時候，他返回的報文段中rwnd=0，如果B的應用程式將快取清空了，同時B沒有資料要向A傳送，則A不能知道B的快取清空。TCP規定在rwnd=0時A繼續傳送一個位元組資料的報文段。

4.5 TCP連線管理

三次握手：

為什麼是3次握手？

1、主要是為了防止已經失效的連線請求報文突然又傳送到了伺服器，從而產生錯誤連線。2、改為兩次握手可能產生死鎖。假設A向B傳送請求，B收到請求後傳送確認訊號。此時如果按照兩次握手協議，連線已建立，B開始傳輸資料。然後如果B的確認訊號A沒有接受到，A將不能知道B的序列號，將無法接受B的資料。而B在傳送資料超時後會重複傳送資料，從而死鎖。

四次揮手：

為什麼要客戶端要等待2MSL（報文最大生存時間）？

1、保證客戶端傳送的最後一個ACK報文能夠到達伺服器。2、如果客戶端直接進入closed狀態，而服務端還有資料在網路中，當有一個新連線的埠和服務端埠一樣時，那麼客戶端會認為這些資料是新連線的。

當主機接收到一個TCP報文段，其埠號或源IP地址與該主機上進行中的套接字都不匹配，此時主機會向源傳送一個特殊的重置報文段，其RST標誌位置1.

4.6 擁塞控制

擁塞的原因：傳送流量超過鏈路容量，重傳機制，

擁塞的代價：當分組的到達速率接近鏈路容量時，分組經歷的排隊時延是巨大的；傳送方在遇到大時延時進行的不必要重傳會引起路由器來轉發不必要的分組；一個分組沿一條路徑被丟棄時，每個上游路由器用於轉發該分組的傳輸容量被浪費。

擁塞控制的方法：（1）端到端擁塞控制，網路層並沒有為運輸層的擁塞控制提供支援，TCP運用的方式，只能推斷是否發生擁塞。（2）網路輔助的擁塞控制，路由器可以向傳送端反饋網路的擁塞情況，但還未被用於TCP中。

4.7 TCP擁塞控制（加性增、乘性減（AIMD）擁塞控制方法）

TCP採用的方法是讓每一個傳送方根據所感知到的網路擁塞程度來限制其能向連線傳送流量的速率。

如何調整發送方的傳送速率：在傳送方跟蹤一個變數，即擁塞視窗（cwnd），其對一個TCP傳送方能向網路中傳送流量的速率進行了限制（傳送方中未被確認的資料量不超過cwnd和rwnd的最小值）。

如何感知擁塞：通過出現超時或3次冗餘ACK來確認是否發生擁塞。

TCP傳送方能夠以更高的速率傳送而不會使網路擁塞，有三個原則：（1）一個丟失的報文段意味擁塞，此時應降低TCP傳送方速率（減小cwnd的大小）。（2）一個確認報文段指示網路正在向接收方交付傳送方的報文段，此時可以增加發送方的速率。（3）頻寬探測

TCP擁塞控制演算法：慢啟動，擁塞避免，快速恢復

（1）慢啟動

當TCP連線開始時，cwnd的值置為1個MSS（最大報文段長度），每當傳輸的報文段首次被確認就增加1個MSS，因此cwnd以指數增長。

指數增長的結束方案：（1）如果出現超時的丟包事件，將慢啟動閾值ssthresh置為cwnd/2，並將cwnd重新置為1並重新開始慢啟動。（2）當新的cwnd增長到超過ssthresh時，結束慢啟動進入擁塞避免模式。（3）如果檢測到3個冗餘ACK則進入快速恢復狀態。

（2）擁塞避免

每個RTT（往返時間）只增加一個MSS。假設當前MSS為1460位元組而cwnd為14600位元組，則一個RTT傳送10個報文段，每到達一個ACK增加MSS/10的擁塞視窗長度，當收到10個報文段的所有ACK時增則會增加1個MSS。

當出現超時時，將ssthresh置為cwnd/2，同時將cwnd置為1，開始慢啟動。當出現3次冗餘ACK時，表示當前網路仍可以交付，TCP將ssthresh置為cwnd/2，同時cwnd=cwnd/2+3MSS，並進入快速恢復。

（3）快速恢復

在快速恢復中，對於引起TCP進入快速恢復狀態的缺失報文段，每收到一個它的冗餘ACK就將cwnd增加一個MSS。當收到丟失報文段的ACK時，cwnd=ssthresh，並進入擁塞避免。如果在這個階段超時，同樣進入慢啟動。

TCP擁塞控制的FSM

公平性：在K條TCP連線經過傳輸速率為R的鏈路時，如果每條連線的平均傳輸速率接近R/K，則認為該擁塞控制是公平的。在每條TCP連線的RTT相等的情況下，上述TCP擁塞控制是公平的（詳見圖3.56），但實際中RTT小的連線會有更高的吞吐量。