执行摘要

  • Olivier Bonaventure 是 UCLouvain 教授兼工程学院院长，他的工作连接了互联网路由、传输协议、可运行代码、开放教育和商业部署。
  • 他是多路径 TCP 的主要学术架构师和 RFC 共同作者，而该协议的架构、拥塞控制、安全性和实现来自多个重叠的研究人员和工程师团队。
  • UCLouvain 帮助将 MPTCP 从规范转化为 Linux 代码和部署证据，这些证据后来被 Apple、电信运营商、Tessares 和上游 Linux 社区使用。
  • Bonaventure 的持久贡献是一种协议部署方法：保留有用的接口，在实际系统中测试假设，纠正失败并将维护责任移交给能够持久运行的组织。

一条连接如何应对网络故障

一部智能手机即使 Wi-Fi 连接中断，仍可保持在移动网络覆盖内。宽带用户可能拥有缓慢的固网线路和可用的蜂窝链路。服务器可以通过多条数据中心路由到达同一目的地，即使其中一条发生拥塞或故障。传统的传输控制协议（TCP）通常通过一对地址和端口来标识连接。当该路径消失时，即使其他路由仍然可用，应用程序也可能丢失会话。

多路径 TCP，通常简称为 MPTCP，正是围绕这一矛盾而设计的。它保留了现有应用程序所期望的可靠、有序字节流，同时允许端点在底层创建多个 TCP 子流。这些路径可以保持连接存活、聚合容量或允许流量根据本地策略移动。难点从来都不是观察到两条路径可能比一条好。挑战在于让它们像一个应用服务一样运作，而无需同时替换所有应用程序、服务器、防火墙、网络地址转换器或负载均衡器。这使得 MPTCP 既是一个部署问题，也是一个协议设计问题。

Olivier Bonaventure 的职业生涯为我们理解这一过程提供了一个视角。他并非独自发明了 MPTCP，也未编写所有实现或控制部署该协议的公司。他帮助构建了一条管道，让一项集体设计的协议得以从标准工作进入软件、测量、运营商产品和长期维护。

MPTCP 是由一个网络而非一个发明者构建的

简化的描述可能称 Bonaventure 为 MPTCP 的发明者，并从学术想法到商业使用画一条直线。标准和实现记录并不支持这种说法。MPTCP 出自 UCLouvain、伦敦大学学院、布加勒斯特理工大学、Cisco、Apple、互联网工程任务组（IETF）以及后来的 Linux 社区的研究人员和工程师。

这项工作被划分到几个技术层面。一些参与者开发了架构；其他人设计了线协议、拥塞控制算法、安全机制或应用程序接口；内核开发人员将这些文档转化为可运行代码；设备公司和电信运营商随后对路径策略、产品设计和支持做出了自己的决定。

Bonaventure 的贡献最好跨时间理解。他出现在实验性和标准轨规范、操作经验文档、UCLouvain 的研究和实现环境、教程、开放教育材料以及通过 Tessares 的商业化路径中。他帮助连接了通常分离的阶段：协议设计、实现、测量、标准修订、部署和机构传承。

这比单一发明者的标签更具影响力。协议很少因为一个人的精妙想法而成为基础设施。当多个组织能够实现、测试、运营、修订并最终维护它们，而无需永久依赖原始研究团队时，它们才成为基础设施。

围绕可部署性形成的职业生涯

Bonaventure 于 1992 年获得列日大学计算机科学工程学位。随后，他在 André Danthine 的网络小组担任研究工程师，同时完成博士学位。他在 1999 年的博士论文研究了异步传输模式（ATM）如何在 TCP/IP 之下运行，同时提供最低保证带宽。

该课题属于 20 世纪 90 年代的重大争论。ATM 提供了工程化的虚电路和服务等级，而互联网协议栈则围绕数据包、端点控制和逐步采用发展起来。技术问题不仅仅在于 ATM 能否承载 IP 流量，而在于能否在不丢弃已使用的应用程序、协议和运营实践的情况下引入新的网络能力。

这个问题在 Bonaventure 的职业生涯中反复出现。MPTCP 同样将新能力置于现有应用程序接口之下。它并非要求软件开发人员替换熟悉的 TCP 字节流，而是改变了传输层使用可用路径的方式。该机制与他的博士工作不同，但集成问题是相似的。

