TCP与UDP的底层原理与抓包实战：从三次握手到粘包排查-平芜编程栈

1. 先把传输层的位置摆正：为什么TCP和UDP如此重要

计算机网络这门课里，很多初学者一上来就被七层模型吓住，然后死记硬背TCP是可靠的、UDP是不可靠的，考试过了就丢。但真到了写代码、排查线上故障、优化网络性能的时候，才会意识到这两个协议不是考试题，而是天天要打交道的底层逻辑。我见过不少开发者，业务代码写得飞起，但一问TCP握手为什么是三次、UDP头为什么这么短，立刻答不出来。这三脚猫功夫，迟早会在某个深夜的故障排查现场还债。

先说清楚它们在协议栈里的位置。网络层负责的是“从这台机器到那台机器”的寻址和路由，IP协议干的就是这个活。但一台机器上跑着几十上百个进程，数据到了机器之后，该交给谁？这就轮到传输层出场了。传输层的核心工作就是“端到端”的交付，靠的是端口号来区分不同的应用进程。HTTP服务听80端口、HTTPS听443、DNS查53、SSH连22，这些数字对应的就是传输层的能力边界。

TCP和UDP就是传输层的两个代表选手。TCP全称是传输控制协议，UDP全称是用户数据报协议。俩名字都带“协议”，但气质完全不同。用生活里的例子来打比方：TCP像顺丰快递，有面单、有签收、有物流跟踪、丢件了还给你补发；UDP像在球场边喊一嗓子“把球传过来”，对方听没听见、球传不传，全看缘分。

这篇文章适合三类人看：计算机专业的学生、刚入行的后端或者客户端开发者、还有那些写网络程序总感觉“哪里不对”但说不出来为什么的人。我会从原理讲到实操，再拿Wireshark抓包、Python写socket程序来验证，最后把我在项目里踩过的坑一并列出来。看完之后，你对TCP和UDP的理解会从“背过”变成“真的通了”。

2. UDP：极简主义的信使，快但不承诺

2.1 UDP到底做了什么

UDP的报文头只有8个字节：源端口、目的端口、长度、校验和，各占2字节。对比TCP最小20字节的头部，UDP省掉的不仅仅是空间，更是一整套复杂的连接管理机制。发送端把数据扔给UDP，UDP加个头部就交给IP层，到对端之后解个头、按端口分发，就完事了。没有确认、没有重传、没有顺序保证、没有流量控制。

这个设计看起来很“简陋”，但它换来的东西是低延迟和低开销。你不需要建立连接，想发就发；你不用等对端确认，下一包数据已经在路上了。那么问题来了：谁在需要可靠传输的场景下会用它？

答案是那些“时效性大于一切”的应用。比如实时音视频通话，一帧画面晚到100毫秒，用户已经明显感觉卡顿，但偶尔丢几个包，画面花一下也就过去了，下一帧马上补上。假如这里强行用TCP，丢包触发重传，重传的数据到达时那一段画面早就该播完了，反而是灾难。再比如游戏里的角色位置同步、操作指令下发，要的是当前这一刻的状态，不是把十分钟前的数据补发过来。

还有DNS查询。你访问一个域名，本地DNS服务器发一个UDP查询包出去，默认情况下用的就是53端口的UDP。查询没回应？客户端自己超时重发，或者退而求其次走TCP。为什么不用TCP做首要选择？因为大多数DNS查询就一个小包，来一次三次握手的开销比查询本身还贵。

2.2 用Python写一个UDP收发Demo

空谈理论没有感觉，我建议你亲手写一个最小的UDP收发程序，把整条链路跑通。我找一个生产项目的简化版来演示，你先在机器上装好Python3，不需要任何第三方库。

# udp_server.py import socket server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server.bind(("127.0.0.1", 8888)) print("UDP server listening on 127.0.0.1:8888") while True: data, addr = server.recvfrom(65535) print(f"received from {addr}: {data.decode()}") server.sendto(f"ack: {data.decode()}".encode(), addr)

# udp_client.py import socket client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) server_addr = ("127.0.0.1", 8888) for i in range(3): message = f"hello udp {i}" client.sendto(message.encode(), server_addr) data, _ = client.recvfrom(65535) print(f"response: {data.decode()}")

