1- 運輸層概述

1.1 基本概念

​

1.2 程序之間的通訊

• 從通訊和資訊處理的角度看，運輸層向它上面的應用層提供通訊服務，它屬於面向通訊部分的最高層，同時也是使用者功能中的最低層。
• 當網路的邊緣部分中的兩個主機使用網路的核心部分的功能進行端到端的通訊時，只有位於網路邊緣部分的主機的協議棧才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到三層（到網路層）的功能。

​

1.3 程序之間通訊流程

區域網1上的主機與區域網2上的主機，通過互連的廣域網進行通訊，網路層的作用範圍是主機到主機。

提供直接的通訊服務是運輸層的任務。運輸層協議又稱為端到端協議，運輸層的作用範圍是應用程序到應用程序也稱為端到端

。

步驟分析

“邏輯通訊”是指運輸層之間的通訊好像是沿水平方向傳送資料，但事實上，這兩條資料並沒有一條水平方向的物理連線，要傳送的資料是沿著圖中上下多次的虛線方向傳送的。

程序Ap1與Ap4之間進行基於網路的通訊，程序Ap2與Ap3之間進行基於網路的通訊，在運輸層使用不同的埠，來對應不同的應用程序，然後通過網路層及其下層來傳輸應用層報文。

接收方的運輸層通過不同的埠，將收到的應用層報文，交付給應用層中相應的應用程序，這裡埠並不是指看得見、摸得著的物理埠，而是指用來區分不同應用程序的識別符號。

1.4 概念總結

2- 運輸層埠號、複用與分用

2.1 為啥使用埠號

2.2 傳送方的複用和接收方的分用

UDP複用

這是收發雙方的應用程序，傳送方的某些應用程序所傳送的不同應用報文，在運輸層使用UDP協議進行封裝，這稱為UDP複用。

TCP複用

另一些應用程序所傳送的不同應用報文，在運輸層使用TCP協議進行封裝，這稱為TCP複用。

IP複用

運輸層使用埠號來區分不同的應用程序，不管是使用運輸層的UDP協議封裝成的UDP使用者資料報，還是使用TCP協議封裝成的TCP報文段，在網路層都需要使用IP協議封裝成IP資料報

傳送方

IP資料報首部中的協議欄位的值，用來表明IP資料報的資料載荷部分，封裝的是何種協議資料單元，取值為6。表示封裝的是TCP報文段，取值為17，表示封裝的是UDP使用者資料報。

接收方

接收方的網路層收到IP資料報後進行IP分用，若IP資料報首部中協議欄位的值為17，則把IP資料報的資料的資料載荷部分所封裝的UDP使用者資料報，上交運輸層的UDP。若協議欄位的值為6，則把IP資料報的資料載荷部分所封裝的TCP報文段，上交運輸層的TCP。運輸層對UDP使用者資料報進行UDP分用，對TCP報文段進行TCP分用，也就是根據埠號，將它們交付給上層相應的應用程序。

2.3 運輸層熟知埠號

不管在運輸層使用UDP還是TCP協議，在網路層都需要使用IP協議，IP資料報首部中協議欄位的值，表明了IP資料報資料載荷部分，封裝的是何種協議資料單元。

3- 運輸層傳輸流程

3.1 步驟一

通過例項來說明運輸層埠號的作用

使用者PC、DNS伺服器、WEB伺服器通過交換機進行互聯，它們處於同一個乙太網中。DNS伺服器中的記錄有該域名所對應的IP地址。我們在使用者PC中使用網頁瀏覽器來訪問Web伺服器的內容，在網頁瀏覽器的位址列中輸入Web伺服器的域名。使用者PC中的DNS客戶端程序會發送一個DNS查詢請求報文，其內容為"域名www.porttest.com所對應的IP地址是什麼?"

DNS查詢請求報文需要使用運輸層的UDP協議，封裝成UDP使用者資料報，其首部中的源埠欄位的值，在短暫埠號(49151~65535)中挑選一個未被佔用的，用來表示DNS客戶端程序，例如49152。目的埠欄位的值設定為53，這是DNS服務端程序所使用的熟知埠號。

3.2 步驟二

將UDP使用者資料報封裝在IP資料報中，通過乙太網傳送給DNS伺服器，DNS伺服器收到該資料報後。

3.3 步驟三

從中解封出UDP使用者資料報，UDP首部中的目的埠號為53，這表明應將該UDP使用者資料報的資料載荷部分，也就是DNS查詢請求報文交付給本伺服器中的DNS伺服器端程序，DNS伺服器端程序解析DNS查詢請求報文的內容，然後按其要求查詢對應的IP地址。

之後，會給使用者PC傳送DNS響應報文，其內容為"域名www.porttest.comsu所對應的IP地址是192.168.0.3"。DNS響應報文需要使用運輸層的UDP協議，封裝成UDP使用者資料報，其首部中的源埠欄位的值設定為熟知埠號53，表明這是DNS伺服器端程序所傳送的UDP使用者資料報，目的埠欄位的值設定為49152，這是之前使用者PC中傳送DNS查詢請求報文的DNS客戶端程序所使用的短暫埠號。之後，將UDP使用者資料報封裝在IP資料報中的通過乙太網傳送給使用者PC。

3.4 步驟四

之後，將UDP使用者資料報封裝在IP資料報中通過乙太網傳送給使用者PC。使用者PC收到該資料報後，從中解封出UDP使用者資料報。UDP首部中的目的埠號為49152，這表明應將該UDP使用者資料報的資料載荷部分也就是DNS響應報文，交付給使用者PC中的DNS客戶端程序。DNS客戶端程序解析DNS響應報文的內容，就可知道自己之前的所請求的Web伺服器的域名，所對應的IP地址為192.168.0.3。

3.5 步驟五

現在，使用者PC中的HTTP客戶端程序，可以向Web伺服器傳送HTTP請求報文，其內容為"首頁內容是什麼?"HTTP請求報文需要使用運輸層的TCP協議封裝成TCP報文段，其首部中的源埠欄位的值，在短暫埠號49151~65535中挑選一個未被佔用的，用來表示HTTP客戶端程序，例如仍然使用之前用過的49152。目的埠欄位的值設定為80，這是HTTP伺服器程序所使用的熟知埠號。

