# 运维常见题-网络维护 ## 🤔 为什么 TIME_WAIT 需要等待 2MSL？ - **TIME_WAIT 是 TCP 连接主动关闭方在发送最后一个 ACK 后进入的状态，需要等待 2MSL（2 × Maximum Segment Lifetime，报文最大生存时间）才彻底关闭。两个目的：①确保最后的 ACK 能到达对端（若丢失，对端会重发 FIN，本方仍需在 TIME_WAIT 内响应）；②让旧连接的报文在网络中彻底消亡，避免串扰到新连接。** - **MSL 是什么** - MSL（Maximum Segment Lifetime）：报文在网络中允许存活的最长时间 - 典型值：RFC 793 建议 2 分钟；Linux 实现中 TIME_WAIT 时长由内核常量 `TCP_TIMEWAIT_LEN`（固定 60 秒）硬编码，即 MSL=30 秒，**不可通过 sysctl 调整** - 2MSL = 2 × MSL = 最后 ACK 单向 1MSL + 对端重发 FIN 单向 1MSL - **原因一：确保最后一个 ACK 可靠到达** - 四次挥手最后一步：主动关闭方发送 ACK 确认对端的 FIN - 如果这个 ACK 丢失，对端（被动关闭方）会重发 FIN - 若主动关闭方已经关闭，收到重发的 FIN 会回复 RST（导致对端误判），所以必须保持在 TIME_WAIT 状态，能再次 ACK - 2MSL 保证"FIN + ACK"最多一个来回（1MSL 发 + 1MSL 回） - **原因二：让旧连接的报文消亡** - 关闭连接后，网络中可能还有延迟的旧报文（迷路的包） - 若立即用相同的四元组（源IP/源端口/目的IP/目的端口）建立新连接，旧报文可能串扰到新连接 - 等待 2MSL 让所有旧报文自然消亡，保证新连接不受污染 - **TIME_WAIT 过多的问题与优化** - 问题：高并发短连接场景（如 Nginx 反向代理大量出站连接）会积累大量 TIME_WAIT，占用端口和内存 - 优化： - `net.ipv4.tcp_tw_reuse=1`：复用 TIME_WAIT 连接（仅出站，需配合 tcp_timestamps） - `net.ipv4.tcp_max_tw_buckets`：限制 TIME_WAIT 最大数量 - 调整 `net.ipv4.ip_local_port_range`：扩大本地端口范围 - 注意：`tcp_tw_recycle` 已被移除（4.12 起，因 NAT 环境有副作用） - **协助记忆** - 主动关闭方像"说再见的人"：说完"再见"（发 ACK）后不能马上走，要站在门口等一会儿（TIME_WAIT），确认对方真的听到了（防止 ACK 丢失），也等自己之前的"话"（报文）都消散了（防串扰）。 - 两个原因口诀："确认 ACK 到达" + "等旧包消亡"；时长就是 2MSL。 - **进阶思考** - **为什么是 2MSL 而不是 1MSL 或 3MSL？** - 1MSL：ACK 从本方到对端的最长时间；对端若没收到 ACK，会在 1MSL 内重发 FIN，重发的 FIN 再花 1MSL 到达本方。所以"ACK 丢失 + FIN 重发 + 到达本方"最多需要 2MSL。2MSL 是能覆盖这个最坏情况的精确时间，3MSL 则多余。 - **被动关闭方（收到 FIN 的一方）会不会进入 TIME_WAIT？** - 不会。TIME_WAIT 只由主动关闭方（先发 FIN 的一方）进入。被动关闭方在发送 FIN 并收到 ACK 后直接进入 CLOSED 状态。所以服务器主动关闭大量连接时（如 Nginx 关闭到后端的连接）才会积累 TIME_WAIT。 - **服务器出现大量 TIME_WAIT 一定有问题吗？** - 不一定。TIME_WAIT 是 TCP 正常状态，大量 TIME_WAIT 说明服务器在主动关闭大量连接（常见于反向代理、短连接服务）。只有当 TIME_WAIT 耗尽本地端口导致新连接失败时才需要优化。 - **扩展信息** - **TCP 状态转换中 TIME_WAIT 的位置**： - 正常关闭路径： ``` 主动关闭方：ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED 被动关闭方：ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED ``` - **查看 TIME_WAIT 数量**： ```bash ss -tan | awk '{print $1}' | grep TIME-WAIT | wc -l # 或 netstat -an | grep TIME_WAIT | wc -l ``` ## 🤔 简述 OSI 七层参考模型？ - **OSI（Open Systems Interconnection）七层模型是 ISO 定义的网络通信标准参考模型，把网络通信从下到上分为：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。核心价值：分层解耦、各层职责明确，是理解网络协议和排查问题的框架。** - **七层及职责（从下到上）** - **物理层（Physical）**：传输原始比特流（0/1），定义物理接口、电压、线缆、速率。典型：网线、光纤、集线器（Hub） - **数据链路层（Data Link）**：将比特流封装成帧（Frame），实现相邻节点间的检错/纠错，通过 MAC 地址寻址（以太网仅 CRC 检错，不保证可靠送达，可靠性主要由传输层承担）。典型：以太网、交换机、ARP、MAC 地址 - **网络层（Network）**：将数据包（Packet）从源路由到目的地，通过 IP 地址寻址，跨网段传输。典型：IP、ICMP、路由器 - **传输层（Transport）**：端到端的数据传输，提供可靠性（TCP）或不可靠传输（UDP），通过端口号区分应用。典型：TCP、UDP - **会话层（Session）**：建立、管理、终止会话连接（OSI 中多为理论层次，现实中几乎无独立实现）。典型：NetBIOS - **表示层（Presentation）**：数据格式转换、加密解密、压缩。典型：JPEG、ASCII 编码（TLS/SSL 归属有分歧，多数教材归会话层，也有归表示层） - **应用层（Application）**：为用户应用提供网络服务接口。典型：HTTP、FTP、DNS、SMTP - **分层的好处** - 各层职责单一，独立演进（如物理层从铜缆升级到光纤，不影响上层协议） - 便于标准化和互操作（不同厂商的设备按同一层协议协作） - 便于排查问题（从下到上逐层排查：物理连通 → MAC → IP → 端口 → 应用） - **数据封装与解封装** - 发送方：应用层数据逐层向下封装（加各层头部），最后变成比特流发送 - 接收方：比特流逐层向上解封装（剥离各层头部），还原成应用层数据 - 每层只关心自己的头部，不理解上层内容（"分层不越权"） - **协助记忆** - 七层口诀（中文）："物数网传会表应"（物理、数据链路、网络、传输、会话、表示、应用）。 - 英文口诀："Please Do Not Throw Sausage Pizza Away"（Physical, Data Link, Network, Transport, Session, Presentation, Application）。 - 比喻：寄快递——物理层是卡车（运输比特），数据链路层是装箱贴 MAC 标签，网络层是写收件地址（IP），传输层是选快递方式（TCP=挂号信，UDP=平信），会话层是打电话确认，表示层是打包/加密，应用层是写内容。 - **进阶思考** - **OSI 七层模型为什么实际上没有完全实现？** - OSI 是理想化的参考模型，实际网络协议栈（TCP/IP）只实现了其中部分层次。会话层和表示层在实际 TCP/IP 模型中往往被合并到应用层，或由应用自己处理。OSI 的价值是"理论框架"，TCP/IP 是"工程实践"。 - **为什么说"网络排查要从下往上逐层排查"？** - 因为上层依赖下层：物理层不通，上层必然不通；但上层应用出错，下层可能完全正常。从下往上排查（物理连通性 → 数据链路 → IP 路由 → 端口 → 应用）能最快定位故障层，避免在上层浪费时间。 - **交换机、路由器、网关分别工作在哪一层？** - 交换机：数据链路层（第二层，按 MAC 地址转发） - 路由器：网络层（第三层，按 IP 地址路由） - 网关：OSI 严格定义网关工作于传输层及以上（4~7 层）；日常说的"默认网关"实为路由器（三层设备，网络层）——两个概念要区分 - 三层交换机：同时具备二层交换和三层路由能力 ## 🤔 简述 TCP/IP 四层模型？与 OSI 七层模型对应关系？ - **TCP/IP 四层模型是实际互联网使用的协议栈分层，从下到上：网络接口层（Network Interface）、网际层（Internet）、传输层（Transport）、应用层（Application）。它是 OSI 七层模型的"工程化精简版"——把 OSI 的高层（会话/表示/应用）合并为应用层，把低层（物理/数据链路）合并为网络接口层。** - **四层及职责（从下到上）** - **网络接口层（Network Interface / 链路层）**：对应 OSI 的物理层 + 数据链路层，负责在物理介质上传输比特流和帧，处理 MAC 寻址、物理传输。典型：以太网、Wi-Fi、ARP - **网际层（Internet / 网络层）**：对应 OSI 的网络层，负责数据包的路由转发，跨网段传输，IP 寻址。核心协议：IP、ICMP、ARP（有的教材把 ARP 归链路层）、IGMP - **传输层（Transport）**：对应 OSI 的传输层，端到端通信，端口寻址，提供 TCP（可靠）和 UDP（不可靠）两种传输方式。典型：TCP、UDP - **应用层（Application）**：对应 OSI 的会话层 + 表示层 + 应用层（三层合并），为用户应用提供网络服务。典型：HTTP、HTTPS、FTP、DNS、SMTP、SSH - **与 OSI 七层的对应关系** | TCP/IP 四层 | OSI 七层 | 典型协议 | |------------|---------|---------| | 应用层 | 应用层 + 表示层 + 会话层 | HTTP/HTTPS/DNS/FTP/SMTP/SSH | | 传输层 | 传输层 | TCP/UDP | | 网际层 | 网络层 | IP/ICMP/ARP/IGMP | | 网络接口层 | 数据链路层 + 物理层 | 以太网/Wi-Fi/ARP | - **为什么实际用 TCP/IP 而不是 OSI** - OSI 是学术理论模型，设计时各层职责理想化，但会话层/表示层在现实中难以独立实现 - TCP/IP 是工程实践模型，先有协议后有模型，贴合实际网络设计 - OSI 主要用于教学和概念理解，TCP/IP 是互联网事实标准 - **数据封装（TCP/IP 视角）** - 应用层数据 → 传输层加 TCP/UDP 头（含端口）→ 网际层加 IP 头（含 IP 地址）→ 网络接口层加以太网头（含 MAC 地址）→ 物理传输 - 接收方逆序解封装 - **协助记忆** - TCP/IP 四层口诀："网传应用"（网络接口、网际、传输、应用）——或记英文 "Link, Internet, Transport, Application"（LITA）。 - 对应关系：OSI 七层 → TCP/IP 四层，是"上下合并"（上三层合成应用层，下两层合成接口层，中间两层一一对应）。 - **进阶思考** - **ARP 协议到底属于哪一层？** - 有争议：ARP 在 IP 与 MAC 之间做映射，传统教材归网络层（因为 ARP 报文封装在以太网帧中，但服务于 IP 层），也有教材归数据链路层。准确说法：ARP 是"网络层与数据链路层之间的桥接协议"，不必纠结于严格归类。 - **TCP/IP 模型是四层还是五层？** - 学术界常用五层模型（物理层、数据链路层、网络层、传输层、应用层），把"网络接口层"拆成物理层和数据链路层。四层和五层都是对同一套协议栈的描述，五层更接近 OSI 的低层划分，四层是 TCP/IP 原始定义。面试中两种说法都对，能说清对应关系即可。 - **ICMP 为什么重要？** - ICMP（Internet Control Message Protocol）是网际层的控制协议，承载错误报告和诊断信息。`ping`（回显请求/应答）、`traceroute`（TTL 超时）、网络不可达错误都靠 ICMP。理解 ICMP 是理解网络诊断工具的基础。 - **扩展信息** - **各层数据单元名称**： - 应用层/传输层：数据（Data）→ 传输层封装后：数据段（Segment，TCP）/ 数据报（Datagram，UDP） - 网际层：数据包（Packet / IP 数据报） - 网络接口层：帧（Frame） - 物理层：比特流（Bits） - **各层寻址方式**： - 网络接口层：MAC 地址（48 位，硬件地址） - 网际层：IP 地址（32 位 IPv4 / 128 位 IPv6，逻辑地址） - 传输层：端口号（16 位，区分应用） ## 🤔 简述 TCP 三次握手的过程？ - **TCP 三次握手（Three-way Handshake）是 TCP 建立可靠连接的过程：①客户端发 SYN ②服务器回 SYN+ACK ③客户端发 ACK。三次握手的核心目的：同步双方的序列号（SEQ），确认双方收发能力都正常，为后续可靠传输做准备。** - **三次握手流程** ``` 客户端 服务器 | ① SYN (seq=x) ─────────────→ | | | 收到 SYN，知道客户端能发 | ← ② SYN+ACK (seq=y, ack=x+1) | | 收到 SYN+ACK，知道服务器能收发 | | ③ ACK (seq=x+1, ack=y+1) ──→ | | | 收到 ACK，知道客户端能收 连接建立，双方进入 ESTABLISHED ``` - **每一步的含义** - **第一次：客户端发 SYN（seq=x）**：客户端请求建立连接，携带初始序列号 x，进入 SYN_SENT 状态 - **第二次：服务器回 SYN+ACK（seq=y, ack=x+1）**：服务器同意建立连接，携带自己的初始序列号 y，并确认收到客户端的 x（ack=x+1），进入 SYN_RCVD 状态 - **第三次：客户端发 ACK（ack=y+1）**：客户端确认收到服务器的 y，双方进入 ESTABLISHED 状态，连接建立完成 - **为什么是三次而不是两次或四次？** - **两次不够**：两次握手只能确认"客户端→服务器"的通路，无法确认"服务器→客户端"的通路正常（服务器无法确认客户端能收到自己的消息） - **三次正好**：三次握手让双方都确认了"自己能发、对方能收"，双向通信能力都得到验证 - **四次多余**：三次已经足够建立双向可靠连接，第四次无必要信息可确认 - **序列号（SEQ）的作用** - 每个 TCP 连接双方各有独立的序列号，用于标识字节流的顺序 - 初始序列号（ISN）随机生成，防止历史连接的旧报文串扰新连接 - 后续数据按序列号排序、去重、重传，实现可靠传输 - **协助记忆** - 三次握手像"打电话确认"：A 打电话"喂，听得到吗？"（SYN）→ B 回"听得到，你听得到我吗？"（SYN+ACK）→ A 回"听得到，开始聊"（ACK）。 - 口诀："SYN、SYN+ACK、ACK"，三次握手确认双向通信。 - **进阶思考** - **SYN Flood 攻击利用了三次握手的什么特点？** - SYN Flood：攻击者发送大量 SYN，但收到 SYN+ACK 后不回 ACK，导致服务器大量连接处于 SYN_RCVD（半连接）状态，耗尽服务器资源。防御：SYN Cookie（不立即分配资源）、限制半连接数、tcp_syncookies=1。 - **TCP 三次握手时，如果第二次（SYN+ACK）丢失会怎样？** - 客户端会超时重传 SYN，服务器也会重传 SYN+ACK，直到超时放弃。这是 TCP 的可靠传输机制——每个报文都有重传机制。 - **三次握手过程中能携带数据吗？** - 前两次（SYN、SYN+ACK）不能携带应用数据，第三次（ACK）可以携带数据（但很少这样做）。这是 TCP 的设计约束——必须在连接建立后才能传输数据。 - **扩展信息** - **TCP 头关键字段**： - `Sequence Number`（32 位）：序列号，标识字节流顺序 - `Acknowledgment Number`（32 位）：确认号，期望收到的下一个字节序号 - `Flags`（6 位）：SYN/ACK/FIN/RST/PSH/URG，控制连接状态 - `Window Size`（16 位）：接收窗口，流量控制 - **抓包观察三次握手**： ```bash tcpdump -i eth0 -S 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0' -n # 观察 SYN → SYN+ACK → ACK 的完整握手过程 ``` ## 🤔 TCP 有哪些状态，分别是什么意思？ - **TCP 有 11 种状态，核心是围绕连接的建立（三次握手）、数据传输（ESTABLISHED）、关闭（四次挥手）三个阶段展开。理解 TCP 状态机是排查连接问题（如大量 TIME_WAIT、CLOSE_WAIT 堆积）的基础。** - **连接建立阶段（三次握手）** - `LISTEN`（监听）：服务器端监听端口，等待客户端连接请求 - `SYN_SENT`（已发送 SYN）：客户端发送 SYN 后、等待服务器 SYN+ACK 的状态 - `SYN_RCVD`（已收到 SYN）：服务器收到 SYN 并回复 SYN+ACK 后、等待客户端 ACK 的状态（半连接） - **数据传输阶段** - `ESTABLISHED`（已建立）：连接建立完成，双方可以正常收发数据（最常见的状态） - **连接关闭阶段（四次挥手）** - `FIN_WAIT_1`（主动关闭方）：主动方发送 FIN 后，等待对方 ACK - `FIN_WAIT_2`（主动关闭方）：收到对方 ACK 后，等待对方发送 FIN - `CLOSE_WAIT`（被动关闭方）：收到对方 FIN 并回 ACK 后，等待本地应用调用 close()（应用未及时 close 会堆积此状态） - `LAST_ACK`（被动关闭方）：本地应用 close() 后发送 FIN，等待对方 ACK - `TIME_WAIT`（主动关闭方）：发送最后一个 ACK 后，等待 2MSL 确保对方收到 ACK、旧报文消亡 - `CLOSING`（双方同时关闭）：主动方在 FIN_WAIT_1 状态收到对端 FIN（而非 ACK）时进入的罕见状态（双方同时发 FIN） - `CLOSED`（已关闭）：连接完全关闭，不存在于连接表中 - **状态转换图（正常关闭路径）** ``` 客户端（主动关闭） 服务器（被动关闭） ESTABLISHED ──────────────── ESTABLISHED │ FIN │ 收到 FIN ↓ ↓ FIN_WAIT_1 ──ACK──→ CLOSE_WAIT │ │ 应用 close() ↓ ↓ FIN_WAIT_2 ←────FIN──── LAST_ACK │ ACK │ ↓ ↓ TIME_WAIT ──→ (2MSL后) CLOSED ↓ CLOSED ``` - **协助记忆** - 状态分组记：建立（LISTEN/SYN_SENT/SYN_RCVD）→ 传输（ESTABLISHED）→ 关闭（FIN_WAIT_1/2、CLOSE_WAIT、LAST_ACK、TIME_WAIT）。 - 关键区分：主动关闭方走 FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT，被动关闭方走 CLOSE_WAIT → LAST_ACK。 - **进阶思考** - **服务器出现大量 CLOSE_WAIT 状态说明什么？** - CLOSE_WAIT 是被动关闭方"收到 FIN 但应用没有调用 close()"的状态。大量 CLOSE_WAIT 堆积说明**应用代码有问题**——收到对端关闭信号后没有及时关闭 socket，导致连接无法释放。这是应用层 bug 的典型表现，不是系统配置问题。 - **大量 TIME_WAIT 和大量 CLOSE_WAIT 分别代表什么不同问题？** - TIME_WAIT：主动关闭方的正常状态，大量 TIME_WAIT 说明服务器在主动关闭大量连接（常见于反向代理），可通过内核参数优化，但本身不是 bug - CLOSE_WAIT：被动关闭方的异常状态，大量 CLOSE_WAIT 是应用没有正确关闭 socket 导致的资源泄漏，需要修复应用代码 - **如何查看各个状态的连接数量？** ```bash ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn # 或按状态统计 netstat -an | awk '/^tcp/ {print $NF}' | sort | uniq -c ``` - **扩展信息** - **TCP 状态与 ss 输出对应**： - `ss -tan` 的 State 列显示：LISTEN、ESTAB、SYN-SENT、SYN-RECV、FIN-WAIT-1、FIN-WAIT-2、CLOSE-WAIT、LAST-ACK、TIME-WAIT、CLOSING - 注意 ss 用短横线（如 `TIME-WAIT`），netstat 中 TIME_WAIT/CLOSE_WAIT/LAST_ACK/SYN_SENT/SYN_RECV 用下划线，但 FIN_WAIT1/FIN_WAIT2 无下划线（ss 才是 FIN-WAIT-1/2） - **SYN 半连接与全连接队列**： - SYN 半连接队列：存放 SYN_RCVD 状态的连接（三次握手未完成） - Accept 队列：存放已完成握手、等待应用 accept() 的连接 - 队列满时会导致连接被丢弃，表现为"偶发连接超时/失败"，需调大 `net.core.somaxconn` 和应用 backlog ## 🤔 简述 TCP 四次挥手的过程？ - **TCP 四次挥手（Four-way Handshake）是 TCP 优雅关闭连接的过程：①主动方发 FIN ②被动方回 ACK ③被动方发 FIN ④主动方回 ACK。因为 TCP 连接是"全双工"（双向独立），关闭时需要两个方向分别关闭，所以需要四次交互（FIN+ACK 各两次）。** - **四次挥手流程** ``` 主动关闭方 被动关闭方 | ① FIN (seq=u) ─────────────→ | | | 收到 FIN，知道自己这一方向要关 | ← ② ACK (ack=u+1) ─────────── | （此时被动方可能还有数据要发） | 进入 FIN_WAIT_2 | 进入 CLOSE_WAIT | | 应用 close() | ← ③ FIN (seq=w, ack=u+1) ─── | 进入 LAST_ACK | ④ ACK (ack=w+1) ───────────→ | | 进入 TIME_WAIT（等 2MSL） | 进入 CLOSED ``` - **每一步的含义** - **第一次：主动方发 FIN**：主动关闭方表示"我没有数据要发了"，进入 FIN_WAIT_1 - **第二次：被动方回 ACK**：被动方确认收到 FIN，进入 CLOSE_WAIT（此时被动方可能还有数据要发送，所以不能立即关闭） - **第三次：被动方发 FIN**：被动方数据发送完毕，也发送 FIN 表示"我也没数据要发了"，进入 LAST_ACK - **第四次：主动方回 ACK**：主动方确认收到被动方的 FIN，进入 TIME_WAIT（等待 2MSL），被动方收到 ACK 后进入 CLOSED - **为什么是四次而不是三次？** - TCP 是全双工通信，两个方向的数据流需要**独立关闭** - 主动方的 FIN 只关闭了"主动方→被动方"方向，被动方可能还有数据要发（如剩余响应数据） - 所以被动方先 ACK（确认收到 FIN），等自己数据发完后再发 FIN——这多出来的一次交互就是"被动方数据处理完才能关闭"的体现 - 特殊场景：如果被动方收到 FIN 时恰好没有数据要发，可以合并 ②③ 两步（ACK+FIN 一起发），变成三次挥手（实际仍可能发生） - **主动关闭 vs 被动关闭** - 主动关闭方：先发 FIN 的一方，最终进入 TIME_WAIT（等待 2MSL） - 被动关闭方：先收 FIN 的一方，走 CLOSE_WAIT → LAST_ACK，不进入 TIME_WAIT - 谁先调用 close() 谁就是主动关闭方（特殊：双方同时关闭时，双方都发 FIN、都进入 TIME_WAIT） - **协助记忆** - 四次挥手像"两人道别"：A 说"我要走了"（FIN）→ B 说"好的，但我话还没说完"（ACK，B 继续说）→ B 说"我说完了，再见"（FIN）→ A 说"再见"（ACK）。 - 口诀："FIN、ACK、FIN、ACK"；全双工所以要"两个方向各自关"。 - **进阶思考** - **为什么主动关闭方要等 2MSL（TIME_WAIT），而被动方不用？** - 因为最后一个 ACK 是主动方发的，主动方要确保这个 ACK 能到达被动方（若丢失，被动方会重发 FIN）。被动方收到 ACK 后直接关闭，不需要等待。此外 2MSL 也让旧连接的重复报文段在网络中自然消亡，避免污染新连接。 - **如果四次挥手过程中，某一方突然崩溃/断电会怎样？** - 对端不会立即感知（TCP 有 keepalive 机制：`tcp_keepalive_time=7200s` 默认 2 小时才探测，配合 `tcp_keepalive_intvl=75s` 探测间隔、`tcp_keepalive_probes=9` 探测次数）。若崩溃方重启，收到对端的数据包会回复 RST，对端收到 RST 后立即断开连接（不经过四次挥手）。 - **CLOSE_WAIT 堆积和 TIME_WAIT 堆积分别怎么处理？** - CLOSE_WAIT：应用代码 bug（未 close socket），需修复代码 - TIME_WAIT：正常状态，端口耗尽时才需调优（tcp_tw_reuse、扩大端口范围） - **扩展信息** - **抓包观察四次挥手**： ```bash tcpdump -i eth0 'tcp[tcpflags] & (tcp-fin) != 0' -n # 观察 FIN → ACK → FIN → ACK 的完整挥手过程 ``` - **异常关闭（RST）vs 优雅关闭（FIN）**： - FIN：优雅关闭，走四次挥手，数据完整传输 - RST：异常关闭，立即断开，不经过四次挥手，常用于拒绝连接、超时、错误场景 ## 🤔 TCP 与 UDP 的主要区别及适用场景？ - **TCP 是面向连接、可靠、有序的字节流传输协议；UDP 是无连接、不可靠、面向报文的传输协议。核心区别在"可靠性 vs 实时性"的权衡：TCP 用连接管理+确认重传+流量控制保证数据不丢不乱，UDP 牺牲可靠性换取低延迟、低开销。选型原则："要可靠用 TCP，要快用 UDP"。** - **核心区别对比** | 维度 | TCP | UDP | |------|-----|-----| | 连接性 | 面向连接（三次握手） | 无连接 | | 可靠性 | 可靠（确认+重传） | 不可靠（不确认、不重传） | | 顺序性 | 有序（序列号） | 无序 | | 传输方式 | 字节流 | 数据报文 | | 头部开销 | 20 字节（+选项） | 8 字节 | | 传输效率 | 低（握手/确认/重传） | 高（无额外开销） | | 流量/拥塞控制 | 有（窗口、慢启动等） | 无（应用层自控） | | 应用场景 | HTTP/HTTPS、SSH、FTP、邮件 | DNS、视频、语音、游戏、实时通信 | - **TCP 的特点** - 面向连接：通信前必须三次握手建立连接 - 可靠传输：确认重传、序列号排序、流量控制、拥塞控制 - 字节流：数据是连续的字节流，没有消息边界（需要应用层自己分包） - 适用：需要数据完整性和顺序的场景（网页、文件传输、数据库连接、邮件） - **UDP 的特点** - 无连接：直接发送，不建立连接 - 不可靠：不确认、不重传、不排序，数据可能丢失/重复/乱序 - 面向报文：每个数据报独立，有消息边界（应用层不用分包） - 低开销：头部仅 8 字节，无连接管理开销 - 适用：实时性要求高、能容忍少量丢失的场景（视频通话、直播、游戏、DNS 查询、NTP） - **选型原则** - 需要数据完整、顺序、可靠 → TCP（文件、网页、数据库、API） - 需要低延迟、实时性、可容忍少量丢失 → UDP（音视频、游戏、直播） - 特殊情况：可靠 + 低延迟需应用层自己实现（如 QUIC 协议，基于 UDP 实现可靠传输） - **协助记忆** - TCP = "挂号信"（要确认、要签收、要排队），UDP = "平信/明信片"（直接寄、不确认、可能丢）。 - 口诀："TCP 可靠慢，UDP 快不可靠；要可靠用 TCP，要实时用 UDP"。 - **进阶思考** - **为什么 DNS 用 UDP 而不是 TCP？** - DNS 查询是"一次请求、一次响应"的短交互，数据量小（几百字节）。用 UDP 可以避免握手开销（TCP 三次握手约 1~1.5 个 RTT），快速完成查询。但 DNS 区域传输（AXFR）和大响应（传统 512 字节 UDP 限制，EDNS0 后可扩展）会用 TCP。 - **视频通话为什么用 UDP？** - 视频通话对实时性要求高（延迟 >200ms 就影响体验），但对少量丢包容忍（丢几帧不影响理解）。UDP 的低延迟特性符合需求；若用 TCP，丢包重传会导致延迟累积，画面卡顿。 - **QUIC 协议为什么基于 UDP？** - QUIC（HTTP/3 底层）基于 UDP 实现了类似 TCP 的可靠传输，但避免了 TCP 的队头阻塞（Head-of-Line Blocking）问题，且握手更快（0-RTT/1-RTT）。因为 TCP 协议栈改动困难（内核、中间设备），在 UDP 之上用应用层实现是更快的演进路径。 - **扩展信息** - **UDP 头部字段（8 字节）**： - 源端口（16 位）、目的端口（16 位） - 长度（16 位）、校验和（16 位） - 对比 TCP 头部 20 字节（含序列号、确认号、窗口、标志位等），UDP 精简得多 - **TCP 与 UDP 都有校验和，但用途不同**： - TCP 校验和：保证数据完整性，出错则重传 - UDP 校验和：检测传输错误，出错则丢弃（不重传） - UDP 校验和在 IPv4 中可选，IPv6 中强制 ## 🤔 VPN 工作原理及应用场景？ - **VPN（Virtual Private Network，虚拟专用网络）通过加密隧道技术在公共网络（如互联网）上建立一条虚拟的"私密通道"，让远程用户/分支机构像在局域网内一样安全访问内部资源。核心原理：数据加密 + 隧道封装 + 身份认证，实现"公网传输、私网体验"。** - **工作原理** - **隧道封装**：原始数据包被封装在另一个数据包中（如 IP 包封装 IP 包），通过公共网络传输 - **数据加密**：封装的数据经过加密（如 AES），即使被窃听也无法解读 - **身份认证**：建立隧道前双方身份认证（用户名密码、证书、预共享密钥 PSK），防止非法接入 - **地址分配**：VPN 客户端被分配一个"虚拟内网 IP"，加入内网地址空间 - **常见 VPN 协议** - `IPsec`：网络层 VPN，提供加密和认证，常用于站点到站点（Site-to-Site）VPN，兼容性好但配置复杂 - `OpenVPN`：控制面基于 SSL/TLS 交换密钥，数据面经 TUN/TAP 在网络层/链路层封装 IP 包，跨平台、配置灵活、穿透 NAT 能力强，个人/中小企业常用 - `WireGuard`：现代 VPN 协议，代码精简（约 4000 行）、性能高、加密算法先进（ChaCha20），Linux 内核原生支持 - `L2TP/IPsec`、`PPTP`（已废弃，不安全）、`SSTP` 等 - `SSL VPN`（如 Cisco AnyConnect、FortiClient，需装客户端；另有 clientless 型 SSL VPN 可纯浏览器访问） - **应用场景** - **远程办公**：员工在家/出差通过 VPN 安全访问公司内网（OA、内部系统、数据库） - **站点互联**：分支机构/异地机房之间建立加密隧道，打通两地内网 - **云上网络**：本地数据中心与云 VPC 之间建立 VPN 连接（云 VPN 网关） - **隐私保护/翻墙**：个人通过 VPN 隐藏真实 IP、访问受限内容（如跨境访问） - **安全传输**：在不安全的公共 Wi-Fi 上保护数据传输安全 - **VPN 与专线的区别** - VPN：基于公网，成本低、部署快，但带宽/延迟受公网影响，安全性依赖加密 - 专线（MPLS、光纤直连）：物理隔离，带宽稳定、延迟低，但成本高、部署慢 - 选择：核心业务（数据库同步、低延迟）用专线，一般办公/远程接入用 VPN - **协助记忆** - VPN = "公网上的加密管道"：数据放进加密的"管子"（隧道）里在公网传输，外面的人看不到管子里的内容。 - 三要素：隧道封装（建管）+ 加密（上锁）+ 认证（验身份）。 - **进阶思考** - **VPN 和代理（Proxy）有什么区别？** - VPN：在网络层/传输层加密整个流量，所有应用的流量都走隧道，透明且全面 - 代理：通常只代理特定协议（HTTP 代理在应用层；SOCKS5 在会话层，可代理任意 TCP/UDP），应用需配置代理，可能不加密 - VPN 是"网络层/链路层方案"（加密整个 IP 包），代理是"更高层方案"；VPN 更安全全面，代理更灵活轻量 - **WireGuard 为什么比 OpenVPN 快？** - WireGuard 代码精简（约 4000 行 vs OpenVPN 数万行），连接状态极简，加密算法（ChaCha20）在无硬件加速的设备上性能更好，且 Linux 内核原生支持（内核态处理，避免用户态/内核态切换开销）。 - **VPN 能保证绝对安全吗？** - 不能。VPN 的安全性取决于：①协议安全性（PPTP 已不安全，避免使用）；②加密强度（过时算法可能被破解）；③密钥管理（PSK 泄露风险）；④配置正确性。此外，VPN 无法防御终端被入侵、DNS 泄露、恶意网站等。 - **扩展信息** - **VPN 隧道模式对比**： - 隧道模式（Tunnel mode）：整个 IP 包被加密封装（IPsec 默认），隐藏原始源/目的地址 - 传输模式（Transport mode）：只加密 IP 载荷，IP 头保留（用于端到端加密） - **常见 VPN 端口**： - OpenVPN：1194（UDP，可改） - WireGuard：51820（UDP，默认） - IPsec：UDP 500（IKE）、UDP 4500（NAT-T） - L2TP：UDP 1701 ## 🤔 简述 ping 命令工作原理？ - **`ping` 基于 ICMP（Internet Control Message Protocol）协议，发送 ICMP Echo Request（回显请求）报文，对端收到后回复 ICMP Echo Reply（回显应答）。通过测量请求到应答的往返时间（RTT）和丢包率，判断目标主机的连通性和网络质量。** - **工作原理** - `ping` 发送 ICMP Echo Request（类型 8）报文到目标主机 - 目标主机收到后回复 ICMP Echo Reply（类型 0） - 客户端记录发送时间，收到应答后计算 RTT（Round-Trip Time，往返时间） - 连续发送多个报文（默认每秒 1 个），统计丢包率、最小/平均/最大 RTT - **ICMP 报文格式** - ICMP 报文封装在 IP 数据包中（网络层协议，无端口号概念） - 关键字段：类型（Type）、代码（Code）、校验和、标识符、序列号 - Echo Request（Type 8）/ Echo Reply（Type 0）是 ICMP 最常用的两种 - **ping 输出解读** ```bash ping -c 4 192.168.1.1 # 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.5 ms # --- 192.168.1.1 ping statistics --- # 4 packets transmitted, 4 received, 0% packet loss, time 3000ms # rtt min/avg/max/mdev = 0.4/0.5/0.6/0.08 ms ``` - `time=`：RTT 往返时间，越小越好 - `ttl=`：剩余跳数（TTL 初始值减跳数，可粗略判断系统类型：Linux 64、Windows 128） - `packet loss`：丢包率，0% 表示网络稳定 - `icmp_seq`：序列号，缺号（不连续）说明丢包；乱序（但无缺号）则是重排序，两者机理不同 - **ping 不通的可能原因** - 目标主机不存在/关机 - 网络路由不通（中间路由器故障） - 防火墙拦截 ICMP（有些服务器/防火墙默认丢弃 ICMP） - 目标主机配置了"禁止响应 ping" - 注意：**ping 不通 ≠ 主机不可达**，可能是 ICMP 被过滤，但 TCP 端口可达（如网页能打开但 ping 不通） - **协助记忆** - ping = "网络声呐"：发一个探测信号（ICMP Echo Request），听回声（Echo Reply），通过回声时间判断距离（RTT）和障碍（丢包）。 - 口诀："ICMP 回显请求 + 回显应答，测连通 + 测延迟 + 测丢包"。 - **进阶思考** - **ping 用的是 TCP 还是 UDP？** - 都不是。ping 用 ICMP 协议（网络层），直接封装在 IP 包中，没有传输层的 TCP/UDP 概念，也没有端口号。这是常见误区。 - **为什么有些服务器能访问（网页能开）但 ping 不通？** - 因为管理员可能用防火墙丢弃 ICMP 包（防止 ping 扫描探测），但保留 TCP 端口（如 80/443）。所以"ping 不通"只能说明 ICMP 不通，不能说明主机不可达——排查时不能只依赖 ping。 - **ping 的 TTL 值有什么用？** - TTL（Time To Live）是 IP 包的生存跳数，每经过一个路由器减 1。通过返回包的 TTL 值，可以粗略判断目标主机系统类型（Linux 默认 64、Windows 默认 128、Cisco 等路由器默认 255），以及是否可能经过 NAT（启发式，需结合其他信息） - **扩展信息** - **ping 常用参数**： ```bash ping -c 10 192.168.1.1 # 发送 10 个包后停止（默认无限） ping -i 0.5 192.168.1.1 # 每 0.5 秒发送一个（默认 1 秒） ping -s 1400 192.168.1.1 # 指定 ICMP 数据部分大小（默认 56 字节，测 MTU 需配合 -M do 设置 DF 位） ping -W 2 192.168.1.1 # 超时 2 秒 ping -f 192.168.1.1 # flood 模式，快速发送（需 root，慎用） ``` - **ICMP 其他类型（排查工具基础）**： - Type 0/8：Echo Reply/Request（ping） - Type 3：Destination Unreachable（目标不可达，含端口不可达、网络不可达等） - Type 5：Redirect（重定向） - Type 11：Time Exceeded（超时，traceroute 依赖此类型） ## 🤔 什么是 MTU？MTU 设置不当会导致哪些问题？ - **MTU（Maximum Transmission Unit，最大传输单元）是网络接口一次能传输的最大数据包大小（不含链路层头部）。以太网标准 MTU 为 1500 字节。MTU 设置不当（尤其过大）会导致"能 ping 通但大包传输失败"的典型问题。** - **MTU 概念** - MTU 定义网络层数据包（IP 包）的最大大小 - 以太网标准：MTU = 1500 字节（加上 14 字节以太网头 + 4 字节 CRC = 1518 字节帧；带 802.1Q VLAN 标签时为 1522 字节） - 不同链路 MTU 不同：以太网 1500、PPPoE 1492、VPN 隧道更小（如 1400）、jumbo frame 9000 - **MTU 与 MSS 的关系** - MSS（Maximum Segment Size，最大分段大小）= MTU - IP 头（20）- TCP 头（20） - 以太网下：MSS = 1500 - 20 - 20 = 1460 字节 - MSS 是双方在 SYN/SYN-ACK 中各自声明，发送方取自身与对端 MSS 的较小值（非双向协商） - **MTU 设置不当的典型问题** - **MTU 过大（最常见，实为本机 MTU 大于路径 MTU）**：大包无法通过某些链路（如 VPN、PPPoE），导致 IP 分片或丢包 - 现象：小包（ping 小包）正常，大包（大文件传输、HTTPS）失败/超慢 - 原因：中间链路 MTU 更小，大包被分片，若分片被禁止（DF 位）则丢包 - **MTU 过小**：数据被过度分片，增加开销，传输效率下降 - **MTU 不一致**：链路上各设备 MTU 不一致，导致分片重组异常 - **典型症状** - ping 小包（如 32 字节）正常，ping 大包（如 2000 字节）失败 - 网页小文件加载正常，大文件上传/下载卡住 - SSH 能连但传输大文件时断线 - VPN 连接后某些网站无法访问（VPN 隧道 MTU 问题） - **排查与解决** ```bash # 检测路径上的最大 MTU（从大到小试，找临界点） ping -M do -s 1472 192.168.1.1 # 1472+28=1500，若失败说明 MTU 小于 1500 ping -M do -s 1400 192.168.1.1 # 逐渐减小，找到能通过的最大值 # 查看网卡 MTU ip link show eth0 # 修改 MTU ip link set eth0 mtu 1400 ``` - `ping -M do`：设置 DF（Don't Fragment）位，禁止分片，用于测 MTU - `-s 1472`：ICMP 数据部分 1472 字节，加 28 字节头（IP 20 + ICMP 8）= 1500 - **协助记忆** - MTU = "公路限高杆"：超过限高的货车（大包）过不去，要么拆开（分片），要么绕路（丢包）。 - 典型症状口诀："小包能通大包断，VPN 之后网站瘫"——多半是 MTU 问题。 - **进阶思考** - **什么是 PMTUD（路径 MTU 发现）？** - Path MTU Discovery：自动发现路径上的最小 MTU。发送方设置 DF 位（禁止分片），若中间链路 MTU 过小，路由器返回 ICMP "需要分片"（Type 3 Code 4）消息，发送方据此减小包大小。但某些网络会屏蔽 ICMP，导致 PMTUD 失效（MTU 黑洞），此时需手动调小 MTU。 - **为什么 VPN 环境下常见 MTU 问题？** - VPN 会在原始数据包外加封装头（加密+隧道头），导致有效 MTU 变小。如果 VPN 虚拟网卡 MTU 设置过大，大包会被分片或丢弃。通常需要把 VPN 网卡 MTU 调小（如 1400），或配置 MSS Clamping。 - **jumbo frame（巨型帧）是什么？什么场景用？** - jumbo frame 是 MTU 大于 1500（通常 9000）的以太网帧，用于存储网络、高性能计算集群，减少分片和 CPU 开销。但要求链路两端和中间设备都支持，否则反而导致问题。 - **扩展信息** - **常见链路 MTU 值**： - 以太网：1500 - PPPoE：1492（PPPoE 头占 8 字节） - OpenVPN（TUN 模式）：默认 tun-mtu 1500，靠 mssfix 自动处理；需根据链路实际 MTU 调整 - WireGuard：1420（默认，预留加密头） - 回环接口（loopback）：65536 - **MSS Clamping**： - 在路由器/防火墙配置 `tcp-mss-clamp`，强制改写 TCP 握手中的 MSS 值，避免大包分片 - 适用于无法调整终端 MTU 的场景（如 VPN 出口、PPPoE 链路） ## 🤔 如何使用 tcpdump 抓取指定主机、端口的数据包？ - **`tcpdump` 是 Linux 最强大的命令行抓包工具，通过 BPF（Berkeley Packet Filter）过滤表达式精确筛选数据包。抓指定主机/端口的核心：`tcpdump host `（主机）、`tcpdump port <端口>`（端口）、组合过滤（`and/or/not`）。** - **常用过滤表达式** ```bash # 按主机 tcpdump host 192.168.1.100 # 指定主机（双向） tcpdump src host 192.168.1.100 # 只抓源主机 tcpdump dst host 192.168.1.100 # 只抓目的主机 # 按端口 tcpdump port 80 # 指定端口（双向） tcpdump src port 80 # 只抓源端口 tcpdump dst port 80 # 只抓目的端口 tcpdump portrange 8000-9000 # 端口范围 # 按协议 tcpdump tcp # 只抓 TCP tcpdump udp # 只抓 UDP tcpdump icmp # 只抓 ICMP # 按网段 tcpdump net 192.168.1.0/24 # 指定网段 # 组合过滤（and/or/not） tcpdump host 192.168.1.100 and port 80 # 指定主机+端口 tcpdump host 192.168.1.100 and not port 22 # 排除 SSH tcpdump '(host A or host B) and port 80' # 括号组合 ``` - **常用参数** - `-i eth0`：指定网卡（`-i any` 抓所有网卡） - `-n`：不解析主机名（端口名解析在 4.99 起也并入 `-n`；早期版本 `-nn` 才同时禁用端口名解析） - `-nn`：等价于 `-n -n`，同时禁用主机名和端口名解析（4.99 起已冗余） - `-v/-vv/-vvv`：详细输出（越 v 越详细，`-vvv` 显示完整协议细节） - `-c 100`：抓 100 个包后停止 - `-w file.pcap`：保存到文件（供 Wireshark 分析） - `-r file.pcap`：读取文件 - `-s 0`：抓完整包（现代 tcpdump 4.0+ 默认即抓全包，`-s 0` 已非必须，仅显式声明） - `-X`：同时显示十六进制和 ASCII 内容 - `-A`：只显示 ASCII 内容（看 HTTP 明文） - `-S`：显示绝对序列号（默认相对序列号） - `-e`：显示链路层头部（含 MAC 地址） - `-tttt`：显示完整时间戳 - **实战示例** ```bash # 抓某主机的 HTTP 流量（含明文内容） tcpdump -i eth0 -nn -A 'host 192.168.1.100 and port 80' # 抓某端口完整包保存到文件 tcpdump -i eth0 -nn -s 0 -w http.pcap 'port 80' # 抓 TCP 三次握手/四次挥手 tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-fin) != 0' # 抓 SYN 包（只抓 SYN，不抓 SYN+ACK） tcpdump -i eth0 -nn 'tcp[tcpflags] == tcp-syn' ``` - **权限与安全注意** - tcpdump 需要 root 权限（或 CAP_NET_RAW capability；开启混杂模式还需 CAP_NET_ADMIN） - 抓包涉及隐私，需遵守法律法规和公司政策 - 生产环境抓包注意磁盘空间（-w 保存大文件），用 `-c` 限制数量 - **协助记忆** - tcpdump = "网络摄像机"：`host`/`port`/`net` 是"拍谁"，`tcp`/`udp`/`icmp` 是"拍什么类型"，`-w` 是"录像存档"，`-A/-X` 是"看清内容"。 - 过滤口诀："host 定主机，port 定端口，and/or/not 组合"。 - **进阶思考** - **BPF 过滤表达式和执行 `grep` 过滤有什么区别？** - BPF 过滤是在**内核层**过滤（libpcap 编译成 BPF 字节码在内核执行），只有匹配的包才从内核拷贝到用户态，高效 - `grep` 是抓取后再在用户态过滤，所有包都已经拷贝到用户态，低效 - 所以：能用 BPF 过滤的尽量用 BPF，`grep` 只用于 BPF 无法表达的场景 - **`-s 0` 和默认抓包大小有什么区别？** - 现代 tcpdump（4.0+）默认即抓完整包（snaplen 262144），`-s 0` 只是显式声明，非必须；老版本（4.0 前）默认只抓前 68/96 字节，需 `-s 0` 才能看到完整载荷 - **tcpdump 抓不到包是什么原因？** - ①网卡没选对（应用走了 lo 回环，但抓了 eth0）；②过滤表达式写错；③数据走了其他网卡/隧道；④权限不足；⑤promiscuous 模式未生效（非混杂模式只抓本机流量）。 - **扩展信息** - **tcpdump 与 Wireshark 配合**： - 在服务器上 `tcpdump -w file.pcap` 抓包，下载到本地用 Wireshark 图形化分析（过滤、统计、流跟踪） - Wireshark 的过滤器语法与 tcpdump 的 BPF 语法类似但不完全相同（Wireshark 用 display filter，tcpdump 用 capture filter） - **tcpdump 过滤语法速查**： - `tcp[tcpflags]`：TCP 标志位（tcp-syn/tcp-fin/tcp-rst/tcp-ack/tcp-psh/tcp-urg） - `tcp[13] & 2 != 0`：等价于 SYN 标志位检查（字节偏移方式） - `ip[0] & 0x0f`：IP 头长度 - `greater 1000`：抓大于 1000 字节的包 ## 🤔 tcpdump 抓的数据包怎么分析？ - **tcpdump 抓包后的分析分三层：①看基本字段（时间、源/目的 IP、端口、协议、标志位）②看 TCP 连接状态（三次握手、四次挥手、RST）③结合应用层内容定位问题（HTTP 状态、响应时间、错误）。核心思路：先看"包从哪来到哪去"，再看"连接正常吗"，最后看"内容对不对"。** - **基本输出解读** ``` 10:30:15.123456 IP 192.168.1.100.54321 > 192.168.1.1.80: Flags [S], seq 1234567890, win 64240, length 0 ``` - `10:30:15.123456`：时间戳（精确到微秒） - `192.168.1.100.54321`：源 IP + 源端口 - `192.168.1.1.80`：目的 IP + 目的端口 - `Flags [S]`：TCP 标志（S=SYN、F=FIN、R=RST、P=PSH、. =ACK） - `seq 1234567890`：序列号 - `win 64240`：接收窗口大小 - `length 0`：数据长度 - **常见 TCP 标志组合** - `[S]`：SYN，连接请求（三次握手第一步） - `[S.]`：SYN+ACK，连接确认（三次握手第二步） - `[.]`：ACK，普通确认 - `[F]`：FIN，关闭请求（四次挥手） - `[F.]`：FIN+ACK - `[R]`：RST，重置连接（异常关闭/拒绝） - `[P.]`：PSH+ACK，推送数据 - **分析场景与方法** - **看三次握手是否完成**：是否有 S → S. → .（SYN → SYN+ACK → ACK）完整序列 - **看四次挥手是否正常**：是否有 F → . → F → . 完整序列 - **看 RST 包**：出现 RST 说明连接被异常重置（端口未监听、防火墙拒绝、应用崩溃） - **看重传**：`tcp.analysis.retransmission`（Wireshark 标记），大量重传说明网络丢包/拥塞 - **看 RTT**：SYN 到 SYN+ACK 的时间差 = 网络往返延迟 - **用 Wireshark 深入分析** - `tcpdump -w file.pcap` 抓包 → Wireshark 打开 - Statistics → Flow Graph：看 TCP 流的完整交互 - Follow TCP Stream：看完整 TCP 会话（应用层内容重组） - Statistics → IO Graph：看流量趋势 - 过滤器：`tcp.stream eq 0`（看第一个连接）、`http`（看 HTTP）、`tcp.analysis.retransmission`（看重传） - **典型问题定位** - **连接超时**：只有 SYN 没有 SYN+ACK → 目标不可达/防火墙丢弃 - **连接被拒绝**：SYN 后收到 RST → 端口未监听/防火墙拒绝 - **连接建立后立即断开**：握手后收到 RST → 应用层拒绝/超时 - **传输慢**：大量重传、窗口小 → 网络拥塞/丢包 - **HTTP 慢**：看 HTTP 请求和响应的时间差 → 服务端处理慢 - **协助记忆** - 分析三步："看流向（IP/端口）→ 看状态（标志位/握手）→ 看内容（载荷）"。 - 标志口诀：S 是 SYN 请求，S. 是 SYN+ACK，. 是 ACK，F 是 FIN，R 是 RST（异常）。 - **进阶思考** - **如何判断网络问题是"网络慢"还是"应用慢"？** - 看 SYN 到 SYN+ACK 的时间（网络往返 RTT）和 ACK 到数据返回的时间（应用处理时间）。如果 RTT 大说明网络慢，如果 RTT 正常但数据返回慢说明应用处理慢。用 Wireshark 的 Time 列可以精确计算各阶段耗时。 - **抓包看到大量 `[S]` 重传说明什么？** - SYN 重传说明 SYN 包没有收到 SYN+ACK 响应：①目标不可达；②防火墙丢弃 SYN；③目标服务器 SYN 队列满（SYN Flood 或连接数过多）；④网络丢包。结合是否有 SYN+ACK 可以进一步区分。 - **tcpdump 能抓 HTTPS 的内容吗？** - 不能。HTTPS 内容被 TLS 加密，tcpdump 只能看到加密后的密文（TLS 1.2 及以下能看到握手、证书交换；TLS 1.3 中 Certificate 消息也已加密，看不到明文证书）。要看 HTTPS 内容需在应用层解密（如浏览器开发者工具、配置 SSLKEYLOGFILE——需在启动浏览器前设置，且仅 Chrome/Firefox/curl 等支持）。 - **扩展信息** - **常用 Wireshark 显示过滤器**： ``` tcp.port == 80 # TCP 80 端口 http # HTTP 协议 tcp.flags.syn == 1 # SYN 包 tcp.analysis.retransmission # 重传包 tcp.stream eq 5 # 第 6 个 TCP 流（索引从 0 开始） ip.addr == 192.168.1.100 # 指定 IP ``` - **tcpdump 输出中时间戳的意义**： - 默认时间戳是本地时间；`-tttt` 显示完整日期时间 - 对比两个包的时间差可以计算 RTT、重传间隔、应用响应时间 ## 🤔 Linux 网络丢包，如何排查？ - **Linux 网络丢包排查的核心是"分层定位"：先判断丢在哪一层（应用/协议栈/网卡/网络），再针对性排查。常用工具：`ifconfig`/`ip -s`（看网卡统计）、`netstat -s`（看协议栈统计）、`ss`（看连接状态）、`ethtool`（看网卡硬件统计）、`dropwatch`（定位内核丢包点）。** - **第一层：看网卡统计（接收/发送丢包）** ```bash ip -s link show eth0 # 推荐（ifconfig 已废弃，字段名不同） # ip -s 的字段： # RX: errors / dropped / missed / mcast # TX: errors / dropped / carrier / collsns # ifconfig 的字段（旧）： # RX: errors / dropped / overruns / frame # TX: errors / dropped / overruns / carrier ``` - `dropped`：驱动层丢弃（如内存分配失败） - `missed`（ip -s）/ `overruns`（ifconfig）：ring buffer 溢出（CPU 来不及处理） - `errors`：物理层错误（线缆、协商问题） - `carrier`：载波问题（TX） - **第二层：看协议栈统计（内核丢包）** ```bash netstat -s | grep -i -E 'drop|overflow|pruned|error' # 或 cat /proc/net/snmp ``` - 关注：`TcpExt: ListenOverflows`（监听队列满）、`TcpExt: ListenDrops`、`TcpExt: TCPBacklogDrop`（backlog 溢出） - `Udp: InErrors`、`Udp: RcvbufErrors`（UDP 接收缓冲区满） - `Tcp: RetransSegs`（TCP 重传，说明网络丢包） - **第三层：看连接状态** ```bash ss -s # 汇总统计 ss -tan # TCP 连接状态 # 关注：大量 SYN_RECV（SYN Flood）、大量 TIME_WAIT、大量 CLOSE_WAIT ``` - **第四层：看内核丢包点（高级）** ```bash dropwatch -l kas # 实时监控内核丢包点（需内核 CONFIG_NET_DROP_MONITOR 且额外安装） perf record -e skb:kfree_skb # 用 perf 追踪丢包（需 root 权限） cat /proc/net/softnet_stat # 软中断统计：每行一个 CPU，第二列是 dropped（丢包），第三列是 time_squeeze ``` - **第五层：网络层排查** - `ping`：测连通性和丢包率 - `mtr`：连续 traceroute + ping，定位哪个跳丢包 - `traceroute`：定位丢包发生在哪一跳 - `ethtool -S eth0`：看网卡硬件计数器（更细粒度） - **常见丢包原因与解决** | 原因 | 现象 | 解决 | |------|------|------| | ring buffer 太小 | overruns 增长 | `ethtool -G eth0 rx 4096` 调大 ring buffer | | 监听队列满 | ListenOverflows | 调大 `net.core.somaxconn`、应用 backlog | | UDP 缓冲区满 | RcvbufErrors | 调大 `net.core.rmem_max`、应用 SO_RCVBUF | | CPU 不足 | softnet_stat 丢包 | 多队列网卡、RPS/RFS、绑核 | | 网络拥塞 | TCP 重传高 | 优化网络、限流、QoS | - **协助记忆** - 排查口诀："网卡看 dropped，内核看 netstat，连接看 ss，丢包点看 dropwatch"。 - 分层定位：物理（网卡）→ 内核（协议栈）→ 应用（连接状态）→ 网络（丢包点）。 - **进阶思考** - **ring buffer 是什么？为什么调大能减少丢包？** - ring buffer 是网卡的内存缓冲区（环形队列），接收的数据包先存这里，等 CPU 处理。高流量时 CPU 来不及处理，ring buffer 满了新包就被丢弃（overruns）。调大 ring buffer（`ethtool -G eth0 rx 4096`）增加缓冲容量，给 CPU 更多处理时间。 - **softnet_stat 丢包是什么意思？** - softnet_stat 记录每个 CPU 的软中断处理统计，**第二列（dropped）**表示软中断队列满导致的丢包，第三列（time_squeeze）是软中断配额耗尽次数。网卡把包交给了某个 CPU 的队列，但 CPU 来不及处理，队列满就丢包。解决：多队列网卡 + 分散到多 CPU（RPS/RFS/绑核）。 - **TCP 重传高就一定是网络丢包吗？** - 不一定。TCP 重传可能由：①网络丢包；②乱序（乱序包会触发快速重传）；③超时设置过短；④发送方拥塞控制。要区分，需结合 `ethtool -S`（网卡是否丢包）、`ping -i 0.2`（连续 ping 看丢包率）、抓包分析（Wireshark 看重传类型：快速重传 vs 超时重传）。 - **扩展信息** - **关键内核参数（丢包调优）**： ```bash net.core.rmem_max # 接收缓冲区最大值 net.core.wmem_max # 发送缓冲区最大值 net.core.netdev_max_backlog # 网卡到协议栈的队列长度 net.core.somaxconn # listen 队列最大值 net.ipv4.tcp_max_syn_backlog # SYN 队列最大值 ``` - **mtr 命令（丢包定位利器）**： ```bash mtr -r -c 100 8.8.8.8 # 报告模式，100 次 # 输出每个跳的丢包率、延迟，精确定位丢包发生的跳数 ``` ## 🤔 简述 ARP 协议的作用与工作原理？ - **ARP（Address Resolution Protocol，地址解析协议）的作用：在已知 IP 地址的情况下，解析出对应的 MAC 地址。因为数据链路层用 MAC 地址寻址，网络层用 IP 地址寻址，ARP 就是两者之间的"翻译官"。** - **为什么需要 ARP** - IP 层负责跨网段路由（用 IP 地址），数据链路层负责同网段传输（用 MAC 地址） - 发送数据时，只知道目标 IP，不知道目标 MAC，无法封装以太网帧 - ARP 通过广播查询"谁有 192.168.1.1 这个 IP？请告诉我你的 MAC 地址" - **工作原理（同网段）** ``` 主机 A（192.168.1.10）要发送数据给主机 B（192.168.1.20） 1. A 查本地 ARP 缓存，没有 B 的 MAC 记录 2. A 广播 ARP 请求："谁是 192.168.1.20？告诉 192.168.1.10" 3. B 收到请求，单播 ARP 应答："我是 192.168.1.20，我的 MAC 是 xx:xx:xx" 4. A 收到应答，更新 ARP 缓存，用 B 的 MAC 封装数据发送 ``` - **跨网段场景** - 若目标 IP 不在同一网段，A 会把数据发给默认网关（路由器） - 此时 ARP 解析的是"网关的 MAC 地址"，而不是目标主机的 MAC - 数据到达网关后，网关再继续路由到目标网段 - **ARP 缓存与老化** - ARP 缓存：保存 IP→MAC 的映射表（`arp -n` 或 `ip neigh` 查看） - 缓存有老化时间（Linux 内核默认 base_reachable_time 30 秒，叠加随机因子后约 15~45 秒；Windows 约几分钟；Cisco 交换机默认可达 4 小时），过期后重新 ARP 查询 - `arp -d ` 或 `ip neigh del ` 手动删除缓存条目 - **ARP 的安全问题** - **ARP 欺骗/中毒（ARP Spoofing/Poisoning）**：攻击者伪造 ARP 应答，把网关 IP 映射到自己的 MAC，实现中间人攻击 - 防御：静态 ARP 绑定（`arp -s`）、交换机端口安全、DAI（Dynamic ARP Inspection） - **协助记忆** - ARP = "网络里的问路"："谁知道 192.168.1.20 在哪？"（广播问路）→ "是我，我的 MAC 是 xx"（单播回答）。 - 口诀："IP 找 MAC，广播问、单播答，缓存几分钟"。 - **进阶思考** - **ARP 是三层协议还是二层协议？** - 有争议。ARP 报文封装在以太网帧中（二层），但服务于 IP 层（三层），做 IP→MAC 映射。传统教材多归网络层，也有归数据链路层。准确说法："ARP 是二三层之间的桥接协议"。 - **免费 ARP（Gratuitous ARP）是什么？有什么用？** - 免费 ARP：主机主动广播自己的 IP→MAC 映射，用于：①检测 IP 冲突；②更新其他主机的 ARP 缓存；③故障转移时通知（如 Keepalived 切换 VIP 后发免费 ARP）。 - **为什么跨网段时 ARP 解析的是网关而不是目标主机？** - 因为 ARP 只在同一广播域（网段）内有效。跨网段的数据必须经过网关（路由器）转发，所以本机只需知道"网关在哪"（网关的 MAC），数据交给网关后由网关继续路由。 - **扩展信息** - **ARP 相关命令**： ```bash arp -n # 查看 ARP 缓存（旧命令） ip neigh show # 查看邻居表（ARP 缓存，新命令） ip neigh add 192.168.1.20 lladdr xx:xx:xx nud permanent dev eth0 # 手动添加静态 ARP（permanent 永不过期） ip neigh del 192.168.1.20 # 删除 ARP 条目 arping -I eth0 192.168.1.20 # ARP 探测（确认主机是否存在） ``` - **ARP 报文格式**： - 硬件类型（2 字节）、协议类型（2 字节） - 硬件地址长度（1）、协议地址长度（1） - 操作码（2 字节：1=请求、2=应答） - 发送方 MAC+IP（各 6/4 字节）、目标 MAC+IP（各 6/4 字节） ## 🤔 简述交换机的工作原理？ - **交换机工作在数据链路层（第二层），核心功能是基于 MAC 地址在局域网内转发数据帧。工作原理：①学习（记录源 MAC 到端口映射）②转发（根据目的 MAC 查表转发）③泛洪（未知 MAC 时广播到所有端口）④过滤（同端口不转发）。它构建了局域网内的二层通信。** - **核心机制** - **MAC 地址学习**：收到帧时，记录"源 MAC → 来源端口"到 MAC 地址表（CAM 表） - **查表转发**：收到帧时，查目的 MAC 对应的端口，从该端口转发 - **泛洪（Flooding）**：目的 MAC 未知时（表中无记录）广播到所有端口（除来源端口）；广播帧（FF:FF:FF:FF:FF:FF）和组播帧同样会被泛洪（除非启用 IGMP Snooping） - **MAC 地址老化**：MAC 表项有老化定时器（默认约 300 秒），无流量则自动删除 - **过滤**：源端口和目的端口相同时，不转发（丢弃） - **转发模式** - **存储转发（Store-and-Forward）**：完整接收帧，校验 CRC 后再转发，延迟稍大但可靠 - **直通转发（Cut-Through）**：收到目的 MAC 就立即转发，延迟小但不校验 CRC（可能转发错误帧） - **碎片隔离（Fragment-Free）**：收到前 64 字节后转发（过滤冲突碎片），折中方案 - **与集线器（Hub）的区别** - 集线器：物理层设备，广播到所有端口，共享带宽，所有设备在同一个冲突域 - 交换机：数据链路层，按 MAC 定向转发，独享带宽，每个端口独立冲突域 - 交换机通过隔离冲突域提升网络性能 - **广播域与冲突域** - 冲突域（Collision Domain）：共享介质的范围（集线器所有端口同一冲突域，交换机每个端口独立冲突域） - 广播域（Broadcast Domain）：广播帧能到达的范围（交换机默认不隔离广播，所有端口同一广播域） - 交换机缩小冲突域，路由器/VLAN 缩小广播域 - **交换机类型** - 二层交换机：只做 MAC 转发，传统交换机 - 三层交换机：增加路由功能（IP 转发），可跨 VLAN 通信 - 管理型 vs 非管理型：管理型支持 VLAN、QoS、端口聚合等配置 - **协助记忆** - 交换机 = "邮局分拣员"：看到来信（帧）就记下寄件人地址（学 MAC），查收件人地址（查表），知道就直送（转发），不知道就挨家问（泛洪）。 - 口诀："学习、转发、泛洪、过滤"——交换机四大动作。 - **进阶思考** - **交换机的 MAC 地址表满了会怎样？** - MAC 表满时，交换机会退化为"泛洪模式"（对未知 MAC 泛洪到所有端口），性能下降，且存在安全隐患（可被嗅探）。攻击者可用 MAC 泛洪攻击（MAC Flooding）填满表。防御：端口安全（限制每端口 MAC 数）。 - **交换机和路由器本质区别是什么？** - 交换机：二层设备，按 MAC 地址转发，隔离冲突域，同一广播域内通信 - 路由器：三层设备，按 IP 地址转发，隔离广播域，跨网段通信 - 一句话："交换机连同网段，路由器连不同网段" - **为什么要划分 VLAN？交换机不能直接做到吗？** - 二层交换机默认所有端口在同一广播域，无法隔离广播。VLAN 在二层交换机上逻辑划分多个广播域（不同 VLAN 不能直接通信，需三层设备路由）。所以 VLAN 是二层隔离广播的手段，跨 VLAN 通信需要三层交换机或路由器。 - **扩展信息** - **查看交换机 MAC 地址表**（思科风格示例）： ``` show mac address-table # 查看 MAC 表 # VLAN MAC Address Port # 10 aa:bb:cc:dd:ee:01 Gig0/1 # 10 aa:bb:cc:dd:ee:02 Gig0/2 ``` - **交换机端口模式**： - Access 端口：属于单一 VLAN，连接终端设备 - Trunk 端口：承载多个 VLAN（打 802.1Q 标签），连接交换机/路由器 - 配置示例（思科）：`switchport mode access`、`switchport mode trunk` ## 🤔 简述路由器的工作原理？ - **路由器工作在网络层（第三层），核心功能是基于 IP 地址在不同网络之间转发数据包（路由转发）。工作原理：①查路由表（根据目的 IP 找下一跳）②逐跳转发（数据包经过多个路由器，每跳都查表）③最长前缀匹配（最具体的路由优先）④默认路由兜底。** - **核心机制** - **路由表**：存储"目的网络 → 下一跳/出接口"的映射关系 - **查表转发**：收到数据包，根据目的 IP 查路由表，确定下一跳 - **逐跳转发（Hop-by-Hop）**：数据包不直达，而是经过多个路由器接力转发，每跳只关心"下一跳是谁" - **最长前缀匹配**：路由表中匹配目的 IP 的最具体（前缀最长）路由优先 - **默认路由**：没有匹配路由时，走默认路由（`0.0.0.0/0`，通常是出口网关） - **路由转发流程** ``` 收到数据包 1. 查目的 IP，解封装到网络层 2. 查路由表，找最长前缀匹配的路由 3. 若匹配：确定下一跳 IP 和出接口，TTL 递减并重算 IP 头校验和，重新封装（更新源/目的 MAC）转发；若 TTL 减为 0 则丢包并回 ICMP Time Exceeded 4. 若无匹配：丢包并回 ICMP "网络不可达"（若无默认路由） ``` - **路由器与交换机的区别** | 维度 | 交换机（二层） | 路由器（三层） | |------|--------------|--------------| | 工作层 | 数据链路层 | 网络层 | | 寻址 | MAC 地址 | IP 地址 | | 转发依据 | MAC 地址表 | 路由表 | | 隔离域 | 冲突域 | 广播域 | | 作用范围 | 同网段（局域网） | 跨网段（广域网） | - **路由表的来源** - 直连路由：路由器接口直接连接的网段（自动生成） - 静态路由：手动配置（`ip route add`） - 动态路由：路由协议自动学习（OSPF、BGP、RIP 等） - **协助记忆** - 路由器 = "城市快递中转站"：收到包裹（数据包）看收件地址（目的 IP），查地图（路由表）决定下一站（下一跳），一站一站接力（逐跳转发）送到目的地。 - 口诀："查路由表、找下一跳、逐跳转发、最长前缀匹配"。 - **进阶思考** - **什么是下一跳（Next Hop）？为什么路由器不直接知道完整路径？** - 下一跳是数据包要发往的"下一个路由器"的 IP 地址。IP 网络是逐跳转发模型，每个路由器只知道"下一步交给谁"，不知道完整路径。这是互联网可扩展性的关键设计（无需全网拓扑信息）。 - **最长前缀匹配为什么重要？** - 路由表可能有重叠路由（如 `10.0.0.0/8` 和 `10.1.0.0/16`），目的 IP `10.1.2.3` 同时匹配两条。最长前缀匹配选择更具体（前缀更长）的 `10.1.0.0/16`，实现精细化路由。 - **默认路由（0.0.0.0/0）有什么作用？** - 默认路由匹配所有 IP（前缀长度 0），作为"兜底"路由。当没有更具体的路由匹配时，数据包走默认路由（通常是出口网关）。没有默认路由时，未匹配的数据包被丢弃并回 ICMP 不可达。 - **扩展信息** - **查看和添加路由（Linux）**： ```bash ip route show # 查看路由表 ip route add 10.0.0.0/8 via 192.168.1.1 dev eth0 # 添加静态路由 ip route add default via 192.168.1.1 # 添加默认路由 ip route del 10.0.0.0/8 # 删除路由 ``` - **路由表字段解读**： ``` default via 192.168.1.1 dev eth0 # 默认路由：下一跳 192.168.1.1，出接口 eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 # 直连路由 ``` ## 🤔 什么是静态路由与动态路由？ - **静态路由是管理员手动配置的固定路由，动态路由是路由器通过路由协议自动学习和更新的路由。核心区别：静态路由简单可控但需手动维护（适合小网络/固定路径），动态路由自动收敛但配置复杂（适合大网络/拓扑变化频繁）。** - **静态路由（Static Routing）** - 管理员手动指定"目的网络 → 下一跳/出接口" - 优点：简单、可控、无协议开销、安全（路由不会被动改变）、稳定 - 缺点：网络变化需手动更新；大网络配置量大；无法自动绕过故障链路 - 适用：小网络、固定路径、边缘网络（如家庭、分支机构出口）、需要精确控制路由的场景 - **动态路由（Dynamic Routing）** - 路由器通过路由协议（OSPF、BGP、RIP 等）自动交换路由信息、学习拓扑 - 优点：自动适应拓扑变化（链路故障自动绕行）、适合大网络、配置维护简单（新增网络自动学习） - 缺点：协议开销（CPU/带宽）、配置复杂、可能产生路由环路/振荡（需协议本身防环机制） - 适用：中大型网络、拓扑变化频繁、需要冗余和自动故障切换的场景 - **对比速查** | 维度 | 静态路由 | 动态路由 | |------|---------|----------| | 配置方式 | 手动 | 协议自动 | | 维护成本 | 高（变化需手动改） | 低（自动学习） | | 协议开销 | 无 | 有（CPU/带宽） | | 故障恢复 | 无法自动绕行 | 自动收敛绕行 | | 安全性 | 高（不被动变） | 需认证防路由注入 | | 适用规模 | 小网络 | 中大网络 | - **实际网络中的组合使用** - 核心网络用动态路由（自动收敛），边缘出口用静态路由（默认路由指向 ISP） - 典型：企业内网 OSPF 动态路由，出口路由器静态默认路由 + BGP 对接运营商 - **协助记忆** - 静态路由 = "手写地图"（自己画路线，路变了要手动改）；动态路由 = "导航软件"（自动规划，路况变了自动绕行）。 - 选型口诀："小网络静态够，大网络动态省心；核心用动态，边缘用静态"。 - **进阶思考** - **为什么大网络不适合纯静态路由？** - ①配置量爆炸（N 个网段需要 N×(N-1) 条路由）；②链路故障无法自动绕行（需人工介入）；③新增网段需在所有路由器手动配置。动态路由协议自动完成这些工作。 - **静态路由和默认路由是什么关系？** - 默认路由（`0.0.0.0/0`）是特殊的静态路由，匹配所有目的地址，作为"兜底"（默认路由也可由 OSPF default-information originate 或 BGP 动态下发，不限于静态配置）。边缘网络常只配一条默认路由指向出口，减少配置量。 - **浮动静态路由（Floating Static Route）是什么？** - 静态路由可以设置管理距离（AD），作为动态路由的"备份"。主链路（动态路由）故障时，备份的静态路由（AD 更高）自动生效，实现静态+动态的冗余组合。 - **扩展信息** - **Linux 静态路由配置**： ```bash ip route add 10.0.0.0/8 via 192.168.1.1 # 临时添加 # 永久配置（CentOS/RHEL）：/etc/sysconfig/network-scripts/route-eth0 # 或 Netplan（Ubuntu）/ NetworkManager ``` - **路由优先级（管理距离 AD）**： - 直连路由：0（最高优先级） - 静态路由：1 - OSPF：110 - RIP：120 - BGP：20（外部）/ 200（内部） - AD 越小越优先，同一目的多条路由时按 AD 选 ## 🤔 动态路由协议有哪些及作用？ - **动态路由协议按工作范围分两类：IGP（内部网关协议，用于自治系统内部，如 OSPF、RIP、IS-IS）和 EGP（外部网关协议，用于自治系统之间，如 BGP）。核心作用：让路由器自动交换路由信息、学习网络拓扑、实现故障自动收敛。** - **内部网关协议（IGP，同一自治系统内）** - **OSPF（Open Shortest Path First）**：链路状态协议，基于 SPF/Dijkstra 算法计算最短路径，收敛快、支持分层（Area）、无环路，企业网最常用 - **RIP（Routing Information Protocol）**：距离矢量协议，按跳数（最大 15 跳）选路，简单但收敛慢、不支持大网络，已基本被 OSPF 取代 - **IS-IS（Intermediate System to Intermediate System）**：链路状态协议，与 OSPF 类似，运营商网络常用 - **EIGRP（Enhanced Interior Gateway Routing Protocol）**：思科私有协议（现已部分开放），混合型，收敛快 - **外部网关协议（EGP，自治系统之间）** - **BGP（Border Gateway Protocol）**：互联网的核心路由协议，连接不同自治系统（AS），基于路径矢量算法，支持策略路由，承载互联网全局路由表 - 应用：运营商之间、企业与运营商之间、云专线对接 - **距离矢量 vs 链路状态** - **距离矢量（RIP）**：路由器只和邻居交换"我到某网络的距离"，逐跳传播，收敛慢、易环路（靠水平分割/毒性逆转防环） - **链路状态（OSPF/IS-IS）**：每个路由器广播完整链路状态，全网拓扑一致，各自计算最短路径，收敛快、无环路 - **路由协议选型** - 企业内网：OSPF（主流，收敛快、支持分层） - 运营商骨干：IS-IS 或 OSPF - 互联网互联：BGP - 简单小网络：静态路由即可 - **协助记忆** - OSPF = "全网地图计算最短路径"（链路状态），RIP = "邻居间口口相传距离"（距离矢量，最多 15 跳），BGP = "互联网的国境线协议"（自治系统之间）。 - 口诀："内部用 OSPF，外部用 BGP；OSPF 快而稳，BGP 管互联网"。 - **进阶思考** - **OSPF 和 RIP 的本质区别是什么？** - OSPF 是链路状态协议：每个路由器有全网完整拓扑（LSDB），用 Dijkstra 算法独立计算最短路径，收敛快（秒级）、无环路 - RIP 是距离矢量协议：只知"距离+方向"，逐跳传播，收敛慢（分钟级）、有 15 跳限制、易环路 - 现代网络几乎都用 OSPF，RIP 仅用于教学和小型实验 - **BGP 为什么是互联网的核心协议？** - 互联网由无数自治系统（AS）组成，BGP 在 AS 之间交换路由，支持策略路由（路径选择、过滤），并能承载数十万条路由。BGP 的稳定性和策略能力是互联网互联的基础。 - **什么是路由收敛（Convergence）？** - 收敛是网络拓扑变化后，所有路由器路由表达到一致状态的过程。收敛越快，故障影响越小。链路状态协议（OSPF）收敛快（秒级），距离矢量（RIP）慢（分钟级）。 - **扩展信息** - **常见路由协议端口/协议号**： - OSPF：IP 协议号 89 - RIP：UDP 520 - BGP：TCP 179 - IS-IS：直接封装在数据链路层 - **自治系统（AS）与 AS 号**： - AS 是单一机构管理的网络集合，AS 号由 IANA 分配（16 位/32 位） - 企业内网通常用私有 AS 号（64512~65535），运营商/互联网用公有 AS 号 ## 🤔 VLAN 是什么？解决了什么问题？ - **VLAN（Virtual Local Area Network，虚拟局域网）是在二层交换机上把物理网络逻辑划分成多个隔离的广播域。它解决的问题：①隔离广播域（减少广播风暴）②增强安全性（不同部门隔离）③灵活组网（不受物理位置限制）。核心：一台物理交换机划分出多个逻辑上独立的子网。** - **VLAN 解决的问题** - **广播隔离**：默认交换机所有端口在同一广播域，广播帧会泛洪到所有端口；划分 VLAN 后，广播只在同 VLAN 内传播，减少广播风暴 - **安全隔离**：不同 VLAN（如财务部和研发部）二层隔离，不能直接通信，需三层路由且可配 ACL 控制 - **灵活组网**：同一 VLAN 的主机可跨物理交换机（通过 Trunk 链路），不受物理位置限制 - **资源优化**：减少广播流量，提高带宽利用率 - **VLAN 的基本概念** - **VLAN ID**：1~4094（0 和 4095 保留），每个 VLAN 一个唯一 ID - **Access 端口**：属于单一 VLAN，连接终端设备（PC、服务器），收发不带标签的帧 - **Trunk 端口**：承载多个 VLAN，连接交换机/路由器，帧带 802.1Q 标签（VLAN ID） - **VLAN 1**：默认 VLAN，所有端口默认属于 VLAN 1 - **VLAN 工作原理（802.1Q 标签）** - Trunk 链路的帧插入 4 字节 802.1Q 标签（含 VLAN ID），接收端根据标签识别 VLAN - Access 端口收到帧时打上本端口 VLAN 标签，发出时剥离标签 - 跨交换机的 VLAN 通信通过 Trunk 链路传输 - **跨 VLAN 通信** - 不同 VLAN 二层隔离，需要三层设备（路由器/三层交换机）做路由转发 - 传统方式：单臂路由（一个物理接口划分多个子接口，每个对应一个 VLAN） - 现代方式：三层交换机（SVl，Switch Virtual Interface，每个 VLAN 一个虚拟接口做网关） - **典型应用场景** - 企业：财务部、研发部、人事部各划分独立 VLAN，隔离访问 - 数据中心：不同业务/租户划分 VLAN 隔离 - 校园网：教学区、办公区、宿舍区 VLAN 隔离 - **协助记忆** - VLAN = "把一栋大楼划分成多个独立单元"：同一栋楼（物理交换机），不同单元（VLAN）之间互不相通，需要门禁（三层路由）才能往来。 - 口诀："VLAN 隔离广播域，Access 连终端，Trunk 连交换机，跨 VLAN 要路由"。 - **进阶思考** - **VLAN 和子网（Subnet）有什么区别？** - VLAN 是二层概念（数据链路层），隔离广播域，用 VLAN ID 标识 - 子网是三层概念（网络层），隔离 IP 网段，用 IP 地址/子网掩码标识 - 通常一个 VLAN 对应一个子网（一对一），但技术上可以一个 VLAN 多个子网（不常见） - **为什么需要 Trunk 端口？** - 多台交换机互联时，若每台交换机有多个 VLAN，需要一条链路同时传输多个 VLAN 的流量。Trunk 端口通过 802.1Q 标签区分不同 VLAN，实现一条物理链路承载多个 VLAN。 - **Native VLAN 是什么？** - Native VLAN 是 Trunk 链路上不打标签的 VLAN（默认 VLAN 1）。Untagged 帧在 Trunk 上默认属于 Native VLAN。安全最佳实践：Native VLAN 不要用于业务（避免 VLAN 跳跃攻击）。 - **扩展信息** - **VLAN 配置示例（思科风格）**： ``` vlan 10 # 创建 VLAN 10 name Finance # 命名 interface Gig0/1 # Access 端口配置 switchport mode access switchport access vlan 10 interface Gig0/24 # Trunk 端口配置 switchport mode trunk switchport trunk allowed vlan 10,20,30 ``` - **VLAN 范围分类（802.1Q 通用标准）**： - 0 与 4095：保留（0 为默认/不可用，4095 为管理帧） - 1~4094：正常 VLAN（可自由使用） - 注意：1002~1005 在 Cisco 设备中保留（非 IEEE 标准），不同厂商有差异 ## 🤔 Linux 如何添加路由？ - **Linux 添加路由用 `ip route add` 命令（现代，推荐）或 `route add`（旧命令）。核心语法：`ip route add <目的网段> via <下一跳IP> dev <网卡>`。临时添加直接生效但重启丢失，永久配置需写入网络配置文件。** - **基本语法** ```bash # 添加静态路由：访问 10.0.0.0/8 网段，下一跳 192.168.1.1，走 eth0 ip route add 10.0.0.0/8 via 192.168.1.1 dev eth0 # 添加默认路由（0.0.0.0/0 可省略） ip route add default via 192.168.1.1 dev eth0 # 添加直连路由（该网段直接连接在 eth0 上） ip route add 192.168.2.0/24 dev eth0 # 添加指定源地址的路由 ip route add 10.0.0.0/8 via 192.168.1.1 src 192.168.1.10 ``` - **查看与删除路由** ```bash ip route show # 查看完整路由表 ip route get 8.8.8.8 # 查询到 8.8.8.8 会走哪条路由 ip route del 10.0.0.0/8 # 删除路由 route -n # 旧命令查看路由表 ``` - **永久配置（重启不丢失）** - **CentOS/RHEL（NetworkManager 或传统 network）**： ```bash # 方法一：nmcli（NetworkManager） nmcli connection modify eth0 +ipv4.routes "10.0.0.0/8 192.168.1.1" nmcli connection up eth0 # 方法二：传统 network 脚本 # 编辑 /etc/sysconfig/network-scripts/route-eth0 # 内容：10.0.0.0/8 via 192.168.1.1 dev eth0 ``` - **Ubuntu（Netplan）**： ```yaml # /etc/netplan/01-netcfg.yaml network: ethernets: eth0: routes: - to: 10.0.0.0/8 via: 192.168.1.1 # 应用：netplan apply ``` - **通用（systemd-networkd）**：在 `.network` 文件的 `[Route]` 段配置 - **多网卡场景的路由** - 多个网卡（多出口）时，需要为不同网段指定不同网卡和下一跳 - 策略路由（Policy Routing）：基于源地址/协议等规则选路，用 `ip rule` + 多张路由表 - 典型场景：内网走 eth0、外网走 eth1 - **协助记忆** - 添加路由 = "告诉系统怎么走"：`ip route add 目的地 via 下一跳 dev 网卡`。 - 口诀："目的网段 + 下一跳 + 出接口"；临时用 `ip route add`，永久写配置文件。 - **进阶思考** - **`ip route add` 和 `route add` 有什么区别？** - `ip route` 是 iproute2 工具集（现代，功能强大，推荐） - `route` 是 net-tools 工具集（旧，功能有限，已废弃） - 两者功能重叠，但 `ip route` 支持策略路由、多路由表等高级功能 - **为什么多网卡主机需要策略路由？** - 默认只有一张主路由表，所有流量按目的地址选路。多网卡时（如内网+外网），需要"从内网口进来的流量从内网口回"，这需要基于源地址的策略路由（`ip rule` + 多路由表），否则回程可能走错网卡导致通信失败。 - **路由不生效怎么排查？** - ①`ip route get <目的IP>` 查看实际走哪条路由；②检查是否被更具体的路由覆盖；③检查网卡是否 up；④检查防火墙是否放行；⑤检查下一跳是否可达（`ip neigh`）。 - **扩展信息** - **策略路由配置示例（多网卡）**： ```bash # 创建自定义路由表（表 100 用于内网） ip route add 192.168.0.0/16 dev eth0 table 100 ip route add default via 192.168.1.1 dev eth0 table 100 # 规则：源地址 192.168.x.x 的流量走表 100 ip rule add from 192.168.0.0/16 table 100 ``` - **路由表类型**： - `local`：本地路由表（本机地址、广播），优先级最高 - `main`：主路由表（默认，`ip route` 操作的表） - `default`：默认路由表（一般不用） - 自定义表：table 100~65535，用于策略路由 ## 🤔 Linux 网络慢，如何排查？ - **Linux 网络慢的排查分"系统侧"和"应用侧"两条线：系统侧排查网络/内核性能（带宽、连接、CPU），应用侧排查后端服务响应时间。常用工具：`iftop`/`nethogs`（实时带宽）、`nstat`（协议栈统计）、`ss`（连接状态）、`perf top`（CPU 热点）、`wrk`/`ab`（HTTP 压测）。** - **第一步：区分是"网络慢"还是"应用慢"** - `ping`/`mtr`：若 RTT 高 → 网络层问题；若 RTT 正常但 HTTP 慢 → 应用层问题 - `curl -w '%{time_total}'`：记录总请求时间，分别看 DNS/TCP/首字节/总时间，定位瓶颈段 - `top`/`htop`：CPU 100% → 应用 CPU 密集；磁盘 %util 高 → IO 瓶颈 - **第二步：系统层排查** - 带宽：`iftop -i eth0`（实时流量）、`nstat`（TCP 统计） - 连接：`ss -s`（连接数）、`ss -tan`（状态分布，如大量 TIME_WAIT） - CPU/IO：`top`（CPU 密集？）、`iostat`（磁盘等待高？） - 软中断：`mpstat -P ALL 1`（某个 CPU 打满 → 多队列/绑核优化） - **第三步：应用层排查** - `wrk -t4 -c200 -d10s http://target`：压测看吞吐和延迟 - `curl -w`：单请求拆解时间（DNS/TCP/TTFB/总时间） - Nginx 日志：`$upstream_response_time` 高的接口是瓶颈 - 数据库：慢查询（`slow_query_log`）、锁等待 - **常见根因与解决** | 根因 | 现象 | 解决 | |------|------|------| | 网络拥塞 | RTT 高、重传多 | 调优内核参数、限流、升级带宽 | | DNS 慢 | 首次请求 TTFB 长 | 本地 DNS 缓存、公网 DNS 优化 | | CPU 热点 | top 中某进程 CPU 100% | 优化代码、多实例、绑核 | | 磁盘 IO | iostat %util 高 | SSD、优化查询、减少磁盘写 | | 后端慢 | upstream_response_time 高 | 优化 SQL、增加后端节点 | - **协助记忆** - 排查口诀："先看方向（网络 or 应用），再看层次（带宽/CPU/IO），后看业务（接口/SQL）"。 - 工具口诀："iftop 看流量，nstat 看 TCP，top 看 CPU，iostat 看磁盘，wrk 压应用"。 - **进阶思考** - **如何精确定位"某个 HTTP 接口慢"？** - Nginx 日志加 `$request_time`/`$upstream_response_time` 字段 → 日志聚合按接口/P99 延迟排序 → 找出慢接口 → 下游定位（上游处理时间 vs Nginx 代理时间）。 - **高并发下 Nginx 本身的性能瓶颈在哪？** - 常见：①`worker_connections`/fd 不足（报 `worker_connections are not enough`）；②本地端口耗尽（大量出站）；③单核 CPU 吃满（SSL/正则/压缩）；④磁盘 IO（大文件/日志写）。 - **如何区分"丢包"和"延迟高"导致的慢？** - `mtr -r -c 100`：按跳丢包率区分（某跳丢包 = 网络问题）；`ping -c 100` 看丢包率；RTT 基线 vs 实际对比。丢包重传是慢的常见原因，但"高延迟+低丢包"通常是带宽/拥塞问题。 - **扩展信息** - **常用监控/排查命令速查**： ```bash iftop -i eth0 # 实时带宽监控 nethogs eth0 # 按进程看带宽 nstat # TCP 协议栈增量统计（无 -s 参数，直接运行输出） mpstat -P ALL 1 # 各 CPU 利用率 iostat -x 1 # 磁盘 IO wrk -t4 -c100 -d10s http://target # HTTP 压测 ``` - **Nginx 日志中的时间字段（压测分析利器）**： - `$request_time`：客户端请求到 Nginx 完成响应的总时间 - `$upstream_response_time`：Nginx 到后端的往返时间（纯后端耗时） - `$upstream_connect_time`：Nginx 与后端的 TCP 连接耗时 - 两者差值 = Nginx 处理时间（通常极小，大说明 Nginx 自身有瓶颈） ## 🤔 有哪些常用的网络故障排查工具及作用？ - **网络故障排查工具按功能分五类：连通性（ping/mtr/traceroute）、抓包分析（tcpdump/Wireshark）、流量监控（iftop/nethogs）、配置查看（ip/ss/netstat）、协议统计（nstat/netstat -s）。核心：先定方向（哪一层的问题），再选工具。** - **连通性测试** - `ping`：ICMP 回显，测基本连通性和 RTT，失败仅说明 ICMP 不通（可能防火墙拦截） - `mtr`：连续 traceroute + ping，逐跳显示丢包率和延迟，定位故障跳数 - `traceroute`：追踪数据包经过的路由器，找出延迟/丢包的跳数 - **抓包分析** - `tcpdump`：命令行抓包，BPF 过滤精确筛选，可保存 pcap 供分析 - Wireshark：图形化分析，支持协议解码、统计、流跟踪、IO 图 - **流量监控** - `iftop`：实时按 IP 显示各连接带宽（`-i eth0` 指定网卡） - `nethogs`：实时按进程显示带宽（类似 Windows 资源监视器的网络列） - `nload`：实时显示网卡入/出流量图形 - **配置与状态查看** - `ip addr/route/neigh`：查看 IP、路由、ARP 缓存 - `ip -s link`：网卡收发包统计（丢包/错误） - `ss -tan`：TCP 连接状态分布（TIME_WAIT/CLOSE_WAIT 等） - `netstat -s`：协议栈统计（重传、溢出、丢包计数） - **协议统计与压测** - `nstat`/`netstat -s`：TCP/IP 协议栈统计（重传、丢包、超时） - `curl -w`：单请求时间拆解（DNS/TCP/首字节/总时间） - `wrk`/`ab`：HTTP 压测工具（QPS、延迟、错误率） - **协助记忆** - 五类工具口诀："ping 看通不通，tcpdump 看包，iftop 看流量，ip/ss 看配置，nstat 看统计"。 - 排查路线："先测连通→再查流量→再看配置→最后抓包分析"。 - **进阶思考** - **什么时候该用 `tcpdump` 而不是 `iftop`？** - `iftop` 看"哪个连接在用流量"（宏观），`tcpdump` 看"连接里到底传了什么"（微观）。`iftop` 发现异常流量 → `tcpdump` 抓包深入分析。前者快速定位异常连接，后者确认协议内容。 - **`wrk` 和 `ab` 哪个更适合生产压测？** - `wrk`：多线程、Lua 脚本扩展、性能远高于 ab（尤其是 HTTP/1.1 keepalive），适合生产环境压测 - `ab`：功能简单、输出直观，适合简单测试和对比 - 生产压测用 `wrk`，快速验证用 `ab`。 - **运维排查时如何快速判断是 Nginx 问题还是后端问题？** - 看 Nginx access_log 中 `$upstream_response_time`：若值高 → 后端慢；若接近 0 但 `$request_time` 高 → Nginx 自身处理慢（少见）。error.log 中 `upstream timed out` → 后端超时；`connect() failed` → 后端连不上。 - **扩展信息** - **工具速查表**： | 场景 | 工具 | |------|------| | 通不通 | ping / mtr / traceroute | | 看什么包 | tcpdump / Wireshark | | 谁在用带宽 | iftop / nethogs | | IP/路由/ARP | ip addr/route/neigh | | TCP 状态 | ss / netstat | | 协议统计 | nstat / netstat -s | | HTTP 性能 | wrk / curl -w | | CPU 热点 | perf top / top | | 磁盘 IO | iostat | - **排查顺序口诀**："先看通不通（ping）→ 再看谁在吃（iftop）→ 再看系统撑得住不（top/iostat）→ 再看包里有啥（tcpdump）" ## 🤔 Linux 服务器网络不通，如何排查？ - **Linux 网络不通的排查分"本地不通"和"跨网不通"两种场景：本地不通从网卡/IP/路由入手，跨网不通从路由/防火墙/邻居表入手。核心工具链：`ip addr`（IP）→ `ip route`（路由）→ `ip neigh`（邻居/ARP）→ `ping`（连通性）→ `tcpdump`（抓包）→ `iptables`/`firewalld`（防火墙）。** - **排查思路：分层定位** ``` 1. 网卡是否 UP？ → ip link show 2. IP 是否正确配置？ → ip addr show 3. 路由是否正确？ → ip route show / ip route get <目标> 4. ARP 能否解析？ → ip neigh show（看目标是否有 MAC） 5. ping 测试 → ping <网关> / ping <目标> 6. 防火墙是否拦截？ → iptables -L / firewall-cmd --list-all ``` - **第一层：检查网卡和 IP** ```bash ip link show # 网卡是否 UP？MTU 是否正确？ ip addr show # IP 是否正确配置？子网掩码是否正确？ systemctl status NetworkManager # 或 systemctl status network ``` - 常见问题：网卡 DOWN、IP 未分配（DHCP 失败）、IP 冲突、MTU 不匹配 - **第二层：检查路由** ```bash ip route show # 看是否有默认路由 ip route get <目标IP> # 看实际走哪条路由 ``` - 常见问题：默认路由缺失、路由指向错误网关、路由被其他路由覆盖 - **第三层：检查 ARP/邻居表** ```bash ip neigh show # 看 ARP 缓存，目标是否有 MAC ``` - 有目标 MAC → 二层可达 - 无目标 MAC / 状态为 FAILED → ARP 失败（可能三层以下就有问题） - **第四层：ping 和防火墙** ```bash ping <网关IP> # 测到网关 ping <目标IP> # 测到目标 iptables -L -n # 查防火墙规则 firewall-cmd --list-all # firewalld 规则 ``` - ping 网关通、ping 目标不通 → 路由/中间网络问题 - ping 网关不通 → 网卡/链路/网关故障 - 防火墙拦截：注意 input 链和 forward 链（转发场景） - **第五层：抓包定位（复杂场景）** ```bash tcpdump -i eth0 -nn 'host <目标IP>' # 抓包看交互 ``` - 看是否有 SYN 发出但无 SYN+ACK（丢包/防火墙） - 看是否有 RST（对端拒绝） - 看是否有 ACK 但无响应（中间链路问题） - **常见场景与解决** | 场景 | 现象 | 排查方向 | |------|------|---------| | 本机 IP 未配置 | 网卡 UP 但无 IP | DHCP 重试/静态配置 | | 默认路由缺失 | ping 网关不通 | `ip route add default via ...` | | 防火墙拦截 | ping 目标不通 | `iptables -L`、`firewall-cmd` | | DNS 不通 | 域名无法解析但 IP 可 ping | `/etc/resolv.conf`、DNS 服务器 | | MTU 问题 | 小包通、大包断 | `ping -M do -s 1472` 测 MTU | | ARP 不通 | `ip neigh` 状态 FAILED | 网卡/链路/广播域隔离 | - **协助记忆** - 排查口诀："先看卡（ip link），再看 IP（ip addr），看路由（ip route），看 ARP（ip neigh），最后 ping 和防火墙"。 - 定位口诀："ping 网关不通 → 网卡/链路问题；ping 目标不通 → 路由/防火墙问题；DNS 不通 → 配置文件问题"。 - **进阶思考** - **能 ping 通网关但 ping 不通目标，最可能是什么问题？** - ①缺少到目标网段的路由（`ip route show` 检查）；②对端有防火墙拦截；③中间有设备丢包（`mtr` 定位）；④对端主机不可达但网络可达（主机防火墙拦截 ICMP）。 - **TCP 连接不通但 UDP 通是什么问题？** - ①防火墙只放行了 UDP 不放行 TCP；②目标端口未监听（UDP 不需监听即可接收）；③TCP 队列满（如 SYN Flood 导致 listen backlog 满）。 - **如何排查"SSH 断开后连不上"？** - 先 ping 测试基本连通 → 用其他端口/机器测试是否防火墙 → 检查 SSH 端口监听状态 → 用 `tcpdump port 22` 抓包看是否有 SYN/ACK 交互 → 检查 SSH 日志（`/var/log/secure` 或 `journalctl -u sshd`）。 - **扩展信息** - **快速排查命令（万能排查序列）**： ```bash ip addr show # 1. IP 配置 ip link show # 2. 网卡状态/MTU ip route show # 3. 路由表 ip neigh show # 4. ARP/邻居表 ping -c 3 <网关> # 5. 到网关 ping -c 3 <目标> # 6. 到目标 traceroute <目标> # 7. 逐跳排查 ``` - **MTU 问题快速测试**： ```bash ping -M do -s 1472 <目标> # 1472+28=1500（标准MTU），若失败则MTU<1500 ping -M do -s 1400 <目标> # 逐步降低找临界值 ``` ## 🤔 Linux 上 traceroute 路由追踪实现原理是什么？ - **traceroute 通过发送 TTL 从 1 开始递增的探测包，利用沿途路由器在 TTL 到达 0 时返回的 ICMP "Time Exceeded"（类型 11）消息，逐跳定位从源到目标所经过的每一跳路由器（及延迟）。核心原理："故意让包死在每一跳，让路由器告诉我是谁"。** - **工作原理** ``` traceroute 工作流程（UDP 模式）： 1. 发送 TTL=1 的 UDP 探测包到目标端口（33434 起） → 第一跳路由器 TTL 减为 0，回 ICMP Time Exceeded（Type 11） → traceroute 收到，记录该跳的 IP 和 RTT 2. 发送 TTL=2 的 UDP 探测包 → 第一跳路由器 TTL=1 转发给第二跳 → 第二跳路由器 TTL 减为 0，回 ICMP Time Exceeded → traceroute 记录第二跳的 IP 和 RTT 3. 重复递增 TTL，直到收到目标的 ICMP Port Unreachable（Type 3, Code 3） 或达到最大跳数（默认 30） ``` - **不同平台的实现差异** | 平台 | 工具 | 协议 | 特点 | |------|------|------|------| | Linux | `traceroute` | UDP（默认） | 需 root；可用 `-I` 切 ICMP ping | | Linux | `traceroute -T` | TCP | 适用于防火墙拦截 ICMP/UDP 的场景 | | Linux | `mtr` | UDP/ICMP | traceroute + ping 持续监测（推荐） | | Windows | `tracert` | ICMP | 无需 root，默认用 ICMP | | macOS | `traceroute` | ICMP | macOS 默认用 ICMP | - **traceroute 输出解读** ``` traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.234 ms 1.112 ms 1.098 ms # 跳1：网关 2 10.0.0.1 (10.0.0.1) 5.432 ms 5.321 ms 5.298 ms # 跳2：运营商路由器 3 * * * # 跳3：超时（路由器不回 ICMP） 4 8.8.8.8 (8.8.8.8) 12.34 ms 12.28 ms 12.21 ms # 跳4：目标 ``` - `* * *`：该跳路由器不响应 ICMP（防火墙拦截或配置屏蔽）——不代表不可达 - 每行三个时间：三次探测的 RTT，可观察丢包和抖动 - RTT 逐跳增加是正常的（经过更多链路），某跳 RTT 突然增大才是网络瓶颈 - **traceroute 不通/卡住的原因** - 中间路由器丢弃 ICMP Time Exceeded → 那跳显示 `* * *`（丢包但可能仍可达） - 目标主机防火墙拦截 UDP → 最后一跳 `* * *`，但 HTTP 可能正常 - UDP traceroute 对防火墙不友好（改用 ICMP `traceroute -I` 或 TCP `traceroute -T`） - **mtr（推荐的增强版 traceroute）** ```bash mtr 8.8.8.8 # 实时交互模式 mtr -r -c 100 8.8.8.8 # 报告模式，100 次探测后输出 mtr -n 8.8.8.8 # 不解析 DNS（加快速度） ``` - 比 traceroute 多显示：丢包率、平均/最小/最大延迟——更利于网络质量分析 - **ICMP 与 UDP traceroute 的区别** - ICMP（`traceroute -I` 或 Windows `tracert`）：用 ICMP Echo Request 探测，简单可靠，但可能被防火墙拦截 - UDP（Linux `traceroute` 默认）：用高 UDP 端口探测，依赖中间路由器回 ICMP Time Exceeded，可能被防火墙拦截 - TCP（`traceroute -T` 或 `tcptraceroute`）：用 TCP SYN 探测，穿透防火墙能力强（很多防火墙只拦截 ICMP 不拦截 TCP） - **协助记忆** - traceroute = "逐跳问路"：发一个"超时的包"让每台路由器回一个"超时消息"，逐跳拼出完整路径。 - 原理口诀："TTL 从 1 递增，路由器 TTL 归零时回 ICMP Time Exceeded，逐跳记录 IP 和 RTT"。 - **进阶思考** - **为什么 traceroute 要用高端口（33434 起）？** - 高端口避免与常用服务端口冲突（若目标端口正好有服务在监听，会收到目标的响应而非中间路由器的 ICMP）。递增端口：33434、33435、33436...每跳递增 1。 - **traceroute 显示某跳 RTT 突然增大，是这一跳慢还是上一跳慢？** - RTT 是从探测发出到 ICMP 返回的往返时间，包含所有中间跳的延迟和排队时间。RTT 突增可能是该跳本身的延迟（如卫星链路），也可能是路径上的综合因素。更精确的定位需要双向 traceroute（两端同时测）或 mtr 持续观察。 - **Linux 默认 traceroute 用 UDP 而非 ICMP 的原因？** - UDP traceroute 可以用不同端口（33434+），在目标端口没有服务时会触发 ICMP Port Unreachable，便于识别最终到达目标。而 ICMP traceroute 只用一个目标地址，无法通过端口区分多目标。另外部分网络设备对 ICMP 有特殊限制。 - **扩展信息** - **traceroute 常用参数**： ```bash traceroute -I 8.8.8.8 # 用 ICMP 替代 UDP traceroute -T -p 80 8.8.8.8 # 用 TCP SYN 探测（穿透防火墙） traceroute -n 8.8.8.8 # 不解析 DNS（加快速度） traceroute -w 2 8.8.8.8 # 超时 2 秒（默认 5 秒） traceroute -m 10 8.8.8.8 # 最多 10 跳 ``` - **mtr 输出字段解读**： - `HOST`：路由器 IP - `%Loss`：丢包率（0% 正常，>5% 需关注） - `Snt`：已发送包数 - `Last`/`Avg`/`Best`/`Wrst`：最近/平均/最优/最差 RTT（ms） - `StDev`：RTT 标准差（抖动），越大越不稳定 --- > 作者: [0x5c0f](https://blog.0x5c0f.cc) > URL: https://blog.0x5c0f.cc/posts/other/%E8%BF%90%E7%BB%B4%E5%B8%B8%E8%A7%81%E9%A2%98-%E7%BD%91%E7%BB%9C%E7%BB%B4%E6%8A%A4/