基于Python Socket的TFTP服务器无法检测后续RRQ请求的故障排查

• 会话超时阈值：企业内网防火墙对无连接的UDP会话，默认超时时间普遍设置为30s~120s，远低于TCP会话的超时设置。TFTP协议的核心特性是69端口仅用于接收初始的RRQ/WRQ请求，后续文件数据传输会使用服务端随机分配的临时高端口；如果防火墙只做了69端口的静态放行、没有开启TFTP专用的ALG（应用层网关）识别能力，就会把大文件传输过程中间隔稍长的动态端口UDP报文判定为无效包直接丢弃。
• 单包大小限制：内网防火墙默认对单条UDP报文的截断阈值匹配以太网1500字节的MTU，如果TFTP客户端和服务端协商的块大小超过这个阈值，又没有正常启用PMTU发现机制，超出阈值的大包会被直接丢弃，这和观测到的“大文件传输到10%左右停止响应”的现象完全匹配。
• 单源UDP会话并发限制：防火墙对单个IP地址发起的UDP会话数，默认设置了100~500条的拦截阈值，连续传输多个文件时，每一次TFTP传输都会对应一条独立的动态UDP流，累积到阈值后，新发出的RRQ报文会在防火墙层被直接丢弃，不会进入主机的socket接收缓冲区。这也解释了为什么Wireshark能抓到客户端发出的第4次RRQ，但服务端的select完全感知不到可读事件。

• 开启防火墙的TFTP ALG功能：不要仅做69端口UDP的静态放行，让防火墙能够识别TFTP协议交互过程中动态协商的临时传输端口，自动放行对应端口的双向UDP流量，避免临时端口的流被判定为陌生流量拦截。
• 调整匹配业务的会话参数：把涉及TFTP传输的安全域之间的UDP会话超时阈值，从默认值调整为适配大文件传输的场景，比如针对49000KB的大文件，超时阈值设置为300s，避免长时传输的会话被防火墙提前回收资源。
• 放开单IP的UDP会话并发限制：或者将阈值调整到适配当前连续5次文件传输的业务规模，预留足够的冗余额度，避免累积的会话数触发拦截规则。
• 补充Windows端的socket适配调整：Windows内核对UDP socket的接收缓冲区处理逻辑和Linux存在差异，连续传输大文件时如果之前的TFTP连接线程没有正确关闭旧socket、释放内核缓冲区，会导致69端口的接收缓冲区被占满，新到的RRQ报文直接被内核丢弃，进而导致select.select(self.sock, [], self.sock, self.timeout)完全捕获不到可读事件。可以将69端口的UDP接收缓冲区大小临时调整到2MB以上，排查缓冲区溢出导致的丢包问题。

之前观测到“跳过第三个2900KB大文件时，能正常接收第4次RRQ请求”的现象，本质是没有长时间的大文件传输占用防火墙的UDP会话槽，也不会造成内核接收缓冲区的累积占满，所以小文件的请求能正常被处理；一旦传输49000KB的大文件，会话被防火墙判定过期、动态端口流量被拦截，就会出现传输中途停止的问题。

内容的提问来源于stack exchange，提问作者sanjanaraju_inde