當(dāng)前位置:首頁(yè) > 公眾號(hào)精選 > wenzi嵌入式軟件
[導(dǎo)讀]UDP和TCP的區(qū)別在上一則文章中,對(duì)TCP的三次握手建立連接和四次揮手釋放連接進(jìn)行了詳細(xì)地闡述,本節(jié)教程針對(duì)于TCP的其他內(nèi)容進(jìn)行講解,首先是同處于傳輸層協(xié)議的UDP協(xié)議,這兩者有什么區(qū)別與聯(lián)系呢?相同點(diǎn)那就是說(shuō):UDP?和?TCP?是?TCP/IP?體系結(jié)構(gòu)運(yùn)輸層中的兩個(gè)重要...

UDP 和 TCP 的區(qū)別

在上一則文章中,對(duì) TCP 的三次握手建立連接四次揮手釋放連接進(jìn)行了詳細(xì)地闡述,本節(jié)教程針對(duì)于 TCP 的其他內(nèi)容進(jìn)行講解,首先是同處于傳輸層協(xié)議的UDP協(xié)議,這兩者有什么區(qū)別與聯(lián)系呢?

相同點(diǎn)那就是說(shuō):UDP?和?TCP?是?TCP/IP?體系結(jié)構(gòu)運(yùn)輸層中的兩個(gè)重要協(xié)議,下圖是TCP/IP的體系結(jié)構(gòu)圖:

額外補(bǔ)充的一點(diǎn)就是說(shuō),在?TCP和?UDP?協(xié)議下層的IP協(xié)議,IP協(xié)議可以為各種網(wǎng)絡(luò)應(yīng)用提供服務(wù),使用IP層協(xié)議互連不同的網(wǎng)絡(luò)接口,下面是一個(gè)結(jié)構(gòu)圖:

image-20210718234432031
TCPUDP的使用頻率也僅次于位于網(wǎng)際層的IP協(xié)議。

UDP也稱(chēng)之為是用戶數(shù)據(jù)報(bào)協(xié)議,而TCP呢,被稱(chēng)之為傳輸控制協(xié)議,比較顯著的一點(diǎn)區(qū)別就是說(shuō),UDP?是無(wú)連接的,而TCP?是面向連接的,下面是兩種通信方式通信的一個(gè)示意圖:

image-20210718235508609
如上圖所示,對(duì)于UDP來(lái)講,其無(wú)需建立連接就能夠進(jìn)行數(shù)據(jù)傳輸,而對(duì)于?TCP來(lái)講,其在進(jìn)行數(shù)據(jù)傳輸之前,需要進(jìn)行“三報(bào)文握手”建立連接,然后才進(jìn)行數(shù)據(jù)傳輸,數(shù)據(jù)傳輸完成之后,還需要進(jìn)行“四報(bào)文揮手”釋放連接。

也正是因?yàn)?code style="box-sizing: border-box;margin-right: 2px;margin-left: 2px;padding: 2px 4px;font-size: inherit;color: rgb(233, 105, 0);line-height: inherit;overflow-wrap: break-word;border-radius: 4px;background: rgb(248, 248, 248);">UDP無(wú)連接的特性,對(duì)于UDP來(lái)說(shuō),其支持單播、多播以及廣播,而對(duì)于TCP來(lái)說(shuō),因?yàn)槿挝帐纸⒌牡倪B接,它有了一條可靠的信道,它也就僅僅支持單播,下面是兩個(gè)通信方式的示意圖:

image-20210719000338512
緊接著,分析一下UDPTCP數(shù)據(jù)傳輸?shù)脑敿?xì)過(guò)程

image-20210706213718285
可以看到,對(duì)于?UDP來(lái)講,其是面向應(yīng)用報(bào)文的,發(fā)送方的應(yīng)用進(jìn)程將應(yīng)用報(bào)文交付給傳輸層的UDP,UDP直接給應(yīng)用層報(bào)文添加一個(gè)UDP首部,使之成為UDP用戶數(shù)據(jù)報(bào),然后進(jìn)行發(fā)送,接收方的UDP收到該UDP用戶數(shù)據(jù)報(bào)后,去掉UDP首部,將應(yīng)用層報(bào)文交付給應(yīng)用進(jìn)程,換言之,就是說(shuō)UDP對(duì)應(yīng)用進(jìn)程交下來(lái)的報(bào)文既不合并也不拆分,而是保留這些報(bào)文的邊界,也就是說(shuō),UDP是面向應(yīng)用報(bào)文的。