从 1992 年到 1997 年，Bonaventure 在列日大学担任研究工程师。公开记录无法重建该时期的每一项职责，但该序列将实现和网络实验置于他常规教职生涯之前。他后来的团队继续将论文与代码、教程和测量相结合。1997 年至 1998 年，他任职于 Alcatel-Bell。所审查的材料未确立具体的职位名称或识别特定产品，因此这一时期不应被美化。尽管如此，这使他短暂置身于一家电信公司，在那里兼容性、产品生命周期和客户支持提出了与实验室原型不同的约束。

1998 年，Bonaventure 成为 FUNDP（现为那慕尔大学）的助理教授。他于 2002 年转到 UCLouvain，2006 年成为教授，2011 年成为全职教授。截至研究截点，UCLouvain 将其认定为全职教授兼鲁汶工程学院院长。

漫长的 UCLouvain 时期提供了短期研究项目很少能提供的东西：连续性。MPTCP 需要研究生研究人员、内核开发、实验、IETF 参与、运营商关系和多年的维护。大学并不拥有该协议，Bonaventure 也没有编写每一个组件，但该团队创建了一个机构基础，使这些活动相互加强。

路由工作教会他设计过渡过程

在 MPTCP 成为他最显眼的关联之前，Bonaventure 从事路由、流量工程和收敛方面的工作。这些课题面临一个基本的运营问题：网络必须在继续承载流量的同时进行变更。运营商可能需要调整拓扑、策略或链路权重，而路由器持有分布式状态，相邻系统遵循各自的更新周期。数学上正确的目标状态是不够的。过渡过程可能在网络稳定之前产生环路、数据包丢失或临时拥塞。

Bonaventure 共同撰写了关于 OSPF（开放最短路径优先）网络中无中断拓扑重配置的工作，该工作于 2007 年获得 INFOCOM 最佳论文奖。这项工作将重配置视为一个有序的操作过程，而非单一计算。它探讨了网络如何从一个有效状态过渡到另一个状态，同时减少转发中断。

MPTCP 在传输层应用了同样的习惯。一个应用程序连接必须持续，而子流可能出现、消失或表现不同。该机制必须考虑过渡，而非假设端点始终以一组稳定的路由开始和结束。他在 BGP（边界网关协议）对等链路故障快速恢复方面的工作涉及一个更为保守的边界。域间路由将技术状态与商业策略和安全假设结合起来。没有运营商能强迫每个对等体同时升级。

后来关于 xBGP 和安全 BGP 传输的研究延续了这条探究路线。目标并非通过一次彻底替换来取代域间路由，而是在熟悉的运营结构中引入受控扩展点或更强的传输。因此，MPTCP 是一个更广泛职业问题的突出例子：基础设施如何在无需假装可以协商掉其现有基础的情况下进行变革？

MPTCP 在底层改变传输的同时保留了应用程序

传统 TCP 为应用程序提供可靠的顺序流，并将连接绑定到一对端点地址和端口上。当主机通常依赖一个主要网络接口且更改地址通常意味着更改网络身份时，该模型是有效的。移动设备、多宿主服务器和数据中心架构暴露了这一局限性。应用程序可以打开多个独立连接，但随后必须自行管理路径选择、排序和故障。绑定到一条连接的会话在路径故障时仍可能消失。

MPTCP 保留了普通的套接字抽象，同时让传输层了解多个地址和子流。现有应用程序可以继续看到一个连接，即使端点在其下使用了多条路径。这种机制可以产生三种不同的结果。弹性：当一条路径故障时，保持逻辑连接存活。聚合：通过多条路径发送数据以增加可用吞吐量。移动性和策略：根据无线电状况、成本、电池使用、运营商规则或应用需求添加或移除路径。

这些目标并不总是一致的。手机可能将蜂窝服务作为备用，因为持续使用它会消耗能源或数据配额。混合接入网关可能同时使用固网线路和 LTE。数据中心主机可能将流量分散到多条相似路由上。MPTCP 提供了机制，而路径管理器、调度器、拥塞控制和端点策略决定了用户获得的服务。

与现有互联网的兼容性成为核心约束。防火墙、网络地址转换器、负载均衡器、入侵检测系统和 TCP 优化器积累了关于普通 TCP 的假设。它们可能删除未知选项、重写数据包或期望连接中的所有字节沿一条路径传输。

因此，MPTCP 采用了 TCP 选项和外观普通的子流。如果能力协商失败，连接可以继续作为常规 TCP。这使得逐步部署成为可能，但也限制了选项空间，复杂化了握手并产生了一个可观察性问题：即使预期的多路径服务已悄然消失，应用程序仍可能正常工作。

