HTTP与HTTPS协议详解：从基础到加密原理

目录

• HTTP协议
• • HTTP协议格式
  • HTTP的方法
  • HTTP的状态码
  • HTTP常见Header
  • 长连接和短连接
  • Cookie
• HTTPS协议
• • 对称加密和非对称加密概念
  • HTTPS：对称加密+非对称加密+证书认证

HTTP协议

HTTP协议格式

HTTP的方法

HTTP的方法最主要的就是GET 和 POST。

GET：用于请求数据（从服务器获取资源，如网页、图片、API数据）。

POST：用于提交数据（向服务器发送数据以创建或修改资源，如表单提交、文件上传）。

GET：

1. 数据通过URL参数传递（附加在URL后，形如 ?key1=value1&key2=value2）。

2. 数据可见（暴露在地址栏、浏览器历史、服务器日志中）。

3. 有长度限制（受浏览器和服务器限制，通常不超过2048字符）。
   POST

4. 数据通过请求体（Request Body）传递。

5. 数据不可见（不显示在URL中，适合敏感信息）。

6. 无严格长度限制（可传输大量数据，如文件上传）

HTTP的状态码

最常见的状态码, 比如 200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)

HTTP常见Header

请求头（Request Headers）

客户端发送给服务器的头信息，用于告知服务器客户端的请求信息：

• Host
  告诉服务器请求的资源所在的主机和端口（主机和端口是服务端的）（如 Host: www.example.com:443）。
• User-Agent
  声明客户端的操作系统、浏览器版本等信息（如 User-Agent: Mozilla/5.0 (Windows NT 10.0)）。
• Referer
  表示当前请求是从哪个页面跳转过来的（如 Referer: https://www.google.com）。
• Cookie
  客户端携带的Cookie数据，用于会话管理（如 Cookie: session_id=abc123）。

响应头（Response Headers）

服务器返回给客户端的头信息，用于控制客户端行为或补充响应内容：

• Content-Type
  告知客户端返回数据的类型（如 Content-Type: text/html; charset=utf-8）。
• Content-Length
  表示响应体的长度（字节数），如 Content-Length: 1024。
• Location
  搭配 3xx重定向状态码，告诉客户端下一步跳转的URL（如 Location: /new-page）。

特殊情况说明

• Cookie 虽然是客户端发送的，但服务器也可以通过 Set-Cookie（响应头）让客户端存储Cookie。
• Content-Type 和 Content-Length 在极少数情况下也可能出现在请求头中（如POST请求提交数据时）。

长连接和短连接

短连接

特点：

1.每次请求-响应后关闭 TCP 连接。

2. 下次请求需重新建立连接（三次握手）。

3. HTTP/1.0 默认行为（除非显式设置 Connection: keep-alive）。

工作流程：

1.客户端发起请求 → TCP 三次握手建立连接。

2. 服务器返回响应。

3. 服务器主动关闭 TCP 连接（四次挥手）。

4. 后续请求重复步骤 1~3。

缺点

1.高延迟：每次请求需重新握手，增加 RTT（Round-Trip Time）时间。

2.资源浪费：频繁创建/销毁连接消耗 CPU 和内存。

3.性能瓶颈：不适合高频请求场景（如网页加载多个资源）。

适用场景

1.低频请求（如传统静态网页）。

2.无需保持状态的简单交互。

长连接

特点

1.复用 TCP 连接处理多个请求-响应。

2.默认在 HTTP/1.1 中启用（无需显式设置）。

3.通过 Connection: keep-alive 头部协商（HTTP/1.0 需手动开启）。

工作流程

1.客户端发起首次请求 → TCP 三次握手建立连接。

2.服务器返回响应，保持连接不关闭。

3.客户端复用同一 TCP 连接发送后续请求。

4.空闲一段时间后（超时时间由服务器设定），连接自动关闭。

优点

1.降低延迟：避免重复握手（尤其 HTTPS 的 TLS 握手更耗时）。

2.减少资源消耗：复用连接减少 CPU/内存开销。

3.提升吞吐量：适合高频请求（如现代网页加载 JS/CSS/图片）。

适用场景

1.高频请求（如 API 调用、动态网页）。

2.需要低延迟的交互（如 WebSocket 前置握手）。

Connection （请求头和响应头）

Connection 是一个 HTTP 请求头（Request Header）和响应头（Response Header），用于控制当前 TCP 连接的行为，尤其是决定是否保持长连接（Keep-Alive）。

• 客户端请求头：
  客户端通过 Connection 头告知服务器是否希望保持长连接。

GET /example HTTP/1.1
Host: api.example.com
Connection: keep-alive  # 表示客户端希望保持连接

• 服务器响应头：
  服务器通过 Connection 头确认是否支持长连接。

HTTP/1.1 200 OK
Connection: keep-alive  # 服务器同意保持连接
Keep-Alive: timeout=60, max=1000

Connection 可以取值 keep-alive 和 close ：

