计算机网络第5章（传输层）
B站視頻：計算機網(wǎng)絡微課堂（有字幕無背景音樂版）
網(wǎng)址：https://www.bilibili.com/video/BV1c4411d7jb?p=61
目錄
- 5.1、運輸層概述
- 概念
- 總結
- 5.2、運輸層端口號、復用與分用的概念
- 為什么用端口號
- 發(fā)送方的復用和接收方的分用
- TCP/IP體系的應用層常用協(xié)議所使用的運輸層熟知端口號
- 運輸層傳輸流程
- 5.3、UDP和TCP的對比
- 概念
- 用戶數(shù)據(jù)報協(xié)議UDP（User Datagram Protocol）
- 傳輸控制協(xié)議TCP（Transmission Control Protocol）
- 總結
- 5.4、TCP的流量控制
- 概念
- 總結
- 5.5、TCP的擁塞控制
- 概念
- 擁塞控制的算法
- 慢開始和擁塞避免
- 慢開始（slow-start）
- 擁塞避免（congestion avoidance）
- 兩個算法完整示意圖
- 快重傳和快恢復
- 快重傳（fast retrasmit）
- 快恢復（fast recovery）
- 改進后的整體算法的示意圖
- 5.6、TCP超時重傳時間的選擇
- 5.7、TCP可靠傳輸?shù)膶崿F(xiàn)
- 5.8、TCP的運輸連接管理
- 概念
- TCP的連接建立
- TCP的連接建立要解決以下三個問題
- TCP使用“三報文握手”建立連接
- 總結
- TCP的連接釋放
- TCP通過“四報文揮手”來釋放連接
- TCP?；钣嫊r器的作用
- 5.9、TCP報文段的首部格式
- 各字段的作用
5.1、運輸層概述
概念
進程之間的通信
- 從通信和信息處理的角度看，運輸層向它上面的應用層提供通信服務，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層。
- 當網(wǎng)絡的邊緣部分中的兩個主機使用網(wǎng)絡的核心部分的功能進行端到端的通信時，只有位于網(wǎng)絡邊緣部分的主機的協(xié)議棧才有運輸層，而網(wǎng)絡核心部分中的路由器在轉發(fā)分組時都只用到三層（到網(wǎng)絡層）的功能。
進程之間通信流程
“邏輯通信”是指運輸層之間的通信好像是沿水平方向傳送數(shù)據(jù)，但事實上，這兩條數(shù)據(jù)并沒有一條水平方向的物理連接，要傳送的數(shù)據(jù)是沿著圖中上下多次的虛線方向傳送的
進程Ap1與Ap4之間進行基于網(wǎng)絡的通信，進程Ap2與Ap3之間進行基于網(wǎng)絡的通信
在運輸層使用不同的端口，來對應不同的應用進程
然后通過網(wǎng)絡層及其下層來傳輸應用層報文
接收方的運輸層通過不同的端口，將收到的應用層報文，交付給應用層中相應的應用進程
這里端口并不是指看得見、摸得著的物理端口，而是指用來區(qū)分不同應用進程的標識符
總結
5.2、運輸層端口號、復用與分用的概念
為什么用端口號
發(fā)送方的復用和接收方的分用
多個進程（這里一個端口表示一個進程） 利用一個運輸層協(xié)議（或者稱為運輸層接口）發(fā)送數(shù)據(jù)稱為 復用
多個進程（這里一個端口表示一個進程） 利用一個運輸層協(xié)議（或者稱為運輸層接口）接收時叫做 分用。
TCP/IP體系的應用層常用協(xié)議所使用的運輸層熟知端口號
運輸層傳輸流程
舉例
在瀏覽器輸入域名，回車瀏覽
然后用戶PC中的DNS客戶端進程會發(fā)送一個DNS查詢請求報文
DNS查詢請求報文需要使用運輸層的UDP協(xié)議
首部中的源端口字段的值，在短暫端口號49151~65535中挑選一個未被占用的，用來表示DNS客戶端進程
首部中的目的端口字段的值：53，是DNS服務器端進程所使用的熟知端口號
之后，將UDP用戶數(shù)據(jù)報封裝在IP數(shù)據(jù)報中，通過以太網(wǎng)發(fā)送給DNS服務器
DNS服務器收到該IP數(shù)據(jù)報后，從中解封出UDP用戶數(shù)據(jù)報
UDP首部中的目的端口號為53，這表明應將該UDP用戶數(shù)據(jù)報的數(shù)據(jù)載荷部分，也就是DNS查詢請求報文，交付給本服務器中的DNS服務器端進程
DNS服務器端進程解析DNS查詢請求報文的內容，然后按其要求查找對應的IP地址
之后，會給用戶PC發(fā)送DNS響應報文，DNS響應報文需要使用運輸層的UDP協(xié)議封裝成UDP用戶數(shù)據(jù)報
其首部中的源端口字段的值設置為熟知端口號53，表明這是DNS服務器端進程所發(fā)送的UDP用戶數(shù)據(jù)報，目的端口的值設置為49152，這是之前用戶PC中發(fā)送DNS查詢請求報文的DNS客戶端進程所使用的短暫端口號
將UDP用戶數(shù)據(jù)報封裝在IP數(shù)據(jù)報中，通過以太網(wǎng)發(fā)送給用戶PC
用戶PC收到該數(shù)據(jù)報后，從中解封出UDP用戶數(shù)據(jù)報
UDP首部中的目的端口號為49152，這表明應將該UDP用戶數(shù)據(jù)報的數(shù)據(jù)載荷部分，也就是DNS響應報文，交付給用戶PC中的DNS客戶端進程
DNS客戶端進程解析DNS響應報文的內容，就可知道自己之前所請求的Web服務器的域名對應的IP地址
現(xiàn)在用戶PC中的HTTP客戶端進程可以向Web服務器發(fā)送HTTP請求報文（和DNS發(fā)送和接收流程差不多）
5.3、UDP和TCP的對比
概念
- UDP 和 TCP 是TCP/IP體系結構運輸層中的兩個重要協(xié)議
- 當運輸層采用面向連接的 TCP 協(xié)議時，盡管下面的網(wǎng)絡是不可靠的（只提供盡最大努力服務），但這種邏輯通信信道就相當于一條全雙工的可靠信道。
- 當運輸層采用無連接的 UDP 協(xié)議時，這種邏輯通信信道是一條不可靠信道。
可靠信道與不可靠信道
-
兩個對等運輸實體在通信時傳送的數(shù)據(jù)單位叫作運輸協(xié)議數(shù)據(jù)單元 TPDU (Transport Protocol Data Unit)。
-
TCP 傳送的數(shù)據(jù)單位協(xié)議是 TCP 報文段(segment)。
-
UDP 傳送的數(shù)據(jù)單位協(xié)議是 UDP 報文或用戶數(shù)據(jù)報。
UDP的通信是無連接的，不需要套接字（Socket）
TCP是面向連接的，TCP之間的通信必須要在兩個套接字（Socket）之間建立連接
用戶數(shù)據(jù)報協(xié)議UDP（User Datagram Protocol）
可以發(fā)送廣播
可以向某個多播組發(fā)送多播
還可以發(fā)送單播
UDP 支持單播、多播以及廣播
換句話說，UDP支持一對一，一對多，以及一對全的通信
運輸過程
UDP對應用進程交下來的報文既不合并也不拆分，而是保留這些報文的邊界
換句話說，UDP是面向應用報文的
UDP向上層提供無連接不可靠傳輸服務
UDP結構
傳輸控制協(xié)議TCP（Transmission Control Protocol）
使用TCP協(xié)議的通信雙方，在進行數(shù)據(jù)傳輸之前，必須使用“三報文握手”建立TCP連接
TCP連接建立成功后，通信雙方之間就好像有一條可靠的通信信道，通信雙方使用這條基于TCP連接的可靠信道進行通信
很顯然，TCP僅支持單播，也就是一對一的通信
運輸過程
發(fā)送方
-
TCP會把應用進程交付下來的數(shù)據(jù)塊看作是一連串無結構的字節(jié)流，TCP并不知道這些待傳送的字節(jié)流的含義
-
并將他們編號，并存儲在自己發(fā)送緩存中
-
TCP會根據(jù)發(fā)送策略，提取一定量的字節(jié)構建TCP報文并發(fā)送
接收方
- 一方面從所接受到的TCP報文段中，取出數(shù)據(jù)載荷部分并存儲在接收緩存中；一方面將接收緩存中的一些字節(jié)交付給應用進程
- TCP不保證接收方應用進程所收到的數(shù)據(jù)塊與發(fā)送方發(fā)送的數(shù)據(jù)塊，具有對應大小的關系（例如，發(fā)送方應用進程交給發(fā)送方的TCP共10個數(shù)據(jù)塊，但接收方的TCP可能只用了4個數(shù)據(jù)塊，就把收到的字節(jié)流交付給了上層的應用進程，但接收方收到的字節(jié)流必須和發(fā)送方應用進程發(fā)出的字節(jié)流完全一樣）
- 接收方的應用進程必須有能力識別收到的字節(jié)流，把它還原成有意義的應用層數(shù)據(jù)
TCP是面向字節(jié)流的，這正是TCP實現(xiàn)可靠傳輸、流量控制、以及擁塞控制的基礎
本圖只畫了一個方向的數(shù)據(jù)流，在實際網(wǎng)絡中，基于TCP連接的兩端，可以同時進行TCP報文段的發(fā)送和接收
TCP向上層提供面向連接的可靠傳輸服務
TCP結構
總結
5.4、TCP的流量控制
概念
舉例
具體流程的視頻
上圖主機A現(xiàn)在可將發(fā)送緩存中序號1~200的字節(jié)數(shù)據(jù)全部刪除，因為已經收到了主機B對它們的累計確認
上圖主機A現(xiàn)在可將發(fā)送緩存中序號201~500的字節(jié)數(shù)據(jù)全部刪除，因為已經收到了主機B對它們的累計確認
上圖主機A現(xiàn)在可將發(fā)送緩存中序號501~600的字節(jié)數(shù)據(jù)全部刪除，因為已經收到了主機B對它們的累計確認
上圖如果零窗口探測報文在發(fā)送過程中如果丟失，還是能打破死鎖局面
因為零窗口探測報文段也有重傳計時器，重傳計時器超時后，零窗口探測報文段會被重傳
總結
5.5、TCP的擁塞控制
概念
網(wǎng)絡擁塞往往是由許多因素引起的。例如：
擁塞控制的一般原理
- 擁塞控制的前提：網(wǎng)絡能夠承受現(xiàn)有的網(wǎng)絡負荷。
- 實踐證明，擁塞控制是很難設計的，因為它是一個動態(tài)問題。
- 分組的丟失是網(wǎng)絡發(fā)生擁塞的征兆而不是原因。
- 在許多情況下，甚至正是擁塞控制本身成為引起網(wǎng)絡性能惡化、甚至發(fā)生死鎖的原因。
開環(huán)控制和閉環(huán)控制
監(jiān)測網(wǎng)絡的擁塞
主要指標有：
上述這些指標的上升都標志著擁塞的增長。
擁塞控制的算法
真正的發(fā)送窗口值 = Min (接收方窗口值，擁塞窗口值)
下圖的實例橫縱坐標的意思
傳輸輪次：
- 發(fā)送方給接收方發(fā)送數(shù)據(jù)報文段后，接收方給發(fā)送方發(fā)發(fā)回相應的確認報文段
- 一個傳輸輪次所經歷的時間其實就是往返時間，往返時間并非是恒定的數(shù)值
- 使用傳輸輪次是為了強調把擁塞窗口所允許發(fā)送的報文段都連續(xù)發(fā)送出去，并受到了對已發(fā)送的最后一個報文段的確認
擁塞窗口：
- 它會隨網(wǎng)絡擁塞程度，以及所使用的擁塞控制算法動態(tài)變化
慢開始和擁塞避免
慢開始（slow-start）
- 目的：用來確定網(wǎng)絡的負載能力或擁塞程度。
- 算法的思路：由小到大逐漸增大擁塞窗口數(shù)值。
- 兩個變量：
- 擁塞窗口（cwnd）：初始擁塞窗口值：2 種設置方法。窗口值逐漸增大。
- 1 至 2 個最大報文段 （舊標準）
- 2 至 4 個最大報文段 （RFC 5681）
- 慢開始門限（ssthresh）：防止擁塞窗口增長過大引起網(wǎng)絡擁塞。
- 擁塞窗口（cwnd）：初始擁塞窗口值：2 種設置方法。窗口值逐漸增大。
圖中swnd是發(fā)送窗口
每經過一個傳輸輪次，擁塞窗口就加倍
窗口大小按指數(shù)增加，2的n-1次方
擁塞避免（congestion avoidance）
- 思路：讓擁塞窗口 cwnd 緩慢地增大，避免出現(xiàn)擁塞。
- 每經過一個傳輸輪次，擁塞窗口 cwnd = cwnd + 1。
- 使擁塞窗口 cwnd 按線性規(guī)律緩慢增長。
- 在擁塞避免階段，具有 “加法增大” (Additive Increase) 的特點。
如果在發(fā)送過程中出現(xiàn)部分報文段丟失，這必然會造成發(fā)送方對這些丟失報文段的超時重傳
這個時候又回到了慢開始
兩個算法完整示意圖
快重傳和快恢復
快重傳（fast retrasmit）
快恢復（fast recovery）
改進后的整體算法的示意圖
5.6、TCP超時重傳時間的選擇
如果超時重傳時間RTO的值設置得比RTT0的值小很多，這會引起報文段不必要的重傳，使網(wǎng)絡負荷增大
如果超時重傳時間RTO的值設置得遠大于RTT0的值，這會使重傳時間推遲的太長，使網(wǎng)絡的空閑時間增大，降低傳輸效率
RFC6298建議使用下式計算超時重傳時間RTO
往返時間RTT的測量比較復雜
TCP超時重傳的計算
舉例
總結
5.7、TCP可靠傳輸?shù)膶崿F(xiàn)
本集具體講解
5.8、TCP的運輸連接管理
概念
TCP的連接建立
- TCP 建立連接的過程叫做握手。
- 握手需要在客戶和服務器之間交換三個 TCP 報文段。稱之為三報文握手。
- 采用三報文握手主要是為了防止已失效的連接請求報文段突然又傳送到了，因而產生錯誤。
TCP的連接建立要解決以下三個問題
TCP使用“三報文握手”建立連接
- TCP 連接的建立采用客戶服務器方式。
- 主動發(fā)起連接建立的應用進程叫做TCP客戶 (client)。
- 被動等待連接建立的應用進程叫做TCP服務器 (server)。
“握手”需要在TCP客戶端和服務器之間交換三個TCP報文段
過程
最初兩端的TCP進程都處于關閉狀態(tài)
一開始，TCP服務器進程首先創(chuàng)建傳輸控制塊，用來存儲TCP連接中的一些重要信息。例如TCP連接表、指向發(fā)送和接收緩存的指針、指向重傳隊列的指針，當前的發(fā)送和接收序號等
之后，就準備接受TCP客戶端進程的連接請求
此時，TCP服務器進程就進入監(jiān)聽狀態(tài)，等待TCP客戶端進程的連接請求
TCP服務器進程是被動等待來自TCP客戶端進程的連接請求，因此成為被動打開連接
TCP客戶進程也是首先創(chuàng)建傳輸控制塊
由于TCP連接建立是由TCP客戶端主動發(fā)起的，因此稱為主動打開連接
然后，在打算建立TCP連接時，向TCP服務器進程發(fā)送TCP連接請求報文段，并進入同步已發(fā)送狀態(tài)
TCP連接請求報文段首部中
- 同步位SYN被設置為1，表明這是一個TCP連接請求報文段
- 序號字段seq被設置了一個初始值x，作為TCP客戶端進程所選擇的初始序號
請注意：TCP規(guī)定SYN被設置為1的報文段不能攜帶數(shù)據(jù)，但要消耗掉一個序號
TCP服務器進程收到TCP連接請求報文段后，如果同意建立連接，則向TCP客戶進程發(fā)送TCP連接請求確認報文段，并進入同步已接收狀態(tài)
TCP連接請求確認報文段首部中
- 同步位SYN和確認為ACK都設置為1，表明這是一個TCP連接請求確認報文段
- 序號字段seq被設置了一個初始值y，作為TCP服務器進程所選擇的初始序號，
- 確認號字段ack的值被設置成了x+1，這是對TCP客戶進程所選擇的初始序號（seq）的確認
請注意：這個報文段也不能攜帶數(shù)據(jù)，因為它是SYN被設置為1的報文段，但同樣要消耗掉一個序號
TCP客戶進程收到TCP連接請求確認報文段后，還要向TCP服務器進程發(fā)送一個普通的TCP確認報文段，并進入連接已連接狀態(tài)
普通的TCP確認報文段首部中
- 確認位ACK被設置為1，表明這是一個普通的TCP確認報文段
- 序號字段seq被設置為x+1，這是因為TCP客戶進程發(fā)送的第一個TCP報文段的序號為x，所以TCP客戶進程發(fā)送的第二個報文段的序號為x+1
- 確認號字段ack被設置為y+1，這是對TCP服務器進程所選擇的初始序號的確認
請注意：TCP規(guī)定普通的TCP確認報文段可以攜帶數(shù)據(jù)，但如果不攜帶數(shù)據(jù)，則不消耗序號
TCP服務器進程收到該確認報文段后也進入連接已建立狀態(tài)
現(xiàn)在，TCP雙方都進入了連接已建立狀態(tài)，它們可以基于已建立好的TCP連接，進行可靠的數(shù)據(jù)傳輸
為什么TCP客戶進程最后還要發(fā)送一個普通的TCP確認報文段？能否使用“兩報文握手”建立連接？
下圖實例是“兩報文握手”
為了防止已經失效的連接請求報文段突然又傳到服務端，因而產生錯誤”，這種情況是：一端(client)A發(fā)出去的第一個連接請求報文并沒有> 丟失，而是因為某些未知的原因在某個網(wǎng)絡節(jié)點上發(fā)生滯留，導致延遲到連接釋放以后的某個時間才到達另一端(server)B。本來這是一個> 早已失效的報文段，但是B收到此失效的報文之后，會誤認為是A再次發(fā)出的一個新的連接請求，于是B端就向A又發(fā)出確認報文，表示同> 意建立連接。如果不采用“三次握手”，那么只要B端發(fā)出確認報文就會認為新的連接已經建立了，但是A端并沒有發(fā)出建立連接的請求，因> 此不會去向B端發(fā)送數(shù)據(jù)，B端沒有收到數(shù)據(jù)就會一直等待，這樣B端就會白白浪費掉很多資源。
所以并不多余，這是為了防止已失效的連接請求報文段突然又傳送到了TCP服務器，因而導致錯誤
總結
TCP的連接釋放
- TCP 連接釋放過程比較復雜。
- 數(shù)據(jù)傳輸結束后，通信的雙方都可釋放連接。
- TCP 連接釋放過程是四報文握手。
TCP通過“四報文揮手”來釋放連接
- TCP 連接的建立采用客戶服務器方式。
- 主動發(fā)起連接建立的應用進程叫做TCP客戶 (client)。
- 被動等待連接建立的應用進程叫做TCP服務器 (server)。
- 任何一方都可以在數(shù)據(jù)傳送結束后發(fā)出連接釋放的通知
過程
現(xiàn)在TCP客戶進程和TCP服務器進程都處于連接已建立狀態(tài)
TCP客戶進程的應用進程通知其主動關閉TCP連接
TCP客戶進程會發(fā)送TCP連接釋放報文段，并進入終止等待1狀態(tài)
TCP連接釋放報文段首部中
- 終止位FIN和確認為ACK的值都被設置為1，表明這是一個TCP連接釋放報文段，同時也對之前收到的報文段進行確認
- 序號seq字段的值設置為u，它等于TCP客戶進程之前已傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加1
- 確認號ack字段的值設置為v，它等于TCP客戶進程之前已收到的、數(shù)據(jù)的最后一個字節(jié)的序號加1
請注意：TCP規(guī)定終止位FIN等于1的報文段即使不攜帶數(shù)據(jù)，也要消耗掉一個序號
TCP服務器進程收到TCP連接釋放報文段后，會發(fā)送一個普通的TCP確認報文段并進入關閉等待狀態(tài)
普通的TCP確認報文段首部中
- 確認位ACK的值被設置為1，表明這是一個普通的TCP確認報文段
- 序號seq字段的值設置為v，它等于TCP服務器進程之前已傳送過的數(shù)據(jù)的最后一個字節(jié)的序號加1，這也與之前收到的TCP連接釋放報文段中的確認號匹配
- 確認號ack字段的值設置為u+1，這是對TCP連接釋放報文段的確認
TCP服務器進程應該通知高層應用進程，TCP客戶進程要斷開與自己的TCP連接
此時，從TCP客戶進程到TCP服務器進程這個方向的連接就釋放了
這時的TCP連接屬于半關閉狀態(tài)，也就是TCP客戶進程已經沒有數(shù)據(jù)要發(fā)送了
但如果TCP服務器進程還有數(shù)據(jù)要發(fā)送，TCP客戶進程仍要接收，也就是說從TCP服務器進程到TCP客戶進程這個方向的連接并未關閉
TCP客戶進程收到TCP確認報文段后就進入終止等待2狀態(tài)，等待TCP服務器進程發(fā)出的TCP連接釋放報文段
若使用TCP服務器進程的應用進程已經沒有數(shù)據(jù)要發(fā)送了，應用進程就通知其TCP服務器進程釋放連接
由于TCP連接釋放是由TCP客戶進程主動發(fā)起的，因此TCP服務器進程對TCP連接的釋放稱為被動關閉連接
TCP服務器進程發(fā)送TCP連接釋放報文段并進入最后確認狀態(tài)
該報文段首部中
- 終止位FIN和確認位ACK的值都被設置為1，表明這是一個TCP連接釋放報文段，同時也對之前收到的報文段進行確認
- 序號seq字段的值為w，這是因為在半關閉狀態(tài)下，TCP服務器進程可能又發(fā)送
- 確認號ack字段的值為u+1，這是對之前收到的TCP連接釋放報文段的重復確認
TCP客戶進程收到TCP連接釋放報文段后，必須針對該報文段發(fā)送普通的TCP確認報文段，之后進入時間等待狀態(tài)
該報文段首部中
- 確認為ACK的值被設置為1，表明這是一個普通的TCP確認報文段
- 序號seq字段的值設置為u+1，這是因為TCP客戶進程之前發(fā)送的TCP連接釋放報文段雖然不攜帶數(shù)據(jù)，但要消耗掉一個序號
- 確認號ack字段的值設置為w+1，這是對所收到的TCP連接釋放報文段的確認
TCP服務器進程收到該報文段后就進入關閉狀態(tài)，而TCP客戶進程還要進過2MSL后才能進入關閉狀態(tài)
TCP客戶進程在發(fā)送完最后一個確認報文后，為什么不直接進入關閉狀態(tài)？而是要進入時間等待狀態(tài)？
因為時間等待狀態(tài)以及處于該狀態(tài)2MSL時長，可以確保TCP服務器進程可以收到最后一個TCP確認報文段而進入關閉狀態(tài)
另外，TCP客戶進程在發(fā)送完最后一個TCP確認報文段后，在經過2MSL時長，就可以使本次連接持續(xù)時間內所產生的所有報文段都從網(wǎng)絡中消失，這樣就可以使下一個新的TCP連接中，不會出現(xiàn)舊連接中的報文段
TCP?；钣嫊r器的作用
TCP雙方已經建立了連接，后來，TCP客戶進程所在的主機突然出現(xiàn)了故障
TCP服務器進程以后就不能再收到TCP客戶進程發(fā)來的數(shù)據(jù)
因此，應當有措施使TCP服務器進程不要再白白等待下去
5.9、TCP報文段的首部格式
各字段的作用
源端口和目的端口
序號、確認號和確認標志位
數(shù)據(jù)偏移、保留、窗口和校驗和
同步標志位、終止標志位、復位標志位、推送標志位、緊急標志位和緊急指針
選項和填充
總結
以上是生活随笔為你收集整理的计算机网络第5章（传输层）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 计算机网络第4章（网络层）
- 下一篇： android编程常见问题- Resou