計算機網路筆記（湖科大）_ Part 05 傳輸層

文章參考于B站：計算機網路微課堂

五、傳輸層

本質：行程之間的通信

• 從通信和資訊處理的角度看，運輸層向它上面的應用層提供通信服務，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層，

• 當網路的邊緣部分中的兩個主機使用網路的核心部分的功能進行端到端的通信時，只有位于網路邊緣部分的主機的協議堆疊才有運輸層，而網路核心部分中的路由器在轉發分組時都只用到三層（到網路層）的功能，

行程間的通訊流程

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

梳理一下：

? 我們通訊的本質還是網路1中的一臺計算機中的某個行程與另一個網路2中的某個行程之間的通訊，例如QQ，微信,我們的網路層解決了不同網路中的通訊問題，資料鏈路層解決了同一網路中的鏈路之間的的通訊問題，物理層負責傳輸bit流，到此我們只是講2個網路中的主機聯系起來，我們QQ和微信則是運行在計算機的一個行程，行程占用計算機埠，由此我們運輸層解決的就是這么一個問題，就是我們同通過一臺主機中的一個行程，與另一臺計算機的另外一個行程完成通信！

一、埠號、復用和分用

1、為什么使用埠號？

2、發送方的復用和接收方的分用

多個行程（這里一個埠表示一個行程） 利用一個運輸層協議（或者稱為運輸層介面）發送資料稱為 復用

多個行程（這里一個埠表示一個行程） 利用一個運輸層協議（或者稱為運輸層介面）接收時叫做 分用，

3、TCP/IP體系的應用層常用協議所使用的運輸層熟知埠號

我們要直到協議是會占用服務器的埠號的！

舉個例子：FTP協議（檔案傳輸協議）

當我們的兩臺主機需要進行檔案傳輸的話，需要滿足這個應用層協議，如：我們從本機向Linux的服務器上上傳檔案，我們可以將服務器看作一個FTP服務器，我們本機訪問需要訪問服務器的21埠，選擇ftp協議

、

4、運輸層傳輸流程

在瀏覽器輸入域名，回車瀏覽

然后用戶PC中的DNS客戶端行程會發送一個DNS查詢請求報文

DNS查詢請求報文需要使用運輸層的UDP協議

• 首部中的源埠欄位的值，在短暫埠號49151~65535中挑選一個未被占用的，用來表示DNS客戶端行程
• 首部中的目的埠欄位的值：53，是DNS服務器端行程所使用的熟知埠號

我們通過DNS服務器決議出該域名對應的ip地址

之后，將UDP用戶資料報封裝在IP資料報中，通過以太網發送給DNS服務器

DNS服務器收到該IP資料報后，從中解封出UDP用戶資料報

UDP首部中的目的埠號為53，這表明應將該UDP用戶資料報的資料載荷部分，也就是DNS查詢請求報文，交付給本服務器中的DNS服務器端行程

DNS服務器端行程決議DNS查詢請求報文的內容，然后按其要求查找對應的IP地址

之后，會給用戶PC發送DNS回應報文，DNS回應報文需要使用運輸層的UDP協議封裝成UDP用戶資料報

其首部中的源埠欄位的值設定為熟知埠號53，表明這是DNS服務器端行程所發送的UDP用戶資料報，目的埠的值設定為49152，這是之前用戶PC中發送DNS查詢請求報文的DNS客戶端行程所使用的短暫埠號

現在用戶PC中的HTTP客戶端行程可以向Web服務器發送HTTP請求報文（和DNS發送和接收流程差不多）

第一步

第二步

第三步

第四步

第五步

二、UDP和TCP的對比 [重點]

UDP 和 TCP 是TCP/IP體系結構運輸層中的兩個重要協議

• 當運輸層采用面向連接的 TCP 協議時，盡管下面的網路是不可靠的（只提供盡最大努力服務），但這種邏輯通信信道就相當于一條全雙工的可靠信道，
• 當運輸層采用無連接的 UDP 協議時，這種邏輯通信信道是一條不可靠信道，

可靠信道與不可靠信道

