正反向隔离装置TCP/UDP穿透demo：会话老化与心跳保活实战

简介：这是一份围绕正反向隔离装置TCP/UDP穿透的演示工程，面向网络与安全方向的学习者、开发人员及需要验证跨网隔离通信方案的工程实践者，重点补充了UDP穿透场景。资源共11个文件，包含ini配置、cpp源码、代理/测试可执行程序、txt说明及pptx方案文档，压缩包约1.68MB，便于在实验环境中对照配置、运行测试并理解正反向隔离下的数据收发流程。已有1253人学习下载，说明该主题在TCP/IP与网络安全实践中具有一定关注度。包内通过TCP测试、UDP收发测试、代理端与输出端等多组程序配合，展示穿透链路的搭建、参数配置与连通性验证方法，并配有整体方案材料，可帮助读者梳理隔离服务架构、理解代理转发与UDP数据通道的差异，也为排查端口、协议与转发配置问题提供参考。

1. 正反向隔离装置里的 TCP/UDP 穿透 demo：先给结论，再讲怎么复现

在自建实验环境里把这套正反向隔离装置的 TCP/UDP 穿透 demo 跑通之后，我得到的结论和一开始的预期正好相反：卡住整条链路的从来不是协议封装能不能骗过去，而是装置会话表的老化时间。加帧头、做长度前缀、处理粘包，这些两小时就能写完；让一条会话在装置的会话表里活得比数据传完更久，才是真正需要靠反复调试才能解决的问题。

这篇围绕 tcpip 网络安全这个关键词，不讲协议教科书，直接讲能跑起来的最小链路：拓扑怎么搭、放行矩阵怎么摸、正向和反向两条路径各自的判定点在哪、失败时该看哪几个读数。新手可以照着把 demo 跑起来，熟手可以对着我在避坑章里列的五个踩坑点，核对自己环境里那些“看起来通了其实没通”的假象。

2. 把被测装置夹进链路：拓扑、放行矩阵与基线抓包

先讲环境。穿透测试里最常见的错误是“上来就写代码”，写完了发现连不上，然后花一整天怀疑自己的 socket 写错了。实际上百分之八十的失败在第一分钟就已经注定——拓扑摆错了，或者根本不知道装置的放行方向。所以我一般会强迫自己先花半天做三件事：摆拓扑、摸放行矩阵、录基线包。这三件事做完，后面任何一次失败都能在三十秒内定位到是链路的哪一段出了问题，而不是靠猜。

2.1 三段式拓扑：为什么必须是三台而不是两台

两台机器直连测不出任何东西。正反向隔离装置的核心特征是方向性：某个方向允许发起连接，反方向不一定；某个方向允许建连但不一定允许带载荷；UDP 可能压根没有独立会话，全靠借 TCP 的通道。所以拓扑必须是三段——发起侧、被测装置、响应侧。

我的实验环境是这样摆的：三台虚拟机跑在同一台宿主机上，用不同的虚拟网段隔开，中间那台虚拟机做网桥式转发，把两侧网段物理隔断，只保留装置本身的转发逻辑。

注意：地址段只是实验环境里的占位，实际测试把自己的网段替换进去就行，关键是两侧必须物理或逻辑隔离，不能让 A 和 B 有第二条通路。这一点我吃过亏——有一次宿主机的默认路由没关干净，A 直接绕过了装置和 B 通了，测试结果全部作废，还以为是装置放行了全部流量。测之前先用traceroute确认路径里只有装置一跳，这个动作成本很低，但能省掉一整天的返工。

拓扑里还有个容易被忽略的细节：响应侧 B 上要同时开 TCP 监听和 UDP 监听，而且监听端口要和稍后写的 demo 里一致。UDP 的监听不需要listen()，但一定要在测试前先用ss -lunp确认端口确实绑上了，否则你会看到“装置放行了但对面没回包”这种双重误判。

2.2 放行矩阵：先测方向，再测端口