3.6 步驟六

之後，將TCP報文段封裝在IP資料報中，通過乙太網傳送給Web伺服器。Web伺服器收到該資料報後，從中解封出TCP報文段。TCP首部中的目的埠號為80，這表明應該將TCP報文段的資料載荷部分也就是HTTP請求報文，交付給本伺服器中的HTTP伺服器端程序，HTTP伺服器端程序解析HTTP請求報文的內容，然後按其要求查詢首頁內容。

3.7 步驟六

之後，會給使用者PC傳送HTTP響應報文，其內容是HTTP客戶端所請求的首頁內容，HTTP響應報文需要使用運輸層的TCP協議封裝成TCP報文段，其首部中的源端欄位的值設定為熟知埠號80。表明這是HTTP伺服器端程序所傳送的TCP報文段，目的埠欄位的值設定為49152，這是之前使用者PC中，傳送HTTP請求報文HTTP客戶端程序所使用的短暫埠號。

3.8 步驟七

之後，將TCP報文段封裝在IP資料報中，通過乙太網傳送給使用者PC，使用者PC收到該資料報後，從中解封出TCP報文段。TCP首部中的目的埠號為49152，這表明應將該TCP報文段的資料載荷部分，也就是HTTP響應報文，交付給使用者PC中的HTTP客戶端程序。

HTTP客戶端程序解析HTTP響應報文的內容，並在網頁瀏覽器中進行顯示，這樣我們就可以在網頁瀏覽器中，看到Web伺服器所提供的首頁內容。

4-UDP和TCP的對比

4.1基本概念

• UDP 和 TCP是TCP/IP體系結構運輸層中的兩個重要協議。
• 當運輸層採用面向連線的 TCP協議時，儘管下面的網路是不可靠的，但這種邏輯通訊通道就相當於一條全雙工的可靠通道。
• 當運輸層採用無連線的 UDP協議時，這種邏輯通訊通道是一條不可靠通道。

兩個對等運輸實體在通訊時傳送的資料單位叫作運輸協議資料單元 TPDU。

TCP 傳送的資料單位協議是 TCP 報文段，UDP 傳送的資料單位協議是 UDP 報文或使用者資料報。

UDP特點

無連線的協議，提供無連線服務。其傳送的運輸協議資料單元TPDU是UDP報文或者使用者資料報。

支援單播，多播、廣播，不提供可靠交付。簡單適用於很多應用，如多媒體應用等。

UDP的通訊是無連線的，不需要套接字(Socket)。

TCP特點

面向連線的協議，提供面向連線服務。其傳送的運輸協議資料單元TPDU是TCP報文。

支援點對點單播，不支援多播、廣播、提供可靠服務。

複製、用於大多數應用，如：全球資訊網、電子郵件、檔案傳送等。

TCP是面向連線的，TCP之間的通訊必須要在兩個套接字（Socket）之間建立連線。

兩者對比

使用UDP協議的通訊雙方，可以隨時傳送資料。使用TCP協議的通訊雙方，在進行資料傳輸之前必須使用“三報文握手”來建立TCP連線。

TCP連線建立成功後才能進行資料傳輸，資料傳輸接收後，必須使用"四報文揮手"，來釋放TCP連線。

4.2 使用者資料報協議UDP

4.2.1 基本傳輸

可以傳送廣播

​

可以向某個多播組傳送多播

​

還可以傳送單播

​

總結

使用UDP協議進行通訊的四臺主機，其中任何一臺主機都可向其他三臺主機發送廣播。也可以向某個多播組發多播，還可以向某臺主機發送單播。

UDP支援單播、多播、以及廣播。UDP支援一對一，一對多，以及一對全的通訊。

4.2.2 對應用報文的處理

​

步驟流程

傳送方的應用程序，將應用層報文交付給運輸層的UDP。UDP直接給應用層報文新增一個UDP首部，使之成為UDP使用者資料報，然後進行傳送。
接收方的UDP收到該UDP使用者資料報後，去掉UDP首部，將應用層報文交付給應用程序。也就是說，UDP對應用程序交下來的報文既不合並也不拆分，而是保留這些報文的邊界，換句話來說。UDP是面向應用報文的。

4.2.3 UDP向上層提供無連線不可靠傳輸服務

網際層向其上層提供的是無連線不可靠的傳輸服務，當運輸層使用UDP協議時，向其上層提供的也是無連線不可靠的傳輸服務。

​

流程步驟

傳送方給接收方傳送UDP使用者資料報，若傳輸過程中使用者資料報受到干擾而產生誤碼，接收方UDP可以通過該資料報首部中的檢驗和欄位的值，檢查出產生誤碼的情況。但是僅僅丟棄該資料報，其他什麼也不做，傳送方給接收方傳送UDP使用者資料報。

如果該資料報被因特網中的某個路由器丟棄了，傳送方UDP不做任何處理。因為UDP向上層提供的是無連線不可靠的傳輸服務。對於UDP使用者資料報出現的誤碼和丟失等問題，UDP並不關心。基於UDP的這個特點，UDP適用於實時應用，例如IP電話，視訊會議等。

4.3 傳輸控制協議TCP

4.3.1 基本傳輸

使用TCP協議的通訊雙方，在進行資料傳輸之前，必須使用“三報文握手”建立TCP連線。

TCP連線建立成功後，通訊雙方之間就好像有一條可靠的通訊通道，通訊雙方使用這條基於TCP連線的可靠通道進行通訊。

​

總結

很顯然，TCP僅支援單播，也就是一對一的通訊。

4.3.2 對應用報文的處理

運輸過程

​

傳送方

• TCP會把應用程序交付下來的資料塊看作是一連串無結構的位元組流，TCP並不知道這些待傳送的位元組流的含義。
• 並將他們編號，並存儲在自己傳送快取中。
• TCP會根據傳送策略，提取一定量的位元組構建TCP報文併發送。

接收方

