边缘TCP优化魔法加速游戏视频用户全球访问

(修改于10.16日,更新相关版权图片,多谢大家监督和建议,创作不易,但要求不能降低)

现代数字化应用需要覆盖更广泛分布各地的终端用户,利用边缘节点以及优化的骨干网络是常见的降低用户访问延迟提升用户体验的架构方法,尤其疫情期间,远程办公成为刚需,视频会议、远程教育甚至在线游戏等视频语音以及互动服务都非常依赖整个用户访问链路的优化,前文《“三次握手”这道经典面试题答案是该更新了》中,我们解析了安全通信协议TLSv1.3 的新特性,如何优化新建 TCP 连接和证书交换来回时间的 RTT 优化;

边缘加速这个领域目前大家比较熟悉 CDN 静态内容缓存和动态访问加速,但通常我们都是指的 HTTP/S 协议的7层应用,在游戏、直播等领域,很多移动端跟后台的交互是基于 TCP或 UDP 协议,也属于动态加速场景,通常会利用 Anycast IP 就近接入边缘节点,再通过云厂商的高质量全球骨干网来降低延迟,提升吞吐,以及减少抖动

既然 CDN 比如 AWS Cloudfront 和 Anycast IP + 骨干网 (AWS Global Accelerator)都能实现动态加速,那各自适合哪些场景呢?以及所谓的动态加速是如何实现的呢?

我们引用 AGA(AWS Global Accelerator)常见问题里面的一段来回答一下 CDN 和 AGA 的区别:

“AWS Global Accelerator 和 Amazon CloudFront 是相互独立的服务,都使用 AWS 全球网络及其遍布世界各地的边缘站点。CloudFront 能提高可缓存内容(如图像和视频)和动态内容(如 API 加速和动态站点交付)的性能。Global Accelerator 可通过在一个或多个 AWS 区域中运行的应用程序的边缘为数据包提供代理,提高 TCP 或 UDP 上的各种应用程序的性能。Global Accelerator 非常适合非 HTTP 使用案例,例如游戏 (UDP)、IoT (MQTT) 或 IP 语音,也非常适合特别要求静态 IP 地址或决定性的快速区域故障转移的 HTTP 使用案例。两种服务均与 AWS Shield 集成以提供 DDoS 保护。”

利用边缘节点服务(CDN & AGA 等)同时加速 HTTP/S 和 TCP/UDP 应用访问,参考架构如下:

边缘TCP优化魔法加速游戏视频用户全球访问
边缘TCP优化魔法加速游戏视频用户全球访问

– 1 –

如何动态加速?

动态内容的响应时间 = DNS 查询时间 + TCP 连接耗时 + 首包耗时 + 具体内容下载耗时

边缘TCP优化魔法加速游戏视频用户全球访问
边缘TCP优化魔法加速游戏视频用户全球访问

吞吐 <= TCP Receive Window / RTT

TCP Receive Window 是接收方在不确认发送方的情况下可以接受的数据量。如果发送方没有收到发送第一个数据包的确认,它将停止并等待,如果这个等待超过一定限制,它甚至可能重新传输。默认情况下,窗口大小高达 65,535 字节,这对于具有小 RTT 的链路来说是足够的。为了获得良好的性能,发送方也应分配与接收端相同的内存量。

因此要实现动态加速常见的优化方法:

  • HTTP Keep-alive
  • Off-loading SSL Termination
  • TCP Optimization
  • 采用 UDP 协议比如 QUIC 协议

– 2 –

Cloudfront动态加速之 TCP 优化

用户通过 Cloudfront (CDN)访问部署在 AWS 区域内的服务,所有的 TCP 请求(HTTP是基于 TCP的应用层协议)终结在边缘节点,边缘节点再代理用户请求到后台服务;

– 2.1 –

持久性 TCP 连接:

每次新建 TCP 连接需要一些时间,通常需要服务器和客户端之间有三次握手,通过 Cloudfront (CDN)访问后台服务,用户每次跟边缘节点都需要三次握手进行 TCP 建立连接协商,但边缘节点通过 AWS 骨干网访问后台服务建立的连接是持久性连接,可以被后续用户请求复用,对于离服务所在区域比较远的用户尤其有效,可以降低数百毫秒的连接耗时;如下图,用户 B 在用户 A 之后再次访问 index.jsp 边缘节点到后端服务直接返回数据而不需要再次建立连接,整体响应时间优化到原来的 1/2。

边缘TCP优化魔法加速游戏视频用户全球访问
边缘TCP优化魔法加速游戏视频用户全球访问

– 2.2 –

支持TCP BBR拥塞处理算法:

TCP bottleneck bandwidth and round trip (BBR) 拥塞处理算法是 Google 开发用来优化互联网用户访问性能,BBR 算法之前的算法比如CUBIC,Reno 等都尝试在数据包传输公平性与如何检测/响应拥塞或数据包丢失之间取得平衡,这些算法可能会导致延迟和吞吐波动;而 BBR 则观察通过检测带宽和 RTT 这两个指标来进行拥塞控制;BBR不考虑丢包,因为丢包(在现在这个时代)并不一定是网络出现拥塞的标志了,BBR 依赖实时检测的带宽和RTT来决定拥塞窗口的大小:窗口大小 = 带宽 * RTT;

