udp协议分析实验报告心得(udp协议分析实验总结)

关于UDP协议的用途，看完就懂了

目前我们用的大多数应用层的协议都是基于TCP的，例如:telent, ftp, http, https, smtp.很少有基于UDPy协议的应用层的协议。

那么UDP协议到底有什么作用呢？

首先我们比较下TCP与UDP协议的差别

（1）连接与无连接

TCP是面向连接的，UDP是面向无连接的。 因此导致TCP更适合于消息的多播发布可以向多个点传送消息（因为没有繁琐的握手机制与挥手机制）同时也导致UDP适用于快速传输的协议，对信息的时实性要求严格的协议。

由于UDP的速度快，所以适合于在线视频媒体，电话视频聊天，qq聊天，电视广播，多人在线游戏这些项目。

（为了时实性牺牲写可靠性，即使有包丢失，可能会导致语音不清楚，视频不清楚等问题，不过没有影响）

（2）可靠性

TCP是可靠的传输协议，UDP是不可靠的。

因此导致UDP不适合金融支付这方面要求可靠性的项目。 （因为UDP没有超时重传的机制不能保证可靠性）。

（3）有序性

TCP协议可以保证有序性，UDP协议不保证。

（消息将会以从服务端发出的顺序发送给客户端，尽管消息可能到网络的另一端时是无顺序的，TCP协议会为你排好序） 但是即使UDP不可靠，无序，但是我们可以将这些要求转移给上层应用来实现，不仅降低了执行时间，而且使质量得到保证。（例如可以通过给UDP协议使用序列号和重传机制来改善它的这两个缺点）。

（4）重量级与轻量级

TCP协议是重量级，UDP协议是轻量级

因为TCP要保证可靠性和有序性，所以TCP数据报报头的信息量大，报头大小是20个字节，UDP报头的大小是8个字节。所以TCP占用的系统的开销大。

（5）拥塞和流量控制

TCP有流量控制，UDP没有。

TCP通常在发送包之前会测试网络的快慢情况，就好比我们在linux中投的ping命令，通过往返的时间和丢包率来评估网路的状况，来调动滑动窗口的大小。（这项机制增加了TCP的可靠性）。

（6）数据边界

TCP协议没有数据边界，UDP有

因此TCP容易发生粘包的现象。在UDP中数据包是单独发送的，只有当他们到达时才会再次集成，包有明确的界限来判断哪些包已经收到。

总结：

UDP协议被广泛用到对网络数据传输的实时性很高，对数据准确性不是非常高的场合，并且如今网络物理介质的高速提升（光纤）降低了数据丢包的机率，并且当网络状况很好的情况下，UDP的缺点又可以很好的大程度上的被改善。因此UDP协议发展前途无量。

UDP协议是什么意思 UDP协议分析【介绍】

UDP协议,UDP协议是什么意思

UDP 是User Datagram Protocol的简称， 中文名是用户数据包协议，是 OSI 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。它是IETF RFC 768是UDP的正式规范。

UDP协议是英文UserDatagramProtocol的缩写，即用户数据报协议，主要用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/服务器模式的网络应用都需要使用UDP协议。UDP协议从问世至今已经被使用了很多年，虽然其最初的光彩已经被一些类似协议所掩盖，但是即使是在今天，UDP仍然不失为一项非常实用和可行的网络传输层协议。

与我们所熟知的TCP(传输控制协议)协议一样，UDP协议直接位于IP(网际协议)协议的顶层。根据OSI(开放系统互连)参考模型，UDP和TCP都属于传输层协议。

UDP协议的主要作用是将网络数据流量压缩成数据报的形式。一个典型的数据报就是一个二进制数据的传输单位。每一个数据报的前8个字节用来包含报头信息，剩余字节则用来包含具体的传输数据。

0UDP报头

UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：

源端口号

目标端口号

数据报长度

校验值

UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方(可以是客户端或服务器端)将UDP数据报通过源端口发送出去，而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口;而另外一些网络应用则可以使用未被注册的动态端口。因为UDP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。一般来说，大于49151的端口号都代表动态端口。

数据报的长度是指包括报头和数据部分在内的总的字节数。因为报头的长度是固定的，所以该域主要被用来计算可变长度的数据部分(又称为数据负载)。数据报的最大长度根据操作环境的不同而各异。从理论上说，包含报头在内的数据报的最大长度为65535字节。不过，一些实际应用往往会限制数据报的大小，有时会降低到8192字节。