• 一方面從所接受到的TCP報文段中，取出資料載荷部分並存儲在接收快取中；一方面將接收快取中的一些位元組交付給應用程序。
• TCP不保證接收方應用程序所收到的資料塊與傳送方傳送的資料塊，具有對應大小的關係（例如，傳送方應用程序交給傳送方的TCP共10個數據塊，但接收方的TCP可能只用了4個數據塊，就把收到的位元組流交付給了上層的應用程序，但接收方收到的位元組流必須和傳送方應用程序發出的位元組流完全一樣）。
• 接收方的應用程序必須有能力識別收到的位元組流，把它還原成有意義的應用層資料。

TCP是面向位元組流的，這正是TCP實現可靠傳輸、流量控制、以及擁塞控制的基礎。在實際網路中，基於TCP連線的兩端，可以同時進行TCP報文段的傳送和接收，也就是全雙工通訊。

4.3.3 TCP向上層提供面向連線的可靠傳輸服務

儘管網際層中的IP協議，向上層提供的是無連線不可靠的傳輸服務。也就是說，IP資料報可能在傳輸過程中出現丟失或誤碼。

​

但只要運輸層使用TCP協議，就可向其上層提供面向連線的可靠傳輸服務，我們可將其想象成，使用TCP協議的收發雙方基於TCP連線的可靠通道進行資料傳輸。

不會出現誤碼、丟棄、亂碼以及重複等傳輸差錯。TCP適用於要求可靠傳輸的應用，例如檔案傳輸。

4.4 協議對比

UDP構成

一個UDP使用者資料報由首部和資料載荷兩部分構成，其首部格式如圖所示，僅有4個欄位，每個欄位長度為2個位元組。由於UDP不提供可靠的傳輸服務，它僅僅在網際層的基礎上，添加了用於區分應用程序的埠。因此它的首部非常簡單，僅有8個位元組。

TCP構成

一個TCP報文段由首部和資料載荷兩個部分構成，其首部格式如圖所示，這比UDP使用者資料報的首部複製的多，其最小長度為20個位元組。最大的長度為60個位元組，這是因為TCP要實現可靠傳輸，流量控制，擁塞控制等服務。其首部自然會比較複雜，首部中的欄位比較多，首部長度也比較長。

4.5 小結

5- TCP控制

5.1 TCP的流量控制

5.1.1 基本概念

5.1.2 案例分析

步驟分析1

假設主機A和B是因特網上的兩臺主機，它們之間已經建立了TCP連線，A給B傳送資料，B對A進行流量控制。這是主機A中待發送資料的位元組序號。假設主機A傳送的每個TCP資料報文段可攜帶100位元組資料。因此圖中每個小格子表示100個位元組資料的序號，在主機A和B建立TCP連線時，B告訴A："我的接收視窗為400"。主機A將自己的傳送視窗也設定為400。這意味著主機A在未收到主機B發來的確認時，可將序號落入傳送視窗中的全部資料傳送出去。

​

步驟分析2

主機B對A的流量控制，主機A將傳送視窗內序號1~100的資料封裝成一個TCP報文段傳送出去。傳送視窗內還有300位元組可以傳送，這裡的seq是TCP報文段首部中的序號欄位，取值1表示TCP報文段資料載荷的第一個位元組的序號是1。

這裡的DATA表示這是TCP資料報文段，主機A將傳送視窗內序號101_{200的資料封裝成一個TCP報文段傳送出去，傳送視窗內還有200位元組可以傳送。主機A將傳送視窗內還有200位元組可以傳送。主機A將傳送視窗內序號201}300的資料，封裝成一個TCP報文段傳送出去。但該報文段在傳輸過程中丟失了，主機A傳送視窗內還有100個位元組可以傳送，主機B對主機A所傳送的201號以前的資料進行累計確認。

並在該累計確認中將視窗欄位的值調整為300，也就是對主機A進行流量控制。這裡的大寫ACK是TCP報文段首部中的標誌位，取值1表示這是一個TCP確認報文段，小寫ack是TCK報文段首部中的確認號欄位。取值201表示序號201之前的資料已全部正確接收，現在希望收到序號201及其後續資料。rwnd是TCP報文段首部中的視窗欄位，取值300表示自己的接收視窗大小為300。

步驟分析3

主機A收到該累計確認後，將傳送視窗向前滑動，使已經發送並收到確認的這些資料的序號移出傳送視窗。由於主機B在該累計確認中將自己的接收視窗調整為了300。主機A相應地將自己的傳送視窗調整為300。主機A傳送視窗內的序號為201_{500，也就是主機A還可以傳送這300位元組，201}300號位元組是已傳送的資料，如果重傳計時器超時，它們會被重傳。301_{400位元組以及401}500號位元組還未被髮送，可分別封裝在一個TCP報文段中傳送，主機A現在可將傳送快取中序號1~200的位元組資料全部刪除了。

因為已經收到了主機B對它們的累計確認，主機A將傳送視窗內序號301_{400的資料封裝成一個TCP報文段傳送出去，傳送視窗內還有100位元組可以傳送。主機A將傳送視窗內序號401}500的資料，封裝成一個TCP報文段傳送出去。至此，序號落在傳送視窗內的資料已經全部發送出去了，不能再發送新資料了。

步驟分析4

現在，傳送視窗內序號201~300這100個位元組資料的重傳計時器超時了，主機A將它們重新封裝成一個TCP報文段傳送出去，暫時不能傳送其他資料。主機B收到該重傳的TCP報文段後，對主機A所傳送的501號以前的資料進行累計確認，並在該累計確認中將視窗欄位的值調整為100，這是主機B對主機A進行的第二次流量控制。

步驟分析5

主機A收到該累計確認後，將傳送視窗向前滑動，使已傳送並收到確認的這些資料的序號移出傳送視窗。由於主機B在該累計確認中將自己的接收視窗調整為了100。因此，主機A相應地將自己的傳送視窗調整為100。目前，主機A傳送視窗內的序號為501_{600。也就是主機A還可以傳送這100位元組，主機A現在可將傳送快取中序號201}500的位元組資料全部刪除了，因為已經收到了主機B對它們的累計確認。

步驟分析6

