很多人第一次写 TCP 程序，都是从回显服务器开始的：客户端发什么，服务器就原样返回什么。跑通了之后往往觉得不过瘾，因为回显程序没有任何“业务逻辑”。我一般建议新手把第一个正经的网络程序改成“TCP 四则运算服务”：客户端从键盘输入加减乘除表达式，把字符串发给服务器，服务器完成解析和计算，再把结果返回给客户端。别看例子小，这一来一回之间，把 socket 生命周期、协议设计、粘包处理、异常排查全部串起来了。这篇东西就按我实际带人跑这个 Demo 的过程来写，代码可以直接抄，中间穿插的坑都是实测踩过的。

1. 为什么从“TCP加计算器”入手：这个Demo到底在练什么

1.1 从 echo 到计算器：项目呈现的完整链路

回显服务器最大的问题是“太顺了”：收到什么就回什么，不需要考虑数据的含义，也不需要处理错误。你把回显改成计算器，难度立马就不一样了，因为它强迫你面对网络编程里最核心的几个问题：

• 客户端要持续从键盘读输入，输入本身是零散的、带格式的；
• 服务器不能只“收”，还要做解析、计算、错误处理，再把结果返回；
• 双方得约定好一条消息从哪开始、到哪结束；
• 连接可能随时中断，客户端可能发来乱七八糟的内容。

所以这个项目表面上是一个玩具，实际上是把“应用层协议”“socket 阻塞模型”“消息边界”“异常兜底”这四件事全部过了一遍。我甚至觉得，能独立把这个 Demo 写干净的人，写一般的业务通信接口基本不会犯低级错误。

1.2 TCP 与 UDP 的直觉对比：为什么要用 TCP

有些新手会问，计算器为什么要用 TCP，用 UDP 不行吗？我习惯用寄快递来类比：UDP 是明信片，写好就丢出去，不保证对方一定收到，也不保证顺序，但快；TCP 是挂号信，先打电话确认有人接收，再一封一封按顺序送达，收不到就重发。四则运算的结果如果丢了、错乱了，用户立刻会发现，所以必须要一个可靠、有序的通道。

从技术角度看，TCP 是面向连接的字节流，通信前必须三次握手建立连接，发送的数据最终在内核里被拆成一个个数据段，接收方按序重组。UDP 是无连接的数据报，每次 send 对应一次独立发送，有消息边界但不可靠。这个 Demo 的核心目标是“把数据完整地从一端送到另一端并拿回结果”，所以选择 TCP 是唯一合理的答案。

1.3 教学选型对比：Python、Java、C/Go 各自适合的切入方式

我在博客里写这个项目用的是 Python，理由很简单：标准库自带 socket 模块，代码量小，不需要处理 C 语言那套繁琐的缓冲区生命周期，也不像 Java 那样需要容器支撑。适合“先理解网络通信流程”的阶段。

当然这不代表其他语言不值得学：

选型思路是：如果你是零基础，先用 Python 跑通整个流程；如果你已经会用 Python 写，再拿 Go 或 C 重写一遍，重点感受“缓冲区不同导致的心智负担差异”。同一套逻辑，换一种语言写，理解深度完全不一样。

2. 动手前必须定的三件事：协议格式、行缓冲模型、并发方式

2.1 请求响应协议：行分隔符 vs 长度前缀

写代码之前，第一件事不是敲 socket，而是定协议。计算器这个场景的协议很简单：客户端发来一行文本，比如1+2*3\n，服务器算完返回一行结果7\n。以换行符\n作为一条消息的结束标志，这就是行分隔符协议。

另一种常见方案是长度前缀协议，发送方先写 4 字节的大端整数表示消息体长度，再写消息体本身。行分隔符的好处是直观、人类可读，适合文本指令；长度前缀适合二进制数据、内容本身可能包含换行符的场景。做计算器用行分隔符就够，但你要知道有这两种思路，因为后面的粘包处理方式完全不一样。

2.2 TCP 是字节流：粘包、拆包问题从第一天就要认识

