《图解HTTP》阅读总结（上）

正如译者所说，说话HTTP协议书真的很少:

在我的印象中，只有两本书解释了网络协议。《HTTP 但其厚度令人望而生畏；另一本书是《TCP/IP 详解，卷 一、内容难懂，学习难度大。

确实如此，《HTTP 我也看到了《权威指南》的一小部分真的是从入门到放弃，不是写得不好，真的很棒，很细致。但对我来说太无聊了。

这本《图解HTTP》，本书图文并茂，大量图片穿插文中，生动形象地向读者介绍每一个应用案例，减少了读者阅读时的枯燥感。哈哈，很适合我，我的文章也非常喜欢用“图解XXX但真的没有这本书用图那么彻底。

虽然是一本2014年的“老书”，但其实很多知识还是沿用至今的，HTTP版本为1.一、推荐阅读。

当你通过浏览器查看网页时发生了什么？从一张图片和一个问题开始。

1990年，HTTP/0.9

1996 年的 5 月，HTTP/1.0

1997 年 1 月，HTTP/1.1

这本书于2014年出版，上面写着新 一代 HTTP/2.0 正在制定中，但仍需要时间才能达到较高的使用覆盖率。

实际上2015年，HTTP/2 但正如作者所说，2.0普及真是**没那么快**。

TCP/IP 是各类互联网相关协议族的总称， 包含很多协议

可见，HTTP是TCP/IP协议中的一个

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

一张图表示一个简单的HTTP请求：

事实上，请求报文的组成如下：

HTTP 是一种无保存状态，即无状态（stateless）协议。HTTP 协议自 保存请求和响应之间的通信状态。也就是说，在 HTTP 这个 等级，协议不会持续处理发送的请求或响应。

HTTP 在协议的初始版本中，每次进行一次 HTTP 通信必须断开一次 TCP 连接。每个请求都会导致不必要的 TCP 建立和断开连接 打开，增加通信成本。

为解决上述 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 在传输数据时，可以根据数据的原始外观直接传输，但也可以传输 通过编码提高传输速率。通过编码传输，可以有效处理大量的 访问请求。但是编码操作需要电脑来完成，所以会消耗更多 的 CPU 等资源。

常用的内容编码如下。

• gzip（GNU zip）

• compress（UNIX 系统标准压缩)

• deflate（zlib）

• identity(不编码)

**分割发送方式：**在 HTTP 通信过程中，请求的编码实体资源尚未全部传输完成之前， 请求页面无法显示浏览器。传输大容量数据时通过把数据分割成 多块，能够让浏览器逐步显示页面。

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

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

包含在请求报文中的某些首部字段（如下）就是判断的基准。这些首 部字段的详细说明请参考下一章。

• Accept

• Accept-Charset

• Accept-Encoding

• Accept-Language

• Content-Language

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

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

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

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

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

透明协商（Transparent Negotiation）

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

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

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

• 200 OK 表示从 客户端发来的请求在服务器端被正常处理了。
• 204 No Content 该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中 不含实体的主体部分。
• 206 Partial Content 该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的 GET 请求。

• 301 Moved Permanently 永久性重定向。该状态码表示请求的资源已被分配了新的 URI，以后 应使用资源现在所指的 URI。
• 302 Found 临时性重定向。该状态码表示请求的资源已被分配了新的 URI，希望 用户（本次）能使用新的 URI 访问。
• 303 See Other 该状态码表示由于请求对应的资源存在着另一个 URI，应使用 GET 方法定向获取请求的资源。
• 304 Not Modified 该状态码表示客户端发送附带条件的请求 2 时，服务器端允许请求访 问资源，但未满足条件的情况。
• 307 Temporary Redirect 临时重定向。该状态码与 302 Found 有着相同的含义。尽管 302 标准 64 禁止 POST 变换成 GET，但实际使用时大家并不遵守。 307 会遵照浏览器标准，不会从 POST 变成 GET。

• 400 Bad Request 该状态码表示请求报文中存在语法错误。

• 401 Unauthorized 该状态码表示发送的请求需要有通过 HTTP 认证（BASIC 认证、 DIGEST 认证）的认证信息。

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

• 404 Not Found 该状态码表明服务器上无法找到请求的资源。

• 500 Internal Server Error 该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。
• 503 Service Unavailable 该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法 处理请求。

通过阅读前四章，将以前关于HTTP的散碎知识串起来了，虽然大部分知识之前都知道，但感觉通过系统学习一下，了解的更清晰了，知识需要形成体系。下一篇争取下周发出。