什么是Http

HTTP，作为一种关键的应用层协议，以其简洁高效的特性，专为支持分布式超媒体信息系统的运作而设计。

自1990年代初概念初现以来，HTTP协议历经了不断的实践检验和技术革新，逐步稳固了其作为互联网通信核心基石的地位。然而，随着技术的飞速发展和网络应用的日益复杂，全球万维网生态中对于更高效、更安全的通信协议的需求也在不断增加，下面便是HTTP协议版本发展的时间线。

Http协议不断地升级不仅反映出业界对持续优化网络通信效率与用户体验的不懈追求，也预示着未来HTTP将在保持其核心价值的基础上，更好地适应不断变化的互联网环境与新兴应用需求。

---

历代Http协议

• HTTP/0.9 (1991年)：HTTP的第一个版本，它非常基础，只支持GET请求方法，并且响应为HTML格式的文本，没有请求头和响应头，每个请求处理完后，TCP连接就会关闭。

• HTTP/1.0 (1996年)：HTTP/1.0相对于HTTP/0.9有了显著的改进，引入了Connection: keep-alive，支持持久连接，使得多个请求和响应可以在同一个TCP连接中进行，也支持了管道化技术，允许浏览器同时发送多个请求。

• HTTP/1.1 (1997年)：HTTP/1.1在HTTP/1.0的基础上进一步标准化了协议。引入了更多的请求方法（如PUT、DELETE等），增加了Host头，使得同一台服务器上可以运行多个网站，也对连接管理、缓存等方面进行了优化。

• HTTP/2 (2015年)：HTTP/2是基于SPDY协议发展而来的，是HTTP协议自1999年HTTP 1.1发布后的首个重大更新。HTTP/2采用了二进制分帧层，实现了多路复用、头部压缩、服务端推送等特性，大大提高了网络性能和效率。

HTTP/3 (2022年)：HTTP/3是基于QUIC协议构建的，旨在解决HTTP/2在传输层依赖TCP所带来的问题。QUIC协议提供了与TCP相似的连接语义、可靠性和拥塞控制，但具有更低的连接延迟和更高的重传效率。HTTP/3通过结合QUIC协议的特性，进一步提升了网络传输的速度和安全性。

注意，目前HTTP/1.1仍然是当前互联网通信中广泛使用的协议版本。

---

主要特点

HTTP（超文本传输协议）是一种应用层协议，采用请求与响应模式，具有无状态特性。通常基于TCP连接实现，特别是在HTTP 1.1版本中引入了持续连接机制，有效提升了网络交互效率。大部分Web应用的开发都依赖于HTTP协议，它奠定了Web应用的基石。

HTTP 协议的主要特点可概括如下：

• 客户/服务器模式：支持经典的客户端发起请求、服务器响应的服务模式。

• 简单快捷：客户仅需发送请求方法和路径至服务器，常用方法如GET、HEAD、POST，简洁的设计使服务器程序规模小，通信高效。

• 灵活性强：HTTP能够传输任意类型的数据，通过Content-Type标识数据类型，适应性强。

• 无连接性：每次连接仅处理单个请求，处理完成后即断开，有助于节省传输时间。

• 无状态性：协议对事务处理无记忆能力，需重传前序信息时可能导致数据量增大，但服务器在无需先前信息时响应迅速。

---

格式和URL

HTTP协议主要是通过URL（统一资源定位符）进行定位并请求网络资源，它是URI（统一资源标识符）的一种特定形式，它包含了足够的信息来定位并访问网络资源。

这种格式为互联网上的资源提供了清晰、明确的访问路径，使得用户或应用程序能够准确地找到并获取所需的信息或服务，它是Web开发中不可或缺的一部分，也是现代网络交互的基础。

标准格式通常遵循结构：http://host[:port][path]。

• http 指的是所使用的协议类型，即超文本传输协议；
• host 表示资源所在的主机名或IP地址；
• port 是可选部分，用于指定主机上特定的服务端口号，默认为80；
• path 是绝对路径，用于指示服务器上资源的具体位置。

协议内容

HTTP协议的请求结构主要由三大部分构成，它们分别是请求行、消息报头和请求正文。

请求行

请求行作为HTTP请求的核心组成部分，其格式规范而严谨，主要包含了请求方法、请求的资源URI（URL）以及HTTP协议的版本信息，它指明了客户端希望服务器执行的具体操作和目标资源。

格式如下

结构清晰、易于解析的请求行格式，确保了HTTP请求的高效传输和处理。

MethodType  [空格]  Request-URI  [空格]  HTTP-Version  CRLF

