TUN调试中文件描述符状态转换详解

凌晨三点十七分，我的手机在桌上疯狂震动。群里炸了锅——某个刚上线的小交易所，USDT充提延迟飙到四十分钟，技术群里有人甩出截图，错误日志里密密麻麻全是EMFILE。我揉着眼睛爬起来，打开那台跑着TUN模式的云服务器，心里清楚，今晚又得和文件描述符死磕到底了。

这已经不是第一次了。自从那波“土狗行情”起来，链上交易量暴涨，我们那套基于TUN虚拟网卡的代理程序，成了连接交易所API和链上节点的唯一通道。白天还好，一到凌晨行情剧烈波动，连接数一上来，系统就罢工。说白了，就是文件描述符（FD）不够用了，而TUN设备在Linux内核里的状态机，远比我们想的要拧巴。

一、TUN设备不是普通文件，它是“双向暗门”

先别急着看状态转换，你得先明白TUN这玩意儿是什么。普通网络包走物理网卡，进内核协议栈，再交给socket。但TUN设备是个“虚拟网卡”，它把内核网络协议栈处理完的数据包，直接丢给用户态程序——也就是我们的代理进程。反过来，用户态程序写入的数据，会被内核当作从网卡收到的包，重新进入协议栈。

听起来很美，对吧？但问题在于，这个“丢给用户态”的动作，本质上是通过一个文件描述符完成的。你打开/dev/net/tun，得到一个fd，然后ioctl设置IFF_TUN标志，再把它绑定到一个网络接口上。从此，这个fd就成了内核和用户态之间的唯一桥梁。

但这里有个致命陷阱：TUN fd的读写行为，和普通socket fd完全不同。普通socket的fd，数据到了就read，写不进去就EAGAIN，状态转换是线性的。而TUN fd，它的状态不仅取决于你是否读写了，还取决于内核协议栈对那个虚拟网卡接口的拥塞控制、队列状态，甚至是ARP/NDP邻居表的状态。

我举个例子。你往TUN fd里write一个IP包，内核会把它当作从eth0收到的包，进行路由判断。如果路由表说这个包要去某个网关，但网关的ARP缓存还没解析出来，内核就会把这个包挂起，同时你的write调用可能已经返回了成功——但包根本没发出去。这时候，你的fd状态是“可写”的，但实际内核队列里塞满了待解析的包。如果你继续疯狂write，内核的发送队列会爆掉，然后直接丢包，但你的fd依然显示“可写”。

这就是第一层状态混乱的根源：用户态看到的fd可读可写，和内核实际的队列深度、邻居表状态，完全脱节。

二、FD状态机的三个“幽灵态”：可读、可写、还有“假死”

我们调试到崩溃的那天晚上，我用strace挂上代理进程，看到一长串的write(13, ...) = 4096，然后突然变成write(13, ...) = -1 EAGAIN。但诡异的是，我明明用poll监控了这个fd的POLLOUT事件，poll返回说可写，write却报EAGAIN。

后来我翻内核源码，才发现TUN设备的write路径上，有一个私有标志位——IFF_NAPI和IFF_NAPI_FRAGS。如果启用NAPI模式，TUN设备会走tun_get_user函数，这个函数会检查一个叫做tun->numqueues的队列计数。当队列里的skb（socket buffer）数量超过tx_queue_len（默认1000）时，内核会返回-EAGAIN，但不会设置fd的POLLOUT事件为不可用。

为什么？因为内核认为TUN设备是“自循环”的，你write进去的包，最终会通过协议栈再走回来，所以它把发送队列当作“无限长”来乐观处理。但实际情况是，如果协议栈处理不过来（比如路由表条目过多，或者邻居表满了），队列就会堆积，最终触发-EAGAIN，可poll事件依然告诉你“可写”。

这就是第一个幽灵态：poll说可写，write却EAGAIN。我们叫它“假可写”。

2.1 假可写是怎么害死你的

那天晚上，我们的代理进程逻辑很简单：poll(fd, POLLOUT)，如果可写，就批量write从交易所API拉到的交易数据。结果呢？poll一直返回可写，write前几次成功，然后突然EAGAIN。但我们的代码没处理EAGAIN，直接panic，整个进程崩溃，所有FD全部关闭，TUN设备瞬间变成无主状态。

更坑的是，TUN设备在进程崩溃后，不会自动销毁。它在/sys/class/net/tun0里依然存在，但fd已经没了。你必须重新打开/dev/net/tun，再ioctl设置IFF_TUN，然后重新绑定到同一个接口名。但此时接口的IP地址、路由表、ARP缓存，全都还在——内核不会因为你进程死了就清理这些网络栈状态。于是你重启进程，打开新fd，绑定到tun0，发现write依然EAGAIN，因为内核的发送队列里还塞满了上一个进程留下的skb。

这就是第二个幽灵态：fd没了，但内核队列还在。我们叫它“僵尸队列”。

三、真正的状态转换图：从“等待”到“死锁”的路径

经过两天的抓包和bpftrace跟踪，我画出了TUN fd在调试中实际经历的状态转换路径。和教科书上的“可读-可写-关闭”完全不同，它至少有五个状态：