keep-alive：客户端或服务器希望保持连接（HTTP/1.1 默认启用，无需显式设置）。

close：明确要求当前请求完成后关闭连接（使用短连接）。

Cookie

Cookie 是 HTTP 协议中用于 在客户端（浏览器）存储小型数据 的机制，主要用于会话管理（如用户登录状态）、个性化设置（如语言偏好）和用户行为跟踪（如广告定向）。以下是全面解析：

• Cookie 的工作原理

  基本流程:

  1. 服务器设置 Cookie
     通过 HTTP 响应头的 Set-Cookie 字段向浏览器发送 Cookie：

  HTTP/1.1 200 OK
  Set-Cookie: session_id=abc123; Path=/; Secure; HttpOnly

  2. 浏览器存储 Cookie
     浏览器将 Cookie 存储在本地（内存或硬盘），后续请求自动附加到请求头的 Cookie 字段：

  GET /profile HTTP/1.1
  Cookie: session_id=abc123

  3. 服务器读取 Cookie
     服务器解析请求头的 Cookie 字段，识别用户身份或状态。

• Cookie 的分类

  1. 会话 Cookie（Session Cookie）

     不设置 Expires 或 Max-Age，浏览器关闭后自动删除。

  2. 持久 Cookie（Persistent Cookie）

     设置过期时间，长期存储在硬盘中。

• Cookie 的应用场景

  （1）会话管理

  用户登录后，服务器下发 Session ID（Session ID是根据用户名和密码生成的在整个服务器中的唯一的ID，确保每个用户都不一样）

  Set-Cookie: session_id=xyz789; Path=/; HttpOnly; Secure; SameSite=Lax

  后续请求自动携带该 Cookie，服务器验证 Session ID 维持登录状态。

  （2）个性化设置

  存储用户语言、主题偏好

HTTPS协议

HTTPS = HTTP + TLS/SSL 加密

TLS/SSL在应用层：

对称加密和非对称加密概念

对称加密：

定义：对称加密是指加密和解密使用相同密钥的加密方式。

特点：

• 加解密速度快，适合大数据量加密
• 密钥管理困难（需要安全地共享密钥）
• 算法相对简单

工作流程：

1. 通信双方协商一个共享密钥
2. 发送方用该密钥加密数据
3. 接收方用相同密钥解密数据

典型应用场景：

• 大量数据的加密（如文件加密、数据库加密）
• SSL/TLS协议中的数据加密部分
• 磁盘加密

非对称加密：

定义：非对称加密使用一对密钥（公钥和私钥），公钥用于加密，私钥用于解密。

特点：

• 加解密速度慢，不适合大数据量加密
• 解决了密钥分发问题
• 可实现数字签名功能
• 算法复杂度高

工作流程：

1. 接收方生成密钥对（公钥和私钥）
2. 接收方将公钥发送给发送方
3. 发送方用公钥加密数据
4. 接收方用私钥解密数据

典型应用场景：

• 安全密钥交换（如SSL/TLS握手）
• 数字签名
• 身份验证
• 小数据量加密

HTTPS：对称加密+非对称加密+证书认证

HTTPS使用对称加密+非对称加密+证书认证的方式来加密：

• 如果只使用对称加密+非对称加密来加密：
  

  关键问题就是：服务端发来的公钥被调包了，即客户端没法判断公钥是否是合法的。

  我们可以用证书认证来证明公钥的合法性。

• 证书（使用了数字签名）：
  

  签名形成的过程也被叫做对数据进行数字签名。

  数字签名是基于非对称加密算法。

• 如何使用对称加密+非对称加密+证书认证来数据传输：

  客户端浏览器都内置了CA机构的公钥

  • 步骤1：验证证书的真假：

    1. 客户端用CA公钥对发来的证书的签名进行解密
    2. 解密后的结果和INFO进行对比，
       相等，这个证书就是CA机构验证过的证书；不相等，就是假证书
    3. 查看INFO中的域名是否和服务端一样，一样就是服务端的证书
       防止中间人在CA机构申请了证书来窃听消息。（域名具有唯一性）

  • 步骤2：提取证书中的公钥a，客户端用公钥a来加密密钥b传输给服务端

  • 步骤3：双方用密钥b来传输消息。

• 提示：

  • CA机构的公钥用于解密，私钥用于加密，这是一个特例。
  • 如果中间人修改了证书的INFO，那么客户端用公钥解密后，签名和INFO不匹配；如果中间人修改了证书的签名，他没有私钥加密，那么最后客户端用公钥解密后，签名和INFO还不匹配。
  • 只有真正的CA机构的证书才会签名和INFO匹配。即使中间人使用了真正的CA证书，客户端查看证书INFO域名也会知道这不是客户端域名

总结

HTTPS ⼯作过程中涉及到的密钥有三组：

第⼀组(⾮对称加密): ⽤于校验证书是否被篡改。

第⼆组(⾮对称加密): ⽤于传递对称加密的密钥.

第三组(对称加密): 客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.