http相关技术总结

一、状态码

1.1 常见的 HTTP 状态码以及代表的意义

200 OK: 请求成功，服务器成功处理了请求。
201 Created: 请求已成功，并在服务器上创建了新的资源。
204 No Content: 服务器成功处理了请求，但没有返回任何内容。
400 Bad Request: 服务器无法理解请求的语法，请求有语法错误。
401 Unauthorized: 请求需要用户身份验证。
403 Forbidden: 服务器拒绝请求，没有权限访问。
404 Not Found: 请求的资源不存在。
405 Method Not Allowed: 请求方法不被允许。
500 Internal Server Error: 服务器内部错误，无法完成请求。
502 Bad Gateway: 服务器作为网关或代理，从上游服务器收到无效响应。
503 Service Unavailable: 服务器当前无法处理请求，通常由于过载或维护。

1.2 网络状态 301、302、303 有何区别？

• HTTP状态码301：永久重定向。表示请求的资源已被永久移动到新的位置，将来任何新的请求都应使用新的URL。大多数浏览器会缓存这个重定向的URL，所以在下次访问旧的URL时，浏览器会直接跳转到新的URL，而不会再向服务器请求。
• HTTP状态码302：临时重定向。表示请求的资源临时移动到新的位置，但未来的请求仍应使用原始的URL。浏览器通常不会缓存这个重定向的URL，所以每次访问旧的URL时，都会向服务器请求，然后服务器再返回新的URL。
• HTTP状态码303：查看其他位置。表示请求的资源存在于另一个URL，应使用GET方法获取。这个状态码主要用于在执行POST、PUT等可能引起服务器状态变化的操作后，将客户端重定向到一个新的资源，避免用户刷新或重复提交表单。

1.3 网络状态 400、401、403 有何区别？

• 400 Bad Request

  • 状态码说明：HTTP状态码400表示客户端发出的请求有语法错误，服务器无法理解或处理该请求。这可能是由于请求中的参数不正确、格式错误或其他语法问题导致的。
  • 常见原因：用户提供的数据格式不正确，请求缺少必需的参数，或请求中包含无效的字符等。
  • 示例情况：如果客户端发送的JSON请求格式不合法，服务器可能会返回400状态码来表示请求不符合预期的语法。

• 401 Unauthorized

  • 状态码说明：HTTP状态码401表示客户端的请求需要身份验证，但未提供有效的身份验证信息。这意味着客户端没有足够的权限来访问请求的资源，需要提供有效的凭证。
  • 常见原因：客户端未提供或提供了无效的身份验证令牌、用户名和密码等。
  • 示例情况：当尝试访问需要登录的Web页面或API端点时，服务器可能会返回401状态码，要求客户端提供有效的身份验证信息，如用户名和密码或访问令牌。

• 403 Forbidden

  • 状态码说明：HTTP状态码403表示服务器理解了请求，但拒绝了请求，因为客户端没有访问所请求资源的权限。与401状态码不同，403状态码表示客户端已经提供了身份验证信息，但服务器拒绝了访问请求。
  • 常见原因：服务器认为客户端没有足够的权限来访问请求的资源，或者请求的资源被服务器配置为禁止访问。
  • 示例情况：如果用户尝试访问受限资源，而其权限不足以访问该资源，服务器可能会返回403状态码。

二、http和https的区别

主要的区别在于安全性和数据传输方式上，HTTPS比HTTP更加安全，适合用于保护网站用户的隐私和安全，如银行网站、电子商务网站等。

• 安全性：HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输的数据可以被任何抓包工具截取并查看。而HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，更为安全。
• 数据传输方式：HTTP协议的端口号是80，HTTPS协议的端口号是443。
• 网址导航栏显示：使用HTTP协议的网站导航栏显示的是"http://“，而使用HTTPS协议的网站导航栏显示的是"https://”。
• 证书：HTTPS需要到CA申请证书，一般免费证书较少，因而需要一定费用。
• 网络速度：HTTP协议比HTTPS协议快，因为HTTPS协议需要进行加密和解密的过程。
• SEO优化：搜索引擎更倾向于把HTTPS网站排在更前面的位置，因为HTTPS更安全。

三、https加密全过程

• 客户端发起请求：客户端向服务器的443端口发起连接请求。
• 服务器响应并发送证书和随机数：服务器收到请求后，会返回其数字证书（包含公钥）以及一个随机生成的字符串（server-random）给客户端。这个证书用于验证服务器的身份，并且公钥将用于后续的加密操作。
• 客户端验证证书并生成随机数：客户端收到证书后，会验证证书的有效性和可信度，如果证书有效，则生成另一个随机字符串（client-random）。
• 生成premastersecret：客户端结合client-random和server-random生成一个premastersecret，这是一个临时密钥，用于后续的加密操作。
• 公钥加密premastersecret：客户端使用服务器的公钥对premastersecret进行加密，然后将加密后的数据发送给服务器。
• 服务器解密premastersecret：服务器收到加密的premastersecret后，使用自己的私钥进行解密，得到原始的premastersecret。
• 生成mastersecret并建立加密通道：客户端和服务器分别使用相同的算法，结合client-random、server-random和premastersecret生成最终的mastersecret。这个mastersecret将用于后续的数据传输加密。
  