标准记录排除了单一发明者的说法

MPTCP 的架构和标准文档显示了集体作者身份。RFC 6182 阐述了架构指南，由 Alan Ford、Costin Raiciu、Mark Handley、Sébastien Barré 和 Janardhan Iyengar 编写。RFC 6824 是实验性 MPTCP 版本 0 规范，由 Ford、Raiciu、Handley 和 Bonaventure 编写。后来的标准轨规范 RFC 8684 增加了 Christoph Paasch。

其他组件的作者不同。关于耦合拥塞控制的 RFC 6356 由 Raiciu、Handley 和 Damon Wischik 编写。Michael Scharf 和 Ford 记录了应用程序接口的考虑因素。Marcelo Bagnulo 及后来的贡献者参与了安全分析。

这种分工并非偶然。架构描述了诸如应用程序透明性、弹性、资源池化和增量部署等目标。线规范定义了选项、密钥、子流、序列映射和故障行为。拥塞控制解决了当一个逻辑连接可以使用多个 TCP 子流时的公平性问题。安全工作检查了令牌、子流附着和攻击者模型。实现随后将这些文档转换为内核状态和本地运营策略。

一个合理的架构并不能保证一个合理的握手。一个公平的拥塞控制算法在延迟差异很大的路径上仍可能表现不佳。一个实现可以遵循 RFC 却难以诊断。Bonaventure 的影响力在那些层面相交之处最强：利用实现和部署证据改进标准流程。

RFC 6824 作为实验性规范于 2013 年 1 月发布。它定义了 MPTCP 版本 0 并使用 TCP 选项类型 30。“实验性”并不意味着随意。它承认，对广泛部署的协议进行重大扩展需要来自实际软件和网络的证据，才能将其视为稳定的基础设施。这些证据来自研究内核、中间盒测试、数据中心实验、Apple 的部署和运营商系统。社区发现了仅靠文档审查无法暴露的握手、安全、路径管理和运营问题。

由 Bonaventure、Paasch 和 Gregory Detal 编写的 RFC 8041 将这一运营经验纳入标准记录。它涵盖了数据中心、Wi-Fi 和蜂窝链路、代理、中间盒干扰、拥塞控制、调度、强制门户和负载均衡服务器集群。该文档将部署行为视为能够改变协议的证据。这是一个重要的制度性步骤。规范并不仅仅因为先发布而保持权威。当实际代码反复与假设相矛盾时，标准必须考虑现有的网络。

RFC 8684 于 2020 年 3 月发布，取代了 RFC 6824，并将 MPTCP 版本 1 转移到标准轨上。它修订了MP_CAPABLE交换，并澄清了通过实现学到的行为。版本 1 与版本 0 不线兼容。这一断裂造成了迁移工作，但保留每一个实验性选择会带来其自身的代价。MPTCP 的发展表明，当运营证据使得早期设计难以维护时，成熟可能需要明确的版本边界。

一条连接，多个普通 TCP 子流

对应用程序而言，MPTCP 连接仍然显示为一个可靠的字节流。在底层，每个子流是一个普通的 TCP 连接，具有自己的序列号、拥塞窗口、重传、往返时间和故障状态。MPTCP 层协调它们，并向应用程序呈现一个有序的连接。

第一个子流从一个普通的 TCP 三次握手开始，并通过MP_CAPABLE选项进行增强。这表示两端都理解 MPTCP，并交换用于识别和验证连接的密钥材料。如果任一端或中间设备不支持该选项，会话可以继续作为普通 TCP。

一旦 MPTCP 连接存在，端点可以使用MP_JOIN创建另一个子流。加入交换携带一个标识连接的令牌和从连接密钥派生的基于 HMAC 的机制。它允许另一条路径加入，而无需透露完整密钥或使任意附着变得容易。协议不决定何时应创建额外的子流。这一责任属于路径管理器和部署策略。手机可能仅在 Wi-Fi 恶化时添加蜂窝服务。混合接入网关可能立即激活固网和移动路径。数据中心主机可能发现多个地址和路由。

MPTCP 可以宣告和撤销地址，并将路径标记为备用。这些功能与网络地址转换、隐私和服务器集群设计相互作用。本地地址可能无法从每条远端路径到达，而宣告所有接口可能暴露运营商希望保持私密的拓扑。因此，路径管理成为一个重要的策略边界。早期实现将大部分逻辑放在内核中。上游 Linux 后来添加了 netlink 和用户空间控制，允许特权软件根据设备和运营商要求添加或移除子流。

