先说一个我实际遇到过的场景。有段时间某个内部服务的调用方频繁反馈“请求很慢，偶尔直接超时”，团队里很多人第一反应都是把客户端超时时间调大。但调大之后该超时还是超时，只是等得更久。最后定位到根因是连接池参数配错，大量请求在等连接复用，而TCP握手本身的耗时被忽略，整个调用链的延迟被无限放大。这件事让我意识到一个问题：很多写得动业务代码的人，其实并不真正理解网络编程。

网络编程并不是“会用HTTP库调接口”，也不是“会写一个socket demo”。它覆盖的是从物理链路到应用层协议的一整条链路：TCP/UDP的传输语义、Socket生命周期、并发模型、报文编解码、超时与重试，以及各种异常状态下的行为。这篇内容不打算把一门系列课程压缩成一篇，而是把我在实际项目里反复用到的核心知识和踩过的坑整理出来，给正在学网络编程、或者已经被线上网络问题折磨过的人一份可以直接参考的笔记。无论你是后端、运维，还是写客户端的同学，把底层这些逻辑搞清楚了，排查问题时会少走非常多弯路。

1. 网络编程到底在解决什么问题，为什么绕不开

很多人觉得网络编程离自己很远，理由是“我平时写接口都是用框架，HTTP库一封装，根本碰不到Socket”。这个想法短期看没错，但一旦遇到线上问题，框架帮你掩盖的东西全会变成拦路虎。

网络编程的核心，其实是解决两件事：怎么把数据可靠地从A点送到B点，以及怎么让这条数据通路在高并发、高延迟、不可靠的环境下仍然可用。前者是协议栈的事，后者才是程序员真正要花心思的地方。

以最常见的HTTP请求为例。当你调用一个接口时，背后至少经历了这几步：DNS解析拿到目标IP、TCP三次握手建立连接、可能还有TLS握手加密、然后才是发送HTTP报文、等待响应、解析响应、最后关闭或复用连接。任何一步出问题，表现到业务层就是“超时”“连接被重置”“响应慢”。不懂底层的人只能瞎猜，懂底层的人能直接判断是DNS出了问题、握手没完成、还是服务端根本没回包。

我在实际项目中见过太多类似的误判。比如一个定时任务偶尔失败，有的人怀疑是代码逻辑问题，反复加日志；其实用ss -s看一眼系统Socket统计，发现是TIME_WAIT堆积导致端口不够用，方向完全就错了。再比如调用第三方接口偶发慢请求，有人急着调超时时间，实际上只要抓包看一眼，就会发现是Nagle算法和延迟ACK相互等待，白白卡了40毫秒。

这些都不算什么高深理论，但前提是你知道Socket、知道TCP状态机、知道数据是怎么分包和重组。这篇文章后面讲的所有内容，本质上都是在帮你建立这张“问题地图”——出故障时能快速定位到网络栈的哪一层，而不是在业务代码里瞎转。

2. 一次HTTP请求的完整旅程：从三次握手到报文解析

要理解网络编程，最好的切入点就是拆解一次HTTP请求。它不是魔法，只是一台机器上的数据，经过协议栈层层封装，传到另一台机器，再被层层解包。

2.1 三次握手与四层模型：连接不是一步到位的

我们常说的连接，在TCP里是一个状态机，而不是一条真实的物理线路。三次握手的目标是让通信双方确认“你能收到我的数据，我也能收到你的数据”，并且同步初始序列号。

流程很简单：客户端发SYN包，服务端回SYN+ACK包，客户端再回ACK包。为什么是三次而不是两次？因为如果只有两次，服务端无法确认客户端是否真的收到了自己的SYN+ACK。生活中类比就是打电话：你问“在吗”，对方回“在，你听得到我吗”，你再回“听得到”，双方才确认链路通畅。

这个握手过程对应到代码里就是：

• 服务端调用listen()后进入监听状态；
• 客户端调用connect()时，内核帮你完成了三次握手；
• 连接建立后，accept()才会返回一个可用的连接描述符。

握手耗时虽然只有几毫秒（RTT级别），但在高并发下会放大。如果服务端accept()不及时，内核的Accept队列会堆积，客户端的connect()就会表现为“建立连接超时”。我见过某个项目把监听队列长度设成默认值，结果双十一大促时大量连接排队失败，加个listen(fd, backlog)参数调大才解决。

