1. 为什么UDP传大文件这件事值得认真对待
很多人第一次接触网络编程，都是从TCP开始的。TCP用起来太省心了，三次握手建立连接，数据按序到达，丢了自动重传，流量拥塞自己调节，写代码的人几乎不用操心底层发生了什么。但当你真正面对一些特殊场景——比如局域网内批量分发镜像文件、跨机房同步日志归档、嵌入式设备之间做固件推送——你会发现TCP有时候反而“太规矩了”，规矩到让你没法针对自己的业务特点做优化。
UDP就完全是另一回事。它像一张白纸，发出去就不管了，不保证到达、不保证顺序、不保证不重复。用它传大文件，等于你要自己把TCP帮你做的那些事全部重新实现一遍：分片、编号、确认、重传、排序、去重、流量控制、拥塞避免。听起来很吓人，但这恰恰是它有价值的地方——你可以根据具体场景裁剪出一套最合适的可靠传输机制，而不是被通用协议绑死。
这个项目的核心目标很明确：用Java实现一套基于UDP套接字的可靠大文件传输方案。所谓“大文件”，我个人的经验线是超过100MB就算，超过1GB就要认真对待了。因为文件一大，你必然会遇到分片管理、内存占用、超时重传策略、接收端缓冲等一系列问题，这些在小文件场景下根本暴露不出来。
适合谁来参考这篇内容？如果你已经写过简单的UDP收发Demo，知道DatagramSocket和DatagramPacket怎么用，但一传大文件就各种丢包、乱序、内存溢出，那这篇就是写给你的。如果你只是想知道“UDP能不能传大文件”这种问题，答案是可以，但你需要往下看完整个设计思路再决定要不要自己造这个轮子。
2. 整体方案设计与核心思路拆解
2.1 为什么不用TCP而选UDP
这个问题必须先回答清楚，否则整个项目就没有立足点。TCP在绝大多数文件传输场景下都是更优解，这是事实。但有几类场景UDP确实有优势：
第一类是局域网内一对多分发。比如一个机房里有50台机器需要同时接收同一个文件，用TCP意味着服务端要维护50条连接，每条连接独立做拥塞控制，带宽分配很难做到公平高效。用UDP的话，服务端可以按固定速率向组播地址发送，接收端各自按需接收，服务端压力小得多。
第二类是对传输时机有精细控制需求。TCP的拥塞控制是内核层面的，应用层很难干预。有些场景下你明确知道当前网络质量很好，想跑满带宽，但TCP的慢启动和拥塞窗口增长策略会让你等很久。UDP可以让你自己决定发送速率。
第三类是需要穿透某些中间设备。有些网络环境对TCP连接有额外的检查或限制，UDP数据报反而更容易通过。这个不多展开，做过网络编程的人都懂。
注意：选UDP不等于放弃可靠性，而是把可靠性的控制权从内核拿到应用层。你要做的功课比TCP多得多，这一点在动手之前必须有心理准备。
2.2 可靠传输需要解决的核心问题
用UDP传大文件，本质上你要在应用层实现一个简化版的TCP。核心要解决的问题按优先级排列如下：
- 分片与重组：大文件不可能一个数据报发完。UDP单个数据报的理论上限是65507字节（65535减去IP头和UDP头），但实际使用中考虑到MTU（最大传输单元），通常把每个数据报的有效载荷控制在1400字节左右，避免IP层分片。文件被切成N个块，每块编号，接收端按编号重组。
- 确认与重传：接收端收到数据块后要回ACK，发送端在一定时间内没收到ACK就重传。这里涉及超时时间怎么定、重传几次放弃、是否要做快速重传。
- 顺序保证：UDP不保证到达顺序，接收端可能先收到第5块再收到第3块。需要一个滑动窗口或缓冲区来暂存乱序到达的块，等前面的块到齐后再按序写入文件。
- 去重：重传可能导致接收端收到重复的块，需要根据编号去重。
- 流量控制：接收端处理不过来的时候要能告诉发送端慢一点，否则接收缓冲区溢出，丢包率飙升。
- 完整性校验：文件传完之后要验证内容是否完整，通常用MD5或SHA-256做整体校验。
2.3 协议头设计：每个数据报带什么信息
既然要在UDP之上建一套自己的协议，就得定义自己的协议头。我采用的是固定16字节的头部，结构如下：
| 字段 | 长度 | 说明 |
|---|---|---|
| 魔数 | 4字节 | 固定值，用于快速识别是否为本次传输的数据报 |
| 类型 | 1字节 | 0=数据块，1=ACK，2=开始传输，3=传输完成，4=取消 |
| 块编号 | 4字节 | 当前数据块的序号，从0开始递增 |
| 总块数 | 4字节 | 文件被切成的总块数，用于接收端判断是否收齐 |
| 数据长度 | 2字节 | 当前数据报中有效载荷的字节数 |
| 保留 | 1字节 | 对齐用，暂时填0 |
头部之后紧跟有效载荷。这样每个数据报的总大小控制在16+1400=1416字节以内，加上UDP头和IP头也不会超过1500字节的典型MTU，避免IP分片。
实操心得：魔数这个字段看起来多余，但在实际调试中非常有用。当你的程序同时监听多个端口或者网络中有其他UDP流量时，没有魔数你根本分不清收到的包是不是自己的。我一般用一个不太常见的4字节序列，比如0xCAFEBABE这种。
2.4 滑动窗口与发送速率控制
发送端不能一次性把几万个数据块全发出去，那样网络设备缓冲区瞬间就爆了。需要一个滑动窗口机制：维护一个发送窗口，窗口内的块可以连续发送，窗口外的块必须等窗口滑动后才能发。
窗口大小的选择是个经验活。太小了带宽利用率低，太大了容易造成网络拥塞。我的做法是初始窗口设为32个块，然后根据ACK的返回情况动态调整：如果连续多个窗口的块都在超时前收到ACK，窗口翻倍；如果出现超时重传，窗口减半。这就是一个简化的AIMD（加性增乘性减）策略，和TCP的拥塞控制思路一致。
接收端也有一个窗口，用于暂存乱序到达的块。接收窗口的大小应该大于等于发送窗口，否则发送端发出来的块接收端没地方放，只能丢弃，造成不必要的重传。
3. 核心细节解析与实操要点
3.1 文件分片的具体做法
分片看起来简单，实际上有几个细节容易踩坑。首先，块大小怎么定？前面说了1400字节是经验值，但这不是拍脑袋来的。以太网的MTU是1500字节，减去IP头最少20字节、UDP头8字节，剩下1472字节。再留一点余量给可能的PPPoE等额外封装，1400是比较安全的数字。
其次，文件最后一块怎么处理？如果文件大小不是块大小的整数倍，最后一块会小于1400字节。这时候数据长度字段就派上用场了，接收端根据这个字段判断实际有效数据是多少。
第三，块编号从0开始还是从1开始？我建议从0开始，因为数组下标习惯从0开始，代码写起来更自然。但要注意总块数的计算：totalBlocks = (fileSize + blockSize - 1) / blockSize，这是向上取整的经典写法。
// 分片逻辑示例 int blockSize = 1400; long fileSize = file.length(); int totalBlocks = (int) ((fileSize + blockSize - 1) / blockSize); // 读取第i块 byte[] buffer = new byte[blockSize]; FileInputStream fis = new FileInputStream(file); fis.skip((long) i * blockSize); int bytesRead = fis.read(buffer);注意：fis.skip()在有些文件系统上不保证精确跳过指定字节数，稳妥的做法是用循环读取来定位。不过对于本地文件系统，skip通常没问题，我实测下来在Windows和Linux上都能精确跳过。
3.2 超时重传的时间怎么定
超时时间（RTO）的设置直接影响到传输效率和可靠性。设得太短，ACK还没回来就重传，浪费带宽；设得太长，丢包后要等很久才重传，传输速度上不去。
静态RTO在局域网内可以设得很短，比如50毫秒。但在广域网上，RTT可能波动很大，静态值就不合适了。更好的做法是动态计算RTO，类似TCP的做法：先测量每个块的往返时间（RTT），然后取加权平均值和偏差来计算RTO。
简化版的做法是：维护一个RTT的指数加权移动平均（EWMA），每次收到ACK时更新，RTO设为SRTT + 4 * RTTVAR。这个公式来自RFC 6298，是经过验证的经典算法。
// 简化的RTO计算 double srtt = -1; // 平滑RTT double rttvar = -1; // RTT偏差 double rto = 200; // 初始RTO，单位毫秒 void updateRTO(long measuredRTT) { if (srtt < 0) { srtt = measuredRTT; rttvar = measuredRTT / 2.0; } else { rttvar = 0.75 * rttvar + 0.25 * Math.abs(srtt - measuredRTT); srtt = 0.875 * srtt + 0.125 * measuredRTT; } rto = srtt + 4 * rttvar; rto = Math.max(rto, 10); // 下限10ms rto = Math.min(rto, 2000); // 上限2秒 }实操心得：初始RTO不要设得太小，我一般设200毫秒。因为第一个块的RTT测量往往不准，设太小容易导致不必要的重传。等收到几个ACK之后，RTO会迅速收敛到合理值。
3.3 接收端的乱序处理与去重
接收端收到数据块后，不能直接写入文件，因为可能是乱序的。需要一个接收缓冲区，按块编号存放。当编号连续的块从缓冲区起始位置开始都到齐了，就可以批量写入文件，然后滑动接收窗口。
去重逻辑相对简单：如果收到的块编号小于当前期望的编号，说明是已经处理过的重复块，直接丢弃并回ACK即可。如果块编号在接收窗口范围内但缓冲区里已经有了，也是重复块，同样丢弃回ACK。
// 接收端核心逻辑示意 Map<Integer, byte[]> receiveBuffer = new HashMap<>(); int expectedBlock = 0; void handleDataBlock(int blockNum, byte[] data) { if (blockNum < expectedBlock) { // 重复块，直接回ACK sendACK(blockNum); return; } if (receiveBuffer.containsKey(blockNum)) { // 重复块，回ACK sendACK(blockNum); return; } receiveBuffer.put(blockNum, data); sendACK(blockNum); // 尝试按序写入 while (receiveBuffer.containsKey(expectedBlock)) { byte[] blockData = receiveBuffer.remove(expectedBlock); writeToFile(blockData); expectedBlock++; } }注意：接收缓冲区不能无限增长。如果发送端窗口是32，接收缓冲区最多也就存32个块左右。如果发现缓冲区大小超过窗口大小的两倍，说明有问题，要么是发送端窗口控制失效，要么是ACK丢失导致发送端一直重传。这时候要考虑主动丢弃一些块来保护内存。
3.4 传输完成后的完整性校验
文件传完之后，接收端需要确认收到的文件是否完整。最可靠的方式是发送端在传输开始前先发送文件的MD5或SHA-256哈希值，接收端收完后计算本地文件的哈希值进行比对。
哈希值的传输可以放在“开始传输”消息里，也可以单独发一个控制消息。我倾向于放在开始传输消息里，这样接收端一开始就知道目标哈希，收完后直接比对，不需要额外的往返。
如果哈希不匹配怎么办？说明有块丢失或损坏但ACK机制没发现。这种情况概率很低，但一旦发生，最简单的处理是重新传输整个文件。更精细的做法是让接收端报告哪些块缺失，发送端只重传缺失的块。不过实现复杂度会上升不少，看你的场景是否值得。
4. 完整实操流程与核心环节实现
4.1 发送端主循环的搭建
发送端的主循环是整个程序的心脏。它的基本流程是：建立UDP套接字，发送开始传输消息，进入发送循环，在循环中处理超时重传和ACK接收，最后发送完成消息并等待确认。
public void sendFile(String host, int port, File file) throws Exception { DatagramSocket socket = new DatagramSocket(); InetAddress address = InetAddress.getByName(host); // 计算文件分片信息 int blockSize = 1400; long fileSize = file.length(); int totalBlocks = (int) ((fileSize + blockSize - 1) / blockSize); String fileHash = calculateHash(file); // 发送开始传输消息 sendStartMessage(socket, address, port, fileSize, totalBlocks, fileHash); // 等待接收端准备好 waitForReady(socket); // 进入发送循环 int windowSize = 32; int base = 0; // 窗口起始块 int nextSeq = 0; // 下一个要发送的块 Map<Integer, Long> sendTimeMap = new HashMap<>(); // 记录每个块的发送时间 Set<Integer> ackedBlocks = new HashSet<>(); FileInputStream fis = new FileInputStream(file); byte[] fileData = new byte[(int) fileSize]; fis.read(fileData); fis.close(); while (base < totalBlocks) { // 发送窗口内的块 while (nextSeq < base + windowSize && nextSeq < totalBlocks) { byte[] blockData = extractBlock(fileData, nextSeq, blockSize); sendDataBlock(socket, address, port, nextSeq, totalBlocks, blockData); sendTimeMap.put(nextSeq, System.currentTimeMillis()); nextSeq++; } // 接收ACK，设置超时时间为最近的RTO socket.setSoTimeout((int) rto); try { DatagramPacket ackPacket = new DatagramPacket(new byte[1024], 1024); socket.receive(ackPacket); int ackBlock = parseACK(ackPacket); ackedBlocks.add(ackBlock); sendTimeMap.remove(ackBlock); // 更新RTO // ...（省略RTT计算逻辑） // 滑动窗口 while (ackedBlocks.contains(base)) { base++; } } catch (SocketTimeoutException e) { // 超时，重传窗口内所有未确认的块 for (int i = base; i < nextSeq; i++) { if (!ackedBlocks.contains(i)) { byte[] blockData = extractBlock(fileData, i, blockSize); sendDataBlock(socket, address, port, i, totalBlocks, blockData); sendTimeMap.put(i, System.currentTimeMillis()); } } } } // 发送完成消息 sendFinishMessage(socket, address, port); socket.close(); }这段代码有几个关键点需要展开说明。第一，文件数据一次性读入内存。对于大文件来说这可能是个问题，1GB的文件就要占1GB内存。如果内存紧张，可以改成按需读取，每次发送块的时候从文件读取对应位置的数据。但那样会有频繁的IO操作，速度会慢一些。折中方案是维护一个滑动窗口大小的内存缓冲区，只缓存窗口内的数据。
第二，超时后的重传策略。我选择的是重传窗口内所有未确认的块，这是一种保守但简单的做法。更精细的做法是只重传超时的那个块，但需要为每个块单独维护定时器，实现复杂度高很多。在实际局域网环境中，丢包往往是突发性的，重传整个窗口反而更高效。
第三，窗口滑动的条件。只有当base指向的块被确认后，base才能前移。如果base的ACK丢了但后面块的ACK到了，窗口不会滑动，会导致不必要的重传。这是Go-Back-N策略的固有缺陷。改进方案是使用选择确认（SACK），接收端可以告诉发送端哪些块已经收到，发送端只重传真正丢失的块。
4.2 接收端主循环的搭建
接收端相对简单一些，主要是收包、判断类型、处理数据块、发送ACK。
public void receiveFile(int port, String outputPath) throws Exception { DatagramSocket socket = new DatagramSocket(port); socket.setSoTimeout(30000); // 30秒没收到任何包就认为传输结束 FileOutputStream fos = null; int expectedBlock = 0; int totalBlocks = -1; Map<Integer, byte[]> receiveBuffer = new HashMap<>(); String expectedHash = null; while (true) { byte[] buf = new byte[2048]; DatagramPacket packet = new DatagramPacket(buf, buf.length); try { socket.receive(packet); } catch (SocketTimeoutException e) { // 超时，传输可能已结束 break; } // 解析协议头 ByteBuffer bb = ByteBuffer.wrap(packet.getData(), 0, packet.getLength()); int magic = bb.getInt(); if (magic != MAGIC) continue; // 不是我们的包，忽略 byte type = bb.get(); int blockNum = bb.getInt(); int total = bb.getInt(); short dataLen = bb.getShort(); bb.get(); // 保留字节 if (type == TYPE_START) { totalBlocks = total; expectedHash = readHashFromPacket(bb); fos = new FileOutputStream(outputPath); sendReady(socket, packet.getAddress(), packet.getPort()); } else if (type == TYPE_DATA) { byte[] data = new byte[dataLen]; bb.get(data); if (blockNum < expectedBlock) { sendACK(socket, packet.getAddress(), packet.getPort(), blockNum); continue; } if (receiveBuffer.containsKey(blockNum)) { sendACK(socket, packet.getAddress(), packet.getPort(), blockNum); continue; } receiveBuffer.put(blockNum, data); sendACK(socket, packet.getAddress(), packet.getPort(), blockNum); // 按序写入 while (receiveBuffer.containsKey(expectedBlock)) { byte[] blockData = receiveBuffer.remove(expectedBlock); fos.write(blockData); expectedBlock++; } } else if (type == TYPE_FINISH) { // 传输完成，校验哈希 fos.close(); String actualHash = calculateHash(new File(outputPath)); if (actualHash.equals(expectedHash)) { sendFinishAck(socket, packet.getAddress(), packet.getPort(), true); } else { sendFinishAck(socket, packet.getAddress(), packet.getPort(), false); } break; } } socket.close(); }接收端有一个容易忽略的细节：SocketTimeoutException的处理。如果发送端发完所有块后，最后一个FINISH消息丢了，接收端会一直等下去。设置一个合理的超时时间（比如30秒），超时后认为传输结束，主动做完整性校验。如果校验通过就正常结束，不通过就报错。
实操心得：接收端的文件写入最好用BufferedOutputStream包装一下，否则每个块都触发一次系统调用，写入速度会成为瓶颈。我实测过，不加缓冲的情况下，接收1GB文件要多花将近一倍的时间。
4.3 参数调优与性能测试
参数调优这件事没有银弹，必须根据实际网络环境来。我在局域网（千兆交换机，RTT小于1毫秒）和跨机房（RTT约20毫秒）两种环境下做过对比测试，结论如下：
| 参数 | 局域网推荐值 | 跨机房推荐值 | 说明 |
|---|---|---|---|
| 块大小 | 1400字节 | 1400字节 | 受MTU限制，不宜再大 |
| 初始窗口 | 64 | 16 | 局域网RTT小，可以激进一些 |
| 初始RTO | 50ms | 200ms | 跨机房RTT大，RTO要相应放大 |
| 最大重传次数 | 10 | 20 | 跨机房丢包概率高，多给几次机会 |
| 接收缓冲区上限 | 128块 | 64块 | 防止内存无限增长 |
在千兆局域网环境下，用上述参数传输一个1GB的文件，实测耗时约12秒，平均速率约85MB/s，接近千兆网络的理论上限（约118MB/s）。跨机房环境下，1GB文件耗时约3分钟，平均速率约5.7MB/s，主要受限于带宽和RTT。
注意：这些数字是基于特定测试环境的，你的实际结果可能会有差异。关键是要理解每个参数背后的权衡逻辑，然后根据自己的环境调整。
4.4 传输进度的可视化反馈
大文件传输耗时较长，用户需要知道当前进度。发送端可以根据已确认的块数计算进度百分比，定期打印或更新界面。
// 进度反馈 int lastReportedPercent = -1; // 在滑动窗口的循环中 int percent = (int) (base * 100L / totalBlocks); if (percent != lastReportedPercent && percent % 5 == 0) { System.out.printf("传输进度: %d%% (%d/%d 块)%n", percent, base, totalBlocks); lastReportedPercent = percent; }每5%报告一次比较合适，太频繁了刷屏，太少了用户等得心焦。如果是图形界面，可以更新进度条；如果是命令行，打印百分比就够了。
5. 常见问题与排查技巧实录
5.1 丢包率居高不下怎么办
丢包是UDP传输的常态，但丢包率超过5%就说明有问题了。排查思路按以下顺序进行：
首先检查接收缓冲区是否溢出。如果接收端处理速度跟不上发送速度，内核的UDP接收缓冲区会满，后续到达的包直接被丢弃。解决办法是增大接收缓冲区（socket.setReceiveBufferSize()），或者降低发送端的发送速率。
其次检查网络设备是否有UDP限速。有些交换机和路由器对UDP流量有额外的限速策略，尤其是广播和组播流量。如果是这个原因，只能降低发送速率或者改用单播。
第三检查MTU设置是否匹配。如果发送端的数据报大小超过了路径上某个设备的MTU，IP层会分片，分片后的包只要丢一个，整个数据报就废了。解决办法是确保数据报大小不超过路径MTU，通常1400字节是安全的。
5.2 传输速度上不去怎么调
速度上不去的原因通常有三个：窗口太小、RTO太大、或者接收端写入太慢。
窗口太小是最常见的原因。如果窗口只有几个块，发送端发完就得等ACK，带宽利用率极低。解决办法是逐步增大窗口，观察速度变化。但也不能无限增大，窗口太大容易造成突发流量导致丢包。
RTO太大意味着丢包后要等很久才重传。如果RTO是500毫秒，丢一个包就浪费半秒。解决办法是让RTO动态收敛到合理值，前面提到的EWMA算法就是干这个的。
接收端写入太慢往往被忽略。如果接收端每收到一个块就写一次文件，IO开销会很大。用BufferedOutputStream可以显著改善。另外，如果接收端和发送端在同一台机器上测试，磁盘IO可能成为瓶颈，这时候换到两台机器上测试才能看到真实速度。
5.3 内存占用过高怎么优化
如果发送端一次性把整个文件读入内存，大文件会占用大量内存。优化方案是滑动窗口缓冲区：只把窗口内的数据保留在内存中，窗口滑过后释放。
// 滑动窗口缓冲区示意 byte[] windowBuffer = new byte[windowSize * blockSize]; // 当base滑动时，从文件中读取新的块填充到缓冲区接收端也有类似的问题。如果接收缓冲区无限增长，内存会爆。解决办法是设置缓冲区上限，超过上限时丢弃最旧的块（虽然会导致重传，但保护了内存）。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 传输卡住不动 | 最后一个FINISH消息丢失 | 查看发送端是否在等待FINISH_ACK | 接收端设置超时，超时后主动校验 |
| 速度突然降到很低 | 网络拥塞导致大量丢包 | 打印丢包率和重传次数 | 减小窗口，降低发送速率 |
| 接收端文件损坏 | 块丢失但ACK机制没发现 | 对比MD5 | 增加每块的校验和字段 |
| 程序内存溢出 | 接收缓冲区无限增长 | 监控缓冲区大小 | 设置缓冲区上限 |
| 传输完成后程序不退出 | 套接字未关闭或线程未结束 | 检查socket.close()调用 | 确保所有资源正确释放 |
| 跨平台传输乱码 | 字节序不一致 | 检查ByteBuffer的字节序设置 | 统一使用大端序（网络字节序） |
实操心得：字节序这个问题我踩过坑。Java的ByteBuffer默认是大端序，和网络字节序一致，所以通常没问题。但如果你用了
ByteBuffer.order(ByteOrder.LITTLE_ENDIAN)，在x86机器上测试正常，到了ARM机器上就全乱了。建议协议头统一用大端序，不要改。
5.5 调试技巧：如何抓包分析
当问题难以定位时，抓包是最直接的手段。在Linux上用tcpdump，在Windows上用Wireshark。抓包时注意过滤条件，只看你的UDP端口，否则数据量太大没法分析。
# Linux下抓取指定UDP端口的包 tcpdump -i eth0 -w udp_capture.pcap udp port 9876抓到包之后用Wireshark打开，可以看到每个数据报的发送时间、到达时间、序号、ACK情况。通过分析时间线，能很快定位是发送端没发、网络丢了、还是接收端没回ACK。
我遇到过一个诡异的问题：发送端显示已发送，接收端显示未收到，抓包发现包确实到了接收端机器，但应用程序没收到。最后发现是接收端的防火墙规则把UDP包拦截了。这种问题不看抓包根本想不到。
6. 进阶优化方向与个人经验
6.1 选择性重传（SACK）的实现思路
前面提到的Go-Back-N策略在丢包率低的时候没问题，但丢包率高的时候会重传大量已经收到的块，浪费带宽。选择性重传的思路是让接收端告诉发送端“我收到了哪些块”，发送端只重传没收到的。
实现方式是在ACK消息里携带一个位图，每一位表示对应的块是否收到。位图的长度等于窗口大小。发送端收到ACK后，根据位图更新哪些块需要重传。
这个优化在丢包率超过2%的场景下效果明显，但在局域网这种低丢包环境下收益不大，反而增加了协议复杂度。我的建议是先用Go-Back-N跑通，有需要再升级到SACK。
6.2 多线程收发的考量
单线程收发在高速网络下可能成为瓶颈。发送端可以用一个线程专门发送数据，另一个线程专门接收ACK。接收端也可以用线程池来处理数据块的写入。
但多线程会引入新的问题：共享数据的同步、线程间的协调、异常处理。如果单线程能满足性能需求，就不要上多线程。我实测过，在千兆局域网下，单线程收发就能跑满带宽，多线程反而因为锁竞争导致性能下降。
6.3 断点续传的可行性
断点续传在大文件传输中很有价值。实现思路是接收端定期把已收到的块信息持久化到磁盘，传输中断后重新连接时，接收端告诉发送端哪些块已经有了，发送端从缺失的块开始传。
这个功能的实现复杂度不低，需要设计一套会话管理机制。但如果你的场景经常需要传超大文件（比如几十GB），断点续传能节省大量时间，值得投入。
6.4 个人实操体会
这个项目我前前后后迭代了三个版本。第一版是最简单的停等协议，发一个块等一个ACK，速度慢得令人发指，1GB文件传了将近一个小时。第二版加了滑动窗口，速度提升到十几分钟，但丢包率一高就崩。第三版加了动态RTO和拥塞控制，才算是能用了。
最大的体会是：UDP可靠传输的难点不在发送和接收本身，而在异常处理。正常情况下的代码很简单，但网络一抖动，各种边界情况就出来了。超时、乱序、重复、丢ACK、丢FINISH，每一种都要有对应的处理逻辑。写这个程序的过程中，我对TCP的敬意增加了不少——内核里那套协议栈考虑的东西比我想象的多得多。
另一个体会是：测试环境要尽量模拟真实场景。我在本地回环接口上测试一切正常，到了真实局域网就各种问题。后来用网络模拟工具人为引入延迟和丢包，才把问题暴露出来。如果你也在做类似的项目，建议尽早到真实网络环境中测试，不要等到代码写完才发现问题。
最后分享一个小技巧：在协议头里加一个时间戳字段（8字节），记录发送端的发送时间。接收端收到后可以计算单向延迟，用于更精确的RTO估计。这个字段在调试时也很有用，抓包时能直接看到每个包的延迟情况。代价是每个数据报多了8字节开销，在1400字节的载荷下占比不到0.6%，完全可以接受。
