本文最后更新于 4 年前，文中所描述的信息可能已发生改变。

图解HTTP ​

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

1.1 使用HTTP访问web ​

1.2 HTTP的诞生 ​

• 1.2.1 为知识共享而规划web

  3 项 WWW 构建技术

  • SGML（Standard Generalized Markup Language，标准通用标记语言）

    HTML（HyperText Markup Language，超文本标记语言）

  • 作为文档传递协议的 HTTP

  • URL（Uniform Resource Locator，统一资源定位符）。

• 1.2.2 web成长阶段

  web的发展历史

• 1.2.3　驻足不前的 HTTP

  HTTP发展的很慢

1.3 网络基础TCP/IP ​

1. TCP/IP协议族 ​

把与互联网相关联的协议集合起来总称为 TCP/IP也有说法认为，TCP/IP 是指 TCP 和 IP 这两种协议。还有一种说法认为，TCP/IP 是在 IP 协议的通信过程中，使用到的协议族的统称。

2. TCP/IP的分层管理 ​

• 应用层

  应用层决定了向用户提供应用服务时通信的活动。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域名系统）服务就是其中两类。

  HTTP 协议也处于该层。

• 传输层

  传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。

  在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报协议）。

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

  网络层用来处理在网络上流动的数据包。

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

  用来处理连接网络的硬件部分。

3. TCP/IP 通信传输流 ​

​

1.4 与HTTP密切相关的协议 ​

1. 负责传输的 IP 协议 ​

不要把IP和IP协议搞混，IP其实是一种协议的名称。

IP 协议的作用是把各种数据包传送给对方。

2. 确保可靠性的 TCP 协议 ​

TCP 位于传输层，提供可靠的字节流服务。

所谓的字节流服务（Byte Stream Service）是指，为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。

3. 负责域名解析的 DNS 服务 ​

它提供域名到 IP 地址之间的解析服务。

1.6　各种协议与 HTTP 协议的关系 ​

​

1.7　URI 和 URL ​

• URL 正是使用 Web 浏览器等访问Web 页面时需要输入的网页地址。
• URI 是 Uniform Resource Identifier 的缩写。URI 就是由某个协议方案表示的资源的定位标识符。协议方案是指访问资源所使用的协议类型名称。

第 2章 简单的 HTTP协议 ​

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

在两台计算机之间使用 HTTP 协议通信时，在一条通信线路上必定有一端是客户端，另一端则是服务器端

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

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

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

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

2.3　HTTP 是不保存状态的协议 ​

HTTP 是一种不保存状态，即无状态（stateless）协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。

也就是不保留之前的访问记录，主要是为了更快地处理大量的事务。

2.4　请求 URI 定位资源 ​

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

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

• GET：获取资源

• POST：传输实体主体

• PUT：传输文件

• HEAD：获得报文首部

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

• DELETE：删除文件

• OPTIONS：询问支持的方法

• TRACE：追踪路径

  TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。 发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最后接收到请求的服务器端则返回状态码 200 OK 的响应。

  但是，TRACE 方法本来就不怎么常用，再加上它容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了。

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

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

2.6　使用方法下达命令 ​

2.7　持久连接节省通信量 ​

早期的HTTP 协议的初始版本中，每进行一次 HTTP 通信就要断开一次TCP 连接。

以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使这样也没有多大问题。可随着 HTTP 的普及，文档中包含大量图片的情况多了起来。

1. 持久连接 ​

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

2. 管线化 ​

持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。

这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。

2.8　使用 Cookie 的状态管理 ​

由于HTTP是无状态的，所以无法在用户下次使用时根据之前的状态进行本次的请求处理。也就是说用户每次使用web都需要重新登录，这明显是不方便的。所以有了Cookie技术。

Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。

服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

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

3.1　HTTP 报文 ​

用于 HTTP 协议交互的信息被称为 HTTP 报文。

请求端（客户端）的HTTP 报文叫做请求报文，响应端（服务器端）的叫做响应报文。

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

请求行包含用于请求的方法，请求 URI 和 HTTP 版本。状态行包含表明响应结果的状态码，原因短语和 HTTP 版本。

首部字段包含表示请求和响应的各种条件和属性的各类首部。一般有 4 种首部，分别是：通用首部、请求首部、响应首部和实体首部。

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

3.3　编码提升传输速率 ​

HTTP 在传输数据时可以按照数据原貌直接传输，但也可以在传输过程中通过编码提升传输速率。

但是会增加cpu负担。

常用的内容编码有以下几种。

• gzip（GNU zip）

• compress（UNIX 系统的标准压缩）

• deflate（zlib）

