《图解 HTTP》阅读总结

(Updated: )

TCP/IP 基础

链路层级

TCP/IP 协议族按层次分别 分为以下 4 层: 应用层、传输层、网络层和数据链路层。

  • 应用层

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

  • 传输层

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

  • 网络层(又名网络互连层)

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

  • 链路层(又名数据链路层，网络接口层)

用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱 动、NIC(Network Interface Card，网络适配器，即网卡)，及光纤

建立连接的过程

为了准确无误地将数据送达目标处，TCP 协议采用了三次握手 (three-way handshaking)策略。用 TCP 协议把数据包送出去后，TCP 不会对传送后的情况置之不理，它一定会向对方确认是否成功送达。握手过程中使用了 TCP 的标志(flag)——SYN(synchronize) 和 ACK( acknowledgement)。

  1. 发送端首先发送一个带 SYN 标志的数据包给对方。
  2. 接收端收到后，回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。
  3. 最后，发送 端再回传一个带 ACK 标志的数据包，代表“握手”结束。

若在握手过程中某个阶段莫名中断，TCP 协议会再次以相同的顺序 发送相同的数据包。

URL结构

与 URI(统一资源标识符)相比，我们更熟悉 URL(Uniform Resource Locator，统一资源定位符)。URL 正是使用 Web 浏览器等访问 Web 页面时需要输入的网页地址。比如，下图的 http://hackr.jp/ 就是 URL。

HTTP 是一种不保存状态，即无状态(stateless)协议。HTTP 协议 自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。
HTTP/1.1 虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管理状态了

常用请求方法

  • GET : 获取资源

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

  • POST: 传输实体主体

POST 方法用来传输实体的主体。虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进 行传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容。

  • PUT : 传输文件

PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在 请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可 以上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若 配合 Web 应用程序的验证机制，或架构设计采用 **REST(Representational State Transfer，表征状态转移)**标准的同类 Web 网站，就可能会开放使 用 PUT 方法。

  • HEAD: 获得报文首部

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

  • DELETE: 删除文件

服务器请求响应 DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方 法按请求 URI 删除指定的资源。但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机 制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用程 序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。

  • OPTIONS: 询问支持的方法

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

  • TRACE: 追踪路径

TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的 方法。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个 服务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最 后接收到请求的服务器端则返回状态码 200 OK 的响应。客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修 改 / 篡改的。这是因为，请求想要连接到源目标服务器可能会通过代理 中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。

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

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

请求头版本支持

持久连接

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

管线化

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

Cookie

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

HTTP 报文

HTTP 报文内的 HTTP 信息

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端(客户端)的 HTTP 报文叫做请求报文，响应端(服务器端)的叫做响应报文。HTTP 报文本身是由多行(用 CR+LF 作换行符)数据构成的字符串文本。
HTTP 报文大致可分为报文首部和报文主体两块。两者由最初出现 的空行(CR+LF)来划分。通常，并不一定要有报文主体。

返回结果的 HTTP 状态码

  • 2XX 成功

    • 200 OK
      表示从客户端发来的请求在服务器端被正常处理了。在响应报文内，随状态码一起返回的信息会因方法的不同而发生改 变。比如，使用 GET 方法时，对应请求资源的实体会作为响应返回; 而使用 HEAD 方法时，对应请求资源的实体主体不随报文首部作为响 应返回(即在响应中只返回首部，不会返回实体的主体部分)。

    • 204 No Content
      该状态码代表服务器接收的请求已成功处理，但在返回的响应报文 中不含实体的主体部分。另外，也不允许返回任何实体的主体。比如， 当从浏览器发出请求处理后，返回 204 响应，那么浏览器显示的页面不 发生更新。一般在只需要从客户端往服务器发送信息，而对客户端不需要发送 056 新信息内容的情况下使用

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

  • 3XX 重定向

    • 301 Moved Permanently
      永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以 后应使用资源现在所指的 URI。也就是说，如果已经把资源对应的 URI 保存为书签了，这时应该按 Location 首部字段提示的 URI 重新保存

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

    • 303 See Other
      该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。303 状态码和 302 Found 状态码有着相同的功能，但 303 状态码明 确表示客户端应当采用 GET 方法获取资源，这点与 302 状态码有区别。比如，当使用 POST 方法访问 CGI 程序，其执行后的处理结果是希望客户端能以 GET 方法重定向到另一个 URI 上去时，返回 303 状态码。

    • 304 Not Modified
      该状态码表示客户端发送附带条件的请求 A 时，服务器端允许请求 访问资源，但因发生请求未满足条件的情况后，直接返回 304 Not Modified(服务器端资源未改变，可直接使用客户端未过期的缓存)。 304 状态码返回时，不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中，但是和重定向没有关系

    • 307 Temporary Redirect 临时重定向
      该状态码与 302 Found 有着相同的含义。尽管 302 标 准禁止 POST 变换成 GET，但实际使用时大家并不遵守。307 会遵照浏览器标准，不会从 POST 变成 GET。但是，对于处理 响应时的行为，每种浏览器有可能出现不同的情况。

  • 4XX 客户端错误

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

    • 401 Unauthorized
      该状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、 DIGEST 认证)的认证信息。另外若之前已进行过 1 次请求，则表示用 户认证失败。返回含有 401 的响应必须包含一个适用于被请求资源的 WWW- Authenticate 首部用以质询(challenge)用户信息。当浏览器初次接收 到 401 响应，会弹出认证用的对话窗口。

    • 403 Forbidden
      该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必 要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分 对原因进行描述，这样就能让用户看到了。未获得文件系统的访问授权，访问权限出现某些问题(从未授权的 发送源 IP 地址试图访问)等列举的情况都可能是发生 403 的原因。

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

  • 5XX 服务器错误

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

    • 503 Service Unavailable
      该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无 法处理请求。如果事先得知解除以上状况需要的时间，最好写入 Retry- After 首部字段再返回给客户端

