CDN这三个字母只要是干互联网的多少都听过不过说归说真让我在面试或者带新人的时候讲清楚“CDN到底凭什么能加速”不少人其实是懵的。我自己做Web开发和技术运维这些年配置过的域名、调过的缓存策略不算少踩过的坑更是一箩筐。这篇打算把CDN的加速原理掰开揉碎讲明白顺带结合最近大家常讨论的哔哩哔哩CDN优选思路聊一聊从理论到落地的完整路径。适合看这篇的人刚接触前端和运维的工程师被领导要求“配个CDN加速一下”却不知道怎么下手的朋友以及那些用着CDN但一直没搞懂它为什么快的资深同事。我尽量用大白话把原理讲透再给你可以直接抄作业的实操方案。1. 先搞清楚CDN到底在解决什么问题1.1 一切延迟都源于物理距离网络访问本质上是在传输比特而比特不能超光速。光在光纤中的传播速度大概是每秒20万公里左右这听上去很快但地理距离一旦拉长延迟就会变得非常明显。北京到上海的直线距离大约是1100公里一趟数据包单程下来至少需要5.5毫秒再加上沿途路由设备的处理时间、排队时间往返RTT超过30毫秒是常态。这个数字平时感觉不到但放到视频播放场景里就有体感了。你打开一个视频播放器要先把首段数据下载完才能起播首字节时间TTFB越高用户看到的缓冲圈就转得越久。更麻烦的是跨运营商链路联通和移动之间的互联带宽经常拥堵用户报障时描述往往就是“网页能开视频卡死”。而CDN干的第一件事就是把内容放到离用户物理距离更近的地方去。1.2 优化延迟的思路别走原路我的理解里CDN解决的核心问题是“绕路”。源站只有一个点全国用户都去连它肯定有人近有人远。CDN的做法是在全国各地甚至全球部署一堆边缘节点用户请求不再直接打到源站而是先被调度到最近、最快的那个节点由它来响应内容。这个优化思路跟日常工作里“就近取材”是一样的。你不可能为了让全国客户都满意把仓库开在每一个城市但你可以通过前置仓来缩短物流链路。CDN边缘节点就是互联网的前置仓而下面要讲的缓存和调度就是前置仓的库存管理和订单分配系统。1.3 源站压力也要顺便减掉除了延迟源站承载压力也是一笔账。一个视频平台如果所有请求都怼到源站带宽成本高不说源站一挂全站皆瘫。CDN承担了绝大多数静态资源请求之后源站只需要服务少量回源请求和动态接口整体可用性会明显提升。我见过不少团队最开始只用CDN做静态资源加速后来发现它在抗突发流量、防攻击上也有奇效。再也不怕某个大促、某个热点视频把服务器打爆。可以说CDN解决的问题远不止“快一点”这么简单它是互联网基础架构里一个承上启下的关键层。2. 三大核心机制决定CDN快不快2.1 智能调度谁是离你最近的那个人CDN的调度算法是所有加速策略的起点。传统DNS解析只负责把域名翻译成IP而CDN的DNS服务会动态判断“你是谁”“你在哪”“你现在走哪个运营商网络”然后返回一个当前对你最优的边缘节点IP。通常的调度策略包括这几个维度地理位置按用户IP所在地理区域就近分配。运营商网络电信用户尽量给电信节点联通用户进联通节点避免跨网。节点负载如果就近节点已经过载就把用户分配到邻近的轻负载节点。链路质量实时探测各骨干线路的丢包率和RTT避开通堵的链路。这层调度对于最终体验影响巨大。同一个用户分到了跟你是同运营商的节点和分到了跨运营商节点视频起播速度差距可能达到几倍。后来出现的HTTPDNS方案本质上是把这种动态调度从传统DNS领域往下游移动了一层让APP直接通过HTTP接口拿最优IP从而避开本地DNS解析被缓存造成的调度失效问题。2.2 边缘缓存把数据留在离用户最近的地方调度把人带到了边缘节点节点上得有内容给用户才行这就是缓存的职责。CDN的缓存体系一般分两层边缘节点负责覆盖本地区用户核心节点或中层节点负责存储更大范围的热门内容源站永远处于最上层。缓存加速能成立靠的是互联网流量访问的“二八定律”。80%的用户请求集中在20%的内容上比如热播剧、热门视频、头部图片。缓存系统只要把这一小部分热点内容放在边缘节点就能覆盖大多数用户请求命中率上来之后用户请求根本不需要触及源站。我平时配置缓存时最关注三个参数参数作用典型值缓存时间控制内容在节点上的有效期图片1天~30天HTML建议短一些缓存优先级命中缓存时的优先级顺序按文件类型设置回源策略缓存未命中时向源站请求的方式回源重定向、回源带参数等缓存时间的设置是门学问。图片、CSS、JS这种哈希文件缓存一个月没毛病带个性化信息的接口、动态页面缓存几秒钟甚至不缓存都行。定错了会导致两种极端缓存时间太长用户看到的内容不更新缓存时间太短源站压力一点没减轻。2.3 协议优化在TCP和HTTP层面挤时间调度和缓存解决的是“少走路”和“少取货”的问题但即使内容就在离你很近的节点上TCP连接建立的握手开销、HTTP的串行请求效率依然会拖慢加载速度。所以主流CDN平台普遍会在传输协议层做优化。比较常见的手段包括连接复用通过Keep-Alive让同一TCP连接处理多个HTTP请求省去反复握手。TCP优化调整TCP窗口、快重传等参数提升高延迟链路下的吞吐。HTTP/2多路复用一个连接上并行跑多个请求解决HTTP/1.x队的头阻塞。HTTP/3QUIC基于UDP实现连接建立更快弱网环境下表现更好。TLS握手优化会话复用、OCSP装订、TLS1.3降低HTTPS握手耗时。印象很深的一次有个客户反映海外访问网站特别慢加了CDN并且开了QUIC之后打开速度体感提升极快。原因就是QUIC把连接建立的RTT从两次降到了接近一次在高延迟跨国场景下省出来的时间非常可观。3. 实测分享哔哩哔哩视频卡顿与CDN节点优选3.1 B站视频为什么还需要“优选”按理说B站的CDN节点覆盖已经很广为什么社区里还有大量关于“哔哩哔哩CDN优选”的讨论甚至有人专门写脚本去测速和切换节点原因是CDN调度是全局策略不可能为每个个体量身定制。你所在地区的IP段如果被解析到了一个异常拥塞的节点或者运营商互联链路不稳定实际体验就会很差表现为视频加载慢、拖进度条要等很久。这种问题在跨网用户和校园网用户群体里特别突出。优选的核心思路很简单绕过默认调度结果通过测速找到当前网络环境下最快的节点然后通过本地hosts把视频域名直接指向它。3.2 测速指标与评测方法做节点优选之前先明确看哪些指标否则就是瞎试TCP连接延迟TCPing这是首选指标能快速反映网络链路质量。可以用tcping工具或自写脚本实现。HTTP请求耗时完整发起一个HTTP HEAD请求看首字节时间比纯TCP延迟更接近真实播放场景。丢包率丢包会直接导致视频花屏、卡顿而且光看延迟看不出丢包问题必须要测。下载速度有条件的话下载一个几十MB的测试文件统计实际吞吐这是最直观的结果。提醒一句测速需要多做几轮不同时间段的结果可能差异很大。晚上8点到11点是晚高峰这个时间段的测速结果最有参考价值。我自己习惯在晚高峰连续测三轮每轮间隔几分钟取稳定值排排序。另外测速时尽量别开代理类软件这类工具会改变路由测出来的是假数据。3.3 优选脚本的核心逻辑与代码实现目前社区常见的B站CDN优选脚本核心逻辑都不复杂先从DNS拿到一个CDN域名解析出来的所有IP再逐个测速排序最后把最优的IP写进hosts。我用Python写个简化版演示这个思路注意这里依赖了dnspython库跑之前先pip install dnspython。#!/usr/bin/env python3 import socket import time import statistics import dns.resolver # 这里填写B站视频CDN的域名 CDN_DOMAIN upos-sz-mirror08.bilivideo.com # 测速端口B站视频服务通常用80/443 TEST_PORT 443 # 每个IP测几轮 TEST_ROUNDS 5 # TCP连接超时时间(秒) TIMEOUT 3 def get_ip_list(domain): 解析域名获取所有A记录IP try: answers dns.resolver.resolve(domain, A) ip_list sorted({answer.address for answer in answers}) print([*] 解析到 {} 个IP.format(len(ip_list))) return ip_list except Exception as e: print([!] DNS解析失败: {}.format(e)) return [] def tcp_connect(host, port, timeoutTIMEOUT): 返回TCP连接耗时失败返回None start time.perf_counter() try: with socket.create_connection((host, port), timeouttimeout): return (time.perf_counter() - start) * 1000 except OSError: return None def speed_test(ip): 对单个IP执行多轮TCP握手测速返回平均延迟(ms) results [] for _ in range(TEST_ROUNDS): cost tcp_connect(ip, TEST_PORT) if cost is not None: results.append(cost) time.sleep(0.1) if not results: print([!] {} 全部连接超时.format(ip)) return None # 去掉最大最小值取平均减少抖动干扰 results sorted(results)[1:-1] return statistics.mean(results) def main(): ip_list get_ip_list(CDN_DOMAIN) if not ip_list: return result [] for ip in ip_list: avg speed_test(ip) if avg is not None: result.append((avg, ip)) print([*] {} 平均TCP连接耗时: {:.2f}ms.format(ip, avg)) if not result: print([!] 所有IP都无法连通换个时段再试试吧) return result.sort() best result[0] print(\n[] 最优节点: {} 平均耗时 {:.2f}ms.format(best[1], best[0])) # 输出hosts格式的配置 print([] hosts推荐写入:) print({} {}.format(best[1], CDN_DOMAIN)) # 再输出前3名方便手动挑选 print([] 备选节点:) for avg, ip in result[1:4]: print({} {} (耗时 {:.2f}ms).format(ip, avg)) if __name__ __main__: main()这段代码只是演示基本思路真实场景要考虑更多比如B站视频域名分成多个区域段需要从UA和接口参数去匹配对应域名又比如应该针对所有视频相关域名分别测速再生成hosts而不是只测一个域名。用bash写会更轻量适合在Windows的Git Bash或Linux环境直接跑。我常用的大概逻辑就是这样#!/bin/bash DOMAINupos-sz-mirror08.bilivideo.com for ip in $(dig short $DOMAIN A | sort -u); do if [ -z $ip ]; then continue fi TCP_TIME$(timeout 3 bash -c echo /dev/tcp/$ip/443 2/dev/null) if [ $? -eq 0 ]; then # 用curl测HTTP首字节时间 HTTP_TIME$(curl -o /dev/null -s -w %{time_starttransfer} --resolve $DOMAIN:443:$ip https://$DOMAIN/ 2/dev/null) echo $ip $HTTP_TIME fi done | sort -k2 -n | head -53.4 hosts改动的注意事项与避坑测出最优IP之后直接写进hosts文件路径如下WindowsC:\Windows\System32\drivers\etc\hostsLinux/macOS/etc/hosts写入格式是“IP 域名”比如122.225.55.10 upos-sz-mirror08.bilivideo.com改完记得刷新DNS缓存Windows执行ipconfig /flushdnsmacOS执行sudo dscacheutil -flushcache。这里有几个我踩过的坑值得多说两句。第一hosts文件只接受IP和域名的映射不要写“https://域名”或带端口写错了不仅不生效还可能拖慢系统解析。第二CDN节点的IP是会变化的今天最优不代表一周后最优过一段时间发现速度又变差了需要重新测一遍并更新hosts所以优选脚本不是一次性工具而应该定期跑。第三如果你访问的是B站业务里其他域名字段比如接口域名、图片域名只改视频域名是不够的要确认卡顿具体发生在哪个环节再对症下药。我一直建议身边朋友把优选当成调试手段而不是长期改造方案。真正的长期方案是推动运营商优化路由或者让内容平台优化调度策略。对个人来说优选相当于自己动手做的一点点拨正能解决实际问题就值得用。4. CDN配置参数与常见故障排查实录4.1 缓存命中率上不去的几个原因很多人配置完CDN以为万事大吉打开统计后台一看缓存命中率只有20%顿时就慌了。命中率上不去先别急着怀疑CDN不行大概率是配置逻辑有漏洞。常见原因有这几种缓存时间设置过短比如给HTML设置了60秒缓存而站点流量没那么集中结果是绝大多数请求都处于过期态每次都回源。URL携带动态参数CDN默认情况下把完整URL包括查询参数作为缓存key同一个资源带着不同的时间戳参数会生成多个缓存副本互相挤占空间。Cookie导致缓存失效针对动态会话的缓存规则误伤到了静态资源。缓存规则粒度太粗没有区分静态和动态内容或者泛域名配置覆盖了不该缓存的内容。排查的时候我习惯先把CDN日志里回源请求的URL拉出来看看哪些URL回源最频繁再针对性地调整缓存规则。比如给URL中的时间戳参数做忽略处理或者对静态目录单独设置长缓存时间命中率常有立竿见影的回升。4.2 回源配置引发的连锁问题回源是CDN里最容易被忽视、却又最容易出事的一环。比较典型的一个问题源站绑定了一个域名而CDN回源时用的Host头和实际访问域名不一致导致源站返回了404或错误页面边缘节点把这个错误页面也缓存下来用户就开始持续报障。另外就是回源协议不一致。源站只开了HTTP但CDN回源配置强制用了HTTPS回源全挂。或者反过来源站证书是自签名证书CDN源站校验开启后拒绝连接。我做配置时一定会把回源测试放在上线前最后一个环节用curl模拟回源请求确认状态码、Header、响应体都正常。上线后还要持续关注回源带宽正常情况下回源带宽应该远小于总下行带宽如果回源带宽跟总带宽接近说明缓存基本没生效赶紧回头查规则。4.3 改了hosts还是慢问题出在哪这个坑在优选的实践里太常见了。费劲测速、写hosts、刷新缓存结果视频还是卡为什么一种可能是你测速的对象域名和视频实际请求的域名不是同一个。B站不同的视频清晰度、不同的分区可能走不同的CDN节点你只优选了其中一个域名其他域名仍然走默认解析效果自然不明显。建议先打开浏览器的开发者工具筛选出视频分片请求逐个确认实际请求的域名再决定要优化哪些。另一种可能是你测的是TCP连接延迟而实际瓶颈在带宽。视频是持续传输型业务如果上下行带宽不足或者使用了流量比较紧张的共享网络节点再快也白搭。这时候优选帮不上忙你应该换个网络环境测试或者检查是不是被限速了。最后一种可能性是hosts文件格式不生效比如Windows下hosts文件末尾没有换行或被安全软件拦截了写入修改后并没有真正生效。判断方法很简单在命令行跑ping 域名看解析出来的IP是否等于你写入的IP不是的话就是hosts没生效。4.4 缓存穿透、缓存雪崩与热点内容除了日常配置问题稍微大一点的站点还会遇到缓存穿透和雪崩的问题。缓存穿透是指恶意用户或者异常爬虫故意请求那些根本不存在的内容命中不了缓存每次都打到源站。处理方案不复杂CDN管理后台一般有频率控制功能或者给这些非法请求直接返回短时间缓存空结果。缓存雪崩发生在大量缓存同时过期的场景瞬间所有请求都回源把源站打垮。我会刻意给相似资源的缓存时间加上少量随机偏移让过期时间错开这个技巧在自建缓存层时特别好使。CDN平台上虽然没有直接暴露这种随机偏移配置但我们可以通过调整不同目录的缓存时长达到类似效果。热点内容导致的流量集中也很常见。节假日活动的图片和视频会被大量访客同时刷如果不提前预热第一个用户访问时会有一波陡峭的回源请求。很多云厂商的CDN都有预热或者刷新功能事先把热点内容推送到边缘节点上就能平滑度过流量波峰。最后补充点个人的实际心得CDN这个东西用起来门槛不高但精细调优确实需要耐心和数据支持。我做了这么久运维越来越觉得它像一门“概率优化”的艺术——你做的调度、缓存、协议优化都是在尽量提高用户获得满意体验的概率但没有任何配置能保证100%的加速效果因为网络环境太复杂了。所以合理的做法是监控先行用数据说话。上线CDN后持续观察访问延迟、缓存命中率、回源带宽、错误率这几项核心指标哪个异常就去排查对应的环节。不要迷信任何“一键加速”的承诺那只是起点离最优效果还有很长的调试路要走。如果你是冲着B站CDN优选来看这篇的我最后再给你一个建议优选脚本可以帮你解决燃眉之急但记得隔一两个星期重新跑一次节点的IP和链路状态一直在变一次配置吃半年的想法趁早放弃。保持测速、写入、验证这套流程在手边遇到卡顿就花几分钟重测一轮稳得很。