Cloudfront已全面部署 BBR 算法,在多个网络和区域的聚合吞吐性能提升了 22%(该性能受很多因素影响,不过总体而言是有利的),比如单个印度区域的延迟降低了 14%,第三方 2 MB 文件 CDN 下载测试中发现亚洲区域性能提升明显(28%左右)。

更多内容请扩展阅读文末的参考资料。

– 3 –

支持 TCP/UDP 的 AGA 动态加速

AWS Global Accelerator可能大家不是很熟悉,其实类似 GCP 的全球静态 Anycast IP 加 Premium Network加速方案,目前这两家支持全球 Anycast IP 的边缘节点数量都在100左右,不过 GCP 目前不支持 UDP 协议。

作为一名老司机很容易把 AGA 的动态加速原理联想等同 Cloudfront产品的实现,因为他们都是基于边缘节点的服务,但一个游戏客户反馈的一个奇怪的测试现象,引发了团队的好奇和不少争论,感谢队友的死扣,让我有机会学习到一个新知识,下面我们一起了解下 AGA 目前的 TCP 方面的优化。

首先,今年3月份, AGA 才推出在边缘节点上支持 TCP Termination (TCP 终止),也就是说,原本用户通过 AGA 的 Anycast IP 加速访问后台服务,用户终端是直接和后台服务进行 TCP 三次握手和建立连接的,如下图,用户终端到 AGA 边缘节点时间为 x,AGA 到后台之间的时间为 y,那这种情况下,建立连接时间是 3RTT=3(x+y)

边缘TCP优化魔法加速游戏视频用户全球访问
边缘TCP优化魔法加速游戏视频用户全球访问

与 Cloudfront 的做法类似,AGA 也选择了在边缘终止 TCP 连接,即在客户端与离客户端最近的 AWS 边缘节点之间建立 TCP 连接来缩短初始连接时间,但与 Cloudfront 做法不同的是,Cloudfront 场景下,用户终端首先需要跟边缘节点先三次握手完成 TCP 连接建立后,边缘节点才会接着跟相对距离较远的区域内服务三次握手建立连接,也就是,用户首次动态访问 Cloudfront 建立连接的时间没有优化,都是3 RTT=3(x+y);

AGA 的做法不一样,在客户端发送三次握手请求到边缘节点,几乎同时,边缘节点会转发三次握手请求到后台服务,也就是两端的两个 TCP 连接几乎是同时在进行,也就是有 TCP Termination 功能之后,用户请求哪怕是首次请求,跟后台服务建立 TCP 连接的时间优化到 Max(x+3y,3x);

边缘TCP优化魔法加速游戏视频用户全球访问
边缘TCP优化魔法加速游戏视频用户全球访问

这也解释了客户自己测试时的一个现象,x 侧耗时非常短,y 距离远耗时长,客户应用从边缘节点很快获得 TCP 连接已建立的消息,随即开始发送数据,但发现还需要等待比较长的时间才能得到后台响应(因为要等待边缘到区域中服务建立连接时间)。但整体而言,从客户侧到后台通过 TCP Termination 整个响应时间至少在 TCP 连接这块肯定是有优化的。

由于 AGA 所在的边缘节点到 AWS 区域是走的 AWS 全球骨干网,带宽,稳定性都比互联网要优化,这段连接还有如下的优化来提升性能:

  • 支持 Jumbo frame:通过在 AWS 边缘节点和 AWS 区域中的应用程序终端节点之间启用 Jumbo frame,AGA 能够在每个数据包中发送和接收多达 6 倍的数据(有效负载),Jumbo frame 可以减少了在客户端和应用程序之间传输数据所需的总时间。
  • Large receive side window 和 TCP 缓冲区:通过调整 AWS 边缘基础设施上的接收侧窗口和 TCP 缓冲区设置,AGA 能够在较短的时间段内从您的应用程序接收和缓冲更大量的数据。这样可以更快地向您的客户端下载,客户端现在可以在更短的时间内直接从 AWS 边缘获取数据。
  • Large congestion window。通过通过 AWS 全球网络传输数据,AGA 可以扩大 TCP 拥塞窗口,以发送比通常通过公共互联网发送更多的数据。

更多优化的测试数据可扩展阅读文末的参考资料。

– 4 –

总结

边缘服务在支撑大规模用户场景中越来越重要,电商社交APP中必备的 CDN 缓存加速,游戏,直播等 TCP/UDP 协议的全球加速都离不开边缘服务的支撑,AGA 作为一个新的同时支持 TCP 和 UDP 加速的服务,跟聚焦 HTTP服务的 Cloudfront (CDN)相比有不少差异化的发展方向,期待更多的特性能在 AGA 上支持比如 TLS 终结,QUIC 协议支持等等。

参考资料

  • Dynamic Content Acceleration: Amazon CloudFront and Amazon Route 53 (ARC309)——AWS re:Invent 2013
  • TCP BBR Congestion Control with Amazon CloudFront
  • TCP BBR congestion control comes to GCP – your Internet just got faster
  • Achieve up to 60% better performance for internet traffic with AWS Global Accelerator

申明

本站点所有文章,仅代表个人想法,不代表任何公司立场,所有数据都来自公开资料,转载请注明出处

来源:求索云途,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/135491

发表评论

登录后才能评论
服务中心
服务中心
联系客服
联系客服
侵权联系 投诉举报
返回顶部
河南,挺住!郑州,挺住!一起为他们加油!!