看了这么多天基础语法和数据结构今天终于走到了网络编程。在编程学习路径里这一天往往是一个分水岭前边学的所有东西都是程序在“自己跟自己玩”而网络编程让程序和世界连在了一起。我个人的感受是掌握了这部分你再回头看那些“系统设计”“分布式”“微服务”之类的词汇就不会觉得虚了因为它们的地基就是今天要聊的这套东西。这篇文章我会从最底层的通信模型讲起把 TCP、UDP、套接字、握手、缓冲区这些概念全部捋一遍然后带着你从零写一个可用的 TCP 聊天服务讲清楚服务端和客户端各自的职责再顺手解决并发、粘包、端口占用这些实战里必踩的坑。无论你是刚学完 Python 基础想进阶还是准备面试想补网络基础这篇都值得你花点时间认真读一遍。1. 网络编程到底在解决什么问题1.1 一切从通信模型说起先想一个问题如果让你设计一个程序让两台电脑之间可以互相发消息你会怎么搞你可能会说把消息写到文件里另一台电脑去读不行两台电脑没有共享磁盘。那插个 U 盘拷过去这确实能传输数据但它本质上不是“通信”因为整个过程没有两台电脑直接对话。网络编程要解决的核心问题就一句话让两台独立运行的设备通过网络介质按照共同的规则交换数据。这就牵扯出两个基本概念一个叫“客户端”一个叫“服务端”。客户端是主动发起请求的一方服务端是等待请求并处理的一方。比如你打开浏览器访问网站浏览器就是客户端网站服务器就是服务端。这个模型叫 C/S 模型它是绝大多数网络应用的基本结构。理解 C/S 模型有一个要点服务端必须先启动并且在自己的端口上“蹲守”客户端才能找到它。你可以把这个过程类比成打电话服务端是那个一直在办公室坐着、电话开机的人客户端是拿起电话拨号的人。电话没开机你拨号只会听到“您拨打的用户暂时无法接通”。对应到程序里就是连接被拒绝。1.2 协议栈与数据流转两台设备之间要通信光有“我想发数据”的意愿远远不够。数据在网络上怎么找到对方怎么保证不丢怎么知道数据是给哪个程序的这些问题如果每个开发者都要自己解决那整个互联网早就乱套了。所以行业里把通信规则做成了分层模型最普及的参考模型是 TCP/IP 四层模型应用层、传输层、网络层、链路层。应用层你写的代码比如 HTTP、FTP、WebSocket协议语义就在这一层。传输层负责端到端的传输TCP 和 UDP 就在这一层它决定了数据是否可靠、是否有序。网络层负责寻址和路由IP 协议在这一层每台设备都有 IP 地址数据包靠它找到对方。链路层负责物理网络中的传输比如网卡、以太网协议。我们平时在代码里操作的东西基本都是在应用层和传输层。数据发送时是从上往下逐层“打包”应用层数据交给传输层加上端口信息网络层加上 IP 地址链路层加上 MAC 地址等信息最后变成比特流扔到网线上。接收方再做相反的过程一层层“拆包”最终把数据交给对应程序。这个过程我建议你一定要画一遍哪怕就用笔在纸上画个箭头也行。以后遇到“为什么我的数据发不过去”“为什么服务端收不到消息”这类问题排查思路基本就是沿着这条链路自下而上或自上而下过一遍。1.3 设计选择TCP还是UDP网络编程里第一个真正的选择就是到底用 TCP 还是 UDP。这两个协议完全不同选错后面全白干。TCP传输控制协议是面向连接的、可靠的、基于字节流的传输协议。它通过三次握手建立连接数据有确认机制丢包会重传能保证数据按顺序到达对方的缓冲区。代价是效率相对低、连接有状态、协议头更大。UDP用户数据报协议是无连接的、不可靠的、基于数据报的传输协议。它不建立连接发完就完数据有可能丢失、乱序、重复到达。它不管对方收没收到但胜在开销小、延迟低、支持广播和多播。什么场景用 TCP什么场景用 UDP我举个例子你就明白了。你在网上下载文件一个字节都不能错错一个文件可能就打不开了这种场景必须 TCP。再比如视频通话、在线游戏里的位置同步帧丢一两帧无所谓下几帧补上就行但延迟一定要低这种场景 UDP 更合适。当然现实中很多应用是混合用的握手和关键控制信令走 TCP音视频数据走 UDP。我个人给初学者一个很实用的建议第一次写网络程序无脑选 TCP。TCP 的逻辑更符合直觉调试起来也更容易等把 TCP 玩通了你自然会理解 UDP 的价值在哪里。2. 核心细节解析与实操要点2.1 套接字网络编程的基本操作单元网络编程的一切操作几乎都围绕着一个叫“套接字”的东西展开。英文叫 Socket很多教程也直接叫“Socket 编程”。Socket 是什么一句话说它是操作系统提供的一个编程接口让你可以通过文件描述符的方式去操作网络连接。你读写网络数据就像读写文件一样调用 read/write只不过底层流转是在网络上。这个设计非常巧妙Unix 哲学里“一切皆文件”的思想在这里得到了延续。Python 标准库提供了socket模块封装了系统调用所以你不必理会 C 语言那些繁琐的结构体。一个典型的 TCP 服务端代码流程是这样创建 socket 对象绑定地址和端口bind监听客户端连接listen接受连接拿到一个新的 socketaccept用这个新 socket 收发数据recv / send关闭连接close客户端流程更简单创建 socket 对象连接服务端connect收发数据关闭这里有个非常容易混淆的细节accept 返回的 socket 和最初创建的那个 socket 不是一回事。监听 socket 只负责“接电话”accept 之后返回的那个新 socket 才是真正“通话”的通道。服务端可以同时持有多个这样的通信 socket分别对应不同的客户端这就是并发的基础。2.2 创建套接字与关键参数用 Python 创建 socket通常一句话就够了import socket s socket.socket(socket.AF_INET, socket.SOCK_STREAM)这里的两个参数决定了这个 socket 的工作方式。第一个参数AF_INET是地址族指定使用 IPv4 地址。平时写代码基本就用它。如果你要处理 IPv6可以改成AF_INET6。对于纯内网通信或者学习阶段IPv4 足够。第二个参数SOCK_STREAM表示流式套接字对应 TCP。如果改成SOCK_DGRAM就是数据报套接字对应 UDP。这两个词要记住面试和实际阅读代码都常碰到。还有一个常见的坑IPv4 地址到底传什么。bind和connect都需要一个地址元组(ip, port)。服务端绑定时ip 可以填127.0.0.1表示只允许本机访问也可以填0.0.0.0表示监听所有网卡允许外部设备访问。如果你在局域网里想用手机连你电脑上的服务服务端必须绑0.0.0.0或者你电脑的具体局域网 IP不然会被系统直接拒绝。端口号的范围是 0 到 65535其中 0 到 1023 是特权端口通常需要管理员权限才能绑定。自己写程序测试时尽量用 8000 以上的端口避免跟系统服务冲突。2.3 三次握手connect背后的流程每次执行connect时如果你的传输层用的是 TCP内核会自动为你完成“三次握手”。这个过程极其重要很多面试题考它排查网络故障也绕不开它。三次握手的过程可以这样理解客户端发送一个 SYN 报文意思是“我想建立连接”。服务端收到后回复 SYN ACK 报文意思是“我收到你的请求了同时我也想建立连接”。客户端再回复一个 ACK 报文意思是“我知道你收到了连接正式建立”。为什么需要三次而不是两次有一个很容易理解的解释握手的目的之一是让双方确认彼此的收发能力都正常。第一次握手服务端确认客户端能发第二次握手客户端确认服务端能收、能发第三次握手服务端确认客户端能收。到这一步两边都确认了“你能收我发的我也能收你发的”连接才算稳。你可能会问那我connect没成功是为什么常见原因有两个一是服务端根本没监听内核直接返回“连接被拒绝”这种错误是立刻的二是服务端监听但连接队列满了或者网络不通客户端会一直等下去直到超时。这两种出现的现象完全不同排查时可以先区分。2.4 缓冲区与send/recv的真相初学网络编程很多人会想当然地认为send发多少数据对方recv就会收到多少数据。这是最大的误解之一。TCP 是字节流协议它在传输层不关心什么“消息”边界。你调用send(bhello world)这 11 个字节进入发送缓冲区内核会自己决定怎么把它分成若干数据包发出去。对方调用recv(1024)它从接收缓冲区里取出 1024 个字节但取出的不一定是那完整的 11 个字节可能只有 5 个也可能已经包含了下一段消息的内容。这意味着什么意味着网络编程没有“一次发送一次接收”对应关系的保证。你必须在应用层想办法确定消息的边界。最常用的办法有三种固定长度每条消息都定长比如 4 字节收不够就继续收多了就存着下次处理。分隔符消息之间用特殊字符分隔比如\n收到就按分隔符切分。长度前缀先发送 4 字节的包头表示后面数据的字节数接收方先收包头再按长度收包体。第三种方案是工程上最通用的后面实操我会带着你实现。现在你只需要建立一个意识用 TCP 做通信应用层协议是必须自己设计的。3. 上手实操从单联接到并发聊天室3.1 环境准备与基础示例实操之前先把工具准备好。Python 3.8 以上就自带socket模块不需要装第三方库。为了方便跟踪网络状态推荐装一个 Wireshark抓包分析但不是必需。调试时可以先用telnet工具模拟客户端或者干脆用 Python 写一个测试客户端。写一个最小可用的 TCP 服务端其实不到十行import socket server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.bind((0.0.0.0, 9000)) server.listen(5) print(server is listening on 9000) while True: conn, addr server.accept() print(fnew connection from {addr}) data conn.recv(1024) print(freceived: {data.decode()}) conn.send(bgot it) conn.close()这段代码只能处理一个连接而且是一次性的接受连接、收一条消息、回一句、关闭。但它把服务端的基础流程完整展示出来了。如果你现在运行它再用浏览器访问http://127.0.0.1:9000你会看到浏览器发送的 GET 请求文本在终端里打出来。这是一个很有成就感的时刻因为你的程序真的在跟外部世界交互了。3.2 从零实现一个可复用的服务端上面的例子太简陋真正可用的服务端要能反复处理连接并且一个连接里可能有多条消息。我们先加一个循环让同一个连接能持续收发消息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(server is listening on 9000) while True: conn, addr server.accept() print(fnew connection from {addr}) try: while True: data conn.recv(1024) if not data: break print(freceived: {data.decode()}) conn.sendall(becho: data) except ConnectionResetError: print(fclient {addr} closed abruptly) finally: conn.close() print(fconnection from {addr} closed)注意到我在开头加了一行setsockopt设置SO_REUSEADDR。这一行非常实用它允许服务端关闭后立刻重新绑定同一个端口。不加这行程序结束后端口可能还处在 TIME_WAIT 状态重新运行时会报“address already in use”。这是初学阶段最常见的报错之一后面我还会细说。内层循环里我判断if not data: break这是 TCP 编程里一个很重要的约定对方关闭连接时recv 会返回空字节串 b。收到这个就说明对端已经关闭该结束这次通信了。很多人忘了这个判断导致程序卡在 recv 上永远等下去。3.3 客户端怎么配合有服务端必须有客户端客户端代码相比之下简单得多import socket client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect((127.0.0.1, 9000)) try: while True: msg input(please input: ) if not msg: break client.sendall(msg.encode()) response client.recv(1024) print(fserver response: {response.decode()}) finally: client.close()这个客户端从终端读一行发给服务端然后打印服务端的回显。实验的时候可以在一个终端窗口开服务端在另一个终端窗口跑这个客户端。我这里故意把sendall和send区分开来提一下send返回的是实际发送的字节数可能比你给的数据少sendall会循环发送确保全部发送成功。应用层写代码能用 sendall 就不要用 send。运行几次之后你会有一种感觉原来网络通信并不玄乎就是两端按约定好的顺序互相往 socket 里塞数据。但到这一步服务端还是只能服务一个客户端第二个客户端连进来时会被晾在 accept 队列里。要解决这个问题得引入并发。3.4 引入多线程让服务端一次服务多个客户端最简单的并发方案就是每个客户端来了给它开一个线程。主线程继续 accept新连接的收发都在子线程里处理。import socket import threading def handle_client(conn, addr): print(fnew connection from {addr}) try: while True: data conn.recv(1024) if not data: break print(f{addr} - {data.decode()}) conn.sendall(becho: data) except ConnectionResetError: pass finally: conn.close() print(fconnection from {addr} closed) 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(server is listening on 9000) while True: conn, addr server.accept() t threading.Thread(targethandle_client, args(conn, addr)) t.start()到这里一个多客户端聊天服务端就成型了。每个客户端连接都由独立的线程处理互不阻塞。注意一点线程的 daemon 属性需要看情况设置。如果你希望在主程序退出后线程也自动结束可以在start()前设置t.daemon True。但在大多数服务端场景里我们希望线程能处理完所以不设置 daemon 也是合理的。多线程方案的好处是简单直观但缺点也明显如果同时有几千个客户端连接每个连接一个线程资源开销会把程序拖垮。生产环境里通常会改用事件驱动模型Python 的asyncio或者selectors模块就是干这个的。初学者先把多线程方案吃透再去学事件循环理解曲线会顺很多。3.5 用 selectors 实现单线程高并发说一个“可选的进阶版”因为这块很容易劝退新手我先给你一个直观的认识。selectors模块是基于操作系统 IO 多路复用机制的封装核心思想是一个线程同时盯着很多 socket 文件描述符哪个有数据就处理哪个没有数据的就放着不管。用 selectors 改造上面的回显服务端import selectors import socket sel selectors.DefaultSelector() def accept_conn(server): conn, addr server.accept() conn.setblocking(False) sel.register(conn, selectors.EVENT_READ, read_handler) def read_handler(conn, mask): data conn.recv(1024) if data: conn.sendall(becho: 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(5) server.setblocking(False) sel.register(server, selectors.EVENT_READ, accept_conn) while True: events sel.select(timeoutNone) for key, mask in events: callback key.data callback(key.fileobj, mask)注意这里要求 socket 是非阻塞的调用了setblocking(False)否则注册到 selector 里没有意义。非阻塞模式下recv如果没数据会立刻返回一个BlockingIOError异常而 selector 会帮我们保证能读的时候才回调所以这个异常不会发生。这个方案能在一个线程里管理成千上万的连接是生产级服务常用的模型。你不一定马上要会写但至少要知道有这条路线。真到了需要自己写服务端框架的时候再回头深入学asyncio就事半功倍。4. 常见问题与排查技巧实录4.1 端口被占用怎么办这个错误几乎每个人都会遇到。现象是运行服务端时报错OSError: [Errno 98] Address already in use原因是上一次运行的服务端没有释放端口或者别的程序占了同一个端口。解决方式分几步走先确认谁占了这个端口。Linux 下可以用lsof -i :9000或netstat -tlnp | grep 9000查看。如果确定是自己的僵尸进程可以用kill命令结束它。如果是正常退出后立刻重启导致 TIME_WAIT 占用记住我在代码里加的那行SO_REUSEADDR它能让你快速重启而不需要等内核超时。有一个很重要的认知TIME_WAIT 状态的时间不是程序能控制的通常持续几十秒到几分钟。这是 TCP 协议为保证旧连接的延迟数据包不会干扰新连接而做的设计。有的生产系统会专门调节内核参数来缩短这个时间但那是运维层面的活儿。你只需要知道这不是 bug是协议保护机制。4.2 粘包和拆包应用层必须处理的头等大事粘包这个词听起来玄乎实际就是两条消息在接收端被一次性读出来了或者一条消息被分两次读出。原因我在前面第 2.4 节已经埋伏了全是因为 TCP 是字节流没有消息边界。比如客户端连续发送bhello和bworld服务端recv(1024)可能一次收到bhelloworld。这就是粘包。如果客户端只发一个 3000 字节的大消息服务端recv(1024)可能先收到前 1024 字节这是拆包。解决思路就是设计一个简单的协议。我推荐最通用的长度前缀方案实现起来也不难import struct def send_message(sock, data: bytes): # 4字节大端整数表示消息长度 header struct.pack(I, len(data)) sock.sendall(header data) def recv_exactly(sock, n: int) - bytes: data b while len(data) n: chunk sock.recv(n - len(data)) if not chunk: raise ConnectionError(connection closed while receiving) data chunk return data def recv_message(sock) - bytes: header recv_exactly(sock, 4) msg_len struct.unpack(I, header)[0] return recv_exactly(sock, msg_len)这里recv_exactly的作用是“收满 n 个字节才返回”不管底层分多少次送到。用这套收发函数应用层就可以放心地按“一条消息一个 recv_message”来编写逻辑了。粘包问题从根上解决。非阻塞和异步场景下这套方案要搭配缓冲区来用但思路不变先收满包头再收满包体。无论你以后用 Netty、Go 的 bufio 还是 Node.js 的流式处理这个原则都是通用的。4.3 recv阻塞导致程序卡死的排查思路新手最常见的疑惑是服务端跑得好好的客户端也发数据了但服务端就是没有任何输出。这时候十有八九是recv在阻塞等待数据而你以为它“应该收到”的数据并没有到缓冲区。排查时按顺序检查客户端是否真的发送成功了sendall没抛异常不代表网络传输成功只代表数据交给了内核缓冲区。客户端发送的数据是否被连接的另一端的接收逻辑读取了有时候是服务端代码逻辑错位比如先发后收导致互相等待。有没有在recv前调用了某些阻塞操作把整个流程卡住了另外生产环境的服务端不能容忍无限阻塞所以通常要给 socket 设置超时conn.settimeout(5.0) try: data conn.recv(1024) except socket.timeout: print(recv timeout)设置了超时之后超过 5 秒没有数据recv会抛出socket.timeout异常你就可以做对应的处理比如记录日志、关闭连接或继续轮询。要注意一旦设置超时后续所有 recv/send 调用都受这个超时影响不想要的话要重新设成None。4.4 半开连接与连接重置的实战处理还有一种暗坑叫“半开连接”。想象一个场景客户端程序崩溃了但操作系统没有来得及发送 FIN 包服务端这边完全不知道连接已经死亡。服务端继续recv就会一直阻塞直到 TCP 的保活机制或你手动设置的超时触发。在局域网环境里这种问题往往要等很久才能被发现。应对手段通常是在应用层做心跳客户端每隔一段时间发送一个心跳包服务端超过一定间隔没收到就认为连接失效主动关闭。这是所有在线服务都要考虑的基础能力QQ、微信、各种 App 的长连接背后都有一套心跳机制在支撑。另外如果客户端进程被强杀服务端在往这条连接写数据时可能收到ConnectionResetError也就是常见的“对端连接重置”。这在 Python 里是ConnectionResetError异常代码里要捕获它并做清理。我在前面示例里都加了except ConnectionResetError就是为了应对这种情况。实际生产环境里除了ConnectionResetError还建议捕获BrokenPipeError它发生在你往一个对端已关闭的连接写数据时。4.5 调试工具从 print 到 Wireshark写网络程序光靠 print 日志有时候很难定位问题因为问题可能出在内核协议栈里。你需要合适的工具。最方便的是抓包工具我平时用 Wireshark图形界面、tcpdump命令行适合服务器上抓。抓本机回环流量时注意 Wireshark 需要选择lo网卡并且可能需要管理员权限。抓到包之后配合过滤条件tcp.port 9000和follow tcp stream功能你能直接看到按时间顺序排列的每一个报文什么 SYN、ACK、PSH、FIN 一目了然。还有个轻量方法是用nc命令快速测试端口是否通、服务是否能响应。比如nc -vz 127.0.0.1 9000表示检查 9000 端口是否能连接。这种方法在排查“服务端没起来”还是“客户端连不上”的定位上非常快。当你熟练使用这些工具后排查思路会清晰很多先抓包看有没有报文到达再在代码里打日志看有没有执行到对应位置最后对照协议分析是发送方问题还是接收方问题。网络编程的调试本质上是在回答“数据到底走到哪一步了”这个问题。5. 进一步优化与个人体会5.1 从回显服务到真正的应用层协议我们前面写了一个回显服务它只完成了最基础的通信。真实应用远没这么简单。比如一个聊天室服务端要把一个客户端发来的消息转发给其他所有客户端这就需要维护一个连接列表并且在转发时考虑“其他客户端的分包情况”。这个小小的需求已经能引申出很多问题连接列表用什么数据结构管理操作时要不要加锁客户端离线怎么从列表里剔除如果其中一个客户端接收慢会拖累整个服务端吗消息是否需要持久化有人把网络编程比作打字聊天时的“对方正在输入”提示因为状态管理无处不在。你先把回显服务跑通再试着加一个“群发”功能你会立刻发现并发状态管理才是真正考验水平的地方。5.2 网络编程的通用知识可以迁移到任何语言虽然我用 Python 做了实操但这一整套思想是跨语言的。Java 里面有ServerSocket和SocketGo 里有net.Listen和net.DialNode.js 里是net.createServer概念全部对应得上。你只要掌握了 TCP 握手、缓冲区、粘包、并发模型这些底层原理换语言只是换 API 写法而已。这也是为什么我建议初学者不要整天追新框架先把 socket 程序写熟练。框架会变协议不会变。今天学的 TCP 字节流特性你在十年后写任何网络服务依然要面对。5.3 踩坑后的几点忠告最后分享几个我在实际调试中积累的经验不算什么了不起的道理但都是被坑过之后长记性的地方。第一不要把recv的返回值和非空消息混为一谈。recv返回b是对方关闭连接的唯一可靠信号但它同时也是一个合法返回值千万不要把空消息本身当作协议的一部分去解析。第二一定要给服务端设置合理的超时和异常处理。网络是天生不可靠的你的程序必须假设所有可能出错的地方都会出错。不设超时的服务端在生产环境就是一个定时炸弹。第三调试网络程序先确认网络连通性再怀疑代码逻辑。我见过有人排查了一个小时最后发现服务端监听的是127.0.0.1而客户端在另一台机器上连接肯定连不上。先检查监听地址、防火墙、端口占用这些外部因素再深入代码内部。第四不要在收数据时一次性recv(65535)然后期望它包含完整消息。缓冲区大小只是一个上限不表示底层会按这个大小切分数据。写代码时永远假设“这次 recv 返回的字节数是不确定的”用recv_exactly或缓冲区累积来处理。第五多读几个开源项目的网络层代码。我自己的体会是真正让我从“懂概念”到“能落地”的转折点是读了一个消息队列客户端的源码看它是怎么用缓冲区、怎么处理半包的。单纯看教程十遍不如读一份优秀的实现一遍。网络编程这条路今天算是一个很有仪式感的起点。往后你会发现几乎所有高端话题——分布式系统、微服务治理、实时音视频、区块链网络底层——都得回到今天这些原点上。把这些基石打扎实后面每一步都会走得稳当得多。 
长河君 · 2026/10/21 22:39:55 · 阅读 1.2k 网络编程入门：TCP/UDP、Socket与聊天室实战解析
看了这么多天基础语法和数据结构今天终于走到了网络编程。在编程学习路径里这一天往往是一个分水岭前边学的所有东西都是程序在“自己跟自己玩”而网络编程让程序和世界连在了一起。我个人的感受是掌握了这部分你再回头看那些“系统设计”“分布式”“微服务”之类的词汇就不会觉得虚了因为它们的地基就是今天要聊的这套东西。这篇文章我会从最底层的通信模型讲起把 TCP、UDP、套接字、握手、缓冲区这些概念全部捋一遍然后带着你从零写一个可用的 TCP 聊天服务讲清楚服务端和客户端各自的职责再顺手解决并发、粘包、端口占用这些实战里必踩的坑。无论你是刚学完 Python 基础想进阶还是准备面试想补网络基础这篇都值得你花点时间认真读一遍。1. 网络编程到底在解决什么问题1.1 一切从通信模型说起先想一个问题如果让你设计一个程序让两台电脑之间可以互相发消息你会怎么搞你可能会说把消息写到文件里另一台电脑去读不行两台电脑没有共享磁盘。那插个 U 盘拷过去这确实能传输数据但它本质上不是“通信”因为整个过程没有两台电脑直接对话。网络编程要解决的核心问题就一句话让两台独立运行的设备通过网络介质按照共同的规则交换数据。这就牵扯出两个基本概念一个叫“客户端”一个叫“服务端”。客户端是主动发起请求的一方服务端是等待请求并处理的一方。比如你打开浏览器访问网站浏览器就是客户端网站服务器就是服务端。这个模型叫 C/S 模型它是绝大多数网络应用的基本结构。理解 C/S 模型有一个要点服务端必须先启动并且在自己的端口上“蹲守”客户端才能找到它。你可以把这个过程类比成打电话服务端是那个一直在办公室坐着、电话开机的人客户端是拿起电话拨号的人。电话没开机你拨号只会听到“您拨打的用户暂时无法接通”。对应到程序里就是连接被拒绝。1.2 协议栈与数据流转两台设备之间要通信光有“我想发数据”的意愿远远不够。数据在网络上怎么找到对方怎么保证不丢怎么知道数据是给哪个程序的这些问题如果每个开发者都要自己解决那整个互联网早就乱套了。所以行业里把通信规则做成了分层模型最普及的参考模型是 TCP/IP 四层模型应用层、传输层、网络层、链路层。应用层你写的代码比如 HTTP、FTP、WebSocket协议语义就在这一层。传输层负责端到端的传输TCP 和 UDP 就在这一层它决定了数据是否可靠、是否有序。网络层负责寻址和路由IP 协议在这一层每台设备都有 IP 地址数据包靠它找到对方。链路层负责物理网络中的传输比如网卡、以太网协议。我们平时在代码里操作的东西基本都是在应用层和传输层。数据发送时是从上往下逐层“打包”应用层数据交给传输层加上端口信息网络层加上 IP 地址链路层加上 MAC 地址等信息最后变成比特流扔到网线上。接收方再做相反的过程一层层“拆包”最终把数据交给对应程序。这个过程我建议你一定要画一遍哪怕就用笔在纸上画个箭头也行。以后遇到“为什么我的数据发不过去”“为什么服务端收不到消息”这类问题排查思路基本就是沿着这条链路自下而上或自上而下过一遍。1.3 设计选择TCP还是UDP网络编程里第一个真正的选择就是到底用 TCP 还是 UDP。这两个协议完全不同选错后面全白干。TCP传输控制协议是面向连接的、可靠的、基于字节流的传输协议。它通过三次握手建立连接数据有确认机制丢包会重传能保证数据按顺序到达对方的缓冲区。代价是效率相对低、连接有状态、协议头更大。UDP用户数据报协议是无连接的、不可靠的、基于数据报的传输协议。它不建立连接发完就完数据有可能丢失、乱序、重复到达。它不管对方收没收到但胜在开销小、延迟低、支持广播和多播。什么场景用 TCP什么场景用 UDP我举个例子你就明白了。你在网上下载文件一个字节都不能错错一个文件可能就打不开了这种场景必须 TCP。再比如视频通话、在线游戏里的位置同步帧丢一两帧无所谓下几帧补上就行但延迟一定要低这种场景 UDP 更合适。当然现实中很多应用是混合用的握手和关键控制信令走 TCP音视频数据走 UDP。我个人给初学者一个很实用的建议第一次写网络程序无脑选 TCP。TCP 的逻辑更符合直觉调试起来也更容易等把 TCP 玩通了你自然会理解 UDP 的价值在哪里。2. 核心细节解析与实操要点2.1 套接字网络编程的基本操作单元网络编程的一切操作几乎都围绕着一个叫“套接字”的东西展开。英文叫 Socket很多教程也直接叫“Socket 编程”。Socket 是什么一句话说它是操作系统提供的一个编程接口让你可以通过文件描述符的方式去操作网络连接。你读写网络数据就像读写文件一样调用 read/write只不过底层流转是在网络上。这个设计非常巧妙Unix 哲学里“一切皆文件”的思想在这里得到了延续。Python 标准库提供了socket模块封装了系统调用所以你不必理会 C 语言那些繁琐的结构体。一个典型的 TCP 服务端代码流程是这样创建 socket 对象绑定地址和端口bind监听客户端连接listen接受连接拿到一个新的 socketaccept用这个新 socket 收发数据recv / send关闭连接close客户端流程更简单创建 socket 对象连接服务端connect收发数据关闭这里有个非常容易混淆的细节accept 返回的 socket 和最初创建的那个 socket 不是一回事。监听 socket 只负责“接电话”accept 之后返回的那个新 socket 才是真正“通话”的通道。服务端可以同时持有多个这样的通信 socket分别对应不同的客户端这就是并发的基础。2.2 创建套接字与关键参数用 Python 创建 socket通常一句话就够了import socket s socket.socket(socket.AF_INET, socket.SOCK_STREAM)这里的两个参数决定了这个 socket 的工作方式。第一个参数AF_INET是地址族指定使用 IPv4 地址。平时写代码基本就用它。如果你要处理 IPv6可以改成AF_INET6。对于纯内网通信或者学习阶段IPv4 足够。第二个参数SOCK_STREAM表示流式套接字对应 TCP。如果改成SOCK_DGRAM就是数据报套接字对应 UDP。这两个词要记住面试和实际阅读代码都常碰到。还有一个常见的坑IPv4 地址到底传什么。bind和connect都需要一个地址元组(ip, port)。服务端绑定时ip 可以填127.0.0.1表示只允许本机访问也可以填0.0.0.0表示监听所有网卡允许外部设备访问。如果你在局域网里想用手机连你电脑上的服务服务端必须绑0.0.0.0或者你电脑的具体局域网 IP不然会被系统直接拒绝。端口号的范围是 0 到 65535其中 0 到 1023 是特权端口通常需要管理员权限才能绑定。自己写程序测试时尽量用 8000 以上的端口避免跟系统服务冲突。2.3 三次握手connect背后的流程每次执行connect时如果你的传输层用的是 TCP内核会自动为你完成“三次握手”。这个过程极其重要很多面试题考它排查网络故障也绕不开它。三次握手的过程可以这样理解客户端发送一个 SYN 报文意思是“我想建立连接”。服务端收到后回复 SYN ACK 报文意思是“我收到你的请求了同时我也想建立连接”。客户端再回复一个 ACK 报文意思是“我知道你收到了连接正式建立”。为什么需要三次而不是两次有一个很容易理解的解释握手的目的之一是让双方确认彼此的收发能力都正常。第一次握手服务端确认客户端能发第二次握手客户端确认服务端能收、能发第三次握手服务端确认客户端能收。到这一步两边都确认了“你能收我发的我也能收你发的”连接才算稳。你可能会问那我connect没成功是为什么常见原因有两个一是服务端根本没监听内核直接返回“连接被拒绝”这种错误是立刻的二是服务端监听但连接队列满了或者网络不通客户端会一直等下去直到超时。这两种出现的现象完全不同排查时可以先区分。2.4 缓冲区与send/recv的真相初学网络编程很多人会想当然地认为send发多少数据对方recv就会收到多少数据。这是最大的误解之一。TCP 是字节流协议它在传输层不关心什么“消息”边界。你调用send(bhello world)这 11 个字节进入发送缓冲区内核会自己决定怎么把它分成若干数据包发出去。对方调用recv(1024)它从接收缓冲区里取出 1024 个字节但取出的不一定是那完整的 11 个字节可能只有 5 个也可能已经包含了下一段消息的内容。这意味着什么意味着网络编程没有“一次发送一次接收”对应关系的保证。你必须在应用层想办法确定消息的边界。最常用的办法有三种固定长度每条消息都定长比如 4 字节收不够就继续收多了就存着下次处理。分隔符消息之间用特殊字符分隔比如\n收到就按分隔符切分。长度前缀先发送 4 字节的包头表示后面数据的字节数接收方先收包头再按长度收包体。第三种方案是工程上最通用的后面实操我会带着你实现。现在你只需要建立一个意识用 TCP 做通信应用层协议是必须自己设计的。3. 上手实操从单联接到并发聊天室3.1 环境准备与基础示例实操之前先把工具准备好。Python 3.8 以上就自带socket模块不需要装第三方库。为了方便跟踪网络状态推荐装一个 Wireshark抓包分析但不是必需。调试时可以先用telnet工具模拟客户端或者干脆用 Python 写一个测试客户端。写一个最小可用的 TCP 服务端其实不到十行import socket server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.bind((0.0.0.0, 9000)) server.listen(5) print(server is listening on 9000) while True: conn, addr server.accept() print(fnew connection from {addr}) data conn.recv(1024) print(freceived: {data.decode()}) conn.send(bgot it) conn.close()这段代码只能处理一个连接而且是一次性的接受连接、收一条消息、回一句、关闭。但它把服务端的基础流程完整展示出来了。如果你现在运行它再用浏览器访问http://127.0.0.1:9000你会看到浏览器发送的 GET 请求文本在终端里打出来。这是一个很有成就感的时刻因为你的程序真的在跟外部世界交互了。3.2 从零实现一个可复用的服务端上面的例子太简陋真正可用的服务端要能反复处理连接并且一个连接里可能有多条消息。我们先加一个循环让同一个连接能持续收发消息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(server is listening on 9000) while True: conn, addr server.accept() print(fnew connection from {addr}) try: while True: data conn.recv(1024) if not data: break print(freceived: {data.decode()}) conn.sendall(becho: data) except ConnectionResetError: print(fclient {addr} closed abruptly) finally: conn.close() print(fconnection from {addr} closed)注意到我在开头加了一行setsockopt设置SO_REUSEADDR。这一行非常实用它允许服务端关闭后立刻重新绑定同一个端口。不加这行程序结束后端口可能还处在 TIME_WAIT 状态重新运行时会报“address already in use”。这是初学阶段最常见的报错之一后面我还会细说。内层循环里我判断if not data: break这是 TCP 编程里一个很重要的约定对方关闭连接时recv 会返回空字节串 b。收到这个就说明对端已经关闭该结束这次通信了。很多人忘了这个判断导致程序卡在 recv 上永远等下去。3.3 客户端怎么配合有服务端必须有客户端客户端代码相比之下简单得多import socket client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect((127.0.0.1, 9000)) try: while True: msg input(please input: ) if not msg: break client.sendall(msg.encode()) response client.recv(1024) print(fserver response: {response.decode()}) finally: client.close()这个客户端从终端读一行发给服务端然后打印服务端的回显。实验的时候可以在一个终端窗口开服务端在另一个终端窗口跑这个客户端。我这里故意把sendall和send区分开来提一下send返回的是实际发送的字节数可能比你给的数据少sendall会循环发送确保全部发送成功。应用层写代码能用 sendall 就不要用 send。运行几次之后你会有一种感觉原来网络通信并不玄乎就是两端按约定好的顺序互相往 socket 里塞数据。但到这一步服务端还是只能服务一个客户端第二个客户端连进来时会被晾在 accept 队列里。要解决这个问题得引入并发。3.4 引入多线程让服务端一次服务多个客户端最简单的并发方案就是每个客户端来了给它开一个线程。主线程继续 accept新连接的收发都在子线程里处理。import socket import threading def handle_client(conn, addr): print(fnew connection from {addr}) try: while True: data conn.recv(1024) if not data: break print(f{addr} - {data.decode()}) conn.sendall(becho: data) except ConnectionResetError: pass finally: conn.close() print(fconnection from {addr} closed) 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(server is listening on 9000) while True: conn, addr server.accept() t threading.Thread(targethandle_client, args(conn, addr)) t.start()到这里一个多客户端聊天服务端就成型了。每个客户端连接都由独立的线程处理互不阻塞。注意一点线程的 daemon 属性需要看情况设置。如果你希望在主程序退出后线程也自动结束可以在start()前设置t.daemon True。但在大多数服务端场景里我们希望线程能处理完所以不设置 daemon 也是合理的。多线程方案的好处是简单直观但缺点也明显如果同时有几千个客户端连接每个连接一个线程资源开销会把程序拖垮。生产环境里通常会改用事件驱动模型Python 的asyncio或者selectors模块就是干这个的。初学者先把多线程方案吃透再去学事件循环理解曲线会顺很多。3.5 用 selectors 实现单线程高并发说一个“可选的进阶版”因为这块很容易劝退新手我先给你一个直观的认识。selectors模块是基于操作系统 IO 多路复用机制的封装核心思想是一个线程同时盯着很多 socket 文件描述符哪个有数据就处理哪个没有数据的就放着不管。用 selectors 改造上面的回显服务端import selectors import socket sel selectors.DefaultSelector() def accept_conn(server): conn, addr server.accept() conn.setblocking(False) sel.register(conn, selectors.EVENT_READ, read_handler) def read_handler(conn, mask): data conn.recv(1024) if data: conn.sendall(becho: 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(5) server.setblocking(False) sel.register(server, selectors.EVENT_READ, accept_conn) while True: events sel.select(timeoutNone) for key, mask in events: callback key.data callback(key.fileobj, mask)注意这里要求 socket 是非阻塞的调用了setblocking(False)否则注册到 selector 里没有意义。非阻塞模式下recv如果没数据会立刻返回一个BlockingIOError异常而 selector 会帮我们保证能读的时候才回调所以这个异常不会发生。这个方案能在一个线程里管理成千上万的连接是生产级服务常用的模型。你不一定马上要会写但至少要知道有这条路线。真到了需要自己写服务端框架的时候再回头深入学asyncio就事半功倍。4. 常见问题与排查技巧实录4.1 端口被占用怎么办这个错误几乎每个人都会遇到。现象是运行服务端时报错OSError: [Errno 98] Address already in use原因是上一次运行的服务端没有释放端口或者别的程序占了同一个端口。解决方式分几步走先确认谁占了这个端口。Linux 下可以用lsof -i :9000或netstat -tlnp | grep 9000查看。如果确定是自己的僵尸进程可以用kill命令结束它。如果是正常退出后立刻重启导致 TIME_WAIT 占用记住我在代码里加的那行SO_REUSEADDR它能让你快速重启而不需要等内核超时。有一个很重要的认知TIME_WAIT 状态的时间不是程序能控制的通常持续几十秒到几分钟。这是 TCP 协议为保证旧连接的延迟数据包不会干扰新连接而做的设计。有的生产系统会专门调节内核参数来缩短这个时间但那是运维层面的活儿。你只需要知道这不是 bug是协议保护机制。4.2 粘包和拆包应用层必须处理的头等大事粘包这个词听起来玄乎实际就是两条消息在接收端被一次性读出来了或者一条消息被分两次读出。原因我在前面第 2.4 节已经埋伏了全是因为 TCP 是字节流没有消息边界。比如客户端连续发送bhello和bworld服务端recv(1024)可能一次收到bhelloworld。这就是粘包。如果客户端只发一个 3000 字节的大消息服务端recv(1024)可能先收到前 1024 字节这是拆包。解决思路就是设计一个简单的协议。我推荐最通用的长度前缀方案实现起来也不难import struct def send_message(sock, data: bytes): # 4字节大端整数表示消息长度 header struct.pack(I, len(data)) sock.sendall(header data) def recv_exactly(sock, n: int) - bytes: data b while len(data) n: chunk sock.recv(n - len(data)) if not chunk: raise ConnectionError(connection closed while receiving) data chunk return data def recv_message(sock) - bytes: header recv_exactly(sock, 4) msg_len struct.unpack(I, header)[0] return recv_exactly(sock, msg_len)这里recv_exactly的作用是“收满 n 个字节才返回”不管底层分多少次送到。用这套收发函数应用层就可以放心地按“一条消息一个 recv_message”来编写逻辑了。粘包问题从根上解决。非阻塞和异步场景下这套方案要搭配缓冲区来用但思路不变先收满包头再收满包体。无论你以后用 Netty、Go 的 bufio 还是 Node.js 的流式处理这个原则都是通用的。4.3 recv阻塞导致程序卡死的排查思路新手最常见的疑惑是服务端跑得好好的客户端也发数据了但服务端就是没有任何输出。这时候十有八九是recv在阻塞等待数据而你以为它“应该收到”的数据并没有到缓冲区。排查时按顺序检查客户端是否真的发送成功了sendall没抛异常不代表网络传输成功只代表数据交给了内核缓冲区。客户端发送的数据是否被连接的另一端的接收逻辑读取了有时候是服务端代码逻辑错位比如先发后收导致互相等待。有没有在recv前调用了某些阻塞操作把整个流程卡住了另外生产环境的服务端不能容忍无限阻塞所以通常要给 socket 设置超时conn.settimeout(5.0) try: data conn.recv(1024) except socket.timeout: print(recv timeout)设置了超时之后超过 5 秒没有数据recv会抛出socket.timeout异常你就可以做对应的处理比如记录日志、关闭连接或继续轮询。要注意一旦设置超时后续所有 recv/send 调用都受这个超时影响不想要的话要重新设成None。4.4 半开连接与连接重置的实战处理还有一种暗坑叫“半开连接”。想象一个场景客户端程序崩溃了但操作系统没有来得及发送 FIN 包服务端这边完全不知道连接已经死亡。服务端继续recv就会一直阻塞直到 TCP 的保活机制或你手动设置的超时触发。在局域网环境里这种问题往往要等很久才能被发现。应对手段通常是在应用层做心跳客户端每隔一段时间发送一个心跳包服务端超过一定间隔没收到就认为连接失效主动关闭。这是所有在线服务都要考虑的基础能力QQ、微信、各种 App 的长连接背后都有一套心跳机制在支撑。另外如果客户端进程被强杀服务端在往这条连接写数据时可能收到ConnectionResetError也就是常见的“对端连接重置”。这在 Python 里是ConnectionResetError异常代码里要捕获它并做清理。我在前面示例里都加了except ConnectionResetError就是为了应对这种情况。实际生产环境里除了ConnectionResetError还建议捕获BrokenPipeError它发生在你往一个对端已关闭的连接写数据时。4.5 调试工具从 print 到 Wireshark写网络程序光靠 print 日志有时候很难定位问题因为问题可能出在内核协议栈里。你需要合适的工具。最方便的是抓包工具我平时用 Wireshark图形界面、tcpdump命令行适合服务器上抓。抓本机回环流量时注意 Wireshark 需要选择lo网卡并且可能需要管理员权限。抓到包之后配合过滤条件tcp.port 9000和follow tcp stream功能你能直接看到按时间顺序排列的每一个报文什么 SYN、ACK、PSH、FIN 一目了然。还有个轻量方法是用nc命令快速测试端口是否通、服务是否能响应。比如nc -vz 127.0.0.1 9000表示检查 9000 端口是否能连接。这种方法在排查“服务端没起来”还是“客户端连不上”的定位上非常快。当你熟练使用这些工具后排查思路会清晰很多先抓包看有没有报文到达再在代码里打日志看有没有执行到对应位置最后对照协议分析是发送方问题还是接收方问题。网络编程的调试本质上是在回答“数据到底走到哪一步了”这个问题。5. 进一步优化与个人体会5.1 从回显服务到真正的应用层协议我们前面写了一个回显服务它只完成了最基础的通信。真实应用远没这么简单。比如一个聊天室服务端要把一个客户端发来的消息转发给其他所有客户端这就需要维护一个连接列表并且在转发时考虑“其他客户端的分包情况”。这个小小的需求已经能引申出很多问题连接列表用什么数据结构管理操作时要不要加锁客户端离线怎么从列表里剔除如果其中一个客户端接收慢会拖累整个服务端吗消息是否需要持久化有人把网络编程比作打字聊天时的“对方正在输入”提示因为状态管理无处不在。你先把回显服务跑通再试着加一个“群发”功能你会立刻发现并发状态管理才是真正考验水平的地方。5.2 网络编程的通用知识可以迁移到任何语言虽然我用 Python 做了实操但这一整套思想是跨语言的。Java 里面有ServerSocket和SocketGo 里有net.Listen和net.DialNode.js 里是net.createServer概念全部对应得上。你只要掌握了 TCP 握手、缓冲区、粘包、并发模型这些底层原理换语言只是换 API 写法而已。这也是为什么我建议初学者不要整天追新框架先把 socket 程序写熟练。框架会变协议不会变。今天学的 TCP 字节流特性你在十年后写任何网络服务依然要面对。5.3 踩坑后的几点忠告最后分享几个我在实际调试中积累的经验不算什么了不起的道理但都是被坑过之后长记性的地方。第一不要把recv的返回值和非空消息混为一谈。recv返回b是对方关闭连接的唯一可靠信号但它同时也是一个合法返回值千万不要把空消息本身当作协议的一部分去解析。第二一定要给服务端设置合理的超时和异常处理。网络是天生不可靠的你的程序必须假设所有可能出错的地方都会出错。不设超时的服务端在生产环境就是一个定时炸弹。第三调试网络程序先确认网络连通性再怀疑代码逻辑。我见过有人排查了一个小时最后发现服务端监听的是127.0.0.1而客户端在另一台机器上连接肯定连不上。先检查监听地址、防火墙、端口占用这些外部因素再深入代码内部。第四不要在收数据时一次性recv(65535)然后期望它包含完整消息。缓冲区大小只是一个上限不表示底层会按这个大小切分数据。写代码时永远假设“这次 recv 返回的字节数是不确定的”用recv_exactly或缓冲区累积来处理。第五多读几个开源项目的网络层代码。我自己的体会是真正让我从“懂概念”到“能落地”的转折点是读了一个消息队列客户端的源码看它是怎么用缓冲区、怎么处理半包的。单纯看教程十遍不如读一份优秀的实现一遍。网络编程这条路今天算是一个很有仪式感的起点。往后你会发现几乎所有高端话题——分布式系统、微服务治理、实时音视频、区块链网络底层——都得回到今天这些原点上。把这些基石打扎实后面每一步都会走得稳当得多。