緊接著,上圖的右邊是TCP的數(shù)據(jù)發(fā)送流程,發(fā)送方的TCP把應(yīng)用進(jìn)程交付下來(lái)的數(shù)據(jù)塊看作是一連串的無(wú)結(jié)構(gòu)的字節(jié)流,TCP并不知道這些待傳送的字節(jié)流的含義,僅僅將他們編號(hào),并存儲(chǔ)在自己的發(fā)送緩存中,TCP根據(jù)發(fā)送策略,從發(fā)送緩存中提取出一定數(shù)量的字節(jié),構(gòu)建TCP報(bào)文段并發(fā)送,接收方的TCP一方面從接收到的TCP報(bào)文中取出數(shù)據(jù)載荷部分并存儲(chǔ)在接收緩存中,一方面將接收緩存中的一些字節(jié)交付給應(yīng)用進(jìn)程,TCP不保證所收到的數(shù)據(jù)塊與發(fā)送方應(yīng)用進(jìn)程所發(fā)出的數(shù)據(jù)塊具有對(duì)應(yīng)大小的關(guān)系,但是呢,接收方應(yīng)用進(jìn)程收到的字節(jié)流必須和發(fā)送方應(yīng)用進(jìn)程發(fā)出的字節(jié)流完全一樣,與此同時(shí),接收方應(yīng)用進(jìn)程必須有能力識(shí)別收到的字節(jié)流,把它還原成有意義的應(yīng)用層數(shù)據(jù)。也就是說(shuō),TCP是面向字節(jié)流的,這也正是TCP實(shí)現(xiàn)可靠傳輸、流量控制以及擁塞控制的基礎(chǔ)。

緊接著,再來(lái)看另外一個(gè)對(duì)比,其示意圖如下所示:

image-20210706215655559
就是說(shuō)對(duì)于TCP/IP體系架構(gòu)來(lái)說(shuō),網(wǎng)際層向上提供無(wú)連接不可靠的傳輸服務(wù),而對(duì)于?UDP來(lái)說(shuō),其所再運(yùn)輸層向上提供無(wú)連接不可靠的傳輸服務(wù),這樣一種機(jī)制也就造成了數(shù)據(jù)包的丟失以及誤碼現(xiàn)象,但是對(duì)于UDP傳輸來(lái)講,它就僅僅是丟棄其他什么也不做;但是對(duì)于TCP傳輸協(xié)議來(lái)講呢,網(wǎng)際層向上提供無(wú)連接不可靠的傳輸服務(wù),TCP所處的傳輸層向上提供面向連接的可靠傳輸服務(wù),這也就實(shí)現(xiàn)了基于TCP連接的可靠信道,不會(huì)出現(xiàn)傳輸差錯(cuò),誤碼,丟失,亂序以及重復(fù)的問(wèn)題。

下面對(duì)比一下UDPTCP報(bào)文的首部,一個(gè)UDP用戶數(shù)據(jù)報(bào)由首部和數(shù)據(jù)載荷兩部分組成,TCP報(bào)文段也是由首部和數(shù)據(jù)載荷部分組成,其中UDP用戶數(shù)據(jù)報(bào)首部?jī)H僅8個(gè)字節(jié),僅僅包含源端口,目的端口,長(zhǎng)度以及校驗(yàn)和。而對(duì)于TCP來(lái)講,其首部包含的信息較多,其首部大小最小為20字節(jié),最大為60字節(jié)。

image-20210707133649551

小結(jié)

綜上所述,針對(duì)于TCPUDP來(lái)說(shuō)兩者的特點(diǎn)與區(qū)別匯總?cè)缦拢?/p>用戶數(shù)據(jù)報(bào)協(xié)議UDP

  • 無(wú)連接

  • 支持一對(duì)一,一對(duì)多,多對(duì)一和多對(duì)多交互通信

  • 對(duì)應(yīng)用層交付的報(bào)文直接打包

  • 盡最大努力交付,也就是不可靠;不使用流量控制和擁塞控制

  • 首部開(kāi)銷(xiāo)小,僅 8 字節(jié)

