HTTP协议详解

一、HTTP协议概述

1.1 定义

HTTP（Hypertext Transfer Protocol）即超文本传输协议，是一种用于在计算机网络之间传输超文本和其他资源的应用层协议。它基于请求 - 响应模式，通过客户端和服务器之间的交互，实现了在全球范围内快速传输数据和资源的功能，是构建万维网（World Wide Web）的基础。

1.2 起源与发展

HTTP的历史可以追溯到1989年，蒂姆·伯纳斯 - 李（Tim Berners - Lee）发表了一篇论文，提出了在互联网上构建超链接文档系统的构想，该系统采用了URI、HTML和HTTP三个关键技术。1991年，HTTP/0.9版本正式诞生，其作用是传输超文本内容，但只支持GET请求。随着互联网的发展，HTTP不断演进，先后出现了HTTP/1.0、HTTP/1.1、HTTP/2和HTTP/3等版本。

二、HTTP协议的发展历程

2.1 HTTP/0.9 - 单行协议

1991年诞生的HTTP/0.9是HTTP的第一个版本，极其简单。请求报文只有单行文本，仅包含一个GET方法和资源路径，无需指定协议版本、主机名或端口。响应更为简单，服务器直接返回所请求的资源内容，没有任何额外的状态行或头部，因此无法传输HTML以外的其他类型文件，也没有状态码表示请求结果。由于功能非常有限，它仅能满足早期万维网传输简单文本页面的基本需求。

2.2 HTTP/1.0 - 扩展与奠基

1996年发布的HTTP/1.0相比HTTP/0.9有了长足进步，主要引入了以下关键特性：

• 协议版本：在请求行中增加了协议版本信息，使客户端和服务器明确所使用的HTTP版本。

• 状态码：服务器响应以一个状态行开头，包含数字状态码和原因短语，使浏览器能够程序化地判断请求是成功还是失败。

• 头部 (Header)：引入了HTTP头部的概念，包括请求头和响应头，通过头部字段，客户端和服务器可以传递元数据，支持传输纯文本以外的其他类型内容，如图片、音频等。

• 多种内容类型：借助新的头部，能传输HTML之外的内容，如通过Content - Type: image/gif等头字段支持传输图片等二进制资源。

• 缓存机制：开始支持基本的缓存控制头部，例如Expires，允许浏览器和代理缓存资源副本以减少重复请求。

然而，HTTP/1.0每个请求都需要新建TCP连接，“一请求一连接”的模型开销大且效率低，默认不支持持久连接。

2.3 HTTP/1.1 - 标准化与改进

1997年初发布的HTTP/1.1是第一个真正标准化的版本，引入了多项性能和扩展改进：

• 持久连接：默认支持连接复用，一个TCP连接可用于发送多个请求/响应对，无需每次请求都重新建立连接，大幅减少了握手延迟和服务器负载，提高了请求串行传输多个资源的效率。

• 管线化 (Pipelining)：允许客户端在同一连接上并行发送多个请求，而不必等待前一个响应完全回来，降低了整体延迟。但需要服务器按请求顺序发送响应，可能因队头阻塞而削弱效果，且很多早期服务器和代理对管线化支持不佳，主流浏览器后来默认关闭了管线化。

• 分块传输编码：支持chunked分块传输编码，服务器可以把响应报文拆分为若干块依次发送，而不需要事先计算内容长度，提高了大文件传输或长连接推送的效率。

• 虚拟主机：引入必需的Host头，指定请求主机域名，使得在同一台物理服务器（同一IP）上可以托管多个网站（虚拟主机）。

• 缓存控制：增加了Cache - Control等更完善的缓存控制机制，相比HTTP/1.0能更精细地指定缓存的策略。

2.4 HTTP/2 - 性能的飞跃

2015年发布的HTTP/2基于SPDY协议，带来了显著的性能提升：

• 二进制分帧：采用二进制协议而非文本协议，将所有传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，减少了解析开销，提高了效率。

• 多路复用：允许在一个TCP连接上同时处理多个请求，解决了HTTP/1.x中的队头阻塞问题，提高了并发性能。

• 头部压缩：使用头部压缩技术（HPACK）减少了数据传输的大小，进一步提高效率。

• 服务器推送：允许服务器在客户端请求之前主动推送资源，加快页面加载速度。

2.5 HTTP/3 - 基于QUIC的革新

2020年发布的HTTP/3基于UDP协议的QUIC协议，旨在进一步提升性能和安全性：

