亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: TCP RFC793,請(qǐng)教個(gè)問(wèn)題 [打印本頁(yè)]

作者: 葉葉葉Yeah 時(shí)間: 2013-12-08 14:35
標(biāo)題: TCP RFC793,請(qǐng)教個(gè)問(wèn)題
RFC793
3.3. Sequence Numbers 里面有段話，沒(méi)看明白

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

復(fù)制代碼

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

大家是怎么理解的？

作者: 葉葉葉Yeah 時(shí)間: 2013-12-08 15:04
為什么我的問(wèn)題沒(méi)人回復(fù)？
我要先混個(gè)臉熟么？

作者: Sevk 時(shí)間: 2013-12-08 21:52
提示: 作者被禁止或刪除內(nèi)容自動(dòng)屏蔽

作者: Sevk 時(shí)間: 2013-12-08 21:54
提示: 作者被禁止或刪除內(nèi)容自動(dòng)屏蔽

作者: shan_ghost 時(shí)間: 2013-12-09 10:48
本帖最后由 shan_ghost 于 2013-12-09 10:50 編輯

沒(méi)仔細(xì)研究過(guò)這個(gè)。不過(guò)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)證無(wú)誤），就發(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)對(duì)應(yīng)的包尚未收到，但收到了后續(xù)的包”

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

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

作者: 葉葉葉Yeah 時(shí)間: 2013-12-10 00:22
回復(fù) 5# shan_ghost

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

作者: shan_ghost 時(shí)間: 2013-12-10 11:32
本帖最后由 shan_ghost 于 2013-12-10 11:46 編輯

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

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

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

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

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

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

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

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

為解決這個(gè)問(wèn)題，接收端就使用了一個(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è)說(shuō)法不夠精確，但能盡量清晰的表達(dá)邏輯關(guān)系），從而為“滑動(dòng)窗口”騰出更多空間（或者叫允許滑動(dòng)窗口左邊界向右移動(dòng)）——對(duì)于發(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ǔ)了空洞，再通過(guò)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è)是后來(lái)的擴(kuò)展，初期的TCP協(xié)議并沒(méi)有定義這個(gè)）。
這可以避免出現(xiàn)“包N丟包，結(jié)果從N到N+M的所有包都被重發(fā)”問(wèn)題。

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

作者: shan_ghost 時(shí)間: 2013-12-10 11:35
總之，這個(gè)東西的核心是滑窗算法；而要理解滑窗算法，就必須先搞明白這個(gè)算法是要解決什么問(wèn)題、如何解決、具體機(jī)制如何、解決過(guò)程是否如同預(yù)期、有哪些意外、如何解決這些意外……

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

作者: Sevk 時(shí)間: 2013-12-10 13:25
提示: 作者被禁止或刪除內(nèi)容自動(dòng)屏蔽

作者: peijue 時(shí)間: 2013-12-10 17:29
回復(fù) 7# shan_ghost

受教了。

作者: 葉葉葉Yeah 時(shí)間: 2013-12-10 23:20
回復(fù) 8# shan_ghost

非常感謝，看完你的講解再對(duì)照RFC文檔，發(fā)現(xiàn)容易理解多了。
真是有風(fēng)度的大牛啊！

謝謝謝謝�。�！

歡迎光臨 Chinaunix (http://www.72891.cn/)