udp协议分析实验报告(udp协议分析实验报告怎么做)

【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攻击的主流防御手段，在华为防火墙产品中广泛应用。

wireshark 仅仅显示UDP命令

应该是你过滤规则的问题

建议改一下这个框里面填写的过滤规则

udp协议详解

应用层：应用程序间沟通的层，如简单电子邮件传输（SMTP）、文件传输协议（FTP）、网络远程访问协议（Telnet）等。

传输层：在此层中，它提供了节点间的数据传送服务，如传输控制协议（TCP）、用户数据报协议（UDP）等，TCP和UDP给数据包加入传输数据并把它传输到下一层中，这一层负责传送数据，并且确定数据已被送达并接收。

互连网络层：负责提供基本的数据封包传送功能，让每一块数据包都能够到达目的主机（但不检查是否被正确接收），如网际协议（IP）。

网络接口层：对实际的网络媒体的管理，定义如何使用实际网络（如Ethernet、Serial Line等）来传送数据。

TCP/IP中的协议

以下简单介绍TCP/IP中的协议都具备什么样的功能，都是如何工作的：

1． IP

网际协议IP是TCP/IP的心脏，也是网络层中最重要的协议。

IP层接收由更低层（网络接口层例如以太网设备驱动程序）发来的数据包，并把该数据包发送到更高层---TCP或UDP层；相反，IP层也把从TCP或UDP层接收来的数据包传送到更低层。IP数据包是不可靠的，因为IP并没有做任何事情来确认数据包是按顺序发送的或者没有被破坏。IP数据包中含有发送它的主机的地址（源地址）和接收它的主机的地址（目的地址）。

高层的TCP和UDP服务在接收数据包时，通常假设包中的源地址是有效的。也可以这样说，IP地址形成了许多服务的认证基础，这些服务相信数据包是从一个有效的主机发送来的。IP确认包含一个选项，叫作IP source routing，可以用来指定一条源地址和目的地址之间的直接路径。对于一些TCP和UDP的服务来说，使用了该选项的IP包好象是从路径上的最后一个系统传递过来的，而不是来自于它的真实地点。这个选项是为了测试而存在的，说明了它可以被用来欺骗系统来进行平常是被禁止的连接。那么，许多依靠IP源地址做确认的服务将产生问题并且会被非法入侵。

04 - TCP和UDP的认识和区别

本文主要分析运输层的两种协议TCP和UDP，重点在于TCP如何实现可靠传输，并且进行流量控制，以及TCP的三次握手和四次挥手的详细过程。最后对TCP和TDP的两种协议进行了比较。

TCP的拥塞控制已在另一篇博客 拥塞控制的基本方法 说明，本文不再赘述.

运输层就是位于应用层和网络层之间的，为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务。

物理层、数据链路层以及网络层他们共同解决了将主机通过异构网络互连起来所面临的问题，实现了主机到主机的通信，而通信的真正实体是位于通信两端主机中的进程。

因特网的运输层为应用层提供了两种不同的运输协议，即面向连接的TCP和无连接的UDP

UDP是无连接的，不可靠的运输协议，TCP是面向连接的，可靠的运输协议

运输层在网络通信中的作用：

运输层在网络通信中作用过程：

注：这里所说的主机和主机之间的通信其实是主机进程之间的通信

用户数据报协议(User Datagram Protocol)，是TCP/IP体系结构运输层中的一个重要协议，这种逻辑通信信道是一条不可靠信道。

特点：

说明：

TCP 是TCP/IP体系结构运输层中的重要协议，当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道。

TCP 传送的数据单位协议是 TCP 报文段(segment)

特点：

TCP传输过程

说明：

发送方：

接收方：

在TCP传输中为了实现可靠传输和流量控制都需要涉及超时重传，超时重传中最为重要的是计算超时重传的时间。

RTO是超时重传时间，RTT是往返时间。

超时重传时间不能远大于往返时间，会浪费资源

超时重传时间不能小于往返时间，会造成不必要的重传

超时重传时间应当略大于往返时间，为了避免误差，应当选用一段时间内的加权的往返时间

总结：

1、如果超时重传时间RTO的值设置得比RTT的值小很多，这会引起报文段不必要的重传，使网络负荷增大

2、如果超时重传时间RTO的值设置得远大于RTT0的值，这会使重传时间推迟的太长，使网络的空闲时间增大，降低传输效率

3、因此需要将超时重传时间设置的略大于一次往返时间。

超时重传时间的要略大于一次往返时间，但一次往返时间是不固定的，因此超时重传时间的计算是基于加权平均往返时间

说明：

往返时间RTT的测量不能简单的进行一次往返时间的计算，有如下问题需要处理

问题1：如果报文丢失或确认报文的迟到，都会导致重传报文。这样两次的报文发送使得无法准确计算一次往返时间。

解决1：Karn算法

问题2：

对于问题1的解决会引入新问题

解决2：

利用滑动窗口机制来实现流量控制，重点有两个，一个是接收方通过对已接收的数据进行累计确认，并调整窗口大小，来对发送方进行流控，第二个就是启动持续计时器来探知是否要发送零窗口探测报文，通过这两个就可以让接收方对发送方进行窗口大小的调控，以此做到了流量控制。

一般来说，我们总是希望数据传输的更快一些，但是如果发送方把数据发送的过快，接收方就可能来不及接收，这就会造成数据的丢失。所以就需要进行流量控制，

流量控制简单说就是让发送方的发送速率不要太快，要让接收方来得及接收

我们利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制

重点在于接收方根据自己的存储空间来决定自己的接收空间的大小，以此来限制发送方发送窗口的大小

过程：

说明：

接收方给发送方发送的确认报文丢失后会形成A和B主机的相互等待，这样就造成了死锁，需要通过一个持续计时器，当计时器为0时发送零窗口探测报文询问以此让接收方再次发送确认报文。这样就打破了死锁

说明：

零窗口探测报文丢失后，是否仍然会死锁？

零窗口探测报文发送到主机B时，主机B的接收窗口为0，还能接收零窗口探测报文吗

可靠传输是通过确认机制来实现的，接收方给发送方发送的确认报文带有的字段决定了发送方是否要重传，是否要滑动窗口的操作，以此做到了可靠传输

说明：

TCP是面向连接的协议，它基于运输连接来传送TCP报文段，TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的部分。

TCP的运输连接管理就是使运输连接的建立和释放都能正常的进行。

共有三个阶段

过程示意图：

说明：

为什么必须要三次握手，不能两次握手？

TCP双方已经建立了连接，后来，TCP客户进程所在的主机突然出现了故障，TCP服务器进程以后就不能再收到TCP客户进程发来的数据，因此，应当有措施使TCP服务器进程不要再白白等待下去。