卫星连接通常具有500ms左右的RTT。 连接通常会遭受次优的传输速度，尽pipe有大量的带宽，因为TCP确认需要很长的时间才能到达。
我的理解是，用TCP连接解决这个问题的一个好方法是将TCP窗口大小设置为连接速度（以位为单位）乘以RTT（以秒为单位）。 所以卫星上的1mbps连接应该有512kb的窗口大小。
这有什么陷阱？ 是否还有其他类似的调整来优化卫星连接？ 据我所知，许多现代操作系统会自动修改窗口大小，但是它们是否足够积极，足以使窗口尺寸足够大到可以用于卫星通信？
另外，我将假定在频繁丢弃数据包的networking上，大窗口大小是不可取的，因为重传将是窗口大小，并且您可能会将大部分带宽用于重传开销。
谢谢，我还在学习关于networking的很多东西，并且非常感谢你的投入。
您通常应该使用实现适当的窗口缩放的TCP堆栈。 但是，当然，您的窗口大小需要设置带宽延迟产品（BDP）。 如果你有不同的BDP，你可以将窗口大小设置为一个常见的“最差”情况。 有趣的是，如果窗口大小比BDP大（当然不应该太大），大多数连接不会受到太多影响，但是如果窗口大小比BDP小得多，则会显示性能下降。
要检查您的TCP / IP协议栈是否正确增加窗口大小，您应该使用Wireshark或任何其他stream量嗅探器。 您可以直接查看标题中的窗口大小标志（考虑到缩放因子！）。 Wireshark也可以通过考虑缩放因子来显示有效的窗口大小。
查看本教程，了解如何在此处绘制您的TCP窗口大小作为时间的函数。
这是完全学术的，因为没有人通过卫星连接运行TCP。 我不知道有一个这样的卫星提供商。 他们都在卫星上运行卫星专用协议，并把TCP端点放在地面站。
当networking中的一台机器向卫星terminal发送TCP SYN包时，卫星terminal向卫星发送一个TCP代理请求。 这指示地面站打开到Internet上某个服务器的TCP连接。 地面站向互联网服务器讲TCP。 卫星terminal不会通过卫星讲TCP，而是说一个为卫星使用而优化的协议。 地面站充当卫星terminal和互联网服务器之间的代理。
为了方便起见，有带宽延迟产品计算器可用 – 一个这样的计算器在这里 。 对于在丢包情况下造成问题的大型窗口 – 这就是为什么TCP窗口是可变的。 数据包丢失后，窗口大小将减小，从而减less传输中的数据，从而降低传输速度。 经过一段时间后，窗口大小将重新协商。
实际上你的延迟对卫星来说并不是那么糟糕 – 一个1T的RTT @ 1M只有一个125K的窗口。 许多现代操作系统很容易支持这种开箱即用的function，所以可能不需要额外的修改。
顺便说一下，有些市场上的各种WAN优化器运气非常好。 这些都倾向于优化TCP窗口大小，以及使用caching和压缩，以推动更多的通过链接，并提高明显的响应能力。