主機A將傳送視窗內序號501_{600的資料，封裝成一個TCP報文段傳送出去。至此，序號落在傳送視窗內的資料已經全部發送出去了，不能在傳送新資料了。主機A所傳送的601號以前的資料進行累計確認，並且在改累計確認中將視窗欄位的值調整為0，這是主機B對主機A進行的第三次流量控制，主機A收到該累計確認後，並且將傳送視窗向前滑動，使已傳送並收到確認的這些資料的序號移出傳送視窗。由於主機B在該累計確認中將自己的接收視窗調整為了0。因此，主機A相應地將自己的接收視窗調整為0。目前，主機A不能再發送一般的TCP報文段了。主機A現在可將傳送快取中的序號501}600的位元組資料全部刪除了，因為已經收到了主機B對它們的累計確認。

步驟分析7

假設主機B向主機A傳送了零視窗的報文段後不久，主機B的接收快取又有了一些儲存空間。於是，主機B向主機A傳送了接收視窗等於300的報文段。然而，這個報文段在傳輸過程中丟失了，主機A一直等待主機B傳送的非零視窗的通知，而主機B也一直等待主機A傳送的資料，如果不採取措施，這種互相等待而形成的死鎖局面將一直持續下去。

步驟分析8

TCP為每一個連線設有一個持續計時器。只要TCP連線的一方收到對方的零視窗通知，就啟動持續計時器。若持續計時器超時，就傳送一個零視窗探測報文，僅攜帶一位元組的資料。而對方在確認這個探測報文段時，給出自己現在的接收視窗值。如果接收視窗仍然是0，那麼收到這個報文段的一方就重新啟動持續計時器。如果接收視窗不是0，那麼死鎖的局面就可以被打破了。

主機A收到零視窗通知時，就啟動一個持續計時器。當持續計時器超時時，主機A立刻傳送一個僅攜帶一位元組資料的零視窗探測報文段。假設主機B此時的接收視窗又為0了。主機B就在確認這個零視窗探測報文段時給出自己現在的接收視窗值為0，主機A再次收到零視窗通知，就再次啟動一個持續計時器。當持續計時器超時，主機A立刻傳送一個零視窗探測報文段。假設主機B此時的接收快取又有了一些儲存空間，於是將自己的接收視窗調整為了300，主機B就在確認這個零視窗探測報文段時，給出自己現在的接收視窗值為300，這樣就打破了死鎖的局面。

步驟分析9

主機A所傳送的零視窗探測報文段到達主機B時，如果主機B此時的接收視窗仍然為0，那麼主機B根本就無法接受該報文段，又怎麼會針對該報文段給主機A發回確認時？實際上TCP規定，即使接收視窗為0，也必須接受零視窗探測報文段、確認報文段、以及攜帶有緊急資料的報文段。

如果零視窗探測報文段丟失了，會出現怎樣的問題呢? 還能否打破死鎖的局面嗎？

能打破死鎖的局面，因為零視窗探測報文段也有重傳計時器，當重傳計時器超時後，零視窗探測報文段會被重傳。

5.1.3 小結

5.2 TCP的擁塞控制

5.2.1 基本概念

5.2.2 擁塞控制的演算法

條件設定

5.2.3 慢開始和擁塞避免

慢開始

步驟流程1

傳輸輪次是指: 傳送方給接收方傳送資料報文段後，接收方給傳送方發回相應的確認報文段。一個傳輸輪次所經歷的時間，其實就是往返時間。往返時間並非是恆定的數值。使用傳輸輪次是為了強調，把擁塞視窗所允許傳送的報文段都連續傳送出去，並且收到了對已傳送的最後一個報文段的確認。

縱座標是擁塞視窗，它會隨網路擁塞程度以及所使用的擁塞控制演算法動態變化，在TCP雙方建立邏輯連線關係時，擁塞視窗的值被設定為1，如下圖標出傳輸輪次0時的擁塞視窗值為1，另外，還需要設定慢開始門限的初始值。本例採用16傳送方每收到一個新報文段的確認時，就把擁塞視窗值加1，然後開始下一輪的傳輸，當擁塞視窗值增長到慢開始門限值時，就改為執行擁塞避免演算法。

步驟流程2

由於傳送方當前的擁塞視窗值是1，而傳送視窗值等於擁塞視窗值，傳送方當前只能傳送一個TCP資料報文段，換句話說，擁塞視窗值是幾，就能傳送幾個資料報文段。傳送方傳送0號資料報文段，接收方收到後，給傳送方發回對0號報文段的確認報文段，傳送方收到該確認報文段後，將擁塞視窗值加1增大到2，這意味著傳送方。現在可以傳送1_{2號共兩個資料報文段。接收方收到後，給傳送方發回對1}2號報文段的確認報文段，傳送方收到後，將擁塞視窗值增加2增大到4。

步驟流程3

傳送方現在可以傳送3_{6號共四個資料報文段。接收方收到後，給傳送方發回對3}6號報文段的確認報文段。傳送方收到後，將擁塞視窗值加4增大到8，傳送方現在可以傳送7_{14號共8個數據報文段。接收方收到後，給傳送方發回對7}14號報文段的確認報文段，傳送方收到後，將擁塞視窗值加8增大到16。

傳送方當前的擁塞視窗值，已經增大到了慢開始門限值。之後，然後要改用擁塞避免演算法。

擁塞避免

步驟流程1

每個傳輸輪次結束後，擁塞視窗值只能線性加1，而不像慢開始演算法那樣，每個傳輸輪次結束後，擁塞視窗值按指數規律增大，傳送方現在可以傳送15_{30號共16個數據報文段，接收方收到後。給傳送方發回對15}30號報文段的確認報文段。傳送方收到後，將擁塞視窗值加1增大到17。

步驟流程2

在圖中標出該值，傳送方現在可以傳送31_{47號共17個數據報文段，接收方收到後，給傳送方發回對31}47號報文段的確認報文段。傳送方收到後，將擁塞視窗值加1增大到18。

步驟流程3

在圖中標出該值，隨著傳輸輪次的增加，擁塞視窗值每輪次都線性加1。當前擁塞視窗值增加到類4，傳送方現在可以傳送171~194號共24個數據報文段。假設這24個數據報文段在傳輸過程中丟失了幾個。這必然會造成傳送方對這些丟失報文段的超時重傳。傳送方以此判斷網路很可能出現了擁塞。

步驟流程4

