网络编程之深入浅出，全面理解HTTP协议

Posted 大忽悠爱忽悠

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了网络编程之深入浅出，全面理解HTTP协议相关的知识，希望对你有一定的参考价值。

网络编程之深入浅出，全面理解HTTP协议

前言

HTTP（全称超文本传输协议，英文全称HyperText Transfer Protocol）是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收html页面的方法。

本篇文章篇幅比较长，先来个思维导图预览一下：

“HTTP之父”其人


“HTTP之父”——Ted Nelson


HTTP协议logo

1960年Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。

Ted Nelson组织协调万维网协会（World Wide Web Consortium）和Internet工作小组（Internet Engineering Task Force）共同合作研究，最终发布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定义了HTTP协议的我们今天普遍使用的一个版本——HTTP 1.1。

由于Ted Nelson对HTTP技术的发展做出的突破性历史贡献，他被称为“HTTP之父”。

HTTP概述

计算机网络体系结构分层

TCP/IP 通信传输流

利用 TCP/IP 协议族进行网络通信时，会通过分层顺序与对方进行通信。发送端从应用层往下走，接收端则从链路层往上走。

TCP/IP 通信传输流如下：

  • 首先作为发送端的客户端在应用层（HTTP 协议）发出一个想看某个 Web 页面的 HTTP 请求；
  • 接着，为了传输方便，在传输层（TCP 协议）把从应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层；
  • 在网络层（IP 协议），增加作为通信目的地的 MAC 地址后转发给链路层。这样一来，发往网络的通信请求就准备齐全了；
  • 接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到由客户端发送过来的 HTTP请求。

HTTP 请求如下图所示：

在网络体系结构中，包含了众多的网络协议，这篇文章主要围绕 HTTP 协议（HTTP/1.1版本）展开。

HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。

HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息，客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。

我们在浏览器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator，统一资源定位符)。就像每家每户都有一个门牌地址一样，每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。

HTTP 工作过程

HTTP请求响应模型：

HTTP通信机制是在一次完整的 HTTP 通信过程中，客户端与服务器之间将完成下列7个步骤：

  • 1）建立 TCP 连接：在HTTP工作开始之前，客户端首先要通过网络与服务器建立连接，该连接是通过 TCP 来完成的，该协议与IP 协议共同构建 Internet，即著名的 TCP/IP 协议族，因此 Internet 又被称作是 TCP/IP网络。HTTP 是比 TCP 更高层次的应用层协议，根据规则，只有低层协议建立之后，才能进行高层协议的连接，因此，首先要建立TCP 连接，一般 TCP 连接的端口号是80；
  • 2）客户端向服务器发送请求命令：一旦建立了TCP连接，客户端就会向服务器发送请求命令；
    例如：GET/sample/hello.jsp HTTP/1.1；
  • 3）客户端发送请求头信息：客户端发送其请求命令之后，还要以头信息的形式向服务器发送一些别的信息，之后客户端发送了一空白行来通知服务器，它已经结束了该头信息的发送；
  • 4）服务器应答：客户端向服务器发出请求后，服务器会客户端返回响应；
    例如： HTTP/1.1 200 OK
    响应的第一部分是协议的版本号和响应状态码；
  • 5）服务器返回响应头信息：正如客户端会随同请求发送关于自身的信息一样，服务器也会随同响应向用户发送关于它自己的数据及被请求的文档；
  • 6）服务器向客户端发送数据：服务器向客户端发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以 Content-Type 响应头信息所描述的格式发送用户所请求的实际数据；
  • 7）服务器关闭 TCP 连接：一般情况下，一旦服务器向客户端返回了请求数据，它就要关闭 TCP 连接，然后如果客户端或者服务器在其头信息加入了这行代码 Connection:keep-alive ，TCP 连接在发送后将仍然保持打开状态，于是，客户端可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。

HTTP 协议基础

通过请求和响应的交换达成通信

应用 HTTP 协议时，必定是一端担任客户端角色，另一端担任服务器端角色。仅从一条通信线路来说，服务器端和客服端的角色是确定的。HTTP 协议规定，请求从客户端发出，最后服务器端响应该请求并返回。换句话说，肯定是先从客户端开始建立通信的，服务器端在没有接收到请求之前不会发送响应

HTTP 是不保存状态的协议

HTTP 是一种无状态协议。协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设计成如此简单的。
可是随着 Web 的不断发展，我们的很多业务都需要对通信状态进行保存。于是我们引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管理状态了。

使用 Cookie 的状态管理

Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

