计算机网络笔记再战——明白几个经典的协议HTTP章4

计算机网络笔记再战——明白几个经典的协议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 为骨架举行构建。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。