计算机网络笔记再战——理解几个经典的协议10 HTTP章4
确保 Web 安全的HTTPS
HTTP是不安全的，它使用的是明文传递，这意味着潜在的报文纂改。这里我们将学习更加安全的HTTPS协议
- 通信使用明文（不加密），内容可能会被窃听
- 不验证通信方的身份，因此有可能遭遇伪装
- 无法证明报文的完整性，所以有可能已遭篡改
HTTP本身没有办法加密，但是可以跟SSL（Secure Socket Layer）或者是TLS（Transport Layer Security）一起配套使用。这个时候，我们先使用安全加密协议进行加密。这样信道就可以被认为是可靠的。
但还有一种——我们如何确保双方是真实存在而不是伪造的呢？毕竟谁都可以发起HTTP，我可以伪装成任何人发起通信，这是不安全的。所以SSL证书就派上了用场，SSL证书是第三方机构用信誉作为担保，保证通信的对方是真实存在的，而且就是这个人。
当然，还有一种就是报文纂改，我们使用一种MD5 和 SHA-1 等散列值校验来保证我们的报文是没有经过祖安该的
这样看来HTTP+ 加密 + 认证 + 完整性保护=HTTPS。HTTPS的通信协议步骤如下：
- 步骤 1：客户端发送 Client Hello 报文，包含支持的 SSL 版本和加密组件列表。
- 步骤 2：服务器回应 Server Hello 报文，选定加密组件，并确认 SSL 版本。
- 步骤 3：服务器发送 Certificate 报文，提供公钥证书。
- 步骤 4：服务器发送 Server Hello Done 报文，表示握手初始阶段结束。
- 步骤 5：客户端发送 Client Key Exchange 报文，内含用服务器公钥加密的 Pre-master secret。
- 步骤 6：客户端发送 Change Cipher Spec 报文，表示后续通信将使用协商密钥加密。
- 步骤 7：客户端发送 Finished 报文，包含之前通信内容的校验值。
- 步骤 8：服务器发送 Change Cipher Spec 报文。
- 步骤 9：服务器发送 Finished 报文。
- 步骤 10：握手完成，SSL 加密通道建立，开始应用层通信，客户端发送 HTTP 请求。
- 步骤 11：服务器回应 HTTP 响应。
- 步骤 12：通信结束后，客户端发送 close_notify 报文，随后发送 TCP FIN 报文，关闭 TCP 连接。
基于HTTP的派生协议
HTTP 协议作为互联网通信的基石，诞生于上世纪九十年代，是万维网的核心协议。最初的 HTTP/0.9 和 HTTP/1.0 是为简单的文本页面传输设计的，随着 Web 的迅猛发展，HTTP/1.1 于 1999 年被正式采纳，成为至今最广泛应用的协议版本，后来的 HTTP/2 和 HTTP/3 则从性能、并发、连接管理等方面对协议做了大幅优化。在这个基础之上，诞生了一大批衍生协议或扩展协议，服务于内容发布、媒体流传输、实时数据同步、设备控制、安全认证等不同领域。
首先必须提到的就是 WebDAV（Web Distributed Authoring and Versioning），它是一种基于 HTTP/1.1 的扩展协议，主要用于支持 Web 上的分布式内容管理。WebDAV 在 HTTP 基础上新增了一些方法，例如 PROPFIND（用于获取资源的属性信息）、PROPPATCH（修改属性）、MKCOL（创建集合资源）、COPY 和 MOVE（复制与移动资源）、LOCK 和 UNLOCK（锁定资源以避免写入冲突）等。这些操作使得 WebDAV 能够支持文档远程编辑、多用户协作和版本控制，并被广泛用于如企业网盘、协作办公系统中。例如 Microsoft 的 SharePoint 和 Apple 的 iCloud Drive 等都提供对 WebDAV 的支持。WebDAV 的实现过程中还引入了对资源属性的统一建模机制，即将元信息抽象为属性对，并支持 XML 格式进行封装、解析。虽然 WebDAV 本身并不提供完整的版本控制能力，但其后续扩展 DeltaV（RFC 3253）则补全了这一点，使得 WebDAV 可以支持资源的历史记录、版本图、分支合并等复杂功能。
SOAP（Simple Object Access Protocol）虽然通常和 XML Web Service 相联系，但它本质上是一个基于 HTTP（或其他传输协议）的消息传递框架。SOAP 协议使用 XML 结构封装消息，通过 HTTP 的 POST 方法进行传输，具有良好的平台无关性和语言中立性。SOAP 的头部结构支持安全、事务、路由等功能，而主体部分则可携带具体的数据或命令，适合企业级系统间的高可靠性通信。SOAP 与 WSDL（Web Services Description Language）配合使用，可以提供完整的服务描述与调用定义，而 UDDI（Universal Description, Discovery and Integration）作为注册发现机制，可以用于 Web 服务的动态发现。虽然 REST 式服务在轻量化通信方面后来居上，但 SOAP 至今仍在一些需要严格安全和事务控制的系统中被广泛应用，例如银行、保险、航运等领域的企业系统中。
再来看 REST（Representational State Transfer）风格的服务。REST 并不是一个协议，而是一种基于 HTTP 协议的设计风格。它强调无状态通信，资源导向的接口设计，以及统一的操作接口（即使用 HTTP 方法如 GET、POST、PUT、DELETE 对资源进行操作）。REST 架构轻量、简洁、易于实现，并且天然与 Web 兼容，因此迅速成为 Web API 的主流标准。诸如 Twitter、GitHub、Google 等提供的开放 API，大多遵循 REST 风格。REST 接口广泛使用 JSON 作为数据交换格式，与早期基于 XML 的接口相比，具有更小的数据体积和更高的解析效率。REST 的一个关键点是资源 URI 的设计应具有可读性和层次结构，并且支持超媒体导航，这使得 REST 可以与 HTML、XML 等媒体类型高度兼容，同时也更利于自动化工具对接口的解析和使用。虽然 REST 本身不规定状态管理方式，但实践中常常使用 Cookie 或 Token 实现用户状态管理与认证控制。
GraphQL 是 Facebook 于 2015 年开源的一种 API 查询语言和运行时系统，它同样是基于 HTTP 实现的。不同于 REST 中“一资源一接口”的设计理念，GraphQL 将所有资源建模为一个统一的图结构，客户端可以一次请求中声明所需的所有字段，服务器仅返回指定数据。这样可以有效解决 REST 接口中存在的 over-fetching 和 under-fetching 问题。GraphQL 接口通常通过 HTTP POST 方法进行交互，请求体中使用 JSON 格式的查询语法表达所需字段与数据关系。GraphQL 的架构允许将后端多个微服务、数据源聚合为统一的数据视图，因此非常适合构建灵活、可扩展的前端数据接口。其运行时执行查询解析与类型校验，并支持查询嵌套、参数化、别名、片段、订阅等高级语义。此外，GraphQL 还引入 Schema 的概念，明确了每个字段、类型的结构与依赖，便于接口文档的自动生成与客户端代码的类型校验。
另一个重要的基于 HTTP 的协议是 gRPC。它最初由 Google 推出，是一种高性能、开源和通用的远程过程调用（RPC）框架，适用于微服务间通信。虽然 gRPC 默认基于 HTTP/2 实现（其多路复用、头部压缩、流控制特性对性能有显著提升），但其传输层仍以 HTTP 为基础。gRPC 使用 Protocol Buffers（简称 Protobuf）作为接口定义语言和数据序列化格式，相比 JSON 更为高效与紧凑。gRPC 支持多种语言间的互通，可以通过定义 .proto 文件来生成对应语言的客户端和服务端代码。gRPC 的一个突出特点是支持双向流通信（bi-directional streaming），即客户端与服务端可保持一个持续的 HTTP/2 流，在该流上互相发送多个消息，非常适合用于实时通信和数据流传输场景。为了支持浏览器环境下的使用，Google 还推出了 gRPC-Web，这是一种使用 HTTP/1.1 封装 gRPC 消息的子协议，能让 Web 应用也能访问基于 gRPC 的后端服务。
继续扩展，SSE（Server-Sent Events）是基于 HTTP 的一种单向服务器推送机制。它允许服务器主动通过一个 HTTP 连接不断向客户端发送事件数据，客户端通过 JavaScript 的 EventSource API 接收这些事件并作出响应。SSE 使用的是 HTTP 的持久连接机制，连接建立后，服务器不断向客户端发送特定格式的数据，数据以 data: 前缀标识，事件之间用换行符分隔。相较于 WebSocket 的双向通信，SSE 更加简单可靠，特别适用于数据变化频繁但客户端只需被动接受更新的场景，如股票报价、实时新闻推送、聊天信息提示等。SSE 的优点包括基于 HTTP，因此可轻松穿透防火墙与代理，且自动支持断线重连机制。
与 SSE 形成对比的是 WebSocket，它是一种更为通用的双向通信协议。虽然 WebSocket 在通信建立过程中依赖 HTTP 进行握手，但握手成功后将协议升级为 WebSocket，之后的通信不再使用 HTTP 语义，而是使用更高效的帧结构进行双向消息传递。WebSocket 的目标是解决 HTTP 在实时通信上的不足，适用于聊天室、游戏同步、协同编辑、在线监控等需要低延迟双向通信的场景。WebSocket 支持文本与二进制数据，且其连接保持状态，有利于维持会话信息，并且由于帧头结构比 HTTP 请求头更为精简，网络开销也大幅降低。
还有一个值得一提的是 JSON-RPC 和 XML-RPC，它们都是基于 HTTP 的轻量级远程过程调用协议。JSON-RPC 使用 JSON 格式定义方法调用、参数和返回值，而 XML-RPC 则使用 XML 表达这些结构。这类协议在设计上力求简单，仅使用 POST 方法，通过 HTTP 传递请求与响应消息体，广泛应用于跨平台接口、轻量服务集成等场景。虽然这些协议逐渐被 REST 和 gRPC 所取代，但在一些对协议标准化、明确格式有高要求的老系统中仍然占据一席之地。
在设备控制与物联网领域，CoAP（Constrained Application Protocol）虽然不是直接基于 HTTP，但它借鉴了 HTTP 的语义结构，提供了与 HTTP 类似的 GET、POST、PUT、DELETE 操作。CoAP 使用 UDP 作为传输层，适合资源受限的设备之间的通信，但它支持将 CoAP 请求转换为 HTTP 请求，从而实现边缘设备与 Web 服务之间的桥接。与此同时，HTTP-over-CoAP 也成为一种新型的边缘应用集成技术，适用于智能家居、环境监控等场景。
HTTP Signature 是一种用于对 HTTP 请求进行签名的机制，常用于 API 安全认证中。它通过对请求的特定头部和方法签名，并在 Authorization 头中附带签名摘要，实现消息完整性验证与身份认证。它广泛用于如 ActivityPub、Linked Data 等去中心化社交协议中，用于确保消息来源可信和传输内容未被篡改。
除了上述协议，还可以看到 HTTP/3 的出现为未来更多协议提供了基础。HTTP/3 基于 QUIC 协议实现，具备 0-RTT 连接、无队头阻塞、多路复用传输等优势，为构建低延迟、可靠的应用层协议打下基础。未来的新协议，如 Media over QUIC、MASQUE 等，也将以 HTTP/3 为骨架进行构建。