運(yùn)輸層協(xié)議概述

• 從通信和信息處理的角度看，運(yùn)輸層向它上面的應(yīng)用層提供通信服務(wù)，它屬于面向通信部分的最高層，同時(shí)也是用戶功能中的最低層。
• 當(dāng)網(wǎng)絡(luò)的邊緣部分中的兩個(gè)主機(jī)使用網(wǎng)絡(luò)的核心部分的功能進(jìn)行端到端的通信時(shí)，只有位于網(wǎng)絡(luò)邊緣部分的主機(jī)的協(xié)議棧才有運(yùn)輸層，而網(wǎng)絡(luò)核心部分中的路由器在轉(zhuǎn)發(fā)分組時(shí)都只用到下三層的功能。

應(yīng)用進(jìn)程之間的通信

在IP層看來，通信的兩端是兩個(gè)主機(jī)，IP數(shù)據(jù)報(bào)的首部明確的標(biāo)志了這兩個(gè)主機(jī)的IP地址。但是兩個(gè)主機(jī)之間的通信這種說法還不夠清楚，這是因?yàn)檎嬲M(jìn)行通信的實(shí)體是在主機(jī)中的進(jìn)程，是兩個(gè)進(jìn)程之間在交換數(shù)據(jù)。從而引出了運(yùn)輸層，從運(yùn)輸層的角度看來，通信的真正端點(diǎn)并不是主機(jī)而是主機(jī)中的進(jìn)程（端到端的通信）。

在一個(gè)主機(jī)中經(jīng)常有多個(gè)應(yīng)用進(jìn)程同時(shí)分別和另一個(gè)主機(jī)的多個(gè)應(yīng)用進(jìn)程通信。這就表明了運(yùn)輸層有一個(gè)很重要的功能，復(fù)用和分用，應(yīng)用層不同進(jìn)程的報(bào)文通過不同的端口向下交到運(yùn)輸層，再往下就共用網(wǎng)絡(luò)層提供的服務(wù)。

• 復(fù)用指的是發(fā)送方不同的應(yīng)用進(jìn)程都可以使用同一個(gè)運(yùn)輸層協(xié)議傳輸數(shù)據(jù)（當(dāng)然要加上適當(dāng)?shù)氖撞浚?/li>
• 分用指的是接收方的運(yùn)輸層在剝?nèi)?bào)文的首部后能夠把這些數(shù)據(jù)正確交付目的應(yīng)用進(jìn)程

“運(yùn)輸層提供應(yīng)用進(jìn)程間的邏輯通信”?！斑壿嬐ㄐ拧钡囊馑际牵哼\(yùn)輸層之間的通信好像是沿水平方向傳送數(shù)據(jù)。但事實(shí)上這兩個(gè)運(yùn)輸層之間并沒有一條水平方向的物理連接。

運(yùn)輸層的主要功能

• 運(yùn)輸層為應(yīng)用進(jìn)程之間提供端到端的邏輯通信（但網(wǎng)絡(luò)層是為主機(jī)之間提供邏輯通信）
• 運(yùn)輸層還要對收到的報(bào)文進(jìn)行差錯(cuò)檢測。
• 運(yùn)輸層需要有兩種不同的運(yùn)輸協(xié)議，即面向連接的 TCP 和無連接的 UDP

兩種不同的運(yùn)輸協(xié)議

• 運(yùn)輸層向高層用戶屏蔽了下面網(wǎng)絡(luò)核心的細(xì)節(jié)（如網(wǎng)絡(luò)拓?fù)?、所采用的路由選擇協(xié)議等），它使應(yīng)用進(jìn)程看見的就是好像在兩個(gè)運(yùn)輸層實(shí)體之間有一條端到端的邏輯通信信道。
• 當(dāng)運(yùn)輸層采用面向連接的 TCP 協(xié)議時(shí)，盡管下面的網(wǎng)絡(luò)是不可靠的（只提供盡最大努力服務(wù)），但這種邏輯通信信道就相當(dāng)于一條全雙工的可靠信道。
• 當(dāng)運(yùn)輸層采用無連接的 UDP 協(xié)議時(shí)，這種邏輯通信信道是一條不可靠信道。

運(yùn)輸層的兩個(gè)主要協(xié)議

TCP/IP 的運(yùn)輸層有兩個(gè)不同的協(xié)議：

• 用戶數(shù)據(jù)報(bào)協(xié)議 UDP(User Datagram Protocol)
• 傳輸控制協(xié)議 TCP(Transmission Control Protocol)

TCP與UDP

• 兩個(gè)對等運(yùn)輸實(shí)體在通信時(shí)傳送的數(shù)據(jù)單位叫作運(yùn)輸協(xié)議數(shù)據(jù)單元TPDU (Transport Protocol Data Unit)。
• TCP 傳送的數(shù)據(jù)單位協(xié)議是 TCP 報(bào)文段(segment)
• UDP 傳送的數(shù)據(jù)單位協(xié)議是 ** UDP 報(bào)文或用戶數(shù)據(jù)報(bào)**。

區(qū)別

• UDP 在傳送數(shù)據(jù)之前不需要先建立連接。對方的運(yùn)輸層在收到 UDP 報(bào)文后，不需要給出任何確認(rèn)。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 是一種最有效的工作方式。
• TCP 則提供面向連接的服務(wù)。TCP 不提供廣播或多播服務(wù)。由于 TCP 要提供可靠的、面向連接的運(yùn)輸服務(wù)，因此不可避免地增加了許多的開銷。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多，還要占用許多的處理機(jī)資源。

還要強(qiáng)調(diào)兩點(diǎn)

• 運(yùn)輸層的 UDP 用戶數(shù)據(jù)報(bào)與網(wǎng)際層的IP數(shù)據(jù)報(bào)有很大區(qū)別。IP 數(shù)據(jù)報(bào)要經(jīng)過互連網(wǎng)中許多路由器的存儲轉(zhuǎn)發(fā)，但 UDP 用戶數(shù)據(jù)報(bào)是在運(yùn)輸層的端到端抽象的邏輯信道中傳送的。
• TCP 報(bào)文段是在運(yùn)輸層抽象的端到端邏輯信道中傳送，這種信道是可靠的全雙工信道。但這樣的信道卻不知道究竟經(jīng)過了哪些路由器，而這些路由器也根本不知道上面的運(yùn)輸層是否建立了 TCP 連接。

TCP/IP體系中的運(yùn)輸層協(xié)議

TCP/IP體系中的運(yùn)輸層協(xié)議.png

運(yùn)輸層的端口

• 運(yùn)行在計(jì)算機(jī)中的進(jìn)程是用進(jìn)程標(biāo)識符來標(biāo)志的。
• 運(yùn)行在應(yīng)用層的各種應(yīng)用進(jìn)程卻不應(yīng)當(dāng)讓計(jì)算機(jī)操作系統(tǒng)指派它的進(jìn)程標(biāo)識符。這是因?yàn)樵谝蛱鼐W(wǎng)上使用的計(jì)算機(jī)的操作系統(tǒng)種類很多，而不同的操作系統(tǒng)又使用不同格式的進(jìn)程標(biāo)識符。
• 為了使運(yùn)行不同操作系統(tǒng)的計(jì)算機(jī)的應(yīng)用進(jìn)程能夠互相通信，就必須用統(tǒng)一的方法對 TCP/IP 體系的應(yīng)用進(jìn)程進(jìn)行標(biāo)志。

需要解決的問題

• 由于進(jìn)程的創(chuàng)建和撤銷都是動(dòng)態(tài)的，發(fā)送方幾乎無法識別其他機(jī)器上的進(jìn)程。
• 有時(shí)我們會(huì)改換接收報(bào)文的進(jìn)程，但并不需要通知所有發(fā)送方。
• 我們往往需要利用目的主機(jī)提供的功能來識別終點(diǎn)，而不需要知道實(shí)現(xiàn)這個(gè)功能的進(jìn)程。

端口號（protocol port number）簡稱為端口（port）

• 解決這個(gè)問題的方法就是在運(yùn)輸層使用協(xié)議端口號(protocol port number)，或通常簡稱為端口(port)。
• 雖然通信的終點(diǎn)是應(yīng)用進(jìn)程，但我們可以把端口想象是通信的終點(diǎn)，因?yàn)槲覀冎灰岩獋魉偷膱?bào)文交到目的主機(jī)的某一個(gè)合適的目的端口，剩下的工作（即最后交付目的進(jìn)程）就由 TCP 來完成。

軟件端口與硬件端口

• 在協(xié)議棧層間的抽象的協(xié)議端口是軟件端口。
• 路由器或交換機(jī)上的端口是硬件端口。
• 硬件端口是不同硬件設(shè)備進(jìn)行交互的接口，而軟件端口是應(yīng)用層的各種協(xié)議進(jìn)程與運(yùn)輸實(shí)體進(jìn)行層間交互的一種地址。

TCP的端口

