图解http阅读笔记

第1章——了解web及网络基础

1.1使用 HTTP 协议访问 Web

Web 使用一种名为 HTTP（HyperText Transfer Protocol，超文本传输协议 [超文本转移协议] --关于HTTP中文翻译的讨论）的协议作为规范，完成从客户端到服务器端等一系列运作流程。而协议是指规则的约定。可以说，Web 是建立在 HTTP 协议上通信的。

1.2 HTTP 的诞生

• HTTP/0.9 —— HTTP 于 1990 年问世。那时的 HTTP 并没有作为正式的标准被建立。现在的 HTTP 其实含有 HTTP1.0 之前版本的意思，因此被称为HTTP/0.9。
• HTTP/1.0 —— HTTP 正式作为标准被公布是在 1996 年的 5 月，版本被命名为HTTP/1.0，并记载于 RFC1945。虽说是初期标准，但该协议标准至今仍被广泛使用在服务器端。
• HTTP/1.1 —— 1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 协议版本。当初的标准是 RFC2068，之后发布的修订版 RFC2616 就是当前的最新版本。
• HTTP/2.0 —— 深入理解http2.0协议，看这篇就够了！

当年 HTTP 协议的出现主要是为了解决文本传输的难题。由于协议本身非常简单，于是在此基础上设想了很多应用方法并投入了实际使用。现在 HTTP 协议已经超出了 Web 这个框架的局限，被运用到了各种场景里。

1.3 网络基础 TCP/IP

通常使用的网络（包括互联网）是在 TCP/IP 协议族的基础上运作的。而 HTTP 属于它内部的一个子集。

TCP/IP 协议族里重要的一点就是分层。TCP/IP 协议族按层次分别分为以下 4 层：应用层、传输层、网络层和数据链路层。分层的好处在于，当协议某个部分需要变动时不需要整体的替换掉整个协议，只需替换变动的层即可，将各层之间的接口做好规划就可以让每个内部的层自由设计，同时层次化之后设计也更加简单，各个层只需考虑自身的功能实现即可。

TCP/IP 协议族各层的作用如下：

• 应用层

  应用层决定了向用户提供应用服务时通信的活动。TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域名系统）服务就是其中两类。HTTP 协议也处于该层。

• 传输层

  传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议：TCP（Transmission ControlProtocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协议）。

• 网络层（又名网络互连层）

  网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。

• 链路层（又名数据链路层，网络接口层）

  用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在链路层的作用范围之内。

利用 TCP/IP 协议族进行数据交互时会按分层依次传递数据，发送端自顶向下发送传输数据时每经过一层就会打上一个首部信息，接受层自底向上接受数据时会一层一层去掉首部信息，这种数据的包装方法称之为封装。

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

• 负责传输的 IP 协议

  IP 间的通信依赖 MAC 地址（物理地址，基本上是唯一且不变的）。在网络上，通信的双方在同一局域网（LAN）内的情况是很少的，通常是经过多台计算机和网络设备中转才能连接到对方。而在进行中转时，会利用下一站中转设备的 MAC地址来搜索下一个中转目标。这时，会采用 ARP 协议（AddressResolution Protocol）。ARP 是一种用以解析地址的协议，根据通信方的 IP 地址就可以反查出对应的 MAC 地址。

• 确保可靠性的 TCP 协议

  TCP位于传输层，提供可靠的字节流服务，为保证可靠，TCP在将数据包送出去后通过三次握手等一些手段来保证通信的可靠性。

• 负责域名解析的 DNS 服务

  DNS是位于应用层的协议，它提供域名到 IP 地址之间的解析服务，DNS 协议提供通过域名查找 IP 地址，或逆向从 IP 地址反查域名的服务。

各种协议与 HTTP 协议的关系：

1.5 URI 和 URL

与 URI（统一资源标识符）相比，我们更熟悉 URL（UniformResource Locator，统一资源定位符）。URI 用字符串标识某一互联网资源，而 URL 表示资源的地点（互联网上所处的位置）。可见 URL 是 URI 的子集。

表示指定的 URI，要使用涵盖全部必要信息的绝对 URI、绝对 URL 以及相对 URL。相对 URL，是指从浏览器中基本 URI 处指定的 URL，形如 /image/logo.gif。

URI格式如下:

• 登录信息：此项为可选项
• 服务器地址：可以使DNS可解析的域名，也可以是IPv4或IPv6地址名
• 服务器端口号：此项是可选项，忽略则自动使用默认的端口号
• 查询字符串和片段标识符：此项是可选项

