关于HTTP 的一些常见问题汇总

#http #计算机网络

目录

• 1. 总结
• 2. websocket 与 HTTP 的区别
• 3. http1.0 、http1.1、https、http2 、 http3 的区别
• 4. HTTP/3.0 如何解决队头阻塞问题
  • 4.1. 基于 QUIC 的设计
  • 4.2. 独立的流处理
  • 4.3. 具体工作机制
  • 4.4. 优势体现
  • 4.5. 实际应用场景： 假设一个网页同时加载多个资源
  • 4.6. 与 HTTP/2 的对比
  • 4.7. 额外优化
• 5. 请简述 QUIC
  • 5.1. 基础架构
  • 5.2. 核心特性
  • 5.3. 多路复用优势
  • 5.4. 安全特性
  • 5.5. 性能优化
  • 5.6. 实际应用优势
  • 5.7. 与传统协议的区别
• 6. HTTPS 协议
• 7. 网络七层协议
• 8. tcp 怎么在不可靠的传输上保证可靠 的
• 9. 三次握手与四次挥手
• 10. HTTP 协议的理解
• 11. 常见的 HTTP 请求
• 12. 简述 HTTP 内容协商
• 13. HTTP 缓存机制
• 14. 为什么 HTTP2 下，一个 TCP 包丢失会阻塞所有流
  • 14.1. 根本原因
  • 14.2. 阻塞过程
  • 14.3. 具体影响
  • 14.4. 解决方案
  • 14.5. 为什么这是个问题？

1. 总结

• HTTP 内容协商
• ws(s) 和 HTTP(S) 区别？
• http1.0 ：串行
• http1.1
  • HTTP重用TCP 连接，省去三次握手的开销
  • 支持pipeline网络传输，即
    • 客户端可以连续发送多个请求，而不需要等待服务器的响应
  • 主要问题：对头阻塞
• http2.0
  • 多路复用：在同一个 TCP 连接中，可以同时发送和接收多个 HTTP 请求/响应
  • 二进制分帧：每个帧都带有标识，表明属于哪个请求
  • 对头阻塞：本质还是因为 TCP
    • TCP 使用序列号确保数据包的有序传输，丢了，即使后续包已到达，**也必须等待丢失包重传后才能交付给应用层
• HTTP3
  • QUIC（Quick UDP Internet Connections）
    • 建立在 UDP 之上的传输层协议，它解决了 UDP 的不可靠性
• 三次握手四次挥手
• HTTP 缓存的几个头
• HTTPS
  • 加密机制：
    • 使用非对称加密（公钥/私钥）建立初始连接
    • 使用对称加密进行实际数据传输
  • 证书流程验证
    • 

2. websocket 与 HTTP 的区别

• 连接方式
  • ws：长连接、有状态
  • http：短连接、无状态
• 都基于 TCP，都使用 res/req 模型
• wss 与 https
• 传递方式：
  • http：文本
  • http2：二进制
  • ws： 协议帧
• ws 使用 HTTP 建立连接，如下图
  • 

3. http1.0 、http1.1、https、http2 、 http3 的区别

• HTTP1.0
  • 每个请求都需要建立 TCP 连接
  • 都是串行请求
  • 是一个必须被淘汰的协议
• HTTP 1.1
  • 可以设置 keepalive 来让HTTP重用TCP链接，即所谓的 HTTP 长连接，省去三次握手的巨大开销
  • 支持pipeline网络传输，即
    • 客户端可以连续发送多个请求，而不需要等待服务器的响应。
    • 服务器必须按照接收请求的顺序返回响应。
    • 所有的请求和响应都通过同一个 TCP 连接传输
    • pipeline 的对头阻塞问题
      • 
• HTTP 2.0
  • 支持服务端 push
  • 二进制分帧协议
  • 多路复用
    • 在同一个 TCP 连接中，可以同时发送和接收多个 HTTP 请求/响应。
    • 所有请求都是并行的，不需要按顺序等待
    • 工作原理
      • 请求被分成小的数据帧
      • 每个帧都带有标识，表明属于哪个请求
      • 服务器可以同时处理这些帧，并以任意顺序返回
      • 客户端根据标识重组这些帧
  • 二进制的流与帧
    • 
  • HTTP 2.0 的 队头阻塞（Head-of-Line Blocking）问题
    • 问题原因：
      • 虽然 HTTP/2 在应用层实现了多路复用，但它仍然依赖于 TCP 这个可靠的传输层协议，并且 HTTP/2 的多路复用建立在单个 TCP 连接之上
      • 当 TCP 丢包时，整个 TCP 流都会暂停，等待丢失的包被重传
      • 这意味着所有的 HTTP/2 流都会被阻塞，即使它们是相互独立的
