LWN: multipath TCP的现状

点击上方蓝色“Linux News搬运工”关注我们~

Upstreaming multipath TCP

By Jonathan Corbet

---

LPC

 

过去差不多10年中，multipath TCP (MPTCP)协议以及在Linux kernel的支持一直在持续开发。MPTCP对于拥有超过一个网卡接口的设备来说有很多好处。虽然现在有很多地方已经采用了MPTCP，不过upstream Linux kernel里面尚未正式支持。2019 Linux Plumbers Conference会议上，Matthieu Baerts和Mat Martineau讨论了Linux MPTCP当前实现的状态，以及如何才能合入mainline kernel。

 

MPTCP是由RFC 6824所定义的，它的核心想法是，允许一个网络连接（network connection）能通过多条物理路径来收发数据。有一个很典型的应用场景就是手机，手机拥有WiFi和4G网络接口，如果能同时利用这两条路来发送数据，肯定能够得到更高的带宽，容错性也更高（其中一条路径状态变化并不会导致网络连接中断）。

 

Apple在2013年就增加了MPTCP支持，就是主要想改善某条链路出问题时候的出错处理。很典型的就是走出房间的过程中，用户使用的WiFi信号变弱所以必须要切换到4G网络。而Samsung和LG等公司也通过打上MPTCP patch来获取更大的贷款。MPTCP还经常应用到一些既有DSL也有LTE的家庭网关上，目的仍然是更大带宽。5G标准里也包含了MPTCP。

 

Linux在2009年3月开始实现MPTCP，过去10年里已经达到了0.95版本。Baerts认为它的用户已经有百万数量级了，不过目前还没有达到upstream的标准。MPTCP开发者一直希望能推上upstream，不过受限于一些因素尚未成功。首先就是MPTCP加入后也不能影响现有的TCP协议栈，具体来说不能导致性能下降，也不能在关闭MPTCP的情况下增加code size。这个协议本身是可选的，所以应用程序必须明确提出使用MPTCP，才会用到它。目前他们打算采用小步走的策略，先把最基本的功能合入进去。

 

The MPTCP protocol

 

Baerts接下来简要介绍了一下MPTCP协议本身，他觉得这个协议就像是最简单版本的TCP。众所周知，因为互联网上现有的各种中转设备无法处理它们不能识别的网络数据，所以每次给互联网广域网增加新的协议都是一件很麻烦的事情。简单来说有两种方法，一种是QUIC采用的方法，把所有协议细节隐藏掉，让中间网关看不到。另一种方法则是MPTCP采用的，就是伪装成一个现存的协议。因此MPTCP在中间网关看来其实就像是个普通的TCP连接。

 

MPTCP新协议肯定需要包含一些新的信息来把多个TCP连接合并起来。这里使用了好几种处理方法，首先是要利用多个连接统一分配的"data sequence number"。在TCP header里有一个MPTCP选项，以及一些新加的SYNC标志来表示支持MPTCP能力，还有能增加一个TCP connection到现有的某个MPTCP session里去。还会有一些其他的通知机制，例如公布有新的地址可用等等。多个TCP connection中的接收窗口也会被组合起来形成MPTCP级别可以看到的一个统一窗口。

 

其实MPTCP协议有两个版本，一个是RFC 6824，后来又有了一个新的RFC 6824bis。后者已经提交公开，将会是MPTCP v1.0 patch所实现的协议。新版本改动让这个协议更加容易实现，而5G也在使用这个版本的标准，所以今后用户应该都会很快切换到这个版本。Baerts会上也问kernel的网络开发者是否介意他只实现RFC 6824bis的支持，Eric Dumazet认为可以接受。

 

Getting it upstream

 

6月份就有个patch set发到mailing list上了，这个patch set创建了一个新的协议类型（IPPROTO_MPTCP），应用程序可以通过这个协议来指定使用multipath功能。Baerts指出这个patch set还没有支持IPv6，虽然添加IPv6并不难，不过MPTCP开发者打算稍后再做。一位听众提出其实可以反着做，只实现IPv6，今后再加IPv4。Dave Miller则提出基本功能需要在第一版本里就包含，IPv6也要支持，他认为现在阶段只实现IPv4功能已经无法满足需求了。

 

开发者们还问道怎么能对MPTCP subflows设置socket option。Baerts回答说现在还没有定义好API，所以user-space暂时还无法访问subflow。

 

听众又问，谁可以创建MPTCP socket。第一版的实现里，还没有完善的加固（harden）功能，例如尚未实现fuzzing机制。后面的计划是增加一个sysctl节点来控制谁能访问这个功能。缺省关闭这个功能，可以逐个network space来进行控制。Miller也不赞成这个做法，他希望合入的时候这个功能要完善，不应该缺省关闭。其实系统里面的sysctl已经太多了。Alexei Starovoitov觉得接收路径上更加重要一些，这个不应该通过sysctl来控制。Apple有一个远程安全攻击漏洞被利用来给手机系统进行越狱破解，他不希望Linux上也碰到这个问题。

 

Use cases

 

Martineau指出，MPTCP最开始的应用场景是在服务器端。这种场景下path management会非常简单。而现在在客户端这边会很麻烦，要处理多种差异显著的网络接口。这里需要一些底层机制，部分已经合入upstream了。他举的例子是SKB extensions，这是一种不继续撑大sk_buff结构并且能在packet里增加额外信息的方式。SKB extensions加入后，已经从sk_buff结构中去掉了多个不相干的指针，确实有改善。

等MPTCP第一版合入之后，大家就可以开始增加更多功能了。包括优先增加客户端应用场景下的支持。还有需要能支持user-space path manager，这样就能让系统管理员来增加、减少path（底层链路）了。GitHub上已经有些代码在实现user-space的管理功能了。

 

后续还有一个需要开发的方向就是packet scheduler，用于决定每个packet应该通过哪个patch来收发。它也应该允许用户配置，从而能实现throughput、latency、redundancy等方面的优化。在服务器方面，这个工作比较简单，主要能相应每个MPTCP连接对端的请求就好。kernel会实现一个基本的scheduler，今后估计还是要增加BPF hook来支持更复杂的场景。

 

MPTCP是个可选功能，除非application指定要用它，否则不会被激活。不过肯定会有用户希望能让他们的可执行程序能自适应的支持具有MPTCP功能的环境。目前有个初步的解决方案，可能不够优雅。需要增加一个新的cgroup hook，允许在某个程序调用socket()的时候执行预设好的BPF program，这样就能修改所请求的协议，改为IPPROTO_MPTCP，这样应用程序本身都不用意识到。

 

还有个"break before make"机制可以支持建立一个不用包含任何subflow的MPTCP connection。在一些场景会很有用，例如需要在多个WiFi AP之间切换的时候。等后续真有这种强烈需求的时候会加进来。最终肯定有需要对subflow设置socket option，这种功能要很仔细地处理，因为一些socket option会影响到正常的TCP。

 

最终，Martineau指出in-kernelTLS support带来的麻烦。因为MPTCP不是TCP，所以缺乏TLS所依赖的一些上层协议。要支持的话就需要很多工作，希望最终能把TLS数据也分发到多个flow上去。不过如果牵涉到硬件加速的话就很难了。不确定最终方案会是什么样。

 

[Your editor thanks the Linux Foundation, LWN's travel sponsor, for supporting travel to this event.]

 

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议修改再创作～

 

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～