Cookie 的流程：

请求 URI 定位资源

HTTP 协议使用 URI 定位互联网上的资源。正是因为 URI 的特定功能，在互联网上任意位置的资源都能访问到。

告知服务器意图的 HTTP 方法（HTTP/1.1）

持久连接

HTTP 协议的初始版本中，每进行一个 HTTP 通信都要断开一次 TCP 连接。比如使用浏览器浏览一个包含多张图片的 HTML 页面时，在发送请求访问 HTML 页面资源的同时，也会请求该 HTML 页面里包含的其他资源。因此，每次的请求都会造成无谓的 TCP 连接建立和断开，增加通信量的开销。

为了解决上述 TCP 连接的问题，HTTP/1.1 和部分 HTTP/1.0 想出了持久连接的方法。其特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。旨在建立一次 TCP 连接后进行多次请求和响应的交互。在 HTTP/1.1 中，所有的连接默认都是持久连接。

管线化

持久连接使得多数请求以管线化方式发送成为可能。以前发送请求后需等待并接收到响应，才能发送下一个请求。管线化技术出现后，不用等待亦可发送下一个请求。这样就能做到同时并行发送多个请求，而不需要一个接一个地等待响应了。

比如，当请求一个包含多张图片的 HTML 页面时，与挨个连接相比，用持久连接可以让请求更快结束。而管线化技术要比持久连接速度更快。请求数越多，时间差就越明显。

HTTP 协议报文结构

HTTP 报文

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫做请求报文；响应端（服务器端）的叫做响应报文。HTTP 报文本身是由多行（用 CR+LF 作换行符）数据构成的字符串文本。

HTTP 报文结构

HTTP 报文大致可分为报文首部和报文主体两部分。两者由最初出现的空行（CR+LF）来划分。通常，并不一定有报文主体。

HTTP 报文结构如下：

请求报文结构

请求报文的首部内容由以下数据组成：

  • 请求行 —— 包含用于请求的方法、请求 URI 和 HTTP 版本；
  • 首部字段 —— 包含表示请求的各种条件和属性的各类首部。（通用首部、请求首部、实体首部以及RFC里未定义的首部如 Cookie等）。

请求报文的示例，如下：

响应报文结构


响应报文的首部内容由以下数据组成：

  • 状态行 —— 包含表明响应结果的状态码、原因短语和 HTTP 版本。
  • 首部字段 —— 包含表示请求的各种条件和属性的各类首部。（通用首部、响应首部、实体首部以及RFC里未定义的首部如 Cookie等）

响应报文的示例，如下：

HTTP 报文首部之请求行、状态行

1.请求行

举个栗子，下面是一个 HTTP 请求的报文：

GET  /index.htm  HTTP/1.1
Host: sample.com

其中，下面的这行就是请求行，

GET  /index.htm  HTTP/1.1
  • 开头的 GET 表示请求访问服务器的类型，称为方法；
  • 随后的字符串 /index.htm 指明了请求访问的资源对象，也叫做请求 URI；
  • 最后的 HTTP/1.1，即 HTTP 的版本号，用来提示客户端使用的 HTTP 协议功能。

综合来看，大意是请求访问某台 HTTP 服务器上的 /index.htm 页面资源。

2.状态行

同样举个栗子，下面是一个 HTTP 响应的报文：

HTTP/1.1  200  OK
Date: Mon, 10 Jul 2017 15:50:06 GMT
Content-Length: 256
Content-Type: text/html
    
<html>
...

其中，下面的这行就是状态行，

HTTP/1.1  200  OK
  • 开头的 HTTP/1.1 表示服务器对应的 HTTP 版本；
  • 紧挨着的 200 OK 表示请求的处理结果的状态码和原因短语。

HTTP 报文首部之首部字段（重点分析）

首部字段概述

先来回顾一下首部字段在报文的位置，HTTP 报文包含报文首部和报文主体，报文首部包含请求行（或状态行）和首部字段。

在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖 HTTP 报文相关的内容信息。使用首部字段是为了给客服端和服务器端提供报文主体大小、所使用的语言、认证信息等内容。

首部字段结构

  • HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“：”分隔。
  • 另外，字段值对应单个 HTTP 首部字段可以有多个值。
  • 当 HTTP报文首部中出现了两个或以上具有相同首部字段名的首部字段时，这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同，优先处理的顺序可能不同，结果可能并不一致。
首部字段名冒号字段值
Content-Type：text/html
Keep-Alive：timeout=30, max=120

首部字段类型

