卫星互联网路由：一颗卫星飞过头顶，你的数据包在赌哪条路？

晚上十点，南京河西，雨刚停。朋友在船上发来一张模糊照片，问我：卫星互联网是不是把信号“打上天”，再“掉下来”？我盯着那条消息笑了。真要这么简单，路由工程师可以下班了。数据包从你的终端出发，先找卫星，再在星间链路里一跳一跳地走，落到地面网关，才进互联网。中间每一步都要问：下一跳是谁？这条链路还活着吗？绕路会不会更稳？这就是卫星互联网路由。不是一根天上网线，更像一张会呼吸的网。低轨卫星星座星间链路路由拓扑示意图

一颗星飞过去，路由表就得“换脑子”？

一颗星飞过去，路由表就得“换脑子”？ 低轨卫星飞得快。90分钟绕地球一圈，不是文学修辞。你抬头看它好像不动，其实它在地平线上跑。星座里每颗星相对邻居的位置一直在变。星间链路——就是卫星和卫星之间的激光或微波通信——有的刚建好，有的马上要断。地面互联网的路由协议，比如OSPF，喜欢稳定拓扑：邻居在，链路在，大家慢慢收敛。卫星网络不吃这套。收敛还没完，拓扑又变了。真让人懊恼。 所以卫星互联网路由的入门课，是承认“动态”不是意外，是常态。星历可预测。卫星位置能算到秒级。于是工程上常把时间切片：未来几分钟到几十分钟，按固定间隔切成小段。每一小段里，把星座拓扑当成近似不变。这个思路叫虚拟拓扑，或者时间扩展图。说人话：把一张一直在变的网，拆成一叠“时刻表”。每个时刻表上算一次路径。数据包按时刻表走。很像地铁换乘图，只不过换乘站会飘。

把时间切成片，路由就在“时刻表”上算

具体怎么算？地面控制中心拿到星历、链路计划、网关位置、业务需求。用时间扩展图跑约束路径：时延、丢包、链路容量、星上队列。算完不一定把整张表塞给卫星，太重。更常见的是预计算若干候选路径，或者按目的地给下一跳。卫星飞过不同区域，路由表跟着切换。切换要平滑。否则数据包在星上排队，排着排着链路断了。尴尬。 这里有个容易被忽略的点：卫星互联网路由不是只选“短”。短路径可能经过拥挤的星间链路。也可能落到一个地面网关，而那个网关后面的光纤绕远。端到端时延要算天上一段、地上一段。你在这头觉得“卫星离我近”，数据包可能先横穿半个星座。对吧，路由是全局买卖，不是单跳买卖。卫星互联网用户终端接入地面网关路由路径示意图

星上不是机房，路由要“省着算”

星上不是机房，路由要“省着算” 星上处理器不是云服务器。功耗、散热、内存、抗辐射，样样紧。你让星上跑复杂路由协议，频繁泛洪，链路状态数据库一大，星上CPU就喘。工程上得抠：多久更新一次？故障时谁重路由？集中算还是分布式？集中式好管，但依赖地面控制链路；分布式反应快，但容易震荡。混合方案常见：地面算大账，星上做局部修补。链路断了，邻居先扛一下，别全网广播。像小区停水，先关阀门，不是拉全城开会。 还有激光链路的对准。星间链路不是插网线。两颗星相对运动，光束要追。天气、遮挡、卫星姿态都会影响。雨衰对馈电链路也狠。路由协议得把这些“物理脾气”当输入，不是当异常。误判一次，可能把流量赶到一条快断的链路。然后丢包。然后重传。然后更堵。循环起来很烦。 再说控制平面。星上路由表怎么更新，不能全指望实时下注。常见做法是把控制平面和数据平面拆开：地面算路径，星上按标签或段路由转发。源路由把路径编码进包头，星上少查表；段路由用一串段标识，让中间节点少做决策。听着花哨，实质是省算力、减状态。卫星不是机房，它更像一个在风里跑的信封分拣员。你给它太多规则，它真的会乱。

别把卫星路由想成“天上网线”

别把卫星路由想成“天上网线” 常见误解一：卫星互联网就是弯管，路由只在地面。不对。有星间链路的星座，天上也在转发。误解二：星间链路一定比光纤快。看距离和处理。跨洋长距离，天上可能占便宜；短距离、网关密集区，地面光纤更稳。误解三：路由表算一次能用很久。低轨星座不行。拓扑变化是分钟级甚至更短。误解四：加卫星就能加容量。路由不均衡，卫星再多也白搭。热点区域上空卫星排队，极区链路稀疏，容量分布不均。这事儿真不浪漫。 边界也清楚。极区和高纬度，星间链路几何关系特殊；赤道区域网关多，落地选择多；海洋和偏远地区，网关少，路由绕。政策、频谱、地面关口站分布，都会改路径。卫星互联网路由不是纯算法题，是工程、地理、商业一起拧的绳。你要问它什么时候好用？应急、海上、偏远、航空。什么时候别硬吹？城市密集区，地面网络通常更省心。就这样。