• 端口用一個(gè) 16 位端口號進(jìn)行標(biāo)志（可允許有65535個(gè)不同的端口號）。
• 端口號只具有本地意義，即端口號只是為了標(biāo)志本計(jì)算機(jī)應(yīng)用層中的各進(jìn)程。在因特網(wǎng)中不同計(jì)算機(jī)的相同端口號是沒有聯(lián)系的。

由此可見兩個(gè)計(jì)算機(jī)中的進(jìn)程要相互通信，不僅要知道對方的IP地址，還要知道對方的端口號。

三類端口

• 熟知端口（系統(tǒng)端口），數(shù)值一般為 0 -1023
  例如： http = 80，ftp = 21
• 登記端口號，數(shù)值為1024 - 49151，為沒有熟知端口號的應(yīng)用程序使用的。使用這個(gè)范圍的端口號必須在 IANA 登記，以防止重復(fù)。
• 客戶端口號或短暫端口號，數(shù)值為49152 - 65535，留給客戶進(jìn)程選擇暫時(shí)使用。當(dāng)服務(wù)器進(jìn)程收到客戶進(jìn)程的報(bào)文時(shí)，就知道了客戶進(jìn)程所使用的動(dòng)態(tài)端口號。通信結(jié)束后，這個(gè)端口號可供其他客戶進(jìn)程以后使用。

用戶數(shù)據(jù)報(bào)UDP

UDP概述

• UDP 只在 IP 的數(shù)據(jù)報(bào)服務(wù)之上增加了很少一點(diǎn)的功能，即端口的功能和差錯(cuò)檢測的功能。
• 雖然 UDP 用戶數(shù)據(jù)報(bào)只能提供不可靠的交付，但 UDP 在某些方面有其特殊的優(yōu)點(diǎn)。

UDP的主要特點(diǎn)

• UDP 是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。
• UDP 使用盡最大努力交付，即不保證可靠交付，同時(shí)也不使用擁塞控制。
• UDP 是面向報(bào)文的。UDP 沒有擁塞控制，很適合多媒體通信的要求。
  無擁塞控制就說明網(wǎng)絡(luò)出現(xiàn)的擁塞不會(huì)使主機(jī)發(fā)送的速率降低。這對某些實(shí)時(shí)應(yīng)用是很重要的（IP電話，實(shí)時(shí)視頻會(huì)議等）
• UDP 支持一對一、一對多、多對一和多對多的交互通信。
• UDP 的首部開銷小，只有 8 個(gè)字節(jié)。

面向報(bào)文的UDP

• 發(fā)送方 UDP 對應(yīng)用程序交下來的報(bào)文，在添加首部后就向下交付 IP 層。UDP 對應(yīng)用層交下來的報(bào)文，既不合并，也不拆分，而是保留這些報(bào)文的邊界。
• 應(yīng)用層交給 UDP 多長的報(bào)文，UDP 就照樣發(fā)送，即一次發(fā)送一個(gè)報(bào)文。
• 接收方 UDP 對 IP 層交上來的 UDP 用戶數(shù)據(jù)報(bào)，在去除首部后就原封不動(dòng)地交付上層的應(yīng)用進(jìn)程，一次交付一個(gè)完整的報(bào)文。
• 應(yīng)用程序必須選擇合適大小的報(bào)文。

面向報(bào)文的UDP.png

UDP的首部格式

UDP的首部格式.png

• 源端口 在需要對方回信時(shí)選用，不需要時(shí)可全用0
• 目的端口
• 長度 UDP用戶數(shù)據(jù)報(bào)的長度，最小值為8（只由首部）
• 檢驗(yàn)和 檢驗(yàn)UDP用戶數(shù)據(jù)報(bào)在傳輸中是否有差錯(cuò)，有錯(cuò)就丟棄

UDP基于端口分用

UDP基于端口分用.png

UDP差錯(cuò)檢驗(yàn)

如果接收方UDP發(fā)現(xiàn)收到的報(bào)文中的目的端口號不正確（即不存在對應(yīng)于該端口的號的應(yīng)用進(jìn)程），就丟棄該報(bào)文，并由網(wǎng)際控制報(bào)文協(xié)議ICMP發(fā)送端口不可達(dá)差錯(cuò)報(bào)文給發(fā)送方。

在計(jì)算檢驗(yàn)和時(shí)，臨時(shí)把“偽首部”和 UDP 用戶數(shù)據(jù)報(bào)連接在一起得到一個(gè)臨時(shí)的數(shù)據(jù)報(bào)，它不向下傳遞也不向上遞交。偽首部僅僅是為了計(jì)算檢驗(yàn)和。

UDP計(jì)算檢驗(yàn)和的方法和IP數(shù)據(jù)報(bào)首部檢驗(yàn)和方法相類似。但不同的是，IP數(shù)據(jù)報(bào)的檢驗(yàn)和只檢驗(yàn)IP數(shù)據(jù)報(bào)的首部，但UDP的檢驗(yàn)和是把首部和數(shù)據(jù)部分一起檢驗(yàn)

計(jì)算UDP檢驗(yàn)和的例子：

UDP檢驗(yàn)和的例子.png

在發(fā)送方，先把全0放入檢驗(yàn)和字段，再把偽首部以及UDP用戶數(shù)據(jù)報(bào)看成是許多16位的字串接起來。若UDP用戶報(bào)的數(shù)據(jù)部分不是偶數(shù)個(gè)字節(jié)，則要填入一個(gè)全零字節(jié)（先不發(fā)送）。然后按照二進(jìn)制反碼計(jì)算出這些16位字的和。將此和的二進(jìn)制反碼寫入檢驗(yàn)和字段后，就發(fā)送這樣的UDP數(shù)據(jù)報(bào)。在接收方，把收到的UDP數(shù)據(jù)報(bào)連通偽首部（以及可能填充全零字節(jié)）一起，按二進(jìn)制反碼求這些16位字的和。當(dāng)無差錯(cuò)時(shí)其結(jié)果應(yīng)為全1（原本的檢驗(yàn)和為0，封裝成數(shù)據(jù)報(bào)后再次相加的時(shí)候就多個(gè)檢驗(yàn)和反碼相加，所以無差錯(cuò)時(shí)結(jié)果為1）。

傳輸控制協(xié)議TCP概述

TCP最主要的特點(diǎn)

• TCP 是面向連接的運(yùn)輸層協(xié)議
  建立與釋放連接
• 每一條 TCP 連接只能有兩個(gè)端點(diǎn)(endpoint)，每一條 TCP 連接只能是點(diǎn)對點(diǎn)的（一對一）
• TCP 提供可靠交付的服務(wù)。
  無差錯(cuò)、不重復(fù)、不丟失、并且按序到達(dá)
• TCP 提供全雙工通信
  TCP在兩端設(shè)置了發(fā)送和接收緩存
• 面向字節(jié)流
  這里的流指的是流入到進(jìn)程或從進(jìn)程流出的字節(jié)序列，面向字節(jié)流的含義是：雖然應(yīng)用程序和TCP的交互是一次一個(gè)數(shù)據(jù)塊（大小不等），但TCP把應(yīng)用程序交下來的數(shù)據(jù)看成僅僅是一連串的無結(jié)構(gòu)的字節(jié)流。TCP并不知道所傳輸?shù)淖止?jié)流的含義。TCP并不保證接收方應(yīng)用程序所收到的數(shù)據(jù)塊和發(fā)送方應(yīng)用程序所發(fā)出的數(shù)據(jù)塊具有對應(yīng)的大小關(guān)系（發(fā)送發(fā)交給發(fā)送方TCP10個(gè)數(shù)據(jù)塊，但接收方的TPC用了4個(gè)數(shù)據(jù)塊就把收到的字節(jié)流交付上層的應(yīng)用程序）。但接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)送的字節(jié)流完全一樣。

TCP面向流的概念

TCP面向流的概念.png

應(yīng)當(dāng)注意

• TCP 連接是一條虛連接而不是一條真正的物理連接。
• TCP 對應(yīng)用進(jìn)程一次把多長的報(bào)文發(fā)送到TCP 的緩存中是不關(guān)心的。
• TCP 根據(jù)對方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來決定一個(gè)報(bào)文段應(yīng)包含多少個(gè)字節(jié)（UDP 發(fā)送的報(bào)文長度是應(yīng)用進(jìn)程給出的）。
• TCP 可把太長的數(shù)據(jù)塊劃分短一些再傳送。TCP 也可等待積累有足夠多的字節(jié)后再構(gòu)成報(bào)文段發(fā)送出去。

TCP的連接

• TCP 把連接作為最基本的抽象
• 每一條 TCP 連接有兩個(gè)端點(diǎn)
• TCP 連接的端點(diǎn)不是主機(jī)，不是主機(jī)的IP 地址，不是應(yīng)用進(jìn)程，也不是運(yùn)輸層的協(xié)議端口。TCP 連接的端點(diǎn)叫做套接字(socket)或插口
• 端口號拼接到(contatenated with) IP 地址即構(gòu)成了套接字

