1、物联网网络基础:TCP/IP协议栈、MAC地址与IP地址、DNS解析原理、DHCP工作原理

做物联网设备联网故障排查,说白了就是跟这几个东西打交道。我刚开始带团队那会儿,有个同事折腾了一整天,说设备死活连不上服务器。我过去一看,IP地址配错了。嗯,这种基础问题其实最坑人。今天咱们就把这几个核心概念掰开揉碎讲清楚。

1.1 TCP/IP协议栈:物联网设备的"通信语言"

TCP/IP协议栈,你可以把它想象成快递寄送流程。我经常跟新人这么打比方:

  • 应用层:你写好的包裹内容(HTTP、MQTT、CoAP这些协议)
  • 传输层:快递单号,保证包裹不丢不重(TCP/UDP)
  • 网络层:快递路线规划,从北京到上海怎么走(IP协议)
  • 链路层:快递员怎么把包裹送到你手上(以太网、Wi-Fi)

我在一个智能水表项目里遇到过,设备上报数据总是丢包。排查了半天,发现是应用层用了UDP,但水表数据又要求可靠传输。后来改成TCP,问题就解决了。你想想看,协议栈每一层都有自己的职责,选错了就是给自己挖坑。

排查要点:设备联网出问题时,先确认是哪一层出了问题。应用层报错?还是网络层不通?一层一层往上查,效率最高。

1.2 MAC地址与IP地址:设备的"身份证"和"门牌号"

这两个概念我见过太多人搞混了。我习惯这么理解:

  • MAC地址:设备的硬件身份证,出厂就烧死了,全球唯一。比如你手机网卡的MAC是固定的。
  • IP地址:设备在网络中的门牌号,可以变。你今天在家是一个IP,明天去公司又是另一个。

有一次客户说他们的传感器在仓库里连不上网。我远程一看,IP地址是169.254.x.x——这是DHCP失败后的自动私有地址。但MAC地址是正常的。这说明问题出在IP分配上,不是硬件坏了。

避坑指南:我曾经遇到一个项目,设备MAC地址冲突了。两台设备出厂时MAC写成了同一个值,结果网络里疯狂丢包。所以采购设备时,一定要确认MAC地址是唯一的。

1.3 DNS解析原理:把域名翻译成IP地址

DNS解析,说白了就是查电话本。你输入"baidu.com",DNS服务器帮你找到对应的IP地址。物联网设备也一样,它要连服务器,得先知道服务器的IP。

我遇到过最典型的故障:设备能ping通IP,但连不上域名。为什么?DNS解析失败了。排查步骤很简单:

  1. 先ping域名,看能不能解析出IP
  2. 如果不行,检查设备配置的DNS服务器地址
  3. 再不行,手动指定一个公共DNS,比如8.8.8.8

注意:有些物联网设备为了省资源,会硬编码DNS服务器地址。如果这个DNS挂了,设备就彻底连不上网了。我建议在设备固件里至少配置两个备用DNS。

1.4 DHCP工作原理:自动分配IP地址

DHCP就是网络里的"自动发牌机"。设备一接入网络,DHCP服务器就给它分配一个IP地址、子网掩码、网关和DNS。整个过程分四步:

步骤 动作 说明
1 Discover 设备广播:"谁有IP?给我一个!"
2 Offer DHCP服务器回应:"我这有一个,你要不要?"
3 Request 设备说:"好,就这个了。"
4 Ack 服务器确认:"OK,归你了。"

我在一个工厂项目里,几十台设备同时开机,结果DHCP服务器扛不住,部分设备没拿到IP。后来我们给DHCP服务器做了负载均衡,才解决这个问题。

排查技巧:如果设备拿不到IP,先看DHCP服务器日志。很多时候是地址池满了,或者设备MAC被拉黑了。我曾经就遇到过有人把设备MAC误加到黑名单里,查了一下午才发现。

1.5 综合排查思路

好了,这几个基础概念讲完了。实际排查时,我一般按这个顺序来:

  1. 看MAC:设备MAC地址对不对?有没有冲突?
  2. 看IP:设备拿到IP了吗?是不是169.254.x.x?
  3. 看DNS:域名能解析吗?DNS服务器通不通?
  4. 看协议栈:应用层用的什么协议?TCP还是UDP?端口对不对?

你想想看,大部分联网问题,跑不出这个圈子。我带的团队现在遇到故障,第一反应就是按这个流程走一遍,基本能解决80%的问题。

个人习惯:我建议你在设备里加一个网络诊断功能,一键检测MAC、IP、DNS、网关。这样现场人员不用懂技术,也能快速定位问题。

嗯,这一章就到这里。下一章咱们聊聊实际设备联网时,最常见的那些坑和对应的排查工具。