網絡讀書筆記-運輸層

領會和表達複雜世界背後的簡單性的能力是給我罕見和絕妙的禮物 —— Van Jacobson

運輸層和網絡層：在協議棧中，運輸層恰好位於網絡層之上。網絡層提供了主機之間的邏輯通訊，而運輸層爲運行在不一樣主機上的進程之間提供了邏輯通訊。運輸層只工做在端系統中，運輸層協議未來自應用進程的報文移動到網絡邊緣（即網絡層）。

咱們將特別關注因特網協議，即TCP和UDP運輸層協議。因特網（更通常地講是一個 TCP/IP 網絡）爲應用層提供了兩種大相徑庭的可用傳輸層協議：一種是UDP（用戶數據報協議），它爲調用它的應用程序提供了一種不可靠、無鏈接的服務；另外一種是TCP（傳輸控制協議），它爲調用它的應用程序提供了一種可靠的、面向鏈接的服務。

在介紹TCP/UDP以前，先來學習運輸層的多路複用與多路分解：將由網絡層提供的主機到主機交付服務延伸到爲運行主機上的應用程序提供進程到進程的交付服務。考慮接收主機怎樣將一個到達的運輸層表文段定向到適當的套接字？爲此目的，每一個運輸層報文段中具備幾個字段，在接收端運輸層檢查這些字段，標識出接收套接字，進而將報文段定向到該套接字。將運輸層報文段中的數據交付到正確的套接字的工做稱爲多路分解。在源主機從不一樣套接字中收集數據塊，併爲每一個數據塊封裝首部信息（用於分解）從而生成報文段，而後將報文段傳遞到網絡層，這些工做稱爲多路複用。

1. 無鏈接傳輸：UDP

UDP 報文段結構：

圖1 UDP報文段結構

UDP 首部只有4個字段，每一個字段由兩個字節組成，共8字節。

圖2 查看UDP報文段結構

2. 可靠數據傳輸原理

2.1 構造 可靠數據傳輸協議（rdt）

rdt1.0 經徹底可靠信道的可靠數據傳輸

考慮了簡單的狀況，假設底層信道是徹底可靠的。發送方和接收方的有限狀態機（FSM）定義：

rdt2.0 經具備比特差錯信道的可靠數據傳輸

爲了可靠通訊，加上了具備 ACK, NAK 的重傳機制，基於自動自動重傳機制的可靠數據傳輸協議稱爲 自動重傳請求（ARQ）協議。爲了處理比特差錯，ARQ還須要另外三種協議功能來處理存在比特差錯狀況：差錯檢測，接收方反饋，重傳（接收方收到差錯分組時，發送方重傳該分組）。

僅當接收到ACK並離開該狀態時才能再次發送數據rdt_send(data)，所以，除非發送方確信接收方已正確接收當前分組，不然發送方將不會發送新數據。像rdt2.0這樣的協議被稱爲停等（stop-and-wait）協議。

看起來能夠運行，可是有一個致命的缺陷，尤爲是沒有考慮ACK或NAK分組丟失的狀況。

rdt2.1 rdt2.0 + 序號 用來處理受損的 ACK 和 NAK。

rdt2.2 在具備比特差錯信道上實現的一個無NAK的可靠傳輸協議；（使用校驗和、序號、ACK分組、重傳）

rdt3.0 比特交替協議 （一個可能出錯和丟包的信道上可靠傳輸數據的協議）rdt2.2+定時器

rdt2.2已經有足夠的功能（序號）來處理冗餘分組的狀況。從發送方觀點來看，重傳是一種萬能靈藥。發送方不知道是數據分組丟失仍是（接收方回傳的）ACK丟失，或者只是該分組或者ACK過分延遲。在全部這些狀況下，動做均可採用：重傳！爲了實現基於時間的重傳機制，須要一個倒計時計數器，在一個給定的時間量過時後，可中斷髮送方。

