[計算機網(wǎng)絡]第三章——傳輸層

僅供交流，請勿轉載，侵權必刪，寫作業(yè)時請勿直接抄襲

3.1 概述和傳輸層服務

傳輸層協(xié)議為運行在不同主機上的應用進程之間提供了邏輯通信( logic communication)功能。從應用程序的角度看，通過邏輯通信，運行不同進程的主機好像直接相連一樣;實際上，這些主機也許位于地球的兩側，通過很多路由器及多種不同類型的鏈路相連。應用進程使用傳輸層提供的邏輯通信功能彼此發(fā)送報文，而無須考慮承載這些報文的物理基礎設施的細節(jié)。

如圖所示，傳輸層協(xié)議是在端系統(tǒng)中而不是在路由器中實現(xiàn)的。在發(fā)送端，傳輸層從發(fā)送應用程序進程接收到的報文轉換成傳輸層報文段(segment)。 實現(xiàn)的方法(可能)是將應用報文劃分為較小的塊，并為每塊加上一個傳輸層首部以生成傳輸層報文段。然后，在發(fā)送端系統(tǒng)中，傳輸層將這些報文段傳遞給網(wǎng)絡層，網(wǎng)路層將其封裝成網(wǎng)絡層分組( 即數(shù)據(jù)報)并向目的地發(fā)送。

網(wǎng)絡路由器僅作用于該數(shù)據(jù)報的網(wǎng)絡層字段;即它們不檢查封裝在該數(shù)據(jù)報的傳輸層報文段的字段。在接收端，網(wǎng)絡層從數(shù)據(jù)報中提取傳輸層報文段，并將該報文段向上交給傳輸層。傳輸層則處理接收到的報文段，使該報文段中的數(shù)據(jù)為接收應用進程使用。

網(wǎng)絡應用程序可以使用多種的傳輸層協(xié)議。例如，因特網(wǎng)有兩種協(xié)議，即TCP和UDP

傳輸層概述

因特網(wǎng)網(wǎng)絡層協(xié)議有一個名字叫IP,即網(wǎng)際協(xié)議。IP為主機之間提供了邏輯通信。IP 的服務模型是盡力而為交付服務( best- effort delivery service)。這意味著IP盡它“最大的努力”在通信的主機之間交付報文段，但它并不做任何確保。特別是，它不確保報文段的交付，不保證報文段的按序交付，不保證報文段中數(shù)據(jù)的完整性。由于這些原因，IP被稱為不可靠服務( unreliable service)。 在此還要指出的是,每臺主機至少有一個網(wǎng)絡層地址，即所謂的IP地址。

在對IP服務模型有了初步了解后，總結一下UDP和TCP所提供的服務模型。UDP和TCP最基本的責任是，將兩個端系統(tǒng)間IP的交付服務擴展為運行在端系統(tǒng)上的兩個進程之間的交付服務。將主機間交付擴展到進程間交付被稱為傳輸層的多路復用(transport- layer multiplexing)與多路分解( demultiplexing)。

UDP和TCP還可以通過在其報文段首部中包括差錯檢查字段而提供完整性檢查。進程到進程的數(shù)據(jù)交付和差錯檢查是兩種最低限度的傳輸層服務，也是UDP所能提供的僅有的兩種服務。特別是，與IP一樣，UDP也是一種不可靠的服務，即不能保證一個進程所發(fā)送的數(shù)據(jù)能夠完整無缺地(或全部!)到達目的進程。

關于TCP的講解，接下來會仔細說明。

?? 傳輸層的功能

1?? 提供應用進程之間的邏輯通信（網(wǎng)絡層提供主機之間的邏輯通信）

2?? 提供復用與分用

3?? 差錯檢測

4?? 提供無連接的或面向連接的服務

3.2 多路復用與多路分解

將主機間交付擴展到進程間交付被稱為傳輸層的多路復用(transport- layer multiplexing)與多路分解( demultiplexing)。

一個進程有一個或多個套接字，相當于從網(wǎng)絡向進程傳遞數(shù)據(jù)和從進程向網(wǎng)絡傳遞數(shù)據(jù)的門戶，在接受方中的傳輸層并沒有直接將數(shù)據(jù)交付給進程，而是給了套接字。

每個傳輸層報文段中具有幾個字段。在接收端，傳輸層檢查這些字段，標識出接收套接字，進而將報文段定向到該套接字。將傳輸層報文段中的數(shù)據(jù)交付到正確的套接字的工作稱為多路分解（demultiplexing）。

