運輸層協(xié)議概述

從通信和信息處理的角度看，運輸層向它上面的應(yīng)用層提供通信服務(wù)，它屬于面向通信部分的最高層，同時也是用戶功能中的最低層。

當(dāng)網(wǎng)絡(luò)的邊緣部分中的兩個主機使用網(wǎng)絡(luò)的核心部分的功能進行端到端的通信時，只有位于網(wǎng)絡(luò)邊緣部分的主機的協(xié)議棧才有運輸層，而網(wǎng)絡(luò)核心部分中的路由器在轉(zhuǎn)發(fā)分組時都只用到下三層的功能。

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

在IP層看來，通信的兩端是兩個主機，IP數(shù)據(jù)報的首部明確的標志了這兩個主機的IP地址。但是兩個主機之間的通信這種說法還不夠清楚，這是因為真正進行通信的實體是在主機中的進程，是兩個進程之間在交換數(shù)據(jù)。從而引出了運輸層，從運輸層的角度看來，通信的真正端點并不是主機而是主機中的進程(端到端的通信)。

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

復(fù)用指的是發(fā)送方不同的應(yīng)用進程都可以使用同一個運輸層協(xié)議傳輸數(shù)據(jù)(當(dāng)然要加上適當(dāng)?shù)氖撞?

分用指的是接收方的運輸層在剝?nèi)笪牡氖撞亢竽軌虬堰@些數(shù)據(jù)正確交付目的應(yīng)用進程

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

運輸層的主要功能

運輸層為應(yīng)用進程之間提供端到端的邏輯通信(但網(wǎng)絡(luò)層是為主機之間提供邏輯通信)

運輸層還要對收到的報文進行差錯檢測。

運輸層需要有兩種不同的運輸協(xié)議，即面向連接的 TCP 和無連接的 UDP

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

運輸層向高層用戶屏蔽了下面網(wǎng)絡(luò)核心的細節(jié)(如網(wǎng)絡(luò)拓撲、所采用的路由選擇協(xié)議等)，它使應(yīng)用進程看見的就是好像在兩個運輸層實體之間有一條端到端的邏輯通信信道。

當(dāng)運輸層采用面向連接的 TCP 協(xié)議時，盡管下面的網(wǎng)絡(luò)是不可靠的(只提供盡最大努力服務(wù))，但這種邏輯通信信道就相當(dāng)于一條全雙工的可靠信道。

當(dāng)運輸層采用無連接的 UDP 協(xié)議時，這種邏輯通信信道是一條不可靠信道。

運輸層的兩個主要協(xié)議

TCP/IP 的運輸層有兩個不同的協(xié)議：

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

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

TCP與UDP

兩個對等運輸實體在通信時傳送的數(shù)據(jù)單位叫作運輸協(xié)議數(shù)據(jù)單元TPDU (Transport Protocol Data Unit)。

TCP 傳送的數(shù)據(jù)單位協(xié)議是 TCP 報文段(segment)

UDP 傳送的數(shù)據(jù)單位協(xié)議是 ** UDP 報文或用戶數(shù)據(jù)報**。

區(qū)別

UDP 在傳送數(shù)據(jù)之前不需要先建立連接。對方的運輸層在收到 UDP 報文后，不需要給出任何確認。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 是一種最有效的工作方式。

TCP 則提供面向連接的服務(wù)。TCP 不提供廣播或多播服務(wù)。由于 TCP 要提供可靠的、面向連接的運輸服務(wù)，因此不可避免地增加了許多的開銷。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多，還要占用許多的處理機資源。

還要強調(diào)兩點

運輸層的 UDP 用戶數(shù)據(jù)報與網(wǎng)際層的IP數(shù)據(jù)報有很大區(qū)別。IP 數(shù)據(jù)報要經(jīng)過互連網(wǎng)中許多路由器的存儲轉(zhuǎn)發(fā)，但 UDP 用戶數(shù)據(jù)報是在運輸層的端到端抽象的邏輯信道中傳送的。

TCP 報文段是在運輸層抽象的端到端邏輯信道中傳送，這種信道是可靠的全雙工信道。但這樣的信道卻不知道究竟經(jīng)過了哪些路由器，而這些路由器也根本不知道上面的運輸層是否建立了 TCP 連接。

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

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

運輸層的端口

運行在計算機中的進程是用進程標識符來標志的。

運行在應(yīng)用層的各種應(yīng)用進程卻不應(yīng)當(dāng)讓計算機操作系統(tǒng)指派它的進程標識符。這是因為在因特網(wǎng)上使用的計算機的操作系統(tǒng)種類很多，而不同的操作系統(tǒng)又使用不同格式的進程標識符。

為了使運行不同操作系統(tǒng)的計算機的應(yīng)用進程能夠互相通信，就必須用統(tǒng)一的方法對 TCP/IP 體系的應(yīng)用進程進行標志。

需要解決的問題

由于進程的創(chuàng)建和撤銷都是動態(tài)的，發(fā)送方幾乎無法識別其他機器上的進程。

有時我們會改換接收報文的進程，但并不需要通知所有發(fā)送方。

我們往往需要利用目的主機提供的功能來識別終點，而不需要知道實現(xiàn)這個功能的進程。

端口號(protocol port number)簡稱為端口(port)

