364 lines
15 KiB
Markdown
364 lines
15 KiB
Markdown
# 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 不是因为最优秀才统治,而是因为它在"通用-效率-易用"的三角里选了大多数场景的最佳折中,生态把它推成了事实标准。
|