互联网协议 — HTTP 超文本传输协议
目录
文章目录
- 目录
- HTTP 协议的诞生
- HTTP 协议
- 发展历程
- HTTP/0.9
- HTTP/1.0
- HTTP/1.1
- HTTP/2
- HTTP/3
- HTTP 请求报文
- 请求行
- 请求体（Request Header）
- HTTP 响应报文
- 响应行
- 响应头（Response Header）
- 报文主体（Response Body）
- Cookie 机制
- 长连接与短连接
HTTP 协议的诞生
1989年，Tim Berners-Lee 在论文中提出可以在互联网上构建超链接文档，并提出了三点：
-
URI（Uniform Resource Identifier，统一资源标识符）：互联网的唯一 ID，包含了 URL 和 URN。
-
HTML：超文本文档。
-
HTTP：传输超文本的文本传输协议，简称：超文本传输协议。
HTTP 协议
HTTP（Hyper Text Transfer Protocol，超文本传输协议），是基于 TCP/IP 通信协议来实现数据传递的应用层协议，是用于从万维网（WWW，World Wide Web）服务器传输超文本到本地浏览器的传送协议。是互联网上应用最为广泛的一种网络协议。所有的 WWW 文件都必须遵守这个标准。HTTP 是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。
发展历程
HTTP/0.9
当时网络资源匮乏，0.9 版本相对简单，采用纯文本格式，且设置为只读，所以当时只能使用 GET 的方式从服务器获得 HTML 文档，响应以后则关闭。
请求只有一行，比如：GET www.leautolink.com。响应中也只包含了文档本身，无响应头，无错误码，无状态码。
HTTP/1.0
随着时代的进步，更多情况需要采用图文的方式才能生动的表达出自己的观点。随着 1995 年开发出 Apache，同时其他的多媒体等技术发展迅速，从而进一步的促使 HTTP 新功能的出现。
HTTP/1.0 最早在网页中使用是在 1996 年，那个时候只是使用一些较为简单的网页上和网络请求上。增加了以下几个方面：
- 增加 POST 方法。
- 增加 Head 方法。
- 增加协议版本号，
- 增加文件处理类型。
- 增加 HTTP Header
- 增加响应状态码。
- 提供国际化支持。
HTTP/1.1
1995 年，网景公司和微软开启浏览器大战。1999 年 HTTP/1.1 发布并成为标准，写入 RFC。
-
增加 PUT 等方法。
-
缓存处理，在 HTTP/1.0 中主要使用 header 里的 If-Modified-Since，Expires 来做为缓存判断的标准，HTTP/1.1 则引入了更多的缓存控制策略，如：Entity tag，If-Unmodified-Since，If-Match，If-None-Match 等更多可供选择的缓存头来控制缓存策略。
-
带宽优化及网络连接的使用，HTTP/1.0 中，存在一些浪费带宽的现象，例如：客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP/1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
-
错误通知的管理，在 HTTP/1.1 中新增了 24 个错误状态响应码，如 409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
-
Host 头处理，在 HTTP/1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。HTTP/1.1 的请求消息和响应消息都应支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（400 Bad Request）。
-
长连接，HTTP/1.1 支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟，在 HTTP/1.1 中默认开启 Connection:keep-alive，一定程度上弥补了 HTTP/1.0 每次请求都要创建连接的缺点。当然持久连接是可选择的，如果考虑关闭，只需要使用 Connecttion:close 关闭即可。释放 TCP 连接时，若 connection mode 为 close，则 Server-Side 主动关闭 TCP 连接，Client-Side 被动关闭连接，最后释放 TCP 连接。若 connection mode 为 keep-alive，则该连接会保持一段时间，在该时间内 Server-Side 可以继续接收请求。
GET /article/12 HTTP/1.1
Host: www.xxx.cn
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.106 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Cookie: SESSION=so9nlsvenminor5abs65sh9dsa
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 17 May 2020 17:04:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: blade-2.0.6-BETA
Content-Encoding: gzip
HTTP/2
HTTP/1.1 的不足：
-
TCP 自带慢启动：一个页面有静态数据，动态页面，很多小文件在加载的过程中就会直接发起请求，这样导致太多的请求都会经历慢启动过程，花费时间太多。
-
多条 TCP 连接导致的带宽竞争：带宽固定，多条 TCP 连接同时发起会竞争带宽资源，并且由于各个 TCP 连接之间没有通信机制，也无法得知哪些资源优先级更高，从而导致想快速下载的资源反而延迟下载。
-
队头阻塞：HTTP1.1 中，大家共用了一条 TCP 通道，第一个请求没有结束，第二请求就可能阻塞等待，也就是说不能同时发送接收数据。
HTTP/2 主要为了解决以上问题，详见《互联网协议 — HTTP/2 超文本传输协议第 2 版》。
HTTP/3
- 进一步解决了队头阻塞问题。通过独立不同流，让各个流之间实现相互独立传输，互不干扰。
- 切换网络时的连接保持。WI-FI 和 3G/4G 经常需要来回切换。基于 TCP 的协议，会因为网络的切换导致 IP 地址的改变。而基于 UDP 的 QUIC 协议，及时切换也可以恢复之前与服务器的连接。
详见《互联网协议 — QUIC 快速 UDP 互联网连接》和《互联网协议 — HTTP/3 超文本传输协议第 3 版》
HTTP 请求报文
HTTP 请求报文由：请求行、请求体（Request Header）、报文主体（Request Body）组成：
请求行
用于说明请求类型，要访问的资源以及所使用的 HTTP 版本。
格式：Method Request-URI HTTP-Version
- Method：HTTP Method。
- Request-URI：统一资源标识符。
- HTTP-Version：表示请求的 HTTP 协议版本。
\r\n），请求行必须由换行符结尾。
其中 HTTP Method 有下列几种类型：
- GET：(获取) 请求获取 Request-URI 标识的资源。
- POST：(创建) 请求在 Request-URI 标识的资源添加新的数据。
- PUT：(更新) 请求向 Request-URI 标识的资源上传其最新内容 。
- DELETE：(删除) 请求删除 Request-URI 标识的资源。
- HEAD：请求获取 Request-URI 标识的资源的 Response-Header。
- TRACE：请求服务器回送请求信息，一般用于测试或诊断。
- OPTIONS：请求获取服务器的性能参数，或者查询与资源相关的选项。
- CONNECT：用于与代理服务器通信时建立隧道，使用隧道协议进行 TCP 通信。
因为这些 HTTP 协议提供了多种 Method，所以 HTTP 协议除了作为传输协议之外，还被作为应用协议。
请求体（Request Header）
Request Header 是 HTTP Header 的其中一种类型，用于指定服务器接受的附加信息，由由若干个请求报头域键值对组成，报头域的格式为 报头域名: 值。下面列出常用的请求报头域：
-
Host：指定服务器的主机和端口号信息，发送请求时，该请求报头域是必需的。
-
Authorization：请求服务器鉴权，如果服务器的响应代码为 401 未授权，那么可以发送一个含有 Authorization 请求报头域的请求，要求服务器对客户端进行鉴权验证。
-
Accept：指定客户端接受的响应信息数据类型，e.g.
'Accept': 'application/json'指定接受 JSON 格式数据。 -
Accept-Charset，指定客户端接受的响应信息字符集类型，e.g.
Accept-Charset:iso-8859-1,gb2312,utf8。 -
Accept-Encoding：指定客户端接受的内容压缩类型，e.g.
Accept-Encoding:gzip.deflate。 -
Accept-Language：指定客户端接受的自然语言类型，e.g.
eg：Accept-Language:zh-cn。 -
User-Agent：将客户端操作系统、浏览器和其它本地属性传入服务器。
-
Cache-Control：指定请求和响应遵循的缓存机制。
-
Connection：指定 TCP 连接模式。
-
Cookie：最重要的请求头之一，将 Cookie 发送给服务器。
GET /562f25980001b1b106000338.jpg HTTP/1.1
Host img.mukewang.com
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8
HTTP 响应报文
HTTP 响应报文由：响应行、响应头（Response Header）、报文主体（Response Body） 组成：
响应行
格式：HTTP-Version Status-Code Reason-Phrase
- HTTP-Version：服务器 HTTP 协议版本。
- Status-Code：服务器发回的响应状态码。
- Reason-Phrase：状态码的文本描述。
其中由服务器响应的状态码分为 5 大类型:
- 1xx：(指示信息) 表示请求已接收，继续处理。
- 2xx：(成功) 表示请求已被成功接收、理解、接受。
- 3xx：(重定向) 要完成请求必须进行更进一步的操作。
- 4xx：(客户端错误) 请求有语法错误或请求无法实现。
- 5xx：(服务器端错误) 服务器未能实现合法的请求。
更多状态码
响应头（Response Header）
用来指定客户端接收的的附加信息：
-
Server：包含了服务器处理请求的软件环境信息。
-
Allow：服务器支持哪些 HTTP Method。
-
Set-Cookie：最重要的响应报头域之一，用于把 cookie 发送到客户端，每一个写入 cookie 都会生成一个 Set-Cookie。e.g.
Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com。 -
Location：用于重定向到一个新的位置，包含新的 URL 地址。
报文主体（Response Body）
在客户端发送 Request 或服务器响应 Response 时都可以传输一个报文主体（Response Body），其由实体报头域和实体正文（可选）组成，其中实体报头域用于定义了实体正文。常用的实体报头域有下列几种类型：
-
Content-Type：指定了发送给接收者的实体正文的媒体格式类型（MIME type），e.g.
'Content-Type': 'application/json'/Content-Type:text/html;charset=GB2312。 -
Content-Length：指定了实体正文的长度，以十进制数字表示。
-
Content-Encoding：指定了附加在实体正文上的附加内容的压缩类型，e.g.
Content-Encoding：gzip。 -
Content-Language：描述了资源所使用的自然语言。
-
Expires：指定了响应过期的日期和时间，以此更新缓存数据，e.g.
Expires：Thu，15 Sep 2006 16:23:12 GMT。 -
Last-Modified：描述了资源的最后修改日期和时间。
Cookie 机制
HTTP 协议是无状态、无记忆的，Cookie 机制就是为了让其具有记忆功能。
从上图我们可以知道 Cookie 是由浏览器负责存储，并不是操作系统负责，我们换个浏览器打开同样的网页，服务就认不出来了。
Cookie 常见的应用一个是身份识别，一个是广告追踪，比如：我们在访问网页视频或者图片的时候，广告商会悄悄给我们 Cookie 打上标记，方便做关联分析和行为分析，从而给我推荐一些相关内容。
长连接与短连接
HTTP 协议需要依靠 TCP 协议来传输数据，HTTP 对 TCP 连接的使用，分为两种方式：“短连接” 和 “长连接”。其中，长连接又称 “持久连接”（Keep-Alive 或 Persistent Connection）。
假设有一个网页，里面包含好多图片，还包含好多外部的 CSS 文件和 JS 文件。在 “短连接” 的模式下，浏览器会先发起一个 TCP 连接，拿到该网页的 HTML 源代码，拿到 HTML 之后，这个 TCP 连接就关闭了。然后，浏览器开始分析这个网页的源码，知道这个页面包含很多外部资源（e.g. 图片、CSS、JS）。然后针对每一个外部资源，再分别发起一个个 TCP 连接，把这些文件获取到本地。同样的，每抓取一个外部资源后，相应的 TCP 就断开。
相反，如果是 “长连接” 的方式，浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后，该 TCP 连接并不会立即关闭，而是暂时先保持着（Keep-Alive）。然后浏览器分析 HTML 源码之后，发现有很多外部资源，就用刚才那个 TCP 连接去抓取此页面的外部资源。
在 HTTP 1.0 版本，默认使用的是 “短连接”，到了 1995 年底开始制定 HTTP 1.1 草案的时候，网页已经开始变得复杂（网页内的图片、脚本越来越多了），这时候再用短连接的方式，效率太低下了。因为建立 TCP 连接是有时间成本和 CPU 成本的，所以，在 HTTP 1.1 中，默认采用的是 “Keep-Alive” 的方式。