网络协议趣谈UDP协议

Posted 2021-08-30 sysu_lluozh

对于非底层开发或者应用层开发来讲，最常用的就是UDP和TCP协议。这两个协议经常会被放在一起问，接下来两个协议结合学习

一、TCP和UDP有哪些区别

1.1 TCP面向连接

一般问两个协议的区别时，大部分人会回答，TCP是面向连接的，UDP是面向无连接的

什么叫面向连接，什么叫无连接呢？
在互通之前，面向连接的协议会先建立连接。例如，TCP会三次握手，而UDP不会。那为什么要建立连接呢？TCP三次握手，UDP也可以发三个包玩玩，有什么区别吗？

所谓的建立连接，是为了在客户端和服务端维护连接，而建立一定的数据结构来维护双方交互的状态，用这样的数据结构来保证所谓的面向连接的特性

1.2 TCP可靠交付

例如，TCP提供可靠交付。通过TCP连接传输的数据，无差错、不丢失、不重复、并且按序到达
IP包是没有任何可靠性保证的，一旦发出去，就像西天取经，走丢了或者被妖怪吃了都只能随它去。但是TCP号称能做到那个连接维护的程序做的事情，而UDP继承了IP包的特性，不保证不丢失，不保证按顺序到达

1.3 TCP面向字节流

再如，TCP是面向字节流的。发送的时候发的是一个流，没头没尾。IP包可不是一个流，而是
一个个的IP包
之所以变成了流，这也是TCP自己的状态维护做的事情。而UDP继承了IP的特性，基于数据报的，一个一个地发，一个一个地收

1.4 TCP可拥塞控制

还有TCP是可以有拥塞控制的。它意识到包丢弃了或者网络的环境不好时，就会根据情况调整自己的行为，看看是不是发快了，要不要发慢点
UDP就不会，应用让我发，我就发，管它洪水滔天

1.5 TCP是有状态的服务

因而TCP其实是一个有状态服务，里面精确地记着发送了没有，接收到没有，发送到哪个了，应该接收哪个了，错一点儿都不行。而UDP则是无状态服务，发出去就发出去了

可以这样比喻，如果MAC层定义了本地局域网的传输行为，IP层定义了整个网络端到端的传输行为，这两层基本定义了这样的基因：网络传输是以包为单位的，二层叫帧，网络层叫包，传输层叫段，笼统地称为包。包单独传输，自行选路，在不同的设备封装解封装，不保证到达

二、UDP包头是什么样的

当发送的UDP包到达目标机器后，发现MAC地址匹配，于是就取下来将剩下的包传给处理IP层的代码。把IP头取下来，发现目标IP匹配，接下来呢？这里面的数据包是给谁呢？

发送的时候，知道自己发的是一个UDP的包，收到的那台机器咋知道的呢？所以在IP头里面有 个8位协议，这里会存放数据里面到底是TCP还是UDP，当然这里是UDP
于是，如果知道UDP头的格式，就能从数据里面将它解析出来。解析出来以后呢？数据给谁处理呢？

处理完传输层的事情，内核的事情基本就干完了，里面的数据应该交给应用程序自己去处理，可是一台机器上跑着这么多的应用程序，应该给谁呢？

无论应用程序写的使用TCP传数据，还是UDP传数据，都要监听一个端口。正是这个端口用来区分应用程序，要不说端口不能冲突呢。两个应用监听一个端口，到时候包给谁呀？所以，按理说，无论是TCP还是UDP包头里面应该有端口号，根据端口号，将数据交给相应的应用程序

当我们看到UDP包头的时候，发现的确有端口号，有源端口号和目标端口号。因为是两端通信，不难发现UDP除了端口号，再没有其他的了。和下两节要讲的TCP头比起来，这个简直简单得一塌糊涂啊！

三、UDP的三大特点

UDP就像小孩子一样，有以下这些特点：

3.1 沟通简单

不需要一肚子花花肠子(大量的数据结构、处理逻辑、包头字段)。前提是它相信网络世界是美好的，秉承性善论，相信网络通路默认就是很容易送达的，不容易被丢弃

3.2 轻信他人

