運輸層

注:本文的圖片均來源于謝希仁《計算機網(wǎng)絡》第六版的課件PPT

1.重點內(nèi)容

(1)運輸層為相互通信的應用進程提供邏輯通信

(2)端口和套接字的意義

(3)無連接的UDP的特點

(4)面向連接的TCP的特點

(5)在不可靠的網(wǎng)絡上實現(xiàn)可靠傳輸?shù)墓ぷ髟砝狗伲V沟却齾f(xié)議和ARQ協(xié)議

(6)TCP的滑動窗口罢荡、流量控制丢烘、擁塞控制和連接管理

2.運輸層協(xié)議概述

在之前我們說過了新锈,網(wǎng)絡層是為在網(wǎng)絡中的主機之間提供邏輯通信稿湿,但嚴格的說起來主機之間的通信其實是主機中的應用進程互相通信。而我們這一部分要講的運輸層,就是為應用進程之間提供端到端的邏輯通信。此外疼约,運輸層還要對收到的報文進行差錯檢測,對比網(wǎng)絡層中蝙泼,IP數(shù)據(jù)報中只對首部進行檢驗程剥,不對數(shù)據(jù)部分進行檢驗。

運輸層向上面的應用層提供通信服務汤踏,是通信部分的最高層织鲸,同時也是用戶功能中的最低層哨免。它向高層用戶評比了下面網(wǎng)絡核心的細節(jié),使應用進程看見的好像就是在兩個運輸層實體之間有一條端到端的邏輯通信信道昙沦。

運輸層協(xié)議與網(wǎng)絡層協(xié)議的區(qū)別如圖1所示。

圖1

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

(1)用戶數(shù)據(jù)報協(xié)議UDP载荔,通信時傳輸?shù)臄?shù)據(jù)單位叫做UDP用戶數(shù)據(jù)報

(2)傳輸控制協(xié)議TCP盾饮,傳輸?shù)臄?shù)據(jù)單位叫做TCP報文段

TCP:提供面向連接的服務。傳輸數(shù)據(jù)之前需要建立連接懒熙,傳輸結(jié)束需要釋放連接丘损。盡管下面的網(wǎng)絡是不可靠的,但是使用TCP協(xié)議使得這種邏輯信道相當于是一條全雙工的可靠信道工扎。TCP不提供廣播或多播服務徘钥。

UDP:無連接的協(xié)議。在傳送數(shù)據(jù)之前不需要建立連接肢娘,目的主機收到UDP報文后也不需要給出任何確認呈础。使用UDP協(xié)議的邏輯信道仍然是一條不可靠信道。UDP支持一對一橱健,一對多而钞,多對一,多對多通信拘荡。

應用層協(xié)議主要使用的運輸層協(xié)議:

TCP:SMTP臼节,TELNET,HTTP珊皿,F(xiàn)TP

UDP:DNS网缝,TFTP,RIP蟋定,DHCP粉臊,SNMP,NFS溢吻,IGMP

運輸層在從IP層收到數(shù)據(jù)之后维费,要將數(shù)據(jù)交給指定的應用進程。但是要怎么交給指定的應用進程呢促王?在計算機中犀盟,進程的創(chuàng)建和撤銷都是動態(tài)的,發(fā)送方幾乎無法識別目的機器上的進程蝇狼。另外阅畴,我們往往需要利用目的主機提供的功能來識別重點,而不需要知道實現(xiàn)這個功能的進程迅耘。解決這個問題的辦法就是在運輸層使用協(xié)議端口號贱枣。

雖然监署,在通信過程中,通信的終點是應用進程纽哥,但是我們可以把端口想象成是通信的重點钠乏。在把報文交給目的主機的某一個合適的目的端口后,剩下的工作就由TCP來完成春塌。

端口用一個16位端口號來進行標志晓避。端口號只具有本地意義。

運輸層的端口號有三類:

(1)熟知端口:0~1023

(2)登記端口號:1024~49151只壳,使用這個范圍的端口號必須在IANA登記俏拱,避免重復。

(3)客戶端口號(短暫端口號):49152~65535吼句,留給客戶進程選擇暫時使用锅必。

3.用戶數(shù)據(jù)報協(xié)議UDP

UDP只在IP的數(shù)據(jù)報服務至上增加了很少一點功能,這就是端口的功能和差錯檢測的功能惕艳。雖然UDP提供的是不可靠服務搞隐,但是在某些方面有其特殊的優(yōu)點。

UDP的特點:

(1)UDP是無連接的远搪,即發(fā)送數(shù)據(jù)前不需要建立連接尔许,減少了開銷和發(fā)送數(shù)據(jù)之前的時延。