装置到底放行了什么，不要信文档，要自己测。我会把“方向 × 协议 × 端口”做成一个三维矩阵，逐格打一遍，记录回包情况。这里的核心判断是：连接能不能建立、载荷能不能通过、回包能不能回来，这是三件不同的事，必须分开测。

用下面这段脚本批量打一遍，比手工敲快得多。注意每个用例之间要等一秒以上，避免装置会话表里残留上一轮的表项影响判断。

#!/bin/bash # 逐格探测放行矩阵：内->外、外->内 两个方向 # TCP_PORT / UDP_PORT 换成响应侧实际监听的端口 TCP_PORT=9001 UDP_PORT=9002 OUT_IP=10.10.2.10 # 响应侧地址 TIMEOUT=2 # 单次探测超时，秒 echo "== TCP 正向（内->外）连通性 ==" # -z 只做连接不传数据，-w 控制超时，避免脚本卡死 nc -zv -w $TIMEOUT $OUT_IP $TCP_PORT 2>&1 echo "== TCP 反向（外->内）连通性 ==" # 由响应侧主动连发起侧，验证装置是否允许外向内建连 nc -zv -w $TIMEOUT 10.10.1.10 $TCP_PORT 2>&1 echo "== UDP 正向探测 ==" # UDP 无连接，用 echo 发一个字节，看回包；nc -u 不回包说明表项没建立 echo "probe" | nc -u -w $TIMEOUT $OUT_IP $UDP_PORT 2>&1 echo "== UDP 回包窗口测试 ==" # 发完之后等 30 秒再发一次，用来判断 UDP 会话表老化时间是否短于 30 秒 echo "probe2" | nc -u -w $TIMEOUT $OUT_IP $UDP_PORT 2>&1

参数说明：-z是零 I/O 扫描模式，只建连不发数据，适合判断“握手能不能过”；-w是超时，设太小会误判为不通，设 2 到 3 秒比较稳；UDP 那两行是关键，很多装置对 UDP 首包会直接丢弃，必须由内侧先发包建立起五元组表项，回包才有机会通过，所以第一次探测没回包不等于不放行，可能是包格式或方向不对。

测完之后把结果填进矩阵表，我一般会写成下面这个样子，后面写代码时直接照着这张表选协议和端口。

这张表最值钱的一行是最后一行：UDP 首包丢弃、第二次通过。这一个现象直接告诉你，装置对 UDP 做了会话跟踪，你必须设计一个“预热包”机制，而不是简单地把 UDP 当无连接处理。

2.3 基线抓包：把“正常”先录下来，后面才有对照

放行矩阵测完，马上录一轮基线包。基线的作用是给你一个“已知正常”的参照物，后面任何一次异常都能拿它做逐字段对比，包括序列号、窗口大小、TCP 选项、TTL、IP ID 这些容易被装置改写的字段。

# 在发起侧 A 上抓，两个网卡分别对应装置内侧和本机回环 # -s 0 抓完整包长，-w 直接落盘便于后续对比，不要用 -c 限制数量 tcpdump -i eth0 -s 0 -w /tmp/base_tcp.pcap 'tcp port 9001' # UDP 基线单独抓一份，注意 UDP 没有握手，必须靠时间戳对齐 tcpdump -i eth0 -s 0 -w /tmp/base_udp.pcap 'udp port 9002' # 同时在装置上抓一份，用于对比包在穿过装置前后的字段变化 tcpdump -i any -s 0 -w /tmp/base_device.pcap 'host 10.10.1.10 or host 10.10.2.10'

抓完用tcpdump -r回看时，重点看四个字段：序列号是否被装置重写、TCP 选项里的窗口缩放因子有没有被剥离、MSS 有没有被改成更小的值、IP 层的 TTL 有没有被减。窗口缩放被剥离是最阴的一个，它不会让连接失败，但会让吞吐量掉到原来的几十分之一，表现出来就是“通了但慢得离谱”，很多人会误以为是带宽问题。MSS 被改小则意味着装置在做分片重组，大包场景下必须把应用层分片阈值调到比 MSS 更小，否则会出现“小包正常大包卡死”的经典现象。