• 0 - RTT握手：加快了连接建立速度，允许客户端在第一次连接时发送数据。

• 解决队头阻塞：通过使用UDP协议，解决了TCP拥塞控制导致的队头阻塞问题。

• 更快的流控制和错误恢复机制：提高了传输的稳定性。

三、HTTP协议的工作原理

3.1 基本工作流程

HTTP协议工作于客户端 - 服务端架构上，其基本工作流程如下：

1. 客户端发起请求：客户端（如Web浏览器）通过TCP/IP协议与服务器建立连接，然后向服务器发出HTTP请求，请求特定的资源，这通常通过URL来指定。请求包含请求行、请求头和请求体（可选）。请求行包含方法（如GET、POST）、URL和HTTP版本；请求头包含客户端信息、接受的媒体类型等元数据；请求体则包含要发送的数据（如表单数据、文件等）。

2. 服务器响应请求：服务器接收到客户端的请求后，解析请求行和请求头，根据请求的方法和URL找到相应的资源或处理程序。服务器处理请求后，生成响应，通过连接将响应发送回客户端。响应包含状态行、响应头和响应体（可选）。状态行包含HTTP版本、状态码和状态消息；响应头包含服务器信息、内容类型等元数据；响应体则包含请求的数据或资源。

3. 客户端处理响应：客户端接收到服务器的响应后，会根据响应内容进行处理，如显示网页、保存文件等。如果连接是临时的，服务器在发送响应后关闭连接；如果连接是持久的，则连接保持打开状态，以便客户端可以发送更多的请求。

3.2 具体示例

假设某个网页有5个img图像，总共6个对象存在同一个服务器中，该网页的基本文档形式URL为：http://192.168.24.61:8088/list.aspx?caid = 118。当采用HTTP/1.0时，WEB服务过程如下：

1. 客户端启用了对http://192.168.24.61:8088服务器的TCP连接，服务器监听来自网络的网络服务请求。

2. 客户端通过第一步建立的链接套接字发送“请求报文”。请求报文中包含了文档的路径名（ /list.aspx?caid = 118）。

3. 服务器通过第一步建立的连接套接字收到了所要请求的报文，从数据库中查找 /list.aspx?caid = 118，将文档封存在HTTP的“相应报文”中，并通过先前建立的套接字将该报文传回到客户端。

4. 服务器告诉TCP断开连接，在客户端完全收到响应报文之前不会断开TCP连接。

5. 当客户端接受完响应的报文，本次TCP连接就宣告结束了。到达的报文说明所封装的内容是HTML基本文件，客户端从响应报文中取出文件，对HTML文件进行解析，从而发现该文件还要引用另外5个img对象。针对所有的img对象，需要重复进行前四个步骤。

这种方式效率较低，因为每个请求对象都要建立和维持一个全新的连接。为了提高效率，可以采用持续连接模式，服务器在完成一次HTTP报文交互后继续保持连接，统一客户端和服务器之间后继的请求和响应报文可以在原来的连接进行。

四、HTTP协议的主要特点

4.1 支持客户/服务器模式

HTTP协议规定了客户端（如浏览器）和服务器之间请求和回应的方式，客户端向服务器提出请求，服务器根据请求提供相应的服务和资源。

4.2 简单快速

客户端向服务器请求服务时，只需传送请求方法和路径，就能快速得到回应。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

4.3 灵活

HTTP允许传输任意类型的数据对象，正在传输的类型由Content - Type加以标记，无论是文字、图片、视频还是音频，HTTP协议都能轻松应对。

4.4 无连接

每次连接只处理一个请求，处理完后就断开连接，这样可以节省资源。不过，HTTP/1.1引入了持久连接机制，在一定时间内可以复用连接。

4.5 无状态

HTTP协议对于事务处理没有记忆能力，每次请求都需要提供完整的信息。如果后续处理需要前面的信息，则必须重传，这可能导致每次连接传送的数据量增大。但在服务器不需要先前信息时，它的应答就较快。为了解决HTTP协议无状态的问题，出现了Cookie和Session等技术。

五、HTTP常见请求方法

5.1 GET

• 作用：向服务器请求获取指定资源，如请求一个网页、图像、文件等。请求的结果应当是可缓存的，并且安全地重发请求不会产生副作用（除非资源本身会发生变化）。

• 请求格式：URL后面可以跟查询字符串，以问号（?）开始，通过key = value的形式传递参数，多个参数之间用&分隔。例如：https://example.com/api/data?key1 = value1&key2 = value2。