(2)UDP使用盡最大努力交付终娃,即不保證可靠交付味廊,因此主機不需要維持復雜的連接狀態(tài)表。

(3)UDP是面向報文的棠耕。UDP對應用層交下來的報文余佛,既不合并也不拆分,而是保留這些報文的邊界窍荧。接收方的UDP對IP層交上來的UDP數(shù)據(jù)報辉巡,去除首部后原封不動的交付給應用層。也就是說UDP一次交付一個完整的報文蕊退,由應用程序來選擇合適大小的報文的長度郊楣。

(4)UDP沒有擁塞控制。網(wǎng)絡的擁塞不會使源主機的發(fā)送速率降低瓤荔,對于某些實時應用很重要净蚤。

(5)UDP支持一對一、一對多输硝、多對一以及多對多的交互通信今瀑。

(6)UDP的首部開銷小,只有8個字節(jié),而TCP的首部有20個字節(jié)橘荠。

用戶數(shù)據(jù)報UDP有兩個字段:數(shù)據(jù)字段和首部字段屿附。

UDP的首部格式:如圖2所示。

圖2

其中偽首部只是在計算檢驗和的時候使用哥童,并不向上交付也不向下傳送挺份。計算UDP檢驗和的例子如圖3所示。

圖3

當運輸層從IP層收到UDP數(shù)據(jù)報時贮懈,就根據(jù)首部中的目的端口压恒,將UDP數(shù)據(jù)報通過相應的端口上交到應用進程,如圖4所示错邦。如果接收方的UDP發(fā)現(xiàn)收到的報文中目的端口號不正確,就丟棄該報文型宙,并有ICMP發(fā)送“端口不可達”差錯報文給發(fā)送方撬呢。

圖4

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

由于TCP協(xié)議比較復雜,先簡要概述一下TCP妆兑,之后再詳細討論TCP的可靠傳輸魂拦、流量控制和擁塞控制等問題。

TCP最主要的特點:

(1)TCP是面向連接的運輸層協(xié)議搁嗓。這就意味著芯勘,應用程序在使用TCP協(xié)議之前,必須建立TCP連接腺逛,使用完TCP協(xié)議之后荷愕,必須釋放TCP連接。

(2)每一條TCP連接只能有兩個端點棍矛,每一條TCP連接只能是點對點的安疗。

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

(4)TCP提供全雙工通信够委。TCP的兩端都設有發(fā)送緩存和接收緩存荐类,用來臨時存放雙向通信時的數(shù)據(jù)。發(fā)送數(shù)據(jù)時茁帽,應用程序在把數(shù)據(jù)傳送給發(fā)送緩存之后就可以做其他事情了玉罐。接收數(shù)據(jù)時,TCP將收到的數(shù)據(jù)放入緩存潘拨,應用程序在合適的時候讀取緩存中的數(shù)據(jù)吊输。

(5)面向字節(jié)流。TCP中的流指的是流入到進程或從進程流出的字節(jié)序列铁追。TCP面向流的概念如圖5所示璧亚。

圖5

圖5表明,TCP并不關(guān)心應用程序一次把多長的報文發(fā)送到TCP的發(fā)送緩存中,而是根據(jù)接收方給出的窗口值和當前網(wǎng)絡擁塞的程度來決定一個報文段應包含多少個字節(jié)癣蟋。如果應用進程傳送到發(fā)送緩存的數(shù)據(jù)塊太長透硝,TCP可以把它劃分短一些再傳送,如果太短疯搅,可以等待積累到足夠多的字節(jié)后再構(gòu)成報文段發(fā)送出去濒生。

TCP的連接:

TCP把連接作為最基本的抽象。每一條TCP連接有兩個端點幔欧,這個端點叫做套接字(socket)或插口罪治。套接字由端口號拼接到IP地址組成:

????????????????????????????????????????????????socket=(IP地址:端口號)

每一條TCP連接唯一的被通信兩端的兩個端點所確定:

????????????????????????????????TCP連接::={socket1,socket2}={(IP1:port1),(IP2:port2)}

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

TCP提供的是可靠的交付服務,但是TCP報文需要向下交付給IP層礁蔗,而IP層提供的是盡最大努力服務觉义,不保證可靠性。因此TCP必須采取適當?shù)拇胧﹣肀WC通信的可靠浴井。

理想的傳輸條件:

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

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

然而實際中的網(wǎng)絡并不具備這樣的理想條件磺浙,但可以使用一些可靠的傳輸協(xié)議洪囤,使得傳送出現(xiàn)差錯時讓發(fā)送方重傳出錯的數(shù)據(jù),在接收方來不及處理收到的數(shù)據(jù)時使發(fā)送方降低發(fā)送數(shù)據(jù)的速度撕氧。這樣便能達到可靠通信瘤缩。

