网络层面的延迟优化：DNS解析、TCP连接复用、HTTP/2与HTTP/3协议选择
水印接口的响应延迟，很多时候卡在网络链路上。你想想看，用户从点击到看到水印，最多也就几百毫秒的容忍窗口。DNS解析慢个100ms，TCP握手再慢个100ms，还没开始传数据呢，200ms就没了。这一章咱们就来抠这些“沉默的延迟”。
核心思路：网络优化不是改协议版本那么简单。DNS、TCP、HTTP协议这三层，每一层都有独立的优化空间。我习惯从“最上游”开始排查——先管DNS，再管连接，最后管协议。
1. DNS解析——被忽视的第一跳延迟
DNS解析就像查电话簿。每次请求一个域名，浏览器都得先去DNS服务器问：“xxx.com的IP是多少？”这个过程少则几毫秒，多则几百毫秒。我遇到过最夸张的一次，一个视频水印接口由于DNS解析超时，首次请求延迟飙到了1.2秒。排查了半天，发现是权威DNS服务商节点挂了。
怎么优化？
- DNS预解析：在HTML里加
<link rel="dns-prefetch" href="//cdn.example.com">，让浏览器提前查。对于API域名，也可以用preconnect指令，不仅解析DNS，还能提前建立TCP连接。 - 长TTL缓存：把域名TTL设到600秒以上。别设成30秒，那等于让每次请求都重新解析。当然，如果你要频繁切换CDN节点，那可以折中设个300秒。
- 多地域DNS分流：用GeoDNS把用户解析到最近的同城节点。比如华东用户靠近上海，华南靠近广州。我见过有些项目全球统一解析香港节点，结果北美用户延迟暴增。
- CDN内化DNS：很多CDN厂商自带智能DNS，但你得主动开启“CNAME加速”或“A记录就近解析”。默认配置有时会绕路。
一个小技巧：可以在业务代码里用performance.getEntriesByType('resource')查看每个资源的DNS耗时。如果发现某个域名解析超过50ms，就该考虑预解析了。
2. TCP连接复用——别再握一次手就分手
TCP三次握手本身就是一次RTT的损耗。如果你每个水印请求都新建连接，那就是一帧一帧地握手。那画面太美我不敢看。
Keep-Alive 与连接池
HTTP/1.1默认带Keep-Alive，但很多框架默认开启但没管好连接池。我在实践中踩过一个大坑：服务端Keep-Alive超时设了60秒，客户端连接池最大空闲连接数却只有2。导致大量请求在等待连接，反而搞出了队列延迟。
// 以Go为例，调整Transport参数
transport := &http.Transport{
MaxIdleConns: 100, // 总空闲连接数
MaxIdleConnsPerHost: 20, // 每个host最多20个空闲
IdleConnTimeout: 90 * time.Second, // 比服务端KeepAliveTimeout略短
DisableCompression: false,
}
client := &http.Client{Transport: transport}| 参数 | 建议值 | 为什么 |
|---|---|---|
| MaxIdleConns | 100 ~ 200 | 避免高并发时创建新连接 |
| MaxIdleConnsPerHost | 10 ~ 30 | 防止单个域名耗尽连接池 |
| IdleConnTimeout | 略小于服务端KeepAliveTimeout | 避免触发服务端主动断连 |
避坑指南：我曾经把IdleConnTimeout设得比服务端KeepAliveTimeout还大50秒。结果服务端先断开连接，客户端还在用这个socket发数据，直接返回连接复位错误。嗯，那天的日志全都是write: broken pipe。从那以后，我养成了“客户端超时比服务端短5~10秒”的习惯。
TCP Fast Open（TFO）
TFO允许客户端在SYN包里夹带数据，省掉一次RTT。但有个坑：它依赖操作系统和内核支持，而且首次连接不行（因为还没拿到Cookie）。我一般只在长连接的场景里开启它——比如WebSocket或长轮询。
3. HTTP/2 与 HTTP/3——从多路复用到0-RTT
HTTP/1.1即使Keep-Alive，也有线头阻塞问题：一个请求没收到响应，后续请求就得排队。HTTP/2的多路复用解决了这个问题，但它在丢包场景下反而更糟——因为TCP层的重传会影响所有流。
HTTP/2 的核心优势
- 多路复用：一个TCP连接可以同时发起多个请求，没有顺序依赖。
- 头部压缩（HPACK）：重复的Header只传一次。对于水印接口这种固定Header多的场景，能省50%的头部字节。
- 服务器推送（Server Push）：很少用在水印接口上，因为水印资源往往是动态生成的，不适合提前推送。
HTTP/3（QUIC） 为什么更适合移动端？
HTTP/3基于QUIC，在UDP上实现了可靠传输。它的最大好处是：0-RTT握手（第二次连接时）和无队头阻塞（因为每个流独立）。我去年帮一个海外电商项目优化水印接口，从HTTP/2切到HTTP/3后，弱网下的P50延迟从380ms降到了210ms。
但也要注意：QUIC现在还在普及期，部分网络中间件会拦截UDP包。国内某些运营商就喜欢丢UDP。
| 对比项 | HTTP/1.1 with Keep-Alive | HTTP/2 | HTTP/3 (QUIC) |
|---|---|---|---|
| 传输层 | TCP | TCP | UDP |
| 头部压缩 | 无 | HPACK | QPACK |
| 多路复用 | 无（有队头阻塞） | 有（但TCP级队头阻塞） | 有（流级独立） |
| 握手延迟 | 2 RTT（含TLS） | 1~2 RTT | 0~1 RTT |
| 弱网稳定性 | 中等 | 较差（丢包影响所有流） | 优秀（每个流独立丢包重传） |
| 部署普及度 | 100% | ~80% | ~30%（仍在增长） |
我个人的选择：如果服务端和客户端都在内网，HTTP/2就够用了。如果面向公网用户、尤其是移动端，强烈推荐上HTTP/3。但记得做fallback——比如用Alt-Svc头宣告QUIC支持，客户端自动协商。
网络优化全景图
最后说一句：这三层优化没有银弹。DNS预解析容易加，但要注意控制数量，否则反而增加DNS查询。连接池要配合微服务架构调整，不是越大越好。HTTP/3很好，但得做降级方案。我的做法是先用压测工具（比如wrk或k6）分别模拟这三层的瓶颈，再针对性改。改完后，记得用curl --http3或浏览器DevTools的协议列确认是否生效。