1. 项目缘起与整体设计思路UDP 这套东西刚入行的朋友一听“可靠传输”四个字第一反应往往是“这不是 TCP 干的活吗你折腾 UDP 图啥”。我当初接这个需求时也是这个反应。但真到了某些特定场景里TCP 反而会变成拖后腿的那一方。比如内网批量分发大文件、跨机房做日志归档、点对点做数据同步这些场景有几个共同特点链路质量相对可控、对吞吐量敏感、不希望被 TCP 的拥塞控制“一刀切”地压速。TCP 的拥塞窗口在丢包时会直接腰斩恢复又慢一条本来能跑满千兆的链路可能因为偶尔的丢包掉到几十兆。而 UDP 没有这些包袱怎么发、发多快、丢了怎么补全由应用层自己说了算。这个项目的核心目标很明确用 Java 的 DatagramSocket 实现一套应用层的可靠传输协议把一个大文件几百 MB 到几个 GB从一端完整、正确地送到另一端同时尽量榨干链路带宽。说白了就是把 TCP 里那些保证可靠性的机制——确认、重传、排序、去重、流量控制——自己在应用层重新实现一遍但实现方式针对“大文件单向传输”这个具体场景做裁剪和优化去掉通用协议里那些用不上的复杂度。为什么选 Java因为 Java 的 NIO 提供了DatagramChannel配合ByteBuffer和Selector能比较优雅地做非阻塞收发而且 Java 跨平台写出来的东西在 Linux、Windows、macOS 上都能跑团队里谁都能接手。当然纯DatagramSocket的阻塞模型也能做只是并发一上来线程模型会比较难看这个后面细说。整套设计我拆成四个层次来想分片层负责把文件切成合适大小的数据块协议层定义包头格式塞进序号、确认号、标志位这些字段传输控制层管发送窗口、超时重传、拥塞退避应用层负责文件读写、进度统计、断点续传的元数据管理。这四层各管一摊耦合度低调试的时候能一层一层单独验证不至于一出问题就抓瞎。适合谁来参考这份东西我觉得有三类人比较对口一是做后端或中间件、想深入理解可靠传输原理的开发者二是做内网工具、需要自己掌控传输策略的工程师三是学生或转行者想找一个比“手写 TCP 三次握手”更贴近真实工程的练手项目。前提是你得会基本的 Java 网络编程知道DatagramPacket怎么用不然看下去会有点吃力。2. 核心机制拆解与关键参数选择2.1 包头设计每个字节都要抠UDP 本身只给你一个数据报边界剩下的全靠自己在 payload 里塞元数据。包头设计是整个协议的地基设计得不好后面要么浪费带宽要么扩展困难。我最终定下来的包头是16 字节固定头结构如下字段长度说明魔数2 字节固定值用于快速识别非法包版本号1 字节协议版本方便后续升级标志位1 字节SYN / ACK / FIN / DATA / HEARTBEAT序号4 字节数据包序号从 0 递增确认号4 字节累计确认表示“这个序号之前我都收到了”窗口大小2 字节接收方剩余缓冲区能容纳的包数数据长度2 字节payload 实际字节数为什么序号用 4 字节因为大文件分片后包数量可能上百万2 字节的 65535 根本不够用会回绕回绕处理起来极其恶心。4 字节能表示 42 亿个包按每包 1400 字节算能覆盖约 5.6 TB 的文件足够用了。确认号用累计确认而不是选择确认是因为大文件单向传输场景下接收端基本是顺序到达累计确认实现简单、包头小偶尔乱序靠重传兜底就行没必要上 SACK 那套复杂逻辑。标志位用一个字节的位图0x01是 SYN0x02是 ACK0x04是 FIN0x08是 DATA0x10是心跳。这样判断包类型只需要做位与运算比字符串比较快得多。2.2 分片大小1400 字节的由来分片大小这个参数很多人随手写个 1024 或者 8192其实是有讲究的。以太网的 MTU 是 1500 字节减去 IP 头 20 字节、UDP 头 8 字节留给应用层的最大空间是1472 字节。再减去我们自己的 16 字节包头payload 最大就是 1456 字节。我取1400 字节作为 payload 大小留了几十字节的余量防止某些链路有额外的封装开销导致分片。注意一旦 IP 层发生分片只要其中一片丢了整个数据报都得重传效率会断崖式下跌。所以宁可 payload 小一点也不要触发 IP 分片。这是实测踩过的坑早期用 1472 跑丢包率一高吞吐直接崩。2.3 发送窗口与接收缓冲区发送窗口决定了“在没收到确认之前最多能发出去多少个包”。窗口太小链路利用率上不去因为发送端老是停下来等确认窗口太大一旦丢包重传的量会很大而且接收端缓冲区容易溢出。我用的计算方式是带宽时延积BDP。假设链路带宽 100 Mbps往返时延 RTT 是 20 ms那么 BDP 100 Mbps × 0.02 s 2 Mb 250 KB。按每包 1400 字节算大约需要 178 个包才能填满管道。所以发送窗口初始值设为256 个包留一点余量。接收端的缓冲区则设为窗口的 2 倍即 512 个包的槽位用环形数组实现避免频繁扩容。窗口不是固定不变的后面会讲怎么根据 ACK 的到达情况动态调整。2.4 超时重传RTO 怎么算才不抽风超时重传时间RTO如果写死一个固定值比如 200 ms那在不同网络环境下表现会天差地别。局域网里 200 ms 太长丢包了要等半天才重传跨地域链路 200 ms 又太短正常延迟就被误判成丢包导致无谓重传越重传越堵。我用的是自适应 RTO参考了经典算法但做了简化。每次收到 ACK测量一个 RTT 样本然后平滑 RTTSRTT (1 - α) × SRTT α × RTTα 取 0.125偏差RTTVAR (1 - β) × RTTVAR β × |SRTT - RTT|β 取 0.25最终RTO SRTT 4 × RTTVAR初始 SRTT 设为 100 msRTTVAR 设为 50 ms所以初始 RTO 是 300 ms。这个值在大多数网络下都比较稳。另外加了个下限RTO 最小不低于 50 ms防止在超低延迟局域网里频繁误重传。2.5 拥塞控制简单但够用的 AIMDUDP 没有拥塞控制如果不加限制地猛发网络一堵丢包率飙升重传风暴会把链路彻底打死。我在发送端加了一个简化版的AIMD加性增、乘性减拥塞窗口每收到一个有效 ACK拥塞窗口cwnd 1慢启动阶段翻倍增长检测到超时重传cwnd cwnd / 2同时ssthresh cwnd实际发送窗口 min(发送窗口, cwnd)这套逻辑比 TCP 的完整实现简单得多但对付大文件单向传输足够了。实测在模拟丢包 1% 的环境下吞吐能稳定在链路带宽的 70% 以上比不加拥塞控制时的 30% 好太多。3. 完整实操流程与核心代码实现3.1 发送端主循环从文件到数据报发送端的整体流程是打开文件 → 建立连接握手→ 循环读取分片并发送 → 处理 ACK 和重传 → 发送 FIN 结束。核心循环我用一个while驱动配合Selector做非阻塞收发。先看文件分片和发送的核心逻辑public class ReliableUdpSender { private static final int PAYLOAD_SIZE 1400; private static final int HEADER_SIZE 16; private static final int WINDOW_SIZE 256; private DatagramChannel channel; private InetSocketAddress remote; private long base 0; // 窗口起始序号 private long nextSeq 0; // 下一个待发序号 private long fileSize; private RandomAccessFile file; private MapLong, byte[] sentPackets new ConcurrentHashMap(); private MapLong, Long sendTimeMap new ConcurrentHashMap(); public void sendFile(Path path) throws IOException { file new RandomAccessFile(path.toFile(), r); fileSize file.length(); long totalPackets (fileSize PAYLOAD_SIZE - 1) / PAYLOAD_SIZE; // 握手阶段发送 SYN等待 SYN-ACK handshake(); while (base totalPackets) { // 窗口未满继续发送 while (nextSeq base WINDOW_SIZE nextSeq totalPackets) { byte[] payload readChunk(nextSeq); byte[] packet buildPacket(nextSeq, payload); channel.send(ByteBuffer.wrap(packet), remote); sentPackets.put(nextSeq, packet); sendTimeMap.put(nextSeq, System.currentTimeMillis()); nextSeq; } // 等待 ACK超时则重传 waitForAck(); } sendFin(); } private byte[] readChunk(long seq) throws IOException { long offset seq * PAYLOAD_SIZE; int len (int) Math.min(PAYLOAD_SIZE, fileSize - offset); byte[] buf new byte[len]; file.seek(offset); file.readFully(buf); return buf; } }readChunk用RandomAccessFile而不是FileInputStream是为了支持断点续传——如果传输中断下次可以从任意序号对应的偏移量重新读不用从头来。这个设计在传几个 GB 的大文件时特别有用中断一次重传全部的话心态会崩。3.2 包头组装与解析包头的组装我用ByteBuffer来做比手动移位清晰得多private byte[] buildPacket(long seq, byte[] payload) { ByteBuffer buf ByteBuffer.allocate(HEADER_SIZE payload.length); buf.putShort((short) 0x55AA); // 魔数 buf.put((byte) 1); // 版本 buf.put((byte) 0x08); // DATA 标志 buf.putInt((int) seq); // 序号 buf.putInt(0); // 确认号数据包填 0 buf.putShort((short) WINDOW_SIZE); // 窗口 buf.putShort((short) payload.length); // 数据长度 buf.put(payload); return buf.array(); }解析的时候反过来先读魔数校验不匹配直接丢弃防止把别的程序的 UDP 包误收进来。这个魔数校验看着不起眼但在共享网络环境里能省掉很多莫名其妙的 bug。3.3 接收端乱序处理与累计确认接收端的核心是一个环形缓冲区按序号取模定位槽位。收到包后先检查序号是否在窗口内是就放入对应槽位然后尝试推进累计确认号public class ReliableUdpReceiver { private static final int BUFFER_SIZE 512; private byte[][] buffer new byte[BUFFER_SIZE][]; private long expectedSeq 0; // 期望收到的下一个序号 private long highestAck -1; public void onPacket(byte[] data, InetSocketAddress from) { ByteBuffer buf ByteBuffer.wrap(data); short magic buf.getShort(); if (magic ! (short) 0x55AA) return; // 非法包丢弃 buf.get(); // version byte flags buf.get(); long seq buf.getInt() 0xFFFFFFFFL; buf.getInt(); // ack buf.getShort(); // window short len buf.getShort(); byte[] payload new byte[len]; buf.get(payload); if ((flags 0x08) ! 0) { // DATA 包 int slot (int) (seq % BUFFER_SIZE); if (seq expectedSeq buffer[slot] null) { buffer[slot] payload; } // 尝试推进 expectedSeq while (buffer[(int) (expectedSeq % BUFFER_SIZE)] ! null) { writeToFile(expectedSeq, buffer[(int) (expectedSeq % BUFFER_SIZE)]); buffer[(int) (expectedSeq % BUFFER_SIZE)] null; expectedSeq; } highestAck expectedSeq - 1; sendAck(highestAck); } } }这里有个细节收到重复包时不要重复写文件。判断依据就是buffer[slot] null如果槽位已经有数据了说明这个包之前收过直接忽略但仍然要回一个 ACK因为对方可能没收到之前的确认。3.4 断点续传的元数据管理大文件传输最怕传到 90% 断了一切归零。我在发送端和接收端各维护一个.meta文件记录已确认的字节偏移量。发送端每次收到 ACK 就更新元数据接收端每次推进expectedSeq也更新。重启后双方先交换元数据从较小的那个偏移量继续传。private void saveMeta(long confirmedBytes) { try (FileWriter fw new FileWriter(metaPath.toFile())) { fw.write(String.valueOf(confirmedBytes)); } catch (IOException e) { // 元数据写失败不影响主流程下次全量重传即可 } }提示元数据文件建议每收到 100 个 ACK 落一次盘不要每个包都写否则磁盘 IO 会成为瓶颈。我早期每个 ACK 都写结果传输速度被磁盘拖慢了一半。3.5 实测数据与调优记录在局域网两台机器之间传一个 2 GB 的文件千兆网卡直连实测数据如下配置平均吞吐耗时重传率窗口 64固定 RTO 200ms320 Mbps52s8.2%窗口 256自适应 RTO780 Mbps21s1.1%窗口 512自适应 RTO AIMD860 Mbps19s0.6%窗口从 64 提到 256 是提升最大的一步因为 64 个包填不满千兆链路的管道。再往上提到 512 收益就递减了而且接收端缓冲区压力变大内存占用从 30 MB 涨到 60 MB。最终我选了 256 作为默认值兼顾吞吐和内存。4. 常见问题排查与避坑经验4.1 问题速查表现象可能原因排查方向解决方法传输卡在某个序号不动ACK 包丢失或对端没收到抓包看 ACK 是否发出增加 ACK 重传接收端定期重发最近 ACK吞吐突然掉到很低触发拥塞控制乘性减看 cwnd 变化日志检查是否误判丢包调大 RTO 下限接收端文件损坏乱序写入或重复写入校验文件 MD5检查槽位判空逻辑加写入前序号校验内存持续增长sentPackets 未清理看 Map 大小收到 ACK 后及时 remove 已确认的包跨平台传输失败字节序问题检查 ByteBuffer 默认序统一用ByteOrder.BIG_ENDIAN4.2 踩过的坑ACK 风暴早期实现里接收端每收到一个数据包就回一个 ACK。结果在高速传输时ACK 包的数量和数据包一样多上行带宽被 ACK 占了一大半而且发送端处理 ACK 的 CPU 开销也很高。后来改成延迟确认 累计确认接收端每收到 8 个包或者距离上次发 ACK 超过 20 ms才回一个 ACKACK 里带当前最高的累计确认号。这一改ACK 数量降到原来的八分之一吞吐直接涨了 15%。4.3 踩过的坑缓冲区溢出导致丢包接收端环形缓冲区如果满了新来的包只能丢弃。但丢弃之后发送端并不知道还在按窗口猛发结果就是大量重传。我的解决办法是在 ACK 里带上接收窗口的剩余空间发送端根据这个值动态收缩发送窗口。当接收窗口小于某个阈值比如 32 个包时发送端主动降速等接收端消费完再提速。这个机制加上之后接收端的丢包率从 3% 降到了 0.2%。4.4 踩过的坑文件句柄泄漏RandomAccessFile和DatagramChannel都是需要显式关闭的资源。我一开始在finally块里只关了 channel忘了关 file结果传了几十个文件之后程序报“too many open files”。后来统一用 try-with-resources 管理或者在一个shutdown()方法里按顺序关闭所有资源问题才解决。注意DatagramChannel关闭后如果还有线程在receive()上阻塞会抛AsynchronousCloseException这个异常要单独捕获并静默处理不要当成错误往上抛。4.5 独家心得先跑通再优化这个项目我最大的体会是不要一上来就追求完美协议。我第一版只做了最简单的“发一个等一个 ACK”吞吐只有几兆但它能正确传完文件。有了这个正确性基线后面加窗口、加拥塞控制、加断点续传每加一个功能都能对比测试确认没有引入回归。如果一开始就堆所有机制出了问题根本不知道是哪一层导致的。另外日志要分级。传输过程中每个包的收发都打日志的话磁盘 IO 会把性能拖垮。我的做法是默认只打 WARN 以上需要调试时通过启动参数打开 DEBUG并且 DEBUG 日志写到独立文件避免污染主日志。4.6 后续可以扩展的方向这套东西目前只支持单向传输如果要做双向需要在包头里同时维护两个方向的序号和确认号复杂度会上升不少。另一个方向是加加密在 payload 层做 AES 加密包头加一个校验字段防止数据被篡改。还有就是多线程发送把文件分成几段每个线程负责一段共享一个拥塞窗口这个在超高带宽链路上能进一步榨性能但线程间的窗口同步要做好不然会互相踩踏。我个人在实际操作中的体会是UDP 可靠传输这东西原理不难难的是各种边界情况的处理——丢包、乱序、重复、超时、缓冲区满、对端崩溃。每一个都要有对应的策略而且策略之间还会互相影响。把这些问题一个一个踩过来对网络协议的理解会比看十本书都深。