• identity（不进行编码）

由于请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。所以在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。

这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。

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

HTTP协议通过采用MIME机制来允许同时处理多种数据格式的文件，例如图片、文字、视频等。

MIME（Multipurpose Internet Mail Extensions，多用途因特网邮件扩展）机制，它允许邮件处理文本、图片、视频等多个不同类型的数据。例如，图片等二进制数据以 ASCII 码字符串编码的方式指明，就是利用 MIME 来描述标记数据类型。而在 MIME 扩展中会使用一种称为多部分对象集合（Multipart）的方法，来容纳多份不同类型的数据。

通常是在图片或文本文件等上传时使用。

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

由于过去的时候并没有高速的网络，所以需要指定下载的实体范围，多次加载，如果完整加载不出来，也可以逐步加载。像这样，指定范围发送的请求叫做范围请求（Range Request）

执行范围请求时，会用到首部字段 Range 来指定资源的 byte 范围。

byte 范围的指定形式如下。

• 5001~10 000 字节

  Range: bytes=5001-10000

• 从 5001 字节之后全部的

  Range: bytes=5001-

• 从一开始到 3000 字节和 5000~7000 字节的多重范围

  Range: bytes=-3000, 5000-7000

针对范围请求，响应会返回状态码为 206 Partial Content 的响应报文。

如果服务器端无法响应范围请求，则会返回状态码 200 OK 和完整的实体内容。

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

同一个 Web 网站有可能存在着多份相同内容的页面。

当浏览器的默认语言为英语或中文，访问相同 URI 的 Web 页面时，则会显示对应的英语版或中文版的 Web 页面。这样的机制称为内容协商（Content Negotiation）。

内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。

包含在请求报文中的某些首部字段（如下）就是判断的基准。

• Accept

• Accept-Charset

• Accept-Encoding

• Accept-Language

• Content-Language

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

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

由服务器端进行内容协商。以请求的首部字段为参考，在服务器端自动处理。

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

由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。

• 透明协商（Transparent Negotiation）

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

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

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

状态码的职责是当客户端向服务器端发送请求时，描述返回的请求结果。根据返回的状态码，能知道请求的结果。

4.2　2XX 成功 ​

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

1. 200 OK

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

2. 204 No Content

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

   一般在只需要从客户端往服务器发送信息，而对客户端不需要发送新信息内容的情况下使用。

3. 206 Partial Content

   该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的 GET 请求。

4.3　3XX 重定向 ​

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

1. 301 Moved Permanently

   永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以后应使用资源现在所指的 URI。 例如访问网站，但是网站已经别分配了新的URI，如果曾经把URI保存为过书签，那建议现在就会去根据返回的首部字段的提示更新URI。

2. 302 Found

   临时性重定向。和 301 Moved Permanently 状态码相似，但 302 状态码代表的资源不是被永久移动，只是临时性质的。换句话说，已移动的资源对应的URI 将来还有可能发生改变。并不会建议去更新书签而是保留，以为未来还会变化。

3. 303 See Other

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

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

   比如，当使用 POST 方法访问 CGI 程序，其执行后的处理结果是希望客户端能以 GET 方法重定向到另一个 URI 上去时，返回 303 状态码。

4. 304 Not Modified

   该状态码表示客户端发送附带条件的请求 A 时，服务器端允许请求访问资源，但未满足条件的情况。304 状态码返回时，不包含任何响应的主体部分。

   比如客户端请求的资源在上次请求后没有发生变化，因此服务器无需重新发送资源内容，客户端可以使用本地缓存的副本。

   附带条件的请求是指采用GET方法的请求报文中包含If-Match，If-ModifiedSince，If-None-Match，If-Range，If-Unmodified-Since中任一首部。

5. 307 Temporary Redirect

   临时重定向。该状态码与 302 Found 有着相同的含义。

   尽管 302 标准禁止 POST 变换成 GET，但实际使用时大家并不遵守。

   307 会遵照浏览器标准，不会从 POST 变成 GET。

4.4　4XX 客户端错误 ​

4XX 的响应结果表明客户端是发生错误的原因所在。

1. 400 Bad Request

   该状态码表示请求报文中存在语法错误。发生此错误时，修改请求内容再次发送尝试请求

   另外，浏览器会像 200 OK 一样对待该状态码。

2. 401 Unauthorized

   该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、DIGEST 认证）的认证信息。表示客户端请求未被授权。当服务器收到包含未经授权的请求时，它会返回这个状态码，表明请求的资源要求身份验证，而提供的凭据（通常是用户名和密码）是无效的、缺失的或不足的。

