計算機網路：運輸層
運輸層服務
運輸層協議為執行在不同主機上的應用程序之間提供了邏輯通訊 (logic communication) 功能。
運輸層協議是在端系統中而不是在路由器中實現的 。 在傳送端，運輸層將從傳送應用程式程序接收到的報文轉換成運輸層分組（運輸層報文段，segment）。
實現的方法（可能）是將應用報文劃分為較小的塊，併為每塊 加上一個運輸層首部以生成運輸層報文段。 然後，在傳送端系統中，運輸層將這些報文段 傳遞給網路層，網路層將其封裝成網路層分組（即資料報）並向目的地傳送。**網路路由器僅作用於該資料報的網路層欄位，即它們不檢查封裝在該資料報的運輸層報文段的欄位。**在接收端，網路層從資料報中提取運輸層報文段，並將該報文段向上交給運輸層。運輸層則處理接收到的報文段，使該報文段中的資料為接收應用程序使用。
網路應用程式可以使用多種的運輸層協議 。例如，因特網有兩種協議，即 TCP 和 UDP。每種協議都能為呼叫的應用程式提供一組不同的運輸層服務。
因特網網路層協議有一個名字叫 IP ，即網際協議。IP 為主機之間提供了邏輯通訊。 IP 的服務模型是盡力而為交付服務（ best-effort delivery service）。這意味著 IP 盡它“最大的努力”在通訊的主機之間交付報文段，但它並不做任何確保。特別是：
- 它不確保報文段的交付；
- 不保證報文段的按序交付；
- 不保證報文段中資料的完整性。
由於這些原因，IP 被稱為不可靠服務（unreliable service）。在此還要指出的是，每臺主機至少有一個網路層地址，即所謂的 IP 地址 。
將主機間交付擴充套件到程序間交付被稱為運輸層的多路複用（transport-layer multiplexing）與多路分解（demultiplexing）。
TCP還為應用程式提供了幾種附加服務：
- 可靠資料傳輸（reliable data transfer）：通過使用流量控制、序號、確認和定時器, TCP 確保正確地、按序地將資料從傳送程序交付給接收程序。
- 擁塞控制（congestion control）：TCP 擁塞控制防止任何一條 TCP 連線用過多流量來淹沒通訊主機之間的鏈路和交換裝置。TCP 力求為每個通過一條擁塞網路鏈路的連線平等地共享網路鏈路頻寬。這可以通過調節 TCP 連線的傳送端傳送進網路的流量速率來做到。在另一方面， UDP流量是不可調節的。使用 UDP傳輸的應用程式可以根據其需要以其願意的任何速率傳送資料。
多路複用與多路分解
多路複用與多路分解，也就是將由網路層提供的主機到主機交付服務延伸到為執行在主機上的應用程式提供程序到程序的交付服務。
一個程序（作為網路應用的一部分）有一個或多個 套接字（socket），它相當於從網路向程序傳遞資料和從程序向網路傳遞資料的門戶。因此，在接收主機中的運輸層實際上並沒有直接將資料交付給程序，而是將資料交付給了一箇中間的套接字 。由於在任一時刻，在接收主機上可能有不止一個套接字，所以每個套接字都有唯一的識別符號。識別符號的格式取決於它是 UDP 還是 TCP 套接字。
將運輸層報文段中的資料交付到正確的套接字的工 作稱為多路分解（demultiplexing）。在源主機從不同套接字中收集資料塊，併為每個資料塊封裝上首部資訊（這將在以後用於分解）從而生成報文段，然後將報文段傳遞到網路層，所有這些工作稱為多路複用（multiplexing）。
- 套接字有唯一識別符號;
- 每個報文段有特殊欄位來指示該報文段所要交付到的套接字。欄位是源埠號欄位(source port number field)和目的埠號欄位( destination port number field)
- 無連線的多路複用與多路分解：一個 UDP 套接字是由一個二元組來全面標識的，該二元 組包含一個目的 IP 地址和一個目的埠號。
- 面向連線的多路複用與多路分解：一個TCP套接字是由一個四元組(源 IP 地址，源埠號，目的 IP 地址，目的埠號)來標識的。
無連線運輸：UDP
UDP 只是做了運輸協議能夠做的最少工作。除了複用/分解功能及少量的差錯檢測外，它幾乎沒有對 IP 增加別的東西。
有許多應用更適合用 UDP：
- 關於何時、傳送什麼資料的應用層控制更為精細。
- 無需連線建立。
- 無連線狀態。
- 分組首部開銷小。每個 TCP 報文段都有 20 位元組的首部開銷，而 UDP 僅有 8 位元組的開銷。
UDP報文段結構
| 源埠號 | 目的埠號 | 長度 | 檢驗和 | 單位 |
|---|---|---|---|---|
| 8 | 8 | 8 | 8 | 位元 |
UDP檢驗和
傳送方的 UDP 對報文段中的所有 16 位元字的和進行反碼運算，求和時遇到的任何溢位都被回捲（加 1 ）。得到的結果被放在 UDP 報文段中的檢驗和欄位。
可靠傳輸原理
實現這種服務抽象是可靠資料傳輸協議(reliable data transfer protocol)的責任。
經完全可靠信造的可靠資料傳輸: rdt 1.O
經具有位元差錯通道的可靠資料傳輸: rdt 2.0
這種報文協議使用了肯定確認(positive acknowledg- ment)與否定確認(negativeacknowledgment)。這些控制報文使得接收方可以讓傳送方知道哪些內容被正確接收，哪些內容接收有誤並因此需要重複。在計算機網路環境中，基於這樣重傳機制的可靠資料傳輸協議稱為自動重傳請求(Automatic Repeat reQuest, ARQ)協議。
rdL2.1：考慮到 Ack 或 NAck 丟失或損壞的情況，在資料分組中新增一新欄位，讓傳送方對其資料分組編號，即將傳送資料分組的序號(sequencenumber)放在該欄位。於是，接收方只需要檢查序號即可確定收到的分組是否是一次重傳。
對於停等協議這種簡單情況，1 位元序號就足夠了，因為它可讓接收方知道傳送方是杏正在重傳前一個傳送分組(接收到的分組序號與最近收到的分組序號相同)，或是一個新分組(序號變化了，用模 2 運算“前向”移動)。
經具有位元差錯的丟包通道的可靠資料傳輸: rdt 3.0
為了實現基於時間的重傳機制，需要一個倒計數定時器(countdown timer)，在一個給定的時間量過期後，可中斷髮送方。
流水線可靠資料傳輸協議
回退 N 步(Go-Back-N，GBN)
在回退 N 步(GBN)協議中，允許傳送方傳送多個分組(當有多個分組可用時)而不需等待確認，但它也受限於在流水線中未確認的分組數不能超過某個最大允許數 N。
隨著協議的執行，該視窗在序號空間向前滑動。因此，N 常被稱為視窗長度(window size), GBN 協議也常被稱為滑動視窗協議(sliding-window protocol)。
使用累積確認是 GBN 一個自然的選擇。
在 GBN 協議中，接收方丟棄所有失序分組。
選擇重傳(Selective Repeat, SR)
選擇重傳(SR)協議通過讓傳送方僅重傳那些它懷疑在接收方出錯(即丟失或受損)的分組而避免了不必要的重傳。
SR 接收方將確認一個正確接收的分組而不管其是否按序。失序的分組將被快取直到所有丟失分組(即序號更小的分組)皆被收到為止，這時才可以將一批分組按序交付給上層。
面向連線的運輸：TCP
- TCP 被稱為是面向連線的（ connection- oriented ）。
- TCP 連線提供的是全雙工服務 (full-duplex service ）。
- TCP 連線也總是點對點（ point-to-point ）的。
三次握手初期設定的傳送快取（ send buff er ），TCP 可從快取中取出並放人報文段中的資料數量受限於最大報文段長度（ Maximum Segmenl Size, MSS）， MSS 通常根據最初確定的由本地傳送主機發送的最大鏈路層幀長度（即所謂的最大傳輸單元（ Maximum Transmission Unit, MTU ））來設定。
TCP 報文段結構
TCP 的首部一般是 20 位元組（比 UDP 首部多 12 位元組）。
| 源埠號 | 目的埠號 | 序號 | 確認號 | 首部長度 | 保留未用 | URG | ACK | PSH | RST | SYN | FIN | 接收視窗 | 因特網檢驗和 | 緊急資料指標 | 選項 | 單位 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 16 | 16 | 32 | 32 | 4 | 6 | 1 | 1 | 1 | 1 | 1 | 1 | 16 | 16 | 16 | ~ | bit |
- 序號和確認號：TCP 把資料看成一個無結構的、有序的位元組流，一個報文段的序號（ sequence number for a segment ）因此是該報文段首位元組的位元組流編號。
- 4 位元的首部長度欄位（ header length field ）：該欄位指示了以 32 位元的字為單位 TCP 首部長度，由於 TCP 選項欄位的原因，TCP 首部的長度是可變的。（通常，選項欄位為空，所以 TCP 首部的典型長度就是 20 位元組。）
- 可選與變長的選項欄位（ options field ）：該欄位用於傳送方與接收方協商最大報文
段長度（ MSS ）時，或在高速網路環境下用作視窗調節因子時使用。 - 16 位元的接收視窗欄位( receive window field )：該欄位用於流量控制 。
往返時間的估計與超時
- 估計往返時間
大多數 TCP 的實現僅在某個時刻做 SampleRTT 測量，而不是為每個傳送的報文段測量一個 SampleRTT。
TCP 維持一個 SampleRTT 均值（稱為 EstimatedRTT) 一旦獲得一個新 SampleRTT 時， TCP 就會根據下列公式來更新 EstimaLedRTT：
EstimatedRTT = (1 - α）· EstimatedRTT + α·SampleRTT（α=0.125）
RTT 偏差 DevRTT，用於估算 SampleRTT一般會偏離 EstimatedRTT 的程度：
DevRTT = (1-β）· DevRTT + β·|SampleRTI - EstimatedRTT|（β=0.25）
- 設定和管理重傳超時間隔
TimeoutInterval = EstimatedRTT + 4·DevRTT
推薦的初始 TimeoutInterval 值為 1 秒，當出現超時後，TimeoutInterval 的值將加倍，以免即將被確認的後繼報文段過早出現超時。且一旦報文段收到並更新 EstimatedRTT 後，需要使用上述公式重新計算TimeoutInterval。
可靠資料傳輸
在 TCP 傳送方有3個與傳送和重傳有關的主要事件：從上層應用程式接收資料；定時器超時和收到 ACK。
- 超時間隔加倍
- 快速重傳：如果 TCP 傳送方接收到對相同資料的 3 個冗餘 ACK ，就執行快速重傳（fast retransmit)。
- 由於 TCP 只是對已經接收到的最後一個按序位元組資料進行重複確認，所以當接收到的報文段失序時可能會產生一個冗餘 ACK。
- TCP 的差錯恢復機制為 GBN 協議與 SR 協議的混合體。
流量控制
TCP 通過讓傳送方維護一個稱為接收視窗（ receive window ，rwnd）的變數來提供流量控制。通俗地說，接收視窗用於給傳送方一個指示一一該接收方還有多少可用的快取空間：
- LastByteRead：主機上的應用程序從快取讀出的資料流的最後一個位元組的編號。
- LastByteRcvd：從網路中到達的並且已放入主機 接收快取中的資料流的最後一個位元組的編號。
- LastByteRcvd - LastByteRead ≤ Rev Buffer
- rwnd = RcvBuffer - （LastByteRcvd - LastByteRead）
- 傳送方：LastByteSent - LastByteAcked ≤ rwnd
TCP 連線管理
SYN->SYNACK->FIN->ACK
擁塞控制原理
擁塞資訊從網路反饋到傳送方的兩種方式：
- 直接反饋資訊可以由網路路由器發給傳送方，通常採用了一種阻塞分組（ choke packet ）的形式。
- 路由器標記或更新從傳送方流向接收方的分組中的某個欄位來指示擁塞的產生，一旦收到一個標記的分組後，接收方就會向傳送方通知該網路擁塞指示。（至少要經過一個RTT。）
TCP擁塞控制
執行在傳送方的 TCP 擁塞控制機制跟蹤一個額外的變數，即擁塞視窗( congestion window，cwnd ）。
LastbyteSent - LastByteAcked ≤ min{cwnd，rwnd}
一個 TCP 傳送方的“丟包事件”定義為: 要麼出現超時，要麼收到來自接收方的 3 個冗餘 ACK。
- 慢啟動
cwnd 的值以 1 MSS開始並且每當傳輸的報文段被確認就倍增。
- 超時： TCP 傳送方將 cwnd 設定為 1 並重新開始慢啟動過程，它還將第二個狀態變數的值 ssthresh（“慢啟動闊值”的速記）設定為 cwnd/2。
- cwnd超過ssthresh：轉移到擁塞避免狀態。
- 檢測到3個冗餘ACK：轉移到快速恢復狀態。
- 擁塞避免
每當傳輸的報文段被確認就增加一個MSS。
- 超時：cwnd 的值減半。
- 檢測到3個冗餘ACK：轉移到快速恢復狀態。
- 快速恢復
在快速恢復中，對於引起 TCP 進入快速恢復狀態的缺失報文段，對收到的每個冗餘的ACK, cwnd 的值增加一個 MSS。
- 吞吐量
當擁塞發生時，視窗長度為W位元組。
一條連線的平均吞吐量 = 0.75 ✘ W / RTT
L表示丟包率。
一條連線的平均吞吐量 = 1.22 ✘ MSS / RTT ✔L
- 公平性
擁塞控制機制是多個 TCP 連線最終收斂到共享頻寬的狀態。
影響公平性：
- UDP
- 並行TCP連線