卫星网络与天地一体：LEO 星座、星地链路与协议优化

当基站、光纤到不了的地方——大洋、沙漠、极地、灾区、低空飞行器——卫星成为唯一答案。低轨（LEO）星座把卫星通信从「昂贵、高延迟、窄带」变成了「大众化、低延迟、宽带」。但卫星网络给工程师的挑战截然不同：链路延迟几百毫秒、频繁切换、信道受天气影响。理解这些特性，才能在「天地一体」的架构里做出正确的协议选型与优化决策。

一、卫星网络的演进

1.1 从 GEO 到 LEO

按轨道高度，通信卫星分三类：

为什么 LEO 能「降延迟」：
  信号传播延迟 ∝ 距离
  GEO：地面↔卫星单程 ~125ms（往返 ~500ms）
  LEO：地面↔卫星单程 ~5~10ms（往返 ~20~40ms）
  → 接近地面网络的体验，宽带上网才成为可能

一句话：卫星通信的「降延迟革命」本质是降低轨道高度——用成千上万颗小卫星换回接近地面的传播时延。

1.2 星座组网思路

LEO 星座三要素：
1. 轨道面（Plane）：多个倾角相近的轨道平面
2. 每面卫星数：均匀分布，保证全球无死角
3. 星间链路（ISL）：卫星之间激光/射频互联，构成太空骨干
覆盖逻辑：
  卫星相对地面高速运动（~7.5km/s）
  → 对用户而言卫星「划过头顶」，需频繁切换
  → 星座设计要让任何时刻、任何地点至少有一颗可见卫星

二、LEO 星座架构

2.1 星座拓扑与通信路径

一条用户流量的完整路径：
  用户终端（天线）──星地链路──► LEO 卫星
      │
      ├──（可选）星间激光链路 ──► 多跳 → 出口卫星
      │
      ▼
  地面网关（Gateway）──地面骨干──► 数据中心/Internet

路径选择决定延迟：
  单跳 + 落地网关：最短，适合低延迟业务
  多跳星间链路：灵活，但每跳增加少量时延

2.2 星间链路（ISL）

星间链路是「太空骨干网」，通常用激光或 Ka 波段：

ISL 类型：
  同轨道面内相邻星（Intra-plane）：稳定，延迟极小
  相邻轨道面之间（Inter-plane）：相对运动，需动态对准
  跨极区：复杂，通常关闭或备用

关键技术：
  激光通信：带宽大（可达数百 Gbps）、波束窄需精密对准
  动态路由：星座拓扑随时间变化，路由需周期性重算

2.3 地面网关与回传

网关（Gateway）选址原则：
  靠近网络骨干（数据中心、IX 交换点）
  多网关冗余，故障时切换出口
  每网关可服务过顶的多颗卫星

回传架构：
  卫星 ──► 网关 ──► 地面网络 ──► 应用
  或：卫星 ──► 卫星 ──► 网关（卫星出口汇聚）

三、星地链路的物理特性

3.1 延迟与抖动

星地链路延迟构成：
  传播延迟（轨道高度决定，基本固定）
  编码/交织延迟（误码纠错，与信道质量相关）
  调度排队延迟（多用户共享，可变）

抖动来源：
  卫星运动导致的路径长度变化
  大气闪烁与降雨衰减导致的速率自适应
  切换瞬间的重新协商

3.2 链路预算与衰减

星地链路损耗主要来源：
  自由空间损耗（与距离、频率相关，Ka/Ku 波段显著）
  大气吸收（氧气/水汽，Ku/Ka 波段降雨衰减严重）
  多云雨衰减（Rain Fade）：Ka 波段在暴雨时可衰减数十 dB

应对：
  自适应编码调制（ACM）：链路差时降速率、加纠错
  功率控制：卫星增大发射功率补偿衰减
  切换备份：恶劣天气切到其他卫星/路径

3.3 波束管理与切换

波束成形：
  卫星用多波束（Spot Beam）覆盖地面，每个波束服务一片区域
  波束切换：用户终端在不同波束间移动时切换

切换类型：
  波束内切换：同星不同波束
  星间切换：不同卫星接管（伴随路由更新）
  网关切换：出口网关变更

切换对连接的影响：
  TCP 会话应尽量保持（用隧道/SRV6 等规避路径突变）
  实时流媒体需要无缝切换（快速握手恢复）

一句话：卫星链路的本质是「延迟高、抖动大、带宽动态」——所有协议优化都围绕这三件事展开。

