UCloud基于SD-WAN架构的GitHub加速方案

摘要：客户收益与展望利用的云网基础架构，该公司通过较低的成本，在不到一周的时间内，快速搭建一套高速稳定的加速平台方案。

背景

Git是目前世界上最流行的分布式版本控制系统，GitHub是一个基于Git的代码托管平台，一个拥有143万开发者的社区，是一个巨大的开源宝库。作为全球程序员和编程爱好者的聚集地，诸多优秀的开源项目代码都托管于GitHub上。

UCloud深圳某初创客户，正在开发运营一款海外社交App，公司研发团队在GitHub上建立了代码仓库，用于托管多个项目的代码，也经常从众多的开源项目中获取产品的灵感。

但当他们的团队成员在GitHub准备下载项目时，就会发现 git clone/pull的速度非常慢。一些小项目等几分钟倒还好，但项目庞大起来或者项目文件数目过多时，git clone/pull 大概率会失败。公司的研发人员也尝试使用过网上常见的诸如修改Hosts、代理上网等方式，但日常使用体验并不好，访问也不稳定，无法满足团队高频度的开发更新需求。

公网GitHub访问速度

根本原因在于大陆地区的国际出口人均带宽不够，截止到2020年3月大陆地区国际出口总带宽为 8.3Tbps，大陆地区共有约9亿网民。假设其中有1%的网民，即9000000人需要访问国际站点，人均带宽不足1Mbps。

同时由于国际公网路由复杂，在不同国家运营商AS间的对等连接导致存在绕行的情况，也导致延迟增加，访问效率降低。

图为广州IDC测试 github.com 的路由，广州访问需从欧洲绕行北美 延时高达270ms；

工具PingInfo View测试结果

图为广州IDC测试github.com 的丢包率，广州访问github.com丢包率3.85%，网络抖动在±100ms；

为此该公司一直在找寻能满足研发需求的高速、稳定的GitHub加速方案，本质是要解决跨国网络复杂、线路拥塞导致的访问延时高、速度慢、抖动大等系列问题。

需求与解决方案

客户需求

作为初创团队， 公司希望能更好地控制成本，同时充分利用GitHub平台上更多的资源来推广产品。UCloud是该公司一直以来十分信赖的合作伙伴，在和他们的日常交流中获知这一需求，并通过多次沟通，总结出需求的几个特点：
1、方案成本低，需要比市面上的专线、广域网加速产品成本上有优势；
2、加速效果好，网络抖动少，服务质量稳定，至少99.9%以上的可用性；
3、接入场景灵活，支持多终端，多种网络环境接入，方便移动办公。

方案对比

在解决跨国网络卡顿、延时高的问题上，对比以下几种方案：

方案介绍

UCloud整合现有全球节点和专线资源，提供PathX、GlobalSSH等全球动态加速产品，构建基于SD-WAN架构的全球加速网络。SD-WAN全称是Software-Defined WAN，即软件定义广域网，SD-WAN核心优势在于转控分离，控制器可以根据物理网络的实时路况，来对上层Overlay网络进行动态调整，选择质量更好的底层Underlay网络。通过端到端的长连接优化，有效降低公网抖动和延迟，使得访问速度大幅提升。

加速方案实施

**SD-WAN方案组件
**
整体方案需要在边缘节点和代理节点部署接入和转发组件，可基于UCloud平台的快杰云主机、GlobalSSH加速等产品，提供灵活接入的跨境专线，提升整个方案构建效率：

Nginx（正向代理）

加速方案中由于用户端需要访问包括GitHub、Docker镜像和其他众多应用服务。而用户端只需配制一个代理域名，所以需要部署一个海外的正向代理节点，转发用户端的请求到不同的源站。

Nginx是一款开源的、高性能的Web服务器和代理服务器，可以支持基于HTTP/HTTPS协议的Web站点服务。当在海外代理节点商部署了Nginx服务，同时加载正向代理模块后，可以在海外代理节点上实现支持HTTP/HTTPS协议的7层负载转发。