優化：由於停等協議利用率過低，因此要提升利用率，使用可以容許發送方發送多個分組而無需等待確認的流水線技術（流水線可靠數據傳輸協議）。流水線技術對 rdt 可帶來以下影響：

• 必須增長序號範圍。
• 協議的發送方和接收方兩端也許必須緩存多個分組。
• 所需序號範圍和對緩衝的要求取決於數據傳輸協議如何處理丟失、損壞及延時過大的分組。解決流水線的差錯恢復有兩種基本方法：回退N步（go-back-n, GBN）和 選擇重傳（selective repeat, SR）。

圖3.18：停等和流水線發送

2.2 回退N步 (GBN)

在回退N步(GBN)協議中，容許發送方發送多個分組而不需等待確認，但它也受限在流水線中未確認的分組數不能超過某個最大容許數N。

圖3.19 在GBN中發送方看到的序號

在GBN協議中，接收方丟棄全部失序分組，以達到按序將數據交付給上層的任務。（假定如今指望接收分組n, 而分組n+1卻到了，採起丟棄分組n+1的策略，直到分組n被正確接收）。

這種方法的有點是接收緩存簡單（即接收方不須要緩存任何失序分組），發送方需維護窗口的上下邊界([base, base+N))及下一個序號(nextseqnum)在該窗口的位置，可是接收方須要維護的惟一信息就是下一個按序接收分組的序號(expectedseqnum)。

圖3.22 GBN操做

GBN協議中綜合了使用序號、累計確認、校驗和以及超時/重傳操做。

2.3 選擇重傳 (SR)

選擇重傳(SR)協議經過讓發送方僅重傳那些它懷疑在接收方出錯（即丟失或受損）的分組而避免了沒必要要的重傳。這種個別的、按需的重傳要求接收方逐個地確認正確接收的分組。

圖3.26 SR操做

咱們知道要掌握 TCP 協議，重點應該關注如下幾個問題： （極客時間-趣談網絡協議）

• 順序問題 ，穩重不亂；
• 丟包問題，承諾靠譜；
• 鏈接維護，善始善終；
• 流量控制，把握分寸；
• 擁塞控制，知進知退。

3. TCP協議

TCP是因特網運輸層的面向鏈接的可靠運輸協議。

TCP是面向鏈接的，這是由於在一個應用進程開始向另外一個應用進程發送數據以前，這兩個進程必須先互相「握手」，即它們必須相互發送某些預備報文段，以創建確保數據傳輸的參數。TCP鏈接提供的是全雙工服務。

3.1 TCP 報文段結構

圖3.29 TCP報文段結構

TCP首部共20字節。包含：16(源端口號)+16(目的端口號)+32(序號)+32(確認號)+4(首部長度)+(6+6)(flags)+16(接收窗口)+16(因特網校驗和)+16(緊急數據指針) = 160比特 = 20字節。

實際抓到的包開始看到的都是Seq=0, 實際上是WireShark的設置：

事實上，握手時 Seq 號並非從 0 開始的。咱們之因此在 Wireshark 上看到 Seq=0 ，是由於 Wireshark 啓
用了 Relative Sequence Number 。若是你想關閉這個功能，能夠在 Edit-->Preferences-->protocols-->TCP 裏設置。

設置以後能夠看到Seq、Ack與首部數據對應了。

圖3.30 查看TCP的報文段結構

序號和確認號：TCP報文段首部中兩個最重要的字段是序號字段和確認號字段。這兩個字段是TCP可靠傳輸服務的關鍵部分。重點，序號和確認號計算：

