前端面试闯关记--http

加油同学
130 阅读11分钟

计算机网络层级

OSI七层

全称：Open Systems Interconnection Reference Model 开放式系统互联通信参考模型

‌物理层 -> ‌数据链路层 -> ‌网络层（IP、ICMP） -> ‌传输层(TCP、UDP) -> 会话层 -> 表示层(HTTPS中的TLS加密实现‌) -> 应用层（HTTP、SMTP、DNS）

什么是http

HTTP（Hypertext Transfer Protocol） ，即超文本传输协议，是一种基于请求和响应的协议，主要用于在Web浏览器和服务器之间传输超文本数据。 属于应用层。

HTTP是无状态的，这意味着每次请求都是独立的，服务器不会记住之前的请求信息。虽然无状态提高了性能和灵活性，但在开发时常需要引入Session和Token来维持状态。

为什么是3次握手？

TCP连接的建立采用三次握手机制：建立一个TCP连接时，需要客户端和服务器端总共发送3个包。

三次握手的目的是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。在socket编程中，客户端执行connect()时将触发三次握手。

  • 第一次握手： 客户端发送SYN包（SYN=1，Seq=x）到服务器，表示请求建立连接。

    客户端发送一个TCP的SYN标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号X，保存在包头的序列号（Sequence Number）字段里。

  • 第二次握手： 服务器收到SYN包后，返回一个SYN ACK包（SYN=1，ACK=1，Seq=y，Ack=x+1），表示同意连接。

    服务器发回确认包（ACK）应答。即SYN标志位和ACK标志位均为1。服务器端选择自己的ISN序列号，放在seq域里，同时将确认序号（Acknowledgement Number）设置为客户的ISN加1，即X+1。发送完毕后，服务器端进入SYN_RCVD状态。

  • 第三次握手： 客户端收到服务器的响应后，再次发送一个ACK包（ACK=1，Seq=x+1，Ack=y+1），连接建立成功。

    客户端再次发送确认包（ACK），SYN标志位为0，ACK标志位为1，并且把服务器发来ACK的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1。
    发送完毕后，客户端进入ESTABLISHED状态，当服务器端收到这个包时，也进入ESTABLISHED状态，TCP握手结束，TCP连接建立完成。

为什么需要三次握手？

三次握手的核心目的在于确认通信双方的接收和发送能力。

  • 第一次握手：客户端确认自己能发送，服务器能接收。
  • 第二次握手：服务器确认自己能发送，客户端能接收。
  • 第三次握手：客户端再次确认，确保双向通信没有问题。

如果只进行两次握手，服务器无法确认客户端是否能正确接收数据，因此必须进行三次握手。

http缓存

HTTP缓存分为强缓存和协商缓存。

强缓存

强缓存表示在有效期内，浏览器无需向服务器发送请求，直接使用本地缓存。
常见的控制头有：

  • Expires：表示缓存过期时间，使用的是绝对时间。
  • Cache-Control：使用相对时间，如 max-age=3600，表示缓存有效期为1小时。

协商缓存

当强缓存失效时，浏览器通过协商缓存来决定是否重新获取资源。
常见的控制头有：

  • Last-Modified 和 If-Modified-Since：通过文件修改时间来判断是否更新。
  • ETag 和 If-None-Match：通过文件指纹（哈希值）来校验文件是否变化。

缓存的优先级

Cache-Control > Expires > ETag > Last-Modified

缓存与状态码

‌200 OK (from cache) ‌

  • ‌触发场景‌：强制缓存生效时返回

  • ‌特征说明‌：

    • 客户端直接复用本地缓存，‌不向服务器发送请求‌‌

    • 响应头包含 Cache-Control 或 Expires 字段定义缓存策略‌

    • 显示形式包括：

      • 200 (from memory cache)：内存缓存（高频访问资源）
      • 200 (from disk cache)：磁盘缓存（低频大文件）‌

304 Not Modified‌

  • ‌触发场景‌：协商缓存生效时返回

  • ‌工作流程‌：

    1. 客户端发送携带 If-Modified-Since（基于时间戳）或 If-None-Match（基于ETag）的请求‌

    2. 服务器比对资源修改状态：

      • 未修改 → 返回 304 并复用本地缓存
      • 已修改 → 返回 200 及新资源‌

  • ‌性能优势‌：减少约60%的带宽消耗（仅传输头信息）‌

206 Partial Content‌

  • ‌缓存关联‌：支持断点续传与分块下载
  • ‌典型场景‌：视频播放器分段加载时，响应头包含 Content-Range 指定数据范围‌78

