TCP協(xié)議通過(guò)使用連續(xù)ARQ協(xié)議和滑動(dòng)窗口協(xié)議，來(lái)保證數(shù)據(jù)傳輸?shù)恼_性，從而提供可靠的傳輸。

一、ARQ協(xié)議

ARQ協(xié)議，即自動(dòng)重傳請(qǐng)求（Automatic Repeat-reQuest），是OSI模型中數(shù)據(jù)鏈路層和傳輸層的錯(cuò)誤糾正協(xié)議之一。它通過(guò)使用確認(rèn)和超時(shí)這兩個(gè)機(jī)制，在不可靠服務(wù)的基礎(chǔ)上實(shí)現(xiàn)可靠的信息傳輸。如果發(fā)送方在發(fā)送后一段時(shí)間之內(nèi)沒(méi)有收到確認(rèn)幀，它通常會(huì)重新發(fā)送。ARQ包括停止等待ARQ協(xié)議和連續(xù)ARQ協(xié)議，擁有錯(cuò)誤檢測(cè)（Error Detection）、正面確認(rèn)（Positive Acknowledgment）、超時(shí)重傳（Retransmission after Timeout）和 負(fù)面確認(rèn)及重傳（Negative Acknowledgment and Retransmission）等機(jī)制。

（1）停止等待ARQ協(xié)議

要想弄明白為什么TCP要使用連續(xù)ARQ協(xié)議，首先需要弄清楚停止等待ARQ協(xié)議的原理。

TCP 連接是全雙工的連接，也就是說(shuō)在通信的時(shí)候，雙方既是發(fā)送方，也是接收方。下面為了簡(jiǎn)化問(wèn)題，只考慮一方發(fā)送，一方接受的情況。其中，A作為發(fā)送方，B作為接收方。

1.無(wú)差錯(cuò)情況

A發(fā)送分組M1，發(fā)送完就暫停發(fā)送，等待B的確認(rèn)。B收到M1就向A發(fā)送確認(rèn)。A在收到了對(duì)M1的確認(rèn)后，就再發(fā)送下一個(gè)分組M2。依次下去發(fā)送剩余的數(shù)據(jù)...如下圖所示：

2.出現(xiàn)差錯(cuò)

如果A發(fā)送的過(guò)程中出現(xiàn)差錯(cuò)，B在接收M1時(shí)檢測(cè)出了差錯(cuò)，就丟棄M1，其他什么都不做（也不會(huì)通知A收到有差錯(cuò)的分組）。又或者A傳送的過(guò)程中分組丟失了，以上這兩種情況下，B不會(huì)發(fā)送任何信息。?

既然說(shuō)它是可靠傳輸協(xié)議，那自然有它可靠的方法：如果發(fā)生以上的情況，A只要超過(guò)了一段時(shí)間仍然沒(méi)有收到確認(rèn)，就認(rèn)為剛才發(fā)送的分組丟失了，所以它會(huì)重傳剛剛的發(fā)送過(guò)的分組，也就是所謂的超時(shí)重傳。?

超時(shí)重傳的原理也很簡(jiǎn)單：發(fā)送方發(fā)送完一個(gè)分組后，就會(huì)設(shè)置一個(gè)超時(shí)計(jì)時(shí)器，如果超時(shí)計(jì)時(shí)器到期之前沒(méi)有收到接收方發(fā)來(lái)的確認(rèn)信息，則會(huì)重發(fā)剛發(fā)送過(guò)的分組；如果收到確認(rèn)信息，則撤銷(xiāo)該超時(shí)計(jì)時(shí)器。如下圖所示：

這里應(yīng)該注意的是：

①既然發(fā)送方發(fā)送的分組可能丟失或者有差錯(cuò)，可能需要重傳，那么它必須暫時(shí)保留已發(fā)送的分組副本，只有收到確認(rèn)后，才清除這個(gè)副本。

②分組和確認(rèn)分組信息都應(yīng)該有各自的編號(hào)，用來(lái)標(biāo)示每一個(gè)分組和確認(rèn)信息。（這樣才知道需要發(fā)送哪個(gè)分組，收到了哪個(gè)分組的確認(rèn)信息）