1. 正常读写态：fd可读可写，内核队列空闲，这是唯一健康的状态。
2. 假可写态：poll返回可写，但write返回EAGAIN。触发条件：内核发送队列（tx_queue_len）已满，但tun->flags里的IFF_NAPI未设置，导致poll逻辑没有检测队列深度。
3. 假可读态：poll返回可读，但read返回0（EOF）。触发条件：对端（内核协议栈）关闭了虚拟网卡接口，比如你执行ip link set tun0 down，但fd还开着。此时read会返回0，但fd并没有进入“关闭”状态，你必须主动close。
4. 僵尸队列态：进程崩溃或fd关闭，但内核网卡接口仍存在，队列里残留skb。新fd绑定后，write依然EAGAIN，除非你ip link set tun0 down && ip link set tun0 up清空队列。
5. 死锁态：最恶心的一种。当你的进程同时有多个线程操作同一个TUN fd，比如一个线程在read，另一个线程在write，而内核的tun->lock被某个长时间持有的操作卡住（比如ARP解析超时），那么所有线程都会阻塞在read或write上，而且poll永远不会返回，因为fd的内核等待队列被锁住了。

3.1 死锁态的真实案例：虚拟币链上交易广播

那晚我们崩的根源，就是死锁态。行情波动时，链上交易广播需要构造大量原始交易，每个交易都要通过TUN设备发给全节点。我们的多线程模型里，线程A负责从TUN fd读取全节点的“新块通知”，线程B负责写入“交易广播”。

结果，全节点的TCP连接因为网络拥塞，导致内核协议栈在tun_net_xmit函数里等待邻居表锁。这个锁被线程A的read操作持有——因为read要取包，而包需要经过邻居表解析。于是线程B的write阻塞在同一个锁上，线程A的read也因为锁被自己持有的递归调用而卡死。整个fd进入死锁态，poll永远返回0，进程假死。

我们用gdb attach上去，看到所有线程都卡在__mutex_lock_slowpath上，而锁的owner是线程A，但线程A的调用栈显示它也在等同一个锁——典型的递归死锁。最后只能kill -9，然后清空tun0的队列，重启进程。

四、调试时的救命稻草：如何手动复位状态

如果你也遇到这种情况，别慌，按这个顺序操作：

第一步：确认僵尸队列
bash ip -s link show tun0 看TX列，如果packets在增长，但dropped也在增长，说明队列在堆积。

第二步：强制复位网卡接口
bash ip link set tun0 down ip link set tun0 up 这会清空tun->tx_queue，并重置邻居表。但注意，这会导致所有通过tun0的现有连接断开，包括你正在监听的链上节点连接。

第三步：调整fd的流量控制
在代码里，对TUN fd的write操作，必须做显式EAGAIN重试，不能依赖poll。因为poll的POLLOUT不可靠。正确写法是： c while (write(fd, buf, len) < 0) { if (errno == EAGAIN) { usleep(100); // 让内核队列有机会排空 continue; } // 其他错误，关闭fd }

第四步：启用NAPI模式
创建TUN设备时，设置IFF_NAPI和IFF_NAPI_FRAGS。这会让内核在发送队列满时，通过napi_schedule触发软中断，并且poll逻辑会检查tun->rxq的pending包数，从而让poll的POLLOUT更准确。但代价是CPU占用会上升。

五、虚拟币场景下的特别坑：非阻塞与超时的纠缠

最后说个虚拟币交易特有的坑。我们用的是epoll边缘触发模式（ET），配合非阻塞fd。ET模式下，你必须在read或write返回EAGAIN后，停止对该事件的关注，直到下次事件触发。但TUN fd的“假可写”状态，会导致ET模式下永远等不到下一次EPOLLOUT。

为什么？因为内核在发送队列满时，确实会触发一次EPOLLOUT事件，但如果你write返回EAGAIN后，没有再次调用epoll_wait去重新注册，内核就不会再发这个事件。于是你的进程就“饿死”了——明明队列空了，但poll不通知你。

解决办法是：在ET模式下，每次write返回EAGAIN后，主动调用epoll_ctl修改事件，或者干脆用LT模式（水平触发）。LT模式下，只要fd可写，epoll_wait就会一直返回，但你得处理频繁的无效唤醒。

我们最后的选择是：放弃poll/epoll对TUN fd的监控，改用单独的线程，阻塞式read和write，配合超时alarm。虽然老土，但最稳。毕竟虚拟币行情波动时，你宁可慢一点，也不能让FD状态卡死导致整个系统宕机。

六、凌晨五点的复盘：FD状态转换的本质

天亮的时候，群里安静了。交易所那边说恢复了，但我知道，这仅仅是又一次侥幸。TUN设备的状态机之所以这么诡异，是因为它跨越了两个世界：用户态的文件抽象，和内核态的网络协议栈。文件描述符的poll/read/write语义，在网络栈的复杂状态面前，显得过于简陋。

虚拟币交易的高并发、低延迟要求，恰恰放大了这种不匹配。每一次行情暴涨，都是对TUN fd状态机的极限压力测试。你没法改变内核，只能改变自己的代码——永远不要信任poll返回的“可写”状态，永远要处理EAGAIN，永远要为僵尸队列准备复位脚本。

现在，我写了个守护脚本，每30秒检查一次/sys/class/net/tun0/statistics/tx_dropped，如果数值在增长，就自动ip link set tun0 down && up，然后重启代理进程。虽然粗暴，但至少比凌晨三点被电话吵醒要好。

下次如果还有人跟你说“TUN调试很简单，就是个fd读写”，你可以把这篇文章甩给他。然后问他一句：“你见过凌晨四点的tx_queue_len吗？”