# 互联网层级介绍互联网层级的基础知识

### 网络分层模型与协议

互联网能跑起来，靠的不是某个“超级协议”，而是一套分工明确的分层体系。每层只解决一类问题，只和上下两层打交道，对等层之间用统一的格式对话。这种设计让“换掉底层技术不影响上层应用”成为可能——比如把网线换成 Wi-Fi、把 HTTP 换成 HTTP/3，其他层几乎不用改。

#### 先搞清三套模型，别混着说

| 模型 | 层级 | 定位 |
|---|---|---|
| **OSI 七层模型** | 物理层→数据链路层→网络层→传输层→会话层→表示层→应用层 | ISO 提出的理论参考模型，教科书标准，实际产品没按它实现 |
| **TCP/IP 四层模型** | 网络接口层→网际层→传输层→应用层 | 真实互联网的架构，RFC 1122 定义 |
| **五层教学模型** | 物理层→数据链路层→网络层→传输层→应用层 | 把 OSI 下三层 + TCP/IP 上两层结合，国内教材最常用 |

理解这三者的关系很重要：**OSI 是地图，TCP/IP 是实际修的路**。日常讨论中大家说的“网络层”“传输层”名称来自 OSI，而具体协议（IP、TCP、HTTP）属于 TCP/IP 体系。

> 另外有个工程上的补充：**“2.5 层”**的说法，指 MPLS、VXLAN、GRE 这类隧道技术——它们夹在二层和三层之间，既不是纯 MAC 转发也不是纯 IP 路由。

#### 逐层拆解

##### 第 1 层：物理层（Physical Layer）

**要解决的问题**：比特怎么变成电信号、光信号或无线电波传出去。它不关心“这是什么数据”，只关心电压高低、光脉冲有无、频率相位、引脚定义、时钟同步。

**典型协议 / 标准**：
- 有线：以太网物理层标准（1000BASE-T、10GBASE-SR/LR）、RS-232 串口、DSL、PON（GPON/EPON）
- 无线：IEEE 802.11 a/b/g/n/ac/ax 的物理层调制（OFDM、QAM）、4G/5G 空口物理层
- 介质：双绞线（Cat5e/Cat6）、同轴电缆、单模/多模光纤

**特点**：
- 数据单位是 **bit（比特）**，没有“帧”“包”的概念。
- 纯硬件范畴，涉及网卡 PHY 芯片、光模块、集线器（Hub）、中继器。
- 只提供**原始比特流传输**，不检错、不重传、不寻址——出错留给上层处理。
- 关键参数：带宽、波特率、信噪比、衰减、双工方式（半双工/全双工）。

##### 第 2 层：数据链路层（Data Link Layer）

**要解决的问题**：在同一个局域网（同一广播域）内，把比特组装成帧，用 MAC 地址找到下一跳，并做差错检测。

**再细分两个子层**：LLC（逻辑链路控制，做复用/流控）+ MAC（介质访问控制，做寻址与信道竞争）。

**典型协议**：
| 协议 | 说明 |
|---|---|
| **以太网 IEEE 802.3** | 绝对主流。帧结构：前导码 + 目的MAC(6B) + 源MAC(6B) + 类型/长度 + 数据(46~1500B) + FCS校验。**MTU 默认 1500 字节** |
| **802.1Q VLAN** | 在以太网帧里插 4 字节 VLAN Tag，实现逻辑隔离 |
| **ARP** | IP 地址 → MAC 地址映射（严格说跨二三层，常叫“2.5层”） |
| **PPP / HDLC** | 点对点链路，早期拨号上网、路由器串口互联用 |
| **Wi-Fi 802.11 MAC** | 多了 CSMA/CA（碰撞避免）、ACK 确认、重传机制 |
| **STP/RSTP 802.1D** | 生成树协议，防二层环路 |
| **LACP 802.3ad** | 链路聚合，多条物理链路绑成一条逻辑链路 |

**特点**：
- 数据单位是 **Frame（帧）**。
- 寻址靠 **MAC 地址（48 位，扁平、不可路由、出厂烧录）**，只能在本广播域内有效。
- 用 **FCS/CRC 校验**检错，错了就丢（以太网不重传，Wi-Fi 会重传）。
- 交换机工作在二层：靠 **MAC 地址表自学习**转发，隔离冲突域但不隔离广播域。
- 这一层的关键词：**广播域、冲突域、VLAN、二层环路、MAC 表泛洪**。