套接字（socket）

套接字.png

每一條TCP連接唯一地被通信兩端的兩個(gè)端點(diǎn)（即兩個(gè)套接字）所確定，即：

TCP連接.png

同一個(gè)名詞socket有多種不同的意思

• 應(yīng)用編程接口 API 稱為 socket API, 簡稱為 socket。
• socket API 中使用的一個(gè)函數(shù)名也叫作 socket。
• 調(diào)用 socket 函數(shù)的端點(diǎn)稱為 socket。
• 調(diào)用 socket 函數(shù)時(shí)其返回值稱為 socket 描述符，可簡稱為 socket。
• 在操作系統(tǒng)內(nèi)核中連網(wǎng)協(xié)議的 Berkeley 實(shí)現(xiàn)，稱為 socket 實(shí)現(xiàn)。

可靠傳輸?shù)墓ぷ髟?/h1>

TCP發(fā)送的報(bào)文段是交給IP層傳輸?shù)摹５獻(xiàn)P層只提供盡最大努力服務(wù)，也就是說，TCP下面的網(wǎng)絡(luò)所提供的是不可靠傳輸，因此，TCP必須采用適當(dāng)?shù)拇胧┎拍苁沟脙蓚€(gè)運(yùn)輸層之間的通信變得可靠。

可靠傳輸有以下兩個(gè)特點(diǎn)

• 傳輸信道不產(chǎn)生差錯(cuò)
• 不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù)，接收方總是來得及處理收到的數(shù)據(jù)

在這樣的理想傳輸條件下，不需要采取任何措施就能夠?qū)崿F(xiàn)可靠傳輸。然而實(shí)際的網(wǎng)絡(luò)都不具備以上兩個(gè)理想的條件。但我們可以使用一些可靠傳輸協(xié)議，當(dāng)出現(xiàn)差錯(cuò)時(shí)讓發(fā)送方重傳出現(xiàn)差錯(cuò)的數(shù)據(jù)，同時(shí)在接收方來不及處理收到的數(shù)據(jù)時(shí)，及時(shí)告訴發(fā)送方適當(dāng)?shù)慕档桶l(fā)送數(shù)據(jù)的速度，這樣一來，本來是不可靠的傳輸信道就能夠?qū)崿F(xiàn)可靠傳輸。

停止等待協(xié)議

停止等待協(xié)議.png

• 在發(fā)送完一個(gè)分組后，必須暫時(shí)保留已發(fā)送的分組的副本
  為發(fā)生超時(shí)重傳而使用，只有收到相應(yīng)的確認(rèn)報(bào)文時(shí)才能清除暫時(shí)保存的副本
• 分組和確認(rèn)分組都必須進(jìn)行編號
  這樣才能明確是哪一個(gè)發(fā)送出去的分組收到了確認(rèn)，而哪一個(gè)分組還沒收到確認(rèn)
• 超時(shí)計(jì)時(shí)器的重傳時(shí)間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r(shí)間更長一些

確認(rèn)丟失和確認(rèn)遲到

確認(rèn)丟失和確認(rèn)遲到.png

可靠通信的實(shí)現(xiàn)

• 使用上述的確認(rèn)和重傳機(jī)制，我們就可以在不可靠的傳輸網(wǎng)絡(luò)上實(shí)現(xiàn)可靠的通信
• 這種可靠傳輸協(xié)議常稱為自動(dòng)重傳請求ARQ (Automatic Repeat reQuest)
• ARQ 表明重傳的請求是自動(dòng)進(jìn)行的。接收方不需要請求發(fā)送方重傳某個(gè)出錯(cuò)的分組

信道利用率

停止等待協(xié)議的優(yōu)點(diǎn)是簡單，但缺點(diǎn)是信道利用率太低。

假定AB之間有一條直通的信道來傳送分組

信道利用率.png

這里的TD是A發(fā)送分組所需要的時(shí)間（顯然TD = 分組長度 / 數(shù)據(jù)速率）再假定TA是B發(fā)送確認(rèn)分組所需要的時(shí)間（A和B處理分組的時(shí)間都忽略不計(jì)）那么A在經(jīng)過TD+RTT+TA時(shí)間后才能發(fā)送下一個(gè)分組，這里的RTT是往返時(shí)間，因?yàn)橹挥蠺D是采用來傳輸有用的數(shù)據(jù)（這個(gè)數(shù)據(jù)包括了分組首部，如果可以知道傳輸更精確的數(shù)據(jù)的時(shí)間，可以計(jì)算的更精確），所有信道利用率為

信道利用率公式.png

為了提高傳輸效率，發(fā)送方可以不使用低效率的停止等待協(xié)議，而是采用流水線傳輸：就是發(fā)送方可以連續(xù)的發(fā)送多個(gè)分組，不必每發(fā)完一個(gè)分組就停下來等待對方的確認(rèn)。這樣可使信道上一直有數(shù)據(jù)不間斷地在傳送。顯然這種傳輸方式可以獲得很高的信道利用率

流水線傳輸.png

當(dāng)時(shí)使用流水線傳輸時(shí)，就要使用下面介紹的連續(xù)ARQ協(xié)議和滑動(dòng)窗口協(xié)議

連續(xù)ARQ協(xié)議

滑動(dòng)窗口協(xié)議比較復(fù)雜，是TCP協(xié)議的精髓所在，在這里先給出ARQ協(xié)議最基本的概念，但不涉及到許多細(xì)節(jié)問題。

連續(xù)ARQ協(xié)議.png

位于發(fā)送窗口的分組都可以連續(xù)的發(fā)送出去，而不需要等待對方的確認(rèn)，發(fā)送方每收到一個(gè)確認(rèn)，就把發(fā)送窗口向前滑動(dòng)一個(gè)分組的位置。

詳細(xì)可以見P201

累計(jì)確認(rèn)

• 接收方一般采用累積確認(rèn)的方式。即不必對收到的分組逐個(gè)發(fā)送確認(rèn)，而是對按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)，這樣就表示：到這個(gè)分組為止的所有分組都已正確收到了。
• 累積確認(rèn)有的優(yōu)點(diǎn)是：容易實(shí)現(xiàn)，即使確認(rèn)丟失也不必重傳。缺點(diǎn)是：不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。

Go - back - N（回退N）

• 如果發(fā)送方發(fā)送了前 5 個(gè)分組，而中間的第 3 個(gè)分組丟失了。這時(shí)接收方只能對前兩個(gè)分組發(fā)出確認(rèn)。發(fā)送方無法知道后面三個(gè)分組的下落，而只好把后面的三個(gè)分組都再重傳一次。
• 這就叫做 Go-back-N（回退 N），表示需要再退回來重傳已發(fā)送過的 N 個(gè)分組。
• 可見當(dāng)通信線路質(zhì)量不好時(shí)，連續(xù) ARQ 協(xié)議會(huì)帶來負(fù)面的影響。

TCP可靠通信的具體實(shí)現(xiàn)

• TCP 連接的每一端都必須設(shè)有兩個(gè)窗口——一個(gè)發(fā)送窗口和一個(gè)接收窗口。
• TCP 的可靠傳輸機(jī)制用字節(jié)的序號進(jìn)行控制。TCP 所有的確認(rèn)都是基于序號而不是基于報(bào)文段。
• TCP 兩端的四個(gè)窗口經(jīng)常處于動(dòng)態(tài)變化之中。
  TCP連接的往返時(shí)間 RTT 也不是固定不變的。需要使用特定的算法估算較為合理的重傳時(shí)間。

TCP報(bào)文段的首部格式

TCP雖然是面向字節(jié)流的，但是TCP傳送的數(shù)據(jù)單元卻是報(bào)文段（可以看上述TCP面向流的概念），而且TCP的全部功能都體現(xiàn)在它的首部中各個(gè)字段。

TCP報(bào)文段的首部格式.png

