API 海外访问速度优化尝试

问题描述:我们的某个线上服务有两种用户,普通用户(通过浏览器访问我们的服务)和 API 用户,API 又分为国内用户和海外用户,服务器放在青云的广州机房,经常有海外的API用户抱怨说访问我们的 API 请求响应很慢,网络延迟很高。

暂且不说功夫网的影响,国内网络的总出口带宽本身就很小,而且这几年出口总带宽也没有实质提升过,国外的请求在电信主干网的出口位置丢包 90% 是常有的事,无奈。去年(2014)年底,青云开放了亚太1区机房,机房位于香港,跟广州机房直通,两个机房的 ping 值在20ms~30ms之间,为了解决海外用户的访问问题,我们想尝试通过香港机房做一次中转,以期达到加速的目的。

亲测试了两种中间机房中转方式,在香港机房搭建 API Proxy 和 VPN 服务器,但是这两种方法均无法加速海外的API访问请求,原因如下:

  • 青云香港机房到广东机房链路 ping 值在 30ms 左右
  • DigitalOcean 纽约机房到青云香港机房的链路 ping 值在 250ms 左右
  • 从纽约到广州机房,其速度由链路本身决定,无论使用任何方案,均无法解决链路的质量问题,速度约等于纽约 -> 香港 -> 广州机房的链路速度之和,即280ms左右

简单讨论一下我实际测试的两个方案的优缺点。

方案一:自己搭建 API Proxy,首先使用 Dnspod 将来自海外的 API 请求目标 IP 解析到到中间节点机房的服务器上,然后通过 Nginx 服务器反向代理所有的请求到国内服务器。

  • 优点:代理的实现方式透明,国内的用户和海外用户无需任何额外的配置即可正常使用。
  • 缺点:我们的一个关键服务是通过 Websocket 提供 Stream 数据流服务,但是 Nginx 始终无法解决 WebSocket 的代理问题,建立 WebSocket 链接后会立即自动断开,抛出 1006 错误的问题,做了很多努力尝试均无效,问题出在 Nginx 自身,也许其他代理工具能够解决,不过这里不想继续尝试下去了。

方案二:利用青云的路由器提供的VPN功能,相当于搭建了 VPN 服务器,海外客户链接到 VPN 上,然后所有的 API 请求由 VPN 代理。

  • 优点:利用青云的基础提供设施,仅需简单配置即刻开通 VPN 账号,方便快捷。
  • 缺点:管理成本增加,需要管理用户的 VPN 账号,包括受理用户的 VPN 账号申请,创建,核销等。用户实际使用成本增加,包括在用户自己的服务器上配置 VPNClient,路由表维护,监控 VPN 连接状态等。

下面截图是纽约机房 VPN 处于关闭状态时的链接情况,通过 MTR 诊断清晰显示出链路在电信主干网入口节点开始丢包,丢包率80%~90%,平均速度250ms~300ms。

下面截图是开启 VPN 后,相当于在互联网上建立了一条专属虚拟通道,所有针对服务器的请求直接通过青云路由器中转,虽然表面上看起来通过VPN链接貌似屏蔽了所有中间节点,但其实对链路本身并没有改变,平均速率250ms左右。

可能但是未经验证方案三:使用第三方API管理平台,国际知名备选服务商有三家:

经过一番调研,我没有找到确凿的文档和信息表明这三家公司的产品对中国的网络有特别优化,所以目前不打算尝试。说句题外话,API 管理平台是一个逐渐升温的领域,上述三家前两家均在近期拿到大额融资,第三家被巨头 Intel 收购,可以预见到将来 API 加速服务会像 CDN 加速一样快速发展起来,只要市场足够大,到后期一定有巨头介入,开始拼资源。

请教了经验丰富的 @kgen 后的总结一下:

香港到国内虽然延迟极低,但是到欧美的线路不佳,API 加速取决于整体链路状况,到底哪里才是合适的中转节点,必须亲自在不同的地区亲测,且测试一段时间后才能下结论。

目前国内的网络环境,到美国最好选择走日本中转,日本有 NTT, KDDI, Softbank 直连中国,要找国内到这三家任意一家较好的机房,二次中转才能达到比较理想的效果,但是需要不断监控,运维的成本会上升。

所以得出结论,如果没有条件或者实力去调研分析全球网络状况,并优选较好的链路搭建自己的加速节点的话,最好还是建议我们的客户选择距离我们的服务器比较近的地方,甚至同一个机房的 VPS 上跑自己的API应用。

最后感谢一下 @kgen 的无私帮助,经过一番折腾后,深刻理解能长期给大家提供优质的科学上网服务是多么的不容易,所以这里必须给云梯做一下广告:科学上网,请用云梯!