多个跨云服务器之间满带宽测速的一种实现方案

多个跨云服务器之间满带宽测速的一种实现方案

引起量变到质变。

新项目要求

因为今天人开发设计的云服务平台新项目是跨云生产调度的超重型测量服务平台，会采用云服务器厂商不同的测量案例网络服务器，如阿里服务器的ECS、亚马逊的EC2或谷歌云的computeengine等。，并且它还将在这种测量情况中传输数据。

这种云服务器之间的传输速率一般是不一样的，即使是同一家云服务器厂商内部不同地区的集群服务器传输数据，带宽也会有很大差异。

因此，需要准确测量该集群服务器的带宽速率，以便生产调度过程安排任务和传输数据。

总而言之，维持这一角色有三条规则:

①检查不同地区云服务器的TCP/UDP传输速率。

②必须是全带宽测速。也就是说，两台网络服务器在测速的时候，一定不能有其他的互联网执行程序。

③几个集群服务器必须高效地创建两组连接。

针对这三个问题，我实现了以下解决方案。

基础设施

一个简单的思路就是启动测速所需的手机客户端和服务器，让这个程序流互相竞争进行测速。

但是这种方法在流程管理上非常容易出现问题，因为每个流程不仅要实际 *** 作自己的情况，还要实际 *** 作其他流程。此外，同时运行四个进程是非常奢侈和浪费的，因为事实上，在每个速度测量中总有一个进程在工作。

因此，更好的方法是构建主从关系，其中主进程启动和停止负责测速的客户/服务终端进程。

这样既能合理防止资源的浪费和竞争，又能在主进程中集成很多逻辑功能，比如对外展示RESTAPI，记录系统日志，备份文件检测结果等。

自然，为了更好地部署和系统控制，所有流程都部署在码头船上。

因为主进程必须浏览主机的Docker服务项，所以需要打开Docker的远程API服务项，将RESTAPI展示给vessel进行实际 *** 作。

功能保持

基本速度测量

TCP和UDP

网络层协议是逐层封装的，而TCP和UDP属于同一层的两个协议。

其中，TCP协议在前端和后端工程师中非常常见，因为RESTAPI乞求依赖的HTTP(S)协议是TCP的顶层协议，UDP协议也广泛应用于视频、手机游戏、免费下载等业务流程中。

它们有一些共同点:请求者被称为移动客户端，请求者被称为服务器，服务器和移动客户端可以双向通信。

而且他们的侧重点不同。TCP更注重稳定性，手机客户端和服务器之间必须建立连接，才能互相传输数据。

UDP更注重速度，手机客户端不需要和服务器建立连接就可以立即传输数据。但是如果推送速度过快或者网络不好，就会造成网络丢包，导致对方接收到的部分数据信息丢失。

速度测量专用工具

常见的命令行测速工具有iperf和speedtest，其中选择了功能更强大的iperf。

Iperf是一种理想的测速专用工具，适用于TCP和UDP协议。它可以根据主要参数确定传输数据的大小、频率或时间以及输出结果的文件格式。

但是由于UDP协议的特点，测速会有点不方便，所以一定要找到合适的带宽。

举个例子，如果数据以1Gbps的速率传输，丢包率为70%，数据以10Mbps的速率传输，丢包率为0，那么毫无疑问，数据库安全更侧重于后者。

自然情况不是丢包率为0，也就是说最好，而是在可容忍的范围内选择更高的速率(数据信息丢失可以重传，不是~)。

这意味着我们必须根据具体的互联网情况不断调整和尝试。

Iperf没有那么智能，所以UDP是精英团队为了寻找理想的传输速率而开发设计的专用UDP传输工具。

全带宽

要保证全带宽，只需要保证测速时没有其他程序进程占用带宽即可。

因为人们可以启动单个被占用的网络服务器来运行测速程序流，其他不是测速程序流的进程不太可能占用带宽，非常容易争夺用于测速的汇编器的带宽。

所以，汇编器一定是互斥的，甚至是互斥的。

大多数选择的情况管理方法都可以保持。子程序每启动一个进程就将情况设置为“连接中”，测速的后置摄像头为“等待中”。只有在“等待”的情况下，才能启动新的汇编程序进行测速。

