深入解析HTTP协议演进与TCP/UDP核心原理

这篇文章和大家聊聊所谓的传输层协议，全是干货，速记！

数据报文传输的流程

我们首先需要了解一下数据报文的传输流程：

电脑的信息 => dns 域名解析 => 在电脑中转化成二进制 => 报文（头：携带数据的基本信息；体：数据体） => 传输协议（UDP、TCP）=> 传输数据给另一台设备

UDP 协议

用户数据报协议（UDP，User Datagram Protocol）是一种简单的、面向数据报的传输层协议。它提供了一个无连接的通信方式，主要特点包括：

• 面向无连接：UDP 不需要在发送数据之前建立连接，知道了对面的 ip （dns 解析）后就直接传输数据。
• 只做数据报文的搬运工：不增加额外的报文，头部只有八个字节
• 不保证数据包的有序性：
• 不保证数据的可靠性：UDP 不保证数据包的顺序和完整性，可能会出现丢包或乱序的情况。
• 没有拥塞控制：
• 高效：由于没有连接建立和维护的开销，UDP 的传输效率较高，适用于实时应用。

常见的应用场景：直播，视频，实时性要求高的应用

TCP 协议：从物理层贯穿到应用层

• 可靠的、面向连接：在传输数据之前，TCP 需要建立一个连接，并在传输结束后释放连接。

• 慢启动、拥塞控制：TCP 通过拥塞避免算法，动态调整发送速率，避免网络拥塞。

• 有序的

• 流量控制：TCP 通过滑动窗口机制，控制数据的发送速率，防止网络拥塞。

• 头部信息多：

  1. Sequence Number（序列号）

  2. Acknowledgment Number（确认号）

  3. Window Size（窗口大小：网络环境支持传输多少字节的数据）

  4. 标识符

     1. URG=1 紧急报文
     2. ACK：1 确认报文
     3. PSH：1 接收端应立即将数据传给应用层
     4. RST：1 需要重连
     5. SYN：1 请求建立连接
     6. FYN：1 关闭连接

常见的应用场景：ajaxs、实时性要求不高的应用。

http 协议 数据传输

三次握手

1. （SYN）：客户端向服务器发送一个 SYN（同步序列号）报文（客户端进入 SYN-SEND 状态）
2. （SYN-ACK）：服务器收到 SYN 报文后，向客户端发送一个 SYN-ACK 报文（服务端进入 SYN-RECEIVED）
3. （ACK）：客户端收到 SYN-ACK 报文后，向服务器发送一个 ACK 报文，确认收到服务器的 SYN 报文（客户端和服务端进入到 ESTABLISHEN）

为什么有三次握手

• 假设客户端像服务端发送一个连接请求 A，但是网络环境差导致 A 报文丢失，TCP 的超时重传会让客户端会重新再发一个连接请求 B，此时服务端顺利接收到 B 报文，然后服务端回复一个确认报文，如果此时连接就建立成功的话，客户端和服务端就开始通信，通性结束后断开连接。但 A 报文有可能在再次出现在网络环境中被服务端接收到，此时服务端会回复一个确认报文并进入到 ESTABLISHEN 状态，而客户端已经下线，服务端会一直等待客户端的数据通讯，造成资源浪费。

四次挥手

1. （FIN）：客户端向服务器发送一个 FIN（终止连接）报文，表示客户端不再发送数据，但仍可以接收数据（客户端进入 FIN-WAIT-1 状态）。
2. （ACK）：服务器收到 FIN 报文后，向客户端发送一个 ACK 报文，确认收到客户端的 FIN 报文（服务器进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态）。
3. （FIN）：服务器向客户端发送一个 FIN 报文，表示服务器也不再发送数据，但仍可以接收数据（服务器进入 LAST-ACK 状态）。
4. （ACK）：客户端收到服务器的 FIN 报文后，向服务器发送一个 ACK 报文，确认收到服务器的 FIN 报文（客户端进入 TIME-WAIT 状态，服务器进入 CLOSED 状态）。客户端在经过一段时间（通常是 2MSL，最大报文段生存时间）后，进入 CLOSED 状态。

http 0.9

• 传输体积很小的 html 超文本
• 特点

1. 只有请求行，没有请求头，没有请求体

   例如：www.baidu.com/images/inde...，images/index.js 是请求行

2. 服务端没有返回头信息

3. 返回的内容以 ASCII 字符流传输

http 1.0

• 万维网联盟（W3C）和 http 工作组成立

• 浏览器展示的不仅是 html，还有 js，css，图片，音频，视频等等

• HTTP 需要支持不仅限于 ASCII 的编码，还需要支持多种的编码类型

• 特点：增加了请求头，响应头 key-value

• 1.0 需要解决的问题

  1. 浏览器需要知道服务器返回的内容是什么类型
  2. 浏览器需要知道服务器用的是什么压缩方式（文件越来越大需要压缩）
  3. 浏览器要能告诉服务器自己需要的语言类型
  4. 浏览器需要知道文件的编码类型

• 请求头

  1. accept：text/html （浏览器能接受的类型）
  2. accept-encoding：gzip，deflate，br，zstd （浏览器能接受的压缩方式）
  3. accept-language：zh:CN,zh;q=0.9 （浏览器能接受的语言类型）
  4. accept-charset：UTF-8，TSO-8859-1;q=0.9（浏览器能接受的编码类型）