##### 第 3 层：网络层（Network Layer）

**要解决的问题**：跨越多个网络，把数据包从源主机送到目的主机。核心是三件事：**寻址、路由、分片**。

**典型协议**：
| 协议 | 作用 | 特点 |
|---|---|---|
| **IPv4** | 主协议，32 位地址，约 43 亿个，点分十进制 | 无连接、尽力而为、首部 20B（含选项最长 60B），有分片字段，靠 TTL 防环 |
| **IPv6** | 接替 IPv4，128 位地址 | 首部固定 40B、简化了头部、无分片（由端侧 PMTUD 处理）、原生支持 IPSec、取消广播改用组播 |
| **ICMP** | 诊断与差错报告 | ping、traceroute 都靠它；包含“目标不可达”“超时”“重定向”等报文类型 |
| **IGMP** | IPv4 组播组成员管理 | 加入/离开组播组 |
| **RIP** | 距离向量路由协议 | 基于跳数，最大 15 跳，收敛慢，已淘汰 |
| **OSPF** | 链路状态内部网关协议 | Dijkstra 最短路径树，分 Area，收敛快，企业网主流 |
| **IS-IS** | 链路状态，运营商骨干常用 | 跑在数据链路层之上，扩展性好 |
| **BGP** | 外部网关协议，互联网的“ glue ” | 基于 TCP 179 端口，路径向量，策略驱动（AS-PATH、LOCAL_PREF），全球约 90 万条路由表项 |
| **NAT** | 地址转换 | 缓解 IPv4 枯竭，副作用是破坏端到端性、P2P 穿透困难 |
| **IPsec** | 网络层加密认证（AH/ESP） | 传输模式/隧道模式，常用于站点到站点 VPN |
| **MPLS** | 标签交换 | 靠 Label 转发而非查 IP 表，支持 TE、VPN，运营商骨干核心 |

**特点**：
- 数据单位是 **Packet（包/分组）**，IP 层叫 Datagram。
- **IP 本身不可靠**：不保证送达、不保证顺序、不保证不重复——可靠性交给传输层（TCP）。这是互联网设计的核心哲学：**端到端原则**，网络核心保持简单智能放在边缘。
- **TTL（生存时间）**每过一跳减 1，归零丢弃，防止路由环路无限兜圈。
- **分片与重组**：当包大于链路 MTU 时切分（IPv6 取消中间节点分片，改由源端做路径 MTU 发现）。
- 路由器工作在这一层：查**路由表**做最长前缀匹配转发，隔离广播域。

##### 第 4 层：传输层（Transport Layer）

**要解决的问题**：进程到进程的通信（主机到主机是 IP 干的），加上可靠性、流量控制、拥塞控制、多路复用。

**典型协议**：
| 协议 | 特点 | 典型场景 |
|---|---|---|
| **TCP** | 面向连接、可靠、字节流、全双工、有拥塞控制 | Web、邮件、文件传输，占互联网流量大头 |
| **UDP** | 无连接、不可靠、尽最大努力、开销小（首部仅 8B） | DNS、视频直播、VoIP、游戏、QUIC 底座 |
| **SCTP** | 多宿主、多流、面向消息 | 电信信令（SIGTRAN），小众 |
| **QUIC (HTTP/3)** | 跑在 UDP 之上，内置 TLS 1.3、0-RTT、队头阻塞解耦、连接迁移 | Chrome/YouTube 默认，HTTP/3 标配 |
| **DCCP** | 带拥塞控制的不可靠传输 | 极少用 |

**TCP 的关键机制（面试高频）**：
- **三次握手**建立连接（SYN/SYN-ACK/ACK），**四次挥手**断开（FIN/ACK ×2）。TIME_WAIT 状态等 2MSL 是为了让旧报文在网络里自然消亡。
- **序列号 + 确认号 + 累积 ACK**实现可靠传输；丢包靠超时重传 + 快速重传（3 个重复 ACK）。
- **滑动窗口**做流量控制（接收方通告 rwnd）。
- **拥塞控制**：慢启动、拥塞避免、快重传、快恢复；算法演进 Reno → Cubic → BBR（基于带宽探测，Google 系主流）。
- **Nagle 算法**合并小报文，**Delayed ACK**延迟确认，两者相遇可能产生 40ms 延迟。
- 首部最小 20B，通过**端口号（16 位，0~65535）**区分进程：0~1023 知名端口（80/443/22/53），1024~49151 注册端口，49152~65535 动态端口。

