CDN加速怎么选？4层与7层工作原理及实践对比

1. 先对齐概念：4层和7层到底差在哪里

做运维和架构的同学应该都有这种经历：业务一卡，领导就说“上CDN”。但真正到了选型环节，发现CDN产品里经常出现“L4加速”和“L7加速”两个选项，很多人第一反应是——不都是加速吗，选贵的准没错。结果实际接入后，要么钱花了没效果，要么该快的不快，该稳的又不稳。我自己就踩过这个坑，所以这篇把两个层级的原理拆开讲清楚。

先说结论：4层和7层的差异，本质上不是“速度档位”的差异，而是转发模型的差异。4层加速工作在OSI模型的传输层，处理到TCP/UDP报文头为止；7层加速工作在应用层，能看懂HTTP协议栈里的内容，比如URL、Header、Cookie、响应体。这就是“拆包深度不同”带来的能力边界不同，直接决定了它能优化什么、不能优化什么。

一个请求从客户端发出，到CDN边缘节点，再到源站，如果走的是4层，节点只做报文转发，看到的是：

code复制源IP 目标IP 源端口 目标端口 协议类型(6=TCP, 17=UDP)

够了，按目标IP和端口把数据包扔给后端就行。

如果走的是7层，节点要做的就复杂得多：

code复制TCP连接终止 → TLS解密 → HTTP报文解析（请求行/Header/Body）→ 判断缓存 → 回源/命中 → 缓存副本 → 响应

所以在节点上，4层和7层处理路径完全不同，整个架构中的资源消耗、性能瓶颈、可观测性也完全不一样。

我习惯用一个快递的类比来给刚入行的同事解释：4层就像快递转运中心，只认面单上的地址，按城市分拣，包裹里装的是什么都不管；7层就像拆包验货的仓库，会根据货品类型重新打包、贴上新的标签，甚至有些货压根不用去总仓调，本地就有库存直接发。这个“本地库存”就是7层最核心的缓存能力，4层永远做不到。

2. 4层加速的看家本领：不读懂内容也能快

2.1 转发模型：从LVS到DPDK

4层加速最经典的落地形态是LVS（Linux Virtual Server），这在大规模集群里非常常见。LVS有三种转发模式，我分别说一下它们的区别和适用场景：

• DR模式（Direct Routing）：请求进来后，LVS只修改MAC地址，然后把数据包发给后端的真实服务器。响应数据不经过LVS，直接回给客户端。这种模式下LVS的负载压力最小，性能最高，但要求后端服务器和LVS在同一个二层网络，且后端服务器也要配置VIP。我见过不少团队在这个模式下栽跟头，就是因为忽略了后端服务器的ARP抑制配置。
• NAT模式：进出流量都经过LVS，LVS改写IP地址和端口，所以LVS本身容易成为瓶颈。好处是后端服务器可以随便藏在私网里，安全性更好。适合流量规模不大、但需要隐藏后端拓扑的场景。
• TUN模式（IP Tunneling）：把原始数据包封装在一个新的IP包里，传到后端再解封装。这种模式允许后端和LVS跨网段部署，灵活性高。不过因为要处理IP-in-IP封装，CPU开销也上来了。

很多云厂商的LB产品，底层就是LVS的某种模式的变体。在大流量的场景下，纯内核协议栈处理报文会遇到瓶颈，于是又发展出了DPDK（Data Plane Development Kit）这套玩法。DPDK绕过了内核协议栈，在用户态直接轮询网卡收包，配合大页内存、CPU亲和性绑定，单机转发能力能做到线性提速。用一句话总结就是：把原来操作系统内核干的活，搬到用户态自己干，而且是专门为转发优化过的干法。

2.2 4层加速到底在优化什么

4层加速能做的事情，从客户端视角看，主要有三类：

第一是就近接入和智能路由。 如果只是纯4层LB，节点只负责把流量转给后端，那和普通负载均衡没什么区别。但CDN场景下的4层加速，通常还叠加了全球节点调度能力。客户端通过Anycast或DNS调度，自动接入离自己最近的边缘节点。边缘节点和源站之间，又有多条可用路径，CDN系统会实时探测哪条链路延迟低、丢包少，动态选路。这解决的是“跨地域传输质量差”的问题，尤其对游戏、金融行情这类实时性要求极高的业务，效果立竿见影。

第二是TCP层面的优化。 这是4层加速里最容易被低估的杀手锏。BGP公网质量不稳定，跨网传输时TCP的拥塞控制算法经常被触发，导致吞吐率直线下降。CDN厂商在边缘节点和源站之间，往往使用高质量内网或优化过的专线链路，配合BBR这类现代拥塞控制算法，可以显著提升大文件的传输速度和稳定性。