停止等待協(xié)議:

停止等待就是每發(fā)送完一個分組就停止發(fā)送,等待對方確認伦泥,收到確認后再發(fā)送下一個分組剥啤。以A為發(fā)送方,B為接收方不脯,僅考慮A向B發(fā)送數(shù)據(jù)铐殃,停止等待協(xié)議有以下三種情況:

(1)無差錯情況

如圖6(a)所示,A在發(fā)送完分組后跨新,等待接收B的確認分組富腊,B在接收到分組后就向A發(fā)送確認分組,A在收到確認分組后再發(fā)送下一個分組域帐。

(2)出現(xiàn)差錯

如圖6(b)所示赘被,分組在傳輸過程中出現(xiàn)差錯。B在接收M1時出現(xiàn)差錯肖揣,丟棄M1民假,什么也不做。A在一定時間后仍未接收到M1的確認分組龙优,認為M1分組丟失羊异,重傳M1分組(超時重傳)。要實現(xiàn)超時重傳,需要設定一個超時計時器野舶。A為每一個已發(fā)送的分組都設置了一個超時計時器易迹,如果在計時到期之前收到了相應確認,就撤銷計時器平道,否則進行超時重傳睹欲。

這里需要注意三點:

(i)A在發(fā)送完一個分組后,必須暫時保留已發(fā)送分組的副本一屋,以備超時重傳使用窘疮。

(ii)分組和確認分組都必須進行編號。

(iii)超時計時器設置的重傳時間應當比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些冀墨。

圖6

(3)確認丟失和確認遲到

如圖7(a)所示闸衫,B接收到M1分組后向A發(fā)送的M1確認分組中途丟失,這時A在計時器到期之前未收到M1分組確認诽嘉,因此超時重傳蔚出。這個時候B端已經(jīng)有M1分組了,直接丟棄重復的M1分組含懊,重傳M1確認分組。

如圖7(b)所示衅胀,B在接收到M1分組后向A發(fā)送的M1確認分組因為某種原因遲到了岔乔,而A在計時器到期之前還是未收到M1分組確認,因此超時重傳滚躯。這個時候B丟棄重復的M1分組雏门,重傳確認分組,A在收到遲到的確認分組之后什么也不做掸掏,直接丟棄重復的確認。

使用這樣的確認和重傳機制丧凤,便可在不可靠的網(wǎng)絡上實現(xiàn)可靠傳輸募闲,將這種可靠傳輸協(xié)議稱為自動重傳請求ARQ

圖7

停止等待協(xié)議的優(yōu)點很明顯:簡單愿待。缺點也很明顯:信道利用率太低浩螺。信道利用率如圖8所示:

因此,信道利用率:????????????????????U=TD/(TD+RTT+TA)

圖8

因此仍侥,為了提供信道利用率要出,發(fā)送方可以不使用低效率的停止等待協(xié)議,而是采用流水線傳輸农渊。流水線傳輸使得發(fā)送方可以連續(xù)發(fā)送多個分組患蹂,不必每發(fā)完一個分組就停下來等待對方確認。如圖9所示:

圖9

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

連續(xù)ARQ協(xié)議的工作原理如圖10所示。這里發(fā)送窗口的意義是位于發(fā)送窗口內(nèi)的5個分組都可以連續(xù)發(fā)送出去传于,而不需要等待對方的確認囱挑。接收方一般采用累積確認的方式,不必對每一個分組發(fā)送確認格了,對按序到達的最后一個分組發(fā)送確認看铆。

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

Go-back-N:表示需要再退回來重傳已發(fā)送的N個分組。

圖10

6.TCP報文段的首部格式

TCP報文段分為首部和數(shù)據(jù)兩部分悄但,TCP的全部功能都體現(xiàn)在它首部中各字段的作用棠隐,TCP報文段首部的前20個字節(jié)是固定的。TCP報文段的格式如圖11所示:

圖11

(1)源端口和目的端口:TCP的分用功能也是通過端口實現(xiàn)的檐嚣。

(2)序號:指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號助泽。

(3)確認號:期望收到對方的下一個報文的第一個數(shù)據(jù)字節(jié)的序號。

(4)數(shù)據(jù)偏移:指出TCP報文段的數(shù)據(jù)起始處距離TCP報文段的起始處有多遠嚎京。

(5)保留:保留為今后使用嗡贺,但目前應置為0。