類似于打開微信和qq，qq的消息不會給微信，微信的消息不會給qq

在源主機從不同套接字中收集數(shù)據(jù)塊，并為每個數(shù)據(jù)塊封裝上首部信息（這將在以后用于分解）從而生成報文段，然后將報文段傳遞到網(wǎng)絡層，所有這些工作稱為多路復用（multiplexing）

發(fā)送端進行多路復用；接收端進行多路分解

例如小明從郵遞員收到新建，并通過查看收信人姓名而將信件交付給他的朋友時執(zhí)行的就是多路分解；而當小美從朋友手中收集信件并交給郵遞員時，執(zhí)行的就是多路復用

傳輸層多路復用的要求

1?? 套接字有唯一標識符

2?? 每個segment有特殊字段來指示所要交付到的套接字，而這些特殊字段就是源端口號字段和目的端口號字段

端口號是一個16位的數(shù)，大小在0~65535之間，0~1023范圍之間的是周知端口號（如HTTP：80，F(xiàn)TP：21，telnet：23)，用戶使用的端口號要大于1023

無連接的多路復用與多路分解

通常，客戶端應用程序的端口號可以自動分配

此時，一個UDP套接字是由一個二元組全面標識的，該二元組包括一個目的IP地址和一個目的端口號

具有不同源IP地址和源端口號，但是具有相同目的IP地址和目的端口號的兩個報文段會通過同一個套接字被送到同一個目的進程中。

報文段中的源端口號和源IP地址可以作為報文段回發(fā)時的返回地址使用

有連接的多路復用與多路分解

一個TCP套接字需要一個四元組

源IP地址和目的IP地址

源端口號和目的端口號

具有不同源IP地址和源端口號，但是具有相同目的IP地址和目的端口號的兩個報文段會被送到不同的套接字中

每個帶有端口號的客戶端應用程序都指向服務器上的套接字

3.3 UDP|User Datagram Protocol :用戶數(shù)據(jù)報協(xié)議

UDP的段叫數(shù)據(jù)報

UDP只具有傳輸協(xié)議能夠做的最少工作：多路復用/多路分解；差錯檢測。幾乎是直接跟IP打交道

使用UDP時，在發(fā)送報文段之前，發(fā)送方和接收方的傳輸層實體之間沒有握手，因此UDP被稱為是connectionless

提供的也是"best effort"服務

特征

1?? 實現(xiàn)簡單：發(fā)送方、接收方?jīng)]有連接狀態(tài)

2?? 數(shù)據(jù)段首部head小(8字節(jié))，傳輸開銷小，時延較短

3?? 速度快：不用控制

典型應用

Remote file server (NFS)

Streaming multimedia流式多媒體

Internet telephony

Network management

Routing protocol(RIP)

Name translation (DNS)

Multicasting

Real-time involved apps(RTP)實時傳輸協(xié)議

TFTP

DHCP動態(tài)主機配置協(xié)議

UDP報文段結構

段頭只有8個字節(jié)：源端口號、目的端口號、長度、校驗和各2B

UDP校驗和checksum

UDP檢驗和提供了差錯檢測功能。這就是說，檢驗和用于確定當UDP報文段從源到達目的地移動時，其中的比特是否發(fā)生了改變(例如，由于鏈路中的噪聲干擾或者存儲在路由器中時引入問題)。

發(fā)送方

1?? 將段內容視為16位整數(shù)序列

0110011001100110
0101010101010101
0000111100001111

2?? 對段內容相加，取低16位，按位取反，得到校驗和

相加得到1100101011001010

按位取反得到0011010100110101

3?? 發(fā)送方將校驗和0011010100110101輸入UDP校驗和字段

接收方

1?? 將段內容視為16位整數(shù)序列

0110011001100110
0101010101010101
0000111100001111

2?? 對段內容相加，取低16位

相加得到1100101011001010

3?? 與checksum再相加，檢查是否全為1（這里相加就是1111111111111111）

NO -檢測到錯誤

YES -沒有檢測到錯誤

但是，不能糾正

這種檢錯能力很弱

3.4 TCP|Transmission Control Protocol傳輸控制協(xié)議

TCP概述

特點

1?? 點對點：一個發(fā)送方，一個接收方(不能用于多播)

2?? 可靠的、字節(jié)有序的流式發(fā)送數(shù)據(jù)：沒有“報文邊界”

3?? 流水線式：TCP擁塞和流量控制設置窗口大小

