tcpdump 显示数据包，但应用程序显示数据包是突发的答案

【问题标题】：tcpdump shows packets but application shows packets are burstytcpdump 显示数据包，但应用程序显示数据包是突发的
【发布时间】：2017-03-23 01:17:04
【问题描述】：

我正在开发一个无法透露太多信息的系统，但我想我可以描述这个问题，以了解最可能的罪魁祸首在哪里。

我有一个在嵌入式 Linux 系统上运行的应用程序，该系统有一个 TCP 服务器侦听 IP 和端口。它正在等待来自系统外部的外部客户端连接到它，它将接受连接以响应客户端。

客户端预计以大约 120 毫秒或每秒 8 条消息的速率发送消息。当客户端连接时，tcpdump 会验证接口是否以大约 120 毫秒的间隔从客户端接收消息，但服务器应用程序将其视为突发。

突发，因为它收到 X 条消息，然后经过 Y 秒的死寂，然后重复该过程。

应用程序只希望一个客户端连接，并且应用程序是单线程的。有谁知道为什么 Linux 中的 TCP 可能会表现出这种行为？关于在应用程序和 Linux 套接字之间查看位置的任何想法？

注意 1：还有一点要说，我正在为我的应用程序使用 POCO 库。我正在使用 StreamSocket 和 ServerSocket 包装器。 https://pocoproject.org/

注意 2：我还应该指出，情况并非总是如此。有时，我的应用程序会以预期的 ~120 毫秒间隔接收数据包。所以它确实可以正常工作，但是这个错误每隔一段时间就会出现。

【问题讨论】：

【解决方案1】：

即：发送方的数据一起积累，然后一起发送出去，以减少发送单个数据包带来的开销。尝试在客户端设置套接字选项 TCP_NODELAY 看看它是否有效。

要确定真正的原因，服务器/客户端的数据包捕获会有所帮助。

【讨论】：

所以我愿意，但是您要寻找什么？另外每条消息的大小是16字节，响应消息小于这个。
我将首先验证客户端是否每 120 毫秒发送一个数据包，以及服务器是否接收到每个单独的数据包或一个大块数据包。
嗯，tcpdump 有一个与从客户端接收到的每个数据包相关联的时间戳。它显示了约 120 毫秒的间隔 - 这似乎是您声明要验证的第一件事。这几乎意味着它不是 Nagle 算法的罪魁祸首。那你会得出同样的结论吗？
同意。现在在我看来，数据只是在应用层缓冲。要确定，请打印出服务器端接收到的字节数。如果超过 16 字节且与 Nagle 无关，则只是正常的 TCP 应用层行为。