Scapy实战：Python数据包构造、收发解析与网络排障

前段时间排查一个局域网里的通信异常，抓包软件翻来覆去看了半天，最后定位到一个自己拼的畸形报文上。当时我就在想，要是能直接用代码把包拼出来、发出去、再把回包收回来解析，整个流程脚本化，比在图形界面里点来点去省事得多。Python 的 scapy 库干的就是这个活——它把网络协议的每一层都抽象成可以随手拼装的 Python 对象，你写几行代码就能构造出一个完整的数据包，发出去，收回来，拆开看。它不是那种"调用一个函数帮你搞定一切"的高层封装，恰恰相反，它把细节全摊在你面前，你可以精确到某个标志位、某个序列号去改。这篇文章面向的是已经会一点 Python、想上手网络层实操的读者，也适合平时做协议验证、内网排障、教学演示的朋友。下面我按自己摸索的顺序，从装环境到写出能跑的脚本，把坑和技巧一并说清楚。

1. 环境准备与版本选择的那些事

1.1 三个平台的安装差异

scapy 的安装本身不复杂，一条pip install scapy就能把纯 Python 部分装好，但真正让人卡住的是底层抓包驱动。它依赖系统提供的数据链路层访问能力，Linux 上靠的是 libpcap，macOS 自带 BSD 的抓包接口基本可用，Windows 上则必须额外装一个 Npcap 驱动，而且安装时要勾选"支持 WinPcap API 兼容模式"这个选项，否则 scapy 起来之后conf.iface会是空的，或者一发包就抛出找不到网卡的异常。我第一次在 Windows 上折腾，就是因为漏勾了那个框，白白查了半个多小时。

Linux 侧的坑主要在权限。普通用户默认没有打开原始套接字（raw socket）的权限，直接用会收到 Permission denied。最省事的做法是临时sudo跑脚本，但长期这么干不优雅。比较稳妥的方式是给 Python 解释器加CAP_NET_RAW和CAP_NET_ADMIN两个能力，用setcap命令打上去，这样普通用户也能抓包发裸包。需要注意的是，每次升级 Python 解释器这个能力都会丢，得重新打一次，这个细节文档里很少提，但在自动化环境里特别容易踩。

macOS 上还有一个隐性的问题：较新版本系统对网卡访问做了限制，某些虚拟网卡（比如容器或虚拟化软件创建的网桥）在列表里能看到，但抓包时只能收到本机发出的包，收不到外部进来的。这种情况不是你代码写错了，换物理网卡验证一下就能确认。

提示：安装完先别急着写业务代码，跑一句from scapy.all import conf; print(conf.iface)，能打印出网卡名就说明链路层通了。这一步没通过，后面所有操作都是空中楼阁。

1.2 依赖库与"能跑起来"的最小验证

scapy 本身是"可选依赖"设计，核心功能不装额外库也能用，但如果你想解析 pcap 文件、做 TLS 层解析、画个简单的报文图，就需要补装几个。常见的搭配是pip install scapy[complete]，它会把 cryptography、matplotlib 这些一并拉下来。我的建议是先用最小安装跑通，确定自己真的需要哪一块再补，不然装一堆用不上的东西，依赖冲突排查起来更烦。

最小验证我一般分三步走。第一步，构造一个 ICMP 包并打印它的结构，确认分层拼装正常；第二步，用sr1向本机回环地址发一个包，确认发送接收链路正常；第三步，用sniff抓几个包，确认嗅探功能正常。这三步覆盖了 scapy 最核心的三条腿：构造、收发、嗅探，任何一步失败都能快速定位问题在哪个环节。

from scapy.all import IP, ICMP, sr1, sniff # 第一步：构造，只看不设置网络 pkt = IP(dst="127.0.0.1") / ICMP() print(pkt.summary()) # 第二步：发送并等一个回包 resp = sr1(pkt, timeout=2, verbose=False) print(resp.summary() if resp else "没收到回包") # 第三步：抓三个包看看 sniff(count=3, prn=lambda p: p.summary())

回环地址做验证有个好处：完全不出本机，不打扰任何人，也避开了防火墙和路由的干扰。等这三步都过了，再去碰真实网段。我见过不少人一上来就往外部地址发包，结果收不到回应，分不清是自己代码写错了、网络不通、还是对方策略拦了，白白绕远路。

1.3 虚拟环境与版本兼容的取舍

scapy 的版本迭代挺活跃，2.4 到 2.5 再到 2.6，API 有过几次调整，比如网卡列表函数在 2.5 之后推荐用show_interfaces()替代老的show_if_list()，路由表相关的一些属性也有变动。如果你照着两三年前的教程写，很可能遇到"函数不存在"或者"属性为空"这类问题。我的习惯是固定版本，在虚拟环境里锁住scapy==2.5.0这种写法，等项目稳定了再考虑升级。

