WangQuan's Blog

Appearance

OSI 七层与 TCP/IP 四层：分层、职责与关系 ​

网络分层模型最重要的意义，不是让你背出“第几层叫什么”，而是先分清：

  1. 这一层到底在解决什么问题
  2. 它和上下层的边界在哪里
  3. 为什么真实工程里更常讲 TCP/IP，但学习时仍然会提 OSI

1. 为什么网络一定要分层 ​

一次网络通信至少会遇到这些问题：

  1. 应用数据怎么组织
  2. 两端进程怎么建立端到端传输
  3. 数据包怎么找到目标机器
  4. 底层链路怎么把数据真正送出去

如果一套协议同时解决全部问题，复杂度会非常高，而且任何一个局部修改都会牵一发动全身。

所以分层真正解决的是 让每层只处理自己最核心的一类问题，并通过稳定接口和上下层协作。

2. OSI 七层模型是什么 ​

OSI 是 Open Systems Interconnection，中文常叫“开放系统互联参考模型”。

它更偏一套理论上的标准分层方式。

七层通常是：

  1. 物理层
  2. 数据链路层
  3. 网络层
  4. 传输层
  5. 会话层
  6. 表示层
  7. 应用层

很多初学者第一次看会觉得层太多。

更稳的理解方式是，OSI 更像一张把网络职责拆得更细的分析地图。

3. TCP/IP 四层模型是什么 ​

真实互联网协议族更常按 TCP/IP 模型来理解。

常见写法会分成四层：

  1. 网络接口层
  2. 网络层
  3. 传输层
  4. 应用层

它不是说底层职责真的只有四层，而是把 OSI 里一些更细的层合并了。

所以工程上更常见的理解是：

OSITCP/IP
物理层 + 数据链路层网络接口层
网络层网络层
传输层传输层
会话层 + 表示层 + 应用层应用层

4. 每一层大致在做什么 ​

4.1 网络接口层 ​

它更偏“数据在本地链路上怎么发出去”。

例如：

  1. 以太网
  2. Wi-Fi
  3. MAC 地址
  4. 帧封装

它主要负责把数据交给当前链路去传，不负责跨多个网络做全局路由。

4.2 网络层 ​

它更偏“数据包怎么找到目标机器”。

这里的核心协议就是 IP。

它主要解决：

  1. 逻辑寻址
  2. 路由转发
  3. 跨网段通信

4.3 传输层 ​

它更偏“目标机器上的哪个进程来收，以及传输特性是什么”。

这里最常见的是：

  1. TCP
  2. UDP

它主要解决端到端通信问题。

4.4 应用层 ​

它更偏“业务语义怎么表达”。

例如：

  1. HTTP
  2. HTTPS
  3. DNS
  4. SMTP

它解决的是请求、响应、域名解析、邮件等更贴近业务和应用协议的问题。

5. OSI 和 TCP/IP 的关系到底怎么理解 ​

很多人会把它理解成“两个互相打架的体系”，这不准确。

实际写项目时，更多是这样：

  1. OSI 更像理论参考模型
  2. TCP/IP 更像真实互联网协议族的归纳方式

所以学习时经常同时讲这两个模型，是因为：

  1. OSI 更适合把职责分析清楚
  2. TCP/IP 更适合落到真实协议和工程实践

🌟 如果一定要压缩成一句话，OSI 更像理论坐标系，TCP/IP 更像真实世界正在跑的协议分层。

6. 这一层最重要的能力边界 ​

分层模型里最容易混的，不是名字，而是边界。

6.1 网络层和传输层不是一回事 ​

  • 网络层关心“包怎么找到目标机器”
  • 传输层关心“目标机器上的哪个端点来收，以及传输特性是什么”

6.2 传输层和应用层不是一回事 ​

  • 传输层关心“怎么送”
  • 应用层关心“送的内容按什么协议组织”

6.3 Socket 也不等于某一层协议 ​

Socket 更像程序对网络通信能力的编程入口，它会同时接触 IP 地址、端口、协议族等概念，但它本身不是分层模型中的某个协议层。

7. 一个请求大致会穿过哪些层 ​

以浏览器访问 https://example.com 为例，可以粗略理解成：

  1. 应用层：组织 HTTP 请求，同时可能涉及 DNS
  2. 传输层：通常使用 TCP
  3. 网络层：通过 IP 寻址和转发
  4. 网络接口层：通过以太网或 Wi-Fi 把数据帧发出去

所以所谓“访问网页”，本质上不是单个 HTTP 协议自己完成全部工作，而是多层协作的结果。

8. 一个网络请求从发起到收到响应，完整会经历什么 ​

如果只说“请求会经过七层”，还是太抽象。

更适合建立整体感的方式，是顺着一次真实访问把主线走一遍。

假设用户在浏览器地址栏输入：

text
https://example.com/api/users/1001