UDP协议使用报头中的校验值来保证数据的安全。校验值首先在数据发送方通过特殊的算法计算得出，在传递到接收方之后，还需要再重新计算。如果某个数据报在传输过程中被第三方篡改或者由于线路噪音等原因受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检测是否出错。这与TCP协议是不同的，后者要求必须具有校验值。

UDPvs.TCP

UDP和TCP协议的主要区别是两者在如何实现信息的可靠传递方面不同。TCP协议中包含了专门的传递保证机制，当数据接收方收到发送方传来的信息时，会自动向发送方发出确认消息;发送方只有在接收到该确认消息之后才继续传送其它信息，否则将一直等待直到收到确认信息为止。

与TCP不同，UDP协议并不提供数据传送的保证机制。如果在从发送方到接收方的传递过程中出现数据报的丢失，协议本身并不能做出任何检测或提示。因此，通常人们把UDP协议称为不可靠的传输协议。

相对于TCP协议，UDP协议的另外一个不同之处在于如何接收突法性的多个数据报。不同于TCP，UDP并不能确保数据的发送和接收顺序。例如，一个位于客户端的应用程序向服务器发出了以下4个数据报

D1

D22

D333

D4444

但是UDP有可能按照以下顺序将所接收的数据提交到服务端的应用：

D333

D1

D4444

D22

事实上，UDP协议的这种乱序性基本上很少出现，通常只会在网络非常拥挤的情况下才有可能发生。

UDP协议的应用

也许有的读者会问，既然UDP是一种不可靠的网络协议，那么还有什么使用价值或必要呢?其实不然，在有些情况下UDP协议可能会变得非常有用。因为UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能，但是在实际执行的过程中会占用大量的系统开销，无疑使速度受到严重的影响。反观UDP由于排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，使速度得到了保证。

关于UDP协议的最早规范是RFC768，1980年发布。尽管时间已经很长，但是UDP协议仍然继续在主流应用中发挥着作用。包括视频电话会议系统在内的许多应用都证明了UDP协议的存在价值。因为相对于可靠性来说，这些应用更加注重实际性能，所以为了获得更好的使用效果(例如，更高的画面帧刷新速率)往往可以牺牲一定的可靠性(例如，会面质量)。这就是UDP和TCP两种协议的权衡之处。根据不同的环境和特点，两种传输协议都将在今后的网络世界中发挥更加重要的作用.

[编辑本段]UDP报头

UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：

源端口号

目标端口号

数据报长度

校验值

UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方(可以是客户端或服务器端)将UDP数据报通过源端口发送出去，而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口;而另外一些网络应用则可以使用未被注册的动态端口。因为UDP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。一般来说，大于49151的端口号都代表动态端口。

数据报的长度是指包括报头和数据部分在内的总字节数。因为报头的长度是固定的，所以该域主要被用来计算可变长度的数据部分(又称为数据负载)。数据报的最大长度根据操作环境的不同而各异。从理论上说，包含报头在内的数据报的最大长度为65535字节。不过，一些实际应用往往会限制数据报的大小，有时会降低到8192字节。

UDP协议使用报头中的校验值来保证数据的安全。校验值首先在数据发送方通过特殊的算法计算得出，在传递到接收方之后，还需要再重新计算。如果某个数据报在传输过程中被第三方篡改或者由于线路噪音等原因受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检测是否出错。这与TCP协议是不同的，后者要求必须具有校验值。

许多链路层协议都提供错误检查，包括流行的以太网协议，也许想知道为什么UDP也要提供检查和。其原因是链路层以下的协议在源端和终端之间的某些通道可能不提供错误检测。虽然UDP提供有错误检测，但检测到错误时，UDP不做错误校正，只是简单地把损坏的消息段扔掉，或者给应用程序提供警告信息。

[编辑本段]UDP协议的几个特性

(1) UDP是一个无连接协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制;在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。

(2) 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。

(3) UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。

(4) 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

(5)UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表(这里面有许多参数)。

(6)UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

