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的一个很重要的因素吧。