OPENPPP2 —— VMUX_NET 多路复用原理剖析

在阅读本文之前，必先了解以下几个概念：

1、MUX（Multiplexer）：合并多个信号到单一通道。

2、DEMUX（Demultiplexer）：从单一通道分离出多个信号。

3、单一通道，可汇聚多个通道。

MUX 在网络编程之中得应用，例如：TCP/IP、QUIC/CONN

即为：一个网络链接（模式），可承载并映射多个网络链接（模式）得通信数据。

注意：TCP/QUIC链接均为模式链接，真实通信中不存在链接，它是一个逻辑概念。

其结构为：（* 以TCP & MUX为例子）

上述为一个典型的 “MUX多路复用” 网络通信程序结构，多个TCP链接经过MUX交换机，在单一的TCP链接之中复用通信，并经过互联网进行传输。

注意：MUX为双向通信结构，所以不需要区分流程箭头方向。

好的，经过上述的概念理解，我们在来剖析 OPENPPP2（PPP PRIVATE NETWORK™ 2）之中的 VMUX_NET 的网络通信结构。

浅显的初略结构图，大约是这样：

从上述图示之中，可以了解到它与上述的MUX多路复用存在一定的差异，其：VMux linklaye 与 VMux Connection 是多对对的关系。

一个很有意思的疑问点是：为什么 OPENPPP2 之中 VMUX_NET 被设计为多对多的关系呢？

这是源于以下几个点：

1、单一TCP链路，或会受到来自 “IDC、ASN、ISP” 的高级QOS策略宽频限制，故而导致难以达到或逼近 POINT-TO-POINT（点对点）网络链路的瓶颈带宽。

2、单一TCP链路，在应用程式保证有序的前提下，难以把产生的CPU的计算负载压力分摊到其它线程之中，这可能导致在宽频交换的高压状态，某一个CPU核心的负载压力过大。

3、关于拥塞控制协议大多存在的 “慢启动（ssthresh）”，从初衷是好的，但在大流、突发场景之中，或许并不一定都是好事。

拥塞控制协议大多包含动态调整 ssthresh，即会根据实况动态的上调与下调，当单一链接上调时启速会比较慢，会导致网络宽频突发不足（RTT时延越大越明显），但若多个链接同时处于慢启上调，那么基于指数效应在探测瓶颈带宽初期，亦可以获得不错的宽频吞吐速度。

这源于：

控制协议除特殊之外，几乎都是对具体逻辑连接，进行拥塞逻辑控制的，所以，在多个链接并行收发时，可以获得更高的网络宽频吞吐效率。

所以：

多对多MUX多路复用，可为人们带来以下几个优势：

1、可获更优良单链接宽频吞吐能效

2、对流媒体链接速度有一定的加成

3、相对低一些的网络抖动（Jetter）

4、相对低一些的首帧RTT时延

缺陷：

1、更高的开发及维护的复杂性，与DEV调试的复杂性。

2、可在多个线程/CPU核上处理，但MUX核心交换机仍仅同一个时间轮片之中为线性交换（可以理解为逻辑上的单核/单线程处理）。

以下，让我们捕捉一部分 VMUX_NET 的代码并分别阐述，其的设计实现意图：

RX收：

openppp2/ppp/app/mux/vmux_net.cpp at main · liulilittle/openppp2

vmux_net::packet_input_unorder 函数是处于来自多个不同线程、不同链接输入过来的 “VMUX FRAME”（帧）。

openppp2 是建立在 TCP/IP 协议簇上方的，而每个 TCP/IP 协议簇，每个有序数据的交付到达是有序的，但多个不同 TCP/IP 链接并不是有序的。

举一例子：同时向 www.baidu.com 443 建立了两条TCP链接，A与B链接。

A向服务器发送数据，B也向服务器发送数据，两个是同时发送过去：那么服务器可能先收到A发送的数据，也能先收到B向服务器发送的数据。

这是源于：A/B可能会在发送到服务器时产生丢包，或因为网络波动（如TTL沿途跃点的路由）、OS内核事件排队等等，导致两个链接包发送到服务器先后顺序是不同的，在UDP之中乱序问题一直是不可避免地，回归TCP的本质协议实现，UDP存在的问题TCP协议本身也存在，只是大家基于逻辑链接开发，并不能从上层感知这种问题而已，但这并非是不存在。

TX发：