解決這個問題的方法就是在運輸層使用協(xié)議端口號(protocol port number)，或通常簡稱為端口(port)。

雖然通信的終點是應(yīng)用進程，但我們可以把端口想象是通信的終點，因為我們只要把要傳送的報文交到目的主機的某一個合適的目的端口，剩下的工作(即最后交付目的進程)就由 TCP 來完成。

軟件端口與硬件端口

在協(xié)議棧層間的抽象的協(xié)議端口是軟件端口。

路由器或交換機上的端口是硬件端口。

硬件端口是不同硬件設(shè)備進行交互的接口，而軟件端口是應(yīng)用層的各種協(xié)議進程與運輸實體進行層間交互的一種地址。

TCP的端口

端口用一個 16 位端口號進行標志(可允許有65535個不同的端口號)。

端口號只具有本地意義，即端口號只是為了標志本計算機應(yīng)用層中的各進程。在因特網(wǎng)中不同計算機的相同端口號是沒有聯(lián)系的。

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

三類端口

熟知端口(系統(tǒng)端口)，數(shù)值一般為 0 -1023

例如： http = 80，ftp = 21

登記端口號，數(shù)值為1024 - 49151，為沒有熟知端口號的應(yīng)用程序使用的。使用這個范圍的端口號必須在 IANA 登記，以防止重復(fù)。

客戶端口號或短暫端口號，數(shù)值為49152 - 65535，留給客戶進程選擇暫時使用。當(dāng)服務(wù)器進程收到客戶進程的報文時，就知道了客戶進程所使用的動態(tài)端口號。通信結(jié)束后，這個端口號可供其他客戶進程以后使用。

用戶數(shù)據(jù)報UDP

UDP概述

UDP 只在 IP 的數(shù)據(jù)報服務(wù)之上增加了很少一點的功能，即端口的功能和差錯檢測的功能。

雖然 UDP 用戶數(shù)據(jù)報只能提供不可靠的交付，但 UDP 在某些方面有其特殊的優(yōu)點。

UDP的主要特點

UDP 是無連接的，即發(fā)送數(shù)據(jù)之前不需要建立連接。

UDP 使用盡最大努力交付，即不保證可靠交付，同時也不使用擁塞控制。

UDP 是面向報文的。UDP 沒有擁塞控制，很適合多媒體通信的要求。

無擁塞控制就說明網(wǎng)絡(luò)出現(xiàn)的擁塞不會使主機發(fā)送的速率降低。這對某些實時應(yīng)用是很重要的(IP電話，實時視頻會議等)

UDP 支持一對一、一對多、多對一和多對多的交互通信。

UDP 的首部開銷小，只有 8 個字節(jié)。

面向報文的UDP

發(fā)送方 UDP 對應(yīng)用程序交下來的報文，在添加首部后就向下交付 IP 層。UDP 對應(yīng)用層交下來的報文，既不合并，也不拆分，而是保留這些報文的邊界。

應(yīng)用層交給 UDP 多長的報文，UDP 就照樣發(fā)送，即一次發(fā)送一個報文。

接收方 UDP 對 IP 層交上來的 UDP 用戶數(shù)據(jù)報，在去除首部后就原封不動地交付上層的應(yīng)用進程，一次交付一個完整的報文。

應(yīng)用程序必須選擇合適大小的報文。

面向報文的UDP.png

UDP的首部格式

UDP的首部格式.png

源端口 在需要對方回信時選用，不需要時可全用0

目的端口

長度 UDP用戶數(shù)據(jù)報的長度，最小值為8(只由首部)

檢驗和 檢驗UDP用戶數(shù)據(jù)報在傳輸中是否有差錯，有錯就丟棄

UDP基于端口分用

UDP基于端口分用.png

UDP差錯檢驗

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

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

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

計算UDP檢驗和的例子：

UDP檢驗和的例子.png

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

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

TCP最主要的特點

TCP 是面向連接的運輸層協(xié)議

建立與釋放連接

每一條 TCP 連接只能有兩個端點(endpoint)，每一條 TCP 連接只能是點對點的(一對一)

TCP 提供可靠交付的服務(wù)。

無差錯、不重復(fù)、不丟失、并且按序到達

TCP 提供全雙工通信

TCP在兩端設(shè)置了發(fā)送和接收緩存

面向字節(jié)流

這里的流指的是流入到進程或從進程流出的字節(jié)序列，面向字節(jié)流的含義是：雖然應(yīng)用程序和TCP的交互是一次一個數(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個數(shù)據(jù)塊，但接收方的TPC用了4個數(shù)據(jù)塊就把收到的字節(jié)流交付上層的應(yīng)用程序)。但接收方應(yīng)用程序收到的字節(jié)流必須和發(fā)送方應(yīng)用程序發(fā)送的字節(jié)流完全一樣。

TCP面向流的概念

TCP面向流的概念.png

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

TCP 連接是一條虛連接而不是一條真正的物理連接。

TCP 對應(yīng)用進程一次把多長的報文發(fā)送到TCP 的緩存中是不關(guān)心的。

TCP 根據(jù)對方給出的窗口值和當(dāng)前網(wǎng)絡(luò)擁塞的程度來決定一個報文段應(yīng)包含多少個字節(jié)(UDP 發(fā)送的報文長度是應(yīng)用進程給出的)。

