但是如果只做上面的回复处理，还是有问题：

比如 B 收到数据后回复给 A 的数据 "{OK}" 的包，A 没收到，怎么办呢？？？

2）当 A 没有收到B的 "{OK}" 包后，要做定时重发数据

定时重发，直到成功接收到确认包为止，再发下面的数据，当然，重发了一定数量后还是没能收到确认包，可以执行一下 ARP 的流程，防止对方网卡更换或别的原因。

但是这样的话，B 会收到很多重复的数据，假如每次都是 B 回复确认包 A 收不到的话。

3）发送数据的包中加个标识符 - 编号

比如 A 要发送的数据 “{标识符 | data}”到 B，B 收到后，先回复 “{OK}" 确认包，再根据原有的标识符进行比较，如果标识符相同，则数据丢失，如果不相同，则原有的标识符 = 接收标识符，且处理数据。

当 A 发送数据包后，没有收到确认包，则每隔 x 秒，把数据重发一次，直到收到确认包后，更新一下标识符，再进行后一包的数据发送。

经过上面1），2），3）点的做法，则可以保证数据百分百到达对方，当然，标识符用 ID 号来代替更好。

3、解决方案 - 冗余传输方案：

在外网通信链路不稳定的情况下，有什么办法可以降低UDP的丢包率呢？

一个简单的办法来采用冗余传输的方式。

如下图，一般采用较多的是延时双发，双发指的是将原本单发的前后连续的两个包合并成一个大包发送，这样发送的数据量是原来的两倍。

这种方式提高丢包率的原理比较简单，例如本例的冗余发包方式，在偶数包全丢的情况下，依然能够还原出完整的数据，也就是在这种情况下，50%的丢包率，依然能够达到100%的数据接收。

4、解决方案 - RUDP：

UDP 实现可靠性既然那么麻烦，那直接用 TCP 好了！确实很多人也都是这样做的，TCP 是个基于公平性的可靠通信协议，但是在一些苛刻的网络条件下 TCP 要么不能提供正常的通信质量保证，要么成本过高。为什么要在 UDP 之上做可靠保证，究其原因就是在保证通信的时延和质量的条件下尽量降低成本。RUDP 主要解决以下相关问题：

• 端对端连通性问题：一般终端直接和终端通信都会涉及到 NAT 穿越，TCP 在 NAT 穿越实现非常困难，相对来说 UDP 穿越 NAT 却简单很多，如果是端到端的可靠通信一般用 RUDP 方式来解决，场景有：端到端的文件传输、实时音视频传输、交互指令传输等等。【UDP NAT穿越简单很多】

• 弱网环境传输问题：在一些 Wi-Fi 或者 3G/4G 移动网下，需要做低延迟可靠通信，如果用 TCP 通信延迟可能会非常大，这会影响用户体验。例如：实时的操作类网游通信、语音对话、多方白板书写等，这些场景可以采用特殊的 RUDP 方式来解决这类问题；【弱网传输UDP延长会低很多】

• 带宽竞争问题：有时候客户端数据上传需要突破本身 TCP 公平性的限制来达到高速低延时和稳定，也就是说要用特殊的流控算法来压榨客户端上传带宽，例如：直播音视频推流，这类场景用 RUDP 来实现不仅能压榨带宽，也能更好地增加通信的稳定性，避免类似 TCP 的频繁断开重连；

• 传输路径优化问题：在一些对延时要求很高的场景下，会用应用层 relay 的方式来做传输路由优化，也就是动态智能选路，这时双方采用 RUDP 方式来传输，中间的延迟进行 relay 选路优化延时。还有一类基于传输吞吐量的场景，例如：服务与服务之间数据分发、数据备份等，这类场景一般会采用多点并联 relay 来提高传输的速度，也是要建立在 RUDP 上的（这两点在后面着重来描述）；

• 资源优化问题：某些场景为了避免 TCP 的三次握手和四次挥手的过程，会采用 RUDP 来优化资源的占用率和响应时间，提高系统的并发能力，例如 QUIC。