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数据报。伪首部既不向下传送也不向上递交，仅仅是为了计算检验和

.. figure:: https://img.zhaoweiguo.com/knowledge/images/protocols/udp_protocol1.png
   :width: 80%



.. figure:: https://img.zhaoweiguo.com/knowledge/images/protocols/udp_protocol2.png
   :width: 80%


典型应用::

  域名系统（DNS）
  简单网络管理协议（SNMP）
  动态主机配置协议（DHCP）
  路由信息协议（RIP）
  VXLAN、
  QUIC
  某些影音流服务

适合场景::

    1. 音频和视频
      数据中缺少了某些包并不会产生严重的问题

    2. 数据很短，用一个包就能装得下
      如: DNS 查询
      如果只有一个包，重发也只不过是重发一个包而已，这情况下就不需要 TCP 这样复杂的机制
      发送数据，对方一般都会回复，只要将回复的数据当接收确认就行，不需要专门的接收确认包

    说明:
    需要简单的请求-响应通信，而较少考虑流量控制和差错控制。
    对于需要传送成块数据的进程（如FTP）则不适合使用UDP
    UDP适合于具有内部流量控制和差错控制机制的进程，如简单文件传输协议TFTP。
    对多播来说，UDP是一个合适的传输协议。
    UDP常用于交互实时应用，以避免接收报文之间的不一致延时。
    UDP可用于管理进程，如SNMP

.. note:: 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/

* UTP: http://www.bittorrent.org/beps/bep_0029.html
* KCP: 
* QUIC: