《計算機網絡-自頂向下的方法》第三章-運輸層-閱讀筆記

寫在前面

計算機網絡分了五層（應用層，運輸層，網絡層，鏈路層，物理層），《自頂向下》的第三章詳細講解了運輸層的兩大協議以及其背後原理，其中tcp協議是本章乃至整個計算機網絡的一個重點內容，鑑於此，我以爲有必要對本章做個筆記，以鞏固運輸層的知識。

正文

運輸層的目的在於爲不一樣主機(host)上的應用或者說進程提供邏輯通訊——經過運輸層協議，兩臺電腦彷彿直接相連同樣。應用無需知道底層內部實現的原理和細節，好比怎麼把遠隔世界兩地電腦上的數據進行相互傳輸。

本章的一些注意點：

• 運輸層協議僅僅實如今網絡的邊緣處，例如主機，電腦，手機等。如路由器，交換機這些網絡核心設備，是沒有實現運輸層協議的
• 每一層協議僅僅檢查分組相應的協議層字段
• 最經常使用的兩種輸入層協議，tcp和udp
• 運輸層的下面是網絡層，網絡層的目的在於爲不一樣的主機提供邏輯通訊，而非主機上的進程
• 網絡層經常使用協議是IP，其提供的是一種不可靠的數據傳輸服務
• 爲了作到爲不一樣主機(host)上的應用或者說進程提供邏輯通訊這一目的，運輸層協議必須能分辨出數據的來源和去向。爲此，運輸層存在着兩種行爲，多路複用和多路分解

多路複用

當運輸層收到來自上方應用層的數據時，運輸層會爲數據封上一些頭部信息，根據全部協議不一樣，封上的信息也不同。這一行爲，被稱爲多路複用。

多路分解

當運輸層收到下方網絡層傳輸來的數據時，運輸層會檢查多路複用時封上的信息，從而正確的把數據定向到相應的進程。

如何使用運輸層的協議？ 操做系統提供了被稱爲socket的接口api供編程人員調用，對socket的形象理解是其是一種抽象，將複雜的實現(tcp, udp)協議的各類行爲抽造成簡單的幾個函數給開發人員使用。就像瀏覽器將發送請求報文這一http協議規定的行爲，抽象成咱們只須要輸入url而後回車便可。

這裏須要注意的一點是，在通常狀況下，一個計算機端口只能被一個進程佔用。一個進程能夠建立多個socket，多個tcp socket能夠監聽同一個端口，並保證接受的數據依舊是正確的。但多個udp socket就沒法監聽同一端口。這其中的差別源於tcp和udp協議的不一樣，tcp是面向鏈接的，其有足夠狀態的信息來分辨數據來源，後定向到正確的socket。但udp不須要維持鏈接，僅僅經過端口號來決定數據的去向，因此會致使衝突。

udp的多路複用和分解

一個udp socket經過一個二元組(目的ip地址，目的端口號)來標識，當輸入層收到數據時，經過檢查這個二元組，來定向數據該去往哪個udp socket。這也是爲何多個udp socket沒法監聽同一個端口的緣由，由於系統沒法再根據二元組來肯定消息的去向（它們的二元組是同樣的）。

TCP的多路複用分解

一個tcp socket經過一個四元組(源ip，源端口，目的ip，目的端口號)來標識，這也解釋爲何多個tcp socket能夠監聽同一個端口，儘管目的ip和目的端口號是同樣的，可是源ip和源端口的組合老是不一樣的。

UDP

相比於TCP來說，UDP是一個簡單的協議，就是把網絡層IP提供的服務封裝了下，實現了多路複用和分解，提供了端到端進程間的通訊和錯誤檢驗服務。

相對於TCP來講：

• UDP是不可靠的傳輸服務
• 沒有流量和擁塞控制

但：

• 可以夠精細的控制數據的發送時間和速率
• 無需事先創建鏈接
• 無鏈接狀態
• 分組首部開銷小

封裝

在接收到應用層傳輸來數據後，在數據前方加上了四個字段，分別是源端口號、目的端口號、長度（包括頭部）、檢驗和，應用數據。

可靠數據傳輸

數據傳輸可能遇到的問題:

• 傳輸中數據被損壞
• 數據丟失
• 數據可能亂序到達

解決方法：

• 檢驗和
• 序號
• 定時器
• 確定和否認反饋分組

如何在保證可靠性的前提下，提升其性能？

• 經過引入流水線(pipelining)技術

引入流水線致使了：