首部字段根据实际用途被分为以下4种类型：

类型描述
通用首部字段请求报文和响应报文两方都会使用的首部
请求首部字段从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息
响应首部字段从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
实体首部字段针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的的信息。

通用首部字段（HTTP/1.1）

首部字段名说明
Cache-Control控制缓存的行为
Connection逐挑首部、连接的管理
Date创建报文的日期时间
Pragma报文指令
Trailer报文末端的首部一览
Transfer-Encoding指定报文主体的传输编码方式
Upgrade升级为其他协议
Via代理服务器的相关信息
Warning错误通知

Cache-Control

通过指定首部字段 Cache-Control 的指令，就能操作缓存的工作机制。

可用的指令一览

缓存请求指令

缓存响应指令

表示能否缓存的指令

  • public 指令
Cache-Control: public

当指定使用 public 指令时，则明确表明其他用户也可利用缓存。

  • private 指令
Cache-Control: private

当指定 private 指令后，响应只以特定的用户作为对象，这与 public 指令的行为相反。缓存服务器会对该特定用户提供资源缓存的服务，对于其他用户发送过来的请求，代理服务器则不会返回缓存。

  • no-cache 指令
Cache-Control: no-cache
  1. 使用 no-cache 指令是为了防止从缓存中返回过期的资源。
  2. 客户端发送的请求中如果包含 no-cache 指令，则表示客户端将不会接收缓存过的响应。于是，“中间”的缓存服务器必须把客户端请求转发给源服务器。
  3. 如果服务器中返回的响应包含 no-cache指令，那么缓存服务器不能对资源进行缓存。源服务器以后也将不再对缓存服务器请求中提出的资源有效性进行确认，且禁止其对响应资源进行缓存操作。
Cache-Control: no-cache=Location

由服务器返回的响应中，若报文首部字段 Cache-Control 中对 no-cache 字段名具体指定参数值，那么客户端在接收到这个被指定参数值的首部字段对应的响应报文后，就不能使用缓存。换言之，无参数值的首部字段可以使用缓存。只能在响应指令中指定该参数。

  • no-store 指令
Cache-Control: no-store

当使用 no-store 指令时，暗示请求（和对应的响应）或响应中包含机密信息。因此，该指令规定缓存不能在本地存储请求或响应的任一部分。
注意：no-cache 指令代表不缓存过期的指令，缓存会向源服务器进行有效期确认后处理资源；no-store 指令才是真正的不进行缓存

指定缓存期限和认证的指令

  • s-maxage 指令
Cache-Control: s-maxage=604800（单位：秒）

s-maxage 指令的功能和 max-age 指令的相同，它们的不同点是 s-maxage指令只适用于供多位用户使用的公共缓存服务器（一般指代理）。也就是说，对于向同一用户重复返回响应的服务器来说，这个指令没有任何作用。

另外，当使用 s-maxage 指令后，则直接忽略对 Expires 首部字段及 max-age 指令的处理。

  • max-age 指令
Cache-Control: max-age=604800（单位：秒）

当客户端发送的请求中包含 max-age 指令时，如果判定缓存资源的缓存时间数值比指定的时间更小，那么客户端就接收缓存的资源。另外，当指定 max-age 的值为0，那么缓存服务器通常需要将请求转发给源服务器。
当服务器返回的响应中包含 max-age 指令时，缓存服务器将不对资源的有效性再作确认，而 max-age 数值代表资源保存为缓存的最长时间。
应用 HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的情况时，会优先处理 max-age 指令，并忽略掉 Expires 首部字段；而 HTTP/1.0 版本的缓存服务器则相反。

  • min-fresh 指令
Cache-Control: min-fresh=60（单位：秒）

min-fresh 指令要求缓存服务器返回至少还未过指定时间的缓存资源。

  • max-stale 指令
Cache-Control: max-stale=3600（单位：秒）

使用 max-stale 可指示缓存资源，即使过期也照常接收。

如果指令未指定参数值，那么无论经过多久，客户端都会接收响应；如果指定了具体参数值，那么即使过期，只要仍处于 max-stale 指定的时间内，仍旧会被客户端接收。

  • only-if-cached 指令
Cache-Control: only-if-cached

表示客户端仅在缓存服务器本地缓存目标资源的情况下才会要求其返回。换言之，该指令要求缓存服务器不重新加载响应，也不会再次确认资源的有效性。

  • must-revalidate 指令
Cache-Control: must-revalidate

