Skip to main content

HTTP/HTTPS

ventixyAbout 22 min

Hyper Text Transfer

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是⼀种⽤于分布式、协作式和 超媒体信息系统的 应用层协议 （TCP/UDP为运输层协议）

HTTP协议版本介绍

HTTP协议发展历程：0.9、1.0、1.1版本（HTTP/1.1）、HTTP/2.0、HTTP/3.0：

  • HTTP/0.9：仅支持GET方法，只能发送HTML格式的数据，不支持请求头和响应头
  • HTTP/1.0：增加了POST、HEAD等请求方法，引入头部信息：支持请求头和响应头
    • 多数据格式：不仅可以传输纯文本，还可以传输图片、视频等多种媒体类型
    • 短连接：每次请求都需要建立新的TCP连接，效率较低
  • HTTP/1.1：通过Connection: keep-alive默认保持TCP连接打开，允许多个请求复用同一个TCP连接，还支持分块传输编码、断点续传等功能
  • HTTP/2.0：采用更高效的二进制格式代替文本格式，提高解析效率
  • HTTP/3.0：放弃了TCP，转而使用基于UDP的QUIC协议，进一步提升了性能并减少了延迟

尽管HTTP/2.0和HTTP/3.0提供了显著的性能改进，但HTTP/1.1仍然是广泛使用的版本之一

如果希望客户端和服务器之间能够进行正常的通讯，双方在传递数据时只需要遵守固定的格式即可 这个格式其实就是协议

HTTP协议：客户端和服务器在进行通讯时，发送的HTTP请求和响应应当具有的特定的格式

HTTP请求报文

HTTP请求报文是客户端（通常是Web浏览器）与服务器之间通信的基础。主要由三个部分组成：请求行 (Request Line)，请求头 (Request Headers)，请求正文 (Request Body)

不同于一些底层网络协议（如TCP/IP），后者可能会利用固定长度或特定位置的比特/字节来定义和区分字段，HTTP作为一种应用层协议，采用的是基于文本的格式，使得它更加灵活和易于人类阅读

请求行 (Request Line)包含三个字段：请求方法(如GET、POST等)、请求URI 和 HTTP版本

请求头 (Request Headers)：请求头用于描述请求的元数据，指导服务器如何处理和优化响应

请求正文 (Request Body) 中包含了要的数据，主要在POST、PUT等请求中使用。也可用来传输大量的数据，比如文件上传

常见请求头字段

HTTP请求头（Request Headers）包含了客户端发送给服务器的关于请求、客户端本身以及所需响应的信息。这些头部字段帮助服务器理解请求的具体细节，并据此做出适当的响应

  1. Host：指定请求的目标主机名和端口号，这是HTTP/1.1强制要求的字段，用于支持虚拟主机服务

  2. User-Agent： 提供了发起请求的用户代理（通常是浏览器）的信息，包括名称、版本号和其他属性。这有助于服务器根据不同的客户端特性定制响应内容

  3. Accept：列出了客户端能够理解的内容类型（MIME类型，如text/html, application/json等），让服务器知道客户端期望接收的数据格式

  4. Accept-Language：表示客户端偏好的自然语言，帮助服务器选择合适的语言版本返回给客户端

  5. Accept-Encoding：客户端支持的内容编码方式（如gzip, deflate），允许服务器在传输时对数据进行压缩以节省带宽。

  6. Connection：控制网络连接的行为，如keep-alive保持连接打开以便于后续请求，或close指示服务器立即关闭连接。

  7. Content-Type：当使用POST或PUT方法时，指定请求体中的媒体类型，告知服务器客户端发送的数据格式。

  8. Content-Length：标识请求体的大小（以字节为单位），仅当有请求体时适用

  9. Authorization：包含认证凭据，用于验证客户端的身份，通常与Base64编码后的用户名和密码一起使用

  10. Cookie：包含之前由服务器通过Set-Cookie头设置的cookie信息，使客户端可以向服务器发送状态信息

  11. Referer：显示当前页面是从哪个页面链接过来的，有助于追踪用户的浏览路径

  12. Origin：在跨域请求中指明请求来源，帮助服务器判断是否允许该请求

