低轨星座里的‘堵车’困局：卫星互联网路由的真实落地难题

上次在西北戈壁的无人区做终端测试，标称百兆带宽的卫星终端，连个30分钟的低清视频会议都能卡三次。一开始以为是终端的射频模块出了问题，换了三台同型号设备，卡顿依旧。后来拉了后台的路径日志才发现，问题根本不在终端——是整个路径上的路由选择，把流量绕了三个根本不畅通的星间链路，端到端的延迟比标称值高了4倍，丢包率常年维持在15%以上。

不是地面网搬上天，是完全不一样的“移动拓扑”

很多人对这类系统的认知，还停留在“把地面的路由器装到卫星上”的阶段。这是最容易踩的认知误区。传统路由协议的核心假设——节点拓扑的相对稳定性，在低轨星座场景下从根本上不成立。地面互联网的核心路由器，位置可能十年都不会变，哪怕是城域内的节点迁移，也是按月甚至按季度的频率调整，路由协议有充足的时间收敛、计算最优路径。但550公里轨道上的卫星，绕地球一圈只需要90分钟左右，对地面任意一个固定观测点来说，每4到6分钟就会有一颗卫星移出可视范围，新的卫星进入链路。整个星座的拓扑结构，是每几秒就会发生一次变化的动态网络。

最早一批做星座路由仿真的团队，直接把地面网的OSPF协议参数改了个更新周期，跑出来的仿真结果说能支持百万级节点的路由计算，真上了半实物仿真平台，三分钟就把路由表算崩了。毕竟地面上的路由协议，设计的时候根本没考虑过每几秒就换一批邻居节点的场景，等协议把邻居关系建立完、把链路状态泛洪完，节点都已经飞出链路范围了，算出来的路径早就失效了。

后来大家摸索出的思路，是把原本需要实时计算的拓扑状态，提前做轨道预测——毕竟卫星的轨道参数是可以精准计算的，未来几分钟甚至几小时内的星间链路连接关系，根本不需要实时探测，靠轨道模型就能算出来。但这种方法也有硬伤：一旦卫星因为姿态调整、轨道抬升、碰撞规避做了非规划内的变轨，原本的预测模型就全错了，路由表的收敛速度根本追不上实际的拓扑变化。

被忽略的链路不对称问题

刚解决完动态拓扑的问题，另一个更隐蔽的坑就冒出来了。地面网络的链路，不管是光纤还是微波，基本都是对称带宽——上下行的速率差不多，丢包率也基本一致。但天上的链路根本不是这样。星间的激光链路，会因为卫星姿态的微小偏差，出现接收功率的波动；地面站的回传链路，会因为降雨、云层遮挡出现大的衰减，有时候上行带宽掉一半，下行带宽还维持在原有水平。之前的路由算法，所有的度量值都是对称设计的，算路径的时候只看跳数、几何距离，根本没把这种不对称性当回事。

2023年某公开的星座测试数据显示，当某条跨波束的星间链路因为降雨衰减超过10dB时，路由算法因为没把链路的非对称带宽纳入度量模型，直接把80%的跨区域流量往这条链路上导，结果端到端丢包率冲到30%以上，比走更远的地面站回传路径的丢包率还高2倍。路由度量的设计如果只考虑距离、跳数，不把链路的实时不对称性、动态衰减值纳入计算，算出来的最短路径往往是实际场景下的最差路径。

更麻烦的是，这种链路的不对称性是随机的，根本没法靠提前的轨道预测完全覆盖。你永远不知道哪片云飘过来，会挡住哪条地面回传链路的信号，也不知道哪颗卫星的姿控系统会出现微小的偏差，让激光链路的接收功率掉几个dB。之前有团队试过把实时的链路测量值直接塞进路由度量里，结果又遇到了新的问题：测量值本身是有噪声的，有时候链路只是临时波动了一下，路由算法就把流量切走了，过两秒链路恢复了，又把流量切回来，整个网络的流量来回震荡，用户端的感知比之前还差。

端侧接入的路由决策，根本不是星上算完就完事

很多人觉得，把所有的路由计算都放到星上完成，终端只需要负责收发信号就行。实际测试下来，这根本不现实。用户拿着终端在城市的楼宇间移动，头顶可能同时有3到4颗可见的卫星，分别属于不同的星座，每颗卫星到用户要访问的服务器的路径长度、拥塞程度都不一样。如果终端只按照信号强度选星，很可能选了一颗离得近但星间链路已经堵死的卫星，结果端到端延迟比选信号弱一半但路径畅通的卫星高3倍。

你花几千块买的卫星互联网终端，很多时候的选路逻辑跟十年前的3G手机选基站没区别——谁信号强连谁，根本不管后面的路堵不堵。之前有测试团队在同一个位置做对比，终端按照内置逻辑选的卫星，到公网服务器的延迟是420ms，手动切换到信号强度低12dB的另一颗卫星，延迟直接降到110ms，差了整整4倍。

这里还要提一个很容易被忽略的硬约束：星上算力与功率的硬约束，是所有路由方案绕不开的前置边界。目前主流的星上处理芯片，为了抗宇宙射线的辐射，通用计算能力大概只相当于2015年的手机处理器水平，整星的可用功率也就几千瓦，还要分给姿态控制、通信载荷、太阳能板调整各个模块。如果路由算法每算一条路径就要消耗几十毫瓦的功率，整个星座一年下来就要多消耗几百瓦的在轨功率，直接缩短卫星的轨道寿命。那种动辄说要在星上跑全量BGP路由表的方案，先不说能不能算得过来，光是芯片的散热都压不住。

很多宣传里说这类网络能替代地面光纤，其实从路由的逻辑上就站不住脚。卫星的波束容量是有限的，一个低轨卫星的点波束，总容量也就几个G，当同一个波束里接入的用户数超过阈值，不管路由算法怎么优化跨星的转发路径、怎么调整链路的流量分配比例，整个波束的总带宽就那么多，根本不可能凭空变出更多的容量给用户分。硬要把这类网络往城市核心区推，路由再怎么精巧，也解决不了容量天花板的问题。它的适用场景本来就很明确：地面光纤到不了的远洋、山区、应急救援现场，给没有网络覆盖的地方提供基础的连接能力，而不是跟千兆光纤比谁的速率更快。

上次跟做星座运营的朋友聊天，他说现在最头疼的不是把卫星发上去，是怎么让这些卫星之间的“路”真的好走。毕竟天上的路没有交警，没有红绿灯，连车道线都是每几秒就变一次的，之前地面上攒了几十年的路由经验，到了天上，一半都用不上。