傳送方以此判斷網路很可能出現了擁塞，需要進行以下工作。(1) 將慢開始門限值更新為發生擁塞時擁塞視窗值得一半，網路傳送擁塞時的擁塞視窗值是24，因此更新慢開始門限值為該值的一半，即12。(2) 將擁塞視窗值減小為1，並且重新開始執行慢開始演算法。

步驟流程5

當慢開始演算法執行到擁塞視窗值，增大到新的慢開始門限值時，就停止使用慢開始演算法。轉而執行擁塞避免演算法。

步驟流程6

TCP傳送方一開始使用慢開始演算法，讓擁塞視窗值從1開始按指數規律增大。當擁塞視窗值增大到慢開始門限值時，停止使用慢開始演算法，轉而執行擁塞避免演算法，讓擁塞視窗值按線性加1的規律增大。當發生超時重傳時，就判斷網路很可能出現擁塞。採取相應的措施，一方面將慢開始門限值，更新為發生擁塞時擁塞視窗值得一半。另一方面將擁塞視窗值減少為1，並且從新開始執行慢開始的演算法，擁塞視窗值又從1開始按指數規律增大，當增大到了新的慢開始門限值時，停止使用慢開始演算法，轉而執行擁塞避免演算法，讓擁塞視窗值按線性加1的規律增大。

5.2.4 快重傳和快恢復

快重傳（fast retrasmit）

快恢復（fast recovery）

改進後的整體演算法的示意圖

步驟流程

TCP傳送方一開始使用慢開始演算法，讓擁塞視窗值從1開始按指數規律增大，當增大到慢開始門限初始值時，停止使用慢開始演算法。轉而執行擁塞避免演算法，讓擁塞視窗值按線性加1的規律增大。當發生超時重傳時，就判斷網路可能出現了擁塞，採取相應的措施。一方面將慢開始門限值更新為發生擁塞時擁塞視窗值的一半。另一方面將擁塞視窗值減少為1，並重新開始執行慢開始演算法。

擁塞視窗值又從1開始按指數規律增大，當增大到了新的慢開始門限值時，停止使用慢開始演算法，轉而執行擁塞避免演算法，讓擁塞視窗值按線性加1的規律增大。當傳送方收到3個重複確認時，就進行快重傳和快恢復。也就是更新慢開始門限值為當前擁塞視窗值的一半，並將擁塞視窗值也取為新的慢開始門限值，轉而執行擁塞避免演算法，讓擁塞視窗值按線性加1的規律增大。

5.3 TCP超時重傳時間的選擇

5.3.1 基本概念

步驟流程1

主機A給主機B傳送TCP資料報文段0，並且記錄下當前的時間。主機B收到後，給主機A傳送相應的確認報文段。主機A收到確認報文段後，記錄下當前的時間。那麼主機A記錄下的這兩個時間，它們的差值就是報文段的往返時間RTT。

如果超時重傳時間RTO的值設定得比RTT0的值小很多，這會引起報文段不必要的重傳，使網路負荷增大。

步驟流程2

如果超時重傳時間RTO的值設定得遠大於RTT0的值，這會使重傳時間推遲的太長，使網路的空閒時間增大，降低傳輸效率。

步驟流程3

注意：TCP下層是複雜的網際網路環境，主機A所傳送的報文段，可能只經過一個高速率的區域網，也有可能經過多個低速率的網路，每個IP資料報的轉發路由還可能不同。

5.3.2 超時重傳時間

RFC6298建議使用下式計算超時重傳時間RTO

5.3.3 往返時間RTT的測量比較複雜

存在問題

當傳送方出現超時重傳後，收到確認報文段時，是無法判斷出該確認，到底是對原報文段的確認。還是對重傳報文段的確認，也就是無法準確測量出RTT，進而無法正確計算超時重傳時間RTO。

解決方案

5.3.4 TCP超時重傳的計算

步驟分析1

這是測量到的第一個RTT樣本RTT1，根據RTTs1的計算公式可知RTTs1的值。根據RTTs1的計算公式可知RTTs1的值。根據RTTD1的計算公式可知RTTD1的值，再根據RTO的計算公式可計算出RTO1的值。這是測量到的第二個RTT樣本RTT2。根據RTTs的計算公式和 α的值，可寫出計算RTTs2的表示式。將之前計算出的RTTs1的值和本次測量到的RTT2的值帶入該式，可計算出RTTs2的值。

步驟分析2

根據RTTD的計算公式和 β的值，可以寫出計算RTTD2的表示式。將之前計算出的RTTD1、RTTs1、以及本次測量到的RTT2的值代入該公式，可計算出RTTD2的值，再根據RTO的計算公式可計算出RTO2的值。

步驟分析3

假設這是測量到的第五個RTT樣本，但是根據RTO4的值可知，在收到確認之前就會產生超時重傳。則不採用上述公式計算RTO，而是將新RTO的值取為舊RTO值的兩倍。因此RTO5的值取為兩倍的RTO4的值。

5.3.5 小結

5.4 TCP可靠傳輸的實現

5.4.1 案例說明

步驟流程1

假定資料傳輸只在一個方向進行，傳送方給接收方傳送TCP資料報文段，接收方給傳送方傳送相應的TCP確認報文段，這樣的好處是使討論僅限於兩個視窗，也就是傳送方的傳送視窗和接收方的接收視窗。TCP的滑動視窗是以位元組為單位的。

步驟流程2

假設傳送方收到了一個來自接收方的確認報文段，在報文段首部中的視窗欄位的值為20，也就是接收方表明自己的接收視窗的尺寸為20位元組。確認號欄位的值為31，這表明接收方希望收到下一個資料的序號是31，而序號30為止的資料已經全部正確接收了。

步驟流程3

傳送方根據這兩個欄位的值構造出自己的傳送視窗，假定網路不存在擁塞問題，也就是傳送方在構造自己的傳送視窗時，僅僅考慮接收方的接收視窗，而不是考慮擁塞視窗。傳送方在沒有收到接收方確認的情況下，可以把傳送視窗內的資料依次全部發送出去。凡是已經發送過的資料，在未收到確認之前，都必須暫時保留，以便在超時重傳時使用。傳送視窗後沿的後面部分，是已傳送並收到確認定位資料位元組的序號，這些資料位元組顯然不需要再儲存在傳送快取中了，可以將它們刪除。傳送視窗前沿的前面是當前不允許傳送的資料位元組的序號，傳送視窗的後沿不可能向後移動，因為不能撤銷掉已收到的確認。

