图解HTTP协议-笔记

第1章 Web及网络基础

1.1 使用HTTP协议访问Web

Web使用一种HTTP协议（HyperText Transfer Protocol，超文本传输协议）作为规范，完成从客户端到服务器端的一系列运作流程。 HTTP协议是Web通信的基础。

1.2 HTTP协议的背景

略

1.3 网络基础 TCP/IP

HTTP协议属于TCP/IP协议族内部的一个子集。

1.3.1 TCP/IP协议族

广义上的TCP/IP是互联网相关的各类协议族的总称。狭义上是指TCP和IP两种协议，或IP协议的通信过程中使用到的协议族的统称。

1.3.2 TCP/IP的分层管理

从高到低：应用层、传输层、网络层、数据链路层。

如图所示，层与层之间传输数据时，每经过一层时必定会打上一个该层所属的首部信息，反之接收端在层与层之间传输数据时，每经过一层会把对应的首部消去。这种把数据信息包装起来的做法称为封装。

1.4 与HTTP关系密切的协议：IP、TCP、DNS

1.4.1 IP协议 （负责传输）

IP协议位于网络层。作用是把各种数据包传送给对方。
关键条件：IP地址和MAC地址。

ARP协议

路由选择协议

略

1.4.2 确保可靠性的TCP协议

TCP位于传输层，提供可靠的字节流服务。为了方便传输，将大块数据分割成报文段为单位的数据包进行管理。

三次握手

1.4.3 负责域名解析的DNS协议

DNS位于应用层，提供域名到IP地址之间的解析服务。

1.5 HTTP协议与各个协议的关系

1.6 URI和URL

URI- Uniform Resource Identifier
URL-Uniform Resource Locator

1.6.1 统一资源标识符 URI

URI是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。
标准的URI协议有30种左右，其中包含 http, ftp, mailto, telnet, file等。

1.6.2 URI格式

第2章 简单的HTTP协议 （HTTP/1.1）

2.1 HTTP协议用于客户端和服务器端之间的通信

在两台计算机之间使用HTTP协议通信时，在一条通信线路上必定有一端是客户端，另一端是服务器端。其中请求访问文本或图像等资源的一端称为客户端，而提供资源响应的一段称为服务器端。

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

HTTP协议规定，请求必然由客户端发出，而服务器端响应该请求并返回。因此建立通信先从客户端开始，服务器端在没接收到请求之前不会发送响应。

具体示例

客户端请求报文
由请求方法、请求URI、协议版本、可选的请求首部字段和内容实体构成的。

GET /index.htm HTTP/1.1
Host: hackr.jp

GET ——请求访问服务器的类型，称为方法（Method）
/index.htm —— 指明请求访问的资源对象，也叫请求URI（request-URI）
HTTP/1.1 —— HTTP版本号，提示客户端使用的HTTP的协议功能。

服务器响应报文

服务器响应报文基本上由协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的原因短语、可选的相应首部字段以及实体主体构成。

2.3 HTTP是不保存状态的协议 无状态(Stateless)协议

HTTP协议自身不会对请求和响应之间的通信状态进行保存。也不保留之前一切的请求或响应报文的信息。
目的： 更快处理大量事务，确保协议的可伸缩性。
使用Cookie技术实现保持并管理状态的功能。

2.4 请求URI定位资源

HTTP协议使用URI定位互联网上的资源。需要在请求报文中将请求URI包含在内，请求URI的方式有很多。

如果不是访问特定资源而是对服务器本身发起请求，可以用一个*来代替请求URI。

2.5 告知服务器意图的HTTP方法

• GET
  GET用于请求已经被URI识别的资源，指定的资源经过服务器端解析后返回相应内容。
  如果请求的是文本，则保持原样返回；如果请求的是CGI（通用网关接口）那样的程序，则返回经过执行之后的输出结果（在服务器端运行）。

• POST
  POST方法用于传输实体的主体。GET方法也可以传输实体的主体，但主要用POST方法，POST的主要目的并不是获取响应的主体内容。

• PUT
  PUT方法用于传输文件。要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。
  问题在于PUT方法自身不带验证机制，任何人都可以上传文件，因此一般的Web网站不使用该方法。可以配合Web应用程序的验证机制或采用REST（表征状态转移）标准的架构设计的同类web网站开放使用PUT方法。