301 Moved Permanently / 302 Found‌

  • ‌缓存影响‌：

    • 301 永久重定向会被浏览器缓存（后续请求直接跳转新URL）‌
    • 302 临时重定向不缓存，每次需重新验证‌8

4xx/5xx 系列状态码‌

  • ‌缓存策略‌：

    • 403 Forbidden / 404 Not Found → 不缓存，每次重新请求‌
    • 500 Internal Server Error → 客户端可能短暂缓存错误状态（需配置 Retry-After 头控制

为什么有https

HTTP是明文传输，存在严重的安全隐患，如：

  • 中间人攻击：攻击者劫持传输数据并篡改。
  • 窃听：攻击者可以直接读取传输内容。

HTTPS（HTTP Secure）通过SSL/TLS加密来解决这些问题，确保通信的机密性、完整性和身份验证。

SSL/TLS

  • SSL‌（Secure Sockets Layer）：已淘汰的早期加密协议（SSL 3.0于2015年正式弃用）
  • ‌TLS‌（Transport Layer Security）：SSL的继承者，当前最新版本为TLS 1.3（支持0-RTT特性）‌

RTT定义

  • 1-RTT‌：完成完整加密握手需要1次网络往返（客户端与服务端各发送1次数据包）‌
  • ‌0-RTT‌：客户端首次连接即可发送加密数据，无需等待握手完成（需预存会话密钥）

SSL 与 TLS 对比

特性TLS 1.3 (0-RTT)SSL/TLS 1.2及更早版本
‌首次连接握手延迟‌1-RTT（含密钥交换与身份验证）‌2-RTT（TCP+TLS叠加延迟）‌
‌会话恢复延迟‌0-RTT（直接复用缓存密钥）‌1-RTT（需重新协商参数）‌
‌抗重放攻击能力‌需服务端主动防御（如单次令牌验证）‌不支持0-RTT，天然规避风险‌
‌数据加密强度‌前向安全（PFS）强制启用‌部分版本存在非前向安全漏洞‌

https的加密算法

HTTPS采用对称加密和非对称加密相结合的方式：

  1. 非对称加密：用于在握手阶段传输对称密钥，常见算法为RSA或ECDHE。
  2. 对称加密：用于数据传输，速度快，常见算法为AES。
  3. 消息摘要算法：用于验证数据完整性，如SHA-256。
RSA

客户端生成预主密钥 → 使用服务器公钥加密 → 服务端用私钥解密获取预主密钥 → 双方生成会话密钥‌

graph LR
  A[客户端] -->|RSA公钥加密| B[预主密钥]
  B --> C[服务端]
  C -->|RSA私钥解密| D[会话密钥]
AES

加密与解密使用‌相同密钥‌，其核心处理单元为128位数据分组‌

  1. ‌基础模式‌

    • ECB（电子密码本）：相同明文生成相同密文，易受模式分析攻击‌
    • CBC（密码块链接）：引入初始化向量(IV)，增强安全性但需要填充‌

  2. ‌增强模式‌

    • GCM（Galois/Counter Mode）：支持认证加密，TLS 1.2+标准配置‌
    • XTS（磁盘加密模式）：适合存储设备加密，无需要求填充‌

全球98%的HTTPS连接使用AES-GCM模式，金融行业AES-256采用率达87%‌

SHA-256
  1. ‌固定输出长度‌
    无论输入数据大小，始终输出256位哈希值‌
  2. ‌不可逆性‌
    无法通过哈希值逆向推导原始数据（单向函数特性）‌
  3. ‌强抗碰撞性‌
    输入数据微小变化（如1bit差异）会导致输出哈希值显著不同（雪崩效应）‌
  4. ‌预处理标准化‌
    强制数据填充至512位倍数长度，包含原始数据长度标识‌
MD5

128位、已被实际攻破（火焰网攻击）‌

http版本的更迭

HTTP/1.0

  • 单一连接：每个请求都要新建TCP连接，导致性能低下。
  • 无状态：每次请求独立，不能复用连接。

HTTP/1.1

  • 持久连接（Keep-Alive） ：一个TCP连接可以发送多个请求，减少连接开销。
  • 分块传输：大文件传输时，可以分片发送。
  • 新增缓存控制：如Cache-Control头。

