c# - TCP/IP Windows 7 环回适配器上的数据包延迟问题(或软件错误？)

Question

我们有一个客户端和服务器应用程序目前正在同一台 Windows 7 64 位机器上进行测试。它们都是用 C# 编写的，并使用 P/Invoke 调用 Winsock2 库。

该应用程序总体上运行良好，没有任何错误。 tcp/ip 上每个“跃点”的延迟平均约为 350 微秒。

但是，有时在接收数据包之前会有超过 40 到 50 毫秒的非常长的延迟，然后突然它们就会全部到达。

目前诊断的努力:

1. 在接收数据的这些延迟期间，服务器会继续记录它正在发送数据包。它设置为每 1 毫秒发送一次测试数据包，在客户端收到任何数据包之前，它会持续 15 或 20 毫秒，有时甚至多达 50 毫秒。

2. tcpdump 用于嗅探环回适配器上的数据包，并显示在此延迟期间，从服务器端口 (6488) 到客户端端口 (61743) 的流量照常。

   <

3. 客户端在循环中调用 select() winsock2 调用，因此在 select() 调用之前通过计数器进行记录显示它具有正确的文件描述符。当然，这在延迟前后都可以正常工作。

4. 在 select() 调用之后的进一步记录显示 fd 不存在——这意味着对套接字的读取将被阻止。但是，在没有任何延迟的传输期间，日志记录显示它按预期工作，因此 select() 返回套接字的 fd 以执行非阻塞读取。

简而言之，环回适配器似乎将这些数据包在某个地方保存了很长时间，然后才最终将它们传送到接收方。

任何进一步的想法或解决方案？

一些想法是，人们经常声称重叠 I/O 在 Windows 上工作得更好，但如果您需要监听超过 64 个套接字，这似乎只对可伸缩性有影响。

切换到重叠是否可以解决问题？我们希望避免这样做，因为这会增加项目的截止日期和预算。这应该可以与 select() 配合使用。

此外，Windows 中处理环回的进程或线程是否会进行上下文切换或其他事情，如果是这样，是否有办法对其进行配置以避免这些延迟？

编辑:正确答案是确保禁用 Nagle 算法。我们认为它已被禁用，但这是发现错误的地方——在我们内部实现的 SetSocketOption() 中，我们使用 GetSocketOption() 来验证。所以事实证明，您必须在连接或绑定(bind)套接字之前设置 NoDelay，否则它会默默地失效。

非常感谢 Fun Mun Pieng 的正确答案!!!

Answer 1

我怀疑这可能是由于 Nagle algorithm .以下代码将其禁用:

socket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, true);