古法网络入门

在前端篇第 10 讲里，申请表单已经能用 fetch 把申请发给服务器，并收到受理编号。从页面这边看，只有一行。但这一行下面，查名字、找对方设备、建立连接、把数据分成小块运送，好几项工作同时在动。本系列就按层来看这些工作。

• 掌握全景 ── OSI 参考模型的七层，和实际在运行的 TCP/IP 四层。每一层有什么设备、什么协议
• 从下往上潜 ── 从第 2 讲的物理层（网线、电波），到第 10 讲的 HTTP
• 在手边用起来 ── 第 11 讲是 Docker 和云上的网络，第 12 讲是“连不上”时的排查
• 每讲都实际测量 ── 在练习用网络里记录真实的数据包，用这些数字来讲解

一句话说，网络就是把计算机连起来、把数据送到的机制。从新井的电脑到服务器的路线，粗略画出来是这样的。

家里或公司里的网络叫局域网（LAN，Local Area Network）。局域网的出口有路由器，再往外是运营商（ISP）的网络，再连到别的网络……这张由网络组成的网络就是互联网。服务器也待在数据中心的局域网里。

途中的设备不会把数据一口气整个送过去，而是分成叫数据包（packet）的小包裹，一台传给下一台。它不像电话那样和对方之间占住一条专线，而是像邮寄那样，每个包裹写上地址，走空着的路。一条线可以让许多通信共用，没有浪费。

为了让发送方和接收方用同样的方式解读，人们约定了数据的格式和步骤，这就是协议（protocol）。HTTP、TCP、IP、Ethernet，都是协议的名字。

送达之前要做的事情很多，所以网络把工作分成层来考虑。想想寄信的时候。

信纸上写什么，是写信人的事。信封上的“财务部 收”决定在楼里交给谁。地址决定送到哪栋楼。卡车只看地址，把信运到下一个邮局，不读信的内容。道路也不知道卡车装着什么。

网络也一样，每一层各有分工。这样做有三个好处。

• 可以替换 ── 有线换成 Wi-Fi，HTTP 的写法也不变。下层换掉，上层照常运行
• 只想自己这一层 ── 写 fetch 的时候，没人会去操心网线的电压
• 能缩小故障范围 ── “域名查到了，但连不上”，那就查域名那一层以下（第 12 讲）

分层方法里最有名的一把“尺子”，是 OSI 参考模型。国际标准化组织（ISO）从 1977 年开始制定，1984 年以 ISO 7498 发布。它把通信的工作分成七层。

发送时从上层往下层传，接收时从下往上传。每一层都有主要的设备和协议。整理成一张表是这样的（详细内容见各讲）。

数据的叫法也按层不同。第 4 层叫段（segment），第 3 层叫包（packet），第 2 层叫帧（frame），第 1 层叫比特（bit）。平时常常统称“数据包”，但讨论分层时分开叫，就不会混乱。

不过，现在互联网上实际在运行的不是 OSI 的协议，而是 TCP/IP。TCP/IP 由 Vint Cerf 和 Bob Kahn 在 1974 年的论文中提出雏形，1983 年 1 月 1 日，当时的 ARPANET 统一切换到了 TCP/IP。1980 年代末到 1990 年代初，人们曾为 OSI 和 TCP/IP 谁会普及而争论不休（被称为“协议战争”，Protocol Wars），最后普及的是 TCP/IP。

TCP/IP 的思路在 1989 年的 RFC 1122 中整理成了四层。和 OSI 这把尺子并排放，是这样的。

主要的区别有两个。第一，相当于 OSI 第 5、6 层的工作，在 TCP/IP 里合并在应用层。加密用的 TLS、字符编码，都是应用和程序库的事。第二，OSI 的第 1、2 层在 TCP/IP 里合并成一个链路层。