兩個對等運輸物體在通信時傳送的資料單位叫作運輸協議資料單元 TPDU (Transport Protocol Data Unit)，

• TCP 傳送的資料單位協議是 TCP 報文段(segment)，
• UDP 傳送的資料單位協議是 UDP 報文或用戶資料報，

• UDP的通信是無連接的，不需要套接字（Socket）
• TCP是面向連接的，TCP之間的通信必須要在兩個套接字（Socket）之間建立連接

1、用戶資料報協議UDP（User Datagram Protocol）

可以發送廣播

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

還可以發送單播

UDP 支持單播、多播以及廣播

換句話說，UDP支持一對一，一對多，以及一對全的通信

運輸程序

UDP對應用行程交下來的報文既不合并也不拆分，而是保留這些報文的邊界

換句話說，UDP是面向應用報文的

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

UDP結構

2、傳輸控制協議TCP（Transmission Control Protocol）

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

TCP連接建立成功后，通信雙方之間就好像有一條可靠的通信信道，通信雙方使用這潭訓于TCP連接的可靠信道進行通信

很顯然，TCP僅支持單播，也就是一對一的通信

運輸程序

發送方

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

接收方

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

TCP是面向位元組流的，這正是TCP實作可靠傳輸、流量控制、以及擁塞控制的基礎

本圖只畫了一個方向的資料流，在實際網路中，基于TCP連接的兩端，可以同時進行TCP報文段的發送和接收

TCP結構

小節

三、TCP的流量控制

1、概述

舉例

具體流程的演示教程

上圖主機A現在可將發送快取中序號1~200的位元組資料全部洗掉，因為已經收到了主機B對它們的累計確認

上圖主機A現在可將發送快取中序號201~500的位元組資料全部洗掉，因為已經收到了主機B對它們的累計確認

上圖主機A現在可將發送快取中序號501~600的位元組資料全部洗掉，因為已經收到了主機B對它們的累計確認

上圖如果零視窗探測報文在發送程序中如果丟失，還是能打破死鎖局面

因為零視窗探測報文段也有重傳計時器，重傳計時器超時后，零視窗探測報文段會被重傳

2、小結

四、TCP的擁塞控制

1、概念

負載可以理解TCP報文段數量，吞吐量就是網路實際處理的資料量的能力

網路擁塞往往是由許多因素引起的，例如：

1. 點快取的容量太小；
2. 鏈路的容量不足；
3. 處理機處理的速率太慢；
4. 擁塞本身會進一步加劇擁塞；

擁塞控制的一般原理

• 擁塞控制的前提：網路能夠承受現有的網路負荷，
• 實踐證明，擁塞控制是很難設計的，因為它是一個動態問題，
• 分組的丟失是網路發生擁塞的征兆而不是原因，
• 在許多情況下，甚至正是擁塞控制本身成為引起網路性能惡化、甚至發生死鎖的原因

開環控制和倍訓控制

監測網路的擁塞

主要指標有：

1. 由于缺少快取空間而被丟棄的分組的百分數；
2. 平均佇列長度；
3. 超時重傳的分組數；
4. 平均分組時延；
5. 分組時延的標準差，等等，

上述這些指標的上升都標志著擁塞的增長，

2、擁塞控制的演算法

真正的發送視窗值 = Min (接收方視窗值，擁塞視窗值)

下圖的實體橫縱坐標的意思

傳輸輪次：

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

擁塞視窗：

• 它會隨網路擁塞程度，以及所使用的擁塞控制演算法動態變化

3、慢開始和擁塞避免

慢開始（slow-start）

• 目的：用來確定網路的負載能力或擁塞程度，

• 演算法的思路：由小到大逐漸增大擁塞視窗數值，

• 兩個變數：

  擁塞視窗（cwnd）：初始擁塞視窗值：2 種設定方法，視窗值逐漸增大，

  • 1 至 2 個最大報文段 （舊標準）
  • 2 至 4 個最大報文段 （RFC 5681）

擁塞避免（congestion avoidance）