• HEAD
  HEAD方法和GET方法一样，只是不返回报文主体部分，用于确认URI的有效性以及资源更新的时间和日期等。

• DELETE
  DELETE方法用来删除文件，是与PUT相反的方法。DELETE方法按照请求URI删除指定的资源。存在与PUT方法一样的安全性问题。

• OPTIONS
  OPTIONS方法用来查询针对请求URI指定的资源支持的方法。

• TRACE
  TRACE方法让Web服务器端将之前的请求通信环回给客户端的方法，记录发送请求过程中经过的代理中转以及怎样被加工修改/篡改的，用来确认连接过程中发生的一系列操作。

• CONNECT
  CONNECT方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行TCP通信。主要是用SSL（Secure Sockets Layer，安全套接层）协议以及TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经过网络隧道传输。
  CONNECT方法格式： CONNECT 代理服务器名:端口 HTTP版本

2.6 使用方法下达命令

2.7 持久连接节省通信量

HTTP初始版本中，每进行一次HTTP通信就要断开一次TCP连接。
（三次握手-HTTP通信-四次挥手）
适用于容量很小的文本传输，而在涉及到大量资源传输时，则会增加通信量开销。

2.7.1 持久连接 HTTP Persistent Connections

持久连接也称为HTTP Keep-alive 或 HTTP Connection Reuse。只要任意一端都没有主动明确提出断开连接则保持TCP连接状态。
优势：减少了TCP连接的重复建立与断开造成的额外开销，减轻服务器端负载；HTTP请求和响应时间结束地更早，Web显示速度提高。

HTTP/1.1 所有连接都默认为持久连接，而1.0中没有标准化。

2.7.2 管线化

持久连接使管线化（pipelining）方式发送成为可能。管线化技术出现后，客户端不必等待响应就可以直接发送下一个请求，因此可以做到同时并行发送多个请求。

2.8 使用Cookie的状态管理

HTTP是无状态协议，可以减少服务器的CPU以及内存资源的消耗，且HTTP协议自身的简单性可以适用于各种场景中。

Cookie技术保留无状态协议的优点特征同时解决网络通信中状态保存的需求，通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

第3章 HTTP报文内的HTTP信息

3.1 HTTP报文

3.2 请求报文以及响应报文的结构

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

• 请求行：包含用于请求的方法、请求URI和HTTP版本。
• 状态行：包含表明响应结果的状态码，原因短语和HTTP版本。
• 首部字段： 包含表示请求和响应的 各种条件和属性的各类首部。（通用首部、请求首部、响应首部和实体首部）
• 其他: 可能包含HTTP的RFC里未定义的首部（Cookie等）。

3.3 编码提升传输速率

对HTTP传输过程中将数据进行编码会提升传输速率，但会消耗更多CPU资源进行编码。

3.3.1 报文主体和实体主体的差异

• 报文 message
  HTTP通信中的基本单位，由八位组字节流（octet sequence）组成。
• 实体 entity
  作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。

通常报文主体就是实体主体，但在传输过程中进行编码操作时，实体主体的内容发生变化，导致它和报文主体产生差异。

3.3.2 压缩传输的内容编码

• gzip (GNU zip)
• compress (UNIX)
• deflate (zlib)
• identity

3.3.3 分割发送的分块传输编码

整块传输完成之后浏览器才会显示请求页面，当大容量数据传输时则会很慢，通过吧数据分割成多块，能够让浏览器逐步显示页面。
分块传输编码将实体主体分块。每一块都会用十六进制标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标记。
使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。
HTTP/1.1中存在一种传输编码的机制，可以在通信时按某种编码方式传输，但只定义作用于分块传输编码中。

3.4 发送多种数据的多部分对象集合

HTTP协议中也采纳了多部分对象集合，发送的一份报文主体内可以含有多类型实体。通常是在图片和文本文件等上传时使用。

• multipart/form-data
  在Web表单文件上传时使用。
• multipart/byteranges
  状态码206（Partial Content）响应报文包含了多个范围的内容时使用。

在HTTP报文中使用多部分对象集合时，需要在首部字段里加上Content-type;
使用boundary字符串来划分多部分对象集合知名的各类实体。在boundary字符串指定的各个实体的起始行之前插入“–”标记，再多部分对象集合对应的字符串最后插入“–”标记作为结束。

