本文内容为《图解HTTP》一书学习笔记。本文主要概述一到三章内容。

第一章 了解Web及网路基础

第一章主要内容是对TCP/IP协议族进行简介，与《图解TCP/IP》一书内容有重复，此处就不全做记录而是摘选部分记录。
下图是用户打开浏览器访问网址时，IP协议、TCP协议和DNS服务在使用HTTP协议的通信过程中发生的作用。

1.7 URI和URL

URL(Uniform Resource Locator)：统一资源定位符，使用 Web 浏览器访问 Web 页面时需要输入的网页地址。
URI(Uniform Resource Identifier)：统一资源标识符，由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称（采用HTTP协议时，协议方案就是http，除此之外还有ftp、mailto、telnet、file等）。
URI 用字符串标识某一互联网资源，而 URL 表示资源的地点（互联网上所处的位置），可见 URL 是 URI 的子集。下图列举几种URI例子。

URI例子

1.7.2 URI格式

绝对URI的格式

• 协议方案名：使用http：或https：等协议方案名获取访问资源时要指定协议类型。不区分字母大小写，最后附一个冒号（：）。
• 登录信息（认证）：指定用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。此项是可选项。
• 服务器地址：使用绝对URL必须指定待访问的服务器地址。地址可以是DNS可解析的名称（例如hackr.jp），可以是IPv4地址（例如192.168.1.1），也可以是IPv6地址（例如[0:0:0:0:0:0:0:1]）。
• 服务器端口号：指定服务器连接的网路端口号。可选项。用户省略则使用默认端口。
• 带层次的文件路径：指定服务器上的文件路径来定位特指的资源。与UNIX系统的文件目录结构类似。
• 查询字符串：针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数。可选项。
• 片段标识符：标记出已获取资源中的子资源（文档内的某个位置）。但在RFC（Request for comments，征求修正意见书，用来制定HTTP协议技术标准的文档）中并没有明确规定其使用方法方法。可选项。

第二章 简单的HTTP协议

• 应用 HTTP 协议时，必定是一端担任客户端的角色，另一端担任服务器端的角色

• 请求必定先由客户端发出，服务器端接收到请求之后再回复响应
  下面来看一个具体的实例：

  
  

请求报文：

请求报文的组成

响应报文的组成

2.3 HTTP 是不保存状态的协议

HTTP 协议自身不具备保存之前发送过的请求或者响应的功能，即对于发送过的请求和响应都不做持久化处理。这是为了保持协议的可伸缩性，以便更快地处理大量事务。
但如果无状态会导致业务处理变得棘手。举个例子，用户登录到一家购物网站，即使他跳到该站的其他页面后，也需要能够继续保持登录状态。网站为了能够掌握是谁送出的请求，需要保存用户的状态。
HTTP/1.1 虽然是无状态协议，但是为了实现期望的保持状态的功能，于是引入了 Cookie 技术。

2.4 请求URI定位资源

上图是一个请求的例子。
如果不是访问特定资源而是对服务器本身发起请求，可以用一个*来代替请求URI。下面这个例子是查询HTTP服务器端支持的HTTP方法种类：

OPTIONS * HTTP/1.1

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

HTTP/1.1 中常用的方法有8种，HTTP方法区分大小写，注意要用大写字母：

1. GET：获取资源。GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。如果请求的资源是文本，那就保持原样返回；如果是像 CGI （Common Gateway Interface，通用网关接口）那样的程序，则返回经过执行后的输出结果。

   
   
   GET

2. POST：传输实体主体。GET与POST功能很相似，但传输一般用POST。GET是客户端想访问服务器某个资源，POST是客户端想把某条信息告诉服务器。

   
   
   POST

3. PUT：传输文件。PUT 方法用来传输文件（客户端传给服务器），在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。但鉴于HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件，存在安全性问题，因此一般的 Web 网站不使用此方法。

   
   
   PUT
   
   

   响应的意思其实是请求执行成功了，但无数据返回。

4. HEAD：获得报文首部。HEAD 方法和 GET 方法一样，只是不返回报文主体内容。用于确认 URI 的有效性及资源更新的日期时间等。

   
   
   HEAD

5. DELETE：删除文件，是和 PUT 相反的方法。按照请求URI删除指定的资源。但和 PUT 方法相同，DELETE 方法本身也是不带验证机制的方法，所以一般的 Web 网站不会使用 DELETE 方法。

   
   
   DELETE

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

   
   
   OPTIONS
7. TRACE：追踪路径。很少用到的一个方法。
8. CONNECT：要求用隧道协议连接代理。CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接层） 和 TLS（Transport Layer Security，传输层安全） 协议把通信内容加密后经网络隧道传输。CONNECT方法格式如下：