传输还必须维护两个序列空间。每个子流具有普通的 TCP 序列号，而逻辑连接使用数据序列号空间。数据序列信号将来自子流的字节映射到连接范围的流中，并在该更高层进行确认。

因此，先通过 Wi-Fi 发送的字节可以通过蜂窝网络重传，而不会改变应用程序看到的顺序。接收方必须区分丢失和延迟，对通过具有不同延迟的路径到达的数据进行重新排序，并防止一条慢速路由导致过多缓冲。调度器选择在哪里发送新数据和重传数据。最低往返时间调度器可以减少相似路径上的延迟，但会闲置较慢的容量。冗余调度器可以出于弹性目的通过多条路径传输相同数据，同时消耗更多带宽。备用调度器可以保留蜂窝服务直到 Wi-Fi 故障。

这些决策取决于服务。语音助手重视连续性和短暂中断。批量传输可能看重组合吞吐量。农村混合接入产品可能尝试使用所有可用的固网和移动容量。调度器是通用协议机制转变为具体产品策略的地方。拥塞控制带来另一个约束。如果每个子流像完全独立的 TCP 连接一样行动，一个 MPTCP 会话可能不公平地占据共同瓶颈。耦合拥塞控制旨在汇集资源，同时避免过度侵略性并将流量移向不太拥塞的路径。

网络拓扑可能部分隐藏。两条看起来独立的路径可能共享一个瓶颈、无线电资源或提供商链路。没有任何拥塞控制算法能推断每个商业和物理依赖，因此运营商仍需要测量和本地策略。

连接关闭也是分层的。TCPFIN可以关闭一个子流，而 MPTCP 连接在其他地方继续。连接级别的DATA_FIN关闭可靠流。重置和快速关闭机制处理突然故障。Linux 在首次上游合并后继续添加重置、计费、套接字选项和诊断行为，表明实现的完整性是多年形成的，而非一次发布。

现有互联网塑造了协议

MPTCP 端点并非通过中性管道通信。网络地址转换器重写地址和端口。防火墙检查握手状态。负载均衡器分发流量。TCP 优化器可能更改分段或有效载荷，而监控系统可能期望在一条路径上观察完整流。这些设备可能传递、剥离、修改或拒绝不熟悉的 TCP 选项。一个仅在干净的实验室端点之间工作的协议在公共互联网上几乎没有价值。

2012 年的 NSDI 论文《能有多难？》将这一问题置于研究的中心。Costin Raiciu、Christoph Paasch、Sébastien Barré、Alan Ford、Michio Honda、Fabien Duchêne、Olivier Bonaventure 和 Mark Handley 检查了中间盒行为、不等长路径、重排序、缓冲区压力和现实服务器及操作系统约束。

标题捕捉了从图表到系统的转变。在高层次上，跨路由拆分数据并重组数据看起来很简单。已部署的互联网将其转变为一个涉及兼容性、序列映射、调度和故障的问题。该论文获得 USENIX NSDI 社区奖，因为它提供了其他研究人员可以使用的可运行代码和证据。

回退对于这种可部署性至关重要。当MP_CAPABLE被剥离或阻止时，连接可以作为普通 TCP 继续。用户更有可能保留服务，但运营商可能不知道弹性或聚合已经消失。因此，生产系统需要关于协商成功、回退原因、子流创建、路径故障和调度的计数器。没有中断并不能证明 MPTCP 处于活动状态。提供商如果无法观察其声称所依赖的机制，就无法支持可信的多路径服务。

MPTCP 还验证子流的附着。它交换密钥、派生令牌，并在另一路径加入连接时使用基于 HMAC 的检查。安全分析已检查了令牌猜测、拒绝服务、地址宣告、子流劫持以及路径上或路径外攻击者。这不提供应用程序机密性。TLS 或其他应用程序安全层仍负责保护内容。MPTCP 的身份验证保护多路径连接的结构；它不替代其上的加密。

可运行代码将研究转化为基础设施

UCLouvain 的历史项目记录将 Sébastien Barré 归功于大约 2009 年启动了主要的 Linux MPTCP 实现谱系，部分借鉴了早期的 shim6 相关工作。Christoph Paasch、Gregory Detal、Fabien Duchêne 和其他许多人扩展了这棵代码树。它支撑了实验、教程和早期部署。

