TCP RFC793,请教个问题

叶叶叶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.
   

复制代码

我想问两个问题：
1. 为什么 SEG.ACK 要大于 SND.UNA ,不能等于？ SND.NXT 是下一个要发送的序列号，可以等于 SEG.ACK ？
2. 一个segment 的序列号与长度的和小于或等于收到的ACK，就能说明这个segment 是被应答了？难道不会出现后发的segment 先被应答的情况吗？

大家是怎么理解的？

叶叶叶Yeah

为什么我的问题没人回复？
我要先混个脸熟么？

shan_ghost

没仔细研究过这个。不过tcp的一般流程是：

1、接收端通知发送端还可以接受多少数据（滑窗剩余空间），设为n K

2、发送端发送至多n K数据（可能分为N个包），并为这些包设置“重传计时器”

3、接收端每收到一个数据包（且验证无误），就发一个ack，表示该包（以及在它之前的包）都已经正确收到
这个ack包可延缓发送，即用一个ACK表示“直到序号为XXX的数据都已经收到”

4、发送端收到ack，就不再缓冲这些包（否则，如果重传计时器时间到仍未收到ACK，就会自动重传）

5、如果接收端收到乱序包，要立即发一个DUP ACK，表示“该序号对应的包尚未收到，但收到了后续的包”

6、发送端发现DUP ACK包，记录它的序号，记录它出现了多少次
过去的方案是：一旦发现三次（相同序号的）DUP ACK，就进入“快速重传”，即不等重传计时器超时，就立即重发该包。这可以避免进入拥塞控制逻辑。
后来发现链路上包乱序现象非常多见，相关算法就被改进了。新的算法通过动态决策，大大减少了“快速重传包”的数量。


大致上就是这些。至于ACK包的序号如何确定之类问题，偶还没注意过。

叶叶叶Yeah

回复 5# shan_ghost


    如果需要按顺序接收，那么在收到一个数据分节（segment）时为什么只检测分节里的序列号是否在接收窗口，而没有检测是否按顺序？
是不是RFC文档没有规定这些？
是不是TCP 收到一个数据分节后把它暂存起来？ 这个时候TCP不会发送ACK 吗？

shan_ghost

叶叶叶Yeah 发表于 2013-12-10 00:22
如果需要按顺序接收，那么在收到一个数据分节（segment）时为什么只检测分节里的序列号是否在接收窗口，而没有检测是否按顺序？

是不是RFC文档没有规定这些？

是不是TCP 收到一个数据分节后把它暂存起来？ 这个时候TCP不会发送ACK 吗？

1、TCP保证上层应用看到的数据是有序的、可靠的；但TCP协议本身不要求来自网络的数据按顺序到来，且不出错、不丢包。

2、RFC有详细规定……不过偶只仔细看过快速重传、TCP windows相关方面的内容

3、不仅TCP在收到一个数据包后要把它暂存起来；发送端也要把发过的数据包暂存起来，只有收到ACK包才可以把数据从缓存中删除。

这其实就是TCP保证数据可靠性的具体机制： 发送方发一个包，但不能确定这个包可以被对端正确接收；所以它必须暂时缓存这个包，直到对端用ACK报告了“包XXX正确收到”这个信息。
如果超过一定时间收不到ACK，它就必须利用缓存里的备份重新发送该包。


而在接收端，如果收一个包就必须发一个ACK、且必须等接收端收到后才能继续；那么，对一个100ms延迟的网络，就意味着这套机制限制每200ms才能传输一个数据包。这显然是绝对无法接受的。

为解决这个问题，接收端就使用了一个叫做“滑动窗口”的特殊缓冲区。这就允许发送方可以连续发送总大小不大于这个缓冲区的数据；接收端则应尽快向发送方报告哪些包已经收到。
——事实上，发送端的发送缓冲区也是一个“滑动窗口”。


实际上，TCP接受到的数据，最终是要传送给上层应用程序的。所以，只有按顺序到达的那些数据才可以“搬”到应用程序的接收缓冲区（这个说法不够精确，但能尽量清晰的表达逻辑关系），从而为“滑动窗口”腾出更多空间（或者叫 允许滑动窗口左边界向右移动）——对于发送端，情况是一样的；不同的是，它是以收到ACK而不是“数据已移入应用读缓冲区”，作为移动滑动窗口的条件。

而不按顺序到达的数据呢，如果N+1、N+2先于N到了，那就先缓存N+1和N+2,等N到了、填补了空洞，再通过ACK报告“N+2及之前的所有包都已收到”。

因此，ACK报告的状态必须关联于“和前面数据连续的、最后一个包的尾部”，这才能保证滑窗正确动作。



最后，未按顺序到达的包，也可以使用SACK报告已经正确收到（SACK=selective ack，即选择性ACK：这个是后来的扩展，初期的TCP协议并没有定义这个）。
这可以避免出现“包N丢包，结果从N到N+M的所有包都被重发”问题。

另一种机制则是，当N尚未到、而N+1、N+2、N+3已经到达时，可以在N+1、N+2、N+3到达时反复报告N-1收到,这就是dup ack（重复的ACK）。
发送端发现dup ack，就说明接收端出现了乱序。当dup ack连续出现k次时，就说明包N可能已经丢了。此时它就可以不等重传计时器超时，立即重传包N。
这个机制可以避免滑动窗口长时间无法“滑动”（除非发送端重传计时器超时），进而避免进入拥塞控制逻辑（此时TCP协议认为网络带宽不足，会导致数据传输速率减半，需要较长时间才能恢复）；但不合适的k值可能导致重传一些没有丢失的包（比如，当k为3,而包N乱序深度达到了6）。
早期，K值固定为3；现在则可通过一些机制来动态调整k值（或者改用时间控制）。

shan_ghost

总之，这个东西的核心是 滑窗算法；而要理解滑窗算法，就必须先搞明白这个算法是要解决什么问题、如何解决、具体机制如何、解决过程是否如同预期、有哪些意外、如何解决这些意外……

按照这个脉络，整个TCP协议就非常容易理解了。

peijue

回复 7# shan_ghost


    受教了。