CONNECT 代理服务器名：端口号 HTTP版本

CONNECT

2.6 使用方法下达命令

略

2.7 持久连接节省通信量

HTTP初始版本中，每进行一次HTTP通信就要断开一次TCP连接，如下图所示。

在传输容量很小的文本时，这么做没问题。但如果文档中包含大量图片，比如使用浏览器浏览一个包含多张图片的HTML页面时，发送请求访问HTML页面资源的同时，也会请求该HTML页面里包含的图片。每次的请求都会造成无谓的TCP连接建立和断开，通信开销太大，如下图所示。

2.7.1 持久连接

为了解决上述问题，HTTP/1.1引入了持久连接（HTTP Persistent Connections），只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

持久连接的好处在于减少了 TCP 连接的重复建立和断开造成的额外开销，减轻了服务器端的负载。另外减少开销的那部分时间，使得HTTP请求和响应能够更早的结束，这样Web页面的显示速度也就响应提高了。
在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 中并未标准化。

2.7.2 管线化

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

2.8 使用 Cookie 的状态管理

HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管理。假设要求登录认证的Web页面本身无法进行状态的管理（不记录已登录的状态），那么每次跳转新页面不是要再次登录，就是要在每次请求报文中附加参数来管理登录状态。
保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入Cookie 技术。Cookie 技术通过在请求和响应报文中写入了 Cookie 信息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。
服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

没有Cookie信息状态下的请求

第2次以后（存有Cookie信息状态）的请求

下图是发生Cookie交互时，HTTP请求报文和响应报文的内容：

第3章 HTTP报文内的HTTP信息

用于HTTP协议交互的信息被称为HTTP报文。客户端发送的报文称为请求报文，服务器端响应的报文称为响应报文。
HTTP 报文大致可以分为报文首部和报文主体。报文中不一定有报文主体。

HTTP报文的结构

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

请求报文（上）和响应报文（下）的结构

请求报文和响应报文首部内容由以下几部分组成。

• 请求行：包含用于请求的方法、请求 URI 和 HTTP 版本
• 状态行：包含表明响应结果的状态码、原因短语和 HTTP 版本
• 首部字段：包含表示请求和响应的各种条件和属性的各类首部。一般有 4 种首部：通用首部、请求首部、响应首部和实体首部。

• 其他：可能包含HTTP的RFC里未定义的首部（Cookie等）。

  
  
  请求报文（上）和响应报文（下）的实例

3.3 编码提升传输速率

3.3.1报文主体和实体主体的区别

• 报文（message）：HTTP通信中的基本单位，由8位组字节流（octet sequence，其中octet为8个比特）组成，通过HTTP通信传输。
• 实体（entity）：作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。
  HTTP 报文的主体用于传输请求或响应的实体主体。
  通常，报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。

3.3.2 压缩传输的内容编码

内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。
常用的内容编码有以下几种：gzip(GNU zip)、compress(UNIX 系统的标准压缩)、deflate(zlib) 和 identity(不进行压缩)

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

在HTTP通信过程中，在传输大数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。
分块传输编码会将实体主体分为多个部分。使用分块传输编码的实体主体会由接收的客户端负责界面，恢复到编码前的实体主体。

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

邮件采用了MIME（Multipurpose Internet Mail Extensisons，多用途因特网邮件扩展）机制，从而可以处理文件、图片、视频等多类型数据。MIME扩展中会使用多部分对象集合（Multipart）的方法，来容纳多份不同类型的数据。
在 HTTP 协议中也采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。
多部分对象集合包含的对象具体类型略。

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

为了实现能在下载中断处恢复下载，要指定下载的实体范围。指定范围发送的请求叫做范围请求。对一份有10000字节大小的资源，如果使用范围请求，可以只请求5001-10000字节内的资源。
执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围。byte范围的指定形式如下：

• 5001-10000字节

Range：bytes=5001-10000

• 从 5001 字节之后的全部

Range：bytes=5001-

• 从一开始到 3000 字节和 5000-7000 字节的多范围请求

Range：bytes=-3000，5000-7000

针对范围请求，响应会返回状态码为 206 Partial Content 的响应报文。对于多重范围的范围请求，响应会在首部字段 Content-Type 标明 multipart/byteranges 后返回响应报文。
如果服务器端无法响应范围请求，则会返回状态码 200 OK 和完整的实体内容

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

内容协商

当浏览器的默认语言为英语或中文，访问相同URI的Web页面时，则会显示对应的英语版或中文版的Web页面。这样的机制为内容协商。
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为合适的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。
包含在请求报文中的某些首部字段（如下）就是判断的基准：

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