3.5 获取部分内容的范围请求

网络传输需要一种可恢复的机制，能够从之前下载中断处恢复下载。
实现该功能需要指定下载的实体范围——范围请求（Range Request）

Range: bytes= #.... 可以用逗号分隔多重范围的范围请求

针对范围请求，相应会返回状态码为206 Partial Content的响应报文。对于多重范围的范围请求，响应首部字段Content-Type标明multipart/byteranges后返回响应报文。

3.6 内容协商返回最合适的内容

内容协商（Content Negotiation）机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为适合的资源。内容协商会议响应资源的语言、字符集、编码方式等作为判断的基准。首部字段如下：

• Accept
• Accept-Charset
• Accept-Encoding
• Accept-Language
• Content-Language

内容协商技术有以下3种类型。

• 服务器驱动协商（Server-driven Negotiation）
• 客户端驱动协商（Agent-driven Negotiation）
• 透明协商（Transparent Negotiation）

第4章 返回结果的HTTP状态码

HTTP状态码负责表示客户端HTTP请求的返回结果、标记服务器端的处理是否正常、通知出现的错误等工作。

4.1 状态码告知从服务器端返回的请求结果

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器端是正常处理了请求、还是出现了错误。

	类别	原因短语
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

4.2 2XX成功

2XX的响应结果表明请求被正常处理。

• 200 OK
  表示从客户端发来的请求在服务器端被正常处理。
• 204 No Content
  代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外也不允许返回任何实体的主体。一般在客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。
• 206 Partial Content
  响应报文中包含Content-Range 指定范围的实体内容。

4.3 3XX重定向

3XX响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。

• 301 Moved Permanently
  永久性重定向。表示该请求的资源已经被分配了新的URI，以后也应当使用资源现在所指的URI。（资源是永久移动，）

• 302 Found
  临时性重定向。该状态码表示请求的资源已经被分配了新的URI，希望用户（本次）能使用新的URI访问。

• 303 See Other
  该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。
  注意： 当301，302，303状态码返回时，几乎所有的浏览器都会把POST改为GET，并删除请求报文内点主体，之后请求会自动再次发送。（尽管301和302禁止将POST方法改为GET方法）

• 304 Not Modified
  表示客户端发送附带条件的请求时，服务器端允许请求访问资源，但未满足的情况。（与重定向事实上无关）

• 307 Temporary Redirect
  临时重定向。该状态码与302有相同的含义。

4.4 4XX客户端错误

• 400 Bad Request
  请求报文中存在语法错误；浏览器会像 200 OK一样对待该状态码。
• 401 Unauthorized
  该状态码表示发送的请求需要有通过HTTP认证（BASIC认证或DIGEST认证等）的认证信息；如果已经进行过一次请求，则表示认证失败。
  返回含有401的响应必须包含一个适用于被请求资源的WWW-Authenticate首部用于质询（Challenge）用户信息。当浏览器初次接收到401响应，会弹出认证用的对话窗口。
• 403 Forbidden
  表示对请求资源的访问被服务器拒绝了。（未获得文件系统的访问授权，访问权限出现某些问题）
• 404 Not Found

4.5 5XX服务器错误

• 500 Internal Server Error
  表明服务器端在执行请求时发生了错误。也有可能是Web应用存在的bug或临时故障。
• 503 Service Unavailable
  表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。可以写入Retry-After首部字段返回给客户端，如果已经事先得知解除上述情况所需时间。

第5章 与HTTP协作的Web服务器

一台Web服务器可搭建多个独立域名的Web网站，也可以作为通信路径上的中转服务器提升传输效率。

5.1 用单台虚拟主机实现多个域名

HTTP/1.1 允许一台HTTP服务器搭建多个Web站点。
使用虚拟主机（Virtual Host）功能，即使物理层面只有一台服务器，则可以假想已具有多台服务器。
客户端使用HTTP协议访问服务器。当客户端使用主机名和域名访问时，当请求发送到服务器，已经是按IP地址形式访问了，因此托管了多个虚拟主机的服务器在收到请求时就要弄清楚究竟要访问那个域名。
注意 在相同的IP地址下，客户端在发送HTTP请求时，必须在Host首部完整指定主机名或域名的URI。

5.2 通信数据转发程序：代理、网关、隧道