2.4 四项判定标准：连得上、连得久、传得对、断得回

后面所有测试我都按这四个指标打分，缺一个都不能算通过。

“断得回”这一项最容易被跳过，但它是反向穿透里最要命的一环。装置的会话表可能在链路静默一段时间后单方面清理，而两端的 TCP 状态还停在 ESTABLISHED，这就是典型的半开连接——你这边以为连着，实际数据全进黑洞。后面第四章讲心跳时会专门拆这个。

3. 正向穿透 demo：从三次握手到会话保持

正向是所有测试的起点，也是最容易做出“假成功”的地方。因为正向通常放行，你随手写个 socket 就能连上，于是很容易得出“装置没问题”的结论。但正向真正的考点不在连得上，而在装置对这条连接做了哪些不可见的改写，以及这些改写会不会在你换成大包、长连接、高频小包之后突然翻脸。

3.1 TCP 正向：三次握手在装置上留下什么痕迹

一次正向 TCP 建连，在装置上其实发生了两次握手：发起侧 A 和装置握手，装置和响应侧 B 再握手。这意味着你在 A 上抓到的 SYN-ACK，源其实是装置，不是 B；序列号空间也是装置自己维护的，跟 B 的序列号没有直接关系。理解这一点很重要，因为它解释了三个常见现象。

第一个现象是 TTL 异常。如果从 A 抓到的回包 TTL 是 63 或 64，说明这个包是装置自己回的，不是从 B 透传过来的；如果是 62 或者更低，才可能是透传。这个差别决定了装置到底是“透明转发”还是“应用层重组”，两种模式对载荷的处理完全不同，前者字节级透传，后者可能会做协议识别和内容过滤。

第二个现象是窗口大小突变。装置如果做 TCP 会话代理，它给 A 通告的窗口是它自己的接收窗口，跟你 B 的窗口没有任何关系。这时候如果你在 A 上看到窗口一直是 65535 不动，而 B 那边实际处理很慢，就会出现发送方一直往装置里灌数据、装置内部缓冲区打满、然后开始丢包或阻塞的情况。表现出来就是发送端send()一直成功但接收端迟迟收不到，这种“写了但没到”的故障最难查。

第三个现象是 FIN/RST 的来源。连接关闭时，如果 RST 是装置发的而不是对端发的，说明装置认为会话已经失效——通常就是它自己的会话表超时了，而两端还在用。这就是我前面说的半开连接，正向场景里同样存在。

实际操作中，我会在握手阶段做三次重复，每次间隔五秒，然后对比三次的窗口和选项字段是否一致。不一致说明装置有负载均衡或者会话复用，后面写多连接并发的时候必须考虑这一点。

3.2 UDP 正向：会话表比协议本身更关键

UDP 没有握手，装置判断“这个回包属于哪条流”只能靠五元组匹配。这就带来两个硬约束：首包必须由内侧发起，回包必须在会话表有效期内到达。

我在 2.2 里测出来的“首包丢弃、第二次通过”，本质上就是装置在等一个内侧发起的包来建表。有些装置的实现更严格：它要求连续 N 个包或者 N 字节之后才建表，这时候单发一个探测包是不够的，得发一小段数据。所以写 UDP 客户端时，我的习惯是先发一个预热包，等 200 毫秒，再发正式数据，而不是直接一把梭。

另一个坑是源端口。UDP 客户端如果每次都用不同的源端口，那每次都是一个新五元组，等于每次都要重新建表，装置那边会话表会被迅速打满，然后开始丢包。反向也类似，响应侧回包的目标端口必须和请求的源端口完全一致，否则匹配不上。这一点看起来是常识，但在用socket.connect()的 UDP 模式时，很多人不显式bind()，操作系统分配的临时端口在某些装置上会被当作不可信源端口丢弃。