• 思路：讓擁塞視窗 cwnd 緩慢地增大，避免出現擁塞，
• 每經過一個傳輸輪次，擁塞視窗 cwnd = cwnd + 1，
• 使擁塞視窗 cwnd 按線性規律緩慢增長，
• 在擁塞避免階段，具有 “加法增大” (Additive Increase) 的特點，

如果在發送程序中出現部分報文段丟失，這必然會造成發送方對這些丟失報文段的超時重傳

這個時候又回到了慢開始

兩個演算法完整示意圖

補充一下：

• ? 慢開始指的是開始時TCP報文段的數量較少（擁塞視窗較小），并不是增長緩慢，視窗大小按指數增加，2的n-1次方
• ? 擁塞避免也不是真的避免了擁塞，而是發生擁塞的時候處理的一種演算法

4、快重傳和快恢復

簡述：當即使發送的報文段失真，也讓我們的接受方重復回傳上一個正常接受的報文段，避免造成發送方誤以為發生擁塞

快重傳（fast retrasmit）

快恢復（fast recovery）

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

五、TCP超時重傳時間的選擇

難點在于每次TCP報文段的往返時間RTT是不確定的 ；

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

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

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

往返時間RTT的測量比較復雜

TCP超時重傳的計算
總結

六、TCP可靠傳輸的實作

具體流程視頻講解

七、TCP的運輸連接管理【重點】

1、概述

2、TCP的連接建立

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

1、TCP的連接建立要解決以下三個問題

2、TCP使用“三報文握手”建立連接

• TCP 連接的建立采用客戶服務器方式，
• 主動發起連接建立的應用行程叫做TCP客戶 (client)，
• 被動等待連接建立的應用行程叫做TCP服務器 (server)，

“握手”需要在TCP客戶端和服務器之間交換三個TCP報文段

最初兩端的TCP行程都處于關閉狀態

一開始，TCP服務器行程首先創建傳輸控制塊，用來存盤TCP連接中的一些重要資訊，例如TCP連接表、指向發送和接收快取的指標、指向重傳佇列的指標，當前的發送和接收序號等

之后，就準備接受TCP客戶端行程的連接請求

此時，TCP服務器行程就進入監聽狀態，等待TCP客戶端行程的連接請求

TCP服務器行程是被動等待來自TCP客戶端行程的連接請求，因此成為被動打開連接

TCP客戶行程也是首先創建傳輸控制塊

由于TCP連接建立是由TCP客戶端主動發起的，因此稱為主動打開連接

然后，在打算建立TCP連接時，向TCP服務器行程發送TCP連接請求報文段，并進入同步已發送狀態

TCP連接請求報文段首部中

• 同步位SYN被設定為1，表明這是一個TCP連接請求報文段
• 序號欄位seq被設定了一個初始值x，作為TCP客戶端行程所選擇的初始序號

請注意：TCP規定SYN被設定為1的報文段不能攜帶資料，但要消耗掉一個序號

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確認報文段可以攜帶資料，但如果不攜帶資料，則不消耗序號

TCP服務器行程收到該確認報文段后也進入連接已建立狀態

現在，TCP雙方都進入了連接已建立狀態，它們可以基于已建立好的TCP連接，進行可靠的資料傳輸

為什么TCP客戶行程最后還要發送一個普通的TCP確認報文段？能否使用“兩報文握手”建立連接？

下圖實體是“兩報文握手”

所以并不多余，這是為了防止已失效的連接請求報文段突然又傳送到了TCP服務器，因而導致錯誤

3、總結

3、TCP的連接釋放

• TCP 連接釋放程序比較復雜，
• 資料傳輸結束后，通信的雙方都可釋放連接，
• TCP 連接釋放程序是四報文握手，

1、TCP通過“四報文揮手”來釋放連接

• TCP 連接的建立采用客戶服務器方式，
• 主動發起連接建立的應用行程叫做TCP客戶 (client)，
• 被動等待連接建立的應用行程叫做TCP服務器 (server)，
• 任何一方都可以在資料傳送結束后發出連接釋放的通知

程序

現在TCP客戶行程和TCP服務器行程都處于連接已建立狀態

