我来教你什么是cdn优化从全链路入手就会找到答案。

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

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

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

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

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

百度智能云CDN架构与优势

当前，百度智能云CDN的主要特点如下：

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

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

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

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

就拿手机百度APP的Feed小视频来说，当用户点击一个视频后，一个HTTPS请求会从端上触发，经历端上APP及播放器再到底层网络协议栈发出，再通过公网途经就近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的选择是可配置的，主要是考虑优化影响较大的场景）的个数。

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

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

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

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