虽然UDP是一个不可靠的协议，但它是分发信息的一个理想协议。例如，在屏幕上报告股票市场、在屏幕上显示航空信息等等。UDP也用在路由信息协议RIP(Routing Information Protocol)中修改路由表。在这些应用场合下，如果有一个消息丢失，在几秒之后另一个新的消息就会替换它。UDP广泛用在多媒体应用中，例如，Progressive Networks公司开发的RealAudio软件，它是在因特网上把预先录制的或者现场音乐实时传送给客户机的一种软件，该软件使用的RealAudio audio-on-demand protocol协议就是运行在UDP之上的协议，大多数因特网电话软件产品也都运行在UDP之上。

UDP = uridine diphosphate，尿苷二磷酸，一种嘧啶核苷酸，由碱基、尿嘧啶与核糖组成，主要用途是RNA合成(转录)时的原料。 另外UDP也是DTP能量消耗后产物，功能类似ADP，但较ADP少见。参与微生物肽聚糖等的合成。

UDP是什么，UDP协议及优缺点

UDP，全称 User Datagram Protocol，中文名称为用户数据报协议，主要用来支持那些需要在计算机之间传输数据的网络连接。

UDP 协议从问世至今已经被使用了很多年，虽然目前 UDP 协议的应用不如 TCP 协议广泛，但 UDP 依然是一种非常实用和可行的网络传输层协议。尤其是在一些实时性很强的应用场景中，比如网络游戏、视频会议等，UDP 协议的快速能力更具有独特的魅力。

UDP 是一种面向非连接的协议，面向非连接指的是在正式通信前不必与对方先建立连接，不管对方状态就直接发送数据。至于对方是否可以接收到这些数据，UDP 协议无法控制，所以说 UDP 是一种不可靠的协议。

UDP 协议适用于一次只传送少量数据、对可靠性要求不高的应用环境。

与前面介绍的 TCP 协议一样，UDP 协议直接位于 IP 协议之上。实际上，IP 协议属于 OSI 参考模型的网络层协议，而 UDP 协议和 TCP 协议都属于传输层协议。

因为 UDP 是面向非连接的协议，没有建立连接的过程，因此它的通信效率很高，但也正因为如此，它的可靠性不如 TCP 协议。

UDP 协议的主要作用是完成网络数据流和数据报之间的转换在信息的发送端，UDP 协议将网络数据流封装成数据报，然后将数据报发送出去；在信息的接收端，UDP 协议将数据报转换成实际数据内容。

可以认为 UDP 协议的 socket 类似于码头，数据报则类似于集装箱。码头的作用就是负责友送、接收集装箱，而 socket 的作用则是发送、接收数据报。因此，对于基于 UDP 协议的通信双方而言，没有所谓的客户端和服务器端的概念。

UDP 协议和 TCP 协议简单对比如下：

TCP 协议：可靠，传输大小无限制，但是需要连接建立时间，差错控制开销大。

UDP 协议：不可靠，差错控制开销较小，传输大小限制在 64 KB以下，不需要建立连接。

?相比较 TCP，UDP 是一种不可靠的网络协议，它在通信实例的两端各建立一个 socket，但这两个 socket 之间并没有虚拟链路，它们只是发送、接收数据报的对象。

【udp】关于docker 容器网络下使用 UDP 协议无法通讯问题的分析和处理

工作中遇到一个 docker 容器下 UDP 协议网络不通的问题，困扰了很久，也比较有意思，所以想写下来和大家分享。

我们有个应用是基于 UDP 协议的，部署上去发现无法工作，但是换成 TCP 协议是可以的（应用同时支持 UDP、TCP 协议，切换成 TCP 模式发现一切正常）。

虽然换成 TCP 能解决问题，但是我们还是想知道到底 UDP 协议在容器网络模式下为什么会出现这个问题，以防止后面其他 UDP 应用会有异常。

这个问题抽象出来是这样的：如果有 UDP 服务运行在宿主机上（或者运行在网络模型为 host 的容器里），并且监听在 0.0.0.0 地址（也就是所有的 ip 地址），从运行在 docker bridge（网桥为 docker0） 网络的容器运行客户端访问服务，两者通信有问题。

注意以上的的限制条件，通过测试，我们发现下来几种情况都是正常的：

这个问题在 docker 上也有 issue 记录，但是目前并没有合理的解决方案。