(6)緊急URG:URG=1時表明緊急指針字段有效鞍帝。告訴系統(tǒng)诫睬,此報文段中有緊急數(shù)據(jù),應當盡快傳送帕涌。

(7)確認ACK:當ACK=1時摄凡,確認號字段才有效。

(8)推送PSH:接收端的TCP在收到PSH=1的報文時蚓曼,盡快交付給接收應用進程亲澡。

(9)復位RST:RST=1時,表明TCP連接中出現(xiàn)嚴重差錯纫版,必須釋放連接床绪,然后再重新建立運輸連接。

(10)同步SYN:SYN=1表示這是一個連接請求或連接接受報文其弊。

(11)終止FIN:用來釋放一個連接会涎。FIN=1時表明此報文段的發(fā)送端的數(shù)據(jù)已發(fā)送完畢,并要求釋放運輸連接瑞凑。

(12)窗口:用來讓對方設置發(fā)送窗口的依據(jù)末秃。

(13)檢驗和:同UDP一樣,計算時需要在TCP報文段的前面加上12字節(jié)的偽首部籽御。

(14)緊急指針:指出本報文段中緊急數(shù)據(jù)共有多少字節(jié)哨毁。

(15)選項:長度可變。最大報文段長度MSS倦踢,窗口擴大選項影斑,時間戳選項,選擇確認選項。

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

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

在講述了可靠傳輸?shù)墓ぷ髟硪约癟CP報文段的首部格式之后,我們接下來就要介紹TCP可靠傳輸?shù)膶崿F(xiàn)绘盟。假定數(shù)據(jù)傳輸只在一個方向傳輸(方便討論問題),即A為發(fā)送方悯仙,B為接收方龄毡。

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

TCP的滑動窗口是以字節(jié)為單位的。假定A收到了B發(fā)來的確認報文段锡垄,其中窗口是20沦零,確認號是31。根據(jù)這兩個數(shù)據(jù)货岭,A構(gòu)造出自己的發(fā)送窗口路操,如圖12所示:

圖12

先來討論A的發(fā)送窗口。發(fā)送窗口表示:在未收到B的確認的情況下千贯,A可以連續(xù)的把窗口內(nèi)的數(shù)據(jù)都發(fā)送出去屯仗。凡是已發(fā)送出去但未收到確認的數(shù)據(jù)都要暫時保留,以備超時重傳時使用搔谴。

發(fā)送窗口的位置由前沿和后沿的位置共同確定魁袜。后沿的變化有兩種:前移(收到了新的確認),不動(未收到新的確認)己沛。前沿通常是向前移動的慌核,但也可能不動距境,這對應著兩種情況:未收到新的確認申尼,對方通知的窗口大小不變;收到了新的確認垫桂,但通知的窗口減小师幕。對于前沿,理論上是可以后移诬滩,但TCP標準強烈不贊成這么做霹粥,因為可能會引發(fā)錯誤。

A發(fā)送數(shù)據(jù)時的示意如圖13所示疼鸟,可以看到后控,描述一個發(fā)送窗口的狀態(tài)需要三個指針:P1,P2空镜,P3浩淘。指針都指向字節(jié)的序號捌朴。

圖13

再來看一下B的接收窗口。B的接收窗口大小是20张抄,到30號為止的數(shù)據(jù)都已經(jīng)發(fā)送給確認并已交付主機砂蔽,因此可不必保留。接收窗口內(nèi)的序號是允許接收的數(shù)據(jù)署惯。B只能對按序到達的數(shù)據(jù)中的最高序號給出確認左驾。

假定B收到了并把序號為31~33的數(shù)據(jù)交付主機,然后B刪除了這些數(shù)據(jù)极谊,接收窗口向前移動3個序號诡右,同時給A發(fā)送確認,確認號是34怀酷,如圖14所示稻爬。未按序到達的數(shù)據(jù)先暫存在接收窗口中。而A在經(jīng)過一段時間后仍未收到B的確認蜕依,那么就會啟動超時重傳桅锄。

圖14

之前說到過應用進程將數(shù)據(jù)傳送到TCP的發(fā)送緩存,從TCP的接收緩存中讀取數(shù)據(jù)样眠。接下來進一步討論發(fā)送緩存和接收緩存友瘤。

發(fā)送緩存和接收緩存:

先來看一下發(fā)送緩存,如圖15所示檐束,發(fā)送緩存用來暫時存放:

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

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

圖15

接下來再看一下接收緩存辫秧,如圖16所示,接收緩存用來暫時存放:

(1)按序到達的被丧、但尚未被應用程序讀取的數(shù)據(jù)

(2)未按序到達的數(shù)據(jù)

