我已经看过许多有关在Azure上工作时在WCF中禁用Nagle算法的帖子。我一直在想这是否仅适用于Azure还是应该是更通用的最佳实践。
如各种来源所述，Nagle算法基本上将小的TCP请求批处理为单个较大的请求。批处理基于每个连接进行。
在专业的环境中，我看到的大多数WCF传输都是小的数据块，它们是由一个线程发送的，并且大多是双向发送的。我知道对于Nagle算法来说，这并不是理想的情况。
所以...我的结论正确吗，在使用WCF或SOAP时，不管上下文如何，最好仅总是禁用它？
最佳答案
据我了解，Nagle的算法仅在数据以不足网络吞吐量的速率以小块流式传输时才有帮助。例如，如果它是视频馈送或来自某个硬件传感器的恒定输出(实时无关紧要，而历史则无关紧要)。
想象一个极端的情况-所有这些数据都是在不使用Nagle算法逐字节发送的情况下进行的，实际上是将流量乘以41。
相反，当数据以一个大块写入(SOAP请求)，然后以一个大块接收(SOAP响应)时，它当然是无用的，甚至是有害的(由于延迟)。因此，建议将其淘汰。
因此，可以得出结论，除非实时处理很重要(控制台终端)，否则应将Nagle的算法留在上以用于流应用程序(文件，视频，恒定数据馈送)。对于应用程序而言，不要阻塞无用流量的 channel 基本上是“良好行为准则”(在网络负载沉重的大型数据中心中，这可能是一个问题)。
如果通信是在请求-响应模式下完成的(即:所有数据都立即写入缓冲区-因此Nagle的算法无效)，则可以默认将其关闭。
关于.net - WCF/SOAP中的Nagle算法是否有用？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14403314/