会话老化时间必须实测。我的做法是发一个包、等一段时间、再发一个包，用二分法逼近超时阈值，一般测三到五个点就能估出来。测出来如果是 30 秒，那心跳间隔就得设到 10 秒以内；如果是 120 秒，20 秒一次就够。这个数值直接决定后面反向通道的心跳参数，不能拍脑袋定。

3.3 最小可跑 demo：一个客户端打通 TCP 与 UDP

下面这段代码是正向侧的最小骨架，TCP 和 UDP 两个函数分开写，方便单独替换测试。里面的超时、预热、心跳间隔都是参数化的，改起来不用动逻辑。

import socket import time import struct DEVICE_OUT_IP = "10.10.2.10" TCP_PORT = 9001 UDP_PORT = 9002 CONNECT_TIMEOUT = 3 # 建连超时，超过就认为方向不放行 HEARTBEAT_GAP = 8 # 心跳间隔，必须小于实测的会话老化时间 WARMUP_GAP = 0.2 # UDP 预热后等待时间，给装置建表留余量 def tcp_forward(payload: bytes) -> bytes: """正向 TCP：建连 -> 发送 -> 收满 -> 关闭""" s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(CONNECT_TIMEOUT) try: s.connect((DEVICE_OUT_IP, TCP_PORT)) # 先发长度前缀，解决对端不知道要读多少的问题 s.sendall(struct.pack(">I", len(payload)) + payload) # 按长度前缀精确读回，避免一次 recv 读不全 head = recv_exact(s, 4) if not head: return b"" n = struct.unpack(">I", head)[0] return recv_exact(s, n) finally: s.close() def udp_forward(payload: bytes) -> bytes: """正向 UDP：必须先发预热包，让装置建立五元组表项""" s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) s.settimeout(CONNECT_TIMEOUT) # 显式 bind 固定源端口，保证多次请求属于同一个五元组 s.bind(("0.0.0.0", 0)) try: s.sendto(b"\x00", (DEVICE_OUT_IP, UDP_PORT)) # 预热包 time.sleep(WARMUP_GAP) s.sendto(payload, (DEVICE_OUT_IP, UDP_PORT)) data, _ = s.recvfrom(65535) return data finally: s.close() def recv_exact(sock: socket.socket, n: int) -> bytes: """精确读 n 字节，处理 TCP 半包""" buf = b"" while len(buf) < n: chunk = sock.recv(n - len(buf)) if not chunk: break buf += chunk return buf if __name__ == "__main__": print("TCP 回显:", tcp_forward(b"hello-tcp")[:32]) print("UDP 回显:", udp_forward(b"hello-udp")[:32])

这段代码有三个刻意的设计。sendall之前先打包长度前缀，是因为装置可能会把一次send拆成多个 TCP 段，对端如果按“一次 recv 就是一整条消息”来读，必然出错。recv_exact是配套的半包处理，必须循环读到够数为止。UDP 那段先bind再sendto，是为了固定源端口——前面说过，源端口一变就是新五元组，装置会当成新会话处理。

参数上，CONNECT_TIMEOUT设 3 秒是个经验值。设成 1 秒，装置在负载稍高时会把正常的慢建连误判成不通；设成 10 秒，一旦方向不放行，每次测试都要白等十秒。HEARTBEAT_GAP必须严格小于实测老化时间，且留至少三分之一余量，这一点在第四章展开。

3.4 失败时的三种典型现象与读数方法

正向失败基本就三种表现，每种对应一组固定的读数动作。

第一种是connect直接超时。这时先看ss -tanp里有没有 SYN-SENT 状态的条目，如果有，说明包发出去了但没回包，问题在装置的放行策略或响应侧没监听；如果没有，说明本机路由有问题，包压根没出网卡。这两个方向的排查成本差很多，所以第一步永远是先分清包有没有出去。

