4、网络协议栈优化：TCP三次握手优化、TCP_NODELAY、连接池原理、HTTP/1.1 vs HTTP/2 vs gRPC
聊到吞吐优化，网络协议栈这块是绕不开的硬骨头。很多人觉得网络调优就是改几个内核参数，其实没那么简单。我个人的经验是，网络优化更像是在做「手术」，切对了地方，吞吐能翻倍；切错了，反而会引入各种诡异问题。
今天咱们就聚焦四个核心点：TCP三次握手怎么省时间、Nagle算法为什么该关掉、连接池到底在解决什么问题，以及HTTP/1.1、HTTP/2、gRPC这三兄弟该怎么选。
4.1 TCP三次握手：能不能砍一刀？
先看最基础的。TCP三次握手，说白了就是客户端和服务端互相确认「你准备好了吗？」「我准备好了！」的过程。但每次建连都要多一个RTT（往返时延），在高并发场景下，这个开销会被放大。
我遇到过最夸张的情况：一个短连接服务，每秒要建几千次连接，光握手就占了30%的响应时间。这谁能忍？
4.1.1 优化手段一：TCP Fast Open
TCP Fast Open（TFO）是个好东西。它允许在第一次握手时就把数据带过去。说白了，就是省掉一次RTT。
# 服务端开启TFO
echo 3 > /proc/sys/net/ipv4/tcp_fastopen
# 客户端也需要支持
# 内核参数 tcp_fastopen 取值含义：
# 0: 禁用
# 1: 客户端启用
# 2: 服务端启用
# 3: 两端都启用
嗯，这里要注意：TFO依赖客户端和服务端都支持，而且第一次连接还是正常的三次握手。但从第二次开始，就能省掉那个RTT了。
4.1.2 优化手段二：连接复用
其实最狠的优化不是砍握手，而是——不握手。用连接池复用已有连接，这才是王道。后面会细讲。
4.2 TCP_NODELAY：别让数据等太久
TCP_NODELAY这个选项，说白了就是关掉Nagle算法。Nagle算法是什么？它会把多个小包攒成一个大包再发，目的是减少网络中的小包数量。
听起来挺合理对吧？但问题来了——它会让数据等。等什么呢？等凑够一个MSS（最大报文段长度），或者等收到上一个包的ACK。
我曾经踩过一个坑：一个实时推送服务，客户端发消息总是延迟几百毫秒。查了半天，发现就是Nagle算法在作祟。小消息攒着不发，用户那边就觉得卡。
// Java中开启TCP_NODELAY
Socket socket = new Socket();
socket.setTcpNoDelay(true);
// C/C++中
int flag = 1;
setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(flag));
4.3 连接池原理：复用才是王道
连接池的核心思想很简单：别每次请求都建新连接，用完了也别急着关，留着给下一个请求用。
为什么连接池能提升吞吐？你想想看：
- 省掉了三次握手的1.5个RTT
- 省掉了四次挥手的2个RTT
- 避免了TCP慢启动的带宽爬坡过程
我记得有一次优化一个数据库访问层：原来每次查询都新建连接，QPS撑死2000。换成连接池后，同样的机器配置，QPS直接飙到15000。说白了，连接池就是让TCP连接「热着」，别让它凉下来。
4.3.1 连接池的核心参数
| 参数 | 说明 | 我的建议 |
|---|---|---|
| 最小空闲连接数 | 池子里最少保持多少条空闲连接 | 根据峰值QPS的10%来估算 |
| 最大连接数 | 池子最多能有多少条连接 | 别超过系统文件描述符上限的80% |
| 连接超时时间 | 获取连接的最大等待时间 | 一般设100-500ms，别太长 |
| 空闲连接存活时间 | 空闲连接多久会被回收 | 建议30-60秒，太短浪费，太长占资源 |
避坑指南：我曾经遇到过连接池「雪崩」——所有连接同时过期，瞬间大量请求去建新连接，把数据库打挂了。解决方案是给连接加一个「随机偏移量」，让过期时间分散开。
4.4 HTTP/1.1 vs HTTP/2 vs gRPC：选哪个？
这三个协议，说白了就是三代技术。我直接说结论：
- HTTP/1.1：老黄牛，稳定但慢。队头阻塞是硬伤——一个请求卡住了，后面的都得等。
- HTTP/2：多路复用，一个连接上可以同时跑多个请求。解决了队头阻塞，但TCP层面的队头阻塞还在。
- gRPC：基于HTTP/2，用Protobuf序列化。性能最好，但调试麻烦。
4.4.1 核心对比
| 特性 | HTTP/1.1 | HTTP/2 | gRPC |
|---|---|---|---|
| 连接复用 | 有限（一般6-8个并发） | 完全多路复用 | 完全多路复用 |
| 队头阻塞 | 严重 | TCP层面仍有 | TCP层面仍有 |
| 序列化格式 | 文本（JSON/XML） | 文本（JSON/XML） | 二进制（Protobuf） |
| 头部压缩 | 无 | HPACK | HPACK |
| 流式传输 | 不支持 | 支持 | 原生支持 |
| 适用场景 | 传统Web、简单API | 现代Web、移动端 | 微服务间通信、高性能场景 |
我个人习惯：对外暴露的API，如果客户端是浏览器，用HTTP/2；内部微服务调用，无脑上gRPC。至于HTTP/1.1，除非是维护老系统，否则真不建议新项目用了。
4.4.2 一个真实的性能对比
我之前做过一个压测：同样的业务逻辑，同样的机器配置：
- HTTP/1.1：QPS约8000，延迟P99 120ms
- HTTP/2：QPS约15000，延迟P99 65ms
- gRPC：QPS约28000，延迟P99 30ms
你看，差距就是这么明显。gRPC的二进制协议和高效的序列化，在高并发下优势巨大。
4.5 本章知识体系
下面这张图，把咱们今天聊的内容串起来了：
说白了，网络协议栈优化的核心就四个字：减少等待。不管是砍握手、关Nagle、用连接池，还是升级协议，都是在跟「等」字作斗争。
嗯，今天就聊到这儿。这些优化手段，我建议你从连接池和TCP_NODELAY入手，收益最直接。至于协议升级，可以慢慢来，毕竟牵一发而动全身。