四层模型（应用层、传输层、网络层、链路层）对应的报文封装逻辑是：应用层产生数据，传输层加TCP头（源端口、目的端口、序列号等），网络层加IP头（源IP、目的IP），链路层加MAC头和帧尾。抓包工具Wireshark里看到的每一个包，都是这种层层封装的产物。理解这层关系，你就明白为什么connect()之后还要区分“连上了”和“能收发数据”这两个概念，也就能理解为什么要做心跳。

2.2 报文里到底装了什么，服务端看到的原始数据

很多人写服务端框架的时候，从没看过HTTP请求的原始样子。其实用nc或者一个简单的TCP客户端就能看得很清楚：

$ echo -e "GET /index.html HTTP/1.1\r\nHost: example.com\r\nUser-Agent: curl/7.68.0\r\n\r\n" | nc 127.0.0.1 8080

一个标准的HTTP请求报文就是这样的文本块：

GET /index.html HTTP/1.1 Host: example.com User-Agent: curl/7.68.0

第一行是请求行，包含方法、路径和协议版本；接下来是若干Header，每个都是键: 值的形式；空行之后是Body（GET没有Body）。服务端解析报文的逻辑就是按\r\n切行，遇到空行说明Header结束，然后根据Content-Length或Transfer-Encoding决定怎么读Body。

这里有个重点：HTTP报文是文本协议，边界靠空行和长度字段划分；但TCP本身不帮你划分“一条消息”的边界。换句话说，HTTP报文在传输层是被拆成若干TCP段（segment）发出去的，到达对端后再按顺序组装。这就是下一节要讲的粘包和半包问题。

当你在代码里调用recv()时，返回的数据长度不一定正好等于对端一次send()的长度。可能是半个报文，也可能是多个报文拼在一起。所有基于TCP的协议（HTTP、WebSocket、Redis协议、自定义RPC协议）都必须自己解决“消息边界”的还原问题。

2.3 粘包、半包：TCP是水管，不是快递箱

这是我带新人时必讲的一个比喻。TCP是一条水管，你往里倒水（发送数据），对端从另一头接水（读取数据）。水在水管里是连续流动的，没有“这是第一杯水，那是第二杯水”的天然分界。而UDP才像快递箱：每个send对应一个独立包裹，接收方每次recv拿到一个完整包裹。

粘包指的是：发送方发了两个消息（比如A和B），接收方一次recv()把AB一起读走了；半包指的是：A消息比较大，拆成了两个TCP段，接收方第一次recv()只拿到了A的前半段。

解决思路有三种，实际项目里按需选：

1. 固定长度：每条消息固定N个字节，不足补零。简单但浪费带宽，适用于消息长度非常稳定的场景。
2. 分隔符：消息末尾加特殊标记（比如HTTP的空行、Redis协议的\r\n），读数据时按标记切分。缺点是需要转义，且扫描大消息时效率低。
3. 长度前缀：每个消息前面加4字节长度字段，接收方先读长度，再读够长度。这是最通用、最高效的方式，大多数RPC框架都这么干。

我在模拟项目X里实现过一个简单的长度前缀协议，核心收包逻辑类似这样：

import struct def recv_exact(conn, n): data = b'' while len(data) < n: chunk = conn.recv(n - len(data)) if not chunk: raise EOFError data += chunk return data def recv_message(conn): header = recv_exact(conn, 4) (length,) = struct.unpack('>I', header) return recv_exact(conn, length)

这段代码的关键是recv_exact：它循环调用recv()，直到读满指定字节数才返回。不理解TCP流式语义的人，很容易写成“读一次就算一条消息”，然后在并发量上来时出现莫名其妙的解析错误。

3. 最小可用TCP服务端：先跑起来，再谈优化

纸上谈兵再多，不如亲手写一个能收发数据的服务端。下面这个例子用Python实现，不依赖任何框架，目的是让你看清Socket API最原始的样子。

3.1 Python版本的服务端和客户端

服务端代码：

import socket server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind(('0.0.0.0', 9000)) server.listen(5) print('listening on 0.0.0.0:9000') while True: conn, addr = server.accept() print('connected from', addr) data = conn.recv(1024) if data: conn.sendall(b'echo: ' + data) conn.close()

客户端代码：

import socket client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect(('127.0.0.1', 9000)) client.sendall(b'hello, tcp') resp = client.recv(1024) print('received:', resp) client.close()

