1. 先搞清楚网络编程到底在学什么我见过不少新人一开始就扑到 socket API 上写完一个 echo server 就以为自己会网络编程了。其实那只是学了 API 的皮毛真正的核心在于理解数据是怎么在网络里流动的、连接是什么状态、谁负责什么时候发送和接收数据。如果你翻开任何一本网络编程的书第一章基本都是 TCP/IP 协议栈看起来很枯燥但你必须承认一个事实网络上传输的所有数据都是按协议栈的分层规则一层层封装、再一层层解包的。应用层的 HTTP、WebSocket、自定义 RPC最后都会落到 TCP 或 UDP 这两个传输层协议上而传输层又依赖 IP 层和链路层把数据从一台机器搬到另一台机器。我自己的理解是网络编程其实只干三件事建立连接让两个进程之间形成一条可以互相发送数据的管道。传输数据把应用层的数据按照约定好的格式发出去同时从管道里按约定解析对方发来的数据。处理异常连接断开、超时、半包、粘包、对端崩溃这些事情处理不好服务器上线第二天就会出事故。这三件事背后牵扯的知识点才是网络编程的核心笔记。Python 也好C 也好Java 也好语言只是工具协议理解得越深代码写出来越稳。我建议你带着三个问题去学习数据发出去了我怎么知道对方收到了对方发来一堆字节流我如何知道一条消息在哪里结束、下一条从哪里开始连接断开了我怎么第一时间感知到这三个问题后面每一节都会反复涉及。把它们想透比记住每个 API 的签名重要一百倍。2. TCP 连接的建立与断开握手细节在代码里的真实模样这一节要讲的是最容易被忽视却又最能决定系统稳定性的部分TCP 连接的生命周期。2.1 三次握手不是面试题而是你服务器高并发的第一道坎很多教程都把三次握手画成客户端、服务器、SYN、ACK 四个箭头然后草草带过。但在真实项目里,握手失败的原因五花八门客户端在防火墙后面被丢包、服务器 accept 队列满了、半连接队列被攻击者占满……你调 socket 的时候根本看不见这些但它们决定了你的服务能不能扛住几万并发连接。先回顾一下三次握手的实质客户端发送 SYN申请建立连接。服务器收到后返回 SYNACK表示我收到你的请求同时我也请你确认我的接收能力。客户端再回一个 ACK连接建立完成。注意一个关键点服务器在步骤 2 发出 SYNACK 后会把这个连接放到一个叫 accept 队列的地方等待应用层调用 accept() 把它取走。如果应用层迟迟不调 accept或者队列满了内核就会开始丢连接。这就是为什么很多服务器在高并发瞬间会出现 connect 超时但 CPU 和带宽看着都正常——瓶颈可能在 accept 队列。在 Python 里socket 的 listen(backlog) 参数就控制着这个队列长度的上限。很多人写listen(5)或者随便填一个数字压力测试一上来就崩。根据我的经验backlog 至少要设到 128 甚至更高而且要结合内核参数somaxconn一起调整因为内核还会把这个队列截断到somaxconn的限值。import socket server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # backlog 设大配合内核 net.core.somaxconn 一起调 server.listen(256)2.2 四次挥手里最大的坑TIME_WAIT连接断开的过程同样是面试题常客谁先关、谁后关、为什么会有 TIME_WAIT。但在实际运维里TIME_WAIT 多到把端口耗尽才是最常见的生产事故。简单回顾四次挥手主动关闭方发 FIN对方回 ACK对方再发 FIN主动方回 ACK。收到最后一个 ACK 后主动关闭方会进入 TIME_WAIT 状态默认等待 2MSL大约 60 秒后才彻底消失。这么做的原因是最后一个 ACK 可能丢失对方会重发 FIN你得留着这个连接状态来处理重传。所以 TIME_WAIT 是协议设计上的必要机制不是 bug。但问题是如果一台服务器上有大量短连接每一秒都在创建和断开TIME_WAIT 状态的连接会迅速堆积。每个 TCP 连接至少占用一个本地端口端口是有限的默认约 28000 个等 TIME_WAIT 攒满新连接就建不起来了表现就是服务卡死、报Cannot assign requested address。解决方案有几种按优先级排列调整内核参数缩短 TIME_WAIT 的回收时间net.ipv4.tcp_tw_reuse1。开启net.ipv4.tcp_fin_timeout调低超时。最好从源头改让服务端不要频繁创建短连接改用连接池或长连接。我个人强烈建议先改代码再改内核参数。因为tcp_tw_reuse只在客户端有效对服务器端的 TIME_WAIT 堆积帮助有限不要一上来就乱改内核。提示SO_REUSEADDR这个 socket 选项非常实用。它允许新监听套接字绑定到处于 TIME_WAIT 状态的地址上很多服务重启失败就是因为它没被设置。3. 阻塞、非阻塞与 I/O 多路复用选型背后的逻辑网络编程的第二道分水岭就是 I/O 模型的选型。老话说得好阻塞不背锅背锅的是你拿阻塞模式去处理成千上万的并发连接。3.1 阻塞 I/O 为什么简单也为什么危险阻塞模式下recv()调用会一直卡住直到内核缓冲区里有数据。写一个线性处理请求的服务器一次只能服务一个连接这当然简单清晰。但现实是一个进程往往要同时服务几百个连接阻塞模式就废了。解决办法之一是开线程。一个线程处理一个连接代码写起来几乎和阻塞模式一样简单线程数兜底就能扛住几千连接。但线程多了会有新的问题内存开销、上下文切换、锁竞争。尤其 Python 这类语言还受全局解释器锁的限制多线程做网络 I/O 虽然还行但扩展性天花板非常明显。3.2 非阻塞 I/O 和 I/O 多路复用从轮询到事件驱动非阻塞模式下recv()会立刻返回有数据返回数据没数据返回错误码。这意味着你可以在一个循环里轮询所有连接但轮询本身很傻大部分时间都在做无效检查CPU 空转。于是出现了 I/O 多路复用机制把一批套接字交给内核内核告诉我们哪些套接字已经就绪了。最原始的select()一次能监控的连接数有限制通常 1024而且每次调用都要把所有描述符从用户态拷贝到内核态效率不高。poll()去掉了数量限制但拷贝问题还在。真正能扛住几十万连接的是epoll它的关键变化就两点用事件驱动的方式工作连接就绪时内核主动告诉应用不用每次重新遍历全量连接。使用共享内存的方式减少用户态与内核态之间的数据拷贝。不管你是直接用 C 写 epoll还是在 Python 里用 asyncio还是在 Java 里用 Netty底层核心逻辑都是这种事件循环 非阻塞 就绪回调的模型。3.3 实战选型建议如果你只是写一个内部小工具比如定时采集数据的脚本直接阻塞模式也没问题代码可读性最好。如果你的服务器要面对公网流量几百上千的并发连接建议直接用 asyncioPython或者基于事件循环的框架。如果你的系统对延迟和吞吐有极致要求那就得认真考虑上 C/Go/Rust 这一级别的并发模型了。选型逻辑总结成一句话能用简单方案解决就不要上复杂度但一定要知道复杂方案在什么情况下是必需品。4. Python 网络编程实践从 socket 手写到 asyncio 的演进说完了理论直接上手。这一节我从最原始的socket写起一步步演进到 asyncio让你看清 Python 网络编程的完整脉络。4.1 手写一个基础 TCP 服务端先来个最简单的版本阻塞 单线程只适合课堂演示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) while True: conn, addr server.accept() print(fclient connected: {addr}) while True: data conn.recv(1024) if not data: break conn.sendall(data) conn.close()这个代码有两个非常典型的问题。第一它只能服务一个客户端第二个客户端的连接请求会一直等在 accept 队列里。第二recv(1024)只读 1024 字节如果发送方一次发了 3000 字节一次不一定能读完需要循环读。4.2 多线程版本与它的代价把它改成多线程每来一个连接就开一个线程import socket import threading def handle_client(conn): try: while True: data conn.recv(1024) if not data: break conn.sendall(data) finally: 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(128) while True: conn, addr server.accept() threading.Thread(targethandle_client, args(conn,), daemonTrue).start()这段代码能扛住几百个连接但你已经能感受到隐患了每连接一线程1000 个连接就是 1000 个线程。线程不是免费的内存、调度、切换都是成本。而且 Python 的 GIL 让 CPU 密集操作无法并行虽然网络 I/O 能释放 GIL但当线程数量猛增时锁竞争和调度开销依然可观。4.3 asyncio用事件循环替代线程Python 3.4 之后引入 asyncio它解决的就是大量连接 较低的资源开销问题。同样是 echo serverasyncio 写法是import asyncio async def handle_client(reader, writer): addr writer.get_extra_info(peername) print(fclient connected: {addr}) try: while True: data await reader.read(1024) if not data: break writer.write(data) await writer.drain() except ConnectionResetError: pass finally: writer.close() await writer.wait_closed() async def main(): server await asyncio.start_server(handle_client, 0.0.0.0, 9000) async with server: await server.serve_forever() asyncio.run(main())关键区别在于await让出控制权事件循环在等待 I/O 期间会去处理其他连接的数据。这就像一个餐厅只有一个服务员但他眼观六路哪桌喊他就去哪桌而不是一桌派一个服务员杵着等菜。实际用下来asyncio 的坑也有几个。第一个是drain()必须配合write()用否则大量写入时缓冲区塞满数据可能丢失或者内存暴涨。第二个是不要在协程里写 CPU 密集的同步代码比如某些加解密算法一旦阻塞就会卡住整个事件循环所有连接集体变慢。第三个是asyncio.run()是 Python 3.7 的入口老代码里用loop.run_until_complete的写法可以去掉了。4.4 真实项目中我会怎么选如果只是快速验证一个通信逻辑我会直接上 asyncio。如果想要更完善的框架能力比如连接管理、超时控制、协议编解码我会在 asyncio 之上再叠一层封装或者直接用成熟的网络框架。框架的好处是帮你处理了大量边界情况坏处是你得花时间读懂它的模型。无论选什么你对 socket、事件循环、连接状态的理解才是核心竞争力。5. 粘包、半包与协议设计必须踩过的坑网络编程里最让新手崩溃的就是我明明 send 了两条消息对方 recv 到了一条巨长的数据或者我 send 了一条消息对方 recv 了两次才读完。这就是两个经典问题粘包和半包。5.1 为什么会出现粘包和半包TCP 是面向字节流的协议它不关心你的应用层消息边界。发送方调用send()后数据进入内核发送缓冲区内核根据自己的策略决定什么时候把多少字节发出去。接收方调用recv()读到的可能是一个消息的前半截半包也可能是好几条消息拼在一起粘包。这个问题的本质是TCP 只保证字节顺序和可靠性不保证消息边界。所以协议设计者必须在应用层定义消息的边界规则。代码写错了怪 TCP就是个典型误区。5.2 常用的协议编解码方案最常见的方案有四类固定长度消息约定每条消息都是 N 字节不足补零。实现简单但浪费带宽不适合长度差异大的场景。特殊分隔符比如用\r\n或者\n作为消息结束标记。HTTP 的头部就是这种思路但正文长度不定时还得配合 Content-Length。长度字段前缀在每个消息前面先用 4 个字节表示消息体长度然后跟着消息体。这是目前最实用的方案各类 RPC、消息队列内部协议大多采用。自定义头部 变长体在长度前缀的基础上增加消息类型、版本号、校验码等字段适合复杂业务协议。来看一个长度前缀方案的 Python 实现import struct def pack_message(data: bytes) - bytes: # 4 字节无符号整数表示长度 数据本体 length len(data) return struct.pack(!I, length) data def read_message(conn_recv, read_size4096): 从字节流里按长度前缀拆出一条完整消息。 header b while len(header) 4: chunk conn_recv(4 - len(header)) if not chunk: raise ConnectionError(connection closed while reading header) header chunk (length,) struct.unpack(!I, header) body b while len(body) length: chunk conn_recv(min(read_size, length - len(body))) if not chunk: raise ConnectionError(connection closed while reading body) body chunk return body这个read_message函数的关键在于两处循环头部必须收满 4 字节body 必须收满 length 字节。任何一次recv返回的数据不足都要继续读直到凑满为止。这就是解决半包问题的核心思路。5.3 别让缓冲区大小成为性能瓶颈recv(1024)这种写法在工程上要小心。接收缓冲区设得太小大消息要循环读很多次CPU 空转设得太大一次读完多条消息又加重粘包处理难度。合理的做法是接收缓冲区设成一个中等值4KB 到 64KB 之间均可配合上面的长度前缀逻辑用循环把消息拆干净。发送端同理sendall()比send()更安全因为send()不保证一次发完。提示在处理大量小消息时可以把多个消息合并成一个缓冲区再一次性发送减少系统调用次数。这种批量发送技巧在很多高性能框架里都有实现属于优化细活。6. 我踩过的网络编程调试坑与实用经验最后这一节分享一些只有真正跑过生产环境才会注意到的经验。这些内容常规文档里写得少但个个都可能导致线上事故。6.1 服务端地址绑定与重启失败写服务器时如果忘了setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)服务正常关闭后端口还处在 TIME_WAIT 状态立刻重启就会报Address already in use。这不是 Bug是协议机制但很多人不知道一行代码就能规避。在我自己的代码模板里SO_REUSEADDR永远是绑定之前的第一行设置。6.2 半开连接与心跳机制两个现象非常骗人一是客户端直接拔网线服务端完全不知道连接已经失效二是服务端进程崩溃客户端send()会立刻失败但客户端长时间不发数据的话它也不会知道服务端已经没了。TCP 的机制里断开需要双方交互才能被感知物理链路断掉时并没有数据包来告知对端。所以生产系统基本都要做心跳检测应用层每隔一段时间发送一个 ping 消息对端回复 pong连续几次没回复就判定连接已死主动关闭并清理资源。这就是为什么很多协议里有 KeepAlive 字段的底层原因。不要依赖 TCP 自带的 keepalive 选项它的默认周期太长通常两小时对应用来说太慢了。6.3 调试工具比想象中重要我排过最诡异的一个问题客户端一直收不到服务端的完整响应代码看起来逻辑完全正确。最后用抓包工具一看发现服务端发了 8KB 数据客户端recv()之后只处理了前 1KB剩下 7KB 留在内核缓冲区下次recv()才读到。这根本不是网络问题而是应用层没有按消息边界消费数据。在这个排查过程中几个工具帮了大忙netstat -anp看端口监听状态、连接总数、TIMEWAIT 数量。ss -s快速汇总 TCP 连接各状态统计。strace -p pid看进程的系统调用确认阻塞点和返回值。抓包工具看报文内容、重传比例、握手时长判断是网络还是应用的问题。这些工具的使用习惯要早培养。很多问题不用靠猜数据都在报文的细节里。6.4 超时设置必须显式化不设超时的网络程序等于把系统稳定性交给运气。连接建立超时、读写超时、整体会话超时这三个都要在代码里写清楚。Python 的 socket 三件套分别是settimeout()、非阻塞模式配合事件循环、以及 asyncio 的wait_for()。我见过太多线上偶发卡死的案例最后都是因为某个recv()永远在等一个永远不会来的包。超时怎么取值我的经验是分场景局域网内部服务可以给 3-5 秒公网服务要看业务容忍度通常 10-30 秒心跳类消息则必须比正常业务超时短方便快速发现死连接。超时之后的重试策略也很重要一般是指数退避加上限而不是死循环重试。6.5 日志打得好排错早下班最后一条经验网络编程的日志一定要包含足够多的上下文。单打一条connection closed没有任何排查价值。关键信息至少包括对端地址、连接 ID、收发了多少字节、当前处于哪个消息的哪个阶段、错误码是什么。我在实际项目里会把每次消息收发都加一行 trace 日志平时不输出但出问题时打开调试开关立刻能看到全链路。别小看这件事网络问题的定位难点往往在于数据在哪一步出了岔子日志就是定位岔子的路标。以上这些笔记是我从手写 socket 到现在折腾过多种语言各种框架之后沉淀下来的核心内容。网络编程没有捷径你把协议、I/O 模型、协议边界这几个点吃透了再去碰任何框架都不会慌。如果这篇文章能帮你少踩几个坑那这五千多字就没白写。