主机发现这件事，很多人第一反应是掏出扫描器跑一遍网段，但真到自己动手写的时候，往往卡在最基础的一步：怎么判断一个IP到底活没活着。ICMP ping最直观，可它在很多网络里被策略拦得干干净净；TCP探测可靠，但要处理三次握手和超时重传，代码量一下就上去了。UDP主机发现是个被低估的折中方案——它不需要建立连接，发出去一个探测包，只要能从回包里解出IP头部，就能拿到源地址、TTL、协议号这些硬信息，判断逻辑反而比想象中干净。

这篇内容围绕一个具体的小工具展开：用Python从零写一个基于UDP的主机发现程序，核心动作是构造探测包、收包、然后手动解码IP header。适合已经会写点Python、想搞清楚原始套接字和协议解析到底怎么回事的人，也适合做内网资产梳理、教学演示、协议学习的朋友。我不会只丢一段能跑的代码就完事，而是把每个设计选择背后的理由、解码时容易踩的坑、以及实测中那些文档里不会写的细节都摊开讲。读完你拿到的不只是一个脚本，而是一套能迁移到其他协议探测上的思路。

1. 为什么主机发现要绕到UDP和IP头解码这条路上

1.1 三种探测思路的取舍：ICMP、TCP、UDP各自的实际处境

做主机发现，本质是回答一个问题：目标地址上有没有一台机器在响应网络流量。围绕这个目标，常见的探测手段就那么几类，但每一类在实际网络环境里的表现差异很大，选型不能只看"哪个最准"，得看"哪个在目标环境里还能用"。

ICMP Echo是最经典的方案，一个ping包过去，对方回一个Echo Reply，逻辑简单到不能再简单。问题在于，很多网络策略会直接丢弃ICMP，尤其是跨网段、跨区域的时候，你发出去的包石沉大海，根本分不清是主机不在还是被拦了。我见过不少内网环境，主机明明活着，ping就是不通，这时候纯靠ICMP会漏掉一大片。

TCP探测（比如向常见端口发SYN）可靠性高，因为TCP有明确的状态机，收到SYN-ACK或者RST都能说明主机在线。但代价是要处理连接状态、超时重传、端口选择，代码复杂度明显上升，而且如果目标端口全被过滤，同样会误判。

UDP主机发现的定位介于两者之间。它不追求"精确判断服务是否开放"，只追求"能不能收到一个带IP头的回包"。UDP是无连接的，发一个探测包出去，如果目标主机在线且端口关闭，通常会回一个ICMP端口不可达；如果端口有服务，可能回UDP数据。无论哪种，只要我们能抓到回包并解出IP头部，就能确认源地址可达。这个思路的好处是：不依赖ICMP Echo是否被放行（端口不可达的ICMP类型不同，策略上经常是分开处理的），也不需要维护连接状态。

注意：UDP探测的"回包"来源可能是目标主机本身，也可能是路径上的设备。解码IP头时一定要核对源地址，别把中间设备的响应当成目标主机在线。

三种方案的对比可以整理成下面这张表，选型时对着看：

1.2 解码IP header带来的额外价值：不只是"活着没"

如果目标只是判断主机在不在，其实收到任意回包就够了，为什么还要费劲去解码IP header？这是很多人会问的问题。我的答案是：解码IP头让这个工具从"能判断"升级到"能解释"，而"能解释"在实际排查里价值大得多。

IP头部里藏着不少有用信息。源地址告诉你回包到底从哪来，这是核对目标的关键；TTL值能粗略推断目标的操作系统类型和网络跳数，虽然不精确，但在资产梳理时是个有用的旁证；协议号字段告诉你这个包承载的是ICMP、TCP还是UDP，帮助你理解对方是用什么方式回应的；总长度和头部长度则让你知道这个包的结构是否完整、有没有被截断。

举个实际场景：你发UDP探测包到某个地址，收到一个回包，源地址对得上，但协议号显示是ICMP（值为1），那说明对方回的是端口不可达，主机大概率在线但端口没开；如果协议号是UDP（值为17），说明端口上有服务在跑。这两种情况的后续处理完全不同，而这一切判断都建立在你能正确解出IP头的基础上。

