我有过在申请增加TCP窗口大小有些疑惑。 在我的C ++应用软件，我们1K左右从客户端到服务器使用TCP / IP封锁套接字发送大小的数据包。 最近我遇到了这个概念TCP窗口大小。 所以，我尝试使用值增加到64K setsockopt()两个SO_SNDBUF和SO_RCVBUF 。 增加该值后，我得到了性能WAN连接，但不是在LAN连接一些改进。
按我的TCP窗口大小的理解，
客户端将数据包发送到服务器。 一旦达到这个TCP窗口大小，它会等待，以确保从服务器接收窗口大小的第一个数据包ACK。 在广域网连接的情况下，ACK是从服务器获取延迟到客户端，因为围绕在100ms的延迟时间RTT的。 所以在这种情况下，增加TCP窗口大小补偿ACK的等待时间，从而提高了性能。
我想了解的表现在我的应用如何改进。
在我的应用程序，尽管TCP窗口大小（同时发送和接收缓冲区）的使用增加了setsockopt在插座的水平，我们仍然维持1k的同一数据包的大小（即字节，我们从客户在单个插槽发送发送到服务器）。 此外，我们禁用Nagle算法（内置选项，以小数据包整合成一个大的数据包，从而避免了因频繁套接字调用）。
我的疑惑是：
由于我使用的是阻塞插座，为1K的每个数据分组发送，如果ACK不从服务器都应该可以挡住。 那么怎样的性能提升，仅广域网连接的TCP窗口大小后改善？ 如果我误解了TCP窗口大小的概念，请大家指正。
用于发送数据的64K，我相信我仍然需要调用socket的发送功能的64倍（因为我通过阻塞套接字发送1K每发送），即使我增加了我的TCP窗口大小为64K。 请证实。
什么是窗口缩放与RFC 1323算法启用TCP窗口大小的上限？
我不是在我的英语这么好。 如果你无法理解任何上述情况，请让我知道。
首先，有一个很大的误解，显而易见的问题：即TCP窗口大小是什么是控制SO_SNDBUF和SO_RCVBUF 。 这不是真的。
什么是TCP窗口大小？
简而言之，TCP窗口大小决定了你的网络堆栈多少随访数据（数据包）愿意接收确认的尚未确认但最早的数据包之前把在电线上。
TCP堆栈与和账户住了一个事实，即一旦确定数据包在传输过程中丢失或受到损坏的， 每一个数据包发送，从一个开始 ，不得不重新发送，因为数据包可能只是为了得到确认由接收器。 因此，让太多的未确认的数据包同时存在投机消耗连接的带宽：没有了带宽使用将实际产生任何有用的保证。
在另一方面，不允许在同一时间多个未确认的数据包只会杀死有很高的连接带宽， 带宽时延产品 。 因此，TCP堆栈有罢工使用了带宽，没有任何好处，而不是驱动管积极就够了（并因此允许一些能力去未使用的）之间的平衡。
TCP窗口大小决定了这个平衡被击中。
什么SO_SNDBUF和SO_RCVBUF吗？
他们控制的网络堆栈已预留用于维修您的套接字的缓冲区空间量。 这些缓冲器有助于积累传出的数据，该堆栈尚未能穿上已从上述配线接收但尚未通过您的应用程序分别读取线和数据。
如果这些缓冲器中的一个充满你将无法发送或直到一些空间被释放接收更多的数据。 请注意，这些缓冲区只影响网络堆栈（或者他们已被送往之前，他们已经到达之后）如何处理上的网络接口的“近”端的数据，而TCP窗口影响堆栈如何管理的“远”数据接口的侧（即，在丝）。
问题的答案
否。如果是这样的话，那么你会招致发送的每个数据包，这将完全摧毁高延迟连接的带宽往返延迟。
是的，但有没有关系或者TCP窗口大小或分配给该套接字缓冲区的大小。
根据各种来源的我已经能够找到（ 例如 ），缩放使窗口达到1GB的最大尺寸。
- 由于我使用的是阻塞插座，为1K的每个数据分组发送，如果ACK不从服务器都应该可以挡住。
错误。 在TCP发送是异步的。 send（）方法只是将数据传输到套接字发送缓冲区和回报。 它只是块而插座发送缓冲区已满。
那么怎样的性能提升，仅广域网连接的TCP窗口大小后改善？
因为你错了吧阻塞，直到它得到了一个ACK。
- 用于发送数据的64K，我相信我仍然需要调用socket的发送功能的64倍
为什么？ 你可以只用64K数据缓冲区调用它一次。
（因为我通过阻塞套接字发送每发送1K）
为什么？ 或者这是你误解的第（1）重复？
即使我增加了我的TCP窗口大小为64K。 请证实。
号您可以一次发送这一切。 无需环路。
什么是窗口缩放与RFC 1323算法启用TCP窗口大小的上限？
远大于你永远都需要。