很多刚接触 socket 的人会以为“发送端 send 一次，接收端 recv 一次”就能一一对应。实际上 TCP 不会帮你保存任何消息边界。比如你连续调用了三次 send，分别发送1+1\n、2+2\n、3+3\n，接收端很可能一次 recv 就同时收到b'1+1\n2+2\n3+3\n'，这就是粘包。反过来说，如果一条消息本身很大，接收端一次 recv 可能只拿到前半段，这是拆包。

解决思路只有一个：在应用层自己定边界。行分隔符协议下，接收方维护一个缓冲区，把每次 recv 到的数据追加进去，然后不断检查缓冲区里有没有\n，有就切出来当一条完整消息处理。你要记住，这不是某个框架的问题，是 TCP 的固有特性，任何网络程序都无法绕过。

2.3 服务端模型：单线程循环、线程池、协程怎么选

最早的教学版本往往是单线程的：

while True: conn, addr = server.accept() handle_client(conn)

但这个写法有个致命的体验问题：handle_client通常要阻塞在recv上等客户端输入，如果第一个客户端连上之后迟迟不发算式，第二个客户端的accept永远等不到。也就是说，单线程只能同时服务一个连接。

教学 Demo 最稳妥的提升方式是“每连接一线程”：主线程只负责accept，每进来一个客户端就开一个线程去处理。这个模型虽然资源开销大，但逻辑最简单，适合解释清楚“谁在等谁”。真要拿去做生产服务，再换 ThreadPoolExecutor 限流、或者用 asyncio/go 协程，那是后话。我在代码里就用守护线程来处理每个客户端。

2.4 表达式计算：为什么我不推荐直接 eval

动态语言里有个看起来很爽的解法：服务器收到字符串之后，直接eval一下，结果就出来了。比如收到"1+2*3"，eval返回7，三行代码搞定。但这就是一个巨大的安全漏洞：eval会把它收到的字符串当成代码来执行。如果客户端发送的内容不是正经算术表达式，而是一条恶意代码指令，服务端就等于被别人远程操纵了。

虽然这个 Demo 是拿来练习的，本地跑不会出什么事，但我建议从第一行代码开始就养成不信任输入的习惯。四则运算的解析器也就几十行，写起来完全可控。下面的完整代码里，我给了不用eval的递归下降解析版，支持加减乘除、括号、浮点数和空格。

3. 完整代码：服务端、客户端、表达式解析器

3.1 项目文件结构

建议拆成三个文件，职责分离：

tcp_calculator/ ├── server.py # 服务器端：监听、接收、计算、返回 ├── client.py # 客户端：键盘输入、发送、打印结果 └── calculator.py # 表达式解析与计算，不依赖网络

把计算逻辑单独放在calculator.py里，好处是将来如果要写单元测试、或者在别的协议里复用，都不需要牵扯 socket 代码。

3.2 服务端实现逐段拆解

先看server.py：

import socket import threading host = '0.0.0.0' port = 9000 threads = [] def handle_client(conn, addr): print(f"[连接] {addr} 已接入") conn.sendall(b"欢迎使用TCP计算器。请输入表达式，例如 1+2*3；输入 quit 退出。\n") buf = b'' try: while True: data = conn.recv(1024) if not data: # 客户端关闭连接时，recv 会返回空字节串 break buf += data # 按行切分出完整请求, 粘包/拆包都在这里解决 while b'\n' in buf: line, buf = buf.split(b'\n', 1) line = line.strip() if not line: continue text = line.decode('utf-8', errors='replace') if text.lower() in ('quit', 'exit'): conn.sendall(b"bye\n") return try: result = calculate(text) response = f"{text} = {result:g}\n".encode('utf-8') except Exception as exc: response = f"error: {exc}\n".encode('utf-8') conn.sendall(response) except ConnectionResetError: print(f"[连接] {addr} 异常断开") finally: conn.close() print(f"[连接] {addr} 已断开") def main(): server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((host, port)) server.listen(5) print(f"TCP计算器服务端已启动，监听 {host}:{port}") while True: conn, addr = server.accept() t = threading.Thread(target=handle_client, args=(conn, addr), daemon=True) t.start() if __name__ == '__main__': main()

这段代码值得注意的有几个点：