• 安全性与隐私：因为GET请求的参数会显示在URL中，所以不宜用于传输敏感信息，搜索引擎也会索引这些URL，可能暴露数据。

• 缓存策略：GET请求的响应可以被缓存，以提高性能和减少带宽消耗。

5.2 POST

• 作用：用于向服务器提交数据，让服务器进行处理，如创建新资源、更新现有资源或执行某个操作等。

• 请求格式：POST请求的数据通常放在请求体（Request Body）中，可以是表单数据（application/x - www - form - urlencoded或multipart/form - data）、JSON数据（application/json）等形式。

• 安全性：POST请求的数据不会显示在URL中，相对更安全，适用于提交敏感数据。

• 幂等性：理想情况下，POST方法不应该是幂等的，也就是说，多次执行相同的POST请求可能会有不同的结果，例如创建多个资源。但在实际应用中，特别是遵循RESTful原则的设计中，POST有时也可以用于幂等的操作。

• 缓存策略：POST请求通常不会被缓存，以防止意外重复提交。

5.3 PUT

• 作用：用于替换服务器上的某一资源，如果资源存在，则更新资源；如果资源不存在，则创建新资源（取决于服务器是否支持）。

• 请求格式：PUT请求的请求体中必须包含完整的资源表示，服务器会根据请求体内容更新资源，或者用请求体内容创建新资源。

• 幂等性：PUT方法是幂等的，即无论请求多少次，只要请求体内容不变，服务器对资源的更改效果都是一样的。

• 缓存策略：PUT请求通常不应被缓存，但如果服务器确保了PUT操作的幂等性和可缓存性，那么在某些条件下是可以缓存的。

5.4 DELETE

• 作用：用于请求服务器删除指定的资源。

• 请求格式：DELETE请求通常只需在URL中指定要删除的资源位置，请求体可选，但即使提供，很多服务器也不会处理。

• 幂等性：DELETE方法是幂等的，多次发送相同的DELETE请求至同一URL，服务器都会尝试删除该资源，但一旦资源被删除，后续请求将返回资源未找到（404 Not Found）。

• 缓存策略：与PUT方法相似，DELETE请求通常不应被缓存，但如果服务器确保了DELETE操作的幂等性和可缓存性，在特定条件下也可以考虑缓存。

5.5 HEAD

与GET方法基本相同，但没有响应体，仅传输状态行和标题部分，常用于客户端查看服务器的性能或检查资源的元数据，如获取资源的大小、修改时间等，而不获取实际数据。

5.6 OPTIONS

请求服务器返回该资源所支持的预定义URL的HTTP策略，用于跨域资源共享（CORS）中的预检请求，或者检查服务器允许的HTTP方法。也可以利用向Web服务器发送'*'的请求来测试服务器的功能性。

5.7 CONNECT

用来建立到给定URI标识的服务器的隧道，是HTTP/1.1协议预留的，可以将链接改成管道方式的代理服务器，常用于SSL隧道、HTTP代理。

5.8 TRACE

请求服务器回显其收到的请求信息，主要用于HTTP请求的测试或诊断。

5.9 PATCH

用于对指定资源进行部分修改，通常用于资源的部分更新，与PUT不同，PUT通常用于资源的总体更新。PATCH不是幂等的，因为多次应用相同的PATCH请求可能会产生不同的结果。

六、HTTP状态码

HTTP状态码是服务器所返回的数字代码，用于指示HTTP请求的处理结果，分为五个类别：

6.1 1xx - 信息性状态码

表示请求已被接收，继续处理。常见的有：

• 100 Continue：请求者可以继续发送请求的剩余部分。

• 101 Switching Protocols：服务器已接受切换协议的请求。

6.2 2xx - 成功状态码

表示请求的成功处理。主要有：

• 200 OK：请求成功，并返回所请求的数据。

• 201 Created：成功请求并创建了新的资源。

• 204 No Content：请求成功，但没有内容返回。

• 206 Partial Content：客户端进行了范围请求，而服务器成功执行了这部分的GET请求，响应报文内包含由Content - Range指定范围的实体内容。

6.3 3xx - 重定向状态码

表示需要进一步的操作来完成请求。常见的状态码有：

• 301 Moved Permanently：请求的资源已被永久移动到新位置。

• 302 Found：临时重定向，资源暂时位于不同的URI。

• 304 Not Modified：客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足条件的情况，客户端可以直接使用缓存中的资源。

6.4 4xx - 客户端错误状态码

表示请求有错误。常见的有：