不会建立连接，虽然有端口号，但是监听在这个地方，谁都可以传给他数据，他也可以传给任何人数据，甚至可以同时传给多个人数据

3.3 愣头青

做事不懂权变。不知道什么时候该坚持，什么时候该退让。它不会根据网络的情况进行发包的拥塞控制，无论网络丢包丢成啥样了，它该怎么发还怎么发

四、UDP的三大使用场景

UDP在以下的场景中使用

4.1 需要资源少/网络情况好/丢包不敏感

第一，需要资源少，在网络情况比较好的内网，或者对于丢包不敏感的应用
这很好理解， 就像领导会让刚毕业的小朋友去做一些没有那么难的项目，打一些没有那么难的客户，或者做一些失败了也能忍受的实验性项目

• DHCP协议基于UDP协议
  一般的获取IP地址都是内网请求，而且一次获取不到IP又没事，过一会儿还有机会
• PXE基于UDP协议
  PXE可以在启动的时候自动安装操作系统，操作系统镜像的下载使用的TFTP，在还没有操作系统的时候，客户端拥有的资源很少，不适合维护一个复杂的状态机，而且因为是内网一般也没啥问题

4.2 非一对一的广播应用

第二，不需要一对一沟通，建立连接，而是可以广播的应用
小时候人都很简单，大家在班级里面谁成绩好，谁写作好，应该表扬谁惩罚谁，谁得几个小红花都是当着全班的面讲的，公平公正公开。长大了人心复杂了，薪水、奖金要背靠背，和员工一对一沟通

UDP的不面向连接的功能，可以使得可以承载广播或者多播的协议。DHCP就是一种广播的形 式，所以基于UDP协议

对于多播，IP地址中有一个D类地址，也即组播地址，使用这个地址可以将包组播给一批机器。当一台机器上的某个进程想监听某个组播地址的时候，需要发送IGMP包，所在网络的路由器就能收到这个包，知道有个机器上有个进程在监听这个组播地址。当路由器收到这个组播地址的时候会将包转发给这台机器，这样就实现了跨路由器的组播

4.3 需求处理速度快/时延低

第三，需要处理速度快，时延低，可以容忍少数丢包，但是要求即便网络拥塞也毫不退缩，一往无前的时候
曾国藩建立湘军专门招出生牛犊不怕虎的新兵，而不用那些老油条的八旗兵，就是因为八旗兵经历的事情多，遇到敌军不敢舍死忘生

4.3.1 TCP重传导致效率低

同理，UDP简单、处理速度快，不像TCP那样操这么多的心，各种重传，保证顺序，前面的不收到，后面的没法处理。不然等这些事情做完时延早就上去了，而TCP在网络不好出现丢包的时候，拥塞控制策略会主动的退缩导致降低发送速度，这就相当于本来环境就差还自断臂膀，用户本来就卡，这下更卡了

4.3.2 应用根据实际实现可靠和连接保证

当前很多应用都是要求低时延，它们可不想用TCP如此复杂的机制，而是想根据自己的场景实现自己的可靠和连接保证
例如：

• 如果应用自己觉得有的包丢了就丢了，没必要重传就可以算了，有的比较重要则应用自己重传，而不依赖于TCP
• 如果有的前面的包没到，后面的包到了，那就先给客户展示后面的数据包，干嘛非得等到齐了呢？
• 如果网络不好丢了包，不能退缩且要尽快传，速度不能降下来，要挤占带宽，抢在客户失去耐心之前到达

4.3.3 UDP让应用有城会玩的机会

由于UDP十分简单，基本啥都没做，也就给了应用城会玩的机会。就像在和平年代，每个人应该有独立的思考和行为，应该可靠并且礼让，但是如果在战争年代，往往不太需要过于独立的思考，而需要士兵简单服从命令即可

曾国藩说哪支部队需要诱敌牺牲，也就牺牲了，相当于包丢了就丢了。两军狭路相逢的时候，曾国藩说上，没有带宽也要上，这才给了曾国藩运筹帷幄城会玩的机会。同理如果实现的应用需要有自己的连接策略，可靠保证，时延要求，使用UDP，然后再应用层可以自主实现这些

五、基于UDP城会玩的例子

