1、前言
本文是《HTTP 权威指南》的第一章节 HTTP 概述的 读书笔记，我会尝试站在 HTTP 设计者 的角度上将知识点编辑成串，所以阅读本文您将收获 HTTP 宏观层面上的架构设计。
2、概述
HTTP（HyperText Transfer Protocol）：超文本传输协议，是互联网上应用最广泛的网络协议之一。设计 HTTP 的最初目的是为了提供一种发布和接收 HTML 页面的方法。通过 HTTP 或者 HTTPS 协议请求的资源由统一资源标识符（Uniform Resources Identifiers，URI）来标识。
HTTP 发展历程：
1、由1989年在欧洲核子研究组织（CERN）发起。
2、由 W3C 和 IETF 制定标准并发布一系列 RFC（最著名的是RFC 2616 -- HTTP/1.1）。
3、2014年12月，IETF 提交了 HTTP/2的标准。
4、2015年2月17日，HTTP/2标准被批准。
5、2015年5月，HTTP/2标准以 RFC 7540正式发表。
3、HTTP 的构成
3.1、服务端
因为 Web 服务器所使用的是 HTTP 协议，因此经常会被称为 HTTP 服务器。
市面上常见的 HTTP 服务器有：
- Apache HTTP Server
- IIS
- Google WebServer 基于 Apache HTTP Server 开发的。
- Nginx
- Tengine 基于 Nginx 开发的。
- Lighttpd
3.2、客户端
最常见的客户端就是浏览器，客户端向服务器请求 HTTP 对象，并将这些对象显示在你的屏幕上。
服务端与客户端就好比
公司与家，现在我们已经知道了两个真实世界上的地理位置。但是由于没有坐标，也就无法在地图上定位两个位置。（记住公司与家这个比喻，会在下文中反复提及该比喻。）
3.3、资源
Web 服务器是 Web 资源的宿主，所有能够提供 Web 内容的东西都可以理解为 Web 的资源。比如：图片、HTML、音频、股票交易系统。
3.3.1、媒体类型
正因为有了多种资源，所以也就衍生了对资源分类的需求。对资源的分类也有利于数据的传输（打包、传输、解包），制定媒体类型可以让众多服务器/客户端遵守统一的标准。
HTTP 在设计媒体类型时参考了 MIME（多用于因特网邮件扩展），因为 MIME 很好的解决了在不同的电子邮件系统之间搬移报文时存在的问题，因此 HTTP 也采纳了它，用它来描述并标记多媒体内容。
HTTP 服务器会为所有的 HTTP 对象数据附加一个 MIME 的类型。 当 Web 浏览器从服务器取回数据对象时，会去查看 MIME 类型，看看它是否知道如何处理这个对象。
MIME 类型是一种文本标记，由主要的对象对象和特定的子类型组成。使用 Content-Type 首部来标识。
| 名称 | 扩展名 | MIME类型 |
|---|---|---|
| 超文本标记语言文本 | .htm, .html | text/html |
| 普通文本 | .txt | text/plain |
| RTF文本 | .rtf | application/rtf |
| GIF图形 | .gif | image/gif |
| JPEG图形 | .ipeg, .jpg | image/jpeg |
| au声音文件 | .au | audio/basic |
| MIDI音乐文件 | .mid, .midi | audio/midi, audio/x-midi |
| RealAudio音乐文件 | .ra, .ram | audio/x-pn-realaudio |
| MPEG文件 | .mpg,.mpeg | video/mpeg |
| AVI文件 | .avi | video/x-msvideo |
| GZIP文件 | .gz | application/x-gzip |
| TAR文件 | .tar | application/x-tar |
| JSON文件 | .json | application/json |
| png图形 | .png | image/png |
更多的 MIME 类型，请参考 HTTP Content-Type 常用对照表。
3.3.2、URI
到目前为止我们手上拥有的武器是：客户端、服务端、资源类型。下一步我们需要作的事情就是把资源类型跟资源能对应上，这才能方便的往客户端或服务端直接发送资源。而 URI 恰恰就是做这样的事情，你看它的名字就知道了 —— 统一资源标识符（Uniform Resources Identifier，URI）。
URI 就像经纬度坐标一样，在世界范围内唯一标识并定位信息资源。
比如：http://www.jianshu.com/u/c2dc43022058 这是我的简书首页。给定 URI，HTTP就可以解析出对象。
URI 有两种形式：
3.3.2.1、URL
URL 说明了协议、服务器和本地资源。
比如：http://www.jianshu.com/u/c2dc43022058，对应的是下表的内容。
| 协议 | 服务器 | （相对服务器的）本地资源 |
|---|---|---|
| http | www.jianshu.com | /u/c2dc43022058 |
3.3.2.2、URN
URN 是作为特定内容的唯一名称使用的，与目前资源的所在地无关。使用与位置无关的 URN 的好处是可以将资源四处搬移。
但是 URN 仍处于试验阶段，所以这部分了解下即可。
3.4、事务
直到目前为止，我们手上有的武器有：客户端、服务端、统一资源标识符、资源类型，但是还没有涉及到如何交换资源这一重大议题。
** 事务：即是一次成对出现的请求及响应的结果。**
HTTP 事务是通过名为HTTP 报文的格式化数据块进行的。
1、浏览器输入地址http://baidu.com，这是不符合标准格式的地址。
2、浏览器代理拦截了该次请求，并遵循 HTTP 协议模拟服务器返回我 HTTP报文。
3、浏览器获取报文中的Location首部，浏览器地址重新输入地址http://www.baidu.com，并再次发起请求。
这个过程关联知识点HTTP 的报文，即请求报文与响应报文的具体构成。
3.5、报文
HTTP 报文都是纯文本，相比二进制代码它具备很强的可读性。我们可以用 Charles 来查看具体的报文。
HTTP 报文分为三个部分：
1、起始行，报文的第一行就是起始行。比如上图中的：POST /v3/pb HTTP/1.1 与 HTTP/1.1 200 OK
2、首部字段，起始行后面有0~N 个首部字段。它们是由键名与键值构成。格式如：Content-Type : text/html。（Charles 会将数据格式化，所以看不到冒号分割。）首部之后会有一行空行，这个空行是不应被省略的。
3、主体，空行之后就是报文主体了。报文主体可以为空，通常用于表示该条报文要传输的数据
我们可以通过HTTP 报文，构建一个数据与意图的包裹。但目前为止，仍然没有恰当的武器能够支持客户端与服务端之间互相传递包裹。
3.6、连接
3.6.1、TCP
HTTP 是位于 TCP 层之上的应用层协议，HTTP 无需操心网络通讯的细节，它把联网的细节都交给了通用、可靠的 TCP 协议。
在 HTTP 客户端向服务端发送报文之前，需要先用 IP 地址和端口号在客户端与服务端之间建立一条 TCP/IP 连接。
建立 TCP/IP 连接的过程与打电话很相似。
| 序号 | 建立 TCP/IP 连接 | 打电话 |
|---|---|---|
| 1、 | 需要知道 IP 地址 | 需要知道电话号码 |
| 2、 | 连接 IP 地址 | 拨打电话号码 |
| 3、 | 输入端口号 | 输入分机号码 |
| 4、 | 连接成功 | 电话拨号成功 |
在 TCP 中你需要知道服务器的 IP 地址，以及与服务器上允许的特定软件相关的 TCP 端口号。
前面提到过 URL，通过 URL 自然就能够为我们提供存储资源的机器的 IP 地址。
举例：http:// [主机名 或 IP 地址][端口号（可选）][资源位置]
- 如果填写的是主机名，则可以通过与域名服务（DNS）的机制方便的将主机名转化为 IP 地址。
- 如果未填写端口号，则默认端口号是：80。
HTTP 提供给我们五件武器，使用这些武器我们顺利完成了对数据包裹的交换。这是最小的交互模型，理解它有助我们正确理解之后将要穿插在中间的代理链。
本文用客户端或服务端名词定义其实是不严谨的，它们都是实现了 HTTP 协议规范的应用程序，本质上它们都是普通的应用程序（包括代理也是如此）。它们都需要正确的处理发送与接收响应报文，站在Web服务器的视角 响应可以看做是向Web 浏览器发送报文。站在 Web 浏览器亦反之。
4、拓展阅读
另外列出一些比较重要的应用程序（它们均满足 HTTP 协议规范只是在应用场景上实现不同）：
- 代理，位于客户端与服务端之间的 HTTP 中间实体。
- 缓存，HTTP 仓库，使常用页面的副本可以保存在离客户端更近的地方。
- 网管，连接其他应用程序的特殊 Web 服务器。
- 隧道，对 HTTP 通信报文进行
盲转发的特殊代理。 - Agent 代理，发起自动 HTTP 请求的半智能 Web 客户端。
（了解即可，后面会依次详细介绍）