HTTP/2.0

  • 二进制分帧：相较于HTTP/1.x的文本协议，提升了解析效率。
  • 多路复用：一个TCP连接上可以发送多个请求，避免队头阻塞。
  • 服务器推送：服务器可以主动推送资源到客户端（仅限第一次推送）。
  • 头部压缩：通过HPACK算法减少头部冗余。

流ID为奇数表示客户端发起，偶数表示服务端发起‌

问题：

TCP层队头阻塞‌：若单个TCP包丢失，后续所有流需等待重传（HTTP/3已通过QUIC协议解决）‌

HTTP/3.0

  • 基于QUIC协议：通过UDP传输，解决TCP的延迟和拥塞问题。
  • 快速重连：连接中断后可以迅速恢复。
  • 减少握手次数：降低延迟。

解决 一一 对头阻塞与数据顺序

  • ‌流级别多路复用‌
    • 每个数据流（Stream）分配独立ID与序号空间，不同流的数据包传输互不影响，避免TCP的全局队头阻塞问题‌
    • 接收端通过Stream ID重组数据，保证同一流内数据按序处理‌
  • ‌递增包编号（Packet Number） ‌
    • 每个UDP数据包携带全局递增编号，消除TCP重传导致的序列号歧义‌
    • 接收方根据包编号检测丢失包并请求重传，同时重建数据顺序‌
  • ‌前向纠错（FEC） ‌
    • 关键数据包附加冗余校验信息，非连续丢包时可快速恢复，减少顺序错乱影响‌
前向纠错（FEC）

前向纠错（Forward Error Correction, FEC） ‌ 是一种通过预先在数据中添加冗余信息，使得接收端能够自行检测并纠正传输过程中产生的错误的技术。其核心特点是‌无需重传‌，适用于实时性要求高或重传成本过高的场景（如卫星通信、流媒体传输）

  1. ‌发送端‌：

    • 对原始数据块（如K字节）进行数学编码，生成冗余校验数据（如M字节）。
    • 合并发送数据包：总长度 = K + M。
    • ‌常用编码方法：
      • ‌海明码（Hamming Code） ‌：纠正单比特错误（如内存校验）。
      • ‌里德-所罗门码（Reed-Solomon, RS） ‌：纠正突发错误（如CD/DVD、QR码）。
      • ‌LDPC码（低密度奇偶校验码） ‌：接近香农极限的高效纠错（5G通信、Wi-Fi 6）。
      • ‌Turbo码‌：深空通信、卫星链路。

  2. ‌接收端‌：

    • 利用冗余信息检测错误位置（如通过奇偶校验矩阵）。
    • 根据编码规则重建原始数据（如多项式插值、迭代解码）。

解决 一一 数据完整性

  • 端到端加密校验‌

    • 所有数据包默认使用TLS 1.3加密，通过AEAD算法保证数据完整性与防篡改‌
    • 每个数据帧内置CRC校验码，接收端验证失败则触发重传‌

  • 确认重传机制‌

    • 接收方通过ACK帧反馈已接收包编号，未确认包超时后自动重传‌
    • 支持选择性确认（SACK），精确识别丢失包范围‌

  • 流控与错误隔离‌

    • 流级别流量控制：单个流错误不影响其他流传输‌
    • 连接迁移时通过新路径验证机制（Path Challenge）确保传输完整性‌

提升缓存效率（零往返复用 与‌ 多流并行处理）

0-RTT会话恢复机制‌‌

  • ‌首次连接‌：客户端与服务端完成1-RTT密钥协商，建立TLS 1.3加密会话
  • ‌后续请求‌：客户端直接复用已缓存的会话密钥，无需重新握手即可发送包含If-None-Match等验证头的请求，消除TCP+TLS的握手延迟（传统方案需1-3次RTT）‌

独立流多路复用‌‌

  • 每个缓存验证请求分配独立Stream ID，避免TCP队头阻塞
  • 示例场景：浏览器同时验证CSS/JS/图片缓存时，各资源验证流可并行处理，服务器端响应304的延迟从串行处理的200ms降至120m

TCP与UDP

HTTP是基于TCP的传输协议，而UDP则用于实时通信场景，如视频通话和直播。

TCP的特点

  • 面向连接：三次握手建立连接。
  • 可靠传输：通过ACK和超时重传机制保证数据完整性。
  • 流量控制与拥塞控制：防止网络过载。

UDP的特点

  • 无连接：不需要建立和断开连接。
  • 不可靠传输：不保证数据到达顺序和完整性。
  • 低延迟、高实时性：常用于直播、语音通话等场景。
avatar
文章
阅读
粉丝