优化 CDN,从全链路入手

阅读数:396 2019 年 9 月 12 日 00:16

优化CDN,从全链路入手

CDN 是一种新型网络构建方式,目的是提高用户访问响应速度和准确率。CDN 代表了一种基于质量与秩序的网络服务模式。本文将从技术角度探讨 CDN 的应用前景,同时结合实际场景中的问题和解决办法,希望能够帮助企业更好的用好网络,服务用户。

今天,我们来介绍下 CDN 优化的核心要点和关键环节。

质量与规模均是业内领先

百度智能云 CDN 自 2016 年开始对外商业化,搭上百度智能云发展的快车道,不断打磨与改进,目前储备带宽近 100T,全球可用节点近 1000 个,拥有国内与海外完整的加速解决方案,CDN 的规模与质量都得到了大幅提升。

优化CDN,从全链路入手

百度智能云 CDN 架构与优势

当前,百度智能云 CDN 的主要特点如下:

  • 边缘 CDN 节点支持 QUIC、HTTP2.0、TLS1.3 等新特性。

  • 节点内部支持私有协议,主要用于节点间加速与内部回源防劫持。

  • 上传加速,节点间使用 QUIC、长连接复用等技术打造上传加速差异。

  • 中心节点与百度内网有高速专线连接,总体利用率不到 40%。

  • 与 BOS(对象存储)结合,有一套完整的上传与分发解决方案。

由于百度智能云的 CDN 表现出色,不少重量级的企业已经在使用。例如,我们服务的长视频类客户主要有爱奇艺、芒果点播等,短视频类客户主要有快手、手百 Feed、全民视频、好看视频等,手机 APP 下载类客户有魅族、小米、华为等。

从全链路入手进行优化

如何做到 CDN 的优化?我们从全链路分析着手,涉及到客户端、网络、节点和回源整个请求的生命周期。

就拿手机百度 APP 的 Feed 小视频来说,当用户点击一个视频后,一个 HTTPS 请求会从端上触发,经历端上 APP 及播放器再到底层网络协议栈发出,再通过公网途经就近 CDN 网络,首次未命中回源获取,同步响应第一个用户。在 CDN 上缓存后,便能加速后续的请求。从这个过程来看,一个请求的生命周期大概经过以下阶段。

优化CDN,从全链路入手

1 客户端:需要不同调整策略

端上的数据往往是我们优化的突破点,因端上 APP 实现逻辑的差异,不同的实现形式可能需要服务端有不同的对应调整。HTTPS 现在基本是端上的标配,有效的 HTTPS Session 复用能大大提升加载资源的速度,手机百度 APP 通过多种 Session 复用技术,可以做到 0-1RTT 的时延。

我们团队与手机百度网络团队联合优化时发现,手机百度端上网络库存在以目标 IP 为粒度的 Session 复用,虽说这样能大幅度提升 Session 复用率,但在目前以 SNI 为基石的多域名复用 CDN 加速机制下,会出现握手失败的情况,最后通过端上网络库的打点,我们能及时发现并解决问题。

另外,我们还结合端上的卡顿分析,发现 4G 网络用户因受运营端套餐的限制,会出现每月从 1 号开始,卡顿比或 loading 率持续上升,再到次月初恢复的现象。

2 网络:注意域名解析

在发请求前,域名解析是一个必不可少的环节,大部分端会首先用 DNS 来解析,但国内的 DNS 劫持与污染一直是非常严重的问题。我们给用户建议使用 HTTP DNS 后有效解决了劫持问题。例如,在某些弱网络环境下,手机百度 APP 端上会自动升级到 QUIC 协议,主动改善用户体验。

3CDN 节点:分层优化

节点内的优化一直是我们的重点,优良架构的选型与核心模块的优化都有显著的效果。百度智能云 CDN 采用典型的分层结构,接入业务层与 Cache 存储层分离,各自分工明确,通过四层 BGW 加七层 Nginx 的两层负载,应对各种故障场景。

CDN 节点上内核协议栈的行为,对性能有很大的影响,如初始窗口、发包策略、重传策略等,我们线上内核大量尝试 BBR、Boost 等较为先进的发包算法,有效提升传输速度与可用性。

另外,协议栈层面,我们还自研了一套系统,能自定义监控一条 TCP 流上所有的形为,这样就能有效快速的定位到应用层数据发完后,是协议栈没有及时处理还是端上网络不好。

4 回源:用私有协议应对劫持

回源劫持一直是比较头疼的问题,如 302 劫持、DNS 劫持等。比较有技术含量的运营商能根据 Host 进行阻断,可能是为了减少跨网流量或主动封堵。此问题可以用 HTTPS 得到有效解决。但 HTTPS 就会要求用户必须提供有效的证书,且存在大量的 SSL 握手,在节点内部回源,就显得有点太重。

为此我们开发了一套私有回源协议,尽量使问题简单有效的得到解决。另外,如果使用百度智能云的 BOS 存储,还会有额外的优化,如高速专线回源、独享公网带宽、常态有 40% 的允余,足以应对各种突发。

重点优化 Nginx 接入层

为了能有效的衡量七层接入层 Nginx 的优化效果,我们团队构建了一个能体现 Nginx 运行状况的卡顿指标,具体为 Nginx 每分钟处理事件 cycle 时间超过 50ms(50ms 的选择是可配置的,主要是考虑优化影响较大的场景)的个数。

优化CDN,从全链路入手

一次处理 cycle 超过 50ms 意味着这个 Nginx worker 上的所有请求,都会在这个时间段(50ms 内)得不到及时的处理。就小文件场景来说,就会体现在首包时间长,而我们的优化往往就是毫秒级进行。对于 Nginx 这样一个高效的异步事件驱动的模型来说,这有背于高并发设计原则,我们应该全力降低并消除回调 callback 过于占用 CPU 的情况。通过我们线上的实践,大体发现两类问题。

1 智能压缩减少 CPU 消耗

这个问题大家都比较容易理解,压缩本来是一个 CPU 密集性任务。为了有效降低 CDN 的出口带宽,部分文件类型的压缩是不可少的。但我们也发现,有部分用户的文件类型,压缩比很低,这类基本没有压缩的必要,所以我们 CDN 支持了智能压缩,自动计算与识别压缩比,来决定压缩与否。

2 解决系统调用卡顿

系统 writev 调用卡顿,是我们逐步缩小定位到的,发现线上机器因内存使用不当,产生大量的内存碎片,而每次 writev 调用时,在申请内存不够时,会时不时的触发 reclaim 或 compaction。经过与内核同学一起定位,通过修改内核行为得到有效解决。

经过以上调整之后,收益明显:可以做到小文件首包降低 30ms+,与多家竞品对齐或超越;同时,每分钟事件处理超过 50ms 的卡顿数降低 90%(从每分钟 40 次到每分钟 4 次)。

总结

本文主要介绍了百度智能云 CDN 优化的核心要点和关键环节,后续将持续撰写相关文章,敬请关注。您可以通过后台或者直接在文末留言,共同讨论如何让 CDN 更快、更稳、更安全。

本文转载自公众号 AIOps 智能运维(ID:AI_Ops)。

原文链接:

https://mp.weixin.qq.com/s/NGeO6aGOedq_mQ6rwaNtCg

收藏

评论

微博

用户头像
发表评论

注册/登录 InfoQ 发表评论