标签：可靠传输 头部 频率 乱序 思考 height display work 了解
最近加入了一个用帧同步的项目，帧同步方案对网络有着极大的影响，于是采用了RUDP（可靠UDP），那么为什么要摒弃TCP，而费尽心思去采用UDP呢？要搞明白这个问题，首先要了解TCP和UDP的区别 ， 明白TCP无法避免的痛点。
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/
帧同步方案中逻辑帧一般都在8~16帧左右，一般都在12帧以上，这要的网络传输频率决定了不可能采用TCP协议，那么如果采用UDP会出现什么问题呢？
1. 丢包，帧同步中逻辑帧在每个Client上一定是一致的，也就是说决定不能出现丢帧的情况，
2. 数据完整性，UDP协议头部虽然有16位的校验和，但是IPv4并不强制执行，也就是说UDP无法抱枕数据的完整性
3. 乱序。 UDP并不保证数据的顺序，故可能出现数据包乱序问题
以上问题任何一项都会导致Client在逻辑帧上出现不同步问题，为了解决这个问题就必须引入RUDP概念，这里的RUDP主要是解决上述的问题，并不某个RFC定义的规范。
简单思路，既然原生UDP有那么多痛点，那我能不能像应用层协议一样在UDP数据包头再加一段包头，从而定义为RUDP呢，答案是肯定的。首先思考RUDP需要解决哪些问题，然后根据问题加上必要的包头字段。
1. 数据完整性 –> 加上一个16或者32位的CRC验证字段
2. 乱序 –> 加上一个数据包序列号SEQ
3. 丢包 –> 需要确认和重传机制，就是和Tcp类似的Ack机制
在思考一下既然是自定义协议是不是需要一个协议号字段来过滤一些非法包，那么又可以加入一个新字段：
4. 协议字段 –> protol 字段，标识当前使用协议
综合以上字段，我们的RUDP就可以简单实现成如下：
根据初步得到的协议头，就可以尝试去实现协议啦，后面会开始一步一步实现整个RUDP逻辑。
标签：可靠传输 头部 频率 乱序 思考 height display work 了解
原文地址：http://www.cnblogs.com/lixiang-share/p/7152870.html
