TCP RFC793,請教個(gè)問題

葉葉葉Yeah

RFC793
3.3. Sequence Numbers 里面有段話，沒看明白

1. A new acknowledgment (called an "acceptable ack"), is one for which
   
2.   the inequality below holds:
   
3. 
   
4.     SND.UNA < SEG.ACK =< SND.NXT
   
5. 
   
6.   A segment on the retransmission queue is fully acknowledged if the sum
   
7.   of its sequence number and length is less or equal than the
   
8.   acknowledgment value in the incoming segment.
   

復(fù)制代碼

我想問兩個(gè)問題：
1. 為什么 SEG.ACK 要大于 SND.UNA ,不能等于？ SND.NXT 是下一個(gè)要發(fā)送的序列號(hào)，可以等于 SEG.ACK ？
2. 一個(gè)segment 的序列號(hào)與長度的和小于或等于收到的ACK，就能說明這個(gè)segment 是被應(yīng)答了？難道不會(huì)出現(xiàn)后發(fā)的segment 先被應(yīng)答的情況嗎？

大家是怎么理解的？

葉葉葉Yeah

為什么我的問題沒人回復(fù)？
我要先混個(gè)臉熟么？

shan_ghost

沒仔細(xì)研究過這個(gè)。不過tcp的一般流程是：

1、接收端通知發(fā)送端還可以接受多少數(shù)據(jù)（滑窗剩余空間），設(shè)為n K

2、發(fā)送端發(fā)送至多n K數(shù)據(jù)（可能分為N個(gè)包），并為這些包設(shè)置“重傳計(jì)時(shí)器”

3、接收端每收到一個(gè)數(shù)據(jù)包（且驗(yàn)證無誤），就發(fā)一個(gè)ack，表示該包（以及在它之前的包）都已經(jīng)正確收到
這個(gè)ack包可延緩發(fā)送，即用一個(gè)ACK表示“直到序號(hào)為XXX的數(shù)據(jù)都已經(jīng)收到”

4、發(fā)送端收到ack，就不再緩沖這些包（否則，如果重傳計(jì)時(shí)器時(shí)間到仍未收到ACK，就會(huì)自動(dòng)重傳）

5、如果接收端收到亂序包，要立即發(fā)一個(gè)DUP ACK，表示“該序號(hào)對應(yīng)的包尚未收到，但收到了后續(xù)的包”

6、發(fā)送端發(fā)現(xiàn)DUP ACK包，記錄它的序號(hào)，記錄它出現(xiàn)了多少次
過去的方案是：一旦發(fā)現(xiàn)三次（相同序號(hào)的）DUP ACK，就進(jìn)入“快速重傳”，即不等重傳計(jì)時(shí)器超時(shí)，就立即重發(fā)該包。這可以避免進(jìn)入擁塞控制邏輯。
后來發(fā)現(xiàn)鏈路上包亂序現(xiàn)象非常多見，相關(guān)算法就被改進(jìn)了。新的算法通過動(dòng)態(tài)決策，大大減少了“快速重傳包”的數(shù)量。


大致上就是這些。至于ACK包的序號(hào)如何確定之類問題，偶還沒注意過。

葉葉葉Yeah

回復(fù) 5# shan_ghost


    如果需要按順序接收，那么在收到一個(gè)數(shù)據(jù)分節(jié)（segment）時(shí)為什么只檢測分節(jié)里的序列號(hào)是否在接收窗口，而沒有檢測是否按順序？
是不是RFC文檔沒有規(guī)定這些？
是不是TCP 收到一個(gè)數(shù)據(jù)分節(jié)后把它暫存起來？ 這個(gè)時(shí)候TCP不會(huì)發(fā)送ACK 嗎？

shan_ghost

葉葉葉Yeah 發(fā)表于 2013-12-10 00:22
如果需要按順序接收，那么在收到一個(gè)數(shù)據(jù)分節(jié)（segment）時(shí)為什么只檢測分節(jié)里的序列號(hào)是否在接收窗口，而沒有檢測是否按順序？

是不是RFC文檔沒有規(guī)定這些？

是不是TCP 收到一個(gè)數(shù)據(jù)分節(jié)后把它暫存起來？ 這個(gè)時(shí)候TCP不會(huì)發(fā)送ACK 嗎？

1、TCP保證上層應(yīng)用看到的數(shù)據(jù)是有序的、可靠的；但TCP協(xié)議本身不要求來自網(wǎng)絡(luò)的數(shù)據(jù)按順序到來，且不出錯(cuò)、不丟包。

2、RFC有詳細(xì)規(guī)定……不過偶只仔細(xì)看過快速重傳、TCP windows相關(guān)方面的內(nèi)容

3、不僅TCP在收到一個(gè)數(shù)據(jù)包后要把它暫存起來；發(fā)送端也要把發(fā)過的數(shù)據(jù)包暫存起來，只有收到ACK包才可以把數(shù)據(jù)從緩存中刪除。

