一、說明
在網絡原理中我們經常說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物理機使用Nmap進行掃描，發現掃描速度與Windows物理機差不多。
也就是說當前的結論是：虛擬機中的快只是因為收不到響應、Nmap的UDP掃描緩慢和服務端限制回復ICMP不可達速度無關、和Nmap所用操作系統也無關，瓶頸到底是哪還是不太清楚。
參考：
https://nmap.org/book/scan-methods-udp-scan.html#scan-methods-ex-udpscan-scanme2