从学习角度讲，手动解码IP header是理解网络协议最直接的方式。你会在代码里一个字节一个字节地对照RFC 791的字段定义，把版本、头部长度、服务类型、总长度、标识、标志、片偏移、TTL、协议、校验和、源地址、目的地址这些字段一个个抠出来。这个过程做完一遍，你对"网络包长什么样"的理解会从抽象变成具体。

1.3 这个工具适合谁，不适合谁

说清楚边界很重要，免得有人拿它去干不合适的活。

适合的人：想学原始套接字和协议解析的开发者，做内网资产初步摸排的运维，需要教学演示网络协议结构的讲师，以及想理解"抓包工具背后在干什么"的技术爱好者。这个工具的代码量不大，但覆盖了套接字编程、字节序处理、位运算、协议字段解析这几个硬核知识点，是个很好的练手项目。

不适合的场景：大规模网段扫描（这个工具是单包探测思路，没做并发和重试优化，扫大网段效率不高）、需要精确服务识别的场景（它只判断主机可达性，不做端口服务指纹）、以及任何未经授权的网络探测。最后这条必须强调，主机发现类工具只能在你自己有管理权限的网络里用，或者在有明确授权的测试环境里用，这一点没有商量余地。

2. 原始套接字与UDP探测包的构造细节

2.1 原始套接字的权限门槛和平台差异

要用Python手动构造和解析IP包，绕不开原始套接字（raw socket）。普通套接字是操作系统帮你把传输层以下的事情都处理好了，你只管收发数据；原始套接字则把IP层甚至更底层暴露给你，你可以自己拼IP头、自己解IP头，自由度高了，门槛也高了。

第一个门槛是权限。在Linux上创建原始套接字需要root权限，普通用户直接报"Operation not permitted"。Windows上则需要管理员权限。这不是Python的限制，是操作系统出于安全考虑的设计——能随意构造原始包意味着能伪造源地址、能发畸形包，风险太大。所以这个工具跑起来的第一件事就是确认权限，代码里最好加个友好的错误提示，而不是让用户对着一个PermissionError发呆。

第二个门槛是平台差异。Linux和Windows在原始套接字的语义上有区别：Linux上socket(AF_INET, SOCK_RAW, IPPROTO_UDP)收到的是包含IP头的完整包，而某些平台上收到的可能不含IP头，需要设置IP_HDRINCL选项来控制发送时是否自己构造IP头。这些差异如果不处理，代码换个平台就跑不起来。

import socket import sys def create_raw_socket(): try: # 创建原始套接字，协议指定为UDP sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_UDP) # 告诉内核：IP头由我们自己构造 sock.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1) return sock except PermissionError: print("需要管理员/root权限才能创建原始套接字") sys.exit(1) except OSError as e: print(f"创建套接字失败: {e}") sys.exit(1)

这段代码里IP_HDRINCL这个选项值得多说一句。它的作用是告诉内核"发送时别帮我加IP头，我自己来"。如果不设这个选项，你往套接字里写的字节会被当成IP载荷，内核再给你套一个IP头，结果就是你精心构造的头部变成了载荷的一部分，收包方解出来全是乱的。这个坑我第一次写的时候踩过，发出去的包抓包一看结构完全不对，排查了半天才发现是少了这个选项。

2.2 手工拼一个合法的IP头：字段顺序和字节序的坑

既然要自己构造IP头，就得按RFC 791的定义一个字段一个字段地拼。IP头固定部分20字节，字段顺序是：版本（4位）+头部长度（4位）、服务类型（8位）、总长度（16位）、标识（16位）、标志（3位）+片偏移（13位）、TTL（8位）、协议（8位）、头部校验和（16位）、源地址（32位）、目的地址（32位）。

这里有几个容易出错的地方。第一是版本和头部长度共用一个字节，版本在高4位，头部长度在低4位，拼接时要用位运算：(4 << 4) | 5表示IPv4、头部长度5个32位字（即20字节）。第二是字节序，网络传输用大端序，Python的struct模块打包时要用!前缀指定网络字节序，否则在小端机器上拼出来的字段是反的。第三是校验和，IP头校验和需要先把校验和字段置0，对整个头部做16位反码求和，再取反填回去，这一步漏了或者算错了，很多系统会直接丢弃这个包。

