1. 项目背景与方案选型1.1 为什么还要自己写TCP请求很多人一听到“TCP请求实现”第一反应是现在到处都是HTTP库requests、axios一把梭谁还自己捣鼓TCP这个想法我见过太多次了。但实际情况是HTTP只是TCP之上的一个应用层协议当你真正面对自定义协议对接、长连接维护、实时数据推送、嵌入式设备通信这些场景时数据库连接池、消息队列客户端、工业网关、物联网设备上报底层全是裸TCP。如果只懂HTTP不懂TCP遇到问题和看天书没区别。我做过一个真实的物联网网关项目设备端和服务器通信用的就是私有二进制协议帧头、长度字段、CRC校验全部自定义不用TCP根本无从下手。另一个场景是行情推送服务两万台终端保持长连接服务端推送行情时还会出现半包、粘包问题这种场景下只熟悉HTTP的人大概率会被折磨得怀疑人生。所以这篇博客说的“TCP请求”不是教你重复造轮子而是帮你把TCP客户端和服务端的实现逻辑彻底打通。涵盖的内容包括socket核心API怎么用、三次握手和四次挥手在代码层面意味着什么、粘包拆包怎么处理、连接超时和异常断开怎么兜底、长连接如何做心跳保活。文章会以Python为主要示例语言但核心思路同样适用Java、Go、C因为TCP的设计哲学是跨语言的。1.2 这篇内容适合谁如果你是刚接触网络编程、只会用requests调接口的开发者这篇文章帮你补齐TCP这块最关键的地基。如果你已经在写业务接口、但从来没处理过自定义协议、半包粘包、连接异常恢复这类问题看完可以直接在你的项目里落地。如果你是想进阶的高级开发者文章里关于连接池、读写缓冲、事件模型的分析也能提供一些不同视角的参考。我会用一个贯穿全文的模拟项目来讲解一个“即时消息推送服务”服务端用Python实现客户端模拟设备或终端双方通过自定义的TCP协议通信包含粘包处理、心跳保活、断线重连三个核心要素。这个项目足够典型覆盖了TCP实战中80%的常见需求。2. TCP基础原理与代码层面的映射2.1 三次握手不是理论是状态机先花一段篇幅把TCP握手和代码的对应关系讲清楚。很多人背过“三次握手SYN、SYNACK、ACK”但一写代码就懵——因为socket API把这套状态管理给封装了你感知不到握手过程但它实实在在影响着你的代码行为。在Python里服务端调用listen()之后内核就进入了LISTEN状态操作系统会自动响应客户端的SYN包。客户端调用connect()时操作系统帮你完成了三次握手发送SYN、等待SYNACK、回复ACK。当connect()返回成功连接已经建立可以马上收发数据。这背后的状态机转换是内核自动完成的不需要应用层操心。但有一个关键点很多人没意识到connect()成功只代表握手完成不代表对端应用进程是健康的。如果对端进程已经崩溃但操作系统还活着连接照样能建立成功第一次真正的数据收发才暴露问题。所以写网络程序千万不要把“连接成功”等同于“对端可用”。我在模拟项目里加了一个轻量的心跳机制就是为了弥补这个问题。每次心跳请求如果在超时时间内没收到响应就判定对端不可用触发重连。这个逻辑后面会有详细实现。2.2 四次挥手与半关闭状态的坑连接关闭比建立更微妙。正常情况下主动关闭方调用close()或shutdown()之后TCP会走四次挥手流程主动方发FIN、被动方回ACK、被动方再发FIN、主动方最后回ACK。代码层面常见的坑是客户端发完数据立刻close()服务端可能还在写响应结果刚返回结果客户端连接已断开。另一个坑是close()之后内核会尝试把发送缓冲区里的数据发给对端但如果你有大量数据没发完而直接close()数据可能被丢弃。正确的做法是需要完整收发数据的场景用shutdown(SHUT_WR)配合close()半关闭状态下先停止发送但保留接收等对端关闭后再处理。我在模拟项目的服务端里做了这层处理收到客户端断开请求后先退出接收循环再发送最后的确认信息最后才调用close()。2.3 阻塞与非阻塞理解send和recv的本质TCP的send()和recv()是阻塞的。send()只有在数据被拷贝到内核发送缓冲区后才返回如果发送缓冲区满了调用线程会卡住。recv()如果接收缓冲区没有数据会一直等在那里。这个阻塞特性在生产环境里是致命的——一个连接卡住整个线程就废了。解决方案有两种路线一种是把socket设为非阻塞模式配合select、poll、epoll这些IO多路复用机制来处理多个连接另一种是开多线程每个连接一个线程。Python的asyncio和socket.setblocking(False)结合是现代做法Go语言天生就是goroutine配合非阻塞IO。模拟项目里我用的是selectors库属于IO多路复用比裸多线程更优雅也比纯asyncio更贴近传统socket的理解路径。核心思路是把多个socket注册到一个事件循环里哪个socket有数据可读、哪个socket可写由操作系统通知我们在循环里只处理有事件的连接。3. 环境准备与工程结构设计3.1 实验环境搭建在动手之前先确认你本机的Python版本。我推荐3.8以上原因很简单selectors库在3.4就加入了但3.8之后asyncio的稳定性有明显提升而且3.8之后的f-string调试语法用起来也舒服。我测试用的是3.10向下兼容3.8没有问题。新建一个干净的虚拟环境依赖只有Python标准库不需要安装第三方包。完整的socket编程、线程、选择器调度都靠标准库实现这也能帮你更清晰地理解TCP的本质。提示尽量别在Windows的PowerShell里跑服务端监听Windows的socket实现和Linux有一些细微差异尤其是select在大并发下的表现。建议实验环境使用Linux或macOSWindows环境需要额外注意超时和IO模型差异。工程结构我拆成两个文件一个服务端一个客户端代码量都不大但逻辑完整tcp_demo/ ├── server.py # 推送服务端 └── client.py # 模拟设备终端3.2 协议格式设计从第一步就想清楚写TCP程序之前最该做的是设计好应用层协议。TCP本身是流式协议它只保证字节按序到达不保证消息边界。比如客户端调用send()发送100字节服务端recv()可能一次只收到50字节剩下的50字节下一次才到——这叫半包如果客户端快速发送两次消息服务端recv()可能一次把两段数据都读出来——这叫粘包。处理粘包半包最常用的方案是“长度字段法”每条消息前面固定加4字节存的是正文长度。接收方先读4字节解析出长度再按长度读指定字节数的正文。这个方案简单可靠是我在所有自定义TCP协议里的首选。模拟项目里的消息格式定义如下| 4字节消息长度 | 2字节消息类型 | N字节消息体 |消息类型用整数区分1代表心跳请求2代表心跳响应3代表业务消息推送4代表客户端错误上报。每条消息的总长度就是4 2 N但因为前4字节只存“后面还剩下多少字节”所以长度字段的值是2 N。这里很容易搞混写代码时务必保持一致。4. 服务端实现事件循环与粘包处理4.1 服务端网络骨架服务端要管理多个客户端连接同时还要监听新连接我用的方案是selectors注册监听socket事件循环里区分“可读”事件类型如果是监听socket来事件说明有新客户端连接接受并注册如果是已连接socket来事件说明客户端发来了数据读取并处理。import socket import selectors import struct DEFAULT_PORT 9000 sel selectors.DefaultSelector() def accept(sock): conn, addr sock.accept() conn.setblocking(False) sel.register(conn, selectors.EVENT_READ, read_event) print(f[连接接入] {addr}) def read_event(conn): try: header recv_exactly(conn, 4) if not header: raise ConnectionError(连接关闭) body_len struct.unpack(I, header)[0] body recv_exactly(conn, body_len) handle_message(conn, body) except (ConnectionError, EOFError): sel.unregister(conn) conn.close() print([连接断开] 清理资源) def recv_exactly(conn, n): data b while len(data) n: chunk conn.recv(n - len(data)) if not chunk: raise EOFError(对端关闭连接) data chunk return datarecv_exactly是处理半包的核心函数。它按照期望的字节数循环读取直到读够为止。如果recv()返回空字节说明对端已经关闭连接或网络异常这时必须退出循环并清理资源否则会死循环卡住。事件循环长这样def event_loop(): with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as listener: listener.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) listener.bind((0.0.0.0, DEFAULT_PORT)) listener.listen(128) listener.setblocking(False) sel.register(listener, selectors.EVENT_READ, accept) print(f[服务启动] 监听端口 {DEFAULT_PORT}) while True: events sel.select(timeout1) for key, _ in events: callback key.data callback(key.fileobj)SO_REUSEADDR这个选项值得专门说明一下。如果不加服务端程序退出后端口会进入TIME_WAIT状态马上重启会报“Address already in use”。开发调试阶段几乎必然会撞上这个问题所以一上来就加上这个选项可以省掉很多烦恼。4.2 消息分发处理handle_message根据消息类型分发给对应的处理方法def handle_message(conn, body): msg_type, payload struct.unpack(H, body[:2])[0], body[2:] if msg_type 1: send_message(conn, 2, bpong) elif msg_type 3: print(f[业务消息] {payload.decode(errorsignore)}) send_message(conn, 3, bserver received) elif msg_type 4: print(f[客户端上报] {payload.decode(errorsignore)}) else: print(f[未知消息类型] {msg_type})发送消息时要用struct.pack把长度和类型都编码成固定字节序def send_message(conn, msg_type, payload): body struct.pack(H, msg_type) payload header struct.pack(I, len(body)) conn.sendall(header body)这里用sendall而不是send原因很实际send()只是尝试发送可能只发了一部分就返回sendall()会循环发送直到全部发完函数返回时数据已经全部进入内核发送缓冲区。4.3 一个极其隐蔽的发送缓冲问题事件循环模式下如果业务逻辑需要主动向客户端推送大量数据比如行情推送、实时位置同步而客户端消费速度跟不上sendall()会阻塞而阻塞发生在事件循环线程里会导致所有其他连接全部卡死。这是一个非常常见的生产事故。解决思路有两个层面。第一个层面把每次要发送的数据先写入一个内存队列事件循环只负责检查可写事件真正执行发送动作在可写事件触发后进行。第二个层面如果队列积压超过阈值比如10MB就主动断开这个慢客户端防止内存拖垮服务端。pending_send {} def queue_message(conn, data): conn.setblocking(False) pending_send.setdefault(conn, b) pending_send[conn] data sel.modify(conn, selectors.EVENT_READ | selectors.EVENT_WRITE, read_event)在read_event里每次处理完业务消息如果发现pending_send有数据就调用try_flushdef try_flush(conn): buf pending_send.get(conn) if not buf: return sent conn.send(buf) buf buf[sent:] if buf: pending_send[conn] buf else: pending_send.pop(conn, None) sel.modify(conn, selectors.EVENT_READ, read_event)这个模式的本质是把“可写”也纳入事件驱动。我踩过一次很惨的坑当时没有做写缓冲一个网络慢的客户端直接把整个行情推送线程拖死线上服务雪崩。那次之后我总结了一条铁律——任何可能写大量数据的服务端网络层必须有发送队列。5. 客户端实现连接、发送、重试与心跳5.1 基础客户端连接逻辑客户端核心功能建立连接、发送心跳、接收服务端推送的消息。我用的结构是主线程负责发送后台线程负责接收。import socket import struct import threading import time class TCPClient: def __init__(self, host127.0.0.1, port9000): self.host host self.port port self.sock None self.connected False def connect(self): self.sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.sock.settimeout(5) self.sock.connect((self.host, self.port)) self.connected True self.sock.settimeout(None) print(f[客户端] 连接服务器成功 {self.host}:{self.port})settimeout(5)是连接超时保护。如果服务器不可达或网络异常connect()可能长时间阻塞超时设置能避免线程无限期卡住。连接成功后再把超时改回无限阻塞因为后续接收数据的场景需要长时间阻塞等待推送。5.2 心跳保活的设计逻辑心跳保活要解决的核心问题是TCP连接在空闲一段时间后中间的网络设备可能已经默默释放了这条连接但两端进程完全不知道。比如手机切到WiFi、交换机老化表项超时连接就变成“半开连接”你往里面发数据才会触发RST不发数据就一直以为连接正常。最简单的探测包就是心跳请求。客户端每隔30秒发送一条心跳消息服务端收到后回复心跳响应。如果连续3次心跳没收到响应客户端就认为连接已死主动重连。def start_heartbeat(self): lost_count 0 while self.connected: try: self.send_message(1, bping) lost_count 0 except (BrokenPipeError, ConnectionResetError, OSError): lost_count 1 if lost_count 3: print([客户端] 心跳丢失3次触发重连) self.reconnect() lost_count 0 time.sleep(30)心跳间隔的选择没有标准答案要看业务容忍度。实时性要求高的场景5秒到10秒比较合适外部网络环境差、流量敏感的移动设备可以放宽到60秒。我做的物联网网关项目里用的是15秒因为设备数量多、流量压力大太频繁的心跳会白白消耗带宽和电量。5.3 接收线程与断线重连后台接收线程不能因为一次异常就退出它应该是整个客户端最顽强的部分。我的实现方式是接收线程捕获所有异常通知主线程连接失效然后尝试清理资源重连动作可以由主线程的心跳循环触发也可以由接收线程直接触发。def recv_loop(self): while self.connected: try: header self.recv_exactly(4) body_len struct.unpack(I, header)[0] body self.recv_exactly(body_len) self.handle_message(body) except (ConnectionError, OSError) as e: print(f[客户端] 接收异常: {e}) self.connected False break断线重连还有一个细节很多人会忽略重连之前必须完全关闭旧socket。否则旧的socket文件描述符还占着新连接疯狂尝试建立又会触发大量异常。我在reconnect里先尝试关闭旧连接再创建新的def reconnect(self): print([客户端] 开始重连...) self.close() self.connected True for attempt in range(5): try: self.connect() break except OSError as e: print(f[客户端] 重连失败第{attempt 1}次: {e}) time.sleep(2 ** attempt) else: print([客户端] 重连失败退出) self.connected False指数退避——重连失败后的等待时间是2的attempt次方秒分别是1、2、4、8、16秒。直接用固定间隔会导致大量客户端在同一时刻疯狂重连打爆服务器指数退避能让重连请求在时间上自然分散开。6. 核心问题的根因与排查思路6.1 连接重置 ConnectionResetError 该怎么理解客户端执行业务时突然抛出ConnectionResetError: [Errno 104] Connection reset by peer含义是服务端进程在连接未正常关闭的情况下崩溃或退出操作系统代发了RST包。排查思路要分方向看服务端日志进程是不是异常退出了看服务端代码里是否有未捕获异常导致close()之前就崩溃检查服务端是否主动断开了这个连接比如触发了写缓冲超限、心跳超时检查防火墙或负载均衡器是否空闲超时比较常见的误判是把ConnectionResetError当成普通网络抖动直接忽略结果业务数据静默丢失。连接重置不是抖动它代表对端拒绝承认这条连接必须触发重连和数据补偿机制。6.2 socket.timeout 和 BlockingIOError 的区别socket.timeout只在你显式设置了超时时间后才会出现它表示等待操作超时此时连接本身可能还好好的。而BlockingIOError只出现在非阻塞模式下表示立刻执行无法完成需要进行IO多路复用等待。这两个异常的处理策略完全相反异常类型出现条件处理策略socket.timeout显式settimeout看场景如果是心跳超时可重试如果是读数据超时视业务容忍度决定是否重连BlockingIOError非阻塞模式不应当作异常处理正常进入事件循环等待ConnectionResetError对端RST立即重连补偿数据BrokenPipeError写入了已关闭的socket立即重连丢弃该次写操作或进入补偿流程6.3 半包粘包问题复现与验证为了让你直观理解半包粘包我写过一个最简单的验证脚本客户端循环发送1万条短消息服务端统计收到的消息条数和总字节数。# 客户端发送侧 for i in range(10000): msg fmessage-{i}.encode() body struct.pack(H, 3) msg client.send(struct.pack(I, len(body)) body) # 服务端接收侧错误示范没有按长度精准读取 data conn.recv(4096)这个错误示范的结果是接收到的字节总量正确但解析出来的消息条数远小于1万条因为recv(4096)很可能一次收到多条消息的字节。有些消息还被切断到4096字节边界。正确解法的关键就是前面提到的recv_exactly(4)再recv_exactly(body_len)不管底层怎么分包应用层都能按消息边界拼装完整。这个逻辑必须写成公共函数每个连接的处理流程都走它。6.4 Nagle算法与延迟确认的相互作用还有一个容易被忽视的TCP细节Nagle算法和延迟确认机制的相互作用。Nagle算法会把小的数据包合并成大包减少网络报文数量延迟确认则是对端等在接收缓冲区拿更多数据后再统一回复ACK。这两个机制叠加在某些场景下会造成明显的延迟。比如客户端发一个很小的请求Nagle会等数据攒够一个MSS再发送服务端收到后延迟确认又等数据再回复ACK。你发的每个小包都可能被等住40毫秒甚至200毫秒。如果业务是实时性要求高、每次请求数据量小可以在建立socket后直接关闭Nagle算法client.sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)代价是网络报文数量增加小包占用的带宽开销变大。一般控制面消息、心跳这类请求建议关闭Nagle批量文件传输这种大数据则保持默认配置。7. 性能优化与生产环境经验7.1 连接数突增的承压能力模拟项目的listen(128)在开发环境够用但生产环境如果预计有几千个并发连接要改大这个队列并且内核参数也要调整。listen()的第二个参数是等待accept的连接队列上限如果系统经常出现连接被拒绝或超时观察ss -lnt里的Send-Q积压情况适当调大这个值。Linux内核层还需要调整net.core.somaxconn和net.ipv4.tcp_max_syn_backlog服务端进程的ulimit -n也要同步提升。这个我单独写过一段配置经验sudo sysctl -w net.core.somaxconn1024 sudo sysctl -w net.ipv4.tcp_max_syn_backlog1024 ulimit -n 65535另外每连接一个线程的模式在几百连接时勉强可行过千就需要换成select/epoll单线程模型。Python的selectors默认会用epollLinux下这正是它比裸多线程模型更适合承载高并发的原因。7.2 单条消息大小的边界限制前面的协议里长度字段我用了I这是4字节无符号整数最大能表示42亿多字节。理论上单条消息可以很大但实际使用中必须设置一个合理上限。我踩过一个真实事故因为解析逻辑有bug某个客户端发了一个异常的长度值服务端就傻乎乎地recv_exactly等待接收几十GB的数据把内存和文件描述符全部拖死。生产环境务必设一个max_message_size比如10MB超出则直接断开连接并记日志MAX_BODY_LEN 10 * 1024 * 1024 # 10MB # 在解析长度后校验 if body_len MAX_BODY_LEN: raise ConnectionError(消息体超过最大限制断开)7.3 数据补偿与幂等设计TCP重连之后最麻烦的问题是重连期间服务端下发的数据丢了客户端补还是不补如果业务是顺序性的比如设备状态上报客户端可以把未确认的消息重新发一遍如果业务是实时推送丢了就丢了客户端只需要恢复在线状态即可。我在模拟项目里做了一个简单的待确认队列客户端发送业务消息时先存入本地队列收到服务端确认后移除重连成功后把队列里未确认的消息重新发送。这个模式就是“消息可靠传输”的最小实现很多消息中间件底层思路也是这个。self.pending_queue deque() def send_with_ack(self, msg_type, payload): seq self.next_seq() self.send_message(msg_type, struct.pack(Q, seq) payload) self.pending_queue.append((seq, msg_type, payload)) def handle_message(self, body): # 收到确认消息后从队列移除对应seq注意这里的幂等设计服务端收到重复消息后不能重复处理两次。通常做法是客户端为每条消息生成一个唯一的seq服务端保存最近已处理seq的缓存收到重复seq直接返回成功不下发。8. 常见问题速查与排障实录8.1 速查表症状可能原因动手解决connect总是超时防火墙屏蔽端口、目标不可达、地址写错先用ping和telnet排查网络连通性再检查netstat监听状态服务端启动报Address already in use端口处于TIME_WAIT状态加SO_REUSEADDR或等1~2分钟重启客户端发送消息后服务端收不到Nagle算法缓冲导致小包延迟关闭Nagle或等协议栈自动flush收到的消息截断了半包未完整读取用长度字段循环读取收到的消息拼在一起了粘包未拆分严格按body_len截断长时间空闲后连接已死半开连接、设备NAT表项超时心跳保活客户端显示已连接但服务端看不到服务端accept队列满调整listen大小和内核参数增加服务端处理速度高并发下频繁ConnectionReset单个线程被慢客户端拖死改成非阻塞事件驱动加发送队列8.2 一次完整的现场排查分享一次实际排障过程。某次模拟项目的服务端上线后客户端频繁出现连接重置而且时间是随机分布没有大流量高峰。看服务端日志发现每次RST都伴随select超时触发但客户端已经好几分钟没有发送任何数据。排查过程分几步第一步确认客户端没有崩溃日志显示心跳循环还在跑第二步确认网络没有断开因为客户端完全有正常的外网访问能力第三步抓包发现客户端发出的心跳包到达了服务器网卡但服务端没有任何recv日志。最后定位到问题根源selectors的事件循环里recv_exactly读取的是TCP数据流我在处理心跳消息时把数据读了但没有更新心跳计时服务端的select超时逻辑误把没有数据心跳到达的判断当成连接闲置主动调用了close()。修复方案是在事件循环里记录每个连接的最后活跃时间只有超过阈值才判定为保活失败而不是依赖select超时。这个坑提醒了我一件事被动接收方一定要有独立的活跃时间跟踪不要简单依赖select超时来判断连接状态。8.3 抓包工具是最佳排查伙伴除了代码层面排障我还强烈建议把抓包工具用起来。看TCP握手是否正常、RST来自哪一端、数据包是否被重传都能直接拔高问题定位效率。简单做法是在运行抓包工具命令行下用tcpdump即可tcpdump -i any port 9000 -w tcp_demo.pcap抓完的pcap文件用分析工具打开。重点关注以下内容三次握手是否有重传、收到RST包时对方IP和端口对不对、数据包序列号是否连续、有没有大量快重传。我自己遇到过一个特别诡异的延迟问题业务层完全看不出问题一抓包才发现是因为网络路径上有个设备在做TCP分包重组小包被缓冲到200毫秒才转发。这种情况光盯应用代码是死路一条。9. 扩展方向与最后的一些心得模拟项目的完整实现可以很快在本地跑起来先启动服务端再启动几个客户端观察心跳日志和消息推送到达情况。如果你有兴趣继续深入几个非常值得做的扩展方向把应用层协议从自定义二进制换成与HTTP兼容的长度前缀意味着服务端可以直接复用到HTTP/1.1的帧解析逻辑。另一个方向是给服务端接入真正的消息队列比如把所有收到的业务消息统一扔到队列里做异步持久化。还有一个更进阶的做法把连接事件与日志监控对接分析每个连接的存活时长、消息频率、重连次数用于容量评估和故障定位。最后说说我在实际项目里反复用到、也反复踩坑后总结的几条原则写给你当避坑参考第一TCP编程里永远假设对端随时可能消失。只要有这种心态你就会主动写好超时、重连、数据补偿三件套。绝大多数线上事故都源于“我认为连接好好的”。第二协议设计要在开发之前完成不要边写边改。长度字段用固定字节序、消息类型预留扩展位、所有字段显式定义上限这样才能让两端独立演化。第三任何自定义协议的代码必须加详细注释至少说明字段取值和字节序规则。三个月后回头看自己的代码你会发现没有注释的协议代码完全是一堆不可读的二进制操作。第四先跑通单连接再去优化并发先保证功能正确再调整Nagle、缓冲区、线程模型这些性能参数。顺序反了问题排查会陷入先解决优化、再回来解决崩的循环。写到这里核心内容基本覆盖完整。TCP请求实现这件事看起来基础但由于它处在“语言库函数”和“操作系统内核”的交界处可踩的坑远比表面看起来多。希望这篇内容能帮你少走一些弯路把连接管理、消息解析、异常恢复这套基本功真正打磨扎实。