• 响应体

  1. content-type（服务器返回的类型）
  2. content-encoding（服务器用的压缩方式）
  3. content-language（服务器用的语言类型）

• 状态码

  1. 2xx 成功

  • 200 成功

  • 204 成功，但是没有内容

  • 205 成功，报文没有实体

  • 206 成功，报文只含有实体的一部分

  2. 3xx 重定向

  • 301 永久重定向（请求能走，没有资源，这个资源被放在别的URL了）

  • 302 临时重定向（请求的资源临时被移动到新的 URL）

  • 303 临时重定向（请求的资源可以在另一个 URL 处找到，客户端应使用 GET 方法请求新的 URL）

  • 304 协商缓存 （表示请求的资源未被修改，客户端应继续使用缓存的版本。）

  3. 4xx 客户端错误

  • 400（请求无效或格式错误，服务器无法理解请求）

  • 401（未授权）

  • 403（禁止访问）

  • 404（服务器无法找到请求的资源，通常是因为 URL 错误或资源已被删）

  4. 5xx 服务器错误
  • 500 内部服务器错误（服务器遇到错误，无法完成请求）
  • 501 未实现（服务器不具备完成请求的功能）
  • 502 错误网关（服务器作为网关或代理，从上游服务器收到无效响应）
  • 503 服务不可用（服务器暂时无法处理请求，通常是由于过载或维护）

• Cache 缓存机制（强缓存和协商缓存）

• 用户代理：通过请求头的 User-Agent 字段传递 User-Agent: Mozilla/5.0 (平台信息) 引擎/版本 产品/版本 [扩展信息]

http 1.1

• 1.0 缺陷：每一次请求都要重新建立连接，浪费资源

• 1.1 的特点

  1. 增加了 TCP 的持久连接（一个 TCP 连接中可传输多个 HTTP 请求）
  2. 允许同时建立 6 个 TCP 持久连接
  3. 增加了带宽优化机制（文件切片）
  4. 增加了 Host 字段（主机名）
  5. 客户端增加了 cookie

• 问题：队头阻塞（一个 TCP 连接中，前面的请求没有返回，后面的请求就会阻塞）

http 2.0

• 1.1 的缺陷

  1. 队头阻塞

  2. 带宽利用率低 （100M应该有12.5M/s，但是只有2.5M/s），是因为

  • TCP 的慢启动
  • 同时建立了 6 个 tcp 连接，导致每个连接之间竞争带宽
  • http队头阻塞

• 2.0 多路复用--解决队头阻塞

  1. 一个域名下，只需要一个 TCP 连接
  2. 二进制分帧层：将请求全部打包成帧，帧与帧之间互不干扰，并打上编号，服务端可以根据编号的优先级来处理加急请求

HTTPS 和 HTTP 的区别

• https 是 http 的安全版本。（https = http + TLS + SSL）

• TLS加密：

  1. 对称加密：两边拥有相同的密钥，两边都知道如何解密

  2. 非对称加密：为了让两边拥有相同的密钥

     1. 客户端生成 密钥
     2. 服务端生成 公钥+私钥
     3. 服务端将 公钥 发送给客户端
     4. 客户端利用 公钥 加密 密钥 并传输给服务端
     5. 服务端用私钥解开 公钥 得到 密钥

这个大家可以发挥一下自己的想象力，

服务端就像银行金库，有一个特殊的保险柜：

• 公钥：银行给客户的 "锁"，只能用来锁保险柜

• 私钥：银行自己的 "钥匙"，只能用来打开保险柜

客户端就像客户：

• 客户把贵重物品（密钥）放进保险柜
• 用银行给的锁（公钥）锁住保险柜
• 保险柜运输到银行
• 银行用自己的钥匙（私钥）打开保险柜

HTTP 3.0

• 2.0 缺陷

  1. TCP 的队头阻塞（超时重传）：注意这是TCP的对头阻塞，和 http 队头阻塞的不一样
  2. TCP 的慢启动
  3. TCP 建立连接和关闭连接（耗时）

• QUIC：传输层协议

  • 基于UDP协议
  • 多路复用
  • 有序性
  • 快速握手
  • 可靠性
  • 加密传输
  • 流量控制

  通过独立流(Stream)和包号(Packet Number)设计解决TCP队头阻塞，例如：

QUIC为每个数据流分配独立编号，即使某个流出现丢包，其他流的传输不受影响，彻底规避TCP的全局重传阻塞问题。

• 难以普及的原因：

  • TCP 协议僵化：指由于 TCP 协议在互联网基础设施中被广泛应用已久，导致对其进行任何实质性改进或修改变得极其困难的现象
  • 设备更换根本导致 3.0 没有普及开来

HTTP/1.1 = HTTP 协议 + TCP 传输层
HTTP/2 = HTTP 协议改进版 + TCP 传输层
HTTP/3 = HTTP 协议进一步改进 + QUIC 传输层 (基于 UDP)

面试考点

1. UDP 和 TCP 区别
2. TCP 为什么是三次握手
3. 状态码
4. http 队头阻塞，怎么解决
5. TLS 加密手段（http和https的区别）
6. HTTP 3.0的认识