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

#http #计算机网络

目录

1. websocket 与 HTTP 的区别

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

2. 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是有解的
      • 图片&文件

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

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

3.1. 基于 QUIC 的设计

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

3.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: ...          // 实际数据
   }

3.3. 具体工作机制

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

3.4. 优势体现

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

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

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

3.6. 与 HTTP/2 的对比

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

3.7. 额外优化

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

4. 请简述 QUIC

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

4.1. 基础架构

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

4.2. 核心特性

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

4.3. 多路复用优势

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

4.4. 安全特性

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

4.5. 性能优化

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

4.6. 实际应用优势

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

4.7. 与传统协议的区别

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

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

5. 请简述 HTTPS 协议

图片&文件

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

6. 简述网络七层协议

图片&文件

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

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

图片&文件

8. 三次握手与四次挥手

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

9. HTTP 协议的理解

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

10. 常见的 HTTP 请求

图片&文件

11. 简述 HTTP 内容协商

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

12. HTTP 缓存机制

图片&文件

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

13.1. 根本原因

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

13.2. 阻塞过程

  1. 数据包丢失场景
TCP 数据流：
[包1] [包2] [包3] [包4] [包5]
         ↓ (丢失)
[包1] [空缺] [包3] [包4] [包5]
  1. 阻塞影响
    • 包2丢失后，包3、4、5虽然已到达
    • 但==由于 TCP 的顺序保证，这些包无法上交给应用层==
    • 导致所有 HTTP/2 流都被阻塞，直到包2重传成功

13.3. 具体影响

  1. 多路复用的限制

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

  2. 性能影响

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

13.4. 解决方案

  1. HTTP/3 和 QUIC

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

  2. 优化建议

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

13.5. 为什么这是个问题？

  1. TCP 设计理念

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

  2. 现代网络特点

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

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

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