但是，这只是从编码逻辑的角度进行 *** 作。为了一个平滑和健壮的程序流，最好有其他的强制 *** 作方法。

如果你此刻使用器具，你可以很容易做到。

但是，所有必须进行速度测量的过程都将在容器中启动，并且容器的名称都是统一的。然后一旦程序流程出现bug，启动了几个汇编器，Docker服务项目就会出错，告诉船只名字有矛盾，然后建立不成功。

自然，这种方法也有风险。例如，如果最后一个过程未能按时退出整个测速过程，则无法进行新的测速。因此，必须设置请求超时，并且在一定时间后必须主动终止当前的速度测量汇编器。

另外，如果子程序意外退出，导致终止不成功，就要进行解决:每次启动子程序都要检查，立即销毁未终止的汇编程序。

多节点

节点算非常复杂的问题。想象一下，在一段时间内，在几个云服务器上开始几个速度测量过程。如何保证他们有条不紊的进行测速？

要处理这个问题，首先考虑一个更简单的问题:

在一段时间内，如何决定哪个云服务器启动服务器组装器，哪个云服务器启动移动客户端组装器？

如果按照“主从”模式，就要创建一个中心节点来进行 *** 控，但这样的缺陷很多。最关键的一条是，如果某个节点无法与管理中心节点通信，就无法获得与其他节点通信的机会，它与其他节点之间的互联网立刻通畅。

此外，还存在管理中心节点与其他节点之间的多节点通信问题。

一般来说，这种方式下的通信成本太高，服务器和手机客户端之间传输数据的中间商太多，非常容易出问题。

所以简单的方法就是要求云服务器互相提速，但是没有响应。

在这种情况下，子程序的逻辑应该分成两个控制模块，一个用于不响应请求、分配端口号和启动服务器设备。

另一个用于轮询磁带速度测量序列，请求并启动移动电话客户端的连接。

工作内容如下:

这种处理还有一种极端情况，就是说两个云服务器互相恳求进行检测。如果对方的恳求到达时间相同，那么另一个端口号将被分配给对方。然后收到对方分配的另一个端口号后，发现服务器已经启动，放弃连接。

所以出现了类似流程的“死锁”。

处理这类事情的流程是用时间戳记录求情的瞬间，根据时间戳的顺序决定是启动手机客户端还是服务器。

即使更极端的情况发生——它们也有相同的时间戳。则根据通过请求超时获取或发送消息释放端口号创建下一个连接。

弱互联网下的解决方案

互联网弱是指网络不好或者带宽小的情况。

这种事情的处理通常意味着重新测试，但是关于重新测试有几个地方必须注意:

针对带宽小的情况，需要考虑减少传输数据量，以保证在规定的请求超时内进行测速。

针对测速不成功的情况，区分测量并举，限制复试频率，防止无限复试。

复试时，手机客户端和服务器可以进行交换检测，可以根据一方的限制保留复试。

摘要

整个结构如下:

那个时候，保留一个功能不难，但要保留好却不容易。

虽然理论上只需要简单的使用专门的工具进行测速就可以得到结果，但是在具体的情况下可用性会越来越低。

例如，如果没有针对弱互联网的重测系统，那么不经意的互联网震颤就会危及测速结果。

如果没有充分考虑多节点竞争连接的问题，在几个云服务器上的具体 *** 作会导致程序流程不正确或者测速结果不准确的问题。

如何保持效果好？

至少2个考虑到方向:

乘法逻辑思维。比如今天的架构适用于10个网页，一切正常。那么，如果有100页或者1000页，会不会有什么特性问题呢？

极端的逻辑思维。也就是说一些极端情况下的解决方案，比如请求超时的解决方案，器皿互斥的解决方案等等。(来自:人与未来gtxlab；作者:朱德龙)

极客网络随即与全球近120个国家的顶级主机房合作，展示了中国香港、英国、日本、日本、中国台湾省、马来西亚、西班牙、荷兰、美国、法国、印度、巴西、墨西哥、印度尼西亚、柬埔寨等国家和地区的网络服务器和云服务器的租赁服务。如有需要，请联系极客网在线客服！