短连接风暴场景下，四层转发能扛住高并发的核心原因是它把数据包在内核态直接转发，不解析HTTP协议，CPU开销比七层代理低一个量级，握手风暴再猛也挤不爆应用层线程池。
短连接风暴是什么感觉？就好比早高峰的地铁闸机，每秒钟涌进来几千个乘客，个个刷票进门就走，不带停顿，正常的闸机也许能处理，但如果每个乘客进门时都要安检、搜身、查身份证，队伍就堵死在门口了，七层转发就是那个安检岗位,四层转发则是只认票不看人的快速通道。
短连接高并发怎么扛？四层转发扛住的底层逻辑
先搞清楚短连接风暴在技术上到底发生了什么
短连接的含义很简单：客户端发起TCP握手，数据传完立刻断开，健康检查、日志上报、指标采集、移动端心跳、投票点赞、秒杀抢购,这些场景全是短连接的大户。
当请求量爆发时，最被动的其实是应用层，连接一多，每建一个TCP连接就要分配一个文件描述符（fd），后端进程就要多一个线程去等待读写，连接来得快走得也快，进程就陷入一个疯狂创建和销毁连接的循环里，CPU被system态占据，频繁的上下文切换把性能拖垮，很多运维把这种状态叫“打满”，实际上不是CPU打满,是内核的连接表被打满了。
四层转发在这种场景下的优势在于，它根本不关心每个连接里传输的应用数据，它只看IP和端口，靠哈希算法决定这包数据去哪个后端，数据全在内核态处理，不走用户态，内存拷贝少,上下文切换几乎为零。
四层转发如何扛住每秒几万的建连请求
关键在于三个机制：
- 内核态转发：SYN包到达LVS或DPDK等四层转发层后，直接在网卡驱动或内核协议栈完成目标地址改写（NAT），把流量原样扔给后端，没有TCP终止的逻辑,转发层自己几乎不占用连接资源。
- 无连接状态：四层转发的连接跟踪表只记录五元组映射（源IP、源端口、目的IP、目的端口、协议），一条记录只占几十字节，一个8GB内存的服务器就能维护上千万条连接映射。
- 同步握手放行：在DR模式或FullNAT模式下，转发层甚至不需要回复SYN-ACK，让后端直接被客户端看到,三层负载可以横向扩展到几十台机器。
所以业内共识认为：四层转发遇到短连接风暴，瓶颈基本不在转发层，而在后端容量和后端内核参数，转发层更像是高速公路收费站，多条收费通道同时放行，车辆不会堵在收费站前，能不能消化车流取决于前方的城市道路（后端）。
短连接风暴场景下四层转发和七层转发区别在哪
七层转发（比如Nginx、HAProxy在HTTP模式）真正的问题出在它必须等完整的HTTP头部解析完，才能决定把请求交给哪个后端，这个过程需要频繁的内存分配、字符串解析、哈希查找和请求上下文管理,单条连接占用的CPU资源是四层转发的几十倍。
| 对比维度 | 四层转发（LVS/DPDK） | 七层转发（Nginx/HAProxy） |
|---|---|---|
| 工作层次 | 传输层（IP+端口） | 应用层（HTTP头/URL/Cookie） |
| 转发速度 | 内核态/网卡直转，微秒级 | 用户态解析，毫秒级 |
| 单机并发能力 | 数百万连接 | 数万到十几万连接 |
| 是否需要结束TCP连接 | 不需要 | 需要与客户端建立连接 |
| 短连接风暴表现 | CPU稳定，转发不掉速 | CPU飙升，连接池迅速占满 |
| 运维成本 | 配置简单，黑白名单能力弱 | 路由规则灵活，可做限流 |
关键分水岭在于：当连接生命周期极短（几十到几百毫秒），且请求量超过每秒几万次，七层转发就开始出现明显的accept队列溢出和TIME_WAIT堆积。 业内专家指出，高并发秒杀等场景中，Nginx前置的架构经常要先在Nginx前面加一层LVS或F5,才能把每秒几十万的建连请求削峰成后端的可控流量。
四层转发在短连接场景的适用边界
四层转发虽然快，但不是万能的，它看不到URL，做不了业务路由，也做不了细粒度的限流，如果业务需要按用户身份、设备类型、城市归属做流量划分，四层转发就无法满足，还有HTTPS场景，如果想做SSL卸载，四层转发做不到,必须把证书完整的终止能力放在七层。
短连接风暴中最怕要配Cookie保持或Session一致性的场景，因为四层转发只看IP，如果客户端IP变化，或者使用了NAT网关，就可能出现同一个用户被分配到不同后端的情况，此时要在后端加一层分布式缓存，或者全局一致性哈希,保证状态不丢。
短连接风暴如何应对？四层转发的落地实操清单
第一步：转发层的选型和部署模式
业界目前主要用三种四层方案：LVS（Linux Virtual Server）、DPDK（数据面开发套件） 和 云厂商的负载均衡SLB。
- LVS最成熟，部署简单，用keepalived做高可用即可，配置示例：配置一个VIP，两台LVS机器做心跳，后端RS（Real Server）把VIP绑在lo接口上,DR模式下RS直接回包给客户端。
- DPDK把网卡收包转发绕过了Linux内核的锁竞争，CPU能跑到满，适合极致的性能要求，但DPDK会占用整块网卡和对应CPU核,部署上要考虑隔离和运维成本。
- 云厂商SLB的优点是免运维，专属集群性能极高，短连接风暴场景下通过加带宽和并发连接数规格就能扛住，缺点是可控性弱,无法自定义转发逻辑。
第二步：内核参数必须跟着调
四层转发扛住了连接建立，后端的accept队列就成了新的瓶颈。SYN队列（半连接队列）和accept队列（全连接队列）的默认值太小，是短连接风暴中最常见的丢包原因。
必须调整的一组参数（建议写入/etc/sysctl.conf）：
- net.ipv4.tcp_max_syn_backlog = 65535（SYN队列容量,太低会导致SYN丢弃）
- net.core.somaxconn = 65535（全连接队列容量,Nginx和Java的backlog参数要与此对应）
- net.ipv4.ip_local_port_range = 1024 65535（扩大本地自动分配的端口范围）
- net.ipv4.tcp_tw_reuse = 1（基于时间戳的TCP连接复用,减少TIME_WAIT瓶颈）
- net.ipv4.tcp_fin_timeout = 15（缩短FIN_WAIT_2状态的等待时间）
socket监听的backlog参数也要对应调大，如果用的是Java，ServerSocket的backlog默认50，必须显式设置，如果是Tomcat或Spring Boot，要在配置里写server.tomcat.accept-count=10000，否则全连接队列溢出后客户端表现为建立时偶发超时,高并发下非常诡异。
第三步：压测验证转发层的真实极限
不要等线上打挂了再救火，用wrk或ab做压测时，注意压测的并发连接数要模拟短连接风暴的队形：一次压大量瞬时连接，而不是均匀递增的请求率。
压测命令参考（wrk每线程有独立连接池）：
- 压测短连接：wrk -t8 -c10000 -d60s –latency http://VIP:8080/
- 监控转发层：sar -n DEV 1 观察网卡PPS；mpstat -P ALL 1 观察CPU是否被软中断打满
- 监控后端关键指标：ss -lnt 看Recv-Q和Send-Q队列长度，如果Recv-Q持续大于0说明accept队列已经堵塞
压测出来的准确QPS数据就是扩容和容量规划的基准，如果压测时发现后端CPU没有跑满但accept丢包，说明syn backlog和somaxconn调的还不够,继续调大再压。
哪些场景下四层转发也扛不住短连接风暴
后端处理能力才是终局瓶颈
四层转发能卸载连接建立的负担，但每次请求的业务计算仍然要后端承担，如果后端的每个请求要查三次数据库、调两个外部接口，单机吞吐就是几百QPS，无论前面加多少层LVS,风暴来了一样会把数据库连接池打满。
行业共识是：四层转发解决的是连接数的问题，不是业务处理能力的问题。 后端必须配合服务降级、异步化、缓存穿透保护等手段,才能整体扛住。
DPDK的高性能反而可能引发新问题
DPDK方案在转发层速度极快，但它把CPU核心绑定到轮询收包任务时，如果后端响应不过来，会导致转发层继续快速把请求丢给后端，造成后端过载雪崩，必须在转发层加一个简单的速率限制，比如DPDK的ACL表限制后端最大并发数,或配套使用限流组件。
还有一种场景：两个不同地域的机房互相调用且走的专线带宽有限，四层转发出口的带宽会成为新的瓶颈，短连接虽小，但SYN/ACK/RST包的报文开销接近满包，容易被PPS（每秒包数）瓶颈卡住，而不是BPS（每秒比特数）瓶颈，监控上要多留意PPS指标,建议在核心交换机做sFlow采样观察。
短连接风暴不是你死我活的战争，而是容量规划和技术选型的产物。四层转发用极低的成本把连接建立的洪峰挡在前面，后端再专心地处理业务逻辑，这是目前短连接高并发场景下的最佳组合打法。 先上四层，再看内核，最后削后端，三步走完,高并发短连接风暴基本可控。
Q&A：短连接高并发场景常见的三个疑问
Q：四层转发加七层转发一起使用，网络链路会拖慢响应吗？
A：会有一点多跳延迟，但通常只在微秒到毫秒级，LVS把流量先均衡到Nginx集群（七层），Nginx再转发到具体业务节点，这种两级结构是十多年前大规模门户网站的标准架构，延迟增加小于1ms，相比请求处理的时间可以忽略不计，实际业务对RT敏感的，建议优先用七层做最终路由,四层只负责第一级入口集群的流量分发。
Q：LVS的DR模式和TUN模式在短连接场景下选哪个？
A：DR模式要求后端物理机和LVS在同一二层网络，但性能最好，数据包入口和出口都直接与VIP交互，转发层只有入口流量，TUN模式通过IPIP隧道封装包，可以跨网段，但封包拆包有额外CPU开销，同机房内部署，选DR模式；多机房异地容灾，选TUN模式，云环境里用FullNAT,它解决的是后端无法绑定VIP的问题。
Q：四层转发扛住压力后，后端单机需要多少连接数才算合理？
A：单机并发连接数的合理值取决于连接的平均时长和业务复杂度，短连接场景下，后端最关心的是每秒能建立多少连接（CPS），而不是同时保持多少连接（并发），一个合理的参考是压测调优后，单机CPS能到两三万且CPU维持在70%以下，就可以放心交给LVS继续调度流量，后端出现大量CLOSE_WAIT连接时，往往是业务代码没有及时关闭Socket导致的，加重了连接表负担，此时调整四层参数无效,要排查应用代码。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/633700.html
