ACKs和SEQs背後的理由？

我不知道，如果人們覺得這很明顯，但我有兩個問題：ACKs和SEQs背後的理由？

在3次握手，這是爲什麼ACK = SEQ + 1，即爲什麼我確認序號爲我期待下一個字節來自發件人？
握手後，我的ACK = SEQ + len。爲什麼這與握手有所不同？爲什麼不只是對我期待的下一個字節進行確認（與握手期間一樣）？

我知道我一定錯過了某個基本點。有人可以澄清這一點嗎？

來源

2010-03-01 Legend

這是因爲序列號空間的第一個字節對應於SYN標誌，而不是數據字節。（結尾處的FIN標誌也消耗的序列號空間本身的一個字節。）

來源

2010-03-01 20:00:12

握手期間，您正在同步。序號是已知數據。一旦你同步了，數據長度就是已知的數據以及一個有用的僞隨機驗證器。發件人知道他發了多少，如果你回覆，他就會認爲你已經收到了。這比回覆更容易，比如說校驗和或散列數據，通常就足夠了。

來源

2010-03-01 19:51:31

我明白了......我想我明白了你對握手的看法。但是，爲什麼不只是回覆ACK = SYN只是爲了說「好吧..我有你的SYN編號」？其次，我的第二個問題涉及同樣的事情......我並不是真的建議我們添加一個校驗和或一個散列......從你的回答看來，似乎有一個涉及某個地方的安全概念，但我是仍然試圖找出哪裏... – Legend

不 - 這只是一個驗證。一旦發送者/接收者已經同步，他們需要一種確定接收消息的方式。 AOK是接收者獲得了與發送者一樣多的字節。對雙方都知道的東西。這不是安全。這更像是一個奇偶位，雖然這是一個不準確的比喻。爲什麼在協議上加上一個消息傳遞計數器？它不增加任何價值，只是開銷。 –

SYN和FIN標誌可以使流的序列號增1。因此，

SYN (seq x) --------------> 
          <--- SYNACK (ack x+1, seq y) 
ACK (seq x+1, ack y+1) --->

是你的三次握手。這樣做是因爲SYN和FIN需要確認收到。這樣，在連接的整個生命週期中，每個人都可以在同一頁面上。

理論上在TWHS的一部分的任何分組可以具有有效載荷，但如果任一帶有SYN標誌的集合中的數據包的有效載荷具有，相對側需要確認二者數據和標誌。

來源

2010-03-08 03:57:18 jdizzle

ACKs和SEQs背後的理由？

回答

相關問題