📚 课程目录第2章网络层优化

网络层优化：TCP参数调优、连接池管理、DNS解析优化、网络超时设置

网络层，说白了就是消费端拉取数据的「高速公路」。路况好不好，直接决定了数据能不能又快又稳地到达。我见过太多团队，业务代码写得飞起，结果被网络层拖了后腿——TCP握手慢、连接反复建、DNS解析卡住、超时设置不合理……每一个坑都能让你的拉取性能掉一个数量级。

这一章，咱们就把网络层的四个核心优化点掰开揉碎。我会结合自己踩过的坑，告诉你每个参数该怎么调、每个策略该怎么配。

核心思路：网络层优化的目标不是「快」，而是「稳中求快」。减少握手次数、复用连接、缩短解析路径、合理兜底——这四件事做好了，性能自然就上去了。

TCP参数调优：别让内核默认值坑了你

TCP是消费端拉取的基础协议。但Linux内核的默认TCP参数，是为通用场景设计的，不是为高并发、低延迟的消费端场景设计的。你不调，它就按「佛系」模式跑。

我个人习惯，第一件事就是关掉Nagle算法。Nagle算法会把小包攒起来再发，目的是减少网络小包数量。但对于消费端拉取来说，每次请求的数据量可能不大，攒包反而增加了延迟。

# 在Java中关闭Nagle算法
Socket socket = new Socket();
socket.setTcpNoDelay(true);

# 在Netty中
Bootstrap b = new Bootstrap();
b.option(ChannelOption.TCP_NODELAY, true);

我的经验：有一次线上消费延迟飙升，排查了半天，最后发现是Nagle算法在作祟。请求体只有几百字节，硬是被攒了40ms才发出去。关掉之后，P99延迟直接降了60%。

第二个要调的参数是TCP keepalive。默认的keepalive间隔是2小时，太长了。对于消费端长连接，如果对端挂了，你要等2小时才能发现？那业务早崩了。

# 系统级调整（/etc/sysctl.conf）
net.ipv4.tcp_keepalive_time = 300    # 空闲5分钟后开始探测
net.ipv4.tcp_keepalive_intvl = 30    # 每次探测间隔30秒
net.ipv4.tcp_keepalive_probes = 3    # 连续3次失败则断开

嗯，这里要注意：keepalive时间设得太短也不行，会增加无谓的探测包。我个人建议300秒是一个比较平衡的值。

连接池管理：复用才是王道

每次请求都新建TCP连接？那性能就别想了。三次握手+慢启动，光握手就要一个RTT。对于消费端拉取场景，连接池是必须的。

连接池的核心参数就几个：最大连接数、最小空闲数、空闲超时时间、获取连接超时时间。我见过最典型的错误，就是最大连接数设得太大，结果把对端打挂了。

参数	推荐值	说明
最大连接数	50-200	根据服务端承载能力调整，不是越大越好
最小空闲数	5-10	保证突发流量时有连接可用
空闲超时	60-300秒	超过此时间未使用的连接将被回收
获取超时	100-500ms	从池中获取连接的等待时间

我曾经踩过的坑：有一次把最大连接数设成了1000，结果服务端扛不住，直接返回Connection Refused。后来才发现，服务端每个连接都要占用文件描述符和内存，连接数太多反而会触发服务端的保护机制。建议先压测，再定值。

连接池的另一个关键点是「连接健康检查」。空闲连接可能已经被对端关闭了，但你不知道。取出来直接用，就会报错。

// 使用HikariCP连接池示例
HikariConfig config = new HikariConfig();
config.setMaximumPoolSize(100);
config.setMinimumIdle(10);
config.setIdleTimeout(300000);      // 5分钟
config.setConnectionTimeout(500);   // 500ms获取超时
config.setValidationTimeout(3000);  // 3秒验证超时
config.setConnectionTestQuery("SELECT 1");

DNS解析优化：别让域名解析成为瓶颈

很多人忽略了DNS解析的耗时。一次DNS查询，如果走递归解析，可能要几百毫秒甚至几秒。对于消费端拉取来说，每次请求都做DNS解析？那延迟直接爆炸。

我建议的做法是：缓存DNS结果，并且提前解析。

TTL缓存：将DNS结果的TTL设置为至少300秒。Java的InetAddress默认会缓存，但时间可能太短。
预解析：在应用启动时，主动解析所有会用到的域名。这样第一次请求就不会卡在DNS上。
异步解析：如果域名变更频繁，可以用异步线程定期刷新DNS缓存，避免阻塞主流程。

// Java中设置DNS缓存时间
// 在启动参数中设置
-Dsun.net.inetaddr.ttl=300
-Dsun.net.inetaddr.negative.ttl=10

// 或者代码中主动解析
InetAddress[] addresses = InetAddress.getAllByName("your-service.example.com");
// 缓存到本地Map或缓存框架中

一个小技巧：如果服务端IP很少变动，可以直接把IP写死在配置中心，跳过DNS解析。我在一个高并发项目中就这么干的，每次拉取省掉了5-10ms的DNS查询时间。

网络超时设置：给每个环节一个「死线」

没有超时的系统，就像没有刹车的车。一旦网络抖动，所有线程都会卡住，最终导致线程池耗尽、服务雪崩。

网络超时应该分三层设置：

连接超时（connectTimeout）：建立TCP连接的最大等待时间。推荐1-3秒。
读取超时（readTimeout / socketTimeout）：等待服务端返回数据的最大时间。推荐5-10秒。
写入超时（writeTimeout）：发送请求数据的最大时间。推荐3-5秒。

// OkHttp客户端超时设置示例
OkHttpClient client = new OkHttpClient.Builder()
    .connectTimeout(3, TimeUnit.SECONDS)
    .readTimeout(10, TimeUnit.SECONDS)
    .writeTimeout(5, TimeUnit.SECONDS)
    .build();

注意：超时时间不是越长越好。设得太长，网络抖动时大量请求堆积，会拖垮整个系统。设得太短，正常慢请求也会被误杀。我一般建议先设一个保守值（比如连接3秒、读取10秒），然后根据线上P99延迟逐步调低。

还有一个容易被忽略的点：超时重试策略。超时后要不要重试？重试几次？间隔多久？

我个人习惯的规则是：

连接超时：重试1次，间隔100ms。因为连接超时可能是临时的网络波动。
读取超时：不重试，或者最多重试1次。因为读取超时往往意味着服务端已经处理了请求，重试可能导致重复消费。
写入超时：不重试。写入超时说明数据可能已经发出，重试会导致数据重复。

好了，网络层的四个优化点就聊到这儿。TCP参数调优让单连接更高效，连接池管理让并发更稳定，DNS优化让寻址更快，超时设置让系统更健壮。这四个点你一个一个去落地，消费端的拉取性能至少能提升30%。