傳輸控制層協(xié)議TCP

  • 面向連接

  • 每一條TCP連接只能有兩個(gè)端點(diǎn),只能是一對(duì)一通信

  • 面向字節(jié)流

  • 可靠傳輸,使用流量控制和擁塞控制

  • 首部最小20字節(jié),最大60字節(jié)

TCP 的流量控制

滑動(dòng)窗口的引出

在上一則文章敘述?TCP三次握手和四次揮手的那個(gè)過(guò)程中,我們知道對(duì)于TCP的通信來(lái)講,是每發(fā)送一個(gè)數(shù)據(jù),都要進(jìn)行一次確認(rèn)應(yīng)答。當(dāng)上一個(gè)數(shù)據(jù)包收到應(yīng)答了,再發(fā)送下一個(gè)數(shù)據(jù)包,這樣一個(gè)通信的流程是如下所示的:

image-20210711105416703
通過(guò)上述這個(gè)示意圖也可以看出,如果說(shuō)每次發(fā)送一個(gè)數(shù)據(jù)包應(yīng)答一次再發(fā)送下一個(gè)數(shù)據(jù)包,這樣的效率也過(guò)于低下了,這時(shí)候也就引入了滑動(dòng)窗口的概念。那有了窗口,就可以指定窗口的大小了,窗口大小也就是指無(wú)需要等待應(yīng)答,而可以繼續(xù)發(fā)送數(shù)據(jù)的最大值,比如說(shuō)如果當(dāng)前的窗口是?3?的話,那么發(fā)送方就可以連續(xù)發(fā)送三個(gè)TCP段,而且如上圖所示如果其中的一個(gè)ACK丟失了,那么可以通過(guò)下一個(gè)確認(rèn)應(yīng)答進(jìn)行確認(rèn),比方說(shuō),如果ACK 600丟失了,那么ACK 700的確認(rèn)應(yīng)答就可以替代ACK 600的確認(rèn)應(yīng)答。

image-20210711233912755

流量控制

根據(jù)上述引出的滑動(dòng)窗口機(jī)制,我們知道,因?yàn)榇藱C(jī)制的原因,我們能夠使得傳輸速率更快了,但是如果發(fā)送方的發(fā)送速率過(guò)快,那么接收方就可能來(lái)不及處理,這就會(huì)造成數(shù)據(jù)的丟失,而即將敘述的流量控制,就是讓發(fā)送方的發(fā)送速率不要太快,要讓接收方能夠來(lái)得及接收,而利用滑動(dòng)窗口機(jī)制可以很方便地在 TCP 連接上實(shí)現(xiàn)對(duì)發(fā)送方的流量控制。

在介紹流量控制是如何實(shí)現(xiàn)的之前,先來(lái)分別看看發(fā)送方和接收方的滑動(dòng)窗口,首先來(lái)介紹發(fā)送方的窗口,那對(duì)于發(fā)送方來(lái)講,這個(gè)窗口有多大呢?這是取決于接收方能夠處理多大的數(shù)據(jù),也就是說(shuō)在發(fā)送數(shù)據(jù)之前,接受方會(huì)給發(fā)送方報(bào)一個(gè)窗口大小,這個(gè)窗口大小也就是Advertised window,具體是什么意思呢?看如下示意圖:

image-20210727010803750
  • LastByteAcked:第一部分和第二部分的分界線

  • LastByteSent:第二部分和第三部分的分界線

通過(guò)示意圖也可以看出來(lái),對(duì)于Advertised window來(lái)說(shuō),這個(gè)窗口的大小應(yīng)該等于第二部分 第三部分。

對(duì)于接收端來(lái)講,它的緩存里面記錄的內(nèi)容要簡(jiǎn)單一些,示意圖如下所示:

image-20210712002717332
其中,MaxRcvBuffer也正如其字面意思,就是最大緩存的量,對(duì)于接收方的窗口大小也就如藍(lán)色方框所示,說(shuō)到這里呢,也就引入了一個(gè)問(wèn)題,就是說(shuō):接收窗口和發(fā)送窗口的大小是相等的么?

答案是并不是完全相等,接收窗口的大小是約等于發(fā)送窗口的大小的。

原因在于滑動(dòng)窗口不是一成不變的,比如說(shuō),當(dāng)接收方的應(yīng)用進(jìn)程讀取數(shù)據(jù)比較快的時(shí)候,這樣的話接收窗口就會(huì)很快空出來(lái),但是要把這一消息告訴發(fā)送方,需要經(jīng)過(guò)網(wǎng)絡(luò)傳輸,那么這樣依賴就會(huì)出現(xiàn)不一致的情況,所以說(shuō),是約等于的。

