最近好几个朋友问我怎么用 Python 做网络通信说网上教程看着不少但真到自己写的时候连socket.bind()报错都不知从哪查。其实Python内置的socket模块是学习网络通信底层原理最好的入门工具——它把TCP和UDP那套流程全暴露在你面前比一上来就套Flask、Twisted这些高级框架更能让人看清本质。这篇内容适合刚接触网络编程、想弄明白服务端和客户端怎么对话以及那些被OSError、Address already in use折腾过的人。我把从原理到实战再到踩过的坑一次性讲透。Python Socket网络通信详解1. 网络通信的基础Socket到底是什么Socket这个词直译是“插座”但很多人理解成“端口”就有点偏了。我更愿意把它看成两个进程之间的一条数据管道——不管是同一台机器上的两个进程还是隔着几台服务器只要协商好了IP和端口就能通过这条管道把字节流传来传去。要理解Socket得先分清TCP和UDP。TCP是面向连接的打个比方就像打电话得先拨号、对方接通、双方确认“喂喂能听到吗”然后才开始说话说完还要挂机。UDP则像寄快递你把包裹写上地址扔进快递柜能不能送到、多久送到全看运气和网络状况没有确认机制。Python里面用socket模块来创建套接字核心就三个要素协议族family、套接字类型type、协议protocol。最常见的是IPv4加TCP也就是AF_INET加SOCK_STREAMIPv4加UDP则是AF_INET加SOCK_DGRAM。底层调用的是操作系统提供的BSD Socket接口所以你在Linux、macOS、Windows上写代码API几乎一模一样。你可能会问那我直接用requests库访问网页或者用pymysql连数据库是不是就不涉及Socket了恰恰相反这些库底层全都在用Socket只不过帮你封装好了。搞清楚Socket原理等于看清了所有网络通信的“底牌”。2. 环境准备与API全景图先看一张地图再出发2.1 Python环境的搭建要点实操之前先确认环境没问题。Python的socket模块是标准库装完解释器就有不需要pip额外安装。但很多人的麻烦出在环境本身——装错版本、多版本并存、环境变量没配好编译时一通报错。我的建议是直接用Python 3.8以上版本在官网下载安装时**务必勾选“Add Python to PATH”**那个选项。这个勾选决定了你在命令行里敲python能不能直接进交互环境。装完之后在终端里跑一下python --version看到输出版本号就说明OK没看到就去检查环境变量PATH里有没有Python的安装路径。这个坑我在Windows上踩过不止一次明明能进IDLE但命令行就是不认。如果你需要同时管理多个Python版本建议用conda或者pyenv单独建环境。比如conda create -n socket_demo python3.11 conda activate socket_demo这样后续跑网络编程的测试脚本不会和系统级的Python搞混。2.2 核心API速查你必须掌握的8个方法掌握列表之后再看代码就不会被面试笔试题里的细节绊住了。主要流程是服务端和客户端各自做四件事服务端socket()创建套接字 →bind()绑定IP和端口 →listen()监听连接 →accept()接受连接客户端socket()创建套接字 →connect()发起连接 →send()/recv()收发数据 →close()关闭连接方法作用核心注意点socket(family, type)创建套接字默认参数即TCPbind(address)绑定地址address是(host, port)元组listen(backlog)监听连接backlog是连接等待队列长度accept()接受一条连接返回(conn, addr)二元组connect(address)客户端发起连接目标必须是已绑定的地址send(data)发送数据注意可能没全部发送完recv(bufsize)接收数据返回bytes空表示对端关闭setsockopt(level, opt, val)设置套接字选项最常用SO_REUSEADDR其中recv()有个容易误解的点它接收的是字节流不是消息包。TCP是流协议你send两次对端可能一次recv就全读走也可能分三次读走。这给很多人造成了困惑后面我在实际操作部分会专门讨论怎么处理这种“粘包”问题。2.3 理解阻塞与非阻塞模式刚接触Socket的时候最不适应的就是默认的阻塞模式——程序执行到accept()或recv()就停住了等数据来了才继续跑。比如recv(1024)没收到数据整个进程就卡在那里。非阻塞模式一般用两种方式实现一是setblocking(False)把套接字设为非阻塞没数据就立刻抛异常二是用select、poll这些IO多路复用接口同时盯着多个套接字。后面我会用一个多客户端并发场景演示这里先建立概念阻塞模式逻辑简单但并行处理多个客户端时会成为瓶颈非阻塞加多路复用是性能提升的关键方向。3. TCP服务端与客户端从零搭一个可用的场景3.1 先写一个最简单的TCP回显服务端很多人看教程上来就是一大段框架代码反而把基础结构掩盖了。我习惯从最朴素的版本开始写——做一个“回声服务”客户端发什么服务端原样返回什么。别小看这个过程它能让你看清服务端每一行代码的意义。import socket # 创建一个TCP套接字 server_sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 设置地址复用避免“Address already in use” server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 绑定到本机9000端口 server_sock.bind((127.0.0.1, 9000)) # 开始监听最多允许5个连接等待 server_sock.listen(5) print(服务端已启动等待客户端连接...) while True: # 接受一个客户端连接 conn, addr server_sock.accept() print(f新连接来自: {addr}) # 循环处理数据 while True: data conn.recv(1024) if not data: print(f{addr} 已断开) break # 原样回发 conn.send(data) conn.close()这段代码里accept()每次只处理一个客户端。当第一个客户端建立连接后后面的客户端只能排队等这就是阻塞模式的局限。如果想验证它确实能跑可以先在命令行启动这个脚本再用另一个终端敲telnet 127.0.0.1 9000连上看效果。3.2 客户端代码与三次握手的直观理解客户端的代码要更简单些import socket client_sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) client_sock.connect((127.0.0.1, 9000)) client_sock.send(bHello, this is my first socket message) response client_sock.recv(1024) print(f收到回显: {response.decode()}) client_sock.close()运行之后客户端打印出“收到回显: Hello...”。这个看似简单的过程本质上走完了TCP的三次握手客户端发送SYN包请求建立连接。服务端收到后回复SYNACK表示“收到我也准备好了”。客户端再回一个ACK双方进入连接状态。connect()方法返回的时候三次握手已经完成。而accept()能拿到这个连接则意味着连接已经进入“已建立”状态。这里有个细节send()返回的是实际发送的字节数。TCP不保证你一次send多少就发送多少因为受限于滑动窗口和MSS最大报文段大小。严谨的做法是用循环确保所有数据都发出比如def send_all(sock, data: bytes): total_sent 0 while total_sent len(data): sent sock.send(data[total_sent:]) if sent 0: raise RuntimeError(socket连接中断) total_sent sent同理recv(1024)里的1024只是“最多读这么多”不表示一次读完对方发的所有数据。等下讲到粘包问题时我会给出相对完整的方案。3.3 处理多个客户端用threading实现简单并发实际项目中不可能只服务一个客户端。最简单的办法是每来一个连接就开一条线程处理import socket import threading def handle_client(conn, addr): print(f处理连接: {addr}) while True: try: data conn.recv(1024) if not data: break conn.send(data) except ConnectionResetError: break 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(5) while True: conn, addr server.accept() thread threading.Thread(targethandle_client, args(conn, addr)) thread.start()这种模式是经典的thread-per-connection。好处是代码直观每个连接互不干扰坏处是并发量大了之后线程开销大达到几千个连接时内存和上下文切换就成了负担。如果是写小工具、内部局域网项目这个方案完全够用。在高并发生产环境一般会用asyncio或者selectors模块去改造。4. UDP通信轻量场景的最优解4.1 UDP服务端和客户端的差异TCP的流程是“先连接再通信”UDP则没有连接概念。它就像寄快递服务端只需要bind一个端口然后不停地接收来自任何地址的报文客户端不需要connect直接sendto()把数据交给网络。来看UDP服务端import socket udp_server socket.socket(socket.AF_INET, socket.SOCK_DGRAM) udp_server.bind((127.0.0.1, 9001)) print(UDP服务端已启动...) while True: data, addr udp_server.recvfrom(1024) print(f来自{addr}的消息: {data.decode()}) udp_server.sendto(data, addr)客户端import socket udp_client socket.socket(socket.AF_INET, socket.SOCK_DGRAM) udp_client.sendto(bhello udp, (127.0.0.1, 9001)) data, addr udp_client.recvfrom(1024) print(data.decode())注意区别UDP用recvfrom()而不是recv()返回的不只是数据还有发送方地址发送用sendto()必须指定目标地址因为连接不是固定的。4.2 什么时候选UDP而不是TCP很多人习惯“能用TCP就不用UDP”其实场景不同不能一刀切。UDP的优点是无连接、无状态、延迟低很适合这几类场景音视频通话丢几个包还能听但延迟高了体验极差。实时游戏状态同步位置信息每秒更新几十次用TCP的可靠性重传反而会让画面卡顿。DNS查询DNS本身用的就是UDP一次请求一个包一问一答。局域网设备发现比如你的手机通过广播消息找智能家居设备广播本身用的是UDP。要说缺点也很明确UDP不保证可靠交付丢包、乱序、重复都可能发生。所以需要在应用层自己设计确认、重传、序号等机制。如果数据完整性要求高比如文件传输、数据库同步那还是老老实实走TCP。4.3 一个实用案例用UDP做设备健康监测我之前做过一个内部小工具用UDP轮询局域网内几台Linux服务器的存活状态。每台机器上跑一个轻量脚本每5秒向监控端发送自己的CPU和内存占用率。监控端收到就更新状态超过15秒没收到就标记掉线。这样做的关键好处有三个第一UDP不用维持一堆TCP连接服务端不用为每台设备维护状态第二即使某几帧数据丢失下一帧马上会来不影响整体监控第三代码量很小客户端几十行就够。这种场景用TCP反而特有劣势——连接断了要重连重连期间的监控就是空窗期。5. 进阶实操粘包处理、缓冲区与可靠传输改良5.1 什么是粘包为什么会出现粘包是TCP新手最容易遇到的坑之一。前面说了TCP是字节流协议它不关心你的业务数据怎么切分只负责把字节按顺序送到。如果客户端连续发了三次数据服务端可能一次recv()就拿到三批数据的拼合体或者第二次收的时候拿到后半截。一个经典面试场景客户端发送send(bAAA)、send(bBBB)服务端recv(1024)很可能直接拿到bAAABBB。你想按消息去解析结果对不上。根本原因在于TCP的send()只是把数据写进了内核发送缓冲区至于对端什么时候读到、读到多少完全由网络状态和对端接收时机决定。5.2 给数据加“信封”自定义消息格式解决粘包问题的通用思路是定长消息头加消息体——发送方在发数据之前先给数据加上一个固定长度的长度字段接收方先读长度再按长度读消息体。就像寄包裹时先在信封外写明重量收到的人才知道要拆开多少。import struct def pack_message(data: bytes) - bytes: 将数据打包为: 4字节长度 原始数据 length len(data) return struct.pack(I, length) data def recv_exact(sock, n: int) - bytes: 可靠地读取n个字节 chunks [] remaining n while remaining 0: chunk sock.recv(remaining) if not chunk: raise ConnectionError(连接中断) chunks.append(chunk) remaining - len(chunk) return b.join(chunks) def recv_message(sock) - bytes: 接收一条完整消息 length_data recv_exact(sock, 4) length struct.unpack(I, length_data)[0] return recv_exact(sock, length)这里用了struct.pack(I, length)把数据长度转成4字节无符号大端整数。大端序在网络传输中是标准约定跨语言通信时大家都认这个格式。你还可以在消息头里增加消息类型、版本号等字段让协议更完善。5.3 用SO_REUSEADDR和超时机制减少崩溃很多初学者在调脚本时都遇到过这个报错OSError: [Errno 98] Address already in use原因很简单服务端上次运行结束后TCP连接并没有立即完全消失内核里还残留着TIME_WAIT状态。这时候立刻重新bind同一个端口就会被拒绝。解决办法就是第3个章节代码里写过的setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)。这个选项允许内核在套接字还没有完全释放时重新使用端口对开发调试非常有用。另外阻塞模式的recv()有个隐患如果对端一直不发数据服务端会永远卡住。为了应对不可靠客户端可以设置超时时间conn.settimeout(5.0) try: data conn.recv(1024) except socket.timeout: print(客户端5秒没发数据关闭连接) conn.close()加了超时后即使对端失联服务端也能主动清理连接不至于线程越积越多。5.4 多线程并发的封装建议如果每次都要手写循环收消息再按长度拆包很容易出错。实际项目中我会把常用的逻辑封装成一个简单的类核心API暴露出来class TCPServer: def __init__(self, host127.0.0.1, port9000): self.host host self.port port self.running False self.server socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) def start(self): self.server.bind((self.host, self.port)) self.server.listen(10) self.running True print(fServer listening on {self.host}:{self.port}) while self.running: conn, addr self.server.accept() threading.Thread(targetself._handle, args(conn, addr), daemonTrue).start() def _handle(self, conn, addr): with conn: while True: try: msg recv_message(conn) response self.on_message(msg) conn.send(pack_message(response)) except ConnectionError: break def on_message(self, msg: bytes) - bytes: return msg # 子类重写这个方法 def stop(self): self.running False self.server.close()把核心流程封装好之后业务逻辑就只集中在on_message()一个方法里。这个方案的思路其实和很多主流网络框架殊途同归只是更容易让人看透每一层在干什么。6. 常见问题与故障排查实录6.1 高频报错实例对照表我在帮人调试各种Socket项目时总结了一套频率极高的报错组合这里整理成速查表报错信息常见原因解决方案Address already in useTIME_WAIT残留或端口被占用加SO_REUSEADDR或换端口Connection refused服务端没启动或端口不对检查服务端状态、防火墙Connection reset by peer对端强制关闭或数据没接收完就close在业务上做异常捕获timed out网络不通或服务端没响应检查防火墙确认IP可达[WinError 10048]Windows上端口被占用netstat查看占用并关闭进程Windows和Linux的报错格式不太一样但本质一致。比如Windows下最常见的是[WinError 10048]对应Linux的errno 98 Address already in use。6.2 实战排查思路从现象到根本原因遇到问题不要瞎试我一般按“三看”来排查一看端口用netstat -an | grep 端口Linux/macOS或netstat -ano | findstr 端口Windows检查端口是否被监听。如果是自己之前的服务占着杀掉进程再重启。二看防火墙把监听地址换成0.0.0.0后局域网内其他机器连不上多半是防火墙拦了端口。Linux下用firewall-cmd --list-ports查看Windows在“高级安全Windows Defender防火墙”中添加入站规则。三看代码逻辑确认发送方send了数据但接收方recv阻塞多半是消息长度没对上。检查一下是否用了结构化的粘包处理方案还是一股脑地recv(1024)。6.3 两个容易忽略的隐蔽问题第一个是对端半关闭状态。客户端执行shutdown(socket.SHUT_WR)只关闭发送方向服务端还能往客户端发数据。但close()是全关闭会同时断开两个方向。第二次实际处理文件传输协议时如果误用close()接收方可能还没读完数据连接就断了。第二个是缓冲区大小限制。如果想用socket.recv()接收超大文件传一个很大的bufsize其实不安全因为底层缓冲区有内核限制。更好的方案是循环读取并写入文件一点点积累def recv_file(sock, file_path): with open(file_path, wb) as f: while True: data sock.recv(65536) if not data: break f.write(data)每次读64KB是个不错的折中既不频繁调用内核也不占用过多内存。7. 其他语言与场景的对照理解Socket的通用性7.1 与C#异步回调的对比搜热词时看到有人提到“C# socket bigging receive回调”其实讲的是C#里用BeginReceive做异步接收。核心思路和Python里用asyncio或起线程很像都是为了避免主线程阻塞在等待数据上。C#的经典写法是给Socket绑定一个回调函数收到数据后触发而Python里对应方案要么用selectors模块注册事件回调要么用asyncio配合await loop.sock_recv()。理解了Socket底层的recv()语义后换任何语言都是同一个原理在套不同的语法壳。7.2 Socket与应用层协议的关系很多人学完Socket后问那我是不是可以自己写一个HTTP服务器当然可以。HTTP本身是应用层协议底层就是TCP。你完全可以用原始的socket接收浏览器请求头然后手动拼一个HTTP响应import socket s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((127.0.0.1, 8000)) s.listen(1) conn, addr s.accept() request conn.recv(1024) print(request.decode()) response ( HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: 13\r\n \r\n Hello, World! ) conn.sendall(response.encode()) conn.close()浏览器打开http://127.0.0.1:8000就能看到“Hello, World!”。这个例子虽然简陋但能帮你看清楚框架帮你隐藏的正是这些一次次recv()和send()的循环。7.3 从Socket走向成熟框架的路径理解底层之后实际项目的选型会清晰很多。做短暂连接或大量HTTP请求直接上requests加FastAPI没问题但如果要处理长连接、实时推送、海量并发websockets、asyncio、uvloop这些方案就是基于Socket思路的进阶。底层原理通透了上层框架的配置选项就不会再看不懂了。8. 压测小实验验证你的服务端性能8.1 为什么一定要做压测写完服务端连接几个客户端验证能通这只是第一步。真实环境中并发量一上来很多隐藏问题才会暴露。之前我写过一个秒级处理5000条消息的推送服务单线程版本直接把CPU跑满客户端大面积超时。这就是典型的没做预压测。8.2 用Python写一个简易压测脚本import socket import threading import time def single_client(thread_id, count100): client socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: client.connect((127.0.0.1, 9000)) for i in range(count): msg fthread-{thread_id}-msg-{i}.encode() client.send(pack_message(msg)) response recv_message(client) client.close() return True except Exception as e: print(f线程{thread_id}失败: {e}) return False def run_benchmark(num_clients100, per_client100): start time.monotonic() threads [] results [] for i in range(num_clients): t threading.Thread(targetlambda: results.append(single_client(i, per_client))) threads.append(t) for t in threads: t.start() for t in threads: t.join() duration time.monotonic() - start total_messages num_clients * per_client print(f完成{total_messages}条消息耗时{duration:.2f}秒吞吐率{total_messages / duration:.0f} msg/s)跑一次就知道服务端能撑多大并发几百线程时是否出现丢连、延迟激增。压测结果会直接指导你决定用threading还是asyncio做改造。8.3 压测之后怎么改进压测暴露的瓶颈通常集中在三处一是线程创建过多导致上下文切换开销二是recv循环里做了阻塞等待三是单线程IO瓶颈。改进方向一般是引入selectors做事件循环或用asyncio实现单线程异步IO把等待时间让渡给其他连接。这也是为什么很多人学完Socket基础后下一站就是学asyncio。9. 项目实战实现一个简单的聊天室服务端把前面学的所有内容串起来做一个局域网聊天室。需求很简单多个客户端连上服务端任何一个人发的消息服务端广播给其他所有人。import socket import threading class ChatServer: def __init__(self, host0.0.0.0, port9002): self.server socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.server.bind((host, port)) self.server.listen(20) self.clients [] # 维护所有客户端连接 self.lock threading.Lock() def broadcast(self, sender, message): 将消息广播给除发送者之外的所有客户端 with self.lock: for client in self.clients[:]: if client is not sender: try: client.send(pack_message(message)) except Exception: self.clients.remove(client) def handle(self, conn, addr): name f{addr[0]}:{addr[1]} print(f{name} 加入聊天室) while True: try: msg recv_message(conn) if msg.decode() /quit: break self.broadcast(conn, f{name}: {msg.decode()}.encode()) except ConnectionError: break print(f{name} 离开聊天室) conn.close() with self.lock: if conn in self.clients: self.clients.remove(conn) def start(self): while True: conn, addr self.server.accept() with self.lock: self.clients.append(conn) threading.Thread(targetself.handle, args(conn, addr), daemonTrue).start() if __name__ __main__: ChatServer().start()注意两点一是broadcast时先复制一份self.clients[:]防止循环中客户端断开导致列表被修改弹异常二是每次发送都用了我们之前设计的pack_message()避免接收端出现中文内容因TCP分片导致的乱码或粘连。这样一个聊天室已经能容纳几十个人同时在线足够作为小团队内部即时通讯工具的原型。10. 写在经验之外的一些话我自己刚开始学Socket时也是在bind、listen、accept这几个词之间来回绕直到亲手写完一个聊天室才真正把这些API串成了一个整体认知。如果要给你一个学习路线建议我个人的体会是先照着最简单的TCP回声服务敲一遍再改成多线程版本然后加一个消息头协议最后用压测脚本验证改进效果。这条路线走完网络编程的地基基本就稳了。还有个小技巧调试阶段不要嫌麻烦多用print打印conn对象、addr元组和每一次recv()拿到的原始bytes结果。Socket的世界里眼见为实的调试输出比翻文档管用一百倍。另外建议把带SO_REUSEADDR、struct长度头、异常处理的模板代码保存下来以后写任何网络程序都可以直接在这个底子上改省下大量重复踩坑的时间。
最近好几个朋友问我怎么用 Python 做网络通信说网上教程看着不少但真到自己写的时候连socket.bind()报错都不知从哪查。其实Python内置的socket模块是学习网络通信底层原理最好的入门工具——它把TCP和UDP那套流程全暴露在你面前比一上来就套Flask、Twisted这些高级框架更能让人看清本质。这篇内容适合刚接触网络编程、想弄明白服务端和客户端怎么对话以及那些被OSError、Address already in use折腾过的人。我把从原理到实战再到踩过的坑一次性讲透。Python Socket网络通信详解1. 网络通信的基础Socket到底是什么Socket这个词直译是“插座”但很多人理解成“端口”就有点偏了。我更愿意把它看成两个进程之间的一条数据管道——不管是同一台机器上的两个进程还是隔着几台服务器只要协商好了IP和端口就能通过这条管道把字节流传来传去。要理解Socket得先分清TCP和UDP。TCP是面向连接的打个比方就像打电话得先拨号、对方接通、双方确认“喂喂能听到吗”然后才开始说话说完还要挂机。UDP则像寄快递你把包裹写上地址扔进快递柜能不能送到、多久送到全看运气和网络状况没有确认机制。Python里面用socket模块来创建套接字核心就三个要素协议族family、套接字类型type、协议protocol。最常见的是IPv4加TCP也就是AF_INET加SOCK_STREAMIPv4加UDP则是AF_INET加SOCK_DGRAM。底层调用的是操作系统提供的BSD Socket接口所以你在Linux、macOS、Windows上写代码API几乎一模一样。你可能会问那我直接用requests库访问网页或者用pymysql连数据库是不是就不涉及Socket了恰恰相反这些库底层全都在用Socket只不过帮你封装好了。搞清楚Socket原理等于看清了所有网络通信的“底牌”。2. 环境准备与API全景图先看一张地图再出发2.1 Python环境的搭建要点实操之前先确认环境没问题。Python的socket模块是标准库装完解释器就有不需要pip额外安装。但很多人的麻烦出在环境本身——装错版本、多版本并存、环境变量没配好编译时一通报错。我的建议是直接用Python 3.8以上版本在官网下载安装时**务必勾选“Add Python to PATH”**那个选项。这个勾选决定了你在命令行里敲python能不能直接进交互环境。装完之后在终端里跑一下python --version看到输出版本号就说明OK没看到就去检查环境变量PATH里有没有Python的安装路径。这个坑我在Windows上踩过不止一次明明能进IDLE但命令行就是不认。如果你需要同时管理多个Python版本建议用conda或者pyenv单独建环境。比如conda create -n socket_demo python3.11 conda activate socket_demo这样后续跑网络编程的测试脚本不会和系统级的Python搞混。2.2 核心API速查你必须掌握的8个方法掌握列表之后再看代码就不会被面试笔试题里的细节绊住了。主要流程是服务端和客户端各自做四件事服务端socket()创建套接字 →bind()绑定IP和端口 →listen()监听连接 →accept()接受连接客户端socket()创建套接字 →connect()发起连接 →send()/recv()收发数据 →close()关闭连接方法作用核心注意点socket(family, type)创建套接字默认参数即TCPbind(address)绑定地址address是(host, port)元组listen(backlog)监听连接backlog是连接等待队列长度accept()接受一条连接返回(conn, addr)二元组connect(address)客户端发起连接目标必须是已绑定的地址send(data)发送数据注意可能没全部发送完recv(bufsize)接收数据返回bytes空表示对端关闭setsockopt(level, opt, val)设置套接字选项最常用SO_REUSEADDR其中recv()有个容易误解的点它接收的是字节流不是消息包。TCP是流协议你send两次对端可能一次recv就全读走也可能分三次读走。这给很多人造成了困惑后面我在实际操作部分会专门讨论怎么处理这种“粘包”问题。2.3 理解阻塞与非阻塞模式刚接触Socket的时候最不适应的就是默认的阻塞模式——程序执行到accept()或recv()就停住了等数据来了才继续跑。比如recv(1024)没收到数据整个进程就卡在那里。非阻塞模式一般用两种方式实现一是setblocking(False)把套接字设为非阻塞没数据就立刻抛异常二是用select、poll这些IO多路复用接口同时盯着多个套接字。后面我会用一个多客户端并发场景演示这里先建立概念阻塞模式逻辑简单但并行处理多个客户端时会成为瓶颈非阻塞加多路复用是性能提升的关键方向。3. TCP服务端与客户端从零搭一个可用的场景3.1 先写一个最简单的TCP回显服务端很多人看教程上来就是一大段框架代码反而把基础结构掩盖了。我习惯从最朴素的版本开始写——做一个“回声服务”客户端发什么服务端原样返回什么。别小看这个过程它能让你看清服务端每一行代码的意义。import socket # 创建一个TCP套接字 server_sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 设置地址复用避免“Address already in use” server_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 绑定到本机9000端口 server_sock.bind((127.0.0.1, 9000)) # 开始监听最多允许5个连接等待 server_sock.listen(5) print(服务端已启动等待客户端连接...) while True: # 接受一个客户端连接 conn, addr server_sock.accept() print(f新连接来自: {addr}) # 循环处理数据 while True: data conn.recv(1024) if not data: print(f{addr} 已断开) break # 原样回发 conn.send(data) conn.close()这段代码里accept()每次只处理一个客户端。当第一个客户端建立连接后后面的客户端只能排队等这就是阻塞模式的局限。如果想验证它确实能跑可以先在命令行启动这个脚本再用另一个终端敲telnet 127.0.0.1 9000连上看效果。3.2 客户端代码与三次握手的直观理解客户端的代码要更简单些import socket client_sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) client_sock.connect((127.0.0.1, 9000)) client_sock.send(bHello, this is my first socket message) response client_sock.recv(1024) print(f收到回显: {response.decode()}) client_sock.close()运行之后客户端打印出“收到回显: Hello...”。这个看似简单的过程本质上走完了TCP的三次握手客户端发送SYN包请求建立连接。服务端收到后回复SYNACK表示“收到我也准备好了”。客户端再回一个ACK双方进入连接状态。connect()方法返回的时候三次握手已经完成。而accept()能拿到这个连接则意味着连接已经进入“已建立”状态。这里有个细节send()返回的是实际发送的字节数。TCP不保证你一次send多少就发送多少因为受限于滑动窗口和MSS最大报文段大小。严谨的做法是用循环确保所有数据都发出比如def send_all(sock, data: bytes): total_sent 0 while total_sent len(data): sent sock.send(data[total_sent:]) if sent 0: raise RuntimeError(socket连接中断) total_sent sent同理recv(1024)里的1024只是“最多读这么多”不表示一次读完对方发的所有数据。等下讲到粘包问题时我会给出相对完整的方案。3.3 处理多个客户端用threading实现简单并发实际项目中不可能只服务一个客户端。最简单的办法是每来一个连接就开一条线程处理import socket import threading def handle_client(conn, addr): print(f处理连接: {addr}) while True: try: data conn.recv(1024) if not data: break conn.send(data) except ConnectionResetError: break 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(5) while True: conn, addr server.accept() thread threading.Thread(targethandle_client, args(conn, addr)) thread.start()这种模式是经典的thread-per-connection。好处是代码直观每个连接互不干扰坏处是并发量大了之后线程开销大达到几千个连接时内存和上下文切换就成了负担。如果是写小工具、内部局域网项目这个方案完全够用。在高并发生产环境一般会用asyncio或者selectors模块去改造。4. UDP通信轻量场景的最优解4.1 UDP服务端和客户端的差异TCP的流程是“先连接再通信”UDP则没有连接概念。它就像寄快递服务端只需要bind一个端口然后不停地接收来自任何地址的报文客户端不需要connect直接sendto()把数据交给网络。来看UDP服务端import socket udp_server socket.socket(socket.AF_INET, socket.SOCK_DGRAM) udp_server.bind((127.0.0.1, 9001)) print(UDP服务端已启动...) while True: data, addr udp_server.recvfrom(1024) print(f来自{addr}的消息: {data.decode()}) udp_server.sendto(data, addr)客户端import socket udp_client socket.socket(socket.AF_INET, socket.SOCK_DGRAM) udp_client.sendto(bhello udp, (127.0.0.1, 9001)) data, addr udp_client.recvfrom(1024) print(data.decode())注意区别UDP用recvfrom()而不是recv()返回的不只是数据还有发送方地址发送用sendto()必须指定目标地址因为连接不是固定的。4.2 什么时候选UDP而不是TCP很多人习惯“能用TCP就不用UDP”其实场景不同不能一刀切。UDP的优点是无连接、无状态、延迟低很适合这几类场景音视频通话丢几个包还能听但延迟高了体验极差。实时游戏状态同步位置信息每秒更新几十次用TCP的可靠性重传反而会让画面卡顿。DNS查询DNS本身用的就是UDP一次请求一个包一问一答。局域网设备发现比如你的手机通过广播消息找智能家居设备广播本身用的是UDP。要说缺点也很明确UDP不保证可靠交付丢包、乱序、重复都可能发生。所以需要在应用层自己设计确认、重传、序号等机制。如果数据完整性要求高比如文件传输、数据库同步那还是老老实实走TCP。4.3 一个实用案例用UDP做设备健康监测我之前做过一个内部小工具用UDP轮询局域网内几台Linux服务器的存活状态。每台机器上跑一个轻量脚本每5秒向监控端发送自己的CPU和内存占用率。监控端收到就更新状态超过15秒没收到就标记掉线。这样做的关键好处有三个第一UDP不用维持一堆TCP连接服务端不用为每台设备维护状态第二即使某几帧数据丢失下一帧马上会来不影响整体监控第三代码量很小客户端几十行就够。这种场景用TCP反而特有劣势——连接断了要重连重连期间的监控就是空窗期。5. 进阶实操粘包处理、缓冲区与可靠传输改良5.1 什么是粘包为什么会出现粘包是TCP新手最容易遇到的坑之一。前面说了TCP是字节流协议它不关心你的业务数据怎么切分只负责把字节按顺序送到。如果客户端连续发了三次数据服务端可能一次recv()就拿到三批数据的拼合体或者第二次收的时候拿到后半截。一个经典面试场景客户端发送send(bAAA)、send(bBBB)服务端recv(1024)很可能直接拿到bAAABBB。你想按消息去解析结果对不上。根本原因在于TCP的send()只是把数据写进了内核发送缓冲区至于对端什么时候读到、读到多少完全由网络状态和对端接收时机决定。5.2 给数据加“信封”自定义消息格式解决粘包问题的通用思路是定长消息头加消息体——发送方在发数据之前先给数据加上一个固定长度的长度字段接收方先读长度再按长度读消息体。就像寄包裹时先在信封外写明重量收到的人才知道要拆开多少。import struct def pack_message(data: bytes) - bytes: 将数据打包为: 4字节长度 原始数据 length len(data) return struct.pack(I, length) data def recv_exact(sock, n: int) - bytes: 可靠地读取n个字节 chunks [] remaining n while remaining 0: chunk sock.recv(remaining) if not chunk: raise ConnectionError(连接中断) chunks.append(chunk) remaining - len(chunk) return b.join(chunks) def recv_message(sock) - bytes: 接收一条完整消息 length_data recv_exact(sock, 4) length struct.unpack(I, length_data)[0] return recv_exact(sock, length)这里用了struct.pack(I, length)把数据长度转成4字节无符号大端整数。大端序在网络传输中是标准约定跨语言通信时大家都认这个格式。你还可以在消息头里增加消息类型、版本号等字段让协议更完善。5.3 用SO_REUSEADDR和超时机制减少崩溃很多初学者在调脚本时都遇到过这个报错OSError: [Errno 98] Address already in use原因很简单服务端上次运行结束后TCP连接并没有立即完全消失内核里还残留着TIME_WAIT状态。这时候立刻重新bind同一个端口就会被拒绝。解决办法就是第3个章节代码里写过的setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)。这个选项允许内核在套接字还没有完全释放时重新使用端口对开发调试非常有用。另外阻塞模式的recv()有个隐患如果对端一直不发数据服务端会永远卡住。为了应对不可靠客户端可以设置超时时间conn.settimeout(5.0) try: data conn.recv(1024) except socket.timeout: print(客户端5秒没发数据关闭连接) conn.close()加了超时后即使对端失联服务端也能主动清理连接不至于线程越积越多。5.4 多线程并发的封装建议如果每次都要手写循环收消息再按长度拆包很容易出错。实际项目中我会把常用的逻辑封装成一个简单的类核心API暴露出来class TCPServer: def __init__(self, host127.0.0.1, port9000): self.host host self.port port self.running False self.server socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) def start(self): self.server.bind((self.host, self.port)) self.server.listen(10) self.running True print(fServer listening on {self.host}:{self.port}) while self.running: conn, addr self.server.accept() threading.Thread(targetself._handle, args(conn, addr), daemonTrue).start() def _handle(self, conn, addr): with conn: while True: try: msg recv_message(conn) response self.on_message(msg) conn.send(pack_message(response)) except ConnectionError: break def on_message(self, msg: bytes) - bytes: return msg # 子类重写这个方法 def stop(self): self.running False self.server.close()把核心流程封装好之后业务逻辑就只集中在on_message()一个方法里。这个方案的思路其实和很多主流网络框架殊途同归只是更容易让人看透每一层在干什么。6. 常见问题与故障排查实录6.1 高频报错实例对照表我在帮人调试各种Socket项目时总结了一套频率极高的报错组合这里整理成速查表报错信息常见原因解决方案Address already in useTIME_WAIT残留或端口被占用加SO_REUSEADDR或换端口Connection refused服务端没启动或端口不对检查服务端状态、防火墙Connection reset by peer对端强制关闭或数据没接收完就close在业务上做异常捕获timed out网络不通或服务端没响应检查防火墙确认IP可达[WinError 10048]Windows上端口被占用netstat查看占用并关闭进程Windows和Linux的报错格式不太一样但本质一致。比如Windows下最常见的是[WinError 10048]对应Linux的errno 98 Address already in use。6.2 实战排查思路从现象到根本原因遇到问题不要瞎试我一般按“三看”来排查一看端口用netstat -an | grep 端口Linux/macOS或netstat -ano | findstr 端口Windows检查端口是否被监听。如果是自己之前的服务占着杀掉进程再重启。二看防火墙把监听地址换成0.0.0.0后局域网内其他机器连不上多半是防火墙拦了端口。Linux下用firewall-cmd --list-ports查看Windows在“高级安全Windows Defender防火墙”中添加入站规则。三看代码逻辑确认发送方send了数据但接收方recv阻塞多半是消息长度没对上。检查一下是否用了结构化的粘包处理方案还是一股脑地recv(1024)。6.3 两个容易忽略的隐蔽问题第一个是对端半关闭状态。客户端执行shutdown(socket.SHUT_WR)只关闭发送方向服务端还能往客户端发数据。但close()是全关闭会同时断开两个方向。第二次实际处理文件传输协议时如果误用close()接收方可能还没读完数据连接就断了。第二个是缓冲区大小限制。如果想用socket.recv()接收超大文件传一个很大的bufsize其实不安全因为底层缓冲区有内核限制。更好的方案是循环读取并写入文件一点点积累def recv_file(sock, file_path): with open(file_path, wb) as f: while True: data sock.recv(65536) if not data: break f.write(data)每次读64KB是个不错的折中既不频繁调用内核也不占用过多内存。7. 其他语言与场景的对照理解Socket的通用性7.1 与C#异步回调的对比搜热词时看到有人提到“C# socket bigging receive回调”其实讲的是C#里用BeginReceive做异步接收。核心思路和Python里用asyncio或起线程很像都是为了避免主线程阻塞在等待数据上。C#的经典写法是给Socket绑定一个回调函数收到数据后触发而Python里对应方案要么用selectors模块注册事件回调要么用asyncio配合await loop.sock_recv()。理解了Socket底层的recv()语义后换任何语言都是同一个原理在套不同的语法壳。7.2 Socket与应用层协议的关系很多人学完Socket后问那我是不是可以自己写一个HTTP服务器当然可以。HTTP本身是应用层协议底层就是TCP。你完全可以用原始的socket接收浏览器请求头然后手动拼一个HTTP响应import socket s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.bind((127.0.0.1, 8000)) s.listen(1) conn, addr s.accept() request conn.recv(1024) print(request.decode()) response ( HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: 13\r\n \r\n Hello, World! ) conn.sendall(response.encode()) conn.close()浏览器打开http://127.0.0.1:8000就能看到“Hello, World!”。这个例子虽然简陋但能帮你看清楚框架帮你隐藏的正是这些一次次recv()和send()的循环。7.3 从Socket走向成熟框架的路径理解底层之后实际项目的选型会清晰很多。做短暂连接或大量HTTP请求直接上requests加FastAPI没问题但如果要处理长连接、实时推送、海量并发websockets、asyncio、uvloop这些方案就是基于Socket思路的进阶。底层原理通透了上层框架的配置选项就不会再看不懂了。8. 压测小实验验证你的服务端性能8.1 为什么一定要做压测写完服务端连接几个客户端验证能通这只是第一步。真实环境中并发量一上来很多隐藏问题才会暴露。之前我写过一个秒级处理5000条消息的推送服务单线程版本直接把CPU跑满客户端大面积超时。这就是典型的没做预压测。8.2 用Python写一个简易压测脚本import socket import threading import time def single_client(thread_id, count100): client socket.socket(socket.AF_INET, socket.SOCK_STREAM) try: client.connect((127.0.0.1, 9000)) for i in range(count): msg fthread-{thread_id}-msg-{i}.encode() client.send(pack_message(msg)) response recv_message(client) client.close() return True except Exception as e: print(f线程{thread_id}失败: {e}) return False def run_benchmark(num_clients100, per_client100): start time.monotonic() threads [] results [] for i in range(num_clients): t threading.Thread(targetlambda: results.append(single_client(i, per_client))) threads.append(t) for t in threads: t.start() for t in threads: t.join() duration time.monotonic() - start total_messages num_clients * per_client print(f完成{total_messages}条消息耗时{duration:.2f}秒吞吐率{total_messages / duration:.0f} msg/s)跑一次就知道服务端能撑多大并发几百线程时是否出现丢连、延迟激增。压测结果会直接指导你决定用threading还是asyncio做改造。8.3 压测之后怎么改进压测暴露的瓶颈通常集中在三处一是线程创建过多导致上下文切换开销二是recv循环里做了阻塞等待三是单线程IO瓶颈。改进方向一般是引入selectors做事件循环或用asyncio实现单线程异步IO把等待时间让渡给其他连接。这也是为什么很多人学完Socket基础后下一站就是学asyncio。9. 项目实战实现一个简单的聊天室服务端把前面学的所有内容串起来做一个局域网聊天室。需求很简单多个客户端连上服务端任何一个人发的消息服务端广播给其他所有人。import socket import threading class ChatServer: def __init__(self, host0.0.0.0, port9002): self.server socket.socket(socket.AF_INET, socket.SOCK_STREAM) self.server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) self.server.bind((host, port)) self.server.listen(20) self.clients [] # 维护所有客户端连接 self.lock threading.Lock() def broadcast(self, sender, message): 将消息广播给除发送者之外的所有客户端 with self.lock: for client in self.clients[:]: if client is not sender: try: client.send(pack_message(message)) except Exception: self.clients.remove(client) def handle(self, conn, addr): name f{addr[0]}:{addr[1]} print(f{name} 加入聊天室) while True: try: msg recv_message(conn) if msg.decode() /quit: break self.broadcast(conn, f{name}: {msg.decode()}.encode()) except ConnectionError: break print(f{name} 离开聊天室) conn.close() with self.lock: if conn in self.clients: self.clients.remove(conn) def start(self): while True: conn, addr self.server.accept() with self.lock: self.clients.append(conn) threading.Thread(targetself.handle, args(conn, addr), daemonTrue).start() if __name__ __main__: ChatServer().start()注意两点一是broadcast时先复制一份self.clients[:]防止循环中客户端断开导致列表被修改弹异常二是每次发送都用了我们之前设计的pack_message()避免接收端出现中文内容因TCP分片导致的乱码或粘连。这样一个聊天室已经能容纳几十个人同时在线足够作为小团队内部即时通讯工具的原型。10. 写在经验之外的一些话我自己刚开始学Socket时也是在bind、listen、accept这几个词之间来回绕直到亲手写完一个聊天室才真正把这些API串成了一个整体认知。如果要给你一个学习路线建议我个人的体会是先照着最简单的TCP回声服务敲一遍再改成多线程版本然后加一个消息头协议最后用压测脚本验证改进效果。这条路线走完网络编程的地基基本就稳了。还有个小技巧调试阶段不要嫌麻烦多用print打印conn对象、addr元组和每一次recv()拿到的原始bytes结果。Socket的世界里眼见为实的调试输出比翻文档管用一百倍。另外建议把带SO_REUSEADDR、struct长度头、异常处理的模板代码保存下来以后写任何网络程序都可以直接在这个底子上改省下大量重复踩坑的时间。
