4.2 传输与应用层加速

4.2 传输与应用层加速

上一节修好了丢包与抖动，本节处理吞吐问题：为什么同一条链路，下载能跑满、业务系统却慢得像断线。承上：4.1 解决"包能不能到"，本节解决"到得快不快、连接效率高不高"。启下：4.3 节的应用识别决定加速策略施加给谁。读完本节，你应当能判断一条慢链路的病根在窗口还是应用，并说清加速手段各自的适用边界。

TCP 在广域网上吃亏的根源

TCP 的吞吐受一个朴素公式约束：吞吐 ≈ 窗口大小 ÷ 往返时延。窗口（发送端在收到确认前最多能发多少数据）有上限，往返时延越大，每秒能"倒手"的次数越少。算一笔账：窗口 4 MB、往返时延 200 毫秒，单连接理论吞吐上限约 160 Mbps；窗口若被收到 4 MB 上限，再宽的管道也灌不满。更糟的是丢包反应：传统 TCP 一遇丢包就把窗口砍半，广域网 1% 的本底丢包足以让窗口常年爬不起来——这就是"链路宽、应用慢"的机制性原因，与带宽采购无关。

对策一：窗口与拥塞算法调优

最便宜的招是调参：在两端系统上放大 TCP 窗口上限、换更耐丢包的拥塞控制算法（如基于带宽时延测量的 BBR 类，对随机丢包的容忍远好于传统算法）。这招零带宽开销，但要求你能动两端系统——分支终端与云上服务往往都不归网络团队管，落地受限。

对策二：TCP 代理拆分连接

SD-WAN 边缘的标准解法是代理拆分：把端到端的一条 TCP 连接拆成三段——客户端到本侧边缘（局域网质量，时延极小）、边缘到对侧边缘（走优化的广域隧道）、对侧边缘到服务器（又是局域网质量）。每段独立跑自己的窗口与重传，广域段用激进的窗口策略与本地快速重传，丢包不再传回真正的发送端。终端与服务器的系统一个字节都不用改，这就是代理方案在广域网场景流行的原因。

代理的适用边界同样要写进方案：流量必须对称地经过两侧边缘才可拆分——分支机构到总部的流量天然满足，分支直连公有云 SaaS 的流量只有单侧边缘，无法拆分（这类流量靠 1.2 节的就近分流解决，路径短了本来也不太需要拆）。此外代理维护连接状态，高并发会话消耗边缘内存，配置时按会话数规划。

加速技术对照与取舍

数据去重值得一提：备份与镜像类流量重复度极高，边缘把数据切块记指纹，重复块只传指纹不传数据，广域带宽可以省出数倍。但两个前提常被忽略：流量必须可解密（TLS 流量要在边缘终结证书才能看到内容，带来合规与密钥管理问题）；去重的缓存与指纹计算吃 CPU，小规格边缘设备上开启要测吞吐。

一条链路的诊断顺序

把本章与第 3 章串成一条诊断路径，遇到"分支访问慢"按序执行：

第一步：看 3.2 体检单——该方向各链路的时延/抖动/丢包是否达标？
  ├─ 不达标且有备选链路 → 3.3 选路切换，观察是否恢复
  ├─ 不达标且无备选 → 4.1 开纠错（UDP实时流）或评估换路
  └─ 达标但应用仍慢 → 进入传输层诊断
第二步：传输层——单连接吞吐 vs 链路带宽的比值
  ├─ 比值低（跑不满）→ 窗口受限：查 RTT 与窗口，评估代理拆分
  └─ 大量小往返（应用层慢）→ 协议行为：查应用往返次数，考虑协议优化或就近部署
第三步：记录处置与效果入库存档，回填 SLA 阈值基线
​

这条路径的价值在于可复制：同样的症状不再依赖个人经验猜，而是按指标走分支。第 6 章的可见性平台会把这套诊断流程固化成一键式的工作流。

一次吞吐诊断的完整记录

把第二节末尾的诊断路径走成实例。症状：某分支访问总部文件服务器，拷贝大文件只有 8 Mbps，而该分支宽带标称 200 Mbps。第一层（链路体检单）：分支到总部隧道时延 42 毫秒、丢包 0.2%、带宽余量充足——链路无罪。第二层（传输层）：单连接吞吐 8 Mbps 对照链路能力严重跑不满，典型窗口受限特征。计算验证：标准配置的 TCP 窗口在 42 毫秒往返下理论吞吐约 30 至 70 Mbps（取决于窗口上限与丢包反应），再叠加文件协议的小块读写，8 Mbps 合理但不该是终点。处置：对该方向的 TCP 流量启用边缘代理拆分（两端边缘都有部署，条件满足），并在文件服务器侧核对网卡与共享配置。结果：拆分后单流吞吐升至 65 Mbps，受文件协议块大小限制无法跑满 200 Mbps，但业务感知从"几分钟"缩到"几十秒"，投诉关闭。留档：本方向 TCP 吞吐基线从 8 Mbps 更新为 65 Mbps，写入该分支的体检档案。

这个记录示范了诊断报告的正确格式：每一步有测量数字、有判据、处置有前后对比、结论入档。第 6 章的可见性平台要自动化的正是这条格式。

问题：加速功能会不会与加密冲突？

会，这是部署加速时最常见的技术纠纷。代理拆分与去重都需要"看到"流量内容，而业务流量正越来越多地被应用层自身加密（HTTPS、加密的文件传输协议）。可选的解法按侵入度排序：在边缘终结 TLS（边缘持有证书做中间人，安全性争议大、需企业统一管控终端信任）、应用层网关配合（对自有业务系统部署边缘可解密的协议）、或放弃内容级加速只做传输级优化（代理拆分不需要看内容，只优化 TCP 行为，兼容加密流量）。实践中多数企业选择最后一种：加速交给传输层，内容安全交给专用设施，两条线不打架。

本节要点

• 吞吐公式"窗口除以往返时延"解释了高时延链路跑不满的机制；丢包砍窗口雪上加霜。
• 调参最便宜但受权限约束；代理拆分对终端透明，但要求流量双侧过边缘。
• 去重压缩对备份类流量收益巨大，前提是可解密且 CPU 够用。
• 诊断按固定顺序：先体检单选路，再传输层窗口，最后应用协议——每步有判据，不靠猜。

再补一条优先级建议：与 4.1 节的纠错相比，本章的加速手段落地成本更高（代理要双侧、去重要解密），所以排期上"先纠错后加速"——先把实时流的体验底线守住，再追批量流的吞吐上限。多数项目做对这一条，就能用最低的复杂度拿到八成的体验收益。

传输层的加速讲完，下一节进入最贴近业务的补课手段：把应用认出来，把带宽排给最重要的它。