TG咨询当一个服务突然出现大量连接超时、请求排队或新用户无法建立会话时，问题未必来自带宽不足，也可能是连接状态被异常流量快速占满。完善TCP攻击防护，需要同时处理网络入口、操作系统、代理服务和应用连接池，而不是只增加服务器配置。
这类防护的目标，是让正常连接能够继续完成握手和数据传输，让异常连接尽快失效，并为运维人员保留清晰的判断依据。下面以常见的Linux服务器、Apache httpd、HAProxy和Windows IIS场景为例，说明可执行的处理方法。
先区分连接耗尽的几种表现
TCP连接异常通常会呈现不同特征，处理方式也不能混用。半连接数量持续增长，说明连接建立阶段承受压力；已建立连接很多但长期没有有效数据，可能是空闲连接占用资源；单个来源地址以固定节奏建立和关闭连接，则更适合从速率和行为角度限制。
| 观察现象 | 优先检查位置 | 适合的防护方向 |
|---|---|---|
| 新连接大量超时 | 边界设备、监听队列、半连接队列 | 丢弃明显异常的建立请求，启用内核防护机制 |
| 连接数接近上限 | 应用服务、文件描述符、连接池 | 设置并发上限、空闲超时和排队上限 |
| 少数地址持续高频连接 | 访问日志、负载均衡器 | 进行来源速率限制，并保留误判回退方式 |
判断时应把网络设备统计、主机连接状态和应用日志放在同一时间线中观察。单看某一项指标，容易把正常流量增长误认为攻击，也可能忽略真实的连接耗尽。
从四个层面完善TCP攻击防护
一、在边界限制不必要的暴露面
第一步是确认哪些端口真的需要对外提供服务。对外开放的端口越多，越容易出现未维护的监听程序或管理接口。可以使用防火墙规则，仅允许业务所需的TCP端口进入；数据库、消息队列和运维接口则应限制在明确的办公网段、专用网络或经过认证的跳板路径内。
边界规则适合处理明显不应到达主机的流量，但不宜仅靠固定来源地址名单。移动网络、企业出口和代理网络的地址会变化，过度依赖地址封禁可能误伤正常用户。因此，规则应包含记录、过期时间和人工解除机制。
二、调整主机的连接处理能力
Linux系统可以检查监听队列、文件描述符上限、连接跟踪表以及半连接防护选项。内核参数不能脱离业务直接调到最大值：队列扩大只能缓冲短时突发，不能解决持续的恶意连接；文件描述符提高后，也要确认应用和反向代理是否同步支持。
在Windows IIS环境中，应重点查看HTTP.sys队列、站点连接限制、应用程序池回收和空闲超时。修改前先记录原值，并安排在低峰期逐项变更。每次只改一类参数，观察约15至30分钟的连接数、错误率和响应时间，再决定是否继续。
三、让代理和应用主动释放异常连接
HAProxy、Apache httpd等组件通常可以分别设置客户端连接上限、连接建立超时、请求超时和空闲超时。连接建立超时过长，会让大量无效连接长时间占用名额；设置过短，则可能影响高延迟网络中的正常用户。实际值应结合用户分布和业务响应时间调整，常见做法是先用较短的连接建立窗口，再对慢接口单独放宽。
应用层也应限制每个用户、令牌或来源在单位时间内创建连接的数量。对于支付确认、登录验证等关键接口，应使用独立连接池，避免普通查询把全部连接耗尽。数据库连接池的最大值不能简单等同于前端并发数，还要考虑数据库自身的连接上限和事务持续时间。
四、把监控指标变成处置动作
有效的TCP攻击防护必须有可观测性。建议持续记录新建连接速率、当前连接数、半连接数量、监听队列溢出、连接重置、超时比例和各端口分布。日志中应保留时间、端口、协议状态和来源网络等信息，但要遵守隐私和数据留存要求。
- 发现连接数异常上升时，先确认业务发布、营销活动或网络故障是否同时发生。
- 对比多个节点：若只有一台异常，优先检查主机和应用；若所有节点同时异常，再检查公共入口和上游链路。
- 临时收紧高风险端口的访问范围，并降低非关键服务的连接上限。
- 保留变更前后的指标，确认正常用户的成功率没有明显下降。
- 流量恢复后逐步撤销临时规则，避免长期封禁造成业务遗漏。
选择防护方式时要看适用条件
| 方式 | 优点 | 局限 | 适用条件 |
|---|---|---|---|
| 主机防火墙 | 部署直接、成本较低 | 主机已承受部分流量，面对大规模入口压力能力有限 | 端口收敛和小规模异常来源控制 |
| 负载均衡器限流 | 可按端口、来源和连接状态处理 | 配置错误可能影响全部后端 | 存在统一入口且需要集中策略 |
| 应用连接池隔离 | 能保护关键接口和依赖服务 | 不能替代网络层过滤 | 不同业务重要性差异明显 |
| 内核参数优化 | 可改善短时突发下的连接处理 | 无法单独消除持续攻击 | 主机参数已审计并有回滚方案 |
常见问题
只提高服务器配置能解决连接耗尽吗？
通常不能。更高的资源上限可以延后耗尽时间，但异常连接仍可能继续占用队列、文件描述符或应用连接池，必须配合入口限制和超时策略。
是否应该直接封禁所有高频来源？
不建议直接长期封禁。应先确认来源是否属于运营商出口、企业代理或共享网络，并优先采用短时限流、挑战验证或较短封禁周期。
连接超时和服务进程崩溃有什么关系？
大量超时会使连接长期占用资源，进而增加排队和内存压力；但崩溃也可能由程序缺陷或依赖服务故障引起，需要结合进程日志和系统事件判断。
如何验证防护没有误伤正常用户？
在变更后对不同网络、地区和客户端进行连接测试，同时观察成功率、响应时间、重置比例和投诉情况。防护规则应支持快速回滚。
归根结底，TCP攻击防护不是单个参数或设备的名称，而是一套从端口收敛、连接限额、超时释放到监控响应的组合措施。把异常识别和业务优先级结合起来，才能降低连接耗尽带来的服务中断影响。
