引言
在当今数字化的世界中，超文本传输协议（HTTP）无疑是构建现代互联网的基石。作为应用层协议，它支撑着我们日常浏览网页、使用Web应用、与云端服务交互等几乎所有的网络活动。
本文旨在为广大前端开发者，提供一份全面、详尽且底层的HTTP知识指南。我们将从HTTP协议的根基------OSI七层模型和TCP/IP协议栈讲起，深入探讨TCP的三次握手与四次挥手、HTTP与HTTPS的区别，以及浏览器缓存机制等核心概念。在此基础上，我们将重点剖析HTTP协议从诞生至今的各个版本（HTTP/0.9、HTTP/1.0、HTTP/1.1）的特性、演进过程及其背后的设计思想。通过这种由浅入深、层层递进的方式，我们希望帮助读者构建一个完整、系统的HTTP知识体系，不仅能从容应对面试中的各种提问，更能将这些知识应用于实际工作中，提升开发效率和应用性能。
在本文的上半部分，我们将重点关注HTTP的基础知识和早期版本的演进。下半部分则将聚焦于HTTP/2和HTTP/3带来的革命性变化，以及对现代Web性能优化的深远影响。让我们一同开启这段探索HTTP协议奥秘的旅程。
HTTP的基石：网络协议模型与TCP/IP
要真正理解HTTP，我们必须先了解它在整个网络通信体系中所处的位置。HTTP并非孤立存在，而是构建在一系列更底层的协议之上，其中最核心的就是TCP/IP协议栈。
1. OSI七层模型与TCP/IP四层模型
为了使不同厂商的网络设备能够相互通信，国际标准化组织（ISO）提出了开放系统互连（OSI）七层模型。这是一个理论上的网络通信模型，将复杂的网络通信过程划分为七个逻辑层，每一层都负责特定的功能，并为其上一层提供服务。
OSI七层模型：
- 物理层（Physical Layer）： 负责传输原始的比特流，如网线、光纤、无线电波等。
- 数据链路层（Data Link Layer）： 负责在相邻节点之间传输数据帧，并进行差错校验，如以太网协议。
- 网络层（Network Layer）： 负责在网络中为数据包选择最佳路径，实现路由和寻址，如IP协议。
- 传输层（Transport Layer）： 负责在端到端之间提供可靠或不可靠的数据传输服务，如TCP和UDP协议。
- 会话层（Session Layer）： 负责建立、管理和终止会话。
- 表示层（Presentation Layer）： 负责数据的格式转换、加密和压缩。
- 应用层（Application Layer）： 负责为应用程序提供网络服务，如HTTP、FTP、SMTP等。
然而，在实际应用中，更为广泛使用的是TCP/IP四层模型，它是OSI模型的简化版，也是互联网事实上的标准。
TCP/IP四层模型：
- 网络接口层（Network Interface Layer）： 对应OSI的物理层和数据链路层。
- 网络层（Internet Layer）： 对应OSI的网络层，核心是IP协议。
- 传输层（Transport Layer）： 对应OSI的传输层，核心是TCP和UDP协议。
- 应用层（Application Layer）： 对应OSI的会话层、表示层和应用层，包含了HTTP、FTP等协议。
HTTP正位于TCP/IP模型的应用层。它利用传输层的TCP协议来保证数据传输的可靠性，而TCP又依赖于网络层的IP协议进行寻址和路由。这种分层结构使得各层协议可以独立发展和演进，同时又能协同工作，共同构成了我们今天所熟知的互联网。
2. TCP：可靠的传输控制协议
HTTP之所以能够可靠地传输网页内容，其背后的功臣就是TCP（Transmission Control Protocol，传输控制协议）。TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。其"可靠性"体现在以下几个方面：
- 数据分段： 将应用层的大块数据分割成适合在网络中传输的数据段。
- 序列号与确认应答： 为每个数据段分配一个序列号，接收方收到数据后会发送一个确认应答（ACK）。如果发送方在一定时间内没有收到确认，就会重新发送数据，从而保证数据不会丢失。
- 流量控制： 通过滑动窗口机制，控制发送方的发送速率，防止过快的数据淹没接收方。
- 拥塞控制： 当网络发生拥塞时，动态调整发送速率，避免加剧网络拥堵。
三次握手：建立连接
在HTTP通信开始之前，客户端和服务器之间必须通过TCP的三次握手来建立一个可靠的连接。
- 第一次握手（SYN）： 客户端向服务器发送一个SYN（同步序列编号）报文，请求建立连接。此时客户端进入
SYN_SENT状态。 - 第二次握手（SYN+ACK）： 服务器收到SYN报文后，如果同意建立连接，会向客户端发送一个SYN+ACK（同步序列编号+确认）报文，作为响应。此时服务器进入
SYN_RCVD状态。 - 第三次握手（ACK）： 客户端收到服务器的SYN+ACK报文后，会向服务器发送一个ACK（确认）报文。此时客户端和服务器都进入
ESTABLISHED状态，TCP连接建立成功，可以开始进行数据传输。
四次挥手：断开连接
当数据传输完成后，需要通过四次挥手来断开TCP连接。
- 第一次挥手（FIN）： 客户端向服务器发送一个FIN（结束）报文，请求断开连接。此时客户端进入
FIN_WAIT_1状态。 - 第二次挥手（ACK）： 服务器收到FIN报文后，会向客户端发送一个ACK报文，表示收到了断开请求。此时服务器进入
CLOSE_WAIT状态，客户端进入FIN_WAIT_2状态。此时TCP连接处于半关闭状态，服务器仍然可以向客户端发送数据。 - 第三次挥手（FIN）： 当服务器也准备好关闭连接时，会向客户端发送一个FIN报文。此时服务器进入
LAST_ACK状态。 - 第四次挥手（ACK）： 客户端收到服务器的FIN报文后，会向服务器发送一个ACK报文。此时客户端进入
TIME_WAIT状态，等待一段时间后关闭连接。服务器收到ACK报文后，立即关闭连接。
3. UDP：不可靠的用户数据报协议
与TCP相对的是UDP（User Datagram Protocol，用户数据报协议）。UDP是一种无连接的、不可靠的传输层协议。它不保证数据的顺序和可靠性，但传输速度快、开销小。UDP适用于对实时性要求高、但对数据完整性要求不高的场景，如在线游戏、视频会议、DNS查询等。HTTP/3的底层协议QUIC正是基于UDP构建的，我们将在下篇中详细探讨。
HTTP与HTTPS：安全性的飞跃
HTTP本身是明文传输的，这意味着数据在传输过程中容易被窃听和篡改。为了解决这个问题，HTTPS（Hyper Text Transfer Protocol Secure，超文本传输安全协议）应运而生。HTTPS并非一个全新的协议，而是HTTP与SSL/TLS协议的结合体。
HTTPS = HTTP + SSL/TLS
SSL（Secure Sockets Layer，安全套接层）及其后继者TLS（Transport Layer Security，传输层安全）是一套在传输层对网络连接进行加密的协议。它在HTTP和TCP之间增加了一个安全层，对传输的数据进行加密、解密和身份验证。
HTTPS的主要作用：
- 数据加密： 通过对称加密和非对称加密相结合的方式，对传输的数据进行加密，防止被窃听。
- 身份验证： 通过数字证书验证服务器的身份，防止中间人攻击。
- 数据完整性校验： 通过消息摘要算法，确保数据在传输过程中没有被篡改。
由于HTTPS提供了更高的安全性，现代Web应用已普遍采用HTTPS。浏览器也会对未使用HTTPS的网站标记为"不安全"，搜索引擎也会优先收录HTTPS网站。
浏览器缓存机制：提升性能的关键
为了提升页面加载速度和用户体验，浏览器引入了缓存机制。当浏览器请求一个资源时，会先检查本地缓存中是否存在该资源。如果存在且未过期，则直接从缓存中读取，无需向服务器发送请求。浏览器缓存分为两种：强缓存和协商缓存。
1. 强缓存
强缓存是指浏览器在请求资源时，如果发现缓存未过期，就直接使用缓存，不会向服务器发送任何请求。控制强缓存的HTTP头部字段有两个：
Expires（HTTP/1.0）： 指定一个绝对的过期时间。但由于客户端和服务器时间可能不一致，存在一定问题。Cache-Control（HTTP/1.1）： 提供了更灵活的缓存控制，如max-age指定一个相对的过期时间（单位为秒），no-cache表示需要进行协商缓存，no-store表示禁止缓存。
Cache-Control的优先级高于Expires。
2. 协商缓存
协商缓存是指浏览器在请求资源时，会向服务器发送一个请求，由服务器来判断资源是否过期。如果未过期，服务器会返回一个304 Not Modified状态码，浏览器则从缓存中读取资源。控制协商缓存的HTTP头部字段有两组：
Last-Modified/If-Modified-Since： 服务器在响应头中返回资源的最后修改时间（Last-Modified）。浏览器在下次请求时，会在请求头中带上If-Modified-Since字段，值为上次返回的Last-Modified。服务器比较时间，如果未修改则返回304。ETag/If-None-Match： 服务器为每个资源生成一个唯一的标识符（ETag）。浏览器在下次请求时，会在请求头中带上If-None-Match字段，值为上次返回的ETag。服务器比较ETag，如果一致则返回304。
ETag的优先级高于Last-Modified，因为它能更精确地判断资源是否变化（例如，文件内容未变但修改时间变了）。
HTTP各版本特性（上）：从诞生到普及
了解了HTTP的基础知识后，我们来回顾一下HTTP协议的演进历程。
1. HTTP/0.9：最初的模样
诞生于1991年的HTTP/0.9是HTTP协议的第一个版本，其设计目标非常简单：传输超文本文档。它的特性如下：
- 只有一个
GET请求方法： 只支持获取资源，不支持提交数据。 - 没有请求头和响应头： 无法指定请求的资源类型，也无法返回丰富的元数据。
- 响应只有HTML文本： 服务器只能返回HTML格式的文档，无法传输图片、CSS、JavaScript等其他类型的文件。
HTTP/0.9非常简陋，但它奠定了HTTP协议的基础，使得简单的网页得以在网络上传输。
2. HTTP/1.0：引入头部，丰富功能
随着Web的发展，HTTP/0.9已无法满足需求。1996年，HTTP/1.0发布，带来了许多重要改进：
- 引入请求头和响应头： 这是HTTP/1.0最重要的变化。通过头部字段，客户端和服务器可以传递更多的元数据，如
Content-Type指定资源类型，Content-Length指定内容长度等。这使得HTTP能够传输图片、视频、CSS、JS等多种类型的数据。 - 增加了
POST和HEAD等请求方法：POST用于向服务器提交数据，HEAD用于获取资源的元信息。 - 增加了状态码： 如
200 OK、404 Not Found等，使得客户端能够了解请求的处理结果。 - 支持Cookie： 引入了Cookie机制，使得HTTP协议能够记录状态。
然而，HTTP/1.0也存在一个致命的缺陷：
- 默认使用短连接： 每个HTTP请求都需要建立一个新的TCP连接，请求完成后立即断开。当一个页面包含多个资源（如图片、CSS、JS）时，需要频繁地建立和断开TCP连接，这会带来巨大的性能开销。
3. HTTP/1.1：长连接与管道化
为了解决HTTP/1.0的性能问题，1999年，HTTP/1.1发布，它至今仍是使用最广泛的HTTP版本。HTTP/1.1的核心改进在于性能优化：
- 长连接（Persistent Connection）： 默认启用长连接（
Connection: keep-alive）。一个TCP连接可以处理多个HTTP请求，浏览器可以通过一个TCP连接连续请求页面、图片、脚本等多个资源。服务器处理完一个请求后不会立即断开连接，而是保持一段时间，等待后续请求。这大大减少了TCP连接建立和断开的开销，显著提升了页面加载速度。 - 管道化（Pipelining）： 在长连接的基础上，HTTP/1.1引入了管道化技术。客户端可以一次性发送多个请求，而无需等待前一个请求的响应。但是，服务器必须按照接收请求的顺序返回响应。这在一定程度上提高了并发性，但并未完全解决问题。
- 分块传输编码（Chunked Transfer Encoding）： 允许服务器在发送响应时，将数据分成多个块（chunk）进行传输。这使得服务器可以在内容完全生成之前就开始发送数据，有利于动态内容的传输。
- 更丰富的缓存控制： 引入了
Cache-Control、ETag等更强大的缓存控制字段。 - 增加了
PUT、DELETE、OPTIONS等请求方法： 使得HTTP协议更适用于RESTful架构。
尽管HTTP/1.1带来了巨大的性能提升，但它仍然存在一个核心问题------队头阻塞（Head-of-line blocking） 。由于管道化要求响应必须按顺序返回，如果第一个请求的响应非常慢，那么后续请求的响应即使已经处理完毕，也必须排队等待，从而阻塞了整个连接。为了缓解这个问题，开发者们想出了各种优化手段，如合并文件、使用雪碧图、域名分片等。但这些都只是治标不治本的"变通"之法。要从根本上解决队头阻塞问题，还需要等待HTTP/2的到来。
在本文的上半部分，我们已经详细探讨了HTTP协议的基础知识以及HTTP/0.9、HTTP/1.0和HTTP/1.1的演进过程。在下半部分，我们将继续深入研究HTTP/2和HTTP/3带来的革命性变化，以及它们如何彻底改变现代Web的性能格局。
---待续---