TCP 可把太長的數(shù)據(jù)塊劃分短一些再傳送。TCP 也可等待積累有足夠多的字節(jié)后再構(gòu)成報文段發(fā)送出去。

TCP的連接

TCP 把連接作為最基本的抽象

每一條 TCP 連接有兩個端點

TCP 連接的端點不是主機，不是主機的IP 地址，不是應(yīng)用進程，也不是運輸層的協(xié)議端口。TCP 連接的端點叫做套接字(socket)或插口

端口號拼接到(contatenated with) IP 地址即構(gòu)成了套接字

套接字(socket)

套接字.png

每一條TCP連接唯一地被通信兩端的兩個端點(即兩個套接字)所確定，即：

TCP連接.png

同一個名詞socket有多種不同的意思

應(yīng)用編程接口 API 稱為 socket API, 簡稱為 socket。

socket API 中使用的一個函數(shù)名也叫作 socket。

調(diào)用 socket 函數(shù)的端點稱為 socket。

調(diào)用 socket 函數(shù)時其返回值稱為 socket 描述符，可簡稱為 socket。

在操作系統(tǒng)內(nèi)核中連網(wǎng)協(xié)議的 Berkeley 實現(xiàn)，稱為 socket 實現(xiàn)。

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

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

可靠傳輸有以下兩個特點

傳輸信道不產(chǎn)生差錯

不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù)，接收方總是來得及處理收到的數(shù)據(jù)

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

停止等待協(xié)議

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

在發(fā)送完一個分組后，必須暫時保留已發(fā)送的分組的副本

為發(fā)生超時重傳而使用，只有收到相應(yīng)的確認報文時才能清除暫時保存的副本

分組和確認分組都必須進行編號

這樣才能明確是哪一個發(fā)送出去的分組收到了確認，而哪一個分組還沒收到確認

超時計時器的重傳時間應(yīng)當(dāng)比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些

確認丟失和確認遲到

確認丟失和確認遲到.png

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

使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網(wǎng)絡(luò)上實現(xiàn)可靠的通信

這種可靠傳輸協(xié)議常稱為自動重傳請求ARQ (Automatic Repeat reQuest)

ARQ 表明重傳的請求是自動進行的。接收方不需要請求發(fā)送方重傳某個出錯的分組

信道利用率

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

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

信道利用率.png

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

信道利用率公式.png

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

流水線傳輸.png

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

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

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

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

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

詳細可以見P201

累計確認

接收方一般采用累積確認的方式。即不必對收到的分組逐個發(fā)送確認，而是對按序到達的最后一個分組發(fā)送確認，這樣就表示：到這個分組為止的所有分組都已正確收到了。

累積確認有的優(yōu)點是：容易實現(xiàn)，即使確認丟失也不必重傳。缺點是：不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。

Go - back - N(回退N)

如果發(fā)送方發(fā)送了前 5 個分組，而中間的第 3 個分組丟失了。這時接收方只能對前兩個分組發(fā)出確認。發(fā)送方無法知道后面三個分組的下落，而只好把后面的三個分組都再重傳一次。

這就叫做 Go-back-N(回退 N)，表示需要再退回來重傳已發(fā)送過的 N 個分組。

可見當(dāng)通信線路質(zhì)量不好時，連續(xù) ARQ 協(xié)議會帶來負面的影響。

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

TCP 連接的每一端都必須設(shè)有兩個窗口——一個發(fā)送窗口和一個接收窗口。

TCP 的可靠傳輸機制用字節(jié)的序號進行控制。TCP 所有的確認都是基于序號而不是基于報文段。

TCP 兩端的四個窗口經(jīng)常處于動態(tài)變化之中。

TCP連接的往返時間 RTT 也不是固定不變的。需要使用特定的算法估算較為合理的重傳時間。

TCP報文段的首部格式

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

TCP報文段的首部格式.png

源端口和目的端口字段——各占 2 字節(jié)。端口是運輸層與應(yīng)用層的服務(wù)接口。運輸層的復(fù)用和分用功能都要通過端口才能實現(xiàn)。

序號字段——占 4 字節(jié)。TCP 連接中傳送的數(shù)據(jù)流中的每一個字節(jié)都編上一個序號。序號字段的值則指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號。(如果不理解，可以看P202)

確認號字段——占 4 字節(jié)，是期望收到對方的下一個報文段的數(shù)據(jù)的第一個字節(jié)的序號。例如，B正確收到了A發(fā)送過來的一個報文段，其序號字段值是501，而數(shù)據(jù)長度是200字節(jié)(序號501 - 700)，這表明B正確收到了A發(fā)送的到序號700為止的數(shù)據(jù)，因此，B期望收到A的下一個數(shù)據(jù)序號為701，于是B在發(fā)送給A的確認報文段中把確認號置位701。總之，若確認號為N，則表明到N-1為止的所有數(shù)據(jù)都已正確收到。

數(shù)據(jù)偏移(即首部長度)——占 4 位，它指出 TCP 報文段的數(shù)據(jù)起始處距離 TCP 報文段的起始處有多遠。“數(shù)據(jù)偏移”的單位是 32 位字(以 4 字節(jié)為計算單位)。