Bonaventure 的角色是研究负责人、协议共同设计者、导师、共同作者和偶尔的代码贡献者。这很重要，但并不使他成为主要的内核程序员。研究负责人可以通过组合人员、提出问题、保障合作和将代码作为共享实验平台提供来建立基础设施。

2019 年 ACM SIGCOMM 网络系统奖认可了 Linux MPTCP 实现，并指出 Paasch、Barré 和 Detal 为其主要开发者，同时承认更广泛的贡献者社区。他们的可见度很重要，因为该项目依赖于多种专业知识。制度建设并不取代工程荣誉；它创造了工程师能够产生持久工作的条件。

UCLouvain 的代码树可以比主线 Linux 更快地添加调度器、路径管理器、套接字选项和实验。这种灵活性对研究人员和早期采用者有用。它也造成了维护负担。用户必须携带补丁、跟随内核变化、集成安全修复并支持标准发行版生命周期之外的行为。

研究分支证明了机制可以工作。一个需要维护的子系统必须满足关于审查、兼容性、测试和支持的不同期望。上游化并非将代码复制到一个更大的仓库中。它将责任转移给另一个机构，且通常需要围绕那个社区能持续维持的内容重新设计接口。

初始 MPTCP 支持于 2020 年 3 月进入主线 Linux 5.6。第一次合并提供了连接建立、协议选项、命名空间控制和自测试。它尚未同时创建和使用多个子流，因此将 Linux 5.6 描述为完整的多路径实现会夸大这一里程碑。

有限的首次合并反映了上游治理。更小的步骤降低了评审风险，并允许子系统在承担完整的多路径操作之前建立测试和接口。该发布也表明，声称内核“支持 MPTCP”需要附加条件。版本、路径管理、调度器行为和诊断功能决定了该支持的含义。

后续工作添加了 netlink 路径管理器、多个子流的同时使用、连接级别的乱序处理以及用户空间控制。Matthieu Baerts、Paolo Abeni、Mat Martineau 和其他上游贡献者在此期间成为核心。Tessares 的工程师也参与了，但该子系统并非简单地完整移入了 UCLouvain 的代码树。这一进程在实践中展示了制度化。协议协商首先到来。策略接口和实际的多路径使用随后。重置处理、诊断和自测试继续发展。主线 Linux 成为通用的维护层，而设备制造商和运营商保留了路径策略的本地控制。

当前的 Linux 记录将 Matthieu Baerts 和 Mat Martineau 列为 MPTCP 维护者。Bonaventure 不是当前的 Linux MPTCP 维护者。历史影响并不产生当前的合并权限或安全责任。这种继任加强了他的影响力的论证。当协议能够在不需要其原始学术领袖接受每个补丁或诊断每个回归的情况下继续时，它就成为了基础设施。剩下的问题是，后来的社区是否有足够的维护者、测试和资金来维持该子系统。

部署依赖于产品策略和运营商经济

Apple 将 MPTCP 转化为可见的消费者基础设施。其支持材料解释称，iPhone 或 iPad 可以使用 Wi-Fi 作为主要连接，蜂窝服务作为备用。Siri 是最著名的例子。如果 Wi-Fi 不可用或无响应，应用程序可以通过蜂窝网络继续，而无需创建一个全新的逻辑会话。

建议网络管理员允许 TCP 选项 30，并在该选项无法通过时预期普通 TCP 回退。这次部署表明 MPTCP 可以在消费者规模上提供弹性。这并不意味着每个 iOS 应用程序都结合了 Wi-Fi 和蜂窝带宽。Apple 编写了自己的实现，运营了服务器端并选择了产品策略。Bonaventure 影响了上游研究和标准工作，但并未编写 Apple 的内部网络堆栈。

UCLouvain 的研究人员后来检查了 Apple 的切换行为，并报告了 iOS 11 中更广泛的应用程序访问。过渡并非字面上的瞬间完成，且端点策略仍然影响结果。一条连接可以在经历延迟、重排序或吞吐量降低的情况下承受路径变更。

物理网络并不会消失在抽象层背后。移动连续性仍然取决于无线电状态、网络地址转换、服务器支持、路径验证和应用程序定时。数据中心将多路径用于另一个目的。服务器之间可能存在多条物理或等价路由。MPTCP 可以在传输层暴露这种多样性，潜在地提高利用率和弹性，而无需应用程序管理多个套接字。