HTTP头部字段的数量并不是固定的，HTTP协议甚至允许自定义头部字段以满足特定需求

  • HTTP头部字段不是通过位数来区分的，而是通过文本格式进行解析：每个HTTP头部字段都是一个名称: 值对，其中名称和值之间用冒号（:）加上空格分隔。字段名是大小写不敏感的

  • 顺序无关性：头部字段的顺序一般不影响其含义，除了某些特定情况下的特殊字段（如Connection字段中的元素）

每个头部字段都以回车换行（CRLF, \r\n）结束。头部字段集合以一个额外的CRLF行（即两个连续的CRLF）结束，这标志着头部与可能跟随的实体主体之间的分界

HTTP响应报文

HTTP响应报文是服务器返回给客户端的消息，包含了请求的结果信息以及可能的资源数据。响应报文由三部分组成：状态行、响应头部和实体主体（可选）

状态行 (Status Line)：包含HTTP版本、状态码（如200）和状态消息（如ok）

响应头部 (Response Headers)：包含了一系列 名称: 值 对，提供了关于响应或其载荷的信息

空行 (Blank Line)：一个仅包含CRLF（回车换行）的行，用于标记头部字段的结束和实体主体的开始

常见的状态码

HTTP状态码是服务器对客户端请求的响应状态的数字代码。它们帮助客户端理解服务器处理请求的结果，并根据这些结果采取适当的行动

HTTP状态码分为五个类别，每个类别的第一个数字定义了响应的类别

  1. 1xx（信息性响应）：请求已被接收，继续处理。
  2. 2xx（成功响应）：请求已成功被服务器接收、理解和处理。
  3. 3xx（重定向）：需要客户端采取进一步操作以完成请求。
  4. 4xx（客户端错误）：请求包含语法错误或无法完成。
  5. 5xx（服务器错误）：服务器在尝试处理请求时遇到错误。

下面是每种类别常见的HTTP状态码：

1xx - 信息性响应

  • 100 Continue：客户端应继续其请求。
  • 101 Switching Protocols：服务器理解并同意客户端升级协议的要求。

2xx - 成功响应

  • 200 OK：标准的成功响应，表示请求已被成功处理。
  • 201 Created：请求成功且服务器创建了一个新的资源。
  • 204 No Content：服务器成功处理了请求，但不需要返回任何实体内容。

3xx - 重定向

  • 301 Moved Permanently：请求的资源已被永久移动到新位置，后续对该资源的请求都应指向给出的新URI。
  • 302 Found：请求的资源临时从不同的URI响应请求。
  • 304 Not Modified：资源未被修改，可以使用缓存的版本。

4xx - 客户端错误

  • 400 Bad Request：由于明显的客户端错误（如请求格式错误），服务器无法处理请求。
  • 401 Unauthorized：请求需要用户验证。
  • 403 Forbidden：服务器理解请求但拒绝执行。
  • 404 Not Found：请求的资源在服务器上不存在。
  • 405 Method Not Allowed：请求方法对指定资源不适用。

5xx - 服务器错误

  • 500 Internal Server Error：服务器遇到了未知情况，阻止了它完成请求。
  • 501 Not Implemented：服务器不具备完成请求的功能。
  • 502 Bad Gateway：作为网关或代理的服务器收到无效响应。
  • 503 Service Unavailable：服务器暂时无法处理请求（可能是过载或维护）。
  • 504 Gateway Timeout：作为网关或代理的服务器未能及时从上游服务器获得响应。

GET与POST

GET和POST的主要区别在于语义：GET用于获取数据，POST用于提交数据

  • GET： 适用于获取数据，如查询、搜索等。 参数暴露在URL中，安全性较低。
  • POST： 适用于提交数据，如表单提交、文件上传等。 参数在请求体中，安全性较高。

1. 语义区别：

  • GET：用于获取数据。请求指定的资源，服务器解析后返回响应内容。
  • POST：用于提交数据。请求服务器处理数据（如提交表单或上传文件），数据包含在请求体中。

2. 请求参数位置

  • GET： 参数通常附加在URL后，使用?分隔URL和参数，参数间用&连接。
    • 例如：/api/data?id=1&name=test
  • POST： 参数通常放在请求体中。例如：{"id": 1, "name": "test"}