先逐行解释服务端。socket.socket(AF_INET, SOCK_STREAM)创建IPv4流式套接字，也就是TCP套接字。SO_REUSEADDR这个选项必须设置，否则服务端刚重启时会因为上一个进程还占着端口（TIME_WAIT状态）而报Address already in use。bind把套接字绑定到本机9000端口，0.0.0.0表示监听所有网卡，这样局域网内其他机器也能连。listen(5)是告诉内核最多排队多少个未accept()的连接。

accept()是一个阻塞调用：没有连接进来时，线程会卡在这一行。一旦有客户端完成三次握手，它就返回一个已连接的套接字conn和客户端地址addr。conn.recv(1024)从内核接收缓冲区读取最多1024字节；conn.sendall(b'echo: ' + data)把数据原样发回去。注意我用的是sendall而不是send，因为send只保证尝试发送，可能一次没发完；sendall内部会把剩余数据循环发送完毕。

3.2 为什么recv的返回值不能当“一条完整消息”

这个Demo跑起来没问题，但如果你把recv(1024)的返回值直接当成“客户端发来的一条完整消息”，很快就会踩坑。原因在2.3节已经说了：recv返回的是当前内核缓冲区里可读的数据，不是“对端调用了一次send”。

举个具体例子：客户端连续调用两次sendall(b'hello')和sendall(b'world')，服务端可能一次recv()就读到helloworld，也可能第一次只读到hel，第二次才读到loworld。这取决于网络延迟、缓冲区大小、以及TCP分段的时机。

正确的收包姿势一定是循环读，然后按协议约定的边界去切。这也是为什么真实项目几乎不直接操作原始Socket，而是用框架封装好的解码器——Netty里有ByteToMessageDecoder，Python的asyncio也有Protocol接口，目的都是帮你解决消息边界问题。

3.3 这个Demo的瓶颈在哪儿

上面这个服务端是单线程串行处理的：accept()了一个连接，就堵在处理这个连接的IO上，期间其他连接排着队进不来。也就是说，如果某个客户端连接后一直不发数据，服务端就卡在recv()，其他所有客户端都无法被服务。

这是理解并发模型最好的起点。解决思路无非几种：每来一个连接开一个新线程处理；或者把socket设为非阻塞，用事件循环统一监听所有连接的可读事件。第4节我详细展开这块。

另外这个Demo还有个隐患：recv(1024)我默认了客户端会一次把数据发完。如果客户端发的是一个大文件，1024字节根本不够，服务端读完1024字节就返回了，剩下的数据还躺在缓冲区里，但代码已经走到conn.close()，数据直接丢弃。真实项目里，接收缓冲区大小、循环读取、消息边界校验，这些都需要根据协议认真设计。

4. 并发模型怎么选：多线程、多进程还是事件驱动

看到并发这个词，很多人第一反应是“用多线程”。但线程不是免费的午餐。并发模型的选择，直接决定了系统在连接数上升时的表现是线性恶化还是崩溃式恶化。

4.1 多线程：简单直接，但别滥用

每来一个连接，创建一个线程去处理，代码逻辑和单线程版几乎一样，只是把处理逻辑挪到了线程函数里。好处是简单，不用改协议、不用改收发逻辑；坏处是线程本身有开销——创建和销毁线程需要时间，每个线程要占栈空间（默认可能几MB），大量线程切换会消耗CPU。

我做过一个对比测试：同一个echo服务，线程模型在1000并发时CPU占用不高，但到5000并发时，光是线程切换就让吞吐量掉了大半，内存也被栈空间吃掉了不少。对于长连接类型的业务（比如IM、消息推送），连接数动辄几十万，线程模型完全不可行。

另一个坑是共享状态。多线程访问同一个数据结构要加锁，锁竞争会进一步降低性能，还容易引入死锁、竞态条件这些难排查的问题。所以多线程适合的是：连接数不多（几百到几千）、每个连接处理耗时短、不需要共享大量可变状态的场景，比如一个内网管理接口。

4.2 事件驱动：用更少的线程扛更多的连接

事件驱动的核心思想是：把Socket设为非阻塞，用一个线程去同时监听成千上万个Socket的IO事件，哪个Socket可读就读哪个，读完了处理，然后继续等下一个事件。

