本文主要是介绍如何合理利用多个中国大陆小带宽服务器?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
我们知道在中国大陆带宽单价非常昂贵,一个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群的地址,加入进来获取,目前这个工具暂时是不开源的,本文也只是大约聊聊,它是怎么实现的。
这篇关于如何合理利用多个中国大陆小带宽服务器?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!