starlink传输协议，smarteye
从传输协议的视角看 Starlink,数字通信系统总是涉及一系列设计权衡。最大化系统的某个特性可能会损害其他特性，而不同的通信服务可能会根据这些设计决策与通信介质的物理特性，选择优化不同的性能参数。
在这篇文章中，我将探讨 TCP（互联网的主力传输协议）如何与 Starlink 服务 的特性进行交互。
首先，回顾一下 1687 年的牛顿物理学 中的一个小知识点是有帮助的。在地球表面，如果你水平发射一个抛射物，由于地球大气层的摩擦效应和地球引力的共同作用，它会落回地球。
假设地球没有大气层，如果你以足够快的速度水平发射这个抛射物，它将不会返回地球，而是进入太空。然而，如果你足够高以避开可能挡路的山脉，那么存在一个临界速度，抛射物将被地球引力捕获，既不会落到地面，也不会飞向太空（图 1）。
在地球表面的这个 轨道速度 约为 40,320 公里/小时。轨道速度随着高度的增加而降低，在地球表面以上 35,786 公里的高度，抛射物相对于地球表面某一点的轨道速度为 0 公里/秒。这是 地球同步赤道轨道 的高度，轨道上的物体似乎固定在天空中的某个位置。
地球同步服务
地球同步卫星是第一波基于卫星的通信服务的首选方法。每颗卫星可以“覆盖”整个半球。如果卫星位于赤道平面上，那么它相对于地球的位置是固定的，允许使用大型天线。这些天线能够在低信噪比 (SNR) 下工作，允许信号调制使用具有高密度离散相位幅度点的编码，从而提高了服务的容量。
然而，地球同步服务也有一些不利的方面。考虑到使用相同无线电频率的地球同步轨道卫星之间的串扰干扰，国际协议要求使用相同频率的地球同步卫星之间保持 2° 的间距，因此这个轨道槽是一个有限的资源，如果它们都使用 K 波段（18 – 27Ghz）无线电系统，则仅限于 180 颗航天器。在地球上的任何一点，使用地球同步服务可以接收（和发送）的信号容量都有一个上限。
根据观察者是在赤道正下方还是远离这一点，地球同步轨道卫星距离地球的距离在 35,760 到 42,664 公里之间，因此信号往返地球同步卫星的时间在信号传播时间方面将在 238 毫秒到 284 毫秒之间。
在 IP 术语中，这意味着往返时间在 477 到 569 毫秒之间，并且需要加上信号编码和解码时间。此外，信号在地面终端和卫星地面站之间传递还需要延迟。实际上，对于包括地球同步卫星服务的互联网路径，大约三分之二秒（660 毫秒）的往返时间是一个常见的体验。
这种延长的延迟意味着终端需要使用大缓冲区来保存所有未确认数据的副本，这是 TCP 协议所要求的。TCP 是一种基于反馈控制的协议，使用 ACK 节奏。往返时间越长，反馈的滞后越大，终端对拥塞或可用容量的响应越慢。拥塞考虑导致在驱动卫星电路的系统中使用大缓冲区，这可能会进一步加剧拥塞引起的不稳定性。在地球同步服务环境中，与地面对应物相比，单个 TCP 会话更容易出现不稳定性，并且在低事件后恢复时间更长，当这些 对应物存在 时。
低地球轨道系统
对地球同步卫星缺点的一个潜在回应是将卫星更靠近地球。这种方法有几个好处。地球的旋转铁芯产生了一个磁场，捕获了高能带电太阳粒子，并通过所谓的“范艾伦带”重新定向，从而偏转太阳辐射。这不仅使地球能够保留其大气层，还保护了使用低于 2,000 公里左右轨道高度的卫星的电子设备免受太阳辐射的最严重影响（例如最近的太阳风暴）。将卫星发射到低地球轨道的成本也低得多，如今 SpaceX 可以使用可重复使用的火箭助推器进行发射。
地球与轨道卫星之间的距离减少，减少了向卫星发送信号并返回的延迟，这可以提高包括此类卫星电路的端到端数据包传输协议的效率。
这组轨道高度，从大约 160 公里到 2,000 公里，统称为 低地球轨道 (LEO)。这里的目的是保持卫星的轨道足够高，以防止其因擦过地球电离层的上部而减速，但又不至于高到失去 内范艾伦带 提供的辐射保护。在 550 公里的高度，从地球表面到达卫星并返回的最小信号传播延迟仅为 3.7 毫秒。
但所有这些都带来了一些不同的问题。在 550 公里的高度，轨道卫星只能被地球的一小部分看到。如果建立通信的最小有效仰角为地平线上方 25 度，那么卫星的覆盖范围是一个半径为 940 公里的圆，或面积为 200 万平方公里的圆（较低的仰角是可能的，但通过地球大气层的较长路径段会降低信噪比，影响可用信号容量并增加总路径延迟）。
为了向地球表面的任何一点（510.1 百万平方公里）提供连续服务，轨道卫星的最小数量为 500 颗。这种使用卫星星座的方式意味着，基于 LEO 卫星的服务并不是简单地将信号发送到天空中的一个固定点，并由该单一卫星将信号反射到地球上的某个其他位置。连续的 LEO 卫星服务需要在卫星经过头顶时跨越一系列连续的卫星，并在用户和用户指定的地面站都能看到时，将虚拟电路路径切换到后续卫星。
在 550 公里的高度，轨道卫星相对于地球表面某一点的相对速度为 27,000 公里/小时，并在不到五分钟的时间内从地平线到地平线穿过天空。这对服务无线电部分的设计有一些影响。如果卫星星座足够大，那么卫星之间的距离足够近，不需要使用需要某种机械转向装置的大型碟形天线来跟踪单个卫星在其穿过天空的路径上的位置，但这本身并非没有缺点。
单个信号载波可能最初作为弱信号（相对而言）被获取，随着卫星的无线电转发器和地球天线对齐而增加强度，并在卫星移动时再次减弱。Starlink 的天线使用相控阵排列，使用平面上的较小天线网格。这允许通过改变网格中每个天线之间的相位差来电子控制天线。即便如此，这仍然是一个相对粗糙的安排，因此信号质量并不一致。这意味着随着相控阵天线在卫星经过头顶时跟踪每个卫星，信噪比不断变化。
似乎 Starlink 服务使用动态信道速率控制来应对这种不断变化的信噪比。发射器不断调整调制和编码方案以匹配当前的信噪比，如 IEEE 802.11ac 标准中所述。该信号的调制使用自适应相位幅度调制，随着信噪比的提高，调制器可以在相位幅度空间中使用更多的离散码点，从而在使用恒定频率载波信号的同时提高服务的有效容量。这意味着卫星服务试图以峰值传输效率运行，并且发射器不断调整其信号调制以利用卫星系统的瞬时信噪比。对于上层协议驱动程序，传输服务似乎具有不断变化的信道容量和延迟。
Starlink 卫星的 Ku 波段下行链路共有八个使用频分复用的信道。每个信道具有 240MHz 的模拟带宽。每个信道被分成帧，帧使用时分复用细分为 302 个间隔，每个间隔为 4.4 微秒，加上帧保护间隔，每帧为 1,333 微秒，或每秒 750 帧。每帧包含一个标头，其中包含卫星、信道和调制信息。这意味着假设每个活跃用户至少分配一个间隔，则存在高达 1.3 毫秒的竞争延迟。
这给我们留下了四个主要的 Starlink 服务容量变化的因素，即：
-
信号调制能力的变化是信号信噪比变化的直接结果。 -
卫星路径延迟的变化是由于卫星和地球天线的相对运动。 -
需要定期执行卫星切换。 -
与其他用户共享公共卫星传输介质引起的可变性，导致时隙竞争。
查看这些可变性因素如何影响服务特性的一种方法是使用容量测量工具定期测量服务容量。图 2 显示了在 Starlink 服务中进行的容量测量测试的结果。这里的测试是在 2023 年 8 月至 2024 年 3 月期间每四小时进行一次的 Speedtest 测量。该服务的下载容量中值约为 120 Mbps，个别测量值高达 370 Mbps，低至 10 Mbps，上传容量为 15 Mbps，变化范围在 5 Mbps 到 50 Mbps 之间。
在互联网术语中，ping 是一个非常古老但仍然非常有用的工具，这可能解释了它的长寿。图 3 是 Starlink 连接上从客户侧终端到 Starlink 地面站后面的第一个 IP 端点的连续（洪水）ping 的 380 秒间隔的图（“洪水”ping 在每次从远程端接收到数据包时发送一个新的 ping 数据包）。
在此 ping 数据中可见的第一个主要特征是，最小延迟每 15 秒定期变化一次。似乎这种变化与 Starlink 用户的终端被分配到不同的卫星相关。这意味着用户设备每 15 秒“跟踪”一颗卫星，这对应于 11 度的弧角。
第二个特征是，在卫星切换时会发生丢失事件，以及由于阻塞、信号质量或拥塞而较少发生的丢失事件。
第三个是，当用户被分配到不同的航天器时，延迟会显著增加。此数据集中的最坏情况是从 30 毫秒增加到 80 毫秒。
最后，在每个 15 秒的卫星跟踪间隔内，延迟变化相对较高。连续 RTT 间隔之间的抖动平均变化为 6.7 毫秒。切换时的延迟尖峰增加了 30 毫秒到 50 毫秒，表明系统中存在深度缓冲区以容纳与卫星切换相关的瞬态问题。为了说明这种链路行为，ping 数据集已被过滤以消除在第 283 秒和第 298 秒分配卫星的影响（图 5）。
当使用 1 秒间隔的 ping 进行长时间测量时，总体数据包丢失率略高于 1% 作为长期平均丢失率。
TCP 协议性能
TCP (RFC 793) 是滑动窗口肯定确认协议的一个实例。发送方维护所有已传递到本地系统 IP 层的数据的本地副本，并且只有在收到接收方的肯定确认后才会丢弃该本地副本的发送数据。
TCP 的变体基于发送方控制将数据传递到网络的速率的变化以及对数据丢失的响应的变化。TCP 的经典版本在没有丢失的情况下使用发送窗口大小的线性膨胀，并在数据包丢失时将此窗口减半。这是 Reno TCP 控制算法。它在当今互联网中的使用已被 CUBIC TCP 控制算法 所取代，该算法使用变化的窗口膨胀率，试图将发送速率稳定在略低于网络队列形成的水平（这最终会导致数据包丢失）。
一般来说，对于此类 TCP 控制算法，关于网络路径特性有一小组常见的假设：
-
路径的 稳定 最大容量，其中稳定性描述了在几个往返时间 (RTT) 间隔内可用路径容量相对恒定的情况。 -
抖动（端到端延迟的变化）量相对于 RTT 较低。 -
平均数据包丢失率较低。在基于拥塞的丢失 TCP 控制算法的情况下，数据包丢失通常被算法解释为网络缓冲区已满的迹象，丢失是缓冲区溢出的指示。
显然，正如我们所指出的，对于包含 Starlink 组件的端到端路径，前两个条件不一定成立。丢失配置文件也不同。存在潜在的拥塞引起的数据包丢失，就像在任何非同步分组交换介质中一样，但在卫星切换期间可能会发生额外的丢失组件，并且无线电信号的其他损害可能会引起进一步的丢失组件。
TCP 通常倾向于通过使用保守的选择来应对此类环境。
RTT 估计是 RTT 测量值的平滑平均值，加上各个测量值与该平均值的平均偏差。对于 Starlink，由于其 RTT 测量值的个体差异相对较高，这意味着 TCP 发送方可能会以高于最小 RTT 的 RTT 估计值运行，这可能导致发送速率低于系统的可用端到端容量。
非拥塞引起的数据包丢失的发生也会影响 TCP 性能。通常，丢失会导致发送方快速减少其发送窗口，基于如果此丢失是由网络缓冲区溢出引起的，则发送方需要允许这些缓冲区排空，然后以较低的速率恢复发送，这应该恢复反馈控制环路的连贯性。
这在实践中如何运作？
图 6 显示了 Starlink 电路上 TCP CUBIC 会话的详细视图。前两秒显示了慢启动 TCP 发送速率膨胀行为，其中发送窗口在每个 RTT 间隔内翻倍，在两秒内达到 240Mbps 的峰值。发送方然后在下一秒切换到快速减少发送窗口的模式，在一秒内将其发送速率降至 50Mbps。此时，CUBIC 拥塞避免阶段似乎开始发挥作用，发送速率在接下来的五秒内增加到 70Mbps。在第 8 秒有一个丢失事件，导致发送速率回落到 40Mbps。跟踪的其余部分显示了相同的慢发送速率膨胀和间歇性速率减少行为，这是 CUBIC 的典型特征。
此 CUBIC 会话的平均传输速率约为 45Mbps，远低于约 250Mps 的峰值名义电路容量。
Starlink 是一个共享介质，系统在本地使用量较少（非高峰）时的性能与高峰时的性能显著不同。图 7 显示了非高峰时 CUBIC 的性能配置文件。
高峰和非高峰之间的可达到的吞吐量差异非常显著，非高峰性能达到的吞吐量水平比高峰负载性能高出三到四倍。慢启动阶段在第一秒内将吞吐量增加到约 200Mbps。然后流量振荡了一秒，然后在第 4 秒开始更稳定的拥塞避免行为。CUBIC 窗口膨胀行为在第 12 秒之前可见，然后流量在会话的剩余时间内围绕 200Mbps 的吞吐量振荡。
图 6 和图 7 中的这两个配置文件之间的差异是 Starlink 设备的主动流量管理的结果，还是 CUBIC 如何与其他并发流量达到流量平衡的结果？
我们可以尝试通过使用不同的 TCP 控制协议来回答这个问题，该协议对与其他并发流量的竞争有完全不同的响应。
瓶颈带宽和往返传播时间 (BBR) 协议是 Google 大约十年前开发的 TCP 拥塞控制算法。BBR 试图将 TCP 流量定位在网络队列形成的开始，而不是在满和空队列状态之间振荡（就像大多数基于丢失的 TCP 拥塞控制算法的情况一样）。
简而言之，BBR 对网络路径的延迟带宽积进行初步估计，然后驱动发送方以该速率发送六个连续的 RTT 间隔。它对丢失的数据包执行修复而不调整其发送速率。第七个 RTT 间隔看到发送速率增加 25%，并在此间隔内仔细测量端到端延迟。
周期中的最后一个 RTT 间隔看到发送速率从原始速率下降 25%，旨在排空在前一个 RTT 间隔中可能形成的任何网络队列。如果在发送速率膨胀间隔内端到端延迟增加，则保持原始发送速率。如果增加的发送窗口没有影响端到端延迟，则表明网络路径有进一步的容量，并且延迟带宽估计在下一个八 RTT 周期中增加。（BBR 协议有几个后续修订，但在这种情况下，我使用的是原始（v1）版本的 BBR。）
使用 BBR 的 Starlink 性能测试结果如图 8 所示。
在这种情况下，BBR 对路径带宽进行了初步估计，约为 250Mbps。此估计在第 14 秒似乎已修订为约 350Mbps，然后在 15 秒后降至约 200Mbps，并在测试的最后 10 秒保持在该水平。这些变化可能是 BBR 对 Starlink 中卫星切换的响应，延迟的变化被 BBR 解释为队列形成的迹象，或队列形成的缺失，这被用来改变 BBR 对链路的带宽延迟估计。
在非高峰时间进行了相同的 BBR 测试，结果非常相似（图 9）。
如果 BBR 对延迟变化敏感，而 Starlink 中的延迟如此多变，那么为什么 BBR 与 CUBIC 相比表现如此出色？
我怀疑这里 BBR 不是采取单一的延迟测量，而是在发送方将其发送速率增加到突发速率后测量此第 7 个 RTT 间隔内发送的所有数据包的 RTT，并使用最小 RTT 值作为“加载”RTT 值来确定是否执行发送速率调整。只要最小 RTT 水平保持一致（如图 3 所示，显示这些值在每个 15 秒调度间隔内是稳定的），BBR 将假设其发送速率不会导致网络队列形成，并将保持其发送速率。
Starlink 的协议调整
Starlink 提供了一种有些独特的数据链路服务。它具有非常高的抖动率，与网络拥塞无关的约 1% 到 2% 的数据包丢失率，以及每 15 秒定期跳跃的延迟配置文件。从 TCP 协议的角度来看，Starlink 代表了一个异常恶劣的链路环境，较旧的 TCP 变体，如 Reno TCP，在 Starlink 连接上使用时表现非常差，它们对数据包丢失反应迅速，恢复缓慢。
你能调整 TCP 的变体以优化其在包含 Starlink 组件的路径上的性能吗？
一个有前途的方法似乎是从 BBR 的变体开始。选择 BBR 的原因是它能够在面对单个数据包丢失事件时保持其发送速率。如果要为 Starlink 优化 BBR，则可以注意到 Starlink 每 15 秒定期执行一次卫星切换，如果 BBR 的定期发送速率膨胀与计划的卫星切换时间同时发生，BBR 发送方可以推迟其速率膨胀，在计划的切换时间内保持其当前发送速率。
BBR 的问题是，对于该协议的第 1 版，它在声称网络资源方面相当激进，这可能会使其他非 BBR TCP 并发会话的容量不足。一个可能的回应是使用相同的 15 秒卫星切换计时器与第 3 版的 BBR 协议，该协议旨在与并发数据流一起工作时不那么激进。
理论上，可以以类似的方式调整 CUBIC，如果在计划的卫星切换时发生数据包丢失，则使用选择性确认 (SACK) (RFC 2883) 执行丢失数据包修复。虽然 CUBIC 是一种更公平的协议，用于与路径容量共享其他并发 TCP 会话，但当面对高抖动路径（如端到端路径包含 Starlink 组件时）时，它往往反应保守。即使对计划的卫星切换有一些敏感性，CUBIC 仍然容易降低网络资源的使用效率。
一种有些不同的方法可以使用显式拥塞通知 (ECN) (RFC 3168)。这种方法的优点是它允许 TCP 会话区分高发送速率导致网络队列形成（拥塞）的情况，而瞬态事件（如卫星切换）导致数据包丢失而没有网络队列形成的情况。ECN 可以允许一种非常像 BBR 的流量控制行为。
虽然早期的 TCP 控制协议（如 Reno）在 Starlink 连接上表现不佳，但较新的 TCP 对应物（如 CUBIC）表现更高效。使这些协议在 Starlink 环境中可行的主要 TCP 特性是使用选择性确认，这允许 TCP 控制算法区分孤立的数据包丢失和导致网络拥塞的丢失。
试图检测网络队列形成开始的 TCP 控制协议可以通过在突发期间检测端到端延迟的变化来使用端到端技术来做到这一点，如 BBR。这些协议需要谨慎实施其对延迟的敏感性，因为 Starlink 连接上高度不稳定的短期延迟，加上 15 秒的粗粒度延迟变化，有可能混淆队列开始检测算法。
如果 Starlink 路由设备启用了 ECN，观察 ECN 感知的 TCP 协议的行为将是有趣的。ECN 有潜力为端点提供关于网络级队列形成开始的清晰信号，与延迟变化不同。
支持红外夜视IRCUT的4G智能安全帽BW620Y，内部主板型号有，SAE01, W20, k61v1_32_bsp_1g, k62v1_64_bsp， soq_azw_05_Natv，soq_azw_01_Natv，AZW003，aqm6816，soq_azw_01_Natv，SC161, W25，比传统的白光照明灯效果要好很多，可以避免图像中间大块的亮光斑，可以在雾天使用。https://www.bilibili.com/video/BV1594y1E7tB/
危险气体检测仪，通过4G/5G执法记录仪或者4G/5G智能安全帽上报到平台，https://www.besovideo.com/detail?t=1&i=273
智能安全帽~生命体征检测与危险气体检测一体化集成设计还是蓝牙无线外挂式方式好？https://www.besovideo.com/detail?t=1&i=279
智能安全帽~生命体征采集上报，https://www.besovideo.com/detail?t=2&i=506
智能安全帽，检测生命体征上报平台， https://v.douyin.com/e3oP4Yx/
AIoT万物智联，智能安全帽生产厂家，执法记录仪生产厂家，为大型国企央企提供移动视频类产品的ODM/OEM服务，单北斗定位智能安全帽、智能头盔、智能头箍、头盔记录仪、独立北斗定位执法记录仪、智能视频分析/边缘计算AI盒子、车载视频监控/车载DVR/NVR、布控球、智能眼镜、智能手电、智能电子工牌、无人机4G补传系统等统一接入大型统一视频平台~融合通信可视指挥调度平台VMS/smarteye 。
什么是智能安全帽，如何选购智能安全帽，智能安全帽的主要功能，https://www.besovideo.com/detail?t=1&i=109
目前支持的AI智能算法、视频智能分析算法有哪些，https://www.besovideo.com/detail?t=1&i=297
视频演示1~单独北斗定位智能安全帽助力光伏新能源， 视频演示2~石油石化
海康、大华等5000路固定点摄像头走国标GB28181接入统一视频平台smarteye，支持eHome,ISUP, SIP，萤石云，CMSV6等
海康等IP摄像头走国标GB28181接入smarteye平台， https://www.besovideo.com/detail?t=1&i=244
国网+南网电力施工作业现场安全生产风险管控应用方案，https://www.besovideo.com/detail?t=1&i=50
轻危大型厂矿可视化监管系统方案（有内部作业视频数据安全保密的需求），https://www.besovideo.com/detail?t=1&i=258
小微型4G/WiFi执法记录仪、胸牌记录仪大全~智慧养老+银发经济，https://www.besovideo.com/detail?t=2&i=1784
超薄款4G工牌视频记录仪BH128，https://www.besovideo.com/detail?t=2&i=1575
超小微型4G胸牌视频记录仪BZ223，全国产芯片，单独北斗定位， https://www.besovideo.com/detail?t=2&i=1542
4G/5G执法记录仪前端人脸识别、人脸比对使用说明，https://www.besovideo.com/detail?t=1&i=365
防抖执法记录仪、智能安全帽、头盔记录仪大全，https://www.besovideo.com/detail?t=2&i=1692
可拆卸智能安全帽、绑带式、粘贴式、贴合式、分体式智能头盔记录仪、智能头箍记录仪大全，https://www.besovideo.com/detail?t=2&i=1697
定位安全帽大全，人员定位考勤、电子围栏脱岗检查 all in smarteye，https://www.besovideo.com/detail?t=2&i=1843
支持南方电网WAPI无线网络的4G/5G执法记录仪、智能布控球、智能安全帽产品，https://www.besovideo.com/detail?t=1&i=404
各种布控球分类列表大全，https://www.besovideo.com/detail?t=1&i=339
北斗双频高精度定位智能工卡、电子工牌大全，https://www.besovideo.com/detail?t=2&i=1689
无人机4G/5G图传到远程指挥中心统一视频平台smarteye或者海康等国标大平台， https://www.besovideo.com/detail?t=2&i=1775
县级应急指挥调度系统建设， https://www.besovideo.com/detail?t=1&i=411
智慧铁路，铁路应急指挥通信系统建设，可视化作业现场风险管控系统应用方案，https://www.besovideo.com/detail?t=1&i=413
智慧港口可视化作业风险管控系统建设方案，https://www.besovideo.com/detail?t=1&i=414
石油石化可视化巡检系统安全风险管控系统应用方案，https://www.besovideo.com/detail?t=1&i=415
车载视频监控产品，车载DVR/NVR、4G行车记录仪系列产品，https://www.besovideo.com/detail?t=2&i=1850
为什么武警、特警拉练演习的MESH自组网系统都不约而同的选择了smarteye平台？https://www.besovideo.com/detail?t=2&i=1215