使用 must-revalidate 指令，代理会向源服务器再次验证即将返回的响应缓存目前是否仍有效。另外，使用 must-revalidate 指令会忽略请求的 max-stale 指令。

  • proxy-revalidate 指令
Cache-Control: proxy-revalidate

proxy-revalidate 指令要求所有的缓存服务器在接收到客户端带有该指令的请求返回响应之前，必须再次验证缓存的有效性。

  • no-transform 指令
Cache-Control: no-transform

使用 no-transform 指令规定无论是在请求还是响应中，缓存都不能改变实体主体的媒体类型。这样做可防止缓存或代理压缩图片等类似操作。

Cache-Control 扩展

Cache-Control: private, community="UCI"

通过 cache-extension 标记（token），可以扩展 Cache-Control 首部字段内的指令。上述 community 指令即扩展的指令，如果缓存服务器不能理解这个新指令，就会直接忽略掉。

Connection

Connection 首部字段具备以下两个作用:

控制不再转发的首部字段

Connection: Upgrade

在客户端发送请求和服务器返回响应中，使用 Connection 首部字段，可控制不再转发给代理的首部字段，即删除后再转发（即Hop-by-hop首部）。

管理持久连接

Connection: close

HTTP/1.1 版本的默认连接都是持久连接。当服务器端想明确断开连接时，则指定 Connection 首部字段的值为 close。

Connection: Keep-Alive

HTTP/1.1 之前的 HTTP 版本的默认连接都是非持久连接。为此，如果想在旧版本的 HTTP 协议上维持持续连接，则需要指定

Date

表明创建 HTTP 报文的日期和时间。

Date: Mon, 10 Jul 2017 15:50:06 GMT

HTTP/1.1 协议使用在 RFC1123 中规定的日期时间的格式。

Pragma

Pragma 首部字段是 HTTP/1.1 版本之前的历史遗留字段，仅作为与 HTTP/1.0 的向后兼容而定义。

Pragma: no-cache

该首部字段属于通用首部字段，但只用在客户端发送的请求中，要求所有的中间服务器不返回缓存的资源。

所有的中间服务器如果都能以 HTTP/1.1 为基准，那直接采用 Cache-Control: no-cache 指定缓存的处理方式最为理想。但是要整体掌握所有中间服务器使用的 HTTP 协议版本却是不现实的，所以，发送的请求会同时包含下面两个首部字段：

Cache-Control: no-cache
Pragma: no-cache

Trailer

Trailer: Expires

首部字段 Trailer 会事先说明在报文主体后记录了哪些首部字段。可应用在 HTTP/1.1 版本分块传输编码时。

Transfer-Encoding

Transfer-Encoding: chunked
  • 规定了传输报文主体时采用的编码方式。
  • HTTP/1.1 的传输编码方式仅对分块传输编码有效。

Upgrade

Upgrade: TSL/1.0

用于检测 HTTP 协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议。

Via

Via: 1.1 a1.sample.com(Squid/2.7)

为了追踪客户端和服务器端之间的请求和响应报文的传输路径。

报文经过代理或网关时，会现在首部字段 Via 中附加该服务器的信息，然后再进行转发。

首部字段 Via 不仅用于追踪报文的转发，还可避免请求回环的发生。

Warning

该首部字段通常会告知用户一些与缓存相关的问题的警告。

Warning 首部字段的格式如下：

Warning：[警告码][警告的主机:端口号] "[警告内容]"([日期时间])

最后的日期时间可省略。

HTTP/1.1 中定义了7种警告，警告码对应的警告内容仅推荐参考，另外，警告码具备扩展性，今后有可能追加新的警告码。

请求首部字段（HTTP/1.1）

Accept

Accept: text/html, application/xhtml+xml, application/xml; q=0.5
  • Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用 type/subtype这种形式，一次指定多种媒体类型。
  • 若想要给显示的媒体类型增加优先级，则使用 q=[数值] 来表示权重值，用分号（;）进行分隔。权重值的范围0~1（可精确到小数点后三位），且 1 为最大值。不指定权重值时，默认为 1。

Accept-Charset

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次性指定多种字符集。同样使用 q=[数值] 来表示相对优先级。

Accept-Encoding

Accept-Encoding: gzip, deflate

Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先顺序，并可一次性指定多种内容编码。同样使用 q=[数值] 来表示相对优先级。也可使用星号（*）作为通配符，指定任意的编码格式。

Accept-Language

Accept-Lanuage: zh-cn,zh;q=0.7,en=us,en;q=0.3

告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级，可一次性指定多种自然语言集。同样使用 q=[数值] 来表示相对优先级。