import struct def build_ip_header(src_ip, dst_ip, payload_len, proto=socket.IPPROTO_UDP): version_ihl = (4 << 4) | 5 # IPv4，头部长度5字=20字节 tos = 0 # 服务类型，普通优先级 total_len = 20 + payload_len # IP头 + 载荷 identification = 54321 # 标识，随便给个值 flags_frag = 0 # 不分片 ttl = 64 # 生存时间 checksum = 0 # 先置0，后面算 src = socket.inet_aton(src_ip) dst = socket.inet_aton(dst_ip) # 先按校验和字段为0打包 header = struct.pack('!BBHHHBBH4s4s', version_ihl, tos, total_len, identification, flags_frag, ttl, proto, checksum, src, dst) # 计算校验和 def calc_checksum(data): if len(data) % 2: data += b'\x00' s = 0 for i in range(0, len(data), 2): w = (data[i] << 8) + data[i + 1] s += w s = (s & 0xffff) + (s >> 16) return (~s) & 0xffff checksum = calc_checksum(header) # 用算好的校验和重新打包 header = struct.pack('!BBHHHBBH4s4s', version_ihl, tos, total_len, identification, flags_frag, ttl, proto, checksum, src, dst) return header

calc_checksum这个函数是核心。它的逻辑是把数据按16位一组累加，累加过程中如果溢出16位就把高位加回低位（这叫反码求和），最后取反。注意如果数据长度是奇数要补一个0字节，否则会越界。这个函数不只用于IP头，后面解包验证时也能复用。

提示：校验和算错是新手最常见的错误之一。调试时可以先不算校验和（填0），看目标是否响应，确认其他字段没问题后再把校验和加回来，这样能把问题范围缩小。

2.3 UDP头与载荷：让探测包"看起来正常"

IP头拼好之后，后面要跟UDP头。UDP头只有8字节：源端口（16位）、目的端口（16位）、长度（16位）、校验和（16位）。UDP校验和是可选的，IPv4下填0表示不校验，这给我们省了不少事——毕竟UDP校验和还要算伪头部，比较麻烦。探测包的目的端口可以选一个大概率关闭的端口（比如高位端口），这样目标更可能回ICMP端口不可达，正好符合我们"收到回包即在线"的判断逻辑。

载荷部分可以放一点无害的数据，也可以留空。我一般放几个字节的标记字符串，方便在抓包时识别是自己发的探测包。整个探测包的结构就是：IP头（20字节）+ UDP头（8字节）+ 载荷（可选）。

def build_udp_probe(src_ip, dst_ip, dst_port=33434, payload=b'PROBE'): src_port = 40000 udp_len = 8 + len(payload) # UDP校验和填0，IPv4下表示不校验 udp_header = struct.pack('!HHHH', src_port, dst_port, udp_len, 0) udp_segment = udp_header + payload ip_header = build_ip_header(src_ip, dst_ip, len(udp_segment)) return ip_header + udp_segment

这里源端口我固定用40000，目的端口用33434（这个端口号在traceroute类工具里常见，选它没什么特殊含义，只是习惯）。实际使用时源端口可以随机化，避免多个探测包被中间设备做流关联。载荷用b'PROBE'这种短标记，既能让包看起来有内容，又不会触发什么奇怪的处理逻辑。

3. 收包之后：把IP header一个字节一个字节拆开

3.1 IP头字段的偏移量对照与解包代码

发包只是前半程，真正体现这个工具价值的是收包后的解码。原始套接字收到的数据是完整的IP包（Linux下如此），我们要做的就是把前20字节按字段偏移拆出来。对照RFC 791，各字段的字节偏移如下：

有了这张表，解包就是按偏移取字节再转换。用struct.unpack一次性解出固定部分最省事，格式串是!BBHHHBBH4s4s，和打包时对称。解出来之后，版本和头长还要再拆：version = first_byte >> 4，ihl = first_byte & 0x0F，头部实际长度是ihl * 4字节。

def parse_ip_header(packet): if len(packet) < 20: return None (version_ihl, tos, total_len, ident, flags_frag, ttl, proto, checksum, src, dst) = struct.unpack('!BBHHHBBH4s4s', packet[:20]) version = version_ihl >> 4 ihl = version_ihl & 0x0F header_len = ihl * 4 return { 'version': version, 'header_len': header_len, 'tos': tos, 'total_len': total_len, 'ident': ident, 'flags': flags_frag >> 13, 'frag_offset': flags_frag & 0x1FFF, 'ttl': ttl, 'proto': proto, 'checksum': checksum, 'src': socket.inet_ntoa(src), 'dst': socket.inet_ntoa(dst), }

