所考虑的应用程序（服务器）有许多连接的客户端。它处理来自客户端的每条消息并发送两条输出消息。输出消息按顺序生成并写入套接字。我观察到，有时客户端的第二条输出消息会延迟很长时间。我正在尝试了解其中的原因。
下面是从客户端捕获的应用程序和客户端之间经过过滤的 TCP 流。
- 14908是客户端输入的消息。 14910和15337是两个输出消息
- 14910没有延迟。但15337延迟了40ms左右。
- 正如我所看到的，直到收到 ack 15336 才发送 15337 数据包。
如果套接字不返回 EWOULDBLOCK 或 EAGAIN ，应用程序将数据包发送到 TCP 层。我假设套接字没有被阻止，因为 #14908 中发布的窗口是 1424 并且 #15336(len=229) 不应该将其发送到 EWOULDBLOCK。
那么你能帮我理解是什么原因导致TCP层延迟发送#15337直到确认#15336吗？
答案1
14908是客户端输入的消息。 14910 和 15337 是两个输出消息。
14910 是对客户端的响应，显然设置了 PSH 标志，因此服务器立即发送。然后服务器等待客户端的 ACK，然后发送 15337。
14910没有延迟。但15337延迟了40ms左右。
这是 ACK (15336) 从客户端传输到服务器、服务器处理它以及下一个数据包从服务器传输到客户端所需的时间。
正如我所看到的，直到收到 ack 15336 才发送 15337 数据包。
正确的。这就是 TCP 的一般运行方式。
那么您能帮我了解导致这种延迟的原因吗？
您绝对没有提供足够的信息，我们无法为您提供任何确定的答案。您还通过提供经过过滤的捕获的图像而不是捕获的图像来限制我们的理解。
您可以注意到，数据包 15337 和数据包 15756 之间存在大致相同的时间差（略短，分别为 39.87 毫秒和 39.93 毫秒）。此交换之间的数据包计数差异为 419，而第一个交换的数据包计数为 426。
因此，最好的猜测是，这种“延迟”是客户端在将 ACK 发送到服务器和下一个数据包从服务器到达之间发送/接收大量其他流量的结果。
我无法告诉您更多信息，因为我没有数据包捕获，也无法告诉您其他流量可能是什么。我也无法告诉您客户端正在运行哪种硬件或者客户端可能承受多少负载。但无论如何，所有这些细节都超出了本网站的范围。