我在Azure上看到过很多关于在WCF中禁用Nagle算法的帖子。我一直想知道这是否仅适用于Azure，或者这应该是更通用的最佳实践。
如各种来源所述，Nagle算法基本上将小TCP请求批处理为一个更大的请求。批处理基于每个连接进行。
我在专业环境中看到的大多数WCF传输都是小块数据，由单个线程发送，主要是双向传输。我知道这对于Nagle算法来说并不是理想的情况。
那么......我的结论是否正确，在使用WCF或SOAP时，无论上下文如何，最好只始终禁用它？
答案 0 :(得分：3)
据我了解，Nagle的算法只有在数据以小块的形式以低于网络吞吐量的速率流式传输时才有用。例如，如果它是某个硬件传感器的视频输入或恒定输出（实时无关紧要，但历史记录确实如此）。 想象一下极端情况 - 所有这些数据都是在没有Nagle算法的情况下逐字节发送的，基本上将流量乘以41。
相反，当数据写入一个大块（SOAP请求）然后在一个大块（SOAP响应）中接收时，它当然没有用，甚至有害（由于延迟）。因此，建议游览它。
因此，可以得出结论，除非实时处理很重要（控制台终端），否则Nagle的algorighm 应该留在用于流应用程序（文件，视频，常量数据馈送）。它基本上是一个“良好行为准则”，用于不使用无用流量阻塞信道的应用（这可能是网络负载较重的大型数据中心的问题）。 如果通信是在请求 - 响应模式下完成的（即：所有数据一次写入缓冲区 - 因此Nagle的算法无效），您可以默认关闭它。
答案 1 :(得分：2)
对于使用大量小型（TCP / HTTP级别）消息的协议，应关闭Nagle。我不认为这样做总是。
请注意，WCF不一定表示SOAP。这取决于使用的绑定。消息大小还取决于使用的编码。 WCF 非常可配置。
WCF可以使用例如JSON。因此，假设您在WCF + JSON + REST上构建服务器应用程序，并且平均JSON有效负载很小（例如，小于1500字节，这意味着自JSON默认使用UTF-8以来约为1500个字符），而且可能是值得。
但是，如果您的应用程序使用SOAP绑定并且您测量的平均消息大小超过1500字节（这似乎很可能使用SOAP XML有效负载），那么它不值得。
所以，你真的需要在做出决定之前测量一些事情恕我直言 - 就像Azure人一样，好吧，也许他们之后做了:-)。测量HTTP消息大小的一种简单方法是使用Fiddler2，尤其是统计选项卡（选择所有消息，它将为您提供总帧数和总字节数）。