##### 第 5 层：会话层（Session Layer）& 第 6 层：表示层（Presentation Layer）

这两层在 TCP/IP 体系里没有独立实现，功能被并进了应用层，但概念依然有用：

- **会话层**：建立、管理、终止会话，同步点、断点续传。对应技术：RPC 会话、NetBIOS、PPTP、TLS 握手建立的会话（Session ID / Session Ticket 复用）。
- **表示层**：数据格式翻译、加密解密、压缩解压。对应技术：**TLS/SSL（加密）**、JPEG/PNG/H.264（编码）、ASCII/Unicode/UTF-8（字符集）、XDR/Protobuf/JSON（序列化）、MIME/Base64。

> ⚠️ 一个常见误区：**TLS 不是应用层协议**。它在传输层和应用层之间，给上层提供安全通道，对应 OSI 的表示层/会话层。所以准确说法是 HTTPS = HTTP over TLS over TCP。

##### 第 7 层：应用层（Application Layer）

**要解决的问题**：应用程序之间的语义交互，即“数据长什么样、什么意思”。

**主流协议一览**：

| 协议 | 端口 | 特点 |
|---|---|---|
| **HTTP/1.1** | 80 | 文本协议、持久连接、管道化效果差、队头阻塞 |
| **HTTP/2** | 443 | 二进制分帧、多路复用、头部压缩 HPACK、服务端推送 |
| **HTTP/3** | 443/UDP | 基于 QUIC，彻底解决 TCP 队头阻塞，弱网表现好 |
| **DNS** | 53(UDP/TCP) | 域名→IP，层次化树状命名空间，递归+迭代查询，有缓存与 TTL，是互联网的“电话簿”也是单点故障风险点 |
| **DHCP** | 67/68 | 自动分配 IP/掩码/网关/DNS，DORA 四步（Discover-Offer-Request-Ack） |
| **FTP** | 20/21 | 控制连接+数据连接双通道，主动/被动模式，明文不安全 |
| **SMTP** | 25/587 | 发邮件，推模式；**POP3(110)/IMAP(143)** 收邮件，IMAP 支持服务端多文件夹同步 |
| **SSH** | 22 | 加密远程登录，替代明文的 Telnet(23) |
| **WebSocket** | 80/443 | HTTP 升级后长连接全双工，推送场景 |
| **MQTT** | 1883/8883 | 发布/订阅，轻量，IoT 首选 |
| **gRPC** | 任意 | HTTP/2 + Protobuf，微服务间 RPC |
| **SNMP** | 161/162 | 网络设备管理监控 |
| **NTP** | 123 | 时间同步，UDP |
| **LDAP** | 389/636 | 目录服务、统一身份认证 |

**特点**：协议多为**请求-响应**或**发布-订阅**语义，数据是人类可读或可序列化的格式，安全性靠下层 TLS 保障。

#### 一次完整的数据流动（封装与解封装）

你在浏览器输入 `https://www.example.com` 回车：

1. **应用层**：浏览器生成 HTTP GET 请求；先查 DNS（UDP 53）拿到 IP。
2. **传输层**：TCP 三次握手（TLS 握手紧随其后），数据切成段，打上源/目的端口。
3. **网络层**：判断目标是否同网段。不同网段就发给默认网关，封装 IP 头（源/目的 IP、TTL、协议号 6=TCP）。
4. **链路层**：ARP 查询网关 MAC，封装以太网帧（源/目的 MAC、类型 0x0800）。
5. **物理层**：转成电信号/光信号出网卡。
6. 沿途每跳路由器**解封装到三层、查路由表、重新封装二层**（MAC 地址每跳都变，IP 地址端到端不变，NAT 场景除外）。
7. 服务器反向解封装，处理请求，原路返回。

这条链路清晰地体现了分层的核心规律：**越往下，作用范围越短（本机→局域网→全网），头部开销越小，语义越简单；越往上，越接近业务，越复杂。**

---

### 网络设备、易错概念与技术演进

#### 各层对应的硬件设备

| 层级 | 设备 |
|---|---|
| 一层 | 网线、光纤、Hub、中继器、光模块 |
| 二层 | 网桥、交换机（Switch）、无线 AP |
| 三层 | 路由器、三层交换机 |
| 四层 | 四层负载均衡（LVS，基于 IP+Port）、NAT 网关、防火墙 |
| 七层 | 反向代理（Nginx）、WAF、API 网关、CDN 边缘节点 |