注意：HTTP规范并未强制规定参数位置，上述做法是约定俗成的习惯。虽然可以在POST请求中通过URL传递数据，或者在GET请求中将数据放入请求体中，但这不符合常规使用习惯，并可能导致兼容性问题或安全隐患。

3. 浏览器行为

  • GET： URL长度有限制（通常不超过2048字符）。 请求可被缓存和收藏。
  • POST： 无URL长度限制。 请求不会被缓存，通常无法直接收藏。

HTTP工作流程

  1. 域名解析： 用户在浏览器地址栏输入URL后，浏览器首先进行域名解析（依次查询浏览器缓存、操作系统缓存、hosts文件、DNS服务器）。

  2. 建立TCP连接： 浏览器与服务器通过TCP三次握手建立连接。

  3. 生成HTTP请求： 浏览器生成HTTP请求报文，向下经过：

    • 传输层（TCP）：拆包并添加TCP头部。
    • 网络层（IP）：添加IP头部。
    • 链路层：通过网卡发送到网络中。

  4. 请求传输： 数据包在网络中经过多次中转，最终到达服务器。

  5. 服务器处理请求： 服务器接收到数据包后，逐层解析：

    • 网络层（IP）：去掉IP头部。
    • 传输层（TCP）：去掉TCP头部并合并数据包。
    • 应用层（HTTP）：解析HTTP请求报文，识别请求的资源并生成HTTP响应。

  6. 返回HTTP响应：服务器将HTTP响应报文向下经过：

    • 传输层（TCP）：拆包并添加TCP头部。
    • 网络层（IP）：添加IP头部。
    • 链路层：通过网卡发送到网络中。

  7. 响应传输： 数据包在网络中经过多次中转，最终到达客户端。

  8. 客户端接收响应： 客户端接收到数据包后，逐层解析：

    • 网络层（IP）：去掉IP头部。
    • 传输层（TCP）：去掉TCP头部并合并数据包。
    • 应用层（HTTP）：解析HTTP响应报文。

  9. 渲染页面： 浏览器解析HTML内容，若遇到CSS、JS、图片等资源，则再次发起HTTP请求获取资源。 当所有资源加载完成后，浏览器渲染页面并呈现给用户。

HTTP工作流程总结

  1. 域名解析：浏览器解析URL中的域名。
  2. 建立TCP连接：通过三次握手建立连接。
  3. 生成HTTP请求：浏览器生成请求报文，经过TCP、IP、链路层发送。
  4. 请求传输：数据包通过网络传输到服务器。
  5. 服务器处理请求：服务器解析请求并生成响应。
  6. 返回HTTP响应：服务器将响应报文经过TCP、IP、链路层发送。
  7. 响应传输：数据包通过网络传输到客户端。
  8. 客户端接收响应：客户端解析响应报文。
  9. 渲染页面：浏览器解析HTML并加载资源，最终渲染页面。

HTTPS原理及应用

HTTPS协议是HTTP协议的安全版本，它通过在HTTP之上使用SSL/TLS协议来保护通信内容的安全性

HyperText Transfer Protocol Secure

HTTPS（HyperText Transfer Protocol Secure，超文本传输安全协议）是 HTTP（超文本传输协议）与 SSL/TLS（Secure Sockets Layer / Transport Layer Security，安全套接字层/传输层安全协议）相结合的安全通信协议。通过加密和身份认证来确保数据在客户端与服务器之间的安全传输

HTTPS 的主要功能：

  1. 数据加密（Encryption） —— 保护数据不被窃听。
  2. 数据完整性（Integrity） —— 保护数据不被篡改。
  3. 身份认证（Authentication） —— 确保通信双方身份的真实性。

HTTPS报文格式

HTTPS 本质上仍然是 HTTP，但增加了 SSL/TLS 加密层，报文结构与 HTTP 相似，主要区别在于：

  1. 端口号不同：HTTP 使用 80 端口，而 HTTPS 使用 443 端口。
  2. 传输方式不同：
    • HTTP：明文传输，容易被中间人攻击（如窃听、篡改）。
    • HTTPS：使用 SSL/TLS 加密，数据经过加密后传输，确保安全性。
  3. 握手阶段（SSL/TLS Handshake）：
    • HTTP 直接请求-响应。
    • HTTPS 需要先进行 SSL/TLS 握手，协商加密方式，建立安全连接后再传输数据。