四、HTTP/1.0、HTTP/1.1、HTTP/2.0、HTTP3.0的区别

HTTP/1.0

背景

• 发布于1996年5月。
• 当时的互联网环境相对简单，网页内容主要是文本，没有复杂的图片、视频等资源。

核心特点

1. 短连接（无持久连接）：

   • 每个请求都需要建立一个新的TCP连接，数据传输完成后立即断开。
   • 由于TCP连接需要三次握手建立和四次挥手释放，频繁的连接建立和关闭增加了额外的延迟。

2. 单次请求/响应模式：

   • 每个TCP连接只能发送一个请求并接收一个响应，无法复用。

3. 性能限制：

   • 对于现代网页来说，加载多个资源（如图片、CSS、JS文件）时，HTTP/1.0的效率非常低。

存在的问题

• 高延迟：每个资源都需要单独的TCP连接，导致大量的连接开销。
• 缺乏缓存控制：虽然支持基本的缓存机制（如Expires），但功能有限，难以满足现代需求。

HTTP/1.1

背景

• 发布于1997年，并在后续进行了多次更新。
• 随着网页复杂度的增加，HTTP/1.1引入了多项改进来提升性能和灵活性。

核心特点

1. 持久连接（Keep-Alive）：

   • 允许同一个TCP连接处理多个请求/响应对，减少了连接建立和关闭的开销。
   • 默认情况下，所有请求都使用同一个连接。

2. 管道化（Pipelining）：

   • 客户端可以在不等待前一个请求响应的情况下发送多个请求。
   • 服务器按顺序返回响应，避免了客户端混淆响应与请求的情况。
   • 队头阻塞（Head-of-Line Blocking）：如果某个请求处理时间较长，后面的请求会排队等待，影响整体性能。

3. 增强的缓存控制：

   • 引入了Cache-Control头部字段，提供了更细粒度的缓存策略。
   • 使用ETag和If-None-Match代替Last-Modified和If-Modified-Since，提高了缓存验证的准确性。

4. 分块传输编码（Chunked Transfer Encoding）：

   • 支持动态生成的内容，允许服务器在不知道总长度的情况下开始传输数据。
   • 数据被分割成小块进行传输，每一块都有自己的大小标识。

存在的问题

• 队头阻塞：管道机制虽然可以同时发送多个请求，但由于响应必须按顺序返回，因此存在性能瓶颈。
• 请求/响应顺序依赖：客户端需要等待前面的响应完成才能正确处理后续的响应。

HTTP/2.0

背景

• 发布于2015年，基于Google开发的SPDY协议。
• 主要目标是解决HTTP/1.1中性能瓶颈，尤其是减少延迟。

核心特点

1. 二进制帧（Binary Framing Layer）：

   • 所有数据都被分割为二进制格式的帧，分为不同类型（如HEADERS帧、DATA帧等）。
   • 帧通过流（Stream）进行管理，每个流对应一个请求/响应对。

2. 多路复用（Multiplexing）：

   • 同一个TCP连接可以并发处理多个请求/响应，而不需要等待前面的请求完成。
   • 流（Stream）的概念使得不同请求之间互不干扰，通过唯一的流ID区分不同的请求/响应。

3. 头部压缩（HPACK算法）：

   • 使用静态表和动态表存储常见的头部字段，减少重复传输的数据量。
   • 头部信息通过索引号或哈夫曼编码进行压缩，进一步降低带宽占用。

4. 服务器推送（Server Push）：

   • 服务器可以主动向客户端推送资源，而无需等待客户端显式请求。
   • 例如，当客户端请求HTML页面时，服务器可以提前推送该页面所需的CSS和JS文件。

5. 流量控制与优先级：

   • 支持流级别的流量控制，确保高优先级的请求能够更快地得到响应。
   • 通过优先级设置，优化用户体验。

存在的问题

• 底层TCP的队头阻塞：虽然解决了HTTP层面的队头阻塞问题，但如果底层TCP出现丢包，仍然会导致整个连接上的所有流受到影响。

HTTP/3.0

背景

• 发布于2022年，基于Google开发的QUIC协议。
• HTTP/3的目标是彻底解决TCP带来的性能瓶颈，尤其是在移动网络环境下。

核心特点

