这个网页里面写了：
http://blog.csdn.net/plusboy/article/details/1523308
其可靠性必须由上层应用实现。一般都会采用消息重传来实现其可靠性，采用消息重传的时候有两种方式，一种是发送者发起，另一种是接收者发起。
前一种接收者发的是ACK。发送者收到ACK，就不重传。但是可能ACK内爆。
第二种接收者发的是NACK。发送者收到NACK，就重传。但是可能NACK内爆。另外需要保留发出去的数据，但是一般可以用超时机制，把以前的数据丢弃。
另外，看到云风的这篇文章。
http://blog.codingnow.com/2016/03/reliable_udp.html
如果用 UDP 再实现一个可靠传输协议，而表现的比 TCP 效果更好，那么多半只是在部分情况下的优势；或是霸道的占用了过量的资源，而 TCP 在设计时则是很友好的，以整个网络的通畅为更高准则的。
如果基于 UDP 可以做的比 TCP 更好，那么一定是放弃了点 TCP 需要做到的东西。
一条路是寄希望于业务逻辑上允许信息丢失。
那么，不允许信息丢失，但允许包乱序会不会改善?
在网络状况不好的时候，我们可以看到有时采用短连接反而能获得比长连接更好的用户体验。
我的思考结论就是：在 UDP 协议之上，实现一个带超时的请求回应机制，让业务层负责超时重发，有可能取得比 TCP 通讯更好的效果。但其前提是：单个请求或回应的包不应该过大，最好不要超过一个 MTU ，在互联网上大约是 500 多字节。MSS加报头就等于MTU。 MSL是2MSL = TIME_WAIT时间。