HTTPS加密机制

HTTPS 结合了 对称加密（Symmetric Encryption） 和 非对称加密（Asymmetric Encryption），充分利用二者的优点。

对称加密（Symmetric Encryption）：发送方与接收方使用 相同的密钥 进行加密和解密。速度快，适合大数据量传输，但密钥管理复杂。常见算法：

  • AES（Advanced Encryption Standard，高级加密标准）：目前主流对称加密算法。
  • DES（Data Encryption Standard，数据加密标准）：已被认为不安全。
  • 3DES（Triple DES，三重数据加密）：比 DES 安全，但速度慢。

✅ 速度快，适合大数据量传输。
❌ 需要安全管理密钥，密钥泄露后数据易被破解。

在HTTPS中，对称加密主要用于加密大量的数据传输，因为它的速度较快

非对称加密（Asymmetric Encryption）：使用 公钥（Public Key） 进行加密，使用 私钥（Private Key） 进行解密（或者反向操作）。 适用于身份认证、密钥交换，但速度慢。 常见算法：

  • RSA（Rivest-Shamir-Adleman）：常用的非对称加密算法。
  • ECC（Elliptic Curve Cryptography，椭圆曲线密码学）：比 RSA 更高效，适用于移动设备。
  • Diffie-Hellman（DH）：主要用于密钥交换，而非加密。

✅ 密钥管理相对简单，可用于身份认证。
❌ 计算量大，加解密速度慢，不适合大数据量传输。

SSL/TLS握手流程

HTTPS 主要使用 非对称加密传输密钥，然后使用 对称加密传输数据，结合了二者的优点。

  • SSL（Secure Sockets Layer）是早期的安全协议，而TLS（Transport Layer Security）是SSL的后继者，提供了更高级别的安全性

  • TLS 1.3 是 TLS 协议的最新版本，相较于 TLS 1.2，它在性能和安全性方面有显著提升：

    1 更快的访问速度

    • TLS 1.2：需要 2-RTT（两次往返） 完成握手。
    • TLS 1.3：仅需 1-RTT（一次往返） 完成握手，支持 0-RTT 模式，进一步减少延迟。
    • 性能提升：TLS 1.3 的握手时间减半，访问速度更快，尤其对移动端用户友好。

    2 更强的安全性

    • 移除不安全的加密算法：TLS 1.3 删除了 RSA 密钥传输、CBC 模式密码、RC4 流密码、SHA-1 哈希函数等易受攻击的算法。
    • 强制前向安全性：TLS 1.3 仅支持前向安全的密钥交换机制（如 ECDHE）。
    • 减少明文暴露：ServerHello 之后的所有握手消息都加密传输，减少了明文暴露的风险。

    3 简化与优化

    • 废弃不必要功能：TLS 1.3 不再支持重协商、压缩和静态 RSA 密钥交换。
    • 更简洁的协议设计：减少了握手步骤和复杂性，提高了协议的健壮性。
TLS 1.3 握手过程

TLS 1.3 的握手仅需 1-RTT，支持 0-RTT 模式，具体步骤如下：

  1. Client Hello： 客户端发送支持的 TLS 版本、加密套件列表、随机数（Client Random）和密钥共享参数（如 ECDHE 公钥）。
  2. Server Hello：
    • 服务器选择 TLS 版本、加密套件，发送随机数（Server Random）和密钥共享参数。
    • 服务器同时发送数字证书和 Finished 消息。
  3. 客户端验证证书： 客户端验证服务器的数字证书。
  4. 生成主密钥： 客户端和服务器使用 ECDHE 参数生成主密钥（Master Secret）。
  5. Change Cipher Spec： 客户端通知服务器后续消息将使用协商的密钥加密。
  6. Finished： 客户端发送加密的 Finished 消息，验证握手是否成功。

0-RTT 模式

  • 在 0-RTT 模式下，客户端可以在第一次握手时直接发送加密的应用数据，无需等待服务器响应
  • 适用场景：适用于对延迟敏感的应用（如网页加载、API 请求）。

