一、Utopian Simplex Protocol（烏托邦）

最簡單的協(xié)議，假設(shè)信道是單工的，無差錯的，且接收方有無限的緩沖區(qū)。

10年積累的成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先做網(wǎng)站后付款的網(wǎng)站建設(shè)流程，更有漢源免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

所以發(fā)送方就可以一直發(fā)

問題：現(xiàn)實情況比這個惡劣的多。

二、Simplex Stop-and-Wait Protocol for an Error-Free Channel（簡單停等）

假設(shè)：單工信道，無差錯，接收方是有限的緩沖區(qū)。

發(fā)送方發(fā)送數(shù)據(jù)，然后停下來等待接收方的ack，收到ack之后再發(fā)數(shù)據(jù)。這樣接收方就可以不發(fā)ack來控制發(fā)送的速度。

問題：

1、如果信道不是無差錯的，那么接收方算了CRC之后發(fā)現(xiàn)不對，就會丟棄包，不發(fā)ack，這時發(fā)送方的timer超時，就會重傳。

2、如果數(shù)據(jù)幀丟了，那么發(fā)送方就會收不到ack，timer超時重傳。

3、如果ack丟了，那么同樣發(fā)送方就會收不到ack，timer超時重傳?？墒沁@就會有一個問題

發(fā)送方重傳的是一樣的東西，這樣接收方就會收到同樣的幀，可接收方不知道是同樣的幀，這時就需要給數(shù)據(jù)幀加序號。

可是這樣還沒完，接收方收到重復(fù)的幀后，接受方發(fā)現(xiàn)是重復(fù)的序號，就丟掉了，不發(fā)ack，可發(fā)送方不知道啊，發(fā)送方覺得是這一幀又沒發(fā)到，timer到了就又重傳。所以這時就需要給ack幀加序號，加上這兩個序號，就是第三個協(xié)議。

三、Stop-and-Wait ARQ（停等ARQ）

就是用0和1給數(shù)據(jù)和ack編號，這樣就解決了重復(fù)數(shù)據(jù)幀和延遲ack的問題。

四、One-Bit Sliding Window Protocol

窗口大小為1的滑動窗口協(xié)議，其實就是停等，只不過這個是雙工的，剛才的停等是單工的信道。

工作流程如下：

1、發(fā)收雙方窗口大小都為1，初始窗口狀態(tài)都一樣，發(fā)送方準(zhǔn)備發(fā)送序號為0的數(shù)據(jù)，接收方等待接收序號為0的數(shù)據(jù)，

2、發(fā)送方發(fā)送數(shù)據(jù)，把該數(shù)據(jù)標(biāo)記為已發(fā)送待確認(rèn)

3、接收方收到數(shù)據(jù)，crc確認(rèn)后將數(shù)據(jù)交給上層，發(fā)送ack給發(fā)送方，并同時把窗口向右滑動，表示下一個待收的數(shù)據(jù)序號為1

4、發(fā)送方收到ack，將窗口向右滑動，準(zhǔn)備發(fā)送下一個序號為1的數(shù)據(jù)，如此反復(fù)。

問題：這樣對于一些帶寬時延積較大的信道，會導(dǎo)致低效，比如衛(wèi)星信道，數(shù)據(jù)的發(fā)送時延很短，但是傳播時延很長，發(fā)送方花了很短的時間將數(shù)據(jù)發(fā)送出去，剩下很大一部分時間都在等待數(shù)據(jù)發(fā)給接收方，然后接收方回ack，時間主要都用到這兩次傳播時延上了，效率很低。

五、Protocol Using Go Back N

還是滑動窗口，這次發(fā)送窗口有很多，但是接收窗口還是一個，這個協(xié)議采用了累計ack的方法。

1、正常情況

看這個正常情況的例子，發(fā)送窗口大小是3，按順序發(fā)0、1、2幀，接收方一開始窗口在0那，收到0號幀之后，由于是累計確認(rèn)，所以不發(fā)ack，把窗口向右滑，等待1號幀，收到1號幀后，滑動窗口，回一個ack1，表示0和1號幀都收到了，發(fā)送方收到這個之后，就明白了，就把窗口向右滑動兩個。這里有一個問題，那就是累計確認(rèn)的話，什么時候選擇回ack呢，如果收到的幀一直都是對的，遲遲不回，發(fā)送方豈不是會超時。