1. recv(1024)每次最多读 1024 字节，但一次读到的内容可能包含多条消息的一半，所以用一个buf累积，循环切分。
2. recv返回b''表示对端已经关闭连接，这是判断断开的唯一可靠信号，一定不能用空数据和“没消息”混在一起。
3. ConnectionResetError是客户端直接强杀进程时，服务端在send或者recv的时候会碰到的异常，必须单独捕获，否则线程直接崩。
4. 子线程设置成daemon=True，主程序 Ctrl+C 退出时线程不会残留。

3.3 客户端实现逐段拆解

再来看client.py：

import socket host = '127.0.0.1' port = 9000 def recv_line(sock): buf = b'' while True: data = sock.recv(1024) if not data: return None buf += data if b'\n' in buf: line, buf = buf.split(b'\n', 1) return line def main(): sock = socket.create_connection((host, port), timeout=10) try: welcome = recv_line(sock) if welcome: print(welcome.decode('utf-8', errors='replace')) while True: try: line = input("请输入表达式: ").strip() except (EOFError, KeyboardInterrupt): break if not line: continue sock.sendall((line + '\n').encode('utf-8')) if line.lower() in ('quit', 'exit'): break resp = recv_line(sock) if resp is None: print("[提示] 服务器已断开连接") break print(resp.decode('utf-8', errors='replace').strip()) finally: sock.close() if __name__ == '__main__': main()

客户端这边，我特意写了一个recv_line而不是直接recv(1024)，目的和服务端一样：结果消息虽然短，但以后如果服务端返回长文本，或者多条结果粘在一起，这个函数都能按行正确切分。socket.create_connection是socket.connect的增强版，不需要自己构造 sockaddr，也支持超时。

3.4 四则运算解析器实现（不用 eval 也能算）

接着是calculator.py，核心思路是递归下降解析。表达式结构可以拆成三层：表达式（加减）、项（乘除）、因子（数字或括号）。

import re def calculate(expr: str) -> float: expr = expr.replace(' ', '') tokens = re.findall(r'\d+\.?\d*|[+\-*/()]', expr) if not tokens: raise ValueError("空表达式") pos = 0 def peek(): if pos >= len(tokens): return None return tokens[pos] def pop(): nonlocal pos t = tokens[pos] pos += 1 return t def parse_expr(): val = parse_term() while peek() in ('+', '-'): op = pop() rhs = parse_term() if op == '+': val += rhs else: val -= rhs return val def parse_term(): val = parse_factor() while peek() in ('*', '/'): op = pop() rhs = parse_factor() if op == '*': val *= rhs else: if abs(rhs) < 1e-10: raise ValueError("除数不能为零") val /= rhs return val def parse_factor(): t = pop() if t is None: raise ValueError("表达式不完整") if t == '(': val = parse_expr() if pop() != ')': raise ValueError("括号不匹配") return val try: return float(t) except ValueError: raise ValueError(f"无效的符号: {t}") result = parse_expr() if pos < len(tokens): raise ValueError("表达式存在多余内容") return result

这套解析器支持1+2*3、(1+2)*3、3.14*2以及带空格的写法，不依赖任何第三方库。它最大的优点是只做数学计算，不执行任意代码，所以放到服务端是安全的。当然它的功能范围有限，不支持负数开头（比如-3+5），不太适合做课程设计里“任意合法表达式”的需求。

3.5 运行效果预期

代码写完后，两个终端分别运行：

python server.py python client.py

正常交互会是这样：

欢迎使用TCP计算器。请输入表达式，例如 1+2*3；输入 quit 退出。 请输入表达式: 1+2*3 1+2*3 = 7 请输入表达式: (10-4)/2 (10-4)/2 = 3 请输入表达式: 1/0 error: 除数不能为零 请输入表达式: 2+a error: 无效的符号: a

服务端终端会同步打印接入记录、断开记录。如果一次开两个客户端同时连上去，会发现各自都能正常收发，互不干扰，这就是线程模型的功劳。

4. 一次请求的完整旅程：从键盘回车到屏幕打印之间发生了什么

4.1 沿着 socket 缓冲区走一遍

