我的（networking）客户端每200毫秒向我的服务器发送50到100 KB的数据包。 有多达300个客户。 服务器什么也不发送给客户 服务器（专用）和客户端在LAN中。 如何调整TCPconfiguration以获得更好的性能？ Windows Server 2003或2008上的服务器，Windows 2000及更高版本上的客户端。
例如TCP窗口大小。 改变这个参数有帮助吗？ 还要别的吗？ 任何特殊的sockets选项？
[编辑]：实际上在不同的模式下数据包可以达到5MB
我在几年前对1700个数据点做了一个研究。 结论是，你可以做的最好的事情是在接收器上配置一个巨大的套接字接收缓冲区（例如512k）。 这样做到监听套接字，所以它将被接受的套接字继承，因此它将在握手时被设置。 这又允许在握手期间协商TCP窗口缩放，这允许客户端知道窗口大小> 64k。 巨大的窗口大小基本上可以让客户端以最大可能的速率进行传输，而不仅仅是拥塞避免，而不是封闭的接收窗口。
什么OS？ IPv4还是V6？ 为什么这么大的一个倾倒; 为什么它不能被分解？
假设一个稳定的，稳定的，低带宽的延迟产品，你可以调整诸如机上尺寸，初始窗口尺寸，mtu（取决于数据，IP版本和模式[tcp / udp]）。
你也可以循环或平衡输入，所以你有更少的中断时间从nic ..绑定也是一个选项。
5MB /包/？ 这是一个非常糟糕的设计..我认为这会导致大量的段重新传输，并且很多kernel / stack mem被用于顺序重构/重传（接受等待时间等）。
（这甚至可能吗？）
由于所有的客户端都在局域网中，你可以尝试启用“巨型帧”（需要运行一个netsh命令，需要谷歌精确的命令，但有很多的方法）。
在应用程序层上，可以使用TransmitFile，它是Windows发送文件的等价物，它在Windows server 2003下工作得非常好（在“非服务器”下是人为限速的，但这对你来说不会有问题）。 请注意，如果您即时生成数据，则可以使用内存映射文件。
至于调整参数，增加发送缓冲区可能不会给你带来任何好处，尽管在某些情况下增加接收缓冲区可能会有所帮助，因为如果接收应用程序不能足够快地处理输入数据，它将降低数据包丢失的可能性。 较大的TCP窗口大小（注册表设置）可能会有所帮助，因为这样可以让发送者在发送ACK之前发送更多的数据。
扬起程序的工作集配额可能是值得考虑的，它没有花费任何代价，并且可能是一个优点，因为内核在发送时需要锁定页面。 被允许拥有更多的页面锁定可能会使事情变得更快（或者可能不会，但也不会伤害到，默认值是无论如何低得可笑）。