先起服务端，再跑客户端，你会看到服务端依次收到三条消息并原样回包。这里的核心点在于：sendto和recvfrom都是无连接的，服务端不需要事先知道客户端是谁，客户端也不需要跟服务端“打招呼”。每个数据报都是独立的，服务端只负责从套接字里取数据，然后按对方的地址回包。

这里有个新手容易踩的坑：recvfrom的缓冲区大小。我给的示例是65535，这基本是UDP单包能传的极限。如果你的业务包比缓冲区还大，recvfrom只会返回缓冲区能装下的那部分，剩下的数据直接丢掉了，而且你根本不知道有没有丢。所以设计UDP应用时，业务包一定要设定一个上限，比如4KB、8KB，超过就分片或者改用别的方案。不要寄希望于UDP帮你自动分包，它只负责把IP层的数据报原样交给你。

2.3 UDP的校验和是个容易被忽略的细节

UDP头里那个2字节的校验和，很容易被忽略，但它真的很关键。它计算的范围除了UDP头本身，还包含一个伪头部，里面有源IP、目的IP、协议号、UDP长度。这个设计的用意是：即使IP层把包转错了目标，接收方也能通过校验和发现数据不对。

不过校验和算错会怎样？在大多数系统里，收到校验和错误的UDP包会直接悄悄丢弃，发送方毫不知情。所以UDP不可靠不只体现在“可能丢包”，它连出错无声无息这件事也一并与生俱来。你在设计高可靠性业务时，如果选了UDP，就必须在应用层自己解决校验、序列号、超时重传这些事。业界有现成的方案，比如QUIC协议就是在UDP之上构建了类似TCP的可靠性机制，但这已经属于进阶话题了。

3. TCP：面向连接的可靠传输，代价是复杂度

3.1 三次握手：为什么非得三次

TCP的“可靠”不是凭空来的，它在一开始就用三次握手建立了连接状态。握手的目的有三个：确认双方都能收发、交换初始序号、协商一些窗口参数。很多人问为什么不是两次，我换个角度解释。

假设只有两次握手：客户端发SYN给服务端，服务端回SYN+ACK，然后服务端就认为连接建立了，开始给客户端发数据。但问题在于，如果第一个SYN在网络里滞留了很久，客户端等不及超时重发了一个新的SYN，服务端回了新的SYN+ACK，旧SYN才姗姗来迟。服务端又回一个旧SYN+ACK，然后傻乎乎地认为这是另一条新连接，开始等数据。客户端的序号早就变了，两边“状态不一致”，旧连接永远悬在那里占资源。三次握手能把这个历史遗留问题暴露出来：客户端收到服务端回执后，再发一个ACK，这个ACK本身就携带了“我知道你在等我，序号没问题”的信息。如果服务端收到的是旧请求对应的ACK，序号对不上，就能干净地丢弃。

具体的状态迁移是这样的：客户端先发SYN，进入SYN_SENT；服务端收到后回SYN+ACK，进入SYN_RCVD；客户端收到SYN+ACK，再发ACK，进入ESTABLISHED；服务端收到ACK，也进入ESTABLISHED。很有意思的是，客户端只要发出ACK就认为自己连接建好了，服务端必须等这个ACK收到才算数。这中间的“不对称”其实反映了TCP的容错思想——客户端可以先发数据，服务端即使没收到ACK也有超时重传兜底。

我建议你亲手抓一次包看看。用Wireshark抓本机回环流量，然后随便访问一个本地HTTP服务，过滤tcp.port == 8080，你会清楚看到三条握手包：第一条没有载荷、带SYN标志，第二条带SYN和ACK标志，第三条只有ACK。这个视觉记忆比看十遍概念都管用。

3.2 四次挥手和TIME_WAIT

断开连接比建立连接更微妙。因为TCP是双工的，两边的数据可以独立地流动，所以每一方向对方说“我没话说了”都要单独表达一次。A发FIN给B，表示A的数据发完了；B回ACK，表示“我知道了”。但如果B还有数据要发给A，它可以继续发，直到B也没话说，再发FIN给A；A回ACK。这就凑成四个包。

