---
title: 卫星互联网路由：一颗卫星飞过头顶，你的数据包在赌哪条路？
url: https://www.17lubbs.com/wei-xing-hu-lian-wang-lu-you-yi-ke-wei-xing-fei-guo-tou-ding-ni-de-shu/
site: 17lubbs
author: 17lubbs 编辑部
published: 2026-10-28T08:39:29+08:00
updated: 2026-10-29T15:02:03+08:00
category: 行业判断
language: zh-CN
license: CC BY 4.0
---

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

> 低轨星座拓扑每几十秒变化一次，一条星间链路的可用时间可能只有 4 分钟。地面路由协议的收敛速度跟不上这种变化，工程上改用预测式路由：用星历提前算出未来 90 秒的拓扑，再下发转发表。

一颗低轨卫星飞过头顶，你的数据包要在几十秒内选好下一条路。地面网络的路由可以慢，因为拓扑基本不变；星座网络不行——拓扑每几十秒就变一次，路由协议必须在”算得快”和”算得准”之间反复权衡。

## 为什么地面路由算法不能直接用？

地面路由协议（如 OSPF、BGP）的设计前提是拓扑稳定：链路断了才触发重算，重算过程可以持续几秒甚至几十秒，期间靠已有转发表兜底。这个前提在星座网络里不成立。

低轨卫星相对地面高速运动，星间链路的通断是常态而非异常。一条链路的可用时间可能只有 4 分钟，如果路由收敛花掉 30 秒，可用窗口就直接少了一大截。更麻烦的是，收敛期间产生的路由震荡会让转发表频繁抖动，丢包率急剧上升。

## 预测式路由是怎么工作的？

核心思路是把”被动响应”换成”提前计算”。星座的轨道参数是确定的，未来一段时间的拓扑可以精确预测，不需要等链路断了才知道。

- **用星历算拓扑**：根据两行轨道根数（TLE）推算未来 90 秒内每颗卫星的位置与星间链路的通断状态。

- **预先求解路径**：在预测拓扑上离线计算各条业务流的路径，生成转发表。

- **按时间片下发**：转发表带生效时间戳，交换机在指定时刻切换，避免逐跳重算。

- **异常兜底**：预测失准（如链路受干扰提前中断）时，回退到本地快速重路由。

## 关键指标是什么？

| 指标 | 典型要求 | 说明 |
| --- | --- | --- |
| 拓扑预测周期 | 60 到 90 秒 | 太短则计算开销大，太长则预测失准 |
| 路由收敛时间 | 小于 1 秒 | 必须远小于链路可用窗口 |
| 端到端时延 | 20 到 60 毫秒 | 取决于跳数与链路速率 |
| 切换丢包率 | 低于 0.1% | 靠转发表预下发实现无损切换 |

## 星间链路突然中断怎么办？

预测能覆盖计划内的变化，覆盖不了干扰、遮挡和设备故障。所以必须保留本地快速重路由能力：每个节点维护一份备份下一跳，检测到链路中断后在毫秒级切换，不等全局收敛。这与地面网络的 FRR（快速重路由）思路一致，只是触发更频繁。

## 这套东西和普通用户有什么关系？

直接影响体验。卫星互联网的时延抖动主要不是传播时延造成的（低轨单跳约 3 到 5 毫秒），而是路由切换造成的。切换做得差，视频会议就会频繁卡顿；做得好，体验可以接近地面宽带。所谓”卫星网不好用”，多数是路由问题而不是带宽问题。

## 未来会往哪个方向走？

两个方向比较确定：一是星上计算能力增强，把部分路由决策下沉到卫星，减少对地面信关站的依赖；二是引入机器学习做流量预测，把”按拓扑选路”升级为”按流量选路”。但短期内，基于星历的确定性预测仍是最可靠的基础方案。

---

## 引用本文

17lubbs：《》，17lubbs，，