TCP客戶行程的應用行程通知其主動關閉TCP連接

TCP客戶行程會發送TCP連接釋放報文段，并進入終止等待1狀態

TCP連接釋放報文段首部中

• 終止位FIN和確認為ACK的值都被設定為1，表明這是一個TCP連接釋放報文段，同時也對之前收到的報文段進行確認
• 序號seq欄位的值設定為u，它等于TCP客戶行程之前已傳送過的資料的最后一個位元組的序號加1
• 確認號ack欄位的值設定為v，它等于TCP客戶行程之前已收到的、資料的最后一個位元組的序號加1

請注意：TCP規定終止位FIN等于1的報文段即使不攜帶資料，也要消耗掉一個序號

TCP服務器行程收到TCP連接釋放報文段后，會發送一個普通的TCP確認報文段并進入關閉等待狀態

普通的TCP確認報文段首部中

• 確認位ACK的值被設定為1，表明這是一個普通的TCP確認報文段
• 序號seq欄位的值設定為v，它等于TCP服務器行程之前已傳送過的資料的最后一個位元組的序號加1，這也與之前收到的TCP連接釋放報文段中的確認號匹配
• 確認號ack欄位的值設定為u+1，這是對TCP連接釋放報文段的確認

TCP服務器行程應該通知高層應用行程，TCP客戶行程要斷開與自己的TCP連接

此時，從TCP客戶行程到TCP服務器行程這個方向的連接就釋放了

這時的TCP連接屬于半關閉狀態，也就是TCP客戶行程已經沒有資料要發送了

但如果TCP服務器行程還有資料要發送，TCP客戶行程仍要接收，也就是說從TCP服務器行程到TCP客戶行程這個方向的連接并未關閉

TCP客戶行程收到TCP確認報文段后就進入終止等待2狀態，等待TCP服務器行程發出的TCP連接釋放報文段

若使用TCP服務器行程的應用行程已經沒有資料要發送了，應用行程就通知其TCP服務器行程釋放連接

由于TCP連接釋放是由TCP客戶行程主動發起的，因此TCP服務器行程對TCP連接的釋放稱為被動關閉連接

TCP服務器行程發送TCP連接釋放報文段并進入最后確認狀態

該報文段首部中

• 終止位FIN和確認位ACK的值都被設定為1，表明這是一個TCP連接釋放報文段，同時也對之前收到的報文段進行確認
• 序號seq欄位的值為w，這是因為在半關閉狀態下，TCP服務器行程可能又發送
• 確認號ack欄位的值為u+1，這是對之前收到的TCP連接釋放報文段的重復確認

TCP客戶行程收到TCP連接釋放報文段后，必須針對該報文段發送普通的TCP確認報文段，之后進入時間等待狀態

該報文段首部中

• 確認為ACK的值被設定為1，表明這是一個普通的TCP確認報文段
• 序號seq欄位的值設定為u+1，這是因為TCP客戶行程之前發送的TCP連接釋放報文段雖然不攜帶資料，但要消耗掉一個序號
• 確認號ack欄位的值設定為w+1，這是對所收到的TCP連接釋放報文段的確認

TCP服務器行程收到該報文段后就進入關閉狀態，而TCP客戶行程還要進過2MSL后才能進入關閉狀態

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

因為時間等待狀態以及處于該狀態2MSL時長，可以確保TCP服務器行程可以收到最后一個TCP確認報文段而進入關閉狀態

另外，TCP客戶行程在發送完最后一個TCP確認報文段后，在經過2MSL時長，就可以使本次連接持續時間內所產生的所有報文段都從網路中消失，這樣就可以使下一個新的TCP連接中，不會出現舊連接中的報文段

2、TCP保活計時器的作用

TCP雙方已經建立了連接，后來，TCP客戶行程所在的主機突然出現了故障

TCP服務器行程以后就不能再收到TCP客戶行程發來的資料

因此，應當措施使TCP服務器行程不要再白白等待下去

4、TCP報文段的首部格式

5、TCP報文段各欄位的作用

源埠和目的埠

序號、確認號和確認標志位

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

選項和填充