这篇文章就分析一下出现这个问题的原因，希望给同样遇到这个问题的读者提供些帮助。

这个问题很容易重现，我的实验是在 ubuntu16.04 下用 netcat 命令完成的，其他系统应该类似。

在宿主机上通过 nc 监听 56789 端口，然后使用 bridge 网络模式，run 一个容器，在容器里面使用 nc 发数据。

第一个报文是能发送出去的，但是以后的报文虽然在网络上能看到，但是对方无法接收。

在宿主机运行 nc UDP 服务器（-u 表示 UDP 协议，-l 表示监听的端口）

注：默认没有指定绑定ip，就是监听在0.0.0.0上。

然后在同一宿主机上，启动一个容器，运行客户端：

nc 的通信是双方的，不管对方输入什么字符，回车后对方就能立即收到。

但是在这个模式下，客户端第一次输入对方能够收到，后续的报文对方都收不到。

在这个实验中，容器使用的是 docker 的默认网络，容器的 ip 是 172.17.0.3，通过 veth pair（图中没有显示）连接到虚拟网桥 docker0（ip 地址为 172.17.0.1），宿主机本身的网络为 eth0，其 ip 地址为 172.16.13.13。

遇到这种疑难杂症，第一个想到的抓包。

我们需要在 docker0 上抓包，因为这是报文必经过的地方。

通过过滤容器的 ip 地址，很容器找到感兴趣的报文：

为了模拟多数应用一问一答的通信方式，我们一共发送三个报文，并用 tcpdump 抓取 docker0 接口上的报文：

抓包的结果如下，可以发现第一个报文发送出去没有任何问题。

UDP 是没有 ACK 报文的，所以客户端无法知道对方有没有收到，这里说的没有问题没有看到对应的 ICMP 差错报文。

但是第二个报文从服务端发送的报文，对方会返回一个 ICMP 告诉端口 38908 不可达；第三个报文从客户端发送的报文也是如此。以后的报文情况类似，双方再也无法进行通信了。

而此时主机上 UDP nc 服务器并没有退出，使用 ss -uan | grep 56789 可能看到它仍然在监听着该端口。

从网络报文的分析中可以看到服务端返回的报文源地址不是我们预想的 eth0 地址，而是 docker0 的地址，而客户端直接认为该报文是非法的，返回了 ICMP 的报文给对方。

那么问题的原因也可以分为两个部分：

第一个问题的关键词是：UDP 和多网络接口。

因为如果主机上只有一个网络接口，发出去的报文源地址一定不会有错；而我们也测试过 TCP 协议是能够处理这个问题的。

通过搜索，发现这确实是个已知的问题。

这个问题可以归结为一句话：UDP 在多网卡的情况下，可能会发生【服务器端】【源地址】不对的情况，这是内核选路的结果。

为什么 UDP 和 TCP 有不同的选路逻辑呢？

因为 UDP 是无状态的协议，内核不会保存连接双方的信息，因此每次发送的报文都认为是独立的，socket 层每次发送报文默认情况不会指明要使用的源地址，只是说明对方地址。

因此，内核会为要发出去的报文选择一个 ip，这通常都是报文路由要经过的设备 ip 地址。

那么，为什么 dnsmasq 服务没有这个问题呢？

于是我使用 strace 工具抓取了 dnsmasq 和出问题应用的网络 socket 系统调用，来查看它们两个到底有什么区别。

dnsmasq 在启动阶段监听了 UDP 和 TCP 的 54 端口

因为是在本地机器上测试的，为了防止和本地 DNS 监听的DNS端口冲突，我选择了 54 而不是标准的 53 端口：

比起 TCP，UDP 部分少了 listen，但是多个 setsockopt(4, SOL_IP, IP_PKTINFO, [1], 4) 这句。

到底这两点和我们的问题是否有关，先暂时放着，继续看传输报文的部分。

dnsmasq 收包和发包的系统调用，直接使用 recvmsg 和 sendmsg 系统调用：

而出问题的 UDP 应用 strace 结果如下：

其对应的逻辑是这样的：使用 ipv6 绑定在 0.0.0.0 和 6088 端口，调用 getsockname 获取当前 socket 绑定的端口信息，数据传输过程使用的是 recvfrom 和 sendto。

对比下来，两者的不同有几点：

