HTTP 应用层协议详解

HTTP 协议基础

HTTP（HyperText Transfer Protocol）即超文本传输协议，是互联网客户端与服务器之间通信的核心协议。它采用无连接、无状态的工作模式，每次请求都是独立的，这意味着服务端不会主动推送数据给客户端，且每次交互通常需重新建立连接。为了维持会话状态（如登录信息），通常需要配合 Session 和 Cookie 使用。

工作流程

当用户在浏览器输入网址时，浏览器作为客户端向服务器发起 HTTP 请求。服务器接收并处理该请求后，返回相应的 HTTP 响应。

在这个模型中，客户端是主动发起方，服务端是被动的响应方。请求携带数据从客户端流向服务端，响应则包含结果数据流回客户端。

报文格式

理解 HTTP 协议的关键在于掌握其请求与响应的报文结构。

请求格式

请求报文主要由五部分组成：

包括请求行（方法、URL、版本）、请求报头、空行以及请求正文。元素间通过空格和换行符分隔，这种定界方式有助于解决网络传输中的粘包问题。

响应格式

响应报文同样包含五个部分：

依次为状态行（版本、状态码、描述）、响应报头、空行及响应正文。

核心要素解析

URL（统一资源定位符）

URL 是资源的唯一标识，类似于网络世界的门牌号。一个典型的 URL 结构如下：

http://www.example.com:8080/product/list?category=book&page=1#top

• 协议：http 或 https，定义获取资源的方式。
• 主机名：www.example.com，通过 DNS 解析为 IP 地址。
• 端口号：:8080，指定服务监听的端口。
• 路径：/product/list，服务器根目录下的具体资源位置。
• 查询参数：?category=book&page=1，由 ? 引导，参数间用 & 分隔。
• 片段：#top，用于定位页面内的特定锚点。

请求方法

常用的 HTTP 方法有五种，其中 GET 和 POST 最为常见：

• GET：主要用于从服务器获取资源。参数直接拼接在 URL 中，肉眼可见，安全性相对较低。

  https://api.example.com/users?id=123 
  

• POST：主要用于向服务器提交数据（如表单、文件）。参数放在请求正文中，URL 不可见，适合传输敏感信息。

  https://www.example.com/login
  

请求报头

报头用于传递元数据，例如客户端类型、内容格式、缓存策略等。常见字段包括：

• Cookie：携带本地存储的用户信息，如偏好设置或登录态。
• Content-Type：声明正文的数据格式（如 JSON、表单、文件）。
• Content-Length：请求正文的字节数。
• Accept：告知服务端客户端可接受的内容类型。
• Host：请求的目标主机名和端口。
• Referer：指示请求来源页面。

HTTP 版本

• HTTP/1.0：仅支持短连接，每次请求都需重新建立 TCP 连接，效率较低。
• HTTP/1.1：默认开启长连接（Keep-Alive），允许复用连接发送多个请求，显著提升了性能。

响应状态码

状态码反映了服务器对请求的处理结果，分为五大类：

• 1xx：信息提示，表示请求已接收，继续处理。
  • 100：继续上传（常用于大文件分片）。
• 2xx：成功处理。
  • 200：请求成功。
  • 201：资源创建成功。
  • 204：删除成功，无内容返回。
• 3xx：重定向。
  • 301：永久重定向。
  • 302：临时重定向。
• 4xx：客户端错误。
  • 400：请求语法错误。
  • 401：未授权（未登录）。
  • 403：禁止访问（无权限）。
  • 404：资源不存在。
• 5xx：服务端错误。
  • 500：服务器内部错误（如崩溃、数据库故障）。

Cookie 与 Session

Cookie 机制

Cookie 是存储在浏览器端的小段数据，用于记录用户状态。首次访问时，服务器通过 Set-Cookie 响应头下发数据，浏览器保存后，后续请求会自动携带该 Cookie。

Set-Cookie: name=value; [属性 1=值 1]; ...

关键属性包括：

• Expires：过期时间，决定生命周期。
• Domain：生效域名。
• Path：生效路径。
• Secure：仅允许 HTTPS 传输。

Session 机制

由于 Cookie 存在被窃取风险，Session 将敏感数据保存在服务端，仅向客户端传递一个无意义的 Session ID。客户端通过 Cookie 携带此 ID，服务端据此查找对应的会话数据。这种方式有效避免了敏感信息暴露在网络传输中。

HTTPS 原理

HTTPS 在 HTTP 基础上增加了加密层，防止中间人篡改数据。其核心涉及对称加密与非对称加密的结合。

• 对称加密：加解密使用同一密钥，效率高但密钥分发困难。
• 非对称加密：使用公钥加密、私钥解密，解决了密钥分发问题但效率低。

单纯使用一种加密方式均存在缺陷：对称加密难以安全分发密钥；非对称加密效率低且无法保证双向安全。因此，实际应用中采用混合加密方案：

1. 握手阶段：服务端提供数字证书（含公钥），客户端验证证书合法性（CA 认证），确保公钥可信。
2. 密钥协商：客户端生成随机对称密钥，用服务端公钥加密后传回。
3. 数据传输：双方使用该对称密钥进行高效加密通信。

此外，为防止数据被篡改，还会引入数字签名机制：对数据进行哈希运算，并用私钥加密哈希值。接收方解密哈希值并与本地计算的哈希值比对，若一致则证明数据完整未被篡改。

通过非对称加密 + 对称加密 + CA 证书认证的组合，HTTPS 既保证了传输效率，又确保了身份真实性和数据机密性。