保留字段——占 6 位，保留為今后使用，但目前應(yīng)置為 0

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

確認 ACK —— 只有當(dāng) ACK = 1 時確認號字段才有效。當(dāng) ACK = 0 時，確認號無效。TCP規(guī)定，在建立連接后所有傳送的報文段都必須把ACK置1

推送 PSH (PuSH) —— 接收 TCP 收到 PSH = 1 的報文段，就盡快地交付接收應(yīng)用進程，而不再等到整個緩存都填滿了后再向上交付。

復(fù)位 RST (ReSeT) —— 當(dāng) RST = 1 時，表明 TCP 連接中出現(xiàn)嚴重差錯(如由于主機崩潰或其他原因)，必須釋放連接，然后再重新建立運輸連接。

同步 SYN —— 在連接建立時用來同步序號，當(dāng)SYN = 1而ACK = 0時，表明這是一個連接請求報文。對方若同意建立連接，則應(yīng)在響應(yīng)的報文段中使SYN = 1和ACK = 1。所以，SYN = 1 表示這是一個連接請求或連接接受報文。

終止 FIN (FINis) —— 用來釋放一個連接。FIN = 1 表明此報文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢，并要求釋放運輸連接。

窗口字段 —— 占 2 字節(jié)，窗口值是[0,2^16 -1]之間的整數(shù)。窗口指的是發(fā)送本報文段的一方的接收窗口(而不是自己的發(fā)送窗口)。窗口值告訴對方：從本報文段首部中的確認號算起，接收方目前允許對方發(fā)送的數(shù)據(jù)量。之所以要有這個限制，是因為接收方的數(shù)據(jù)緩存空間是有限的?？傊翱谥底鳛榻邮辗阶尠l(fā)送方設(shè)置其發(fā)送窗口的依據(jù)。例如。設(shè)確認號是701，窗口字段是1000.這就表明，從701號算起，發(fā)送此報文段的一方還有接收1000個字節(jié)數(shù)據(jù)(字節(jié)序號701-1700)的接收緩存空間?？傊?#xff0c;窗口字段指出了現(xiàn)在允許對方發(fā)送的數(shù)據(jù)量。窗口值是經(jīng)常在動態(tài)變化著

檢驗和 —— 占 2 字節(jié)。檢驗和字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分。與UDP一樣在計算檢驗和時，要在 TCP 報文段的前面加上 12 字節(jié)的偽首部。不同點可以見P204

緊急指針字段 —— 占 16 位，僅在URG = 1時才有意義，它指出在本報文段中緊急數(shù)據(jù)共有多少個字節(jié)(緊急數(shù)據(jù)放在本報文段數(shù)據(jù)的最前面，因此緊急指針指出了緊急數(shù)據(jù)的末尾在報文段中的位置)。

選項字段 —— 長度可變。TCP 最初只規(guī)定了一種選項，即最大報文段長度 MSS。MSS 告訴對方 TCP：“我的緩存所能接收的報文段的數(shù)據(jù)字段的最大長度是 MSS 個字節(jié)。” MSS (Maximum Segment Size)是 TCP 報文段中的數(shù)據(jù)字段的最大長度。數(shù)據(jù)字段加上 TCP 首部才等于整個的 TCP 報文段。

其他選項

窗口擴大選項 ——占 3 字節(jié)，其中有一個字節(jié)表示移位值 S。新的窗口值等于TCP 首部中的窗口位數(shù)增大到(16 + S)，相當(dāng)于把窗口值向左移動 S 位后獲得實際的窗口大小。

時間戳選項——占10 字節(jié)，其中最主要的字段時間戳值字段(4 字節(jié))和時間戳回送回答字段(4 字節(jié))。

選擇確認選項

選項詳解請見P205

填充字段 —— 這是為了使整個首部長度是** 4 字節(jié)**的整數(shù)倍。

TCP可靠傳輸?shù)膶崿F(xiàn)

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

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

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

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

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

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

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

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

發(fā)送/接收緩存

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

發(fā)送緩存

發(fā)送緩存.png

接收緩存

接收緩存.png

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

發(fā)送緩存用來暫時存放：

發(fā)送應(yīng)用程序傳送給發(fā)送方 TCP 準備發(fā)送的數(shù)據(jù)；

TCP 已發(fā)送出但尚未收到確認的數(shù)據(jù)。

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

接收緩存用來暫時存放：

按序到達的、但尚未被接收應(yīng)用程序讀取的數(shù)據(jù)；

不按序到達的數(shù)據(jù)。

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

需要強調(diào)三點

A 的發(fā)送窗口并不總是和 B 的接收窗口一樣大(因為有一定的時間滯后)。

TCP 標準沒有規(guī)定對不按序到達的數(shù)據(jù)應(yīng)如何處理。通常是先臨時存放在接收窗口中，等到字節(jié)流中所缺少的字節(jié)收到后，再按序交付上層的應(yīng)用進程。

TCP 要求接收方必須有累積確認的功能，這樣可以減小傳輸開銷。

超時重傳時間的選擇

重傳機制是 TCP 中最重要和最復(fù)雜的問題之一。

TCP 每發(fā)送一個報文段，就對這個報文段設(shè)置一次計時器。只要計時器設(shè)置的重傳時間到但還沒有收到確認，就要重傳這一報文段。

