驻马店专业做网站公司,织梦手机网站有广告位,广州市建设工程安监站网站,郴州seo注#xff1a;本文为 “HTTP 历史 | 协议报文结构 | 返回状态码” 相关文章合辑。
未整理去重。 HTTP 历史
wangjunliang 最后更新: 2024/3/16 上午10:29
超文本传输协议(英语:HyperTextTransferProtocol,缩写:HTTP)是 万维网(World Wide Web)的基础协议#xff61;自 蒂姆…注本文为 “HTTP 历史 | 协议报文结构 | 返回状态码” 相关文章合辑。
未整理去重。 HTTP 历史
wangjunliang 最后更新: 2024/3/16 上午10:29
超文本传输协议(英语:HyperTextTransferProtocol,缩写:HTTP)是 万维网(World Wide Web)的基础协议自 蒂姆伯纳斯-李 (Tim BernersLee)博士和他的团队在 1989-1991 年间创造出它以来,HTTP 已经发生了太多的变化,在保持协议简单性的同时,不断扩展其灵活性如今,HTTP 已经从一个只在实验室之间交换文档的早期协议进化到了可以传输图片,高分辨率视频和 3D 效果的现代复杂互联网协议
HTTP 的诞生
1989 年 3 月 [欧洲核子研究组织](https://zh.wikipedia.org/wiki/ 歐洲核子研究組織)CERN的 [蒂姆・伯纳斯 - 李 ](https://zh.wikipedia.org/wiki/ 提姆・柏內茲 - 李)Tim BernersLee博士提出了一种能让远隔两地的研究者们共享知识的设想。 最初设想的基本理念是借助多文档之间相互关联形成的超文本HyperText连成可相互参阅的 WWWWorld Wide Web万维网。 蒂姆最初的提议。图片来源欧洲核子研究中心
到 1990 年 10 月Tim 编写了三项基本技术来实现设想这些技术仍然是当今网络的基础您可能已经在网络浏览器的某些部分上看到过这些技术 HTMLHyperText Markup Language超文本标记语言作为编写文档的语言。 HTTPHyperText Transfer Protocol超文本传输协议作为传递文档的协议。 URLUniform Resource Locator统一资源标识符一种唯一的 “地址”用于标识文档在网络上的位置。
此外 Tim 还编写了第一个网页编辑器 / 浏览器“WorldWideWeb.app”和第一个 Web 服务器“httpd”。至此 Tim 初步完成了他的设想的所有技术实现且第一批服务器已经在 1991 年初在 CERN 以外的地方运行了1991 年 8 月 16 日Tim Berners-Lee 在公开的超文本新闻组上 发表 的文章被视为是万维网公共项目的开始。
对于 HTTP 而言 在应用的早期阶段它是非常简单的后来它也被称为 HTTP/0.9有时也叫做单行 hangone-line协议。
HTTP/0.9—— 单行协议 (1991)
最初版本的 HTTP 协议并没有版本号后来它的版本号被定位在 0.9 以区分后来的版本。HTTP/0.9 于 1991 年提出。它是有史以来最简单的协议它的请求由单行指令构成因此也称为单行协议以唯一可用方法 GET 开头其后跟目标资源的路径一旦连接到服务器协议、服务器、端口号这些都不是必须的。
http
GET /index.html
响应也极其简单的只包含 HTML 文档本身。
html
HTML
这是一个非常简单的 HTML 页面
/HTML跟后来的版本不同HTTP/0.9 的响应内容并不包含 HTTP 头。这意味着只有 HTML 文件可以传送无法传输其他类型的文件。也没有状态码或错误代码。一旦出现问题一个特殊的包含问题描述信息的 HTML 文件将被发回供人们查看。
特性 它是 ASCII 协议请求 / 响应都是由 ASCII 字符组成字符串。 它在 TCP/IP 链路上运行。 请求以回车符 (CRLF) 终止。 响应只包含 HTML 文档。 文档传输完成后TCP 连接将终止。
缺陷 只支持 GET 请求 HTTP/0.9 仅支持 GET 方法意味着只能用于获取资源不能用于其他类型的请求如 POST、PUT、DELETE 等。这导致在处理复杂的应用逻辑和实现数据更新等操作时HTTP/0.9 显得非常有限。 只能传输 HTML HTTP/0.9 的响应只能包含 HTML 文档无法处理其他类型的数据如 JSON、XML、图像等。这限制了其在处理现代 Web 应用程序中的数据传输和交互能力。 无法进行内容协商 HTTP/0.9 没有头部信息无法携带元数据如 Content-Type、Content-Length 等这使得它无法识别并正确解析其他响应内容。 没有状态码或错误代码 也是由于 HTTP/0.9 没有头部信息无法携带元数据因此响应成功与失败都是返回 HTML 文档这使得浏览器不能知晓请求执行成功或失败并相应调整行为。 不支持持久连接 在 HTTP/0.9 中每次请求都会建立一个新的 TCP 连接请求完成后立即关闭连接。这导致在处理大量请求时频繁地建立和关闭连接会带来较大的开销影响性能。 安全性问题 HTTP/0.9 没有提供任何加密和安全机制所有的数据都是明文传输。这使得数据容易受到窃听和篡改缺乏对隐私和数据完整性的保护。 只能传输英文文本数据 HTTP/0.9 默认采用的字符集是 ASCII 字符集这意味着 HTTP 只能传输英文文本数据无法支持其他语言的文本数据比如包含非英文字符的文本如中文、日文、俄文等。
正如你们所看到的HTTP/0.9 仅适用于简单的、仅需要获取 HTML 文档的场景。新兴 Web 所需功能及其在公共 Web 上的用例不断增长很快就强化了 HTTP 0.9 的许多缺陷我们需要一个协议该协议不仅可以服务于超文本文档还可以提供有关请求和响应的更丰富的元数据。
很快HTTP 的下一个版本即 HTTP/1.0被推出它解决了 HTTP/0.9 的缺陷并提供更多强大的功能和性能优化。
HTTP/1.0—— 构建可扩展性 (1996)
1996 年 5 月HTTP 工作组 (HTTP-WG) 发布了 RFC 1945文档 RFC 1945 定义了 HTTP/1.0但它是狭义的并不是官方标准。
HTTP/1.0 通过定义了 HTTP 请求 / 响应的结构加入许多头部信息现在可以处理其他响应格式即图像、视频文件、纯文本或任何其他内容类型。它添加了更多方法即 POST 和 HEAD、添加了状态代码来标识响应、引入了字符集、类型、授权、缓存、内容编码等内容。
以下为 HTTP/1.0 的请求示例
GET / HTTP/1.0
Host: cs.fyi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*以下为 HTTP/1.0 的响应示例
HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
(response body)
(connection closed)HTTP/1.0 的请求与响应现在看起来也是非常熟悉的因为它首次定义了请求 / 响应的格式我们沿用至今并且由于加入头信息使得内容协商变得容易起来这也极大的丰富了它的扩展性虽然请求和响应标头仍保留为 ASCII 编码但响应正文可以是任何类型即图像、视频、HTML、纯文本或任何其他内容类型。因此现在服务器不仅仅只能向客户端发送 HTML 文档还可以发送其他任何内容类型推出后不久HTTP 中的 “超文本” 一词就变得用词不当。HMTP 或超媒体传输协议可能更有意义但我想我们终生都坚持这个名字。
请求与响应头仍是 ASCII 编码那么其中的中文是如何处理的呢
我们都知道 ASCII 编码仅表示了英文小大写、数字以及一些标点符号对于其他国家的语言是并不支持的那么请求头中的其他国家的语言的信息如何处理呢
我尝试使用浏览器访问以中文命名的 HTMLURLwangjunliang.com/我想看看.html
请求网址:
https://www.wangjunliang.com/% E6%88%91% E6%83% B3% E7%9C%8B% E7%9C%8B.html请求方法:
GET状态代码:
200远程地址:
127.0.0.1:7890引荐来源网址政策:
strict-origin-when-cross-origin惊奇的发现在请求头中 我想看看 转换为了 %E6%88%91%E6%83%B3%E7%9C%8B%E7%9C%8B这就是传说中的 URL 编码。
URL 编码 URL 编码是一种将特殊字符和非 ASCII 字符转换为 ASCII 字符的方法使它们能够在 HTTP 请求的 URL 中进行传输。具体而言URL 编码使用 “%” 符号后跟两个十六进制数字来表示一个字符。例如中文字符 “中” 的 URL 编码表示为 “% E4% B8% AD”。这个编码表示了字符 “中” 在 ASCII 字符集中的十六进制表示。当 HTTP/1.0 的请求或响应中包含中文字符时这些字符会被转换成对应的 URL 编码形式。服务器收到 URL 编码后的请求后会将其还原为原始的中文字符进行处理。需要注意的是HTTP/1.0 的 URL 编码仅适用于 URL 中的字符编码。
神奇的 base64—— 在 ASCII 上传输任何内容
在 HTTP 的早期版本如 HTTP/0.9 和 HTTP/1.0由于对字符集的限制以及内容协商机制缺失与不完善直接传输二进制数据或非 ASCII 字符是有挑战的。为了在这些早期版本的 HTTP 中传输图片或其他二进制数据人们使用了将二进制数据转换为 ASCII 字符的编码方式 ——base64。
base64 编码 是一种将二进制数据转换成 ASCII 码中 64 个字符A-Z、a-z、0-9 和 、/ 两个符号的文本编码方式。
在 Base64 编码中原始二进制数据每 3 个字节的二进制数据被分成 4 组每组 6 位然后分别转换成 4 个 ASCII 字符。也就是说原始数据每 6 位将会被转换成一个 ASCII 字符而一个 ASCII 字符占用空间则是 8 位因此编码后的数据大小会增加约 1/3
原始数据 (占用空间24 位)base64 编码编码后二进制数据 (占用空间32 位)100100 101001 100100 101001kpkp01101011 01110000 01101011 01110000
如果待编码的二进制数据长度不是 3 的倍数Base64 编码会在末尾添加 1 或 2 个填充字符 “”以确保编码后的文本长度是 4 的倍数。这进一步增加了数据的大小。
特性 定义了请求 / 响应格式 HTTP/1.0 将请求 / 响应格式划分为了三个部分 —— 起始行、头部信息、消息体这个格式一直沿用至今。 加入了状态码和状态描述 在响应的起始行中加入了状态代码和状态的描述信息提供了关于请求处理结果的信息以便客户端和服务器能够进行适当的处理和决策。 加入了内容协商 虽然在 HTTP/1.0 中起始行与头部信息都保留为 ASCII 编码但它通过加入了 Content-Type、Content-Length、Transfer-Encoding 等头部属性可以对不同类型的文件在消息体中进行不同的编码。也就是说起始行、头部信息传输仍是 ASCII 编码而消息体则会根据头部属性让客户端 / 服务器进行内容协商进行不同的编码方式。 可以传输任何文件 由于 HTTP/1.0 加入了内容协商的机制使得只要客户端 / 服务器协商一致HTTP/1.0 就可以传输任何形式的文件。 新增 POST、HEAD 请求 POST 请求方法允许客户端向服务器提交数据而 HEAD 请求方法允许客户端获取资源的元数据。这些新增的请求方法丰富了 HTTP 协议的能力使得客户端和服务器能够进行更多样化的交互和处理。 不再只是传输英文文本数据 HTTP/1.0 引入字符集Character Set解决了其他国家语言文本数据的字符编码问题并确保文本数据能够以正确的方式被处理和显示。 初步引入缓存概念 HTTP/1.0 引入了头部字段如 Expires 和 Last-Modified用于控制缓存的行为以及头部字段如 If-Modified-Since 和 If-None-Match用于条件性请求。 初步引入持久链接 HTTP/1.0 引入一个名为 Connection: keep-alive 的新标头来保持请求建立起来的 TCP 连接以供后续请求继续使用该链接完成请求。 初步引入代理支持 HTTP/1.0 引入了 Proxy-Connection 头部字段来指示代理服务器是否应保持持久连接并引入了 Via 头部字段用于标识请求经过的代理服务器链。
缺陷 持久链接未得到广泛支持默认仍为短连接 HTTP/1.0 的尝试通过引入一个名为 Connection: keep-alive 的新标头来克服短连接问题但它仍然没有得到广泛的支持问题仍然存在。 请求阻塞 在 HTTP/1.0 中每个请求都需要按照顺序进行即必须等待前一个请求的响应返回后才能发送下一个请求。如果前一个请求很耗时会导致后续请求被阻塞影响并发性能。 无状态 HTTP 是一种无状态协议即服务器不维护有关客户端的信息当客户端需要记录状态时必须发送一些记录状态的冗余数据从而导致带宽使用量增加。 缺乏压缩支持 HTTP/1.0 没有内置的数据压缩机制因此在传输大量文本数据时没有有效地压缩数据增加了网络传输的开销。 安全性问题 HTTP/1.0 没有提供任何加密和安全机制所有的数据都是明文传输。这使得数据容易受到窃听和篡改缺乏对隐私和数据完整性的保护。 实现混乱 由于 HTTP/1.0 并不是官方标准许多浏览器厂商并没有按照 HTTP/1.0 的指导实现 HTTP导致在实际运用中混乱不堪。
可以看到对于 HTTP/0.9 人们诟病的是它的文件类型支持不够丰富由于它的文件类型支持不丰富所有通常只是请求 HTML 文档往往发送一次请求就能获取到完整的内容。而在 HTTP/1.0 丰富了文件类型后一次请求不再能获取到全部内容并且请求的内容也从较小的 HTML 文档发展到了图片、音频、视频等较大的文件此时 HTTP 的性能问题也被暴露出来。
此外由于各个浏览器相互竞争各自为战并且 HTTP/1.0 并不是官方标准只是一些指导意见。这导致各个厂商对于 HTTP 都有各自的实现方式导致在实际运用中混乱不堪。
由于上述原因人们迫切需要优化 HTTP 性能制定一份标准化 HTTP 协议
HTTP/1.1—— 标准化的协议 (1997)
HTTP/1.0 多种不同的实现方式在实际运用中显得有些混乱。自 1995 年开始即 HTTP/1.0 文档发布的下一年就开始修订 HTTP 的第一个标准化版本。 在 1997 年 1 月 HTTP1.1 标准以 RFC 2068 文件发布后续 HTTP/1.1 协议进行过两次修订分别是 RFC 2616 发布于 1999 年 6 月以及 RFC 7230-RFC 7235 发布于 2014 年 6 月。
HTTP/1.1 标准消除了早期版本中大量歧义内容并引入了许多关于性能优化的措施持久链接、管道化技术、支持范围请求和部分响应、分块传输机制、明确缓存控制机制、增加压缩技术、增强内容协商机制、增加客户端 cookie 等。除了改进 HTTP 性能方面 HTTP/1.1 还新增状态码、引入了基本认证和摘要认证提供更强大的用户认证机制确保更安全的通信、 引入了 Host 头字段该字段允许在同一个物理服务器上托管多个域名。这使得虚拟主机能够通过在 Host 头中指定域名来区分不同的网站、并且它还新增了许多请求方法极大丰富了请求类型。
以下为HTTP/1.1 的请求示例
http
GET /zh-CN/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8
Accept-Language: en-US,en;q0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/zh-CN/docs/Glossary/Simple_header以下为HTTP/1.1 的响应示例
http
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charsetutf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: 547fa7e369ef56031dd3bff2ace9fc0832eb251a
Keep-Alive: timeout5, max1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding我们可以看到在请求 / 响应格式上 HTTP/1.1 与 HTTP/1.0 并无差异这是因为 HTTP/1.1 沿用了 HTTP/1.0 的请求 / 响应格式。
特性 持久化连接 在 HTTP/1.0 中持久连接默认为关闭并没有得到广泛应用而在 HTTP/1.1 中连接默认情况下不会关闭而是保持打开状态从而允许多个顺序请求。要关闭连接请求头 Connection: close 必须可用。客户端通常在最后一个请求中发送此标头以安全地关闭连接。 管道化技术 HTTP/1.1 引入了管道化技术以解决请求阻塞问题客户端可以在同一连接上向服务器发送多个请求而无需等待服务器的响应并且服务器必须按照接收请求的顺序发送响应。 新增客户端 Cookie 由于 HTTP 是无状态协议当客户端需要记录状态时必须发送一些记录状态的冗余数据从而导致带宽使用量增加。HTTP/1.1 引入了客户端 cookie 以解决该问题通过在浏览器中设置 cookie服务器可以跟踪用户会话状态实现用户身份认证个性化用户体验等。 新增 Gzip、Deflate 等压缩技术 在 HTTP/1.1 中服务器可以使用 Gzip、Deflate 等压缩算法来压缩 HTTP 响应的实体主体部分如 HTML、CSS、JavaScript 等然后在响应头中使用 “Content-Encoding” 字段来指示客户端该响应已经被压缩以及压缩的算法。客户端收到压缩的响应后会自动解压缩以获取原始内容。 引入了基本认证和摘要认证机制 在 HTTP/1.1 中可以通过基本认证和摘要认证机制在请求头中传递用户名和密码等凭据进行用户身份验证。 引入了范围请求和部分响应机制 HTTP/1.1 引入了范围请求和部分响应的功能通过在 HTTP 请求头中使用 “Range” 字段指定所需的资源范围而服务器在响应头中使用 “206 Partial Content” 状态码表明返回的是部分响应并通过 “Content-Range” 字段指示返回内容的字节范围。这使得客户端可以请求大文件的特定部分例如断点续传的情况下从而避免重新下载整个文件。此外范围请求还能让客户端只获取媒体资源的特定片段优化数据传输并提升用户体验。 引入了分块传输机制 HTTP/1.1 引入了分块传输Chunked Transfer Encoding机制用于在动态内容传输时服务器无法提前确定整个内容的长度的情况下逐块发送内容。在分块传输中服务器将响应拆分为一系列块每个块都有一个独立的大小并使用 “Transfer-Encoding: chunked” 请求头来通知客户端有关分块传输的信息。客户端接收到该头信息后知道响应将以分块的形式传输它可以按照指定的块大小逐块接收内容直到接收到一个长度为零的块表示传输已完成。这种机制适用于动态生成内容、流式传输以及服务器长时间运行的响应等场景提供了更灵活和高效的数据传输方式。 明确缓存机制 HTTP/1.1 在 HTTP/1.0 的基础上进一步明确了缓存机制服务器可以通过设置响应头字段来控制缓存行为例如使用 “Cache-Control” 头字段来指定缓存策略如 “max-age” 用于设置资源的最大缓存时间“no-cache” 用于要求客户端验证资源的有效性等。同时服务器也可以在响应头中添加 “Expires” 头字段设置资源的过期时间以便客户端在接收到资源后在过期时间之前可以直接使用缓存的副本。另外HTTP/1.1 还支持 “Last-Modified” 和 “If-Modified-Since” 头字段以及 “ETag” 和 “If-None-Match” 头字段用于在客户端缓存资源后再次请求时验证资源是否已经发生变化如果未变化服务器返回 304 Not Modified 状态码让客户端使用缓存的资源从而避免重复传输。通过这些头字段的灵活组合使用HTTP/1.1 的缓存机制实现了更高效、可控的缓存管理优化了 Web 应用程序的性能和用户体验。 增强内容协商机制 HTTP/1.1 增加了 Accept-Language、Accept-Encoding 和 Accept-Charset 等头字段允许客户端明确指定其首选语言、内容编码方式和字符集让服务器能够更好地提供适配客户端需求的内容。此外HTTP/1.1 还引入了 Vary 头字段用于标明服务器响应可能因客户端请求头的不同而变化这样确保代理服务器能够存储和提供正确的缓存内容。这些改进使得 HTTP/1.1 的内容协商机制更加强大和智能提高了资源传输的效率和用户体验。 添加了新的 HTTP 方法 HTTP/1.1 新增了 PUT、PATCH、OPTIONS、DELETE 方法。 新增了 Host 头字段 TTP/1.1 引入了 Host 头字段该字段允许在同一个物理服务器上托管多个域名。这使得虚拟主机能够通过在 Host 头中指定域名来区分不同的网站。 新增了状态码
缺陷 线头阻塞Head-of-Line Blocking HTTP/1.1 在同一连接上使用持久连接但由于串行发送请求和响应如果一个请求或响应的处理时间较长那么后续的请求和响应将被阻塞为此它引入了管道化技术 (pipelining) 试图解决该问题但它并没有完全解决这个问题因为即使在客户端请求选择某一管道并被异步发送出去但在服务器如果该请求前面存在缓慢或繁重的请求那么该请求就会被阻塞。这种情况也被称为线头阻塞 无法处理较多的并发请求 由于头阻塞问题和单个连接的限制HTTP/1.1 在处理较多的并发请求时表现较差。浏览器限制了同时与同一域名建立的连接数针对同一域名的并发请求最多可以同时发送 6 到 8 个如果有超过限制的请求需要发送浏览器会将这些请求放入队列从而限制了并发请求的数量。 未能被充分利用的 TCP HTTP 1.1 很难榨干 TCP 协议所能提供的所有性能。HTTP 客户端和浏览器必须要另辟蹊径的去找到新的解决方案来降低页面载入时间。 明文传输 HTTP/1.1 默认是明文传输数据在网络上传输时不加密可能被窃听或篡改。这会导致安全隐患尤其是对于敏感信息的传输。 头部冗余 HTTP/1.1 的请求和响应头部会携带一些冗余的信息导致了较大的头部开销特别是对于小的资源请求。 没有对头字段进行压缩 HTTP/1.1 没有对头字段进行压缩尽管 HTTP 响应的主体可以使用 Gzip 等压缩算法但头字段仍然是明文传输可能在一些情况下浪费带宽。 请求 - 响应模式 HTTP/1.1 使用请求 - 响应模式每个请求需要等待响应后才能继续。这种模式对于实时性要求较高的应用场景如实时通信和流媒体效率较低。 缺乏推送功能 HTTP/1.1 缺乏服务器主动向客户端推送资源的机制。客户端只能通过不断发送请求来获取资源这导致了一定的延迟和额外的开销。
超过 25 年的逐步扩展
从 HTTP/1.1 协议发布至今HTTP/1.1 协议已稳定使用超过 25 年目前大部分网站仍是基于 HTTP/1.1 来运行的。这期间 HTTP/1.1 也做了多次扩展与修改并发展不同的应用模式以弥补之前的缺陷以及满足日益进步的需求。
HTTP 用于安全传输
在 1994 年网景通信公司Netscape Communications Corporation为了解决当时互联网上数据传输的安全问题发布了第一个安全套接字层Secure Sockets LayerSSL协议。SSL 协议使用了加密技术对 HTTP 的数据进行加密传输保护数据的安全性。
在 SSL 协议的基础上网景通信公司将安全传输的功能整合到 HTTP 协议中形成了 HTTPS 协议。HTTPS 使用了 SSL/TLSTransport Layer Security协议来加密 HTTP 传输过程中的数据使得网站和用户之间的通信不再以明文传输变得安全。
HTTP 用于复杂应用
在 2000 年一种新的使用 HTTP 的模式被设计出来具象状态传输representational state transfer (或者说 REST)。由 API 发起的操作不再通过新的 HTTP 方法传达而只能通过使用基本的 HTTP / 1.1 方法访问特定的 URI。这允许任何 Web 应用程序通过提供 API 以允许查看和修改其数据而无需更新浏览器或服务器。所有需要的内容都被嵌入到由网站通过标准 HTTP/1.1 提供的文件中。REST 模型的缺点在于每个网站都定义了自己的非标准 RESTful API并对其进行了全面的控制。RESTful API 在 2010 年变得非常流行。
自 2005 年以来可用于 Web 页面的 API 大大增加其中几个 API 为特定目的扩展了 HTTP 协议大部分是新的特定 HTTP 头 Server-sent events服务器可以偶尔推送消息到浏览器。 WebSocket一个新协议可以通过升级现有 HTTP 协议来建立。
SPDY——Google 的尝试 (2009)
这些年来网页愈渐变得的复杂甚至演变成了独有的应用可见媒体的播放量增进交互的脚本大小也增加了许多。 如果仔细观察当前的一些网站所需要下载的资源的话会发现一个非常明显的趋势 —— 近年来加载网站首页需要的下载的数据量在逐渐增加平均每个页面为了完成显示与渲染所需要下载的资源数已经超过了 100 个。HTTP/1.1 链接需要请求以正确的顺序发送理论上可以用一些并行的链接尤其是 5 到 8 个带来的成本和复杂性堪忧。比如HTTP 管线化pipelining就成为了 Web 开发的负担。HTTP 1.1 很难榨干 TCP 协议所能提供的所有性能。HTTP 客户端和浏览器必须要另辟蹊径的去找到新的解决方案来降低页面载入时间。与此同时人们也尝试去用新的协议来替代 TCP但结果证明这也非常困难。无奈之下我们只能尝试同时改进 TCP 协议本身和基于 TCP 的上层协议。
在 2010 年早期谷歌通过实践了一个实验性的 SPDY 协议想要以此来解决当前 HTTP 存在的问题。SPDY 的功能包括多路复用、压缩、优先级、安全性等。本节不打算详细介绍 SPDY因为我们在下一节中深入了解 HTTP/2 的本质时您就会明白了HTTP/2 主要是受到 SPDY 的启发。
在 2015 年Google 决定将 SPDY 协议与 HTTP 合并并基于 SPDY 的特点推出了 HTTP/2。通过将 SPDY 融入 HTTP/2Google 希望避免存在两个竞争的标准统一标准有利于更好地推动 Web 协议的发展。同时Google 宣布 SPDY 协议被废弃不再继续作为一个独立的协议存在HTTP/2 成为了 SPDY 的继任者并继续在未来发展和推广。
HTTP/2—— 更优异的性能 (2015)
由于 HTTP/1.1 发展年限久远用户数量庞大因此对于 HTTP/1.1 的升级需要制定非常严格的边界与观念这也给小组成员的创新带来了一些许限制。
升级的边界与观念
必须保持早期 HTTP 的标准范式 由于 HTTP/1.1 使用年限久远用户数量庞大使用该协议的网站太多了如果改动过大且费力这肯定会阻碍 HTTP/2.0 发展。因此 HTTP/2.0 必须保留所有现有的接口、内容、URI 格式和结构 不需要站点和应用做出改变拥有一个最新的服务器和新点的浏览器即可升级 HTTP/2.0。
如上所述现有的 URI 结构正在被 HTTP 1.x 使用而不能被更换所以 http2 也必须沿用该结构。因此不得不找到一种方式将使用的协议升级至 http2
HTTP 1.1 本身就制定过 “升级” 的方案提供一个首部字段表示允许服务器在收到旧协议请求的同时可以向客户端发送新协议的响应。但这一方案往往需要花费一次额外的往返通信来作为升级的代价。
而这一代价是 SPDY 团队不想接受的。因为他们只实现了基于 TLS 的 SPDY所以他们开发了一个 TLS 的扩展去简化协议的协商。这个扩展被称作 NPNNext Protocol Negotiation借助于此服务器会通知客户端所有它支持的协议让客户端从中选择一个合适的来进行通讯。 提供 HTTP1 到 http2 服务器的代理 HTTP1 的服务器和客户端仍然会长期存在所以我们必须提供 HTTP/1 到 http2 服务器的代理并且这种代理能够将 http2 的功能一对一的映射到 HTTP 1.1 的客户端。 不再使用小版本号 服务器和客户端都必须确定自己是否完整兼容 http2 或者彻底不兼容。如果将来该协议需要被扩充或者变更那么新的协议将会是 http3而不是 http 2.x。 降低协议对延迟的敏感 修复 HTTP/1.1 中 pipelining 和 head of line blocking 的问题 防止主机需求更高的连接数量
在确认好升级边界与观念后HTTP/2 协议规范RFC 7540于 2015 年 5 月发表HTTP/2 解决了 HTTP/1 中存在的一大堆缺点其中相当一部分对于开发者来说非常麻烦在 HTTP/2 出现前开发者要用许多种变通方法来解决。
在 HTTP/2.0 中 HTTP 从一个 ASCII 协议变为一个二进制协议其主要特性是多路复用multiplexing它可以通过同一个 TCP 连接发送多个逻辑数据流。复用使得很多事情变得更快更好它带来更好的拥塞控制、更充分的带宽利用、更长久的 TCP 连接 ———— 这些都比以前更好了链路能更容易实现全速传输标头压缩技术也减少了带宽的用量。采用 HTTP/2 后浏览器对每个主机一般只需要 一个 TCP 连接而不是以前常见的 六个 连接。事实上HTTP/2 使用的连接聚合connection coalescing和 “去分片”desharding技术还可以进一步缩减连接数。HTTP/2 还解决了 HTTP 的队头拥塞head of line blocking问题客户端必须等待一个请求完成才能发送下一个请求的日子过去了。
以下为HTTP/2 的请求示例
http
GET /zh-CN/docs/Glossary/Simple_header HTTP/2
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8
Accept-Language: en-US,en;q0.5
Accept-Encoding: gzip, deflate, brReferer: https://developer.mozilla.org/zh-CN/docs/Glossary/Simple_header
以下为HTTP/2 的响应示例
http
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charsetutf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: 547fa7e369ef56031dd3bff2ace9fc0832eb251a
Keep-Alive: timeout5, max1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
大家可以惊奇的发现除了版本号HTTP/2.0 与 HTTP/1.1 在内容与格式上几乎没有任何差别这得益于早期标准制定者对 HTTP/1.1 升级边界与观念的思考这让标准制定者几乎保留了 HTTP/1.1 内容与形式上的所有标准从修改 HTTP 底层技术来解决 HTTP/1.1 中的缺点。
也正因如此HTTP/2.0 不需 Web 开发者做什么不需要站点和应用做出改变随着陈旧的浏览器和服务器的更新站点自然就会升级到 HTTP/2.0 而不会带来任何问题并且还能在数据传输上节省了可观的成本和支出这使得该协议在互联网和万维网上得到广泛的实现和部署HTTP/2.0 取得了巨大的成功。
特性 HTTP/2.0 是一个二进制协议 在 HTTP/2.0 中HTTP 不再是 ASCII 协议而是二进制协议。作为一个二进制协议它更容易解析但与 HTTP/1.x 不同的是它不再被人眼读取。HTTP/2 的主要构建块是帧和流每个 HTTP/2 请求和响应都被赋予一个唯一的流 ID并且它被分成帧。帧不过是二进制数据帧的集合称为流。每个帧都有一个流 ID用于标识它所属的流并且每个帧都有一个公共标头Type, Length, Flags, Stream Identifie和帧有效负载规范中一共定义了 10 种不同的帧其中最基础的两种分别对应于 HTTP 1.1 的 DATA 和 HEADERS。此外流 ID 是唯一的客户端发起的任何请求流 ID 都使用奇数而来自服务器的响应流 ID 则都是偶数。 多路复用 由于 HTTP/2 现在是二进制协议并且正如我上面所说它使用帧和流来进行请求和响应因此一旦打开 TCP 连接所有流都会通过同一连接异步发送而无需打开任何其他连接。反过来服务器以相同的异步方式响应即响应没有顺序客户端使用分配的流 ID 来识别特定数据包所属的流。流的多路复用解决了 HTTP/1.x 中存在的线头阻塞问题即客户端不必等待正在花费时间的请求其他请求仍将得到处理。 流优先级Stream Prioritization HTTP/2 允许对请求 / 响应进行优先级排序每个流都包含一个优先级也就是 “权重”它被用来告诉对客户端哪个流更重要。当资源有限的时候服务器会根据优先级来选择应该先发送哪些流。借助于借助于 PRIORITY 帧客户端同样可以告知服务器当前的流依赖于其他哪个流该功能让客户端能建立一个优先级 “树”所有 “子流” 会依赖于 “父流” 的传输完成情况。优先级和依赖关系可以在传输过程中被动态的改变。这样当用户滚动一个全是图片的页面的时候浏览器就能够指定哪个图片拥有更高的优先级。或者是在你切换标签页的时候浏览器可以提升新切换到页面所包含流的优先级。优先级的引入确保重要资源的优先加载提高了页面加载速度和用户体验。 头部压缩 HTTP 是一种无状态的协议。简而言之这意味着每个请求必须要携带服务器需要的所有细节而不是让服务器保存住之前请求的元数据这导致许多请求和响应头部会携带一些冗余的一摸一样的信息增大了标头大小致使带宽使用和延迟增加。为了克服这个问题HTTP/2 使用 HPACK 算法对头部信息进行压缩减少了头部大小从而降低了传输的数据量提高了效率。 服务器推送 HTTP/2 的服务器推送功能允许服务器在客户端请求前主动推送资源。服务器可以通过发送一个名为 PUSH_PROMISE 的特殊帧通知客户端即将推送的资源。这个 PUSH_PROMISE 帧与导致推送发生的流相关联并包含服务器将要推送的资源的流 ID。通过服务器推送服务器可以在客户端请求之前主动将客户端可能需要的资源发送到客户端缓存中从而避免了客户端额外的请求减少了延迟。这种特性在某些情况下可以提高页面加载速度和性能尤其是对于一些预加载资源或常用资源可以减少客户端请求的往返次数优化了 Web 应用的性能和用户体验。 中断连接不再断开连接 HTTP/1.1 协议有一个缺点当一个含有确切值的 Content-Length 的 HTTP 消息被送出之后你就很难中断它了。当然通常你可以断开整个 TCP 链接但也不总是可以这样但这样导致的代价就是需要通过三次握手来重新建立一个新的 TCP 连接。在 http2 里面我们可以通过发送 RST_STREAM 帧来实现这种需求它是一种特殊的帧类型用于中止某些流即客户端可以发送此帧让服务器知道我不需要此流了。客户端可以使用 RST_STREAM 并停止接收特定流同时连接不会被关闭其他流仍会正常运行。 可靠性和安全性 HTTP/2 支持数据的流量控制和优先级设置保障了数据的可靠传输。此外HTTP/2 要求使用 TLS 协议进行加密通信提高了数据的安全性。 兼容性 HTTP/2 通过与 HTTP/1.1 的兼容性保证使得现有的 Web 应用可以逐渐迁移到 HTTP/2而不需要进行大规模的更改。
HTTP/3—— 基于 QUIC 的 HTTP (2022)
HTTP 的下一个主要版本HTTP/3 有这与 HTTP 早期版本的相同语义但在传输层部分使用 QUIC (en-US) 而不是 TCP。到 2022 年 10 月26% 的网站正在使用 HTTP/3。
QUIC 旨在为 HTTP 连接设计更低的延迟。类似于 HTTP/2它是一个多路复用协议但是 HTTP/2 通过单个 TCP 连接运行所以在 TCP 层处理的数据包丢失检测和重传可以阻止所有流。QUIC 通过 UDP 运行多个流并为每个流独立实现数据包丢失检测和重传因此如果发生错误只有该数据包中包含数据的流才会被阻止。
RFC 9114 定义的 HTTP/3 被 大多数主流浏览器所支持包括 Chromium及其他的变体例如 Chrome 和 Edge和 Firefox。
更多 HTTP3 的内容会随着发展逐步更新。
最后更新: 2024/3/16 上午 10:29 HTTP 协议之报文详解
老胡爱分享于 2014-04-20 12:51:28 发布
学习 WEB 开发需要对 HTTP 协议熟悉下面直接进入主题。
一、报文
报文是网络中交换和传输的数据单元即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息其长短很不一致长度不限且可变。
HTTP 报文是由一行一行简单的字符串组成的。HTTP 报文都是纯文本不是二进制代码所以人们可以很方便地对其进行读写。如果说 HTTP 是因特网的信使那么 HTTP 报文就是它用来搬东西的包裹了。
二、报文的流动
报文会流入源端服务器工作完成之后会流会用户的 Agent 代理。
HTTP 报文会像河水一样流动不管是请求报文还是响应报文所有报文都会向下游流动。所有报文的发送者都在接受者的上游。如下图所示对请求报文来说代理 1 位于代理 3 的上游但对响应报文来说它就位于代理 3 的下游。 三、报文的组成部分
HTTP 报文是简单的格式化文本。如下图所示。每条报文都包含一条来自客户端的请求或者一条来自服务器的响应。它们由三部分组成对报文进行描述的起始行、包含属性的首部块以及可选的、包含数据的主体部分。 所有的 HTTP 报文都可以分为两类请求报文和响应报文。请求报文会向 Web 服务器请求一个动作。响应报文会将请求的结果返回给客户端。请求报文和响应报文的基本报文结构相同。
1、报文的语法
请求报文的格式
method request-URL version
headersentity-body响应报文的格式
method status reason-phrase
headersentity-body下面是对报文格式各部分的解释
method (方法)
客户端希望服务器对资源执行的动作。是一个单独的词如GET、HEAD、POST。
request-URL (请求 URL)
命名了所请求资源或者 URL 路径组件的完整 URL。
version (版本)
报文所使用的 HTTP 版本其格式HTTP/.
其中 major (主要版本号) 和 minor (次要版本号) 都是整数。
status (状态码)
由三位数字组成描述了请求过程中所发生的情况。
reason-phrase (原因短语)
上面数字状态码的可读版本包含行终止序列之前的所有文本。
headers (首部)
可以有零个或多个首部每个首部都包含一个名字后面跟着一个冒号(:)然后是一个可选的空格接着是一个值最后是一个 CRLF。首部是由一个空行 (CRLF) 结束的表示了首部列表的结束和实体主体部分的开始
entity-body (实体的主体部分)
包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分。有时报文只是以一个 CRLF 结束。
2、起始行
所有的 HTTP 报文都以一个起始行作为开始。请求报文的起始行说明了要做些什么。响应报文的起始行说明发生了什么。
请求行。请求报文请求服务器对资源进行一些操作。请求报文的起始行称为请求行包含一个方法和一个请求 URL方法描述了服务器应该执行的操作请求 URL 描述了要对哪个资源执行这个方法。请求行还包含 HTTP 的版本用来告知服务器客户端使用的是哪种版本的 HTTP。所有的这些字段都由空格符分隔。在 HTTP/1.0 之前并不要求请求行中包含 HTTP 版本号。
响应行。响应报文承载了状态信息和操作产生的所有结果数据将其返回给客户端。响应报文的起始行称为响应行包含了响应报文使用的 HTTP 版本、数字状态码以及描述状态码的文本信息的原因短语。所有的这些字段都由空格符分隔。在 HTTP/1.0 之前并不要求响应行中包含 HTTP 版本号。
方法。请求的起始行以方法作为开始方法用来告知服务器要做些什么。
HTTP 规范中定义了一组常用的请求方法。 注并不是所有服务器都实现了上面列出的 7 种方法。而且由于 HTTP 设计得易于扩展所以除了这些方法以外其他服务器可能还会是实现一些自己的请求方法称为扩展方法。
状态码。用来告诉客户端发生了什么事情。
客户端向一个 HTTP 服务器发送请求报文时会发生很多事情。状态码是在每条响应报文的起始行中返回的。
下面是状态码的分类 原因短语。是响应起始行中最后一个组件。为状态码提供了文本形式的解释。例200 OK 中OK 就是原因短语。
版本号。为 HTTP 应用程序提供了一种将自己所遵循的协议版本告知对方的方式。版本号说明了应用程序支持的最高版本。版本好不会被当作小数来处理。版本的每个数字都回被当成一个单独的数字来处理。因此每个数字都必须单独进行比较以便确定哪个版本更高。比如HTTP/2.22 就比 HTTP/2.3 的版本更高因为 22 比 3 大。
3、首部
首部字段向请求和响应报文中添加一些附加信息。从本质上来说它们只是一些名 / 值对的列表。
首部分类
通用首部
既可以出现在请求报文中也可以出现在响应报文中
请求首部
提供更多有关请求的信息
响应首部
提供更多有关响应的信息
实体首部
描述主体的长度和内容或者资源自身
扩展首部
规范中没有定义的新首部
常见首部实例 4、实体的主体部分
HTTP 报文的负荷。就是 HTTP 要传输的内容。
HTTP 报文可以承载很多类型的数字数据图片、视频、HTML 文档、软件应用程序等。
参考文献《HTTP 权威指南》 【Http】HTTP 报文结构及请求数据大小
志波同学 于 2015-09-10 16:35:26 发布
HTTP 报文结构如下
HTTP 报文结构包含请求行、请求头、请求体三部分。一次请求示例如下图 一、请求行【request-line】
POST 请求方法 /sso/login 请求 URL及 URI HTTP/1.1 HTTP 协议及版本
HTTP 协议没有限制请求行的长度。但是出于各种原因的考虑各家的浏览器、服务器端都做了不同程度的限制。
1、浏览器限制
所有主流浏览器都会对 URI 的长度进行限制。如果你在浏览器中输入过长的 URI那么浏览器会自动进行截断。各个浏览器对 URI 长度的限制各不相同2000 字符以内的 URI 都能符合所有主流浏览器的要求。
2、服务端限制
一般服务是没有专门针对 URI 的参数限制的但是由于 URI 是会包含在请求头中的所以对请求头大小的限制是会影响 URI 的。
3、关于请求行的疑惑
HTTP 协议分为 request-line、request-header、request-body 三个部分的。在查看各浏览器、服务器配置的时候往往将 request-line、request-header 归为一类了request-line 的数据大小受 request-header 的影响比如 nginx 的 large_client_header_buffers 属性。
二、请求头【request-header】
请求头部存放了客户端请求的信息包含 User-Agent、Accept、Host 等。请求头部由关键字 / 值对组成每行一对关键字和值用英文冒号 “:” 分隔。协议中也没有显示限制请求头的大小。但是出于各种原因的考虑各家的浏览器、服务器端都做了不同程度的限制。
1、浏览器限制
各主流浏览器都限制请求头的大小但值得大小不尽相同。
2、服务端限制
出于安全考虑我们必须在服务器端对请求头大小进行限制由于存放的信息比较简单因此建议值不应超过 100K。
三、请求体【request-body】
HTTP 协议没有限制请求体的长度。HTTP 是支持文件传输的文件的二进制数据不是放在请求行或者请求头里面它是放在请求体里面的。
1、浏览器限制
如果浏览器对请求体大小做限制可能会影响文件的传输因此浏览器本身没有对请求体做大小限制。
2、服务端限制
出于安全考虑我们必须在服务器端对请求体大小进行限制请求体长度的最大值的设置有多方面的因素需要根据业务情况反复调优决定。考虑以下几方面因素 1、根据请求报文的大小预估实际请求体的最大值 2、限制上传文件的大小文件上传服务与业务操作服务分离 3、设置合理的超时时间避免由于请求体太大导致线程被长时间占用 4、请求体设置不能太大防止轻易被 DDOS 攻击 HTTP 响应报文
THE ORDER 于 2022-02-01 18:16:38 发布
1. HTTP 响应报文分析
HTTP 响应报文效果图: 响应报文说明:
— 响应行 / 状态行 —
HTTP/1.1 200 OK # HTTP 协议版本 状态码 状态描述
— 响应头 —
Server: Tengine # 服务器名称
Content-Type: text/html; charsetUTF-8 # 内容类型
Transfer-Encoding: chunked # 发送给客户端内容不确定内容长度发送结束的标记是 0\r\n, Content-Length 表示服务端确定发送给客户端的内容大小但是二者只能用其一。
Connection: keep-alive # 和客户端保持长连接
Date: Fri, 23 Nov 2018 02:01:05 GMT # 服务端的响应时间
— 空行 —
— 响应体 —
… # 响应给客户端的数据
原始响应报文说明:
HTTP/1.1 200 OK\r\n
Server: Tengine\r\n
Content-Type: text/html; charsetUTF-8\r\n
Transfer-Encoding: chunked\r\n
Connection: keep-alive\r\n
Date: Fri, 23 Nov 2018 02:01:05 GMT\r\n
\r\n (响应头信息后面还有一个单独的’\r\n’不能省略)
…
说明:
每项数据之间使用:\r\n
2. HTTP 状态码介绍
HTTP 状态码是用于表示 web 服务器响应状态的 3 位数字代码。
状态码 说明
200 请求成功
307 重定向
400 错误的请求请求地址或者参数有误
404 请求资源在服务器不存在
500 服务器内部源代码出现错误
3. 小结
一个 HTTP 响应报文是由响应行、响应头、空行和响应体 4 个部分组成。 HTTP 响应报文 响应行是由三部分组成HTTP 协议版本 状态码 状态描述最常见的状态码是 200 HTTP 返回状态值详解
阳光岛主于 2013-09-07 06:49:39 发布
当用户点击或搜索引擎向网站服务器发出浏览请求时服务器将返回 Http Header Http 头信息状态码。
常见几种如下:
1、Http/1.1 200 OK 访问正常
表示成功访问为网站可正常访问时的状态。
2、Http/1.1 301 Moved Permanently 301 重定向 永久重定向
对搜索引擎相对友好的跳转方式当网站更换域名时可将原域名作 301 永久重定向到新域名原域名权重可传递到新域名也常有将不含 www 的域名 301 跳转到含 www 的如 xxx.com 通过 301 跳转到 www.xxx.com
3、Http/1.1 302 Found 为临时重定向
易被搜索引擎判为作弊比如 asp 程序的 response.Redirect () 跳转、js 跳转或静态 http 跳转。
4、Http/1.1 400 Bad Request 域名绑定错误
一般是服务器上域名未绑定成功未备案等情况。
5、Http/1.1 403 Forbidden 没有权限访问此站
你的 IP 被列入黑名单连接的用户过多可以过后再试网站域名解析到了空间但空间未绑定此域名等情况。
6、Http/1.1 404 Not Found 文件或目录不存在
表示请求文件、目录不存在或删除设置 404 错误页时需确保返回值为 404。常有因为 404 错误页设置不当导致不存在的网页返回的不是 404 而导致搜索引擎降权。
7、Http/1.1 500 Internal Server Error 程序或服务器错误
表示服务器内部程序错误出现这样的提示一般是程序页面中出现错误如小的语法错误数据连接故障等。
HTTP 状态码分类及含义
HTTP 状态码是用来表示 HTTP 请求的结果的根据它们的含义可以分为五类
1xx临时响应请求收到继续处理
2xx成功操作成功收到分析、接受
3xx重定向完成此请求必须进一步处理
4xxx请求错误请求包含一个错误语法或不能完成
5xx服务器错误服务器执行一个完全有效请求失败
Http 状态码一览表
所谓的 404 页就是服务器 404 重定向状态返回页面。数字 404 指的是 404 号状态码。
一般常用到的有 200 号状态码和 404 号状态码。200 号表示网页被下载成功而 404 号表示不能成功下载并产生错误。
下面是 HTTP 状态码一览表。
1xx请求收到继续处理
100—— 客户必须继续发出请求
101—— 客户要求服务器根据请求转换 HTTP 协议版本
2xx操作成功收到分析、接受
200—— 交易成功
201—— 提示知道新文件的 URL
202—— 接受和处理、但处理未完成
203—— 返回信息不确定或不完整
204—— 请求收到但返回信息为空
205—— 服务器完成了请求用户代理必须复位当前已经浏览过的文件
206—— 服务器已经完成了部分用户的 GET 请求
3xx完成此请求必须进一步处理
300—— 请求的资源可在多处得到
301—— 删除请求数据
302—— 在其他地址发现了请求数据
303—— 建议客户访问其他 URL 或访问方式
304—— 客户端已经执行了 GET但文件未变化
305—— 请求的资源必须从服务器指定的地址得到
306—— 前一版本 HTTP 中使用的代码现行版本中不再使用
307—— 申明请求的资源临时性删除
4xx请求包含一个错误语法或不能完成
400—— 错误请求如语法错误
401—— 请求授权失败
402—— 保留有效 ChargeTo 头响应
403—— 请求不允许
404—— 没有发现文件、查询或 URl
405—— 用户在 Request-Line 字段定义的方法不允许
406—— 根据用户发送的 Accept 拖请求资源不可访问
407—— 类似 401用户必须首先在代理服务器上得到授权
408—— 客户端没有在用户指定的饿时间内完成请求
409—— 对当前资源状态请求不能完成
410—— 服务器上不再有此资源且无进一步的参考地址
411—— 服务器拒绝用户定义的 Content-Length 属性请求
412—— 一个或多个请求头字段在当前请求中错误
413—— 请求的资源大于服务器允许的大小
414—— 请求的资源 URL 长于服务器允许的长度
415—— 请求资源不支持请求项目格式
416—— 请求中包含 Range 请求头字段在当前请求资源范围内没有 range 指示值请求
也不包含 If-Range 请求头字段
417—— 服务器不满足请求 Expect 头字段指定的期望值如果是代理服务器可能是下
一级服务器不能满足请求
5xx服务器执行一个完全有效请求失败
500—— 服务器产生内部错误
501—— 服务器不支持请求的[函数
502—— 服务器暂时不可用有时是为了防止发生系统过载
503—— 服务器过载或暂停维修
504—— 关口过载服务器使用另一个关口或服务来响应用户等待时间设定值较长
505—— 服务器不支持或拒绝支请求头中指定的 HTTP 版本 一些常见的状态码为
200 - 服务器成功返回网页
404 - 请求的网页不存在
503 - 服务器超时
下面提供 HTTP 状态码的完整列表。点击链接 可了解详情。您也可以访问 HTTP 状态码上的 W3C 页获取更多信息。
1xx (临时响应)
表示临时响应并需要请求者继续执行操作的状态码。
100 (继续) 请求者应当继续提出请求。服务器返回此代码表示已收到请求的第一部分正在等待其余部分。
101 (切换协议) 请求者已要求服务器切换协议服务器已确认并准备切换。
2xx (成功)
表示成功处理了请求的状态码。
200(成功) 服务器已成功处理了请求。通常这表示服务器提供了请求的网页。如果是对您的 robots.txt 文件显示此状态码则表示 Googlebot 已成功检索到该文件。
201 (已创建) 请求成功并且服务器创建了新的资源。
202 (已接受) 服务器已接受请求但尚未处理。
203 (非授权信息) 服务器已成功处理了请求但返回的信息可能来自另一来源。
204 (无内容) 服务器成功处理了请求但没有返回任何内容。
205 (重置内容) 服务器成功处理了请求但没有返回任何内容。与 204 响应不同此响应要求请求者重置文档视图 (例如清除表单内容以输入新内容)。
206 (部分内容) 服务器成功处理了部分 GET 请求。
3xx (重定向)
要完成请求需要进一步操作。通常这些状态码用来重定向。Google 建议您在每次请求中使用重定向不要超过 5 次。您可以使用网站管理员工具查看一下 Googlebot 在抓取重定向网页时是否遇到问题。诊断下的网络抓取页列出了由于重定向错误导致 Googlebot 无法抓取的网址。
300 (多种选择) 针对请求服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作或提供操作列表供请求者选择。
301 (永久移动) 请求的网页已永久移动到新位置。服务器返回此响应 (对 GET 或 HEAD 请求的响应) 时会自动将请求者转到新位置。您应使用此代码告诉 Googlebot 某个网页或网站已永久移动到新位置。
302 (临时移动) 服务器目前从不同位置的网页响应请求但请求者应继续使用原有位置来响应以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似会自动将请求者转到不同的位置但您不应使用此代码来告诉 Googlebot 某个网页或网站已经移动因为 Googlebot 会继续抓取原有位置并编制索引。
303 (查看其他位置) 请求者应当对不同的位置使用单独的 GET 请求来检索响应时服务器返回此代码。对于除 HEAD 之外的所有请求服务器会自动转到其他位置。
304 (未修改) 自从上次请求后请求的网页未修改过。服务器返回此响应时不会返回网页内容。
如果网页自请求者上次请求后再也没有更改过您应将服务器配置为返回此响应 (称为 If-Modified-Since HTTP 标头)。服务器可以告诉搜索引擎的蜘蛛 / 机器人 自从上次抓取后网页没有变更进而节省带宽和开销。
305 (使用代理) 请求者只能使用代理访问请求的网页。如果服务器返回此响应还表示请求者应使用代理。
307 (临时重定向) 服务器目前从不同位置的网页响应请求但请求者应继续使用原有位置来响应以后的请求。此代码与响应 GET 和 HEAD 请求的 301 代码类似会自动将请求者转到不同的位置但您不应使用此代码来告诉 Googlebot 某个页面或网站已经移动因为 Googlebot 会继续抓取原有位置并编制索引。
4xx (请求错误)
这些状态码表示请求可能出错妨碍了服务器的处理。
400 (错误请求) 服务器不理解请求的语法。
401 (未授权) 请求要求身份验证。对于登录后请求的网页服务器可能返回此响应。
403 (禁止) 服务器拒绝请求。如果您在 Googlebot 尝试抓取您网站上的有效网页时看到此状态码 (您可以在 Google 网站管理员工具诊断下的网络抓取页面上看到此信息)可能是您的服务器或主机拒绝了 Googlebot 访问。
404 (未找到) 服务器找不到请求的网页。例如对于服务器上不存在的网页经常会返回此代码。
如果您的网站上没有 robots.txt 文件而您在 Google 网站管理员工具 “诊断” 标签的 robots.txt 页上看到此状态码则这是正确的状态码。但是如果您有 robots.txt 文件而又看到此状态码则说明您的 robots.txt 文件可能命名错误或位于错误的位置 (该文件应当位于顶级域名为 robots.txt)。
如果对于 Googlebot 抓取的网址看到此状态码 (在 “诊断” 标签的 HTTP 错误页面上)则表示 Googlebot 跟随的可能是另一个页面的无效链接 (是旧链接或输入有误的链接)。
405 (方法禁用) 禁用请求中指定的方法。
406 (不接受) 无法使用请求的内容特性响应请求的网页。
407 (需要代理授权) 此状态码与 401 (未授权) 类似但指定请求者应当授权使用代理。如果服务器返回此响应还表示请求者应当使用代理。
408 (请求超时) 服务器等候请求时发生超时。
409 (冲突) 服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码以及两个请求的差异列表。
410 (已删除) 如果请求的资源已永久删除服务器就会返回此响应。该代码与 404 (未找到) 代码类似但在资源以前存在而现在不存在的情况下有时会用来替代 404 代码。如果资源已永久移动您应使用 301 指定资源的新位置。
411 (需要有效长度) 服务器不接受不含有效内容长度标头字段的请求。
412 (未满足前提条件) 服务器未满足请求者在请求中设置的其中一个前提条件。
413 (请求实体过大) 服务器无法处理请求因为请求实体过大超出服务器的处理能力。
414 (请求的 URI 过长) 请求的 URI (通常为网址) 过长服务器无法处理。
415 (不支持的媒体类型) 请求的格式不受请求页面的支持。
416 (请求范围不符合要求) 如果页面无法提供请求的范围则服务器会返回此状态码。
417 (未满足期望值) 服务器未满足 “期望” 请求标头字段的要求。
5xx (服务器错误)
这些状态码表示服务器在处理请求时发生内部错误。这些错误可能是服务器本身的错误而不是请求出错。
500 (服务器内部错误) 服务器遇到错误无法完成请求。
501 (尚未实施) 服务器不具备完成请求的功能。例如服务器无法识别请求方法时可能会返回此代码。
502 (错误网关) 服务器作为网关或代理从上游服务器收到无效响应。
503 (服务不可用) 服务器目前无法使用 (由于超载或停机维护)。通常这只是暂时状态。
504 (网关超时) 服务器作为网关或代理但是没有及时从上游服务器收到请求。
505 (HTTP 版本不受支持) 服务器不支持请求中所用的 HTTP 协议版本。 via: HTTP 的历史 | HTTP完全注释 wangjunliang 最后更新: 2024/3/16 上午10:29 https://junliangwangx.github.io/HTTP-Explanation/docs/overview/the-history-of-http.html HTTP 协议之报文详解_不发报文就可以接受所有报文 - CSDN 博客 老胡爱分享于 2014-04-20 12:51:28 发布 https://blog.csdn.net/yipiankongbai/article/details/24176693 【Http】HTTP 报文结构及请求数据大小_怎么确定请求体的大小 - CSDN 博客 志波同学 于 2015-09-10 16:35:26 发布 https://zhibo.blog.csdn.net/article/details/48342007 HTTP 响应报文 - CSDN 博客 THE ORDER 于 2022-02-01 18:16:38 发布 https://blog.csdn.net/weixin_44498127/article/details/122765290 HTTP 返回状态值详解 - CSDN 博客 阳光岛主于 2013-09-07 06:49:39 发布 https://blog.csdn.net/ithomer/article/details/10240351 论 HTTP 请求大小 - 轩脉刃 - 博客园 2013-03-29 09:55 轩脉刃 https://www.cnblogs.com/yjf512/archive/2013/03/29/2988296.html
