为什么要分层

基于 HTTP 现代标准 · 核于 2026-06

速查

• 核心思想：把「让两台机器通信」这个极复杂的大问题，纵向切成若干职责单一的层，每层只解决一类小问题，层与层之间约定好接口，从而分而治之。
• 复杂在哪：通信要同时操心「电信号怎么传、丢包怎么办、跨网络怎么找路、数据怎么编码、应用要什么语义」——一锅烩进单个程序，没人写得对也没人维护得动。
• 分层四大好处：模块化（每层独立实现）、解耦（改一层不动其他层）、标准化与互操作（同层认同一套协议，不同厂商设备能互通）、可独立演进/替换（Wi-Fi 换 5G、HTTP/1.1 换 HTTP/3，上层无感）。
• 协议（protocol）：MDN 定义——「一套规定数据如何交换的规则」；通信双方必须先就数据格式达成一致，这套格式约定就是协议。
• 协议栈（protocol stack）：把各层协议自上而下叠在一起协同工作的整体，如经典的 TCP/IP 协议栈（也叫 Internet 协议族）。
• 服务（service）：下层向上层提供能力——上层只管「用」，不管下层「怎么做到」（如传输层向应用层提供「可靠字节流」，应用层不必关心丢包重传）。
• 接口（interface）：相邻两层之间的纵向调用边界，规定上层如何请求下层的服务。
• 协议（peer protocol）：对等层之间的横向通信约定——我方第 N 层与对方第 N 层「逻辑上直接对话」，遵循同一协议。
• 服务 vs 协议：服务是上下层之间纵向的（「下层能为我做什么」），协议是对等层之间横向的（「同层双方按什么规矩说话」）——两者正交，别混。
• 分层的代价：①少量冗余/开销（每层都要加自己的头部，详见「封装」叶）；②跨层信息隐藏（上层看不到下层细节，便于解耦，但极致性能优化时偶尔需「打破分层」）。
• 两套主流模型：OSI 七层（理论参考、教学/排障通用语言）与 TCP/IP 四层（工程实际、现代互联网真正在跑的）——下一页起逐一拆解。
• 要点：分层是理解、设计、排障网络的「通用语言」；现实互联网更贴近 TCP/IP，但 OSI 的分层框架仍是绕不开的思维脚手架。

网络通信到底有多复杂

设想最朴素的目标：你的浏览器要把一条 HTTP 请求送到地球另一端的服务器。听起来一句话，可一旦真要落地，要同时操心的事多到离谱：

• 物理层面：数据最终是电信号、光脉冲或无线电波，0 和 1 怎么在铜缆/光纤/Wi-Fi 上传输？收发双方怎么约定「多高的电平算 1」？
• 链路层面：同一个局域网里有很多设备，数据帧发出去，怎么标明发给谁？多个设备同时发，冲突了怎么办？
• 网络层面：对方不在同一个网络，隔着十几个路由器，怎么找到一条到达对方网络的路（路由）？数据怎么寻址？
• 传输层面：网络是「尽力而为」的，会丢包、乱序、重复。怎么保证字节完整、有序地交付？发得太快把对方压垮了怎么流控？
• 应用层面：到了对方机器，交给哪个程序？双方怎么约定「我要 GET 这个资源、你返回这段 HTML」这类业务语义？

如果把这五类问题一股脑塞进一个程序去解决，结果是灾难：代码极度耦合，改一个传输细节可能牵动整套逻辑；换一种物理介质（铜缆换光纤）就得重写一切；不同厂商各写各的，互相之间根本无法通信。

不分层 = 不可维护、不可互通

通信的复杂度不在「某一件事多难」，而在「太多本质不同的事必须同时做对」。把它们混在一起，既写不对、也无法让全世界异构的设备遵循同一套规则协作——这正是分层思想要破解的根本困境。

分层思想：把大问题切成职责单一的层

分层（layering）的本质是一种**「分而治之」的架构方法**：

把「网络通信」这一个庞大问题，纵向切成若干层，每一层只负责一类单一职责的小问题，并向相邻层约定清晰的边界。

于是上面那五类问题被自然地分派下去：物理传输归一层、同网寻址归一层、跨网路由归一层、可靠交付归一层、应用语义归一层。每层只盯着自己那摊事，做到两个关键性质：

