从 accept 循环到事件驱动：服务端持续监听与稳定运行实践

很多人第一次把服务端跑起来的时候都会遇到同一个怪现象：客户端 A 连上来收发正常，客户端 B 一连上来，要么一直卡在连接中，要么连上了却永远收不到回应。代码看着没毛病，端口也在监听，日志也不报错——问题就出在“监听”这两个字上。socket、bind、listen只是把门牌挂出去，真正让人进门的是后面那个不停转的循环。这一节要聊的就是怎么让服务端持续监听客户端请求：从最小的死循环骨架，到多线程、事件驱动，再到连接队列、错误码处理、断线检测和优雅停机，把这些串起来，你才算真正把“服务端”跑稳了。适合刚写完第一个 demo 的同学，也适合已经用上框架但说不清底层在干什么的同学。

1. 从“只能服务一次”的最小示例说起

1.1 一个只能服务一次的服务器长什么样

先看一段几乎所有人入门时都写过的东西。这段代码能跑，telnet连上去也能收到回显，但只要第一个客户端退出，整个进程就结束了，或者第二个客户端连上来永远没反应。

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(128) conn, addr = server.accept() # 只接一次 data = conn.recv(1024) conn.sendall(b"echo: " + data) conn.close() server.close() # 连监听套接字一起关掉

问题一目了然：accept()只调用了一次，server.close()把门牌都摘了。把这两行改掉，外面套一个while True，就是最朴素的持续监听。

while True: conn, addr = server.accept() try: while True: data = conn.recv(1024) if not data: break conn.sendall(b"echo: " + data) finally: conn.close()

这段改动只有几行，但它包含了持续监听最核心的两个嵌套结构：外层循环负责“等新连接”，内层循环负责“把这一条连接的数据读完”。很多线上事故的根因，就是把这两层循环写混了——在外层循环里做了阻塞读，结果一个客户端不说话，所有新连接全排队。

记住一个判断标准：accept()返回的conn是“某一条连接”，server是“整台服务器的门”。门的生命周期应该覆盖整个进程，而conn的生命周期只覆盖这一次会话。

1.2 listen 之后内核替你做了哪些事

listen()这个调用名字很有迷惑性，听起来像“开始监听”，实际上它做的是两件事：把套接字从主动连接状态切换成被动监听状态，以及在内核里开辟两个队列。客户端的三次握手是内核替你完成的，你的进程根本不知道有连接进来，直到你调用accept()从队列里把它取出来。

这就解释了一个很多人困惑的现象：服务端进程卡在某个耗时操作上十几秒没动，可是netstat里能看到一堆ESTABLISHED连接。这些连接已经握手完成，躺在内核的全连接队列里，只是应用层还没来得及accept。内核不会因为你没accept就拒绝握手，它只会等到队列满了之后再决定怎么办。

理解这一层之后，你对“持续监听”的理解就应该从“循环调用 accept”升级为“让全连接队列不被堵死”。循环调用的频率、每次accept之后处理连接的方式，都会影响队列的消耗速度。这也是为什么后面要讲多线程和事件驱动——它们的本质目的都是让accept这个动作尽可能快地回到循环里。

还有一点容易忽略：accept拿到的conn是一个全新的文件描述符，它继承了监听套接字的部分属性，但从内核角度看它是独立对象。你关掉conn不会影响server继续接受新连接，反过来关掉server也不会立刻杀掉已经建立的conn（这点在讲优雅停机时会用到）。

2. 阻塞在 accept 上的那一刻发生了什么

2.1 三次握手与两个队列的分工

把服务端的连接接收过程拆开看，其实是两段流水线。第一段是内核的：客户端发SYN，内核回SYN+ACK，连接进入半连接队列（SYN 队列）；客户端回ACK，连接从半连接队列移到全连接队列（accept 队列）。第二段是应用的：你调用accept()，从全连接队列头部取出一个连接，内核为它创建新的套接字，返回给你。

这两个队列的长度限制不一样，调优参数也不一样。全连接队列的上限是listen()的 backlog 参数和系统参数somaxconn的较小值；半连接队列的上限由tcp_max_syn_backlog控制。实际排查时经常遇到“客户端连不上但服务端 CPU 很闲”的情况，八成是全连接队列满了，此时内核的处理策略取决于tcp_abort_on_overflow：默认是 0，也就是默默丢掉客户端的 ACK，让客户端以为丢包了去重传，表现出来就是“连接特别慢，但偶尔能连上”；设成 1 就直接回 RST，客户端立刻收到 connection reset。