1. 采用UDP作为传输层协议：

   • UDP是无连接的，具有更低的延迟特性。
   • 不再依赖TCP的可靠传输机制，而是将可靠性移到应用层。

2. 完全解决队头阻塞问题：

   • 在HTTP/2中，虽然HTTP层面的队头阻塞得到了缓解，但TCP层面的队头阻塞依然存在。
   • HTTP/3通过基于UDP的QUIC协议实现了真正的多路复用，每个流独立传输，即使某个流发生丢包，也不会影响其他流。

3. 快速连接建立：

   • QUIC支持0-RTT（Round-Trip Time）连接建立，即客户端可以直接发送加密后的数据，而不需要等待服务器的确认。
   • 这大大缩短了连接建立的时间。

4. 内置加密和安全机制：

   • QUIC集成了TLS 1.3，所有的数据传输都是加密的，提供端到端的安全性。
   • 不需要额外的HTTPS配置，直接通过HTTP/3即可实现安全通信。

5. 改进的拥塞控制：

   • QUIC实现了更灵活的拥塞控制算法，适应不同的网络环境。
   • 支持快速恢复机制，减少因丢包而导致的性能下降。

6. 高效的重传机制：

   • 通过独立的流管理，丢失的数据包只会影响对应的流，不会导致整个连接的阻塞。

存在的问题

• 部署成本较高：由于HTTP/3需要全新的传输协议栈（基于UDP），服务器和客户端都需要支持QUIC协议。
• 兼容性问题：并非所有设备和网络都支持HTTP/3，部分老旧系统可能需要回退到HTTP/2或HTTP/1.1。

五、HTTP 缓存作用

HTTP 缓存是一种优化网络请求性能的重要机制，通过在客户端（如浏览器）或中间代理服务器中缓存资源副本，减少重复请求和数据传输，从而加快页面加载速度、降低服务器负载，并节省带宽。

5.1 HTTP 缓存的作用

1. 减少网络请求次数：避免每次访问都向服务器重新请求相同的资源。
2. 提升页面加载速度：直接从本地缓存加载资源比从服务器获取更快。
3. 减轻服务器压力：服务器不需要重复处理相同的请求。
4. 节省带宽成本：尤其适用于移动设备和带宽受限的场景。

5.2 HTTP 缓存的分类

HTTP 缓存主要分为两类：强制缓存和协商缓存

5.2.1 强制缓存（强缓存）

• 客户端根据响应头中的字段判断是否可以直接使用本地缓存，无需发送请求到服务器。
• 主要依赖的头部字段：
  • Cache-Control
  • Expires（已逐渐被 Cache-Control 取代）

 示例：
Cache-Control: max-age=3600  // 表示该资源在3600秒（1小时）内可以直接使用缓存，而不需要发起请求。

5.2.2 协商缓存（对比缓存)

• 当强缓存失效后，客户端会向服务器发送请求，询问资源是否有更新。
• 如果资源未改变，服务器返回 304 Not Modified，客户端继续使用缓存。
• 主要依赖的头部字段：
  • ETag / If-Match
  • Last-Modified / If-Modified-Since

示例：
ETag: "abc123"
Last-Modified: Tue, 15 Jun 2025 12:00:00 GMT

客户端下次请求时携带：

If-None-Match: "abc123"
If-Modified-Since: Tue, 15 Jun 2025 12:00:00 GMT

如果资源没有变化，服务器返回 304 Not Modified，否则返回新的资源内容。

5.3 缓存控制头详解

5.3.1 Cache-Control

这是 HTTP/1.1 中最重要的缓存控制头，功能强大且灵活。常用指令如下：

5.3.2 Expires

用于指定一个绝对时间点，在此时间之前缓存有效。由于它依赖的是客户端的时间，容易因时间不一致导致错误，因此推荐优先使用 Cache-Control。

示例：
Expires: Wed, 17 Jun 2025 12:00:00 GMT

5.4 缓存流程图（简化版）

5.5 HTTP 缓存常见问题

5.5.1 缓存污染（Stale Content）

• 问题：浏览器缓存了一个旧版本的文件，即使服务器已经更新，用户仍然看到旧内容。
• 解决方案：
  • 给静态资源添加哈希值作为查询参数或文件名（如 style.abc123.css）。
  • 设置合理的 Cache-Control 时间。

5.5.2 跨域缓存问题

• 默认情况下，浏览器不会缓存跨域请求（除非响应头中有 Vary: Origin 并设置了合适的缓存头）。
• 解决方法：服务器正确配置缓存头和 Vary 字段。

5.5.3 隐私泄露风险

• 某些敏感信息（如用户身份 token）如果被缓存，可能造成安全风险。
• 解决方法：使用 Cache-Control: private 或 no-store 来限制缓存行为。