尽管如此，OSI 的层号仍是现场每天都在用的词。“二层交换机”“三层交换机”“四层负载均衡”“在七层分流”里的数字，都是 OSI 的层号。本系列也按内容讲 TCP/IP，编号用 OSI 的方式来进行。

地图有了，来看实物。我在云端的 Linux 上，用叫网络命名空间（network namespace）的机制，搭了一个三台机器的小网络（做法在第 11 讲详细讲）。

服务器的名字定为 api.keihi.example（.example 是为举例说明而保留的名字）。在电脑一侧和服务器一侧都开着 tcpdump 记录，然后发送一次申请。这里用 curl 代替浏览器，发送的内容也比第 10 讲的表单小，只是一个 JSON。

# 在新井的电脑（10.0.1.10）上，用 curl 重现和申请相同的发送
$ curl -X POST -H 'Content-Type: application/json' \
    --data-binary '{"title":"ニューヨーク出張","total":46851}' \
    http://api.keihi.example:3000/api/expenses
{"id":"EXP-2026-0012","status":"submitted"}
# 收到了受理编号（HTTP 状态是 201 Created）

受理编号 EXP-2026-0012 回来了。这时在新井的电脑上流过的数据包，一共 14 个。

# 在新井的电脑上记录的一次申请的全部内容（编号、经过时间、发送方、接收方、种类、字节数、内容）
# ① ARP：向所有人询问路由器（10.0.1.1）的 MAC 地址
 1   0.000ms  02:00:00:00:01:10 -> broadcast         ARP   42  Who has 10.0.1.1? Tell 10.0.1.10
 2   0.012ms  02:00:00:00:01:01 -> 02:00:00:00:01:10 ARP   42  10.0.1.1 is at 02:00:00:00:01:01
# ② DNS：向路由器的 DNS 询问 api.keihi.example 的 IP 地址
 3   0.014ms  10.0.1.10         -> 10.0.1.1          DNS   77  query A api.keihi.example
 4   0.350ms  10.0.1.1          -> 10.0.1.10         DNS   93  response A api.keihi.example A 10.0.2.20
# ③ TCP：与服务器的 3000 端口建立连接（三次往来）
 5   0.680ms  10.0.1.10         -> 10.0.2.20         TCP   74  49914 -> 3000 [SYN] Seq=0
 6   0.808ms  10.0.2.20         -> 10.0.1.10         TCP   74  3000 -> 49914 [SYN, ACK] Seq=0 Ack=1
 7   0.818ms  10.0.1.10         -> 10.0.2.20         TCP   66  49914 -> 3000 [ACK] Seq=1 Ack=1
# ④ HTTP：发送申请，收到受理编号
 8   0.891ms  10.0.1.10         -> 10.0.2.20         HTTP 266  POST /api/expenses HTTP/1.1 + JSON
 9   0.898ms  10.0.2.20         -> 10.0.1.10         TCP   66  3000 -> 49914 [ACK] Seq=1 Ack=201
10   7.011ms  10.0.2.20         -> 10.0.1.10         HTTP 269  HTTP/1.1 201 Created + JSON
11   7.033ms  10.0.1.10         -> 10.0.2.20         TCP   66  49914 -> 3000 [ACK] Seq=201 Ack=204
# ⑤ TCP：关闭连接
12   7.206ms  10.0.1.10         -> 10.0.2.20         TCP   66  49914 -> 3000 [FIN, ACK] Seq=201 Ack=204
13   8.472ms  10.0.2.20         -> 10.0.1.10         TCP   66  3000 -> 49914 [FIN, ACK] Seq=204 Ack=202
14   8.479ms  10.0.1.10         -> 10.0.2.20         TCP   66  49914 -> 3000 [ACK] Seq=202 Ack=205

在发出申请（第 8 个）之前，已经来回了 7 个。先向所有人询问路由器的 MAC 地址（ARP），再用服务器的名字查 IP 地址（DNS），然后和服务器建立连接（TCP 的三次往来），这才是正题 POST。收到受理编号后，关闭连接。每一项都是本系列某一讲的主角。