5.2.1 代理

代理是一种具有转发功能的应用程序，扮演了位于客户端和服务器“中间人”的角色，接受由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。

使用代理服务器的目的： 利用缓存技术减少网络带宽的流量；组织内部针对特定网站的访问控制；以获取访问日志为主要目的。

代理使用方法分类： 是否使用缓存？是否修改报文？

• 缓存代理
• 透明代理

5.2.2 网关

网关是转发其他服务器通信数据的服务器，接收从客户端发来的请求时，它就像自己拥有资源的源服务器一样对请求进行处理。有时客户端无法分辨自己的通信目标是否是一个网关。

网关工作机制与代理十分相似，区别在于网关可以使通信线路上的服务器提供非HTTP协议服务。

网关的优势 ：利用网关能够提高通信的安全性。（通过在客户端与网关之间的通信线路上加密以确保链接的安全）【网关连接数据库、网关联动信用卡结算系统】

5.2.3 隧道

隧道是在相隔甚远的客户端和服务器两者之间进行中转，并保持双方通信连接的应用程序。

隧道可以使用SSL等加密手段进行通信，目的是确保客户端与服务器进行安全的通信。

隧道本身不解析HTTP请求 【透明的】，原样将请求中转给之后的服务器。隧道在双方通信断开连接时结束。

5.3 保存资源的缓存

缓存指代理服务器或客户端本地磁盘内保存的资源副本。可以减少对源服务器的访问，节省通信流量与通信时间。

缓存服务器是代理服务器中的一种，并归类在缓存代理类型中。优势在于利用缓存，客户端就近从缓存服务器上获取资源，避免多次从源服务器转发相同的资源，源服务器也不必多次处理相同的请求。

1. 缓存的有效期限
   如果源服务器资源更新时，缓存的有效性则无法保证。

2. 客户端的缓存
   缓存除了存在缓存服务器中还可以存在客户端浏览器中。

无论是在缓存服务器还是客户端浏览器中的缓存，当判定缓存过期后，会向源服务器确认资源的有效性。如果判断缓存失败，浏览器或缓存服务器会再次请求新资源。

HTTP之前的协议

• FTP
• NNTP
• Archie
• WAIS
• Gopher

第6章 HTTP首部

6.1 HTTP报文首部

• HTTP请求报文
  

• HTTP响应报文
  

6.2 HTTP首部字段

6.2.1 HTTP首部字段传递重要信息

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

6.2.2 HTTP首部字段结构

首部字段名:字段值

其中对应其中一个首部字段的字段值可以有多个值。
HTTP首部字段如果出现重复在规范内尚未确定，不同的浏览器可能会优先处理第一次出现的或最后一次出现的首部字段。

6.2.3 4种HTTPHTTP首部字段类型

• 通用首部字段：请求和响应报文都会使用的；
• 请求首部字段：请求报文使用的首部字段—请求附加内容、客户端信息、响应内容优先级等；
• 响应首部字段：响应报文使用的首部字段—响应附加内容、要求客户端附加额外的内容信息；
• 实体首部字段：针对实体部分使用的字段—资源内容更新时间等与实体有关的信息。

6.2.4 HTTP/1.1 首部字段一览

• 通用首部字段
• 请求首部字段
• 响应首部字段
• 实体首部字段

6.2.5 非HTTP/1.1首部字段

除了上述首部字段（47种- RFC2616）之外，Cookie、Set-Cookie和Content-Disposition等其他RFC中定义的首部字段，也有很高的使用频率也很高。
这些非正式的首部字段统一归纳在RFC4229 HTTP Header Field Registration中。

6.2.6 End-to-end首部和Hop-by-hop首部

• 端到端首部
  分在此类别中的首部会转发给请求/响应的最终接受目标，且必须保存在由缓存生成的响应中，另外规定它必须被转发。
• 逐跳首部
  只对单词转发有效，会因为通过缓存或代理而不再转发。1.1中如果需要使用逐跳首部，需要提供Connection首部字段。
• HTTP/1.1中除如下八种首部字段是逐跳字段外别的都是端到端首部：
  Connection/Keep-Alive/Proxy-Authenticate/Proxy-Authorization/Trailer
  /TE/Transfer-Encoding/Upgrade

6.3 通用首部字段

