原标题：优化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次）。
小提示：后续百度智能云CDN团队将持续撰写相关文章，敬请关注。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