往返時延的方差很大

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

往返時延的方差很大.png

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

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

TCP 保留了 RTT 的一個加權(quán)平均往返時間 RTTs(這又稱為平滑(smooth)的往返時間，因為是加權(quán)平均，所以是平滑的)。

第一次測量到 RTT 樣本時，RTTS 值就取為所測量到的 RTT 樣本值。以后每測量到一個新的 RTT 樣本，就按下式重新計算一次 RTTS：

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

式中，0=

RFC 2988 推薦的 a 值為 1/8，即 0.125。

超時重傳時間RTO

顯然，RTO 應(yīng)略大于上面得出的加權(quán)平均往返時間 RTTs

RFC 2988 建議使用下式計算 RTO：

RTO.png

RTTD 是 RTT 的偏差的加權(quán)平均值，他與RTTs和新的RTT樣本之差有關(guān)。

RFC 2988 建議這樣計算 RTTD。第一次測量時，RTTD 值取為測量到的 RTT 樣本值的一半。在以后的測量中，則使用下式計算加權(quán)平均的 RTTD：

RTTD .png

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

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

TCP 報文段 1 沒有收到確認。重傳(即報文段 2)后，收到了確認報文段 ACK。

如何判定此確認報文段是對原來的報文段 1 的確認，還是對重傳的報文段 2 的確認？

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

Karn算法

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

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

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

修正的Karn算法

報文段每重傳一次，就把 RTO 增大一些：

修正的Karn算法.png

系數(shù) γ 的典型值是 2 。

當(dāng)不再發(fā)生報文段的重傳時，才根據(jù)報文段的往返時延更新平均往返時延 RTT 和超時重傳時間 RTO 的數(shù)值。

實踐證明，這種策略較為合理。

選擇確認SACK(selective ACK)

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

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

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

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

RFC 2018的規(guī)定

TCP首部并沒有哪個字段能提供上述這些字節(jié)塊的邊界信息。如果要使用選擇確認，那么在建立 TCP 連接時，就要在 TCP 首部的選項中加上“允許 SACK”的選項，而雙方必須都事先商定好。

如果使用選擇確認，那么原來首部中的“確認號字段”的用法仍然不變。只是以后在 TCP 報文段的首部中都增加了 SACK 選項，以便報告收到的不連續(xù)的字節(jié)塊的邊界。

由于首部選項的長度最多只有 40 字節(jié)，而指明一個邊界就要用掉 4 字節(jié)，因此在選項中最多只能指明 4 個字節(jié)塊的邊界信息。

詳見P211

TCP流量控制

利用滑動窗口實現(xiàn)流量控制

一般說來，我們總是希望數(shù)據(jù)傳輸?shù)酶煲恍?。但如果發(fā)送方把數(shù)據(jù)發(fā)送得過快，

接收方就可能來不及接收，這就會造成數(shù)據(jù)的丟失。

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

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

流量控制舉例

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

流量控制舉例.png

接收方的主機B一共進行了3次流量控制(藍線)

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

持續(xù)計時器(persistence timer)

TCP 為每一個連接設(shè)有一個持續(xù)計時器

只要 TCP 連接的一方收到對方的零窗口通知，就啟動持續(xù)計時器。

若持續(xù)計時器設(shè)置的時間到期，就發(fā)送一個零窗口探測報文段(僅攜帶 1 字節(jié)的數(shù)據(jù))，而對方就在確認這個探測報文段時給出了現(xiàn)在的窗口值。

若窗口仍然是零，則收到這個報文段的一方就重新設(shè)置持續(xù)計時器。

若窗口不是零，則死鎖的僵局就可以打破了。

必須考慮傳輸效率

應(yīng)用進程把數(shù)據(jù)傳送到TCP發(fā)送緩存后，剩下的發(fā)送任務(wù)就由TCP來控制了。可以用不同的機制來控制 TCP 報文段的發(fā)送時機:

第一種機制是 TCP 維持一個變量，它等于最大報文段長度 MSS。只要緩存中存放的數(shù)據(jù)達到 MSS 字節(jié)時，就組裝成一個 TCP 報文段發(fā)送出去。

第二種機制是由發(fā)送方的應(yīng)用進程指明要求發(fā)送報文段，即 TCP 支持的推送(push)操作。

第三種機制是發(fā)送方的一個計時器期限到了，這時就把當(dāng)前已有的緩存數(shù)據(jù)裝入報文段(但長度不能超過 MSS)發(fā)送出去。

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

TCP的擁塞控制

擁塞控制的一般原理

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

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

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

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

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

擁塞控制所要做的都有一個前提，就是網(wǎng)絡(luò)能夠承受現(xiàn)有的網(wǎng)絡(luò)負荷。

擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網(wǎng)絡(luò)傳輸性能有關(guān)的所有因素。

流量控制往往指在給定的發(fā)送端和接收端之間的點對點通信量的控制。

流量控制所要做的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。

擁塞控制所起的作用

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

擁塞控制所起的作用.png

擁塞控制的一般原理

擁塞控制是很難設(shè)計的，因為它是一個動態(tài)的(而不是靜態(tài)的)問題。