6.3.1 Cache-Control 操作缓存的工作机制

• 缓存请求指令
  no-cache 表示客户端不会接受缓存过的响应（代理服务器必须将请求转发给源服务器）
  no-store 缓存不能在本地存储请求或响应的任意部分。
  max-age= [seconds] 如果缓存保存时间超过max-age则重新向源服务器转发请求，并更新资源。
  max-stale(=[seconds]) 指示缓存资源，即使过期也照常接收。
  min-fresh=[seconds] 要求缓存服务器返回至少还未过指定时间的缓存资源，超时则不返回。
  no-transform 禁止改变实体主体的媒体类型
  only-if-cached 仅在缓存服务器本地缓存目标资源时要求其返回。如无响应返回504。
  cache-extension

• 缓存响应指令
  public 其他用户也可以利用该缓存
  private 其他用户不可以访问该缓存
  no-cache 源服务器禁止缓存服务器对资源进行缓存
  no-store 缓存不能在本地存储请求或响应的任意部分
  no-transform 禁止改变实体主体的媒体类型
  must-revalidate 代理会向源服务器再次验证即将返回的响应缓存目前是否仍然有效（忽略max-stale）
  proxy-revalidate 要求所有缓存服务器在接收到客户端带有该指令的请求返回响应之前，再次验证缓存的有效性。
  max-age= [seconds] 如果响应中包含max-age指令时，缓存服务器不再对资源有效性进行确认。
  s-maxage= [seconds] 与max-age功能相同，但适用向多个客户端响应的公共服务器。
  cache-extension

6.3.2 Connection

Connection作用：

1. 控制不再转发给代理的首部字段；

Connection:不再转发的首部字段名

2. 管理持久连接。

Connection: close #HTTP/1.1 默认持久连接，服务器使用close字段值明确断开连接
Connection: Keep-Alive # 在旧版HTTP协议使用该字段值维持持续连接

6.3.3 Date

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

6.3.4 Pragma

Pragma是1.1版本之前的历史遗留字段。是只在客户端发送的请求中使用的通用首部字段。规范定义格式唯一：

Pragma:no-cache #客户端要求所有的中间服务器不返回缓存的资源

有时和Cache-Control: no-cache一同使用用于对所有HTTP版本缓存服务器做出如上要求。

6.3.5 Trailer

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

6.3.6 Transfer-Encoding

规定传输报文主体时采用的编码方式。HTTP/1.1的传输编码方式仅对分块传输编码有效。

6.3.7 Upgrade

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

6.3.8 Via

追踪客户端与服务器之间的请求和响应报文的传输路径。
可以追踪传输路径也可以避免请求回环的发生，因此经过代理时必须附加该首部字段内容。

6.3.9 Warning

Warning首部是从HTTP/1.0的响应首部（Retry-After）演变过来的。通常会警告用户一些与缓存相关的问题的警告。

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

警告码：
110
111
112
113
199
214
299

6.4 请求首部字段

6.4.1 Accept

Accept首部字段可通知服务器，用户代理能够处理的媒体类型以及媒体类型的相对优先级。可使用type/subtype形式，一次指定多种媒体类型：

• 文本文件
  text/html, text/plain, text/css, applications/xhtml+xml, application/xml…
• 图片文件
  image/jpeg, image/gif, image/png
• 视频文件
  video/mpeg, video/quicktime
• 应用程序使用的二进制文件
  application/octet-stream, application/zip

使用q=来额外表示权重值，用 ; 分隔。取值范围0.000~1.000，默认值1；

6.4.2 Accept-Charset

通知服务器用户代理支持的字符集以及字符集的相对的优先顺序。该首部字段应用于内容协商机制的服务器驱动协商。

6.4.3 Accept-Encoding

通知服务器用户代理支持的内容编码以及内容编码的相对的优先顺序。

6.4.4 Accept-Language

通知服务器用户代理能够处理的自然语言集以及自然语言集的相对的优先顺序。

6.4.5 Authorization

告知服务器用户代理的认证信息（证书值）。想通过服务器认证的用户代理会在接收到返回的401状态码响应后，把首部字段Autorization加入请求中。

6.4.6 Expect

告知服务器，期望出现的某种特定行为。例如HTTP/1.1规范唯一定义的100-continue

Expect: 100-continue

6.4.7 From

