文章讲述了UDP包头的工作原理，强调了UDP的简单、快速特性，以及在资源有限、实时性和低延迟场景下的优势，如直播、游戏和HTTP协议的优化。同时提到了大厂面试中的相关技术点，如QUIC和UDP在游戏中的应用。
====================================================================
当我发送的UDP包到达目标机器后，发现MAC地址匹配，于是取下，将剩下的包传给处理IP层的代码。
把IP头取下来，发现目标IP匹配，接下来这里面的数据包给谁呢？
发送时，我知道我发的是一个UDP包，收到的那台机器咋知道的？
所以在IP头里面有个8位协议，存放数据里面到底是TCP or UDP，当然这里是UDP。
于是如果知道UDP头的格式，就能从数据里将它解析。
解析出来后的数据给谁处理呢？
处理完传输层，内核工作就结束了，里面的数据应该交给应用程序处理。
一台机器上那么多应用程序，给谁呢？
无论应用程序写的使用TCP还是UDP传数据，都要监听一个端口。
端口用来区分应用程序。两个应用监听一个端口，到时候包给谁？
所以无论是TCP、UDP包头里，应该有端口号，根据端口号，将数据交给相应应用程序。
UDP包头有端口号，有源端口号和目标端口号，因为是两端通信嘛。
UDP除了端口号，也没有其他的了。
=====================================================================
沟通简单，不需要大量数据结构、处理逻辑、包头字段。
前提是它相信网络世界是美好的，秉承性善论，相信网络通路默认就是很容易送达的，不易被丢弃。
轻信他人。
它不会建立连接，虽然有端口号，但是监听在这个地方，谁都可以传给他数据，他也可以传给任何人数据，甚至可以同时传给多个人数据。
愣头青。不知何时该坚持，何时该退让。
不会根据网络情况进行发包的拥塞控制，无论网络丢包丢成啥样，它该怎么发还怎么发。
======================================================================
需要资源少，在网络情况比较好的内网，或对于丢包不敏感的应用。即对于失败不那么敏感的场景。
DHCP就是基于UDP。一般获取IP地址都是内网请求，而且一次获取不到IP又没事，过一会儿还有机会。
PXE可以在启动时自动安装os，os镜像的下载使用的TFTP，也是基于UDP。在还没有os时，客户端拥有的资源很少，不适合维护一个复杂状态机，而是因为是内网，一般也没啥问题。
无需一对一沟通，建立连接，而是可以广播的应用。
UDP的不面向连接特性，可承载广播或多播协议。DHCP就是一种广播，基于UDP。
对于多播，IP地址的D类地址，即组播地址，使用这个地址，可以将包组播给一批机器。当一台机器上的某个进程想监听某个组播地址时，需发送IGMP包，所在网络的路由器就能收到这个包，知道有个机器上有个进程在监听这个组播地址。当路由器收到这个组播地址时，会将包转发给这台机器，这就实现了跨路由器的组播。
需要处理速度快，时延低，可以容忍少数丢包，但要求即便网络拥塞，也毫不退缩，一往无前。
UDP简单、处理速度快，不像TCP操心各种重传，顺序，前面的不收到，后面的没法处理。不然等这些事情做完了，时延早就上去了。而TCP在网络不好出现丢包时，拥塞控制策略会主动退缩，降低发送速度，这就相当于本来环境就差，还自断臂膀，用户本来就卡，这下更卡。
当前很多应用都是要求低时延的，它们可不想用TCP如此复杂的机制，而是想根据自己的场景，实现自己的可靠和连接保证。例如，如果应用自己觉得，有的包丢了就丢了，没必要重传了，就可以算了，有的比较重要，则应用自己重传，而不依赖于TCP。有的前面的包没到，后面的包到了，那就先给客户展示后面的嘛，干嘛非得等到齐了呢？如果网络不好，丢了包，那不能退缩啊，要尽快传啊，速度不能降下来啊，要挤占带宽，抢在客户失去耐心之前到达。
如果你实现的应用需要有自己的连接策略，可靠保证，时延要求，使用UDP，然后再应用层实现再好不过。
=======================================================================
原来访问网页和手机APP都是基于HTTP协议。HTTP协议基于TCP，建立连接都需要多次交互，对于时延较大的移动互联网，建立一次连接需要的时间较长，然而既然是移动中，TCP可能还会断了重连，也是很耗时的。
目前HTTP协议往往采取多个数据通道共享一个连接，这样本来为了加快传输速度，但是TCP的严格顺序策略使得哪怕共享通道，前一个不来，后一个和前一个即便没关系，也要等着，时延也会加大。
而QUIC（Quick UDP Internet Connections，快速UDP互联网连接）是Google提出的一种基于UDP改进的通信协议，其目的是降低网络通信的延迟，提供更好的用户互动体验。
QUIC在应用层上，会自己实现快速连接建立、减少重传时延，自适应拥塞控制。
现在直播比较火，直播协议多使用RTMP，也是基于TCP。TCP的严格顺序传输要保证前一个收到了，下一个才能确认，如果前一个收不到，下一个就算包已经收到了，在缓存里面，也需要等着。对于直播来讲，这显然是不合适的，因为老的视频帧丢了其实也就丢了，就算再传过来用户也不在意了，他们要看新的了，如果老是没来就等着，卡顿了，新的也看不了，那就会丢失客户，所以直播，实时性比较比较重要，宁可丢包，也不要卡顿的。
另外，对于丢包，其实对于视频播放来讲，有的包可以丢，有的包不能丢，因为视频的连续帧里面，有的帧重要，有的不重要，如果必须要丢包，隔几个帧丢一个，其实看视频的人不会感知，但是如果连续丢帧，就会感知了，因而在网络不好的情况下，应用希望选择性的丢帧。
还有就是当网络不好的时候，TCP协议会主动降低发送速度，这对本来当时就卡的看视频来讲是要命的，应该应用层马上重传，而不是主动让步。因而，很多直播应用，都基于UDP实现了自己的视频传输协议。
实时游戏
游戏有一个特点，就是实时性比较高。快一秒你干掉别人，慢一秒你被别人爆头，所以很多职业玩家会买非常专业的鼠标和键盘，争分夺秒。
因而，实时游戏中客户端和服务端要建立长连接，来保证实时传输。但是游戏玩家很多，服务器却不多。由于维护TCP连接需要在内核维护一些数据结构，因而一台机器能够支撑的TCP连接数目是有限的，然后UDP由于是没有连接的，在异步IO机制引入之前，常常是应对海量客户端连接的策略。
TCP强顺序，对战的游戏对网络要求很简单，玩家通过客户端发送给服务器鼠标和键盘行走的位置，服务器会处理每个用户发送过来的所有场景，处理完再返回给客户端，客户端解析响应，渲染最新的场景展示给玩家。
写在最后
学习技术是一条慢长而艰苦的道路，不能靠一时激情，也不是熬几天几夜就能学好的，必须养成平时努力学习的习惯。所以：贵在坚持！
最后再分享的一些BATJ等大厂20、21年的面试题，把这些技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，上面只是以图片的形式给大家展示一部分。
Mybatis面试专题
MySQL面试专题
并发编程面试专题
只是以图片的形式给大家展示一部分。
[外链图片转存中…(img-RCRy1n6M-1714536509234)]
Mybatis面试专题
[外链图片转存中…(img-VAHWnYoR-1714536509235)]
MySQL面试专题
[外链图片转存中…(img-Mpm44rLd-1714536509235)]
并发编程面试专题
7844
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
