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