udp文件传输的问题，采用nack，怎么处理最后几个包丢失的情况? 第1页

1. kcp本来就不是为大流量发送服务的，是为有限流量降低 rtt服务的，我主页写的很清楚，不是帮你提高每秒多少KB的带宽利用率，而是帮你降低 rtt。再者你用kcp的时候设置的参数是什么？同时你是怎么测试的？内网？公网？如果你在内网测试不开网络模拟的话，基本没什么丢包，tcp是性能最好的，问题是公网不是这样，公网有丢包，特别是高峰期。

2. nack超时发送重传请求的话，需要估计双方rtt，超过短时均值rtt的 1.5倍就发起请求，有两种回应，当前没包了，或者有包。

3. 你tfrc没写对吧，好多用tfrc的协议不是跑的好好的？速率控制你做丢包递减了没？

4. 如姚老师，考虑多路tcp同时传送，但是tcp线程开几条就得了，5条以上有时适得其反。

第一种思路，既然是传输文件，那么文件的大小和校验码（MD5）应该是一开始就给接收端了吧

那么接收端其实是知道传输已经快结束了，就剩最后一小段数据了。

这时候就改变下策略，激进点，就是在传输接近结束的时候，接收端对剩余的数据包主动发起重传。

这样的好处是避免了在 99%的时候长时间等待，而耽误了后面其它任务，多浪费一点带宽，但是比例很小。

这种策略在P2P文件分享的时候也有用到，有些BT客户端会在下载任务接近完成的时候向所有种子节点发送请求，让任务尽快完成。

第二种思路就是 其它回答提到的编码方案，比如喷泉码，这种编码的好处就是不需要重传包，不停收数据就好，收够了解码用的数据，文件自然就完整了。

第三种，多路TCP，单路TCP的时候是受丢包和RTT影响的，在某些劣质链路上速度上不去，甚至连接都会断掉。同时建立多个TCP连接，每个连接传输文件的一个片段，这样可以获得更高的传输速度，以前的HTTP下载工具比如 网络蚂蚁 flashget都是这样的，迅雷现在也会这么做。分片和调动的算法要自己实现，但是比用UDP实现一套传输控制协议要简单多了。

可以尝试使用传输层编码技术，具体地可以采用喷泉编码和LDPC码等等删除码。可以避免这种最后的数据包传输特别慢的情况，不过引入的代价是要编解码。其实P2P传输中也会遇到最后几个数据块特别难下载的情况，传输层编码技术也适用。其实这样的套路和深空通信中的文件传输问题是一样的，深空通信为了克服巨大的RTT，需要采用删除码对文件进行预先编码，这样可以一次多发数据包，增大接收端的成功接收概率。深空通信一般也采用NACK的方法，不过这种是一次性的延时NACK，就是一轮一轮地发送，发送端发送完一轮数据包，根据NACK决定下一轮如何发送数据包，直到结束。如果楼主有兴趣，我安利楼主一篇论文《Retransmission Spurts of Deferred NAK ARQ in Fountain Coding Aided CCSDS File-Delivery Protocol》， 哈哈。