在实际抓包里，你经常会看到第二次和第三次合在一起发，也就是B回ACK之后马上跟着发FIN，看起来跟三次挥手一样。但这跟网络状况、数据缓存有关，不代表“挥手其实是三次”。内核里处理的时候，B会先关闭发送方向，但接收方向依然开着，直到A也关闭。

这里最值得讲的是TIME_WAIT状态。主动发起关闭的一方，在收到对方FIN并回完ACK之后，不会立刻释放连接，而是进入TIME_WAIT，等2MSL时长（通常约1到4分钟，Linux默认60秒左右）。为什么要等这么久？两个原因：一是万一最后一个ACK丢了，对方会超时重发FIN，你这边还在等着回；二是让网络中残留的旧数据包自然消亡，不至于出现在新连接里。

TIME_WAIT多了不是好事。高并发短连接的服务器上，你执行netstat -ant | grep TIME_WAIT，可能看到成千上万条。每条连接占用一个本地端口，端口耗尽之后新连接就建不起来了。当然这不意味着你要粗暴地禁止TIME_WAIT，后面我讲故障排查时详细说。

3.3 滑动窗口、拥塞控制这些“看不见的机制”

握手和挥手只是TCP的开始，连接建立之后真正干活的是数据传输。TCP怎么保证不丢、不乱、不把对端压垮？靠的是序号、确认号、滑动窗口和拥塞控制。

先讲滑动窗口。发送方有一个窗口，表示“我能一口气发多少字节而不必等确认”。这个窗口大小不是自己拍脑袋定的，而是根据接收方通告的窗口值来动态调整的。你往一个慢速的网络设备狂发数据，对方的接收缓冲区会满，然后它会在ACK里把窗口通告为0，发送方就必须停下来等窗口更新。这个机制保护了接收方不会因为处理不过来而崩溃。

拥塞控制针对的则是网络本身的容量。慢启动、拥塞避免、快重传、快恢复，这一堆术语本质上是在解决一个问题：发送方不知道网络瓶颈在哪，只能靠“试探”来逼近上限。慢启动阶段，发送窗口从一个小值开始，每收到一个ACK就翻倍，呈指数增长，很快就能探到接近网络的极限；一旦出现丢包，立刻减半进入拥塞避免模式，还有重传定时器兜底。

这些机制对应用层是透明的，你写业务代码时根本感知不到它们的存在，但它们在背后决定了你的接口延迟和吞吐量。我见过有人调HTTP接口慢，以为是代码问题，最后发现是TCP窗口和拥塞控制导致小包延迟，这种问题不看抓包基本找不到方向。

3.4 用Python写一个TCP回显服务

搞懂TCP最直接的方式，还是写代码。我用一个回显服务来演示，所谓回显，就是收到什么就返回什么，简单但足以展示连接管理的全过程。

# tcp_server.py import socket server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind(("127.0.0.1", 9999)) server.listen(5) print("TCP server listening on 127.0.0.1:9999") while True: conn, addr = server.accept() print(f"new connection from {addr}") while True: data = conn.recv(1024) if not data: # 对端关闭，recv返回空字节 break print(f"received: {data.decode()}") conn.sendall(b"echo: " + data) conn.close()

# tcp_client.py import socket client = socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect(("127.0.0.1", 9999)) for i in range(3): client.sendall(f"hello tcp {i}".encode()) response = client.recv(1024) print(f"response: {response.decode()}") client.close()

你运行这个程序时会发现，TCP的使用方式跟UDP完全不同：先connect建立连接，然后sendall发数据，recv读对端来的数据。更有意思的是，如果客户端不发数据，服务端的accept会一直阻塞等待新连接。这个“面向连接”的模型，决定了你写代码时必须考虑连接的生命周期：什么时候建连、什么时候断开、断开后资源怎么释放。

代码里有个小细节，我在服务端设置了SO_REUSEADDR。如果不开这个，服务端程序杀掉之后立刻重启，很可能会报“Address already in use”，原因就是之前的连接还在TIME_WAIT状态占着端口。这个参数告诉内核“这种状态下也可以复用端口”，是写服务端程序的基本功。