3. 403 Forbidden

   该状态码表明对请求资源的访问被服务器拒绝了。

   服务器端没有必要给出拒绝的详细理由，也就是说客户端只知道请求资源失败了，但是不知道具体是因为什么失败。

   未获得文件系统的访问授权，访问权限出现某些问题（从未授权的发送源 IP 地址试图访问）等列举的情况都可能是发生 403 的原因。

4. 404 Not Found

   该状态码表明服务器上无法找到请求的资源。（😂经典）

4.5　5XX 服务器错误 ​

5XX 的响应结果表明服务器本身发生错误。

1. 500 Internal Server Error

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

2. 503 Service Unavailable

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

状态码和状况的不一致 ​

不少返回的状态码响应都是错误的，但是用户可能察觉不到这点。比如 Web 应用程序内部发生错误，状态码依然返回 200 OK，这种情况也经常遇到。

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

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

HTTP/1.1 规范允许一台 HTTP 服务器搭建多个 Web 站点。

即使物理层面只有一台服务器，但只要使用虚拟主机的功能，则可以假想已具有多台服务器——虚拟主机（Virtual Host，又称虚拟服务器）。

在相同的 IP 地址下，由于虚拟主机可以寄存多个不同主机名和域名的 Web 网站，因此在发送 HTTP 请求时，必须在 Host 首部内完整指定主机名或域名的 URI。

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

HTTP 通信时，除客户端和服务器以外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。它们可以配合服务器工作。

• 代理

  它扮演了位于服务器和客户端“中间人”的角色，接收由客户端发送的请求并转发给服务器，同时也接收服务器返回的响应并转发给客户端。

• 网关

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

• 隧道

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

1. 代理

   代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求 URI，会直接发送给前方持有资源的目标服务器。

   

   转发时，需要附加Via 首部字段以标记出经过的主机信息。

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

   • 缓存代理

     代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。如果代理再次收到相同资源的请求时，就可以不从源服务器获取资源，直接将之前的缓存返回。

   • 透明代理

     转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理（Transparent Proxy）。反之为非透明代理。

2. 网关

   

   网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提供非 HTTP 协议服务。

   利用网关能提高通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。

3. 隧道

   

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

   隧道本身不会去解析 HTTP 请求。 隧道会在通信双方断开连接时结束。

5.3　保存资源的缓存 ​

缓存是指代理服务器或客户端本地磁盘内保存的资源副本。利用缓存可减少对源服务器的访问，因此也就节省了通信流量和通信时间。

缓存服务器是代理服务器的一种，并归类在缓存代理类型中。

1. 缓存的有效期限

   即便缓存服务器内有缓存，也不能保证每次都会返回对同资源的请求。因为被缓存的资源存在时效性，所以因为客户端的要求、缓存的有效期的因素，会向源服务器确认资源的有效期，若缓存过期等，缓存服务器会再次向源服务器请求资源。

2. 客户端的缓存

   缓存不仅可以存在于缓存服务器内，还可以存在客户端浏览器中。以Internet Explorer 程序为例，把客户端缓存称为临时网络文件（Temporary Internet File）。

   浏览器的缓存如果有效，就会直接从客户端本地读取，但是当判断缓存过期后，会再次向源服务器判断资源的有效性，失败后会向服务器再次请求资源。

第 6章 HTTP首部 ​

6.1　HTTP 报文首部 ​

HTTP 请求报文 ​

在请求中，HTTP 报文由方法、URI、HTTP 版本、HTTP 首部字段等部分构成。

HTTP 响应报文 ​

在响应中，HTTP 报文由 HTTP 版本、状态码（数字和原因短语）、HTTP 首部字段 3 部分构成 。

6.2　HTTP 首部字段 ​

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

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

6.2.2　HTTP 首部字段结构 ​

HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“:”分隔。

• 首部字段名: 字段值

字段值对应单个 HTTP 首部字段可以有多个值。

6.2.3　4 种 HTTP 首部字段类型 ​

• 通用首部字段（General Header Fields）

  请求报文和响应报文两方都会使用的首部。

• 请求首部字段（Request Header Fields）

  从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

• 响应首部字段（Response Header Fields）

  从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。

• 实体首部字段（Entity Header Fields）

  针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

6.2.4　HTTP/1.1 首部字段一览 ​

通用首部字段 ​

请求首部字段 ​

响应首部字段 ​

实体首部字段 ​

6.2.5　非 HTTP/1.1 首部字段 ​

类似有 Cookie、Set-Cookie 和 Content-Disposition等在其他 RFC 中定义的首部字段。

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

HTTP 首部字段将定义成缓存代理和非缓存代理的行为，分成 2 种类型。