虚拟环境这块还有个细节：scapy 的配置对象conf是全局单例，脚本里改过之后，同一个进程内后续所有操作都会继承。这在写单文件小脚本时没什么，但如果你把代码封装成模块被别的程序调用，就可能出现"别人调你的函数，结果发现自己程序的默认网卡被改了"这种诡异现象。解决办法是在自己模块内部显式指定参数，不去动全局配置，需要改的时候用上下文管理器包一层，用完恢复。

2. 分层构造：把数据包当成积木来搭

2.1 "/" 操作符背后的对象模型

scapy 最核心的设计就是那个斜杠。IP()/TCP()看上去像除法，实际上是重载过的运算符，作用是把两个 Packet 对象按层次串起来。前一个对象成为后一个的"底层承载"，后一个对象挂在前一个的 payload 属性上。这个模型非常贴近真实的协议栈：以太网头承载 IP 头，IP 头承载 TCP 头，TCP 头承载应用数据。你用斜杠连起来，就等于在描述"谁装在谁里面"。

理解了这个模型，很多操作就顺理成章了。比如想取某一层，用下标访问pkt[IP]或者pkt[TCP]，它会在包里找对应类型的层；想判断有没有某一层，用IP in pkt或者pkt.haslayer(IP)；想从某一层开始截取剩下的部分，用pkt[IP:]切片。这些操作在解析复杂报文时特别顺手，比如你收到一个带 VLAN 标签的包，想跳过以太网头和 802.1Q 头直接看 IP 层，一行pkt[IP]就拿到了，不用自己去算偏移量。

各层的字段用属性方式读写。ip = IP(dst="192.168.1.1"); ip.ttl = 32这样就行。这里有个容易忽视的点：如果你修改了某一层的某个字段，而这个字段的值会影响另一层（比如 IP 头的长度字段、TCP 的校验和），scapy 在发送时会自动重算，但你在内存里直接show()看到的还是旧值。想看重算之后的样子，用show2()，它会先做一遍组装再显示。这个差别我最初没注意，一直纳闷为什么改完长度字段显示没变。

from scapy.all import Ether, IP, TCP, Raw pkt = Ether() / IP(dst="192.168.1.10") / TCP(dport=80) / Raw(load="hello") pkt.show() # 显示当前内存中的字段值 pkt[IP].ttl = 12 # 改 TTL pkt.show2() # 重新组装后再显示，长度、校验和会更新

2.2 字段默认值、随机值与自动计算

scapy 给每个字段都设了默认值，这一点对新手既友好又危险。友好在于你写IP()/TCP()就能得到一个结构完整、可以直接发出去的包；危险在于你可能根本没意识到某些字段是怎么来的。比如 TCP 的源端口默认是 20，IP 头的 TTL 默认是 64，以太网的源 MAC 在没指定时会取当前网卡的地址，目的 MAC 在知道目的 IP 的情况下会去查 ARP 缓存自动填充。这些"贴心"行为在正常场景下省事，在做精确控制的时候就得留个心眼。

想要更贴近真实流量的随机性，scapy 提供了一批 Rand 开头的字段生成器。RandIP()生成随机 IP，RandShort()生成随机 16 位整数，RandMAC()生成随机 MAC。注意它们不是直接赋值，而是作为字段的默认值传入，比如IP(src=RandIP())。这种写法在同一个包被多次组装时会每次生成新值，这一点和直接写死一个随机数不一样，批量发送的时候要留意。

字段值还有一种"延迟计算"的用法：把字段设成None，scapy 会在组装时自动推算。最典型的是 IP 头的长度字段和校验和字段，你写IP(len=None, chksum=None)，它会在发送前根据实际的载荷长度和内容算出来。这个特性在你自己拼接不定长载荷时特别有用，不用手动去数字节数。同理，TCP 的校验和涉及伪首部计算，手算容易错，设成 None 交给库处理最稳妥。

注意：手动指定了校验和但又改了载荷内容，会导致包被对端丢弃。如果你的脚本先设置chksum再追加数据，务必在最后把chksum重置为 None 让它重算。

3. 发出去与收回来：send/sr 系列 API 的选择

3.1 几个发送函数的区别与使用场景

scapy 的发送函数名字很像，功能差别不小，用错了轻则收不到回应，重则报文根本发不出去。我的经验是可以按"发哪一层"和"要不要答案"两个维度来分。

