CDN|HTTP协议篇
# CDN
30 秒速记
CDN是部署在站点外部的内容分发服务，用于补足应用侧的网络访问加速能力。HTTPS主要强化链路安全，HTTP/2主要改善协议传输效率，二者并不等同于内容就近分发。Nginx、OpenResty提升源站服务能力，WAF负责抵御入侵，CDN的职责则是从源站之外加速资源访问。- 这些能力解决的问题不同，实际架构中可以组合使用，而不是把
CDN当作其他组件的替代品。
CDN 是部署在源站之外、通过内容分发来加速访问的网络服务。 HTTPS 解决链路安全，HTTP/2 提高传输效率，而 CDN 通过改变资源位置和请求路径，让用户从更近的节点取内容。Nginx、OpenResty 更偏向提升站点处理能力，WAF 负责检查恶意请求，它们和 CDN 可以组合使用。是否真正接入 CDN，不能只看单次耗时或响应头，还应结合 DNS、多地域探测和服务商配置判断。
在正式开讲前，我们先来看看到现在为止 HTTP 手头都有了哪些“武器”。
协议方面，HTTPS 强化通信链路安全、HTTP/2 优化传输效率；应用方面，Nginx/OpenResty 提升网站服务能力，WAF 抵御网站入侵攻击，讲到这里，你是不是感觉还少了点什么？
没错，在应用领域，还缺一个在外部加速 HTTP 协议的服务，这个就是我们今天要说的 CDN（Content Delivery Network 或 Content Distribution Network），中文名叫“内容分发网络”。
原理拆解： HTTPS、HTTP/2 与 CDN 分别作用于不同层面。HTTPS 通过证书、加密和完整性校验保护客户端到服务端的连接；HTTP/2 在单条连接上使用多路复用、头部压缩等机制提高传输效率；CDN 则改变资源所在位置和请求路径，把内容放到靠近用户的边缘节点。源站即使启用了前两者，跨地域访问仍可能经过较长链路；接入 CDN 后，边缘节点也通常会同时提供 HTTPS 和 HTTP/2。
具体实现： 浏览器访问 CDN 域名时，会先通过 DNS 获得边缘节点地址，再与该节点建立连接。边缘节点缓存命中便直接响应；未命中时才回源。Nginx 或 OpenResty 可以部署在源站或边缘侧处理代理、缓存和限流，WAF 可以检查恶意请求，但这些组件的部署位置与职责不能仅凭产品名称判断。
最小验证： 输入两个公开 HTTPS 地址，验证协议安全、传输协议和网络距离是可分别观测的指标。命令要求本机安装支持 HTTP/2 的 curl。
set -eu
for url in https://example.com https://www.cloudflare.com; do
curl --http2 -sS -o /dev/null \
-w 'url=%{url_effective}\nhttp=%{http_version}\nremote=%{remote_ip}\ntls_verify=%{ssl_verify_result}\nconnect=%{time_connect}\ntotal=%{time_total}\n\n' \
"$url"
done
http 表示协商得到的 HTTP 版本，tls_verify=0 表示证书校验成功，remote 和耗时反映当前解析结果及链路表现。即使两个地址都使用 HTTPS 和 HTTP/2，连接地址、时延仍可能不同，说明协议能力不能替代就近分发。
边界与排查： 单次耗时会受本地缓存、运营商、网络抖动和连接复用影响，不能据此断言某域名一定使用 CDN。确认 CDN 接入还应结合 DNS 记录、响应头、不同地域探测以及服务商控制台；响应头可被自定义，也不能单独作为证据。
面试官追问
追问 1业务从 HTTP/1.1 升级到 HTTP/2 后，技术负责人主张下线 CDN，因为多路复用已经解决了页面加载慢，你在评审会上怎么回应？
不应因此下线 CDN，HTTP/2 提高单连接承载并发请求的效率，而 CDN 通过边缘节点缩短资源与用户之间的路径。即使源站支持 HTTP/2，跨地域和跨运营商链路仍可能很长，两者解决的瓶颈并不相同。
追问 2一个全国用户访问的下载页已部署高性能 Nginx，源站处理耗时很低，但异地安装包下载仍慢，你会怎样落地外部加速？
应把适合分发的安装包接入 CDN，让浏览器经 DNS 调度连接附近边缘节点，命中缓存时直接响应，未命中才回源。Nginx 可继续承担源站代理、缓存或限流，但它本身不能消除用户到源站的远距离路径。
追问 3安全团队要求用 WAF 代替 CDN，运维团队则认为边缘节点启用 HTTPS 后不再需要源站协议治理，你会如何划分职责？
两种替代关系都不成立：WAF 检查恶意请求，CDN 负责就近分发，HTTPS 保护连接，HTTP/2 优化传输效率。组件可以部署在源站或边缘侧，实际责任要依据流量路径和配置确认，不能仅凭产品名称推断。
追问 4运维用一次 curl --http2 结果看到远端地址和较低总耗时，就宣布站点已正确接入 CDN，你会要求怎样复核？
一次请求只能观察协商协议、证书校验、连接地址和当时耗时，不能单独证明 CDN 接入状态。还应检查 DNS 记录、服务商控制台，并从不同地域探测；响应头可以被自定义，本地缓存和连接复用也会干扰判断。
追问 5预算只能优先投入源站扩容或 CDN，当前监控显示源站计算很快，但海外页面主要慢在连接和传输阶段，你会倾向哪项方案？
现有证据更支持优先评估 CDN，因为瓶颈位于远距离访问路径，而不是源站处理能力。扩容可提高并发服务能力，却不会缩短地理链路；最终仍需通过多地域时延、缓存命中和回源数据验证投入效果。
# 为什么要有网络加速？
30 秒速记
- 网络访问存在无法由应用代码消除的物理时延：距离越远，信号传播耗时越明显。
- 按材料采用的约
20万公里每秒估算，北京到广州约2000公里，单程传播约10ms、往返约20ms；这只是理想化的距离成本。 - 跨运营商访问需要经过有限的互联节点，拥塞和可用带宽会进一步拉长传输时间。
- 数据还要经过多个路由器与网关，每一跳的解析和转发都会累积额外延迟。
- 跨地域、跨运营商和多跳转发在全球访问中会叠加，因此即使使用
HTTP/2，仍需要额外的网络加速手段。
需要网络加速，是因为地理距离、跨运营商传输和多跳转发带来的时延，无法只靠应用代码或 HTTP/2 消除。 按材料中的传播速度估算，北京到广州约 2000 公里，仅信号往返就约需 20ms。实际请求还要经过有限的运营商互联点以及多个路由器、网关，拥塞、带宽竞争和逐跳处理都会继续增加耗时。跨地域甚至跨洲访问时，这些成本会叠加，所以还需要通过就近访问来缩短链路。
你可能要问了，HTTP 的传输速度也不算差啊，而且还有更好的 HTTP/2，为什么还要再有一个额外的 CDN 来加速呢？是不是有点“多此一举”呢？
这里我们就必须要考虑现实中会遇到的问题了。你一定知道，光速是有限的，虽然每秒 30 万公里，但这只是真空中的上限，在实际的电缆、光缆中的速度会下降到原本的三分之二左右，也就是 20 万公里 / 秒，这样一来，地理位置的距离导致的传输延迟就会变得比较明显了。
比如，北京到广州直线距离大约是 2000 公里，按照刚才的 20 万公里 / 秒来算的话，发送一个请求单程就要 10 毫秒，往返要 20 毫秒，即使什么都不干，这个“硬性”的时延也是躲不过的。
另外不要忘了， 互联网从逻辑上看是一张大网，但实际上是由许多小网络组成的，这其中就有小网络“互连互通”的问题，典型的就是各个电信运营商的网络，比如国内的电信、联通、移动三大家
这些小网络内部的沟通很顺畅，但网络之间却只有很少的联通点。如果你在 A 网络，而网站在 C 网络，那么就必须“跨网”传输，和成千上万的其他用户一起去“挤”连接点的“独木桥”。而带宽终究是有限的，能抢到多少只能看你的运气。
还有，网络中还存在许多的路由器、网关，数据每经过一个节点，都要停顿一下，在二层、三层解析转发，这也会消耗一定的时间，带来延迟。
把这些因素再放到全球来看，地理距离、运营商网络、路由转发的影响就会成倍增加。想象一下，你在北京，访问旧金山的网站，要跨越半个地球，中间会有多少环节，会增加多少时延？
最终结果就是，如果仅用现有的 HTTP 传输方式，大多数网站都会访问速度缓慢、用户体验糟糕。
面试官追问
追问 1北京用户访问旧金山活动页时，接口计算接近即时完成，前端同事据此认定端到端请求也不该慢，你会用链路事实怎样反驳？
源站计算快只排除了部分服务端瓶颈，不能消除长距离传播、跨运营商互联和路由节点转发产生的延迟。请求跨越半个地球时，每个网络环节都会累积成本，因此应把服务端耗时与连接、首字节和总耗时分开观察。
追问 2全国直播页面在源站所在运营商内表现正常，另一运营商晚高峰却频繁超时，值班工程师准备直接增加应用实例，你会先查什么？
应先比较不同运营商的链路与互联点表现，确认是否因跨网带宽竞争和拥塞导致超时，再判断应用实例是否不足。若源站处理与同网访问均正常，单纯扩容很可能无法改善互联瓶颈，还会掩盖真实故障位置。
追问 3产品经理按北京到广州约 2000 公里、介质传播速度约 20 万公里每秒，要求页面往返必须稳定在 20ms，这个指标为什么不能直接承诺？
20ms 只是依据直线距离和传播速度得到的理想化往返估算，最多描述难以绕过的传播成本。真实请求还会经过路由器、网关和运营商互联点，并受路径绕行与拥塞影响，因此不能把理论值当作完整请求时延。
追问 4监控显示接口首字节在跨地域用户侧显著升高，但源站日志里的处理耗时没有变化，你会怎样区分网络传播、跨网拥塞与后端变慢？
应对比不同地域和运营商的连接、首字节及总耗时，并结合源站处理时间判断延迟出现在哪一段。若源站耗时稳定而特定网络显著恶化，更应怀疑传播路径或互联拥塞；单点、单次测量会受网络抖动影响。
追问 5团队只能选择继续优化 HTTP/2 参数或引入边缘分发，业务痛点是跨洲访问慢而同城用户正常，你会怎么取舍？
应优先评估边缘分发，因为主要矛盾是用户与源站之间的长距离和复杂网络路径，协议调优无法突破传播距离。HTTP/2 仍能改善连接内传输效率，但不能替代就近访问，方案效果需通过多地域探测验证。
# 什么是 CDN？
30 秒速记
CDN通过跨地域、跨运营商部署节点，让用户从较近的边缘节点获取资源，降低远距离访问的链路成本。- 边缘节点本质上是缓存代理；源站内容可通过推送或拉取逐级进入
CDN节点。 - 用户命中边缘缓存后无需直接访问源站，因此能够缩短访问路径，并减少源站直接承接的内容请求。
- 图片、音频、安装包等稳定资源适合缓存；库存、粉丝数等实时计算数据通常仍需由源站生成。
- 动态资源只有在业务通过
Cache-Control允许短时缓存时，才能在该有效期内获得CDN缓存加速；代价是这段时间内数据可能不是源站最新结果。
CDN 是把源站内容分发到跨地域、跨运营商的边缘节点，让用户就近获取资源的网络。 边缘节点本质上是缓存代理：命中缓存就直接响应，未命中才回源取内容并按策略保存，因此既能缩短访问路径，也能减少源站请求。图片、音频和带版本号的静态文件适合长期缓存；库存、粉丝数等动态数据通常仍由源站实时生成。若业务允许短暂陈旧，动态响应也可通过 Cache-Control 设置较短缓存时间，但包含身份或私密数据的响应不能默认进入共享缓存。