这里有个实操上的关键点：全连接队列满，责任大部分在应用层。队列消耗速度取决于你多久accept一次，如果你在两次accept之间插入了几百毫秒的数据库查询，队列就是在替你扛这段延迟。

2.2 backlog 参数不是“最大连接数”

几乎每一份教程都会写listen(128)，但很少有人解释这个 128 到底是什么。它不是最大并发连接数，而是尚未被 accept 的已完成连接队列长度。已经 accept 的连接不再占这个名额，所以一个服务端同时维持一万条长连接完全可能，只要 backlog 别太小、accept 别太慢。

那 backlog 该给多少？我的经验是按“最坏情况下 accept 的停顿时间 × 峰值新建连接速率”来估。假设峰值每秒新建 2000 条连接，你代码里最坏有 50ms 没回到 accept，那队列需要扛住约 100 条，给 512 或 1024 是安全的。但如果你的服务端是那种“accept 之后同步处理 3 秒才回来”的写法，backlog 给到 65535 也救不了你——队列只是缓冲，不是处理器。

还有一个常见的坑：在 Python 里listen(0)是合法的，Linux 会把它当成 1 处理（有的内核版本直接给你最小值）。曾经有人把 backlog 设成 0 以为表示“无限”，结果压测时连接大面积超时，排查了半天才发现是这个参数。“无限”在 backlog 这个参数上不存在，最大值受somaxconn限制，需要改的话得动/proc/sys/net/core/somaxconn。

3. 三种持续监听的骨架，先选对再优化

3.1 单线程死循环：别急着否定它

一提“单线程循环处理”，很多人第一反应是“这不行，会阻塞”。但在某些场景下它恰恰是最优解：连接数少、每条连接处理极快、且处理逻辑本身是纯 CPU 的短任务。比如一个内网的健康检查端点、一个只做协议转换的转发器，单线程循环完全够用，而且没有并发带来的任何状态一致性问题。

单线程循环的关键在于内层读循环必须设超时，否则一个恶意或故障客户端连上来不发数据，就能把整个服务端钉死。做法是给conn设置SO_RCVTIMEO：

conn.settimeout(30) # 30 秒没数据就抛 socket.timeout

设置超时之后，recv抛异常你需要单独处理，不能一把except Exception吞掉了事，因为超时和连接重置是两种完全不同的语义，前者可能只是客户端在思考，后者是真的断了。我的习惯是把超时异常单独捕获，记录一条日志后决定是继续等还是断开。

单线程循环还有个隐性成本：你无法处理并发连接。第二个客户端连上来时，如果第一个客户端正在传输一个大文件，第二个只能干等。这不是“慢一点”的问题，是“完全没响应”的问题。判断标准很简单：如果你的业务里存在任何一次操作可能超过 100ms，就不要用单线程循环。

3.2 每连接一线程：中小规模里最省心的选择

改成每来一个连接就开一个线程，代码改动极小，心智负担也低——每个连接的处理逻辑写起来就像写单机程序一样自然。

import threading def handle(conn, addr): try: conn.settimeout(60) while True: data = conn.recv(4096) if not data: break conn.sendall(b"echo: " + data) except (socket.timeout, ConnectionResetError): pass finally: conn.close() while True: conn, addr = server.accept() t = threading.Thread(target=handle, args=(conn, addr), daemon=True) t.start()

这套结构能撑住的量级，实测在几百到一两千条活跃连接之间，取决于每条连接的活跃程度和单次处理耗时。线程本身不贵（Linux 上默认栈 8MB 是虚拟内存，实际占用小得多），贵的是线程切换和每个线程阻塞时的栈驻留。连接数上了万，线程模型的调度开销就开始明显，这时候才轮到事件驱动出场。

用线程模型有几个必须注意的点。一是daemon=True，否则主线程退出时子线程会让进程挂住不结束。二是线程里的异常必须自己兜住，未捕获的异常只会打印一行堆栈，线程就静默退出了，连接变成半死状态，很容易被误判成客户端问题。三是连接对象的归属要清晰，conn.close()只能由一个地方负责，我吃过这个亏：主线程在超时清理时关了连接，工作线程同时也在用，结果抛出莫名其妙的错误。现在我的统一做法是——谁 accept 出来谁不管，连接的生命周期完全交给工作线程的finally。

3.3 事件驱动：epoll 到底在替你省什么

上万连接的时候，线程模型的瓶颈不是“线程不够”，而是“大部分线程都在睡”。一万条连接里可能只有几十条在真正收发数据，剩下九千多条都阻塞在recv上，白白占着栈和调度资源。事件驱动换了个思路：把所有套接字交给内核统一看管，谁有数据谁才被叫醒。