目前，主流浏览器均已支持 TLS 1.3：

  • Chrome：从 Chrome 70 开始默认支持 TLS 1.3。
  • Firefox：从 Firefox 63 开始默认支持 TLS 1.3。
  • Safari：从 Safari 12.1 开始支持 TLS 1.3。
  • Edge：基于 Chromium 的 Edge 浏览器默认支持 TLS 1.3。

总结

  • TLS 1.3 的优势：
    • 更快的握手速度（1-RTT，支持 0-RTT）。
    • 更强的安全性（移除不安全的加密算法，强制前向安全性）。
    • 更简洁的协议设计。
  • TLS 1.2 的局限性：
    • 握手时间较长（2-RTT）。
    • 支持不安全的加密算法（如 RSA 密钥传输、SHA-1）。
  • 未来趋势：
    • TLS 1.3 已成为主流，逐步取代 TLS 1.2。
    • 随着浏览器和服务器对 TLS 1.3 的支持普及，HTTPS 的性能和安全性将进一步提升。

通过对比 TLS 1.2 和 TLS 1.3 的握手过程，可以清晰地看到 TLS 1.3 在性能和安全性上的显著优势。随着互联网安全需求的不断提高，TLS 1.3 将成为 HTTPS 通信的标准协议。

数字证书

为了验证服务器的身份，HTTPS使用数字证书来确保客户端与正确的服务器进行通信。数字证书通常包含以下信息：

  • 服务器的身份信息。
  • 发行该证书的认证机构（CA）。
  • 公钥。
  • 有效期。
  • CA的数字签名。

证书的颁发

证书的颁发

  1. 证书申请：服务器管理员向认证机构（CA）提交证书签名请求（CSR）。
  2. 身份验证：CA验证服务器的身份。
  3. 证书颁发：CA颁发数字证书。
  4. 安装证书：服务器安装证书。

证书链

证书链是指从服务器的证书到信任根证书的一系列证书。客户端可以通过验证证书链中的每个证书的签名来确认最终服务器证书的有效性。

Digital Signature

数字签名（Digital Signature）： 确保 数据完整性 + 身份认证。流程：

  1. 发送方计算消息的哈希值（Message Digest）。
  2. 使用私钥对哈希值进行加密，生成 数字签名。
  3. 接收方用发送方的公钥解密 数字签名，并计算消息的哈希值进行对比，验证消息是否被篡改。

常见算法：

  • RSA 签名
  • ECDSA（基于椭圆曲线的数字签名算法）

完整性校验

HTTPS协议使用消息认证码（MAC）或数字签名来确保数据的完整性和防止中间人攻击。TLS协议使用散列函数来生成MAC，这有助于检测数据在传输过程中是否被篡改。

SHA1
C71D49A6144772F352806201EF564951BE55EDD5

下载完成后务必进行SHA1校验（推荐使用iHasher），与网站核对一致后再使用。

散列函数（Hash Function）：将原始数据转换为固定长度的哈希值（不可逆）。 主要用于 数据完整性校验，防止数据被篡改。 常见算法：

  • MD5（已不安全）
  • SHA-256（Secure Hash Algorithm 256-bit）（主流）
  • SHA-3（更强的哈希算法）

HTTPS内容总结

HTTPS 通过 SSL/TLS 加密、身份认证、完整性校验，大幅提升了 Web 传输的安全性，是现代网络安全通信的基础

  1. 防窃听（Eavesdropping）：数据加密（对称 + 非对称）。
  2. 防篡改（Tampering）：消息摘要（SHA-256）。
  3. 防冒充（Impersonation）：数字签名 + 证书验证。
概念作用核心算法
对称加密保护数据不被窃听AES、DES、3DES
非对称加密主要用于密钥交换、身份认证RSA、ECC、Diffie-Hellman
消息摘要确保数据完整性，防篡改MD5（不安全）、SHA-256
数字签名确保身份真实性 + 数据完整性RSA、ECDSA
SSL/TLS 握手交换密钥，建立安全连接TLS 1.2、TLS 1.3
HTTPS 报文HTTP + SSL/TLS 加密基于 HTTP 结构扩展

更多关于加密的内容参照：密码学合集