环境不同于手机。数据中心路径可能具有相似的名义成本，但共享隐藏的瓶颈。过多的子流可能导致不公平或给交换机表带来压力。调度和拥塞控制必须适合架构设计。相同的 MPTCP 机制支持不同的服务，因为通用协议并未规定每一个本地决策。

大多数公共互联网服务器未启用 MPTCP，这鼓励了代理或传输转换器的使用。运营商可以在客户设备或网关与运营商控制的锚点之间运行 MPTCP，然后通过普通 TCP 继续连接到公共服务器。这允许部署而无需每个网站改变。它也将一个有状态的中间件置于服务内部。代理终止传输状态，集中流量并成为一个运营依赖。

由 Bonaventure 及其合作者编辑或共同撰写的 RFC 8803 定义了一个零往返传输转换器，旨在辅助 TCP 扩展的部署。该设计接受了一个中间件可能比等待普通的端到端支持更实用。

锚点的所有权、位置和故障域随后成为产品的一部分。中央代理可以简化管理，同时增加故障影响范围。分布式锚点减少了路径长度，但倍增了状态、软件实例和操作对象。容量规划必须涵盖由转换器处理的固网和移动流量、连接状态和故障切换行为。

移动设备增加了另一项约束：路径有财务和能源成本。保持蜂窝无线电活动会消耗电池电量，而通过计量网络传输流量可能使用户或运营商付出代价。Wi-Fi 可能快速但不稳定；蜂窝可能可靠但昂贵。这有助于解释为什么 Apple 记录的用途强调备用而非持续聚合。该协议可以跨多个网络承载流量，但它无法确定用户愿意支付什么，或者哪种电池权衡是可接受的。

Tessares 将 MPTCP 带过商业边界

混合接入将 DSL 等固网线路与 LTE 等移动连接结合起来。固网链路可以提供稳定的基础，而蜂窝容量增加了速度或连续性。这种模式在更换长铜线环路需要时间或需要大量资本的情况下特别有吸引力。典型的部署将支持 MPTCP 的软件放置在客户网关和运营商控制的汇聚点。运营商可以管理两个接入网络，选择调度器并定义客户支持。

该服务并不能让每个应用程序更快。它主要依赖于 TCP 流量、网关集成、代理容量以及虚拟专用网（VPN）、UDP 等协议的处理方式。因此，商业产品远不止于 RFC。它包括软件、客户端设备、无线电资源、监控和运营支持。

一份投资者公告将 Tessares 确定为一家 UCLouvain 衍生公司，由 Olivier Bonaventure、Gregory Detal、Sébastien Barré、Denis Périquet 和 Sopartec 于 2015 年 3 月创立。该团队结合了学术和标准工作、实现经验、商业领导和大学技术转移。

如果没有网关、集成、销售、支持和对已部署系统的责任，一份规范无法成为运营商产品。因此应将 Bonaventure 描述为联合创始人，而非自动作为公司现任首席执行官、控股股东或日常运营者。公开的运营商公告将 Denis Périquet 列为首席执行官，而创始人所有权和当前管理职责在所提供的记录中未披露。

Proximus 提供了第一个明确的运营商证据。它描述了在 Frasnes-Lez-Anvaing 进行的一项为期九个月的试点，为农村客户结合 DSL 和 4G/LTE。该运营商报告了高满意度，部分参与者的速度提高了多达 20 Mbps，并称该系统有资格进行更广泛的真人用户测试和可能的全国部署。这些都是参与运营商的说法，而非独立性能审计。即便如此，该试点证明的不仅是一个实验室基准。Proximus 将系统安装在客户环境中，协调了两个接入网络，并测试了产生的服务能否得到支持。

一份 2018 年的公告报告了 Proximus、VIVES II 和 SRIW 参与的 300 万欧元融资轮。它指出 Proximus、KPN 和 Telia 为客户，并称比利时、荷兰和立陶宛的近 15,000 户家庭受益于 Tessares 技术。一份 2021 年的公告报告了由欧洲创新委员会基金和 Sagemcom 领投的 350 万欧元融资轮，现有投资者参与。这些数字确立了在那些日期时的融资和客户关系。它们不提供当前收入、盈利能力、估值、客户留存或当前安装基数。

