Multipath TCP的缺陷和优化

盗用一张自己以前写的Reuseport博客里的一张图：

把一个TCP连接的报文排入队列，让服务台作为发送机发送报文，单队列好还是多队列好？答案是单队列好。为什么？ 因为多队列会阻塞。

多队列为什么会阻塞？只要发送机链路出现丢包并且依赖相同的发送机重传，重传完成之前对应队列会一直阻塞，即便其它发送机空闲，队列里的报文也无法发出。

单队列由于不区分队列，所有发送机均可捞取报文发送，便不会阻塞。

然而MPTCP是多队列模型，每个队列属于一个subflow，一旦报文进入一个subflow，它就不能再被其它subflow发送，问题的根本就在这里。

我不认为MPTCP没有意识到这一点，只是受制于实现。在MPTCP中，每一个subflow都是一条标准的TCP连接，重用TCP造成了多队列，同时每一条subflow均受制于滑动窗口，问题还是在TCP，TCP的所有问题均会映射到MPTCP。不依赖TCP，重新实现新协议，才可甩下这个包袱。

那么，如何修改？保证三点即可：

• 不区分新报文和重传报文，统一编于时间序。
• 发送不保序，完全基于时间序，有报文就发。
• 接收端重排序。

多个发送机对应多条path，从唯一的队列捞报文发送，方可达到效率最大化：

这是使用MP(Multipath)的正确姿势。 关于上图，注意以下几点：

• 实现上，如果顾及多线程操作单队列的数据同步问题，可利用hash技术缓解。
• 若多路径RTT方差很小，可取最大RTT作为乱序和丢包检测的边界，作用于RACK算法。
• 若多路径RTT方差很大，需要针对每条路径单独做RACK算法，故ACK需要原路返回。
• 每条路径单独做cc，但公平性约束依然要遵守标准MPTCP规范，遵守互联网原则。
• 是发送机从队列里主动抢捞报文还是采用一种调度策略根据序列号调度报文到发送机，也需斟酌。

若在广域网实施MP，除非接收端内存巨大可采用主动捞取策略，建议主动调度，因RTT大，BDP大，照顾到接收端缓存，乱序不能太狠，故传输需紧凑，这对调度算法要求很高，但end-to-end已与传输分离，这便不是流控及拥塞控制及传输加速所要考虑的了。

MP更多被用来增强网络鲁棒性(Active-Backup)而不是为了效率(Active-Active)，这是普遍部署的SPF路由协议和使用最多的TCP协议共促的思维定势：

• SPF只会选择最短的路径。
• TCP不能乱序发送和到达。

故几乎所有网络传输都是单路径串行。ECMP要基于流而不是包做LoadBalance，路由器要基于流而不是包做RSS，复杂之故事只为照顾TCP。

我想用MP救传输空窗，但纠结Wi-Fi弱网乱序，Wi-Fi帧在物理层就可能乱序，我便不敢传输层再用MP，这只会加重乱序，我抱怨我的拥塞控制算法总是无法好好工作，但问题出在乱序吗？问题不是乱序，问题是我没处理好排序，哦，不，不是我，是TCP根本就没有处理排序，TCP期望的报文总会按序到达。
是优化MPTCP？还是优化QUIC？亦或再做一个协议，套着TCP的躯壳？

怎么办？经理怎么看？

浙江温州皮鞋湿，下雨进水不会胖。