GlobalSSH

GlobalSSH，是一款致力于提高跨国远程管理服务器效率的产品，旨在解决由于跨国网络不稳定导致的远程管理出现的卡顿、连接失败、传输速度较慢等现象。

全球动态加速原理架构

通过GlobalSSH提供的加速域名接入，通过DNS智能调度，用户可实现就近接入，然后通过跨境专线访问海外代理节点，有效规避跨国网络拥塞导致的响应慢、丢包等问题。

方案部署流程

1.开通洛杉矶等海外区域云主机

选择主机的配置（建议4核8G起），绑定EIP（开通带宽，一般10M~100M），初始化系统（选用CentOS 7.6）等；

2.部署正向代理组件

Nginx作为正向代理节点，可基于ngx_http_proxy_connect_module模块：https://github.com/chobits/ngx_http_proxy_connect_module
来支持HTTP CONNECT方法，从而让Nginx服务可以扩展为正向代理节点。

部署步骤：
获取nginx安装包、加载正向代理模块、编译安装：

# wget http://nginx.org/download/nginx-1.9.12.tar.gz
# tar -xzvf nginx-1.9.12.tar.gz
# cd nginx-1.9.12/
# patch -p1 < /path/to/ngx_http_proxy_connect_module/patch/proxy_connect.patch
# ./configure --add-dynamic-module=/path/to/ngx_http_proxy_connect_module
# make && make install

配置样式：

server {
     listen 3128;
     # dns resolver used by forward proxying
     resolver 8.8.8.8;
     # forward proxy for CONNECT request
     proxy_connect;
     proxy_connect_allow 443 563;
     proxy_connect_connect_timeout 10s;
     proxy_connect_read_timeout 10s;
     proxy_connect_send_timeout 10s;
     # forward proxy for non-CONNECT request
     location / {
         proxy_pass http://$host;
         proxy_set_header Host $host;
     }
 }

3.在全球动态加速-GlobalSSH-创建

根据需求选择版本（建议企业版以上），填入代理节点EIP，选择服务器靠近区域（洛杉矶LAX），服务器端口配置自定义端口；

4.配置完成

获取加速域名，可直接用加速域名（xx.xx.ipssh.net）配置代理访问，也可通过自有域名配置CNAME记录访问；

5.用户端配置域名代理

通过GlobalSSH加速到达海外代理节点，代理节点再加速转发到源站；
以Linux系统为例，在文件中添加以下配置，保存后退出：

# vi /etc/profile
http_proxy= xx.xx.ipssh.net:3128
#http代理配置CNAME后可用自有域名
https_proxy=$http_proxy
#https代理
no_proxy=*.abc.com10.*.*.*192.168.*.**.locallocalhost127.0.0.1
#不需要代理的域名、IP
export http_proxy https_proxy no_proxy
# source /etc/profile

配置生效，即可以验证加速效果。

方案验证

配置查看广州主机到节点，网络延时37ms，网络抖动±2ms：

广州主机到节点，丢包率为0%：

通过git clone下载同样大小的项目文件以及一些GitHub上热门的项目，查看加速后下载速度：


综上测试数据，采用方案之前，用户拉取项目下载速率：10~20KB/s，延时270ms，网络抖动±100ms，丢包率3.85%，存在下载缓慢、失败的情况；

采用方案后，下载速率：10MB/s以上，延时37ms，网络抖动±2ms，丢包率0%，用户体验有了显著提升。

客户收益与展望

利用UCloud的云网基础架构，该公司通过较低的TCO成本，在不到一周的时间内，快速搭建一套高速、稳定的SD-WAN加速平台方案。通过这个加速平台，团队成员高效地使用各类协同开发工具平台，App新版本也提前上线，为后续业务推广争取到了充裕的时间窗口，节省了大量运营费用。

整个方案基于开源组件，帮助众多开发者高效流畅地使用GitHub，同时还可拓展支持更多种类的应用，让更多的中国开发者享受全球互联网丰富多样的应用服务的便利，更快速、高效地拥抱开源。