5.1 城会玩一：网页或者APP的访问

5.1.1 网页基于TCP存在的问题

原来访问网页和手机APP都是基于HTTP协议，而HTTP协议是基于TCP，建立连接都需要多次交互，对于时延比较大的目前主流的移动互联网来讲，建立一次连接需要的时间会比较长，然而既然是移动中，TCP可能还会断了重连，也是很耗时的。而且目前的HTTP协议，往往采取多个数据通道共享一个连接的情况，这样本来为了加快传输速度，但是TCP的严格顺序策略使得哪怕共享通道，前一个不来，后一个和前一个即便没关系也要等着，时延也会加大

5.1.2 基于UDP的QUIC

QUIC(全称Quick UDP Internet Connections，快速UDP互联网连接)是Google提出的一种基于UDP改进的通信协议，其目的是降低网络通信的延迟，提供更好的用户互动体验

QUIC在应用层上，自己实现快速连接建立、减少重传时延，自适应拥塞控制，是应用层城会玩的代表

5.2 城会玩二：流媒体的协议

5.2.1 直播RTMP基于TCP存在的问题

现在直播比较火，直播协议多使用RTMP，而这个RTMP协议也是基于TCP的。TCP的严格顺序传输要保证前一个收到了，下一个才能确认，如果前一个收不到，下一个就算包已经收到了在缓存里面，也需要等着
对于直播来讲这显然是不合适的，因为老的视频帧丢了其实也就丢了，就算再传过来用户也不在意了，他们要看新的画面，如果老是没来就等着，卡顿了新的也看不了，那就会丢失客户，所以直播的实时性比较比较重要，宁可丢包也不要卡顿

5.2.2 应用基于UDP实现视频传输协议

另外，对于丢包，其实对于视频播放来讲，有的包可以丢，有的包不能丢，因为视频的连续帧里面，有的帧重要，有的不重要，如果必须要丢包，隔几个帧丢一个其实看视频的人不会感知，但是如果连续丢帧就会感知，因而在网络不好的情况下，应用希望选择性的丢帧

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

5.3 城会玩三：实时游戏

5.3.1 实时游戏基于TCP存在的问题

游戏有一个特点，就是实时性比较高。快一秒你干掉别人，慢一秒你被别人爆头，所以很多职业玩家会买非常专业的鼠标和键盘，争分夺秒

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

另外还是TCP的强顺序问题，对战的游戏对网络的要求很简单，玩家通过客户端发送给服务器鼠标和键盘行走的位置，服务器会处理每个用户发送过来的所有场景，处理完再返回给客户端，客户端解析响应渲染最新的场景展示给玩家

如果出现一个数据包丢失，所有事情都需要停下来等待这个数据包重发。客户端会出现等待
接收数据，然而玩家并不关心过期的数据，激战中卡1秒，等能动了都已经死了

5.3.2 应用基于UDP自定义传输策略

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

5.4 城会玩四：IoT物联网

5.4.1 IoT物联网存在的问题

• 一方面，物联网领域终端资源少，很可能只是个内存非常小的嵌入式系统，而维护TCP协议 代价太大
• 另一方面，物联网对实时性要求也很高，而TCP还是因为上面的那些原因导致时 延大

5.4.2 基于UDP协议的Nest

Google旗下的Nest建立Thread Group，推出了物联网通信协议Thread，就是基于UDP协议

5.5 城会玩五：移动通信领域

5.5.1 移动网络基于TCP存在的问题

移动网络协议比较复杂，而GTP协议本身就包含复杂的手机上线下线的通信协议。如果基于TCP，TCP的机制就显得非常多余

5.5.2 基于UDP的GTP-U

在4G网络里，移动流量上网的数据面对的协议GTP-U是基于UDP

六、小结

针对以上内容小结一下：

• 如果将TCP比作成熟的社会人，UDP则是头脑简单的小朋友
  TCP复杂，UDP简单
  TCP维护连接，UDP谁都相信
  TCP会坚持知进退；UDP愣头青一个勇往直前

• UDP虽然简单，但它有简单的用法
  可以用在环境简单/需要多播、应用层自己控制传输的地方。例如DHCP、VXLAN、QUIC等