高防CDN的清洗能力保护源站不被攻击流量打穿，但清洗之后，合法请求仍然需要回源到源站。如果回源链路的连接管理不当，源站可能被"自己人"的并发连接压垮——大量正常用户的请求同时建立新的TCP连接，源站的连接表被迅速占满。
本文拆解高防CDN回源链路中的TCP连接复用机制，说明它如何降低源站的并发压力。
一、源站被"自己人"压垮的典型场景
攻击期间，清洗中心过滤了恶意流量，正常用户的请求被放行回源。但如果回源链路是"每个请求新建一个TCP连接"的模式，会出现一个悖论：攻击被拦住了，但源站因为正常用户的回源请求过载而宕机。
典型场景是缓存击穿。某个热门页面或接口的缓存刚好过期，大量用户同时请求这个资源。如果边缘节点没有请求合并机制，每个用户请求都会触发一次回源，源站在短时间内收到数百甚至数千个并发连接。这种并发压力与攻击流量在传输层造成的连接耗尽效果类似，但来源是合法用户。这与高防CDN清洗中心架构中提到的回源转发环节直接相关——回源优化是清洗链路的最后一道关卡。
二、TCP连接复用：把"每次新建"变成"重复使用"
TCP连接复用的核心逻辑是：边缘节点与源站之间维护一个长连接池，用户的请求到达边缘节点后，复用池中已有的连接回源，而不是为每个请求新建连接。
连接复用的收益可以从两个维度衡量。第一是握手开销的节省：TCP三次握手加TLS握手通常需要2–3个RTT，在跨地域回源场景下可能消耗几十毫秒。复用连接后，这个开销被分摊到连接的生命周期中，不再每次请求都发生。第二是源站并发连接数的降低：假设源站最多支持1000个并发连接，如果每个用户请求都新建连接，1000个并发用户就会占满源站连接表；如果采用连接复用，边缘节点可能只需要维护几十个到源站的连接，就能支撑数千个用户请求。
连接复用的实现需要注意两个细节。第一，连接池的健康检查：长时间空闲的连接可能已被源站或中间设备关闭，边缘节点需要定期探测连接状态，避免复用已失效的连接导致请求失败。第二，连接池的容量控制：每个边缘节点维护的连接池大小需要根据源站的承载能力和业务流量特征动态调整，池太小会导致请求排队，池太大会给源站造成不必要的连接压力。
三、请求合并：缓存击穿场景下的关键机制
连接复用解决的是"连接开销"问题，请求合并解决的是"并发回源"问题。两者是不同层面的优化。
请求合并的逻辑是：当边缘节点收到多个用户对同一资源的请求，而该资源恰好未命中缓存时，边缘节点只向源站发起一次回源请求，其余请求等待这次回源的结果，然后复用同一份响应。
这个机制对缓存击穿场景尤其重要。以电商大促为例，某个商品详情页的缓存刚好过期，同时有500个用户访问这个页面。如果没有请求合并，边缘节点会向源站发起500次回源请求；有请求合并后，只发起1次回源，其余499个请求等待并复用结果。源站的并发压力从500降到1。
请求合并的实现需要处理一个边界情况：如果回源请求失败或超时，等待的请求需要得到明确的错误响应，而不是无限等待。因此，请求合并机制通常需要配合超时控制和降级策略。
四、长连接保持：WebSocket与游戏协议场景的优化
对于WebSocket长连接业务（实时协作、游戏对战、直播弹幕），连接复用的逻辑与HTTP短连接有所不同。长连接本身就是持续保持的，不需要"复用"，但需要连接保持——边缘节点维护玩家到源站的连接，并在连接中断时快速重建。
长连接场景下的优化重点是连接迁移。当某个边缘节点出现故障或需要维护时，玩家连接需要迁移到其他节点，同时保持会话状态不丢失。这与高防CDN节点调度与近源清洗中提到的节点间调度机制是配套的——调度切换时，长连接需要平滑迁移，避免玩家掉线。
| 机制 | 解决的问题 | 适用场景 | 关键实现细节 |
|---|---|---|---|
| TCP连接复用 | 减少握手开销，降低源站并发连接数 | HTTP短连接、API调用 | 连接池健康检查、容量控制 |
| 请求合并 | 避免缓存击穿，减少并发回源 | 热门资源、缓存过期场景 | 超时控制、降级策略 |
| 长连接保持 | 维持会话状态，支持实时通信 | WebSocket、游戏协议 | 连接迁移、会话保持 |
五、结语
高防CDN的保护目标不只是"攻击流量不进入源站"，还包括"合法流量的回源不给源站造成过载"。TCP连接复用减少握手开销和连接数，请求合并避免缓存击穿，长连接保持支持实时通信场景。这三种机制协同工作，才能让源站在攻击期间和攻击之外都保持健康水位。评估时需要确认服务商是否支持连接池管理、请求合并和长连接迁移，这些能力比"回源带宽是多少"更能说明回源链路的优化水平。