• 职责单一：一层只解决一个层面的问题（如「网络层只管跨网络找路」），不越界。
• 各层独立：每层把自己的实现封装在内部，对外只暴露「我能提供什么服务」，不暴露「我怎么做到的」。上层用下层的服务时，完全不需要知道下层的内部机制。

打个比方——寄一封跨国信件：你（应用层）只管写好信、写上地址投进邮筒；邮局分拣、运输、海关、对方国家的派送……层层分工，你既不需要懂航空货运怎么调度，也不需要懂卡车怎么走国道。每一环只对上一环负责、对下一环提要求，整条链路就能跑通。

分层的两个朴素直觉

1. 横看：同一层的双方（你的邮局 ↔ 对方的邮局）「说同一种行话」——这就是协议。
2. 竖看：相邻层之间「你帮我把这步做了」——这就是服务。 后面会把这两个方向讲透。

分层带来了什么好处

分层不是为了好看，而是实打实地解决了「复杂 + 异构 + 长期演进」三重难题。它的收益可以归为四点：

模块化：每层独立实现

每层是一个自包含的模块，内部怎么实现是它自己的事。写传输层逻辑的人，不必同时是无线电专家；写应用协议的人，不必懂路由算法。关注点分离让每层都能被独立地设计、编码、测试。

解耦：改一层不动其他层

因为层间只通过约定好的接口交互，只要接口不变，某一层内部怎么改都不影响别人。这是分层最实用的工程价值：

• 把局域网从 Wi-Fi 6 升级到 Wi-Fi 7（链路/物理层变了），你的浏览器和 HTTP（应用层）完全无感。
• 传输层从 TCP 切到基于 UDP 的 QUIC（HTTP/3 正是如此），应用层语义照旧。

标准化与互操作

每一层都对应公开的标准协议，全世界的设备只要在同一层实现同一套协议，就能互相通信——这正是 OSI 模型的初衷：让「不同的计算机系统能用标准协议彼此通信」，被形容为「计算机网络的通用语言」。

于是思科的路由器能和华为的路由器对话、Chrome 能访问 Nginx 服务器、iPhone 能连任意品牌的 Wi-Fi——背后都是同层认同一套协议在起作用。互操作性（interoperability）让异构设备组成了统一的互联网。

各层可独立演进与替换

技术是分层进步的。把通信切成层之后，某一层可以单独升级换代，而不必推倒重来：

演进	变化的层	上层是否受影响
铜缆 → 光纤 → 5G	物理层	否
IPv4 → IPv6	网络层	几乎无感（应用按域名访问）
TCP → QUIC（HTTP/3）	传输层	应用语义不变
HTTP/1.1 → HTTP/2 → HTTP/3	应用层	下层照常承载

正因如此，互联网才能在底层介质、寻址方式、传输机制、应用协议各自独立换代的同时，整体持续平滑运行几十年。

协议与协议栈

什么是协议

按 MDN 的权威定义：

协议（protocol）是一套规定数据如何在计算机内部或计算机之间交换的规则。 设备间通信要求双方就所交换数据的格式达成一致，这套定义格式的规则就叫协议。

换句话说，协议规定了三件事：数据长什么格式、按什么规则收发、双方必须遵循同一套约定。任何一方不守约，通信就会鸡同鸭讲。我们熟悉的 HTTP、TCP、IP、UDP、DNS、TLS 等都是协议，各自工作在不同的层。

什么是协议栈

单个协议只解决一层的问题。把各层的协议自上而下叠放、协同工作，就构成了协议栈（protocol stack）。最典型的就是 TCP/IP 协议栈（也叫 Internet 协议族）：应用层的 HTTP、传输层的 TCP、网络层的 IP……层层配合，共同完成一次完整通信。

┌─────────────────────────┐
│  应用层    HTTP / DNS / … │  ← 业务语义
├─────────────────────────┤
│  传输层    TCP / UDP      │  ← 端到端可靠交付
├─────────────────────────┤
│  网络层    IP / ICMP      │  ← 跨网络寻址与路由
├─────────────────────────┤
│  链路/物理  以太网 / Wi-Fi │  ← 比特在介质上传输
└─────────────────────────┘
        这一整摞 = 协议栈

「模型」与「协议栈」别混

OSI / TCP-IP 是分层「模型」（一种抽象划分），而 TCP/IP 协议栈是这个模型上「真实跑着的一组具体协议」。模型是骨架，协议栈是填进骨架的血肉。

层与层之间：服务与接口、对等层与协议

分层模型里有一组容易混淆但极其关键的概念。把它们分清，整套模型才真正「立」起来。