4?? 需要開辟發(fā)送和接收緩沖區(qū)

5?? 全雙工數(shù)據(jù)full duplex data：在同一連接中雙向數(shù)據(jù)流；(UDP也是)

MSS:最大段大小(536字節(jié))

三控一管：連接管理、可靠性控制、流量控制、擁塞控制

所謂的連接只是邏輯上的，發(fā)送方和接收方開辟緩存，設置變量，交換序列號

段文格式

僅從TCP報文段的首部是無法得知目的IP地址的。因此，TCP必須告訴IP層此報文段要發(fā)送給哪一個目的主機（給出其IP地址）。此目的IP地址填寫在IP數(shù)據(jù)報的首部中。

TCP段頭指的是前面五行，一共20個字節(jié)

1?? 源端口號和目的端口號：各占2B

2?? 序列號：TCP是面向字節(jié)流的，傳送時按照一個個字節(jié)傳送，所以在一個TCP連接中傳送的字節(jié)流需要編號，這樣才能保證按序交付

例如，某報文段的序號從301開始，而攜帶的數(shù)據(jù)共有100B.這就表明本報文段數(shù)據(jù)的第一個字節(jié)的序號是301,最后一個字節(jié)的序號是400.顯然，下一個報文段（如果還有）的數(shù)據(jù)序號應當從401開始，即下一個報文段的序號字段應為401,這個字段名也稱為“報文段序號”。

3?? 確認號acknowledgement number：占4B。TCP是含有確認機制的，所以接收端需要給發(fā)送端發(fā)送確認號，這個確認號只需記住一點：若確認號等于N,則表明到序號N-1為止的所有數(shù)據(jù)都已經(jīng)正確收到。

例如，B正確收到了A發(fā)送過來的一個報文段，其序號字段值是501,而數(shù)據(jù)長度是200B（序號501~700),這表明B正確收到了A發(fā)送的到序號700為止的數(shù)據(jù)。因此，B期望收到A的下一個數(shù)據(jù)序號是701,于是B將發(fā)送給A的確認報文段中的確認號設置為701.注意，現(xiàn)在的確認號不是501,也不是700,而是701.

4?? 首部長度

5?? 保留字段：占6位。保留為今后使用，但目前應置為0,該字段可以忽略不計。

6?? 緊急 URG:當URG=1時，表明緊急指針字段有效。它告訴系統(tǒng)此報文段中有緊急
數(shù)據(jù)，應盡快傳送（相當于高優(yōu)先級的數(shù)據(jù)）

7?? 確認比特ACK:只有當ACK=1時，確認號字段才有效；當ACK=0時，確認號無效。TCP規(guī)定，一旦連接建立了，所有傳送的報文段都必須把ACK置1.

8?? 推送比特PSH:TCP收到推送比特置1的報文段，就盡快地交付給接收應用進程，而不再等到整個緩存都填滿后再向上交付。

9?? 復位比特RST:當RST=1時，表明TCP連接中出現(xiàn)嚴重差錯（如由于主機崩潰或其他原因），必須釋放連接，然后再重新建立傳輸連接。

1?? 0?? 同步比特SYN:同步比特SYN置為1,表示這是一個連接請求或連接接收報文，后面的TCP連接會詳細講到。

1?? 1?? 終止比特FIN:釋放一個連接。當FIN=1時，表明此報文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放傳輸連接。

1?? 2?? 窗口字段：占2B.窗口字段用來控制對方發(fā)送的數(shù)據(jù)量，單位為字節(jié)（B).記住一句話：窗口字段明確指出了現(xiàn)在允許對方發(fā)送的數(shù)據(jù)量。例如，設確認號是701,窗口字段是1000.這就表明，從701號開始算起，發(fā)送此報文段的一方還有接收1000B數(shù)據(jù)的接收緩存空間。

1?? 3?? 校驗和字段：占2B.校驗和字段檢驗的范圍包括首部和數(shù)據(jù)兩部分。在計算校驗和時，和UDP一樣，要在TCP報文段的前面加上12B的偽首部（只需將UDP偽首部的第4個字段的17改為6,其他和UDP一樣）。

1?? 4?? 緊急指針字段：占2B.前面已經(jīng)講過緊急指針指出在本報文段中的緊急數(shù)據(jù)的最后
一個字節(jié)的序號。

1?? 5?? 選項字段：長度可變。TCP最初只規(guī)定了一種選項，即最大報文段長度MSS.MSS告訴對方TCP:“我的緩存所能接收的報文段的數(shù)據(jù)字段的最大長度是MSS字節(jié)?！?/p>

