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调度，自动接入离自己最近的边缘节点。边缘节点和源站之间，又有