【发布时间】：2012-07-01 19:46:58
【问题描述】：
我正在测量 Windows 上通过环回接口的 TCP/IP 连接的延迟，并且从发送消息到收到响应的时间大约为 4 毫秒。
对于 RPC 目的，在 TCP/IP 之上有一个TCF 层。 除了 TCF 帧之外，发送和接收的消息仅包含一个字符作为有效负载。
处理命令的“服务器”是在 C++ 中使用 boost asio 实现的。 “客户端”发送命令是使用 Python TCF 参考实现的 Python 脚本。
我尝试将套接字选项设置为 TCP_NODELAY 以禁用 Nagle 算法，并尝试了套接字的各种缓冲区大小，但往返时间仍保持在 4 毫秒左右。我原以为它会低一些。
C++ 端的分析表明，它花费了大约 50% 的执行时间等待命令，因此下一步将尝试用 C++ 实现替换 python 脚本，但很高兴知道是什么可以预期回环接口上的往返时间。
这个 SO，问题：
Linux Loopback performance with TCP_NODELAY enabled
是相关的，但没有完全回答我的问题。
【问题讨论】：
-
如果 C++ 端花费了大约一半的时间等待，那么大概它花费了大约一半的时间不等待。如果您对另一方假设相同，则估计延迟为零。所有时间都计算在内。一半的时间花在 C++ 代码的工作上。一半的时间都花在了 Python 代码的工作上。这样就没有时间双方都在工作，这就是在任何 TCP/IP 延迟期间都会发生的事情。 （发送方等待回复，接收方等待接收。双方都在等待。）
-
+1 @DavidSchwartz 的“Spock”回答
-
@DavidSchwarz：+1 我没想到 :-) 谢谢。不过，我非常想知道典型的 TCP/IP 往返时间应该是多少。
-
在 C++ 中实现“客户端”后，命令/响应对的延迟降至 170µs。用手工制作的字符串 json 化替换对 json_spirit 的调用将其缩短到大约 150µs。
标签： c++ windows network-programming boost-asio loopback