可靠UDP设计

最近加入了一个用帧同步的项目，帧同步方案对网络有着极大的影响，因而采用了RUDP（可靠UDP），那么为何要摒弃TCP，而费尽心思去采用UDP呢？要搞明白这个问题，首先要了解TCP和UDP的区别 ， 明白TCP没法避免的痛点。

TCP VS UDP

1.Tcp 面向链接，提供可靠的传输； UDP面向无链接，提供不可靠传输

2. Tcp 提供流量控制 ； UDP不提供流量控制

3. Tcp 保证传输数据顺序 ； UDP不保证传输顺序，也就是多是乱序收包

4. TCP 面向字节流 ； UDP 面向数据包

……

简单说TCP保证了传输的准确性和相应的流量控制，而UDP不提供任何准确性保证。既然TCP提供这么多完备的方案，为何还要大费周章地去设计RUDP呢，这里主要愿意能够用两个字归纳“速度”，TCP提供了过多的保护，在及时性上作了不少的妥协，好比：控制微包（Nagle算法），延时ACK，流量控制，超时重传等，这些设计严重影响了Tcp的速度和及时性。更多的信息参考连接：http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

帧同步中的UDP

帧同步方案中逻辑帧通常都在8~16帧左右，通常都在12帧以上，这要的网络传输频率决定了不可能采用TCP协议，那么若是采用UDP会出现什么问题呢？

1. 丢包，帧同步中逻辑帧在每一个Client上必定是一致的，也就是说决定不能出现丢帧的状况，

2. 数据完整性，UDP协议头部虽然有16位的校验和，可是IPv4并不强制执行，也就是说UDP没法抱枕数据的完整性

3. 乱序。 UDP并不保证数据的顺序，故可能出现数据包乱序问题

以上问题任何一项都会致使Client在逻辑帧上出现不一样步问题，为了解决这个问题就必须引入RUDP概念，这里的RUDP主要是解决上述的问题，并不某个RFC定义的规范。

RUDP初步

简单思路，既然原生UDP有那么多痛点，那我能不能像应用层协议同样在UDP数据包头再加一段包头，从而定义为RUDP呢，答案是确定的。首先思考RUDP须要解决哪些问题，而后根据问题加上必要的包头字段。

1. 数据完整性 –> 加上一个16或者32位的CRC验证字段

2. 乱序 –> 加上一个数据包序列号SEQ

3. 丢包 –> 须要确认和重传机制，就是和Tcp相似的Ack机制

在思考一下既然是自定义协议是否是须要一个协议号字段来过滤一些非法包，那么又能够加入一个新字段：

4. 协议字段 –> protol 字段，标识当前使用协议

综合以上字段，咱们的RUDP就能够简单实现成以下：

根据初步获得的协议头，就能够尝试去实现协议啦，后面会开始一步一步实现整个RUDP逻辑。