#### 几个容易踩坑的点

1. **ARP 不算纯粹的二层协议**——它用以太网帧承载，但内容是 IP→MAC 的映射，为三层服务，所以常被称作“2.5 层”。
2. **MAC 地址 ≠ IP 地址**：MAC 扁平、不可路由、本地有效；IP 分层、可聚合、全局可达。这就是为什么需要分层寻址——如果全网靠 MAC 路由，路由表将膨胀到无法维护。
3. **BGP 跑在 TCP 上却是“网络层协议”**——协议的“所属层”看它解决什么问题，不看它底下用了什么。同理 OSPF 直接跑在 IP 之上（协议号 89）。
4. **“TCP 可靠、UDP 不可靠”不等于“UDP 不好”**。实时音视频宁可丢几帧也不要重传带来的延迟；而且 QUIC 证明了在 UDP 上也能自己实现可靠传输。
5. **HTTPS 的 S 不在应用层**——TLS 在传输层与应用层之间。抓包时看到的是 TLS 握手而不是 HTTP 明文。
6. **MTU 问题很隐蔽**：1500 字节以太网 MTU + 20B IP + 20B TCP + 20~60B TLS 开销，MSS 大约 1460。VPN、Docker overlay 网络常常因为额外包头导致大包被丢，表现为“能 ping 通但打不开网页”。

#### 现代演进方向（加分项）

- **协议瘦身与融合**：HTTP/3 + QUIC 把 TLS、重传、拥塞控制从内核态移到用户态，绕开操作系统内核的 TCP 栈升级慢的问题。
- **SDN（软件定义网络）**：把控制平面（路由决策）和数据平面（转发）分离，OpenFlow 协议下发流表，网络可编程。
- **Overlay 网络**：VXLAN 把二层帧装进 UDP 包里跨三层传输，是云主机、K8s Pod 网络互通的基础。
- **IPv6 全面铺开**：中国 IPv6 活跃用户已超 7 亿，移动网络基本默认 IPv6-only + NAT64/DNS64 过渡。
- **零信任与 mTLS**：身份验证从“网络边界”下沉到“每个服务之间”，服务网格（Istio）在传输层做双向认证。

---

### 工控接口、系统设备名与协议识别

核心思路：**分三层定位，互相交叉验证**。物理接口（哪个孔/哪根线）→ 系统设备名（COM几、ttyUSB几）→ 协议特征（波特率、站号、报文格式）。只靠一层很容易对不上，比如 USB 转串口每次重启 `ttyUSB0/1` 会漂移，或者一个 RS-485 口上挂了 5 个站号的设备。

#### 先把概念拆开（很多人卡在这里）

| 概念 | 是什么 | 举例 |
|---|---|---|
| **物理接口** | 机箱上的孔、接线端子 | DB9 母头、USB-A、端子排 A/B/GND |
| **系统设备名** | OS 给的逻辑名字 | `COM3`、`/dev/ttyUSB0`、`/dev/ttyS0` |
| **电气制式** | 信号怎么跑 | RS-232（全双工、±5~15V）、RS-485（半双工差分）、RS-422、TTL |
| **通信协议** | 数据怎么组织 | Modbus RTU、Host Link、MC协议、DF1、自定义ASCII、私有二进制 |

**关键点**：一个串口 ≠ 一台设备。RS-485 总线上通常挂一串设备，靠**站号（地址）**区分；而 USB 设备基本是一对一。所以排查时要先分清“这条线上有几个设备”。

#### 协议层验证：确认“这个口连的是不是我要的那台”

知道 COM3 对应某个转换器还不够，得确认它后面挂的是什么、站号多少。

**1. 用串口助手逐口试探**
Windows 用 Putty/SSCOM/Modbus Poll/QModBus，Linux 用 `minicom`、`screen /dev/ttyUSB0 9600`、`moserial`。先发十六进制再看 ASCII。

**2. 波特率盲扫**
常见组合：9600/8N1、19200、38400、115200、4800/7E1（老仪表）。收到全是乱码但每帧长度固定 → 大概率波特率错；完全没回音 → 线序/485方向/设备没电。写个脚本轮训所有串口×所有波特率，把有回应的记下来，效率远高于手工。