发三层（IP 层及以上）用send()，它只发不收，适合做单向的探测或者批量灌包。发二层（以太网帧）用sendp()，需要你显式指定网卡，因为二层帧没有路由信息，库不知道该从哪个网卡出去。这两个是"只管发"的版本，对应的"发并等答案"版本是sr()和srp()，返回两个列表：收到了回应的和没收到回应的。"只要第一个回应"的版本是sr1()，它返回单个包对象或者 None，写交互式脚本时最方便。

选择哪种，关键看你关心什么。如果你只是想让对端收到一个报文，比如测某个端口开不开、触发一次特定的协议交互，用send就够。如果你需要拿到回包做后续分析，用sr1最简洁，它内部会帮你匹配请求和响应。如果是批量探测，比如对一段地址逐个发，用sr能拿到完整的成功失败列表，方便统计。

有个细节值得说：sr和sr1默认会把回包和请求做匹配，靠的是 IP ID、端口这类字段的对应关系。如果你的请求包字段都是默认值，批量发的时候可能出现匹配错乱，拿到别人的回包。解决办法是给每个包一个不一样的标识，比如递增的 IP ID 或者源端口，这样匹配就准了。

3.2 超时、重试与结果对象的解析

超时设置是个必须认真对待的参数。默认超时比较短，跨网段或者对端响应慢的时候很容易"假失败"。我通常按目标距离来设：同局域网 1 到 2 秒足够，跨路由 3 到 5 秒，跨运营商或者对方响应本来就慢的，给到 8 秒以上。超时设太长的副作用是脚本整体耗时飙升，尤其是批量扫的时候，几百个地址每个等 8 秒，跑一次要小半天。

retry参数控制重发次数，默认是 1 次也就是不重发。网络有轻微丢包的环境下，设成 2 到 3 次能明显提高成功率，代价是失败的目标耗时翻倍。还有个inter参数控制发包间隔，默认是 0 也就是连着发。这个参数在探测带速率限制的设备时特别重要，间隔设成 0.05 到 0.1 秒，能避开大部分设备的限速策略，成功率会好看很多。

结果对象的解析是新手容易迷糊的地方。sr返回的是一个二元组，第一个是"发了且有回应"的列表，每个元素是(发出的包, 收到的包)这样的配对；第二个是"发了没回应"的列表。想看汇总，直接调.summary()就能打印成可读格式。想遍历，就for sent, recv in ans:这样拆包。我建议先把ans的长度打出来看一眼，再看几条具体内容，心里有个数再往下写逻辑。

from scapy.all import IP, ICMP, sr ans, unans = sr( IP(dst="192.168.1.0/28") / ICMP(), timeout=2, retry=2, inter=0.05, verbose=False, ) print(f"有回应 {len(ans)} 个，无回应 {len(unans)} 个") for sent, recv in ans: print(sent[IP].dst, "->", recv[IP].src, recv[ICMP].type)

4. 嗅探与落地：sniff 和 pcap 读写

4.1 sniff 的参数组合与回调写法

sniff是日常用得最多的函数。它的核心参数就那么几个：iface指定网卡，count指定抓多少个包就停，prn是每抓到一个包就调一次的回调函数，filter是 BPF 过滤表达式，timeout是抓多久就停，store决定要不要把包留在内存里。

prn的写法直接决定脚本的可读性。最简单的是传个 lambda，prn=lambda p: p.summary()，一行搞定打印。稍微复杂点就定义个具名函数，在里面做解析、判断、落盘。我推荐后者，尤其是逻辑超过三行的时候，lambda 里塞太多东西调试起来费劲，出错了堆栈指向也不清晰。

store=False这个参数值得单独提。默认情况下 sniff 会把抓到的每个包都存在一个列表里，抓几千个包内存还好，抓几十万个就明显吃内存了。如果你的处理逻辑是"来一个处理一个"（比如统计、落盘、实时告警），把 store 设成 False，包处理完就释放，内存占用能压到很低。我之前写一个长时间运行的监控脚本，忘了设这个参数，跑了一晚上内存吃了两个多 G，第二天才反应过来。

filter用的是 BPF 语法，它由底层的抓包库解析，效率比在 Python 侧用if判断高得多，因为过滤发生在内核态，不匹配的包根本不会送到用户态。语法上常见的写法有tcp port 80、udp and host 10.0.0.5、icmp、not arp。注意如果系统里没装 libpcap，这个参数会报错，提示 filter 不可用，这时候要么补装依赖，要么退回用 Python 侧判断。

from scapy.all import sniff, wrpcap buffer = [] def on_packet(pkt): if pkt.haslayer("IP"): buffer.append(pkt) print(pkt["IP"].src, "->", pkt["IP"].dst) sniff( iface="eth0", filter="tcp port 443", prn=on_packet, count=100, timeout=30, store=False, ) if buffer: wrpcap("collected.pcap", buffer)