如何描述傳送視窗的狀態？

假定傳送方將傳送視窗內序號31-41的資料，封裝在幾個不同的報文段中傳送出去。此時傳送視窗的位置並沒有改變。傳送視窗內序號31_{41的資料已經發送但是未收到確認，而序號42}50的資料是允許傳送但是還未傳送的。可以使用三個指標P1，P2，P3分別指向相應的位元組序號。

步驟流程4

繼續看接收方的接收視窗，它的尺寸為20。在接收視窗外面到30號為止的資料，是已經發送過相應確認並已交付給應用程序的資料。因此無需再保留這些資料，可將它們從接收快取中刪除了。接收視窗內31~50號資料是允許接收的資料，接收視窗外51號及其後續資料，目前不允許接收。假設傳送方之前傳送的，封裝有32和33號資料的報文段到達了接收方。

由於資料序號落在接收視窗內，所以接收方接受他們。將它們存入接收快取，但是，它們是未按序到達的資料，因為31號資料還沒有到達，這有可能丟了，也有可能是滯留在網路中的某處。請注意：接收方只能對按序收到的資料中的最高序號給出確認。因此，接收方發出的確認報文段中的確認序號仍然是31，也就是希望收到31號資料，視窗欄位的值仍然是20，表明接收方沒有改變自己接收視窗的大小。

傳送方收到該確認報文段後，發現這是一個針對31號資料的重複確認，就知道接收方收到了未按序到達的資料。由於這是針對31號資料的第一個重複確認，因此這並不會引起傳送方針對該資料的快重傳。另外，接收方通知的視窗尺寸仍是20。現在假設封裝有31號資料的報文段到達了接收方，接收方接受該報文段，將其封裝的31號資料存入接收快取。

將其封裝的31號資料存入接收快取，接收方現在可將接收到的31~33號資料交付給應用程序。然後將接收視窗向前移動3個序號，並給傳送方傳送確認報文段。該確認報文段中視窗欄位的值仍為20，表明接收方沒有改變自己接收視窗的大小。確認號欄位的值為34，這表明接收方已經收到了序號33為止的全部資料。

步驟流程5

現在，假設又有幾個資料報文段到達了接收方，它們封裝有37、38以及40號資料。這些資料的序號雖然落在接收視窗內，但它們都是未按序到達的資料，只能先暫存在接收快取中。

假設接收方先前傳送的確認報文段到達了傳送方，傳送方接收後，將傳送視窗向前滑動3個序號。

傳送視窗的尺寸儲存不變，這樣就有新序號51_{53落入傳送視窗內，而且序號31}33移出了傳送視窗，現在可將31~33號資料從傳送快取中刪除了，因為已經收到了接收方針對它們的確認。

傳送方繼續將傳送視窗內序號42~53的資料，封裝在幾個不同的報文段中傳送出去。現在，傳送視窗內的序號已經用完了，傳送方在未收到接收方來確認的情況下，不能再發送新的資料。序號落在傳送視窗內的已傳送資料，如果遲遲收不到接收方的確認，則會產生超時重傳。

5.4.2 解決方案

6- TCP的運輸連線管理

6.1 基本概念

6.2 TCP的連線建立

前置步驟

• TCP 建立連線的過程叫做握手。
• 握手需要在客戶和伺服器之間交換三個 TCP 報文段。稱之為三報文握手。
• 採用三報文握手主要是為了防止已失效的連線請求報文段突然又傳送到了，因而產生錯誤。

TCP的連線建立要解決以下三個問題

6.2.1三報文握手建立連線

流程步驟1

TCP 連線的建立採用客戶伺服器方式，主動發起連線建立的應用程序叫做TCP客戶 (client)。被動等待連線建立的應用程序叫做TCP伺服器 (server)。

“握手”需要在TCP客戶端和伺服器之間交換三個TCP報文段，最初兩端的TCP程序都處於關閉狀態。

流程步驟2

一開始，TCP伺服器程序首先建立傳輸控制塊，用來儲存TCP連線中的一些重要資訊。例如TCP連線表、指向傳送和接收快取的指標、指向重傳佇列的指標，當前的傳送和接收序號等之後，就準備接受TCP客戶端程序的連線請求。此時，TCP伺服器程序就進入監聽狀態，等待TCP客戶端程序的連線請求。

TCP伺服器程序是被動等待來自TCP客戶端程序的連線請求，因此成為被動開啟連線

流程步驟3

TCP客戶程序也是首先建立傳輸控制塊，由於TCP連線建立是由TCP客戶端主動發起的，因此稱為主動開啟連線。然後，在打算建立TCP連線時，向TCP伺服器程序傳送TCP連線請求報文段，並進入同步已傳送狀態。TCP連線請求報文段首部中，同步位SYN被設定為1，表明這是一個TCP連線請求報文段。序號欄位seq被設定了一個初始值x，作為TCP客戶端程序所選擇的初始序號，請注意：TCP規定SYN被設定為1的報文段不能攜帶資料，但要消耗掉一個序號。

流程步驟4

TCP伺服器程序收到TCP連線請求報文段後，如果同意建立連線，則向TCP客戶程序傳送TCP連線請求確認報文段，並進入同步已接收狀態TCP連線請求確認報文段首部中，同步位SYN和確認為ACK都設定為1，表明這是一個TCP連線請求確認報文段，序號欄位seq被設定了一個初始值y，作為TCP伺服器程序所選擇的初始序號。確認號欄位ack的值被設定成了x+1，這是對TCP客戶程序所選擇的初始序號（seq）的確認。請注意：這個報文段也不能攜帶資料，因為它是SYN被設定為1的報文段，但同樣要消耗掉一個序號。