Authorization

Authorization: Basic ldfKDHKfkDdasSAEdasd==

告知服务器用户代理的认证信息（证书值）。通常，想要通过服务器认证的用户代理会在接收到返回的 401 状态码响应后，把首部字段 Authorization 加入请求中。共用缓存在接收到含有 Authorization 首部字段的请求时的操作处理会略有差异。

Expect

Expect: 100-continue

告知服务器客户端期望出现的某种特定行为。

From

From: Deeson_Woo@163.com

告知服务器使用用户代理的电子邮件地址。

Host

Host: www.jianshu.com

告知服务器，请求的资源所处的互联网主机和端口号。

Host 首部字段是 HTTP/1.1 规范内唯一一个必须被包含在请求内的首部字段。

若服务器未设定主机名，那直接发送一个空值即可 Host: 。

If-Match

形如 If-xxx 这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。

If-Match: "123456"
  • 首部字段 If-Match，属附带条件之一，它会告知服务器匹配资源所用的实体标记（ETag）值。这时的服务器无法使用弱 ETag 值。
  • 服务器会比对 If-Match 的字段值和资源的 ETag 值，仅当两者一致时，才会执行请求。反之，则返回状态码 412 Precondition Failed 的响应。
  • 还可以使用星号（*）指定 If-Match 的字段值。针对这种情况，服务器将会忽略 ETag 的值，只要资源存在就处理请求。

If-Modified-Since

If-Modified-Since: Mon, 10 Jul 2017 15:50:06 GMT
  • 首部字段 If-Modified-Since，属附带条件之一，用于确认代理或客户端拥有的本地资源的有效性
  • 它会告知服务器若 If-Modified-Since 字段值早于资源的更新时间，则希望能处理该请求。而在指定 If-Modified-Since 字段值的日期时间之后，如果请求的资源都没有过更新，则返回状态码 304 Not Modified 的响应。

If-None-Match

If-None-Match: "123456"

首部字段 If-None-Match 属于附带条件之一。它和首部字段 If-Match 作用相反。用于指定 If-None-Match 字段值的实体标记（ETag）值与请求资源的 ETag 不一致时，它就告知服务器处理该请求。

If-Range

If-Range: "123456"
  • 首部字段 If-Range 属于附带条件之一。它告知服务器若指定的 If-Range 字段值（ETag 值或者时间）和请求资源的 ETag 值或时间相一致时，则作为范围请求处理。反之，则返回全体资源。
  • 下面我们思考一下不使用首部字段 If-Range 发送请求的情况。服务器端的资源如果更新，那客户端持有资源中的一部分也会随之无效，当然，范围请求作为前提是无效的。这时，服务器会暂且以状态码 412 Precondition Failed 作为响应返回，其目的是催促客户端再次发送请求。这样一来，与使用首部字段 If-Range 比起来，就需要花费两倍的功夫。

If-Unmodified-Since

If-Unmodified-Since: Mon, 10 Jul 2017 15:50:06 GMT

首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相反。它的作用的是告知服务器，指定的请求资源只有在字段值内指定的日期时间之后，未发生更新的情况下，才能处理请求。如果在指定日期时间后发生了更新，则以状态码 412 Precondition Failed 作为响应返回。

Max-Forwards

Max-Forwards: 10

通过 TRACE 方法或 OPTIONS 方法，发送包含首部字段 Max-Forwards 的请求时，该字段以十进制整数形式指定可经过的服务器最大数目。服务器在往下一个服务器转发请求之前，Max-Forwards 的值减 1 后重新赋值。当服务器接收到 Max-Forwards 值为 0 的请求时，则不再进行转发，而是直接返回响应。

Proxy-Authorization

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5
  • 接收到从代理服务器发来的认证质询时，客户端会发送包含首部字段 Proxy-Authorization的请求，以告知服务器认证所需要的信息。
  • 这个行为是与客户端和服务器之间的 HTTP 访问认证相类似的，不同之处在于，认证行为发生在客户端与代理之间。

Range

Range: bytes=5001-10000

对于只需获取部分资源的范围请求，包含首部字段 Range 即可告知服务器资源的指定范围。

接收到附带 Range 首部字段请求的服务器，会在处理请求之后返回状态码为 206 Partial Content 的响应。无法处理该范围请求时，则会返回状态码 200 OK 的响应及全部资源。

Referer

Referer: http://www.sample.com/index.html

首部字段 Referer 会告知服务器请求的原始资源的 URI。

TE

TE: gzip, deflate; q=0.5