超时重传和累积确认是否会冲突？

[soloopin]

超时重传和累积确认是否会冲突？
累积确认的一个ack会确认累积到某一序列号的所有包，这个过程会不会导致最先到达的那个包的确认超时？

[zzz_zou]

不会。 累计确认的过程中超时了，就会重传。

[xumaojun]

ack确认机制已经保证了不会，好像极限情况是：ack中的编号增长到最大后又开始循环可能导致冲突。

[soloopin]

假设接收方为B，发送方为A，A给B先后发送1，2，3，4，5这5个包，B想等5个都接收到之后才最后发送一个5的累积确认包，但A此时才发送了1，2，3，4这四个包，这时候1的确认已经超时，A需要再给B发送一个1，那么对于B来说，是等到A发完5这个包再给A累积确认5的包，还是立即给1一个确认包？ ------------- TCP的这些细节太多了，很多都不太理解，希望大牛帮忙解答一下，谢谢~~

[UDX协议]

累积确认，是在ACK丢失时出现的。也就是只要最后一个ACK到达就可以确认前面所有的速度。 快速重传和超时重传，还有累积确认是完全不一样的概念 我们正确的做法是，都能够用快速重传，因为基本上是只耽误了一个RTT就进行了重传，但是，如果没有这样的A CK（sack）进行快速度重传，那么多个ACK到来时，就出现了累积确认，结合，TCP的收到两到三个重复ACK的时候，就进行快速重传了，这里，2，3个ACK,有可能就是2到3个rtt，最好也是一个RTT + 两个ACK时间间距，所以协带SACK的ACK是多么的牛BBBBB和重要啊。 超时重传是主动的轮询发送时间超过自己设置的超时时间被动发起的。这样的做法，使随之而来的ACK也晚很多而来，造成重传严重滞后。 所以，最好是，快速重传，》累积ACK重传，》超时重传。 在做UDP可靠传输时，这些概念很重要。结合其他方法，可以作出非常不错的协议。 大家可以了解我写的UDX协议，也是一种UDP可靠传输协议，如果你认为你的协议超级牛B,或者发现UDX哪里存在缺陷，在哪些网络上表现不好，请与我联系。 我喜欢交流，比较，更喜欢从中学习你的经验和技术。 QQ 24508609，让我们一起搞基吧。

[zzz_zou]

TCP发送一个数据包，在一定时间内没有收到ACK，那么就超时重传了。 快速重传是指收到3个以上同样的ACK后采取的手段。和超时重传完全不同，是走拥塞控制路线。 顺便问下LS 基于UDP的可靠传输协议不是有UDT了吗？

[UDX协议]

UDT,拥塞实现的不太理想。