發(fā)送方和接收方的窗口就基本這些內(nèi)容,接下來(lái)是關(guān)于流量控制的內(nèi)容:

先假設(shè)窗口不變,也就是9,當(dāng) 4 的確認(rèn)來(lái)的時(shí)候,窗口會(huì)向右移動(dòng)一個(gè),整個(gè)時(shí)候,13這個(gè)序號(hào)的包也可以發(fā)送了。

image-20210726001856097
如果說(shuō)這個(gè)時(shí)候,發(fā)送方發(fā)送的過(guò)快,會(huì)將第三部分的10、11、12、13全部發(fā)送完畢,之后就停止發(fā)送了,未發(fā)送可發(fā)送部分為0

image-20210726002732414
這個(gè)時(shí)候,只有當(dāng)包 5 的確認(rèn)到達(dá)的時(shí)候,在客戶端相當(dāng)于窗口再滑動(dòng)了一格,這個(gè)時(shí)候,第 14 個(gè)包才可以發(fā)送。

image-20210726003909427
如果接收方處理的太慢了,那么就可以通過(guò)確認(rèn)信息來(lái)調(diào)整窗口的大小,現(xiàn)在假設(shè)一種比較極端的情況,就是說(shuō)接收端一直不處理數(shù)據(jù),那么當(dāng)數(shù)據(jù)包6的確認(rèn)到達(dá)之后,窗口大小就不能是 9了,就需要縮小一個(gè)變?yōu)?,下方是發(fā)送方在收到一個(gè)6的確認(rèn)包之后,窗口的變化情況,可以看到此時(shí)窗口的變化方式并不是向右移動(dòng)一格,而是窗口的左邊向由縮進(jìn)一格,窗口的整體大小并沒(méi)有發(fā)生變化。

image-20210726004657587
如果說(shuō)接收端一直不處理數(shù)據(jù),那么隨著確認(rèn)的包越來(lái)越多,窗口也就越來(lái)越小,直到為0,下方是接收方窗口的變化情況:

image-20210726004911416
與上圖接收方對(duì)應(yīng)的發(fā)送窗口的情況如下如所示,當(dāng) 14 的確認(rèn)到達(dá)發(fā)送端的時(shí)候,發(fā)送端的窗口也調(diào)整為0,停止發(fā)送。

image-20210726005438132
如果到這種情況的話,發(fā)送方會(huì)定時(shí)發(fā)送窗口探測(cè)數(shù)據(jù)包,看是否有機(jī)會(huì)調(diào)整窗口的大小。當(dāng)接收方比較慢的時(shí)候,,要防止低能窗口綜合征,別空出一個(gè)字節(jié)來(lái)就趕快告訴發(fā)送方,然后馬上又填滿了,可以當(dāng)窗口太小的時(shí)候,不更新窗口,直到達(dá)到一定大小,或者緩沖區(qū)一半為空,才更新窗口。

上述就是TCP中的流量控制。

TCP 擁塞控制

在某段時(shí)間,如果對(duì)網(wǎng)絡(luò)中某一資源的需求超過(guò)了該資源所能夠提供的可用部分,網(wǎng)絡(luò)性能就要變壞,這種情況就叫做擁塞。

在計(jì)算機(jī)網(wǎng)絡(luò)中的鏈路容量(即帶寬)、交換結(jié)點(diǎn)中的緩存和處理機(jī)等,都是網(wǎng)絡(luò)的資源

如果出現(xiàn)擁塞而不進(jìn)行控制,整個(gè)網(wǎng)絡(luò)的吞吐量將隨著輸入負(fù)荷的增大而下降。

下圖是理想擁塞控制,實(shí)際的擁塞控制,和無(wú)擁塞控制的一個(gè)曲線圖,曲線如下所示:

image-20210726233128809
TCP 的擁塞控制算法主要涉及到四個(gè),分別是:

  • 慢開(kāi)始算法

  • 擁塞避免算法

  • 快重傳算法

  • 快恢復(fù)算法