1. 方法类型（MethodType）：该方法类型代表客户端希望服务器执行的操作类型，如GET、POST等。
2. [空格]：紧接着是一个空格，用于分隔方法类型和后续的Request-URI（请求URI），它表示客户端想要访问的具体资源位置，它是服务器定位和处理请求的关键信息。
3. [空格]：紧接着再是一个空格，分隔请求URI和HTTP协议的版本信息，版本信息确保了双方通信时使用的协议版本一致。
4. HTTP-Version：表示请求的HTTP 协议版本。
5. CRLF：之后以回车换行符（CRLF）结束，标志着请求行的结束和后续消息报头的开始。

请求方法

简单案例

POST /login HTTP/1.1 表明这是一个POST请求，目标是服务器的/login路径，使用的HTTP协议版本是1.1。

消息报头

消息报头提供了一系列有关请求和客户端的元数据，如请求的附加信息、客户端的环境设置等，有助于服务器更好地理解和处理请求。

报头域的格式

报头域的名字、冒号、空格和值所组成，消息报头域的名字是大小写无关的。

name +“：”+ [空格] + value 组成

注意，HTTP消息报头域的名字在解析时是大小写无关的，这增强了HTTP协议的灵活性和兼容性。

HTTP消息报头类型

HTTP消息报头涵盖了多种类型的报头，包括普通报头、请求报头、响应报头以及实体报头，它们共同构成了HTTP消息的元数据部分。

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成，请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行），消息报头（可选），空行（只有 CRLF 的行），消息正文（可选）组成。

普通报头

在HTTP协议中，普通报头包含了一些特定的报头域，这些报头域是通用的，适用于所有的请求和响应消息，它们并不涉及实际被传输的数据实体内容，而是专注于消息的传输本身。

优化方向报头（缓存）

响应头	描述	示例代码
Cache-Control	用于控制缓存行为。设置为no-cache时，指示浏览器每次请求页面时都必须向服务器验证缓存的内容是否仍然有效。	response.setHeader("Cache-Control", "no-cache");

缓存报头域在HTTP通信中扮演着重要的角色，提供了关于消息本身的元数据，而不是关于被传输数据的具体信息。通过合理使用这些普通报头，我们可以更有效地控制和管理HTTP消息的传输过程，从而优化网络通信的性能和效率。

Cache-Control的选项

缓存指令	描述
no-cache	用于指示请求或响应消息不能缓存。即使存在缓存，也必须向原始服务器进行验证。
no-store	绝对禁止缓存。任何缓存系统都必须丢弃该响应或请求的副本。
max-age	指定响应在缓存中的最大生存时间（以秒为单位）。超过这个时间后，缓存的响应将不再被视为有效。
max-stale	允许缓存的响应在过期后的一段时间内仍然被使用。这个值表示过期后的额外秒数。
min-fresh	指定响应在缓存中必须保持新鲜的最小时间（以秒为单位）。这意味着，从请求时刻起，缓存的响应不能比这个时间更旧。
only-if-cached	仅当缓存中存在响应时才使用缓存的响应，否则直接向原始服务器发送请求。

其他相关的缓存报头

响应头	描述	示例代码
Pragma	在HTTP/1.0中，Pragma头用于向后兼容，实现与Cache-Control相似的功能。尽管Cache-Control是更现代的标准，但在某些旧版浏览器或代理中，可能仍需要设置Pragma。	// response.setHeader("Pragma", "no-cache");
Date	表示消息产生的日期和时间。它有助于缓存机制确定响应的新鲜度。	无需显式设置，通常由服务器自动添加。
Connection	允许发送指定连接的选项。例如，设置为close时，通知服务器在响应完成后关闭连接。这有助于管理持久连接和减少资源消耗。	response.setHeader("Connection", "close");

请求报头

请求报头作为客户端与服务器之间沟通的桥梁，不仅承担着传递附加请求信息的重任，还承载着展示客户端自身特征的关键使命。

Accept

Accept请求报头域扮演着至关重要的角色，它精确地指明了客户端愿意接收的信息类型。

举例来说，当"Accept" 报头域设置为 “Accept:image/gif” 时，这即意味着客户端希望接收GIF格式的图像资源，并期望服务器返回相应类型的数据。若报头域设置为 “Accept:text/html”，则表明客户端偏好接收 HTML 格式的文本内容，通过Accept报头，客户端能够明确表达其数据需求，从而确保服务器能够精准地响应其请求，提供最为合适的信息资源。

Accept-Charset

Accept-Charset请求报头域专门用于指明客户端所支持的字符集。

举例来说，当设置为 “Accept-Charset:iso-8859-1,gb2312” 时，意味着客户端能够处理这两种字符集的数据。如果在请求消息中未明确设置该报头域，那么默认情况下，客户端将接受任何字符集的数据。

