简介：这是一份关于Tracert工具的程序设计报告，面向计算机网络课程设计或实验场景，适合需要掌握原始套接字编程、ICMP协议及路由跟踪原理的在校生或网络学习者。资源为doc格式，共1个文件，压缩包大小约194KB，内容以课程设计报告为主，包含设计目的与要求、系统实现思路、详细流程、主要函数说明及程序源代码注释等，便于对照学习Tracert从源到目的地的逐跳路由探测机制。已有167人学习下载。报告基于Windows平台和VC6.0环境，涉及winsock2/ws2tcpip等Socket API，并梳理了TTL递减、ICMP超时消息、目标连通性Ping检测等关键知识点。通过阅读，可理解如何利用原始套接字构造UDP探测包、解析路由器返回的ICMP报文，并掌握网络故障定位与路径追踪的排错方法，适合作为实验报告模板或课程设计参考资料。
1. Tracert程序设计报告：不只是课程作业，而是网络诊断工具的“解剖实验”
很多人在碰到“Tracert程序设计报告”这个题目时，第一反应是“这不就是把 tracert 命令的输出抄一遍吗？”真正动手才发现，这个题目考察的是你对 IP 协议族底层机制的理解程度，而不是命令行操作熟练度。从 ICMP 报文构造、原始套接字使用，到 TTL 递减逻辑和超时重传判定，每一步都在跟协议细节打交道。一份能拿得出手的报告，核心不是“我调通了”，而是“我为什么这么设计、踩了哪些坑、边界情况怎么处理”。
这篇文章写给正在做课程设计的学生，也写给想重新理解 traceroute 原理的开发者。我不打算带你背 RFC 文档，而是按我自己实现这类工具的路线，把原理、代码骨架、报告组织方式和排错经验一次讲清楚。看完你不仅能交差，还能在答辩时把老师问住的点提前堵上。
2. Tracert 的核心机制：TTL 耗尽与 ICMP 超时报文，为什么它能画出网络路径
2.1 TTL 字段的递减时机：Tracert 能工作的前提
Tracert（Windows 实现）和 traceroute（Linux 实现）能画出路径，依赖的是 IP 报文头里一个容易被忽略的字段——TTL（Time To Live）。这个字段设计初衷是防止报文在网络里死循环，每经过一台路由器就减 1，减到 0 就丢弃。Tracert 把这个“防环机制”反着用：我主动把 TTL 设成 1，第一个路由器收到后减成 0，丢弃报文的同时回一个 ICMP 超时（Time Exceeded）报文给我，我就知道第一跳是谁。
但有个细节很多人第一次写会搞错：TTL 的递减发生在路由器转发路径上。一台路由器收到 TTL=1 的报文，它先判断“这个报文是不是发给我的”。如果是发给它本机的（比如目标 IP 就是它自己），它不会丢弃，而是正常上交给上层协议栈处理。只有当目标 IP 不是它自己、需要转发时，TTL 减 1 变成 0，才触发丢弃和回 ICMP 超时。这就是为什么 Tracert 第一跳是网关，而不是本地网卡——本地网卡收到 TTL=1 的报文时，目标 IP 是远端主机，它要转发，所以丢弃并回超时。
实现时要特别注意：构造报文时 TTL=1，探测第一个路由器；收到超时报文后，把 TTL 改成 2 再发，得到第二跳；以此类推。每次探测同一跳通常发 3 个报文，取 RTT 的统计值，这是模仿 tracert 命令的默认行为。
2.2 ICMP 报文结构：从 Echo Request 到 Time Exceeded 的完整链路
Tracert 的探测报文是 ICMP Echo Request（类型 8），这跟 ping 用的是同一种报文。但跟 ping 不同的是，Tracert 需要在一个目的 IP 上递增 TTL 发送多轮报文，而且目标端口经常故意设成一个不可能监听的端口，诱导目标主机回 ICMP 端口不可达（类型 3，代码 3）。收到“端口不可达”说明已经到目标了，路径探测结束。
ICMP 报文的结构要记牢：类型（1 字节）、代码（1 字节）、校验和（2 字节），后面跟内容。对于 Echo Request，内容里是标识符（2 字节）、序号（2 字节）和用户数据。对于 Time Exceeded 报文，内容里是“触发超时的那个 IP 报文头 + 原报文前 8 字节”。这个“原报文前 8 字节”是排错的关键——它让你能核对收到的超时报文是不是回应你刚才发的那个探测报文。
我在实现时用了一个常见做法：在 Echo Request 的用户数据区塞入发送时间戳和序号，收到超时报文后解析里面携带的原报文头，通过标识符和序号完成匹配。这样即使网络里有乱序，也能准确算出每一跳的 RTT。
// ICMP Echo Request 报文构造（用户数据区前 8 字节用于匹配） struct icmp_echo_packet { uint8_t type; // 8 表示 Echo Request uint8_t code; // 0 uint16_t checksum; // 校验和 uint16_t identifier; // 进程标识，用于匹配回应 uint16_t sequence; // 序号，每发一个报文递增 uint64_t timestamp; // 发送时间戳（纳秒级） }; // 核心逻辑：填充报文头 packet.type = 8; packet.code = 0; packet.identifier = htons(getpid() & 0xFFFF); // 低 16 位足够，避免冲突 packet.sequence = htons(seq); packet.timestamp = get_nanos(); // 自定义函数，读取高精度时钟 packet.checksum = icmp_checksum(&packet, sizeof(packet)); // 计算校验和这里有个参数选择容易被忽略：标识符用进程 PID 的低 16 位是常见做法，但如果你同时跑多个实例，或者 PID 恰好被复用，可能出现匹配串线。我一般会在用户数据区额外塞一个随机种子，匹配时同时校验标识符和随机种子，双保险。
校验和计算是 ICMP 报文最容易写错的地方。算法是：把报文按 16 位一组累加，进位回卷，最后取反。计算时校验和字段本身要置 0。很多人用现成的 checksum 函数直接传整个结构体，没注意结构体里有填充字节（padding），导致校验和算错，目标端直接丢弃。正确做法是用__attribute__((packed))取消结构体对齐，或者干脆把报文填充到字节数组里手工构造。
2.3 目标端口选择：用“不可能被监听的端口”触发终点信号
Tracert 的终点判定，靠的不是“收到 Echo Reply”，而是“收到端口不可达”。Windows 的 tracert 默认使用 UDP 探测，目标端口从 33434 开始逐步递增。Linux 的 traceroute 也类似，只不过默认协议也是 UDP。我们自己做实现时，最省事的是直接用 ICMP Echo Request 一路探测，收到 Echo Reply 就算到终点。但这样有一个问题：很多路由器和防火墙会过滤 ICMP，你可能会在半路就收不到回应，无法区分“到达终点”和“被过滤”。
我常做的处理是：模仿 Windows 的行为，用 UDP 报文做探测，目标端口选一个高位端口（比如 33434 起），同时本地开一个原始套接字监听 ICMP 报文。这样当报文到达目标主机时，目标端口没有服务监听，内核会回一个 ICMP 端口不可达——这个回报几乎不会被防火墙拦截，因为它是“连接被拒”的自然响应。当然，这个方案要求你有管理员权限来开原始套接字，而且目标主机如果开了防火墙并且丢弃入站 UDP，同样收不到回报。
如果你只想跑通最小实现，用 ICMP Echo 方案就够了。报告里可以明确写出两种方案的取舍：ICMP Echo 方案简单但容易跟“网络过滤”混淆；UDP 加高位端口方案更贴近真实 tracert 行为，但需要处理原始套接字权限和端口递增逻辑。这种对比是报告里的加分项。
3. 从零实现一个 Tracert：代码骨架、参数调优与双平台差异
3.1 Windows 和 Linux 的原始套接字差异：同一个思路，两套代码
写 Tracert 绕不开原始套接字（Raw Socket）。Windows 上的实现比 Linux 多一层“纠结”：在 Windows 上发送 UDP 探测报文可以不依赖原始套接字，但接收 ICMP 报文必须用原始套接字；而且 Windows 上 SOCK_RAW 的权限控制更严格，非管理员账户直接创建失败。
Windows 接收 ICMP 报文的套接字创建方式：
SOCKET sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); if (sock == INVALID_SOCKET) { // 最常见的错误是 WSAEACCES，表示权限不足 // 解决方式：以管理员身份运行，或在代码里请求提权 }Linux 上创建方式几乎一样，但有两个额外细节：一是接收 ICMP 需要 root 权限或CAP_NET_RAW能力，二是如果你打算自己构造完整 IP 头（而不是让内核代劳），需要设置IP_HDRINCL套接字选项。不过 Tracert 一般不需要自己构造 IP 头，让内核根据 TTL 参数自动生成 IP 头就够了，省事不少。
int sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); if (sock < 0) { perror("socket"); // 常见失败原因：非 root 用户、容器环境未授权、SELinux 限制 }两边最核心的差异在 TTL 设置：Windows 用setsockopt的IP_TTL选项，Linux 也是IP_TTL，但参数传递的结构体大小不同，我曾经在这上面翻过车——Windows 传 4 字节 int，Linux 也传 int，但有的旧内核版本需要IP_TTL配合IP_MTU_DISCOVER设置，否则探测报文的 DF 位（不分片标志）行为不一致，导致某些网络路径上收不到超时报文。
3.2 最小可运行实现：一轮探测的完整代码骨架
下面是一个简洁的“单跳探测”函数骨架，做完这步，往外层套一个 TTL 递增循环就是完整的 Tracert。这里我选择用 ICMP Echo Request 方案，因为代码最短、最容易讲清楚核心逻辑。UDP 方案在报告里作对比分析即可。
// 发送一次探测报文并等待回应 // 参数：dest_ip 目标地址；ttl 当前跳数；seq 本次序号；timeout_ms 超时时间 int probe_once(const char *dest_ip, int ttl, int seq, int timeout_ms) { int sock = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); if (sock < 0) { perror("socket"); return -1; } // 关键参数：设置 TTL，决定这个包能被转发几跳 int ttl_val = ttl; if (setsockopt(sock, IPPROTO_IP, IP_TTL, &ttl_val, sizeof(ttl_val)) < 0) { perror("setsockopt TTL"); close(sock); return -1; } // 构造 ICMP Echo Request char packet[64] = {0}; struct icmp_header *icmp = (struct icmp_header *)packet; icmp->type = 8; // Echo Request icmp->code = 0; icmp->id = htons(getpid() & 0xFFFF); icmp->seq = htons(seq); // 在用户数据区填入发送时间戳 uint64_t ts = get_nanos(); memcpy(packet + 8, &ts, sizeof(ts)); icmp->checksum = checksum(packet, 8 + sizeof(ts)); struct sockaddr_in addr; addr.sin_family = AF_INET; addr.sin_port = 0; // ICMP 不涉及端口，置 0 inet_pton(AF_INET, dest_ip, &addr.sin_addr); if (sendto(sock, packet, 8 + sizeof(ts), 0, (struct sockaddr *)&addr, sizeof(addr)) < 0) { perror("sendto"); close(sock); return -1; } // 接收超时报文，注意这里 recvfrom 返回的不一定是 ICMP 超时 // 需要解析返回的报文内容，判断类型是 11（超时）还是 0（Echo Reply） char recv_buf[512]; struct sockaddr_in from; socklen_t from_len = sizeof(from); fd_set fds; struct timeval tv = {timeout_ms / 1000, (timeout_ms % 1000) * 1000}; FD_ZERO(&fds); FD_SET(sock, &fds); int sel = select(sock + 1, &fds, NULL, NULL, &tv); if (sel <= 0) { // 超时无响应，打印 * * *，这是网络不通或防火墙过滤的表现 printf("%-3d %-20s %s\n", ttl, dest_ip, "Request timed out."); close(sock); return 0; } int len = recvfrom(sock, recv_buf, sizeof(recv_buf), 0, (struct sockaddr *)&from, &from_len); // 这里要解析 recv_buf：外层是 IP 头，内层是 ICMP 头 // 判断 ICMP 类型：11 表示超时（说明是中间路由器回的） // 如果是 3 且 code 是 3，表示端口不可达（说明到了目标主机，但没监听该端口） // 如果是 0，表示 Echo Reply（说明目标主机直接回了，比 Tracert 更简单） close(sock); return 1; }这段代码有几个参数直接影响成败。TTL 值从 1 开始递增，但要注意有些路由器会“偷懒”，不按标准递减 TTL 而是直接丢弃；所以你会看到某一跳总是超时，但下一跳却能通，这是网络设备实现不规范造成的，不是你的代码 bug。超时时间一般设 1 到 3 秒，太短会在高延迟链路上误报超时，太长会让整体探测时间难以忍受。
3.3 多轮探测与乱序处理：为什么要把标识符和序号一起匹配
Tracert 默认每一跳发 3 次探测报文，取 3 个 RTT 显示。这个“3”不是拍脑袋定的，而是为了在丢包率较高的链路上还能拿到至少一个有效样本。如果链路丢包率 20%，单次探测成功概率 80%，3 次全失败的概率只有 0.8%，基本能保证每一跳都显示出来。
多轮探测有一个隐蔽的坑：网络乱序可能让第 2 轮的超时报文在第 1 轮的超时报文之前到达。如果你只按“收到一个 ICMP 就返回”，会出现 RTT 倒挂——第 1 轮显示 10ms，第 2 轮显示 50ms，但其实第 2 轮是先发的。排查这个问题的办法是解析 ICMP 超时报文里携带的“原报文头”，从原报文头里读出标识符和序号，确认它匹配当前这一轮。这就是我在 2.2 里强调“原报文前 8 字节是排错关键”的原因。
// 解析收到的 ICMP 超时报文，还原原始探测报文的 id/seq // recv_buf 是 recvfrom 收到的原始数据 // 注意：收到的数据以 IP 头开始，IP 头长度从 IHL 字段读取 int ip_hdr_len = (recv_buf[0] & 0x0F) * 4; int icmp_offset = ip_hdr_len; // 此时 recv_buf + icmp_offset 是 ICMP 头 // 如果 ICMP 类型是 11（超时）或 3（不可达）， // 其内容部分携带“触发该报文的原始 IP 报文头 + 原始报文前 8 字节” int orig_ip_offset = icmp_offset + 8; // ICMP 头固定 8 字节，内容从第 9 字节开始 int orig_ip_hdr_len = (recv_buf[orig_ip_offset] & 0x0F) * 4; // 原始 ICMP Echo 报文就在 orig_ip_offset + orig_ip_hdr_len 位置 struct icmp_header *orig_icmp = (struct icmp_header *)(recv_buf + orig_ip_offset + orig_ip_hdr_len); // 核对标识符和序号 if (ntohs(orig_icmp->id) == my_id && ntohs(orig_icmp->seq) == my_seq) { // 是当前轮的回应，计算 RTT }这里要特别留神：收到的 ICMP 报文还可能是一个 Echo Reply（类型 0），它不带“原始报文头”，内容里只有标识符、序号和时间戳。所以解析前一定要先判断类型：类型 0 直接匹配 id 和 seq；类型 11 或 3 要从内容里再解一层。新手最容易犯的错误是统一按“带原始报文头”的格式解析，导致类型 0 的报文解析错位。
3.4 参数表：TTL、超时、重试次数、缓冲区大小的推荐值与修改依据
| 参数 | 推荐值 | 修改依据 | 踩坑提示 |
|---|---|---|---|
| TTL 起始值 | 1 | 必须从 1 开始，这是协议设计的核心 | 从 0 或 2 开始都会导致路径输出错乱 |
| TTL 上限 | 30（Windows 默认） | 超过 30 跳的路径极罕见，但跨国链路可能不够 | 有些长路径需要 40 或 64，建议可配置 |
| 每跳探测次数 | 3 | 平衡耗时与可靠性的默认值 | 高丢包链路上可调高到 5 |
| 超时时间 | 1000ms（局域网）、3000ms（广域网） | 取决于链路延迟，卫星链路要 5000ms 以上 | 设太长，整体探测可能耗时几分钟 |
| 接收缓冲区 | 512 字节 | 超过 512 字节的响应报文一般是畸形包 | 结构体对齐导致读错字段的问题更常见 |
| 标识符位数 | 16 位 | 用 PID 低 16 位最省事 | 长时间运行时 PID 复用会导致匹配串线 |
4. 把实验做成报告：文档结构、核心图表与容易被扣分的细节
4.1 报告骨架：从“我做了什么”到“我为什么这么做”的叙事线
一份 Tracert 程序设计报告，老师最反感的是“代码粘贴 + 运行结果截图”的流水账。要让报告有说服力，需要按“问题定义 - 方案选型 - 关键实现 - 实验验证 - 问题反思”组织。标题是“程序设计报告”，重点在“设计”二字，所以方案选型对比是核心章节，代码只是佐证。
我建议按这样的结构：第一部分写需求分析，明确“输入是一个域名或 IP，输出是逐跳路径与 RTT”；第二部分写协议基础，重点是 TTL 机制与 ICMP 报文交互流程，配一张交互时序图；第三部分写系统设计，包括模块划分、数据结构定义、核心流程图；第四部分写关键实现，选 3 到 4 个有技术含量的片段贴出来讲透；第五部分是测试与分析，展示不同网络环境下的运行结果；最后是总结与改进方向。
交互时序图是报告里最值得花时间的图表。不用画得多精美，但要画出“主机发 TTL=1 的报文 → 路由器 R1 减 TTL 为 0 → R1 回 ICMP 超时 → 主机记录 R1 地址 → 主机发 TTL=2 的报文 → R1 转发（这次不减到 0）→ R2 减 TTL 为 0 → R2 回超时”这个完整循环。这张图画清楚，说明你真的理解了协议。
4.2 测试章节怎么设计：三类场景跑数据，比十个截图更有说服力
只贴“tracert 百度”的结果，是很多报告的败笔。有区分度的测试设计应该覆盖三类网络环境：局域网内部探测（验证第一跳是网关、随后到达目标主机）、跨运营商公网探测（验证中间跳地址归属、观察 RTT 抖动）、被封禁 ICMP 的网络环境（验证超时处理和重试机制）。每一类场景给出预期结果和实际输出的对照。
我还会建议在报告里加一个“异常场景模拟”小节：在代码里人为构造一个不存在的 IP（比如 192.0.2.1，这是 RFC 5737 保留的文档地址），展示超时输出；再构造一个 TTL 上限内的探测，展示“请求超时”与“到达目标”的区分逻辑。这种“故意制造故障”的实验，最能体现你对程序行为边界的理解。
4.3 容易被扣分的五个细节：时间戳精度、域名解析、权限说明、代码注释、日志输出
先说时间戳精度问题。如果你用time()函数获取秒级时间戳，RTT 计算结果是 0ms，因为整个探测过程通常在几十毫秒内完成。要用clock_gettime(CLOCK_MONOTONIC)获取纳秒级时间，计算差值后再转成毫秒显示。这个细节决定了报告里 RTT 数据是“有意义的数字”还是“全是 0 或 1ms”的笑话。
其次是域名解析。输入是一个域名（比如 www.example.com），需要先用getaddrinfo解析成 IP 再做 Tracert。解析结果可能有多个 IP（DNS 轮询），报告中要说明取第一个还是全部探测。有的网络环境 DNS 解析失败，所以代码还要支持直接输入 IP 地址。
权限说明是很多学生漏掉的。报告里必须写清楚：程序需要管理员/root 权限运行，因为原始套接字受限。如果只写“本程序在 Windows 10 上运行通过”而不提权限，老师会质疑你代码的健壮性。
代码注释方面，不要注释“i++ 表示 i 加 1”这种废话，要注释“这里设置 TTL=3，期望第 3 跳路由器返回超时报文”。日志输出要统一格式，每一行包含“跳数、IP 地址、三次 RTT”，方便直接截图放进报告。
5. 避坑指南：Tracert 实现中 5 个让人血压升高的典型问题
5.1 现象：收到的全是超时，但 ping 目标 IP 却通
这是最常见的翻车现场。代码写好了，跑起来每一跳都显示“Request timed out”，但用系统自带的 ping 却能通。原因大多数不是你的代码，而是目标主机或中间路由器丢弃了 ICMP Echo Request。现在很多云服务商的安全组默认禁 ping，但允许 TCP/UDP 业务流量。
解决办法分两步。第一步，换一个目标测试，比如先探测网关（通常是 192.168.x.1 或 10.x.x.1），如果网关能通，说明代码基本逻辑没问题。第二步，把探测报文从 ICMP Echo 换成 UDP（发到一个高位端口），这样防火墙不会拦，因为它是“正常业务流量的一部分”。如果你采用的是 UDP 方案，注意目标主机会回“端口不可达”的 ICMP 报文，这个回来时同样需要原始套接字接收。
5.2 现象：TTL 已经设成 1，收到的 ICMP 报文的源地址却是目标 IP 而不是网关
这事我碰到过一次，排查了很久。现象是：向公网 IP 发 TTL=1 的探测包，收到的超时报文源地址不是第一个路由器内网地址，而是目标公网 IP。原因很可能是目标 IP 和你处于同一个子网，或者中间有一个“透传”设备没有递减 TTL 而是直接转发。
另一种常见情况是：如果你测试的目标 IP 是自己的网关，TTL=1 时网关发现“目标 IP 是我自己”，不会递减 TTL，而是直接交给上层协议栈，最终回一个 Echo Reply（如果你发的是 ICMP Echo）。所以你的程序必须同时处理类型 0（Echo Reply）和类型 11（超时）两种回应。只处理超时报文的代码，在“目标就是第一跳”的场景下会误判为超时。
5.3 现象：某跳总是超时，但下一跳能正常显示
这是 Tracert 的经典迷惑行为。第一跳正常，第二跳超时，第三跳又正常。原因通常不是你的程序问题，而是这一跳的路由器出于安全策略，主动丢弃了 TTL 耗尽的报文，不回 ICMP 超时。但后续报文因为 TTL 更大，经过它时 TTL 还没耗尽，所以正常转发。这个现象在运营商骨干网上尤其常见。
处理办法：不要把它当成 bug 去改代码，而是在报告里把这种行为解释为“部分路由器禁用 ICMP 超时响应，属于已知的网络设备行为”。如果你希望路径显示“不中断”，可以尝试增加该跳的探测次数，有时同一台路由器回包的概率不是 100%。
5.4 现象：时间戳计算出来是负数
代码逻辑看着没问题，但算出来的 RTT 有时候是负值，比如 -3ms。原因是用在了CLOCK_REALTIME上，如果系统时间在两次读取之间被 NTP 调整了，时间可能“倒流”。解决方式是改用CLOCK_MONOTONIC，它不受系统时间跳变影响，专门用于计算时间差。
另一个坑是：发送时间戳写进报文用的是主机字节序，接收端直接用memcpy读出来，如果发送和接收在同一台机器上没问题，但如果你的程序将来改成分布式架构（比如发送端和接收端分离），字节序不一致会导致解析错乱。稳妥的做法是：时间戳只在本机使用，不需要考虑跨机解析，但要在代码里写明“本字段仅用于本地计时”。
5.5 现象：Windows 上套接字创建成功，但 recvfrom 一直收不到数据
代码在管理员权限下运行，socket 创建成功，sendto 也返回成功，但 recvfrom 阻塞直到超时。先检查一下你是不是在recvfrom里设置了MSG_WAITALL标志，这个标志在原始套接字上可能导致行为异常。还有可能是防火墙拦截了本机的 ICMP 接收——是的，Windows 防火墙不仅拦入站，还可能拦本机原始套接字的收包。
解决方式：先临时关闭防火墙测试，确认是防火墙问题后，在代码里调用setsockopt设置SIO_RCVALL或者添加防火墙允许规则。此外，检查你的套接字是不是绑定了端口或地址，如果绑定了特定端口，ICMP 报文不带端口信息，可能无法匹配到套接字。原始套接字接收 ICMP 时，通常不调用bind，让内核匹配所有 ICMP 报文。
6. 进阶玩法：把 Tracert 升级成可视化路径分析工具
如果你做完基础版还有余力，我建议做一个 RTT 趋势分析功能——把每条链路每一轮的 RTT 值收集起来，算出平均值、抖动（Jitter）和丢包率，横向对比不同时间段的探测结果。这个功能在报告里写出来，技术含量立刻不一样。
实现思路是：在原有的探测循环外面再套一层“按时间窗口重复探测”的循环，比如每 5 秒跑一轮完整 Tracert，连续跑 20 轮，然后把数据导出成 CSV 或 JSON。用 Python 的 matplotlib 拉一条“每一跳 RTT 的箱线图”，能直观看出哪一跳延迟高、哪一跳抖动大。这里注意：轮询间隔不要太短，否则会跟上一轮的 ICMP 超时报文串线，建议间隔大于单轮总耗时的 1.5 倍。
另外一个值得做的功能是“自动识别 NAT 设备后的拓扑”。如果目标的某跳 IP 是私网地址（10.x、172.16-31.x、192.168.x），说明探测路径穿过了 NAT，你可以把这些地址单独标记出来，在输出里用不同颜色或符号区分。虽然这个功能跟 Tracert 核心原理关系不大，但能展示你对网络寻址的敏感度。
我自己的习惯是：在每次收尾时跑一遍“网关 → 一个公网 IP → 一个跨境 IP”的三场景测试，确认程序在不同链路类型下都行为正常。然后把这个测试用例写进代码注释里，下次改动代码直接回归。这也是一种工程素养的体现，报告里写一句“维护了自动化回归测试脚本”，比另外贴十张截图更有说服力。希望这些经验能帮你把这份报告做成真正拿得出手的作品。
本文还有配套的精品资源，点击获取
