4、网络层优化：DNS解析优化、连接池技术、HTTP长连接与短连接、Nginx反向代理与负载均衡

网络层，说白了就是你的服务和用户之间的那条路。路窄了、堵了、绕远了，业务代码写得再快也白搭。我这些年调过的线上事故，十有六七都跟网络层脱不了干系。今天咱们就把这块硬骨头啃下来。

4.1 DNS解析优化——别让用户卡在第一步

用户访问你的服务，第一件事不是发请求，而是查DNS。这一步如果慢，后面的优化全白费。我记得有一次线上大促，压测发现平均响应时间多了200ms，查了半天，罪魁祸首居然是DNS解析超时。

4.1.1 常见的DNS问题

• 解析延迟高：每次请求都做DNS查询，尤其是跨运营商场景
• 缓存命中率低：TTL设置不合理，频繁回源
• DNS劫持：部分ISP会插入广告或返回错误IP
• 故障切换慢：后端IP变更，客户端还在用旧IP重试

4.1.2 优化手段

4.2 连接池技术——别让TCP三次握手拖垮你

每次请求都新建TCP连接？那三次握手的开销够你喝一壶的。连接池的核心思想就一句话：复用连接，减少握手。

4.2.1 连接池的核心参数

4.2.2 我在项目中遇到的连接池问题

曾经有个服务，数据库连接池设了200，结果高峰期连接数飙到500+，数据库直接被打挂。后来发现是连接泄漏——获取连接后没归还。嗯，这里要注意：一定要用try-with-resources或者finally块确保归还。

4.3 HTTP长连接与短连接——选错了就是灾难

HTTP1.0默认短连接，每次请求都新建TCP。HTTP1.1引入了长连接（Keep-Alive），复用同一个TCP连接发多个请求。你想想看，如果每个请求都三次握手+四次挥手，光网络开销就占了响应时间的一半。

4.3.1 什么时候用长连接？

• API服务：请求频繁，复用连接能显著降低延迟
• 数据库连接：必须用长连接，短连接根本扛不住
• WebSocket：本身就是长连接场景

4.3.2 什么时候用短连接？

• 低频请求：一天就发几次，长连接反而浪费资源
• 推送/通知：连接数太多，长连接会撑爆服务器
• 临时任务：比如上传一个文件，完事就断

4.4 Nginx反向代理与负载均衡——流量入口的守门员

Nginx是我最常用的反向代理工具。它不仅能做负载均衡，还能做缓存、限流、SSL卸载。说白了，它就是流量的第一道关卡。

4.4.1 反向代理 vs 正向代理

4.4.2 负载均衡算法

• 轮询（Round Robin）：默认方式，简单但没考虑服务器负载
• 最少连接（Least Connections）：把请求发给当前连接数最少的节点
• IP哈希（IP Hash）：同一IP的请求始终发到同一台服务器，适合Session场景
• 加权轮询（Weighted）：给高性能服务器分配更多请求

4.4.3 Nginx配置示例

upstream backend {
    least_conn;  # 最少连接算法
    server 192.168.1.10:8080 weight=3;
    server 192.168.1.11:8080 weight=2;
    server 192.168.1.12:8080 backup;  # 备用节点
}

server {
    listen 80;
    location /api/ {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_connect_timeout 5s;
        proxy_read_timeout 10s;
    }
}

4.4.4 我曾经踩过的坑

有一次线上服务突然变慢，查了半天发现是Nginx的proxy_read_timeout设得太短，后端处理慢一点就被Nginx断开了。客户端不断重试，反而加重了后端压力。嗯，超时时间要跟后端接口的P99响应时间对齐，别拍脑袋设。

4.5 本章知识体系总览

下面这张图把网络层优化的四个核心模块串起来了。你可以看到，从用户请求到后端服务，每一步都有优化空间。

4.6 小结

网络层优化，说白了就是三件事：让路更短（DNS）、让车复用（连接池/长连接）、让流量更均衡（Nginx）。我个人的经验是，先做DNS优化和连接池，这两个见效最快。Nginx的调优要结合后端容量做压测，别盲目改参数。