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

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

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

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

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

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