另外还有SYN代理和连接复用。SYN代理的思路是：客户端和CDN节点建TCP连接时，节点先代替源站完成三次握手，确认客户端没问题之后，节点再和源站建立连接。这样做的最大好处是把源站从海量无效连接中解放出来——慢速攻击、半连接、重复握手的压力全被边缘节点消化掉了。连接复用则是针对大量短连接场景，比如App的API请求，客户端每次请求都要建连、断连，握手开销巨大。通过4层加速在节点上维持长连接池，复用后端连接，业务侧的QPS不变但建连开销大幅降低。

第三是基础安全防护。 4层维度可以做DDoS攻击的流量清洗，比如针对SYN Flood、UDP Flood这类流量型攻击的缓解。原理也不神秘——攻击流量到了CDN节点就被识别并丢弃，源站的出口带宽不会被耗尽。但要明确，4层看不到HTTP层的内容，像CC攻击（模拟正常请求）这种就无能为力。

2.3 4层做不了的，恰恰是选型时的分水岭

4层加速的天然短板就是：它不关心报文里的业务内容，所以无法做内容维度的优化。

举几个具体例子：

• 用户请求一张图片，4层节点不知道这是个图片请求，必须完整回源拉数据。
• 同样的图片被请求一万次，4层节点每次都会回源，因为它在传输层只看到TCP的载荷，无法判断“这个内容是不是重复的”。
• 不同URL可以有不同的缓存策略，4层节点根本读不到URL。

如果你想把热点静态资源的压力从源站剥离掉，4层加速做不到；如果你只想做链路质量优化、把数据更稳更快地送到源站，7层加速又显得过度复杂。这就是为什么很多业务最终是4层和7层配合使用，而不是二选一。

3. 7层加速真正在工作：内容语义层的核心优化逻辑

3.1 缓存的命中逻辑，不只是“存一份副本”

7层加速最核心的价值就是HTTP缓存。但缓存怎么命中、怎么判断过期、怎么失效，这里面的门道比大多数人想的多。

当客户端请求一个资源时，7层节点会先解析URL，然后按请求方法（GET/HEAD）、Cache-Control、Cookie等信息去查本地缓存。命中了就直接返回，并在响应头里带一个X-Cache: HIT；没命中就去源站拉取，拉到之后根据策略决定要不要存下来。这里的关键就在于“按什么维度缓存”。

同一个URL，因为Accept-Encoding不同，返回的内容可能是压缩版和未压缩版两种，这是不同的缓存条目；同一个URL，因为Cookie里带着用户登录态，返回的内容可能是私有的，这种就必须遵循private标记，不能缓存；带Set-Cookie的响应头，如果没有显式配置忽略，节点也会自动放弃缓存——因为响应可能和用户身份绑定。

缓存过期策略上，Cache-Control: max-age是节点最信任的指令。比较常见的误区是：很多人以为源站的响应头里带了Cache-Control: no-cache，CDN就完全不缓存。实际上no-cache的意思是“每次使用前必须先回源验证，但验证如果返回304 Not Modified，还是可以复用本地副本的”。真正禁止缓存的是no-store。这俩的区别，我见过不止一个团队因为搞混，导致源站压力翻倍。

ETag和Last-Modified属于后验机制：节点本地有副本，但不确定是否新鲜，于是拿着If-None-Match或If-Modified-Since去问源站，源站回304，节点复用副本，只需要传一个很小的响应头回来。这个机制能大大节省回源带宽，尤其是资源更新不频繁、但需要时刻保证最新内容的场景。

3.2 不止缓存：TLS握手和协议升级带来的隐性收益

很多人只盯着缓存看7层加速，忽略了另一个大头——TLS优化。

HTTPS已经普及的今天，一次完整的TLS握手需要多个RTT（Round-Trip Time），如果遇到跨地域访问，光握手消耗的时间就能让首屏体验明显变差。7层CDN节点在边缘位置终结TLS连接，也就是和客户端建立HTTPS连接的是CDN节点，节点和源站之间再走一条独立的内部通道，这样：

• 客户端只需要和一个离自己很近的边缘节点握手，延迟大幅降低。
• TLS握手过程可以用会话复用（Session Resumption）或者Pre-shared Key机制，二次访问时直接跳过证书验证等步骤。
• OCSP Stapling可以在TLS握手阶段就附上证书吊销状态，省去客户端额外去查OCSP服务器的开销。

另外就是HTTP协议层的升级。HTTP/2的多路复用解决了HTTP/1.1队头阻塞的问题，多个请求可以同时在一个TCP连接上传输。HTTP/3更进一步，把传输层换成了基于UDP的QUIC，彻底绕开了TCP层面的队头阻塞，弱网环境下的表现明显更好。这些协议升级，如果回源链路不支持，CDN节点可以在边缘统一终结协议，向下兼容老客户端，向上支持新协议，这就是7层加速的协议翻译能力。

