系统设计之通讯协议

 TCP/IP协议

数据如何通过网络发送？为什么 OSI 模型需要这么多层？

下图显示了数据在网络传输时如何封装和解封装。

步骤1：当设备A通过HTTP协议通过网络向设备B发送数据时，首先在应用层添加HTTP头。

步骤2：然后将TCP或UDP标头添加到数据中。它在传输层被封装成 TCP 报文段。标头包含源端口、目标端口和序列号。

步骤 3：然后在网络层用 IP 标头封装这些段。IP 标头包含源/目标 IP 地址。

步骤 4：IP 数据报在数据链路层添加 MAC 标头，其中包含源/目标 MAC 地址。

步骤5：封装后的帧被发送到物理层并以二进制位通过网络发送。

步骤6-10：当Device B从网络接收到比特时，它执行解封装过程，这是封装过程的逆处理。头部被逐层去除，最终Device B可以读取数据。

我们在网络模型中需要分层，因为每一层都专注于自己的职责。每层都可以依赖标头来处理指令，不需要知道最后一层数据的含义。

HTTP协议

协议发展路径

HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)

每一代HTTP解决了什么问题？

下图说明了主要功能。

• HTTP 1.0 于 1996 年最终确定并完整记录。对同一服务器的每个请求都需要单独的 TCP 连接。

• HTTP 1.1 于 1997 年发布。TCP 连接可以保持打开状态以供重用（持久连接），但它并没有解决 HOL（队头）阻塞问题。

  HOL阻塞——当浏览器允许的并行请求数用完时，后续请求需要等待前面的请求完成。

• HTTP 2.0于2015年发布，通过请求复用解决了HOL问题，消除了应用层的HOL阻塞，但传输层（TCP）仍然存在HOL。

  如图所示，HTTP 2.0 引入了 HTTP“流”的概念：一种允许将不同的 HTTP 交换复用到同一个 TCP 连接上的抽象。每个流不需要按顺序发送。

• HTTP 3.0 第一稿于 2020 年发布。它是 HTTP 2.0 的拟议后继者。它使用 QUIC 而不是 TCP 作为底层传输协议，从而消除了传输层的 HOL 阻塞。

QUIC 基于 UDP。它将流作为传输层的一等公民引入。QUIC 流共享相同的 QUIC 连接，因此创建新流不需要额外的握手和缓慢启动，但 QUIC 流是独立交付的，因此在大多数情况下，影响一个流的数据包丢失不会影响其他流。

HTTP 状态码

HTTP 的响应代码分为五类：

1. 信息性 (100-199)
2. 成功 (200-299)
3. 重定向 (300-399)
4. 客户端错误 (400-499)
5. 服务器错误 (500-599)

在API设计方面，REST和GraphQL各有缺点。下图显示了 REST 和 GraphQL 之间的快速比较。

 REST

• 使用标准 HTTP 方法（如 GET、POST、PUT、DELETE）进行 CRUD 操作。
• 当您需要在单独的服务/应用程序之间提供简单、统一的接口时，效果很好。
• 缓存策略实施起来很简单。
• 缺点是可能需要多次往返才能从不同的端点组装相关数据。

GraphQL

• 为客户端提供单一端点来精确查询他们所需的数据。
• 客户端指定嵌套查询中所需的确切字段，服务器返回仅包含这些字段的优化负载。
• 支持用于修改数据的 Mutations 和用于实时通知的订阅。
• 非常适合聚合来自多个来源的数据，并且可以很好地满足快速变化的前端需求。
• 但是，它将复杂性转移到客户端，并且如果没有适当保护，可能会允许滥用查询
• 缓存策略可能比 REST 更复杂。

REST 和 GraphQL 之间的最佳选择取决于应用程序和开发团队的具体要求。GraphQL 非常适合复杂或频繁变化的前端需求，而 REST 适合首选简单且一致的合约的应用程序。

这两种 API 方法都不是灵丹妙药。仔细评估要求和权衡对于选择正确的风格非常重要。REST 和 GraphQL 都是公开数据和支持现代应用程序的有效选项。