UDP介绍：
用户数据报协议，属于传输层的协议，无连接，不保证传输的可靠性。对于来自应用层的数据包，直接加上UDP报头然后传送给IP。UDP头部中有一个校验和字段，可用于差错的检测，但是UDP是不提供差错纠正的。此外IPV4不强制这个校验和字段必须使用，但IPV6是强制要求使用的。
UDP报头：
其中，
①源端口号如果不需要可以置0；
②长度字段是UDP首部和UDP数据的总长度，这个字段是冗余的，因为IP中包含了数据报长度信息；
③校验和字段是端到端的，它覆盖了UDP头部、UDP数据、一个伪头部、填充字节，由初始的发送方计算得到，由最终的目的方计算然后校验。
UDP的优势：
①开销更小
TCP为了保证其可靠性，首部包含20字节，以及40字节的可选项，UDP首部只有8字节
②速度更快
UDP发送数据之前没有TCP的连接建立过程；
TCP提供了过多的保护，在及时性上做了很多的妥协，比如：控制微包（Nagle算法），延时ACK，流量控制，超时重传等，这些设计严重影响了Tcp的速度和及时性
UDP传输过程中存在的主要问题：
①丢失和乱序：因为UDP不提供ACK、序列号等机制，所以是没有办法知道是否有报文丢失以及接收方到达等报文顺序是否和发送方发送的报文数据一样；
②差错：对于差错问题则是可以通过校验和等检测到，但是不提供差错纠正；
③数据完整性，UDP协议头部虽然有16位的校验和，但是IPv4并不强制执行，也就是说UDP无法抱枕数据的完整性
UDP如何解决其传输过程中的问题：
想要保证数据的可靠投递和正确排序，必须由应用程序自己实现这些保护功能
简单思路，既然原生
UDP
有那么多痛点，那我能不能像应用层协议一样在
UDP
数据包头再加一段包头，从而定义为
RUDP
呢，答案是肯定的。首先思考
RUDP
需要解决哪些问题，然后根据问题加上必要的包头字段。
1.
数据完整性
–>
加上一个
16
或者
32
位的
CRC
验证字段
2.
乱序
–>
加上一个数据包序列号
SEQ
3.
丢包
–>
需要确认和重传机制，就是和
Tcp
类似的
Ack
机制（若中间包丢失可以通过序列号累计而检测到，但是一开始的包就丢失是没有办法通过序列号检测到的）
在思考一下既然是自定义协议是不是需要一个协议号字段来过滤一些非法包，那么又可以加入一个新字段：
4.
协议字段
–> protol
字段，标识当前使用协议
综合以上字段，我们的
RUDP
就可以简单实现成如下：
RUDP（Reliable UDP）：
RUDP，可靠UDP，实现了UDP的一些可靠性
UDP最大数据报长度：
有两个原因使得大小满额的数据报不能被端到端投递：
一是系统的本地协议实现可能有一些限制；二是接收应用程序可能没准备好去接收这么大的数据
UDP数据报截断：
当UDP数据报长度超过接收端允许长度时，会发生数据报截断，之后会有几种处理：丢弃超过应用程序可接收字节的部分；将这些超出的数据存到后续的读操作；通知调用者被截断了多少数据；或者只通知被截断，但不通知具体截断数量
TCP中不存在数据报截断