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

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

1、质量与规模均是业内领先

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

用户非常看重CDN的质量,经常会用“PK”的方式从N家中选择1-2家作为供应商。百度智能云CDN经过2017~2018这两年的不断自我进化与客户打磨,目前整体质量综合排名在业界处于领先位置。

优化CDN不用愁,从全链路入手就会找到答案

百度智能云CDN架构与优势

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

  • 边缘CDN节点支持QUIC、HTTP2.0、TLS1.3等新特性。
  • 节点内部支持私有协议,主要用于节点间加速与内部回源防劫持。
  • 上传加速,节点间使用QUIC、长连接复用等技术打造上传加速差异。
  • 中心节点与百度内网有高速专线连接,总体利用率不到40%。
  • 与BOS结合,有一套完整的上传与分发解决方案。

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

2、从全链路入手进行优化

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

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

优化CDN不用愁,从全链路入手就会找到答案

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

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

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

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

▷ 网络:注意域名解析

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

▷ CDN节点:分层优化

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

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

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

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

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

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

3、重点优化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团队将持续撰写相关文章,敬请关注。