**3. Modbus RTU 站号扫描**
对单个口轮询站号 1~247，发 `03 0000 0001`（读一个保持寄存器），有 CRC 正确应答的就是在线站号。**注意**：如果总线上两台设备默认地址都是 1，会互相干扰导致都答不上来——这时只能**一次只接一台**改完地址再并回去。别用写功能码广播，容易误改参数。

**4. 靠报文特征认协议**

| 特征 | 可能是 |
|---|---|
| 定长、第2字节是 01/02/03/04/05/06/0F/10、末尾两字节 CRC16 | Modbus RTU |
| `@01HD...` 这类 @开头 + CR/LF 结尾的 ASCII | 欧姆龙 Host Link / 部分仪表 |
| 固定头 `50 00 ...`、含子头部 | 三菱 MC 协议 |
| `02 30 30 ... 03` + BCC | 西门子 PPI/MPI 或台达 |
| 纯 ASCII、以 `\r\n` 结尾、可读数字 | 电子秤、扫码枪、温控表自有协议 |
| 插上就持续往外吐数据 | 主动上报型（GPS、扫码枪、电表） |

**5. 抓包反推（终极手段）**
- Linux：`usbmon`（`modprobe usbmon` + Wireshark 选 usbmon1）抓 USB 原始流量；`socat` 做串口镜像 `socat -v PTY,link=/tmp/vcom /dev/ttyUSB0`；`strace -e read,write -p <pid>` 看进程发了什么。
- Windows：Serial Port Monitor（Eltima）、USBPcap + Wireshark。
看到真实收发内容后，对照设备手册的协议章节，基本都能对上。

**6. 电气层面排错（不通的时候先看这个）**
- 万用表测静态电平：RS-232 的 TX/RX 对 GND 有 ±5~15V；RS-485 测 A-B 差值，空闲时 A>B 为正常极性，接近 0V 说明接反或总线短路。
- RS-485 总线两端各需一个 **120Ω 终端电阻**，中间不能有分支星型接法；超过 32 单位负载要加分段器。
- 半双工 485 不能同时收发，用普通“回显测试”会自欺。
- 共地问题：不同设备地电位差大会导致间歇性乱码，加光电隔离模块。
- USB 长线（>3m）易丢包，用有源延长线或光纤 USB 延长器；多个转换器集中插容易**供电不足**，表现就是“能枚举但一通信就掉”。

---

### Windows 与 Linux 下的设备定位

#### Windows 下的做法

**1. 设备管理器定位**
`设备管理器 → 端口(COM 和 LPT)`，展开后显示类似 `USB-SERIAL CH340 (COM3)`。右键 → 属性 → **详细信息**，切这几个属性：
- **硬件 ID**：`USB\VID_1A86&PID_7523`（VID/PID 对应芯片厂：FTDI 0403、Prolific 067B、CP210x 10C4、CH340 1A86、沁恒 4348）
- **位置信息 / 父系**：`Port_#0003.Hub_#0002`，这是它在 USB 树上的物理位置，**只要插的 hub 口不变就不变**，比 COM 号可靠。
- **友好名称**：有时会直接带设备型号。

**2. 插拔对比法（最笨但最有效）**
全部拔掉 → 记下当前列表 → 插一个 → 看新增哪个 COM → 贴标签。重复。配合 **USBDeview** 或 **Device Tree Viewer** 能直接看到 bus/port 路径和序列号，比设备管理器直观。