1?? 6?? 填充字段：為了使整個首部長度是4B的整數(shù)倍。

可靠性控制（重要）

丟包重傳

1?? 發(fā)送方:

重新發(fā)送丟失的片段，未被正確接收前一直存在發(fā)送方的緩存區(qū)

需要開辟發(fā)送緩沖區(qū)（發(fā)送窗口）：開始指針：send_base（指向發(fā)送緩存的最左側），窗口大小：n，下一個序列號：nextseqnum

當有數(shù)據(jù)需要發(fā)送時，檢查nextseqnum是否有效，有效就將其封裝成TCP的段發(fā)送，發(fā)送后將nextseqnum右移，一直移動到nextseqnum-send_base=N，此時窗口就滿了，應用層再給數(shù)據(jù)就無法發(fā)送了。接收方確認數(shù)據(jù)收到，然后發(fā)送窗口右移。

? 如何知道段丟失了嗎?

接收方發(fā)送確認段序號

計時器時間到了還沒收到確認信號就認為段丟了，重傳

? 如何知道哪些部分丟失了? 序列號

2?? 接收方:

對期望的那個段進行確認——返回的段序號是它期待的那個段的段序號

需要開辟接收緩沖區(qū)：開始指針：rcv_base（指向的段序號就是接收方期待的段的段序號）以及窗口大小N

第一個灰色：rcv_base指向的段序號就是接收方期待的段的段序號

紫紅色：收到了這個段，沒有差錯，先緩存起來，但是不能送給應用層，如果送給應用層會亂序（不可靠），因為期待的那個段還沒有到，到了一起送

第二個灰色：還沒有收到，下一個期待的段

藍色：空閑接收緩存

示例

后一個確認號=前一個段的段序號+前一個段的數(shù)據(jù)域長度

Seq：段數(shù)據(jù)的第一個字節(jié)的字節(jié)流“數(shù)”，隨機選擇一個初始序列號

ACK：從另一端期望的下一個字節(jié)的Seq

算法表示

發(fā)送端

發(fā)送端簡化后的可靠性控制算法：單向數(shù)據(jù)傳輸；無流量，擁塞控制

有限狀態(tài)機圖如下：

只有一個狀態(tài)：等事件，當一個事件發(fā)生時，狀態(tài)遷移到自己繼續(xù)等事件

快速重傳的解釋如下：代表了輕度擁塞，超時是重度擁塞

偽代碼表示如下

/*發(fā)送端可靠性控制偽代碼，要記住*/
/*假設發(fā)送方不受TCP流量和擁塞限制，來自上層數(shù)據(jù)的長度小于MSS，且數(shù)據(jù)傳輸只在一個方向進行*/
send_base = init_sequence number
nextseqnum = init_sequence number
loop(永遠){
	switch(事件)
	事件:應用層有數(shù)據(jù)讓TCP傳輸
		if(nextseqnum-send_base<N){
			創(chuàng)建段序號為nextsqnum的段
			啟動計時器
			將段發(fā)給IP層
			nextseqnum = nextseqnum +數(shù)據(jù)長度/*段序號是跳躍式的*/
		}else{
			拒絕發(fā)送段
		}
	事件:段序號為y的段的計時器超時
        重傳這個段y
		重新計算計時器超時間隔
		重啟計時器
	事件:接收到ACK，字段值為y
        if(y>send_base){/*段在發(fā)送窗口內*/
            取消掉段y之前所有的段的計時器
            send_base = y/*窗口右移*/
        }else{/*這里指的是y=send_base，接收端還沒有收到y(tǒng)*/
            對ACK字段為y的計數(shù)器+1
            if(計數(shù)器的值==3){
                快速重傳段y
                重啟段y的計時器
            }
        }
}

接收端

第一個灰色：rcv_base指向的段序號就是接收方期待的段的段序號

紫紅色：收到了這個段，沒有差錯，先緩存起來，但是不能送給應用層，如果送給應用層會亂序（不可靠），因為期待的那個段還沒有到，到了一起送

第二個灰色：還沒有收到，下一個期待的段

藍色：空閑接收緩存

產(chǎn)生ACK

舉例分析如下

全雙工通信的話發(fā)送端和接收端都放一份上面的兩種可靠性算法

TCP往返時間和超時

如何設置TCP超時時間間隔：略大于一個RTT

可以預測RTT：

SampleRTT（實際測量的RTT):從段傳輸?shù)紸CK接收的時間

