理解请求-响应模型

Source: Dev.to

Overview

请求‑响应是一个令人兴奋的话题，因为它是互联网以及我们今天使用的大多数技术实际运作的基础。

正如名字所示，请求‑响应模型是客户端（请求方）和服务器（响应方）之间的通信方式。这种通信可以是同步的（等待回复）也可以是异步的（在等待时不阻塞）。

其核心思想很简单：

• 客户端发送请求（请求方）。该请求包含客户端想要的内容——数据、指令、参数、头信息等。
• 当服务器收到该请求后，会尝试理解它、处理它，然后返回一个合适的回复，我们称之为响应。

How the Request–Response Model Works

1. Client sends a request – 客户端通过向服务器发送请求来发起通信。
2. Server parses the request – 服务器将请求拆分为各部分（头信息、主体、参数等），以了解请求的内容。
3. Server processes the request – 服务器执行反序列化、业务逻辑、数据库查询、校验等操作。
4. Server sends a response – 处理完毕后，服务器准备并发送包含状态码、头信息和数据的响应。
5. Client parses and consumes the response – 客户端解析响应并根据需要使用数据（渲染 UI、更新状态、触发操作）。

Where Is the Request–Response Model Used?

• Web 技术：HTTP、DNS、SSH
• RPC（远程过程调用）
• SQL 与数据库协议
• API：REST、SOAP、GraphQL

如果你曾加载过网页、登录过应用或从 API 获取过数据，你已经在使用这个模型。

Structure of a Request–Response Model

• 请求有明确的边界。
• 协议（例如 HTTP）定义了通信方式。
• 消息格式（JSON、XML 等）定义了数据的表示方式。
• 双方必须就这些规则达成一致，通信才能正常进行。

Limitations of the Request–Response Model

• 通知（实时更新） – 持续轮询效率低下；基于推送的协议如 WebSockets 更合适。
• 非常长时间运行的请求 – 客户端可能会被阻塞等待响应，使模型不适用。
• 并发和负载均衡挑战 – 大量并发请求会给服务器带来压力，若设计不当会出现问题。
• 数据流 – 连续流（视频、实时推送）不适合单一的请求‑响应循环。
• 离线或不可靠的网络 – 连接中断会打断流程。
• 高度解耦的系统 – 事件驱动或基于消息的架构往往更受青睐。

Conclusion

请求‑响应模型是计算中最重要的通信模式之一。它驱动了网页、API、数据库以及我们日常依赖的众多系统。

虽然它简单且强大，但了解其局限性与了解其工作原理同样重要。掌握何时使用请求‑响应以及何时不使用，是构建可扩展、高效系统的关键技能。

如果你已经很好地理解了这个模型，那么你已经掌握了现代软件通信的核心部分。