第二种是连上了但recv一直阻塞。这时候看两处：一是netstat -s里的重传计数有没有持续上涨，涨说明链路丢包；二是在装置外侧抓包，看包有没有真的到达响应侧。我遇到过一种情况，装置接收了数据但没转发，原因是它的内部缓冲区满了却不给发送方任何反压信号，表现就是发送端一直成功、接收端一直没数据，属于最难查的一类。

第三种是数据到了但内容不对。这时候不用怀疑协议，先tcpdump把两侧的载荷 dump 出来做十六进制对比，差异通常出现在固定偏移上——比如装置插入了自己的头部，或者把某些字节做了转义。找到偏移量和规律，就能反推装置做了哪层处理。

4. 反向穿透 demo：谁先发起连接，决定了全部

正向做完，反向才是真正的难点。原因很简单：反向方向通常不放行主动建连，你没法从外侧直接连到内侧。所以反向穿透的本质不是“打洞”，而是“让内侧先伸一只手出来，然后外侧抓住这只手不放”，学术点说叫连接反转。整个方案的设计空间，全部围绕“怎么让这条由内向外发起的连接活得够久、承载得够多”展开。

4.1 反向连接的第一性问题：谁先发起连接

我先说结论：反向方案里，内侧必须是客户端，外侧必须是服务端，而且这条连接的建立时机必须早于任何数据需求。也就是说，你不能等有数据要传了才去建连，那时候外侧根本连不进来。正确的做法是内侧程序启动时立刻建一条长连接挂上去，之后所有反向的数据需求都复用这条连接。

这条长连接要解决三个问题。第一是存活，它必须比任何一次数据交互都活得久，靠心跳维持。第二是复用，一条 TCP 连接上要跑多路逻辑流，必须自己加帧头区分，否则数据会串。第三是重连，一旦断开，内侧要能自动重连，并且重连的退避策略要温和，不能一秒一次把装置打崩。

这里有个设计选择值得展开：单连接多路复用，还是多连接各跑一路？我两种都试过。单连接的好处是装置上只需要维护一个会话表项，压力小、存活率高；坏处是一旦断开全部流都断，而且所有流共享一个拥塞窗口，一条流卡住会拖累其他。多连接的好处是隔离性好；坏处是装置会话表压力成倍上升，而且每条连接都要独立心跳，管理成本高。我的选择是单连接 + 应用层多路复用，在帧头里带通道 ID，流量不大的场景下这是最省心的方案。

4.2 会话反转与多路复用：一条连接跑多路流

多路复用的帧格式我一般定成下面这样，八个字节的头，够用且好解析。

这个格式最关键的字段是载荷长度。有了它，接收端才能精确知道一条消息的边界，才能正确处理半包和粘包。没有长度前缀而靠分隔符的方案，在二进制数据上必然出错，因为数据里出现分隔符字节是迟早的事。

通道号的作用是把一条物理连接虚拟成多条逻辑流。内侧每来一个本地请求，就分配一个通道号，发一帧建流；数据在这条通道上双向跑；结束发关流。外侧维护一个通道号到本地处理句柄的映射表，收到帧就查表分发。这套机制不复杂，但状态机要写严谨，尤其是关流和断连的顺序，处理不好会出现通道泄漏——通道号一直不释放，跑几天之后分配不出新的。

4.3 心跳保活：为什么 TCP keepalive 靠不住

这是整个反向方案里最容易被低估的一环。很多人觉得 TCP 自带 keepalive，开一下就行了，实际上在隔离装置场景下它基本没用。原因有三层。

第一层，TCP keepalive 默认是两小时才发一次，可调，但即使调到 30 秒，它探测的也只是“对端操作系统在不在”，不探测“中间装置还认不认这条会话”。装置清理会话表的时候不会通知两端，它只是悄悄把表项删掉，之后的包全丢。这时候两端 TCP 状态都还是 ESTABLISHED，keepalive 探针发出去被装置直接吞掉，等超时重传若干次才报错，中间可能已经过去好几分钟。