操作系统提供的底层机制是select/poll/epoll。select和poll每次调用都要把所有监听的文件描述符从用户态拷贝到内核态，事件数多时效率极低；epoll则是内核维护一个事件表，只返回有事件发生的描述符，适合大规模并发。这就是为什么Nginx、Redis、Netty这些高性能组件底层都在用epoll。

用Python标准库的selectors模块实现一个事件驱动echo服务：

import selectors import socket sel = selectors.DefaultSelector() def accept(sock): conn, addr = sock.accept() conn.setblocking(False) sel.register(conn, selectors.EVENT_READ, read) def read(conn): data = conn.recv(1024) if data: conn.sendall(b'echo: ' + data) else: sel.unregister(conn) conn.close() server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind(('0.0.0.0', 9000)) server.listen(100) server.setblocking(False) sel.register(server, selectors.EVENT_READ, accept) while True: events = sel.select() for key, _ in events: key.data(key.fileobj)

关键在于setblocking(False)和sel.register：每个连接注册一个回调函数，主循环通过sel.select()拿到就绪的事件，然后分发处理。这个模型下，即使有十万个连接，只要同时就绪的事件不多，一个线程就能很轻松地处理。

4.3 选型对照与典型场景

实际项目中很多系统是混合的：事件驱动负责接入层，工作线程池负责业务处理。比如一个Web服务，连接接入用事件循环，收到完整HTTP报文后丢给线程池去查数据库、做计算。这样既保留了事件驱动的高并发能力，又不让CPU密集操作阻塞事件循环。

如果你在选型，我给一个简单的判断标准：连接数预计超过一万，优先事件驱动或协程模型；连接数只有几百，对延迟又极其敏感，多线程模型反而更可控；如果业务逻辑全是IO（文件、数据库、下游调用），协程模型写起来最舒服。

5. 实际开发中最常见的五个坑，以及我的排查路径

这一节是我最想分享的内容。下面每个坑我都经历过，不是从文档里抄来的理论，而是调了一两天才定位出来的问题。

5.1 TIME_WAIT引发的端口耗尽

有一次某个内部网关服务频繁报“Cannot assign requested address”，第一反应是端口不够用了。用ss -s一看，系统里有几万个TIME_WAIT连接。

根因是服务端处理完请求后主动先关闭连接。TCP协议规定：主动关闭方要进入TIME_WAIT状态，并等待2MSL（最大报文生存时间，默认约1分钟）后才完全释放连接。短连接场景下，如果服务端处理完就close()，每个连接都会留下一个TIME_WAIT套接字。并发一高，本地端口（约3万多个可用）很快耗尽，新连接就无法建立。

排查路径是：先ss -tan | grep TIME_WAIT | wc -l看数量，再ss -tan | grep TIME_WAIT | awk '{print $5}' | sort | uniq -c | sort -nr看是访问哪个远端地址产生的，最后用strace跟踪系统调用，发现是服务端主动close()。

修复方案有三个层面：第一，让客户端主动断开连接（改协议约定）；第二，服务端开启HTTP Keep-Alive，减少建连和断连次数；第三，调大本地端口范围（sysctl -w net.ipv4.ip_range=xxxx这样的内核参数）或开启SO_REUSEADDR。注意，SO_REUSEADDR主要用于监听端口的快速重启，对TIME_WAIT客户端端口的复用也有一定帮助。

5.2 Nagle算法和延迟ACK打架，小包延迟40ms

某个调用链路的服务响应时间分布图里，总是有大约5%的请求稳定慢40毫秒左右。抓包发现，客户端发了一个很小的包，迟迟收不到服务端的确认，然后再发第二个包时一下子全出去了。

这就是经典的Nagle算法 vs 延迟ACK冲突。Nagle算法规定：TCP连接上只能有一个未确认的小包，后续小包要等确认后才能发。而延迟ACK机制是接收方收到小包后不立即回ACK，而是等最多40毫秒，看有没有数据要捎带确认。于是：发送方的小包等ACK，接收方的ACK等发送方的下一个包，双方僵持40毫秒。

排查时用Wireshark看时间间隔就能发现规律：相邻两个包之间正好差了约40ms。修复方法简单直接：在Socket上设置TCP_NODELAY，关闭Nagle算法。

conn.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

HTTP短连接时代这个坑非常常见，很多HTTP客户端库默认就开了TCP_NODELAY。如果你在做TCP长连接的自定义协议，记得发小包时排查一下这个选项。

5.3 半关闭语义没搞清，连接永远等不到EOF