还有一个容易被忽略的能力是边缘计算。现在主流CDN厂商都提供了边缘函数（类似服务端的Serverless），用JavaScript或WebAssembly直接编写逻辑部署在边缘节点。比如请求在边缘直接做改写、鉴权、请求聚合，甚至把多个API的响应合并成一个再返回客户端。这种能力意味着业务逻辑可以下沉到离用户最近的地方，不再需要所有请求都打回源站处理。

3.3 7层加速的性能开销和适用边界

7层加速能力强、能做的事情多，但代价也真实存在。节点上每一个请求都要经历解包、解析、查缓存、回源判断、再封包的过程，CPU和内存的消耗远高于4层转发。如果业务本身以动态请求为主——每次请求的响应都依赖用户身份或实时数据库查询——那缓存基本帮不上忙，协议的翻译和TLS终结可能带来一点点开销，但整体收益就变薄了。

这里有一个容易误判的问题：“动态接口也有重复的部分，比如响应结构一样，只是参数不同，能不能缓存？”技术上确实可以做参数级别的缓存策略，但业务上要小心，因为接口里如果混入了用户维度数据，缓存命中后极有可能发生数据串号。我处理过一次线上事故，就是因为把带用户信息的动态接口配置了边缘缓存，结果A用户登录后看到了B用户的数据。最后排查下来才发现是缓存Key的粒度不对，漏掉了Header里的用户令牌。

所以7层加速适合的典型场景，我用一张表总结：

4. 同样的业务，4层和7层如何选：分水岭与组合玩法

4.1 一个决策清单：先看业务诉求再谈技术

我自己做选型时，习惯按这个顺序问问题：

1. 业务是否允许内容被缓存？ 如果不允许（比如实时行情、用户私密数据），7层缓存优势直接失效，更多得依赖4层的链路优化和连接管理能力。
2. 回源带宽和数据传输成本是否构成压力？ 如果源站带宽天天被打满，说明有大量重复内容被反复传输，这是7层缓存最擅长解决的。
3. 用户的地域分布是否分散？ 如果用户集中在北方三四个省份，静态资源直接放对象存储+CDN就够；如果用户全球分布，需要更强调边缘节点覆盖和协议优化，7层的边缘计算能力能发挥更大价值。
4. 对首包延迟还是整体吞吐更敏感？ 首包延迟要求高的交互类应用，4层就近接入+SYN代理效果直接；大文件吞吐，7层缓存和分片传输优势更明显。

4.2 两种架构的真实工作流对比

假设一个业务是内容类App，用户主要浏览文章和图片。走7层加速时，整个链路是这样的：

code复制用户A → CDN边缘节点(解析URL→命中图片缓存→直接返回200)
用户B → CDN边缘节点(动态接口请求→TCP终结→解密→转发回源→源站返回→节点转发响应)

节点不仅承担了缓存角色，还承担了TLS终结、协议转换的职责。用户在弱网环境下，还能通过HTTP/3及时拿到数据。源站侧感受到的压力，大部分是CDN节点回源的缓存未命中流量，静态资源的请求基本到不了源站。

再假设一个全球游戏加速业务，客户端和游戏服务器之间需要保持可靠的UDP长连接，那7层缓存几乎没用，需要的是4层能力：

code复制全球玩家 → 就近CDN节点(智能路由选择最优链路)
→ 源站所在Region的4层接入点(转发给游戏服务器)

这里4层CDN要解决的是跨洋链路的丢包和延迟，以及UDP包的路由稳定性。游戏服务器只需要对接一个固定IP的接入点，不需要暴露在公网环境下，安全性和稳定性都更有保障。这类场景里，边缘节点更像一个“网络管道优化器”，完全不碰业务协议内容。

4.3 组合使用的架构实践

大型业务的真实架构，通常是7层和4层层层叠加的。我在一次视频平台的架构优化里就是这么设计的：

code复制用户 → Global LB（4层，就近接入+Anycast调度）
     → 7层CDN节点（HTTP缓存+协议优化+边缘鉴权）
     → 源站接入LB（4层，同机房LVS做入口）
     → 应用服务（7层业务逻辑处理）

第一层4层负责让用户快速进入CDN网络，第二层7层负责最大化缓存命中率和协议优化，第三层4层是源站机房的负载均衡入口，最后一层才是真正的业务服务。每一层的职责都不同，选型时先想清楚这一层要解决什么问题，再决定用什么方案。

4.4 不同维度上的核心差异

把两者的差异按几个关键维度对比如下：

5. 落地实操中的经验：配置要点与踩坑记录

5.1 7层缓存配置的几个关键参数