与 HTTP 协作的 Web 服务器

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

HTTP/1.1 规范允许一台 HTTP 服务器搭建多个 Web 站点。比如， 提供 Web 托管服务(Web Hosting Service)的供应商，可以用一台服务 器为多位客户服务，也可以以每位客户持有的域名运行各自不同的网站。 这是因为利用了虚拟主机(Virtual Host，又称虚拟服务器)的功能。
即使物理层面只有一台服务器，但只要使用虚拟主机的功能，则可 以假想已具有多台服务器

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

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

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

代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求 URI，会直接发送给前方持有资源的目标服务器。 持有资源实体的服务器被称为源服务器。从源服务器返回的响应经过代理服务器后再传给客户端。

使用代理服务器的理由有:利用缓存技术(稍后讲解)减少网络带 宽的流量，组织内部针对特定网站的访问控制，以获取访问日志为主要 目的，等等。代理有多种使用方法，按两种基准分类。一种是是否使用缓存，另 一种是是否会修改报文。缓存代理代理转发响应时，缓存代理(Caching Proxy)会预先将资源的副本 (缓存)保存在代理服务器上。当代理再次接收到对相同资源的请求时，就可以不从源服务器那里 获取资源，而是将之前缓存的资源作为响应返回。

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

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

网关的工作机制和代理十分相似。而网关能使通信线路上的服务器 提供非 HTTP 协议服务。利用网关能提高通信的安全性，因为可以在客户端与网关之间的通 信线路上加密以确保连接的安全。比如，网关可以连接数据库，使用 SQL 语句查询数据。另外，在 Web 购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动。

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

隧道可按要求建立起一条与其他服务器的通信线路，届时使用 SSL 等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的 通信。隧道本身不会去解析 HTTP 请求。也就是说，请求保持原样中转给 之后的服务器。隧道会在通信双方断开连接时结束。

HTTP 首部

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

1
首部字段名: 字段值

当 HTTP 报文首部中出现了两个或两个以上具有相同首部字段名时会 怎么样? 这种情况在规范内尚未明确，根据浏览器内部处理逻辑的不同， 结果可能并不一致。有些浏览器会优先处理第一次出现的首部字段，而有 些则会优先处理最后出现的首部字段。

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

1. 通用首部字段(General Header Fields) 请求报文和响应报文两方都会使用的首部。

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

2. 请求首部字段(Request Header Fields)

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

  • Accept 用户代理可处理的媒体类型
  • Accept-Charset 优先的字符集
  • Accept-Encoding 优先的内容编码
  • Accept-Language 优先的语言(自然语言)
  • Authorization Web 认证信息
  • Expect 期待服务器的特定行为
  • From 用户的电子邮箱地址
  • Host 请求资源所在服务器
  • If-Match 比较实体标记(ETag)
  • If-Modified-Since 比较资源的更新时间
  • If-None-Match 比较实体标记(与 If-Match 相反)
  • If-Range 资源未更新时发送实体 Byte 的范围请求
  • If-Unmodified-Since 比较资源的更新时间(与 If-Modified-Since 相反)
  • Max-Forwards 最大传输逐跳数
  • Proxy-Authorization 代理服务器要求客户端的认证信息
  • Range 实体的字节范围请求
  • Referer 对请求中 URI 的原始获取方
  • TE 传输编码的优先级
  • User-Agent HTTP 客户端程序的信息