因为是在传输数据的时候出错的，因此第一个疑点是 sendmsg 和 sendto 的某些区别导致选择源地址有不同，通过 man sendto 可以知道 sendmsg 包含了更多的控制信息在 msghdr。

一个合理的猜测是 msghdr 中包含了内核选择源地址的信息！

通过查找，发现 IP_PKTINFO 这个选项就是让内核在 socket 中保存 IP 报文的信息，当然也包括了报文的源地址和目的地址。 IP_PKTINFO 和 msghdr 的关系可以在这个 stackoverflow 中找到：

而 man 7 ip 文档中也说明了 IP_PKTINFO 是怎么控制源地址选择的：

如果 ipi_spec_dst 和 ipi_ifindex 不为空，它们都能作为源地址选择的依据，而不是让内核通过路由决定。

也就是说，通过设置 IP_PKTINFO socket 选项为 1，然后使用 recvmsg 和 sendmsg 传输数据就能保证源地址选择符合我们的期望。

这也是 dnsmasq 使用的方案，而出问题的应用是因为使用了默认的 recvfrom 和 sendto。

为什么内核会把源地址和之前不同的报文丢弃，认为它是非法的？

因为我们前面已经说过，UDP 协议是无连接的，默认情况下 socket 也不会保存双方连接的信息。即使服务端发送报文的源地址有误，只要对方能正常接收并处理，也不会导致网络不通。

但是 conntrack 不是这样，内核的 netfilter 模块会保存连接的状态，并作为防火墙设置的依据。

它保存的 UDP 连接，只是简单记录了主机上本地 ip 和端口，和对端 ip 和端口，并不会保存更多的内容。

关于 这块可参考 intables info 网站的文章：

在找到根源之前，我们曾经尝试过用 SNAT 来修改服务端应答报文的源地址，期望能够修复该问题，但是却发现这种方法行不通，为什么呢？

因为 SNAT 是在 netfilter 最后做的，在之前 netfilter 的 conntrack 因为不认识该 connection，直接丢弃了，所以即使添加了 SNAT 也是无法工作的。

那能不能把 conntrack 功能去掉呢？比如解决方案：

答案也是否定的，因为 NAT 需要 conntrack 来做翻译工作，如果去掉 conntrack 等于 SNAT 完全没用。

知道了问题的原因，解决方案也就很容易找到。

nc 可以跟两个参数，分别代表 ip 和 端口，表示服务端监听在某个特定 ip 上。

如果接收到的报文目的地址不是 172.16.13.13，也会被内核直接丢弃，这种情况下，服务端和客户端也能正常通信。

docker 容器网络下 UDP 协议的一个问题

Setting the source IP for a UDP socket

LinuxC下获取UDP包中的路由目的IP地址和头标识目的地址

Source IP address selection

UDP recvmsg 返回目的地址和目的接口信息

告知你不为人知的 UDP：连接性和负载均衡

告知你不为人知的 UDP：疑难杂症和使用

UDP flood

UDPFlood是日渐猖厥的流量型DoS攻击，原理也很简单。常见的情况是利用大量UDP小包冲击DNS服务器或Radius认证服务器、流媒体视频服务器。100k bps的UDPFlood经常将线路上的骨干设备例如防火墙打瘫，造成整个网段的瘫痪。由于UDP协议是一种无连接的服务，在UDPFLOOD攻击中，攻击者可发送大量伪造源IP地址的小UDP包。但是，由于UDP协议是无连接性的，所以只要开了一个UDP的端口提供相关服务的话，那么就可针对相关的服务进行攻击。

正常应用情况下，UDP包双向流量会基本相等，而且大小和内容都是随机的，变化很大。出现UDPFlood的情况下，针对同一目标IP的UDP包在一侧大量出现，并且内容和大小都比较固定。

UDP协议与 TCP 协议不同，是无连接状态的协议，并且UDP应用协议五花八门，差异极大，因此针对UDPFlood的防护非常困难。其防护要根据具体情况对待：?

判断包大小，如果是大包攻击则使用防止UDP碎片方法：根据攻击包大小设定包碎片重组大小，通常不小于1500。在极端情况下，可以考虑丢弃所有UDP碎片。?

攻击端口为业务端口：根据该业务UDP最大包长设置UDP最大包大小以过滤异常流量。?

