HTTP 概述，参数以及内容介绍

HTTP 概述

超文本传输协议 The Hypertext Transfer Protocol (HTTP)是分布式，协作，超媒体信息系统的应用程序级协议。 自 1990 年以来，这就是互联网（即 Internet）数据通信的基础。HTTP 是一种通用的无状态协议，可以将其用于其他目的，比如使用它的请求方法，错误代码和标头的扩展。

从根本上说，HTTP 是基于 TCP / IP 的通信协议，用于在万维网上传递数据（HTML 文件，图像文件，查询结果等）。默认端口是 TCP 80，也可以使用其他端口。它给计算机之间相互通信提供了一种标准化的方式。HTTP 规范指定如何构造客户端的请求数据并将其发送到服务器，以及服务器如何响应这些请求。

基本特征

HTTP 成为简单但功能强大的协议有三个基本特征：

  • HTTP 是无连接的：HTTP 客户端（例如浏览器）发起 HTTP 请求，并在发出请求后等待响应。服务器处理该请求并发回响应，然后客户端断开连接。因此，客户端和服务器仅在当前请求和响应期间彼此相互了解。如果两者之间产生新一次的连接，对于客户端和服务器来说都是全新的一次连接。
  • HTTP 是类型自由的：这意味着，只要客户端和服务器都知道如何处理数据内容，任何类型的数据都可以通过 HTTP 发送。客户端和服务器都需要使用适当的媒体类型（MIME type）发送特定内容。
  • HTTP 是无状态的：如上所述，HTTP 是无连接的，这是 HTTP 是无状态协议导致的。服务器和客户端仅在当前请求期间彼此知道。之后，他们俩彼此就忘记了。由于协议的这种性质，客户端和浏览器都无法在网页的不同请求之间保存信息。

HTTP / 1.0 为每个请求/响应交换使用一个新的连接，而 HTTP / 1.1 同一个连接可以用于一个或多个请求/响应交换。

基本架构

下图显示了 Web 应用程序基本的体系结构，并描述了 HTTP 所在的位置：

HTTP 协议是基于基于客户端/服务器体系结构的请求/响应协议，其中浏览器，爬虫和搜索引擎等充当 HTTP 客户端，而 Web 服务器充当服务器。

Client

HTTP 客户端用请求方法（request method），URI，协议版本等内容向服务器发送请求，之后跟类似 MIME 的消息，其中包含请求修饰，客户端信息以及连接上要传输的正文内容。

Server

HTTP 服务器以状态行 (status line)作为响应的起始行，包括消息的协议版本和状态码，其后是类似 MIME 的消息，其中包含服务器信息，实体（entity）元信息以及可能的实体主体内容。

HTTP 参数

本节将介绍一些重要的 HTTP 协议参数及其在通信中使用的语法。例如，日期格式，URL 格式等。用于在编写 HTTP 客户端或服务器程序时构造请求和响应消息。

HTTP 版本

HTTP 使用<major>.<minor>编号方案来指示协议的版本。 HTTP 消息的版本由第一行中的 HTTP-Version 字段指示。这是指定 HTTP 版本号的一般语法：

HTTP-Version=&quot;HTTP&quot;&quot;/&quot;1\*DIGIT &quot;.&quot;1\*DIGIT

示例

HTTP/1.0

or

HTTP/1.1

统一资源定位符

统一资源定位符（URI）格式简单，不区分大小写，包含名称，位置等字符串，用于标识资源，例如网站，Web 服务等。用于 HTTP 的 URI 的通用语法如下：

URI="http:""//"host[":"port][abs_path["?"query]]

在此，如果端口为空或未指定端口，则将端口假定为 HTTP 使用 80 端口，并且空的 abs_path 等效于 abs_path 的"/"。 还需要在 URL 中对那些保留(reserved)字符和不安全(unsafe)字符进行编码，所谓保留字符就是那些在 URL 中具有特定意义的字符。不安全字符是指那些在 URL 中没有特殊含义，但在 URL 所在的上下文中可能具有特殊意义的字符。例如双引号("")。

示例

以下三个 URI 是等效的：

http://abc.com:80/~smith/home.html

http://ABC.com/%7Esmith/home.html

http://ABC.com:/%7esmith/home.html

日期/时间格式

所有 HTTP 日期/时间戳都必须毫无例外地以格林威治标准时间（GMT）表示。HTTP 应用程序允许使用以下三种表示形式中的任何一种：

Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, 与 RFC 1123 更新

Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, 被 RFC 1036 淘汰

Sun Nov 6 08:49:37 1994 ; ANSI C&#39;s asctime() format

字符集

我们使用字符集项来指定客户喜欢的字符集。可以列出多个字符集，以逗号分隔。如果未指定值，则默认值为 US-ASCII。

示例

US-ASCII

or

ISO-8859-1