第二层，有些装置会在会话空闲时主动发 RST，或者干脆把空闲会话的表项回收给别人用。这种情况下，靠 TCP 层的任何机制都救不回来，只有应用层定时发数据才能让装置认为这条会话是活跃的。

第三层，应用层心跳还有个附加价值：它能验证端到端的数据通路是否真的通。TCP keepalive 只到内核，应用层心跳会一直跑到对端应用逻辑再回来，中间任何一环出问题都能被发现。

所以我的做法是：应用层心跳间隔取实测老化时间的三分之一，心跳帧走类型 2，载荷里带一个递增序号，对外侧的响应做超时判断，连续三次没响应就主动断开重连。重连退避用 1、2、4、8 秒的指数退避，封顶 30 秒，避免网络抖动时疯狂重连。

4.4 封装格式与半包处理

下面这段是外侧解析帧的核心逻辑，重点在feed方法——它把任意切分的字节流重新组装成完整帧，这是所有穿透程序的基本功。

import struct HEADER_LEN = 8 TYPE_DATA, TYPE_PING, TYPE_OPEN, TYPE_CLOSE = 1, 2, 3, 4 class FrameParser: """把 TCP 字节流切成完整帧，处理半包与粘包""" def __init__(self): self.buf = b"" def feed(self, chunk: bytes): """喂入任意长度数据，产出完整帧列表""" self.buf += chunk frames = [] while True: # 头部都不够，等更多数据 if len(self.buf) < HEADER_LEN: break ver, typ, ch, length = struct.unpack(">BBHI", self.buf[:HEADER_LEN]) total = HEADER_LEN + length # 载荷还没收全，保留在缓冲区等下一次 if len(self.buf) < total: break payload = self.buf[HEADER_LEN:total] frames.append((typ, ch, payload)) # 关键：按 total 切片，不能用 HEADER_LEN 或 length self.buf = self.buf[total:] return frames def build_frame(typ: int, channel: int, payload: bytes = b"") -> bytes: """组帧：版本固定 1，长度取载荷实际长度""" return struct.pack(">BBHI", 1, typ, channel, len(payload)) + payload

feed里的self.buf = self.buf[total:]是唯一正确写法。我见过太多实现写成按length切，结果每次都少切八个字节的头，跑着跑着整个流就错位了，现象是“跑一段时间之后数据全乱”，极难复现和定位。另一个细节是while True循环必须一直转到底，因为一次recv可能收到三个半帧，必须一次全部解出来，否则缓冲区会越积越多。

参数上，通道号用两字节最多支持 65535 条并发逻辑流，一般够用。如果场景里并发更高，把通道号扩到四字节，但那样头部变成十字节，解析代码要同步改，所以一开始就要想清楚并发上限。

5. 排查与避坑：穿透测试里最常见的五个翻车现场

这一章是按我实际踩过的顺序排的。每一个我都至少浪费过半天以上，共同特征是现象看起来像 A 问题，实际原因是 B，如果不提前知道，靠日志根本推不出来。

5.1 连接建立阶段：三个高频翻车

现象一：发起侧一直 SYN-SENT，抓包能看到 SYN 出去，就是没有 SYN-ACK 回来。

原因是方向没放行，或者放行了但装置要求先有内侧发起的会话表项，而测试脚本一上来就从外侧发起。这种情况在正向测试里也会遇到，如果你误把响应侧当成了发起侧。解决方法是回到 2.2 的放行矩阵，确认这条流的首个包确实是由允许发起的一侧发出的。另外补一个动作：在装置两侧同时抓包，如果内侧收到了 SYN 而外侧没有，说明装置直接吞了，这时候查装置的策略配置比查代码有用一万倍。

现象二：TCP 连上了，connect秒回，但第一条数据发出去就没下文。

原因是装置做的是“建连接但不透传载荷”的策略，握手由装置自己应答，载荷需要额外的会话授权。这个坑特别阴，因为connect成功会让你误以为链路全通。识别方法是看握手包的 TTL 和窗口：如果 SYN-ACK 的 TTL 明显是装置本机的值（通常是 64 或 255 的整数值），说明握手是装置代答的，不是端到端的。解决方法是在建连之后立刻发一个应用层探测帧并等响应，把“连得上”和“传得通”分成两个独立判定，不要合并。