Accept-Encoding

Accept-Encoding请求报头域指定客户端可接受的内容编码方式。

举例来说，当该报头域设置为 " Accept-Encoding:gzip, deflate" 时，客户端表示它支持并期望接收通过 gzip 或 deflate 算法压缩的内容。若请求消息中未设置此报头域，服务器将默认客户端能够处理各种内容编码，从而确保数据的广泛兼容性和传输效率。

Accept-Language

Accept-Language请求报头域专门用于指定客户端所偏好的自然语言。

例如，当设置为 Accept-Language: zh-cn"时，客户端明确表示希望接收中文（简体）的内容。若请求消息中未包含此报头域，服务器将默认客户端能够接受各种语言的内容，从而确保服务的广泛覆盖和灵活性。

Authorization

Authorization请求报头域的核心功能是验证客户端对特定资源的访问权限。

当浏览器尝试访问某个页面时，如果遭遇服务器返回的401未授权响应码，它可以通过发送一个附加Authorization报头域的请求，来向服务器证明自己的访问资格，进而完成身份验证流程。这一机制确保了资源访问的安全性，有效防止了未经授权的访问行为，从而维护了网络环境的稳定与可靠。

Host

在发送HTTP请求时，Host请求报头域扮演着至关重要的角色，它负责明确指出被请求资源所在的Internet主机及相应的端口号。

通常是从HTTP URL中自动提取的，确保了请求能够准确无误地定向到目标服务器和端口，进而实现资源的精准获取。通过正确设置Host报头域，我们不仅能够提升请求的处理效率，还能够有效避免潜在的访问冲突和安全风险。

http://www.xxx.com/index.html

浏览器发送的请求消息中，就会包含 Host 请求报头域，如Host：www.xxx.com，此处使用缺省端口号 80，若指定端口号，则变成Host：www.xxx.com:指定端口号。

User-Agent

当我们上网的时候，通常会看到显示我们操作系统和浏览器信息的欢迎信息。这些信息实际上是服务器通过读取User-Agent请求报头域获取的。这个报头域允许客户端告诉服务器其操作系统、浏览器等属性，例如下面所示：

GET http://www.xxx.com/form.html  HTTP/1.1 (CRLF)
... ...
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 (CRLF)
Host:www.xxx.com (CRLF)
Connection:Keep-Alive (CRLF)
(CRLF)

响应报头

响应报头使服务器能够传递额外的响应信息，这些信息无法直接放在状态行中。这些报头不仅包含关于服务器的详细信息，还提供了对请求URI所标识资源的进一步访问指导。

Location

Location响应报头域在网络通信中发挥着关键作用，其主要用途在于指导信息的接收者转向一个新的位置，在域名发生变更时，通过Location响应报头域可以有效地将用户或系统重定向至新的域名地址，确保信息的连续性和准确性。

Server

Server响应报头域承载着服务器处理请求时所依赖的软件信息，它与User-Agent请求报头域形成了互补关系。前者提供了服务器端的软件详情，而后者则揭示了发起请求的用户端环境信息，两者共同构成了网络通信中重要的信息交互环节。

Content-Encoding

Content-Encoding 实体报头域作为媒体类型的修饰符，其值用以标明附加至实体正文内容的编码方式。

在获取 Content-Type 报头域中提及的媒体类型时，需运用相应的解码机制以正确解读。Content-Encoding 的主要应用在于记录文档的压缩方法。

例如，当其值为“Content-Encoding：gzip”时，即表示文档采用了 gzip 压缩格式，提高了网络资源的利用效率。

Content-Language

Content-Language 实体报头域用于标明资源所采用的自然语言。

若该域未被设置，则默认实体内容面向所有语言的读者。这一设计有助于确保信息在不同语言背景下都能得到准确传达，从而提升了用户体验和信息的可达性。

常见配置

• Host: example.com：说明了请求的目标主机。
• User-Agent：提供了发起请求的客户端信息，有助于服务器进行兼容性处理或日志记录。
• Accept：告诉服务器客户端能够处理哪些类型的响应内容。
• Accept-Encoding 和 Accept-Language 分别指示了客户端支持的编码格式和语言偏好。
• Content-Type：说明了请求正文的媒体类型，这里是application/x-www-form-urlencoded，表示表单数据以URL编码的形式发送。
• Content-Length：指明了请求正文的长度。
• Connection: keep-alive：表示客户端希望使用持久连接。

简单案例

POST /login HTTP/1.1
Host: example.com
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
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Connection: keep-alive

注意：特此声明：本文章首发文章在掘金：https://juejin.cn/post/7356867483829583881，未经允许，请勿进行侵权私自转载。