多个跨云服务器之间满带宽测速方案

现在很多客户选择多云方案，企业的开发、业务或管理都放在不同的云平台上。以开发公司为例，开发的云平台项目是跨云调度的重型计算平台，因此将使用阿里云等不同云服务制造商的计算实例服务器ECS、亚马逊的EC2或谷歌云compute engine数据传输也将在这些计算实例之间进行。

这种场景会遇到一个问题，云服务器之间的传输速度通常是不同的，即使在同一云服务制造商的不同区域服务器之间传输数据，带宽也会有所不同。

因此，需要测量这些服务器之间的带宽速度，以服务器之间的带宽速度。

总结起来这个功能实现起来有3个要求：

 ①云服务器在不同务器TCP/UDP检测传输速度。

②必须是全带宽测速，即两台服务器在测速时不能有其他网络程序运行。

③需要有效地在多个服务器之间建立两两个连接。

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

基本架构：

 一个简单的想法是启动测速所需的客户端和服务端，让这些程序争相测速。

然而，这种方法在过程管理中容易出现问题，因为每个过程不仅需要操作自己的状态，还需要操作其他过程的状态。同时，一下子就浪费了四个过程，因为事实上，每次速度测量只有一个过程。

因此，更好的方法是利用主从结构，启停负责速度测量的客户/服务端子流程。

这不仅可以有效地避免资源的浪费和竞争，还可以在主要过程中集成许多逻辑功能，如外部提供 REST API，记录日志、备份测试结果等。

当然，为了方便部署和程序控制，所有的过程都是部署的 Docker 容器中。

宿主机需要访问主过程 Docker 所以需要打开服务 Docker 的 remote API 为容器提供服务REST API进行操作。

基本测速TCP与UDP，网络协议是一层一层封装的TCP和UDP属于同一层的两种协议。

其中TCP由于协议在前后端开发中非常常用REST API请求依赖的HTTP(S)协议就是TCP上层协议，而UDP该协议也广泛应用于视频、游戏、下载等业务。

它们有一些共同点：请求的发起方称为客户端，请求的接收方称为服务端，服务端和客户端可以双向通信。

而且它们的点不同。TCP更注重稳定性，需要在客户端和服务端之间建立连接，才能相互发送数据。

UDP更注重速度。客户端可以直接发送数据，而无需与服务端建立连接。但是，如果发送速度过快或网络不稳定，可能会导致包丢失，导致对方接收的数据丢失。

测速工具：

 常用的命令行测速工具有iperf和speedtest，相比之下，选择功能更强大的iperf。

iperf是理想的测速工具，支持TCP、UDP传输数据的大小、传输次数或传输时间以及输出结果的格式也可以通过参数制定。

但是因为前面UDP协议的特点，测速会有点麻烦，需要找到合适的带宽。

比如按照1Gbps以70%和10%的速度发送数据Mbps以0的速度发送数据，然后如果对数据完整性有要求，则必须更倾向于后者。

当然，实际情况并不是说丢包率为0是最好的，而是在可容忍的范围内采用最大的速度传输(数据丢失后可以重新传输~）。

这意味着需要根据实际网络情况不断调整和尝试。

而iperf没那么聪明，所以UDP这一块是团队内部开发的UDP为了找到理想的传输速度，传输工具。

满带宽：

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

由于我们可以启动一个独立的抢占服务器来运行速度测量程序，其他非速度测量程序不太可能占用带宽，而是用于速度测量的子程序。

因此，子程序之间需要互斥甚至互斥。

基本上可以通过状态管理来实现，主程序在每个过程启动时都会将状态置为connecting”，测速完成后置为”waiting，只有在waiting新的子程序可以在状态下启动测速。

但这只是从代码逻辑层面来控制的，对于稳定和强大的程序，最好有其他硬控制方法。

这个时候用容器很容易。

所有需要测速的过程都是在容器中启动的，容器的名称是统一的，所以一旦程序出现bug，多个子程序同时启动，Docke r服务会报错，通知容器名称冲突，从而创造失败。

当然，这种方法也有一定的风险。例如，如果在上一个测速过程中出现问题，不能按时退出，则无法进行新的测速。因此，需要设时间，并在一段时间以上后主动停止当前的测速子程序。

同时，如果主程序意外退出，导致停止失败，也应处理：每次启动主程序时检查，及时销毁未停止的子程序。

 多节点：

 多节点是一个非常棘手的问题。想象一下，如果在一段时间内同时在多个云服务器上启动多个测速程序，如何保证其有序测速？

要解决这个问题，首先考虑一个简单的问题：如何决定哪些云服务器启动服务端子程序，哪些云服务器启动客户端子程序？

如果按照主-从模式，需要建立一个中心节点进行控制，但有很多缺点。最重要的缺点是，如果一个节点不能与中心节点通信，就无法获得与其他节点通信的机会，网络与其他节点及时畅通。

中心节点与其它节点之间也存在多节点通信问题。

总之，通信成本太高，服务端和客户端传输数据所需的中间环节太多，容易出现问题。

因此，简单的方法是让云服务器发起测速请求并相互响应。

在这种情况下，主程序的逻辑应分为两个模块，一个模块用于响应请求、分配端口和启动服务端容器。

另一个用于轮询带测速队列，发起请求，启动客户端容器建立连接。

工作流程大致如下：多个跨云服务器之间的全带宽速度测量实现方案有一个极端情况，即两个云服务器相互要求测试，如果双方要求到达时间一致，将同时分配端口，然后发现服务端已经启动，放弃连接。

于是出现了类似过程的死锁状态。

处理这种情况的方法是使用时间戳来记录请求启动的时间，双方决定是否启动客户端或服务端。

即使出现更极端的情况——双方的时间戳是一样的。然后通过加班回收或发送消息来建立下一个连接。

弱网下的处理

 弱网是指网络不稳定或带宽小的情况。

原则上，这种情况的处理是重测，但重测有几点需要注意：对于带宽较小的情况，需要考虑减少传输数据的体积，以确保测量速度在设定的超时间内完成。

判断和重测速度失败的情况，同时限制重测次数，避免无限重测。

通过限定一方启动重测，可以实现客户端与服务端的交换测试。

很多时候，实现一个功能并不难，但要实现好功能并不容易。

虽然理论上只能通过调用测速工具来实现，但在实际情况下可用性会变得很低。

例如，如果没有对弱网络的重测机制，偶尔的网络抖动会影响测速结果。

若不考虑多节点争夺连接的问题，则实际运行在多个云服务器上可能会导致程序错误或测速结果不准确。

如何实现功能？

至少有两个考虑方向:倍数思维。比如当前框架支持10页没问题，100页和1000页会有性能问题吗？

极限思维。是一些极端情况下的处理机制，如本文中的加班处理、容器互斥处理等。

我公司提供物理服务器和云服务器的租赁服务，包括香港、美国、韩国、日本、台湾、新加坡、荷兰、法国、英国、德国、埃及、南非、巴西、印度和越南。欢迎来电咨询。