2、丟數(shù)據(jù)

看這個例子，發(fā)送方發(fā)送0、1、2，接收方收到0、1后回了ack1，發(fā)送方滑動兩個窗口，接著發(fā)3號幀，可是這時2號幀丟了，接收方收到3號幀后，發(fā)現(xiàn)這不是我要的啊，我要的是2號幀，他就丟棄，并且回一個ack1，表示并沒有受到2號幀。?這是有一個問題，那就是只有收到幀校驗和對的時候，才會回ack，例如這里3號幀如果校驗和不對，那就不會回ack1，因為校驗和不對時，序號就沒有意義了，有可能是錯的。然后繼續(xù)，發(fā)送方?jīng)]有收到ack2和ack3，2、3號幀就會依次超時，并重傳。

3、ack丟失

考慮一個極端情況，發(fā)送方發(fā)送0、1、2號幀，接收方都正確收到并滑動了窗口，并且回了ack，可是ack全丟了，這時接收方窗口在等3號幀，發(fā)送方0號幀超時重傳，接收方收到后發(fā)現(xiàn)不是我要的幀，就會丟掉，回一個我正在等的幀序號的前一個序號，比如這里等的是3號幀，回的ack就是ack2。這時發(fā)送方收到ack2后，就知道前三個幀都收到了，就會往右滑三次窗口。

4、窗口大小問題

窗口大小和序號的二進(jìn)制位數(shù)有關(guān)，對于n比特位的序號來說，發(fā)送窗口和接收窗口的大小的和需要小于等于2的n次方。對于GBN協(xié)議來說，接收窗口大小是1，那發(fā)送窗口大小就要小于等于2的n次方減一。

如何考慮窗口大小的問題呢，只需要考慮一種極限情況，那就是發(fā)送窗口把所有幀全發(fā)出去了，接收方的ack全丟了，這時候接收窗口不能和發(fā)送窗口有重疊，有重疊就有問題。

看這樣一個例子

這里n=2，按照原理，發(fā)送窗口大是3，考慮發(fā)送和窗口是4的情況，也就是右邊這張圖，發(fā)送方發(fā)了0、1、2、3號幀，接收方全部正確收到并回了ack，可是全丟了，這時接收方在等待新的0號幀，可是這時發(fā)送方重傳了上一次的0號幀，而接收方收到后，會誤以為這時新的0號幀，那么就出錯了。

5、問題

問題就在于這個go back n，可能發(fā)送方發(fā)了8個幀，除了第二幀別的都對了，可這樣發(fā)送方還是得重傳2號幀以及他之后的所有幀，這樣效率太低了。

六、Selective Repeat（選擇重傳） ARQ

選擇重傳其實就是上一個GBN得改進(jìn)，把接收方窗口擴(kuò)大了，遵循的窗口大小原則還是一樣

Wt是發(fā)送窗口大小，Wr是接收窗口大小，第一條的原因和上一個協(xié)議一樣，第二條的原因是接收窗口的大小大于發(fā)送窗口是沒有意義的。

這里涉及一個ack timer的問題，接收方收到數(shù)據(jù)后，會設(shè)置一個timer，等待高層的數(shù)據(jù)，看能不能稍待確認(rèn)過去，如果timer過了還沒有高層的數(shù)據(jù)，那么就會發(fā)送ack。這里這個timer的時間需要考慮，發(fā)送方發(fā)送數(shù)據(jù)過來，接收方設(shè)置timer，timer超時回ack，這是三段時間，發(fā)送方發(fā)過來數(shù)據(jù)的時間加上ack回去的時間是一個RTT，也就是說，RTT加上timer必須要小于發(fā)送方超時重傳的timer。

你是否還在尋找穩(wěn)定的海外服務(wù)器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機(jī)房具備T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確流量調(diào)度確保服務(wù)器高可用性，企業(yè)級服務(wù)器適合批量采購，新人活動首月15元起，快前往官網(wǎng)查看詳情吧

網(wǎng)頁標(biāo)題：【計算機(jī)網(wǎng)絡(luò)】流量控制協(xié)議-創(chuàng)新互聯(lián)
標(biāo)題路徑：http://weahome.cn/article/edsec.html