哈工大計算機網(wǎng)絡傳輸層協(xié)議詳解之：可靠數(shù)據(jù)傳輸?shù)幕驹?/h2>
- 哈工大計算機網(wǎng)絡課程傳輸層協(xié)議詳解之：流水線機制與滑動窗口協(xié)議
- 哈工大計算機網(wǎng)絡課程傳輸層協(xié)議詳解之：TCP協(xié)議
- 哈工大計算機網(wǎng)絡課程傳輸層協(xié)議詳解之：擁塞控制原理剖析
可靠數(shù)據(jù)傳輸原理
什么是可靠？
-
不錯、不丟、不亂
可靠數(shù)據(jù)傳輸協(xié)議
-
可靠數(shù)據(jù)傳輸對應用層、傳輸層、鏈路層都很重要
-
網(wǎng)絡Top-10問題
-
信道的不可靠特性決定了可靠數(shù)據(jù)傳輸協(xié)議(rdt)的復雜性
可靠數(shù)據(jù)傳輸可以從不同的角度來看，比如從a圖是從提供的服務來看：
紅線網(wǎng)上是應用層，在發(fā)送方是一個發(fā)送的進程，接收方是一個接收的進程。紅線下面的傳輸層為上層提供可靠的數(shù)據(jù)傳輸服務，雖然從底層來看仍然是不可靠的信道，但是傳輸層通過設(shè)計的策略來實現(xiàn)可靠。
進一步的，從服務的實現(xiàn)角度（b圖）來看，由于底層仍然是一個不可靠的信道，可靠數(shù)據(jù)的實現(xiàn)要在傳輸層借助算法實現(xiàn)，包括了發(fā)送方的可靠數(shù)據(jù)傳輸協(xié)議部分和接收方可靠數(shù)據(jù)傳輸協(xié)議部分。這兩部分相互配合，共同實現(xiàn)可靠的數(shù)據(jù)傳輸協(xié)議。
因為下層仍然是不可靠的信道，因此傳輸層向下調(diào)用的是udt_send方法，即unreliable data send，發(fā)送到信道中。而此時傳輸層對上層來看是一個可靠的傳輸協(xié)議，因此上層調(diào)用的是rdt_send，即reliable data send。
總而言之，這就相當于在傳輸層實現(xiàn)了一套可靠傳輸協(xié)議，并對上層透明，對上層應用來說它所面向的就是可靠數(shù)據(jù)傳輸，盡管底層的信道仍然是不可靠的，也就是a圖中從服務角度來看。
從圖中可以看到，在傳輸層和不可靠信道（比如網(wǎng)絡層）之間是雙向的箭頭，也就是說在不可靠信道上實現(xiàn)可靠的數(shù)據(jù)傳輸，并不是一個簡單的單向數(shù)據(jù)流動就能實現(xiàn)，需要雙向的控制消息的流動。
可靠數(shù)據(jù)傳輸協(xié)議
只考慮單向數(shù)據(jù)傳輸，但是控制信息雙向流動。利用狀態(tài)機（Finite State Machine, FSM）刻畫傳輸協(xié)議
接下來，我們從易到難，逐步遞進來分析一下實現(xiàn)可靠數(shù)據(jù)傳輸?shù)姆桨负土鞒獭?/p>
Rdt 2.0：產(chǎn)生位錯誤的信道
首先我們假定一個簡單的場景，即信道只會產(chǎn)生位錯誤，而不會有其他錯誤產(chǎn)生。
**場景：**傳輸中可能會發(fā)生位錯誤，比如把某個0翻轉(zhuǎn)為1，把某個1翻轉(zhuǎn)為0。目前的場景認為信道只可能發(fā)生這種錯誤，不會發(fā)生分組丟失等其他問題，并且數(shù)據(jù)是按順序到達的。這種場景下來研究位錯誤時，可靠傳輸機制如何來實現(xiàn)。
接收方：
- 需要知道接收的數(shù)據(jù)是否發(fā)生了位錯誤
- 如果發(fā)生了錯誤，需要發(fā)送方重傳
- 需要告訴發(fā)送方出現(xiàn)錯誤，需要恢復數(shù)據(jù)
接收方如何判斷接收的數(shù)據(jù)是否發(fā)生了位錯誤？
利用校驗和檢測位錯誤
如何從錯誤中恢復？
- 確認機制（Acknowledgements, ACK）：接收方顯示地告知發(fā)送方分組已正確接收
- NAK：接收方顯示地告知發(fā)送方分組有錯誤
- 發(fā)送方收到NAK后，重傳分組
接收方顯示的反饋給發(fā)送方一些控制消息：ACK/NAK
基于上述這種重傳機制的rdt協(xié)議被稱為ARQ（Automatic Repeat reQuest）協(xié)議
基于上述思想，設(shè)計如下的有限狀態(tài)機：
發(fā)送方有限狀態(tài)機
此時，發(fā)送方存在兩個有限狀態(tài)：Wait for call from above和Wait for ACK or NAK。
-
第一個狀態(tài)表示等待上層調(diào)用，比如應用層向傳輸層發(fā)送數(shù)據(jù)（rdt_send），接收到數(shù)據(jù)后會調(diào)用make_pkt進行打包，此時會攜帶是數(shù)據(jù)的checksum校驗和，最后調(diào)用udt_send發(fā)送到接收方。
-
第二個狀態(tài)表示等待ACK/NAK控制狀態(tài)的返回，即?！葏f(xié)議。
上述發(fā)送方的有限狀態(tài)機即表示：接收上層協(xié)議的調(diào)用，并將數(shù)據(jù)打包發(fā)送到接收方，同時，停止等待接收方ACK/NAK狀態(tài)信息的返回。如果接收到的是NAK狀態(tài)，則重新執(zhí)行udt_send將數(shù)據(jù)重傳到接收端。如果接收到的是ACK狀態(tài)，則回到第一個狀態(tài)，等待下次調(diào)用。
接收方有限狀態(tài)機
- 只有一個狀態(tài)，表示等待下層協(xié)議的調(diào)用。此時會去判斷接收的數(shù)據(jù)是否有錯誤。如果有錯誤，則調(diào)用udt_send方法返回NAK狀態(tài)，如果沒有錯誤，則返回ACK狀態(tài)。
Rdt 2.1：發(fā)送方。應對ACK/NAK破壞
Rdt2.0有什么缺陷？
如果ACK/NAK消息發(fā)生錯誤/被破壞(corrupted)會怎么樣？
- 為ACK/NAK增加校驗和，檢錯并糾錯
- 發(fā)送方收到被破壞ACK/NAK時不知道接收方發(fā)生了什么，添加額外的控制消息
- 如果ACK/NAK壞掉，發(fā)送方重傳
- 不能簡單的重傳：產(chǎn)生重復分組。比如前一個分組已經(jīng)被接收端正確接收了，但是返回的ACK/NAK壞掉了，導致發(fā)送方重傳，此時就會產(chǎn)生重復分組。
如何解決重復分組問題？
- 序列號（Sequence number）：發(fā)送方給每個分組增加序列號
- 接收方丟棄重復分組
發(fā)送方有限狀態(tài)機
此時發(fā)送方的有限狀態(tài)機設(shè)計如下所示：
假設(shè)這里使用兩個序列號，0和1，可以看到狀態(tài)機的狀態(tài)翻倍了，因為要停止等待不同序列號下數(shù)據(jù)的ACK/NAK。這里在make_pkt方法中攜帶了每個數(shù)據(jù)包對應的序號，此時對于上述重傳可能產(chǎn)生分組重復的問題，相同序號的數(shù)據(jù)包會在接收到被丟棄。
接收方有限狀態(tài)機
可以看到有限狀態(tài)機的狀態(tài)也翻倍了，分別等待接收序號為0和1的數(shù)據(jù)包。
Rdt2.1 vs Rdt2.0
發(fā)送方
- 為每個分組增加了序列號
- 兩個序列號就夠用，為什么？
- 需校驗ACK/NAK消息是否發(fā)生錯誤
- 狀態(tài)數(shù)量翻倍
- 狀態(tài)必須記住當前的分組序列號
接收方
- 需判斷分組是否重復
- 當前所處狀態(tài)提供了期望收到分組的序列號
- 注意：接收方無法知道ACK/NAK是否被發(fā)送方正確收到
Rdt 2.2：無NAK消息協(xié)議
實際上，我們并不需要兩種狀態(tài)來表示接收方是否正確接收數(shù)據(jù)。
與rdt2.1功能相同，但是只使用ACK，如何實現(xiàn)？
- 接收方通過ACK告知最后一個被正確接收的分組
- 在ACK消息中顯式地加入被確認分組的序列號
- 發(fā)送方收到重復的ACK之后，采取與收到NAK消息相同的動作，重傳當前分組。
Rdt2.2 狀態(tài)機片段
Rdt3.0：如果信道既可能發(fā)生錯誤，也可能丟失分組，怎么辦？
”校驗和 + 序列號 + ACK + 重傳”夠用嗎？
如果發(fā)送方發(fā)送的一個數(shù)據(jù)分組在信道中丟失了，此時發(fā)送方和接收方分別會采取什么反應？
此時，接收方?jīng)]有收到數(shù)據(jù)，則什么也不做，仍然一直等待接收數(shù)據(jù)。而發(fā)送方則會一直等待接收方反饋的狀態(tài)信息（狀態(tài)機停留在Wait for ACK狀態(tài)）。在這種情況下，這個分組就完全丟失了，變成不可靠傳輸了。
又或者，數(shù)據(jù)分組到達接收方，但是接收方返回的ACK在信道中丟失了，此時發(fā)送方也會一直等待下去，此時這個協(xié)議就不能正常工作了，也就是上面的Rdt2.2的機制就不夠用了
怎么解決上述問題？
解決方案也很簡單：超時重傳。
即發(fā)送方等待“合理”的時間，如果超時沒收到ACK，則重傳。
同時，由于存在分組或ACK只是延遲而不是丟失，導致的超時后，數(shù)據(jù)重復的問題，仍然采用上述Rdt2.1機制中介紹的序列號的方法：
- 發(fā)送端發(fā)送數(shù)據(jù)時加上序列號，接收方對于重復的序列號遺棄。
- 接收方返回ACK時，需要在ACK中顯式的告知所確認的分組序號
Rdt3.0有限狀態(tài)機圖例：
從上圖中可以看出：
- 在接收到上層的數(shù)據(jù)后，發(fā)送端除了將數(shù)據(jù)包發(fā)送出去外，還會啟動一個定時器(start_timer)，然后進入等待ACK的狀態(tài)。
- 這里
Wait for ACK狀態(tài)中，多了一種狀態(tài)轉(zhuǎn)移條件，即timeout。如果timeout超時，則觸發(fā)udt_send重傳數(shù)據(jù)。
Rdt3.0工作的幾種場景
右圖的timeout即顯示了當丟失了packet時，等待超時時間后，發(fā)送方重傳packet，此時當數(shù)據(jù)包丟失時，rdt3.0仍能正常工作。
C圖表示了當接收方返回的ACK1丟失時，發(fā)送方再等待timeout時間后，對數(shù)據(jù)包進行了重傳。此時，由于接收方會接收到兩個pkt1，即重復的packet，由于有序號機制，接收方發(fā)現(xiàn)存在兩個相同序列號的數(shù)據(jù)包，會丟棄剛剛收到的這個pkt1的數(shù)據(jù)包，并重發(fā)ACK1。在這種場景下，即使ACK丟失了，rdt3.0機制仍能正常工作。
D圖表示了ACK沒有丟失，只是延遲到達的場景。此時，發(fā)送端在等待timeout時間后對pkt1數(shù)據(jù)包進行了重傳，然而此時發(fā)送方才收到ACK1的返回。這種情況接收方也會出現(xiàn)接收到重復分組的問題，但是由于存在序列號機制，接收方仍然可以根據(jù)序列號丟掉重復的分組。而發(fā)送方也會接收到兩個重復的ACK1的返回，根據(jù)上圖中發(fā)送方的有限狀態(tài)機狀態(tài)可以發(fā)現(xiàn)，由于在前一個ACK1到達后，發(fā)送端就發(fā)送pkt0的數(shù)據(jù)了，因此停留在等待ACK0響應的狀態(tài)，因此第二個ACK1不會引起狀態(tài)機的狀態(tài)轉(zhuǎn)移，相當于也會被接收方丟棄。（因為是示例，所有圖中只有兩個狀態(tài)，實際上TCP在解決這個問題時，會丟棄返回的ACK序號小于當前發(fā)送數(shù)據(jù)包序號的ACK）。因此這種場景下，即使ACK重復，rdt3.0機制仍能正常工作。
到此我們的rdt3.0機制中解決了之前多個場景下的問題，引入了序號機制、超時重傳機制等。
Rdt3.0性能分析
Rdt3.0能夠正確工作，但相對來說性能很差，特別是當帶寬速率很高的時候
示例：比如存在一個1Gbps的鏈路，由于鏈路比較長，存在15ms端到端的傳播延遲，假定發(fā)送的每個分組大小是1KB
則此時的分組的在該鏈路上的傳輸時間為：
即需要8s，可以將一個分組從這個鏈路上發(fā)送出去。由于rdt3.0是一個停等協(xié)議，因此發(fā)送完數(shù)據(jù)分組后，會停止等待ACK的返回。
由于端到端的傳播延遲為15ms，因此rtt約等于30ms（一個來回）。
發(fā)送方利用率：發(fā)送方發(fā)送時間百分比：
相當于在1Gbps鏈路上，每30ms才發(fā)送一個分組 -> 33KB/sec
網(wǎng)絡協(xié)議限制了物理資源的利用
rdt3.0導致的性能較差的原因，本質(zhì)上就是因為停止等待協(xié)議。文章來源：http://www.zghlxwxcb.cn/news/detail-517691.html
總結(jié)
上面我們通過自己設(shè)計可靠傳輸協(xié)議的方式，來層層遞進地展示可靠性傳輸算法所要解決的問題和實現(xiàn)原理。更進一步的，借助于有限狀態(tài)機的狀態(tài)更新來標識可靠性傳輸步驟，其中如果能吃透有效狀態(tài)機在可靠性傳輸過程中的狀態(tài)轉(zhuǎn)換，會很有助于我們自己理解可靠性傳輸?shù)臋C制和原理。文章來源地址http://www.zghlxwxcb.cn/news/detail-517691.html
到了這里，關(guān)于哈工大計算機網(wǎng)絡傳輸層協(xié)議詳解之：可靠數(shù)據(jù)傳輸?shù)幕驹淼奈恼戮徒榻B完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
