上下行数据传输时ACK包的回复时间间隔有多大？

mobileice

请问大家，UE在与服务器进行数据传输的时候，上下行ACK包的回复时间间隔有多大？比如，UE上行发送TCP数据包后，服务器多长时间内应该发送下行的ACK呢？服务器发送下行TCP数据包，UE应该在多长时间内回复上行ACK呢？谢谢大家！

mobileice

昨天看到一个log，在log中看到，上下行ACK包的回复时间间隔超过6S的时，对端就会发送FIN，不知道这是标准制定的还是依赖于设计方式？
谢谢！

gaohui2008

根据记忆中TCP协议，对收到的报文应该立即发ACK，但为了提高效率，可以等毫秒级的时间，等有效信息一起发送。不过这个时间几乎可以忽略，因为这个处理时延要远远小于分组网传输时延。如果一端到发送的报文在规定的时间内没有收到ACK，会超时重传没有收到ACK消息的报文，如果重发3次（可修改）都没收到ACK，会终止这个连接，超时重传定时器根据RTT（一个来回时间）动态计算得出，这个时间不是确定值，所以断开TCP的时间也可能不确定。

爱卫生

回复 gaohui2008 的帖子

  非常专业的回答啊！果然是高手啊！学习了！非常感谢！

mobileice

回复 gaohui2008 的帖子

非常感谢你的回复，很专业，谢谢！

tobino1

学习了、、

kinghighland

回复 gaohui2008 的帖子

也许接收方是收到报文后立即应答的，但是发送方并未作此假设，相反，出于效率的考虑，发送方会在收到应答之前，连续发送多个报文。

TCP传输控制协议把传输管道定义为长宽管道，长为RTT，宽为带宽。在流控过程中，可以连续发送多少个分组而不需要停下来等待ACK，这个个数的计算是基于长宽管道来进行的。
简单的说，就是带宽乘以RTT再除以分组大小，也就是在把管道塞满之前不用等待应答。
在应答的时候，接收方通过应答最近收到的报文（要求最近接收字节的偏移量+1）来完成一次应答多个报文的目的，意味着之前的全收到了，尽管发下一个吧。
同样，如果之前的没有全收到，接收方会应答这些没收到的报文中最早的一个，这个时候那些已经收到的报文也存在再次被发送的概率。为了解决这个问题，TCP也支持选择性应答方案，此时接收方可以一次应答多个报文（逐个点名那些未正确接收的报文）。

gaohui2008

回复 kinghighland 的帖子

很久没有到这个网站了，今天看了你的回帖，感觉又对又不全对。你说的是TCP流控机制，并且是TCP流控机制的目的，题目问的是确认机制。发送方确认机制是会根据RTT做出超时假设的，如果以一个TCP连接建立后第一包为例更能说明问题，此时拥塞窗口是1，相当于一应一答，就不会混淆了。