圖16

根據(jù)以上的討論盟戏,還應注意以下三點:

(1)在同一時刻,A的發(fā)送窗口并不總是和B的接收窗口一樣大甥桂。

(2)對于未按序到達的數(shù)據(jù)并無明確規(guī)定柿究。通常對未按序到達的數(shù)據(jù)時先暫時存放在接收窗口,等待缺失的字節(jié)收到后黄选,再按序交付上層的應用進程蝇摸。

(3)TCP要求接收方必須有累積確認的功能,這樣可以減小傳輸開銷办陷。

超時重傳時間的選擇:

之前說到貌夕,A在規(guī)定時間內(nèi)未收到B發(fā)來的確認就要啟動超時重傳。重傳時間的選擇是TCP最復雜的問題民镜。

TCP采用一種自適應的算法啡专,記錄一個報文段的發(fā)出時間,以及收到相應確認的時間制圈,兩者之差就是報文段的往返時間RTT们童。TCP保留了RTT的一個加權(quán)平均往返時間RTTS辱揭。

RTTS的計算:第一次測量到RTT樣本時,RTTS值就取為所測量到的RTT樣本值病附,之后的RTTS按照下式進行計算:(a的推薦值為0.125)

????????????????????????????????????????新的RTTS=(1-a)*舊的RTTS + a*新的RTT樣本

超時重傳時間RTO按照下式計算:

????????????????????????????????????????????????????RTO=RTTS + 4*RTTD

RTT的偏差加權(quán)平均值RTTD的計算:第一次測量時问窃,取為RTT樣本值的一半,以后的測量中完沪,按下式進行計算:

????????????????????????????????新的RTTD=(1-b)*舊的RTTD + b*| RTTS - 新的RTT樣本 |

公式雖然簡單域庇,但是實現(xiàn)起來相當復雜,如下圖所示覆积。發(fā)出一個報文段听皿,但未收到確認,于是超時重傳宽档,那么接下來收到的確認是對哪一個報文段的確認呢尉姨?

圖17

針對這個問題,有一種Karn算法:在計算加權(quán)平均RTTS時吗冤,只要報文段重傳了又厉,就不采用其往返時間樣本。但是這種算法會導致超時重傳時間無法更新椎瘟。

于是提出了修正的Karn算法:報文每重傳一次覆致,就把超時重傳時間RTO增大一些,典型做法是取為舊的重傳時間的2倍肺蔚。當不再發(fā)送報文重傳時煌妈,再根據(jù)上述的公式進行計算RTTS和RTO。

選擇確認SACK:

之前說到有一些數(shù)據(jù)未按序到達接收方宣羊,被暫時保存下來了璧诵。那么有沒有辦法只傳送缺少的數(shù)據(jù)而不重傳已經(jīng)正確到達接收方的數(shù)據(jù)呢?選擇確認SACK就是一種可行的辦法仇冯。

下面以一個例子來說明SACK的工作原理之宿。TCP的接收方在接收對方發(fā)過來的數(shù)據(jù)字節(jié)流的序號不連續(xù),形成一些不連續(xù)的字節(jié)快赞枕,如圖18所示澈缺。從圖中看到坪创,和前后字節(jié)不連續(xù)的每一個字節(jié)塊都有兩個邊界炕婶。使用SACK能夠描述這些字節(jié)塊的邊界信息。

如果需要使用SACK莱预,那么在建立TCP時柠掂,就要在首部的選項中加入允許SACK的選項,并且雙方必須事先商定好依沮。由于選項的長度最多只有40字節(jié)涯贞,指明一個邊界需要4字節(jié)枪狂,最多只能指明4個字節(jié)塊的邊界信息。

圖18

8.TCP的流量控制

所謂的流量控制就是讓發(fā)送方的發(fā)送速率不要太快宋渔,要讓接收方有時間接收州疾。

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

以圖19為例,接收方B進行了三次流量控制皇拣,第一次將窗口減小到300严蓖,第二次將窗口減小到100,最后減小到0氧急,也就是不讓發(fā)送方發(fā)送數(shù)據(jù)了颗胡。

如果在B將窗口設為0的一段時間后,再次將窗口設為400吩坝,而這個報文段在傳送過程中丟失了毒姨,那么A就會一直等待B發(fā)送窗口大小的報文,B一直等待A發(fā)送數(shù)據(jù)钉寝。為了解決這個問題弧呐,TCP為每一個連接設置一個持續(xù)計時器。只要TCP連接的一方收到對方的零窗口通知嵌纲,就啟動計時器泉懦,若時間到期還未收到非零窗口通知,就發(fā)送一個零窗口探測報文段疹瘦。而對方在確認這個探測報文段時給出現(xiàn)在的窗口值崩哩。若窗口值仍為零,重置計時器言沐,若不為零邓嘹,死鎖就解開了。