4. 实操过程：抓包验证TCP三次握手和UDP传输

4.1 抓包工具的选择与基本用法

纸上谈兵没意思，抓包才是真正让协议“现原形”的方式。主流工具有Wireshark和tcpdump，Wireshark有图形界面，过滤规则直观，适合初学；tcpdump是命令行工具，适合在服务器上远程抓包。

我个人的习惯是：本地调试用Wireshark，线上环境用tcpdump抓包再拉回本地分析。tcpdump抓包的命令大概长这样：

sudo tcpdump -i any -w /tmp/capture.pcap host 127.0.0.1 and port 9999

这个命令把回环接口上、目标端口9999的流量都记录到capture.pcap，抓完按Ctrl+C停止，然后用Wireshark打开这个文件慢慢分析。

4.2 抓TCP握手包，看状态迁移

跑上面那个TCP回显服务，在客户端connect的时候同时开抓包，你会看到类似下面这样的过程：

第一包：客户端 -> 服务端，SYN标志，序列号如Seq=0。这里的0是相对序列号，Wireshark为了可读性把初始序列号显示成0，实际是个随机数。

第二包：服务端 -> 客户端，SYN+ACK，Seq=0，Ack=1。Ack=1表示“我期待你从序号1开始发数据”。

第三包：客户端 -> 服务端，ACK，Ack=1。

你要注意第二包里Seq=0、Ack=1，第三包里Ack=1但已经没有Seq变化，承载数据后Seq才会递增。这是TCP里最容易绕晕的点：一个包的ACK号表示“我希望你下一个包的序号是从我这里这个数字开始”，跟包本身发到哪里是两回事。

如果抓包时看到握手迟迟停在SYN_SENT，多半是防火墙把SYN包丢了，或者服务端根本没监听这个端口。这时候先用netstat -tlnp确认端口在听，再检查防火墙规则，不要一口咬定是“网络问题”。

4.3 抓UDP包，看极简风格

抓UDP就简单了，回到我前面写的UDP服务端，起个抓包，你会看到客户端发出的每个数据报都是一锤子买卖：没有SYN、没有ACK、没有状态标识，源端口和目的端口之间就是纯粹的“发和收”。

有趣的是，你甚至会看到Wireshark在UDP那栏下面显示“IP checksum”等信息，但这只是底层IP协议在干活，UDP本身不带任何可靠性机制。如果中间有个路由器把包丢了，客户端和服务端谁都不会知道。你自己程序里看到的“没有超时重发”不是Bug，是协议设计如此。

4.4 实操中必会的三条排查命令

抓包是细活，但日常排障最常用的其实是几条命令。

先看端口监听状态：netstat -tlnp，确认某个端口到底有没有进程在听。加了-n是不做DNS解析，加快速度也避免误判。

再看当前网络连接全貌：ss -ant，这个命令比netstat更快更现代，一屏能看出ESTABLISHED、SYN_SENT、TIME_WAIT各占多少。如果TIME_WAIT特别多，说明服务器上有大量短连接。

最后是ping和telnet。ping测的是网络层的连通性，Ping不通不代表TCP端口不通，反过来也成立；telnet ip port则是直接测试TCP端口是否可达，如果能通了立刻Ctrl+]退出。很多新手拿ping的结果判断“服务器挂了”，这是个常见误区。

这三条命令配合使用，能覆盖80%的连接类故障场景。以后遇到“连不上”“时好时坏”“慢”这类问题，先冷静下来跑一遍，再决定要不要上抓包。

5. 常见问题与排查技巧实录

5.1 TCP粘包和拆包：应用层该负的责任

“TCP粘包”这个词，估计每个写网络编程的人都听过。很多人以为这是TCP的Bug，其实不是。TCP提供的是字节流，它不关心你的业务消息边界。你调用sendall发了10个包，对端recv可能一次就收到20个包的内容，也可能来3次才收完10个。

那怎么办？两种常见方案：一是固定长度，每条消息都定长，不足补位；二是长度前缀，包头用4字节表示后面的内容长度。最怕的就是在socket套接字上直接按“一次recv就是一个完整消息”来写逻辑，线上数据一复杂，立刻出现错乱。