這其實(shí)就是TCP保證數(shù)據(jù)可靠性的具體機(jī)制： 發(fā)送方發(fā)一個(gè)包，但不能確定這個(gè)包可以被對端正確接收；所以它必須暫時(shí)緩存這個(gè)包，直到對端用ACK報(bào)告了“包XXX正確收到”這個(gè)信息。
如果超過一定時(shí)間收不到ACK，它就必須利用緩存里的備份重新發(fā)送該包。


而在接收端，如果收一個(gè)包就必須發(fā)一個(gè)ACK、且必須等接收端收到后才能繼續(xù)；那么，對一個(gè)100ms延遲的網(wǎng)絡(luò)，就意味著這套機(jī)制限制每200ms才能傳輸一個(gè)數(shù)據(jù)包。這顯然是絕對無法接受的。

為解決這個(gè)問題，接收端就使用了一個(gè)叫做“滑動(dòng)窗口”的特殊緩沖區(qū)。這就允許發(fā)送方可以連續(xù)發(fā)送總大小不大于這個(gè)緩沖區(qū)的數(shù)據(jù)；接收端則應(yīng)盡快向發(fā)送方報(bào)告哪些包已經(jīng)收到。
——事實(shí)上，發(fā)送端的發(fā)送緩沖區(qū)也是一個(gè)“滑動(dòng)窗口”。


實(shí)際上，TCP接受到的數(shù)據(jù)，最終是要傳送給上層應(yīng)用程序的。所以，只有按順序到達(dá)的那些數(shù)據(jù)才可以“搬”到應(yīng)用程序的接收緩沖區(qū)（這個(gè)說法不夠精確，但能盡量清晰的表達(dá)邏輯關(guān)系），從而為“滑動(dòng)窗口”騰出更多空間（或者叫 允許滑動(dòng)窗口左邊界向右移動(dòng)）——對于發(fā)送端，情況是一樣的；不同的是，它是以收到ACK而不是“數(shù)據(jù)已移入應(yīng)用讀緩沖區(qū)”，作為移動(dòng)滑動(dòng)窗口的條件。

而不按順序到達(dá)的數(shù)據(jù)呢，如果N+1、N+2先于N到了，那就先緩存N+1和N+2,等N到了、填補(bǔ)了空洞，再通過ACK報(bào)告“N+2及之前的所有包都已收到”。

因此，ACK報(bào)告的狀態(tài)必須關(guān)聯(lián)于“和前面數(shù)據(jù)連續(xù)的、最后一個(gè)包的尾部”，這才能保證滑窗正確動(dòng)作。



最后，未按順序到達(dá)的包，也可以使用SACK報(bào)告已經(jīng)正確收到（SACK=selective ack，即選擇性ACK：這個(gè)是后來的擴(kuò)展，初期的TCP協(xié)議并沒有定義這個(gè)）。
這可以避免出現(xiàn)“包N丟包，結(jié)果從N到N+M的所有包都被重發(fā)”問題。

另一種機(jī)制則是，當(dāng)N尚未到、而N+1、N+2、N+3已經(jīng)到達(dá)時(shí)，可以在N+1、N+2、N+3到達(dá)時(shí)反復(fù)報(bào)告N-1收到,這就是dup ack（重復(fù)的ACK）。
發(fā)送端發(fā)現(xiàn)dup ack，就說明接收端出現(xiàn)了亂序。當(dāng)dup ack連續(xù)出現(xiàn)k次時(shí)，就說明包N可能已經(jīng)丟了。此時(shí)它就可以不等重傳計(jì)時(shí)器超時(shí)，立即重傳包N。
這個(gè)機(jī)制可以避免滑動(dòng)窗口長時(shí)間無法“滑動(dòng)”（除非發(fā)送端重傳計(jì)時(shí)器超時(shí)），進(jìn)而避免進(jìn)入擁塞控制邏輯（此時(shí)TCP協(xié)議認(rèn)為網(wǎng)絡(luò)帶寬不足，會(huì)導(dǎo)致數(shù)據(jù)傳輸速率減半，需要較長時(shí)間才能恢復(fù)）；但不合適的k值可能導(dǎo)致重傳一些沒有丟失的包（比如，當(dāng)k為3,而包N亂序深度達(dá)到了6）。
早期，K值固定為3；現(xiàn)在則可通過一些機(jī)制來動(dòng)態(tài)調(diào)整k值（或者改用時(shí)間控制）。

shan_ghost

總之，這個(gè)東西的核心是 滑窗算法；而要理解滑窗算法，就必須先搞明白這個(gè)算法是要解決什么問題、如何解決、具體機(jī)制如何、解決過程是否如同預(yù)期、有哪些意外、如何解決這些意外……

按照這個(gè)脈絡(luò)，整個(gè)TCP協(xié)議就非常容易理解了。

peijue

回復(fù) 7# shan_ghost


    受教了。