第2章——简单的 HTTP 协议

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

应用 HTTP 协议时，必定是一端担任客户端（请求访问文本或图像等资源的一端）角色，另一端担任服务器端（提供资源响应的一 端）角色

有时候，按实际情况，两台计算机作为客户端和服务器端的角色有可能会互换。但就仅从一条通信路线来说，服务器端和客户端的角色是 确定的，而用 HTTP 协议能够明确区分哪端是客户端，哪端是服务器端。

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

HTTP 协议规定，请求从客户端发出，最后服务器端响应该请求并返回。

2.3 HTTP 是不保存状态的协议

HTTP 是一种不保存状态，即无状态（stateless）协议。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性。但为了实现期望的保持状态功能，于是引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管理状态了。

2.4 请求 URI 定位资源

HTTP 协议使用 URI 定位互联网上的资源。正是因为 URI 的特定功能，在互联网上任意位置的资源都能访问到。当客户端请求访问资源而发送请求时，URI 需要将作为请求报文中的请求 URI 包含在内。

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

OPTIONS * HTTP/1.1

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

• GET ：获取资源

  GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器端解析后返回响应内容。

• POST：传输实体主体

  POST 方法用来传输实体的主体。然后接受返回的响应

• PUT：传输文件

  PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。

• HEAD：获得报文首部

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

• DELETE：删除文件

  DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按请求 URI 删除指定的资源。但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机制，所以一般的 Web 网站也不使用 DELETE 方法。

• OPTIONS：询问支持的方法

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

• TRACE：追踪路径

  TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。不常用。

• CONNECT：要求用隧道协议连接代理

  CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加 密后经网络隧道传输。

2.6 持久连接节省通信量

在HTTP协议的初始版本中每进行一次通信就要创建和断开一次TCP连接，随着网络的发展，传输内容不再局限于容量很小的文本，大容量的图片多了以后每次请求都会造成无谓的通信开销。

所谓为了解决这个问题，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。

在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内并未标准化。虽然有一部分服务器通过非标准的手段实现了持久连接，但服务器端不一定能够支持持久连接。毫无疑问，除了服务器端，客户端也需要支持持久连接。

同时持久化连接使得管线化成为可能，不用等待响应即可发送下一个请求，速度更快。

2.7 使用 Cookie 的状态管理

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

第3章——HTTP 报文内的 HTTP信息

3.1 HTTP 报文

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

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

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

3.3 编码提升传输速率

HTTP传输数据是可以按数据原貌传输，也可以进行编码后再传输，编码后传输速率提高但是会消耗更多的cpu资源。

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

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

HTTP 报文的主体用于传输请求或响应的实体主体。通常，报文主体等于实体主体。只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。

HTTP协议中有一种被成为内容编码的功能类似于zip压缩文件，可以在实体内容上指明编码格式压缩，由客户端接收后在解码。常用的内容编码有以下几种：

• gzip（GNU zip）
• compress（UNIX 系统的标准压缩）
• deflate（zlib）
• identity（不进行编码）

HTTP还可以将实体主体分块进行传输（分块传输编码），分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标记。使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。

HTTP/1.1 中存在一种称为传输编码（Transfer Coding）的机制，它可以在通信时按某种编码方式传输，但只定义作用于分块传输编码中。

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

HTTP 协议中采用了多部分对象集合，可以容纳多份不同类型的数据，多部分集合包含对象如下：

• multipart/form-data：在 Web 表单文件上传时使用。

  Content-Type: multipart/form-data; boundary=AaB03x 
  --AaB03x 
  Content-Disposition: form-data; name="field1"
  ​
  Joe Blow 
  --AaB03x 
  Content-Disposition: form-data; name="pics"; filename="file1.txt"
  Content-Type: text/plain 
  ​
  ...（file1.txt的数据）... --AaB03x--
  

• multipart/byteranges：状态码 206（Partial Content，部分内容）响应报文包含了多个范围的内容时使用。

  HTTP/1.1 206 Partial Content
  Date: Fri, 13 Jul 2012 02:45:26 GMT 
  Last-Modified: Fri, 31 Aug 2007 02:02:20 GMT 
  Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES 
  ​
  --THIS_STRING_SEPARATES 
  Content-Type: application/pdf 
  Content-Range: bytes 500-999/8000
  ​
  ...（范围指定的数据）... 
  --THIS_STRING_SEPARATES 
  Content-Type: application/pdf 
  Content-Range: bytes 7000-7999/8000 
  ​
  ...（范围指定的数据）... 
  --THIS_STRING_SEPARATES--
  

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

