【Hacker News搬运】Linux的多路径TCP（2022）

[hackernews]

Title: Multipath TCP for Linux (2022)

Linux的多路径TCP（2022）

Text:

hn link

Url: https://www.mptcp.dev/

MPTCP（多路径TCP）是一种扩展标准TCP的协议，它允许设备同时使用多个接口发送和接收TCP数据包，通过单个MPTCP连接。MPTCP可以聚合多个接口的带宽，或者优先选择延迟最低的接口，它还允许在一条路径失效时进行故障转移，并在其他路径上无缝重注入流量。

技术上，当使用`IPPROTO_MPTCP`协议（Linux专用）创建新的套接字时，会创建一个_子流（subflow）_或_路径_。这个子流是一个用于通过单个接口传输数据的常规TCP连接。主机之间可以在以后协商额外的子流。为了使远程主机能够检测到MPTCP的使用，会在底层的TCP子流中的TCP选项字段中添加一个新字段。这个字段包含，例如，一个`MP_CAPABLE`选项，它告诉其他主机如果支持的话就使用MPTCP。如果远程主机或中间件不支持MPTCP，返回的`SYN+ACK`数据包将不会在TCP选项字段中包含MPTCP选项。在这种情况下，连接将被“降级”为纯TCP，并继续使用单路径。

这种行为由两个内部组件实现：

1. **路径管理器**：从创建到删除，管理子流，并处理地址公告。通常，客户端发起子流，服务器端通过`ADD_ADDR`和`REMOVE_ADDR`选项宣布额外的地址。

2. **数据包调度器**：负责选择使用哪个可用的子流来发送下一个数据包。它可以决定最大化可用带宽，只选择延迟最低的路径，或者根据配置的其他策略。

截至Linux v6.8，只有一个数据包调度器，由`net.mptcp`中的sysctl旋钮控制。

MPTCP的主要功能包括：

- 在`socket()`系统调用中支持[`IPPROTO_MPTCP`](https://www.mptcp.dev/implementation.html)协议。
- 如果对等方或中间件不支持MPTCP，则从MPTCP回退到TCP。
- 使用内核内或用户空间路径管理器进行路径管理。
- 常用的TCP套接字选项。
- 调试功能，包括MIB计数器、诊断支持（用于`ss`命令）和跟踪点。

有关更多详细信息，请参阅[ChangeLog](https://github.com/multipath-tcp/mptcp_net-next/wiki/#changelog)。

MPTCP社区通过以下方式进行沟通：

- 邮件列表：mptcp@lists.linux.dev（以及[归档](https://lore.kernel.org/mptcp/)）。
- IRC：[#mptcp](https://web.libera.chat/?nick=mptcp-dev-guest?#mptcp)在libera.chat。
- 在线[会议](https://github.com/multipath-tcp/mptcp_net-next/wiki/Meetings)。

MPTCP项目由社区成员维护，包括：

- 在GitHub上的内核开发：[Kernel development on GitHub](https://github.com/multipath-tcp/mptcp_net-next/)。
- [多路径TCP守护进程](https://github.com/multipath-tcp/mptcpd)：守护进程可以完全控制用户空间路径管理或控制内核路径管理器。
- 包括[`mptcpize`](https://www.mankier.com/8/mptcpize)实用程序，允许旧TCP二进制文件使用MPTCP。
- [带有MPTCP支持的Packetdrill](https://github.com/multipath-tcp/packetdrill)。
- 与MPTCP相关的增强项目。
- [iproute2](https://wiki.linuxfoundation.org/networking/iproute2)（用于[`ip mptcp`](https://www.mankier.com/8/ip-mptcp)命令）。
- [Network Manager](https://networkmanager.dev/)：从v1.40开始包含MPTCP功能。
- [多路径TCP应用程序](https://github.com/mptcp-apps/)：一个项目，用于协调流行TCP应用程序的MPTCP更新。

内核开发包括：

- [Git仓库](https://github.

Post by: pantalaimon

Comments:

ohnoesjmr: I've heard about MPTCP back in 2013.<p>It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day.<p>It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http calls in multiple retry handlers, and mobile operating systems have abstracted network connectivity to the point where it feels more like you are using zeromq rather than tcp.

ohnoesjmr: I-；我早在2013年就听说过MPTCP。<p>当时，当移动应用程序对网络变化的鲁棒性不强时，这很有意义；它很快就会被采用，因为它在当时会有多大的改进<p> 它；令人难以置信的是，这在过去10年中几乎没有任何吸引力，而且内核选项最近才出现，因为每个人都将http调用封装在多个重试处理程序中，移动操作系统已经将网络连接抽象到了使用zeromq而非tcp的地步。

suprjami: I work supporting, debugging, fixing the Linux network stack and drivers. I am amazed how little adoption this has seen.<p>Like everything which came along and tried to supplant regular TCP, such as SCTP, it seems MPTCP has also been confined to a niche of application developers who will use it forever while the rest of the world forgets about it.

suprjami: 我的工作是支持、调试、修复Linux网络堆栈和驱动程序。我感到惊讶的是，这种情况很少被采用<p> 就像所有试图取代常规TCP（如SCTP）的东西一样，MPTCP似乎也局限于应用程序开发人员的利基市场，他们将永远使用它，而世界其他地方却忘记了它。

bdd8f1df777b: The only practical use of MPTCP for me is to use mobile and Wi-Fi network together to boost the speed. iOS and WeChat both support this. However, I always turn them off because my mobile network is metered. So in the end, MPTCP is useless for me personally.

bdd8f1df777b: 对我来说，MPTCP的唯一实际用途是将移动和Wi-Fi网络一起使用以提高速度。iOS和微信都支持这一点。但是，我总是关闭它们，因为我的移动网络是按流量计费的。所以最终，MPTCP对我个人来说是无用的。

EvanAnderson: I don't know which makes me sadder-- IPv4 only having a 32-bit address space or TCP using the source and destination IP addresses in the connection tuple. That's one of those "if I had a time machine" of things-- I'd go back and have Cert and Kahn change both of those items.

EvanAnderson: 我不；我不知道哪一个让我更难过——IPv4只有32位地址空间，或者TCP使用连接元组中的源和目标IP地址。那个；是那些“；如果我有一台时间机器“；事物的I-；d回去让Cert和Kahn更改这两项。

vlovich123: Why does this require explicit opt in by applications if there’s transparent fallback? Wouldn’t it make most sense for the kernel to do it transparently for every TCP connection so that it can make more global decisions about path aggregation / link preference?

vlovich123: 如果有透明的回退，为什么这需要应用程序明确选择加入？内核对每个TCP连接透明地进行操作，这样它就可以做出更多关于路径聚合的全局决策，这难道不是最有意义的吗；链接偏好？