15 KiB
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 为什么能"垄断"
- 无状态、文本化、易实现——比早期二进制协议简单太多
- 浏览器只支持有限协议——HTTP 成了"穿透防火墙最稳的协议"(几乎所有公司都开 80/443 端口)
- REST API 风潮——所有第三方服务的 API 默认就是 HTTP 上的 JSON
- HTTPS 成了安全默认——浏览器警告 + Let's Encrypt 免费证书推动全网迁移
- 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 不是因为最优秀才统治,而是因为它在"通用-效率-易用"的三角里选了大多数场景的最佳折中,生态把它推成了事实标准。