4、网络基础与集成：TCP/IP、HTTP/HTTPS、RESTful API设计原则、gRPC入门
做系统集成，网络是绕不开的坎。我见过太多项目，业务逻辑写得漂漂亮亮，一上线就卡在网络通信上。说白了，网络基础不牢，集成就是空中楼阁。
这一章，我们聊聊四个核心话题：TCP/IP协议栈、HTTP/HTTPS、RESTful API设计，以及gRPC入门。嗯，都是实战中天天要用的东西。
4.1 TCP/IP协议栈：集成的地基
TCP/IP不是单个协议，而是一组协议的集合。我习惯把它看成四层模型：应用层、传输层、网络层、网络接口层。
你想想看，两个系统要通信，数据是怎么从A跑到B的？
- 应用层：HTTP、FTP、SSH这些，负责“说什么”
- 传输层：TCP、UDP，负责“怎么传”
- 网络层：IP协议，负责“往哪传”
- 网络接口层：以太网、Wi-Fi，负责“物理上怎么走”
我在项目中遇到过一个问题：两个服务之间偶尔丢包，查了半天发现是MTU设置不一致。嗯，这就是网络接口层的问题，但表现却在应用层——数据莫名其妙就断了。
核心要点：TCP提供可靠连接，有三次握手、四次挥手、重传机制。UDP只管发，不保证到。集成场景下，90%用TCP，实时音视频才考虑UDP。
避坑指南：我曾经在配置防火墙时忘了放开TCP的端口，结果服务一直连不上。排查了整整两个小时，最后发现是安全组规则没配。记住：网络不通，先查防火墙。
4.2 HTTP/HTTPS：集成的主力军
HTTP是应用层最常用的协议。说白了，就是客户端发请求，服务端给响应。简单，但够用。
HTTPS就是在HTTP外面套了一层TLS/SSL加密。为什么要加密？你想想看，如果明文传输，中间人随便抓包就能看到你的密码、Token、业务数据——这谁受得了？
我建议，所有生产环境的集成，一律用HTTPS。别图省事用HTTP，出事就是大事。
HTTP的核心方法就几个：
| 方法 | 用途 | 是否幂等 |
|---|---|---|
| GET | 获取资源 | 是 |
| POST | 创建资源 | 否 |
| PUT | 更新资源（全量） | 是 |
| PATCH | 更新资源（部分） | 否 |
| DELETE | 删除资源 | 是 |
状态码也要记牢：2xx成功，3xx重定向，4xx客户端错误，5xx服务端错误。我见过有人把500当业务错误码用，这是大忌。
注意：HTTP是无状态的。每次请求都是独立的，服务端不记得你是谁。所以需要Token、Session、Cookie这些机制来维持状态。集成时，Token是最常用的方式。
4.3 RESTful API设计原则
RESTful API，说白了就是一套设计规范。让API看起来像在操作资源，而不是在调用函数。
我个人习惯遵循这几个原则：
- 资源路径用名词：
/users、/orders，不要用动词 - 用HTTP方法表达动作：GET查、POST增、PUT改、DELETE删
- 版本号放路径里：
/v1/users，方便迭代 - 返回统一格式：成功失败都有固定结构
- 使用合适的HTTP状态码：别所有情况都返回200
举个例子，一个用户资源的API设计：
GET /v1/users # 获取用户列表
GET /v1/users/{id} # 获取单个用户
POST /v1/users # 创建用户
PUT /v1/users/{id} # 全量更新用户
PATCH /v1/users/{id} # 部分更新用户
DELETE /v1/users/{id} # 删除用户返回格式我建议这样：
// 成功响应
{
"code": 0,
"message": "success",
"data": { ... }
}
// 失败响应
{
"code": 1001,
"message": "用户不存在",
"data": null
}避坑指南：我曾经设计API时，把删除接口做成了POST请求，结果前端同事疯狂吐槽。记住：RESTful的核心就是用HTTP方法表达语义，别自己发明轮子。
4.4 gRPC入门：高性能的替代方案
RESTful API虽然好用，但有些场景性能不够。比如微服务之间的高频调用、流式数据传输。这时候，gRPC就派上用场了。
gRPC基于HTTP/2，使用Protocol Buffers（protobuf）作为序列化协议。说白了，就是比JSON更小、更快、更严格。
一个简单的gRPC服务定义：
syntax = "proto3";
service UserService {
rpc GetUser (GetUserRequest) returns (User);
rpc ListUsers (ListUsersRequest) returns (stream User);
}
message GetUserRequest {
int32 user_id = 1;
}
message User {
int32 user_id = 1;
string name = 2;
string email = 3;
}gRPC支持四种通信模式：
- 一元RPC：客户端发一个请求，服务端回一个响应。和REST差不多。
- 服务端流式RPC：客户端发一个请求，服务端持续返回数据流。适合大文件下载。
- 客户端流式RPC：客户端持续发送数据，服务端最后返回一个响应。适合批量上传。
- 双向流式RPC：双方同时发送和接收数据。适合实时聊天。
我建议，内部服务之间的集成，优先考虑gRPC。对外暴露的API，还是用RESTful更通用。
核心对比：gRPC比RESTful快3-5倍，但调试起来麻烦。RESTful用curl就能测，gRPC需要专门的工具（如grpcurl）。选哪个，看场景。
注意：gRPC的负载均衡和健康检查需要额外配置。我曾经在生产环境忘了配健康检查，结果某个节点挂了，流量还在往那发——惨痛的教训。
知识体系总览
下面这张图，把本章的核心内容串起来了。你可以看到，从底层协议到上层API，层层递进。
嗯，网络基础这块，说难不难，说简单也不简单。关键是理解每一层在做什么，以及它们之间怎么配合。TCP/IP保证数据能到，HTTP/HTTPS规定数据怎么包装，RESTful和gRPC则是两种不同的集成风格。
我个人建议，先把TCP/IP和HTTP吃透，再学RESTful和gRPC。基础不牢，后面全是坑。