• 400 Bad Request：请求格式错误或无法被理解。

• 401 Unauthorized：请求未授权，用户需要进行身份验证。

• 403 Forbidden：服务器理解请求但拒绝执行。

• 404 Not Found：服务器无法找到请求的资源。

• 408 Request Timeout：请求超时，客户端未向服务器发送请求。

6.5 5xx - 服务器错误状态码

表示服务器未能完成有效的请求。主要包括：

• 500 Internal Server Error：服务器在处理请求时发生了意外错误。

• 502 Bad Gateway：作为网关或代理的服务器收到无效响应。

• 503 Service Unavailable：服务器当前无法处理请求，通常是暂时性故障。

• 504 Gateway Timeout：作为网关或代理的服务器未能及时从上游服务器获取响应。

七、HTTP协议请求中的请求行、请求头和请求体

7.1 请求行

请求行是HTTP请求的第一行，由方法（Method）、请求URI（Uniform Resource Identifier）、协议版本组成，这三部分通过空格分开。示例：GET /index.html HTTP/1.1。下面分别介绍这三个部分：

• 方法（Method）：定义了对资源的操作，常见的HTTP方法包括：

  • GET：请求获取指定资源。GET请求应当只用于获取数据而不会引发服务器上数据的改变。

  • POST：用于提交数据，例如表单数据。POST请求可能会导致新的资源的创建或已有资源的修改。

  • PUT：将请求的数据上传到指定的URI（如果指定的URI不存在，则创建它）。

  • DELETE：请求删除指定的URI上可用的资源。

  • HEAD：请求获取资源的元数据（metadata），类似于GET请求，但不返回消息体。

  • OPTIONS：用于描述目标资源的通信选项。

  • PATCH：用于对资源应用部分修改。

• 请求URI：指定了请求的资源路径。例如：绝对路径/index.html 或 /images/logo.png；带查询字符串/search?q=http （q=http 是查询参数，告诉服务器按照 “http” 进行搜索）。在HTTP/1.1中，请求URI通常传递的是URI的路径和可选的查询字符串。但是在代理请求中，它可能是完整的URI。

• 协议版本：标识了客户端用于构造请求的HTTP协议的版本。常见的版本有：

  • HTTP/1.0：较早的HTTP版本，简单并且不支持每个连接多个请求（非持续连接）。

  • HTTP/1.1：当今最普遍的版本，支持持续连接、流水线化请求、更高效的缓存处理等。

  • HTTP/2：最新的HTTP版本，支持多路复用、头部压缩、服务器推送等。

7.2 请求头

HTTP请求头由一系列的键值对组成，它们为HTTP请求提供了额外的上下文和参数设置。以下是一些常见的请求头部字段，以及它们的含义和用途：

1. 通用信息与上下文控制

   • Host：指定请求的目标服务器的域名和端口号（如果不是默认端口80或443）。这是HTTP/1.1协议中唯一一个强制要求的请求头，允许多个域名（虚拟主机）共享同一个IP地址。示例：Host: www.example.com 或 Host: api.example.com:8080。

   • User - Agent：包含发起请求的客户端（通常是浏览器、爬虫或应用程序）的标识信息。服务器可以根据不同的客户端提供不同的内容或体验（例如，移动版网页）。示例：User - Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36。

   • Referer：表示当前请求是从哪个URL跳转过来的，用于统计分析、日志记录、缓存优化或防盗链。示例：Referer: https://www.google.com/search?q=http+headers。

   • Origin：指示引发该请求的源（协议、域名和端口），主要用于CORS（跨源资源共享）请求中，帮助服务器判断是否允许跨域请求。示例：Origin: https://developer.mozilla.org。

   • Connection：决定当前事务完成后，网络连接是否关闭。HTTP/1.1默认值为keep - alive（持久连接，允许在同一连接上发送多个请求），其他值为close（请求完成后关闭连接）。示例：Connection: keep - alive。

   • Date：请求发送的日期和时间 (GMT)，主要用于消息跟踪、缓存控制等。示例：Date: Tue, 18 May 2025 03:10:07 GMT。

2. 内容协商：这些头部告诉服务器客户端期望接收什么样格式的响应。

   • Accept：客户端可以处理的内容类型（MIME类型），可以使用q值（权重因子，0到1）来表示优先级。示例：Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8。

   • Accept - Charset：客户端可以处理的字符集。示例：Accept - Charset: utf - 8, iso - 8859 - 1;q=0.5。

   • Accept - Encoding：客户端可以处理的内容编码方式（通常是压缩算法）。示例：Accept - Encoding: gzip, deflate, br。

   • Accept - Language：客户端偏好的自然语言。示例：Accept - Language: en - US,en;q=0.9,zh - CN;q=0.8。

