2025 年 11 月 17 日，一篇关于“迈向星际 QUIC 流量”的技术记录引发了对深空互联网未来的讨论。文章开篇提出一个看似冷门却耐人寻味的问题：当公众从“毅力号”火星探测器下载图片时，究竟使用了哪些通信协议？这一疑问源自 2024 年 4 月网络上一则颇具技术色彩的简短招募信息，其内容是寻找熟悉 QUIC 与 Quinn 的专家参与深空 IP 项目。尽管文字简短却行话繁多，但信息背后指向了令人振奋的研究方向：在星际距离上使用 QUIC 协议进行通信。
相关背景显示，QUIC 是一种可替代 TCP 的互联网可靠通信协议，Quinn 是最受欢迎的 Rust QUIC 实现，而项目的目标则是让地球与遥远行星上的计算机能够通过 QUIC 进行通信。由于参与者此前曾为 Quinn 做出贡献，他认为自己具备协助项目的基础。由此展开的研究经历，构成了文章的主要内容。
深空通信困难重重。尽管人类已能与火星探测车乃至太阳系外的探测器保持联络，但随着参与太空探索的主体不断增加，现有架构的局限愈发凸显。扩展深空网络的努力仍在持续，其中一个颇具前景的方向是采用 IP 协议栈，并令 QUIC 成为可靠通信的首选协议。当前项目旨在证明 QUIC 能否在深空环境下稳定运行，并为未来部署提供具体指导。
然而，深空环境的巨大挑战使 QUIC 在默认配置下无法正常工作。例如，地球到火星的单程信号延迟高达 3 至 23 分钟，而信号中断也相当常见，这导致 QUIC 按默认设置尝试建立连接时必然超时，即使成功连接，也会因后续问题迅速断开。因此，关键不在 QUIC 协议本身，而在其配置需要针对深空环境进行高度定制。QUIC 的高度可配置性使得标准兼容的实现无需修改源码，只要暴露足够的配置选项，即可适配深空使用场景。相比之下，2000 年代初对 TCP 的评估已明确显示其不适用于深空网络。
为了找到适用于深空环境的 QUIC 配置，研究人员必须运行大量实验。所谓配置包括初始往返时间估计、失活后断线判断时间、拥塞控制算法等底层参数。虽然这些参数可以理论估算，但实际效果必须经过实验验证。因此实验流程为：设定 QUIC 参数，在模拟深空条件的网络中传输数据，收集指标并逐步找出有效与无效的参数组合。
最初的实验环境由一套程序组件组成：一端的服务器通过 QUIC 提供文件，另一端的客户端负责下载，两者连接于模拟深空网络的测试环境中。该模拟网络由一组虚拟机构成，模拟从 NASA 科研人员的电脑到火星探测车之间的路径，并附带深空延迟与信号中断逻辑。然而，深空延迟的引入造成实验耗时极长，例如模拟从火星下载文件可能需要等待数十分钟，甚至因断连而更久，严重影响实验迭代效率。
为提升迭代速度，科研团队提出了一个关键假设：若能控制程序内部的时钟与数据包 I/O，实验即可“瞬时”完成。实现路径包含两项措施：让程序时钟以超快速度推进，甚至在等待计时器时直接跳过时间；同时取消真正的网络 I/O，将客户端与服务器整合在同一进程中，通过自建模拟网络通信，使网络延迟也随程序时钟跳过。Rust QUIC 实现 Quinn 的高度模块化恰好提供了这些扩展点。其时间系统可通过 tokio 的 start_paused 特性实现自动时间跳跃，而模拟网络则借由 AsyncUdpSocket 与 UdpPoller 接口接入。
新系统成功实现了“瞬时深空实验”，并额外带来了确定性与可调试性优势。在模拟网络中，所有数据包都会被记录成 .pcap 文件，可使用 Wireshark 等工具进行分析，使外界得以对“虚拟深空链路”进行可视化排查，极大提升了调试效率。
文章结尾对最初的问题给出答案：目前从“毅力号”火星车传输图片时使用的协议是低层 CFDP。但作者指出，未来某一天，答案或许将变成 QUIC。