當(dāng)前網(wǎng)絡(luò)正朝著高速化的方向發(fā)展，這很容易出現(xiàn)緩存不夠大而造成分組的丟失。但分組的丟失是網(wǎng)絡(luò)發(fā)生擁塞的征兆而不是原因。

在許多情況下，甚至正是擁塞控制本身成為引起網(wǎng)絡(luò)性能惡化甚至發(fā)生死鎖的原因。這點應(yīng)特別引起重視。

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

開環(huán)控制方法就是在設(shè)計網(wǎng)絡(luò)時事先將有關(guān)發(fā)生擁塞的因素考慮周到，力求網(wǎng)絡(luò)在工作時不產(chǎn)生擁塞，但是系統(tǒng)運行起來就不再中途更正了。

閉環(huán)控制是基于反饋環(huán)路的概念。屬于閉環(huán)控制的有以下幾種措施：

監(jiān)測網(wǎng)絡(luò)系統(tǒng)以便檢測到擁塞在何時、何處發(fā)生。

將擁塞發(fā)生的信息傳送到可采取行動的地方。

調(diào)整網(wǎng)絡(luò)系統(tǒng)的運行以解決出現(xiàn)的問題。

檢測擁塞的指標

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

幾種擁塞控制方法

慢開始和擁塞避免

發(fā)送方維持一個叫做擁塞窗口 cwnd (congestion window)的狀態(tài)變量。擁塞窗口的大小取決于網(wǎng)絡(luò)的擁塞程度，并且動態(tài)地在變化。發(fā)送方讓自己的發(fā)送窗口等于擁塞窗口。如再考慮到接收方的接收能力，則發(fā)送窗口還可能小于擁塞窗口。

發(fā)送方控制擁塞窗口的原則是：只要網(wǎng)絡(luò)沒有出現(xiàn)擁塞，擁塞窗口就再增大一些，以便把更多的分組發(fā)送出去。但只要網(wǎng)絡(luò)出現(xiàn)擁塞，擁塞窗口就減小一些，以減少注入到網(wǎng)絡(luò)中的分組數(shù)。

慢開始算法的原理

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

在主機剛剛開始發(fā)送報文段時可先設(shè)置擁塞窗口 cwnd = 1，即設(shè)置為一個最大報文段 MSS 的數(shù)值。

在每收到一個對新的報文段的確認后，將擁塞窗口加 1，即增加一個 MSS 的數(shù)值。

用這樣的方法逐步增大發(fā)送端的擁塞窗口 cwnd，可以使分組注入到網(wǎng)絡(luò)的速率更加合理。

傳播輪次(transmission round)

使用慢開始算法后，每經(jīng)過一個傳輸輪次，擁塞窗口 cwnd 就加倍。

一個傳輸輪次所經(jīng)歷的時間其實就是往返時間 RTT。

“傳輸輪次”更加強調(diào)：把擁塞窗口 cwnd 所允許發(fā)送的報文段都連續(xù)發(fā)送出去，并收到了對已發(fā)送的最后一個字節(jié)的確認。

例如，擁塞窗口 cwnd = 4，這時的往返時間 RTT 就是發(fā)送方連續(xù)發(fā)送 4 個報文段，并收到這 4 個報文段的確認，總共經(jīng)歷的時間。

慢開始算法.png

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

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

當(dāng) cwnd < ssthresh 時，使用慢開始算法。

當(dāng) cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。

當(dāng) cwnd = ssthresh 時，既可使用慢開始算法，也可使用擁塞避免算法。

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

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

無論在慢開始階段還是在擁塞避免階段，只要發(fā)送方判斷網(wǎng)絡(luò)出現(xiàn)擁塞(其根據(jù)就是沒有按時收到確認)，就要把慢開始門限 ssthresh 設(shè)置為出現(xiàn)擁塞時的發(fā)送方窗口值的一半(但不能小于2)。

然后把擁塞窗口 cwnd 重新設(shè)置為 1，執(zhí)行慢開始算法。

這樣做的目的就是要迅速減少主機發(fā)送到網(wǎng)絡(luò)中的分組數(shù)，使得發(fā)生擁塞的路由器有足夠時間把隊列中積壓的分組處理完畢。

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

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

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

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

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

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

在執(zhí)行慢開始算法時，擁塞窗口 cwnd 的初始值為 1，發(fā)送第一個報文段 M0。

發(fā)送端每收到一個確認 ，就把 cwnd 加 1。于是發(fā)送端可以接著發(fā)送 M1 和 M2 兩個報文段。

接收端共發(fā)回兩個確認。發(fā)送端每收到一個對新報文段的確認，就把發(fā)送端的 cwnd 加 1?，F(xiàn)在 cwnd 從 2 增大到 4，并可接著發(fā)送后面的 4 個報文段。

發(fā)送端每收到一個對新報文段的確認，就把發(fā)送端的擁塞窗口加 1，因此擁塞窗口 cwnd 隨著傳輸輪次按指數(shù)規(guī)律增長。

當(dāng)擁塞窗口 cwnd 增長到慢開始門限值 ssthresh 時(即當(dāng) cwnd = 16 時)，就改為執(zhí)行擁塞避免算法，擁塞窗口按線性規(guī)律增長。