• 序號範圍須要增長
• 收發雙方可能須要緩存亂序到達的分組
• 以上兩個的具體實現取決於傳輸協議如何處理分組丟失、損壞的問題(是選擇回退N步，仍是選擇重傳)

回退N步

其核心在於，發送方會維持一個窗口，發送方能發送的數據量取決於窗口長度，而且當丟失時會重送全部未確認的分組。

接收方會丟棄亂序到達的緩存

特色：

• 累計性ACK
• 單必定時器

選擇重傳

核心在於，收發雙方都會維持一個窗口，而且盡力保證窗口的狀態是同步的，所以當分包丟失時，發送方只會重送丟失的分組。

接收方會緩存亂序到達的分組

特色：

• 獨立性ACK
• 多個定時器

TCP

特色：

• 面向鏈接
• 全雙工的
• 點對點，不存在一次發送將數據傳遞給多個接收方、
• 在合適的時候發送 發送緩存 裏的數據
• 爲每一個數據封上一個TCP頭部
• TCP鏈接的每一端都具備發送緩存和接受緩存

報文段結構

• 源端口號

• 目的端口號

• 序號(seq) - 所帶數據的第一個比特的序號，同時也是接收方期待的序號，等於接收方回覆報文中的ACK(n)中的n

• 確認號(ACK) - 對於一個ACK(n)來講，告訴對方n-1前的數據已經收到，下一次期待的序列號爲n

• 首部長度

• URG

• ACK - 指示，用於指示報文中確認號字段的值是有效的

• PSH - 指示，當即發送發送緩存裏的數據

• RST - 指示，用於強制關閉鏈接

• SYN - 指示，用於握手階段也就是創建鏈接的階段

• FIN - 指示，用於正常關閉鏈接

• 接受窗口 - 用於TCP的流量控制功能

• 因特網檢驗和

• 緊急數據指針

• 選項

• 應用數據

可靠數據傳輸

• TCP協議爲數據的每一Byte都編號，而非針對報文段
• 老是維持最老未經確認的1 Byte的計時器
• 每一次超時重置的計時器時間會加倍
• 其錯誤恢復機制是回退N步和選擇重傳的混合體
  • 不會丟棄亂序到達的分組，而是緩存起來
  • 採用累計性ACK
  • 只會重傳丟失報文段中的數據

快速重傳

當連續收到4個相同的ACK時(一個正常的ACK，三個正常ACK的重複)，會觸發快速重傳，當即重發分組

流量控制

爲了防止太高數據流量致使接收者的接受緩存爆掉，接收者會在其tcp報文中經過 接受窗口 指示發收者還能發送多少數據

接受窗口(rwnd)公式:

• rwnd = RcvBuffer - [LastByteRead - LastbyteRead]
• 且：LastByteSent - LastByteAcked <= rwnd

TCP鏈接管理

創建鏈接（三次握手）

1. 客戶端發送SYN位置1的報文段
2. 服務端返回SYN爲1，ACK爲1的報文段
3. 客戶端發送ACK爲1，且附帶數據的報文段

斷掉鏈接

1. 客戶發送FIN爲1的報文段
2. 服務端返回ACK爲1的報文段
3. 服務端發送FIN爲1的報文段
4. 客戶端返回ACK爲1的報文段
5. 客戶端在一段時間後，關閉鏈接

擁塞控制

擁塞的代價

• 致使分組過長的排隊時延
• 須要重傳因緩存溢出丟失的分組
• 高延時致使重送分組
• 丟包致使運輸相關分組的分組交換器所做的工做所有白費

TCP的擁塞控制

TCP採用端到端的擁塞控制

三個主要問題：

1. 一個TCP的發送方如何限制本身的發送流量的速率？

經過設置一個擁塞窗口(cwnd),而且保證：LastByteSent - LastByteAcked <= min{cwnd, rwnd}

2. 如何感知其發送路徑擁塞了？

• timeout
• 收到一次正常ACK後連續收到三次正常ACK的重複

3. 感到擁塞時，採用什麼樣的算法改變發送速率？

• 慢啓動

cwnd的值從1 MSS開始，而且對每個ACK，cwnd值變爲原來的2倍，直到超過閾值(ssthresh)，轉爲擁塞避免模式

• 擁塞避免

在每個RRT時間，cwnd的值增長一個MSS

• 快速恢復

cwnd的值降爲一半加上重複收到的重複ACK的數量，而且每個ACK，cwnd的值增長一個MSS

在實踐中，一旦timeout就會會到慢啓動的狀態，屢次重複ACK則會進入快速恢復狀態

TCP公平

TCP的公平性在於保證每一個鏈接的吞吐量是平均的，而不是應用或進程間。