> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20200102-freebsd-zai-yan-jiu-zhong/freebsd-in-network-research-and-standardization.md). # FreeBSD 在网络研究与标准化中的应用 我们的研究关注互联网协议，以及如何改进它们让互联网变得更好。我们在网络上进行测量，了解实际部署情况，并基于测量结果开发新的机制、增强与改进。我们的工作成果进入并指导互联网工程任务组（IETF）的互联网标准，并将工作公开发表，让整个互联网社区受益。 我们的研究组参与 IETF 工作已超过三十年，贡献了广泛的标准。近年我们有两项重点工作：尝试让互联网支持更大的分组尺寸，以及确保新协议在卫星网络中良好运行。 FreeBSD 是我们许多工作的载体。通过将 FreeBSD 同时用于研究测试床与新特性目标，我们能完成与更大组织相当的工作。 FreeBSD 已成为我们研究的重要组成部分。近年来，我们以三种不同方式使用 FreeBSD： * 配合 ZFS 的 FreeBSD 构成我们研究组存储网络的核心组件。 * FreeBSD 与 dummynet 在我们进行的网络实验中作为核心组件。 * FreeBSD 网络协议栈是研究新协议特性的高性能平台。 我们的研究组非常幸运，在阿伯丁大学拥有自己的网络。随着 IT 服务部门从计算机科学与工程系接管计算机运营，这种情况越来越少见。我们运行实验室与测试床的所有基础设施，将大学作为上游提供商接入英国研究网络 JANET。 凭借独立的网络，我们能够从自己管理的 IP 地址空间中托管与运行实验。这给实验组装带来极大灵活性，我们能仅在配置机器所需的时间内就搭建起测试网络。在许多其他机构，任何网络操作都需要与 IT 部门数月的协调与沟通，并且必须充分说明理由，非同寻常的请求才会被考虑。我们与大学的网络运营部门保持紧密关系，他们是我们维持独立性的关键。 ## FreeBSD 在网络研究与标准化中的应用 从我们的网络出发，能对互联网进行大规模测量，这些测量结果为协议设计与标准化提供输入。没有我们的视角与友好的上游，我们将不得不从云提供商处扫描整个互联网。在云提供商处搭建测量的复杂性难以想象，而我们却能在短时间内启动实验回答问题。 ## IETF 中的互联网标准化 互联网工程任务组是定义构建互联网所用协议的标准组织。IETF 与其他标准组织（如 ISO 或 IEEE）在许多方面不同，其中刻意开放的流程与志愿者核心尤为突出。 IETF 流程向任何能订阅邮件列表的人开放——参与的唯一门槛是参与本身。这与其他组织截然不同，这种开放模式让像我们这样的大学能与数十亿美元的公司与国家在同等层级上共同改进互联网。 IETF 定义的标准经历严格的撰写流程。它们首先以互联网草案形式由一组志愿者作者撰写或整理。这些文档可能被工作组采纳，在其中接受评审与意见，并通过可能持续数月或数年的流程改进其中的想法。当想法成熟并经过彻底评审后，文档可能以其独有的 RFC 编号发布为 RFC。 “粗略共识与可运行代码”是 IETF 的核心准则之一。可运行的实现是评估新想法的指标之一，IETF 倾向于在草案向 RFC 推进时存在多个可互操作的实现。真正成熟的、高质量、高性能的网络协议栈开源操作系统只有两个：FreeBSD 与 Linux。 草案有了实现非常有帮助，这样就能在它将部署的环境中测试，并能仔细检查定义协议的标准语言。 我们在 Linux 与 FreeBSD 上实现过许多不同协议，涵盖其生命周期的各个阶段，包括我们自己撰写的文档与他人撰写的文档。其中一些想法最终成为 RFC，另一些则在 IETF 流程中无法证明价值而被搁置。 我们研究了新的传输协议（DCCP、UDP Lite 与 UDP Options），对现有协议（如 TCP）的增强（TCP ABE RFC 8511、NewCWV RFC 7661），新的网络层机制（Hop by Hop MTU），开发了新的协议机制（Datagram PLPMTUD），并为卫星网络的默认参数提供过建议。 我们还参与记录与改进 Sockets API（RFC8304），并参与 TAPS 工作组创建下一代传输框架。我们正在改进现有的 socket API，这些改进源于在用户空间或基于 UDP 运行的传输协议的开发。 ## 用 FreeBSD 与 Dummynet 模拟卫星 我们的研究组与卫星网络合作历史悠久。往返地球同步轨道的额外时延对传输协议性能影响巨大。近期我们与欧洲航天局合作，研究 QUIC 传输协议在卫星网络中的表现。 QUIC 是一种新的基于 UDP 的传输协议，旨在替代 HTTP/2。该协议最初由谷歌开发，后由 IETF 接手作为工作项。经过大量努力，工作组现已接近发布 QUICv1。QUICv1 设计了新的 HTTP 层 HTTP3，将用全面加密的协议替代 Web 中的 HTTP2。强加密与认证是 QUIC 的根基，以至于大多数协议头部对网络不可见。 卫星运营商与提供商担心全面加密的影响。TCP 在卫星网络中表现良好的部分原因在于：卫星终端上通常运行增强 TCP 的代理。这些代理让 TCP 在卫星的高延迟与可变延迟下可用的方式之一，是在家庭终端与卫星网关处拆分连接。这种拆分对 TCP 透明，但对 TCP 性能有极大的提升作用。 我们连接到 HYLAS 1 卫星的 KA 波段卫星天线，位于阿伯丁大学著名的 Sir Duncan Rice 图书馆大楼上方。 QUIC 明确旨在让此类代理无法实现。性能增强代理不再可用，因此必须对 QUIC 在卫星网络场景下单独评估。互联网社区与卫星运营商需要合作，让他们的网络在未来部署中切实可行。 我们的测试床网络有一条卫星链路，类似于你在偏远山间小屋用作 DSL 替代的链路。我们过去曾用这条链路研究苏格兰农村地区互联网的发展与变化。这条链路每天容量有限。为能在卫星路径上重复实验，我们必须创建一条尽可能贴近真实卫星的模拟链路。拥有模拟链路来验证测试，还有助于让我们的工作可被其他没有酷炫卫星可玩的人复现。 高质量网络模拟有两个选择。Linux 提供网络模拟模块（netem），FreeBSD 则有与 IPFW 协作的 dummynet 框架。我们在链路上进行了一系列实验，得到其典型特征模型，以及前向（下行）与回程（下行）链路容量和网络时延的数值。我们使用的地球同步卫星系统典型时延为 600ms，与客户 DSL 线路相比巨大。 我们创建测试床时力求周全，同时配置 FreeBSD dummynet 与 Linux netem 测试床。时钟与时序问题让在虚拟机中构建模拟网络变得不切实际——这虽令人遗憾，但我们不确定是否有解决之道。Linux 的网络命名空间确实能规避许多时序问题，同时能在单台主机上运行多个节点。遗憾的是，dummynet 尚不能在 FreeBSD 的 vnet Jail 中工作。 由于需要独立主机，我们倾向使用 PC ENGINES APU 2 主板，它在 FreeBSD 与 Linux 上支持良好，且价格足够低廉，让我们能组建一个小集群用于网络实验。 在配置模拟网络方面，FreeBSD 优于 Linux。受 netem 网络模拟器设计所限，我们难以让 Linux 性能达到所需水平。我们发现分组能绕过我们设置的时延与容量限制。当偶尔有分组能以正常速度 100 倍穿越网络时，难以确保结果可信。netem 配置困难近期也困扰了其他人，我们看到其他团队转而默认使用 dummynet 与 FreeBSD 进行卫星网络模拟。 ## FreeBSD 改进 我们的 FreeBSD 内核工作始于 2014 年。当时我们在标准化对 TCP 的修改——NewCWV。NewCWV 定义了 TCP 在流量突发（如观看流媒体视频时）下的新行为机制。 我们曾在 Linux 上有 NewCWV 实现，是在协议机制研发期间开发的。我们尝试将此代码合入 Linux 上游，但 Linux 网络社区相当封闭，反应冷淡。 IETF 偏爱可运行代码，可运行代码越多越好。我们有一个项目推进前的窗口期，我建议把我们的代码从 Linux 移植到 FreeBSD。 让代码被开源项目接受，其难度与实现本身相当甚至更难。路人提交的可能是个 bug 修复或新特性，但所有代码都需要维护，接受任何代码的成本都需权衡。当代码是触及核心网络路径的实验性特性时，判断是否应接受就更加困难。 可运行代码在 IETF 流程中非常重要——如果有人付出了实现努力，想法更可能获得关注。当想法处于早期阶段时，通过原型化往往能产生重大影响。FreeBSD 的可访问性与社区的友善意味着，我们能花时间在 FreeBSD 中把玩实现。如果想法未成功（也许方法不太对，或时机不合适），我们可以向想法的作者反馈。这让我们在 IETF 流程中能扮演非常积极的评审角色。 IETF 的 6MAN 工作组便是一例。6MAN 工作组维护 IPv6，是协议扩展的开发场所。近期 6MAN 对修复路径 MTU 发现（对所有网络运维与系统管理员都是难题）产生兴趣。2018 与 2019 年间，出现了六七种尝试不同路径 MTU 探测方法的想法。我们能对其中的几种进行原型化，发现实现难点。这项工作仍在推进，但我们放心投入少量时间尝试，因为我们知道如果想法成熟，FreeBSD 社区会给予公正评审。 过去三年，我们与明斯特应用科学大学合作，研究在互联网上使用更大分组尺寸的新方法。我们的新算法 Datagram Packetization Layer Path MTU Discovery（我最喜欢的绕口标准名）设计用于数据报协议，无论其在用户空间还是内核中。该算法的标准部分已接近成熟（在 2020 年初进入工作组流程的最后阶段），我们自豪地说已有多种实现，其中包括 Julius Flohr 在 2019 年末访问我们组期间为 FreeBSD 的 SCTP 协议栈完成的实现。 当你想分享新东西时，FreeBSD 社区更容易理解与接触。一旦找到合适的人，FreeBSD 社区非常友好，会有开发者帮助你把补丁或新想法推进成优秀的成果。 ## 未来 FreeBSD 在研究社区中作为目标与研究对象都有着悠久的传承。我相信 FreeBSD 将继续作为传输与网络协议推进的目标。 作为研究平台，我认为我们正在落后于时代潮流。devops 浪潮随 Docker 而来，对实验与测量活动的组装方式产生了巨大影响。我们作为 H2020 Fire 项目的一部分参与了一个研究测试床，它以 docker 镜像作为部署实验的核心组件。 Jail 与 vnet 对该平台或许更优雅、更易用，但思维份额在 Docker 一边，难以论证构建新系统的合理性。已有不少项目致力于为 FreeBSD 打造更接近 Docker 的方案，我们希望它们能发展到提供与 Linux 容器生态相同功能集的程度。 我们致力于让实验可复现，devops 风格的流水线作为部署与运行实验的方法有许多可取之处。Docker 催生了大量软件包与 API，使可编程工具成为可能。虽然可以拼凑出类似系统，但我们常常不得不通过 shell 管理接口或配置防火墙。 Dummynet 已存在很久，是我们在测试床网络中使用 FreeBSD 的核心。Dummynet 已数年未有积极开发，虽然近期有改动允许大于 2Gb/s 的规则，但尚未获得在 10 与 100 Gb 速度下支持流量整形与模拟所需的关注。 对我们的卫星用例而言，dummynet 仍然良好工作，因为所需容量较低。但对于可能需要非常高容量网络的其他团队，我不确定 dummynet 是否仍是可选项。 ## 结语 对我们而言，FreeBSD 既是实验室基础设施的一部分，也是科学的目标。将 FreeBSD 作为工作目标让我们对其高度熟悉，持续的接触也让我们愿意将 FreeBSD 作为实验平台。FreeBSD 的基础让构建测试床变得容易，并积极地辅助我们的实验，但要成为完美的科学平台，仍有可改进之处。 FreeBSD 社区欢迎并鼓励新工作，这一事实让我们能合理地提议将新想法引入操作系统。没有这个社区，我们可能不会尝试实现来自 IETF 的新想法。FreeBSD 是我们工作的重要组成部分，我们希望在未来许多年中继续使用它。 *** **TOM JONES** 是苏格兰东北部阿伯丁大学工程学院电子研究组的研究员。他的工作关注互联网传输协议及其性能，聚焦于卫星网络。他在 IETF 从事标准化工作，致力于定义下一代 API 与算法以帮助互联网成长。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://freebsd-journal-cn.bsdcn.org/20200102-freebsd-zai-yan-jiu-zhong/freebsd-in-network-research-and-standardization.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.