四层转发之所以通常比七层转发性能更突出，是因为它只处理到传输层的TCP/UDP数据包头，由操作系统内核直接完成数据转发，而七层转发还要拆开应用层报文做内容解析，多干了很多“脑力活”，自然更费时费力，这个结论在绝大多数负载均衡和代理场景下都成立，但选型时还得看具体业务需求。
先搞懂四层转发和七层转发各自在忙什么
要理解性能差距，先得确认两者工作位置和职责边界，四层转发和七层转发指的是OSI模型里不同的层,对应的设备或软件决策依据完全不同。
四层转发的工作边界
四层转发主要看TCP或UDP报文头里的四元组：源IP、源端口、目的IP、目的端口，它不关心数据里装的是HTTP还是HTTPS，也不管URL路径、Cookie、请求头这些内容。
- 内核收到数据包后，直接根据规则查表,把包从入口网卡搬到出口网卡。
- 典型的四层转发设备：LVS、F5的LTM（四层部分）、Nginx的stream模块、HAProxy的tcp模式。
七层转发的工作边界
七层转发工作在应用层，以HTTP/HTTPS为例，它必须先完整接收请求报文，然后解析请求行、请求头、请求体，才能根据URL、域名、Header、甚至Post参数来决策。
- 需要做TLS终止（如果是HTTPS）,做加解密运算。
- 需要维护会话状态，比如Cookie、Session。
- 典型的七层转发设备：Nginx的http模块、HAProxy的http模式、各类API网关。
| 对比维度 | 四层转发 | 七层转发 |
|---|---|---|
| 工作层级 | 传输层（TCP/UDP） | 应用层（HTTP/HTTPS等） |
| 处理依据 | IP+端口 | URL、Header、Cookie、Body |
| 数据包操作 | 直接转发 | 解包、重组、再封装 |
| 资源消耗 | 低 | 较高 |
| 支持高级路由 | 不支持 | 支持 |
行业共识认为，四层转发在吞吐量和并发处理能力上通常高出七层一个量级，尤其在数据包较小、连接数巨大的场景下差距更明显。
四层转发性能碾压七层的三个底层逻辑
同样是转发数据，为什么四层能快这么多？拆开来看,主要是这三件事让七层吃了亏。
第一，数据路径更短，内核直接搬砖
四层转发模式下，数据包进入内核后，经过的协议栈路径非常短，如果是LVS的DR模式或NAT模式，内核只需要修改MAC地址或IP地址，然后重新计算校验和，就能把包丢出去,整个过程甚至不需要把数据拷贝到用户态。
七层转发则不然，Nginx处理HTTP请求时，数据要从内核缓冲区拷贝到应用程序内存，应用解析完逻辑后，还要再组织新的HTTP响应，再拷贝回内核发送，一次请求至少多两次内存拷贝，数据量越大，次数越多,性能劣化越明显。
第二，无状态解析，CPU省下大量指令
四层转发不关心连接里跑的是什么协议，它只维护一张连接跟踪表，记录谁和谁在通信，然后按固定规则转发，CPU执行的是简单的查表和改包头操作,指令周期很短。
七层转发需要对每一个请求做结构化解析，比如HTTP协议，需要按空格和冒号拆分请求行、请求头，做字符串匹配，处理各种边界情况，一个看似简单的Location匹配，背后是一连串的正则或前缀匹配运算，这些都要消耗CPU和内存带宽，在同样一台服务器上跑,七层能处理的请求数往往只有四层的几分之一。
第三，内存拷贝少，缓存命中更高
四层转发可以做到零拷贝转发，尤其配合DPDK或XDP这类技术，网卡直接把数据通过DMA写入预先分配的内存池，处理完再直接发出去，全程绕开内核协议栈,甚至能从物理层面跳过CPU主干运算。
即使不用DPDK，传统内核模式下四层转发对缓存也更友好，因为处理逻辑固定，热点数据（比如转发规则表）很容易留在L2/L3缓存里，七层转发则频繁操作字符串和动态内存，缓存命中率低，频繁访问主存,进一步拉大延迟差距。
业内专家指出，在相同硬件条件下，四层转发通常能达到七层转发2到5倍的并发连接处理能力，而单请求延迟时间可以低一个数量级，具体数字取决于产品实现和测试方法,但趋势非常稳定。
四层转发和七层转发选型怎么选？别被性能一叶障目
虽然四层性能占优，但绝大多数业务最终用的还是七层，因为灵活性太重要，所以四层转发和七层转发的选型对比，核心不是比谁强,而是看谁更匹配你的场景。
纯性能场景：四层是绝对主角
如果你的业务是视频流、游戏对战、私有RPC协议、数据库连接池代理，这类流量对延迟极其敏感，且不依赖HTTP语义,直接用四层转发。
- 典型场景：直播弹幕网关、游戏长连接代理、MySQL读写分离中间件前置入口。
- 推荐技术：LVS、DPDK、Nginx Stream模块、HAProxy TCP模式。
- 关键指标：并发连接数、新建连接速率、转发吞吐量。
业务路由场景：七层的灵活不可替代
需要按域名或路径分发流量、做灰度发布、实现限流熔断、统一鉴权、改造请求响应头，这些操作只能七层才能完成，这是七层转发价格高于四层的根本原因它不只是转发，而是“懂事”的路由器。
- 典型场景：微服务API网关、网站静态资源与动态接口分离、A/B测试流量切分。
- 推荐技术：Nginx、Apache APISIX、Spring Cloud Gateway。
- 关键决策点：业务方是否需要看到HTTP报文内容？
同机房混部场景：四层+七层组合拳
很多大型部署采用两级架构，最外层用四层转发扛海量连接和流量清洗，把请求分发给内网的七层网关，再由七层做精细路由，这样既保住了入口性能,又拿到了应用层的灵活度。
- 第一级：LVS或Nginx Stream做四层流量分发。
- 第二级：Nginx或网关集群做七层业务路由和策略执行。
- 成本与收益：多一层链路，会多一跳网络开销,但整体吞吐能力和业务扩展性反而更好。
实测调优：让四层转发性能再往前一步
如果你的负载均衡已经决定用四层，还能通过一系列操作把性能逼到极限,下面是几个可验证的实战路径。
修改Linux内核参数
四层转发性能瓶颈常出现在连接跟踪表、文件句柄、落网卡队列上,按顺序调这三个参数。
- 调整最大文件描述符：
- 编辑
/etc/security/limits.conf，设置nofile软硬限制。
- 编辑
- 扩大TCP连接跟踪表：
- 使用
sysctl -w net.netfilter.nf_conntrack_max=262144临时生效。 - 永久修改：在
/etc/sysctl.conf增加配置后执行
sysctl -p
- 使用
- 开启网卡多队列：
关闭irqbalance,手动绑定中断到不同CPU核心。
使用DPDK或XDP绕过内核
如果业务体量极大，比如单机每秒处理百万级并发连接，传统内核协议栈会成为瓶颈，这时考虑DPDK（用户态驱动）或XDP（内核旁路）方案，DPDK需要独占网卡和CPU核心，业务代码要单独适配；XDP则更轻量,直接在网卡驱动层过滤转发。
压测工具与验证
用wrk或hping3压测四层转发，主要关注两个指标：新建连接速率和并发连接容量，压测时注意压测机本身不能成为瓶颈，建议用多台机器同时打流量,观察代理节点的CPU占用率和网卡丢包率。
- 如果CPU占用率低但吞吐上不去,检查网卡中断是否均衡。
- 如果并发上不去，优先看
ss -s命令输出的连接状态统计和内存占用。
四层转发性能更突出，本质是“少做事”带来的红利，但高性能只是手段，不是目的，实际架构中，四层和七层各司其职，反而能把性能与灵活性同时拉满。搞清楚你的流量到底需不需要应用层智慧，再决定让哪一层去扛，这才是最划算的选择。
四层转发和七层转发哪个性能好？常见问题
四层转发能处理HTTPS流量吗？
能，四层转发直接转发TCP加密流，它不需要解密，只需要把连接的包原样送到后端，由后端服务器完成TLS加解密，这样网关无法对HTTPS报文内容做缓存或路由,但吞吐性能很好。
Nginx的stream模块和http模块性能差距有多大？
stream模块属于典型四层转发，http模块属于七层转发，在相同硬件和请求体量下，stream模块的并发处理能力和吞吐量通常明显高于http模块，因为stream模块只做TCP流透传，不解析应用数据，实际差距受请求大小和URI复杂度影响，无法给出固定倍数，但趋势是流越大、请求越简单,差距越夸张。
四层转发没有丢失了吗？
不是，四层转发仍是大型互联网架构的基石，七层网关处理不了海量连接时不代表没用，只是不适合，最有效的方案是把四层放在最前面扛流量，七层在前面做精细化控制,后者在公网攻击防护场景下还承担了拒绝服务包清洗任务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/635400.html