• 源端口和目的端口字段——各占 2 字節(jié)。端口是運(yùn)輸層與應(yīng)用層的服務(wù)接口。運(yùn)輸層的復(fù)用和分用功能都要通過端口才能實(shí)現(xiàn)。
• 序號字段——占 4 字節(jié)。TCP 連接中傳送的數(shù)據(jù)流中的每一個(gè)字節(jié)都編上一個(gè)序號。序號字段的值則指的是本報(bào)文段所發(fā)送的數(shù)據(jù)的第一個(gè)字節(jié)的序號。（如果不理解，可以看P202）
• 確認(rèn)號字段——占 4 字節(jié)，是期望收到對方的下一個(gè)報(bào)文段的數(shù)據(jù)的第一個(gè)字節(jié)的序號。例如，B正確收到了A發(fā)送過來的一個(gè)報(bào)文段，其序號字段值是501，而數(shù)據(jù)長度是200字節(jié)（序號501 - 700），這表明B正確收到了A發(fā)送的到序號700為止的數(shù)據(jù)，因此，B期望收到A的下一個(gè)數(shù)據(jù)序號為701，于是B在發(fā)送給A的確認(rèn)報(bào)文段中把確認(rèn)號置位701。總之，若確認(rèn)號為N，則表明到N-1為止的所有數(shù)據(jù)都已正確收到。
• 數(shù)據(jù)偏移（即首部長度）——占 4 位，它指出 TCP 報(bào)文段的數(shù)據(jù)起始處距離 TCP 報(bào)文段的起始處有多遠(yuǎn)?！皵?shù)據(jù)偏移”的單位是 32 位字（以 4 字節(jié)為計(jì)算單位）。
• 保留字段——占 6 位，保留為今后使用，但目前應(yīng)置為 0
• 緊急 URG —— 當(dāng) URG = 1 時(shí)，表明緊急指針字段有效。它告訴系統(tǒng)此報(bào)文段中有緊急數(shù)據(jù)，應(yīng)盡快傳送(相當(dāng)于高優(yōu)先級的數(shù)據(jù))
• 確認(rèn) ACK —— 只有當(dāng) ACK = 1 時(shí)確認(rèn)號字段才有效。當(dāng) ACK = 0 時(shí)，確認(rèn)號無效。TCP規(guī)定，在建立連接后所有傳送的報(bào)文段都必須把ACK置1
• 推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的報(bào)文段，就盡快地交付接收應(yīng)用進(jìn)程，而不再等到整個(gè)緩存都填滿了后再向上交付。
• 復(fù)位 RST (ReSeT) —— 當(dāng) RST = 1 時(shí)，表明 TCP 連接中出現(xiàn)嚴(yán)重差錯(cuò)（如由于主機(jī)崩潰或其他原因），必須釋放連接，然后再重新建立運(yùn)輸連接。
• 同步 SYN —— 在連接建立時(shí)用來同步序號，當(dāng)SYN = 1而ACK = 0時(shí)，表明這是一個(gè)連接請求報(bào)文。對方若同意建立連接，則應(yīng)在響應(yīng)的報(bào)文段中使SYN = 1和ACK = 1。所以，SYN = 1 表示這是一個(gè)連接請求或連接接受報(bào)文。
• 終止 FIN (FINis) —— 用來釋放一個(gè)連接。FIN = 1 表明此報(bào)文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運(yùn)輸連接。
• 窗口字段 —— 占 2 字節(jié)，窗口值是[0,2^16 -1]之間的整數(shù)。窗口指的是發(fā)送本報(bào)文段的一方的接收窗口（而不是自己的發(fā)送窗口）。窗口值告訴對方：從本報(bào)文段首部中的確認(rèn)號算起，接收方目前允許對方發(fā)送的數(shù)據(jù)量。之所以要有這個(gè)限制，是因?yàn)榻邮辗降臄?shù)據(jù)緩存空間是有限的?？傊?strong>窗口值作為接收方讓發(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。例如。設(shè)確認(rèn)號是701，窗口字段是1000.這就表明，從701號算起，發(fā)送此報(bào)文段的一方還有接收1000個(gè)字節(jié)數(shù)據(jù)（字節(jié)序號701-1700）的接收緩存空間。總之，窗口字段指出了現(xiàn)在允許對方發(fā)送的數(shù)據(jù)量。窗口值是經(jīng)常在動(dòng)態(tài)變化著
• 檢驗(yàn)和 —— 占 2 字節(jié)。檢驗(yàn)和字段檢驗(yàn)的范圍包括首部和數(shù)據(jù)這兩部分。與UDP一樣在計(jì)算檢驗(yàn)和時(shí)，要在 TCP 報(bào)文段的前面加上 12 字節(jié)的偽首部。不同點(diǎn)可以見P204
• 緊急指針字段 —— 占 16 位，僅在URG = 1時(shí)才有意義，它指出在本報(bào)文段中緊急數(shù)據(jù)共有多少個(gè)字節(jié)（緊急數(shù)據(jù)放在本報(bào)文段數(shù)據(jù)的最前面，因此緊急指針指出了緊急數(shù)據(jù)的末尾在報(bào)文段中的位置）。
• 選項(xiàng)字段 —— 長度可變。TCP 最初只規(guī)定了一種選項(xiàng)，即最大報(bào)文段長度 MSS。MSS 告訴對方 TCP：“我的緩存所能接收的報(bào)文段的數(shù)據(jù)字段的最大長度是 MSS 個(gè)字節(jié)?！?MSS (Maximum Segment Size)是 TCP 報(bào)文段中的數(shù)據(jù)字段的最大長度。數(shù)據(jù)字段加上 TCP 首部才等于整個(gè)的 TCP 報(bào)文段。
• 其他選項(xiàng)
  • 窗口擴(kuò)大選項(xiàng) ——占 3 字節(jié)，其中有一個(gè)字節(jié)表示移位值 S。新的窗口值等于TCP 首部中的窗口位數(shù)增大到(16 + S)，相當(dāng)于把窗口值向左移動(dòng) S 位后獲得實(shí)際的窗口大小。
  • 時(shí)間戳選項(xiàng)——占10 字節(jié)，其中最主要的字段時(shí)間戳值字段（4 字節(jié)）和時(shí)間戳回送回答字段（4 字節(jié)）。
  • 選擇確認(rèn)選項(xiàng)
    選項(xiàng)詳解請見P205
• 填充字段 —— 這是為了使整個(gè)首部長度是** 4 字節(jié)**的整數(shù)倍。

TCP可靠傳輸?shù)膶?shí)現(xiàn)

以字節(jié)為單位的滑動(dòng)窗口

詳解請見P206，注意圖中的后沿，前沿

以字節(jié)為單位的滑動(dòng)窗口01.png

從下圖可以看出來，要描述一個(gè)發(fā)送窗口的狀態(tài)需要三個(gè)指針：P1，P2，P3

以字節(jié)為單位的滑動(dòng)窗口02.png

以字節(jié)為單位的滑動(dòng)窗口03.png

以字節(jié)為單位的滑動(dòng)窗口04.png

有很多信息見P208，這里不贅述

發(fā)送/接收緩存

發(fā)送方的應(yīng)用進(jìn)程把字節(jié)流寫入TCP的發(fā)送緩存，接收方的應(yīng)用進(jìn)程從TCP的接收緩存中讀取字節(jié)流。下面進(jìn)一步討論前面講的窗口和緩存的關(guān)系

發(fā)送緩存

發(fā)送緩存.png

接收緩存.png

發(fā)送與接收緩存的作用

• 發(fā)送緩存用來暫時(shí)存放：
  • 發(fā)送應(yīng)用程序傳送給發(fā)送方 TCP 準(zhǔn)備發(fā)送的數(shù)據(jù)；
  • TCP 已發(fā)送出但尚未收到確認(rèn)的數(shù)據(jù)。

發(fā)送窗口通常只是發(fā)送緩存的一部分，已被確認(rèn)的數(shù)據(jù)應(yīng)當(dāng)從發(fā)送緩存中刪除，因此發(fā)送緩存和發(fā)送窗口的后沿是重合的。發(fā)送應(yīng)用程序最后寫入發(fā)送緩存的字節(jié)減去最后被確認(rèn)的字節(jié)，就是還保留在發(fā)送緩存中被寫入的字節(jié)。發(fā)送應(yīng)用程序必須控制寫入緩存的速率，不能太快 ，否則發(fā)送緩存就會(huì)沒有存放數(shù)據(jù)的空間。

• 接收緩存用來暫時(shí)存放：
  • 按序到達(dá)的、但尚未被接收應(yīng)用程序讀取的數(shù)據(jù)；
  • 不按序到達(dá)的數(shù)據(jù)。

如果收到的分組被檢測出有差錯(cuò)，則要丟棄。如果接收應(yīng)用程序來不及讀取收到的數(shù)據(jù)，接收緩存最終就會(huì)被填滿，使接收窗口減少到零。反之，如果接收應(yīng)用程序能夠及時(shí)從接收緩存中讀取收到的數(shù)據(jù)，接收窗口就可以增大，但最大不能超過接收緩存的大小。

需要強(qiáng)調(diào)三點(diǎn)

• A 的發(fā)送窗口并不總是和 B 的接收窗口一樣大（因?yàn)橛幸欢ǖ臅r(shí)間滯后）。
• TCP 標(biāo)準(zhǔn)沒有規(guī)定對不按序到達(dá)的數(shù)據(jù)應(yīng)如何處理。通常是先臨時(shí)存放在接收窗口中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應(yīng)用進(jìn)程。
• TCP 要求接收方必須有累積確認(rèn)的功能，這樣可以減小傳輸開銷。

超時(shí)重傳時(shí)間的選擇

• 重傳機(jī)制是 TCP 中最重要和最復(fù)雜的問題之一。
• TCP 每發(fā)送一個(gè)報(bào)文段，就對這個(gè)報(bào)文段設(shè)置一次計(jì)時(shí)器。只要計(jì)時(shí)器設(shè)置的重傳時(shí)間到但還沒有收到確認(rèn)，就要重傳這一報(bào)文段。

