我正在维护一个应用程序，它使用循环执行程序执行应用程序任务，以及通过FTP接收文件的附加低优先级任务，可以在当前帧中的所有其他任务完成处理之后运行。这导致接收任务完全不运行X ms，而不是50-X ms来执行所有recv调用。
我注意到，当将数据套接字（SO_RCVBUF）的窗口大小设置为大数25000时，FTP服务器的吞吐量低于将其设置为512时的吞吐量。
稍微阅读一下，结果发现使用TCP套接字时，如果接收器比发送器慢，那么大的缓冲区大小是不利的。
要实现最大吞吐量，对所使用的链接使用最佳TCP套接字缓冲区大小至关重要。如果缓冲区太小，TCP拥塞窗口将永远不会完全打开，因此将限制发送方。 如果缓冲区太大，发送方可能会超出接收方，这将导致接收方丢弃数据包并关闭TCP拥塞窗口。如果发送主机比接收主机快，则更有可能发生这种情况。只要你有多余的内存，发送方的一个过大的窗口就不是一个大问题。
http://www.onlamp.com/pub/a/onlamp/2005/11/17/tcp_tuning.html
这对我来说非常违反直觉。我不明白更大的缓冲区会如何造成任何伤害，它应该有助于较慢的接收器在发生减速之前处理数据。