四、高延迟网络下的 TCP 优化

4.1 TCP 在高延迟链路的先天短板

TCP 的拥塞窗口（cwnd）增长受限于「每 RTT 增加若干段」，延迟越大，带宽利用率越低：

带宽延迟积（BDP）= 带宽 × RTT
  例：100Mbps × 300ms = 3.75MB ≈ 2500 个 1500B 段
  若 cwnd 只有 100 段，利用率仅 4%

经典问题清单：
  - 慢启动窗口增长慢（RTT 大 → 达到目标带宽需很长时间）
  - 拥塞避免线性增长太慢
  - 丢包误判为拥塞：误码重传把 cwnd 减半

4.2 TCP 加速：PEP 与代理

PEP（Performance Enhancing Proxy）是最经典的卫星加速方案——在链路两端「拆开」TCP：

拆分连接架构：
  客户端 ──TCP①──► PEP-A ──卫星优化协议──► PEP-B ──TCP②──► 服务器
  TCP① 走地面（RTT 小，正常行为）
  卫星段用专用协议（如 SCPS-TP / 私有协议）传输
  TCP② 走地面（RTT 小）

收益：
  卫星段可用大窗口 + 前向纠错 + 本地重传
  地面段保持标准 TCP，无需应用改造

# 配置 TCP 代理的典型内核参数（PEP 节点 / 终端侧）
sysctl -w net.ipv4.tcp_window_scaling=1
sysctl -w net.ipv4.tcp_sack=1
sysctl -w net.core.rmem_max=67108864
sysctl -w net.core.wmem_max=67108864
sysctl -w net.ipv4.tcp_rmem="4096 1048576 67108864"
sysctl -w net.ipv4.tcp_wmem="4096 1048576 67108864"

PEP 的取舍：
  优点：透明、快速提升吞吐
  缺点：破坏端到端语义（丢包、拥塞反馈被屏蔽）
       对加密流量不透明（TLS 1.3 下尤其受限）

4.3 直接调优 TCP

若无法用 PEP，直接在内核层面让 TCP 适应长肥管道（Long-Fat Pipe）：

关键调优点：
  1. 增大窗口：rwnd/rmem 提到 BDP 以上
  2. 丢包重传：启用 F-RTO、早重传，减少等待
  3. 拥塞控制：CUBIC/BBR 比传统 Reno 更适应高 BDP
  4. 关闭延迟 ACK（对吞吐敏感场景）

拥塞控制算法对比（卫星场景）：
  Reno/NewReno：依赖丢包探测，卫星误码场景吃亏
  CUBIC：窗口增长更快，适合高 BDP
  BBR：基于瓶颈带宽与 RTT 探测，对高延迟更稳健
  → 卫星链路优先考虑 BBR / CUBIC

五、QUIC 与 HTTP/3 的卫星适配

5.1 为什么 QUIC 适合卫星

QUIC（基于 UDP）把传输控制移到用户态，天然适合优化高频、动态的链路：

QUIC 对卫星链路的优势：
1. 连接迁移：连接 ID 与四元组解耦 → 卫星切换不断流
2. 0-RTT 恢复：会话重连无需完整握手，切换后秒级恢复
3. 用户态拥塞控制：可针对链路特性定制算法
4. 多路复用：单连接内多流，队头阻塞只影响单流
5. 原生加密：无需 TLS 叠加，减少额外握手轮次

连接迁移原理：
  传统 TCP 靠五元组标识连接 → 切换后 IP/端口变化 = 断连
  QUIC 用 Connection ID 标识 → 切换后告知新地址即可
  → 卫星动态切换场景的「救命特性」

5.2 0-RTT 与握手优化

握手轮次对比（卫星 RTT 高，轮次就是时间）：
  TCP+TLS 1.3：2 RTT 建立
  QUIC 首次：1 RTT
  QUIC 0-RTT 重连：0 RTT（带早期数据）

卫星场景换算：
  单跳 RTT ~30ms，看似不大
  但多跳卫星路径 + 中间网关可达数百 ms → 少一轮就是几百 ms

5.3 为卫星定制拥塞控制

QUIC 允许每应用自定义拥塞控制，甚至可在端侧做「卫星感知」：