往返時(shí)延的方差很大

• 由于 TCP 的下層是一個(gè)互聯(lián)網(wǎng)環(huán)境，IP 數(shù)據(jù)報(bào)所選擇的路由變化很大。因而運(yùn)輸層的往返時(shí)間的方差也很大。

往返時(shí)延的方差很大.png

加權(quán)平均往返時(shí)間RTT

TCP才用了一種自適應(yīng)算法，它記錄一個(gè)報(bào)文段發(fā)出的時(shí)間，以及收到相應(yīng)的確認(rèn)的時(shí)間。這兩個(gè)時(shí)間之差就是報(bào)文段的往返時(shí)間RTT。

TCP 保留了 RTT 的一個(gè)加權(quán)平均往返時(shí)間 RTTs（這又稱為平滑（smooth）的往返時(shí)間，因?yàn)槭羌訖?quán)平均，所以是平滑的）。
第一次測量到 RTT 樣本時(shí)，RTTS 值就取為所測量到的 RTT 樣本值。以后每測量到一個(gè)新的 RTT 樣本，就按下式重新計(jì)算一次 RTTS：

加權(quán)平均公式.png

超時(shí)重傳時(shí)間RTO

顯然，RTO 應(yīng)略大于上面得出的加權(quán)平均往返時(shí)間 RTTs
RFC 2988 建議使用下式計(jì)算 RTO：

RTO.png

RTTD 是 RTT 的偏差的加權(quán)平均值，他與RTTs和新的RTT樣本之差有關(guān)。
RFC 2988 建議這樣計(jì)算 RTTD。第一次測量時(shí)，RTTD 值取為測量到的 RTT 樣本值的一半。在以后的測量中，則使用下式計(jì)算加權(quán)平均的 RTTD：

RTTD .png

β是個(gè)小于 1 的系數(shù)，其推薦值是 1/4，即 0.25。

往返時(shí)間的測量相當(dāng)復(fù)雜

• TCP 報(bào)文段 1 沒有收到確認(rèn)。重傳（即報(bào)文段 2）后，收到了確認(rèn)報(bào)文段 ACK。
• 如何判定此確認(rèn)報(bào)文段是對原來的報(bào)文段 1 的確認(rèn)，還是對重傳的報(bào)文段 2 的確認(rèn)？

往返時(shí)間的測量相當(dāng)復(fù)雜.png

Karn算法

為了解決上面那個(gè)問題，Karn提出了一個(gè)算法

在計(jì)算平均往返時(shí)間 RTT 時(shí)，只要**報(bào)文段重傳了，就不采用其往返時(shí)間樣本。這樣得出的加權(quán)平均平均往返時(shí)間 RTTS 和超時(shí)重傳時(shí)間 RTO 就較準(zhǔn)確。 **

但是，這又有了新的問題、設(shè)想出現(xiàn)這樣的情況：報(bào)文段的時(shí)延突然增大了很多。因此在原來得出的重傳時(shí)間內(nèi)，不會(huì)收到確認(rèn)報(bào)文段。于是就重傳報(bào)文段。但根據(jù)Karn算法，不考慮重傳的報(bào)文段的往返時(shí)間樣本。這樣，超時(shí)重傳時(shí)間就無法更新。

修正的Karn算法

報(bào)文段每重傳一次，就把 RTO 增大一些：

修正的Karn算法.png

系數(shù) γ 的典型值是 2 。
當(dāng)不再發(fā)生報(bào)文段的重傳時(shí)，才根據(jù)報(bào)文段的往返時(shí)延更新平均往返時(shí)延 RTT 和超時(shí)重傳時(shí)間 RTO 的數(shù)值。
實(shí)踐證明，這種策略較為合理。

選擇確認(rèn)SACK（selective ACK）

接收方收到了和前面的字節(jié)流不連續(xù)*的兩個(gè)字節(jié)塊（只是未按序號，它是無差錯(cuò)的）

如果這些字節(jié)的序號都在接收窗口之內(nèi)，那么接收方就先收下這些數(shù)據(jù)，但要把這些信息準(zhǔn)確地告訴發(fā)送方，使發(fā)送方不要再重復(fù)發(fā)送這些已收到的數(shù)據(jù)。

接收到不連續(xù)的字節(jié)流.png

和前后字節(jié)不連續(xù)的每一個(gè)字節(jié)塊都有兩個(gè)邊界：左邊界和右邊界。圖中用四個(gè)指針標(biāo)記這些邊界。第一個(gè)字節(jié)塊的左邊界 L1 = 1501，但右邊界 R1 = 3001。左邊界指出字節(jié)塊的第一個(gè)字節(jié)的序號，但右邊界減 1 才是字節(jié)塊中的最后一個(gè)序號。第二個(gè)字節(jié)塊的左邊界 L2 = 3501，而右邊界 R2 = 4501。

RFC 2018的規(guī)定

• TCP首部并沒有哪個(gè)字段能提供上述這些字節(jié)塊的邊界信息。如果要使用選擇確認(rèn)，那么在建立 TCP 連接時(shí)，就要在 TCP 首部的選項(xiàng)中加上“允許 SACK”的選項(xiàng)，而雙方必須都事先商定好。
• 如果使用選擇確認(rèn)，那么原來首部中的“確認(rèn)號字段”的用法仍然不變。只是以后在 TCP 報(bào)文段的首部中都增加了 SACK 選項(xiàng)，以便報(bào)告收到的不連續(xù)的字節(jié)塊的邊界。
• 由于首部選項(xiàng)的長度最多只有 40 字節(jié)，而指明一個(gè)邊界就要用掉 4 字節(jié)，因此在選項(xiàng)中最多只能指明 4 個(gè)字節(jié)塊的邊界信息。

詳見P211

TCP流量控制

利用滑動(dòng)窗口實(shí)現(xiàn)流量控制

一般說來，我們總是希望數(shù)據(jù)傳輸?shù)酶煲恍?。但如果發(fā)送方把數(shù)據(jù)發(fā)送得過快，
接收方就可能來不及接收，這就會(huì)造成數(shù)據(jù)的丟失。

流量控制(flow control)就是讓發(fā)送方的發(fā)送速率不要太快，既要讓接收方來得及接收，也不要使網(wǎng)絡(luò)發(fā)生擁塞。

利用滑動(dòng)窗口機(jī)制可以很方便地在 TCP 連接上實(shí)現(xiàn)流量控制。

流量控制舉例

A 向 B 發(fā)送數(shù)據(jù)。在連接建立時(shí)，?B 告訴 A：“我的接收窗口 rwnd = 400（字節(jié)）”。看下TCP首部窗口字段的用處

流量控制舉例.png

接收方的主機(jī)B一共進(jìn)行了3次流量控制（藍(lán)線）

考慮一種情況，B向A發(fā)送了零窗口的報(bào)文段后不久，B的接收緩存又有了一些存儲空間。于是B向A發(fā)送了rwnd = 400的報(bào)文段，然而這個(gè)報(bào)文段在傳輸過程中丟失了。A一直等收到B發(fā)送非零窗口的通知，B也一直等A發(fā)送數(shù)據(jù)來，就形成了死鎖。下面的持續(xù)計(jì)時(shí)器就是為了打破死鎖僵局的

持續(xù)計(jì)時(shí)器（persistence timer）

• TCP 為每一個(gè)連接設(shè)有一個(gè)持續(xù)計(jì)時(shí)器
• 只要 TCP 連接的一方收到對方的零窗口通知，就啟動(dòng)持續(xù)計(jì)時(shí)器。
• 若持續(xù)計(jì)時(shí)器設(shè)置的時(shí)間到期，就發(fā)送一個(gè)零窗口探測報(bào)文段（僅攜帶 1 字節(jié)的數(shù)據(jù)），而對方就在確認(rèn)這個(gè)探測報(bào)文段時(shí)給出了現(xiàn)在的窗口值。
• 若窗口仍然是零，則收到這個(gè)報(bào)文段的一方就重新設(shè)置持續(xù)計(jì)時(shí)器。
• 若窗口不是零，則死鎖的僵局就可以打破了。

必須考慮傳輸效率

應(yīng)用進(jìn)程把數(shù)據(jù)傳送到TCP發(fā)送緩存后，剩下的發(fā)送任務(wù)就由TCP來控制了?？梢杂貌煌臋C(jī)制來控制 TCP 報(bào)文段的發(fā)送時(shí)機(jī):

• 第一種機(jī)制是 TCP 維持一個(gè)變量，它等于最大報(bào)文段長度 MSS。只要緩存中存放的數(shù)據(jù)達(dá)到 MSS 字節(jié)時(shí)，就組裝成一個(gè) TCP 報(bào)文段發(fā)送出去。
• 第二種機(jī)制是由發(fā)送方的應(yīng)用進(jìn)程指明要求發(fā)送報(bào)文段，即 TCP 支持的推送(push)操作。
• 第三種機(jī)制是發(fā)送方的一個(gè)計(jì)時(shí)器期限到了，這時(shí)就把當(dāng)前已有的緩存數(shù)據(jù)裝入報(bào)文段（但長度不能超過 MSS）發(fā)送出去。