告知服务器使用用户代理的用户的电子邮件地址。也可能会记录在User-Agent首部字段内。

6.4.8 Host

告知服务器请求的资源所处的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段 。Host可以区分单台服务器分配多个域名的虚拟主机时请求发送的具体目的虚拟主机，这是它必须存在的意义。

6.4.9 条件请求首部字段

附带条件请求：如果符合条件，服务器则会接收客户端发送的请求；

• If-Match
  告知服务器匹配资源所用的实体标记值ETag( 字段值为 * ，只要资源存在就响应)，如果字段值和资源ETag值一致则执行请求。反之返回状态码412 Precondition Failed的响应。
• If-Modified-Since
  如果在字段值指定的日期之后，资源发生了更新，服务器则接受请求。反之返回304 Not Modified的响应。
• If-None-Match
  与If-Match相反，只有ETag值不匹配时，服务器才处理该请求。（GET和HEAD方法使用该首部字段可以获取最新资源）
• If-Range
  如果指定的字段值（ETag或时间）和请求资源的ETag值或时间一致时，则作为范围请求处理，反之返回全体资源。
• If-Unmodified-Since
  与If-Modified-Since相反，只有在指定资源在字段值指示的日期之后未发生更新的情况下才处理请求。反之返回状态码412 Precondition Failed的响应。

6.4.14 Max-Forwards

Max-Forwards:[经过服务器最大数目-十进制]

经过代理服务器转发请求之前，将上述字段值-1后转发给下一个服务器，如果服务器接收到请求时该字段值已为0，则直接返回响应，不再转发。

可以用于测试通信的传输路径上可能存在的问题。

6.4.15 Proxy-Authorization

与Authorization字段类似，当客户端接收到代理服务器发来的认证质询时，会发送包含Proxy-Authorization首部字段的请求，已告知服务器认证所需要的信息。

6.4.16 Range

只需获取部分资源的范围请求，用Range字段告知服务器资源的指定范围。
返回范围资源：客户端206 Partial Content；
无法处理范围请求：返回200 OK以及全部资源。

6.4.17 Referer

告知服务器请求的原始资源的URI。

6.4.18 TE

告知服务器客户端能够处理响应的传输编码方式以及相对优先级。它和首部Accept- Encoding
很像，但是用于传输编码。
还可以指定伴随trailers字段的分块传输编码的方式。

TE:trailers

6.4.19 User-Agent

告知服务器，创建请求的浏览器和用户代理名称等信息。
网络爬虫：可能添加爬虫作者的电子邮件地址；
经过代理：可能添加代理服务器的名称。

6.5 响应首部字段

用于补充响应的附加信息，服务器信息以及对客户端的附加要求等信息。

6.5.1 Accpet-Ranges

告知客户端服务器能否处理范围请求，以指定获取服务器端某个部分的资源。
字段值：可以-bytes；不可以-none。

6.5.2 Age

告知客户端源服务器在多久前创建了响应，字段值的单位为秒。
如果创建该响应的服务器是缓存服务器，Age指缓存后的响应再次发起认证到认证完成的时间值，代理创建响应时必须加上首部字段Age。

6.5.3 ETag

告知客户端实体标识，ETag是一种将资源以字符串形式做成唯一性标识的方式。服务器会为每份资源分配对应的ETag值，且没有统一的算法规则，当资源更新时，ETag也会更新。

• 强ETag值
  不论实体发生多细微的改变都会改变值。
• 弱ETag值
  只用于提示资源是否相同。只有发生根本改变，产生差异时才会改变ETag值。

6.5.4 Location

将响应接收方引导至某个与请求URI位置不同的资源，该字段会配合3XX Redirection的响应，提供重定向的URI。

6.5.5 Proxy-Authenticate

将代理服务器所要求的认证信息发送给客户端。

6.5.6 Retry-After

告知客户端应该在多久之后再次发送请求，可以是创建响应后的秒数也可以是具体的日期时间。
主要配合状态码503 Service Unavailable或3XX Redirection响应一起使用。

6.5.7 Server

告知客户端当前服务器上安装的HTTP服务器应用程序的信息。
标出：服务器上的软件应用名称 +（版本号以及安装时启用的可选项）。

6.5.8 Vary

