详解UDP协议

　　运输层位于网络层之上，网络层提供了主机之间的逻辑通信；而运输层为运行在不同主机上的应用进程之间提供了逻辑通信。从应用程序角度看，通过逻辑通信，运行不同进程的主机好像直接相连一样。应用进程使用运输层提供的逻辑通信功能来发送报文，无需考虑承载这些报文的物理基础设施的细节，就像我们知道的透明传输。

　　UDP是传输层协议的一种，也叫做用户数据报协议，提供一种不可靠、无连接的服务。当我发送的UDP包到达目标机器后，目标机器发现 MAC 地址匹配，于是就取下来，将剩下的包传给处理 IP 层的代码。把 IP 头取下来，发现目标 IP 匹配，然后这里面的数据包发给谁呢？我们自己知道发送的是UDP包，那么目标机器怎么知道的呢？因为IP数据报里面有个字段是上层协议，说明了上层协议是TCP还是UDP ，所以目的主机根据这个信息知道了这个包是UDP包。

　　UDP的报文段结构非常简单，首部有4个字段组成，每个字段占用两个字节。端口号用来区分各个应用程序，每个应用程序需要监听一个端口，不能冲突。目标机器根据目的端口号晶数据交给相应的应用程序。长度字段的意思是UDP首部加上应用数据的总长度。校验和主要是接收方检查在该报文段是否出现了差错。应用数据就是应用层包了。

                           

　UDP协议具有三大特点，通过上面对报文段结构的分析，也能猜到一两个。

• 沟通简单，UDP协议默认包在网络中很容易送达，不容易丢弃。所以它没有设置复杂的字段结构、处理逻辑等。
• 传输便捷，传输时不会建立连接，谁都可以传给它数据，它也可以给任何人传数据，支持同时给多人传数据。
• 不做调整，这里的意思是UDP不会根据网络的情况进行发包的拥塞控制，不论网络丢包程度，它都正常发送。

　基于这些特点，UDP主要有三大使用场景。

• 需要资源少，在网络情况比较好的内网，或者对于丢包不敏感的应用。比如DHCP就是基于UDP协议的，一般的获取 IP 地址都是内网请求，而且一次获取不到IP可以过会再获取。
• 不需要一对一沟通建立连接，而是可以广播的应用。由于无连接特性，可以承载很多广播和多播协议。比如上面说的DHCP就是通过广播的方式来发包。对于多播，主要是D类IP地址即组播地址，使用这个地址可以将包组播给一批机器。当一台机器上的某个进程想监听某个组播地址的时候，需要发送 IGMP 包，所在网络的路由器就能收到这个包，知道有个机器上有个进程在监听这个组播地址。当路由器收到这个组播地址的时候，会将包转发给这台机器，这样就实现了跨路由器的组播。
• 需要处理速度快，时延低，可以容忍少数丢包，但是要求即便网络拥塞，也继续发包的情况。

所以，如果开发人员选择UDP协议开发应用程序，那应用程序差不多就是直接和IP层打交道。UDP从应用进程得到数据，附加上首部字段形成报文段交给网络层。网络层将该运输层报文段封装到一个IP数据报中，然偶尽最大努力交给目的主机。如果目的主机收到该数据报，UDP使用目的端口号将报文段中的数据交付给正确的应用进程。

　　由于UDP 十分简单，基本啥都没做，如果应用是基于UDP开发的，那么就可以有很多自主扩展的东西。我们通过具体的例子说明：

1. 网页或者 APP 的访问，原来访问网页和手机 APP 都是基于 HTTP 协议的。HTTP 协议是基于 TCP 的，建立连接需要多次交互，建立一次连接需要的时间会比较长，TCP 可能还会断了重连，也是很耗时的。而Google 提出了一种基于 UDP 改进的通信协议QUIC（Quick UDP Internet Connections，快速 UDP 互联网连接），其目的是降低网络通信的延迟，提供更好的用户互动体验。QUIC 在应用层上，会自己实现快速连接建立、减少重传时延，自适应拥塞控制。

2. 流媒体的协议，现在直播比较火，直播协议多使用 RTMP。RTMP 协议也是基于 TCP 的。TCP 的严格顺序传输要保证前一个收到了，下一个才能确认，如果前一个收不到，下一个就算包已经收到了，在缓存里面，也需要等着。直播对实时性要求高，宁可丢包，也不能卡顿。关于丢包。其实对于视频播放来讲，有的包可以丢，有的包不能丢。因为视频的连续帧里面，有的帧重要，有的不重要，如果必须要丢包，隔几个帧丢一个，其实看视频的人不会感知，但是如果连续丢帧，就会感知了，因而在网络不好的情况下，应用希望选择性的丢帧。

   还有当网络不好的时候，TCP 协议会主动降低发送速度，这对本来当时就卡顿的视频来讲是要命的，应该让应用层马上重传，而不是主动让步。因而，很多直播应用，都基于 UDP 实现了自己的视频传输协议。

3. 实时游戏，实时游戏中客户端和服务端要建立长连接，来保证实时传输。但是游戏玩家很多，服务器却不多。由于维护 TCP 连接需要在内核维护一些数据结构，因而一台机器能够支撑的 TCP 连接数目是有限的。 UDP 由于是没有连接的，在异步 IO 机制引入之前，常常是应对海量客户端连接的策略。

   如果使用TCP协议，它的强顺序性会带来一些问题。对战的游戏，对网络的要求很简单，玩家通过客户端给服务器发送鼠标和键盘行走的位置，服务器会处理每个用户发送过来的所有场景，处理完再返回给客户端，客户端解析响应，渲染最新的场景展示给玩家。如果出现一个数据包丢失，所有事情都需要停下来等待这个数据包重发。客户端会出现接收数据，然而玩家并不关心过期的数据，激战中卡 1 秒，等能动了已经死了。

   游戏对实时要求较为严格的情况下，采用自定义的可靠 UDP 协议，自定义重传策略，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成的影响。

4. IoT 物联网，一方面，物联网领域终端资源少，很可能只是个内存非常小的嵌入式系统，而维护 TCP 协议代价太大；另一方面，物联网对实时性要求也很高，而 TCP 还是因为上面的那些原因导致时延大。Google 旗下的Nest 建立 Thread Group，推出了物联网通信协议 Thread，就是基于 UDP 协议的。
5. 移动通信领域，在 4G 网络里，移动流量上网的数据面对的协议 GTP-U 是基于 UDP 的。因为移动网络协议比较复杂，而 GTP 协议本身就包含复杂的手机上线下线的通信协议。如果基于 TCP，TCP 的机制就显得非常多余。

　　推荐阅读：《趣谈网络协议》刘超

　　　　　　　《计算机网络：自顶向下方法》原书第六版 陈鸣译