Linux 上是 epoll，macOS 上是 kqueue，Windows 上是 IOCP，Python 的selectors模块把它们统一了。核心结构长这样：

import selectors, socket sel = selectors.DefaultSelector() def accept_cb(sock): conn, addr = sock.accept() conn.setblocking(False) sel.register(conn, selectors.EVENT_READ, handle_cb) def handle_cb(conn): data = conn.recv(4096) if not data: sel.unregister(conn) conn.close() return conn.sendall(b"echo: " + data) server = socket.socket() server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind(("0.0.0.0", 9000)) server.listen(1024) server.setblocking(False) sel.register(server, selectors.EVENT_READ, accept_cb) while True: for key, mask in sel.select(): key.data(key.fileobj)

这套骨架最容易被忽略的一步是setblocking(False)。忘了这一步，你在回调里一次recv就可能把整个事件循环卡住，比线程模型的阻塞更致命，因为它卡的是所有连接。事件驱动的前提是“所有 I/O 都不许阻塞”，任何一次绕过这个约定的调用都会让整个服务端失去响应。

用 C 直接写 epoll 时，最大的坑在触发模式上。水平触发（LT，默认）只要缓冲区还有数据，每次epoll_wait都会返回，写起来安全；边沿触发（ET）只在状态变化时通知一次，性能略好，但要求你必须一次把数据读到EAGAIN为止，并且accept也要循环调用到EAGAIN。ET 模式下如果只accept一次，多个连接同时到达时剩下的连接会永远滞留在队列里，表现就是“压测时丢连接，但服务端看起来很闲”。这个 bug 极其隐蔽，因为它不报错。

4. 让循环真正死不掉：错误码与资源回收

4.1 EINTR、EAGAIN、EMFILE 分别该怎么应对

持续监听的代码写得再漂亮，一旦错误处理偷懒，跑了三天之后必然翻车。三个错误码必须分清楚。

第一个是EINTR，表示系统调用被信号打断。监听进程收到SIGCHLD、SIGTERM之类的信号时，阻塞中的accept会中断并返回这个错误。这不是真错误，重试就行。Python 3.5 之后大部分系统调用会自动重试，但用 C 写或者用select/epoll时还是得自己判断。

第二个是EAGAIN和EWOULDBLOCK，在 Linux 上它们是同一个值，表示“现在没数据，回头再说”。非阻塞模型下它是正常的控制流，不是异常，不能用它去关闭连接。

第三个是EMFILE，进程的文件描述符用完了。这个最难处理，因为此时你连“拒绝这个连接”都做不到——accept都调不了。经典的兜底做法是预留一个文件描述符：启动时打开一个/dev/null占位，accept撞到EMFILE就先关掉这个占位符，accept拿到连接后立刻关掉，再重新打开占位符。这样至少能给客户端返回一个明确的错误响应，而不是让它傻等。

# 伪代码示意思路 try: conn, addr = server.accept() except OSError as e: if e.errno == errno.EMFILE: devnull.close() conn, addr = server.accept() # 抢占到一条 conn.sendall(b"server busy") conn.close() devnull = os.open(os.devnull, os.O_RDONLY)

排查EMFILE的第一步不是加大ulimit，而是确认是不是有连接没关。见过太多案例最后定位到某个异常分支漏了close，ulimit调到十万也顶不住泄漏的速度。

4.2 描述符泄漏的现场诊断

判断有没有泄漏，最简单的方式是持续观察/proc/<pid>/fd下的文件数量，或者用lsof -p <pid> | wc -l。健康状态下这个数字应该在一个区间内波动；如果它随连接数单调递增、连接断开后也不回落，基本可以确定有泄漏。

进一步定位可以看状态分布：ss -tan state close-wait数一下有多少。CLOSE_WAIT的含义非常明确——对端已经发了 FIN，本端内核回了 ACK，但应用层始终没调用close()。这个状态堆积，百分之百是代码问题，不是网络问题，也不是内核参数问题。我遇到过的一个典型场景是：处理函数里用了return提前退出，绕过了finally里的close。改成上下文管理器之后就再没出现过。

一个实用习惯：把“打开连接”和“关闭连接”写在同一个函数里，用try/finally或者with包住，不要让它们分散在两个函数中。泄漏几乎都发生在两者分离的地方。

5. 连接“断了”和“你以为它断了”是两回事

5.1 对端悄悄消失时 recv 返回什么

持续监听的服务端有个绕不开的问题：客户端不是因为close()走的，而是因为网线拔了、手机切飞行模式、进程被kill -9了。这时候服务端收不到 FIN，recv也不会有任何返回，连接就永远挂在那里，占着线程和内存。这就是半开连接。

区分几种情况很有用。对端正常close时，recv返回空字节串（长度为 0），这是最干净的结束信号。对端kill -9时，内核会补发 RST，recv抛ConnectionResetError。而对端网络静默消失时，recv就只是永远阻塞或者一直返回EAGAIN，没有任何错误。

后两种情况只能靠超时机制兜底。SO_RCVTIMEO能让recv在指定时间后抛出超时异常，这样至少循环不会永久卡住。但要注意，超时只能说明“这段时间没数据”，不能等同于“连接已死”——如果一个长连接的业务本身就是低频通信，把超时设成 30 秒会误杀大量正常连接。这就是为什么需要心跳。

5.2 心跳与超时的取舍

TCP 本身带 keepalive，但默认的空闲时间是7200 秒，两小时才探测一次，对绝大多数业务来说毫无意义。可以调，tcp_keepalive_time等等，但它是全局参数，而且探测间隔和次数不够灵活，所以我一般不用它做业务层存活判断。

应用层心跳是我更推荐的做法：客户端每隔 N 秒发一个固定的心跳包，服务端维护每条连接的最后活跃时间，后台线程每隔一段时间扫一遍，超时没活跃的就主动断开。参数怎么定？我的经验值是心跳间隔 15~30 秒，超时判定为心跳间隔的 2.5 到 3 倍。这样能容忍一次偶发丢包，又不至于让死连接占着资源太久。

心跳包尽量小，几个字节的固定魔数就够，别在里面塞 JSON。而且心跳包要和处理逻辑共用同一条连接，不要另开端口——另开端口意味着你要维护两套连接状态的对应关系，复杂度陡增，收益几乎为零。还有一点，服务端收到心跳应该更新活跃时间，但不要每次都回心跳响应，除非客户端确实需要确认链路通畅，否则双向心跳会把带宽和 CPU 白白翻倍。

6. 优雅停机：循环停下之后的那几秒才见功力

6.1 信号处理与监听套接字的收尾顺序

Ctrl+C是最粗暴的停机方式，直接抛KeyboardInterrupt，正在处理的连接全断，缓冲区里的数据全丢。生产环境要的是优雅停机：接住SIGTERM，停止accept新连接，把手上的连接处理完，再退出。

顺序不能乱。第一步是关闭监听套接字，这会让阻塞在accept上的循环抛异常或者返回，循环退出；第二步是等待活跃连接数归零，用计数器或者条件变量；第三步才是关闭剩余连接、释放资源。如果先关连接再关监听，这段时间新来的连接会被内核接受但没人处理，客户端体验极差。

import signal, threading shutdown = threading.Event() def on_term(signum, frame): shutdown.set() signal.signal(signal.SIGTERM, on_term) signal.signal(signal.SIGINT, on_term) while not shutdown.is_set(): try: server.settimeout(1.0) # 让 accept 周期性返回，便于检查标志位 conn, addr = server.accept() except socket.timeout: continue ...

把accept设成带超时是个很实用的小技巧：既不用依赖信号打断的细节差异，又能让循环在 1 秒内响应停机信号。代价是每秒一次空转，几乎可以忽略。

6.2 停不下来的时候，先看谁在占着连接

优雅停机最常见的问题是“等不到归零，最后超时强杀”。原因通常是某条连接的读循环没有退出条件。这时候需要一个整体截止时间：比如最多等 30 秒，时间到了不管连接状态如何，统一强制关闭。这个兜底逻辑一定要有，否则一个卡住的连接就能让整个发布流程挂在那里。

我在实际操作中的体会是，停机逻辑的测试成本远高于编写成本，因为平时根本触发不到。比较省事的做法是在开发环境里加一个内部命令或者测试接口，专门触发停机流程，然后模拟各种连接状态（空闲的、传输中的、半开的）跑一遍，看是不是每次都能在预期时间内退干净。

最后再补充一个小技巧：停机时把监听端口从bind列表里彻底释放之前，先确认TIME_WAIT的影响。所以重启频繁的服务一定要设SO_REUSEADDR，最好在bind之前就设上，不然你会看到“端口被占用”这种明明进程已经退出的诡异报错。这个问题我踩过不止一次，每次都是同一个原因——加了SO_REUSEADDR之后才彻底消停。