忽略重傳，累積的分段

SampleRTT會因路由器擁塞和終端系統(tǒng)負載變化而變化，因此，我們希望估計的RTT“更平穩(wěn)”。

$$EstimatedRT{T}_n=(1?\alpha )?EstimatedRT{T}_{n?1}+\alpha ?SampleRTT$$

Exponential weighted moving average指數(shù)加權運動平均；給定樣本的影響以指數(shù)速度遞減；α的典型值為0.125(右移三位，速度更快)

自適應超時時間設置：EstimtedRTT加上“安全margin”

$$Timeout=EstimatedRTT+4?Deviation$$
其中，$Deviatio{n}_n=(1?\beta )?Deviatio{n}_{n?1}+\beta ?|SampleRTT?EstimatedRTT|$
$$EstimateRT{T}_n=(1?\alpha )EstimateRT{T}_{n?1}+\alpha SampleRTT+4?((1?\beta )Deviatio{n}_n+\beta |SamplaRTT?EstimateRT{T}_n|)$$

β通常取0.25

這個公式也可以用于預測接收窗口rwnd的大小

流量控制Flow Control

前面講過，一條TCP連接的每一側主機都為該連接設置了接收緩存。當該TCP連接收到正確、按序的字節(jié)后，它就將數(shù)之前重傳丟失的報文段據(jù)放人接收緩存。相關聯(lián)的應用進程會從該緩存中讀取數(shù)據(jù)，但不必是數(shù)據(jù)剛一到達就立即讀取。事實上，接收方應用也許正忙于其他任務，甚至要過很長時間后才去讀取該數(shù)據(jù)。如果某應用程序讀取數(shù)據(jù)時相對緩慢，而發(fā)送方發(fā)送得太多、太快，發(fā)送的數(shù)據(jù)就會很容易地使該連接的接收緩存溢出。

TCP為它的應用程序提供了流量控制服務，以消除發(fā)送方是接收方緩存溢出的可能性。流量控制是一個速度匹配服務，即發(fā)送方的發(fā)送速率和接收方應用程序的讀取速率相匹配。

TCP通過讓發(fā)送方維護一個稱為接收窗口receive window的變量來提供流量控制，接收窗口用于給發(fā)送方一個指示——接收方還有多少可用的緩存空間。接收緩存中的空閑空間。

TCP段頭中有一個字段表示接收窗口的大小。

假設主機A通過一條TCP連接向主機B發(fā)送一個大文件，主機B為該連接分配了一個接收緩存，并用RcvBuffer來表示其大小，主機B上的應用進程不時地從該緩存中讀取數(shù)據(jù)，有如下變量定義

LastByteRead：主機B上的應用進程從緩存讀出的數(shù)據(jù)流的最后一個字節(jié)的編號。（被讀走的最后一個段序號）

LastByteRcvd：從網(wǎng)絡中到達的并且已放入主機B接收緩存中的數(shù)據(jù)流的最后一個字節(jié)的編號。（剛收到的段的段序號）

由于 TCP 不允許已分配的緩存溢出，下式必須成立：
$$LastByteRcvd?LastByteRead\le RcvBuffer$$
接收窗口(空閑緩存)用RcvWindow（rwnd）表示，根據(jù)緩存可用空間的數(shù)量來設置：
$$RcvWindow=RcvBuffer?[LastByteRcvd?LastByteRead]$$
主機 B 通過把當前的RcvWindow值放入它發(fā)給主機 A 的報文段接收窗口字段中，通知主機 A 它在該連接的緩存中還有多少可用空間。開始時，主機B設定RcvWindow = RcvBuffer。

主機A 輪流跟蹤兩個變量，LastByteSent 和 LastByteAcked，這兩個變量的意義很明顯。注意到這兩個變量之間的差LastByteSent - LastByteAcked，就是主機A發(fā)送到連接中但未被確認的數(shù)據(jù)量。通過將未確認的數(shù)據(jù)量控制在值 rwnd 以內，就可以保證主機 A 不會使主機B的接收緩存溢出。因此，主機A在該連接的整個生命周期須保證：
$$LastByteSent?LastByteAcked\le rwnd$$
對于這個方案還存在一個小小的技術問題。為了理解這一點，假設主機B的接收緩存已經(jīng)存滿，使得rwnd=0。在將rwnd=0通告給主機A之后，還要假設主機B沒有任何數(shù)據(jù)要發(fā)給主機A。此時，考慮會發(fā)生什么情況。因為主機B上的應用進程將緩存清空，TCP并不向主機A發(fā)送帶有rwnd新值的新報文段；事實上，TCP僅當在它有數(shù)據(jù)或有確認要發(fā)時才會發(fā)送報文段給主機A。這樣，主機A不可能知道主機B的接收緩存已經(jīng)有新的空間了，即主機A被阻塞而不能再發(fā)送數(shù)據(jù)！為了解決這個問題，TCP規(guī)范中要求：當主機B的接收窗口為0時，主機A繼續(xù)發(fā)送只有一個字節(jié)數(shù)據(jù)的報文段。這些報文段將會被接收方確認。最終緩存將開始清空，并且確認報文里將包含一個非0的rwnd值。