• HTTP 3.0
  • 无论 http1.0 的 pipleine 和 http2.0 的多路复用，都会出现 队头阻塞
  • 因为 TCP 是无解了，但是UDP是有解的
    • 

4. HTTP/3.0 如何解决队头阻塞问题

HTTP/3.0 通过以下几个关键机制解决了队头阻塞问题：

4.1. 基于 QUIC 的设计

• HTTP/3 完全基于 QUIC 协议，而不是 TCP
• QUIC 是建立在 UDP 之上的传输层协议
• 这使得协议能够实现真正的多路复用，每个流都是完全独立的
  • 每个 Stream 都是独立的，一个 Stream 的问题不会影响其他 Stream，如下图
  • 

4.2. 独立的流处理

• 每个 HTTP 请求都在独立的 QUIC 流中处理
• 一个流的包丢失只会影响该流，不会影响其他流
• 数据可以按任意顺序到达，不需要严格排序

1. 多路复用机制：
   - 每个请求都在独立的QUIC Stream中传输
   - Stream之间互不影响
   - 每个Stream都有自己的流控制
2. 包处理机制：
   QUIC Packet Header {
     Connection ID: 0x1234...  // 连接标识
     Packet Number: 1          // 包序号
     Stream ID: 1             // 流标识
     Offset: 0               // 数据偏移量
     Length: 1000           // 数据长度
     Payload: ...          // 实际数据
   }

4.3. 具体工作机制

• 当发生丢包时，只有丢包的那个特定流会等待重传
• 其他流可以继续正常传输数据
• 每个流都有自己的流控制和拥塞控制机制

4.4. 优势体现

• 在高丢包率的网络环境下性能更好
• 特别适合移动网络等不稳定的网络环境
• 显著减少了整体的延迟时间

4.5. 实际应用场景： 假设一个网页同时加载多个资源

• 图片流丢包 → 只影响该图片的加载
• CSS 文件继续正常加载
• JavaScript 文件继续正常加载
• HTML 内容继续正常传输

4.6. 与 HTTP/2 的对比

• HTTP/2：一个 TCP 包丢失会阻塞所有流
• HTTP/3：一个包丢失只影响相关的单个流
• 这种差异在高延迟或不稳定的网络中特别明显

4.7. 额外优化

• 0-RTT 连接建立
• 改进的拥塞控制
• 连接迁移支持（比如从 WiFi 切换到 4G 时保持连接

5. 请简述 QUIC

QUIC（Quick UDP Internet Connections）是一个建立在 UDP 之上的传输层协议，它解决了 UDP 的不可靠性

5.1. 基础架构

• 基于 UDP 构建，但提供了类似 TCP 的可靠性
• 将传输层和加密层合二为一
• 在应用层实现了拥塞控制和可靠传输

5.2. 核心特性

• 0-RTT 连接建立：在已知服务器的情况下，可以立即发送数据
• 内置加密：所有 QUIC 数据都默认加密，使用 TLS 1.3
• 连接迁移：支持网络切换（如从 WiFi 切换到 4G）而保持连接

5.3. 多路复用优势

• 独立的流处理：每个流都是独立的，避免队头阻塞
• 并行传输：多个流可以同时传输数据
• 灵活的流控制：每个流都有自己的流控制机制

5.4. 安全特性

• 所有数据强制加密
• 加密和传输协议集成
• 更好的隐私保护：减少了明文元数据

5.5. 性能优化

• 快速握手：减少连接建立时间
• 改进的拥塞控制
• 更好的丢包恢复机制

5.6. 实际应用优势

• 减少延迟：特别是在建立连接时
• 更好的移动支持：支持网络切换，提高移动场景下的性能
• 更好的流媒体和实时通信支持
• 改进的安全性：默认加密所有通信
• 提高可靠性：特别是在不稳定的网络环境下

5.7. 与传统协议的区别

• TCP：严格的顺序传输，存在队头阻塞
• QUIC：灵活的数据传输，避免队头阻塞
• UDP：不可靠传输
• QUIC：在 UDP 之上构建可靠传输

QUIC 协议的这些特性使它特别适合现代互联网应用，尤其是在移动网络环境下。它已经成为 HTTP/3 的基础，并且正在被越来越多的大型网站和服务采用。

6. HTTPS 协议

