传输优化这四个字,很容易被做成“参数大全”：改内核、开BBR、上QUIC、加专线，但真上线后，收益往往不取决于你改了多少参数，而取决于你卡在哪一段：DNS慢、TCP握手慢、TLS握手慢、丢包降速、回源绕路，还是应用层自己串行请求，先把链路拆开，再决定动哪一层，否则就是拿大炮打蚊子，还容易把稳定性打没。
先拆概念：传输优化到底在优化什么
传输优化不是单一技术,它至少横跨四层：
- 网络层和路由层：用户到边缘节点走哪条路，边缘到源站走哪条路，跨国、跨运营商时，绕路带来的RTT增加，比任何内核参数都致命。
- 传输层：TCP、UDP、QUIC，核心指标是RTT、丢包率、带宽时延积、拥塞窗口，BDP = 带宽 × RTT，长肥管道如果窗口不够，带宽再大也跑不满。
- 安全层：TLS握手、会话复用、0-RTT、证书链，TLS 1.3把握手压到1-RTT，会话复用可以接近0-RTT，但0-RTT有重放风险，不能无脑开。
- 应用层：HTTP/1.1、HTTP/2、HTTP/3、压缩、缓存、分片、连接复用，应用层设计不好，传输层再强也救不了。
一句话：传输优化就是减少不必要的往返、降低丢包影响、提高并发效率，同时控制CPU和成本。
方案对比：别迷信单一银弹
TCP CUBIC vs BBR
传输优化别先调内核，CDN视角下的协议、路由与回源选型
CUBIC是经典拥塞控制,把丢包当拥塞信号，公网轻微丢包时，它容易降窗，导致长肥管道跑不满，BBR则估计瓶颈带宽和最小RTT，减少丢包误判，适合跨国、跨运营商、高丢包场景，但BBR不是万能：它可能抢占其他流量的带宽，公平性和排队延迟要观察，最好用BBR v2或厂商优化版，并灰度上线。
HTTP/2 over TCP vs HTTP/3 over QUIC
HTTP/2解决了HTTP/1.1的队头阻塞，但那是应用层的，底层还是TCP，一个TCP包丢失，所有流都被阻塞，HTTP/3基于QUIC，跑在UDP上，流之间独立，丢包只影响单流；还支持0-RTT恢复、连接迁移，移动弱网体验明显更好，代价是UDP可能被运营商QoS或封锁，CPU开销更高，中间件和可观测性更复杂。
传统DNS调度 vs 智能路由/动态加速 用DNS+GSLB+边缘缓存就够了，动态API、跨国访问、弱网场景，需要边缘节点做四七层代理，结合实时探测、智能选路、回源长连接和多路复用，简单说：静态靠缓存，动态靠路由和连接复用。
公网优化 vs 专线
专线稳定、低丢包，但贵且扩展慢，公网+QUIC+BBR+智能选路，成本低、覆盖广，适合大多数互联网业务，金融交易、实时音视频核心链路，才值得考虑专线或云联网。
适用场景：不同业务，打法不同
静态图片、JS、CSS、视频切片：优先边缘缓存、强缓存、TLS 1.3、HTTP/3、Brotli，回源用长连接、连接池、Range请求，收益最大，改动最小。
动态API、小程序、App接口：重点在连接复用、智能选路、回源多路复用、HTTP/3，别让每次请求都重新握手，边缘节点到源站保持长连接，能省掉大量RTT。
直播、点播：低延迟直播优先QUIC/WebRTC，大并发点播用TCP+BBR+分片缓存，HLS/LL-HLS适合兼容性，但延迟和传输优化要分开看。
跨国、弱网、移动端：QUIC + FEC前向纠错 + 多路径 + 边缘中转，单纯开BBR不够，路由绕路和丢包才是大头。
游戏、实时通信：UDP自定义协议、KCP、QUIC，别硬套HTTP，实时性优先，可靠性按需做。
选型建议：先测量，再分层，后灰度
第一,先量化，看DNS耗时、TCP握手、TLS握手、TTFB、下载速度、卡顿率、回源RTT、各运营商丢包率，没有数据，调参就是玄学。
第二,分层优化，接入层上TLS 1.3、HTTP/3；传输层按场景开BBR；路由层做智能选路；回源层做长连接和多路复用；应用层做缓存、压缩、并发。
第三,灰度验证，按地区、运营商、App版本、用户分桶，QUIC先在小流量开，观察UDP封锁率、CPU、成功率，BBR先在新节点开，对比CUBIC的吞吐和延迟。
第四,注意代价，QUIC吃CPU，0-RTT有重放风险，BBR可能不公平，UDP可能被限速，传输优化不是全量开开关，而是权衡收益、成本和稳定性。
传输优化没有银弹,它是一套从路由、协议、安全到应用的系统工程，先把数据拿出来，找到真正的瓶颈，再选合适的方案，别一上来就改内核，那通常是最不重要的一步。
发表评论