有一次写一个代理程序，上游数据转发正常，但连接结束后代理进程挂起不退出。排查发现，代理只调用了close()，没有调用shutdown(SHUT_WR)，导致对端还在等待数据，而代理这边也没有正确感知“数据已经发完了”这个事件。

TCP的半关闭是指通信双方可以各自独立地关闭一个方向的数据流：shutdown(SHUT_WR)表示“我这边不再发数据了”，但还能读；shutdown(SHUT_RD)表示“我不再读了”。这个语义对协议设计非常重要。比如HTTP/1.0里，服务端就是通过关闭连接来告诉客户端“报文结束”的；如果你的代码在需要完整发送响应后，直接close()而不先shutdown(SHUT_WR)，某些对端可能因为“还有数据要读”而一直等。

排查路径是用lsof -p <pid> | grep TCP看连接状态，发现连接一直处于ESTABLISHED，但程序内部逻辑以为已经结束了。修复方式是：明确协议里“消息结束”的信号，要么是连接半关闭，要么是显式的长度字段，不要只依赖close()。

5.4 背压被忽略，内存先爆

这个问题在很多消息推送服务里出现过。生产者疯狂向消费者发数据，消费者处理速度跟不上，但代码里用了无界缓冲区（比如Queue），于是一直往内存里塞，最后OOM。

背压的根源在于TCP本身是有流控的：发送方的滑动窗口会根据接收方的接收缓冲区大小调整。但当你在应用层又加了一层用户态缓冲区时，这层缓冲绕过了TCP的流控机制，导致下游处理不过来时，数据不积压在内核缓冲区（那么发送方会感知到窗口变小而减慢发送），而是堆积在应用层内存里。

正确做法是：用户态缓冲区一定要有界。要么在入队时检查队列长度，满了就拒绝新数据或直接阻塞；要么使用带背压语义的队列（比如Go的channel会在满时阻塞发送方）。另外，读取Socket时要考虑“读得快但处理得慢”的情况，不要无限地recv往内存里堆。

排查这类问题，第一时间看内存监控曲线和GC日志，通常会发现堆内存持续上涨，但CPU并不高，这种特征大概率就是无界缓冲导致的。

5.5 DNS解析拖垮整个调用链

有一次线上服务偶发“卡死几秒”的问题，代码层面看不出任何异常，数据库也正常。后来用strace -e trace=network看到卡点发生在getaddrinfo上——客户端发起HTTP请求前先做DNS解析，而DNS服务器响应超时，getaddrinfo默认要等很久才返回失败。

DNS解析是很多请求链路里的“隐藏单点”。它通常是一个同步阻塞调用，如果DNS服务器没配好、或者网络抖动，一次解析可能耗掉几百毫秒甚至几秒，直接影响所有请求。

解决思路包括：在服务启动时一次性解析域名并缓存IP；连接池复用连接避免重复解析；如果必须每次解析，就改用异步DNS客户端，比如Python的AdResolver或C语言的c-ares；同时为DNS解析配置独立的超时时间，不要让它沿用默认的系统级超时。

我后来在模拟项目X里做了一个简单的IP缓存层：本地缓存三分钟，缓存失效后再解析，同时保留上一次成功的IP作为fallback，这样即使DNS抖动了，服务还能用旧IP继续跑，只是损失一点灵活性。

6. 上生产环境前，我会强制自己检查的四个细节

功能跑通只是第一步。真实环境下，网络编程的成败往往取决于那些“平时看不见、出事就要命”的细节。下面这四点，是我每次写涉及网络的代码前都会过一遍的检查清单。

6.1 连接池：复用连接，而不是反复握手

一次TCP握手至少消耗一个RTT（往返时间），TLS握手的开销更大。如果每个请求都新建连接，延迟和资源消耗都是浪费。连接池的本质是“把建连成本摊销到多次请求上”。

用连接池时最需要注意的是池参数的配置。核心参数有三个：

• maxTotal：池中最大连接数，设置过小会排队，过大浪费资源；
• maxIdle：最大空闲连接数，空闲连接超过这个值会被回收；
• maxWaitMillis：从池中借连接的最长等待时间，超过就抛异常。

我见过一个真实事故：某服务连接池maxTotal=20，而下游延迟本来就高，单连接吞吐撑不上去，大量请求排着队等借连接，整体RT飙升。后来把maxTotal调到200，同时把下游的批量处理逻辑优化了一下，问题立刻解决。连接池不是越大越好，但也要结合QPS和单连接吞吐量算一个合理值。经验公式大致是：池大小 ≈ QPS × 单请求下游耗时 / 1000，再乘一个1.5的安全系数。