3. 响应首部字段(Response Header Fields)

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

  • Accept-Ranges 是否接受字节范围请求
  • Age 推算资源创建经过时间
  • ETag 资源的匹配信息
  • Location 令客户端重定向至指定 URI
  • Proxy-Authenticate 代理服务器对客户端的认证信息
  • Retry-After 对再次发起请求的时机要求
  • Server HTTP 服务器的安装信息
  • Vary 代理服务器缓存的管理信息
  • WWW-Authenticate 服务器对客户端的认证信息

4. 响实体首部字段(Entity Header Fields)

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

  • Allow 资源可支持的 HTTP 方法
  • Content-Encoding 实体主体适用的编码方式
  • Content-Language 实体主体的自然语言
  • Content-Length 实体主体的大小(单位 :字节)
  • Content-Location 替代对应资源的 URI
  • Content-MD5 实体主体的报文摘要
  • Content-Range 实体主体的位置范围
  • Content-Type 实体主体的媒体类型
  • Expires 实体主体过期的日期时间
  • Last-Modified 资源的最后修改日期时间

非 HTTP/1.1 首部字段

在 HTTP 协议通信交互中使用到的首部字段，不限于 RFC2616 中 定义的 47 种首部字段。还有 Cookie、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定义的首部字段，它们的使用频率也很高。这些非正式的首部字段统一归纳在 RFC4229 HTTP Header Field Registrations 中。

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

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

  • 端到端首部(End-to-end Header) 分在此类别中的首部会转发给请求 / 响应对应的最终接收目标，且 必须保存在由缓存生成的响应中，另外规定它必须被转发。
  • 逐跳首部(Hop-by-hop Header) 分在此类别中的首部只对单次转发有效，会因通过缓存或代理而不 再转发。HTTP/1.1 和之后版本中，如果要使用 hop-by-hop 首部， 需提供 Connection 首部字段。

下面列举了 HTTP/1.1 中的逐跳首部字段。除这 8 个首部字段之外， 其他所有字段都属于端到端首部。

  • Connection-Keep-Alive
  • Proxy-Authenticate
  • Proxy-Authorization
  • Trailer
  • TE
  • Transfer-Encoding
  • Upgrade

Cache-Control

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

1
Cache-Control: private, max-age=0, no-cache

  • 缓存请求指令
    | 名字 | 必要 | 描述 |
    | ----| ---- | ---- |
    | no-cache | 无 | 强制向源服务器再次验证 |
    | no-store | 无 | 不缓存请求或响应的任何内容 |
    | max-age = [ 秒] | 必需 | 响应的最大Age值 |
    | max-stale( = [ 秒 ]) | 可省略 | 接收已过期的响应 |
    | min-fresh = [ 秒 ] | 必需 | 期望在指定时间内的响应仍有效 |
    | no-transform | 无 | 代理不可更改媒体类型 |
    | only-if-cached | 无 | 从缓存获取资源 |
    | cache-extension | - | 新指令标记(token) |

  • 缓存响应指令
    | 名字 | 必要 | 描述 |
    | ----| ---- | ---- |
    | public | 无 | 可向任意方提供响应的缓存
    | private | 可省略 | 仅向特定用户返回响应
    | no-cache | 可省略 | 缓存前必须先确认其有效性
    | no-store | 无 | 不缓存请求或响应的任何内容
    | no-transform | 无 | 代理不可更改媒体类型
    | must-revalidate | 无 | 可缓存但必须再向源服务器进行确认
    | proxy-revalidate | 无 | 要求中间缓存服务器对缓存的响应有效性再进行 085 确认
    | max-age = [ 秒] | 必需 | 响应的最大Age值
    | s-maxage = [ 秒] | 必需 | 公共缓存服务器响应的最大Age值
    | cache-extension | - | 新指令标记(token)

  • 为 Cookie 服务的首部字段
    | 名字 | 描述 |
    | ----| ---- |
    | Set-Cookie | 开始状态管理所使用的 Cookie 信息 响应首部字段 |
    | Cookie | 服务器接收到的 Cookie 信息 请求首部字段 |