4.2 离线 pcap 的读写与回放

scapy 对 pcap 文件的支持做得挺完整。rdpcap()一次性把文件读成包列表，wrpcap()把列表写回文件，PcapWriter适合边抓边写、持续追加的场景。读出来的东西就是普通的 Packet 对象列表，可以像操作内存里的包一样做切片、过滤、字段修改。

这里有个实用技巧：读大文件的时候，rdpcap会把全部内容载入内存，几百兆的文件就可能把机器拖慢。scapy 提供了PcapReader，它是迭代器，一次只读一个包，配合生成器写法可以做到流式处理。处理逻辑如果只是统计、筛选、转换格式，用这个更合适。

回放是个有意思的用法。你把 pcap 读出来，改掉源 IP、目的 IP，再用sendp发出去，相当于重现一段流量。这在协议测试、设备联调时很有用。但要注意两点：一是回放会改变原始的时间间隔，sendp是尽最大速度发的，想要保真得自己按时间戳加延时；二是回放的包如果带校验和，改了字段之后要把它重置为 None 让库重算，否则对端会直接丢掉。

还有一种场景是"边抓边分析"。我用过一个思路：sniff 的prn里不做重活，只把包塞进一个队列，另起一个线程从队列里取出来做解析和统计。这样抓包线程不会因为解析慢而丢包。这个模式在高速流量下几乎是必须的，单线程边抓边做复杂解析，丢包率会很高。

5. 两个真实场景的实操记录

5.1 局域网地址探测与响应分析

我经常需要在自建的小型实验网络里确认某些地址是否有设备在线。用常规的 ping 命令一个个敲太慢，写个 scapy 脚本批量发 ICMP 更省事。思路很简单：构造一批IP(dst=...)/ICMP()，用sr发出去，看哪些有回。

from scapy.all import IP, ICMP, sr, conf targets = [f"192.168.1.{i}" for i in range(1, 33)] ans, unans = sr( IP(dst=targets) / ICMP(), timeout=2, retry=1, inter=0.03, verbose=False, ) online = sorted({recv[IP].src for _, recv in ans}) print("在线地址：", online)

这段代码在实际跑的时候有几个点要注意。第一，ICMP 回应的类型字段要看一下，正常回应是 type 0，但也可能收到 type 3（目标不可达）之类的，那说明中间有设备在回你，不代表目标主机在线。第二，有些设备会屏蔽 ICMP 但端口是开的，所以光靠 ICMP 判断在线会有漏网，想更全面就配合 TCP SYN 探测。第三，批量发的时候注意间隔，太密集可能触发某些设备的防护策略，反而什么都收不到。

ARP 层也可以做类似的事情，而且比 ICMP 更可靠，因为 ARP 是二层协议，不受三层防火墙影响。发一个广播的 ARP 请求，谁在线谁就会回应。这个操作只应该在自己管理或明确授权的网络里做，别在别人的网络环境里随便扫。

5.2 自定义协议字段的抓包解析

scapy 另一个让我觉得好用的地方是能定义自己的协议层。假设我在做一个自研的通信模块，报文格式是固定的：1 字节类型、2 字节长度、4 字节序号、然后是不定长的载荷。用 scapy 定义出来之后，抓包时就能像看标准协议一样一层层展开。

from scapy.all import Packet, ByteField, ShortField, IntField, StrLenField from scapy.all import UDP, bind_layers class MyProto(Packet): name = "MyProto" fields_desc = [ ByteField("msg_type", 1), ShortField("length", None), IntField("seq", 0), StrLenField("payload", b"", length_from=lambda p: p.length), ] bind_layers(UDP, MyProto, dport=9999)

定义好之后，抓到的包只要 UDP 目的端口是 9999，就会自动按这个结构解析。length_from这个参数是关键，它让载荷长度跟随前面定义的 length 字段走，实现变长解析。如果没有它，载荷会被当成定长，多出来的字节就丢了。

bind_layers的绑定是有条件的，可以指定端口、类型字段等。多个绑定同时命中时，后绑定的优先级更高，这个顺序在调试自定义协议时容易忽略。我遇到过一次"解析结果不对"，查了半天发现是另一个端口相同的协议绑定把解析抢走了，把绑定条件写得更具体就解决了。

5.3 时间戳与性能数据的一次实测