6.2 超时时间要对齐每一层

超时设置是网络编程里最容易“顾此失彼”的地方。一个完整调用链上，至少有这么几层超时：

• 连接超时（connectTimeout）：建立TCP连接的最长等待时间；
• 读超时（readTimeout / socketTimeout）：建立连接后，等待对端返回数据的最大时间；
• 写超时（writeTimeout）：发送数据时，写入Socket的最长阻塞时间；
• 总超时（全链路超时）：从发起请求到拿到完整响应的最长时间。

这几层超时不是孤立的，它们必须满足一个约束：上层超时 > 下层超时的合理组合。比如总超时2秒，连接超时设了1.5秒，读超时也设了1.5秒，那么最坏情况就是连接超时1.5秒 + 读超时1.5秒 = 3秒，超过总超时，总超时形同虚设。

我的习惯是：连接超时设成总超时的三分之一到二分之一，读超时设成总超时的剩余部分再留一点余量，同时给每个下游调用设置独立的断路器或者降级策略。超时不是越大越好，过大的超时只是把问题延后，而且会导致调用方线程被占住，雪崩时整个系统的线程池被拖垮。

6.3 心跳机制要自己设计，别指望TCP保活

TCP层面有个保活机制（keepalive），但它的默认参数很保守：空闲2小时才开始探测，所以通常不适合作为业务心跳。对于长连接服务，应用层必须自己设计心跳。

心跳协议一般就两类：

1. Ping/Pong消息：客户端定时发Ping，服务端回Pong；服务端也定时检查连接最后活动时间，超过N秒没收到任何消息就认为连接死亡，主动清理。
2. 数据消息附带时间戳：不单独发心跳包，而是所有消息都带上发送时间，接收方根据时间差判断对端是否存活。

心跳间隔要结合业务场景设置：太频繁浪费带宽和CPU，太稀疏则故障发现太慢。通常3～5秒一次Ping、连续3次没收到Pong就判定死亡，是很多即时通讯服务的常见配置。服务端清理死连接也很关键，否则一堆“僵尸连接”占着套接字不释放。

我在一个长连接推送服务里就是用的这个方案：服务端每10秒扫描一次连接表，超过30秒无活动的连接直接关闭。调参的依据是：正常业务消息的最长间隔是15秒，所以30秒无活动基本可以判定异常，不会误杀正常连接。

6.4 优雅关闭：先停止接收新流量，再处理存量

进程要重启或者缩容时，如果直接kill -9，正在处理的请求会全部断裂，客户端会看到一堆“connection reset by peer”。正确的关闭流程是：

1. 从注册中心/负载均衡上摘除节点，让新流量不再打过来；
2. 关闭监听Socket，停止accept()新连接；
3. 等待存量连接处理完（设置一个最大等待时间，比如30秒）；
4. 超过等待时间的连接强制关闭；
5. 最后退出进程。

这个流程在代码里的表现是：主进程收到SIGTERM信号后，先拒绝新连接，再遍历活跃连接表，给已经处理的请求一个宽限期，宽限期结束后再统一清理。很多框架默认支持优雅关闭，但要注意：如果你的代码里有自己管理的长连接，框架可能管不到，需要单独处理。

我踩过的坑是：服务端优雅关停了，但客户端代码还在用被关闭的连接池里缓存的连接，导致一堆“连接已关闭”的异常。后来客户端也加了一层“连接失效自动重建”的逻辑，才彻底解决。这说明优雅关闭不是单端的事，两端必须配合：服务端温柔地断，客户端要能感知并重建。

网络编程的学习曲线确实陡峭：Socket、TCP状态机、并发模型、协议设计、超时重试，每一个主题都能单独写一本书。但实际工作里，你不需要掌握所有细节，你需要的是遇到问题时知道往哪一层看，排查时有清晰的路径，写代码时对每个参数有明确的意图。这恰恰是“调过一个线上问题”和“只看过文档”的本质区别。最后分享一个我个人的小技巧：调试网络问题不要只盯着代码，strace、ss、tcpdump、Wireshark这几个工具至少熟练两个，很多时候真相不在你的代码里，而在系统调用和网络包的时间线里。