假定擁塞窗口的數(shù)值增長到 24 時，網(wǎng)絡(luò)出現(xiàn)超時，表明網(wǎng)絡(luò)擁塞了。

更新后的 ssthresh 值變?yōu)?12(即發(fā)送窗口數(shù)值 24 的一半)，擁塞窗口再重新設(shè)置為 1，并執(zhí)行慢開始算法。

當(dāng) cwnd = 12 時改為執(zhí)行擁塞避免算法，擁塞窗口按按線性規(guī)律增長，每經(jīng)過一個往返時延就增加一個 MSS 的大小。

乘法減小(multiplicative decrease)

“乘法減小“是指不論在慢開始階段還是擁塞避免階段，只要出現(xiàn)一次超時(即出現(xiàn)一次網(wǎng)絡(luò)擁塞)，就把慢開始門限值 ssthresh 設(shè)置為當(dāng)前的擁塞窗口值乘以 0.5。

當(dāng)網(wǎng)絡(luò)頻繁出現(xiàn)擁塞時，ssthresh 值就下降得很快，以大大減少注入到網(wǎng)絡(luò)中的分組數(shù)。

加法增大(addictive increase)

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

要指出

“擁塞避免”并非指完全能夠避免了擁塞。利用以上的措施要完全避免網(wǎng)絡(luò)擁塞還是不可能的。

“擁塞避免”是說在擁塞避免階段把擁塞窗口控制為按線性規(guī)律增長，使網(wǎng)絡(luò)比較不容易出現(xiàn)擁塞。

快重傳和快恢復(fù)

快重傳

快重傳算法首先要求接收方每收到一個失序的報文段后就立即發(fā)出重復(fù)確認。這樣做可以讓發(fā)送方及早知道有報文段沒有到達接收方。

發(fā)送方只要一連收到三個重復(fù)確認就應(yīng)當(dāng)立即重傳對方尚未收到的報文段。

不難看出，快重傳并非取消重傳計時器，而是在某些情況下可更早地重傳丟失的報文段。

快重傳舉例.png

對上圖的解釋請見P220

快恢復(fù)算法

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

當(dāng)發(fā)送端收到連續(xù)三個重復(fù)的確認時，就執(zhí)行“乘法減小”算法，把慢開始門限 ssthresh 減半。但接下去不執(zhí)行慢開始算法。

由于發(fā)送方現(xiàn)在認為網(wǎng)絡(luò)很可能沒有發(fā)生擁塞，因此現(xiàn)在不執(zhí)行慢開始算法，即擁塞窗口 cwnd 現(xiàn)在不設(shè)置為 1，而是設(shè)置為慢開始門限 ssthresh 減半后的數(shù)值，然后開始執(zhí)行擁塞避免算法(“加法增大”)，使擁塞窗口緩慢地線性增大。

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

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

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

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

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

當(dāng) rwnd < cwnd 時，是接收方的接收能力限制發(fā)送窗口的最大值。

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

隨機早期檢測RED(Random Early Detection)

背景見P221

使路由器的隊列維持兩個參數(shù)，即隊列長度最小門限 THmin 和最大門限 THmax。

RED 對每一個到達的數(shù)據(jù)報都先計算平均隊列長度 LAV。

若平均隊列長度小于最小門限 THmin，則將新到達的數(shù)據(jù)報放入隊列進行排隊。

若平均隊列長度超過最大門限 THmax，則將新到達的數(shù)據(jù)報丟棄。

若平均隊列長度在最小門限 THmin 和最大門限THmax 之間，則按照某一概率 p 將新到達的數(shù)據(jù)報丟棄。

隨機早期檢測RED.png

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

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

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

當(dāng) LAV > Thmin 時，丟棄概率 p = 0。

當(dāng) LAV < Thmax 時，丟棄概率 p = 1。

當(dāng) THmin < LAV < THmax時， 0 < p < 1 。

例如，按線性規(guī)律變化，從 0 變到 pmax

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

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

下圖也說明了這一點

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

平均隊列長度以及p的計算

見P223

TCP運輸連接管理

運輸連接的三個階段

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

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

要使每一方能夠確知對方的存在。

要允許雙方協(xié)商一些參數(shù)(如最大報文段長度，最大窗口大小，服務(wù)質(zhì)量等)。

能夠?qū)\輸實體資源(如緩存大小，連接表中的項目等)進行分配。

客戶 - 服務(wù)器方式

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

TCP的連接建立(三次握手)

三次握手.png

本節(jié)在P225

B的TCP服務(wù)器進程先創(chuàng)建傳輸控制塊TCB(transmission control block，存儲了每一個連接中的一些重要信息：TCP連接表，到發(fā)送和接收緩存的指針，到重傳隊列的指針，當(dāng)前的發(fā)送和接收序號等等)，準備接受客戶進程的連接請求。然后服務(wù)器進程就處于LISTEN(收聽)狀態(tài)，等待客戶的連接請求。如果有就作出響應(yīng)

A的TCP客戶進程也是首先創(chuàng)建傳輸控制塊TCB，然后A 的 TCP 向 B 發(fā)出連接請求報文段，其首部中的同步位 SYN = 1，并選擇序號 seq = x，表明傳送數(shù)據(jù)時的第一個數(shù)據(jù)字節(jié)的序號是 x。

