1·HTTP 概述
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 报文的格式化数据块进行的。
加载 baidu 的一次事务
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 客户端。
（了解即可，后面会依次详细介绍）