我们知道，TCP是面向连接的，UDP是面向无连接的。
面向连接的协议会先建立连接，所谓建立连接，是为了在客户端和服务端维护连接，而建立一定的数据结构来维护双方交互的状态，用这样的数据结构来保证所谓的面向连接的特性。
UDP包头：
当我们发送的UDP包到达目标机器后，发现MAC地址匹配，也是取下来，将剩下的包交给IP层处理，IP层将IP头取下来，发现目标IP匹配，而且在IP头中有一个8位的协议，这里会存放，数据里面到底是UDP还是TCP，然后到传输层，这里是UDP包，将UDP包头取下来，如果指定UDP头的格式，那么就能将里面的数据解析出来，这个时候传输层的事情处理完后，内核的事情就基本做完了，那里面的数据应该发给谁呢？
无论应用程序写的使用TCP传数据还是UDP传数据，都要监听一个端口号，正是这个端口号来区分应用程序，所以端口号不能冲突。
然后根据端口号，将数据交给应用程序，也就是到了应用层
我们可以看到，在UDP包头中，有源端口号，目的端口号
UDP的三大特点：
- 它相信网络世界是美好的，相信网络桐庐默认就是很容易送达的，不容易被丢弃的。
- 它不会建立连接，虽然有端口号，但是监听在这个地方，谁都可以传给它数据，它也可以传给任何人数据，甚至可以同时传给多个人数据。
- 它不会根据网络的情况进行发包的拥塞控制，无论网络包丢包丢成什么样了，它该怎么发就怎么发。
UDP的三大使用场景
- 需要资源少，在网络情况比较好的内网，或者对于丢包不敏感的应用。DHCP就是基于UDP协议的。
- 不需要一对一沟通，建立连接，而是可以广播的应用。UDP的不面向连接的功能，可以使得可以承载广播或者多播的协议，DHCP就是一个广播的形式。
- 需要处理速度快，时延低，可以容忍少数丢包，但是要求即便网络拥塞，也毫不退缩，一往无前的时候。
UDP简单，处理速度快，不像TCP那么，操那么多心，各种重传，保证顺序，网络不好的时候，拥塞控制策略会主动的退缩，降低发送的速度，这就相当于本来环境就差还更降低，导致用户更卡。
所以如果能在应用层实现自己的连接策略，可靠保证，时延要求，那么使用UDP是挺好的。
基于UDP的5个例子
网页或者APP的访问
原来访问网页和手机APP就是基于HTTP协议的。HTTP协议是基于TCP的，建立连接都需要多次交互，对于延时比较大的目前主流的移动互联网来说，建立一次连接需要的世界会比较长，而且目前的HTTP协议，往往采取多个数据通道共享一个连接的情况，这样本来为了加快传输速度，但是TCP的严格顺序策略使得共享通道的延时也会加大。
QUIC是google提出的一种基于UDP改进的通信协议，其目的是降低网络通信的延迟，提供更好的用户互动体验。
QUIC在应用层上，会自己实现快速连接建立，减少重传时延，自适应拥塞控制。流媒体协议：
现在直播很火，直播协议多使用RTMP，这个协议也是基于TCP的，但是由于TCP的严格顺序传输，对于直播来讲，是不合适的，另外，对于丢包，对于视频播放来讲，有的包可以丢，有的包不能丢，因为在视频的连续帧里面，有的帧重要，有的帧不重要，如果必须要丢包，隔几个帧丢一个，对于用户来说是不会感知的，因为在网络不好的情况下，应用希望选择性的丢帧。
所以现在的很多直播应用，都基于UDP实现了自己的视频传输协议。实时游戏：
游戏有一个特点，就是实时性比较高，实时游戏中客户端和服务器要建立长连接，来保证实时传输，但是游戏玩家很多，服务器不多，维护TCP需要在内核维护一些数据结构，因而一台机器能够支撑的TCP连接数目有限，但是UCP是没有连接的，在异步IO机制引入之前，常常是应对海量客户端连接的策略。
游戏对实时要求比较严格，采用自定义的可靠的UDP协议，自定义重传策略，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成的影响。
物联网：
一方面，物联网领域终端资源很少，很可能只是个内存非常小的嵌入式系统，而维护TCP协议代价太大；另一方面，物联网对实时性要求也高。
Google旗下的Next建立ThreadGroup，推出了物联网通信协议Thread，就是基础UDP的。移动通信领域
在4G网络中，移动流量上网的数据面对的协议GTP-U是基于UDP的。因为移动网络协议比较复杂，而GTP协议本身就包含负责的手机上线下线的通信协议。如果基于TCP，TCP的机制就显得非常多余。
本文来源：