③超時(shí)計(jì)時(shí)器設(shè)置的時(shí)間應(yīng)該略長(zhǎng)于分組傳送往返時(shí)間。

3.確認(rèn)丟失和確認(rèn)延遲?

沒(méi)有正常進(jìn)行通信，除了發(fā)送方出現(xiàn)問(wèn)題外，接收方同時(shí)也可能存在問(wèn)題。

例如，如果A發(fā)送了M1分組，到達(dá)B，B發(fā)送了M1確認(rèn)信息，但由于網(wǎng)絡(luò)原因，該確認(rèn)信息丟失。那么這個(gè)時(shí)候，A在超時(shí)重傳時(shí)間內(nèi)，沒(méi)有收到B的確認(rèn)信息，而且它并不知道是自己的分組有差錯(cuò)、丟失，還是B發(fā)生的確認(rèn)丟失了。因此，A會(huì)在超時(shí)重傳過(guò)后，重傳M1分組。?

接收方B會(huì)采取這兩個(gè)行動(dòng)：?

①B會(huì)丟棄M1分組，不向上層交付。（B之前已經(jīng)收到過(guò)M1分組了）?

②向A發(fā)送確認(rèn)（因?yàn)锳重發(fā)了，肯定重傳時(shí)間內(nèi)沒(méi)有收到確認(rèn)信息）

還有可能是另一種情況，就是B發(fā)送了確認(rèn)，沒(méi)有丟失，但是延遲了。也就是說(shuō)，B發(fā)送的確認(rèn)在A超時(shí)計(jì)時(shí)器過(guò)期后才到達(dá)。 這種情況下，A收到確認(rèn)信息后會(huì)丟棄，然后重傳剛才的分組，B收到后，丟棄重復(fù)的分組，并重傳確認(rèn)信息。

根據(jù)上述的確認(rèn)和重傳機(jī)制，我們就可以在不可靠的網(wǎng)絡(luò)上實(shí)現(xiàn)可靠的傳輸。

4.信道利用率

停止等待ARQ協(xié)議的優(yōu)點(diǎn)是簡(jiǎn)答，但也有很?chē)?yán)重的確定，就是信道利用率太低。如下圖所示：

信道利用率U = TD / (TD + RTT + TA)

（2）連續(xù)ARQ協(xié)議

由于停止等待ARQ協(xié)議信道利用率太低，所以需要使用連續(xù)ARQ協(xié)議來(lái)進(jìn)行改善。這個(gè)協(xié)議會(huì)連續(xù)發(fā)送一組數(shù)據(jù)包，然后再等待這些數(shù)據(jù)包的ACK。

發(fā)送方采用流水線傳輸。流水線傳輸就是發(fā)送方可以連續(xù)發(fā)送多個(gè)分組，不必每發(fā)完一個(gè)分組就停下來(lái)等待對(duì)方確認(rèn)。如下圖所示：

連續(xù)ARQ協(xié)議通常是結(jié)合滑動(dòng)窗口協(xié)議來(lái)使用的，發(fā)送方需要維持一個(gè)發(fā)送窗口，如下圖所示：

圖（a）是發(fā)送方維持的發(fā)送窗口，它的意義是：位于發(fā)送窗口內(nèi)的5個(gè)分組都可以連續(xù)發(fā)送出去，而不需要等待對(duì)方的確認(rèn)，這樣就提高了信道利用率。?

連續(xù)ARQ協(xié)議規(guī)定，發(fā)送方每收到一個(gè)確認(rèn)，就把發(fā)送窗口向前滑動(dòng)一個(gè)分組的位置。例如上面的圖（b），當(dāng)發(fā)送方收到第一個(gè)分組的確認(rèn)，就把發(fā)送窗口向前移動(dòng)一個(gè)分組的位置。如果原來(lái)已經(jīng)發(fā)送了前5個(gè)分組，則現(xiàn)在可以發(fā)送窗口內(nèi)的第6個(gè)分組。?

接收方一般都是采用累積確認(rèn)的方式。也就是說(shuō)接收方不必對(duì)收到的分組逐個(gè)發(fā)送確認(rèn)。而是在收到幾個(gè)分組后，對(duì)按序到達(dá)的最后一個(gè)分組發(fā)送確認(rèn)。如果收到了這個(gè)分組確認(rèn)信息，則表示到這個(gè)分組為止的所有分組都已經(jīng)正確接收到了。?

累積確認(rèn)的優(yōu)點(diǎn)是容易實(shí)現(xiàn)，即使確認(rèn)丟失也不必重傳。但缺點(diǎn)是，不能正確的向發(fā)送方反映出接收方已經(jīng)正確收到的所以分組的信息。比如發(fā)送方發(fā)送了前5個(gè)分組，而中間的第3個(gè)分組丟失了，這時(shí)候接收方只能對(duì)前2個(gè)發(fā)出確認(rèn)。而不知道后面3個(gè)分組的下落，因此只能把后面的3個(gè)分組都重傳一次，這種機(jī)制叫Go-back-N（回退N），表示需要再退回來(lái)重傳已發(fā)送過(guò)的N個(gè)分組。

二、滑動(dòng)窗口協(xié)議

滑動(dòng)窗口協(xié)議在在發(fā)送方和接收方之間各自維持一個(gè)滑動(dòng)窗口，發(fā)送發(fā)是發(fā)送窗口，接收方是接收窗口，而且這個(gè)窗口是隨著時(shí)間變化可以向前滑動(dòng)的。它允許發(fā)送方發(fā)送多個(gè)分組而不需等待確認(rèn)。TCP的滑動(dòng)窗口是以字節(jié)為單位的。

如下圖所示，發(fā)送窗口中有四個(gè)概念：：已發(fā)送并收到確認(rèn)的數(shù)據(jù)（不在發(fā)送窗口和發(fā)送緩沖區(qū)之內(nèi)）、已發(fā)送但未收到確認(rèn)的數(shù)據(jù)（位于發(fā)送窗口之內(nèi)）、允許發(fā)送但尚未發(fā)送的數(shù)據(jù)（位于發(fā)送窗口之內(nèi)）、發(fā)送窗口之外的緩沖區(qū)內(nèi)暫時(shí)不允許發(fā)送的數(shù)據(jù)。

接收窗口中也有四個(gè)概念：已發(fā)送確認(rèn)并交付主機(jī)的數(shù)據(jù)（不在接收窗口和接收緩沖區(qū)之內(nèi)）、未按序收到的數(shù)據(jù)（位于接收窗口之內(nèi)）、允許的數(shù)據(jù)（位于接收窗口之內(nèi)）、不允許接收的數(shù)據(jù)（位于發(fā)送窗口之內(nèi)）。

規(guī)則：

（1）凡是已經(jīng)發(fā)送過(guò)的數(shù)據(jù)，在未收到確認(rèn)之前，都必須暫時(shí)保留，以便在超時(shí)重傳時(shí)使用。

（2）只有當(dāng)發(fā)送方A收到了接收方的確認(rèn)報(bào)文段時(shí)，發(fā)送方窗口才可以向前滑動(dòng)幾個(gè)序號(hào)。

（3）當(dāng)發(fā)送方A發(fā)送的數(shù)據(jù)經(jīng)過(guò)一段時(shí)間沒(méi)有收到確認(rèn)（由超時(shí)計(jì)時(shí)器控制），就要使用回退N步協(xié)議，回到最后接收到確認(rèn)號(hào)的地方，重新發(fā)送這部分?jǐn)?shù)據(jù)。

此外，TCP利用滑動(dòng)窗口協(xié)議來(lái)進(jìn)行流量控制，如下圖所示：

參考資料：

1、ARQ-維基百科?https://zh.wikipedia.org/wiki/ARQ

2、TCP/IP（三） —— 可靠傳輸工作原理?http://pmghong.blog.51cto.com/3221425/1242470

3、TCP可靠傳輸&流量控制&擁塞控制 ?http://my.oschina.net/manmao/blog/601585

4、計(jì)算機(jī)網(wǎng)絡(luò)【七】：可靠傳輸?shù)膶?shí)現(xiàn)?http://blog.chinaunix.net/uid-26275986-id-4109679.html

5、TCP/IP之TCP協(xié)議（3）：流量控制（滑動(dòng)窗口協(xié)議）http://blog.csdn.net/wbw1985/article/details/4879224

總結(jié)

以上是生活随笔為你收集整理的TCP连续ARQ协议和滑动窗口协议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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