udp协议¶
UDP协议只在IP的数据报服务之上增加了很少的功能，就是复用和分用的功能以及差错检测的功能
IP 包的最大长度为 65535 字节
一般来说 IP 头部为 20 字节，UDP 头部为 8 字节
因此 UDP 的最大数据长度为 65507 字节
这么长的数据已经 超过了以太网和通信线路的最大传输长度
因此需要让 IP 模块使用分片 功能拆分之后再传输
因为: MTU不允许超过 1500 个字节
UDP 头部中的控制信息:
1. 发送方端口号 16
网络包发送方的端口号
2. 接收方端口号 16
网络包接收方的端口号
3. 数据长度 16
UDP 头部后面数据的长度
4. 校验和 16
用于校验错误
UDP的主要特点是:
UDP是无连接的
UDP使用尽最大努力交付,即不保证可靠交付
UDP是面向报文
在计算检验和时，要在UDP用户数据报之前增加12个字节的伪首部。“伪首部”并不是用户数据报真正的首部，只是在计算检验和时，临时添加在UDP数据报前面，得到一个临时UDP数据报。伪首部既不向下传送也不向上递交，仅仅是为了计算检验和
典型应用:
域名系统（DNS）
简单网络管理协议（SNMP）
动态主机配置协议（DHCP）
路由信息协议（RIP）
VXLAN、
QUIC
某些影音流服务
适合场景:
1. 音频和视频
数据中缺少了某些包并不会产生严重的问题
2. 数据很短，用一个包就能装得下
如: DNS 查询
如果只有一个包，重发也只不过是重发一个包而已，这情况下就不需要 TCP 这样复杂的机制
发送数据，对方一般都会回复，只要将回复的数据当接收确认就行，不需要专门的接收确认包
说明:
需要简单的请求-响应通信，而较少考虑流量控制和差错控制。
对于需要传送成块数据的进程（如FTP）则不适合使用UDP
UDP适合于具有内部流量控制和差错控制机制的进程，如简单文件传输协议TFTP。
对多播来说，UDP是一个合适的传输协议。
UDP常用于交互实时应用，以避免接收报文之间的不一致延时。
UDP可用于管理进程，如SNMP
备注
udp 应该一个包是一个，每个都是完整的，不用排序。如果非得要排，就需要应用层自己来排序了
场景:
1. http3, QUIC, QQ自定义协议
2. 流媒体的协议(注意: RTMP是基于TCP的)
3. 实时游戏
游戏对实时要求较为严格的情况下，采用自定义的可靠 UDP 协议，
自定义重传策略，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成的影响。
4. IoT物联网
一方面，物联网领域终端资源少，很可能只是个内存非常小的嵌入式系统，而维护 TCP 协议代价太大；
另一方面，物联网对实时性要求也很高，而 TCP 还是因为上面的那些原因导致时延大
实例: Google 旗下的 Nest 建立 Thread Group，推出了物联网通信协议 Thread
5. 移动通信领域
在 4G 网络里，移动流量上网的数据面对的协议 GTP-U 是基于 UDP 的
移动网络协议比较复杂，而 GTP 协议本身就包含复杂的手机上线下线的通信协议。
如果基于 TCP，TCP 的机制就显得非常多余
基于 UDP 实现可靠传输¶
UDT:
UDX:
VTCP: http://www.vtcp123.com/
KCP:
QUIC: