# 06 互联网作为 IPC 基础设施

> 互联网不是一个新东西,它是"进程间通讯"在全球范围的展开。所有网站、App、API、CDN,本质上都是 IPC 的不同包装。

---

## 一、互联网的本质:全球进程 IPC 网络

> **互联网 = 海量进程通过标准协议(主要是 TCP/IP + HTTP)进行跨主机 IPC 的全球网络。**
>
> **网站 / App = 把"内容生产、存储、分发、消费"四个环节用进程 + 数据库 + 通讯协议组装起来的系统。**

四个环节对应的进程角色:

```
[生产者进程]              比如浏览器/App,上传内容
       ↓ HTTPS(跨主机 IPC)
[网关 / 接入层进程]       负责接收、鉴权、路由
       ↓ 内部 RPC(同数据中心 IPC)
[业务逻辑进程]            处理请求、决定怎么存、怎么发
       ↓
[存储层进程]              数据库 / 对象存储 / 缓存
       ↓
[分发层进程 / CDN]        把内容推到全球边缘节点
       ↓ HTTPS
[消费者进程]              别人的浏览器/App,下载消费
```

整个互联网就是这种结构在全球范围内复制了几亿份,每个网站、每个 App 都是这个模板的实例化。

---

## 二、关于"内容集中分发"这个直觉

直觉上,互联网像一个"内容集中和分发工具":
- 抖音用户上传 → 服务器存 → 别人下载看
- 新浪门户编辑发文 → 服务器存 → 用户访问
- Google 抓全网 → 建索引 → 用户搜索

这个直觉**抓住了大部分场景**,但需要修正三点。

### 修正 1:互联网不只是"内容分发",还有"实时双向通讯"

"上传 → 下载"是单向异步模型,但互联网还有大量双向实时场景:
- 即时通讯(微信、WhatsApp)
- 音视频通话(Zoom、FaceTime)
- 多人游戏(王者荣耀)
- 金融交易(股票下单)

更准确的说法:**互联网是"任意两台联网设备之间的通讯基础设施"**,内容分发是它最常见的应用之一,但不是全部。

### 修正 2:不是"集中",是"逻辑集中 + 物理分散"

抖音的视频实际存在**全球几十个数据中心 + CDN 节点**。你刷抖音时,视频从离你最近的 CDN 节点下载,不是从北京总部。

**CDN(Content Delivery Network,内容分发网络)** 是关键概念:把热门内容**预先复制到全球各地的边缘节点**,让用户就近获取。这是为了:
- 速度(物理距离 = 延迟)
- 成本(减少跨洲带宽)
- 可靠性(一个数据中心挂了别的还能用)

更准确的说法:**逻辑上集中(同一个抖音 App 看到统一内容),物理上分散(数据存多份、就近分发)**。

### 修正 3:数据库 ≠ 所有数据存储

数据库是基础设施没错,但只是存储的一种形式。互联网的存储基础设施实际包括:

| 存储类型 | 适合存什么 | 例子 |
|---|---|---|
| 关系数据库 | 结构化数据(用户表、订单表) | MySQL、PostgreSQL |
| NoSQL 数据库 | 半结构化、海量数据 | MongoDB、Redis、Cassandra |
| 对象存储 | 大文件(视频、图片、备份) | AWS S3、阿里 OSS |
| 文件系统 | 服务器本地文件 | ext4、NTFS |
| 分布式文件系统 | 跨机器超大文件 | HDFS、Google GFS |
| 搜索引擎 | 全文检索 | Elasticsearch |
| 缓存 | 热数据快速读取 | Redis、Memcached |

**抖音的视频不会存在 MySQL 里**——它存在对象存储(S3 类)。MySQL 存的是"视频元数据"(标题、上传时间、作者ID)。

---

## 三、网站类型:按内容来源分类

| 类型 | 内容生产者 | 例子 |
|---|---|---|
| UGC 平台(用户生成) | 用户 | 抖音、小红书、YouTube、Twitter |
| PGC 平台(专业生产) | 平台或签约方 | Netflix、新浪门户、爱奇艺自制剧 |
| 聚合 / 索引平台 | 别人,本平台只收集 | Google、百度 |
| 电商 / 交易平台 | 商家 | 淘宝、亚马逊 |
| 工具型 / SaaS | 用户(在云上工作) | Google Docs、Figma、Notion |

**Google 的特别之处**:看起来"只是给你结果",但它**自己存的内容比绝大多数网站都多**——索引了几千亿网页的副本。它的商业模式是"组织全世界信息",存储是手段,分发是产品。所以更准确的分类是"**它存的是别人内容的索引和副本,自己不生产内容**"。

---

## 四、Google 搜索的真实工作方式

容易误解的点:**用户搜索时,Google 不是实时去访问全球服务器**——那样会慢到无法使用。

真实流程是**两个完全独立、异步进行的阶段**:

### 阶段 A(后台,持续不断):爬取 + 建索引

- Googlebot 7×24 小时在全网爬网页,把内容存到 Google 自己的数据中心
- Google 把这些内容做成**索引**——类似一本书后面的"关键词→页码"索引
- 这个过程跟用户没关系,提前发生

### 阶段 B(用户搜索时,毫秒级):查索引

- 你输入"Python 教程"
- Google 不去访问任何外部服务器,而是查自己数据中心里建好的索引
- 找出最匹配的网页,返回给你
- 全程在 Google 内部系统里完成,所以才能 0.3 秒返回结果

### 完整三阶段图

```
阶段 A:爬取(Crawl)              ← 后台持续进行
   Googlebot 顺着链接爬网页 → 原始 HTML 存到 Google 数据中心
        │
阶段 B:索引(Index)               ← 后台持续进行
   提取关键词、计算页面质量(PageRank 等)
   建成"关键词→网页列表"的倒排索引
═══════════════════════════════════════════
阶段 C:搜索(Search / Serve)      ← 用户触发,毫秒级
   你输入"Python 教程"
   → 查询路由到最近的 Google 数据中心
   → 查倒排索引,找出候选网页
   → 排序算法(几百个信号)
   → 返回前 10 条
```

**关键认识**:你看到的搜索结果**全部来自 Google 自己的副本和索引**,不是实时去原网站抓的。这就是为什么有时候点进去发现页面不存在了——网页已经被删了,但 Google 的索引还没更新。

**类比**:Google 像一个超大的图书馆。爬虫是采购员(去全球买书运回来),索引是卡片目录,搜索是图书管理员查目录(不是跑出去找作者)。

---

## 五、API 的本质

调用 API 的目的是**让别人写好的一段代码帮你干活**。但要注意几个精确化:

### "API" 本身不是代码,是**契约**

- **API(Application Programming Interface)** = 接口契约,规定"你想让我干活,得按这个格式发请求,我会按这个格式回结果"。它是一份规范 / 约定,不是可执行代码。
- **API 实现** = 真正干活的代码
- **API 服务器 / 服务进程** = 跑这段代码的进程

类比:
- API ≈ 餐厅菜单(写明"宫保鸡丁 28 元,要等 15 分钟")
- API 实现 ≈ 后厨的菜谱和厨师手艺
- 服务进程 ≈ 厨师本人,真的在灶台前炒菜

### API 不一定涉及网络

按部署位置分:

| 类型 | 调用者 vs 实现者 | IPC 类型 | 例子 |
|---|---|---|---|
| 库函数 API | 同一个进程内 | 没有 IPC,直接函数调用 | Python 的 `open()` |
| 系统调用 API | 用户进程 → 内核 | 软中断陷入内核 | Linux 的 `read()` |
| 本地服务 API | 两个本地进程 | 同主机 IPC(socket) | Docker daemon |
| 远程 API | 跨网络两个进程 | 跨主机 IPC(HTTPS) | Google Drive API |

### 一次远程 API 调用的物理过程

```
[客户端进程]
   │ ① 把请求按 API 契约打包(序列化成 JSON)
   │ ② 通过 socket 发出 HTTP 请求(跨主机 IPC)
   ▼
[网络]
   │
   ▼
[API 服务器进程]
   ├─ 监听 443 端口(HTTPS)
   ├─ 收到请求,反序列化
   ├─ 调用真正干活的代码(可能再调数据库、其他服务)
   ├─ 把结果序列化成 JSON
   └─ 通过 socket 发回去
   │
   ▼
[客户端进程] 反序列化,拿到结果
```

### 与"模型工具调用"的关系

```
模型工具调用 ⊂ 远程 API 调用 ⊂ 进程间通讯
```

模型调用工具 = 模型(通过宿主代理)调 API。"工具"在物理上就是某个 API,工具 schema 就是 API 契约的简化版,MCP server 就是把 N 个 API 重新打包成"模型友好"格式的中间层。

