TCP window size

Win8,WinBlue对P2P这块很重视，加了很多P2P的功能，性能的测试。

自己对WIFI的协议比较了解，不过对TCP协议没接触过，在tune WIFI throughput的时候，遇到了TCP ACK windows size的影响。

TCP windows size太小的话，一次性灌到wifi的包数量太少，导致没法充分利用WIFi的吞吐量。

如果只有64k的windows size,那么一次性灌到diver只有40来个Packet(每个包1.4k左右)。

40来个包对于WiFi来说，两次aggregation,4ms不到就传完了，所以TCP stack反而成了bottle neck。

TCP的Windows size取决于两个值，对方Rx的buffer size, 自己Tx的buffer size，并且取Min(Rx,Tx).

Rx的buffer size应该是起socket的时候固定配好的，估计不少程序默认都是64k吧。

Tx的buffer size是动态调整的，受网络throughput,latency等影响，尤其是对方的TCP ACK.

如果一段时间内没收到对应的TCP ACK,那么就会发生重传，一旦发生重传，TCP的windows size估计就会减小。

在我的环境下，由于WiFi需要同时在不同的信道上支持多个连接，legacy的AP，有需要支持P2P联系，类似于虚拟了块无线网卡吧。

有时候不可避免，TCP在Driver Pending的时间会比较长，可能Tx在发完一个TCP Packet之后，需要等80ms才能收到对方的TCP ACK.

有时候Tx等不及这么长时间，就TCP 重传了，Windows size自然就下来了，throughput也跟着下来。

当然，WiFi基于无线，有时候也会发生丢包，那么也会导致TCP重传。

当然TCP window过大也有坏处，latency可能会增加，因为一次性丢给driver太多的包，导致driver需要花费些时间来发送这个包。

Window Size的存在，估计是TCP的throughput比不上UDP的一个很重要的因素吧。