这段代码里flags_frag的处理值得注意：它是一个16位字段，高3位是标志（保留位、DF不分片、MF更多分片），低13位是片偏移。用>> 13取标志，用& 0x1FFF取偏移，位运算在这里用得恰到好处。socket.inet_ntoa把4字节的二进制地址转成点分十进制字符串，比手动拼字符串省事。

3.2 校验和验证：判断回包是否完整可信

解出字段之后，一个负责任的实现应该验证IP头校验和。为什么？因为网络传输中包可能损坏，或者你收到的可能是个畸形包，不验证就采信字段值，可能得出错误结论。验证方法很简单：把收到的整个IP头（按头部长度截取）重新算一遍校验和，如果结果是0，说明校验通过（因为校验和字段本身包含了原始校验值，整体再算一遍反码求和取反应该是0）。

def verify_checksum(header_bytes): if len(header_bytes) % 2: header_bytes += b'\x00' s = 0 for i in range(0, len(header_bytes), 2): w = (header_bytes[i] << 8) + header_bytes[i + 1] s += w s = (s & 0xffff) + (s >> 16) return (~s) & 0xffff == 0

这个验证在实际使用中能帮你排除掉不少干扰。我实测时遇到过收到的包头部长度字段异常（比如ihl小于5），这种包直接丢弃，不参与判断。还有一种情况是包被截断，len(packet) < total_len，说明抓到的数据不完整，字段值不可信，也应该跳过。

3.3 从协议号反推对方是怎么回应的

解出协议号之后，判断逻辑就清晰了。协议号是IP头里的一个字节，标识上层承载的是什么协议。对我们这个工具来说，常见的几种值含义如下：

• 协议号1：ICMP。如果回包是ICMP，且类型是3（目的不可达）、代码是3（端口不可达），说明目标主机在线，但我们探测的UDP端口没开。这是UDP主机发现最典型的正面信号。
• 协议号17：UDP。说明目标端口上有服务在跑，直接回了UDP数据。这也是主机在线的强信号。
• 协议号6：TCP。这种情况比较少见，可能是路径上设备或目标主机回了TCP相关的包，需要结合源地址判断。

def classify_response(info, target_ip): if info['src'] != target_ip: return 'unknown', '回包源地址与目标不符' if info['proto'] == 1: return 'alive', '收到ICMP响应，主机在线' if info['proto'] == 17: return 'alive', '收到UDP响应，主机在线且端口有服务' if info['proto'] == 6: return 'alive', '收到TCP响应，主机在线' return 'unknown', f"未知协议号 {info['proto']}"

这里我特意加了源地址核对。前面提过，回包可能来自路径上的设备，如果源地址不是目标IP，这个回包不能作为目标在线的证据。这个判断看起来简单，但漏掉它会导致误报，尤其是在复杂网络里。

4. 把发包、收包、解码串成一个能跑的工具

4.1 主循环设计：超时、重试与结果收集

单个探测包的收发逻辑清楚了，接下来要把它组织成一个能对多个目标工作的工具。核心是一个循环：对每个目标IP，构造探测包、发送、在超时窗口内等待回包、解码、记录结果。超时设置很关键，设太短会漏掉响应慢的主机，设太长整体扫描时间会拖得很久。我的经验是单目标等1到2秒比较合适，内网环境可以更短。

import time def probe_host(sock, src_ip, target_ip, timeout=1.5): packet = build_udp_probe(src_ip, target_ip) sock.sendto(packet, (target_ip, 0)) sock.settimeout(timeout) deadline = time.time() + timeout while time.time() < deadline: try: data, addr = sock.recvfrom(65535) except socket.timeout: break info = parse_ip_header(data) if info is None: continue status, reason = classify_response(info, target_ip) if status == 'alive': return True, info, reason return False, None, '超时无响应'

sock.sendto(packet, (target_ip, 0))这里端口填0是因为我们已经在IP头和UDP头里写好了目的地址和端口，原始套接字发送时地址参数其实用不上，但接口要求给一个，填0即可。recvfrom的缓冲区给65535，保证能收下最大长度的IP包。

4.2 结果输出与TTL的辅助判断

