一、说明
在网络原理中我们经常说TCP是面向连接的要进行三次握手和四次挥手所以速度比较慢，UDP是无连接的直接发送和接收所以速度快（说到这个快慢我总想起多年前有篇分析MSN为什么被QQ淘汰的一篇文章其中有一条就是说MSN用的TCP速度慢QQ用的UDP速度快，时至今日我也不确定在聊天软件中用TCP和用UDP是否会表现出明显的速度差异甚至我不确定是不是MSN用TCP、QQ用UDP）。
今天同事整理端口矩阵时反映说Nmap进行UDP端口扫描没有结果，让帮看一下命令有没有问题。形如下：
nmap -sU -p 1-65535 192.168.220.128
看了一下没什么问题，在自己Windows上用Zenmap跑了一下发现扫描比较慢但没有很在意，直到下午看到还没完成就需要探究一番了。
对以往UDP扫描的速度没什么特别换印像，也就是说应该没有这么慢才对。
二、问题探究
2.1 排除服务端配置问题
首先使用Wireshark截包，发现每秒也就三五个探测及端口不可达ICMP包。
直觉上没认为自己机器的问题，再结合百度、谷歌的结果及官网的如下说法，觉得应该就是服务端通过icmp_ratelimit参数限制了ICMP端口不可达响应速率
但到服务器查看/proc/sys/net/ipv4/icmp_ratelimit发现配置的是1000，如下图
这是越想越不能令人信服的，实际扫描中的每秒三五次和每秒限制1000次差距过于明显，瓶颈不应该在服务器限制响应速率上（而且测试中将icmp_ratelimit配置为不进行限速的0也并没有快很多）。
2.2 排除操作系统问题
向另一同事询问后，他提出有没有可能是操作系统问题，建议使用Linux试一下。
思索之下是有道理的，一是Windows和Linux在发包这种东西上素来就有区别，二是之前用nmap大多在Linux里用UDP扫描感觉没有很慢。
打开Kali虚拟机使用Nmap进行扫描发现确实快很多，如下图所示：
唯一的问题是不管扫哪个机器、怎么扫，所有端口都报open|filtered。这最终只能认为是服务器端口的返回不足以让Nmap区分出其状态。
正准备收工，把UDP扫描慢归为操作系统问题，同时UDP扫描判断端口状态效果一般时，看到Wireshark抓取的数据包如下图所示：
这问题很大，如上截图中只有从虚拟机发往目标机的数据包，并没有从目标机返回的端口不可达ICMP包（但这似乎不是所有端口都被识别为open|filtered的原因，因为后边在Linux物理机上一样是open|filtered）。
这与前面在物理机中的扫描不一致，此时就存在操作系统类型和有无响应数据包两个变量，不能直接下结论说是哪个的问题。
又用一台Linux物理机使用Nmap进行扫描，发现扫描速度与Windows物理机差不多。
也就是说，当前的结论是Nmap的UDP扫描缓慢和服务端无关、和操作系统也无关、虚拟机中的快只是因为收不到响应，其中的道理到目前为止尚不清楚。
参考：
https://nmap.org/book/scan-methods-udp-scan.html#scan-methods-ex-udpscan-scanme2
原文地址：https://www.cnblogs.com/lsdb/p/10678525.html