现象三：UDP 第一次请求超时，第二次就通了。

这个前面提过，是首包被用来建表了。坑在于很多人会把它当成偶发丢包，加重试就完事，结果在生产环境里表现为“每次新建连接的第一个请求都慢一拍”。正确做法是在客户端启动时主动发一个预热包，不等业务数据触发。预热包内容无所谓，一个字节就够，关键是方向和五元组要对。如果装置要求连续 N 个包才建表，就把预热改成连发三个，间隔 50 毫秒。

5.2 会话保持与数据面：两个隐蔽坑

现象四：连接跑着跑着突然静默断开，两端都显示 ESTABLISHED，但数据发不出去。

原因是装置会话表老化，而两端都没感知。这是半开连接的经典形态，也是最难查的一个，因为所有本机命令看起来都正常。判断方法是：在本端发数据的同时，在对端抓包，如果本端send返回成功但对端抓不到包，基本可以确定链路中间把包吞了。解决方法是加应用层心跳，间隔取老化时间的三分之一，并且心跳要有响应判定，连续三次无响应就主动断开重建。不要指望 TCP keepalive，前面说过它在装置场景下基本无效。

顺带说一个相关的坑：加了心跳之后，如果心跳帧和业务帧共用一条连接但没有优先级，业务高峰时心跳可能被大包堵在后面，导致误判超时。解决办法是把心跳做成独立通道号，并且在发送队列里给控制帧更高优先级。

现象五：小数据一切正常，一传大文件就卡死或者校验失败。

原因是 MSS 被装置改小或者做了分片重组，而应用层按自己的 MTU 假设切包，导致超大包在装置侧被丢弃或者重组失败。判断方法很简单：在发起侧抓包看实际发出的包长，如果发现 1500 字节的包被切成 500 多字节的多段，说明路径 MTU 比你以为的小。解决方法是在应用层做分片，单片载荷控制在 1200 字节以内，接收端按帧头长度重组。这个数字不是拍脑袋，是 IPv4 最小重组缓冲区 576 加上一些余量之后的安全值，绝大多数装置的实现都能处理。

还有一个变种：分包大小对了，但接收端校验失败。这种情况多半是半包处理写错了，回到 4.4 检查缓冲区切片逻辑，重点看是不是按length而不是total切的。

6. 收尾：一套能反复用的验证动作

把上面这些跑完，我对这套 demo 的最终判断是三句话：正向看“能不能过”，反向看“能不能久”，UDP 看“表在不在”。三句话对应三组完全不同的验证动作，混在一起测必然互相干扰。

如果只让我保留一套最小验证流程，我会按这个顺序走一遍，每步都有明确的通过标准，任何一步不过就停下来修，不往下走。

最后分享一个我后来固定下来的排查习惯：任何一次“连不通”，我都不先看代码，而是同时开两个窗口，一个跑ss -tanp看本机 TCP 状态机走到哪一步，一个跑tcpdump看包到底有没有出网卡、有没有回来。这两个读数一对照，问题立刻被切成四类——包没出去、包出去了没回、回了但状态没变、状态变了但数据没到。四类问题的排查路径完全不同，先分类再深挖，比一上来就翻代码快得多。

这个习惯是被一次连续两天的误判逼出来的。当时我一直以为装置把包丢了，反复改代码、加重试、换端口，最后发现是本机防火墙把回包拦在了 INPUT 链上，ss里状态停在 SYN-SENT，tcpdump里回包明明已经到了网卡。从那以后我每次开测前都强制走一遍“先看状态、再看包、最后看代码”的顺序，再没在这种低级问题上浪费过时间。希望这套流程能帮到你，少走我走过的那些弯路。

本文还有配套的精品资源，点击获取