在講解這四種擁塞控制算法之前,先假定如下條件:

  • 數(shù)據(jù)是單方向傳送的,而另一個(gè)方向只傳送確認(rèn)

  • 接收方總有足夠大的緩存空間,因而發(fā)送方發(fā)送的窗口的大小由網(wǎng)絡(luò)的擁塞程度來(lái)決定

  • 以最大報(bào)文段?MSS?的個(gè)數(shù)作為討論問(wèn)題的單位,而不是以字節(jié)為單位

也就是說(shuō)現(xiàn)在發(fā)送方和接收方兩者之間的通信是這樣子的,具體過(guò)程如下圖所示:

image-20210726235358470
發(fā)送方向接收方發(fā)送一個(gè) TCP 數(shù)據(jù)報(bào)文段,而接收方收到整個(gè)報(bào)文段之后,就向發(fā)送方回一個(gè)TCP確認(rèn)報(bào)文段

也就是說(shuō),發(fā)送方維護(hù)一個(gè)叫做擁塞窗口cwnd的狀態(tài)變量,其值取決于網(wǎng)絡(luò)的擁塞程度,并且動(dòng)態(tài)變化。

  • 擁塞窗口cwnd的維護(hù)原則:只要網(wǎng)絡(luò)沒(méi)有出現(xiàn)擁塞,擁塞窗口的值就增大一些;但是只要網(wǎng)絡(luò)中出現(xiàn)擁塞,擁塞窗口就減小一些。

  • 判斷出現(xiàn)網(wǎng)絡(luò)擁塞的依據(jù):沒(méi)有按時(shí)收到應(yīng)當(dāng)達(dá)到的確認(rèn)報(bào)文(也就是發(fā)生了超時(shí)重傳)。

發(fā)送方將擁塞窗口作為發(fā)送窗口,也就是 swnd = cwdn

維護(hù)一個(gè)慢開(kāi)始門(mén)限ssthresh狀態(tài)變量:

  • 當(dāng) cwnd < ssthresh 時(shí),開(kāi)始使用慢開(kāi)始算法

  • 當(dāng) cwnd > ssthresh 時(shí),停止使用慢開(kāi)始算法而改用擁塞避免算法

  • 當(dāng) cwnd = ssthresh 時(shí),既可以使用慢開(kāi)始算法,也可以使用擁塞避免算法

慢開(kāi)始和擁塞避免算法

為了更改的闡述慢開(kāi)始算法,我們給出下面這樣一個(gè)折線圖,其中折線圖的橫坐標(biāo)表示的是傳輸輪次,而一個(gè)傳輸輪次指的是發(fā)送方給接收方發(fā)送數(shù)據(jù)報(bào)文段之后,接收方給發(fā)送方回相應(yīng)的確認(rèn)報(bào)文段,一個(gè)傳輸輪次所經(jīng)歷的時(shí)間,其實(shí)就是往返時(shí)間,縱坐標(biāo)是擁塞窗口,這是一個(gè)動(dòng)態(tài)變化的值。

在 TCP 雙方建立邏輯連接關(guān)系時(shí),擁塞窗口的值被設(shè)置為1 ,另外還需要設(shè)置慢開(kāi)始門(mén)限的初始值為16,在執(zhí)行慢開(kāi)始算法時(shí),發(fā)送方每收到一個(gè)接收方發(fā)來(lái)的確認(rèn)報(bào)文段時(shí),就將擁塞窗口值 1,然后再開(kāi)始下一輪次的傳輸,當(dāng)擁塞窗口值增加到慢開(kāi)始門(mén)限值時(shí),就改為執(zhí)行擁塞避免算法。

image-20210727001131965
上述的折線圖該如何解釋呢?就是說(shuō),如果最開(kāi)始,發(fā)送方的擁塞窗口值為1,發(fā)送方發(fā)送一個(gè)TCP 報(bào)文段至接收方,接收方收到之后,發(fā)送TCP確認(rèn)報(bào)文段至發(fā)送方,當(dāng)發(fā)送方收到這個(gè)確認(rèn)報(bào)文段之后,就將擁塞窗口的值加1,因?yàn)樵谶@里,擁塞窗口的值就等于發(fā)送窗口的值,所以,此時(shí)發(fā)送窗口的值為 2,那么發(fā)送方就能夠發(fā)送兩個(gè)報(bào)文段到接收方,當(dāng)發(fā)送方收到這兩個(gè)報(bào)文段的確認(rèn)報(bào)文段后,就將擁塞窗口設(shè)置為 4,此時(shí)發(fā)送方就能發(fā)送4個(gè)TCP報(bào)文段至接收方,按照這樣一種原理,圖中數(shù)據(jù)包每增加一個(gè)輪次,擁塞窗口的值就呈現(xiàn)指數(shù)增長(zhǎng),直至增加到慢開(kāi)始門(mén)限值,也就是 16,此時(shí)改為擁塞避免算法。