TCP連接管理(重要)

連接的開啟：三個握手

1?? 發(fā)送端(客戶端)給接收端(服務器端)發(fā)送一個SYN段(在 TCP 標頭中 SYN 位字段為 1 的 TCP/IP 數(shù)據(jù)包), 該段中也包含客戶端的初始序列號(序列號Sequence number = J)。

同步比特SYN:同步比特SYN置為1,表示這是一個連接請求或連接接收報文，后面的TCP連接會詳細講到。

2?? 接收端返回給發(fā)送端 SYN +ACK 段(在 TCP 標頭中SYN和ACK位字段都為 1 的 TCP/IP 數(shù)據(jù)包)， 該段中包含接收端的初始序列號(序列號 = K)；同時使確認號Acknowledgement number = J + 1來表示確認已收到客戶端的 SYN段(序列號 = J)。

第二次握手，接收端開辟緩存

3?? 發(fā)送端給接收端響應一個ACK段(在 TCP 標頭中 ACK 位字段為 1 的 TCP/IP 數(shù)據(jù)包), 該段中使 確認號 = K + 1來表示確認已收到服務器的 SYN段(序列號 = K)。

第三次握手，發(fā)送端開辟緩存

一旦完成這三個步驟，客戶和服務器主機就可以互相發(fā)送包括數(shù)據(jù)的報文段了。

DoS攻擊：半連接攻擊(第三個握手永遠不做，沒完沒了發(fā)送連接請求，使服務器端不斷開辟緩存，使服務器崩潰)

很多臺客戶端攻擊叫DDos

連接的關閉：兩次握手（四次揮手）

1??客戶端系統(tǒng)向服務器發(fā)送TCP FIN控制段

終止比特FIN:釋放一個連接。當FIN=1時，表明此報文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放傳輸連接。

2??服務器接收到FIN，返回ACK。關閉連接，發(fā)送FIN。

3??客戶端收到FIN，以ACK回應。

計時器定時等待

4??服務器，接收ACK。連接關閉。

timed wait后TCP才真正的關閉

擁塞控制Congestion Control

擁塞指的是路由器擁塞：有太多的發(fā)送端發(fā)送數(shù)據(jù)，發(fā)的太快

表現(xiàn)：丟包(路由器緩沖區(qū)溢出)；長延遲(在路由器緩沖區(qū)中排隊)

擁塞原因與代價（了解即可）

情況一：兩個發(fā)送端和一臺無限大緩存路由器

${\lambda }_{in}$：主機A(B)中的應用程序以${\lambda }_{in}$字節(jié)/秒的平均速率將數(shù)據(jù)發(fā)送到連接中

來自主機A和主機B的包通過一臺路由器，在一段容量為R的共享式輸出鏈路上傳輸，路由器緩存無限大說明不會丟包。當兩個包的發(fā)送速度大于路由器的交換能力時$2{\lambda }_{in}>R$，就會產(chǎn)生擁塞。

情況二：兩個發(fā)送端和一臺有限緩存路由器

此時，路由器的緩存是有限的，也符合實際情況，當包到達一個已滿的緩存時會被丟棄，從而被發(fā)送端重傳。

${\lambda }_{in}$：表示應用程序將初始數(shù)據(jù)發(fā)送到套接字中的速率

${\lambda }_{in}’$：表示傳輸層向網(wǎng)絡中發(fā)送報文段（含有初始數(shù)據(jù)和重傳數(shù)據(jù)）的速率，也稱為網(wǎng)絡的供給載荷（offered load）

1?? ${\lambda }_{in}$較小時，${\lambda }_{in}={\lambda }_{out}$

2?? 出現(xiàn)丟包重傳，${\lambda }_{in}^{\prime }>{\lambda }_{out}$

