我正在维护一个应用程序,它使用循环执行程序执行应用程序任务,以及通过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
这对我来说非常违反直觉。我不明白更大的缓冲区会如何造成任何伤害,它应该有助于较慢的接收器在发生减速之前处理数据。