or

ISO-8859-7

内容编码

内容编码字段表示在通过网络传递内容之前已使用编码算法对内容进行编码。内容编码主要用于允许在不丢失身份的情况下对文档进行压缩或其他有用的转换。

所有内容编码值都不区分大小写。

示例

以下是有效的编码方案：

Accept-encoding: gzip

or

Accept-encoding: compress

or

Accept-encoding: deflate

媒体类型

HTTP 在 Content-Type 和 Accept 标头字段中使用 Internet 媒体类型，用于提供开放和可扩展的数据类型以及类型协商。所有媒体类型值都已向互联网号码分配局（IANA）注册。指定媒体类型的一般语法如下：

media-type = type "/" subtype *( ";" parameter )

类型，子类型和参数属性名称不区分大小写。

示例

Accept: image/gif

语言标签

HTTP 在"Accept-Language"和"Content-Language"字段中使用语言标签。语言标签由一个或多个部分组成：主要语言标签和可能为空的一系列子标签：

language-tag = primary-tag *( "-" subtag )

标签内不允许有空格，并且所有标签都不区分大小写。

示例

en, en-US, en-cockney, i-cherokee, x-pig-latin

其中两个字母的主要标签是 ISO-639 语言的缩写，任何两个字母的初始子标签是一个 ISO-3166 国家/地区代码。

HTTP 消息

HTTP 消息是服务器和客户端之间交换数据的方式。有两种类型的消息︰ 请求（requests）--由客户端发送用来触发一个服务器上的动作；响应（responses）--来自服务器的应答。

HTTP 消息由采用 ASCII 编码的多行文本构成。在 HTTP/1.1 及早期版本中，这些消息通过连接公开地发送。在 HTTP/2 中，为了优化和性能方面的改进，曾经可人工阅读的消息被分到多个 HTTP 帧中。

Web 开发人员或网站管理员，很少自己手工创建这些原始的 HTTP 消息︰ 由软件、浏览器、 代理或服务器完成。他们通过配置文件（用于代理服务器或服务器），API （用于浏览器）或其他接口提供 HTTP 消息。

HTTP 请求和响应具有相似的结构，由以下部分组成︰

  1. 一行起始行用于描述要执行的请求，或者是对应的状态，成功或失败。这个起始行总是单行的。
  2. 一个可选的 HTTP 头集合指明请求或描述消息正文。
  3. 一个空行指示所有关于请求的元数据已经发送完毕。
  4. 一个可选的包含请求相关数据的正文 (比如 HTML 表单内容), 或者响应相关的文档。 正文的大小有起始行的 HTTP 头来指定。

起始行和 HTTP 消息中的 HTTP 头统称为请求头，而其有效负载被称为消息正文。

HTTP 请求

起始行

HTTP 请求是由客户端发出的消息，用来使服务器执行动作。起始行 *(start-line) *包含三个元素：

  1. 一个 HTTP 方法_，一个动词 (像 GET, PUT 或者 POST) 或者一个名词 (像 HEAD 或者 OPTIONS), 描述要执行的动作.。
S.N. Method and Description
1 GET 方法用于使用给定 URI 从给定服务器检索信息。 使用 GET 的请求应仅检索数据，而对数据没有其他影响。.
2 HEAD 与 GET 相同，但仅传输状态行和标头部分。
3 POST 请求用于使用 HTML 表单将数据发送到服务器，例如，客户信息，文件上传等。
4 PUT 用上传的内容替换目标资源的所有当前表示形式。
5 DELETE 删除 URI 给定的目标资源的所有当前表示形式。
6 CONNECT 建立到由给定 URI 标识的服务器的隧道。
7 OPTIONS 描述目标资源的通信选项。
8 TRACE 对目标资源的路径执行消息回送测试。

  1. 请求目标 (request target)通常是一个 URL，或者是协议、端口和域名的绝对路径，通常以请求的环境为特征。请求的格式因不同的 HTTP 方法而异。它可以是：

    • 一个绝对路径，末尾跟上一个 ' ? ' 和查询字符串。这是最常见的形式，称为 原始形式 (origin form)，被 GET，POST，HEAD 和 OPTIONS 方法所使用。

      POST / HTTP/1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0

    • 一个完整的 URL，被称为 绝对形式 (absolute form)，主要在使用 GET 方法连接到代理时使用。

      GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1

    • 由域名和可选端口（以':'为前缀）组成的 URL 的 authority component，称为 authority form。 仅在使用 CONNECT 建立 HTTP 隧道时才使用。

      CONNECT developer.mozilla.org:80 HTTP/1.1

    • 星号形式 (asterisk form)，一个简单的星号('*')，配合 OPTIONS 方法使用，代表整个服务器。

      OPTIONS \* HTTP/1.1

  2. HTTP 版本 (HTTP version)，定义了剩余报文的结构，作为对期望的响应版本的指示符。