至于如何控制發(fā)送的 時(shí)機(jī) 詳見P213

TCP的擁塞控制

擁塞控制的一般原理

在某段時(shí)間，若對網(wǎng)絡(luò)中某資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡(luò)的性能就要變壞——產(chǎn)生擁塞(congestion)

出現(xiàn)資源擁塞的條件： 對資源需求的總和 > 可用資源

若網(wǎng)絡(luò)中有許多資源同時(shí)產(chǎn)生擁塞，網(wǎng)絡(luò)的性能就要明顯變壞，整個(gè)網(wǎng)絡(luò)的吞吐量將隨輸入負(fù)荷的增大而下降。

解決擁塞的要點(diǎn)是平衡，要讓整個(gè)系統(tǒng)的性能想匹配（P214）。

擁塞控制與流量控制關(guān)系密切

• 擁塞控制所要做的都有一個(gè)前提，就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負(fù)荷。
• 擁塞控制是一個(gè)全局性的過程，涉及到所有的主機(jī)、所有的路由器，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。
• 流量控制往往指在給定的發(fā)送端和接收端之間的點(diǎn)對點(diǎn)通信量的控制。
• 流量控制所要做的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。

擁塞控制所起的作用

橫坐標(biāo)為提供的負(fù)載，代表單位時(shí)間內(nèi)輸入給網(wǎng)絡(luò)的分組的數(shù)目（也叫作輸入負(fù)載或網(wǎng)絡(luò)負(fù)載），縱坐標(biāo)是吞吐量，代表單位時(shí)間內(nèi)從網(wǎng)絡(luò)輸出的分組數(shù)目。

擁塞控制所起的作用.png

擁塞控制的一般原理

• 擁塞控制是很難設(shè)計(jì)的，因?yàn)樗且粋€(gè)動(dòng)態(tài)的（而不是靜態(tài)的）問題。
• 當(dāng)前網(wǎng)絡(luò)正朝著高速化的方向發(fā)展，這很容易出現(xiàn)緩存不夠大而造成分組的丟失。但分組的丟失是網(wǎng)絡(luò)發(fā)生擁塞的征兆而不是原因。
• 在許多情況下，甚至正是擁塞控制本身成為引起網(wǎng)絡(luò)性能惡化甚至發(fā)生死鎖的原因。這點(diǎn)應(yīng)特別引起重視。

開環(huán)和閉環(huán)控制

• 開環(huán)控制方法就是在設(shè)計(jì)網(wǎng)絡(luò)時(shí)事先將有關(guān)發(fā)生擁塞的因素考慮周到，力求網(wǎng)絡(luò)在工作時(shí)不產(chǎn)生擁塞，但是系統(tǒng)運(yùn)行起來就不再中途更正了。
• 閉環(huán)控制是基于反饋環(huán)路的概念。屬于閉環(huán)控制的有以下幾種措施：
  • 監(jiān)測網(wǎng)絡(luò)系統(tǒng)以便檢測到擁塞在何時(shí)、何處發(fā)生。
  • 將擁塞發(fā)生的信息傳送到可采取行動(dòng)的地方。
  • 調(diào)整網(wǎng)絡(luò)系統(tǒng)的運(yùn)行以解決出現(xiàn)的問題。

檢測擁塞的指標(biāo)

由于缺少緩存空間而被丟棄的分組的百分?jǐn)?shù)，平均隊(duì)列長度，超時(shí)重傳的分組數(shù)，平均分組時(shí)延，分組時(shí)延的標(biāo)準(zhǔn)差等，這些指標(biāo)的上升都標(biāo)志著擁塞的增長。

幾種擁塞控制方法

慢開始和擁塞避免

• 發(fā)送方維持一個(gè)叫做擁塞窗口 cwnd (congestion window)的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動(dòng)態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口。如再考慮到接收方的接收能力，則發(fā)送窗口還可能小于擁塞窗口。
• 發(fā)送方控制擁塞窗口的原則是：只要網(wǎng)絡(luò)沒有出現(xiàn)擁塞，擁塞窗口就再增大一些，以便把更多的分組發(fā)送出去。但只要網(wǎng)絡(luò)出現(xiàn)擁塞，擁塞窗口就減小一些，以減少注入到網(wǎng)絡(luò)中的分組數(shù)。

慢開始算法的原理

方便起見，我們用報(bào)文段的個(gè)數(shù)作為窗口大小的單位

• 在主機(jī)剛剛開始發(fā)送報(bào)文段時(shí)可先設(shè)置擁塞窗口 cwnd = 1，即設(shè)置為一個(gè)最大報(bào)文段 MSS 的數(shù)值。
• 在每收到一個(gè)對新的報(bào)文段的確認(rèn)后，將擁塞窗口加 1，即增加一個(gè) MSS 的數(shù)值。
• 用這樣的方法逐步增大發(fā)送端的擁塞窗口 cwnd，可以使分組注入到網(wǎng)絡(luò)的速率更加合理。

傳播輪次（transmission round）

• 使用慢開始算法后，每經(jīng)過一個(gè)傳輸輪次，擁塞窗口 cwnd 就加倍。
• 一個(gè)傳輸輪次所經(jīng)歷的時(shí)間其實(shí)就是往返時(shí)間 RTT。
• “傳輸輪次”更加強(qiáng)調(diào)：把擁塞窗口 cwnd 所允許發(fā)送的報(bào)文段都連續(xù)發(fā)送出去，并收到了對已發(fā)送的最后一個(gè)字節(jié)的確認(rèn)。
• 例如，擁塞窗口 cwnd = 4，這時(shí)的往返時(shí)間 RTT 就是發(fā)送方連續(xù)發(fā)送 4 個(gè)報(bào)文段，并收到這 4 個(gè)報(bào)文段的確認(rèn)，總共經(jīng)歷的時(shí)間。

慢開始算法.png

設(shè)置慢開始門限狀態(tài)變量 ssthresh

慢開始門限 ssthresh 的用法如下：

• 當(dāng) cwnd < ssthresh 時(shí)，使用慢開始算法。
• 當(dāng) cwnd > ssthresh 時(shí)，停止使用慢開始算法而改用擁塞避免算法。
• 當(dāng) cwnd = ssthresh 時(shí)，既可使用慢開始算法，也可使用擁塞避免算法。

擁塞避免算法的思路是讓擁塞窗口 cwnd 緩慢地增大，即每經(jīng)過一個(gè)往返時(shí)間 RTT 就把發(fā)送方的擁塞窗口 cwnd 加 1，而不是加倍，使擁塞窗口 cwnd 按線性規(guī)律緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢很多。

網(wǎng)絡(luò)出現(xiàn)擁塞時(shí)

• 無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞（其根據(jù)就是沒有按時(shí)收到確認(rèn)），就要把慢開始門限 ssthresh 設(shè)置為出現(xiàn)擁塞時(shí)的發(fā)送方窗口值的一半（但不能小于2）。
• 然后把擁塞窗口 cwnd 重新設(shè)置為 1，執(zhí)行慢開始算法。
• 這樣做的目的就是要迅速減少主機(jī)發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時(shí)間把隊(duì)列中積壓的分組處理完畢。

慢開始和擁塞避免算法的實(shí)現(xiàn)舉例

當(dāng) TCP 連接進(jìn)行初始化時(shí)，將擁塞窗口置為 1。圖中的窗口單位不使用字節(jié)而使用報(bào)文段。

慢開始門限的初始值設(shè)置為 16 個(gè)報(bào)文段，即 ssthresh = 16。

發(fā)送端的發(fā)送窗口不能超過擁塞窗口 cwnd 和接收端窗口 rwnd 中的最小值。我們假定接收端窗口足夠大，因此現(xiàn)在發(fā)送窗口的數(shù)值等于擁塞窗口的數(shù)值。

慢開始和擁塞避免算法的實(shí)現(xiàn)舉例.png

下面的執(zhí)行步驟就是按照折現(xiàn)上的點(diǎn)的順序