链路层的响应时间是个值得关注的指标。scapy 抓到的每个包都带时间戳，pkt.time是个十进制浮点数，单位秒。想算往返时延，就拿回包时间减去发包时间。这里要注意时钟精度：有些平台的抓包时间戳精度只到微秒，跨机器比对会有偏差，同机比对才比较准。

我做过一次小规模实测，在同一台机器上对 32 个内网地址发 ICMP，间隔 0.03 秒，超时 2 秒。统计下来，局域网内正常响应的时延集中在 1 到 3 毫秒，少数设备在 8 到 15 毫秒，还有两个地址完全无响应。整个脚本跑完不到三秒。对比用系统 ping 命令逐个执行，同样的地址集合要二十多秒。这个差距主要来自进程启动开销和串行等待，scapy 在脚本里批量构造、异步收发，效率高得多。

不过也别迷信这个数字。scapy 是纯 Python 实现，构造大量复杂包的时候，Python 层的开销会显现出来。我试过构造一万个带自定义载荷的包，光拼接就花了两三秒。如果对吞吐有硬要求，可以考虑把构造和发送分开，用多进程并行，或者干脆换更底层的库。多数排障和验证场景下，scapy 的速度完全够用。

6. 常见问题与排查技巧实录

6.1 权限、网卡、过滤器三座大山

新手遇到的问题里，九成集中在三件事上：没权限、网卡选错、过滤器写错。这三个问题的报错信息往往很含糊，容易让人往错误的方向查。

权限问题的典型表现是PermissionError或者Operation not permitted。在 Linux 上要么加 sudo，要么给解释器打能力标记。Windows 上则是 Npcap 没装好或者装的版本不匹配，表现可能是能构造包但发不出去，或者发出去没反应。

网卡选错的表现更隐蔽：脚本不报错，但抓不到任何包，或者只能抓到本机的流量。这是因为默认网卡可能是个虚拟网卡或者回环网卡。排查办法是先打印conf.iface看看当前默认是哪块，再show_interfaces()列出全部，手动指定对的。名字里带 docker、vmnet、vbox 的一般是虚拟网卡，别选错。

过滤器写错会直接抛异常，提示语法错误。BPF 的语法和常见编程语言的逻辑表达式不太一样，and、or、not是小写，字段名要符合协议规范，比如tcp[tcpflags] & tcp-syn != 0这种位运算写法。建议先用最简单的tcp或icmp验证能用，再逐步加条件。

注意：在容器环境里抓包，默认只能看到容器自己网卡上的流量。想抓宿主机或者别的容器的流量，需要把网卡共享出来，这是环境配置问题，不是代码问题。

6.2 报错与现象速查表

下面这张表是我这些年攒下来的，遇到问题先对一遍，能省不少时间。

除了表里这些，还有一个不算问题但常让人困惑的现象：show()显示的长度和实际发出去的不一致。前面提过，show()看的是内存里的值，show2()才会触发组装重算。遇到长度、校验和相关的疑惑，一律用show2()看。

6.3 几个我踩过的坑和应对思路

第一个坑是网卡名称。Linux 下的网卡名可能是eth0、ens33、enp0s3各种形式，硬编码在脚本里换个机器就废了。我的做法是不指定 iface，让它走默认，需要明确指定的时候从conf.iface读出来作为默认值，或者做成命令行参数。这样脚本的可移植性好很多。

第二个坑是发包过快导致本机网卡队列溢出。批量发的时候如果inter设成 0，包的构造速度超过网卡发送速度，本机会直接丢掉一部分，你以为是网络丢包，其实是自己发太猛。加个几十毫秒的间隔，问题就没了。这个现象在虚拟机和配置较低的机器上尤其明显。

第三个坑是混淆了三层和二层发送。用send发一个只有 IP 层的包，库会自己查路由、找网卡、补以太网头；用sendp发同样的包，因为没有以太网层，会直接报错。反过来，用send发一个带了完整以太网头的包，那个以太网头会被当成载荷塞进 IP 包里面，发出去的东西完全不是你想的样子。判断标准很简单：包里有没有Ether()这一层，有就用sendp，没有就用send。

第四个坑是脚本跑在后台时的输出。scapy 的verbose默认是开的，会往终端打一堆进度信息。放在交互式终端里无所谓，做成定时任务或者后台服务的时候，这些输出可能把日志撑爆，或者因为终端不可写而抛异常。养成习惯，正式脚本里把verbose=False加上。

最后一个，关于结果的可靠性。sr1返回 None 的时候，可能是真的没回应，也可能是回应来晚了、被中间设备拦了、或者匹配逻辑没对上。别一看到 None 就下结论说目标不通，多试几次，换个探测方式，交叉验证一下。网络这东西，单次结果的说服力很有限，多跑几轮看趋势才靠谱。