很多人把 socket 理解成“一根管子，从这头塞进去，那头冒出来”，其实更准确的说法是“两个缓冲区 + 内核协议栈”。客户端执行input拿到字符串之后，调sendall，这一步做的事情是：

1. 把字符串按 UTF-8 编码成字节；
2. 调用系统调用，把字节从用户态复制到内核态发送缓冲区；
3. 协议栈按 TCP 分段规则，把字节拆成若干段，经网络发给对方；
4. 服务端内核收到数据段，按序放到接收缓冲区；
5. 服务端进程调recv，把数据从内核缓冲区复制到用户态的 Pythonbytes对象里。

所以这里的sendall并不是“直接递给对方进程”，而是“交给内核”。这也是为什么粘包无法避免的原因：内核只负责搬运字节流，它不知道你要在哪里切一刀。

4.2 用 tcpdump 亲眼看到三次握手与四次挥手

如果条件允许，我建议在这个 Demo 上顺手抓个包，能直观看到 TCP 的状态机。在 Linux 本机环境，可以直接抓回环口：

sudo tcpdump -i lo tcp port 9000 -nn -A

启动服务端后运行客户端，输入一个表达式，你会在抓包结果里看到：

1. 第一个S包，客户端向服务端发 SYN，请求建立连接；
2. 服务端回S.，也就是 SYN-ACK，同意连接；
3. 客户端回.，ACK 确认，连接建立；
4. 之后出现P.包，里面带有 ASCII 可读的表达式内容；
5. 连接关闭时，双方各发一个F（FIN），完成四次挥手。

看到这些日志后再回看代码，你会觉得listen、accept这些词不再是黑盒。Wireshark 也能做同样的事情，图形界面下过滤tcp.stream即可，这里不多展开。

4.3 粘包实验：连续发送三条表达式会怎样

如果你把客户端里的发送方式临时改成一次发送三条表达式：

sock.sendall(b"1+1\n2+2\n3+3\n")

然后观察服务端日志，会发现服务端很可能只调用了两次recv甚至一次recv，就拿到全部数据。但因为服务端代码里有while b'\n' in buf的切分逻辑，它仍然会解析出三条独立计算：

• 第一轮处理1+1 = 2
• 第二轮处理2+2 = 4
• 第三轮处理3+3 = 6

这就是行缓冲模型的意义。我第一次写这个 Demo 的时候偷懒，直接recv(1024)当成一条完整消息，结果客户端连续快速输入时，服务器会把两条表达式当成一条去解析，报“表达式存在多余内容”。当时排查半天，才意识到是粘包。

4.4 阻塞点定位：卡在哪一步才是关键

socket 默认是阻塞模式，代码里每一个关键的调用都可能让程序“停在原地”：

• accept()会阻塞，直到有客户端连接；
• recv()会阻塞，直到对方发来数据或关闭连接；
• sendall()在发送缓冲区满的时候才会阻塞，本地环回一般很难触发。

如果程序卡住了，可以用打印日志的方式定位。在recv前后各打一行时间戳，或者在accept前打印等待提示，都属于最原始但最有效的调试手段。我在带别人调这个 Demo 时，几乎 90% 的“卡死”问题最后都定位在 “自己忘了发\n” 或者 “服务端忘了切分缓冲区” 两个点上。

5. 边界情况与异常处理：这些才是线上和Demo的差距

5.1 除零、非法输入、空表达式

网络程序最怕的不是正常请求，而是垃圾输入。这个 Demo 的解析器已经做了三层校验：

这里的关键思想是：任何输入都不应该让服务端进程崩溃。无论用户发来什么，服务端都得负责返回一个明确的结果，哪怕是错误提示。实际业务里的输入清洗、参数校验、错误码规范都比这个 Demo 复杂，但底层思路一样：先假设外部输入不可信，再写出兜底逻辑。

5.2 客户端中途断开，服务端怎么发现

客户端如果直接按 Ctrl+C 或者强杀进程，TCP 会发送 FIN 包，服务端recv会返回空字节串b''。这就是服务端代码里if not data: break的触发点。