### 关键洞察:边界画在哪决定了开销

**所有"调别人写的代码"的行为,本质都是 IPC 的不同形式**——只是边界画在哪里:

- 同一个进程内调函数 → 几乎零开销,但调用方和被调方必须用同一种语言、同一个内存空间
- 调系统库 → 跨"用户态/内核态"边界
- 调本地服务 → 跨进程边界,但同一台机器
- 调远程 API → 跨进程 + 跨机器边界

**边界画得越远,灵活性越高(可以用任何语言、任何机器),但开销越大(序列化、网络、容错都得考虑)**。这是软件架构里所有"分布式 vs 单体"权衡的本质。

---

## 六、HTTP 在应用层协议中的统治地位

### 占比数据(2025-2026)

- 按网站数量:约 97% 的网站默认走 HTTPS
- 按互联网流量:HTTP + HTTPS 在某些月份占应用层流量 90% 以上
- 按 Chrome 浏览:用户 93.2% 浏览时间在 HTTPS 页面
- 按加密占比:非加密的 HTTP 已被压缩到不到 3%

### 应用层协议生态全景

| 类别 | 协议 | 用途 | 流量占比 / 地位 |
|---|---|---|---|
| Web 浏览(主流) | HTTP / HTTPS | 网页、API、视频流、下载 | **80~90%**(绝对主导) |
| 下一代 Web | QUIC(HTTP/3 底层) | Web 流量,逐步替代 TCP+TLS+HTTP | 7~10%(增长中) |
| 域名解析 | DNS | 把 google.com 翻译成 IP | 2~3%(请求多但流量小) |
| 邮件 | SMTP / IMAP / POP3 | 收发邮件 | 1~2%(萎缩中) |
| 文件传输 | FTP / SFTP | 传文件 | <1%(已被 HTTPS 取代) |
| 远程登录 | SSH / Telnet | 远程操作服务器 | <1%(但极重要) |
| 即时通讯 | XMPP / MQTT / WebSocket | 聊天、IoT、实时推送 | <1% |
| 流媒体专用 | RTMP / RTP / WebRTC | 直播、音视频通话 | 少量但上升 |
| 企业内网 | SMB / NFS | 局域网共享文件 | 公网少 |

### HTTP 为什么能"垄断"

1. **无状态、文本化、易实现**——比早期二进制协议简单太多
2. **浏览器只支持有限协议**——HTTP 成了"穿透防火墙最稳的协议"(几乎所有公司都开 80/443 端口)
3. **REST API 风潮**——所有第三方服务的 API 默认就是 HTTP 上的 JSON
4. **HTTPS 成了安全默认**——浏览器警告 + Let's Encrypt 免费证书推动全网迁移
5. **HTTP/2、HTTP/3 把性能短板补齐**——以前 HTTP 慢的痛点都被新版本干掉了

结果:**今天几乎所有"应用与应用之间的通讯",默认都是 HTTP 上跑**。
- API 调用 → HTTP
- 看视频 → HTTPS
- WebSocket(聊天)→ 借 HTTP 升级握手
- 模型工具调用 → HTTPS
- MCP 远程模式 → HTTP + SSE
- gRPC → HTTP/2 上跑

---

## 七、HTTP 不是万能的:四类不适合的场景

技术上几乎所有应用都能强行跑在 HTTP 上,但有四类场景 HTTP **不是次优,而是架构上根本不匹配**。

### 1. 极端低延迟 / 高频小包(游戏、金融交易、音视频)

- 王者荣耀 → UDP + 自研协议
- Zoom / FaceTime → RTP / WebRTC 跑 UDP
- 高频交易 → 专用 TCP 或 UDP 协议

**为什么 HTTP 不行**:HTTP 跑在 TCP 上,TCP 是"可靠有序"的——丢一个包要重传,后面的包都要等。这对实时场景是灾难。HTTP 头几百字节,游戏一个状态包可能就几十字节,开销 10 倍以上。

### 2. 物联网 / 嵌入式 / 弱网环境

- MQTT(消息队列遥测传输):头 2 字节,适合传感器
- CoAP(受限应用协议):跑在 UDP 上的"HTTP 简化版",专为 IoT 设计

**为什么 HTTP 不行**:一个智能水表用电池跑 10 年,HTTP 每次开 TCP + TLS 握手就消耗几秒电量,根本撑不住。