攻击端口为非业务端口：一个是丢弃所有UDP包，可能会误伤正常业务；一个是建立UDP连接规则，要求所有去往该端口的UDP包，必须首先与TCP端口建立TCP连接。不过这种方法需要很专业的 防火墙 或其他防护设备支持

UDP攻击是一种消耗对方资源，也消耗你自己的资源的攻击方式，现在已经没人使用这种过时的东西了，你攻击了这个网站，其实也在消耗你的系统资源，说白了就是拼资源而已，看谁的带宽大，看谁能坚持到最后，这种攻击方式没有技术含量，引用别人的话，不要以为洪水无所不能，攻击程序在消耗对方资源的时候也在消耗你的资源

我们知道了TCP协议是一种面向连接的传输协议。但是UDP协议与TCP协议不同， UDP是一个无连接协议。使用UDP协议传输数据之前，客户端和服务器之间不建立连接，如果在从客户端到服务器端的传递过程中出现数据的丢失，协议本身并不能做出任何检测或提示。因此，通常人们把UDP协议称为不可靠的传输协议。

既然UDP是一种不可靠的网络协议，那么还有什么使用价值或必要呢？

其实不然，在有些情况下UDP协议可能会变得非常有用。因为UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能，但是在实际执行的过程中会占用大量的系统开销，无疑使传输速度受到严重的影响。反观UDP，由于排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，使传输速度得到了保证。

正是UDP协议的广泛应用，为黑客们发动UDP Flood攻击提供了平台。UDP Flood属于带宽类攻击，黑客们通过僵尸网络向目标服务器发起大量的UDP报文，这种UDP报文通常为大包，且速率非常快，通常会造成以下危害：

防火墙对UDP Flood的防御并不能像SYN Flood一样，进行源探测，因为它不建立连接。那应该怎么防御呢？

最初防火墙对UDP Flood的防御方式就是限流，通过限流将链路中的UDP报文控制在合理的带宽范围之内。

防火墙上针对UDP Flood的限流有三种：

限流虽然可以有效缓解链路带宽的压力，但是这种方式简单粗暴，容易对正常业务造成误判。为了解决这个问题，防火墙又进一步推出了针对UDP Flood的指纹学习功能。

仔细分析，不难发现，UDP Flood攻击报文具有一定的特点，这些攻击报文通常都拥有相同的特征字段，比如都包含某一个字符串，或整个报文内容一致。这些字段来自于DDoS工具自带的默认字符串，所以防火墙是通过收集这些字符串来检测UDP Flood。这种防御算法在现网使用很多，主要因为黑客为了加大攻击频率，快速、长时间挤占攻击目标所在网络带宽，在使用攻击工具实现时直接在内存存放一段内容，然后高频发送到攻击目标，所以攻击报文具有很高的相似性。而正常业务的UDP报文一般每个报文负载内容都是不一样的，这样可以减少误判。

从下面的抓包中可以看出，到达相同目的IP地址的两个UDP报文的载荷是完全一样的，如果防火墙收到大量的类似这样的UDP报文，那么就有可能是发生了UDP Flood攻击。

指纹学习是通过分析客户端向服务器发送的UDP报文载荷是否有大量的一致内容，来判定这个UDP报文是否异常。防火墙对到达指定目的地的UDP报文进行统计，当UDP报文达到告警阈值时，开始对UDP报文的指纹进行学习。如果相同的特征频繁出现，就会被学习成指纹，后续命中指纹的报文判定这是攻击报文，作为攻击特征进行过滤。

强叔再给大家总结一下，防火墙防御UDP Flood攻击主要有两种方式：限流和指纹学习，两种方式各有利弊。限流方式属于暴力型，可以很快将UDP流量限制在一个合理的范围内，但是不分青红皂白，超过就丢，可能会丢弃一些正常报文；而指纹学习属于理智型，不会随意丢弃报文，但是发生攻击后需要有个指纹学习的过程。目前，指纹学习功能是针对UDP Flood攻击的主流防御手段，在华为防火墙产品中广泛应用。

UDP协议、DNS协议总结

??用户数据报协议（UDP）是 ISO 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。 UDP 协议基本上是 IP 协议与上层协议的接口。

下图为UDP协议与DNS协议总结：

脑图链接：

密码：TUlB

引用请注明出处。