收到正面响应后，把关键信息打印出来，方便使用者判断。除了源地址和协议号，TTL也值得输出。TTL的初始值在不同系统上不一样（常见的有64、128、255），每经过一个路由跳数减1，所以收到的TTL值能粗略反映跳数。虽然不精确，但在资产梳理时能提供一点线索。

def report(target_ip, alive, info, reason): if alive: print(f"[在线] {target_ip} | 源:{info['src']} " f"协议:{info['proto']} TTL:{info['ttl']} | {reason}") else: print(f"[无响应] {target_ip} | {reason}")

输出格式我倾向于一行一个目标，信息紧凑，方便重定向到文件后做后续处理。TTL字段单独列出来，是因为它在批量结果里能帮你快速区分"直连主机"和"跨了很多跳的主机"，对理解网络拓扑有帮助。

4.3 一个完整的可运行版本

把前面的片段拼起来，加上参数解析和主函数，就是一个完整工具。下面这版可以直接跑，注意需要管理员权限。

import socket import struct import sys import time def calc_checksum(data): if len(data) % 2: data += b'\x00' s = 0 for i in range(0, len(data), 2): w = (data[i] << 8) + data[i + 1] s += w s = (s & 0xffff) + (s >> 16) return (~s) & 0xffff def build_ip_header(src_ip, dst_ip, payload_len, proto=socket.IPPROTO_UDP): version_ihl = (4 << 4) | 5 total_len = 20 + payload_len src = socket.inet_aton(src_ip) dst = socket.inet_aton(dst_ip) header = struct.pack('!BBHHHBBH4s4s', version_ihl, 0, total_len, 54321, 0, 64, proto, 0, src, dst) csum = calc_checksum(header) header = struct.pack('!BBHHHBBH4s4s', version_ihl, 0, total_len, 54321, 0, 64, proto, csum, src, dst) return header def build_udp_probe(src_ip, dst_ip, dst_port=33434, payload=b'PROBE'): udp_len = 8 + len(payload) udp_header = struct.pack('!HHHH', 40000, dst_port, udp_len, 0) segment = udp_header + payload return build_ip_header(src_ip, dst_ip, len(segment)) + segment def parse_ip_header(packet): if len(packet) < 20: return None (vihl, tos, total_len, ident, ff, ttl, proto, csum, src, dst) = struct.unpack('!BBHHHBBH4s4s', packet[:20]) ihl = vihl & 0x0F if ihl < 5: return None return { 'version': vihl >> 4, 'header_len': ihl * 4, 'total_len': total_len, 'ttl': ttl, 'proto': proto, 'src': socket.inet_ntoa(src), 'dst': socket.inet_ntoa(dst), } def probe_host(sock, src_ip, target_ip, timeout=1.5): packet = build_udp_probe(src_ip, target_ip) sock.sendto(packet, (target_ip, 0)) sock.settimeout(timeout) deadline = time.time() + timeout while time.time() < deadline: try: data, _ = sock.recvfrom(65535) except socket.timeout: break info = parse_ip_header(data) if info is None or info['src'] != target_ip: continue if info['proto'] in (1, 6, 17): return True, info return False, None def main(): if len(sys.argv) < 3: print("用法: python probe.py <源IP> <目标IP1> [目标IP2 ...]") sys.exit(1) src_ip = sys.argv[1] targets = sys.argv[2:] try: sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.IPPROTO_UDP) sock.setsockopt(socket.IPPROTO_IP, socket.IP_HDRINCL, 1) except PermissionError: print("请用管理员/root权限运行") sys.exit(1) for t in targets: alive, info = probe_host(sock, src_ip, t) if alive: print(f"[在线] {t} 协议:{info['proto']} TTL:{info['ttl']}") else: print(f"[无响应] {t}") sock.close() if __name__ == '__main__': main()

这个版本跑起来后，对每个目标发一个UDP探测包，等1.5秒，收到合法回包就判在线。实测在内网环境里，对关闭端口的主机基本都能收到ICMP端口不可达，判断准确率不错。

5. 实测中那些文档不会告诉你的坑

5.1 回包源地址不是目标IP：最隐蔽的误判来源

这个坑我在第一次实测时就踩了。当时扫一个网段，结果里出现了几个"在线"的主机，但仔细一看源地址，根本不是目标IP，而是网关或者中间设备的地址。原因是有时候探测包发出后，路径上的设备会回ICMP不可达（比如路由不可达、管理禁止），这些回包的源地址是设备自己，不是目标主机。如果不核对源地址，就会把这些设备误判成目标在线。