Len ：該數據段的長度，如圖 5 中的 Len=1448 ，注意這個長度不包括 TCP 頭。圖 5 中雖然 10.32.106.62 發出的兩個包 Len=0 ，但實際上是有
TCP 頭的。頭部自己攜帶的信息不少，因此不要覺得 Len=0 就沒意義。
Ack ：確認號，如圖 5 中的 Ack ＝ 6577 ，接收方向發送方確認已經收到了哪些字節。
好比甲發送了 「Seq: x Len: y」 的數據段給乙，那乙回覆的確認號就是 x+y ，這意味着它收到了 x+y 以前的全部字節。一樣以圖 5 爲例， 52 號包
的 Seq=5129, Len=1448 ，因此來自接收方的 53 號包的 Ack=5129+1448=6577 ，表示收到了 6577 以前的全部字節。理論上，接收方回覆的 Ack
號剛好就等於發送方的下一個 Seq 號，因此咱們能夠看到 54 號包的 Seq 也等於 5129+1448=6577 。

可靠數據傳輸：在發送方，TCP的響應無非就是重傳有問題的報文段。TCP的差錯恢復機制是GBN協議和SR協議的混合體。

3.2 TCP 三次握手，創建鏈接

圖3.31 TCP三次握手以及經歷的典型的TCP狀態序列，左側客戶端右側服務器端，來自極客時間趣談網絡協議

客戶應用進程通知客戶TCP，它想創建一個與服務器上某個進程之間的鏈接。客戶端的 TCP 會用如下方式與服務器中的TCP創建一條TCP鏈接：

1. 客戶端的TCP首先向服務器的TCP發送一個特殊的TCP報文段。在報文段的首部中的一個標誌位（即SYN）被置爲1。（所以，這個特殊報文段被稱爲 SYN報文段。）另外，客戶會隨機選擇一個初始序號client_isn（圖3.31中的x），並將此編號放置於該其實的TCP SYN報文段的序號字段seq中。該報文段會被封裝在一個IP數據報中，併發送給服務器。（該報文段中不包含應用層數據）。
2. 一旦包含 TCP SYN 報文段的IP數據報到達服務器主機，服務器會從該數據報中提取出 TCP SYN 報文段，爲該TCP鏈接分配TCP緩存和變量，並向該客戶TCP發送容許鏈接的報文段。（握手第三步以前分配這些緩存和變量，使得TCP易於受到稱爲SYN洪泛/洪水SYN Flood的拒絕服務攻擊DoS）。在報文段首部包含三個重要信息：SYN比特被置爲1；TCP 報文段首部的確認號字段ack被置爲client_isn+1；服務器選擇本身的初始序號server_isn（圖3.31中的y）並將其放到TCP報文段首部的序號字段seq中。該容許鏈接的報文段有時被稱爲SYNACK報文段。(這個報文段中也不包含應用層數據)
3. 在收到SYNACK報文段後，客戶也要給該鏈接分配緩存和變量。這最後一個報文段對服務器容許鏈接的報文段進行了確認（客戶經過將y+1放置到TCP報文段首部的確認字段ack中來完成此工做）。鏈接結束，將SYN置0。

3.3 TCP 四次揮手，關閉鏈接

天下沒有不散的宴席，對於TCP也是同樣。參與一條TCP鏈接的兩個進程中的任何一個都能終止該鏈接。

圖3.32 TCP四次揮手以及經歷的典型的TCP狀態序列，來自極客時間趣談網絡協議

圖3.40 簡潔版本的關閉TCP鏈接

從客戶關閉鏈接舉例（客戶端也可主動關閉該鏈接）：

客戶應用進程發出一個關閉鏈接命令。這會引發客戶TCP向服務器進程發送一個特殊的TCP報文段（讓其首部中的一個標誌位即 FIN 比特被設置爲1），當服務器接收到該報文段後，就向發送方回送一個確認報文段。而後，服務器發送它本身的終止報文段（其FIN比特被置爲1）。最後，該客戶對這個服務器的終止報文段進行確認。此時，在兩臺主機上用於該鏈接的全部資源都被釋放了。

參考

1. 《計算機網絡自頂向下》 第六版
2. 《Wireshark網絡分析就這麼簡單》