何為擁塞避免算法呢,也就是說(shuō)當(dāng)前來(lái)講,每個(gè)傳輸輪次結(jié)束之后,擁塞窗口的值改為線性加1,而不是像慢開(kāi)始算法那樣擁塞窗口的值呈現(xiàn)指數(shù)增長(zhǎng),比如說(shuō)此時(shí)發(fā)送方能夠發(fā)送15~30號(hào)的數(shù)據(jù)報(bào)文段,當(dāng)發(fā)送方收到 15 ~30 號(hào)的數(shù)據(jù)確認(rèn)報(bào)文段,將擁塞窗口值加1增大到17,依據(jù)此原理,發(fā)送方和接收方又進(jìn)行了幾個(gè)輪次的數(shù)據(jù)傳輸,達(dá)到如下所示的一個(gè)折線圖:

image-20210727002623522
如果說(shuō)此時(shí),在擁塞窗口值達(dá)到 24 的時(shí)候,發(fā)送方又向接收方發(fā)送了一串?dāng)?shù)據(jù)包,假設(shè)這串報(bào)文段在傳輸過(guò)程中,丟失了幾個(gè),這必然會(huì)造成發(fā)送方對(duì)這些丟失報(bào)文段的超時(shí)重傳,發(fā)送方依據(jù)此判斷網(wǎng)絡(luò)很可能出現(xiàn)了擁塞,那么這個(gè)時(shí)候就需要做如下的工作:將慢開(kāi)始門(mén)限值更新為發(fā)生擁塞時(shí)擁塞窗口值的一半,然后將擁塞窗口值調(diào)整為1 ,重新執(zhí)行慢開(kāi)始算法,當(dāng)擁塞窗口達(dá)到慢開(kāi)始門(mén)限值的時(shí)候,就執(zhí)行擁塞避免算法,具體過(guò)程如圖所示:

image-20210727003147211
最后,對(duì)這一整個(gè)過(guò)程進(jìn)行標(biāo)注,標(biāo)注之后的折線圖如圖所示:

image-20210727003439349

快重傳算法

有些時(shí)候,個(gè)別報(bào)文段會(huì)在網(wǎng)絡(luò)中丟失,但是實(shí)際網(wǎng)絡(luò)中并沒(méi)有發(fā)生擁塞,這也將導(dǎo)致發(fā)送方超時(shí)重傳,并且誤認(rèn)為是發(fā)生了擁塞,這個(gè)時(shí)候,發(fā)送方將擁塞窗口設(shè)置為最小值1,并且錯(cuò)誤地啟動(dòng)了慢開(kāi)始算法,因而降低了傳輸效率。

而采用快重傳算法可以讓發(fā)送方盡可能早地知道發(fā)生了個(gè)別報(bào)文段的丟失,也就是說(shuō)快重傳也就是讓發(fā)送方盡快進(jìn)行重傳,而不是等待超時(shí)重傳計(jì)時(shí)器超時(shí)再重傳。

具體是怎么樣呢?就是說(shuō)接收方不要等待自己發(fā)送數(shù)據(jù)時(shí)才進(jìn)行捎帶確認(rèn),而是要立即發(fā)送確認(rèn);即使是收到了失序的報(bào)文段也要立即發(fā)出對(duì)已經(jīng)收到報(bào)文段的重復(fù)確認(rèn),發(fā)送方一旦收到 3 個(gè)連續(xù)的重復(fù)確認(rèn),就將相應(yīng)的報(bào)文段立即重傳,而不是等待該報(bào)文段超時(shí)重傳計(jì)時(shí)器超時(shí)再重傳。

具體的過(guò)程是怎么樣的呢,看如下所示的示意圖:

