Day 7-3 TCP/IP 分层模型与可达性认知
本章学习目标
| 目标 | 说明 |
|---|---|
| 理解网络基础 | 掌握 IP 地址、子网掩码、网关的核心概念，理解数据包如何在网络中流动 |
| 配置 Linux 网络 | 使用现代工具（nmcli / Netplan）为 Rocky Linux 10 和 Ubuntu 26.04 配置静态 IP |
| 理解 TCP/IP 模型 | 建立“请求如何到达服务器”的最小认知，区分 TCP 和 UDP |
| 熟练使用诊断工具 | 掌握 ip、ss、tcpdump、curl、ping、traceroute、mtr 等工具 |
| 独立排障 | 运用五层排查法，独立解决 SSH 无法连接、页面无法访问等常见故障 |
本章模块概览
本节导读
前两节我们学会了如何配置 IP 地址。但配置 IP 只是第一步——数据从泽冰的电脑发到小雅的服务器，中间经历了什么？这一节我们从整体上理解“请求如何到达服务器”。
回顾泽冰送花的两个场景：
| 场景 | 送花给同大厦的小芳 | 寄花给上海的小雅 |
|---|---|---|
| 通信类型 | 同子网通信 | 跨子网通信 |
| 关键设备 | 交换机 | 网关 + 路由器 |
| 寻址方式 | MAC 地址（门牌号） | IP 地址（城市 + 大厦）→ MAC 地址（门牌号） |
| 网络层级 | 二层通信（链路层） | 三层通信（网络层） |
同一个场景，不同的通信方式，对应了网络模型中不同的层级。
一、TCP/IP 网络模型
1.1 什么是 TCP/IP 模型？
TCP/IP 网络模型是一组四层通信协议，描述如何通过网络在计算机之间打包、寻址、传输、路由和接收数据通信。协议由 RFC 1122：互联网主机要求——通信层规定。
TCP/IP 模型的四个层分别为：应用层、传输层、互联网层和链路层。
1.2 四层职责详解
| 层级 | 名称 | 职责 | 协议示例 | 运维关注点 |
|---|---|---|---|---|
| 第 4 层 | 应用层 | 业务数据通信 | HTTP、SSH、DNS、FTP、SMTP | 服务配置、日志、应用协议 |
| 第 3 层 | 传输层 | 端到端连接 | TCP、UDP | 端口监听、连接状态、防火墙 |
| 第 2 层 | 互联网层 | 跨网段寻址和路由 | IP、ICMP | IP 地址、路由表、网关 |
| 第 1 层 | 链路层 | 同网段物理通信 | ARP、MAC、以太网 | 网卡状态、MAC 地址、网线 |
各层详细说明：
- 应用层：每一应用具有用于通信的规范，以便客户端和服务器可以跨平台通信。常用的协议有 SSH（远程访问）、HTTPS（安全 Web）、FTP（文件共享）以及 SMTP（电子邮件递送）等。
- 传输层：TCP 提供可靠的连接导向型通信方法，可确保数据交付和顺序。相比之下，UDP 属于无连接数据报协议，提供更快但没那么可靠的通信。HTTP 或 DNS 等应用协议使用特定的 TCP 或 UDP 端口进行通信，
/etc/services文件中提供了这些常用和已注册端口的完整列表。 - 互联网层：负责跨互连网络将数据包从源主机传输到目的地主机。这一层的关键协议包括 IPv4 和 IPv6。网络上的每个主机都具有唯一的 IP 地址和前缀，它们共同决定了主机的网络地址（例如
192.168.3.19/24）。路由器通过连接不同的网络并在这些网络之间转发流量，在这一层发挥着至关重要的作用。 - 链路层：提供与物理介质的连接。最常见的网络类型是有线以太网（802.3）和 Wi-Fi（802.11）。每一物理设备具有一个 MAC 地址，也称为硬件地址，用于标识局域网络段中数据包的目的地。
1.3 TCP/IP 四层模型 vs OSI 七层模型
虽然 TCP/IP 是网络标准，但 OSI 七层模型凭借更精细的结构，仍然是教学领域和运维沟通中的热门参考模型。
运维中常说的“四层”指的是传输层（TCP/UDP），“七层”指的是应用层（HTTP 等协议）。比如：
- 四层负载均衡：工作在传输层，基于 IP 和端口转发（如 LVS、F5）。
- 七层负载均衡：工作在应用层，基于 URL、Host 等应用内容转发（如 Nginx、HAProxy）。
对应关系与运维常用术语：
| OSI 七层 | TCP/IP 四层 | 运维常用说法 | 协议/设备示例 |
|---|---|---|---|
| 应用层 | 应用层 | 七层 | HTTP、HTTPS、DNS、Nginx、HAProxy |
| 表示层 | ↑ | — | SSL/TLS |
| 会话层 | ↑ | — | — |
| 传输层 | 传输层 | 四层 | TCP、UDP、LVS、F5 |
| 网络层 | 互联网层 | 三层 | IP、路由器 |
| 数据链路层 | 链路层 | 二层 | MAC、ARP、交换机 |
| 物理层 | 链路层 | 一层 | 网线、光纤、网卡 |
1.4 运维为什么要理解分层？
核心认知：网络排障是从下到上逐层排查的过程。先确认物理层（网线/光模块），再确认二层（ARP/MAC），然后三层（IP/路由），再四层（端口/防火墙），最后七层（服务/日志）。
1.5 数据封装过程
数据从发送端应用层开始，层层添加头部，最终成为在网络上传输的比特流：
各层封装内容与 PDU 名称：
| 层 | 封装内容 | PDU 名称 | 说明 |
|---|---|---|---|
| 应用层 | 用户数据（HTTP 请求、SSH 命令等） | Data（数据） | 业务数据 |
| 传输层 | TCP/UDP 头部（源端口 + 目标端口） | Segment（段）/ Datagram（数据报） | TCP 叫段，UDP 叫数据报 |
| 网络层 | IP 头部（源 IP + 目标 IP） | Packet（包/分组） | 跨网段寻址 |
| 链路层 | 以太网头部（源 MAC + 目标 MAC） | Frame（帧） | 同网段通信寻址 |
1.6 一个完整数据包的“洋葱结构”与解封装
发送端视角：从内到外逐层封装（包洋葱）
一个 HTTP 请求数据包，从最内层到最外层是这样的：
接收端视角：从外到内逐层解封（剥洋葱）
数据包到达接收端后，从最外层开始，逐层剥离头部，最终还原出原始数据：
从内到外各层头部的作用：
| 层级 | 头部信息 | 作用 | 类比 |
|---|---|---|---|
| 应用层 | GET /index.html | 实际要传输的业务数据 | 包裹里的物品本身 |
| 传输层 | 源端口：54321；目标端口：80 | 找到目标主机上的具体服务 | 包裹上的收件人姓名 |
| 网络层 | 源 IP：10.0.0.100；目标 IP：10.0.0.142 | 跨网络找到目标主机 | 快递单上的城市地址 |
| 链路层 | 源 MAC：aa:bb:cc:dd:ee:01；目标 MAC：aa:bb:cc:dd:ee:02 | 同一子网内找到目标设备 | 同城快递的门牌号 |
关键规则：谁有资格“剥洋葱”？
不是所有收到数据包的设备都会解封装。只有目标地址是自己的，才会继续解封装。
| 设备类型 | 收到数据包后的行为 |
|---|---|
| 主机（PC/服务器） | 检查目标 MAC 和 IP，如果目标不是自己，直接丢弃，不拆包。如果目标是自己的，逐层剥洋葱，直到交给应用。 |
| 路由器 | 检查目标 MAC（如果是自己的）和目标 IP，如果目标不是自己，剥掉二层 MAC 头，看三层 IP 头（Packet），然后查路由表转发出去。 |
| 交换机 | 只检查目标 MAC 地址，根据 MAC 地址表转发，不剥 IP 头（工作在二层，处理的是 Frame）。 |
结合泽冰寄花场景理解：
- 交换机 = 大厦物业：只看门牌号（MAC 地址），不管包裹里是什么。
- 路由器 = 快递分拣中心：打开外层包装看城市（IP 地址），决定发往哪个城市，然后重新打包发走。快递员不拆内层包裹（不剥 TCP 头），只处理面单（IP 头）。
- 小雅的电脑 = 最终收件人：确认门牌号（MAC）、确认收件人（IP）都对，才彻底拆开包裹（剥 TCP 头），取出里面的花（HTTP 数据）。
- Nginx = 小雅本人：包裹拆开后，花（HTTP 数据）最后要交到小雅（Nginx 进程）手上。Nginx 读取 HTTP 请求内容（GET /index.html），然后返回对应的网页文件。
逐层解读（从网卡到 Nginx）：
| 步骤 | 处理层 | 谁在处理 | 操作 | 结果 |
|---|---|---|---|---|
| 1 | 链路层 | 网卡驱动 | 检查目标 MAC 地址是否为本机网卡。确认是，剥掉以太网头部（Frame → Packet） | 露出 IP 头部 + 数据 |
| 2 | 网络层 | 内核网络栈 | 检查目标 IP 地址是否为本机。确认是，剥掉 IP 头部（Packet → Segment） | 露出 TCP 头部 + 数据 |
| 3 | 传输层 | 内核网络栈 | 检查目标端口是 80，确认有 Nginx 在监听，剥掉 TCP 头部（Segment → Data） | 露出 HTTP 请求数据（GET /index.html） |
| 4 | 应用层 | Nginx 进程 | 将 HTTP 请求交给 Nginx | Nginx 处理请求：读取 /index.html，返回网页内容 |
最终目标：所有解封装都是为了最后一刻——把数据交到真正处理业务的进程手里。对 80 端口来说，就是 Nginx；对 22 端口来说，就是 sshd。整个网络协议栈的工作到这里才算真正完成。
二、传输层：TCP vs UDP
传输层提供端到端的通信服务，最主要的两个协议是 TCP 和 UDP。
2.1 TCP vs UDP 对比
| 对比项 | TCP | UDP |
|---|---|---|
| 连接方式 | 面向连接（先建立连接） | 无连接（直接发） |
| 可靠性 | 可靠传输，确认重传 | 不可靠，丢了不管 |
| 速度 | 较慢 | 较快 |
| 适用场景 | SSH、HTTP、MySQL | DNS、视频流、游戏 |
| 类比 | 打电话 | 广场广播 |
2.2 为什么 UDP 不可靠还要用？
很多人第一次学到这里都会问：UDP 不可靠，为什么还在用？不怕丢数据吗？
答案是：有些场景宁可丢数据，也不能等。
场景一：实时音视频通话
泽冰和小雅视频通话时，如果网络抖动丢了一个视频帧，最好的处理方式是直接丢掉，继续播下一帧。如果等重传，画面会卡顿，声音会延迟。
- TCP 方案：丢帧 → 等待重传 → 画面卡住 → 用户体验极差。
- UDP 方案：丢帧 → 直接忽略 → 画面略微模糊但流畅 → 用户基本无感知。
场景二：DNS 查询
DNS 查询的请求和响应都非常小（通常几百字节），一次查询就完成了。如果丢了，客户端等几秒超时后重新发一次就行，不需要建立连接的开销，即一次完成，没有三次握手，没有四次挥手，效率极高。
场景三：游戏
FPS 射击游戏中，玩家的位置每秒要上报几十次。如果某一帧丢了，下一帧马上就到，拿最新的数据比补旧数据更重要。等重传旧数据反而会导致角色瞬移和射击判断混乱。
2.3 TCP vs UDP 场景选择
| 场景 | 选择 | 原因 |
|---|---|---|
| SSH 远程登录 | TCP | 敲的每一个字符都不能丢 |
| HTTP 网页浏览 | TCP | 网页内容必须完整 |
| 文件传输 | TCP | 文件损坏不可接受 |
| 视频通话 | UDP | 流畅优先，偶尔花帧可接受 |
| 直播推流 | UDP | 实时性优先，卡顿比模糊更致命 |
| DNS 查询 | UDP | 一次性请求，丢包重发即可 |
| 游戏实时同步 | UDP | 旧数据不值钱，新数据才重要 |
对完整性要求高的用 TCP（SSH、HTTP、MySQL），对实时性要求高的用 UDP（视频、游戏、DNS）。
2.4 套接字（Socket）
当数据通过网络传输时，IP 地址与服务端口的组合便形成了一个套接字。每个网络数据包都包含源套接字（用于识别发送方）和目的地套接字（用于标识接收方）。
例如，访问 http://10.0.0.142:80 时：
- 源套接字：
10.0.0.100:54321（客户端 IP + 随机端口）。 - 目标套接字：
10.0.0.142:80（服务器 IP + HTTP 端口）。
识别网络套接字信息对于有效监控和过滤流量至关重要。
2.5 常见端口速查
| 端口 | 服务 | 传输层 | 说明 |
|---|---|---|---|
| 22 | SSH | TCP | 远程登录 |
| 53 | DNS | UDP（解析）/ TCP（主从同步） | 域名解析 |
| 80 | HTTP | TCP | 网页访问 |
| 443 | HTTPS | TCP | 加密网页 |
| 3306 | MySQL | TCP | 数据库 |
| 6379 | Redis | TCP | 缓存 |
| 8080 | Tomcat | TCP | Java 应用 |
端口分类：
| 分类 | 范围 | 说明 |
|---|---|---|
| 知名端口 | 0–1023 | 系统保留，需 root 权限 |
| 注册端口 | 1024–49151 | 应用程序使用 |
| 动态端口 | 49152–65535 | 客户端临时使用 |
三、TCP 三次握手与四次挥手
3.1 为什么需要三次握手？
泽冰要给小雅打电话，不能直接说话就开始聊——他需要确认：
- 小雅的号码是有效的。
- 小雅确实在电话旁能接听。
TCP 三次握手同样是为了确认通信双方都准备好了，同时完成序列号同步和窗口协商。
3.2 TCP 连接管理（三次握手与四次挥手）
精简版流程（无状态）：
完整版流程（带状态）：
面试精简版：
- 三次握手：SYN → SYN-ACK → ACK。
- 四次挥手：FIN → ACK → FIN → ACK。
为什么要等 2 倍 MSL？
主动关闭方（客户端）发送最后一个 ACK 后进入 TIME_WAIT 状态，等待 2 倍 MSL（Maximum Segment Lifetime，最大报文生存时间），通常为 2–4 分钟：
- 防止最后的 ACK 丢失：如果服务器没收到最后的 ACK，会重发 FIN，客户端在 TIME_WAIT 期间还能响应重传的 FIN。
- 让旧报文在网络中消失：确保这个连接的所有旧报文都已从网络中消失，不会干扰后续使用相同端口的新连接。
3.3 连接状态速记
运维中经常用 ss 命令查看连接状态，常见状态如下：
| 状态 | 含义 | 常见原因 |
|---|---|---|
| LISTEN | 服务正在监听 | 正常（服务已启动，等待连接） |
| ESTABLISHED | 连接已建立 | 正常（正在通信） |
| TIME_WAIT | 连接关闭等待 | 高并发场景常见，主动关闭方出现 |
| CLOSE_WAIT | 对方已关闭，本机未关闭 | 应用未及时关闭连接（需关注） |
| SYN_SENT | 客户端已发 SYN，等待回复 | 网络不通或服务端未响应 |
| LAST_ACK | 等待最后一个 ACK 确认 | 四次挥手最后阶段 |
关注重点：
- 大量 TIME_WAIT：正常，高并发服务的特征。
- 大量 CLOSE_WAIT：程序 bug，应用没有正确调用 close() 关闭 socket。
四、网络层：IP 地址、子网掩码与网关
详细概念见 Day 7-1，本节回顾核心要点。
4.1 三个核心概念
| 概念 | 作用 |
|---|---|
| IP 地址 | 标识主机 |
| 子网掩码 | 划分网段 |
| 网关 | 跨网段出口 |
4.2 通信规则
核心规则：同一子网直接通信，跨子网需经过网关。
五、常见网络设备
| 设备 | 工作层级 | OSI 层 | 作用 | 类比 |
|---|---|---|---|---|
| 交换机 | 链路层 | 二层 | 同一子网内转发数据（基于 MAC 地址） | 同大厦物业，按门牌号分发 |
| 路由器 | 网络层 | 三层 | 跨子网转发数据（基于 IP 地址） | 片区快递小哥，所有跨网包裹必经之地 |
| 网关 | 网络层 | 三层 | 子网的唯一出口 | 跨城转运 |
| 防火墙 | 传输层+ | 四层+ | 控制数据包进出 | 门卫，检查包裹是否允许进出 |
六、本章小结
6.1 核心知识点速记
四层模型口诀：
- 应用层：业务数据上面跑。
- 传输层：端口连接中间找。
- 网络层：IP 路由来寻址。
- 链路层：MAC 地址最底层。
PDU 名称口诀：
应用叫数据（Data），传输分段（Segment），网络叫包（Packet），链路叫帧（Frame）。
TCP vs UDP 口诀：
- TCP：面向连接打电话，可靠传输要确认。
- UDP：无连接广播喊出去，快速高效不保证。
三次握手：敲门 → 开门 → 进屋。
四次挥手：我要挂了 → 好的 → 我也挂了 → 好的，挂了吧。
OSI vs TCP/IP：
- 七层分得细，四层用得多。
- 四层传端口，七层看协议。
6.2 常用命令速查
| 操作 | 命令 |
|---|---|
| 查看 IP 地址 | ip a 或 ip addr show |
| 查看路由表 | ip route show |
| 查看 ARP 缓存 | ip neigh show |
| 查看监听端口 | ss -tlnp |
| 查看已建立连接 | ss -tan state established |
| 查看连接统计 | ss -s |
6.3 学完本节应能独立完成
- 理解 TCP/IP 四层模型及各层职责。
- 区分 TCP 和 UDP 的差异及适用场景。
- 理解三次握手的必要性。
- 理解 IP 地址、子网掩码、网关的作用。
- 熟记常见服务端口号。
- 理解运维中“四层”和“七层”术语的含义。
下一节预告
Day 7-4：网络诊断工具。
我们已经理解了网络分层模型，下一节我们将学习具体的诊断工具——ip、ss、tcpdump、curl、ping、traceroute、mtr——把理论变成实战工具。
评论