如果你用的是市面上主流的CDN产品，7层配置时这几个参数一定是绕不开的：

• 缓存过期时间（TTL）：静态资源建议按类型区分，图片和JS/CSS可以配置30天以上，HTML文件5~10分钟，动态接口建议不要配置缓存或者只配置几秒钟的短期缓存。TTL过长会导致源站更新后，用户还在看旧内容；过短则起不到缓存效果。
• 缓存键（Cache Key）：默认情况下，URL是缓存键。但如果业务里有按Header、Cookie区分内容的场景，一定要把相关字段加入缓存键配置里。我之前踩过的串号事故，就是因为缓存键漏掉了用户令牌。反过来，如果确定某个URL内容与用户无关，但请求里带着随机参数（比如?_=123456这种时间戳去缓存穿透），最好配置“忽略参数缓存”，否则同一个资源会因参数不同产生无数缓存条目，命中率直线下降。
• 回源HOST配置：节点去源站取数据时用的Host头，必须和源站正确匹配。配置错了会出现“CDN缓存里一切正常，但第一次回源时源站返回403”的诡异问题。

5.2 一个典型的缓存命中率低排查案例

之前接手过一个客户，静态资源上了7层CDN，但源站带宽一直降不下来。面板上看缓存命中率只有40%左右，远低于正常水平。最初怀疑是缓存时间配置太短，但查看配置后TTL设的并不激进。后来把请求日志拉出来，发现大量URL后面都带着不同的签名参数，像是/static/img/logo.png?auth=abcdef、/static/img/logo.png?auth=123456这种。由于默认缓存键是整个URL，这些带不同参数的请求被当作完全不同的资源，全部绕过了缓存去打回源站。

解决方式是在CDN控制台配置“忽略URL参数”，但前提是确认这些参数不会影响响应内容。签名参数通常只是鉴权用途，和图片本身内容无关，所以直接忽略掉后缓存命中率很快拉升到95%以上，源站带宽压力明显缓解。这个案例后来我常跟客户讲：排查缓存问题时，第一件事永远不是动TTL，而是先看缓存Key的实际内容长什么样。

5.3 4层加速部署中的几个容易忽略的坑

4层加速部署看似简单，只是配置IP和端口，但有几个细节不注意会留下隐患：

第一是会话保持（Session Persistence）。4层LB转发时，如果后端有多台服务器，同一个客户端的不同请求可能会被转发到不同服务器。无状态服务无所谓，但如果有基于内存Session的登录态，用户会在操作过程中被反复踢下线。配置源IP哈希或者Cookie会话保持可以解决，但会带来负载不均的副作用。

第二是健康检查的策略。LVS等4层LB通常通过探测TCP端口来判断后端是否存活。问题在于，端口通不代表示服务正常。比如后端进程假死，端口还开着，请求打过去就一直挂起。建议在4层之上做一个轻量的7层健康检查，比如每隔几秒请求一次接口的健康检查路径，用HTTP 200状态码作为健康标准。别把鸡蛋都放在一个篮子里。

第三是MTU问题。4层隧道模式和GRE、VxLAN等封装方案，都会增加额外的包头长度。如果源站网卡的MTU没有同步调低，就会出现“大包发不过去，小包正常”的诡异现象。表现为业务整体可用，但偶尔有一些大请求超时，排查起来特别费劲。

5.4 从成本和业务价值角度做取舍

最后说一点容易被忽略的：4层和7层CDN的计费模型不同，选型时要把这个纳入考量。

4层加速通常按带宽或流量计费，因为它的主要消耗就是网络资源。7层加速可能按请求数计费，因为每个请求都要经过CPU处理。如果一个业务的请求量很大但每个请求都很小，7层的请求数费用可能高到让人肉疼。遇到这种情况，更合理的方案是静态资源走7层缓存，动态请求走4层链路优化，让每一分成本都花在刀刃上。

我自己经历的几个项目中，比较理想的组合是：动态内容接口走4层加速保障链路质量，同时开启TCP连接复用；静态资源走7层加速做缓存和边缘协议优化，两者分流互不干扰。刚开始可能会觉得维护两套配置麻烦，但跑一段时间后，源站的带宽压力和用户的访问延迟都会有明显改善，这笔账怎么算都划算。

如果想快速验证效果，建议先从7层缓存开始，因为缓存是效果最直观的。登录CDN控制台，把一个静态资源目录的TTL配到24小时，然后在源站日志里看这个目录的请求量变化，通常半小时内就能看到明显下降。4层加速的效果不如缓存那么直观，但它解决的问题——跨网延迟、链路不稳、连接开销——恰恰是那些靠缓存解决不了的部分。两个层级都理解了，你做架构选型时心里会非常有底。