简单文件传输协议（TFTP）虽然结构简单，但其在嵌入式设备固件升级、局域网内无盘启动等场景中扮演着至关重要的角色。与FTP不同，TFTP基于无连接的UDP协议实现，这意味着它自身必须处理数据传输的可靠性问题。使用Ruby这门灵活的语言来编写TFTP客户端，不仅能深入理解网络底层协议的交互细节，还能借助Ruby强大的字符串处理能力快速实现复杂的报文解析。本文将聚焦于TFTP客户端开发中最为关键的两个环节：超时重传机制与块大小协商选项，带你一步步打造一个健壮且高效的文件传输工具。

TFTP协议基础与Ruby Socket编程准备

TFTP协议定义了五种核心报文类型：读请求（RRQ）、写请求（WRQ）、数据（DATA）、确认（ACK）和错误（ERROR）。在Ruby中，我们可以使用标准库中的UDPSocket类来轻松处理这些基于UDP的通信。构建一个TFTP客户端的第一步，是向服务器的69端口发送读请求或写请求报文。

请求报文的格式相对简单，包含操作码、文件名和传输模式。在Ruby中，我们可以利用Array#pack方法将数据打包成二进制格式。例如，操作码1代表RRQ，后面紧跟文件名和模式字符串，它们之间用空字节（\x00）分隔。需要注意的是，TFTP协议规定所有字符串都必须以零字节结尾。

require 'socket'
# 创建UDP套接字
socket = UDPSocket.new
# TFTP操作码
RRQ = 1
WRQ = 2
DATA = 3
ACK = 4
ERROR = 5
# 构建读请求报文
filename = "testfile.bin"
mode = "octet" # 二进制模式传输
packet = [RRQ, filename, mode].pack("nZ*Z*")
# 发送读请求到服务器的69端口
socket.send(packet, 0, "127.0.0.1", 69)

上述代码展示了如何构建并发送一个基础的RRQ报文。当服务器收到请求后，它会从一个新的临时端口发送DATA报文给客户端，自此之后，客户端与服务器之间的交互将在这个新的端口上进行。这就要求客户端在发送初始请求后，必须动态获取服务器响应的源IP和端口，并在后续的交互中使用该地址进行通信，而不能继续向固定的69端口发送数据。

实现核心的超时重传机制

由于TFTP建立在UDP之上，而UDP不保证数据的可靠交付，因此网络拥塞或设备故障都可能导致数据包丢失。为了应对这种情况，TFTP协议引入了停止等待协议。客户端发送ACK确认收到数据块后，等待服务器发送下一个数据块；如果在规定时间内没有收到下一个数据块，客户端必须重新发送上一个ACK，以此提醒服务器重传丢失的数据。

在Ruby中，实现超时检测最优雅的方式是使用IO::select方法。该方法可以监控一组文件描述符，直到它们准备好进行I/O操作或超时为止。通过将UDPSocket对象传入IO::select，我们可以在不阻塞整个进程的情况下精确控制等待时间。如果超时发生，IO::select将返回nil，此时我们触发重传逻辑，重新发送上一个ACK报文。

# 接收数据并处理超时重传
block_number = 1
timeout_limit = 5 # 超时5秒
retry_count = 0
max_retries = 3
loop do
  # 监控socket是否有数据可读，设置超时
  ready = IO::select([socket], nil, nil, timeout_limit)
  if ready.nil?
    # 超时，重传上一个ACK
    if retry_count < max_retries
      puts "超时，重传ACK for block #{block_number - 1}"
      ack_packet = [ACK, block_number - 1].pack("nn")
      socket.send(ack_packet, 0, server_addr, server_port)
      retry_count += 1
    else
      puts "达到最大重传次数，传输失败"
      break
    end
  else
    # 有数据可读
    data, addr = socket.recvfrom(516) # 最大TFTP包大小
    opcode, recv_block = data.unpack("nn")
    if opcode == DATA && recv_block == block_number
      # 提取文件数据（前4字节为操作码和块号）
      file_data = data[4..-1]
      # 处理文件数据...
      # 发送ACK
      ack_packet = [ACK, block_number].pack("nn")
      socket.send(ack_packet, 0, addr[3], addr[1])
      block_number += 1
      retry_count = 0 # 重置重传计数器
      # 如果数据小于516字节（默认块大小+4头字节），传输结束
      break if data.length < 516
    end
  end
end

这段代码清晰地展示了超时重传的完整闭环。当IO::select超时未收到数据时，程序会重新发送上一个已确认块的ACK。如果连续三次超时，则判定连接中断并退出循环。这种机制确保了即使在网络状况不佳的情况下，客户端也能通过重传策略尽量完成文件传输。同时，通过动态更新server_addr和server_port，客户端能够正确响应服务器临时分配的传输端口。

利用选项协商优化块大小提升传输效率

标准TFTP协议规定每个数据块的大小固定为512字节。这在传输小文件时并无大碍，但在处理大文件时，频繁的确认应答会极大地拖慢传输速度并增加网络开销。RFC 2347引入了选项协商机制，允许客户端在初始请求中提出如块大小（blksize）、超时时间等选项，若服务器支持，则在首个DATA报文前回复一个选项确认（OACK）报文。

通过协商更大的块大小（例如1428字节，适合以太网MTU），可以显著减少ACK报文的数量，从而提升吞吐量。在Ruby中，我们只需在构建RRQ报文时附加选项字段即可。选项字段同样以零字节结尾的字符串对形式存在，例如blksize\x001428\x00。需要注意的是，如果服务器返回了OACK，客户端必须回复一个块号为0的ACK，之后服务器才开始发送真正的数据块。

# 构建带选项协商的读请求报文
filename = "large_file.iso"
mode = "octet"
blksize = "1428" # 期望的块大小
# 附加blksize选项
packet = [RRQ, filename, mode, "blksize", blksize].pack("nZ*Z*Z*Z*")
socket.send(packet, 0, "127.0.0.1", 69)
# 处理OACK响应
ready = IO::select([socket], nil, nil, 5)
if ready
  data, addr = socket.recvfrom(1024)
  opcode = data.unpack("n").first
  if opcode == 6 # OACK操作码为6
    puts "服务器同意选项协商"
    # 回复块号为0的ACK
    ack_packet = [ACK, 0].pack("nn")
    socket.send(ack_packet, 0, addr[3], addr[1])
    # 后续正常接收DATA报文，但最大包大小需调整为协商后的值
  elsif opcode == 5 # ERROR操作码为5
    puts "服务器拒绝选项: #{data[4..-1]}"
  end
end

引入选项协商后，客户端的逻辑需要稍作调整。在发送RRQ后，客户端首先期待的是一个OACK报文而非直接的数据报文。收到OACK后，客户端必须立即发送一个块号为0的ACK以确认选项生效。此后，数据传输流程恢复到标准的停止等待模式，但此时接收缓冲区的大小必须根据协商的blksize进行动态调整，以防止数据截断。这种优化方式在不改变TFTP核心机制的前提下，极大地提升了大数据量传输的效率。