简介这份PDF面向计算机网络初学者与实验课学生围绕PacketTracer模拟环境与真实设备操作系统梳理网络基础实验的完整流程。内容从网线制作切入讲解直连线与交叉线的区别、EIA/TIA 568A与568B两种布线标准的线序对照并延伸至双机互联、交换机局域网构建及Windows Server 2003系统安装等典型实验覆盖实验目的、设备清单、技术原理与操作步骤。资源包内共1个PDF文件约1.51MB以图文并茂的实验指导形式呈现便于对照操作与复习。目前已有1347人学习下载适合需要完成课程实验、巩固网络基础或准备相关考核的读者可帮助快速理解布线规范、掌握设备互联配置思路并积累排错经验。1. PacketTRacer 实验指导到底在教什么从抓包到协议栈的完整链路很多人第一次看到 PacketTRacer 这个名字会下意识把它和 Wireshark 归为一类——都是抓包工具能看报文就行。但真正把 PacketTRacer 计算机网络实验指导跑完一轮的人会发现它教的不是怎么点按钮看包而是怎么从零构造一个能收发、能解析、能应答的网络协议栈。这个区别很关键Wireshark 是观察者PacketTRacer 是参与者。你要写的代码会真正跑在链路层之上收到真实网卡送来的帧解析出 IP 头、TCP 头再按协议规则回一个包出去。整个过程里抓包只是验证手段协议实现才是主体。这套实验指导适合两类人一类是正在学计算机网络、课本上的三次握手和滑动窗口看得懂但没亲手实现过的学生另一类是做后端或 DevOps、天天跟 TCP 连接池和重传超时打交道、但没往下看过协议栈长什么样的工程师。如果你属于后者做完这套实验再回头看tcp_retries2和somaxconn这些内核参数理解会完全不一样。下面按先搞清楚要做什么、再动手写代码、最后踩坑排查的顺序展开每一步都尽量给到能直接抄的代码和参数。2. 实验环境搭建与 PacketTRacer 最小可运行框架2.1 为什么不用现成抓包工具而要自己搭框架现成工具的问题在于它把收包这件事封装得太好了。你打开 Wireshark选一张网卡包就哗哗地来了你根本不需要关心网卡驱动怎么把帧交给内核、内核怎么通过 BPF 过滤、用户态程序怎么从环形缓冲区读数据。但 PacketTRacer 实验的核心目标之一就是让你亲手处理这些环节。常见做法是提供一个基于原始套接字raw socket或 TUN/TAP 设备的框架你只需要实现协议解析和构造逻辑底层收发的脏活框架帮你干了但你能看到每一层的数据流。我一般会建议先跑通一个最小闭环从网卡收到一个以太网帧打印出源 MAC 和目的 MAC然后构造一个 ARP 应答发回去。这个闭环跑通了说明环境没问题后面加 IP、ICMP、TCP 就是在这个骨架上长肉。2.2 环境依赖与编译参数实验指导通常假设你在 Linux 环境下操作因为原始套接字和 TUN/TAP 在 Linux 上最顺手。需要确认的依赖不多但版本要对依赖项最低版本检查命令说明GCC7.0gcc --version需要支持 C11 标准Make3.8make --version用于编译框架libpcap-dev1.8dpkg -l libpcap-dev抓包和注入用Linux 内核4.15uname -r需要支持 AF_PACKETtcpdump4.9tcpdump --version辅助验证安装命令因发行版而异Debian/Ubuntu 系下sudo apt update sudo apt install -y build-essential libpcap-dev tcpdump net-tools编译框架时Makefile 里通常会有几个关键编译选项需要留意# 典型编译命令-DDEBUG 打开调试输出 gcc -Wall -Wextra -O2 -DDEBUG -o packettracer main.c parser.c sender.c -lpcap-Wall -Wextra打开所有警告协议解析代码里类型转换和缓冲区操作多警告能帮你提前发现越界。-O2优化级别不要开到-O3因为协议栈代码里有大量指针运算过度优化有时会让调试信息错乱。-DDEBUG控制调试打印正式跑性能测试时去掉。2.3 最小可运行代码收一个帧并打印下面这段代码是 PacketTRacer 框架里最核心的收包循环我把它简化到能独立编译运行的程度#include pcap.h #include stdio.h #include arpa/inet.h #include net/ethernet.h // 回调函数每收到一个包调用一次 void packet_handler(u_char *user, const struct pcap_pkthdr *hdr, const u_char *packet) { // 以太网帧头固定 14 字节 struct ether_header *eth (struct ether_header *)packet; printf(收到帧: 长度%u\n, hdr-len); printf( 目的MAC: %02x:%02x:%02x:%02x:%02x:%02x\n, eth-ether_dhost[0], eth-ether_dhost[1], eth-ether_dhost[2], eth-ether_dhost[3], eth-ether_dhost[4], eth-ether_dhost[5]); printf( 源MAC: %02x:%02x:%02x:%02x:%02x:%02x\n, eth-ether_shost[0], eth-ether_shost[1], eth-ether_shost[2], eth-ether_shost[3], eth-ether_shost[4], eth-ether_shost[5]); printf( 类型: 0x%04x\n, ntohs(eth-ether_type)); } int main(int argc, char *argv[]) { if (argc ! 2) { fprintf(stderr, 用法: %s 网卡名\n, argv[0]); return 1; } char errbuf[PCAP_ERRBUF_SIZE]; // 打开网卡混杂模式超时 1000ms pcap_t *handle pcap_open_live(argv[1], 65535, 1, 1000, errbuf); if (handle NULL) { fprintf(stderr, 打开网卡失败: %s\n, errbuf); return 1; } // 只抓以太网帧循环 10 个包后退出 pcap_loop(handle, 10, packet_handler, NULL); pcap_close(handle); return 0; }这段代码的逻辑很直白pcap_open_live打开指定网卡并进入混杂模式pcap_loop循环抓包每抓到一个就调packet_handler。参数65535是 snaplen表示抓完整帧不截断第三个参数1是 promisc设为 1 能收到不是发给本机的帧实验里需要看到完整流量所以打开1000是超时毫秒数影响pcap_loop的响应延迟。编译运行gcc -o capture capture.c -lpcap sudo ./capture eth0需要sudo是因为原始套接字需要 CAP_NET_RAW 权限。跑起来后另开一个终端ping一下网关就能看到 ARP 和 ICMP 帧被打印出来。这个最小框架跑通后面的协议实现就有了落脚点。3. 以太网与 ARP 层实现从帧格式到应答逻辑3.1 以太网帧格式的字段对齐问题以太网帧看起来简单但字段对齐有个容易翻车的地方目的 MAC 6 字节、源 MAC 6 字节、类型 2 字节加起来正好 14 字节。但如果你用结构体直接映射编译器可能会在ether_type后面插入填充字节导致结构体大小变成 16 字节。这就是为什么上面的代码里用struct ether_header而不是自己定义结构体——系统头文件里的定义已经处理好了对齐。自己定义结构体时必须加__attribute__((packed))struct eth_header { uint8_t dst_mac[6]; uint8_t src_mac[6]; uint16_t ether_type; } __attribute__((packed));不加 packed 的话sizeof(struct eth_header)可能是 16 而不是 14解析时偏移量全错。这个坑我在第一次写协议解析时踩过现象是 ARP 包的硬件类型字段读出来是乱码查了半天才发现是结构体对齐问题。3.2 ARP 请求与应答的完整流程ARP 是 PacketTRacer 实验里第一个需要构造并发送的协议。流程分两步收到 ARP 请求后提取发送方的 IP 和 MAC然后构造 ARP 应答发回去。ARP 报文格式如下字段长度字节请求中的值应答中的值硬件类型21以太网1协议类型20x0800IPv40x0800硬件地址长度166协议地址长度144操作码21请求2应答发送方 MAC6请求方 MAC本机 MAC发送方 IP4请求方 IP本机 IP目标 MAC6全 0未知请求方 MAC目标 IP4被请求 IP请求方 IP构造应答的代码// 收到 ARP 请求后构造应答 void send_arp_reply(pcap_t *handle, const u_char *req_packet, const uint8_t *my_mac, uint32_t my_ip) { struct arp_header *arp_req (struct arp_header *)(req_packet 14); // 只处理 ARP 请求操作码 1 if (ntohs(arp_req-opcode) ! 1) return; uint8_t reply[42]; // 14 以太网头 28 ARP 体 struct eth_header *eth (struct eth_header *)reply; struct arp_header *arp (struct arp_header *)(reply 14); // 以太网头目的请求方源本机 memcpy(eth-dst_mac, arp_req-sender_mac, 6); memcpy(eth-src_mac, my_mac, 6); eth-ether_type htons(0x0806); // ARP // ARP 体操作码改为 2应答 arp-hw_type htons(1); arp-proto_type htons(0x0800); arp-hw_len 6; arp-proto_len 4; arp-opcode htons(2); memcpy(arp-sender_mac, my_mac, 6); arp-sender_ip my_ip; memcpy(arp-target_mac, arp_req-sender_mac, 6); arp-target_ip arp_req-sender_ip; pcap_sendpacket(handle, reply, 42); }关键参数说明reply数组大小 42 是 1428 算出来的ARP 体固定 28 字节。pcap_sendpacket的第三个参数是帧长度以太网最小帧是 60 字节不含 FCS但 ARP 应答只有 42 字节网卡驱动会自动填充到 60。如果你在虚拟机里跑有些虚拟网卡不会自动填充需要手动补零到 60 字节否则对端可能丢弃。3.3 用 tcpdump 验证 ARP 应答是否正确写完代码别急着往下走先用 tcpdump 确认应答包格式对sudo tcpdump -i eth0 -e -n arp -vv-e打印以太网头-n不解析主机名-vv详细输出。正常应该看到类似12:34:56.789012 aa:bb:cc:dd:ee:ff 11:22:33:44:55:66, ethertype ARP (0x0806), length 42: Reply 192.168.1.100 is-at aa:bb:cc:dd:ee:ff如果看到的是Request而不是Reply说明操作码没改对如果长度是 28 而不是 42说明以太网头没算进去。这两个是最常见的翻车点。4. IP 与 ICMP 协议实现分片、校验和与 ping 应答4.1 IP 头校验和的算法细节IP 头校验和是 PacketTRacer 实验里第一个看起来简单但容易写错的算法。它的规则是把 IP 头按 16 位分组所有组做反码求和结果取反码。注意两个细节一是校验和字段本身在计算时置 0二是如果头部长度不是 16 位的整数倍最后一个字节要补 0 再算。uint16_t ip_checksum(const uint8_t *data, int len) { uint32_t sum 0; // 按 16 位累加 for (int i 0; i len; i 2) { uint16_t word (data[i] 8) | (i 1 len ? data[i 1] : 0); sum word; // 每加一次就折叠进位防止溢出 if (sum 0xFFFF) sum (sum 0xFFFF) (sum 16); } return (uint16_t)(~sum); }参数data指向 IP 头起始位置len是 IP 头长度通常 20 字节有选项时更长。折叠进位的操作sum (sum 0xFFFF) (sum 16)是关键不折叠的话 32 位累加器可能溢出结果就错了。这个算法在 ICMP 校验和里也能复用只是 ICMP 校验和覆盖整个 ICMP 报文而不只是头部。4.2 处理 ICMP Echo 请求并构造应答ICMP Echo 请求就是 ping 包。收到后需要把类型从 8请求改成 0应答重新计算校验和然后发回去。IP 头也要改源和目的 IP 互换TTL 重置校验和重算。void handle_icmp(pcap_t *handle, const u_char *packet, int len, uint32_t my_ip) { struct ip_header *ip (struct ip_header *)(packet 14); int ip_hlen (ip-ver_ihl 0x0F) * 4; // IP 头长度 struct icmp_header *icmp (struct icmp_header *)(packet 14 ip_hlen); // 只处理 Echo 请求 if (icmp-type ! 8) return; // 构造应答复制原包修改必要字段 uint8_t reply[1500]; memcpy(reply, packet, len); struct eth_header *eth (struct eth_header *)reply; struct ip_header *rip (struct ip_header *)(reply 14); struct icmp_header *ricmp (struct icmp_header *)(reply 14 ip_hlen); // 交换 MAC memcpy(eth-dst_mac, eth-src_mac, 6); memcpy(eth-src_mac, eth-dst_mac, 6); // 注意这里需要本机 MAC // 交换 IP uint32_t tmp rip-src_ip; rip-src_ip rip-dst_ip; rip-dst_ip tmp; rip-ttl 64; rip-checksum 0; rip-checksum ip_checksum((uint8_t *)rip, ip_hlen); // ICMP 类型改为 0应答 ricmp-type 0; ricmp-checksum 0; ricmp-checksum ip_checksum((uint8_t *)ricmp, len - 14 - ip_hlen); pcap_sendpacket(handle, reply, len); }上面代码里交换 MAC 的部分有个 bug——memcpy(eth-src_mac, eth-dst_mac, 6)在交换后执行会覆盖掉刚写入的目的 MAC。正确做法是用临时变量或者先保存本机 MAC。这个坑很典型写协议代码时字段之间有依赖关系顺序错了结果就全错。4.3 IP 分片与重组的最小实现PacketTRacer 实验通常会要求处理超过 MTU 的 ICMP 包也就是分片。IP 头里有三个字段控制分片标识identification、标志flags、片偏移fragment offset。标志字段的低 2 位第一位是 DFDont Fragment第二位是 MFMore Fragments。片偏移以 8 字节为单位。重组逻辑用一个哈希表按标识缓存分片收到 MF0 且偏移非 0 的最后一个分片时触发重组字段位置作用常见值identificationIP 头偏移 4同一数据报的分片共享随机或递增flagsIP 头偏移 6 高 3 位DF/MF 控制MF1 表示还有分片fragment offsetIP 头偏移 6 低 13 位分片在原始数据中的位置以 8 字节为单位重组时按偏移排序检查是否有空洞全部到齐后拼成一个完整 IP 包再交给上层。这个逻辑写起来不复杂但边界条件多比如最后一个分片长度可能不是 8 的倍数重组时要按实际长度截取。5. TCP 状态机与可靠传输三次握手、滑动窗口与重传5.1 TCP 头的关键字段与选项解析TCP 头固定 20 字节但通常带选项MSS、窗口扩大、SACK 等实际长度由数据偏移字段决定。PacketTRacer 实验里需要解析的字段包括字段长度作用实验中的关注点源端口/目的端口各 2 字节标识连接四元组的一部分序列号4 字节字节流编号握手时 ISN 交换确认号4 字节期望收到的下一个字节累积确认数据偏移4 位头长度单位是 4 字节标志位6 位SYN/FIN/ACK/RST/PSH/URG状态转换依据窗口2 字节接收窗口大小流控校验和2 字节含伪头部容易算错TCP 校验和需要构造伪头部源 IP、目的 IP、保留字节、协议号6、TCP 长度。伪头部不实际传输只参与校验和计算。这个设计是为了让 TCP 能检测到 IP 层错误投递。5.2 三次握手的代码实现与状态转换三次握手的核心是状态机。服务端从 LISTEN 开始收到 SYN 后发 SYN-ACK 进入 SYN_RCVD收到 ACK 后进入 ESTABLISHED。客户端从 CLOSED 开始发 SYN 进入 SYN_SENT收到 SYN-ACK 后发 ACK 进入 ESTABLISHED。// 简化的 TCP 状态机处理 void tcp_input(tcp_conn_t *conn, struct tcp_header *tcp, int len) { uint8_t flags tcp-flags; uint32_t seq ntohl(tcp-seq); uint32_t ack ntohl(tcp-ack_seq); switch (conn-state) { case TCP_LISTEN: if (flags TCP_SYN) { // 收到 SYN记录客户端 ISN发 SYN-ACK conn-irs seq; // 初始接收序列号 conn-iss rand(); // 本机初始发送序列号 conn-rcv_nxt seq 1; // 期望下一个字节 conn-snd_nxt conn-iss 1; send_tcp_segment(conn, TCP_SYN | TCP_ACK, NULL, 0); conn-state TCP_SYN_RCVD; } break; case TCP_SYN_RCVD: if ((flags TCP_ACK) ack conn-snd_nxt) { // 握手完成 conn-state TCP_ESTABLISHED; printf(连接建立: %s:%d - %s:%d\n, conn-local_ip, conn-local_port, conn-remote_ip, conn-remote_port); } break; case TCP_ESTABLISHED: // 处理数据、ACK、FIN 等 handle_established(conn, tcp, len); break; } }关键参数irs是客户端初始序列号iss是本机初始序列号rcv_nxt和snd_nxt分别是期望接收和下一个发送的序列号。握手完成后rcv_nxt irs 1snd_nxt iss 1因为 SYN 占一个序列号。5.3 滑动窗口与超时重传的实现要点滑动窗口的核心是维护发送窗口和接收窗口。发送窗口内的数据可以发送但未确认接收窗口内的数据可以接收但未交付应用。窗口大小由 TCP 头的 window 字段通告。超时重传需要维护一个重传定时器。每次发送数据时启动定时器收到 ACK 后取消。超时后重传最早未确认的段并指数退避// 重传定时器检查在事件循环里定期调用 void check_retransmit(tcp_conn_t *conn, uint64_t now_ms) { if (conn-snd_una conn-snd_nxt) return; // 没有未确认数据 if (now_ms - conn-rto_start conn-rto) { // 超时重传最早未确认的段 retransmit_segment(conn, conn-snd_una); // 指数退避上限 60 秒 conn-rto * 2; if (conn-rto 60000) conn-rto 60000; conn-rto_start now_ms; } }rto初始值通常设为 1 秒RFC 6298 建议每次超时翻倍。snd_una是最早未确认的序列号snd_nxt是下一个要发送的序列号。重传时只重传snd_una开始的段不是全部重传。这个实现里有个性能陷阱如果每个连接一个定时器连接数多了之后定时器管理开销很大。常见优化是用一个全局定时器加最小堆管理所有连接的超时时间每次只检查堆顶。6. 实验避坑与排查那些让协议栈跑不通的细节6.1 校验和算出来总是错的现象抓包看到自己发的包Wireshark 标红提示 checksum incorrect。原因最常见的是字节序问题。网络字节序是大端x86 是小端计算校验和时如果混用了htons和直接赋值结果就错。另一个原因是伪头部没算对TCP/UDP 校验和必须包含伪头部漏掉就全错。解决统一在计算前把字段转成网络字节序校验和字段先置 0 再算。用 Wireshark 的 Validate checksum 功能反向验证如果 Wireshark 说对但你自己算不对检查是不是漏了伪头部。6.2 能收到 SYN 但握手完不成现象客户端发 SYN服务端回了 SYN-ACK但客户端不回 ACK连接卡在 SYN_RCVD。原因SYN-ACK 的确认号不对。客户端期望的确认号是它发的 SYN 序列号加 1如果服务端回的确认号不是client_isn 1客户端会丢弃这个包。解决在send_tcp_segment里打印出seq和ack字段和 tcpdump 抓到的对比。常见错误是忘了 SYN 占一个序列号确认号写成了client_isn而不是client_isn 1。6.3 大包发不出去或收到乱序现象小包正常超过 MTU 的包发出去没反应或者收到后解析出错。原因IP 分片没处理。MTU 通常是 1500 字节减去 IP 头 20 和 TCP 头 20MSS 是 1460。超过这个大小的 TCP 段需要 IP 层分片如果没实现分片逻辑大包直接发出去会被网卡丢弃或对端重组失败。解决在 TCP 层根据对端通告的 MSS 限制发送段大小或者在 IP 层实现分片。实验里通常建议在 TCP 层控制因为 IP 分片对性能影响大现代协议栈都尽量在 TCP 层避免分片。6.4 定时器不触发导致重传失效现象故意丢一个 ACK预期会重传但等了几分钟都没动静。原因事件循环被阻塞或者定时器精度不够。如果主循环里用了阻塞式pcap_loop定时器检查根本没机会执行。解决改用pcap_next_ex加非阻塞轮询或者用select/epoll同时监听网卡和定时器。定时器精度至少要到 100ms 级别否则 RTO 退避的指数增长会不准。6.5 在虚拟机里跑结果和物理机不一样现象同样的代码物理机正常虚拟机里 ARP 应答收不到。原因虚拟网卡的混杂模式和物理网卡行为不同。有些虚拟化平台如 VirtualBox 的 NAT 模式会过滤掉非本机 MAC 的帧导致收不到请求。解决把虚拟机网络模式改成桥接Bridged或者在虚拟化平台设置里打开允许混杂模式。如果用的是容器需要加--privileged或--cap-addNET_RAW。7. 用 eBPF 验证协议栈行为一个进阶调试技巧协议栈写完之后怎么确认它真的按预期工作tcpdump 只能看到包看不到状态机的内部状态。我一般会加一层 eBPF 探针在内核里挂 kprobe 到tcp_rcv_state_process之类的函数上观察真实内核协议栈的状态转换然后和自己实现的对比。这个技巧在排查为什么我的实现和 Linux 行为不一致时特别有用。先写一个最小的 eBPF 程序统计每个 TCP 状态的转换次数// bpf_prog.c - 统计 TCP 状态转换 #include linux/bpf.h #include bpf/bpf_helpers.h struct { __uint(type, BPF_MAP_TYPE_HASH); __uint(max_entries, 16); __type(key, __u32); __type(value, __u64); } state_count SEC(.maps); SEC(kprobe/tcp_rcv_state_process) int trace_tcp_state(struct pt_regs *ctx) { // 从寄存器读取新状态x86_64 下第三个参数在 dx __u32 new_state (__u32)PT_REGS_PARM3(ctx); __u64 *count bpf_map_lookup_elem(state_count, new_state); if (count) { __sync_fetch_and_add(count, 1); } else { __u64 init 1; bpf_map_update_elem(state_count, new_state, init, BPF_ANY); } return 0; } char LICENSE[] SEC(license) GPL;编译加载clang -O2 -target bpf -c bpf_prog.c -o bpf_prog.o sudo bpftool prog load bpf_prog.o /sys/fs/bpf/tcp_state sudo bpftool prog attach pinned /sys/fs/bpf/tcp_state kprobe tcp_rcv_state_process然后用bpftool map dump查看各状态计数。跑一次curl请求正常应该看到TCP_SYN_SENT、TCP_ESTABLISHED、TCP_FIN_WAIT1等状态各增加若干次。如果某个状态计数异常高说明有连接卡在那个状态反复重试。这个方法的优势是不需要改内核代码也不影响协议栈行为纯观察。参数说明PT_REGS_PARM3在 x86_64 上对应rdx寄存器ARM64 上对应x2跨平台时需要条件编译。BPF_MAP_TYPE_HASH的max_entries设 16 是因为 TCP 状态总共就十几种够用。我自己的习惯是每实现一个新协议层先用 eBPF 观察内核对应层的状态转换把状态图打印出来贴在显示器边上然后对照着写自己的状态机。这个笨办法帮我省了很多调试时间——状态机写错的时候对照内核的状态转换序列一眼就能看出哪一步跳错了。希望帮到你。本文还有配套的精品资源点击获取
