Small count of packets leading to high RTT values

Question

I have a pretty simple client/server application (TCP). 1 instance is sending 40 packets (smoothly distributed through 1 second) with around 1500 bytes data (part of data is timestamp). 2 instance is receiving these packets and sending back another packets with initial timestamp. Now in 1 instance I'm measuring difference between current timestamp and timestamp from packets. So I'm getting somekind of handmade-RTT. Also additionally I'm taking TCP RTT value for sockets with getsockopt and I see clearly:

• My RTT showing me values around 1 ms (which is expected at such low rate of packets)

• TCP RTT showing me ~40ms And I don't get it why. I know exactly that I'm receiving my packets early than 40 ms.

Also, If I will increase packets count from 40 to 600 for example, I will catch TCP RTT as ~150 mcs which is expected for my configuration.

Can anyone explain me this 40 ms from kernel side on low packets count?

Thank you

Answer 1

40ms是Linux上的ACK延迟。这是正在发生的事情：

1. 端A发送的数据包中的数据量少于该数据包可以容纳的数据量。
2. B端收到它并设置40ms ACK定时器。
3. A边的应用程序调用{​​{1}}。但是不会发送数据包，因为数据量少于该数据包可以容纳的数据，并且最后一个数据包所包含的数据少于该数据包可以容纳的数据。因此，该实现方案会等待观察它是否可以在数据包中容纳更多数据，以避免浪费网络带宽。
4. 40ms计时器到期，并且B端发送一个ACK。
5. A方通过中止其延迟并发送现在延迟的数据来响应ACK。

解决这个问题的方法可能非常好，但是我们需要对您的协议和您的实际要求有更多的了解，以便提出有用的建议。不要禁用Nagle。几乎总是最糟糕的“解决方案”。

Answer 2

延迟确认包就是答案。您将得到的数据包更少。