1. 在執(zhí)行慢開始算法時(shí)，擁塞窗口 cwnd 的初始值為 1，發(fā)送第一個(gè)報(bào)文段 M0。
2. 發(fā)送端每收到一個(gè)確認(rèn) ，就把 cwnd 加 1。于是發(fā)送端可以接著發(fā)送 M1 和 M2 兩個(gè)報(bào)文段。
3. 接收端共發(fā)回兩個(gè)確認(rèn)。發(fā)送端每收到一個(gè)對新報(bào)文段的確認(rèn)，就把發(fā)送端的 cwnd 加 1?，F(xiàn)在 cwnd 從 2 增大到 4，并可接著發(fā)送后面的 4 個(gè)報(bào)文段。
4. 發(fā)送端每收到一個(gè)對新報(bào)文段的確認(rèn)，就把發(fā)送端的擁塞窗口加 1，因此擁塞窗口 cwnd 隨著傳輸輪次按指數(shù)規(guī)律增長。
5. 當(dāng)擁塞窗口 cwnd 增長到慢開始門限值 ssthresh 時(shí)（即當(dāng) cwnd = 16 時(shí)），就改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長。
6. 假定擁塞窗口的數(shù)值增長到 24 時(shí)，網(wǎng)絡(luò)出現(xiàn)超時(shí)，表明網(wǎng)絡(luò)擁塞了。
7. 更新后的 ssthresh 值變?yōu)?12（即發(fā)送窗口數(shù)值 24 的一半），擁塞窗口再重新設(shè)置為 1，并執(zhí)行慢開始算法。
8. 當(dāng) cwnd = 12 時(shí)改為執(zhí)行擁塞避免算法，擁塞窗口按按線性規(guī)律增長，每經(jīng)過一個(gè)往返時(shí)延就增加一個(gè) MSS 的大小。

乘法減小（multiplicative decrease）

• “乘法減小“是指不論在慢開始階段還是擁塞避免階段，只要出現(xiàn)一次超時(shí)（即出現(xiàn)一次網(wǎng)絡(luò)擁塞），就把慢開始門限值 ssthresh 設(shè)置為當(dāng)前的擁塞窗口值乘以 0.5。
• 當(dāng)網(wǎng)絡(luò)頻繁出現(xiàn)擁塞時(shí)，ssthresh 值就下降得很快，以大大減少注入到網(wǎng)絡(luò)中的分組數(shù)。

加法增大（addictive increase）
“加法增大”是指執(zhí)行擁塞避免算法后，在收到對所有報(bào)文段的確認(rèn)后（即經(jīng)過一個(gè)往返時(shí)間），就把擁塞窗口 cwnd增加一個(gè) MSS 大小，使擁塞窗口緩慢增大，以防止網(wǎng)絡(luò)過早出現(xiàn)擁塞。

要指出

• “擁塞避免”并非指完全能夠避免了擁塞。利用以上的措施要完全避免網(wǎng)絡(luò)擁塞還是不可能的。
• “擁塞避免”是說在擁塞避免階段把擁塞窗口控制為按線性規(guī)律增長，使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞。

快重傳和快恢復(fù)

快重傳

• 快重傳算法首先要求接收方每收到一個(gè)失序的報(bào)文段后就立即發(fā)出重復(fù)確認(rèn)。這樣做可以讓發(fā)送方及早知道有報(bào)文段沒有到達(dá)接收方。
• 發(fā)送方只要一連收到三個(gè)重復(fù)確認(rèn)就應(yīng)當(dāng)立即重傳對方尚未收到的報(bào)文段。
• 不難看出，快重傳并非取消重傳計(jì)時(shí)器，而是在某些情況下可更早地重傳丟失的報(bào)文段。

快重傳舉例.png

快恢復(fù)算法

與快重傳配合使用的還有快恢復(fù)算法

• 當(dāng)發(fā)送端收到連續(xù)三個(gè)重復(fù)的確認(rèn)時(shí)，就執(zhí)行“乘法減小”算法，把慢開始門限 ssthresh 減半。但接下去不執(zhí)行慢開始算法。
• 由于發(fā)送方現(xiàn)在認(rèn)為網(wǎng)絡(luò)很可能沒有發(fā)生擁塞，因此現(xiàn)在不執(zhí)行慢開始算法，即擁塞窗口 cwnd 現(xiàn)在不設(shè)置為 1，而是設(shè)置為慢開始門限 ssthresh 減半后的數(shù)值，然后開始執(zhí)行擁塞避免算法（“加法增大”），使擁塞窗口緩慢地線性增大。

從連續(xù)收到三個(gè)重復(fù)的確認(rèn)傳入擁塞避免（下圖）

從連續(xù)收到三個(gè)重復(fù)的確認(rèn)傳入擁塞避免.png

發(fā)送窗口的上限值

• 發(fā)送方的發(fā)送窗口的上限值應(yīng)當(dāng)取為接收方窗口 rwnd 和擁塞窗口 cwnd 這兩個(gè)變量中較小的一個(gè)，即應(yīng)按以下公式確定：

發(fā)送窗口的上限值.png

當(dāng) rwnd < cwnd 時(shí)，是接收方的接收能力限制發(fā)送窗口的最大值。
當(dāng) cwnd < rwnd 時(shí)，則是網(wǎng)絡(luò)的擁塞限制發(fā)送窗口的最大值。

隨機(jī)早期檢測RED（Random Early Detection）

背景見P221
使路由器的隊(duì)列維持兩個(gè)參數(shù)，即隊(duì)列長度最小門限 THmin 和最大門限 THmax。
RED 對每一個(gè)到達(dá)的數(shù)據(jù)報(bào)都先計(jì)算平均隊(duì)列長度 LAV。

1. 若平均隊(duì)列長度小于最小門限 THmin，則將新到達(dá)的數(shù)據(jù)報(bào)放入隊(duì)列進(jìn)行排隊(duì)。
2. 若平均隊(duì)列長度超過最大門限 THmax，則將新到達(dá)的數(shù)據(jù)報(bào)丟棄。
3. 若平均隊(duì)列長度在最小門限 THmin 和最大門限THmax 之間，則按照某一概率 p 將新到達(dá)的數(shù)據(jù)報(bào)丟棄。

隨機(jī)早期檢測RED.png

隨機(jī)早期檢測的隨機(jī)就提現(xiàn)在3中，也就說，RED不是等到已經(jīng)發(fā)生網(wǎng)絡(luò)擁塞后才把所有在隊(duì)列尾部的分組全部丟棄，而是在檢測到網(wǎng)絡(luò)擁塞的早期征兆時(shí)（即路由器的平均隊(duì)列長度超過一定的門限值時(shí)），就先以概率p隨機(jī)丟棄個(gè)別的分組，讓擁塞控制只在個(gè)別的TCP連接上進(jìn)行，因而避免發(fā)生全局性的擁塞控制。

最小門限應(yīng)該足夠大，以保證連接路由器的輸出鏈路有較高的利用率。而最大門限和最小門限的差也應(yīng)該足夠大，使得在一個(gè)TCP往返時(shí)間RTT中隊(duì)列的正常增長仍在最大門限之內(nèi)。經(jīng)驗(yàn)證明最大門限等于最小門限的兩倍是合適的

丟棄概率 p 與 THmin 和 Thmax 的關(guān)系

• 當(dāng) LAV > Thmin 時(shí)，丟棄概率 p = 0。
• 當(dāng) LAV < Thmax 時(shí)，丟棄概率 p = 1。
• 當(dāng) THmin < LAV < THmax時(shí)， 0 < p < 1 。
  例如，按線性規(guī)律變化，從 0 變到 pmax

丟棄概率 p 與 THmin 和 Thmax 的關(guān)系 .png

為什么要用平均隊(duì)列長度？我們知道計(jì)算機(jī)數(shù)據(jù)具有突發(fā)性的特點(diǎn)，因此路由器中的隊(duì)列長度經(jīng)常會(huì)出現(xiàn)很快的起伏變化。如果丟棄概率p按照瞬時(shí)隊(duì)列長度來計(jì)算，那就可能會(huì)出現(xiàn)一些不合理的現(xiàn)象。例如很短的突發(fā)數(shù)據(jù)不大可能使隊(duì)列溢出，因此對于這種數(shù)據(jù)，如果僅因?yàn)樗矔r(shí)隊(duì)列長度超過了門限值THmin就將其丟棄就會(huì)產(chǎn)生不必要的擁塞控制

下圖也說明了這一點(diǎn)

平均隊(duì)列長度和瞬時(shí)隊(duì)列長度的區(qū)別.png

平均隊(duì)列長度以及p的計(jì)算

見P223

TCP運(yùn)輸連接管理

運(yùn)輸連接的三個(gè)階段

• 運(yùn)輸連接就有三個(gè)階段，即：連接建立、數(shù)據(jù)傳送和連接釋放。運(yùn)輸連接的管理就是使運(yùn)輸連接的建立和釋放都能正常地進(jìn)行。

連接建立過程中要解決以下三個(gè)問題：

• 要使每一方能夠確知對方的存在。
• 要允許雙方協(xié)商一些參數(shù)（如最大報(bào)文段長度，最大窗口大小，服務(wù)質(zhì)量等）。
• 能夠?qū)\(yùn)輸實(shí)體資源（如緩存大小，連接表中的項(xiàng)目等）進(jìn)行分配。

客戶 - 服務(wù)器方式
TCP連接的建立都是采用客戶端服務(wù)器的方式，主動(dòng)發(fā)起連接建立的應(yīng)用進(jìn)程叫做客戶（client），被動(dòng)等待連接建立的應(yīng)用進(jìn)程叫做服務(wù)器（server）