这次请求大致会经过下面这些步骤：

  1. 浏览器先解析 URL，识别出协议是 HTTPS、目标域名是 example.com、路径是 /api/users/1001
  2. 浏览器先尝试查缓存，这里的“本地”主要指浏览器缓存和操作系统缓存，看当前域名有没有还没过期的 DNS 结果
  3. 如果这些缓存都没有命中，才会继续向配置好的本地 DNS 服务器发起查询，把域名解析成目标 IP
  4. 浏览器拿到目标 IP 后，开始和目标服务建立 TCP 连接
  5. 如果是 HTTPS，还要在 TCP 之上继续完成 TLS 握手
  6. 握手完成后，浏览器才真正发送 HTTP 请求报文
  7. 请求报文会被分段、封装成 TCP 段、IP 包、链路层帧后发出去
  8. 中间路由设备根据目标 IP 把包一跳一跳转发到目标服务器
  9. 服务器网卡收到帧后，逐层向上拆包，最终交给对应端口上的服务进程
  10. 服务端应用处理业务逻辑，生成 HTTP 响应
  11. 响应再按相反方向逐层封装，回到客户端
  12. 浏览器收到响应后，先解密、再解析响应头和响应体，最后决定是否渲染页面、更新状态或继续发后续资源请求

这里第 2 步和第 3 步很容易混，最好单独区分一下：

  1. 浏览器缓存：浏览器自己记住之前解析过的域名结果
  2. 操作系统缓存：操作系统层面也可能暂存最近用过的 DNS 结果
  3. 本地 DNS 服务器：通常是路由器、运营商 DNS、公司内网 DNS 或公共 DNS，例如 8.8.8.8

也就是说，这里说“本地有 DNS 结果”，实际写项目时，更多是这样：

本地缓存里已经有可用的 DNS 解析结果。

而不是“本机自己就是一台 DNS 服务器”。

如果缓存命中，流程会更短一些：

  1. 浏览器解析 URL
  2. 浏览器或操作系统直接拿到缓存里的 IP
  3. 跳过远程 DNS 查询
  4. 直接进入 TCP 连接建立
  5. 如果是 HTTPS，继续做 TLS 握手
  6. 然后发送 HTTP 请求

如果缓存没有命中，流程才会变成：

  1. 浏览器解析 URL
  2. 浏览器和操作系统都没找到可用缓存
  3. 向本地 DNS 服务器发起查询
  4. 本地 DNS 再根据自己的缓存或继续向上游查询拿到结果
  5. 把 IP 返回给客户端
  6. 客户端再进入后续的 TCP、TLS、HTTP 流程

这条链路最重要的意义，不是背步骤，而是先建立一个稳定认识：

一个请求不是“浏览器发个 HTTP 就完了”，而是域名解析、可靠传输、安全握手、报文封装、路由转发、应用处理共同协作的结果。

9. 把这 12 步放回各层分别在做什么 ​

可以把上面的全过程重新映射回分层模型：

阶段更主要落在哪层
URL 解析、构造请求语义应用层
DNS 域名解析应用层
TCP 三次握手传输层
TLS 握手应用层和传输层之间的安全层
数据分段、确认、重传传输层
IP 寻址和路由转发网络层
以太网 / Wi-Fi 帧发送网络接口层
服务端逐层拆包并交给应用从网络接口层一路向上到应用层
业务处理并返回响应应用层

这里最值得记的一点是：

  1. DNS 不替你发业务请求
  2. TCP 不理解 /api/users/1001 是什么意思
  3. IP 不知道状态码是 200 还是 500
  4. HTTP 也不负责把包跨多跳网络送到目标机器

所以分层真正的价值，就是让每一层只负责自己这段问题。

10. 一张更完整的流程图 ​

mermaid
sequenceDiagram
    participant User as 用户
    participant Browser as 浏览器
    participant DNS as DNS 服务器
    participant Server as 服务端应用

    User->>Browser: 输入 https://example.com/api/users/1001
    Browser->>Browser: 解析 URL 与检查缓存
    Browser->>DNS: 查询 example.com 的 IP
    DNS-->>Browser: 返回目标 IP
    Browser->>Server: TCP 三次握手
    Server-->>Browser: TCP 连接建立
    Browser->>Server: TLS 握手
    Server-->>Browser: TLS 建立完成
    Browser->>Server: 发送 HTTP 请求
    Note over Browser,Server: 请求会经历分段、封装、IP 路由与链路层传输
    Server->>Server: 应用处理业务
    Server-->>Browser: 返回 HTTP 响应
    Note over Server,Browser: 响应同样会逐层封装并返回客户端
    Browser->>Browser: 解密、解析响应、渲染或更新页面

这张图的重点不是把中间每个包都画出来，而是帮助你建立“从用户输入到页面拿到结果”的主线顺序。

11. 为什么有时一个页面请求看起来只发了一次，实际却远不止一次 ​

因为浏览器拿到主 HTML 后，往往还会继续触发很多后续请求，例如：

  1. CSS
  2. JavaScript
  3. 图片
  4. 字体
  5. 接口请求

也就是说，你看到的“打开一个页面”，底层通常不是一次请求，而是一串相关请求的组合。

这也是为什么网络面板里经常会看到：

  1. 先拿 HTML
  2. 再拿静态资源
  3. 再发接口请求

所以“一个页面加载过程”比“一个 HTTP 请求”通常更复杂。

12. 常见误区 ​

12.1 以为 OSI 七层就是现实网络设备逐层对应 ​

不准确。

它更偏分析模型。

12.2 以为学网络就是背层名 ​

真正重要的是每层解决的问题和边界。

12.3 以为协议名出现在哪一层只是记忆题 ​

不是。

放在哪一层，决定了它到底负责什么、不负责什么。

13. 一句话总结 ​

分层模型这条主线，本质上是在解决 如何把一次网络通信拆成若干职责清晰的层，让应用语义、端到端传输、跨网络转发和底层链路传输分别由不同层来承担。

基于 VitePress 构建的个人技术笔记。

Copyright © 2026 WangQuan's Blog