**3. PowerShell 一键导出**
```powershell
Get-WmiObject Win32_PnPEntity | Where-Object {$_.PNPClass -eq "Ports"} |
  Select-Object Name, DeviceID, PNPDeviceID | Format-Table -AutoSize
```
想查注册表原始信息：`HKLM\SYSTEM\CurrentControlSet\Enum\USB\` 下有每个设备的 `FriendlyName`、`PortName`、`SerialNumber`。

**4. 固化 COM 号**
设备管理器 → 端口属性 → 端口设置 → 高级 → 改 COM 号（避开 1~4，从 COM10 起用，减少老软件兼容问题）。更稳的做法是写脚本按 VID/PID/序列号创建固定符号链接或写配置文件，程序读配置而不硬编码 `COM3`。

#### Linux 下的做法（更规范，推荐）

**1. 看拓扑和挂载点**
```bash
lsusb -t                      # 树状拓扑，bus-port:dev，含 VID:PID
dmesg | grep -iE "tty|usb"    # 插拔瞬间内核报的设备和名字
ls /dev/tty{USB,ACM,S}*       # USB转串口 / CDC设备 / 原生串口
```

**2. 查设备详情**
```bash
udevadm info -a -n /dev/ttyUSB0 | grep -iE "vendor|product|serial|devpath|interface"
```
关注 `idVendor`、`idProduct`、`serial`、`devpath`（如 `1-2.3` = bus1 的 2 口再接 3 口）。

**3. 用稳定命名，别用 ttyUSB0（重点）**
udev 自带两套持久名：
```bash
ls -l /dev/serial/by-id/     # 按 VID/PID/序列号绑定，换插口也不变
ls -l /dev/serial/by-path/   # 按物理 USB 端口路径绑定，同型号无序列号时用这个
```
程序里直接开 `/dev/serial/by-path/pci-0000:00:14.0-usb-0:2.3:1.0-port0`，**彻底解决重启漂移**。

**4. 自己写 udev rule（同型号多台设备）**
`/etc/udev/rules.d/99-serial.rules`：
```
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="FT1ABC", SYMLINK+="plc_main", MODE="0666"
SUBSYSTEM=="tty", KERNELS=="1-2.3", SYMLINK+="weigher", MODE="0666"
```
重载：`udevadm control --reload-rules && udevadm trigger`。之后用 `/dev/plc_main`、`/dev/weigher`，可读性直接拉满。

**5. 实时监控插拔**：`udevadm monitor --property`，插一个看一堆属性，顺手抄走做 rule。

---

### 工程化配置与排查流程

#### 工程化落地：别让下次维护再来一遍

1. **标签三重对应**：线缆两端 + 设备本体 + 机柜图纸，统一编号（例：`J3 ↔ COM3 ↔ PLC-01 ↔ 站号1`）。拍照存档，存在设备台账里。
2. **建一张映射表**（建议做成 CSV/JSON 进版本管理）：

| 柜/位置 | 物理口 | 系统名 | VID:PID/SN | 电气 | 协议 | 波特率 | 站号 | 用途 |
|---|---|---|---|---|---|---|---|---|

3. **程序不要硬编码 COM 号**，读配置文件或按 by-path/by-id 打开；启动时做**自动发现**：扫所有串口 → 发识别命令 → 输出 `(端口, 型号, 站号)` → 首次人工确认后锁定成 mapping 文件，后续不一致就告警。
4. **健康监控**：记录每个端口的最后成功通信时间、超时次数、CRC 错误数。出问题时能直接说“3号秤断了”，而不是“好像有个设备不通”。
5. **硬件选型避坑**：
 - 优先选**能烧录唯一序列号**的转换器（FTDI 原生支持），同型号多台时救命。
 - 串口数量 >4 个时，别全用 USB 转，改用 **PCI-E 多串口卡**（原生 UART，不掉号、延迟低、带光电隔离）。
 - 距离远或设备分散时，改用**串口服务器/以太网 IO 模块**，走网线+IP，排查难度下降一个量级。
 - 关键场合考虑现场总线（CANopen、Profinet、EtherCAT）或直接上 MQTT/Modbus TCP。

#### 给你一个可直接执行的流程

```
① 全部断电/拔线 → 记录当前设备列表 baseline
② 逐个上电插入 → 记录每次新增的 COM/tty、VID:PID、hub port、序列号
③ 填映射表 + 贴标签（线两端都要贴）
④ 用串口助手逐口扫波特率、扫站号，补全协议/站号列
⑤ 固化：Windows 固定 COM 号；Linux 写 udev rule 或用 by-path/by-id
⑥ 程序改读配置，加启动自检和通信心跳监控
⑦ 拍照 + 归档，图纸更新
```

**几个高频坑提醒**：
- `ttyACM0`（CDC 类，如 Arduino、部分仪表）和 `ttyUSB0` 不一样，驱动不同。
- USB HID 类设备（扫码枪当键盘模式、某些采集卡）**不会生成串口节点**，得用 hidapi/libusb。
- 工控机**原生串口**是 `ttyS0/COM1`，USB 转的是 `ttyUSB*/COMx`，别混着找。
- 485 A/B 接反是最常见的“完全不通”原因，先测电压再调软件。
- 多台同型号转换器插同一个无源 hub，重启后顺序随机——要么用 by-path，要么换带序列号的型号。