TCP客戶程序收到TCP連線請求確認報文段後，還要向TCP伺服器程序傳送一個普通的TCP確認報文段，並進入連線已連線狀態。普通的TCP確認報文段首部中確認位ACK被設定為1，表明這是一個普通的TCP確認報文段，序號欄位seq被設定為x+1，這是因為TCP客戶程序傳送的第一個TCP報文段的序號為x，所以TCP客戶程序傳送的第二個報文段的序號為x+1。確認號欄位ack被設定為y+1，這是對TCP伺服器程序所選擇的初始序號的確認。請注意：TCP規定普通的TCP確認報文段可以攜帶資料，但如果不攜帶資料，則不消耗序號。

流程步驟5

TCP伺服器程序收到該確認報文段後也進入連線已建立狀態，現在，TCP雙方都進入了連線已建立狀態，它們可以基於已建立好的TCP連線，進行可靠的資料傳輸。

6.2.2 兩報文握手

為什麼TCP客戶程序最後還要傳送一個普通的TCP確認報文段？能否使用“兩報文握手”建立連線？

流程步驟

TCP客戶程序發出一個TCP連線請求報文段、但該報文段在某些網路結點長時間滯留了，這必然會造成該報文段的超時重傳，假設重傳的報文段被TCP伺服器程序正常接收。TCP伺服器程序給TCP客戶程序傳送一個TCP連線請求確認報文段，並進入連線已建立狀態。

請注意: 由於我們改為"兩報文握手"

因此TCP伺服器程序傳送完TCP連線請求確認報文段後，進入的是連線已建立狀態，而不像"三報文握手"那樣進入同步已連線狀態，並等待TCP客戶程序發來針對TCP連線請求確認報文段的普通確認報文段。TCP客戶程序收到TCP連線請求確認報文段後，進入TCP連線已建立狀態。但不會給TCP伺服器程序傳送針對該報文段的普通確認報文段。現在，TCP雙方都處於連線已建立狀態。它們可以相互傳輸資料。之後，可以通過“四報文揮手”來釋放連線，TCP雙方都進入了關閉狀態。

一段時間後，之前滯留在網路中的那個失效的TCP連線請求報文段、到達了TCP伺服器程序。TCP伺服器程序會誤認為這是TCP客戶程序，又發起一個新的TCP連線請求。於是給TCP客戶程序傳送TCP連線請求確認報文段，並進入連線已建立狀態。該報文段到達TCP客戶程序，由於TCP客戶程序並沒有發起新的TCP連線請求，並且處於關閉狀態，因此不會理會該報文段。但是TCP伺服器程序已經進入連線已建立狀態，它認為新的TCP連線已經建立好了，並且一直等待TCP客戶程序發來資料，這將白白浪費TCP伺服器程序所在主機的很多資源。

得出結論

採用"三報文握手"而不是"兩報文握手"來建立TCP連線，是為了防止已失效的連線請求報文段突然又傳送到了TCP伺服器，因而導致錯誤。

6.2.3 小結

6.3 TCP的連線釋放

6.3.1 前置步驟

• TCP 連線釋放過程比較複雜。
• 資料傳輸結束後，通訊的雙方都可釋放連線。TCP 連線釋放過程是四報文握手。

6.3.2 四報文揮手來釋放連線

• TCP 連線的建立採用客戶伺服器方式。
• 主動發起連線建立的應用程序叫做TCP客戶 (client)。
• 被動等待連線建立的應用程序叫做TCP伺服器 (server)。
• 任何一方都可以在資料傳送結束後發出連線釋放的通知

6.3.3 執行流程

流程步驟1

現在TCP客戶程序和TCP伺服器程序都處於連線已建立狀態，TCP客戶程序的應用程序通知其主動關閉TCP連線。TCP客戶程序會發送TCP連線釋放報文段，並進入終止等待1狀態，TCP連線釋放報文段首部中。終止位FIN和確認為ACK的值都被設定為1，表明這是一個TCP連線釋放報文段，同時也對之前收到的報文段進行確認序號seq欄位的值設定為u，它等於TCP客戶程序之前已傳送過的資料的最後一個位元組的序號加1，確認號ack欄位的值設定為v，它等於TCP客戶程序之前已收到的、資料的最後一個位元組的序號加1。請注意：TCP規定終止位FIN等於1的報文段即使不攜帶資料，也要消耗掉一個序號。

流程步驟2

TCP伺服器程序收到TCP連線釋放報文段後，會發送一個普通的TCP確認報文段並進入關閉等待狀態，普通的TCP確認報文段首部中。確認位ACK的值被設定為1，表明這是一個普通的TCP確認報文段。序號seq欄位的值設定為v，它等於TCP伺服器程序之前已傳送過的資料的最後一個位元組的序號加1，這也與之前收到的TCP連線釋放報文段中的確認號匹配，確認號ack欄位的值設定為u+1，這是對TCP連線釋放報文段的確認。

流程步驟3

TCP伺服器程序應該通知高層應用程序，TCP客戶程序要斷開與自己的TCP連線。此時，從TCP客戶程序到TCP伺服器程序這個方向的連線就釋放了。這時的TCP連線屬於半關閉狀態，也就是TCP客戶程序已經沒有資料要傳送了。但如果TCP伺服器程序還有資料要傳送，TCP客戶程序仍要接收，也就是說從TCP伺服器程序到TCP客戶程序這個方向的連線並未關閉。

流程步驟4

TCP客戶程序收到TCP確認報文段後就進入終止等待2狀態，等待TCP伺服器程序發出的TCP連線釋放報文段。若使用TCP伺服器程序的應用程序已經沒有資料要傳送了，應用程序就通知其TCP伺服器程序釋放連線。由於TCP連線釋放是由TCP客戶程序主動發起的，因此TCP伺服器程序對TCP連線的釋放稱為被動關閉連線。

流程步驟5

TCP伺服器程序傳送TCP連線釋放報文段並進入最後確認狀態，該報文段首部中。終止位FIN和確認位ACK的值都被設定為1，表明這是一個TCP連線釋放報文段，同時也對之前收到的報文段進行確認，序號seq欄位的值為w，這是因為在半關閉狀態下，TCP伺服器程序可能又傳送。確認號ack欄位的值為u+1，這是對之前收到的TCP連線釋放報文段的重複確認。

流程步驟6