B 的 TCP 收到連接請求報文段后，如同意，則發(fā)回確認。B 在確認報文段中應(yīng)使 SYN = 1，使 ACK = 1，其確認號ack = x + 1，自己選擇的序號 seq = y。

A 收到此報文段后向 B 給出確認，其 ACK = 1，確認號 ack = y + 1。A 的 TCP 通知上層應(yīng)用進程，連接已經(jīng)建立。

B 的 TCP 收到主機 A 的確認后，也通知其上層應(yīng)用進程：TCP 連接已經(jīng)建立。

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

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

“三次”握手的原因

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

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

考慮一種正常情況。A發(fā)送了連接請求，但是因為連接請求報文丟失而未收到確認。于是A再重傳一次連接請求。后來收到了確認，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接。A共發(fā)送了兩個連接請求報文段，其中第一個丟失，第二個到達了B。沒有“已失效的連接請求報文段 ”

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

TCP連接的釋放(四次握手)

TCP連接的釋放.png

數(shù)據(jù)傳輸結(jié)束后，通信的雙方都可釋放連接。現(xiàn)在 A 的應(yīng)用進程先向其 TCP 發(fā)出連接釋放報文段，并停止再發(fā)送數(shù)據(jù)，主動關(guān)閉 TCP連接。A 把連接釋放報文段首部的 FIN = 1，其序號seq = u(等于A前面?zhèn)鬏數(shù)淖詈笠粋€字節(jié)號+1)，等待 B 的確認。

B 發(fā)出確認，確認號 ack = u + 1，而這個報文段自己的序號 seq = v(等于B前面?zhèn)鬏數(shù)淖詈笠粋€字節(jié)號+1)。TCP 服務(wù)器進程通知高層應(yīng)用進程。從 A 到 B 這個方向的連接就釋放了，TCP 連接處于半關(guān)閉狀態(tài)。B 若發(fā)送數(shù)據(jù)，A 仍要接收。

若 B 已經(jīng)沒有要向 A 發(fā)送的數(shù)據(jù)，其應(yīng)用進程就通知 TCP 釋放連接，序號為seq = w(在半關(guān)閉狀態(tài)可能又發(fā)送了一些數(shù)據(jù)) ack = u+1(B還必須記錄上次已發(fā)送的確認號)。

A 收到連接釋放報文段后，必須發(fā)出確認。在確認報文段中 ACK = 1，確認號 ack = w + 1，自己的序號 seq = u + 1。

TCP 連接必須經(jīng)過時間 2MSL (最長報文壽命)后才真正釋放掉。

A必須等待2MSL的時間

第一，為了保證 A 發(fā)送的最后一個 ACK 報文段能夠到達 B。

這個報文段有可能丟失，因為使得處于LAST-ACK狀態(tài)的B收不到對已發(fā)送的FIN+ACK報文段的確認。B會超時重傳這個FIN+ACK報文段，而A就能在這2MSL時間內(nèi)收到這個重傳的FIN+ACK報文段，接著A重傳一次確認，重新啟動2MSL計時器直到雙方都關(guān)閉。

第二，防止 “已失效的連接請求報文段”出現(xiàn)在本連接中。A 在發(fā)送完最后一個 ACK 報文段后，再經(jīng)過時間 2MSL，就可以使本連接持續(xù)的時間內(nèi)所產(chǎn)生的所有報文段，都從網(wǎng)絡(luò)中消失。這樣就可以使下一個新的連接中不會出現(xiàn)這種舊的連接請求報文段。

除時間等待計時器外，TCP還設(shè)有一個保活計時器，設(shè)想有這樣的情況：客戶已主動與服務(wù)器建立了TCP連接。但后來客戶端的主機出現(xiàn)了故障。顯然，服務(wù)器以后就不再收到客戶發(fā)來的數(shù)據(jù)，因此，應(yīng)當(dāng)有措施使得服務(wù)器不會白白等下去。這就是使用?；钇?#xff0c;時間設(shè)置通常為兩小時，服務(wù)器每收到一次客戶的數(shù)據(jù)，就重新設(shè)置?；钇鳌Ｈ魞尚r每收到客戶的數(shù)據(jù)，服務(wù)器就發(fā)送一個嗅探報文段，以后則每隔75分鐘發(fā)送一次，若一連發(fā)送10個嗅探報文后客戶端仍無響應(yīng)，服務(wù)器就認定客戶端發(fā)送故障，就關(guān)閉這個連接。

TCP有限狀態(tài)機

TCP 有限狀態(tài)機的圖中每一個方框都是 TCP 可能具有的狀態(tài)。

每個方框中的大寫英文字符串是 TCP 標準所使用的 TCP 連接狀態(tài)名。狀態(tài)之間的箭頭表示可能發(fā)生的狀態(tài)變遷。

箭頭旁邊的字，表明引起這種變遷的原因，或表明發(fā)生狀態(tài)變遷后又出現(xiàn)什么動作。

圖中有三種不同的箭頭。

粗實線箭頭表示對客戶進程的正常變遷。

粗虛線箭頭表示對服務(wù)器進程的正常變遷。

另一種細線箭頭表示異常變遷。

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

總結(jié)

以上是生活随笔為你收集整理的计算机网络运输层的概述,计算机网络_运输层的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。