• 证书机制：
  • 网站需要获取 SSL/TLS 证书
  • 证书包含网站的公钥和身份信息
  • 由可信的证书颁发机构（CA）签发
• 加密机制：
  • 使用非对称加密（公钥/私钥）建立初始连接
  • 使用对称加密进行实际数据传输
  • 结合两种加密方式的优势
• 通信过程
  • 客户端发起 HTTPS 请求
  • 服务器发送 SSL 证书
  • 验证证书并交换密钥
  • 建立加密通信通道
  • 安全传输数据
• 两个阶段：
  • ① 证书验证
    • 三方 CA 证书认证
  • ② 数据传输
    • 非对称加密：需要产出 客户端和服务端共享的 随机码 key ，用于下面的对称加密
      • 
    • 对称加密
      • 服务端和客户端共享 随机码 key ，分别用它加密和解密

7. 网络七层协议

8. tcp 怎么在不可靠的传输上保证可靠 的

其实就是位置标记 ，他可以标记位置

9. 三次握手与四次挥手

• 一个用于连接，一个用于关闭
• 连接三次握手的必要性
  • 确认双方的收发能力
    • 第一次握手：表明客户端有发送能力
    • 第二次握手：表明服务器有接收和发送能力
    • 第三次握手：表明客户端有接收能力
  • 防止历史连接的建立
  • 同步双方的初始序列号
• 关闭四次挥手的必要性
  • 确保数据完整传输
    • 第一次挥手：表示客户端不再发送数据， 但仍可接收数据
    • 第二次挥手：表示服务器知道客户端不再发送数据
    • 第三次挥手：表示服务器数据发送完毕，准备关闭连接
    • 第四次挥手：确认收到服务器的 FIN，客户端发送 ACK 包，进入 TIME_WAIT 状态
  • 支持半关闭
  • 处理延迟和重传
  • 防止旧连接干扰

10. HTTP 协议的理解

HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

11. 常见的 HTTP 请求

12. 简述 HTTP 内容协商

根据请求中的所有信息，服务器可以有不同响应

13. HTTP 缓存机制

14. 为什么 HTTP2 下，一个 TCP 包丢失会阻塞所有流

14.1. 根本原因

1. TCP 的可靠性机制
   • TCP 使用序列号确保数据包的有序传输
   • 当一个包丢失时，接收方会等待该包重传
   • 即使后续包已到达，也必须等待丢失包重传后才能交付给应用层
2. HTTP/2 的多路复用
   • HTTP/2 在单个 TCP 连接上复用多个流
   • 所有流的数据都被序列化到同一个 TCP 连接中
   • 不同流的数据帧交错传输

14.2. 阻塞过程

1. 数据包丢失场景

TCP 数据流：
[包1] [包2] [包3] [包4] [包5]
         ↓ (丢失)
[包1] [空缺] [包3] [包4] [包5]

2. 阻塞影响
   • 包2丢失后，包3、4、5虽然已到达
   • 但由于 TCP 的顺序保证，这些包无法上交给应用层
   • 导致所有 HTTP/2 流都被阻塞，直到包2重传成功

14.3. 具体影响

1. 多路复用的限制

   • 虽然 HTTP/2 解决了应用层的队头阻塞
   • 但将问题转移到了传输层
   • 一个包的丢失会影响所有并行的 HTTP 请求

2. 性能影响

   • 在高丢包率的网络环境下性能下降明显
   • 重传延迟会导致所有流的延迟增加
   • 特别是在移动网络等不稳定环境中问题更突出

14.4. 解决方案

1. HTTP/3 和 QUIC

   • 基于 UDP 实现可靠传输
   • 每个流独立处理丢包
   • 一个流的包丢失不会影响其他流

2. 优化建议

   • 在高丢包环境下考虑使用多个 TCP 连接
   • 合理设置 TCP 重传超时时间
   • 考虑启用 TCP BBR 等现代拥塞控制算法

14.5. 为什么这是个问题？

1. TCP 设计理念

   • TCP 设计初衷是提供可靠的字节流服务
   • 严格的顺序保证是其核心特性
   • 这与 HTTP/2 的并行传输需求存在冲突

2. 现代网络特点

   • 互联网环境复杂多变
   • 移动网络丢包率相对较高
   • 延迟敏感的应用越来越多

这就是为什么在 HTTP/3 中，通过使用 QUIC 协议（基于 UDP）来解决这个问题。

QUIC 将可靠性控制从传输层移到应用层，允许更灵活的包处理策略，从而避免了 TCP 层面的队头阻塞问题。