3?? 延時較大，會進行不必要的重傳，實際有效資源只用到了一半（被垃圾包占用了）

情況三：4個發(fā)送方和具有有限緩存的多臺路由器以及多跳路徑

對角發(fā)送。無論在哪一個路由器丟包，都會造成資源浪費。

擁塞控制方法分類

1?? 網(wǎng)絡幫助的擁塞控制

ATM(異步傳輸模式)的內核設備不叫路由器，叫ATM交換機（胖內核，瘦端系統(tǒng)，內核功能強大），擁塞以后通知發(fā)送端——網(wǎng)絡幫助的擁塞控制

交換機直接通知給發(fā)送端

交換機通知給接收端，接收端再通知發(fā)送端（用的更多）

2?? 端到端的擁塞控制

因特網(wǎng)是瘦內核，胖端系統(tǒng)的網(wǎng)絡，端系統(tǒng)功能強大（如DNS就放在端系統(tǒng)），路由器的功能盡量簡單，擁塞了不通知發(fā)送端，靠端系統(tǒng)自行感知。

超時了說明網(wǎng)絡重度擁塞（端到端的延時跟距離有關）

收到三個相同ACK（丟包）說明網(wǎng)絡輕度擁塞——通常采用此方法

ATM的擁塞控制(過時了，了解即可)

ATM提供的四種業(yè)務：ABR、UBR、CBR、VBR

1??ABR: Available Bit Rate 有效位率服務,主要用于視頻服務; 可以保證一個最小帶寬,可能丟包.

2?? CBR : Constant Bit Rate 主要用于實時語音通信; 不會丟包,不需要擁塞控制.

3?? VBR : Variable Bit Rate 不會丟包,不需要擁塞控制.

4?? UBR : Unspecified Bit Rate 使用時有資源則使用,無資源則丟包,免費使用,無擁塞控制

ATM 的通信數(shù)據(jù)單元稱為信元( Cell )。

頭是5個字節(jié)（存訪擁塞指示信息），數(shù)據(jù)域是48個字節(jié)

分為兩種：

1?? data cells:數(shù)據(jù)信元

2?? RM (resource management) cells資源管理信元：存訪擁塞信息，通常每幾十個數(shù)據(jù)信元放一個資源管理信元

ATM網(wǎng)絡針對ABR的擁塞控制方法有三種

1?? CI和NI bits

CI bit : Congestion Indication 擁塞指示ATM 信元頭中有一位即為CI 位,當發(fā)生擁塞時將 CI 位置1。發(fā)送端在接收到CI 位置1 的信息后將會降低發(fā)送速率。
NI bit : No Increasein rate 告訴發(fā)送端不要再增加發(fā)送速率。代表網(wǎng)絡即將進入擁塞或發(fā)生輕度擁塞。

每32 個信元中插入一個資源管理信元,交換機對資源管理信元中的CI 與NI 位進行置位,發(fā)送端根據(jù)這兩位進行速率控制。

2?? ER Setting (Explicit Rate Setting),明確速率設置

交換機根據(jù)可用帶寬,在資源管理信元中有一個字段,告訴發(fā)送端可以多大速率發(fā)送數(shù)據(jù).如果經(jīng)過多個交換機,會取一個最小值。

3?? EFCI(Explicit Forward Congestion Indication)明確轉發(fā)擁塞指示

在數(shù)據(jù)信元中的位,如果擁塞則置1。

TCP擁塞控制（重要）

對于TCP中的擁塞，一共有兩種判斷

超時了說明網(wǎng)絡重度擁塞（端到端的延時跟距離有關）

收到三個相同ACK（丟包）說明網(wǎng)絡輕度擁塞——通常采用此方法

探測擁塞

為了探測網(wǎng)絡是否擁塞, 先發(fā)一個段探測一下, 如果這個段的確認信息正確返回，則沒有問題； 下一個RTT開始時發(fā)送兩個段, 如果還沒有問題, 下一個RTT開始時發(fā)送四個段, ……，每個RTT發(fā)送窗口以2的倍數(shù)增加，經(jīng)過若干次探測之后, 此時還沒丟包，發(fā)送窗口不能再x2, 每個RTT開始時窗口大小+1 （慢慢地增加）

發(fā)送窗口以2的倍數(shù)增加的過程叫慢啟動, 經(jīng)過若干RTT后+1過程叫做擁塞避免，這兩個結合起來就是TCP的擁塞算法

算法中的重要變量

1?? 從慢啟動到擁塞避免的分界線用一個變量threshold（閾值）表示

