一个用于模拟国际空间站通信中延迟/中断容忍网络的开源框架
大家读完觉得有帮助记得关注和点赞!!!
摘要
延迟/中断容忍网络(DTN)对于在具有挑战性的网络环境中实现可靠通信至关重要,尤其是在无法保证端到端连接的空间系统中。我们提出了一个用于与国际空间站通信的束协议的全栈开源实现,具备完整的安全特性,包括使用HMAC-SHA256和AES-256-CBC加密的束认证块、载荷完整性块和载荷机密性块。该系统还包括束的分片与重组、基于优先级的队列、带有ACK/NAK机制的保管传递以及自动重传。我们的系统还包含一个由现代响应式Web界面促进的前端。我们认为这项工作在计算机网络背景下具有高度相关性,因为:(i) 它展示了一个全栈、开源、免费可用的关键可靠协议的实现;(ii) 它为计算机网络和通信领域提供了一个交互式的教育和学习框架。
I. 引言与动机
互联网的基础协议(TCP/IP)是在连续端到端连接、低延迟和对称双向链路的假设下设计的。虽然这些假设适用于大多数地面网络,但在深空通信、灾难恢复场景、远程传感器网络和低地球轨道卫星系统等具有挑战性的环境中,它们根本上是失效的。国际空间站(ISS)在约420公里高度以7.66公里/秒的速度运行,提供了一个引人注目的案例:地面站每次过境的接触窗口仅持续5-10分钟,而连续两次接触之间间隔45-90分钟。像TCP这样的传统传输协议会将这些断连视为网络故障,触发拥塞控制机制,并最终无法可靠地传输数据。
延迟/中断容忍网络(DTN)通过一种根本不同的范式来应对这些挑战。DTN不假设持久连接,而是使用“存储-转发”架构,中间节点持续存储消息(称为束),直到出现合适的转发机会。DTN架构已得到空间数据系统协商委员会的认可,并已实际部署在国际空间站上,使其成为计算机网络教育中一个日益重要的主题。
尽管DTN的重要性与日俱增,但能够展示这些协议实际运行并提供实用实现的可访问教育工具仍然稀缺。学习延迟容忍网络的学生通常只接触到理论描述,而没有机会在真实的操作环境中观察束路由、保管传递、链路预算动态和切换过程。截至目前,只有少数几个例子可用[1, 2, 3, 4, 5]。
在教学和调研环境中被标记为“实现”的大部分内容,仍然不是学习者可以打开、运行和探察的东西。这使得从知道DTN存在,到理解当束在网络中实际移动时,轨道运动、射频裕度、保管传递、分片和端到端安全如何相互作用之间存在差距。我们提出的工具通过以开源方式发布整个流程来弥补这一差距。每一层都是有意可读和可编辑的,以便用户能够将教科书概念与具体函数关联起来,使用参数进行实验,并扩展系统;这种透明度仅靠理论材料或单体式、封闭的实现是难以达到的。
这促使我们开发了开源的ISS通信模拟器[6]。
I-A 学习成果
本项目在计算机网络和通信领域满足了多个教学目标:
协议理解:学生可以观察束协议如何处理消息封装、分片和保管传递——这些概念仅通过静态图表难以领会。
网络仿真:通过利用Mininet [7],学生可以体验具有可配置带宽、延迟和丢包参数的真实网络仿真,这些参数动态地反映轨道几何关系。
物理层意识:链路预算计算让学生接触到射频工程概念,包括自由空间路径损耗、大气衰减、多普勒频移和香农-哈特利容量极限。
安全机制:束安全协议块的实现展示了存储-转发网络中的端到端安全性,在这种网络中,中间节点必须是可信的保管者。
全栈开发:Python/FastAPI后端与React/Three.js前端的结合,展示了构建交互式网络可视化工具的现代软件工程实践。
I-B 与计算机网络的关系
这项工作与计算机网络的几个核心主题相交:
延迟/中断容忍网络:DTN架构[8, 9, 10]代表了对传统互联网假设的重大背离。我们的实现展示了关键的DTN概念,包括束协议的存储-转发范式、用于可靠传递的保管传递机制,以及在具有调度连接性的网络中用于路径计算的路由。模拟器可视化地展示了束如何在地面站网格中穿行,在中间节点等待,直到国际空间站接触窗口实现最终传递。
使用Mininet进行网络仿真:Mininet [7]能够利用软件定义网络能力创建真实的虚拟网络拓扑。我们的系统创建了一个连接到中央ISS节点的地面站节点部分网状网络,其链路参数(带宽、延迟、丢包)基于实时轨道计算动态更新。这允许学生观察实际的数据包流,而不是模拟的抽象。
链路预算与物理层:虽然计算机网络课程通常关注第3层及以上,但空间通信需要理解决定链路可用性的物理层约束。我们的链路预算计算器实现了完整的射频路径分析:发射功率、天线增益、自由空间路径损耗、作为仰角函数的大气衰减以及热噪声计算。由此产生的信噪比通过香农-哈特利容量估计确定可达到的数据速率,直接影响界面中可视化的束传输时间。
具有挑战性网络中的路由:与传统路由不同,DTN路由必须考虑时变连接性。我们的实现使用实时可见性和下次过境预测来进行路由决策。束通过地面站网格向具有更早预测接触窗口的站转发,展示了传统网络课程中不存在的机会路由策略。
II. 方法论:实现细节
开源代码库可访问:https://github.com/kritgrover/iss-simulator。进一步的文档、技术细节、教程和视频演示也可在代码库中找到。一个可测试的部署已在 https://utsc.utoronto.ca/webapps/iss-simulator/ 提供,为用户提供了一种测试系统基本功能的方法。¹
II-A DTN 架构与束协议概述
延迟/中断容忍网络架构通过在传统 OSI 模型之上引入一个新的协议层——束协议,从根本上区别于传统模型,该层作为传输层之上的一个覆盖层运行。在我们的实现中,束是自包含的消息,包括源端点和目标端点、载荷数据、安全块以及用于路由和保管传递的元数据。
RFC 5050 [11] 和 RFC 9171 [12] 中规定的束协议将束定义为 DTN 网络中数据传输的基本单位。每个束包含一个主块(路由和元数据)、载荷块(应用数据)以及用于安全、分片和其他服务的扩展块。我们的实现遵循此结构,同时提供仿真和网络仿真模式,以演示协议在真实条件下的行为。
该系统使用现代技术栈构建,集成了以下元素:
后端:使用带 FastAPI [13] 和 WebSocket [14] 服务器的 Python,利用 Skyfield [15] 基于简化常规扰动模型进行轨道跟踪,并使用 Mininet(可选)[7] 进行真实的网络仿真。
前端:使用带 TypeScript [17] 的 React (Vite),利用 Three.js [18] 进行 3D 地球可视化,使用 Recharts [19] 进行实时分析,并使用 Tailwind CSS [20] 实现响应式 UI。
协议:实现了束协议(RFC 5050/9171)[11, 12] 的仿真,支持保管传递、分片、优先级队列和加密。
II-B 系统架构概述
该模拟器采用客户端-服务器架构,后端仿真逻辑与前端可视化之间有清晰的分离。后端以两种不同的模式运行:仿真模式和 Mininet 仿真模式,可通过USE_MININET环境变量选择。在仿真模式下,束传输通过基于时间的计算进行建模,不使用实际的网络套接字,从而实现快速原型设计和教学演示。Mininet 模式创建一个具有真实 TCP/IP 套接字的虚拟网络拓扑,允许使用 Wireshark [21] 等工具进行数据包级检查,并提供真实的网络行为,包括实际的数据包丢失、延迟和带宽限制。后端由几个核心模块组成:
orbital_tracker.py处理基于 SGP4 的位置计算link_budget_calculator.py计算射频链路参数dtn_bundle_manager.py实现束协议逻辑bsp_security.py提供 BSP 加密和认证bundle_fragmentation.py管理基于最大传输单元的分片network_dtn_manager.py为 Mininet 网络操作扩展束管理器
一个 SQLite 数据库持久化存储束元数据、传输历史以及用于分析和调试的传输记录。
前端通过 WebSocket 连接与后端通信以获取实时更新,并通过 REST API 端点进行束的创建和管理。状态管理遵循 React 的组件化架构,使用自定义钩子封装数据获取和 WebSocket 通信逻辑。
II-C 前端实现
前端构建为一个使用 React 和 TypeScript 的单页应用,提供轨道力学、束传输和网络拓扑的实时可视化。界面组织为两个主要视图:地面站视图(主界面)和 ISS 视图(专用于中继回传和解密消息的 ISS 视角)。
1) 3D 地球可视化: 3D 地球组件使用 Three.js 渲染一个具有实时 ISS 位置和轨道路径可视化的交互式地球模型,如图 1 所示。该实现采用 WebGL 进行硬件加速渲染,即使在复杂几何体下也能确保流畅的 60 FPS 性能。
地球由一个应用于球体几何的高分辨率地球纹理图(NASA 蓝色弹珠)构成。ISS 表示为一个 3D 模型,通过球面到笛卡尔坐标转换并配合坐标系调整来定位。这些关系使得前端能够在一个一致的坐标系中跟踪飞行器:每次更新周期中,来自后端的地理纬度、经度和高度被转换为场景坐标,确保 ISS 精灵、地面站标记和“可见”链路射线随着轨道状态变化而保持对齐。如果没有明确的映射,小型地球模型和 WebGL 坐标轴会相对于纹理和站点标记发生漂移;这些公式强制相同的数值状态同时驱动分析面板和 3D 视图。
图 1:主仪表板界面,显示 3D 地球可视化、轨道参数和下次过境。
II-D 后端引擎
1) 轨道跟踪与位置计算: 轨道跟踪子系统使用简化常规扰动模型传播算法计算 ISS 的实时位置。双行元素数据从 celestrak.org 获取或从本地缓存的上次 celestrak 调用中获取,提供 SGP4 计算所需的轨道参数。OrbitalTracker类构建于 Skyfield 库之上,计算地心惯性坐标系中的 ISS 位置,并将其转换为大地坐标以进行可视化。
对于每个地面站,系统使用球面三角学计算视角。仰角决定了可见性:当仰角超过可配置阈值(默认为 0°)时,认为该站可见。过境预测算法通过搜索仰角超过阈值的过渡来识别即将到来的接触窗口,以 1 分钟为间隔计算信号捕获和信号丢失时间。
2) 链路预算计算: 我们按照标准空间通信工程实践实现了一个全面的射频链路分析。当轨道跟踪器更新 ISS 位置和每个地面站的视角(距离、仰角、方位角)时,计算器刷新任务分析员会监控的相同射频量:链路在物理上是否可行、相对于噪声有多少裕度,以及最重要的是,在一次过境期间可以维持的数据速率。这些跟踪值提供给 UI(信噪比、容量、估计传输时间)和传输调度器:更高的有效速率缩短接触期间的束传递时间,而裕度的丧失对应于链路动态中的链路丢失。
链路预算通过以下链条计算信噪比:
其中 PtPt 是发射功率,GtGt 和 GrGr 是发射和接收天线增益,LFSLFS 是自由空间路径损耗,LatmLatm 是大气衰减,LcableLcable 和 LmiscLmisc 是线缆和其他系统损耗,NfloorNfloor 是噪声基底功率。这些术语共同解释了为什么当跟踪过境时,信噪比会随着距离和仰角的变化而变化。噪声基底计算为:
其中 kBkB 是玻尔兹曼常数,TT 是系统噪声温度,BB 是带宽。跟踪 NfloorNfloor 固定了灵敏度基线,随着几何形状演变,接收功率与之进行比较。
自由空间路径损耗使用弗里斯传输方程计算:
其中 dd 是以公里为单位的距离,ff 是以 MHz 为单位的频率,cc 是光速。由于 dd 直接来自瞬时的 ISS 站几何关系,当用户跟随一次过境从升起到落下时,LFSLFS 是主要的驱动因素。
由于在低仰角下通过对流层的路径长度增加,大气衰减随仰角变化。我们的实现使用了一个带有路径长度缩放因子的经验模型:
其中 θθ 是以弧度为单位的仰角,L0=0.5L0=0.5 dB 是天顶处的衰减。路径长度因子上限为 10.0,以防止在非常低的仰角下出现不切实际的损耗。因此,当仪表板在一次接触期间跟踪仰角时,LatmLatm 解释了纯自由空间模型忽略的地平线附近的额外衰落。
多普勒频移补偿对于维持载波锁定至关重要。ISS 和地面站之间的相对速度从轨道状态向量计算,多普勒频移计算为:
其中 f0f0 是载波频率,vrvr 是以 km/s 为单位的径向速度分量。跟踪 fDopplerfDoppler 将来自 SGP4 的运动状态与物理层关注点联系起来,即使教学 UI 在载波环路细节之前强调速率和裕度,学生也能理解。
可达到的数据速率使用香农-哈特利定理确定:
其中 CC 是以比特/秒为单位的信道容量。系统应用 75% 的效率因子来考虑编码和调制的低效率,得出直接影响束传输时间的实用数据速率。换句话说,用户看到的“Mbps”或传输预计到达时间的量同样来自上述相同的信噪比链;随时间跟踪 CC 具体地展示了轨道运动和天气主导的损耗如何在短暂的接触窗口期间限制 DTN 吞吐量。
3) 束协议实现:DTNBundleManager类实现了核心的束协议功能。每个束表示为一个DTNBundle数据类,包含:束标识符、源端点和目标端点、加密载荷、优先级、创建时间戳、生存时间、保管传递标志、用于防止循环的跳数列表以及安全块。
图 2:地面站视图显示用于创建束的界面,展示加密文本、网络拓扑、链路参数和传输历史。
束的创建遵循 BP 规范:在接收到来自地面站的消息后,系统生成唯一的束 ID,使用束安全协议加密载荷,计算用于完整性验证的 SHA-256 载荷哈希,并初始化路由元数据。然后,该束在源站的传输队列中排队,按优先级和创建时间排序。
优先级队列确保优先束在接触窗口期间首先被传输。队列排序算法使用复合键:优先级级别(加急 > 正常 > 批量),然后是创建时间戳。这保证了优先级别内的公平排序,同时确保时间关键型消息得到优先处理。图 2 显示了消息界面,包括束物流的多个方面。
4) 束安全协议:bsp_security.py中的束安全协议实现提供了 RFC 6257 [22] 中规定的三种安全块类型:
束认证块 (BAB):提供节点间的逐跳认证。每个 BAB 使用 HMAC-SHA256 和共享密钥创建,在每个转发节点认证束的完整性和来源。BAB 包含安全源、安全目标(下一跳)以及在束的元数据和载荷哈希上计算的加密签名。BAB 在每一跳重新生成以反映新的安全源-目标对,确保中间节点无法在不被检测到的情况下重放或修改束。
载荷完整性块 (PIB):提供束载荷的端到端完整性验证。PIB 包含在加密载荷哈希上计算的签名。PIB 在加密后创建,确保完整性检查覆盖将要传输的密文。在交付时,目标节点通过重新计算加密载荷哈希上的 HMAC 签名并将其与 PIB 签名值进行比较来验证载荷完整性。这确保了接收到的加密载荷与最初签名的一致,而无需解密进行完整性验证。
载荷机密性块 (PCB):使用 AES-256-CBC 提供束载荷的端到端加密。加密密钥使用 PBKDF2 从共享密钥派生,迭代 100,000 次并使用 SHA-256。PCB 包含初始化向量和密文,仅允许目标节点(拥有共享密钥)解密载荷。中间节点可以在无法访问明文的情况下转发加密束,即使在不信任的网络环境中也能提供机密性。
安全块创建过程遵循特定顺序:PIB 和 PCB 在束创建时生成,然后 BAB 在传输过程中的每一跳生成。这个顺序确保 BAB 是最外层的安全层,提供束元数据和载荷哈希的逐跳认证,而 PIB 和 PCB 提供端到端的完整性和机密性保护。
5) 束分片与重组: 超过 MTU 的大束必须被分片以穿越异构网络链路。我们实现了分片程序,可配置 MTU 为 4096 字节(包括头部)。
当束的总大小超过 MTU 时,自动进行分片。分片算法将加密载荷划分为固定大小的块,每个块分配一个从 0 开始的片序号。每个片成为一个具有自己束 ID 的独立束,但在元数据中共享父束 ID 以进行重组跟踪。图 3 显示了这样一个场景。
片束包括:父束 ID、片序号、片总数和片载荷。所有片共享来自父束的相同安全块,确保端到端安全性在分片边界上得以保持。
图 3:ISS 视图显示中继接口、消息收件箱和重组组件。
重组在目标节点进行。reassembly_buffers字典按父束 ID 跟踪接收到的片。当接收到父束的所有片时,这些片按片序号排序并连接以重构原始的加密载荷。然后解密重组后的载荷。PIB 完整性验证在每个片到达时进行,确保重组后的加密载荷在解密前与原始载荷匹配。
6) 路由算法: 我们的实现使用一种下次过境预测方法,考虑预测的 ISS 经过地面站的情况,来决定将束转发到哪个站。我们实现了一种广度优先搜索寻路算法,通过地面站网格构建路由。
对于从地面站发往 ISS 的束,算法:
识别具有 ISS 可见性的站,并选择具有最早预测接触窗口的站。
如果选定的站不是源站,则使用 BFS 通过网状网络找到到达该站的路径。
返回完整路由:
[源站, 中间站..., 接触站, ISS]。
对于从 ISS 发往地面站的束,算法相反:它找到当前可见的站或具有即将到来过境的站,然后通过网格路由到最终目的地。
网状拓扑由地面站之间的成对连接定义,创建一个部分网状网络。地面站链路以 100 Mbps 运行,具有最小延迟(模拟),实现站之间的快速束转发。路由算法通过维护已访问节点列表并在转发前检查束的跳数历史来避免循环。
广播束使用洪泛算法:束被转发到所有连接的站,通过重复检测防止无限循环。每个站维护一个broadcast_received集合,跟踪哪些束已经被处理。
7) 保管传递与可靠性: 保管传递在 DTN 网络中提供了可靠的交付保证。当启用保管传递传输束时,接收节点负责交付,向发送方发送保管确认或否定确认。图 4 显示了这样一个场景。
我们的实现使用超时机制跟踪待处理的确认。PendingAcknowledgment类存储:束 ID、预期的 ACK 源、超时时间戳和重传计数。如果在 30 秒内未收到 ACK,系统将传输标记为失败并重试最多 5 次,之后束将被丢弃。
当束到达最终目的地时,发生交付确认。目标节点发送一个交付 ACK,束状态更新为DELIVERED。已交付的束被记录到数据库以进行历史分析,并从活动传输队列中移除。
图 4:显示路由和接收到的 ACK、校验和以及其他用于跟踪束的信息的后端日志(Mininet 模式)。
8) 线程安全与并发: 后端在多线程环境中运行:主 FastAPI 事件循环处理 WebSocket 连接和 HTTP 请求,而后台线程管理束传输、Mininet 网络操作和数据库写入。当多个线程访问共享束状态时,线程安全对于防止竞争条件至关重要。
DTNBundleManager依赖 Python 的全局解释器锁来实现基本的线程安全。然而,GIL 仅确保单个字节码操作的原子性,并不能防止多个线程修改字典和列表等共享数据结构时的竞争条件。束字典、站队列和 ISS 队列的访问没有显式锁定,这意味着并发修改可能导致不一致。大多数操作在 FastAPI 事件循环内发生,或者通过事件循环的单线程性质进行序列化,但真正的线程安全需要显式锁定。
NetworkDTNManager(Mininet 模式)使用存储在_node_locks字典中的threading.Lock对象实现每节点锁。这些锁专门用于序列化node.cmd()调用,因为 Mininet 的命令执行不是线程安全的,并发调用可能导致AssertionError异常:
python
node_lock = self._get_node_lock(from_node)
with node_lock:
# 仅保护 node.cmd() 调用
result = source_node.cmd(cmd)
这种细粒度锁定允许在不同节点上并发操作,同时防止多个线程在同一节点上执行命令时发生冲突。
数据库操作使用 SQLite 内置的线程安全机制。DatabaseManager每个方法调用创建一个连接(而不是每个线程),并且每个连接在使用后立即关闭。写操作通过 SQLite 的内部锁定进行序列化,这防止了数据库损坏,同时允许并发读取。这种方法在数据库级别确保了线程安全,无需应用层显式锁定。
9) 仿真模式 vs. Mininet 仿真模式: 系统支持两种具有不同特性的操作模式:
仿真模式:束传输通过基于时间的计算进行建模,不使用实际的网络套接字。当束传输启动时,系统根据束大小和数据速率计算传输持续时间,然后在主循环中使用基于时间的周期性更新来跟踪进度。此模式提供快速执行、确定性行为和易于调试,使其成为教学演示和快速原型设计的理想选择。然而,它不会捕捉真实的网络效应,如数据包丢失、实际的 TCP/IP 行为或网络拥塞。
Mininet 仿真模式:使用 Mininet 的软件定义网络能力创建一个虚拟网络拓扑。该拓扑包括:一个 ISS 节点(IP: 10.0.0.100/24)、多个地面站节点(IP: 10.0.0.1-9/24),以及一个在部分网状网络中连接地面站的 Open vSwitch。束传输通过 Mininet 节点之间的真实 TCP 套接字进行,链路参数(带宽、延迟、丢包)基于轨道计算动态更新。
在 Mininet 模式下,NetworkDTNManager扩展了DTNBundleManager以处理基于套接字的通信。每个地面站运行一个 DTN 服务器,监听端口 5000,接受来自其他节点的束传输。LinkParameterManager实时更新 Mininet 链路参数:当 ISS 对某个站可见时,链路带宽增加、延迟减少;当可见性丢失时,通过将链路带宽设置为非常低的值来有效地禁用链路。
Mininet 模式支持使用 Wireshark 进行数据包级检查,允许学生观察实际的 DTN 协议消息、加密头部和网络行为。这提供了真实的网络仿真,但需要 root 权限和更多的计算资源。
如果 Mininet 不可用或初始化失败,系统会自动回退到仿真模式,确保在不同的部署环境中都能稳健运行。
10) 数据库持久化: 束元数据和传输历史被持久化存储到 SQLite 数据库中,用于分析、调试和恢复。DatabaseManager类提供线程安全的数据库操作,具有自动模式迁移和损坏恢复功能。
数据库模式存储完整的束状态,包括:束标识符、源端点和目标端点、加密载荷(Base64 编码)、用于完整性验证的载荷哈希、优先级和状态、创建和交付时间戳、保管传递信息、跳数列表和路由路径、安全块以及分片元数据。
复杂数据结构被序列化为 JSON 字符串进行存储,然后在检索时反序列化。这种方法平衡了模式简单性和数据灵活性,允许系统存储任意路由路径和安全块结构,而无需更改模式。
数据库实现自动迁移:当添加新列时,迁移函数检测缺失的列并添加它们而不丢失数据。这确保了与现有数据库文件的向后兼容性,同时支持新功能。
损坏恢复得到优雅处理:如果检测到数据库损坏,系统会自动重新创建数据库文件并重新初始化模式。虽然这会导致数据丢失,但它防止了系统崩溃并允许继续运行。在生产部署中,定期备份可以缓解此风险。
数据库操作依赖 SQLite 的内部锁定来实现并发访问。每个数据库方法同步执行操作,即每个方法在返回之前完成其事务。SQLite 的内部锁定处理并发读写,防止同时访问导致数据库损坏。虽然这为 SQLite 操作提供了基本的线程安全,但应用程序没有实现应用层的显式锁。对于高并发场景,可能需要在应用层进行额外的同步以协调复杂的多步骤操作。
III. 用例与实际应用
ISS 通信模拟器已被开发为一个教育平台,桥接了 DTN 概念的理论理解与实践理解。因此,它是一个完美的工具,用于激发对空间通信中延迟容忍网络的理解,以及其使用的实际演示。
模块化的代码库结构、全面的文档以及标准技术(Python、React、TypeScript)的使用降低了贡献的门槛,使具有中级编程技能的用户也能访问该项目。MIT 许可证鼓励共享修改和扩展,培养了一个学习者和贡献者的社区。
该模拟器在设计时考虑到了可扩展性,允许教育内容随着项目的发展而增长。未来的增强可能包括:
交互式教程:分步指导之旅,引导用户在使用模拟器的同时了解关键概念,为不同技能水平提供结构化的学习路径。
作业模板:教师可以分配的预配置场景和练习,并带有学生解决方案的自动评估(例如,“优化路由以最小化给定消息集的交付时间”)。
比较协议分析:并排比较模式,显示传统 TCP/IP 在 DTN 成功的相同场景下如何失败,提供协议差异的可视化演示。
多卫星场景:扩展以支持多颗卫星或卫星星座,从而能够研究更复杂的空间网络拓扑。
性能分析:增强的指标和可视化工具,用于分析路由效率、交付成功率和网络利用模式。
通过使 ISS 通信模拟器开源且以教育为重点,我们旨在降低理解延迟容忍网络和空间通信的门槛,使这些关键技术能够为下一代网络工程师和空间系统开发人员所用。理论学习资源(工具提示、“学习”选项卡)与实用的动手探索(Wireshark、分片观察、加密工作流)的结合,提供了一个全面的教育体验。
IV. 实验评估
为了定量地表征模拟器的行为并验证其正确性,我们在两种模式下(仿真和 Mininet)进行了受控实验。两种模式都使用确定性的接触时间表,以便运行是可重现的。
IV-A 实验设置
仿真模式:实验 E1 和 E4–E6 在标准工作站上以仿真模式执行。地面站网络由九个地理分布的站(多伦多、伦敦、东京、悉尼、华盛顿特区、新加坡、班加罗尔、圣保罗、莫斯科)组成,通过站间链路为 100 Mbps 的网状拓扑连接。
接触窗口遵循基于代表性 ISS 轨道参数的合成时间表:轨道周期为 92 分钟,每个站有 8 分钟的接触窗口,这些窗口在各站之间错开,以模拟 51.6° 倾角轨道的地面轨迹进展。在接触期间,ISS-地面链路以 56 kbps(代表 S 波段业余无线电链路)运行,距离约为 800 公里,仰角为 30°。脚本experiment_runner.py在配置的时间注入束并推进虚拟时钟,将较长的轨道时间线压缩为几秒的挂钟时间。所有束都使用 AES-256-CBC 加密和 HMAC-SHA256 认证(BAB/PIB/PCB 安全块处于活动状态)。
Mininet 仿真模式:实验 E3、E7 和 E8 使用mininet_experiment_runner.py,它实例化与实时系统相同的九站部分网状拓扑(基于 Mininet 的NetworkDTNManager):地面到地面链路为 100 Mbps,ISS-地面链路通过 Linuxtc更新,具有 56 kbps 带宽、3 ms 延迟和可配置的随机丢失百分比。一个挂钟时间表在所有站之间切换 2 分钟的接触窗口和 3 分钟的间隙;在“中断”期间,ISS 链路严重降级(有效带宽接近为零),因此流量必须等待下一个窗口。束传输使用 Mininet 主机之间的真实 TCP 连接;MetricsCollector除了记录 DTN 级别的交付统计信息外,还记录每跳套接字 RTT、发送成功计数和观察到的丢失。
可重现性:完整的安装依赖项、运行后端实验和解释输出的说明与代码一起保存在公共代码库中 [6]。
IV-B 基线交付与延迟
我们首先通过从分布在整个网络中的站向 ISS 传输 20 个每个 500 字节的束来建立基线性能。表 I 总结了结果。
表 I:基线交付性能(E1:20 个束,500 B 载荷)
指标 | 值 |
|---|---|
交付率 | 100% (20/20) |
平均延迟 | 64.7 秒 |
中位数延迟 | 2.0 秒 |
第 95 百分位延迟 | 262.0 秒 |
最大延迟 | 661.0 秒 |
平均跳数 | 1.95 |
重传次数 | 0 |
保管 ACK | 19 |
NAK | 0 |
所有 20 个束都成功交付到 ISS,零失败。延迟分布揭示了 DTN 特有的双峰行为:当其源站(或附近站)具有 ISS 可见性时创建的束在几秒钟内交付(中位数 2.0 秒),而在接触间隙期间创建的束必须等待下一次过境,导致高达 661 秒(约 11 分钟)的延迟。第 95 百分位延迟 262 秒反映了合成接触时间表的过期间隙。平均每个束经过 1.95 跳(一次地面到地面的保管传递,随后一次地面到 ISS 的上行链路),这与将束转发到具有最早 ISS 接触的站的网状路由策略一致。
IV-C 安全开销
DTN 实现的一个关键问题是安全机制引入的开销。我们测量了束安全协议在 64 B 到 16 KB 载荷大小范围内的尺寸和处理时间开销。表 II 报告了结果。
表 II:按载荷大小划分的 BSP 安全开销(AES-256-CBC 加密,HMAC-SHA256 认证)
明文 (B) | 加密后 (B) | 开销 (B) | 开销 (%) | 总时间 (ms) |
|---|---|---|---|---|
64 | 108 | 44 | 68.8 | 13.11 |
128 | 192 | 64 | 50.0 | 0.03 |
256 | 364 | 108 | 42.2 | 0.03 |
512 | 704 | 192 | 37.5 | 0.03 |
1,024 | 1,388 | 364 | 35.5 | 0.03 |
2,048 | 2,752 | 704 | 34.4 | 0.03 |
4,096 | 5,484 | 1,388 | 33.9 | 0.08 |
8,192 | 10,944 | 2,752 | 33.6 | 0.05 |
16,384 | 21,868 | 5,484 | 33.5 | 0.07 |
对于 1 KB 以上的载荷,尺寸开销收敛到约 33.5%,这归因于 AES 分组密码填充(PKCS7)和密文的 Base64 编码。对于小载荷(≤ 128 B),初始化向量和填充的固定开销占主导地位,对于 64 字节载荷达到 68.8%。在初始密钥派生(PBKDF2,100,000 次迭代)之后,所有载荷大小的处理时间都保持在 0.1 毫秒以下,表明 BSP 安全为束处理增加的计算成本可以忽略不计。第一次加密调用会产生约 13 毫秒的一次性密钥派生成本,该成本在后续操作中被摊销。
IV-D 分片影响
超过 2,048 字节 MTU 的束会自动分片。我们评估了三种载荷大小:1 KB(低于 MTU)、4 KB(2 个片)和 16 KB(8+ 个片),每种 10 个束。
表 III:分片对交付和开销的影响
指标 | 1 KB | 4 KB | 16 KB |
|---|---|---|---|
交付率 | 100% | 100% | 100% |
平均延迟 (秒) | 103.5 | 103.5 | 103.5 |
安全开销 (B) | 844 | 1,856 | 5,856 |
平均跳数 | 1.8 | 1.8 | 1.8 |
挂钟时间 (秒) | 0.7 | 1.9 | 6.2 |
所有载荷大小都实现了 100% 的交付率和相同的延迟特性,表明分片和重组机制保持了交付可靠性。安全开销与载荷大小成比例增长,而挂钟处理时间因额外片束在网络中传输而增加。值得注意的是,16 KB 载荷产生的束每个需要 8 个以上的片,但系统正确地重组并交付了所有片。
IV-E 可扩展性
为了评估系统在负载增加下的行为,我们将并发束的数量从 1 变化到 50,同时保持载荷大小恒定为 500 B。表 IV 总结了结果。
表 IV:可扩展性:性能 vs. 并发束数量
束数量 | 1 | 5 | 10 | 25 | 50 |
|---|---|---|---|---|---|
交付率 | 100% | 100% | 100% | 100% | 100% |
平均延迟 (秒) | 661.0 | 145.8 | 103.5 | 43.4 | 35.4 |
P95 延迟 (秒) | 661.0 | 577.2 | 472.0 | 135.4 | 134.8 |
保管 ACK | 1 | 5 | 8 | 21 | 44 |
平均跳数 | 2.0 | 2.0 | 1.8 | 1.84 | 1.88 |
系统在所有负载水平下都保持 100% 的交付率,表明优先级队列和保管传递机制有效地处理了并发束。平均延迟随束数量增加而减少,因为更接近接触窗口注入的束受益于立即传输;随着更多束均匀分布在时间上,更高比例的束与活动接触窗口重合。无论负载如何,跳数保持稳定在大约 2 跳,表明路由算法始终选择高效的路径。这些结果证实,模拟器优雅地扩展到至少 50 个并发束,而性能没有下降。
IV-F Mininet 仿真验证
我们用 Mininet 实验来补充上述仿真扫描,这些实验通过真实的 TCP 套接字和内核网络执行相同的 DTN 逻辑。表 V 将仿真基线(E1:92 分钟轨道周期,8 分钟错开窗口,虚拟时间)与 Mininet 基线(E8:全局 2 分钟“上行”/3 分钟“下行”时间表,真实挂钟时间,10% 基线 ISS 链路丢包,除非另有说明)进行了对比。两种场景都向 ISS 发送 20 个 500 B 的束。不同模式下的绝对延迟不能直接比较,因为接触时间线和时间基准不同;关键的观察是两者都保持了 100% 的束交付率,而 Mininet 增加了可观察的套接字层行为。
表 V:仿真基线 (E1) vs. Mininet 基线 (E8),20 个束,500 B 载荷
指标 | E1 (仿真) | E8 (Mininet) |
|---|---|---|
交付率 | 100% (20/20) | 100% (20/20) |
平均延迟 | 64.7 秒 | 3.2 秒 |
中位数延迟 | 2.0 秒 | 1.9 秒 |
第 95 百分位延迟 | 262.0 秒 | 9.1 秒 |
最大延迟 | 661.0 秒 | 16.8 秒 |
平均跳数 | 1.95 | 1.0 |
保管 ACK / NAK | 19 / 0 | 0 / 2 |
套接字发送 (成功/总数) | — | 20 / 22 |
平均套接字 RTT | — | 2735 毫秒 |
观察到的网络丢包 (发送) | — | 9.1% |
在 E8 中,两次套接字级别的失败通过 DTN 重传/NAK 处理得以恢复(20 个束发送了 22 次),实现了 90.9% 的网络层交付率,但应用层交付率为 100%。在整形的 ISS 链路下,平均单向套接字 RTT 平均为 2.7 秒,反映了慢速带宽和排队。
我们将配置的 ISS 链路丢包率从 0% 扫描到 30%(各 10 个束,运行 90 秒)。表 VI 显示,在每个丢包水平下,束交付率都保持在 100%:存储转发加上保管语义吸收了会使简单单次尝试传输失败的数据包丢失。套接字统计随丢包率变化:在 5% 配置丢包率下,我们观察到一次 NAK 和一次额外的发送(每次发送成功率为 90.9%),然后最终交付;在几个更高的丢包设置下,记录运行中的所有十次发送都成功了(预期会有随机变化)。
表 VI:Mininet E3:束交付 vs. 配置的 ISS 链路丢包率(各 10 个束)
丢包率 (%) | 交付率 | 平均延迟 (秒) | 平均 RTT (ms) | 发送成功/总数 |
|---|---|---|---|---|
0 | 100% | 3.0 | 3291 | 10/10 |
5 | 100% | 9.4 | 6676 | 10/11 |
10 | 100% | 2.1 | 1872 | 10/10 |
20 | 100% | 1.4 | 1272 | 10/10 |
30 | 100% | 1.1 | 922 | 10/10 |
最后,我们在相同的间歇性 Mininet 拓扑下比较了 DTN 交付与原始 TCP(E7)。一个束使用完整的 DTN 栈从多伦多注入到 ISS,并成功完成(100% 交付,该次运行中端到端延迟约 4.6 秒)。然后,我们从一个主机向端口 5000 上的 ISS 监听器发起五个独立的 TCP 连接,携带相同的 500 字节载荷,同时链路时间表进行切换;所有五个连接都未能完成传输(0/5),出现诸如“No route to host”之类的错误,因为虚拟链路在上行和降级状态之间移动。这说明了该工具的一个核心教学点:传统 TCP 假设一个稳定的路径,而 DTN 被设计为通过在断开连接期间保留保管权直到下一次接触机会来跨越断连。
V. 结论与讨论
在本文中,我们介绍了 ISS 通信系统中使用的 DTN 协议的一个开源实现。该项目的开发旨在允许从业者扩展、修改和调整其功能。该工具能够与网络行业的标准工具(如 Mininet、Wireshark 等)交互和协同工作。同样,该实现还考虑了计算机网络安全上下文中的几个重要元素,例如分片、加密、数据完整性和验证等等。实验表明,在仿真和 Mininet 环境下,面对分片、并发负载和高 ISS 链路丢包率时,束交付率达到 100%,而传统的 TCP 传输在相同的间歇性时间表下失败,这清楚地表明存储-转发保管权在这些具有挑战性的环境中是不可或缺的。
我们的目标是为感兴趣的人士提供一个他们可以在此基础上以多种方式构建和调整的起点,以追求自己感兴趣的领域。