BT 于 2022 年宣布了面向小型企业的 Hybrid Speed Boost，并称该产品使用了 Tessares 的 MPTCP 技术。该运营商描述了铜线宽带和 EE 的 4G 网络的组合，并报告了平均下载速度的提升。其支持文档也异常清晰地说明了局限性。该加速适用于 TCP 网页流量，不加速典型的 UDP 游戏流量。虚拟专用网络（VPN）行为也可能限制收益。两条接入链路并未成为对每个数据包都通用的管道。

来自 Wavenet 和 Digital Wallonia 的公开材料后来称 Wavenet 自 2024 年以来已维护或支持 Tessares 的混合接入解决方案，并服务于主要欧洲运营商使用的 MPTCP 系统。截至研究截止日期，Tessares 仍列为活跃的比利时法律实体。

这些证据支持一种维护和支持的过渡。它并未确立 Wavenet 收购了 Tessares，所有知识产权易手，或 Tessares 停止运营。这一区别很重要，因为基础设施通常比公开启动周期持续更久。即使一家初创公司变得不那么可见，已安装的系统仍需要工程师。

混合接入也是一个经济桥梁，而非光纤的永久替代品。在铜线性能差、移动容量可用且光纤建设需要时间的地方，它最有吸引力。移动频谱和回传仍然带来成本，网关必须安装和支持。随着光纤到达更多地点，结合 DSL 和 LTE 的理由可能减弱。Tessares 展示了软件和运营商控制锚点如何在物理接入网络重建之前改善服务。它并未消除接入投资的长期经济性。

该方法持续超越 MPTCP

Bonaventure 在教育方面的工作将相同方法扩展到一种协议之外。他编写了《计算机网络：原理、协议和实践》，于 2011 年首次发布并随后修订。该书采用开放许可，供教师和学生检查、改编和重新分发。他的公开记录还提到 2012 年因开放教科书工作获得 Saylor 基金会奖项。该书将网络视为读者可以通过协议、代码和实际行为来检查的东西，而非一组理想化的层。开放出版也使该材料能够随系统变化而变化。

2010 年至 2016 年，Bonaventure 担任 ACM SIGCOMM 教育主任，后来还担任编辑和学术领导职务。他的团队发布了实现材料、教程、虚拟环境和实验。2020 年的一次 SIGCOMM 教程延续了围绕多路径传输的动手工作。

可复现性是协议生产的一部分。学生和工程师可以运行代码、检查数据包，并将干净模型与受中间盒约束的路径行为进行比较。在该环境中接受培训的人后来将专业知识带到了 Apple、Tessares、上游 Linux 和其他网络组织中。

他后来的研究从一种多路径协议转向了更可编程的传输系统。QUIC 在 UDP 上运行，大部分传输行为在用户空间中实现，并通过 TLS 集成加密。它提供了一条绕过僵化的内核和中间盒假设的不同路径，不同于 MPTCP 的 TCP 选项策略。

Bonaventure 及其合作者从事了可插拔 QUIC、多路径 QUIC 和相关传输转换研究。这并不意味着放弃 MPTCP。它扩展了问题：传输行为如何在保持互操作性和安全性的同时更快地演进？用户空间部署可以缩短更新周期，但并未消除拥塞、网络策略或实现风险。同样的纪律仍然必要：暴露假设、测试它们并设计维护路径。

关于可扩展 Linux 传输栈和 eBPF 启用的路径感知 TCP 的研究探讨了传输行为如何在不添加针对每个未来机制的固定内核接口的情况下改变。受约束的执行环境和本地安装的逻辑可以支持实验，而公共层定义了安全性和互操作性边界。

可编程性本身带来风险。不同的本地算法可能产生难以比较的行为，而扩展机制可能创建新的安全表面。仅当共享系统仍然提供验证、可观察性和移除不安全代码的方式时，未来决策才能本地化。

xBGP 项目将类似思想应用于路由。它提出了一种通过 eBPF 和经过验证的接口扩展 BGP 实现的供应商中立机制，包括与 FRRouting 和 BIRD 等开放路由栈的合作。其他研究考虑了 BGP 的安全传输，同时保留熟悉的 TCP 导向运营模型。

这些项目是研究和草案阶段的工作，而非普遍部署的证据。它们的相关性在于提出的变革路径。运营商可以等待供应商和标准流程数年来添加一项功能。如果实现保持可验证和可互操作，一个受约束的扩展层可以缩短这一延迟。