2?? Congwin：擁塞窗口大小（擁塞控制時使用的發(fā)送窗口）

TCP慢啟動

慢啟動算法偽代碼表示

初始化：threshold=適當?shù)闹?span id="n5n3t3z"    class="token punctuation">(10、20...不要太大)
初始化：Congwin=1
for(每個確認段)
	Congwin++
until(丟包orCongWin>=threshold)

?? 這里是說沒收到一個對新的報文段的確認后，擁塞窗口就+1，第一輪收到1個確認，第二輪2個，第三輪4個，以此類推，按輪次加倍

TCP擁塞避免

Tahoe 擁塞避免算法偽代碼

/*慢啟動結束*/
while (沒有丟包) {
  每w個段被確認:
      Congwin++/*每個RTT，窗口+1*/
}/*線性增加*/
/*丟包了*/
threshold = Congwin/2
Congwin = 1
進行慢啟動

輕度擁塞也會時發(fā)送窗口變?yōu)?，顯得不太合理

Reno 擁塞避免算法偽代碼

/*慢啟動結束*/
while (沒有丟包) {
  每w個段被確認:
      Congwin++/*每個RTT，窗口+1*/
}/*線性增加*/
/*丟包了*/
threshold = Congwin/2
if(因為超時丟包){/*重度擁塞*/
    Congwin = 1
	進行慢啟動/*回到慢啟動*/
}
if(因為收到三個相同確認段丟包){/*輕度擁塞*/
    Congwin = Congwin /2/*回到while*/
}/*快速恢復*/

問題：如果又收到三個相同的確認段，此時應該再減半

兩個算法的比較

Reno算法的吞吐率更高，震蕩率更小

擁塞避免中的吞吐率

設W是丟包時的窗口大小（以段為單位）

當窗口大小是W，吞吐率=$W/RTT$

當發(fā)生了丟包，窗口大小減少為W/2，吞吐率=$W/2RTT$

平均窗口大小為(W+W/2)/2=0.75W，平均吞吐率=$0.75W/RTT$

如果直到丟包率L，MSS為最大段大小(可要可不要），平均吞吐率為
$$\approx \frac{1.22MSS}{RTT\sqrt{L}}$$

推導過程如下：

在擁塞避免期間，發(fā)送窗口大小從w/2變化到w(段)

第一個RTT，窗口大小=w/2

第二個RTT，窗口大小=w/2+1

第三個RTT，窗口大小=w/2+2

……

當丟包時，窗口大小=w/2+w/2=w

在此期間發(fā)送的段的總數(shù)(包數(shù))
$$\frac{w}{2}(\frac{w}{2}+1)+(1+2+,...+\frac{w}{2})=\frac{3w^2}{8}+\frac{3w}{4}\approx \frac{3w^2}{8}$$
總共丟了一個包，丟包率為
$$L=\frac{8}{3w^2}?w=\sqrt{\frac{8}{3L}}$$
平均吞吐率則為
$$\frac{3}{4}w/RTT=\frac{3}{4RTT}\sqrt{\frac{8}{3L}}\approx \frac{1.22MSS}{RTT\sqrt{L}}$$

算法總結

TCP擁塞避免算法：AIMD：radditive increase, multiplicative decrease

線性增加，指數(shù)減少

每一個RTT增加一次窗口；每次丟包減少為原來窗口大小的1/2

這個算法具有四個特性（也稱為TCP的四個特性）

1?? 有效性：Effectiveness

2?? 收斂性

3?? 公正性：Fairness

如果N個TCP會話共享同一條瓶頸鏈路，則每個會話的鏈路容量應為1/N

沒有絕對的公平

4?? 友好性：Friendliness

如果TCP和UDP用戶共同使用帶寬。如果兩者發(fā)送數(shù)據(jù)的速度>R(路由器最大交換能力),TCP就會將發(fā)送速率降一半，騰出資源給UDP，最終TCP只能發(fā)送一個段，資源幾乎都給了UDP

參考資料

[1] James F.Kurose，Keith W.Ross.Computer Networking—A Top-Down Approach（第6版）.北京：高等教育出版社出版者，2013年。

[2] 西安交通大學Computer Networking2022年春 課程PPT 朱利

[3] 天勤第11版 2023版計算機網(wǎng)絡高分筆記文章來源地址http://www.zghlxwxcb.cn/news/detail-404515.html

到了這里，關于[計算機網(wǎng)絡]第三章——傳輸層的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！