简介：这是一套基于PCAP库实现的轻量级网络入侵检测系统（IDS）源码项目，面向计算机、电子信息及数学相关专业的本科生，适用于课程设计、期末大作业与毕业设计参考。项目采用C语言为主开发，辅以Python脚本和Shell测试工具，涵盖数据包捕获、协议解析、异常流量识别等核心功能模块，具备完整可运行的工程结构与清晰的多线程调度逻辑。压缩包共17个文件，含6个C源文件、4个头文件（.h）、2个Makefile构建脚本、1个Python攻击模拟脚本（arp-poison.py）、1个PDF课程文档（CS241 Coursework 2021-2022）、1个Markdown说明文档及配套测试脚本与配置文件，整体体积仅889KB，便于快速部署与代码研读。已有354人学习下载，读者可直接运行调试，深入理解基于libpcap的底层网络监控机制、状态机建模思路及典型攻击特征提取方法，特别适合夯实C语言系统编程能力与网络安全实践认知。
1. 这不是又一个“抓包+打印”的玩具项目：它用纯 C 实现了带状态跟踪的轻量级 IDS，能实时识别 SYN Flood、ICMP Flood 和 ARP 欺骗三类攻击，且所有逻辑跑在用户态线程池里——适合嵌入式边缘设备或课程设计中要求“看懂每一行”的硬核场景
你可能已经下载过几十个标着“网络入侵检测”的 GitHub 项目，解压后发现只是tcpdump -i eth0 -w test.pcap加个 Python 脚本读 pcap 文件再if 'SYN' in pkt and pkt[TCP].flags == 2: print('疑似SYN Flood')——这种叫流量日志分析，不是入侵检测。而这个基于 PCAP 的系统，从sniff.c开始就绕开了 libpcap 的高层封装，直接调用pcap_open_live()+pcap_setnonblock()构建零拷贝嗅探循环；dispatch.c里用 ring buffer + atomic counter 实现无锁分发；analysis.c中维护了三个独立的状态机：TCP 连接表（含半开连接计数）、ICMP 请求速率滑动窗口（5 秒桶）、ARP 表项冲突检测器。它不依赖 Suricata 规则引擎，也不跑在内核模块里，整个二进制不到 350KB，make && ./ids启动后就能在树莓派 4B 上稳定捕获 800Mbps 流量并实时告警。如果你正被课程设计要求“手写协议解析”“实现状态跟踪”“避免使用现成 IDS 框架”，或者毕设需要可审计、可裁剪、无第三方依赖的底层 IDS 骨架——这个源码包就是为你写的。它不是 demo，是能编译、能跑通、能改、能 debug 的工业级教学骨架。
2. 从 Makefile 到 main.c：五步构建可调试的 IDS 执行体，每一步都决定你能否看到真实告警
2.1 理解 Makefile 的三层结构：为什么它不用 autotools 却能跨平台编译
这个项目的 Makefile 不是简单罗列.c → .o → binary，而是分层组织了编译控制流、依赖图生成和测试集成三部分：
# 第一层：编译控制（核心变量） CC = gcc CFLAGS = -Wall -Wextra -O2 -std=c99 -pthread -I. LDFLAGS = -lpthread -lpcap # 第二层：依赖图自动生成（关键！） SRCS = main.c sniff.c dispatch.c analysis.c OBJS = $(SRCS:.c=.o) DEPS = $(SRCS:.c=.d) # 第三层：目标规则（含隐式规则覆盖） %.o: %.c $(CC) $(CFLAGS) -MMD -MP -c $< -o $@ -include $(DEPS)提示：
-MMD -MP是本项目能稳定编译的关键。它让 gcc 自动生成.d文件（如sniff.d），记录sniff.o依赖的所有头文件（sniff.h,dispatch.h,analysis.h），当任一头文件修改时，make会自动重编对应.o。很多初学者删掉这行，结果改了analysis.h却没触发analysis.o重编，导致 struct 字段错位、内存越界——这是后续所有“程序崩溃但 gdb 看不出问题”的根源。
CFLAGS中-std=c99明确限定语言标准，避免//注释或for (int i=0; ...)在老 GCC 下报错；-pthread不仅链接线程库，还定义_REENTRANT宏，影响errno处理方式；-I.让所有#include "xxx.h"直接从当前目录找，省去路径拼接错误。
2.2 main.c 的四阶段初始化：为什么init_dispatch()必须在start_sniffer()之前调用
main.c的入口逻辑看似简单，实则暗藏状态依赖：
int main(int argc, char *argv[]) { if (argc < 2) { fprintf(stderr, "Usage: %s <interface>\n", argv[0]); return 1; } // 阶段1：全局资源预分配（不可逆） if (!init_dispatch()) { // ← 关键！必须最先调用 fprintf(stderr, "Failed to init dispatcher\n"); return 1; } // 阶段2：嗅探器绑定（依赖 dispatch 已就绪） pcap_t *handle = start_sniffer(argv[1]); if (!handle) return 1; // 阶段3：分析器启动（依赖 dispatch 和 handle） if (!start_analyzer(handle)) { pcap_close(handle); return 1; } // 阶段4：主循环（等待 Ctrl+C） signal(SIGINT, sigint_handler); pause(); // 阻塞等待信号 cleanup(); // 释放所有资源 return 0; }init_dispatch()做了三件事：
① 分配dispatch_queue（ring buffer，大小为QUEUE_SIZE=1024）；
② 初始化worker_threads数组（默认 4 个线程）；
③ 设置atomic_int active_workers = 0。
如果把这个调用放到start_sniffer()之后，sniff.c中的pcap_loop()回调函数packet_handler()会尝试往未初始化的 queue 里 push packet，直接触发 SIGSEGV。这不是 bug，是设计契约：dispatch 模块必须是第一个被初始化的子系统。
2.3 sniff.c 的非阻塞模式陷阱：为什么pcap_setnonblock()比pcap_open_live()更关键
sniff.c的核心是start_sniffer()函数，它不走pcap_loop()而用pcap_next_ex()手动轮询：
pcap_t* start_sniffer(const char *dev) { char errbuf[PCAP_ERRBUF_SIZE]; pcap_t *handle = pcap_open_live(dev, BUFSIZ, PCAP_PROMISC, 1000, errbuf); if (!handle) { fprintf(stderr, "pcap_open_live: %s\n", errbuf); return NULL; } // 关键：必须设为非阻塞！否则 pcap_next_ex() 会卡死 if (pcap_setnonblock(handle, 1, errbuf) == -1) { fprintf(stderr, "pcap_setnonblock: %s\n", errbuf); pcap_close(handle); return NULL; } return handle; }pcap_setnonblock(handle, 1, ...)是生死线。若不设，pcap_next_ex()在无包时会永久阻塞，主线程无法响应SIGINT，pause()形同虚设。而pcap_open_live()的timeout_ms=1000参数只对pcap_loop()生效，对pcap_next_ex()无效——这是 libpcap 文档里埋得最深的坑之一。我当年在树莓派上调试时，Ctrl+C没反应，gdb 发现线程卡在pcap_next_ex的select()系统调用里，查了三天才翻到 libpcap FAQ 第 7 条。
2.4 dispatch.c 的 ring buffer 实现：如何用__atomic_load_n()避免锁竞争
dispatch.c的dispatch_queue是一个典型的生产者-消费者环形队列，但没用 mutex，而是靠原子操作：
typedef struct { packet_t *buffer[QUEUE_SIZE]; atomic_int head; // 生产者写入位置 atomic_int tail; // 消费者读取位置 } dispatch_queue_t; bool dispatch_push(dispatch_queue_t *q, packet_t *pkt) { int h = __atomic_load_n(&q->head, __ATOMIC_ACQUIRE); int t = __atomic_load_n(&q->tail, __ATOMIC_ACQUIRE); if ((h + 1) % QUEUE_SIZE == t) return false; // 满 q->buffer[h] = pkt; __atomic_store_n(&q->head, (h + 1) % QUEUE_SIZE, __ATOMIC_RELEASE); return true; } packet_t* dispatch_pop(dispatch_queue_t *q) { int t = __atomic_load_n(&q->tail, __ATOMIC_ACQUIRE); int h = __atomic_load_n(&q->head, __ATOMIC_ACQUIRE); if (t == h) return NULL; // 空 packet_t *pkt = q->buffer[t]; __atomic_store_n(&q->tail, (t + 1) % QUEUE_SIZE, __ATOMIC_RELEASE); return pkt; }这里__atomic_load_n和__atomic_store_n是 GCC 内置原子操作，比pthread_mutex_lock()快 3~5 倍。注意ACQUIRE/RELEASE内存序：push时先 store data 再 store head，pop时先 load tail 再 load data，保证数据可见性。如果你用-std=c99编译却调用stdatomic.h，会报错——本项目刻意避开了 C11 标准，全部用 GCC builtin，兼容 GCC 4.8+。
2.5 analysis.c 的三类检测器：SYN Flood 不是数 SYN 包，而是看半开连接堆积速率
analysis.c的analyze_packet()函数是 IDS 的大脑，它不做深度包检测（DPI），而是做状态异常检测：
void analyze_packet(const u_char *pkt, struct pcap_pkthdr *header) { const struct ip *ip = (const struct ip*)(pkt + ETHER_HDR_LEN); if (ip->ip_p == IPPROTO_TCP) { const struct tcphdr *tcp = (const struct tcphdr*)((u_char*)ip + (ip->ip_hl << 2)); if (tcp->th_flags & TH_SYN) { // 收到 SYN uint32_t key = ip->ip_src.s_addr ^ ip->ip_dst.s_addr ^ ntohs(tcp->th_sport) ^ ntohs(tcp->th_dport); syn_table_add(key); // 记录半开连接 if (syn_table_rate_exceed(5)) { // 5秒内 > 100 个新 SYN log_alert("SYN Flood detected: %d new connections/sec", syn_table_get_rate()); } } else if (tcp->th_flags & TH_ACK) { // 收到 ACK，清理半开表 uint32_t key = ip->ip_dst.s_addr ^ ip->ip_src.s_addr ^ ntohs(tcp->th_dport) ^ ntohs(tcp->th_sport); syn_table_remove(key); } } }注意：SYN Flood 检测不是统计tcp->th_flags == 2的包数，而是维护syn_table（哈希表）记录每个(src_ip, dst_ip, src_port, dst_port)组合的半开连接，并用滑动窗口计算单位时间新增连接速率。syn_table_rate_exceed(5)内部用clock_gettime(CLOCK_MONOTONIC)计算最近 5 秒窗口内的插入次数。ICMP Flood 同理，但用icmp->icmp_type == ICMP_ECHO+ 时间桶计数；ARP 检测则对比arp->ar_op == htons(ARPOP_REQUEST)的ar_spa和ar_tpa是否与本地 ARP 表冲突。
3. 抓包、注入、验证：用 test.sh 和 arp-poison.py 构建闭环测试链路
3.1 test.sh 的三阶段验证：从静默运行到告警触发，每步都可断点调试
test.sh不是简单的./ids eth0 &，而是分阶段验证：
#!/bin/bash INTERFACE=${1:-lo} # 默认用 lo，避免权限问题 echo "[1/3] 启动 IDS 并后台运行" ./ids "$INTERFACE" > /tmp/ids.log 2>&1 & IDS_PID=$! sleep 1 echo "[2/3] 发送合法流量（HTTP GET）建立 baseline" curl -s http://localhost:8000 > /dev/null 2>&1 sleep 1 echo "[3/3] 触发 SYN Flood（500 个并发）" for i in $(seq 1 500); do timeout 0.1 nc -z -w1 localhost 8080 2>/dev/null & done wait echo "等待 3 秒收集告警..." sleep 3 kill $IDS_PID 2>/dev/null echo "检查日志是否含 'SYN Flood detected'" grep "SYN Flood detected" /tmp/ids.log这个脚本的价值在于可复现、可中断、可定位：
[1/3]启动后sleep 1，确保ids进入主循环，此时可用gdb -p $IDS_PID附加调试；[2/3]用curl发送 HTTP 流量，验证 TCP 正常连接不触发误报；[3/3]用nc并发打端口，模拟真实 Flood，timeout 0.1强制快速失败，避免连接堆积干扰；- 最后
grep检查日志，而非ps aux | grep ids，因为告警是异步写入文件的。
注意：
test.sh默认用lo（回环接口），避免eth0权限问题。若要测物理网卡，需sudo ./test.sh eth0，且确保ids有CAP_NET_RAW能力（sudo setcap cap_net_raw+ep ./ids）。
3.2 arp-poison.py 的双机拓扑：为什么它比单机 nc 更贴近真实攻击面
arp-poison.py是一个精简版 ARP 欺骗工具，但它不是为了“中间人”，而是为了触发 IDS 的 ARP 表冲突检测：
#!/usr/bin/env python3 from scapy.all import * import sys def arp_spoof(target_ip, gateway_ip, interface="eth0"): # 构造欺骗包：告诉 target，gateway 的 MAC 是我的 pkt = ARP(op=2, pdst=target_ip, hwdst="ff:ff:ff:ff:ff:ff", psrc=gateway_ip, hwsrc=get_if_hwaddr(interface)) send(pkt, iface=interface, verbose=0) if __name__ == "__main__": if len(sys.argv) != 4: print("Usage: ./arp-poison.py <target_ip> <gateway_ip> <interface>") sys.exit(1) arp_spoof(sys.argv[1], sys.argv[2], sys.argv[3])它只发一个ARP Reply（op=2），不持续刷新，目的是让 IDS 在analysis.c的arp_check_conflict()中检测到：同一 IP 地址（gateway_ip）在短时间内被不同 MAC 地址声明。真实攻击中，攻击者会持续发送，但本项目只需一次即可触发告警——这是教学设计的取舍：检测逻辑必须简单、可验证、无漏报。用scapy而非c实现，是因为 Python 更易构造任意字段，且test.sh可直接调用，无需额外编译。
3.3 CS241 Coursework 2021-2022.pdf：课程设计原始需求文档里的隐藏约束
CS241 Coursework 2021-2022.pdf是剑桥大学 CS241 课程的原始作业说明，它规定了本项目不可绕过的硬约束：
| 条款 | 原文摘录 | 本项目实现方式 |
|---|---|---|
| C1 | "You must implement all packet parsing manually, without using libnetfilter or similar high-level libraries." | 所有 IP/TCP/ICMP/ARP 解析均用 pointer arithmetic 手写，如ip = (struct ip*)(pkt + 14)，无libtins或dpkt |
| C2 | "Your detector must run as a single user-space process, no kernel modules allowed." | 全部逻辑在main()进程内，dispatch.c的 worker threads 是 pthread，非 kthread |
| C3 | "You must provide a Makefile that builds the binary with 'make', and runs tests with 'make test'." | Makefile中定义了test: test.sh目标，make test即执行./test.sh |
| C4 | "All memory allocations must be checked for failure, and freed on exit." | malloc()后必有if (!ptr) { perror("malloc"); exit(1); }，cleanup()函数显式free()所有 buffer |
这份 PDF 是理解代码风格的钥匙。比如sniff.c里反复出现的if (!pkt) { fprintf(stderr, "malloc failed\n"); exit(1); }，不是冗余，是 C1 的强制要求；main.c结尾的cleanup()不是可选，是 C4 的验收项。
3.4 用 tcpdump 生成自定义测试 pcap：为什么test/目录下的 pcap 文件不能直接用
test/目录下有syn_flood.pcap、icmp_flood.pcap等文件，但它们不能直接喂给ids，因为本项目不支持离线 pcap 分析。ids的main()只接受 live interface 名称（如eth0），不支持-r test/syn_flood.pcap。若你想用 pcap 文件测试，必须用tcpreplay回放：
# 将 pcap 回放到 lo 接口（需 root） sudo tcpreplay -i lo test/syn_flood.pcap # 同时启动 ids 监听 lo sudo ./ids lotcpreplay的-i lo参数是关键：它把 pcap 包注入回环接口，ids就能像抓真实流量一样捕获。test/下的 pcap 是用tcpdump -i eth0 -c 1000 -w syn_flood.pcap 'tcp[tcpflags] & tcp-syn != 0'生成的，确保只含 SYN 包，避免干扰。
3.5 验证告警输出的三种方式：log 文件、stderr、以及 gdb 断点
IDS 的告警输出有三层：
- log 文件：
log_alert()函数写入/tmp/ids_alerts.log，格式为2023-10-05 14:22:33 SYN Flood detected: 127 new connections/sec； - stderr：
fprintf(stderr, ...)输出到终端，方便./ids eth0 2> alerts.log重定向； - gdb 断点：在
log_alert()开头设断点，gdb ./ids→b log_alert→run eth0，可 inspectmsg参数和调用栈。
最可靠的是第一种：/tmp/ids_alerts.log是追加写（fopen("a")），不会因程序崩溃丢失告警；第二种易被 shell 重定向覆盖；第三种需手动 attach，不适合自动化测试。test.sh用grep查日志，正是因为它最稳定。
4. 避坑：五个血泪经验总结，每一条都来自真实翻车现场
4.1 现象：make报错make: *** No rule to make target 'sniff.o', needed by 'ids'. Stop.
原因：Makefile中SRCS = main.c sniff.c ...与实际文件名大小写不符。Linux 文件系统区分大小写，若你把Sniff.c误命名为sniff.c（首字母小写），sniff.o规则匹配失败。
解决：ls -l *.c确认所有文件名与Makefile中完全一致；用git checkout -- .恢复原始命名。
4.2 现象：./ids eth0启动后立即退出，dmesg显示pcap_open_live: eth0: You don't have permission to capture on that device
原因：普通用户无CAP_NET_RAW权限，且eth0不是回环接口。lo接口允许非 root 抓包，但eth0需显式授权。
解决：sudo setcap cap_net_raw+ep ./ids（永久授权），或sudo ./ids eth0（临时）。切勿chmod u+s ./ids，有安全风险。
4.3 现象：test.sh运行后grep找不到告警，但ps aux | grep ids显示进程仍在运行
原因：test.sh中kill $IDS_PID发送的是SIGTERM，而ids的sigint_handler()只处理SIGINT（Ctrl+C）。SIGTERM被忽略，进程不退出，日志未 flush。
解决：test.sh中改用kill -INT $IDS_PID，或在ids的signal()中增加signal(SIGTERM, sigint_handler)。
4.4 现象：gdb附加后bt显示#0 0x00007ffff7bce387 in __GI___poll (fds=0x7fffffffd9e0, nfds=1, timeout=-1)，卡在pcap_next_ex()
原因：pcap_setnonblock()未生效，pcap_next_ex()在无包时阻塞，poll()等待超时。
解决：确认start_sniffer()中pcap_setnonblock()返回值为 0；检查pcap_open_live()的timeout_ms参数（本项目设为 1000，但pcap_next_ex()不用它）。
4.5 现象：arp-poison.py运行后ids日志出现ARP conflict: 192.168.1.1 claimed by 00:11:22:33:44:55 and aa:bb:cc:dd:ee:ff，但test.sh的grep不匹配
原因：test.sh的grep命令默认区分大小写，而日志中ARP conflict的A是大写，但grep "arp conflict"写成了小写。
解决：grep -i "arp conflict"或grep "ARP conflict"，确保大小写一致。-i参数虽方便，但教学场景建议显式写全大写，培养严谨习惯。
5. 进阶技巧：把 IDS 改造成可配置的守护进程，支持动态阈值与 JSON 告警输出
5.1 用 config.h 实现编译期配置：为什么不用 runtime 配置文件
本项目没有config.json或ids.conf，所有参数通过config.h定义：
// config.h #ifndef CONFIG_H #define CONFIG_H #define QUEUE_SIZE 1024 #define MAX_WORKERS 4 #define SYN_FLOOD_THRESHOLD 100 // 5秒内新 SYN 数 #define ICMP_FLOOD_THRESHOLD 500 // 1秒内 ICMP Echo 数 #define ARP_CONFLICT_WINDOW 30 // 秒级冲突检测窗口 #endif这样做的好处是零解析开销、编译期检查、IDE 可跳转。SYN_FLOOD_THRESHOLD是int类型，若你在analysis.c中误写成if (rate > "100")，编译器直接报错。而 JSON 配置需json-c库解析，增加依赖和启动延迟。教学项目优先保证“改一行代码，重新make就生效”。
5.2 修改告警输出为 JSON 格式：三步替换log_alert()，兼容 SIEM 接入
若需对接 ELK 或 Splunk，将log_alert()改为 JSON 输出：
#include <stdio.h> #include <time.h> #include <stdlib.h> void log_alert_json(const char *type, const char *msg, int rate) { time_t now = time(NULL); struct tm *tm = localtime(&now); char time_str[64]; strftime(time_str, sizeof(time_str), "%Y-%m-%dT%H:%M:%SZ", tm); printf("{\"timestamp\":\"%s\",\"type\":\"%s\",\"message\":\"%s\",\"rate\":%d}\n", time_str, type, msg, rate); fflush(stdout); // 强制刷缓冲区 }然后在analysis.c中调用log_alert_json("SYN_FLOOD", "High connection rate", rate)。注意fflush(stdout)：printf默认行缓冲，\n后不 flush，JSON 可能滞留在 buffer 中。fflush()确保每条告警实时输出，便于tail -f /tmp/ids.log | jq '.'实时解析。
5.3 用 systemd 管理为守护进程：让 IDS 开机自启且自动重启
创建/etc/systemd/system/ids.service：
[Unit] Description=PCAP-based Intrusion Detection System After=network.target [Service] Type=simple User=root WorkingDirectory=/opt/ids ExecStart=/opt/ids/ids eth0 Restart=always RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target启用：
sudo cp ids /opt/ids/ sudo cp ids.service /etc/systemd/system/ sudo systemctl daemon-reload sudo systemctl enable ids.service sudo systemctl start ids.serviceRestart=always确保崩溃后自动拉起；StandardOutput=journal将 stdout/stderr 写入 journald，用journalctl -u ids -f实时查看。比nohup ./ids eth0 &更健壮。
5.4 性能调优：用 perf 分析瓶颈，定位 dispatch_queue 的 false sharing
在高流量下，dispatch.c的head/tail原子变量可能因 cache line false sharing 降低性能。用perf定位：
# 编译带 debug info make clean && make CFLAGS="-g -O2" # 运行并采集 sudo perf record -e cycles,instructions,cache-misses -g ./ids eth0 # 分析热点 sudo perf report --sort comm,dso,symbol若发现dispatch_push占 CPU 40% 以上，且cache-misses高，则head和tail可能共享同一 cache line（64 字节）。解决方案：在dispatch_queue_t中插入 padding：
typedef struct { packet_t *buffer[QUEUE_SIZE]; atomic_int head; char pad1[64 - sizeof(atomic_int)]; // 强制 head 单独占 cache line atomic_int tail; char pad2[64 - sizeof(atomic_int)]; // 强制 tail 单独占 cache line } dispatch_queue_t;这是嵌入式开发的硬核技巧，pad1/pad2确保head和tail不在同一 cache line，避免多核写入时 cache coherency 协议频繁同步。
5.5 扩展检测类型：添加 DNS Tunneling 检测的最小改动方案
DNS Tunneling 特征是大量短域名查询（如a1.b2.c3.d4.e5.f6.g7.h8.i9.j0.example.com）。在analysis.c中添加：
#include <string.h> void detect_dns_tunneling(const u_char *pkt, struct pcap_pkthdr *header) { const struct ip *ip = (const struct ip*)(pkt + ETHER_HDR_LEN); if (ip->ip_p != IPPROTO_UDP) return; const struct udphdr *udp = (const struct udphdr*)((u_char*)ip + (ip->ip_hl << 2)); if (ntohs(udp->uh_dport) != 53) return; // DNS port const u_char *dns_payload = (u_char*)udp + 8; // UDP header is 8 bytes if (header->caplen < (u_char*)dns_payload - pkt + 12) return; // DNS header min 12 bytes uint16_t qdcount = ntohs(*(uint16_t*)(dns_payload + 4)); if (qdcount == 0) return; // 提取第一个 query name（跳过 DNS header 12 bytes） const u_char *qname = dns_payload + 12; size_t len = 0; while (qname[len] != 0 && len < 255) len++; if (len > 60) { // 域名长度 > 60 字符，可疑 log_alert("DNS Tunneling suspected: long domain (%zu chars)", len); } }调用点：在analyze_packet()中if (ip->ip_p == IPPROTO_UDP)分支下加入detect_dns_tunneling(pkt, header)。无需改 Makefile，不引入新依赖，5 分钟完成扩展。
从那以后我每次接手 C 语言网络项目，都会先grep -r "pcap_setnonblock" .确认非阻塞模式是否启用；再grep -r "atomic_int" .检查无锁设计是否完整；最后cat Makefile | grep -A5 "CFLAGS"验证-std=c99和-pthread是否在场——这三步做完，80% 的编译和运行时问题就提前规避了。希望帮到你。
本文还有配套的精品资源，点击获取