可以对缓存进行控制。源服务器会向代理服务器传达关于本地缓存使用方法的指令。
当代理服务器接收到带有Vary首部字段的响应之后，如果再要进行缓存，仅对请求中含有相同Vary指定首部字段的请求返回缓存。即使是相同资源但Vary指定的首部字段不相同也要从源服务器重新获取资源。

6.5.9 WWW-Authenticate

用于HTTP访问认证。告知客户端适用于访问请求URI所指定资源的认证方案（Basic或Digest）和带参数提示的质询（Challenge）。
状态码401 Unauthorized响应中，肯定包含WWW-Authenticate首部字段。

6.6 实体首部字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用于补充内容的更新时间等与实体相关的信息。

6.6.1 Allow

首部字段Allow通知客户端能够支持Request-URI指定资源的所有HTTP方法。当服务器接收到不支持的HTTP方法时，响应返回状态码405 Method Not Allowed，且将所有支持的HTTP方法写入Allow首部字段。

6.6.2 Content-Encoding

告知客户端服务器对实体主体选用的内容编码方式。
四种编码方式：gzip，compress，deflate，identity

6.6.3 Content-Language

告知客户端主体主体使用的自然语言。

6.6.4 Content-Length

表明实体主体部分大小（单位/字节）。

6.6.5 Content-Location

给出与报文主体部分相对应的URI。和首部字段Location不同，Content-Location给出的是报文主体返回资源的URI。

6.6.6 Content-MD5

客户端会对接收的报文主体执行相同的MD5算法，然后与首部字段的Content-MD5字段值比较。用于检查报文主体在传输过程中是否保持完整，以及确认传输到达。

6.6.7 Content-Range

针对范围请求，返回响应时使用的首部字段Content-Range，能告知客户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为单位，表示当前发送部分以及整个实体大小。

6.6.8 Content-Type

说明实体主体内对象的媒体类型。

6.6.9 Expires

告知客户端资源失效的时期。缓存服务器接收到含有首部字段Expires的响应后，会以缓存来应答请求，在Expires字段值指定的时间之前，响应的副本会被一直保存。超过指定的时间后，缓存服务器在接受请求时，转向源服务器重新请求资源。
源服务器不希望缓存时：Expires字段值与date相同

6.6.10 Last-Modified

指明资源最终修改的时间，一般来说，这个值就是Request-URI指定资源被修改的时间。

6.7 为Cookie服务的首部字段

Cookie的工作机制是用户识别以及状态管理。Web网站为了管理用户状态通过浏览器将一些数据临时写入用户的计算机内。当用户访问该Web网站时，可通过通信方式取回之前发放的Cookie。

6.7.1 Set-Cookie

服务器准备开始管理客户端状态时，会事先告知各种信息：
Set-Cookie:[属性=…];[];[];

• NAME=VALUE
• expires=DATE
• path=PATH
• domain=域名
• Secure
• HttpOnly

6.7.2 Cookie

Cookie：status=enable
告知服务器，客户端想获得HTTP状态管理支持时，就会在请求中包含从服务器接收到的Cookie。接收到多个Cookie时，同样可以以多个Cookie形式发送。

6.8 其他首部字段

6.8.1 X-Frame-Options

HTTP响应首部，用于控制网站内容在Web网站的Frame标签内的显示问题。主要目的时防止劫持（Click Jacking）攻击。
字段值：

• DENY
• SAMEORIGIN

6.8.2 X-XSS-Protection

HTTP响应首部，针对跨站脚本攻击XSS的一种对策，用于控制浏览器XSS防护机制的开关。
字段值：
0:将ＸＳＳ过滤设置为无效状态。
1:将ＸＳＳ过滤设置为有效状态。

6.8.3 DNT

HTTP请求首部，意为拒绝个人信息被收集
０：同意被追踪
１：拒绝被追踪
Ｗｅｂ服务器需要对ＤＮＴ做对应的支持。

6.8.4 P3P

属于ＨＴＴＰ响应首部，利用P３Ｐ技术（在线隐私偏好平台）让Web网站上的个人隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。

第7章 HTTPS：确保Web安全

7.1 HTTP的缺点

• 通信使用明文（不加密），可能会被窃听。
• 不验证通信双方的身份，可能遭遇伪装。
• 无法证明报文的完整性，可能被篡改。

7.1.1 通信使用明文可能被窃听