HTTPS使用混合加密来结合对称加密和非对称加密的优点。具体流程如下：

  1. 建立连接：客户端向服务器发起HTTPS连接请求。
  2. 交换公钥：服务器将自己的公钥发送给客户端。
  3. 生成会话密钥：客户端使用服务器的公钥加密一个随机生成的对称密钥（会话密钥），然后发送给服务器。
  4. 加密数据传输：服务器收到会话密钥后，使用自己的私钥解密得到会话密钥，之后所有数据都使用这个会话密钥进行对称加密和解密。

HTTPS抓包及解密

HTTPS 虽然通过加密保护了数据传输的安全性，但在某些情况下（如未正确验证证书或密钥泄露），仍然可能被攻击者解密。

  • mitmproxy 是一个强大的工具，用于拦截和修改 HTTP/HTTPS 流量，适合安全测试和调试。
  • Wireshark 结合 SSLKEYLOGFILE 可以解密 HTTPS 流量，用于深度分析网络通信。

mitmproxy 用于拦截和修改流量，适合实时分析和调试。Wireshark 用于深度分析网络流量，结合 SSLKEYLOGFILE 可以解密 HTTPS 流量。两者结合可以更全面地分析网络通信的安全性。

中间人攻击与捕获密钥，参照视频：抓包解密https — mitmproxy与wireshark

  1. 中间人攻击（MITM）简介
    中间人攻击是一种网络攻击方式，攻击者通过拦截通信双方的流量，窃取或篡改数据。
  1. 利用 mitmproxy 进行中间人攻击

mitmproxy 是一个强大的开源工具，支持 HTTP 和 HTTPS 流量的拦截、修改和重放。以下是使用 mitmproxy 进行中间人攻击的步骤：

2.1 安装 mitmproxy

  • 通过 pip 安装：
    pip install mitmproxy
  • 或者从 mitmproxy 官网 下载适合操作系统的版本。

2.2 启动 mitmproxy

  • 在终端运行以下命令启动 mitmproxy：
    mitmproxy
  • 默认监听端口为 8080。

2.3 配置客户端代理

  • 在需要监控的设备或浏览器上，设置代理服务器为运行 mitmproxy 的机器 IP 地址及端口（如 192.168.1.100:8080）。

2.4 安装 mitmproxy 根证书

  • 为了解密 HTTPS 流量，客户端需要信任 mitmproxy 的根证书。
  • 在客户端浏览器中访问 http://mitm.it/，下载并安装适合操作系统的根证书。
  • 安装完成后，mitmproxy 可以解密并查看 HTTPS 请求的内容。

2.5 拦截和查看流量

  • 启动 mitmproxy 后，所有经过代理的 HTTP/HTTPS 流量都会显示在 mitmproxy 的交互界面中。
  • 可以查看请求和响应的详细信息，甚至修改数据包。
  1. 使用 Wireshark 捕获和解密 HTTPS 流量

Wireshark 是一个网络协议分析工具，可以捕获和分析网络流量。结合 SSLKEYLOGFILE，Wireshark 可以解密 HTTPS 流量。

3.1 启用 SSLKEYLOGFILE

  • SSLKEYLOGFILE 是一个环境变量，用于导出 TLS 会话密钥。
  • 在启动目标应用程序（如浏览器）之前，设置环境变量：
    • Windows：
      set SSLKEYLOGFILE=C:\path\to\sslkeylog.log
    • Linux/macOS：
      export SSLKEYLOGFILE=/path/to/sslkeylog.log
  • 确保目标应用程序重启后生效。

3.2 配置 Wireshark

  1. 打开 Wireshark，进入 Edit -> Preferences -> Protocols -> TLS。
  2. 在 (Pre)-Master-Secret log filename 选项中，浏览并选择刚才设置的 SSLKEYLOGFILE 路径。
  3. 应用更改后，Wireshark 将使用日志文件中的密钥解密捕获的 TLS 流量。

3.3 捕获和解密流量

  • 启动 Wireshark，选择需要捕获的网络接口。
  • 开始捕获流量，Wireshark 会自动解密 HTTPS 流量（前提是 SSLKEYLOGFILE 已正确配置）。

注意事项

  • 证书验证：确保客户端正确验证服务器证书，避免中间人攻击。
  • 密钥保护：SSLKEYLOGFILE 包含敏感信息，需妥善保管，防止泄露。
Default footer
Copyright © 2025 ventixy