根据亚太网络信息中心首席科学家杰夫·休斯顿的说法，SpaceX的Starlink卫星互联网服务对TCP协议“代表了一个异常敌意的链接环境”.
上周晚些时候，休斯顿在一篇博客文章中详细介绍了他对Starlink性能的分析，其中详细介绍了他对Starlink性能的分析.
文章一开始就解释说，低地球轨道卫星飞驰而过，它们可以在不到5分钟的时间内从地平线到达地平线.
因此，为了保持连接，地面天线需要定期连接到不同的卫星.
我们认为，这在很大程度上是意料之中的.
因此，对于那些预测未来应用和使用通过Starlink的连接状态的人来说，这一信息是一个具体的参考.
他写道：“连续的低轨卫星服务需要在卫星经过头顶时跳过连续的卫星序列，并在卫星进入最终用户和用户指定的地面站时将虚电路路径切换到连续的卫星.
”休斯顿认为这种情况可能每隔15秒就会发生一次.
通过使用Ping，他发现“最小延迟每15秒有规律地发生变化”，并推测：“这种变化似乎与Starlink用户的终端被分配到不同的卫星有关.
这意味着用户设备会在15秒的间隔内‘跟踪’每颗卫星，这相当于11度弧度的跟踪角.
”在这些切换过程中，休斯顿观察到一些分组丢失--以及延迟的显著增加.
他写道：“在这个数据集中，最糟糕的情况是从30毫秒到80毫秒.
”进一步说：“在每个15秒的卫星跟踪间隔内，潜伏期变化相对较大.
连续RTT间隔之间的抖动平均变化为6.7ms.切换时的延迟峰值增加了额外的30ms到50ms，这表明系统中存在深度缓冲区，以适应与卫星切换相关的瞬时问题.
总体而言，休斯顿认为Starlink具有“非常高的抖动率，大约1%到2%的与网络拥塞无关的丢包率，以及每15秒定期跳跃的延迟曲线.
”这使得它对于传输控制协议(TCP)来说是“一个异常恶劣的链路环境”，这意味着“旧版本的TCP，如Reno TCP，对丢包反应迅速，恢复缓慢，在跨Starlink连接使用时，性能非常差.
”这显然不是好消息，如果你开发的应用程序使用的是一个不喜欢通过Starlink访问太空的TCP版本.
谢天谢地，休斯顿认为他有一个补救办法：调整TCP，让它在Starlink上表现得更好.
他甚至认为有三个候选人可以做这项工作.
一个是瓶颈带宽和往返传播时间(BBR)协议--一种由谷歌开发的TCP拥塞控制算法.
BBR试图预测网络路径上的延迟，并相应地调整发送策略.
Cubic TCP网络拥塞避免算法也可以做这项工作，与选择性确认(SACK-又名RFC 2883)相结合.
休斯顿还认为，显式拥塞通知可能会有所帮助，因为它可以处理卫星切换导致的延迟峰值等情况.
虽然Starlink对TCP的敌意让休斯顿感到担忧，可能会给一些应用程序带来麻烦，但这项服务主要提供了相当可观的带宽：首席科学家从2023年8月到2024年3月每四个小时使用Speedtest，发现该服务的下载容量中值约为120兆比特/秒.
单个测量读数高达370兆比特/秒，低至10兆比特/秒，以及15兆比特/秒的上传容量，变化在5兆比特/秒到50兆比特/秒之间.®.