TCP的連接建立（三次握手）

三次握手.png

1. B的TCP服務(wù)器進(jìn)程先創(chuàng)建傳輸控制塊TCB（transmission control block，存儲了每一個(gè)連接中的一些重要信息：TCP連接表，到發(fā)送和接收緩存的指針，到重傳隊(duì)列的指針，當(dāng)前的發(fā)送和接收序號等等），準(zhǔn)備接受客戶進(jìn)程的連接請求。然后服務(wù)器進(jìn)程就處于LISTEN（收聽）狀態(tài)，等待客戶的連接請求。如果有就作出響應(yīng)
2. A的TCP客戶進(jìn)程也是首先創(chuàng)建傳輸控制塊TCB，然后A 的 TCP 向 B 發(fā)出連接請求報(bào)文段，其首部中的同步位 SYN = 1，并選擇序號 seq = x，表明傳送數(shù)據(jù)時(shí)的第一個(gè)數(shù)據(jù)字節(jié)的序號是 x。
3. B 的 TCP 收到連接請求報(bào)文段后，如同意，則發(fā)回確認(rèn)。B 在確認(rèn)報(bào)文段中應(yīng)使 SYN = 1，使 ACK = 1，其確認(rèn)號ack = x + 1，自己選擇的序號 seq = y。
4. A 收到此報(bào)文段后向 B 給出確認(rèn)，其 ACK = 1，確認(rèn)號 ack = y + 1。A 的 TCP 通知上層應(yīng)用進(jìn)程，連接已經(jīng)建立。
5. B 的 TCP 收到主機(jī) A 的確認(rèn)后，也通知其上層應(yīng)用進(jìn)程：TCP 連接已經(jīng)建立。

三次握手建立TCP連接的各狀態(tài)

三次握手建立TCP連接的各狀態(tài).png

“三次”握手的原因

為什么A還要再發(fā)送一次數(shù)據(jù)呢？主要是為了防止已失效的連接請求報(bào)文段突然又傳送到了B，因而產(chǎn)生錯(cuò)誤。

所謂的“已失效的連接請求報(bào)文段”是這樣產(chǎn)生的。

• 考慮一種正常情況。A發(fā)送了連接請求，但是因?yàn)檫B接請求報(bào)文丟失而未收到確認(rèn)。于是A再重傳一次連接請求。后來收到了確認(rèn)，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接。A共發(fā)送了兩個(gè)連接請求報(bào)文段，其中第一個(gè)丟失，第二個(gè)到達(dá)了B。沒有“已失效的連接請求報(bào)文段 ”
• 現(xiàn)假定出現(xiàn)一種異常情況，即A發(fā)出的第一個(gè)連接請求報(bào)文段并沒有丟失，而是在某些網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間滯留了，以至延誤到連接釋放后才到達(dá)B。本來這是一個(gè)早已經(jīng)失效的報(bào)文段。但B收到此失效的連接請求報(bào)文后，就誤認(rèn)為是A又發(fā)來一次新的連接請求。于是就向A發(fā)送確認(rèn)報(bào)文，同意建立連接。假定不采用三次握手，那么只要B發(fā)出確認(rèn)，新的連接就建成了。由于現(xiàn)在A并沒有建立連接的請求，因此并不會(huì)理睬B的確認(rèn)，也不會(huì)向B發(fā)送數(shù)據(jù)，但是B卻以為連接已經(jīng)建立，并一直等待A發(fā)送數(shù)據(jù)，B的許多資源就這樣白白浪費(fèi)了。采用三次握手就可以防止上述現(xiàn)象的發(fā)生。例如在剛才的情況下，A不會(huì)向B的確認(rèn)發(fā)出確認(rèn)，B由于收不到第三次握手，就知道A并沒有要求建立連接。

TCP連接的釋放（四次握手）

TCP連接的釋放.png

• 數(shù)據(jù)傳輸結(jié)束后，通信的雙方都可釋放連接?，F(xiàn)在 A 的應(yīng)用進(jìn)程先向其 TCP 發(fā)出連接釋放報(bào)文段，并停止再發(fā)送數(shù)據(jù)，主動(dòng)關(guān)閉 TCP連接。A 把連接釋放報(bào)文段首部的 FIN = 1，其序號seq = u（等于A前面?zhèn)鬏數(shù)淖詈笠粋€(gè)字節(jié)號+1），等待 B 的確認(rèn)。
• B 發(fā)出確認(rèn)，確認(rèn)號 ack = u + 1，而這個(gè)報(bào)文段自己的序號 seq = v（等于B前面?zhèn)鬏數(shù)淖詈笠粋€(gè)字節(jié)號+1）。TCP 服務(wù)器進(jìn)程通知高層應(yīng)用進(jìn)程。從 A 到 B 這個(gè)方向的連接就釋放了，TCP 連接處于半關(guān)閉狀態(tài)。B 若發(fā)送數(shù)據(jù)，A 仍要接收。
• 若 B 已經(jīng)沒有要向 A 發(fā)送的數(shù)據(jù)，其應(yīng)用進(jìn)程就通知 TCP 釋放連接，序號為seq = w（在半關(guān)閉狀態(tài)可能又發(fā)送了一些數(shù)據(jù)） ack = u+1（B還必須記錄上次已發(fā)送的確認(rèn)號）。
• A 收到連接釋放報(bào)文段后，必須發(fā)出確認(rèn)。在確認(rèn)報(bào)文段中 ACK = 1，確認(rèn)號 ack = w + 1，自己的序號 seq = u + 1。
• TCP 連接必須經(jīng)過時(shí)間 2MSL （最長報(bào)文壽命）后才真正釋放掉。

A必須等待2MSL的時(shí)間

• 第一，為了保證 A 發(fā)送的最后一個(gè) ACK 報(bào)文段能夠到達(dá) B。
  這個(gè)報(bào)文段有可能丟失，因?yàn)槭沟锰幱贚AST-ACK狀態(tài)的B收不到對已發(fā)送的FIN+ACK報(bào)文段的確認(rèn)。B會(huì)超時(shí)重傳這個(gè)FIN+ACK報(bào)文段，而A就能在這2MSL時(shí)間內(nèi)收到這個(gè)重傳的FIN+ACK報(bào)文段，接著A重傳一次確認(rèn)，重新啟動(dòng)2MSL計(jì)時(shí)器直到雙方都關(guān)閉。
• 第二，防止 “已失效的連接請求報(bào)文段”出現(xiàn)在本連接中。A 在發(fā)送完最后一個(gè) ACK 報(bào)文段后，再經(jīng)過時(shí)間 2MSL，就可以使本連接持續(xù)的時(shí)間內(nèi)所產(chǎn)生的所有報(bào)文段，都從網(wǎng)絡(luò)中消失。這樣就可以使下一個(gè)新的連接中不會(huì)出現(xiàn)這種舊的連接請求報(bào)文段。
  除時(shí)間等待計(jì)時(shí)器外，TCP還設(shè)有一個(gè)?；钣?jì)時(shí)器，設(shè)想有這樣的情況：客戶已主動(dòng)與服務(wù)器建立了TCP連接。但后來客戶端的主機(jī)出現(xiàn)了故障。顯然，服務(wù)器以后就不再收到客戶發(fā)來的數(shù)據(jù)，因此，應(yīng)當(dāng)有措施使得服務(wù)器不會(huì)白白等下去。這就是使用?；钇?，時(shí)間設(shè)置通常為兩小時(shí)，服務(wù)器每收到一次客戶的數(shù)據(jù)，就重新設(shè)置?；钇?。若兩小時(shí)每收到客戶的數(shù)據(jù)，服務(wù)器就發(fā)送一個(gè)嗅探報(bào)文段，以后則每隔75分鐘發(fā)送一次，若一連發(fā)送10個(gè)嗅探報(bào)文后客戶端仍無響應(yīng)，服務(wù)器就認(rèn)定客戶端發(fā)送故障，就關(guān)閉這個(gè)連接。

TCP有限狀態(tài)機(jī)

• TCP 有限狀態(tài)機(jī)的圖中每一個(gè)方框都是 TCP 可能具有的狀態(tài)。
• 每個(gè)方框中的大寫英文字符串是 TCP 標(biāo)準(zhǔn)所使用的 TCP 連接狀態(tài)名。狀態(tài)之間的箭頭表示可能發(fā)生的狀態(tài)變遷。
• 箭頭旁邊的字，表明引起這種變遷的原因，或表明發(fā)生狀態(tài)變遷后又出現(xiàn)什么動(dòng)作。
• 圖中有三種不同的箭頭。
  • 粗實(shí)線箭頭表示對客戶進(jìn)程的正常變遷。
  • 粗虛線箭頭表示對服務(wù)器進(jìn)程的正常變遷。
  • 另一種細(xì)線箭頭表示異常變遷。

TCP有限狀態(tài)機(jī).png