1. 基础构建模块：从本地到网络
管道 (Pipe) & 命名管道 (FIFO)
Unix 经典工具，简单却蕴含了诸多通信系统设计的基本属性。
进程 A
进程 B
单工 (Simplex)
可靠
有序
字节流
异步
流控
匿名 (Pipe)
命名 (FIFO)
注意：两个管道可以组合成一个全双工信道，这是许多系统进程间通信的基础。
共享资源 (Shared Resources)
通过共享内存、文件锁等方式实现通信，追求极致的本地性能。
进程 A
进程 B
内存
高性能
低延迟
脆弱
强耦合
本地优化
跨机需RDMA等
缺点是脆弱性：状态和知识的过度共享，一个环节出错可能导致整个系统崩溃。
套接字 (Sockets)
网络通信的基石，引入了客户端-服务器模型和连接的概念。
Client
Server (binds to port)
双工 (Duplex)
点对点
客户端-服务器
面向连接
字节流 (TCP)
消息 (UDP/UDS)
Unix域套接字 (UDS) 甚至可以传递文件描述符，这是一种对象生命周期管理的雏形。
2. 高级抽象与范式
RPC (远程过程调用)
将网络通信抽象为本地函数调用，核心是 **IDL (接口定义语言)** 和代码生成。
// Client Code
Calculator.Add(5, 3); // 像本地调用
// Server Execution
func Add(a, b) { // 实际在远程执行
return a + b;
}
关键特征:
- 请求-响应模型，通常是同步的
- 面向过程，无连接
- 通过 IDL (如 ProtoBuf) 定义服务和消息
- gRPC 引入了流式处理，增加了异步能力
RMI (远程方法调用)
RPC 的面向对象版本。传递的不再是纯数据，而是**对象的引用**。
// Client finds an object
obj = Directory.lookup("/my/calculator");
// Invokes method on the remote object reference
result = obj.add(5, 3);
引入的复杂性:
- 需要目录服务来发现初始对象
- 必须管理远程对象的生命周期 (引用计数/GC)
- 客户端/服务器界限模糊，系统高度耦合
- 警惕“网络透明性”陷阱 (e.g., DCOM, CORBA)
代理/中间件 (Broker)
引入一个中介来解耦通信双方，常用于消息队列和发布/订阅系统。
Publisher
Subscriber
Broker
Producer
Consumer
适用场景:
- 单向通信，发送后不关心
- 广播/多播事件
- 需要持久化和“至少一次”送达保证
- 不适合低延迟的请求-响应场景
REST (表述性状态转移)
一种架构风格，将万物抽象为**资源 (Resource)**，通过 URI 进行标识。
GET /users/123
POST /users
PUT /users/123
DELETE /users/123
核心思想:
- 松散的面向对象：资源是名词，方法是动词 (GET, POST...)
- 无状态：服务器不保存客户端会话状态
- 缺乏内置的生命周期管理，资源需要手动或通过其他机制清理
- 与 RPC 相比，更侧重于资源和其状态的转移
3. 范式对比与权衡
没有银弹。不同的通信范式在解耦程度、性能开销、状态管理等方面各有优劣。选择哪一种取决于你的具体业务场景和系统目标。
4. 结论：超越功能本身
真正的决定性因素：非功能性需求
演讲最终指出，协议本身的功能特性固然重要，但现实中，**生态系统、实现质量、兼容性、社区支持和工具链**等非功能性因素，往往对项目的成败起着更大的作用。
例如，CORBA 的失败很大程度上源于其复杂性和糟糕的兼容性问题。因此，在做技术选型时，必须将这些“软实力”纳入考量，而不仅仅是比较协议的技术细节。