在实际工作中产品经理给你的 SaaS 后台提了一个需求:加一个在线客服。客户在网页右下角的聊天框里提问,客服在管理后台里回复;客服后台的右上角有个小铃铛,来了新工单就亮一个红点,这个需求你会怎么处理呢,需要用到哪些网络知识呢。

在实际工作中，一台服务器的处理能力总有上限。业务长大之后,唯一的出路是加机器——但加了机器,立刻冒出一个新问题? 用户的请求,该发给哪一台?

前面几篇我们一直在讲"怎么把一堆字节可靠地送到对面"。TCP 把这件事做完了,但它送过去的只是一串没有含义的字节流，至于这些字节怎么表示,TCP 完全不关心。

在网络中发送消息又一个前提:需要知道对方的 IP 地址。TCP 要 IP 才能握手,TLS 要 IP 才能连接。

可你在浏览器里敲的是 github.com,在代码里写的是 https://eth-mainnet.g.alchemy.com——这些名字对网络层毫无意义,IP 包的头部里只有 140.82.121.4 这样的数字。

前面几篇,我们看着 TCP 一层层往上搭:序号、确认、重传、排序、去重、流量控制、拥塞控制。每一样都是为了同一个目标——让应用拿到一段完美的字节流。

上一篇讲清了 TCP 怎么保证"不丢不乱",但留了个关键的空:发送方一次能往外扔多少数据?

这个数字定小了,带宽白白浪费;定大了,轻则把接收方撑爆,重则把整个网络堵死。而且它还不能是个固定值——网络状况和对方的处理能力时时刻刻都在变。

物理世界里并没有一根线真的从你连到服务器,数据包依然是一个个独立地在互联网上乱窜、走不同的路线。所谓"连接",纯粹是通信双方各自在内存里记的一本账。

首先我们看一次完整的网络请求(经典面试题):

1. DNS 解析(应用层):浏览器要访问 example.com,先问 DNS:“它的 IP 是多少?” DNS 返回如 93.184.216.34。(DNS 查询本身通常走 UDP。)
2. 建立 TCP 连接(传输层):浏览器和服务器的 443 端口做 TCP 三次握手,建立可靠连接。
3. TLS 握手(应用层/安全):HTTPS 还要再做 TLS 握手,协商加密密钥(后面 TLS 篇细讲)。
4. 发送 HTTP 请求(应用层):浏览器构造 HTTP 请求报文,交给 TCP。
5. 一路封装下行:HTTP 报文 → 加 TCP 头 → 加 IP 头 → 加以太网帧头 → 变比特流,从网卡发出。
6. 跨互联网路由(网络层):数据包经过家里的路由器、运营商、一个个骨干路由器接力转发,每一跳链路层的 MAC 地址都在变(下一跳变了),但 IP 头里的最终目标 IP 始终不变——这是网络层和链路层分工的绝佳体现。
7. 服务器解封装上行:服务器网卡收到比特流 → 链路层拆帧 → 网络层确认目标 IP 是自己 → 传输层按端口 443 交给 web 服务 → 应用层拿到 HTTP 请求。
8. 响应原路返回,浏览器渲染页面。

当我们在浏览器敲一个网址、Web 服务收到一个请求、区块链节点之间同步一个区块——这些看起来完全不同的事,底层走的是同一套分层协议。理解"数据是怎么一层层被包起来、发出去、再一层层拆开"的,是理解一切网络问题(为什么慢、为什么断、为什么要握手)的前提。今天我们要理解的是网络分层。

说到网络，大家第一个想到的都是TCP、IP协议这些的，很容易忽略网络的硬件设施，我们这一篇主要讲网络的硬件基础设施。

一个前提:互联网是"分组交换"的

在讲设备之前,先建立一个总观念。这两种方式的差别,用包车 vs 拼车一比就清楚了。