image-20210727004738434
通過(guò)上圖可以看到,在發(fā)送M2時(shí),并沒(méi)有等待M1的確認(rèn)報(bào)文段到達(dá)之后再發(fā)送,而是在確認(rèn)報(bào)文段到達(dá)之前就將?M2?的報(bào)文段發(fā)送出去了,發(fā)送?M3?的時(shí)候,數(shù)據(jù)報(bào)發(fā)生了丟失,在發(fā)送?M4?的時(shí)候,接收方收到之后,會(huì)繼續(xù)回傳報(bào)文段 M2 的確認(rèn),一直到發(fā)送?M6?的時(shí)候,都是回傳的M2的確認(rèn)包,而此時(shí)對(duì)于M2的確認(rèn)包的接收已經(jīng)累計(jì)3個(gè)了,就立即重傳M3報(bào)文段,這樣也就不會(huì)造成對(duì)?M3?報(bào)文段的超時(shí)重傳,也就不會(huì)將擁塞窗口調(diào)整為 1 ,也就能夠大大提升網(wǎng)絡(luò)的傳輸效率。

快恢復(fù)算法

發(fā)送方一旦收到3個(gè)重復(fù)確認(rèn),就知道現(xiàn)在只是丟失了個(gè)別的報(bào)文段。于是不啟動(dòng)慢開(kāi)始算法,而執(zhí)行快恢復(fù)算法;發(fā)送方將慢開(kāi)始門(mén)限值和擁塞窗口值調(diào)整為當(dāng)前窗口的一半;開(kāi)始執(zhí)行擁塞避免算法。

小結(jié)

綜上所述,我們綜合前面所敘述的慢開(kāi)始和擁塞避免算法,以及快重傳和快恢復(fù)算法舉一個(gè)例子,例子如下所示:

image-20210727010118107
這個(gè)圖結(jié)合上述的理論能很好的進(jìn)行解釋?zhuān)@里就不在進(jìn)行闡述了。

總結(jié)

至此,關(guān)于計(jì)算機(jī)網(wǎng)絡(luò)中 TCP 部分的闡述到此也就結(jié)束了,結(jié)合前面一則的 TCP 教程閱讀更佳哦~


本站聲明: 本文章由作者或相關(guān)機(jī)構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點(diǎn),本站亦不保證或承諾內(nèi)容真實(shí)性等。需要轉(zhuǎn)載請(qǐng)聯(lián)系該專(zhuān)欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請(qǐng)及時(shí)聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車(chē)的華為或?qū)⒋呱龈蟮莫?dú)角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

倫敦2024年8月29日 /美通社/ -- 英國(guó)汽車(chē)技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車(chē)工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車(chē)。 SODA V工具的開(kāi)發(fā)耗時(shí)1.5...

關(guān)鍵字: 汽車(chē) 人工智能 智能驅(qū)動(dòng) BSP

北京2024年8月28日 /美通社/ -- 越來(lái)越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運(yùn)行,同時(shí)企業(yè)卻面臨越來(lái)越多業(yè)務(wù)中斷的風(fēng)險(xiǎn),如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報(bào)道,騰訊和網(wǎng)易近期正在縮減他們對(duì)日本游戲市場(chǎng)的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國(guó)國(guó)際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)開(kāi)幕式在貴陽(yáng)舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國(guó)國(guó)際大數(shù)據(jù)產(chǎn)業(yè)博覽會(huì)上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱(chēng),數(shù)字世界的話語(yǔ)權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機(jī) 衛(wèi)星通信

要點(diǎn): 有效應(yīng)對(duì)環(huán)境變化,經(jīng)營(yíng)業(yè)績(jī)穩(wěn)中有升 落實(shí)提質(zhì)增效舉措,毛利潤(rùn)率延續(xù)升勢(shì) 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長(zhǎng) 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競(jìng)爭(zhēng)力 堅(jiān)持高質(zhì)量發(fā)展策略,塑強(qiáng)核心競(jìng)爭(zhēng)優(yōu)勢(shì)...

關(guān)鍵字: 通信 BSP 電信運(yùn)營(yíng)商 數(shù)字經(jīng)濟(jì)

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺(tái)與中國(guó)電影電視技術(shù)學(xué)會(huì)聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會(huì)上宣布正式成立。 活動(dòng)現(xiàn)場(chǎng) NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長(zhǎng)三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會(huì)上,軟通動(dòng)力信息技術(shù)(集團(tuán))股份有限公司(以下簡(jiǎn)稱(chēng)"軟通動(dòng)力")與長(zhǎng)三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