在网络传输过程中为了解决大文件传输中断需要重新开始的问题，提供了一种恢复机制，通过指定下载的实体范围实现范围请求。

范围请求的几种形式：

//5001~10 000 字节
Range: bytes=5001-10000
//从 5001 字节之后全部的
Range: bytes=5001-
//从一开始到 3000 字节和 5000~7000 字节的多重范围
Range: bytes=-3000, 5000-7000

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

在访问web网站时可能存在语言或者其他差异，导致同一个URI呈现出的页面是不同的，比如说当浏览器的默认语言为英语或中文，访问相同 URI 的 Web 页面时，则会显示对应的英语版或中文版的 Web 页面。这样的机制称为内容协商（Content Negotiation）

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

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

0. 服务器驱动协商（Server-driven Negotiation）

   由服务器端进行内容协商。以请求的首部字段为参考，在服务器端自动处理。但对用户来说，以浏览器发送的信息作为判定的依据，并不一定能筛选出最优内容。

1. 客户端驱动协商（Agent-driven Negotiation）

   由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。还可以利用 JavaScript 脚本在 Web 页面上自动进行上述选择。比如按 OS 的类型或浏览器类型，自行切换成 PC 版页面或手机版页面。

2. 透明协商（Transparent Negotiation）

   是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。

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

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

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

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

记录在案的状态码种类繁多，但是只需要了解具有代表性的状态码即可。

4.2 2XX 成功

• 200 OK

  表示从客户端发来的请求在服务器端被正常处理了

• 204 No Content

  该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。

• 206 Partial Content

  该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

4.3 3XX 重定向

• 301 Moved Permanently

  永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI。

• 302 Found

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

• 303 See Other

  该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET方法定向获取请求的资源。

  303 状态码和 302 Found 状态码有着相同的功能，但 303 状态码明确表示客户端应当采用 GET 方法获取资源，这点与 302 状态码有区别。

  

• 304 Not Modified

  该状态码表示客户端发送附带条件的请求（指采用 GET 方法的请求报文中包含 If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since 中任一首部）时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。

• 307 Temporary Redirect

  临时重定向。该状态码与 302 Found 有着相同的含义。但是307 会遵照浏览器标准，不会从 POST 变成 GET。但是，对于处理响 应时的行为，每种浏览器有可能出现不同的情况。

4.4 4XX 客户端错误

• 400 Bad Request

  该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。（浏览器会像 200 OK 一样对待该状态 码）

• 401 Unauthorized

  该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。另外若之前已进行过 1 次请求，则表示 用 户认证失败。

• 403 Forbidden

  该状态码表明对请求资源的访问被服务器拒绝了，可能是未获得访问权限等原因，服务器端可以选择是否给出拒绝的详细理由。

• 404 Not Found

  该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。

4.5 5XX 服务器错误

• 500 Internal Server Error

  该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web应用存在的 bug 或某些临时的故障。

• 503 Service Unavailable

  该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

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

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

一台物理意义上的服务器可以通过虚拟主机（Virtual Host，又称虚拟服务器）的功能实现多个域名，这些域名通过DNS解析后是同一个ip地址，因此在发送 HTTP 请求时，必须在 Host 首部内完整指定主机名或域名的 URI。

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

• 代理

  代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求 URI，会直接发送给前方持有资源的目标服务器。使用代理服务器的优点有：通过缓存技术缓解网络带宽，对特定网站实施访问控制等。按使用方法可以大致分为两类，一种是否使用缓存，一种是否会修改报文。

  

  • 缓存代理

    代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。

  • 透明代理

    转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理

• 网关

  利用网关可以由 HTTP 请求转化为其他协议通信,利用网关可以提高通信的安全性，因为可以在客户端和网关之间的通信线路上加密。

• 隧道

  隧道可按要求建立起一条与其他服务器的通信线路，届时使用 SSL 等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。

5.3 保存资源的缓存

缓存指的是在代理服务器（上文中说到的缓存代理类型）或者在客户端本地磁盘保存一些资源副本，在下次访问这些资源时可以直接获取，减少对服务器的访问。

使用缓存时要注意缓存的有效期限，因为有可能在服务器上的某个资源被请求后缓存在了客户端本地，然后服务器上的资源被改动了，这时客户端再去请求得到的是本地缓存的旧的资源，类似于数据库中的缓存一致性问题。所以缓存一般要设置一个过期时间当过期了再去重新获取资源以及一些其他的办法来确保缓存数据是同服务器上的资源是一致的。