3. 条件请求：这些头部允许客户端基于某些条件发起请求，通常用于缓存验证或避免不必要的数据传输。

   • If - Modified - Since：如果资源自指定日期时间以来未被修改，则服务器返回304 Not Modified状态码，不返回资源内容。示例：If - Modified - Since: Mon, 17 May 2025 12:00:00 GMT。

   • If - Unmodified - Since：如果资源自指定日期时间以来已被修改，则服务器返回412 Precondition Failed。示例：If - Unmodified - Since: Mon, 17 May 2025 12:00:00 GMT。

   • If - Match：如果资源的ETag值与指定的值匹配，则服务器处理请求；否则返回412 Precondition Failed。示例：If - Match: "686897696a7c876b7e"。

   • If - None - Match：如果资源的ETag值与指定的值不匹配，则服务器处理请求；否则返回304 Not Modified。示例：If - None - Match: "686897696a7c876b7e"。

4. 认证授权

   • Authorization：包含用于身份验证的信息，例如令牌或凭证，用于访问受保护的资源时提供凭证。示例：Authorization: Bearer <token>。

   • Cookie：向服务器发送的存储在客户端的所有Cookie信息，服务器用来维持会话状态或存储用户特定的信息。示例：Cookie: sessionId=abc123; userId=789。

5. 请求体相关

   • Content - Type：当发送POST或PUT请求时，这个请求头必须被使用来指示提交数据的MIME类型。示例：Content - Type: application/json。

   • Content - Length：在POST或PUT请求中，指示请求体的大小（以字节计）。示例：Content - Length: 348。

7.3 请求体

HTTP请求体是在发送HTTP请求时，位于请求头之后的数据部分，通常用于向服务器发送一些需要处理的数据，例如提交表单数据、上传文件等。在使用POST、PUT等方法时，数据会被放在请求体中发送给服务器；而在使用GET方法时，数据会被追加在URL后面，请求体通常为空。

请求体的格式与内容通常由请求头中的Content - Type字段指定，常见的格式有：

• application/x - www - form - urlencoded：常见的表单提交格式，将请求数据编码为“key = value”形式，多个键值对之间用“&”符号隔开。例如：name=Tom&age=20&gender=male。

• multipart/form - data：用于上传文件或二进制数据的格式。例如：

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content - Disposition: form - data; name="file"; filename="example.txt"
Content - Type: text/plain
...此处为文件内容...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

• application/json：用于传输JSON格式的数据。例如：

{
    "name": "Tom",
    "age": 20,
    "gender": "male"
}

• text/plain：用于发送简单的文本消息或数据给服务器，例如WebSocket连接中的心跳检测。例如：Hello, this is plain text content.

需要注意的是，HTTP请求体的大小通常有一定限制，这是由服务器和客户端共同决定的。如果请求体过大，可能会导致服务器拒绝服务或者出现其他错误。为了减小请求体的大小，HTTP协议支持使用压缩算法对请求体进行压缩，常见的压缩算法有Gzip、Deflate等，可在请求头中使用“Content - Encoding”字段指定压缩算法。同时，为了保护敏感数据不被第三方窃取，通常会将HTTP协议升级为HTTPS协议来实现请求体的加密。

八、HTTP协议的应用与影响

8.1 在Web开发中的应用

HTTP协议是Web开发的基础，几乎所有的Web应用都依赖于HTTP协议进行数据传输和交互。开发者可以根据HTTP协议的特点和请求方法，设计出高效、可靠的Web服务。例如，使用GET方法获取资源，使用POST方法提交表单数据，使用PUT和DELETE方法进行资源的更新和删除等。同时，通过合理利用HTTP状态码，可以更好地处理请求和响应，提高用户体验。

8.2 对互联网的影响

HTTP协议的出现和发展极大地推动了互联网的普及和发展。它使得超文本和其他资源能够在全球范围内快速传输，促进了信息的共享和交流。随着HTTP协议的不断演进，如HTTP/2和HTTP/3的出现，进一步提高了网络性能和用户体验，为互联网的发展注入了新的活力。

综上所述，HTTP协议是互联网中不可或缺的一部分，深入理解HTTP协议的原理、特点、请求方法、状态码以及请求行、请求头和请求体等内容，对于Web开发者和网络工程师来说至关重要。