服务：下层为上层提供能力

下层向紧邻的上层提供「服务（service）」：上层只需「调用」这个服务、享用其结果，完全不必关心下层是怎么实现的。

• 例：传输层向应用层提供「可靠字节流」服务。HTTP（应用层）只管把请求交给 TCP（传输层），TCP 负责切片、确认、重传、排序——HTTP 从不操心丢包，它得到的就是一条「不丢不乱」的字节流。
• 这正是信息隐藏的体现：下层把复杂性封装在内部，对上层只暴露「我能给你什么」。

接口：相邻层之间的调用边界

上层要用下层的服务，得通过两层之间约定的接口（interface）——它规定了「上层该如何向下层发起请求、下层如何把结果交回」。接口是纵向的（上下相邻层之间）。只要接口稳定，下层内部随便重构，上层都不受影响——这就是「解耦」在机制上的落点。

对等层与协议：同层双方的横向对话

而协议（protocol）是横向的：它约定的是通信双方「对等层（peer layer）」之间怎么对话。我方第 N 层与对方第 N 层，在逻辑上仿佛在直接交谈，遵循的就是该层的协议——尽管数据物理上其实是一路向下穿到物理层、传过去、再一路向上交付的（这条路径见「封装与解封装」叶）。

一句话记牢：服务竖着走，协议横着走

• 服务 / 接口：纵向，问的是「下层能为我（上层）做什么、我怎么调它」。
• 协议：横向，问的是「我和对方的同一层，按什么规矩说话」。 两者互相正交，是分层模型的两条独立主线——千万别把「服务」和「协议」当成一回事。

分层的代价

分层不是免费午餐，它换来了清晰与灵活，也付出了两类代价——但在绝大多数场景下，这点代价远小于收益：

• 少量冗余与开销：每经过一层，通常都要给数据添上本层的头部（header）（如 TCP 头、IP 头）。这些控制信息层层累加，带来一定的字节与处理开销。这正是下游「数据封装」要展开的内容（本页不深入，详见对应叶）。
• 跨层信息隐藏：分层刻意让上层「看不见」下层细节——这换来了解耦，但也意味着上层难以利用下层的内部信息做精细优化。在追求极致性能的特殊场景，工程上偶尔会「打破分层」（cross-layer design）拿到下层信息来调优，本质是在「干净分层」与「性能」之间做权衡。

代价是「设计上的取舍」，不是「缺陷」

头部冗余、信息隐藏都是分层为换取模块化、可演进、可互通而主动做出的取舍。理解了它，才不会误以为「分层有害」——它只是有边界、有成本的工程权衡。

引出两套分层模型

明白了「为什么分层」和「分层怎么运作」之后，自然要问：到底该切成几层、每层叫什么、各管什么？ 历史上给出了两套主流答案：

• OSI 七层模型：由 ISO（国际标准化组织）提出的概念参考模型，把通信切成 7 层。它理论完整、概念清晰，是教学与网络排障的「通用语言」——出了问题先定位到「是第几层的事」，能省掉大量盲目排查。但现实互联网并不严格照它实现。
• TCP/IP 四层模型：现代互联网真正在运行的模型（更贴近实际的 Internet 协议族），层数更少、更务实。

两者各有侧重、并不互相否定：OSI 适合用来「讲清楚原理」，TCP/IP 适合用来「描述真实在跑的东西」。接下来的几页会逐一拆解它们的每一层、对照异同，并跟一个真实 HTTP 请求走完整条协议栈。

小结

• 网络通信的复杂在于「太多本质不同的事必须同时做对」，分层用「分而治之」把它切成职责单一、各自独立的层来破解。
• 分层带来模块化、解耦、标准化与互操作、各层可独立演进/替换四大好处，是互联网得以异构互通、长期平滑演进的根基。
• 协议是「数据交换的规则」，各层协议自上而下叠成协议栈（如 TCP/IP 协议栈）。
• 记牢两条正交主线：服务/接口是纵向的（下层为上层提供能力、上层据接口调用），协议是横向的（对等层之间按同一套规矩对话）。
• 分层的代价是少量头部冗余与跨层信息隐藏，属主动的工程取舍而非缺陷。
• 落地成两套模型：OSI 七层（理论/排障通用语言）与 TCP/IP 四层（现代互联网实跑）。

下一页起，我们逐层拆解第一套答案：OSI 七层逐层职责。