### 3. 系统级、超高吞吐场景(数据库、文件系统、内核)

- 数据库通讯:MySQL、PostgreSQL、Redis 都用自己的二进制协议
- 分布式文件系统:HDFS、Ceph 用专用协议
- 进程间通讯:Unix socket、共享内存

**为什么 HTTP 不行**:开销太大、序列化太慢。Redis 处理 10 万 QPS,换成 HTTP+JSON 可能掉到 5000。

### 4. P2P / 无中心架构

- BitTorrent:用户互相传文件,没有中心服务器
- 比特币 / 以太坊:节点对等通讯,自定义二进制协议
- 局域网设备发现(mDNS、SSDP):广播,不是请求-响应

**为什么 HTTP 不行**:HTTP 天生是"客户端-服务器"结构,P2P 场景里没有"服务器"。

### HTTP 能力边界图

```
                      ┌─ 极低延迟 / 实时(游戏、音视频、HFT)
                      │
       HTTP 不擅长 →  ├─ 物联网 / 弱网 / 低功耗(MQTT、CoAP)
                      │
                      ├─ 系统级 / 高吞吐(数据库、内核 IPC)
                      │
                      └─ P2P / 无中心(BitTorrent、区块链)


                      ┌─ Web 浏览
                      │
                      ├─ REST API / RPC
                      │
       HTTP 擅长 →    ├─ 文件下载 / 上传
                      │
                      ├─ 视频点播(非实时)
                      │
                      └─ 模型工具调用 / MCP / SaaS
```

---

## 八、技术选型的普适规律

```
        通用 / 标准化
            ▲
            │
            │
    效率 ◀──┴──▶ 简单 / 易用
```

- HTTP 选了"通用 + 简单",牺牲了"极致效率"
- 专用协议(MQTT、游戏协议)选了"效率",牺牲了"通用"
- 没有银弹,看需求

**用这个框架可以解释很多设计选择**:
- 为什么 MCP 本地模式用 stdio 不用 HTTP → 同主机 IPC,HTTP 是给跨主机设计的,本地用 HTTP 是浪费
- 为什么模型推理框架内部用 gRPC 不用 REST → 高吞吐 + 强类型契约,REST 太松散
- 为什么音视频实时通话不用 HTTP → 实时性要求,HTTP 不行
- 为什么 IoT 用 MQTT 不用 HTTP → 设备资源紧

---

## 九、内容生产工具:本地 vs 云端

| | 本地工具 | 云端工具 |
|---|---|---|
| 编辑进程在哪 | 你的电脑 | 云端服务器 |
| 数据先存哪 | 你的硬盘 | 云端数据库 / 对象存储 |
| 离线能用吗 | 能 | 通常不能(或受限) |
| 多人协作 | 难(要发文件) | 天然支持 |
| 计算资源 | 你的 CPU | 云端 CPU |
| 例子 | Word、Premiere、Photoshop | Google Docs、Figma、Canva |

**注意**:这个边界正在模糊。Word 现在也能云协作(实时协同 + OneDrive 存储);Figma 是 Web App 但用了大量本地 GPU 渲染。

更精确的看法是:**"在哪存"和"在哪算"可以分开**。最现代的设计是:**计算尽量在本地(快)、存储和同步在云端(协作)**——Notion、Obsidian Sync、Linear 都是这个架构。

---

## 十、与"工具调用"知识树的关系

这一篇是**工具调用知识树的更底层基础**。整个 `00-原点` 里讲的"跨主机 IPC",在物理上就是这一篇里的"互联网通讯"。

```
互联网(本篇) ⊃ 远程 API 调用 ⊃ 模型工具调用(00-原点)
```

理解了这一层,再回头看模型工具调用,会更清楚:
- "工具调用"的"跨主机 IPC"几乎都走 HTTPS——因为应用层协议已经被 HTTP 统一了
- MCP 选了 stdio + SSE 两种传输——分别对应"同主机 IPC"和"基于 HTTP 的跨主机 IPC"
- 模型推理服务监听 443 端口、用 JSON 编码——跟所有现代 Web 服务一个套路

---

## 一句话总结

> **互联网是全球进程通过 HTTP(主要)进行 IPC 的网络。** 所有网站、API、CDN、工具调用,都是这个本质在不同维度上的展开。HTTP 不是因为最优秀才统治,而是因为它在"通用-效率-易用"的三角里选了大多数场景的最佳折中,生态把它推成了事实标准。