所属计划:智能摄像头 30 天路线图 · 第一阶段(基础与全局)实验日期:2026-09-30实验环境:Raspberry Pi(192.168.0.108wlan0) Mac(192.168.0.106) Wireshark 4.4.8一、当天目标与产出项目内容目标看到连不上 / 卡顿 / 延迟时脑子里能浮现一条包的旅程:从哪出发 → 经过哪些节点 → 在哪丢了或慢了路线图实验抓包观察一次 HTTP / TCP / UDP 通信实际完成实验 A(DNS)、B(HTTP/TCP)、C(UDP)、D(延迟与路径排查)产出文件dns.pcap、http.pcap、udp.pcap、Follow TCP Stream 截图二、核心概念1. 封装:一个包是层层套信封应用数据(HTTP 请求 / RTSP 指令 / RTP 视频载荷) └ 加 TCP/UDP 头(源端口、目的端口…) → 段 / 数据报 └ 加 IP 头(源 IP、目的 IP、TTL) → 包 └ 加以太网头(源 MAC、目的 MAC) → 帧一句话:IP 决定去哪台机器端口决定找哪个程序。2. TCP 与 UDPTCPUDP连接三次握手建立四次挥手关闭无连接直接发可靠性丢了重传保证顺序丢了就丢了发送方不知道头部大小20 字节起(本次抓包含时间戳选项为 32 字节)固定 8 字节、4 个字段摄像头里的用途HTTP API、RTSP 控制信令、鉴权RTP 视频 / 音频流对应关系:控制面要可靠 → TCP媒体面要实时 → UDP(迟到的旧帧没有价值重传只会增加延迟)。3. 局域网、NAT 与公网私网地址段:10.x、172.16–31.x、192.168.x只在内部有效。NAT 把私网 IP:端口翻译成公网 IP:端口再发出。外部默认连不到内部设备。所以摄像头产品几乎都走云中转或 P2P 打洞而不是让用户自己做端口映射。4. 防火墙要想到四层NAT(地址转换)路由器防火墙云服务商安全组(最容易忘)设备本机防火墙5. TTL 与逐跳转发IP 头里的 TTL 每经过一台路由器减 1减到 0 时该路由器丢弃包并回一个 ICMP 超时消息。traceroute就是利用这一点把每一跳的路由器找出来。6. 路由选最具体的路由表按最长前缀匹配选路。VPN 软件常加0.0.0.0/1和128.0.0.0/1两条路由来覆盖全部公网流量而192.168.0.0/24因前缀更长局域网流量仍然直连。三、实验记录实验 A:DNS(UDP 53)sudotcpdump-iwlan0-nudp port53-wdns.pcapdigexample.com抓到2 个包:1 个查询、1 个应答。DNS 服务器223.5.5.5协议 UDP耗时 36ms返回两条 A 记录。实验 B:HTTP over TCP# Pisudotcpdump-iwlan0-ntcp port8080-whttp.pcap# Maccurl-vhttp://192.168.0.108:8080/共抓到14 个包去掉 3 个重复包为11 个有效包整个过程约 19ms。No.方向标志含义1Mac → PiSYN握手第 1 步2Pi → MacSYN ACK握手第 2 步3、4(重复)见问题 35Mac → PiACK握手第 3 步连接建立6(重复)重复的 ACK7Mac → PiPSH ACK81 字节GET / HTTP/1.18Pi → MacACK确认收到请求(Ack82)9Pi → MacPSH ACK112 字节响应头10Pi → MacFIN PSH ACK15 字节响应体camera-demo ok并带 FIN服务端先关闭11Mac → PiACK确认响应头(Ack113)12Mac → PiACK确认响应体和 FIN(Ack129)13Mac → PiFIN ACK客户端关闭14Pi → MacACK最后确认连接关闭包数分类:握手 3 重复 3 带数据 3(7、9、10) 纯确认 2(8、11) 挥手 3(12、13、14) 14。字节数核对请求 81 字节:GET / HTTP/1.1\r\n(16)Host: ...(26)User-Agent: curl/8.7.1(24)Accept: */*(13) 空行(2)。响应头 112 字节:状态行 17 Server 行 36 Date 行 37 Content-Length 行 20 空行 2。响应体 15 字节 camera-demo ok 换行与Content-Length: 15一致。整个对话 81 112 15 208 字节与 Follow TCP Stream 窗口显示一致。HTTP/1.0 的特征:第 10 包是服务端主动带 FIN说明 PythonBaseHTTP是一个请求一条连接发完就关HTTP/1.1 长连接不会这样。实验 C:UDP# Pi 终端 1sudotcpdump-iwlan0-nudp port9999-X-wudp.pcap# Pi 终端 2nc-u-l9999# Macechohello camera|nc-u192.168.0.1089999抓到1 个包:192.168.0.106.63658 192.168.0.108.9999: UDP length 13。IP 头(20 字节) 45 00 0029 ... 40(TTL64) 11(协议UDP) ... c0a8006a(源) c0a8006c(目的) UDP 头(8 字节) f8aa(源端口 63658) 270f(目的端口 9999) 0015(长度 21) ccc8(校验和) 数据(13 字节) 68 65 6c 6c 6f 20 63 61 6d 65 72 61 0a hello camera\n数据区之后多出的一个00不属于 UDP 数据(UDP 长度字段只有 13 字节数据)推测是以太网最小帧长的填充。客户端端口随机(63658)、服务端端口固定(9999)与 TCP 一致。nc -u发完不会自己退出:UDP 没有连接关闭的概念。实验 D:延迟与路径排查ping-c10154.8.173.130 ss-tntraceroute-n223.5.5.5sudotraceroute-I-n223.5.5.5D-1 云服务器不可达(分层排查)检查项结果结论ping 192.168.0.10% 丢包约 2msPi 到路由器正常ping 223.5.5.50% 丢包约 40ms公网出口正常ping 154.8.173.130100% 丢包只有这台服务器不可达ss -tnp到154.8.173.130:1883一直SYN-SENT进程为 Python(pid 4502)握手第 1 步后无回应最终确认腾讯云服务器到期未续费根因超时与拒绝的区别现象含义Connection refused(收到 RST)服务器在线但端口没有程序监听一直SYN-SENT/ 超时服务器无回应:关机、不存在或被防火墙静默丢弃D-2ss -tn的其他观察1883 是 MQTT 默认端口1935 是 RTMP 默认端口Pi 上有程序在尝试连云服务器这两个服务。本机8554(常见 RTSP 备用端口)有一条连接Send-Q约 2.2MB、对端Recv-Q约 112KB说明客户端读得比服务端送得慢数据在堆积(背压)。这是 Day 09–11 视频卡顿的典型成因之一。D-3 traceroute 对照(223.5.5.5PiICMP 模式共 16 跳)跳地址耗时含义1192.168.0.1≈3ms第一层路由器(默认网关)2192.168.1.1≈3ms第二层网关(私网)310.12.128.1≈8ms运营商内部接入设备(私网)4–5120.80.x / 120.82.x7–10ms运营商本地网络6219.158.7.225≈47ms延迟跳升进入跨城骨干链路7–9125.33.x / 61.148.x / 61.49.x≈39ms骨干 / 目标区域网络10–15* * *无设备转发了包但不回应探测16223.5.5.5≈42–46ms终点家里有两层私网网关(192.168.0.1→192.168.1.1)加运营商的10.x说明包出门前经过多次地址转换。跳数多不等于慢慢主要来自跨了多远(第 5→6 跳多出约 37ms)。ping的ttl49与 16 跳的路径量级吻合(假设对端初始 TTL 为 64则回程经过约 15 台路由器)。D-4 UDP 与 ICMP 两种探测方式方式命令结果UDP(默认)traceroute -n 223.5.5.5第 9 跳后全是*没走到终点ICMPsudo traceroute -I -n 223.5.5.5第 16 跳到达223.5.5.5同一台 Pi、同一个(可达的)目标换一种探测方式结果就不同。* * *只表示该跳没有回应探测包不等于包被丢了。D-5 Mac 开关 VPN 的对照VPN 开(utun4)VPN 关(直连)route -n get 223.5.5.5128.0.0.0/1网关10.8.0.1接口utun4—traceroute 第 1 跳10.8.0.1≈50ms192.168.0.1≈3ms路径进入隧道对端内部网络家里路由 → 二级网关 → 运营商四、问题与解决汇总#现象原因解决 / 结论1http.pcap为 0 字节0 packets captured在 Pi 上curlPi 自己的 IP流量走回环接口lo不经过wlan0且过滤条件写了host 154.8.173.130与该次通信两端无关改为 MaccurlPiPi 上抓wlan0的tcp port 8080。知识点:同一台机器内部通信不出网卡2http.pcap 中第 3、4、6 包为红色(Out-Of-Order / Dup ACK)第 4 包是第 2 包的完整复制(Pi 收到重复 SYN 后重发 SYN-ACK)第 3 包是 Mac 的第二个 SYN(缺 ECE/CWR 标志)第 6 包是第 5 包的重复能确定它们是什么但不能确定根本原因(Wi-Fi 链路延迟 / macOS 的 ECN 回退 / 多接口均未验证)。不影响通信结果。红色异常 ≠ 故障3UDP 首次抓到的不是hello camera先启动了nc -l收到数据后才启动 tcpdump抓到的是 Pi 端 nc 里按回车产生的 1 字节(0a)回包先抓包后发送且不在 nc 终端按回车。重抓得到 13 字节数据包4ping腾讯云 100% 丢包ss显示SYN-SENT云服务器到期未续费见实验 D-15Mac 的 traceroute 第 1 跳 ≈50ms、走10.8.0.1Mac 开了 VPN公网流量经utun4隧道测公网延迟前先确认 VPN 状态6同一目标 traceroute 末尾全是* * *看似不可达默认 UDP 探测不一定被回应用-I走 ICMP 对照* * *不能单独作为不可达的证据7《包的旅程》第 1 题包数分类有误1 个数据实为 3 个带数据包 2 个纯 ACK4 个挥手实为 3 个(首个 FIN 搭在第 10 包)按第三节包数分类修正五、关键认知同机通信走lo不出网卡。抓包前先想清楚流量会经过哪个接口。抓包三步法:先看方向(谁发给谁)→ 再看标志(SYN / ACK / FIN)→ 最后看序号(数据是否连续)。Ack 是我期望收到的下一个字节编号FIN 也占 1 个序号。红色异常包 ≠ 故障要看是否持续出现、是否影响最终结果。超时 ≠ 拒绝:超时查网络和服务器本身拒绝查服务进程。没有对照组的观察容易被当成结论。traceroute、ping、ss要互相印证。排查要在出问题的那台设备上做且要先确认 VPN 等变量。路径由路由表的最长前缀匹配决定VPN 与局域网可同时存在而互不干扰。客户端端口随机、服务端端口固定TCP 和 UDP 都一样。UDP 发送方不知道对方是否收到TCP 靠 ACK 确认并重传。六、命令速查# 抓包(Pi)sudotcpdump-iwlan0-ntcp port8080-whttp.pcap# 抓并存文件tcpdump-n-rhttp.pcap# 回放摘要tcpdump-n-X-rudp.pcap# 回放并显示十六进制# 拷贝到 Macscph***x192.168.0.108:~/http.pcap ~/Desktop/# 连通性与路径ping-c3192.168.0.1# 网关ping-c3223.5.5.5# 公网 IP(不依赖 DNS)sudotraceroute-I-n223.5.5.5# ICMP 方式判断是否到达iproute# 路由表(Linux)route-nget223.5.5.5# 路由(macOS)看 interface 是否为 utun# 连接状态ss-tn# TCP 连接sudoss-tnp|grep-E1883|1935# 带进程# UDP 手动通信nc-u-l9999# 接收echohello camera|nc-uip9999# 发送Wireshark 显示过滤器tcp.port 8080 ip.addr 192.168.0.108 udp.port 9999 dns tcp.flags.syn 1 tcp.analysis.flags tcp.analysis.retransmission七、下一步Day 04 · HTTP / API:控制链入口—— 理解 REST、状态码、鉴权、超时、重试、幂等实验:写一个最小设备管理 API把接口异常变成可定位的问题。