3、DNS与网络层优化：从用户到服务器的第一公里
说实话，很多团队做API性能优化，上来就盯着代码层面——缓存、SQL、线程池。但往往忽略了最基础的一层：网络。你想想看，用户请求从手机发出，到真正落到你的服务器上，中间要经过多少跳？DNS解析、路由转发、TLS握手……任何一个环节出问题，后端再快也白搭。
我个人习惯，接手一个新系统，第一件事不是看代码，而是先抓个包看看网络耗时分布。很多时候你会发现，光是DNS解析就占了200ms，这还没开始发HTTP请求呢。今天我们就聊聊网络层怎么优化，重点放在DNS、CDN和协议选择上。
核心观点：网络层优化是API性能的“第一公里”，也是投入产出比最高的优化点之一。一个DNS预解析配置，可能比重构一段代码效果更明显。
3.1 DNS解析优化：别让域名成为瓶颈
DNS解析，说白了就是把域名翻译成IP地址。这个过程看似简单，但坑特别多。我在项目中遇到过，某次线上故障排查了半天，最后发现是DNS解析超时导致接口响应慢了3秒。
3.1.1 DNS解析的典型耗时
先看一组我实际压测的数据：
| 场景 | 平均耗时 | P99耗时 | 说明 |
|---|---|---|---|
| 首次DNS解析（无缓存） | 50-120ms | 300ms+ | 取决于DNS服务器距离 |
| 本地DNS缓存命中 | 1-5ms | 10ms | 浏览器/OS缓存 |
| HTTPDNS（直连IP） | 10-30ms | 50ms | 绕过运营商DNS |
看到了吗？首次解析和缓存命中之间，差了整整一个数量级。所以优化的核心思路就两条：减少解析次数和加快解析速度。
3.1.2 DNS预解析：让浏览器提前干活
前端页面里，我们经常要请求多个第三方域名——CDN资源、统计服务、API网关。如果等到用户点击按钮才去解析，那就晚了。
我建议的做法，是在页面加载时就用 <link> 标签告诉浏览器提前解析：
<!-- 强制预解析 -->
<link rel="dns-prefetch" href="//api.example.com">
<link rel="dns-prefetch" href="//cdn.example.com">
<!-- 更激进的预连接（包含TCP+TLS） -->
<link rel="preconnect" href="//api.example.com" crossorigin>这里有个细节：dns-prefetch 只做DNS解析，而 preconnect 会提前完成TCP握手和TLS协商。如果你的API是HTTPS的，用 preconnect 效果更好。但注意别滥用——预连接会占用浏览器连接池，一般建议只对首屏关键域名使用。
经验之谈：我曾经在一个电商首页上加了6个preconnect标签，结果反而导致连接池竞争，首屏渲染变慢了。后来只保留了对支付网关和商品图片CDN的两个预连接，效果才出来。凡事有度，别贪多。
3.1.3 DNS缓存策略：本地化是关键
服务端调用外部API时，同样面临DNS问题。Java应用默认使用JVM的DNS缓存，但TTL设置不合理的话，要么频繁解析拖慢性能，要么缓存太久导致故障转移失败。
我一般这样配置：
// JVM参数：设置DNS缓存TTL
// 成功解析缓存30秒，失败缓存5秒
-Dsun.net.inetaddr.ttl=30
-Dsun.net.inetaddr.negative.ttl=5如果是Go或Node.js应用，建议使用内置的DNS缓存库，或者直接集成HTTPDNS服务。HTTPDNS的优势在于：
- 绕过运营商劫持：避免DNS被污染或重定向
- 智能调度：根据用户IP返回最近的节点
- 精准TTL控制：不受本地缓存策略影响
注意：DNS缓存不是越长越好。如果你的服务有故障转移需求（比如多机房容灾），缓存TTL太长会导致流量无法快速切走。我曾经见过一个案例，某团队把DNS TTL设成了24小时，结果主机房挂了，流量还是往那边打，整整一天才恢复。建议生产环境TTL控制在30-60秒。
3.2 CDN加速：让数据离用户更近
CDN的原理很简单——把内容缓存到离用户最近的边缘节点。但实际落地时，很多团队只把它当静态资源加速器，忽略了它对API的加速价值。
3.2.1 动态加速 vs 静态加速
| 类型 | 适用场景 | 加速原理 | 典型延迟降低 |
|---|---|---|---|
| 静态加速 | 图片、CSS、JS、视频 | 边缘节点缓存，回源少 | 50%-80% |
| 动态加速 | API请求、动态页面 | 优化路由、TCP优化、协议转换 | 20%-40% |
很多人以为API请求不能走CDN，因为数据是动态的。其实不然。动态加速（DCDN）通过优化网络路径——比如使用BGP多线接入、智能路由选择、TCP参数调优——能显著减少跨运营商、跨国访问的延迟。
我记得有一次帮一个东南亚客户优化，他们的API服务器在新加坡，但用户主要在印尼和菲律宾。直接访问延迟在200-300ms。接入动态加速后，延迟降到了80ms以内。说白了，CDN不只是缓存，它更是一张优化过的全球网络。
3.2.2 CDN配置的几个关键参数
如果你已经在用CDN，这几个参数建议检查一下：
- 回源超时时间：默认可能30秒，建议缩短到5-10秒，避免慢请求拖垮连接池
- 缓存规则：对API响应设置合适的Cache-Control，即使是动态内容，也可以设置短时间缓存（如5秒）
- Gzip/Brotli压缩：在边缘节点开启压缩，减少传输体积
- HTTP/2支持：确保CDN节点和源站都支持HTTP/2，减少连接开销
一个容易被忽略的点：CDN的SSL握手。如果CDN节点和源站之间也走HTTPS，那TLS握手时间也要算进去。我建议在CDN和源站之间使用长连接，或者直接走内网HTTP（如果安全允许），能省下不少时间。
3.3 网络协议选择：HTTP/2 vs HTTP/3
聊完DNS和CDN，我们来看看传输协议。HTTP/1.1、HTTP/2、HTTP/3，这三者有什么区别？我该用哪个？
3.3.1 核心差异对比
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC (UDP) |
| 多路复用 | 不支持（需多个连接） | 支持（流复用） | 支持（无队头阻塞） |
| 队头阻塞 | 严重 | TCP层仍有 | 无（UDP层面解决） |
| 连接建立 | TCP 1RTT + TLS 1-2RTT | TCP 1RTT + TLS 1-2RTT | 0-1RTT |
| 迁移支持 | 不支持 | 不支持 | 支持（连接ID） |
这里我想重点说一下队头阻塞的问题。HTTP/2虽然解决了应用层的队头阻塞，但TCP层的队头阻塞依然存在——如果一个TCP包丢了，后续所有流都得等它重传。而HTTP/3基于QUIC，在UDP上实现了可靠传输，丢包只影响单个流，其他流不受影响。
我在项目中遇到过这种情况：弱网环境下（比如地铁、电梯），HTTP/2的请求延迟会急剧上升，而切换到HTTP/3后，延迟稳定了很多。说白了，HTTP/3是为移动互联网和弱网环境设计的。
3.3.2 实际选型建议
那到底该用哪个？我的建议是：
- 内网服务：HTTP/1.1就够用，延迟低、丢包少，没必要上复杂的协议
- 公网API：优先HTTP/2，兼容性好，性能提升明显
- 移动端/弱网场景：考虑HTTP/3，但要注意客户端和服务端支持情况
- 实时通信：HTTP/3的0-RTT和连接迁移特性是杀手锏
一个小技巧：如果你不确定该用哪个，可以同时支持HTTP/2和HTTP/3，让客户端通过Alt-Svc头部协商。Nginx和Caddy都支持这种配置，我一般会这样写：
# Nginx配置示例：同时支持HTTP/2和HTTP/3
server {
listen 443 ssl http2;
listen 443 quic reuseport; # HTTP/3
ssl_protocols TLSv1.3;
add_header Alt-Svc 'h3=":443"; ma=86400';
}3.4 网络延迟与丢包处理：实战中的应对策略
网络是不可靠的，延迟和丢包是常态。我们能做的，不是消除它们，而是减少它们的影响。
3.4.1 延迟的常见原因
- 物理距离：光速限制，跨洲延迟至少100ms+
- 路由跳数：每多一跳，增加几毫秒
- 运营商互联：跨运营商延迟可能翻倍
- TCP拥塞控制：丢包后慢启动，吞吐量骤降
我记得有一次排查一个海外用户的慢请求，发现数据包从上海到纽约，绕了欧洲一圈，多了15跳。后来通过BGP优化和CDN加速，把路径缩短到8跳，延迟从280ms降到了160ms。
3.4.2 丢包处理的几个实用技巧
丢包不可避免，但我们可以让应用更健壮：
- 设置合理的超时和重试：不要用默认的60秒超时，建议连接超时3秒，读取超时5秒。重试策略用指数退避，避免雪崩。
- 使用连接池：复用TCP连接，减少三次握手和慢启动的开销。连接池大小建议根据压测结果调整，一般10-50个连接。
- 开启TCP Keepalive：及时清理死连接，避免连接池被僵尸连接占满。
- 考虑使用多路径：关键业务可以同时走两条网络链路（比如专线+公网），一条挂了自动切换。
避坑指南：我曾经在重试逻辑上踩过坑。某个服务调用第三方API，超时后立即重试，结果第三方刚好在重启，连续重试了5次，每次等30秒，最终用户等了2分半钟才收到错误。后来改成指数退避+最多重试2次，用户体验好多了。记住：重试不是越多越好，要考虑对下游的压力。
3.5 本章知识体系总览
下面这张图，我把本章的核心知识点串起来了。你可以把它当作一个检查清单，看看自己的系统在哪些环节还有优化空间。
好了，这一章的内容就到这里。DNS预解析、CDN加速、协议选择、延迟丢包处理——这些看似基础的东西，往往是性能优化的“隐藏金矿”。下次遇到接口慢，别急着改代码，先看看网络层有没有优化空间。你可能会发现，一个简单的配置改动，效果比重构整个模块还好。