第 8 个数据包（申请本身）是 266 字节。在 Wireshark 里逐层选中，该层负责的字节就会变蓝。

从开头起，依次是 Ethernet、IP、TCP 的标头（头部，header），后面接着 HTTP 的文字和 JSON 正文。按层分开写出来是这样的。

# ① Ethernet II（14 字节）
#   目的 MAC 02:00:00:00:01:01（路由器）、源 MAC、类型 08 00（里面是 IPv4）
02 00 00 00 01 01 02 00 00 00 01 10 08 00
# ② IPv4（20 字节）
#   第 9 字节 40＝TTL 64，第 10 字节 06＝里面是 TCP，
#   0a 00 01 0a＝源 10.0.1.10，0a 00 02 14＝目的 10.0.2.20
45 00 00 fc 1b f8 40 00 40 06
06 e7 0a 00 01 0a 0a 00 02 14
# ③ TCP（32 字节）
#   c2 fa＝源端口 49914，0b b8＝目的端口 3000，
#   后面是序号、确认号、标志等
c2 fa 0b b8 83 5b 4e 23 ab f5 ef c6 80 18 00 3f
18 0c 00 00 01 01 08 0a b7 e2 b8 5b 9f a1 af c2
# ④ HTTP（150 字节）
#   从这里开始是文字。行尾是 0d 0a（\r\n），空行表示头部结束
POST /api/expenses HTTP/1.1
Host: api.keihi.example:3000
User-Agent: curl/8.5.0
Accept: */*
Content-Type: application/json
Content-Length: 50

# ⑤ JSON（50 字节）
#   申请的内容。日文用 UTF-8，每个字 3 字节
{"title":"ニューヨーク出張","total":46851}

发送一方从上层开始，每层把自己的头部加在前面再交给下层。HTTP 做出的 200 字节，TCP 加上 32 字节的头部成为 232 字节，IP 再加 20 字节成为 252 字节，Ethernet 加 14 字节成为 266 字节。这叫封装。接收一方正好相反，从下层开始读取并剥掉头部，把内容往上交。

每一层都只读自己的头部。IP 不读 TCP 的头部，TCP 不读 HTTP 的文字。所以各层才能替换。

另外，Wireshark 里看到的 266 字节，不包括在网线上前后附加的部分（8 字节的同步信号，以及检查是否损坏的 4 字节）。这些留到第 2、3 讲再看。

同一次申请的数据包，我在路由器之前（新井的电脑一侧）和之后（服务器一侧）两处都做了记录。并排看看。

MAC 地址前后两个整个换掉了。电脑一侧是“从电脑到路由器”，服务器一侧是“从路由器到服务器”。因为 MAC 地址是到相邻设备的地址。而 IP 地址从头到尾都不变，它是最终的目的地。用邮寄来比喻，就像卡车在每个邮局换乘，信封上的地址却不改写。

TTL 是每经过一台路由器就减 1 的数。变成 0 的数据包会被丢弃，所以迷路的数据包不会永远转下去（第 5 讲的 traceroute 就利用了这个机制）。因为 TTL 变了，IP 头部的校验用数字（校验和）也重新计算了。

不同设备拆开信封的深度不同。交换机看到第 2 层的 MAC 地址，决定从哪个口送出去。路由器看到第 3 层的 IP 地址，决定下一站交给谁，然后换上新的第 2 层再送出去。读 TCP 和 HTTP 的，只有两端的电脑和服务器（也有像防火墙、负载均衡那样，特意往上层看的设备）。

本系列每一讲都用这样的工具来确认。都能在平时的电脑上马上用。

Wireshark 免费，Windows、Mac、Linux 都能用（写作时的最新版是 2026 年 9 月 23 日的 4.6.9，本文的截图是 Ubuntu 的 4.2.2）。打开这次的记录文件，逐层选中，应该能看到和第七章照片一样的样子。