// 卫星场景的 QUIC 拥塞控制思路：按 RTT 趋势与可用带宽调速率
if rtt < min_rtt*1.1 {
    rate += rate_step            // 链路健康，稳步提速
} else if rtt > min_rtt*1.4 {
    rate -= rate_step*2          // RTT 膨胀，主动退让
}
// 结合前向纠错（FEC）掩盖误码型丢包

一句话：QUIC 是卫星网络应用层的「正确抽象」——连接迁移、0-RTT、可定制拥塞控制，几乎每一条都打在卫星链路的痛点上。

六、卫星回传与边缘计算

6.1 卫星回传架构

卫星回传把「末端接入」与「骨干」打通，是天地一体的关键：

典型回传拓扑：
  [偏远基站] ──卫星──► [网关] ──► [核心网] ──► [云/应用]
  或边缘形态：
  [用户终端] ──卫星──► [边缘计算站]（就近处理）──► [中心云]

回传设计要点：
  - 本地缓存：热点内容在边缘缓存，减少卫星流量
  - 就近计算：延迟敏感任务卸载到边缘
  - 智能调度：低优先级数据用低峰时段批量传

6.2 边缘节点与缓存

边缘在卫星网络中的角色：
  1. CDN 下沉：把内容推到「天空边缘」或地面边缘站
  2. 协议加速：边缘站做 PEP/QUIC 代理，改善端侧体验
  3. 数据处理：IoT 数据在边缘聚合后再回传
  4. 断连自治：卫星中断时边缘继续服务，恢复后同步
内容分发策略：
  冷热分离：热内容常驻边缘，冷内容按需拉取
  预取：根据预测（位置、时间）预推送内容到边缘

6.3 与地面网络融合

天地一体网络愿景：
  地面 5G + 卫星回传 + 低空/海洋覆盖 = 全域无缝连接

融合模式：
  - 卫星作为 5G 的中传/回传（Backhaul）
  - 终端双模：地面网络为主、卫星为备（快速切换）
  - 统一寻址：无论走地面还是卫星，应用无感

协议层面：
  - 端到端尽量保持 QUIC/TLS 1.3（连接可迁移）
  - 中间层用 SRv6/隧道隐藏路径变化

七、天地一体的工程实践

7.1 现网案例特征

以 Starlink 为代表的 LEO 宽带服务：
  - 终端：相控阵天线，自动对准卫星
  - 延迟：典型 RTT 30~50ms（远优于传统 GEO 500ms）
  - 带宽：百 Mbps 级，随天气/负载动态调整
  - 切换：卫星每数分钟划过，终端无缝切换波束/卫星

海事/航空互联网：
  - 移动中保持连接：高动态环境下的波束跟踪
  - 与地面网络竞争：机场/码头泊位时切回地面

7.2 测试与评估方法

卫星网络应用的评估要点：
  1. 延迟分布：RTT 的 P50/P95/P99（抖动不可只看均值）
  2. 带宽稳定性：长时间吞吐曲线，而非瞬时峰值
  3. 切换行为：切换期间的丢包与中断时长
  4. 拥塞控制对比：BBR vs CUBIC vs 定制算法的实测
  5. 加密影响：TLS 1.3 握手是否成为瓶颈

# 用 netem 模拟卫星链路特性做应用测试
tc qdisc add dev eth0 root netem \
  delay 30ms 15ms distribution normal \
  loss 1% \
  rate 100mbit
# 再跑 iperf / curl 对比不同拥塞控制算法

7.3 挑战与展望

当前挑战：
  1. 终端成本与功耗：相控阵天线贵、耗电
  2. 频谱与干扰：Ka/Ku 波段共享，需协调
  3. 太空资源：轨道面与频率是稀缺资源
  4. 协议层：端到端语义在加速代理下的权衡
  5. 安全：卫星链路的加密与劫持防护
未来方向：
  - 激光星间链路规模化（太空骨干网）
  - 天基算力：星上计算（In-orbit computing）
  - 与地面 6G 深度融合、一体化的智能路由
  - 星座自主运维：AI 预测轨道与故障

八、总结

卫星网络把「地面为中心」的网络观扩展到「天地一体」：LEO 星座解决了延迟与覆盖，星间链路构成太空骨干，而协议层则是成败关键——TCP 需要大窗口与 PEP，QUIC 则天然契合连接迁移与高频场景。对后端工程师而言，卫星不再是「应急方案」，而是有自己物理特性与协议逻辑的又一传输载体：谁先学会按 BDP 调窗口、按抖动做缓冲、按切换做恢复，谁就能在这张覆盖全球的网上提供稳定体验。