圖19

在TCP傳輸過程中险胰,必須考慮傳輸效率的問題汹押,可以采用不同的機制控制TCP報文段的發(fā)送時機:

(1)TCP維持一個變量,等于最大報文段長度MSS起便,只要緩存中的數(shù)據(jù)達到MSS就組裝成一個TCP報文段發(fā)送出去棚贾。

(2)由發(fā)送方的應用進程指明要求發(fā)送報文段,即PUSH操作榆综。

(3)設置一個計時器妙痹,到期時就把已緩存的數(shù)據(jù)裝入報文段(小于MSS)發(fā)送出去。

9.TCP的擁塞控制

擁塞控制的一般原理:

擁塞:在某段時間內(nèi)鼻疮,對網(wǎng)絡中的某資源需求超過了其最多能提供的可用部分怯伊,網(wǎng)絡性能就會變壞,這時就會產(chǎn)生擁塞判沟。即產(chǎn)生擁塞的條件:

????????????????????????????????????????????對資源需求的總和 > 可用資源

擁塞問題的實質(zhì)往往是整個系統(tǒng)的各個部分不匹配耿芹,只有各部分平衡了崭篡,問題才會得到解決。

擁塞控制:防止過多的數(shù)據(jù)注入到網(wǎng)絡中吧秕,這樣可以使網(wǎng)絡中的路由器或鏈路不過載琉闪。

擁塞控制有一個前提:就是網(wǎng)絡能夠承受現(xiàn)有的網(wǎng)絡負荷。擁塞控制是一個全局性的過程砸彬,涉及到所有主機塘偎、路由器以及與降低網(wǎng)絡傳輸性能有關(guān)的所有因素。

流量控制:往往指點對點通信量的控制拿霉,是個端到端的問題吟秩。

擁塞控制所起的作用如圖20所示。

圖20

擁塞控制是一個動態(tài)的問題绽淘,很難設計涵防,有時甚至正是擁塞控制機制本身成為引起網(wǎng)絡性能惡化甚至發(fā)生死鎖的原因。從控制理論的角度來看沪铭,擁塞控制可以分為開環(huán)控制和閉環(huán)控制壮池。

開環(huán)控制:在設計網(wǎng)絡時事先將有關(guān)發(fā)生擁塞的因素考慮周到,力求在工作時不發(fā)生擁塞杀怠。

閉環(huán)控制:基于反饋回路的概念椰憋,有以下幾種措施:

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

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

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

幾種擁塞控制方法

假定數(shù)據(jù)時單方向傳送,接收方有足夠大的緩存空間赔退。

慢開始和擁塞避免

發(fā)送方維持一個叫擁塞窗口cwnd的狀態(tài)變量橙依,cwnd取決于網(wǎng)絡的擁塞程度。發(fā)送方控制擁塞窗口的原則是:只要網(wǎng)絡沒有出現(xiàn)擁塞硕旗,cwnd就再增大一些窗骑,如果網(wǎng)絡出現(xiàn)擁塞,cwnd就減小一些漆枚。

慢開始算法的原理:如圖21所示创译。

(1)主機剛開始發(fā)送報文段時,可以先設置cwnd=1墙基,即設置為一個最大報文段MSS的數(shù)值软族。

(2)每收到一個對新的報文段的確認,將cwnd加1残制。即每經(jīng)過一個傳輸輪次立砸,cwnd就加倍。

(3)用這樣的方法逐步增大發(fā)送端的cwnd痘拆,可以使分組注入網(wǎng)絡的速率更加合理仰禽。

傳輸輪次:把cwnd所允許的報文段都連續(xù)發(fā)送出去氮墨,并收到對已發(fā)送的最后一個字節(jié)的確認纺蛆。

圖21

為了防止cwnd增長過大引起網(wǎng)絡擁塞吐葵,還需要設置一個慢開始門限ssthresh,用法如下:

(1)cwnd < ssthresh桥氏,使用慢開始算法

(2)cwnd > ssthresh温峭,停止使用慢開始算法,改用擁塞避免算法字支。

(3)cwnd = ssthresh凤藏,既可用慢開始算法,也可用擁塞避免算法堕伪。

擁塞算法的思路:讓cwnd緩慢增大揖庄,即經(jīng)過一個輪次,cwnd增加1欠雌,而不是加倍蹄梢,使cwnd按線性規(guī)律緩慢增長。