另一种情况更隐蔽：客户端先关闭，服务端后sendall。这时候第一次发送可能成功，第二次可能抛ConnectionResetError。因为对端内核已经标记连接关闭，再发数据就会触发 RST。我在服务端代码里用try ... except ConnectionResetError包住整个循环，再在finally里conn.close()，这样无论从哪个入口退出，连接资源都会被回收。

5.3 并发连接与线程安全

“每连接一线程”要面对一个隐性问题：如果同时有 100 个客户端连接，就会有 100 个线程。线程不是免费的，每个线程默认要占据一部分栈空间，并且线程切换有开销。在 Demo 阶段完全够用，但你可以顺手了解一下更稳的实现。

比如用线程池：

from concurrent.futures import ThreadPoolExecutor executor = ThreadPoolExecutor(max_workers=10) # accept 循环里 executor.submit(handle_client, conn, addr)

这里每个线程处理一个连接，连接结束后线程不会销毁，而是归还线程池。由于这个计算器服务本身没有任何共享可变状态（每个连接只操作自己的buf和conn），所以并发计算不存在竞态问题。如果你以后在服务端引入了全局计数器、在线用户列表，就要考虑加锁了。

5.4 字符编码：Windows 控制台与 Linux 的不一致

这个 Demo 还有一个跨平台大坑：编码。Linux 终端默认 UTF-8，Windows 的简体中文版 cmd 默认 GBK，如果客户端直接在 Windows 上跑，input读进来的中文没问题，但当你发送quit基础指令时也没问题，问题往往出在服务端返回的字符串里带有中文提示，Windows 终端解码 UTF-8 字节会乱码。

最省事的方案是：

1. 在代码里统一使用encode('utf-8')/decode('utf-8')；
2. Windows 终端执行chcp 65001切换到 UTF-8 编码页；
3. 所有解码操作都加上errors='replace'，即使出现非法字节，也只是一两个乱码字符，不会让进程崩溃。

我在服务端和客户端的代码里都写了errors='replace'，就是为这个准备的。

6. 实测中的坑与排查手段（附解决清单）

6.1 端口占用、地址复用

服务端跑完一次之后马上重启，如果代码里没写SO_REUSEADDR，很可能会报OSError: [Errno 98] Address already in use。原因是被关闭的连接可能仍处于 TIME_WAIT 状态，占用着端口。解决办法就一行：

server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

这个选项的含义是允许内核在连接处于 TIME_WAIT 时重新绑定端口，在开发调试阶段几乎是必须写的。

6.2 localhost 解析成了 IPv6

有同学喜欢把客户端连接地址写成localhost，服务端监听127.0.0.1，结果客户端报连接失败。原因是现代系统的localhost可能同时解析出 IPv6 地址::1，客户端优先尝试 IPv6，而服务端只监听了 IPv4，两边自然对不上。

解决方案就是本项目代码里的做法：客户端直接用127.0.0.1，服务端监听地址用0.0.0.0，可以同时接收本机的所有 IPv4 地址，包括回环地址。如果你的服务端想支持 IPv6，就得单独监听::。

6.3 send 撞上 BrokenPipeError

如果客户端已经关闭连接，服务端还继续sendall，第一次可能没事，第二次大概率抛BrokenPipeError或ConnectionResetError。我在handle_client里用try包住整个收发循环，并在异常分支里打印日志、在finally里关闭连接，就是希望线程结束时不留任何悬空资源。

6.4 遇到卡住不动，先看这三处

我把新手排查时最常遇到的问题整理成一张表，照着查一般都能解决：

这个 Demo 看起来很小，但把它从“本机能跑”改造成“别人也会用”的过程中，你会自然踩到上面一半的坑。每个坑背后都是 TCP 和操作系统的真实特性，而不是框架的 bug。

最后再分享一个我的个人习惯：每次重写这个 Demo，我都会给自己加一个小挑战——把客户端做成可以连续发送 1000 条表达式，然后统计服务端有没有漏算、重算。这个压力测试能帮你快速暴露行缓冲处理不当的问题。学会这个项目的收发框架之后，换成 JSON 协议、换成文件传输、换成心跳保活，都是同一套路：先定边界，再管连接，最后谈业务。