我们知道在中国大陆带宽单价非常昂贵，一个1Mbps 带宽的机子一年就得卖好几百人民币，这是不值当的，当然我们可以去低价漂阿里云、腾讯云的轻量服务器，99包年，但是带宽太小很难崩。

所以，我们必须构建一个能够把多个99包年云服务器带宽叠加起来的解决方案才行，否则买单台也亏，在我眼中几兆上传带宽太小了，连小水管都不是，小水管起码30上商用上行带宽，我这边本地都是拉的几条200M/200M上下行对等带宽的固定IP商业带宽。

无法榨干这些垃圾小带宽服务器的是一种技术人员的重大失误，近期入手两台服务器，一个华为云3M、一个腾讯云4M带宽的机子。

把它两个带宽叠加在一起就有7M，1080P视频是能稳定流畅看了，4M带宽单机吞吐看1080P有点够呛。

当然，我现在非常非常的气愤，因为我本来可以买到两台腾讯云4M轻量服务器的，但是我当时居然退单了想第二天再来，这波就给坑了，等下个月看有没有机会入手一台。

腾讯云这个饥饿营销，玩的可以啊，妥妥恶心人。

利用中国大陆多个小带宽机子，非常重要是多个小带宽大陆机的流控/帧控算法，对于UDP/IP类的带宽聚合是帧控算法，对于TCP/IP类的带宽聚合是流控算法。

但是我们并需要实现那么的复杂，可以直接采用 “TCP/IP”、“KCP/ENET” 之类的传输控制协议作为下层。

这可以减少我们自己需要去实现：“带宽退让”、“ARQ”、“SACK（选择确认）”、“NAK（否定应答）”、“ACK（确认应答）” 等这些机制。

带宽退让是滑块窗口与重传这部分关联的算法，目的是为了平衡链路拥塞层度，这些可以用成熟现成的控制算法来实现它们。

我们要做的轻量的控制算法，即：只需要保证帧的序及帧缓存积压的问题，就可以，另外我推荐用TCP/IP作为下一层，因为KCP这些协议不适合传输大包，它们是为了小包及时性设计的，所以可以容忍20~30%的带宽损失。

但是我们做小带宽聚合器的目的是什么？是为了提高单机可以获得最大带宽，让这些小带宽机子带宽要榨干，狠狠跑起来，而且更现实的时，这些小带宽机子总带宽大小就几Mbps 上传，你居然会上ENET、KCP这些功耗比较大的控制协议，是不是不合适。

OK，回到重点：

1、由于每个链路通路之间延迟是不同的

     所以：虽然用TCP/IP、KCP这些下层协议保证了段的连续性，但在多个链接输入帧的情况下会出现乱序的问题，如果是单个链接，直连不就好，搞这些东西干什么，搞这个东西目的就是为了榨干所有中国大陆中转机的上行带宽。

2、帧序在链路长时间工作之后，100%会出现序号回绕问题（可以参考TCP/IP、KCP协议栈是怎么处理的）

     一般按照通信行业长期测试的经验，若帧序为四个字节，产生序号回绕问题：只需要通过该公式即可确定：BOOL wraparound = (ack - seq) > (UINT32_MAX / 2)

    帧序回绕问题在接收端处理，但需要确保基本对于接受缓存挤压的帧（TCP之中为段）正确排序，这个不难处理，排序时根据这个算法判断就可以了。

但要注意一个点：

    插入算法应该要高度优化下，必须做成快速插入（来保证排序顺序），而不是很高成本的排序，在控制算法之中，由于通路之间的延迟、乱序、拥塞层度不同，可能会产生很严重的接收端积压问题，一次性积压个几百帧是一点问题都没有的。

    但积压大量的帧缓存，可能会产生很高的网络延迟，这是控制协议的弊端，但是你还真的自己好好做下控制协议，若你不在自己这层控制，让UDP/IP的应用去自己去处理这些问题，它们的传输效率就会非常慢的。

   举个小例子：QUIC/IETF HTTP3.0，如果你在你这层不控制帧序，就以上面两个机子的带宽条件，视频链接速度只有5000 ~ 6000，但是你带了控制协议，它们速度可以达到7000 ~ 10000Kbps，所以不要认为没有作用及意义。

3、连续确认

     这个简单讲讲就行了，当输入帧序为当前接收端确认帧时（注意：ACK都是预测法，即它永远ACK下一帧） 

     因为链路之间速度、延迟、拥塞的不同，可能未来的帧已经提前到达接收端，并且接收端将其缓存堆积在链上（接收方缓冲区），但需要确认的帧还没有到达，这个途中可能积压了几十、几百个帧。

    所以；你需要在确认了下个帧之后，连续确认堆积在接收方队列缓存之中的帧，以便提高网络的传输效率。

当然还有一些细节上的东西要处理，本文就不过多聊这些东西了，大体解决上面那三个就可以，对于TCP/IP的带宽聚合器；可以查阅 Rust 语言编写的开源工具：

surban/aggligator: Aggregates multiple links (TCP, Bluetooth, USB or similar) into one connection having their combined bandwidth and provides resiliency against failure of individual links. (github.com)

本人不需要这种工具，是单独做了一个UDP/IP的，但这两种实现都大同小异，中心思想都是需要一个专用控制协议来处理的，底层传输介质用TCP、还是UDP+KCP 这类都可以，当然这取决于实际的生产场景。

NETWORK UDP/IP AGGLIGATOR 猛禽宽频聚合器【鱼合掌不可兼得，但可以强行兼一下】

游戏延迟：成都移动 -（广州华为云/广州腾讯云；聚合）- 54~57 RTT

宽频吞吐：3 + 4 = 7Mbps 打满带宽

效果图（一）：

效果图（二）： 

效果图（三）：

欲获取猛禽工具，可以在我的GITHUB上面找到我们TG群的地址，加入进来获取，目前这个工具暂时是不开源的，本文也只是大约聊聊，它是怎么实现的。