最近的 UCLouvain 出版物也涵盖了自适应 IPv4/IPv6 地址族选择、交换归属和 Flexicast QUIC。Flexicast 寻求将多播效率与加密传输上的单播回退结合起来，而交换归属则检查系统如何根据策略和性能在接入路径之间切换。

这些项目仍处于不同的研究阶段。它们表明，Bonaventure 在 2025 年和 2026 年的工作并非仅仅是对 MPTCP 的回顾性维护。它继续研究当路径、协议支持和权威分散在不同方面时，如何部署网络能力。

他作为鲁汶工程学院院长的角色扩展了那种制度构建记录。该职位具有时间敏感性，并不给予他所有研究项目的权力。它确实表明，他的影响力日益通过项目、教职人员结构和使其他研究人员工作的环境来运作。

MPTCP 的局限定义了它的真正成就

MPTCP 并未取代普通 TCP，部署仍不均衡。版本 0 和版本 1 在线路上不兼容。许多服务器未启用该协议。中间盒可能强制回退。延迟差异很大的路径可能增加缓冲，而同时使用蜂窝和 Wi-Fi 可能消耗能源或计量数据。

代理允许增量采用，但集中了连接状态。混合接入产品可能仅加速选定的流量。内核可以包含 MPTCP 支持而没有任何应用程序使用它，而端点可能协商一个版本，而另一端期望另一个版本。独立研究试图测量整个互联网上支持 MPTCP 的系统。此类测量可以揭示选项响应和广泛趋势，但它们容易受到误报、中间盒干扰和端点上响应探测但未支持有用应用服务的影响。

选项响应与活跃的生产部署不同。采用声明应结合扫描、明确的产品文档、实现版本和运营流量证据。专门的 IETF MPTCP 工作组在完成其章程文件集后于 2020 年 3 月结束。协议治理并未终止。勘误、互操作性问题、扩展工作和维护转移至 TCP 维护和小扩展工作组，其范围包括 MPTCP。

这种转变是成熟的一部分。一个聚焦的工作组可以使协议经过架构、实验和标准轨修订。一个常设的维护场所随后处理其与更广泛 TCP 系统的交互。长期权威不再依赖于无限期地将原始团队保持在一起。

版本断裂也警告运营商注意隐藏的安装基础。设备、代理、应用程序和嵌入式系统可能在数年内停留在不同代际。普通 TCP 回退可以保留服务，同时隐藏多路径行为的丢失。因此，运营商需要一份协议版本和策略的清单，而不仅仅是一个表示 MPTCP 启用的标志。他们必须知道每个端点支持哪个版本，代理如何受影响，以及回退是否改变了客户承诺。

公开记录也有局限。它支持 Bonaventure 的学术角色、RFC 作者身份、研究领导力、开放教科书、Tessares 联合创始人和当前研究。它未提供可靠的出生日期、个人财富、薪酬、创始人股权、完整的 Tessares 资本表或公司当前的财务表现。它也无法量化他个人在 Apple 实现或任何运营商商业结果中的份额。这些差距应保持开放。技术和制度记录本身足够重要，无需将团队成果归于一人。

他的遗产是管道

Bonaventure 并未独自发明 MPTCP。他未编写其架构文档、拥塞控制 RFC、Apple 的实现或当前的主线 Linux 子系统。在没有证据的情况下，他不应被描述为 Tessares 的现任首席执行官。

他的贡献比那些声称所暗示的更持久。他共同撰写了实验性和标准轨规范，领导了一个产生了重要软件和部署研究的团队，帮助将运营证据带入标准流程，共同创立了一家将协议带入电信产品的公司，并建立了帮助培训后来工程师的教育资源。该模式在他关于 QUIC、eBPF 启用传输和 BGP 扩展机制的工作中延续。每个项目都问：新网络行为如何在现有应用程序、设备、激励和制度边界下生存？

BTW 追踪 Bonaventure，因为他的职业生涯展示了协议基础设施是如何实际构建的。一份 RFC 只是一个阶段。代码必须互操作，故障必须被测量，运营商必须找到部署它的商业或运营理由，维护者必须从原始研究者那里继承责任。

MPTCP 的中心机制是该更广泛教训的一个有用表达。一条应用连接可以在本地实现决定哪些路径活跃、哪些路径保留备用、哪些路径应被放弃的情况下生存。Bonaventure 帮助构建了足够多的周边链条，使这一想法进入手机、宽带服务和 Linux 内核，然后在他不依赖他的情况下继续。