TCP/IP是可能被窃听的网络，按TCP/IP的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。即使将报文加密处理，加密后的报文还是会被窥探到。

使用加密处理防止被窃听

• 通信的加密
  通过和SSL和TLS组合使用加密HTTP通信内容。使用SSL建立安全通信线路之后，就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP即为HTTPS或HTTP over SSL。

• 内容的加密
  将HTTP协议传输的内容本身加密。客户端需要对HTTP报文进行加密处理后再发送请求。前提是客户端和服务器同时具备加密和解密机制。但加密的内容仍有被篡改的风险，因为并不是对通信线路进行加密。

7.1.2 不验证通信方的身份可能会遭遇伪装

任何人都可以发起请求
HTTP协议中的请求和响应不会对通信方进行确认。无法保证“服务器是否就是发送请求中URI真正指定的主机，返回的响应是否真实返回到提出请求的客户端”。

查明对手的证书
使用SSL可以确定通信方，一方面提供加密处理，另一方面称为证书的手段。
证书由值得信任的第三方机构颁发，用于证明服务器和客户端是实际存在的，且很难伪造。

7.1.3 无法证明报文完整性

接收到的内容可能有误
无法确认发出的请求/响应跟接收到的请求/响应是前后相同的。

如何防止篡改
常用MD5和SHA-1等散列值校验的方法以及用来确认文件的数字签名方法。提供文件下载的Web网站也会提供响应的以PGP（Perfect Good Privacy）用来证明创建文件的数字签名。但仍然存在问题在于：如果PGP跟MD5本身被篡改的话，用户是无法分辨的。

7.2 HTTP+加密+认证+完整性保护=HTTPS

7.2.1 HTTP加上加密处理和认证以及完整性保护后即是HTTPS

7.2.2 HTTPS是身披SSL外壳的HTTP

HTTPS并不是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替而已。

7.2.3 相互交换密钥的公开密钥加密技术

共享密钥加密
共享密钥也叫对称密钥加密，加密解密使用相同的共享密钥，但如何安全地转交共享密钥是一个问题。

SSL采用一种公开密钥加密的方式。
使用两把密钥的公开密钥加密
公开密钥使用一对非对称的密钥：私有密钥 private key 和公开密钥 public key；

HTTPS采用混合加密机制
HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。
在交换密钥环节使用公开密钥加密方式，之后建立通信交换报文阶段则使用共享密钥加密方式。

7.2.4 证明公开密钥正确性的证书

公开密钥加密方式仍然存在问题：无法证明公开密钥本身就是货真价实的公开密钥。可以使用由数字证书认证机构和其相关机关颁发的公开密钥证书。

7.2.5 HTTPS的安全通信机制

第8章 确认访问用户身份的认证

HTTP使用的认证方式：

• BASIC认证
• DIGEST认证
• SSL客户端认证
• FormBase认证

8.2 BASIC认证

BASIC认证弊端：BASIC64编码不需要任何附加信息即可解码，如果在非加密线路上进行BASIC认证，被人窃听很容易被盗。
除此之外，如果想再进行一次BASIC认证时，一般浏览器无法实现认证注销操作。
BASIC不够灵活且达不到多数Web期望的安全性等级。

8.3 DIGEST认证

DIGEST同样适用质询/响应的方式，但不会像BASIC那样直接发送明文密码。
质询/响应方式：

DIGEST认证步骤：

8.4 SSL客户端认证

SSL客户端认证借由HTTPS的客户端证书完成认证。凭借客户端证书认证，服务器可确认访问是否来自已登陆的客户端。

SSL客户端认证的步骤

1. 接收到需要认证资源的请求，服务器发送Certificate Request报文，要求客户端提供客户端证书。
2. 用户选择将发送的客户端证书后，客户端会将客户端证书信息以Client Certificate报文方式发送给服务器。
3. 服务器验证证书通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。

8.5 基于表单认证

基于表单的认证方法并不是在HTTP协议中定义的，客户端会向服务器上的Web应用程序发送登录信息，按照登录信息的验证结果认证。

认证多半为表单认证

Session管理和Cookie应用

第9章 基于HTTP的功能追加协议

9.1 基于HTTP的协议

9.2 消除HTTP瓶颈的SPDY

https://www.chromium.org/spdy/

9.2.1