無論是慢開始算法還是擁塞避免算法階段富俄,只要發(fā)送方判斷網(wǎng)絡出現(xiàn)擁塞禁炒,就要把ssthresh設置為出現(xiàn)擁塞時發(fā)送方窗口的一半(但不小于2)。然后將cwnd重新設置為1霍比,執(zhí)行慢開始算法幕袱。

慢開始和擁塞避免算法的實現(xiàn)舉例如圖22所示。

圖22

乘法減小:不論在慢開始階段還是在擁塞避免階段悠瞬,只要網(wǎng)絡出現(xiàn)擁塞们豌,就將ssthresh設置為發(fā)送方窗口值得一半。

加法增大:執(zhí)行擁塞避免算法后浅妆,在收到對所有報文段的確認后玛痊,就把cwnd增加1,使cwnd緩慢增大狂打。

快重傳和快恢復:

快重傳算法:要求接收方在接收到一個失序報文時擂煞,就立即發(fā)出重復確認,使發(fā)送方及早知道有報文段未到接收方趴乡。發(fā)送方只要一連收到三個重復確認就立即重傳接收方尚未收到的報文段对省,如圖23所示。

圖23

快恢復算法:當發(fā)送端連續(xù)收到三個重復確認后晾捏,就執(zhí)行乘法減小算法蒿涎,把ssthresh減半,但接下來不執(zhí)行慢開始算法惦辛。因為發(fā)送方認為現(xiàn)在網(wǎng)絡很可能沒有發(fā)生擁塞劳秋,因此將cwnd設置為ssthresh減半后的值,再開始執(zhí)行擁塞避免算法。

快重傳與快恢復如圖24所示玻淑。

圖24

發(fā)送窗口的上限值 = Min [ rwnd , cwnd ]

隨機早期檢測RED:

路由器的隊列維持兩個參數(shù)嗽冒,隊列長度最小門限THmin和最大門限THmax。RED對每一個到達的數(shù)據(jù)報先計算平均隊列長度Lav补履,然后按圖25所示操作添坊。

圖25

瞬時隊列長度和平均隊列長度的區(qū)別如圖26所示。

圖26

10.TCP的運輸連接管理

運輸連接有三個階段:連接建立箫锤,數(shù)據(jù)傳輸贬蛙,連接釋放

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

(1)要使每一方能夠確知對方的存在

(2)要允許雙方協(xié)商一些參數(shù)

(3)能夠?qū)\輸實體資源進行分配

TCP連接的建立都是采用客戶服務器方式谚攒。

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

在建立連接之前阳准,B的TCP服務器進程先創(chuàng)建傳輸控制塊TCB,準備接受客戶進程的連接請求馏臭,然后就處于LISTEN狀態(tài)溺职,等待客戶的連接請求。A的TCP服務器進程先創(chuàng)建傳輸控制塊TCB位喂,然后向B發(fā)出連接請求報文段浪耘。

以圖27為例說明TCP建立連接的過程:

(1)A向B發(fā)出連接請求報文段,其中報文首部SYN=1塑崖,seq=x七冲,表明傳送數(shù)據(jù)時的第一個數(shù)據(jù)字節(jié)的序號為x。TCP規(guī)定SYN報文段不能攜帶數(shù)據(jù)但要消耗一個序列號规婆。

(2)B的TCP收到連接請求報文后澜躺,如果同意就發(fā)回確認。確認報文段中SYN=1抒蚜,ACK=1掘鄙,seq=y,ack=x+1嗡髓。

(3)A收到此報文段后操漠,還要向B發(fā)出確認。ACK=1饿这,seq=x+1浊伙,ack=y+1。A的TCP通知應用進程长捧,連接已經(jīng)建立嚣鄙。B的TCP進程收到A的確認后,也通知應用進程串结,連接已經(jīng)建立哑子。

圖27

為什么要使用三次握手舅列?

防止已失效的連接請求報文段突然又傳到B,因而產(chǎn)生錯誤卧蜓。

TCP的連接釋放:(四次揮手)

以圖28為例說明四次揮手帐要。

數(shù)據(jù)傳輸結(jié)束后,通信雙方都可釋放連接烦却。

(1)A的應用進程向其TCP發(fā)出連接釋放報文宠叼,并停止發(fā)送數(shù)據(jù)先巴,主動關(guān)閉TCP連接其爵。連接釋放報文段首部的FIN=1,seq=u伸蚯,等待B的確認摩渺。TCP規(guī)定,F(xiàn)IN報文段即使不攜帶數(shù)據(jù)剂邮,也消耗掉一個序號摇幻。

