传输层防护通过滑动窗口限速和半连接队列限并发双管齐下，相当于给服务器装了一个智能门卫既能控制单位时间进门的客流，也能限制同时滞留在大厅的人数，哪个环节失控，另一个机制都能兜底。
传输层连接的本质：一场关于接待能力的博弈
TCP三次握手就像访客按门铃、主人开门、访客确认身份的过程，每一台服务器的接待能力有物理上限：内核协议栈维护的tcp_max_syn_backlog决定等候区能站多少人，net.core.somaxconn决定正式会客室能坐多少人，而每个socket的接收缓冲区大小决定每分钟能端多少杯茶。
攻击者恰恰喜欢在这个环节做文章,SYN Flood伪造不存在的访客地址，把等候区塞满；连接耗尽攻击则假装真心做客，握手成功后赖着不走，占住会客室的椅子，传输层防护的价值就在于此它不关心业务逻辑，只盯住三个数字：每秒新建连接数、并发连接总数、单连接存活时长。
限速的核心机制：令牌桶算法怎么当门卫
业内常用的限速手段是令牌桶算法,服务器按固定速率往桶里放令牌，每个新连接必须抢到一枚令牌才能进门，桶的容量决定瞬时能放多少连接进来，令牌生成速率决定长期稳定的吞吐量。
实际配置中需要关注三个参数：
- burst size：桶的容量，表示突发流量容忍度，设太大等于没限，设太小会误伤正常用户，建议取正常峰值的1.5到2倍
- rate limit：令牌补充速率，按业务特性调整，Web服务建议每秒允许500到2000个新连接，视频流媒体可以放宽到每秒5000
- 超时惩罚：抢不到令牌的IP进入观察名单，后续连接直接丢弃或延迟响应，而不是让客户端无限重试
iptables的hashlimit模块可以落地这套逻辑,比如限制每个源IP每秒最多发起10个新连接：
iptables -A INPUT -p tcp --syn -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name syn_limit -j REJECT这条规则允许短时突发20个连接,但长期速率被压在每秒10个以内，对付扫段攻击，还可以加上--hashlimit-mode srcip,dstport，让每个源IP对同一端口单独计数。
限制并发的三道防线：从握手到挥手全过程管控
第一道防线：半连接队列的防御价值
SYN队列长度是内核参数net.ipv4.tcp_max_syn_backlog，当攻击者只做第一次握手就消失时，这些半连接会占住队列直到超时，核心调整思路是：缩短半连接的等待时间，而不是一味加大队列。
推荐配置组合：
tcp_synack_retries = 1，减少SYN-ACK重传次数，让无效条目快速过期tcp_max_syn_backlog = 1024，小队列配合快速回收，比大队列更抗冲击- 开启
tcp_syncookies = 1，极端情况下让服务器无视队列限制，直接根据cookie信息确认连接合法性
第二道防线：全连接队列的配额管理
握手成功后的连接会进入accept队列,由net.core.somaxconn控制总容量，这里需要结合业务侧改造，单纯调参数容易顾此失彼：
- Nginx的
worker_connections指令限制每进程最大连接数，建议按内存大小估算，每1GB内存对应约2万连接 - 配置
limit_conn_zone模块，对单个IP的并发连接设配额，比如limit_conn addr 100; - 后端服务开启连接复用,HTTP/2的multiplexing能让一条TCP连接承载几十个请求，大幅压缩并发占用
第三道防线：应用层主动断连
对于已经建立的慢连接攻击,传输层需要配合应用层做主动清理，以Linux服务器为例：
- 通过
ss -s查看当前TCP连接状态分布 - 找出
ESTABLISHED状态但长时间无数据传输的连接 - 用
ss -s统计各状态连接数，结合netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr找出TOP连接来源 - 对异常IP执行
tcpkill或通过防火墙断连
行业共识认为,单纯依赖某一层防护效果有限，传输层参数调优必须配合7层应用的能力才能形成闭环。
传输层防护方案怎么选？自建规则与高防IP的取舍
防护效果好不好,要看攻击流量打到哪一层，如果是百G级别的SYN Flood，机房入口的流量清洗设备才是主力；如果只是小规模扫描和慢连接骚扰，服务器自身参数调整就能搞定。
| 方案 | 适用场景 | 限速精度 | 运维成本 |
|---|---|---|---|
| iptables+内核参数 | 中小站点，防护百兆级攻击 | 高，规则可细分到每个IP | 需自行调优测试 |
| 云厂商安全组 | 云服务器基础防护 | 中，通常只支持IP黑白名单 | 无需额外部署 |
| 高防IP | 大型活动、游戏发布，防护G级攻击 | 中高，可在清洗节点限速 | 付费接入，配置简单 |
自建方案的优势在于成本可控、规则灵活，但有个容易被忽略的坑：云服务器的安全组可能抢在iptables之前丢弃流量，你在系统内配的限速规则根本看不到攻击流量，购买高防IP时，咨询服务商能否在清洗节点直接限速源IP的连接速率，这比流量转发到服务器再做限制要高效得多。
具体选型时,先压测确认业务正常流量模型：每秒新建连接数峰值、活动连接数峰值、单连接平均时长，这三个数值决定所有限速阈值的基准线，阈值设成正常值的2倍比较稳妥，既能容忍业务抖动，又能卡死绝大多数异常流量。
传输层防护配置查漏补缺：三个容易踩的坑
第一个坑：NAT环境下的源IP误判。 公司内网几十人共用公网出口IP，按单个IP限速10连接每秒，正常办公都会触发拦截，解决办法是在限速规则里加上--hashlimit-mode srcip,dstip，让源IP和目的IP的组合作为计数单位，内网用户访问不同服务器时各自独立计数。
第二个坑：UDP洪泛被忽视。 很多人把传输层防护等同于TCP防护，实际上UDP的反射放大攻击同样需要速率限制，对于业务不用的UDP端口直接丢弃，对于DNS、NTP等必要UDP服务，用quota模块限制每IP每秒的包数量。
第三个坑：带宽耗尽型攻击。 速率和并发限制解决的是连接建立问题，攻击者照样可以把流量带宽打满，这时候需要上行限速配合，在云控制台把服务器的出方向带宽峰值设一个上限，避免因单台机器被打满而牵连同物理机上的其他租户。
常见问题速查
传输层限速和七层WAF的限速有什么区别？
传输层限速在TCP/UDP协议栈层面工作，只根据IP、端口、连接状态做粗粒度过滤，处理能力强但看不到请求内容，WAF在HTTP层工作，能识别URL路径、请求参数等业务特征，可以做精细拦截但性能消耗大，正常架构是传输层先把明显的攻击流量挡掉，剩下的可疑请求再交给WAF分析。
服务器配置了连接数限制，但攻击一来CPU还是飙升，怎么排查？
先看是软中断消耗还是内核锁竞争,执行top查看si列占用，如果软中断高，说明数据包收发路径有问题，考虑开启RPS（Receive Packet Steering）把中断分散到多核，如果是单核满载，多半是conntrack表冲突，调大nf_conntrack_buckets并开启nf_conntrack_acct做精细化统计，限速规则本身有性能开销，iptables规则条数尽量控制在200条以内。
高防IP的传输层防护和源站防护如何配合？
高防IP承担流量清洗,源站保留基础限制作为纵深防御，高防IP上设置每秒新建连接阈值和并发连接阈值，源站iptables规则的阈值调整到高防IP的1/5左右，确保漏网流量到达源站时已经被削减到可控范围，注意高防IP回源时隐藏源站IP，否则攻击者绕过防护直打源站，一切配置都失去意义。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787266.html
