本学习笔记参考尚硅谷、菜鸟教程、MDN等教程。
快速入门：HTTP 教程 | 菜鸟教程 (runoob.com)
详细解答：HTTP | MDN (mozilla.org)
简介
**HTTP（超文本传输协议，Hypertext Transfer Protocol）**是一种用于从网络传输超文本到本地浏览器的传输协议。它定义了客户端与服务器之间请求和响应的格式。HTTP 工作在 TCP/IP 模型之上，通常使用端口 80。
**HTTPS（超文本传输安全协议，Hypertext Transfer Protocol Secure）**是 HTTP 的安全版本，它在 HTTP 下增加了 SSL/TLS 协议，提供了数据加密、完整性校验和身份验证。HTTPS 通常使用端口 443。
HTTP
HTTP 协议是 Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（ WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。
HTTP 是一个基于 TCP/IP 通信协议来传递数据（HTML 文件、图片文件、查询结果等）。
HTTPS
HTTPS 协议是 HyperText Transfer Protocol Secure（超文本传输安全协议）的缩写，是一种通过计算机网络进行安全通信的传输协议。
HTTP 本身是不安全的，因为传输的数据未经加密，可能会被窃听或篡改，为了解决这个问题，引入了 HTTPS，即在 HTTP 上加入 SSL/TLS 协议，为数据传输提供了加密和身份验证。
HTTPS 经由 HTTP 进行通信，但利用 SSL/TLS 来加密数据包，HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换资料的隐私与完整性。
HTTP 的 URL 是由 http:// 起始与默认使用端口 80，而 HTTPS 的 URL 则是由 https:// 起始与默认使用端口443。
发展历程
| 版本 | 历程 |
|---|---|
| HTTP/0.9 | - 蒂姆伯纳斯李是一位英国计算机科学家，也是万维网的发明者。他在 1989 年创建了单行 HTTP 协议。它只是返回一个网页。这个协议在 1991 年被命名为 HTTP/0.9。 |
| HTTP/1.0 | - 1996 年，HTTP/1.0 发布。该规范是显著扩大，并且支持三种请求方法：GET，Head，和POST。 - HTTP/1.0 相对于 HTTP/0.9 的改进如下： 每个请求都附加了 HTTP 版本。 在响应开始时发送状态代码。 请求和响应都包含 HTTP 报文头。 内容类型能够传输 HTML 文件以外的文档。 - 但是，HTTP/1.0 不是官方标准。 |
| HTTP/1.1 | - HTTP 的第一个标准化版本 HTTP/1.1 ( RFC 2068 ) 于 1997 年初发布，支持七种请求方法：OPTIONS，GET，HEAD，POST，PUT，DELETE，和TRACE - HTTP/1.1 是 HTTP 1.0 的增强： 虚拟主机允许从单个 IP 地址提供多个域。 持久连接和流水线连接允许 Web 浏览器通过单个持久连接发送多个请求。 缓存支持节省了带宽并使响应速度更快。 - HTTP/1.1 在接下来的 15 年左右将非常稳定。 - 在此期间，出现了 HTTPS（安全超文本传输协议）。它是使用 SSL/TLS 进行安全加密通信的 HTTP 的安全版本。 |
| HTTP/2 | - 由IETF在2015年发布。HTTP/2旨在提高Web性能，减少延迟，增加安全性，使Web应用更加快速、高效和可靠。 多路复用：HTTP/2 允许同时发送多个请求和响应，而不是像 HTTP/1.1 一样只能一个一个地处理。这样可以减少延迟，提高效率，提高网络吞吐量。 - 二进制传输：HTTP/2 使用二进制协议，与 HTTP/1.1 使用的文本协议不同。二进制协议可以更快地解析，更有效地传输数据，减少了传输过程中的开销和延迟。 - 头部压缩：HTTP/2 使用 HPACK 算法对 HTTP 头部进行压缩，减少了头部传输的数据量，从而减少了网络延迟。 - 服务器推送：HTTP/2 支持服务器推送，允许服务器在客户端请求之前推送资源，以提高性能。 - 改进的安全性：HTTP/2 默认使用 TLS（Transport Layer Security）加密传输数据，提高了安全性。 - 兼容 HTTP/1.1：HTTP/2 可以与 HTTP/1.1 共存，服务器可以同时支持 HTTP/1.1 和 HTTP/2。如果客户端不支持 HTTP/2，服务器可以回退到 HTTP/1.1。 |
| HTTP/3 | - 于 2021 年 5 月 27 日发布 , HTTP/3 是一种新的、快速、可靠且安全的协议，适用于所有形式的设备。 - HTTP/3 没有使用 TCP，而是使用谷歌在 2012 年开发的新协议 QUIC HTTP/3 是继 HTTP/1.1 和 HTTP/2之后的第三次重大修订。 - HTTP/3 带来了革命性的变化，以提高 Web 性能和安全性。设置 HTTP/3 网站需要服务器和浏览器支持。 - 目前，谷歌云、Cloudflare和Fastly支持 HTTP/3。Chrome、Firefox、Edge、Opera 和一些移动浏览器支持 HTTP/3。 |
HTTP1.0和HTTP1.1的区别
在HTTP1.0版本中，浏览器请求一个带有图片的网页，会由于下载图片而与服务器之间开启一个新的连接；但在HTTP1.1版本中，允许浏览器在拿到当前请求对应的全部资源后再断开连接，提高了效率。
HTTP 工作原理
HTTP 协议工作于客户端-服务端架构上。
HTTP 工作过程通常如下：
- 客户端发起请求：用户通过客户端（如浏览器）输入 URL，客户端向服务器发起一个 HTTP 请求。
- 服务器处理请求：服务器接收到请求后，根据请求的类型（如GET、POST等）和请求的资源，进行相应的处理。
- 服务器返回响应：服务器将处理结果包装成HTTP响应消息，发送回客户端。
- 客户端渲染页面：客户端接收到响应后，根据响应内容（如HTML、图片等）渲染页面，展示给用户。
Web 服务器有：Nginx 服务器，Apache 服务器，IIS 服务器（Internet Information Services）等。
HTTP 三点注意事项：
- HTTP 是无连接：无连接的含义是限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。
- HTTP 是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送，客户端以及服务器指定使用适合的 MIME-type 内容类型。
- HTTP 是无状态：HTTP 协议是无状态协议，无状态是指协议对于事务处理没有记忆能力，缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大，另一方面，在服务器不需要先前信息时它的应答就较快。
以下图表展示了 HTTP 协议通信流程：
会话方式
HTTP 的基本工作原理是客户端（通常是 web 浏览器）向服务器发送请求，服务器接收到请求后，返回相应的资源。这些资源可以是网页、图像、音频文件、视频等。
HTTP 使用了客户端-服务器模型，其中客户端发送请求，服务器返回响应。
HTTP 的请求-响应模型通常由以下几个步骤组成：
- 建立连接：客户端与服务器之间建立连接。在传统的 HTTP 中，这是基于 TCP/IP 协议的。最近的 HTTP/2 和 HTTP/3 则使用了更先进的传输层协议，例如基于 TCP 的二进制协议（HTTP/2）或基于 UDP 的 QUIC 协议（HTTP/3）。
- 发送请求：客户端向服务器发送请求，请求中包含要访问的资源的 URL、请求方法（GET、POST、PUT、DELETE 等）、请求头（例如，Accept、User-Agent）以及可选的请求体（对于 POST 或 PUT 请求）。
- 处理请求：服务器接收到请求后，根据请求中的信息找到相应的资源，执行相应的处理操作。这可能涉及从数据库中检索数据、生成动态内容或者简单地返回静态文件。
- 发送响应：服务器将处理后的结果封装在响应中，并将其发送回客户端。响应包含状态码（用于指示请求的成功或失败）、响应头（例如，Content-Type、Content-Length）以及可选的响应体（例如，HTML 页面、图像数据）。
- 关闭连接：在完成请求-响应周期后，客户端和服务器之间的连接可以被关闭，除非使用了持久连接（如 HTTP/1.1 中的 keep-alive）。
HTTP 方法
HTTP 方法指定了客户端可以对服务器上的资源执行哪些动作。
主要的HTTP方法有：
| 方法 | 描述 |
|---|---|
| GET | 从服务器获取资源。用于请求数据而不对数据进行更改。例如，从服务器获取网页、图片等。 |
| POST | 向服务器发送数据以创建新资源。常用于提交表单数据或上传文件。发送的数据包含在请求体中。 |
| PUT | 向服务器发送数据以更新现有资源。如果资源不存在，则创建新的资源。与 POST 不同，PUT 通常是幂等的，即多次执行相同的 PUT 请求不会产生不同的结果。 |
| DELETE | 从服务器删除指定的资源。请求中包含要删除的资源标识符。 |
| PATCH | 对资源进行部分修改。与 PUT 类似，但 PATCH 只更改部分数据而不是替换整个资源。 |
| HEAD | 类似于 GET，但服务器只返回响应的头部，不返回实际数据。用于检查资源的元数据（例如，检查资源是否存在，查看响应的头部信息）。 |
| OPTIONS | 返回服务器支持的 HTTP 方法。用于检查服务器支持哪些请求方法，通常用于跨域资源共享（CORS）的预检请求。 |
| TRACE | 回显服务器收到的请求，主要用于诊断。客户端可以查看请求在服务器中的处理路径。 |
| CONNECT | 建立一个到服务器的隧道，通常用于 HTTPS 连接。客户端可以通过该隧道发送加密的数据。 |
HTTP 消息
HTTP 消息是服务器和客户端之间交换数据的方式。有两种类型的消息：请求（request）——由客户端发送用来触发一个服务器上的动作；响应（response）——来自服务器的应答。
HTTP 消息由采用 ASCII 编码的多行文本构成。在 HTTP/1.1 及早期版本中，这些消息通过连接公开地发送。在 HTTP/2 中，为了优化和性能方面的改进，曾经可人工阅读的消息被分到多个 HTTP 帧中。
Web 开发人员或网站管理员，很少自己手工创建这些原始的 HTTP 消息：由软件、浏览器、代理或服务器完成。他们通过配置文件（用于代理服务器或服务器），API（用于浏览器）或其他接口提供 HTTP 消息。
HTTP 请求和响应具有相似的结构，由以下部分组成：
- 一行起始行用于描述要执行的请求，或者是对应的状态，成功或失败。这个起始行总是单行的。
- 一个可选的 HTTP 标头集合指明请求或描述消息主体（body）。
- 一个空行指示所有关于请求的元数据已经发送完毕。
- 一个可选的包含请求相关数据的主体（比如 HTML 表单内容），或者响应相关的文档。主体的大小有起始行的 HTTP 头来指定。
起始行和 HTTP 消息中的 HTTP 头统称为请求头，而其有效负载被称为消息主体。
客户端请求消息
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。
-
请求行（Request Line）：
- 方法：如 GET、POST、PUT、DELETE等，指定要执行的操作。
- 请求 URI（统一资源标识符）：请求的资源路径，通常包括主机名、端口号（如果非默认）、路径和查询字符串。
- HTTP 版本：如 HTTP/1.1 或 HTTP/2。
请求行的格式示例：
GET /index.html HTTP/1.1 -
请求头（Request Headers）：
- 通用标头（General header），例如 Via，适用于整个消息。
- 请求标头（Request header），例如 User-Agent、Accept-Type，通过进一步的定义（例如 Accept-Language）、给定上下文（例如 Referer）或者进行有条件的限制（例如 If-None）来修改请求。
- 表示标头（Representation header），例如 Content-Type 描述了消息数据的原始格式和应用的任意编码（仅在消息有主体时才存在）。
-
空行：
- 请求头和请求体之间的分隔符，表示请求头的结束。
-
请求体（可选）：
- 在某些类型的HTTP请求（如 POST 和 PUT）中，请求体包含要发送给服务器的数据。
服务器响应消息
HTTP 响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。
-
状态行（Status Line）：
- HTTP 版本：与请求消息中的版本相匹配。
- 状态码：三位数，表示请求的处理结果，如 200 表示成功，404 表示未找到资源。
- 状态信息：状态码的简短描述。
状态行的格式示例：
HTTP/1.1 200 OK -
响应头（Response Headers）：
- 通用标头（General header），例如 Via，适用于整个消息。
- 响应标头（Response header），例如 Vary 和 Accept-Ranges，提供有关服务器的其他信息，这些信息不适合状态行。
- 表示标头（Representation header），例如 Content-Type 描述了消息数据的原始格式和应用的任意编码（仅在消息有主体时才存在）。
-
空行：
- 响应头和响应体之间的分隔符，表示响应头的结束。
-
响应体（可选）：
- 包含服务器返回的数据，如请求的网页内容、图片、JSON数据等。
HTTP 响应头信息
HTTP 响应头信息是服务器在响应客户端的HTTP请求时发送的一系列头字段，它们提供了关于响应的附加信息和服务器的指令。
以下是一些常见的 HTTP 响应头信息：
| 响应头信息（英文） | 响应头信息（中文） | 描述 |
|---|---|---|
| Date | 日期 | 响应生成的日期和时间。例如：Wed, 18 Apr 2024 12:00:00 GMT |
| Server | 服务器 | 服务器软件的名称和版本。例如：Apache/2.4.1 (Unix) |
| Content-Type | 内容类型 | 响应体的媒体类型（MIME类型），如text/html; charset=UTF-8, application/json等。 |
| Content-Length | 内容长度 | 响应体的大小，单位是字节。例如：3145 |
| Content-Encoding | 内容编码 | 响应体的压缩编码，如 gzip, deflate等。 |
| Content-Language | 内容语言 | 响应体的语言。例如：zh-CN |
| Content-Location | 内容位置 | 响应体的 URI。例如：/index.html |
| Content-Range | 内容范围 | 响应体的字节范围，用于分块传输。例如：bytes 0-999/8000 |
| Cache-Control | 缓存控制 | 控制响应的缓存行为, 如 no-cache 表示必须重新请求。 |
| Connection | 连接 | 管理连接的选项，如keep-alive或close，keep-alive 表示连接不会在传输后关闭。。 |
| Set-Cookie | 设置 Cookie | 设置客户端的 cookie。例如：sessionId=abc123; Path=/; Secure |
| Expires | 过期时间 | 响应体的过期日期和时间。例如：Thu, 18 Apr 2024 12:00:00 GMT |
| Last-Modified | 最后修改时间 | 资源最后被修改的日期和时间。例如：Wed, 18 Apr 2024 11:00:00 GMT |
| ETag | 实体标签 | 资源的特定版本的标识符。例如：“33a64df551425fcc55e6” |
| Location | 位置 | 用于重定向的 URI。例如：/newresource |
| Pragma | 实现特定的指令 | 包含实现特定的指令，如 no-cache。 |
| WWW-Authenticate | 认证信息 | 认证信息，通常用于HTTP认证。例如：Basic realm=“Access to the site” |
| Accept-Ranges | 接受范围 | 指定可接受的请求范围类型。例如：bytes |
| Age | 经过时间 | 响应生成后经过的秒数，从原始服务器生成到代理服务器。例如：24 |
| Allow | 允许方法 | 列出资源允许的 HTTP 方法 。例如：GET, POST，HEAD等 |
| Vary | 变化 | 告诉下游代理如何使用响应头信息来确定响应是否可以从缓存中获取。例如：Accept |
| Strict-Transport-Security | 严格传输安全 | 指示浏览器仅通过 HTTPS 与服务器通信。例如：max-age=31536000; includeSubDomains |
| X-Frame-Options | 框架选项 | 控制页面是否允许在框架中显示，防止点击劫持攻击。例如：SAMEORIGIN |
| X-Content-Type-Options | 内容类型选项 | 指示浏览器不要尝试猜测资源的 MIME 类型。例如：nosniff |
| X-XSS-Protection | XSS保护 | 控制浏览器的 XSS 过滤和阻断。例如：1; mode=block |
| Public-Key-Pins | 公钥固定 | HTTP 头信息，用于HTTP公共密钥固定（HPKP），一种安全机制，用于防止中间人攻击。例如：pin-sha256=“base64+primarykey”; pin-sha256=“base64+backupkey”; max-age=expireTime |
这些响应头信息在实际的 HTTP 响应中可能会有所不同，具体值取决于服务器的配置和处理逻辑。
HTTP 状态码分类
HTTP 状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型。响应分为五类：信息响应(100–199)，成功响应(200–299)，重定向(300–399)，客户端错误(400–499)和服务器错误 (500–599)：
| 分类 | 分类描述 |
|---|---|
| 1** | 信息，服务器收到请求，需要请求者继续执行操作 |
| 2** | 成功，操作被成功接收并处理 |
| 3** | 重定向，需要进一步的操作以完成请求 |
| 4** | 客户端错误，请求包含语法错误或无法完成请求 |
| 5** | 服务器错误，服务器在处理请求的过程中发生了错误 |
HTTP状态码列表:
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed（预期失败） | 服务器无法满足请求头中 Expect 字段指定的预期行为。 |
| 418 | I’m a teapot | 状态码 418 实际上是一个愚人节玩笑。它在 RFC 2324 中定义，该 RFC 是一个关于超文本咖啡壶控制协议（HTCPCP）的笑话文件。在这个笑话中，418 状态码是作为一个玩笑加入到 HTTP 协议中的。 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
883
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