(2)B收到連接釋放報文后即發(fā)出確認,ack=u+1挥萌,seq=v绰姻,ACK=1。TCP服務器進程通知應用進程引瀑,A到B方向的連接釋放了狂芋,TCP處于半關(guān)閉狀態(tài)。B若繼續(xù)發(fā)生數(shù)據(jù)憨栽,A仍要接收帜矾。

(3)B沒有數(shù)據(jù)要發(fā)送了,就通知TCP釋放連接屑柔。FIN=1屡萤,ACK=1,ack=u+1掸宛,seq=w死陆。

(4)A收到連接釋放報文段后,必須發(fā)出確認唧瘾。ACK=1翔曲,seq=u+1,ack=w+1∨蓿現(xiàn)在TCP還沒有釋放掉瞳遍,必須等待經(jīng)過時間等待計時器設置的時間2MSL后才真正釋放掉。

圖28

為什么必須等待2MSL的時間呢菌羽?

(1)保證A發(fā)生的最后一個ACK報文段能夠到達B掠械。

(2)防止已失效的連接請求報文段出現(xiàn)在本連接中。

TCP還設有一個保活計時器猾蒂,若在規(guī)定時間內(nèi)沒有收到過客戶的數(shù)據(jù)均唉,就發(fā)送一個探測報文段,若連續(xù)發(fā)送10個探測報文段后仍無客戶想要肚菠,就任務客戶出現(xiàn)故障舔箭,關(guān)閉連接。

TCP的有限狀態(tài)及如圖29所示蚊逢。

圖29
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末层扶,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子烙荷,更是在濱河造成了極大的恐慌镜会,老刑警劉巖,帶你破解...
    沈念sama閱讀 212,718評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件终抽,死亡現(xiàn)場離奇詭異戳表,居然都是意外死亡,警方通過查閱死者的電腦和手機昼伴,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,683評論 3 385
  • 文/潘曉璐 我一進店門匾旭,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人圃郊,你說我怎么就攤上這事价涝。” “怎么了描沟?”我有些...
    開封第一講書人閱讀 158,207評論 0 348
  • 文/不壞的土叔 我叫張陵飒泻,是天一觀的道長。 經(jīng)常有香客問我吏廉,道長泞遗,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,755評論 1 284
  • 正文 為了忘掉前任席覆,我火速辦了婚禮史辙,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘佩伤。我一直安慰自己聊倔,他們只是感情好,可當我...
    茶點故事閱讀 65,862評論 6 386
  • 文/花漫 我一把揭開白布生巡。 她就那樣靜靜地躺著耙蔑,像睡著了一般。 火紅的嫁衣襯著肌膚如雪孤荣。 梳的紋絲不亂的頭發(fā)上甸陌,一...
    開封第一講書人閱讀 50,050評論 1 291
  • 那天须揣,我揣著相機與錄音,去河邊找鬼钱豁。 笑死耻卡,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的牲尺。 我是一名探鬼主播卵酪,決...
    沈念sama閱讀 39,136評論 3 410
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼谤碳!你這毒婦竟也來了溃卡?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 37,882評論 0 268
  • 序言:老撾萬榮一對情侶失蹤估蹄,失蹤者是張志新(化名)和其女友劉穎塑煎,沒想到半個月后沫换,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體臭蚁,經(jīng)...
    沈念sama閱讀 44,330評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,651評論 2 327
  • 正文 我和宋清朗相戀三年讯赏,在試婚紗的時候發(fā)現(xiàn)自己被綠了垮兑。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片哗蜈。...
    茶點故事閱讀 38,789評論 1 341
  • 序言:一個原本活蹦亂跳的男人離奇死亡聚至,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出固额,到底是詐尸還是另有隱情磕谅,我是刑警寧澤私爷,帶...
    沈念sama閱讀 34,477評論 4 333
  • 正文 年R本政府宣布,位于F島的核電站膊夹,受9級特大地震影響衬浑,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜放刨,卻給世界環(huán)境...
    茶點故事閱讀 40,135評論 3 317
  • 文/蒙蒙 一工秩、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧进统,春花似錦助币、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,864評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至掉分,卻和暖如春俭缓,著一層夾襖步出監(jiān)牢的瞬間迈螟,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,099評論 1 267
  • 我被黑心中介騙來泰國打工尔崔, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留答毫,地道東北人。 一個月前我還...
    沈念sama閱讀 46,598評論 2 362
  • 正文 我出身青樓季春,卻偏偏與公主長得像洗搂,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子载弄,可洞房花燭夜當晚...
    茶點故事閱讀 43,697評論 2 351

推薦閱讀更多精彩內(nèi)容