计算机网络（五）传输层详解
目錄
- 第五章 傳輸層
- 5.1 傳輸層概述
- 進程之間的通信
- 網絡層與傳輸層的區別
- 傳輸層的兩個主要協議
- 傳輸層的端口
- TCP/IP傳輸層端口
- 5.2 UDP
- UDP需要實現的功能
- UDP提供的服務
- UDP適合哪些應用
- UDP協議的特點
- UDP基于端口的分用
- UDP報文的首部格式
- 5.3 TCP概述
- TCP最主要的特點
- TCP面向流的概念
- TCP的連接
- Socket不同的含義
- 5.4 TCP報文格式
- TCP報文段的首部格式
- 為什么要規定MSS
- 其他選項
- 5.5 可靠傳輸的工作原理
- 理想的傳輸條件特點
- 停止等待的協議
- 自動重傳請求ARQ
- 信道利用率
- 流水線傳輸
- 連續ARQ協議
- TCP可靠通信的具體實現
- 5.6 TCP可靠傳輸的實現
- 以字節為單位的滑動窗口
- 發送緩存
- 發送緩存與接收緩存的作用
- 接收方發送確認
- 超時重傳時間的選擇
- 如何設置超時值
- 加權平均往返時間
- 超時重傳時間RTO
- TCP確認的二義性
- Karn算法
- 修正的Karn算法
- 選擇確認SACK
- RFC 2018的規定
- 5.7 TCP的流量控制
- 利用滑動窗口實現流量控制
- 零窗口特例下死鎖的解決
- TCP的傳輸效率
- 發送方糊涂窗口綜合征
- Nagle算法
- 接收方糊涂窗口綜合征
- TCP流量控制小結
- 5.8 TCP的擁塞控制
- 擁塞控制的一般原理
- 網絡擁塞產生的后果及原因
- 擁塞控制所起的作用
- 開環控制和閉環控制
- 監測網絡擁塞的指標
- TCP的擁塞控制方法
- 網絡擁塞的判斷依據
- TCP擁塞控制算法
- 擁塞窗口的調節策略：AIMD
- TCP擁塞控制流程圖
- 發送窗口的上限值
- 5.9 TCP的傳輸連接管理
- 傳輸連接的三個階段
- 連接建立前的準備
- TCP的三次握手
第五章 傳輸層
5.1 傳輸層概述
傳輸層架構在網絡層形成的服務之上，把數據傳輸服務從兩臺計算機之間擴展到兩臺計算機上的進程之間，網絡層提供盡力而為的服務，而傳輸層是有所為有所不為。
傳輸層提供進程之間本地通信的抽象模式，即運行在不同終端上的應用進程仿佛是直接連接在一起的。
進程之間的通信
傳輸層介乎于應用層和網絡層之間，向上為應用層提供通信服務，屬于面向通信部份的最高層，同時也是用戶功能中的最低層，當網絡邊緣的兩個主機使用網絡核心部分的功能進行端到端的通信時，只有位于網絡邊緣的協議棧才有傳輸層，也就是說網絡核心部分的路由器在轉發分組時只用了下三層的功能。
嚴格來講，兩臺主機進行通信就是兩臺主機中運行的進程相互通信，從傳輸層的角度看，通信的真正端點其實并不是主機本身，而是主機中的進程。
網絡層與傳輸層的區別
網絡層是為主機之間提供邏輯通信，通信所用到的關鍵參數是IP地址，包括源地址和目標地址，而傳輸層是為應用進程之間提供端到端的邏輯通信，其所需要的關鍵參數除了IP地址外還需要傳輸協議及端口號。
而傳輸層的作用體現在一臺主機中經常會有多個應用進程同時分別和另一臺主機中的多個應用進程進行通信，這種情況下傳輸層有一個很重要的功能：復用和分用。
復用是指在發生方不同的應用進程都可以使用同一傳輸協議，通過增加適當的首部傳送數據，分用是指接收方的傳輸層在剝去報文的首部后能夠把這些數據正確交付到目的應用進程，另外傳輸層對接收到的報文進行差錯檢測，在網絡層的IP數據報首部中存在著校驗和字段，但其只對首部的差錯進行校驗，不會對報文本身內容進行校驗。根據應用層的不同需求，傳輸層需要有兩種不同的協議：面向連接的TCP和無連接的UDP。
傳輸層可以為高層用戶建立一條端到端的邏輯通信信道，上層協議不同信道也有很大的差別。當傳輸層采用TCP協議時，邏輯信道采用全雙工可靠信道，當使用無連接的協議時，邏輯信道采用不可靠信道。
傳輸層的兩個主要協議
- 用戶數據報協議UDP：傳送單位是UDP報文或用戶數據報，是一種無連接協議，可提供進程到進程之間的報文交付或報文檢錯
- 傳輸控制協議TCP：傳送單位是TCP報文段，面向連接的協議，不提供廣播或多播服務，因為要提供可靠的傳輸服務因此增加了許多開銷
傳輸層的端口
- 硬件端口：路由器或交換機上的端口
- 軟件端口：在協議棧層間的抽象的協議端口
端口號只具有本地意義，即端口號只是為了標記本計算機應用的進程，在互聯網中不同計算機的端口號是不互相關聯的。兩個計算機要互相通信，不僅要知道對方的IP地址（為了找到計算機），還要知道對方計算機的端口號，這樣就可以找到對方計算機中的應用進程。
TCP/IP傳輸層端口
-
服務器使用的端口號
包括熟知端口，也就是系統的端口號，數值通常為0-1023，還有登記端口，數值通常為1024-49151，為沒有數值端口號的程序使用，使用這個端口號必須在IANA登記，以防止端口重復使用
-
客戶端使用的端口號
又稱為短暫端口號，數值在49152-65535，留給客戶進程選擇暫時使用，該端口屬于動態端口范圍，沒有端口可以被正式地注冊占用，當服務器進程收到客戶進程的報文時，就知道了客戶進程所使用的動態端口號，通信結束后這個端口號可提供其他客戶以后使用
常用的熟知端口：
5.2 UDP
UDP需要實現的功能
UDP只在IP的數據服務基礎上增加了很少的一點功能——復用和分用的功能，報文和差錯檢錯的功能
UDP提供的服務
UDP在網絡服務的基礎上提供進程到進程的報文交付服務以及可選的完整檢查性服務
UDP適合哪些應用
能容忍丟包但對延遲敏感的應用，以單次響應為主的應用
UDP協議的特點
-
UDP是無連接的
發送數據之前不需要建立連接，因此減少了開銷和發送數據之前的時延
-
UDP使用盡最大努力交付
不保證可靠交付，因此主機不需要維持復雜的連接狀態表
-
UDP是面向報文的
UDP對應用層下來的報文既不合并，也不拆分，而是保留這些報文的邊界，UDP以此交付一個完整的報文
-
UDP沒有擁塞控制
網絡出現擁塞不會使源主機發送速率降低
-
UDP支持多種交互通信方式：一對多，多對一
-
UDP首部開銷小
UDP對應用層的報文只添加UDP首部便向下交付，一次交付一個報文，當接收方收到到網絡層的報文后，除去首部向上交付，一次交付一個報文，應用程序必須選擇合適大小的報文，若報文太長UDP把它交付給IP層，IP層再傳輸時可能要進行分片，這會降低IP層的傳輸效率。
UDP基于端口的分用
當傳輸層從IP層收到UDP數據報時，就根據首部的目的端口把UDP數據報分別轉向相應端口，上交到最終的終點，如果接收方UDP收到的目的端口不正確，就丟棄該報文，并由ICMP發送端口不可達的差錯報文給發送方。
UDP報文的首部格式
UDP報文有兩個字段，首部字段有8個字節，共有四個字段組成，每個字段都是兩個字節，UDP報文的報頭是攜帶協議所處理需要的信息，載荷部分是攜帶上層的數據，對應用于復用和分用的字段是源端口號和目的端口號，用于檢測報文錯誤的字段包括了報文總長度及校驗和。
UDP校驗和字段的作用：對傳輸的報文段進行檢錯。
在計算校驗和的時候，把UDP用戶數據報之前的12個字節作為偽首部，臨時把偽首部和UDP用戶數據報連接在一起，僅僅是為了計算校驗和。偽首部其實是IP報文首部的一部分，包括源IP地址，目的IP地址，1字節的全0字段，協議字段數值為17，及UDP的長度字段。
5.3 TCP概述
TCP最主要的特點
- TCP是面向連接的傳輸層協議，會有連接的建立與釋放的過程
- 每一條TCP連接只能由兩個端點，也就是一對一的
- TCP提供可靠交付的服務，流水線式發送，無差錯，無丟失，不重復且能夠按序到達
- TCP提供全雙工通信的方式，兩端都設有發送和接收緩存且實現流量控制
- TCP是面向字節流的。TCP中的流指的是流入或流出進程的字節序列。面向流的含義是雖然應用程序和TCP的交互是一次一個數據塊，但TCP把應用層交下來的數據看成僅僅是一串無節奏的字節流
TCP面向流的概念
TCP不保證接收方應用程序所收到的數據塊和發送方應用程序所發送的數據塊大小具有一一對應的關系，但接收方應用程序收到的字節流必須是和發送方應用程序發出的字節流完全一樣，TCP不關心應用進程一次把多長的報文發送到TCP的緩存中，而TCP對連續的字節流根據當前網絡環境因素進行分段，形成TCP報文段實現數據傳輸。TCP的連接是一條虛連接，而不是一條真正的物理連接，TCP根據對方給出的窗口值和當前網絡擁塞的程度來決定一個報文段應包含多少個字節，而UDP發送的報文段是完全由應用進程所確定的。TCP可把太長的數據塊分段再傳送，也可等待足夠多的字節構成報文段再發送。
TCP的連接
TCP把連接作為最基本的抽象，每一條TCP連接有兩個端點，TCP連接的端點不是主機，不是主機的IP地址，不是應用進程，也不是傳輸層的協議端口，TCP連接的端口被稱作套接字或插口，把端口號拼接到IP地址就構成了套接字。
每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定。
TCP連接就是由協議軟件所提供的一種抽象，TCP連接的端點是個很抽象的套接字：
套接字 socket = （IP地址：端口號）
TCP連接：：={socket1，socket2}={（IP1:port1），（IP2:port2）}
Socket不同的含義
- 應用編程接口API
- socket API中的一個函數名
- 調用socket函數的端點稱為socket
- 調用socket函數時其返回值
- 在操作系統內核中socket實現的概念
以上均與本節所提及的套接字不同
5.4 TCP報文格式
TCP報文段的首部格式
圖中每行是4個字節，32位，TCP是面向字節流的，但TCP傳輸的單位卻是報文段，一個TCP報文段分為首部和數據兩部分，而TCP的全部功能都體現在它首部中各字段的作用。
TCP報文段中前20個字節是固定的，后面有4*n個字節是根據需要而增加的選項字段，n是個整數，最長是40個字節，因此TCP首部的長度是20-40個字節之間。
- 第一行是源端口和目的端口字段，各占2個字節。端口是傳輸層和應用層的服務接口，傳輸層的復用和分用功能都要通過端口才能實現。
- 第二行是序號字段，占4個字節。TCP連接中傳輸的數據流每一個字節都編上了序號，序號字段的值實際是指的本報文段中所發送的數據的第一個字節的序號
- 第三行是確認號字段，占4個字節。是期望收到對方的報文段數據的第一個字節序號。
- 數據偏移字段，即首部長度，它占了四位，指出了TCP報文段的數據起始處距離TCP報文段的起始處有多遠，數據偏移的單位是32位字。以4字節長的字為計算單位，最大的數值是60字節
- 保留字段，占6位，保留位今后使用，目前都把它設置為0
- 緊急標志URG，當URG=1時，表明緊急指針字段有效，它高速系統此報文段中有緊急數據，應盡快傳送，相當于是一個高優先級的數據
- 確認標志ACK，只有當ACK=1，確認號字段才有用，當ACK=0時確認號無效
- 推送標志PSH，接收TCP收到PSH=1的報文段，就盡快地交付接收應用進程，不再等到整個緩存填滿了再向上交付
- 復位標志RST，當RST=1時表明TCP連接中出現了嚴重的差錯，如主機崩潰或其他的原因，此時必須釋放連接然后再重新建立連接
- 同步標志SYN，SYN=1表示這是一個連接請求或連接接受報文，與ACK標志配合實現
- 終止標志FIN，它是用來釋放一個連接的，FIN=1表明此報文段中的發送數據已經發送完畢并要求釋放傳輸連接
- 窗口字段占了2個字節，作為接收方讓發送方設置發送窗口的依據，單位為字節，窗口指經常在動態變化著，此字段明確指出現在允許對方發送的數據量
- 檢驗和字段占兩個字節，檢驗范圍為首部和數據兩個部分，在計算檢驗和時要在TCP報文段前加上12位偽首部
- 緊急指針字段占16位，指出在本報文段中緊急數據有多少個字節，緊急數據放在本報文段的最前端，它只當URG=1時才有效
- 選項字段長度可調，最長40個字節，TCP最初只規定了一種選項，即最大報文段長度MSS，MSS告訴對方TCP我的緩存所能接受的報文的最長字段是MSS個字節，而MSS是TCP報文段中的數據字段的最大長度，數據字段加上TCP首部等于整個TCP的報文段，所以MSS的長度是TCP報文長度減去首部長度。
- 填充字段，為了使整個首部長度為4的整數倍
為什么要規定MSS
設置合理的MSS數值，可以提高網絡利用率，減小額外開銷，在建立連接時，雙方都把自己能夠支持的MSS寫入字段，傳送數據時就以此為準，兩個方向可以采用不同的MSS，MSS的默認值是536字節，即所有互聯網都能夠接受的長度是536+20即556個字節。MSS的選擇應盡可能大些，只要在IP層傳輸時不需要再分片就行。
其他選項
- 窗口擴大選項，占3字節，其中有一個字節表示移位值S，新的窗口值等于TCP首部的窗口位數增大到16+S，相當于把窗口值向左移動S位后獲得的窗口值，移位值允許使用的最大值是14，窗口的最大數值可以增大到230-1
- 時間戳選項占10字節，其中最主要的字段是時間戳值字段（4字節）和時間戳回送回答字段（4字節），它們通常是用來計算往返時間RTT和用來處理TCP序號超過22的情況，防止序號繞回這種情況
- 選項確認選項
5.5 可靠傳輸的工作原理
理想的傳輸條件特點
- 傳輸信道無差錯
- 不管發送方以多快的速度發送數據，接收方總是來得及處理收到的數據
停止等待的協議
每發送完一個分組就停止發送，等待對方的確認，當收到確認后再發送下一個分組。全雙工通信的雙方既是發送方又是接收方，為了討論問題的方便，我們在后面僅考慮A發送數據，B接受數據并發送確認，因此A叫做發送方，B叫做接收方，我們分情況來討論。
A向B發送數據M1，B確認收到后A繼續發送M2
B檢測M1時檢測到差錯，就直接丟棄M1，其他什么都不做，也不會通知A收到了有差錯的分組；如果M1在傳輸過程中丟失了，B當然什么也不知道，就什么都不做。
A為每一個已發送的分組都設置了一個超時計時器，A只要在超時計時器到期之前收到了相關的確認就撤銷該超時計時器，繼續發送下一個分組M2，反之則超時重傳M1.
A向B發送M1，B也收到了M1，但是B向A發送的確認收到丟失了，A并不能確定是自己沒有將M1傳給B還是B沒有將確認報文傳給自己，于是選擇了重傳，B此時收到再次發送來的M1要做兩個動作，一個是丟棄這個重新發送過來的M1，并不把它交付給上層，二是再次向A發送確認報文表明自己接收到了M1報文。
B向A發送的確認報文遲到了，A仍然與確認丟失的情況一樣對M1進行重傳，此時B對重新發送的M1進行丟棄，并重新發送確認報文。
在發送完一個分組后，必須暫時保留已發送的分組的副本，以備重發，分組和確認分組都必須要進行編號。超時計時器的重傳時間應當比數據在分組傳輸的平均往返時間RTT要更長一些。
自動重傳請求ARQ
通常A最終總是可以收到對所有發出的分組的確認，如果A總是重傳分組卻收不到確認就表明通信線路質量太差，不能進行通信。
使用確認和重傳機制，我們就可以在不可靠的傳輸網絡上實現可靠的通信，而這種可靠傳輸協議常稱為自動重傳請求ARQ，意思是重傳的請求是自動進行的，接收方不需要請求發送方重傳某個出錯的分組。
信道利用率
TD是發送分組所需要的時間，等于分組長度除以數據率，TA是B發送確認分組所需要的時間，RTT是往返時間，停止等待協議的優點是簡單，缺點是利用率太低。
流水線傳輸
為了提高傳輸效率，發送方可以不使用低效率的停止等待協議，而是采用流水線傳輸，如圖所示，流水線傳輸就是發送方連續發送多個分組，不必每發完一個分組就停下來等接收方確認，這樣可使信道上一直有數據不間斷地傳送，這樣可以獲得很高的信道利用率。
連續ARQ協議
發送方維持的發送窗口意義在于位于發送窗口內的分組都可連續地發送出去，而不需要等待對方的確認，這樣信道利用率就提高了。
連續ARQ協議規定發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置
接收方一般采用累計確認的方式，即不必對收到的分組逐個發送確認，而是對按需到達的最后一個分組發送確認，這樣就表示到這個分組為止的所有分組都正確收到了。它的優點是確認丟失，即使確認丟失也不必重傳，缺點是不能向發送方反映出接收方已經正確收到的所有分組的信息，如果發送方發送了前五個分組，而中間的第三個分組丟失了，這時接收方只能對前兩個分組發出確認，發送方無法知道后面三個分組的下落，只好把后面的三個分組都再重傳一次，這就叫==Go-back-N（回退N），表示需要再退回來重傳已發送的N個分組，可見當通信質量不好的時候連續ARQ協議會帶來負面的影響。
TCP可靠通信的具體實現
TCP連接的每一端都必須要設置兩個窗口，一個發送窗口和一個接收窗口，TCP的可靠傳輸機制是用字節的序號來進行控制的，TCP所有的序號都是基于序號的，TCP兩端的四個窗口是動態變化的，TCP的往返時間RTT也不是固定不變的，需要算法來估算合理的重傳時間。
5.6 TCP可靠傳輸的實現
以字節為單位的滑動窗口
如圖，假定A收到了B發來的確認報文段，其中窗口是20字節，而確認號是31，這表明B期望收到的下一個序號是31，而序號30之前的數據已經收到，根據這兩個數據，A就構造出了自己的發送窗口。發送窗口表示在沒有收到B的確認的情況下，A可以連續把窗口內的數據都發送出去，這個數值是20個字節，但在未收到確認之前著這20個字節都必須要暫時保留，以便在超時重傳時使用，發送窗口里面的序號表示允許發送的序號，窗口越大發送方就能在得到對方確認前連續發送更多的數據，從而獲得更高的傳輸效率。TCP標準強烈不贊成發送窗口前沿或向后收縮
A發送了11個字節的數據，沒有收到任何確認信息，圖中的指針P3-P2等于允許發送但尚未發送的字節數，又稱可用窗口，p3-p1等于A的發送窗口，又稱通知窗口，p2-p1等于已發送但尚未收到確認的字節數，A的發送窗口位置不變。
B的接收窗口中32，33沒有按序到達，接收窗口內31-50是允許接收的序號，確認報文段的序號只能是31.
A收到新的確認號34，發送窗口向前滑動，指針P2不變，可用窗口增大為42-53，B的接收窗口37，38，40沒有按序到達，只能暫存于接收窗口內.
A繼續發送序號42-53，此時P2與P3指針重合，還未收到B的確認，可用窗口減為0，停止發送，紙質收到B的確認，否則啟用超時重傳，如A收到的確認序號落在窗口內，那么A就可以使窗口繼續向前滑動并發送新的數據
發送緩存
緩存空間和序號空間都是有限的，并且都是循環使用的。
發送方的應用進程把字節流寫入TCP的發送緩存，發送窗口通常只是發送緩存的一部分，發送緩存和發送窗口的后沿都是重合的，發送應用程序必須控制寫入緩存的速率，否則可能造成緩存溢出
對于接收緩存，接收方的應用進程從TCP的接受緩存中讀取字節流，收到檢測有差錯的分組就會被丟棄掉，接受應用程序如若未能來得及讀取收到的數據，接收緩存就會被填滿，就無法接受新的數據。反之，應用程序能夠及時從接收緩存中讀取收到的數據，接收窗口就會增大，但不能超過接收緩存的大小。
發送緩存與接收緩存的作用
在發送緩存里，暫存的信息是：
- 發送應用程序傳送給發送方TCP準備發送的數據
- TCP已發出但尚未收到確認的數據
在接收緩存中，暫存的信息是：
- 按序到達的但尚未被接受應用程序讀取的數據
- 沒有按序到達的數據
注意事項：
接收方發送確認
接收方可以在合適的時候發送確認，也可以在自己有數據要發送時把確認信息捎帶上，但需注意兩點：
- 接收方不應過分推遲發送確認，都則會造成發送方不必要的重傳，確認推遲時間不能超過0.5s
- 稍待確認實際上并不經常發生，因為大多數應用程序很少在兩個方向上發送數據
超時重傳時間的選擇
TCP每發送一個報文段就對這報文段設置一次計數器，只要計時器時間到且沒有收到確認就要重傳這一報文段
如何設置超時值
若超時值太小就會造成不必要的重傳，若超時值太大丟包恢復的時間又太長，直觀上超時值應大于RTT，但RTT是變化的，而且往返時間的方差很大。由于TCP下層是互聯網的環境，IP數據報的路由變化很大，因此傳輸層的往返時間RTT也會很大，所以我們要先對RTT進行估計。
RTT是變化的，需要實際測量某一個報文段的往返時間，也就是樣本RTT。由于樣本RTT波動很大，所以計算平均值更有意義。
TCP采用了一種自適用的算法，它記錄一個報文段所發出的時間以及收到相應確認的時間，這兩個時間之差就是報文往返時間RTT。
加權平均往返時間
TCP保留了RTT的加權平均往返時間RTTs，也稱平滑的往返時間。第一次測到RTT樣本時，RTTs的值就取為所測量到的RTT樣本值，以后每測到一個RTT樣本就按照公式重新計算一個RTTs。
在公式中α是在0到1之間，若α接近于0則表示RTT值更新較慢，若α接近于1則表示RTT值更新較快，推薦α的數值是八分之一，也就是0.125
超時重傳時間RTO
RTO應該略大于上面所得出的加權平均往返時間，RTTd是RDD的偏差的加權平均值。
第一次測量時，RTT值取為到RTT樣本值的一半，在以后的測量中使用以下公式計算加權平均的RTTd
這里的β是一個小于1的系數，推薦值是四分之一即0.25
TCP確認的二義性
考慮到可靠傳輸需要確認機制及RTT的測量，這又引出了TCP確認的二義性
發送方發送了報文段1沒有收到確認報文，于是又發送了報文段2，此時收到了確認報文，但是無法辨別是發送給1還是給2的確認，這根本原因是TCP報文段使用了與原報文段相同的序號
Karn算法
當TCP重傳一個報文段時，停止測量本次RTT樣本，這樣得出的加權平均平均往返時間RTTS和超時重傳時間RTO比較準確。
但是當出現報文段的時延突然增大了很多的極端情況怎么辦呢？根據Karn算法超時重傳時間沒有辦法得到及時的更新，于是對Karn算法進行了修正
修正的Karn算法
報文段每重傳一次就把RTO的值增大γ倍，系數γ的典型值是2，當不再發生報文段的重傳時才根據報文段的往返時延更新平均往返時延RTT和超時重傳時間RTO的數值
選擇確認SACK
若收到的報文無差錯只是未按照序號到達，中間還缺少一些序號的數組，那么能否設法傳送缺少的數據而不傳送已經到達接收方的數據呢？答案是可以的。
接收到的字節流序號不連續的情況下，TCP的接收方在接受對方發過來的數據字節流的序號發生了不連續的狀態，結果就形成了一些不連續的字節塊，前后不連續的每一個字節塊都有兩個邊界，左邊界和有邊界。
第一個字節塊的左邊界L1等于1501，但是右邊界R1卻等于3001，左邊界指出字節塊第一個字節的序號，但右邊界減一才是最后一個字節的序號，第二個字節塊的左邊界L2等于3501，但是右邊界R2卻等于4501，接收方收到了前面的字節流不連續的兩個字節塊，如果這些字節的序號都在接收窗口之內，那么接收方就先收下這些數據，但要把這些信息準確地告訴發送方，使發送方不要再重復發送這些已收到的數據。
RFC 2018的規定
在使用選擇確認前，收發雙方必須在建立TCP連接時，在TCP首部的選項中加上“允許SACK”的選項。
原首部中的“確認號字段”留用，以后在TCP報文段的首部中都增加了SACK選項，確認收到的不連續的字節塊的邊界。
首部選項的長度最多只能有40個字節，一個字節塊的兩個邊界就要用到4*2=8個字節，因此在選項字段中最多只能指明4個字節塊的邊界信息，另外需要兩個字節，一個字節指明是SACK選項，一個字節指明此選項占用的字節數。
5.7 TCP的流量控制
通常我們希望數據傳輸的快一些并且接收方能夠來得及接受從而避免丟失，流量控制就是TCP發送端通過調節發送速率不會造成接收端緩存溢出也不會使得網絡擁塞。
利用滑動窗口實現流量控制
A向B傳送數據，在連接建立時，B告訴A我的接收窗口rwnd=400，A的發送窗口是100，A連續發送兩個100的數據都正常確認了，201-300丟失了，此時B確認了201以前的報文并修改了接收窗口為300，A繼續分兩次發送了301-500，因為201-300丟失所以需要超時重傳，此時B的接收窗口已滿，B確認了501之前的信息后再次調整接收窗口為100，A再次發送501-600，B確認此次傳輸接收窗口置0，本次傳輸中B三次調整接收窗口大小。
零窗口特例下死鎖的解決
B向A發送了0窗口的報文段后，B釋放了部分接收緩存的空間，并且重新向A發送了rwnd=400的報文段，但此報文丟失而A并不知道，AB雙方此時就互相等待對方的信息，陷入了一個死鎖的狀態。
為了解決這個問題，TCP為每一個連接設置有一個持續計時器，只要TCP連接一方收到了對方的零窗口通知就啟動該持續計時器，若持續計時器設置的時間到期就發送一個零窗口的探測報文段，僅攜帶了一個字節的數據，而對方就在確認這個探測報文段的時候給出了當前的窗口值，若窗口仍然是0，則收到這個報文的一方就重新設置持續計時器，若窗口不是0則死鎖的僵局就此打破。
TCP的傳輸效率
有三種機制控制TCP報文段發送時機
- 第一種機制是TCP維持一個變量，它等于最大報文段長度MSS。只要緩存中存放的1數據達到MSS字節時，就組裝成一個TCP報文段發送出去。
- 第二種進制是由發送方的應用進程指明要求發送報文段，即TCP支持的推送操作
- 第三種機制是發送方的一個計時器期限到了，這時就把當前已有的緩存數據裝入報文段（但長度不能超過MSS）發送出去
發送方糊涂窗口綜合征
發送方TCP每次收到一字節的數據后就發送。
這樣，發送一個字節需要形成41字節長的IP數據報。若接收方確認，并且發送方要求回送這一字節，就需傳送總長度為162字節共4個報文段，效率很低。
解決辦法：使用Nagle算法
Nagle算法
若發送應用進程，把要發送的數據逐個送入到TCP的發送緩存，則發送方就把第一個字節先發送出去，把后面到達的數據都緩存起來；當發送方收到對第一個字節的確認后，再把發送緩存中的所有數據組裝成一個報文段發送出去，同時繼續對隨后到達的數據進行緩存；只有在收到對前一個報文段的確認后，才繼續發送下一個報文段；當數據發送較快而網絡速率較慢時，用這樣的方法可明顯減少所用網絡帶寬；當到達的數據已到達發送窗口一半或報文段最大值時就立即發送一個報文段，這樣可以提高網絡的吞吐量。
接收方糊涂窗口綜合征
當接收方的TCP緩沖區已滿，接收方會向發送方發送窗口大小為0的報文。
若此時接收方的應用進程以交互方式每次只讀取一個字節，于是接收方又發送窗口大小為一個字節的更新報文，發送方應邀發送一個字節大小的更新報文（IP數據報是41字節長），于是接收窗口又滿了，如此循環往復。
解決方法：讓接收方等待一段時間，使得或者接收緩存已有足夠空間容納一個最長的報文段，或者等到接收緩存已有一般空閑的空間。只要出現這兩種情況之一，接收方就發出確認報文，并向發送方通知“當前的窗口大小”，同時發送方也不要發送太小的報文段。
TCP流量控制小結
TCP接收端：
- 使用顯式的窗口通告，告知發送方可用的緩存空間大小。
- 在接收窗口較小時，推遲發送確認。
- 僅當接收窗口顯著增加時，通告新的窗口大小。
TCP發送端：
- 使用Nagle算法確定發送時機
- 使用接收窗口限制發送的數據量，已發送未確認的字節數不超過接收窗口的大小
5.8 TCP的擁塞控制
網絡擁塞的現象實際上是短時網絡中的分組太多，網絡帶寬不足，解決的措施是減少分組進入網絡。
擁塞控制的一般原理
流量控制是限制發送速度，使之不超過接收端的處理能力，也就是接收端控制發送端，而擁塞控制是限制發送速度，使之不超過網絡的處理能力，是一個全局性的問題。
網絡擁塞產生的后果及原因
網絡擁塞會造成：丟包（路由器緩存溢出）、分組延遲增大（鏈路接近滿載）
大量的網絡資源用于：重傳丟失的分組、不必要地重傳延遲過大的分組，轉發最終被丟棄的分組
這樣會使得網絡的負荷很重，流量很大但網絡吞吐量卻很低，有效流量很少，根本原因是系統對資源的需求總和大于可用的資源
擁塞控制所起的作用
橫坐標是輸入負載，縱坐標是吞吐量，理想的擁塞控制是在吞吐量達到飽和前曲線以45°斜率的線性增長至飽和水平線，而實際上是隨著負載的增加，網絡吞吐量的增長率逐漸減小，已進入了輕度擁塞狀態，繼續增加負載網絡吞吐量反而會下降，此時網絡擁塞了，負載增加到一定程度，網絡吞吐量會降為0，此時為死鎖狀態，實際擁塞控制曲線基本介乎于理想擁塞控制和無擁塞控制的曲線之間。
實踐證明，擁塞控制是很難設計的，因為它是一個動態的問題。
丟包是網絡擁塞的征兆，不是引起擁塞的原因
開環控制和閉環控制
開環控制方法就是在設計網絡時事先將有關發生擁塞的因素考慮周到，力求網絡在工作時不產生擁塞。
閉環控制方法是基于反饋環路的概念，有以下三種措施：
-
監測網絡系統，以便監測到擁塞在何時何處發生
-
將擁塞發生的信息傳送到可采用行動的地方
-
調整網絡系統的運行，以解決出現的問題
監測網絡擁塞的指標
- 由于缺少緩存空間而被丟棄的分組的百分比
- 平均隊列長度
- 超時重傳的分組數
- 平均分組時延
- 分組時延的標準差
上述這些指標的上升都標志著擁塞的增長
方法一監測擁塞發生時通知擁塞發生的分組客觀上增加了網絡的流量，同樣會使網絡更加擁塞；方法二在轉發分組中增加相應的字段表示網絡擁塞狀態或周期性地發出探測分組
TCP的擁塞控制方法
TCP采用基于窗口的方法進行擁塞控制，該方法屬于閉環控制方法。
TCP發送方維持一個擁塞窗口CWND，擁塞窗口的大小取決于網絡的擁塞程度，網絡通暢就增大擁塞窗口，提高網絡利用率，當網絡擁塞時減小擁塞窗口，緩解網絡的壓力。發送端利用擁塞窗口根據自己感知的網絡擁塞程度來調整發送的數據量，所以發送窗口的大小不僅取決于接收方公告的接收窗口，還取決于網絡的擁塞狀況。
網絡擁塞的判斷依據
發送方利用丟包時間來感知擁塞，擁塞造成了丟包和分組延遲的增大，這兩種情況對于發送端來說都是丟包，丟包事件反映在重傳計時器超時或發送端接收到3個重復的確認信號ACK。
發送方通常使用擁塞窗口來限制已發送未確認的數據量，當感知到網絡擁塞后，發送方通常是由CWND來隨發送方感知的網絡擁塞程度進行調整
TCP擁塞控制算法
-
慢開始（slow-start）
算法的思路：在新建連接上指數級增大cwnd，直至檢測到丟包，此時會終止慢開始的階段。它是希望通過迅速增大cwnd至可用的發送速率
原有的規定是先把初始的擁塞窗口的cwnd值設為1至2個發送窗口的最大報文段SMSS，新規則是把初始的擁塞窗口cwnd值設置為不超過2-4個SMSS的數值，防止擁塞窗口cwnd增長過大引起網絡擁塞，我們還需要設置一個狀態變量慢開始門限ssthresh。
擁塞窗口CWND它的控制方法是在每收到一個對新的報文段的確認后，可以把擁塞窗口增加最多一個SMSS的數值，其中N是原先未被確認的但現在剛確認的報文段的字節數，所以當N小于SMSS的時候，擁塞窗口每次的增加量要小于SMSS。用這樣的方法逐漸增大發送方的擁塞窗口，可以使分組注入到網絡的速率更加合理。
發送方每收到一個對新報文段的確認（重傳不計算在內），就使得cwnd加1，此處的1是一個單位也就是一個報文段，每經過一個RTT將cwnd加倍。
為了防止擁塞窗口cwnd增長過快，還要再設置慢開始門限狀態變量ssthresh，它的用法如下：
-
當cwnd<ssthresh時，使用慢開始算法
-
當cwnd>ssthresh時，停止使用慢開始算法而改用擁塞避免算法
-
當cwnd=ssthresh時，既可使用慢開始算法，也可以使用擁塞避免算法
-
擁塞避免（congestion avoidance）
思路：讓擁塞窗口cwnd緩慢增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，使擁塞窗口cwnd按線性規律緩慢增長。
在擁塞避免階段就有“加法增大”的特點，比慢開始算法的擁塞窗口增長速率緩慢得多。
-
在網絡擁塞時的處理：
只要發送方判斷網絡出現擁塞（重傳定時器超時）：
- ssthresh=max(cwnd/2,2)
- cwnd=1
- 執行慢開始算法
-
慢開始和擁塞避免算法的實現舉例
初始cwnd=1，在cwnd<ssthresh的情況下，每經過一個倫茨cwnd就指數增長一次，直到cwnd=ssthresh時，實施擁塞避免算法，cwnd呈線性增長，隨著傳輸輪次的增長每次自增1，當網絡擁塞時cwnd變為1，ssthresh降為8，重新一階段與二階段，當收到連續三個ACK時，進行快重傳算法。
-
快重傳（fast retransmit）
快重傳算法可以讓發送方盡早直到發生了個別報文段的丟失。
快重傳算法并非取消重傳計時器，而是在某些情況下可更早地重傳丟失的報文段。
快重傳算法首先要求接收方不要等到自己發送數據時才進行捎帶確認，而是要立即發送確認，即使收到了失去的報文段也要立即發出對已收到的報文段的重復確認，發送方只要一連收到三個重復的確認，就知道接收方確實沒有收到報文段，因而應當立即進行重傳也就是快重傳，這樣就不會出現超時，發送方也不會誤認為網絡擁塞。
-
快恢復（fast recovery）
當發送端收到連續三個重復的確認時，由于發送方現在認為網絡很可能沒有發生擁塞，因此現在不執行慢開始算法，而是執行快恢復算法FR算法：
- 慢開始門限ssthresh=當前擁塞窗口cwnd/2
- 新擁塞窗口cwnd=慢開始門限ssthresh
- 開始執行擁塞避免算法，使擁塞窗口緩慢地線性增大
如圖四收到了3個ACK確認，此時執行快恢復算法。
擁塞窗口的調節策略：AIMD
AI指的是加法增大，若無丟包，每經過一個RTT將cwnd增大一個MSS，直到檢測到丟包，目的是緩慢增大發送速率。MD指的是乘法減小，發送發檢測超時或三個重復確認時，把門限值設為當前擁塞窗口的一半，目的是迅速減小發送速率從，緩解網絡壓力。
TCP擁塞控制流程圖
發送窗口的上限值
發送窗口的上限值應取為接收方窗口rwnd和擁塞窗口cwnd中較小的一個。
5.9 TCP的傳輸連接管理
傳輸連接的三個階段
- 連接建立（握手）
- 數據傳送
- 連接釋放（放手）
連接建立前的準備
TCP連接建立采用客戶服務器方式，主動發起連接建立的進程叫做客戶，被動連接的進程叫做客戶
TCP的三次握手
總結
以上是生活随笔為你收集整理的计算机网络（五）传输层详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： FreeRTOS系统下LwIP-1.4.
- 下一篇： 趣头条基于ClickHouse玩转每天1