Headers

来自请求的 HTTP headers 遵循和 HTTP header 相同的基本结构：不区分大小写的字符串，紧跟着的冒号 ('😂 和一个结构取决于 header 的值。整个 header（包括值）由一行组成，这一行可以相当长。

有许多请求头可用，它们可以分为几组：

  • General headers，例如 Via，适用于整个报文。
  • Request headers，例如 User-Agent，Accept-Type，通过进一步的定义(例如 Accept-Language)，或者给定上下文(例如 Referer)，或者进行有条件的限制 (例如 If-None) 来修改请求。
  • Entity headers，例如 Content-Length，适用于请求的 body。显然，如果请求中没有任何 body，则不会发送这样的头文件。

Body

请求的最后一部分是它的 body。不是所有的请求都有一个 body：例如获取资源的请求，GET，HEAD，DELETE 和 OPTIONS，通常它们不需要 body。 有些请求将数据发送到服务器以便更新数据：常见的的情况是 POST 请求（包含 HTML 表单数据）。

Body 大致可分为两类：

  • Single-resource bodies，由一个单文件组成。该类型 body 由两个 header 定义： Content-Type 和 Content-Length.
  • Multiple-resource bodies，由多部分 body 组成，每一部分包含不同的信息位。通常是和 HTML Forms 连系在一起。

HTTP 响应

状态行

HTTP 响应的起始行被称作 状态行 (status line)，包含以下信息：

  1. 协议版本，通常为 HTTP/1.1。
  2. 状态码 (status code)，表明请求是成功或失败。常见的状态码是 200,404 或 302。
S.N. Code and Description
1 1xx: 通知 这表示已收到请求，并且流程正在继续.
2 2xx: 成功 这表示已成功接收，理解并接受了该动作.
3 3xx: 重定向 这意味着必须采取进一步的措施才能完成请求.
4 4xx: 客户端出错 这意味着请求包含不正确的语法或无法满足.
5 5xx: 服务端出错 这意味着服务器无法满足看似有效的请求.
  1. 状态文本 (status text)。一个简短的，纯粹的信息，通过状态码的文本描述，帮助人们理解该 HTTP 消息。

一个典型的状态行看起来像这样：HTTP/1.1 404 Not Found。

Headers

响应的 HTTP headers 遵循和任何其它 header 相同的结构：不区分大小写的字符串，紧跟着的冒号 ('😂 和一个结构取决于 header 类型的值。 整个 header（包括其值）表现为单行形式。
有许多响应头可用，这些响应头可以分为几组：

  • General headers，例如 Via，适用于整个报文。
  • Response headers，例如 Vary 和 Accept-Ranges，提供其它不符合状态行的关于服务器的信息。
  • Entity headers，例如 Content-Length，适用于请求的 body。显然，如果请求中没有任何 body，则不会发送这样的头文件。

Body

响应的最后一部分是 body。不是所有的响应都有 body：具有状态码 (如 201 或 204) 的响应，通常不会有 body。
Body 大致可分为三类：

  • Single-resource bodies，由已知长度的单个文件组成。该类型 body 由两个 header 定义：Content-Type 和 Content-Length。
  • Single-resource bodies，由未知长度的单个文件组成，通过将 Transfer-Encoding 设置为 chunked 来使用 chunks 编码。
  • Multiple-resource bodies，由多部分 body 组成，每部分包含不同的信息段。但这是比较少见的。

HTTP/2 帧

HTTP/1.x 报文有一些性能上的缺点：

  • Header 不像 body，它不会被压缩。
  • 两个报文之间的 header 通常非常相似，但它们仍然在连接中重复传输。
  • 无法复用。当在同一个服务器打开几个连接时：TCP 热连接比冷连接更加有效。

HTTP/2 引入了一个额外的步骤：它将 HTTP/1.x 消息分成帧并嵌入到流 (stream) 中。数据帧和报头帧分离，这将允许报头压缩。将多个流组合，这是一个被称为 多路复用 *(multiplexing) *的过程，它允许更有效的底层 TCP 连接。

HTTP 帧现在对 Web 开发人员是透明的。在 HTTP/2 中，这是一个在 HTTP/1.1 和底层传输协议之间附加的步骤。Web 开发人员不需要在其使用的 API 中做任何更改来利用 HTTP 帧；当浏览器和服务器都可用时，HTTP/2 将被打开并使用。

结论

HTTP 报文是使用 HTTP 的关键；它们的结构简单，并且具有高可扩展性。HTTP/2 帧机制是在 HTTP/1.x 语法和底层传输协议之间增加了一个新的中间层，而没有从根本上修改它，即它是建立在经过验证的机制之上。

posted @ 2020-11-27 14:44  _zxmax  阅读(448)  评论(0)    收藏  举报