我在模拟项目X里就遇到过这个坑。客户端发的是JSON文本，本机回环测试一切正常，部署到服务器后偶尔报JSON解析失败。排查半天，发现问题出在TCP流被拆分和合并上——服务端一次recv读到的内容是两条JSON拼在一起，解析器当然爆炸。后来改成“读取长度前缀，再读完整包体”的方案，问题才彻底解决。

5.2 UDP丢包：为什么收不到数据

UDP丢包的原因很多，不一定是“网络不好”。最容易忽略的是接收缓冲区太小，内核把来不及处理的包直接丢了。在Linux上可以执行：

sysctl net.core.rmem_max

看系统接收缓冲区上限，程序里自己在recvfrom之前的setsockopt可以调优。除了缓冲区，还有一个隐患是多个进程绑定同一个UDP端口，Linux默认的负载均衡策略可能导致某些包始终被同一个socket接收，其他进程饿死。这涉及到SO_REUSEPORT选项，但不太适合新手入门，你要做的第一件事永远是确认“服务端有没有真正在收包”，加日志就是最快的手段。

5.3 网络超时与重传：为什么TCP有时很慢

TCP有超时重传机制，如果确认没回来，发送方会等一段时间再重发。这个时间不是固定的，系统会根据往返时延动态调整。本地网络环境下握手几乎是瞬时的，公网跨区域时你可能经常看到几百毫秒的延迟。

如果TCP连接频繁超时，常见原因有三个：一个是防火墙丢包，另一个是链路本身拥塞，还一个是服务端线程池耗尽导致accept处理不过来。你抓包看有没有重传就能区分：如果看到大量TCP Retransmission，基本可以断定是链路质量问题，优化代码没用，得找网络设施的原因。

5.4 实战排查表格

我把上面几类问题整理成一张速查表，方便你遇到问题的时候对照着来。

现象	可能原因	优先排查动作
connect超时	端口未监听	`netstat -tlnp`检查端口
connect被拒	防火墙拦截	检查iptables/安全组规则
频繁超时重传	链路拥塞	抓包看Retransmission，ping测丢包率
大量TIME_WAIT	短连接过多	复用连接、调整keep-alive
UDP收不到包	缓冲区溢出	调大rmem，打印收包日志
应用层消息错乱	TCP粘包/拆包	加长度前缀协议

别小看这张表，很多线上问题走一遍这个流程就能定位，省去大量瞎猜的时间。

6. 我的一些实际经验与建议

踩过无数次坑之后，我现在的习惯是：选型之前，先问三个问题。第一个，业务能不能容忍偶尔丢数据？能，就优先考虑UDP，比如日志上报、指标采集、广播搜索，这类场景UDP的简单高效很占便宜。第二个，业务对顺序和完整性有没有硬性要求？有，那TCP几乎是必须的，比如文件传输、转账交易、消息队列的消费者。第三个，如果非要UDP，应用层能不能接受自己实现可靠性？实在不行就上QUIC，别硬造轮子。

还有一件事我想提醒所有刚入门的朋友：不要听风就是雨，一看到“TCP可靠UDP不可靠”就觉得UDP一无是处。网络世界的需求千差万别，VoIP、视频会议、游戏、DNS、DHCP、QUIC，这么多核心服务都站在UDP的肩膀上，它一点都不“Low”，只是“不同”。

如果你想在TCP和UDP的理解上再上一个台阶，我建议接下来去做三件事：第一，抓一次你访问网站时的完整TLS握手包，看TCP握手和TLS握手是怎么叠加的；第二，自己写一个用UDP传文件的程序，体会一下什么叫做“应用层重传”；第三，读一下RFC 793和RFC 768，原文没有想象中难读，反而能纠正很多流行的二手误解。

网络协议这东西，只停留在概念层面是最亏的，因为大量的知识藏在状态、时序和异常处理里。你能亲手抓到那个SYN包、看到切换状态、知道它下一步要干什么，才算真正对这个协议有了体感。后面再去读更复杂的HTTP/3、QUIC、Multipath TCP，心里就有底了。