修复方法前面代码里已经体现了：info['src'] != target_ip就跳过。但这里还有个细节，有些环境下目标主机会用不同的源地址回包（比如多网卡主机），严格核对可能漏判。我的处理原则是：优先严格核对，如果发现漏判严重，再考虑放宽到"源地址在同一网段"这种宽松判断，但要在输出里标注清楚，让使用者自己权衡。

5.2 权限、防火墙与本地回环的干扰

权限问题前面说过，这里补充一个容易忽略的点：即使你有root权限，本地防火墙也可能拦截你发出的原始包或者收到的回包。有些环境的安全策略会对原始套接字流量做额外检查，导致发包成功但收不到任何响应。排查这类问题时，可以先用抓包工具确认包到底发出去没有、有没有回包到达网卡，把问题定位在网络层还是应用层。

还有一个干扰源是本地回环。如果你探测的目标恰好是本机地址，回包可能走回环接口，原始套接字能不能收到取决于平台实现。我建议探测本机时单独处理，或者干脆跳过，避免把回环的特殊行为当成通用逻辑。

5.3 校验和、字节序、头部长度这三个高频错误点

把实测中反复出现的错误归归类，基本集中在三个地方。第一是校验和算错，表现为目标完全不响应或者回RST，因为校验和错误的包会被直接丢弃。第二是字节序搞反，struct打包时忘了加!，在小端机器上拼出来的字段全是反的，抓包一看版本号变成0x45的高低位颠倒。第三是头部长度字段填错，ihl填了5但实际头部不是20字节，或者解包时没按ihl * 4截取，导致后续字段偏移全错。

这三个错误的共同点是：代码能跑，不报异常，但结果就是不对。排查时最有效的手段是抓包对照，把你发出去的包和标准工具发的包逐字节比对，差异一目了然。我习惯在调试阶段把构造好的包用十六进制打印出来，对照RFC字段表一个字节一个字节看，虽然笨但很有效。

提示：调试原始套接字代码时，抓包工具是必需品。不要靠猜，直接看字节。

5.4 探测包被中间设备"吃掉"的几种情况

还有一种情况是包发出去了，但目标根本没收到，或者收到了但回包在途中被拦。常见原因包括：中间设备对异常UDP包做了过滤、目标主机所在网段禁止ICMP不可达回包、NAT设备改写了源地址导致回包路由不回来。这些情况从工具侧很难直接区分，表现都是"超时无响应"。

应对思路是分层排查：先确认本机发包正常（抓包看发出去了），再确认目标网段可达（用其他方式验证），最后看回包路径。如果确认是中间设备拦截，那这个工具在该环境下就不适用，得换探测方式。这也是为什么我在开头强调选型要看环境，没有一种探测方式能通吃所有场景。

6. 从这个小工具能延伸出去的几个方向

这个工具本身不大，但它涉及的知识点可以往好几个方向延伸。第一个方向是并发化，现在的实现是串行探测，扫大网段效率低，可以用多线程或者异步IO把等待时间重叠起来，但要注意原始套接字在多线程下的收包归属问题，多个线程同时recvfrom会互相抢包，需要设计好分发逻辑。

第二个方向是扩展解码范围。现在只解IP头，其实可以继续往下解UDP头和ICMP头，把端口号、ICMP类型代码也提取出来，这样判断依据更丰富。ICMP头的类型和代码字段能精确区分"端口不可达""主机不可达""管理禁止"等不同情况，对排查很有帮助。

第三个方向是换探测协议。同样的框架，把UDP换成TCP SYN或者ICMP Echo，只需要改构造包和解码判断的部分，收发包的主循环可以复用。这其实是理解协议探测工具共性的好方法——不同协议探测的差异主要在包的构造和响应的解读，骨架是相通的。

我个人在实际操作中的体会是，这类小工具的价值不在于功能多强，而在于它逼着你去理解每一个字节的含义。写完一遍、调通一遍、踩几个坑再修好，对网络协议的理解会比看十篇教程都扎实。如果你也想练手，建议从单目标探测开始，跑通了再扩到网段，每加一个功能就抓包验证一次，稳扎稳打。