TCP客戶程序收到TCP連線釋放報文段後，必須針對該報文段傳送普通的TCP確認報文段，之後進入時間等待狀態。該報文段首部中確認為ACK的值被設定為1，表明這是一個普通的TCP確認報文段。序號seq欄位的值設定為u+1，這是因為TCP客戶程序之前傳送的TCP連線釋放報文段雖然不攜帶資料，但要消耗掉一個序號。確認號ack欄位的值設定為w+1，這是對所收到的TCP連線釋放報文段的確認。TCP伺服器程序收到該報文段後就進入關閉狀態，而TCP客戶程序還要進過2MSL後才能進入關閉狀態。

TCP客戶程序在傳送完最後一個確認報文後，為什麼不直接進入關閉狀態？而是要進入時間等待狀態？

TCP伺服器程序傳送TCP連線釋放報文段後進入最後確認狀態。TCP客戶程序收到該報文段後，傳送普通的TCP確認報文段，並進入關閉狀態而不是時間等待狀態。然而，該TCP確認報文段丟失了。這必然會造成TCP伺服器程序對之前所傳送的TCP連線釋放報文段的超時重傳，並仍處於最後的確認狀態。重傳的TCP連線釋放報文段到達TCP客戶程序。由於TCP客戶程序屬於關閉狀態，因此不理睬該報文段，這必然會造成TCP伺服器程序反覆重傳TCP連線釋放報文段，並一直處於最後確認狀態而無法進入關閉狀態。因此，時間等待狀態以及處於該狀態2MSL時長，可以確保TCP伺服器程序可以收到最後一個TCP確認報文段而進入關閉狀態。另外，TCP客戶程序在傳送完最後一個TCP確認報文段後，再經過2MSL時長，就可以使本次連線持續時間內所產生的所有報文段都從網路中消失，這樣就可以使下一個新的TCP連線中，不會出現舊連線中的報文段。

6.4 TCP保活計時器的作用

TCP雙方已經建立了連線，後來，TCP客戶程序所在的主機突然出現了故障。

TCP伺服器程序以後就不能再收到TCP客戶程序發來的資料，因此，應當有措施使TCP伺服器程序不要再白白等待下去。

7- TCP報文段的首部格式

7.1 基本概念

7.2 源埠和目的埠

源埠和目的埠的作用

假設主機中的瀏覽器程序，要訪問Web伺服器中的Web伺服器程序。當在瀏覽器位址列中輸入了Web伺服器的域名後，瀏覽器程序會構建一個封裝有HTTP請求報文的TCP報文段，該報文段首部中的源埠欄位會填寫一個短暫埠號，例如49152，用來標識傳送該報文段的瀏覽器程序。目的埠欄位會填寫熟知埠號80，因為使用HTTP協議的Web伺服器程序預設監聽該埠。

Web伺服器收到該TCP報文段後，從中解封出HTTP請求報文，並根據TCP報文段首部中目的埠欄位的值，將HTTP請求報文上交給Web伺服器程序。Web伺服器程序根據HTTP請求報文的內容進行相應處理，並構建一個HTTP響應報文。HTTP響應報文需要封裝成TCP報文段進行傳送。該報文段首部中的源埠欄位會填寫熟知埠號80，用來標識傳送該TCP報文段的Web伺服器程序。而目的埠欄位會填寫49152，這是主機中需要接收該TCP報文段的瀏覽器程序所對應的埠號。

主機收到該TCP報文段後，從中解封出HTTP響應報文，並根據TCP報文段首部中目的埠欄位的值49152，將HTTP響應報文上交給瀏覽器程序。瀏覽器程序對HTTP響應報文的內容進行解析並且顯示。

7.3 序號、確認號和確認標誌位

流程步驟

TCP客戶程序傳送一個TCP報文段，該報文段首部中序號欄位的取值為201，這表示該TCP報文段資料載荷的第一個位元組的序號為201。假設資料載荷的長度為100位元組，首部中確認號欄位的取值為800，這表示TCP客戶程序收到了TCP伺服器程序發來的，序號到799為止的全部資料，現在期望收到序號從800開始的資料。為了使確認號欄位有效，首部中的確認標誌位ACK的值必須設定為1。

TCP伺服器程序收到該報文段後，也給TCP客戶程序傳送TCP報文段。該報文段首部中序號欄位的取值為800，這表示該TCP報文段資料載荷的第一個位元組的序號為800，這正好與TCP客戶程序的確認相匹配。

假設資料載荷的長度為200位元組。首部中確認號欄位的取值為301，這表示TCP伺服器程序收到了TCP客戶程序發來的，序號到300為止的全部資料，現在期望收到序號從301開始的資料。為了使確認號欄位有效，首部中的確認標誌位ACK的值必須設定為1。

7.4 資料偏移、保留、視窗和校驗和

​

分析

假設這個TCP報文段首部中的資料偏移欄位的取值為二進位制的0101，那麼首部長度就為20位元組。因為二進位制0101的十進位制值是5，而該欄位以4位元組為單位，因此5乘以4位元組等於20位元組。

​

分析

假設這個TCP報文段首部中的資料偏移欄位的取值為二進位制的1111，那麼首部的長度就為60位元組，因為二進位制1111的十進位制是15，而該欄位以4位元組為單位，因此15乘以4位元組等於60位元組。

​

​

注意事項

傳送視窗的大小還取決於擁塞視窗的大小，也就是應該從接收視窗和擁塞視窗中的取小者，TCP報文段首部中的檢驗和欄位。

7.5 同步標誌位、終止標誌位、復位標誌位、推送標誌位、緊急標誌位和緊急指標

同步標誌位

TCP通過"三報文握手"建立連線的過程。TCP客戶程序傳送的TCP連線請求報文段，首部中的同步標誌位SYN被置於1，表明這是一個TCP連線請求報文段。TCP伺服器程序傳送的TCP連線請求確認報文段，首部中的同步標誌位SYN被置1，確認位ACK也被置1，表明這是一個TCP連線請求確認報文段。

終止標誌位

不管是TCP客戶程序還是TCP伺服器程序，它們所傳送的TCP連線釋放報文段，首部中的終止標誌位FIN都被置1，表明這是TCP連線釋放報文段。

復位標誌位

推送標誌位

緊急標誌位和緊急指標

7.6 選項和填充