当我谈 HTTP 时，我谈些什么?

时间 2020-07-20

标签 http 谈些什么栏目 HTTP/TCP 繁體版

原文原文链接

当咱们打开网站时也许不会去留意网站前面的HTTP是怎么来的。可是它毫无疑问在网络中有着举足轻重的地位。本文从起源到发展，详说HTTP从1到3的演变。html

说在前面

本文不致力于讲完 HTTP 的所有内容，事实上短短的篇幅也不可能讲完。本文也无心于深挖 HTTP 中的某一点，这是像《HTTP 权威指南》或者是 RFC 协议作的事。算法

本文目标是帮助读者理清 HTTP 的演化过程，说说 HTTP 变化的那些事。浏览器

HTTP 的起源

HTTP 最初是 Tim BernersLee 1989 年在欧洲核子研究组织（CERN）所发起的。Tim BernersLee 提出了一种能让远隔两地的研究者们共享知识的设想。这个设想的基本理念是：借助多文档之间相互关联造成的超文本（HyperText），连成可相互参阅的 WWW（World Wide Web，万维网）。用于传输的超文本传输协议（HyperText Transfer Protocol），即 HTTP 由此诞生。缓存

WWW 这一名称，是 Web 浏览器当年用来浏览超文本的客户端应用程序时的名称。如今则用来表示这一系列的集合，也可简称为 Web。安全

HTTP 自己是一个简单的请求-响应协议，它一般运行在 TCP 之上。从整个网络模型来看，HTTP 是应用层的一个协议。在 OSI 七层模型中，HTTP 位于最上层。它并不涉及数据包的传输，只是规定了客户端和服务器之间的通讯格式。定了客户端可能发送给服务器什么样的消息以及获得什么样的响应。请求和响应消息的头以 ASCII 码形式给出。服务器

HTTP 采用 BS 架构，也就是浏览器到服务器的架构，客户端经过浏览器发送 HTTP 请求给服务器，服务器通过解析响应客户端的请求。就是这个简单实用的模型，使得 HTTP 这个基于 TCP/IP 的协议迅速推广。网络

HTTP/0.9 到 HTTP/1.1

HTTP 的演化并非一蹴而就的。当年 HTTP 的出现主要是为了解决文本传输的难题。因为协议自己很是简单，因而在此基础上设想了不少应用方法并投入了实际使用。如今 HTTP 已经超出了 Web 这个框架的局限，被运用到了各类场景里。架构

HTTP/0.9并发

HTTP 协议最先的一个版本是 1990 年发布的 HTTP/0.9。框架

前面说到，HTTP 于 1989 年问世。那时的 HTTP 并无做为正式的标准被创建。这时的 HTTP 其实含有 HTTP/1.0 以前版本的意思，所以被称为 HTTP/0.9。这个版本只有一个命令：GET。经过 GET 能够获取服务器的资源，好比请求服务器根目录下的 index.html 文件。这个版本的协议规定，服务器只能回应 HTML 格式的字符串，不能回应其它格式，也就是说图像、视频等多媒体资源，在 HTTP/0.9 这个版本上是没法进行传输的。

HTTP/1.0

HTTP 正式做为标准被公布是在 1996 年的 5 月，版本被命名为 HTTP/1.0，并记载于 RFC1945 [www.ietf.org/rfc/rfc1945…]。虽然说是初期标准，但该协议标准至今仍被普遍使用在服务器端。

HTTP/1.0 版本发布，增长了 POST 命令和 HEAD 命令，丰富了浏览器与服务器的互动手段。这个版本的 HTTP 协议能够发送任何格式的内容，包括传输文字、图像、视频、文件等，这为互联网的大发展奠基了基础。

HTTP/1.0 除了增长了请求方法以及对发送文件的支持以外，还增长了格式的改变。除了数据部分，每次通讯都必须包括头信息（HTTP header），用来描述一些元数据。另外还增长了状态码、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等等。

HTTP/1.1

HTTP/1.0 版也并非完美的，它的主要缺点是，每一次创建 TCP 链接只能发送一个请求。发送数据完毕，链接就关闭，若是还要请求其余资源，就必须再新建一个链接。若是屡次请求，势必就会对服务器产生较大的资源性能损耗。

1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 协议版本。当初的标准是 RFC2068，以后发布的修订版 RFC2616 就是当前的最新版本。

其中最著名的是 1999 年 6 月公布的 RFC 2616 [tools.ietf.org/html/rfc261…]，定义了 HTTP 协议中现今普遍使用的一个版本——HTTP/1.1。

这个版本最大的变化就是将持久化链接加入了 HTTP 标准，即 TCP 链接默认不关闭，能够被多个请求复用。此外，HTTP/1.1 版还新增了许多方法，例如：PUT、PATCH、HEAD、OPTIONS、DELETE。获得进一步完善的HTTP/1.1 版本，一直沿用至今。

HTTP 协议简单介绍

请求

客户端发送一个 HTTP 请求到服务器，请求消息包括如下格式：

请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

Get 请求例子

1 > GET / HTTP/1.1 2 > Host: www.baidu.com 3 > User-Agent: curl/7.52.1 4 > Accept: /

第一部分：请求行，用来讲明请求类型，要访问的资源以及所使用的 HTTP 版本。

第二部分：请求头部，紧接着请求行（即第一行）以后的部分，用来讲明服务器要使用的附加信息

从第二行起为请求头部，HOST 将指出请求的目的地。User-Agent，服务器端和客户端脚本都能访问它,它是浏览器类型检测逻辑的重要基础。该信息由你的浏览器来定义，而且在每一个请求中自动发送等等。

第三部分：空行，请求头部后面的空行是必须的

即便第四部分的请求数据为空，也必须有空行。

第四部分：请求数据也叫主体，能够添加任意的其余数据。

这个例子的请求数据为空。

响应消息

通常状况下，服务器接收并处理客户端发过来的请求后，会返回一个 HTTP 的响应消息。

HTTP 响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

例子

1 < HTTP/1.1 200 OK 2 < Accept-Ranges: bytes 3 < Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform 4 < Connection: keep-alive 5 < Content-Length: 2381 6 < Content-Type: text/html 7 < Date: Thu, 11 Jun 2020 16:04:33 GMT 8 < Etag: "588604c8-94d" 9 < Last-Modified: Mon, 23 Jan 2017 13:27:36 GMT 10 < Pragma: no-cache 11 < Server: bfe/1.0.8.18 12 < Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/ 13 < 14 15 <meta HTTP-equiv=content-type content=text/html;charset=utf-8><meta HTTP-equiv=X-UA-Compatible content=IE=Edge>... 16

第一部分：状态行，由 HTTP 协议版本号、状态码、状态消息三部分组成。

第一行为状态行，（HTTP/1.1）代表 HTTP 版本为 1.1 版本，状态码为 200，状态消息为（ok）

第二部分：消息报头，用来讲明客户端要使用的一些附加信息

第二行和第三行为消息报头。

Date：生成响应的日期和时间；Content-Type：指定了 MIME 类型的 HTML(text/html)，编码类型是 UTF-8

第三部分：空行，消息报头后面的空行是必须的

第四部分：响应正文，服务器返回给客户端的文本信息。

空行后面的 HTML 部分为响应正文。

状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收、理解、接受
3xx：重定向–要完成请求必须进行更进一步的操做
4xx：客户端错误–请求有语法错误或请求没法实现
5xx：服务器端错误–服务器未能实现合法的请求

安全性与 HTTPS

HTTP 的诞生是为了解决信息传递和共享的问题，并无考虑到互联网高速发展后面临的安全问题。

通常来讲 HTTP 从 TCP 三次握手后，便开始了数据传输。因为 HTTP 自己以明文形式来传输数据，并不具有任何数据加密、身份校验的机制。同时下层协议并不对数据安全性、保密性提供保证。因此在网络传输的过程当中，任意节点的第三方均可以随意劫持流量、篡改数据或窃取信息。

HTTP 没法确保数据的保密性、完整性和真实性，已经不能适应现代互联网应用的安全需求。

随着 Web 的日益壮大，HTTP 的使用呈巨额增加趋势，对信息安全的需求也越来越迫切，SSL（Secure SocketsLayer ，安全套接层）应运而生。

当对于安全需求，首先想到的就是对信息进行加密。SSL ，安全套接层，顾名思义是在 TCP 上提供的安全套接字层。其位于应用层和传输层之间，应用层数据再也不直接传递给传输层而是传递给 SSL 层，SSL 层对从应用层收到的数据进行加密，利用数据加密、身份验证和消息完整性验证机制，为网络上数据的传输提供安全性保证。HTTPS 即是指 Hyper Text Transfer Protocol over SecureSocket Layer。

谈到具体实施上，业内一般采用的通常有对称加密和非对称加密。采用何种方式进行加密？如何判断服务器未被篡改？如何传递加密密钥？带着这样的问题，咱们来看看 HTTPS 的工做流程。

一、客户端发起 HTTPS 请求

这个没什么好说的，就是用户在浏览器里输入一个 HTTPS 网址，而后链接到 server 的 443 端口。

二、服务端的配置

采用 HTTPS 协议的服务器必需要有一套数字证书，能够本身制做，也能够向组织申请，区别就是本身颁发的证书须要客户端验证经过，才能够继续访问，而使用受信任的公司申请的证书则不会弹出提示页面（Let‘s Encrypt 就是个不错的选择，免费的 SSL 证书）。

这套证书其实就是一对公钥和私钥，若是对公钥和私钥不太理解，能够想象成一把钥匙和一个锁头，只是全世界只有你一我的有这把钥匙，你能够把锁头给别人，别人能够用这个锁把重要的东西锁起来，而后发给你，由于只有你一我的有这把钥匙，因此只有你才能看到被这把锁锁起来的东西。

三、传送证书

这个证书其实就是公钥，只是包含了不少信息，如证书的颁发机构，过时时间等等。

四、客户端解析证书

这部分工做是有客户端的 TLS 来完成的，首先会验证公钥是否有效，好比颁发机构，过时时间等等，若是发现异常，则会弹出一个警告框，提示证书存在问题。

若是证书没有问题，那么就生成一个随机值，而后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，否则看不到被锁住的内容。

五、传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端获得这个随机值，之后客户端和服务端的通讯就能够经过这个随机值来进行加密解密了。

六、服务段解密信息

服务端用私钥解密后，获得了客户端传过来的随机值(私钥)，而后把内容经过该值进行对称加密，所谓对称加密就是，将信息和私钥经过某种算法混合在一块儿，这样除非知道私钥，否则没法获取内容，而正好客户端和服务端都知道这个私钥，因此只要加密算法够彪悍，私钥够复杂，数据就够安全。

七、传输加密后的信息

这部分信息是服务段用私钥加密后的信息，能够在客户端被还原。

八、客户端解密信息

客户端用以前生成的私钥解密服务段传过来的信息，因而获取了解密后的内容，整个过程第三方即便监听到了数据，也一筹莫展。

简单说完了 HTTPS 的工做流程。让咱们再将注意力放在 SSL 的演化上。

1994年，Netscape 建立了 SSL 协议的原始规范并逐步发布协议改进版本。1995 年发布 SSL 2.0。1996年，Netscape 和 Paul Kocher 共同设计发布 SSL 3.0 协议，得到互联网普遍承认和支持。因特网工程任务组（IETF）接手负责该协议，并将其重命名为 TLS（传输层安全）协议。

咱们看到，SSL 2.0 规范是在 1995 年左右发布的，而 SSL 3.0 是在 1996 年 11 月发布的。有趣的是，SSL 3.0 是在 RFC 6101 [tools.ietf.org/html/rfc610…] 中描述的，该 RFC 于 2011 年 8 月发布。它位于历史类别中，该类别一般是被考虑和被丢弃的文档想法，或者是在决定记录它们时已经具备历史意义的协议（根据 IETF [www.ietf.org/about/group…] 说明）。在这种状况下，有一个描述 SSL 3.0 的 IETF 文档是颇有必要的，由于在其能够被用做规范参考。

再来看看，SSL 是如何激发 TLS 的发展的。后者在 1996 年 11 月以 draft-ietf-tls-protocol-00 [tools.ietf.org/html/draft-…] 宣告开始。它经历了六个草案版本，并于 1999 年初做为 RFC 2246 [tools.ietf.org/html/rfc224…] - TLS 1.0 正式发布。

在 1995 和 1999 年间，SSL 和 TLS 协议用于保护互联网上的 HTTP 通讯。这做为事实上的标准运行良好。直到 1998 年 1 月，随着 I-D draft-ietf-tls-HTTPs-00 [tools.ietf.org/html/draft-…] 的发布，HTTPS 的正式标准化过程才开始。该工做于 2000 年 5 月以 RFC 2616 - HTTP 上的 TLS 的发布结束。

TLS 在 2000 到 2007 年间继续发展，标准化为 TLS 1.1 和 1.2。直至七年后，TLS 的下一个版本开始进行，该版本在 2014 年四月被采纳为 draft-ietf-tls-tls13-00 [tools.ietf.org/html/draft-…]，并在 28 份草稿后，于 2018 年八月出了完成版本 RFC 8446 [tools.ietf.org/html/rfc844…] - TLS 1.3。

改进与 HTTP2

回到 HTTP 自己。在很长一段时间里，HTTP/1.1 已经足够好了（确实是，如今仍应用最为普遍），可是，Web 不断变化的需求使得咱们须要一个更好更合适的协议。

HTTP/1.1 自从 1997 年发布以来，咱们已经使用 HTTP/1.x 至关长一段时间了。但随着互联网近十年爆炸式的发展，从当初网页内容以文本为主，到如今以富媒体（如图片、声音、视频）为主，并且对页面内容实时性高要求的应用愈来愈多（好比聊天、视频直播），因此当时协议规定的某些特性，已经逐渐没法知足现代网络的需求了。

若是你有仔细观察，那些最流行的网站首页所须要下载资源的话，会发现一个很是明显的趋势。近年来加载网站首页须要下载的数据量在逐渐增长，并已经超过了 2100K。但在这里咱们更关心的是：平均每一个页面为了完成显示与渲染所须要下载的资源数也已经超过了 100 个。

基于此，在 2010 年到 2015 年，谷歌经过实践一个实验性的 SPDY 协议，证实了一个在客户端和服务器端交换数据的另类方式。其收集了浏览器和服务器端的开发者的焦点问题，明确了响应数量的增长和解决复杂的数据传输。在启动 SPDY 这个项目时预设的目标是：

页面加载时间（PLT）减小 50%。
无需网站做者修改任何内容。
将部署复杂性降至最低，无需变动网络基础设施。
与开源社区合做开发这个新协议。
收集真实性能数据，验证这个实验性协议是否有效。为了达到下降目标，减小页面加载时间的目标，SPDY 引入了一个新的二进制分帧数据层，以实现多向请求和响应、优先次序、最小化及消除没必要要的网络延迟，目的是更有效地利用底层 TCP 链接。

**HTTP/1.1 有两个主要的缺点：安全不足和性能不高，**因为背负着 HTTP/1.x 庞大的历史包袱，因此协议的修改，兼容性是首要考虑的目标，不然就会破坏互联网上无数现有的资产。

而如上图所示，SPDY 位于 HTTP 之下，TCP 和 SSL 之上，这样能够轻松兼容老版本的 HTTP 协议同时能够使用已有的 SSL 功能。

SPDY 协议在 Chrome 浏览器上证实可行之后，就被看成 HTTP/2 的基础，主要特性都在 HTTP/2 之中获得继承。

因而时间来到 2015 年，HTTP/2.0 问世。

HTTP/2 相比 HTTP/1.1 的修改并不会破坏现有程序的工做，可是新的程序能够借由新特性获得更好的速度。

HTTP/2 保留了 HTTP/1.1 的大部分语义，例如请求方法、状态码、乃至 URI 和绝大多数 HTTP 头部字段一致。而 HTTP/2 采用了新的方法来编码、传输客户端和服务器间的数据。

来看看 HTTP/2 的具体特色：

二进制分帧层：在应用层与传输层之间增长一个二进制分帧层，以此达到在不改动 HTTP 的语义，HTTP 方法、状态码、URI 及首部字段的状况下，突破 HTTP/1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层上，HTTP/2.0 会将全部传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码，其中 HTTP1.x 的首部信息会被封装到 Headers 帧，而咱们的 request body 则封装到 Data 帧里面。
多路复用：对于 HTTP/1.x，即便开启了长链接，请求的发送也是串行发送的，在带宽足够的状况下，对带宽的利用率不够，HTTP/2.0 采用了多路复用的方式，能够并行发送多个请求，提升对带宽的利用率。
数据流优先级：因为请求能够并发发送了，那么若是出现了浏览器在等待关键的 CSS 或者 JS 文件完成对页面的渲染时，服务器却在专一的发送图片资源的状况怎么办呢？HTTP/2.0 对数据流能够设置优先值，这个优先值决定了客户端和服务端处理不一样的流采用不一样的优先级策略。
服务端推送：在 HTTP/2.0 中，服务器能够向客户发送请求以外的内容，好比正在请求一个页面时，服务器会把页面相关的 logo，CSS 等文件直接推送到客户端，而不会等到请求来的时候再发送，由于服务器认为客户端会用到这些东西。这至关于在一个 HTML 文档内集合了全部的资源。
头部压缩：使用首部表来跟踪和存储以前发送的键值对，对于相同的内容，不会再每次请求和响应时发送。
HTTP/2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS。
HTTP/2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE。

QUIC 和 HTTP3

虽然 HTTP/2 提升了网页的性能，可是并不表明它已是完美的了，HTTP/3 就是为了解决 HTTP/2 所存在的一些问题而被推出来的。随着时间的演进，愈来愈多的流量都往手机端移动，手机的网络环境会遇到的问题像是封包丢失机率较高、较长的 Round Trip Time (RTT)和链接迁移等问题，都让主要是为了有线网路设计的HTTP/TCP协议遇到贫颈。

咱们能够看两个典型的问题。

第一握手带来的消耗。HTTP/2 使用 TCP 协议来传输的，而若是使用 HTTPS 的话，还须要使用 TLS 协议进行安全传输，而使用 TLS 也须要一个握手过程，这样就须要有两个握手延迟过程：

在创建 TCP 链接的时候，须要和服务器进行三次握手来确认链接成功，也就是说须要在消耗完 1.5 个 RTT 以后才能进行数据传输。
进行 TLS 链接，TLS 有两个版本——TLS 1.2 和 TLS 1.3，每一个版本创建链接所花的时间不一样，大体是须要1~2个 RTT。

总之，在传输数据以前，咱们须要花掉 3～4 个 RTT。

第二，TCP 的队头阻塞并无获得完全解决。咱们知道，为了实现多路复用，在 HTTP/2 中多个请求是跑在一个 TCP 管道中的。但当出现了丢包时，HTTP/2 的表现反倒不如 HTTP/1.X 了。由于 TCP 为了保证可靠传输，有个特别的丢包重传机制，丢失的包必需要等待从新传输确认，HTTP/2 出现丢包时，整个 TCP 都要开始等待重传，那么就会阻塞该 TCP 链接中的全部请求。而对于 HTTP/1.1 来讲，能够开启多个 TCP 链接，出现这种状况反到只会影响其中一个链接，剩余的 TCP 链接还能够正常传输数据。

至此，咱们很容易就会想到，为何不直接去修改 TCP 协议？其实这已是一件不可能完成的任务了。由于 TCP 存在的时间实在太长，已经充斥在各类设备中，而且这个协议是由操做系统实现的，更新起来很是麻烦，不具有显示操做性。

HTTP/3 乘着 QUIC 来了。

HTTP3 是基于 QUIC 的协议，如上图。先说 QUIC，QUIC 协议是 Google 提出的一套开源协议，它基于 UDP 来实现，直接竞争对手是 TCP 协议。QUIC 协议的性能很是好，甚至在某些场景下能够实现 0-RTT 的加密通讯。

在 Google 关于 QUIC [docs.google.com/document/d/…] 的文件中提到，与 HTTP/2 相比，QUIC 主要具备下列优点：

Reduce connection establishment latency （减小链接创建时间）
Improved congestion control （改进拥塞控制）
Multiplexing without head-of-line blocking （没有队头阻塞的多路复用）
Forward error correction （修复以前的错误）
Connection migration（支持网络迁移）

多路复用，避免队头阻塞

这句话提及来很容易，但理解起来并不那么显然，要想理解 QUIC 协议到底作了什么以及这么作的必要性，我想仍是从最基础的 HTTP/1.0 聊起比较合适。

Pipiline

根据谷歌的调查，如今请求一个网页，平均涉及到 80 个资源，30 多个域名。考虑最原始的状况，每请求一个资源都须要创建一次 TCP 请求，显然不可接受。HTTP 协议规定了一个字段 Connection，不过默认的值是 close，也就是不开启。

早在 1999 年提出的 HTTP 1.1 [www.ietf.org/rfc/rfc2616…] 协议中就把 Connection 的默认值改为了Keep-Alive，这样同一个域名下的多个 HTTP 请求就能够复用同一个 TCP 链接。这种作法被称为 HTTP Pipeline，优势是显著的减小了创建链接的次数，也就是大幅度减小了 RTT。

以上面的数据为例，若是 80 个资源都要走一次 HTTP 1.0，那么须要创建 80 个 TCP 链接，握手 80 次，也就是 80 个 RTT。若是采用了 HTTP 1.1 的 Pipeline，只须要创建 30 个 TCP 链接，也就是 30 个 RTT，提升了 62.5% 的效率。

Pipeline 解决了 TCP 链接浪费的问题，但它本身还存在一些不足之处，也就是全部管道模型都难以免的队头阻塞问题。

队头阻塞

咱们再举个简单并且直观的例子，假设加载一个 HTML 一共要请求 10 个资源，那么请求的总时间是每个资源请求时间的总和。最直观的体验就是，网速越快请求时间越短。然而若是某一个资源的请求被阻塞了（好比 SQL 语句执行很是慢）。但对于客户端来讲全部后续的请求都会所以而被阻塞。

队头阻塞（Head of line blocking，下文简称 HOC）说的是当有多个串行请求执行时，若是第一个请求不执行完，后续的请求也没法执行。好比上图中，若是第四个资源的传输花了好久，后面的资源都得等着，平白浪费了不少时间，带宽资源没有获得充分利用。

所以，HTTP 协议容许客户端发起多个并行请求，好比在笔者的机器上最多支持六个并发请求。并发请求主要是用于解决 HOC 问题，当有三个并发请求时，状况会变成这样:

可见虽然第四个资源的请求被阻塞了，可是其余的资源请求并不必定会被阻塞，这样总的来讲网络的平均利用率获得了提高。

支持并发请求是解决 HOC 问题的一种方案，这句话没有错。可是咱们要理解到：“并发请求并不是是直接解决了 HOC 的问题，而是尽量减小 HOC 形成的影响“，以上图为例，HOC 的问题依然存在，只是不会太浪费带宽而已。

有读者可能会好奇，为何很少搞几个并发的 HTTP 请求呢？刚刚说过笔者的电脑最多支持 6 个并发请求，谷歌曾经作过实验，把 6 改为 10，而后尝试访问了三千多个网页，发现平均访问时间居然还增长了 5% 左右。这是由于一次请求涉及的域名有限，再多的并发 HTTP 请求并不能显著提升带宽利用率，反而会消耗性能。

SPDY 的作法

有没有办法解决队头阻塞呢？

答案是确定的。SPDY 协议的作法很值得借鉴，它采用了多路复用（Multiplexing）技术，容许多个 HTTP 请求共享同一个 TCP 链接。咱们假设每一个资源被分为多个包传递，在 HTTP 1.1 中只有前面一个资源的全部数据包传输完毕后，后面资源的包才能开始传递（HOC 问题），而 SPDY 并不这么要求，你们能够一块儿传输。

这么作的代价是数据会略微有一些冗余，每个资源的数据包都要带上标记，用来指明本身属于哪一个资源，这样客户端最后才能把他们正确的拼接起来。不一样的标记能够理解为图中不一样的颜色，每个小方格能够理解为资源的某一个包。

TCP 窗口

是否是以为 SPDY 的多路复用已经够厉害了，解决了队头阻塞问题？很遗憾的是，并无，并且我能够很确定的说，只要你还在用 TCP 连接，HOC 就是逃不掉的噩梦，不信咱们来看看 TCP 的实现细节。

咱们知道 TCP 协议会保证数据的可达性，若是发生了丢包或者错包，数据就会被重传。因而问题来了，若是一个包丢了，那么后面的包就得停下来等这个包从新传输，也就是发生了队头阻塞。固然 TCP 协议的设计者们也不傻，他们发明了滑动窗口的概念:

这样的好处是在第一个数据包（1-1000）发出后，没必要等到 ACK 返回就能够马上发送第二个数据包。能够看出图中的 TCP 窗口大小是 4，因此第四个包发送后就会开始等待，直到第一个包的 ACK 返回。这样窗口能够向后滑动一位，第五个包被发送。

若是第1、2、三个的包都丢失了也没有关系，当发送方收到第四个包时，它能够确信必定是前三个 ACK 丢了而不是数据包丢了，不然不会收到 4001 的 ACK，因此发送方能够大胆的把窗口向后滑动四位。

滑动窗口的概念大幅度提升了 TCP 传输数据时抗干扰的能力，通常丢失一两个 ACK 根本不要紧。但若是是发送的包丢失，或者出错，窗口就没法向前滑动，出现了队头阻塞的现象。

QUIC 是如何作的

QUIC 协议基于 UDP 实现，咱们知道 UDP 协议只负责发送数据，并不保证数据可达性。这一方面为 QUIC 的多路复用提供了基础，另外一方面也要求 QUIC 协议本身保证数据可达性。

SPDY 为各个数据包作好标记，指明他们属于哪一个 HTTP 请求，至于这些包能不能到达客户端，SPDY 并不关心，由于数据可达性由 TCP 协议保证。既然客户端必定能收到包，那就只要排序、拼接就好了。QUIC 协议采用了多路复用的思想，但同时还得本身保证数据的可达性。

TCP 协议的丢包重传并非一个好想法，由于一旦有了先后顺序，队头阻塞问题将不可避免。而无序的数据发送给接受者之后，如何保证不丢包，不错包呢？这看起来是个不可能完成的任务，不过若是把要求下降成：最多丢一个包，或者错一个包。事情就简单多了，操做系统中有一种存储方式叫 RAID 5，采用的是异或运算加上数据冗余的方式来保证前向纠错（FEC: Forward Error Correcting）。QUIC 协议也是采用这样的思想，这里再也不赘述。

利用冗余数据的思想，QUIC 协议基本上避免了重发数据的状况。固然 QUIC 协议仍是支持重传的，好比某些很是重要的数据或者丢失两个包的状况。

少 RTT，请求更快速

前面说到，一次 HTTPS 请求，它的基本流程是三次 TCP 握手外加四次 SSL/TLS 握手。也就是须要三个 RTT。可是 QUIC 在某些场景下，甚至可以作到 0RTT。

首先介绍下什么是 0RTT。所谓的 0RTT 就是通讯双方发起通讯链接时，第一个数据包即可以携带有效的业务数据。而咱们知道，这个使用传统的TCP是彻底不可能的，除非你使能了 TCP 快速打开特性，而这个很难，由于几乎没人愿意为了这个收益去对操做系统的网络协议栈大动手脚。未使能 TCP 快速打开特性的TCP传输第一笔数据前，至少要等1个RTT。

咱们这里再说说 HTTP2。对于 HTTP2 来讲，原本须要一个额外的 RTT 来进行协商，判断客户端与服务器是否是都支持 HTTP2，不过好在它能够和 SSL 握手的请求合并。这也致使了一个现象，就是大多数主流浏览器仅支持 HTTPS2 而不单独支持 HTTP2。由于 HTTP2 须要一个额外的 RTT，HTTPS2 须要两个额外的 RTT，仅仅是增长一个 RTT 就能得到数据安全性，仍是很划算的。

TCP 快速打开

何谓 TCP 快速打开，即客户端能够在发送第一个 SYN 握手包时携带数据，可是 TCP 协议的实现者不容许将把这个数据包上传给应用层。这主要是为了防止 TCP 泛洪攻击 [tools.ietf.org/html/rfc498…]。

由于若是 SYN 握手的包能被传输到应用层，那么现有的防御措施都没法防护泛洪攻击，并且服务端也会由于这些攻击而耗尽内存和 CPU。

固然 TCP 快速打开并非彻底不可行的。人们设计了 TFO (TCP Fast Open)，这是对 TCP 的拓展，不只能够在发送 SYN 时携带数据，还能够保证安全性。

TFO 设计了一个 Cookie，它在第一次握手时由 server 生成，Cookie 主要是用来标识客户端的身份，以及保存上次会话的配置信息。所以在后续从新创建 TCP 链接时，客户端会携带 SYN + Cookie + 请求数据，而后不等 ACK 返回就直接开始发送数据。

服务端收到 SYN 后会验证 Cookie 是否有效，若是无效则会退回到三次握手的步骤，以下图所示:

同时，为了安全起见，服务端为每一个端口记录了一个值 PendingFastOpenRequests，用来表示有多少请求利用了 TFO，若是超过预设上限就再也不接受。

关于 TFO 的优化，能够总结出三点内容:

TFO 设计的 Cookie 思想和 SSL 恢复握手时的 Session Ticket 很像，都是由服务端生成一段 Cookie 交给客户端保存，从而避免后续的握手，有利于快速恢复。
第一次请求绝对不会触发 TFO，由于服务器会在接收到 SYN 请求后把 Cookie 和 ACK 一块儿返回。后续客户端若是要从新链接，才有可能使用这个 Cookie 进行 TFO
TFO 并不考虑在 TCP 层过滤重复请求，之前也有相似的提案想要作过滤，但由于没法保证安全性而被拒绝。因此 TFO 仅仅是避免了泛洪攻击（相似于 backlog），但客户端接收到的，和 SYN 包一块儿发来的数据，依然有可能重复。不过也只有多是 SYN 数据重复，因此 TFO 并不处理这种状况，要求服务端程序自行解决。这也就是说，不只仅要操做系统的支持，更要求应用程序（好比 MySQL）也支持 TFO。

TFO 使得 TCP 协议有可能变成 0-RTT，核心思想和 Session Ticket 的概念相似: 将当前会话的上下文缓存在客户端。若是之后须要恢复对话，只须要将缓存发给服务器校验，而没必要花费一个 RTT 去等待。

结合 TFO 和 Session Ticket 技术，一个原本须要花费 3 个 RTT 才能完成的请求能够被优化到一个 RTT。若是使用 QUIC 协议，咱们甚至能够更进一步，将 Session Ticket 也放到 TFO 中一块儿发送，这样就实现了 0-RTT 的对话恢复。

QUIC 是怎么作的

让咱们看看 QUIC 是怎么作的。

首先声明一点，若是一对使用 QUIC 进行加密通讯的双方此前历来没有通讯过，那么 0-RTT 是不可能的，即使是 QUIC 也是不可能的。

QUIC 握手的过程须要一次数据交互，0-RTT 时延便可完成握手过程当中的密钥协商，比 TLS 相比效率提升了 5 倍，且具备更高的安全性。在握手过程当中使用 Diffie-Hellman 算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数会周期性的更新。初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。

具体握手过程以下：

(1) 客户端判断本地是否已有服务器的所有配置参数，若是有则直接跳转到(5)，不然继续

(2) 客户端向服务器发送 inchoate client hello(CHLO) 消息，请求服务器传输配置参数

(3) 服务器收到 CHLO，回复 rejection(REJ) 消息，其中包含服务器的部分配置参数

(4) 客户端收到 REJ，提取并存储服务器配置参数，跳回到(1)

(5) 客户端向服务器发送 full client hello 消息，开始正式握手，消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和本身选择的公开数，能够计算出初始密钥。

(6) 服务器收到 full client hello，若是不一样意链接就回复 REJ，同(3)；若是赞成链接，根据客户端的公开数计算出初始密钥，回复 server hello(SHLO)消息，SHLO 用初始密钥加密，而且其中包含服务器选择的一个临时公开数。

(7) 客户端收到服务器的回复，若是是 REJ 则状况同(4)；若是是 SHLO，则尝试用初始密钥解密，提取出临时公开数

(8) 客户端和服务器根据临时公开数和初始密钥，各自基于 SHA-256 算法推导出会话密钥

(9) 双方更换为使用会话密钥通讯，初始密钥此时已无用，QUIC 握手过程完毕。以后会话密钥更新的流程与以上过程相似，只是数据包中的某些字段略有不一样。

写在最后

想起有一个名言：计算机领域没有什么问题是加一层解决不了的，若是有，就再加一层。网络模型原本就是层层累加，到了 Web 得以快速生动的展示给人们以丰富的内容。从 HTTP 的演变过程当中，咱们能够看到中间又累加了若干层。不知道之后，又会是怎么样呢？

你们会发现，笔者在文中不止一次提到了演变这个词。是的，这是来自达尔文进化论中的理论。在笔者看来，“物竞天择，适者生存”的演变理论和计算机领域的技术变化是很相似的，只不过在这里，不是天择，而是人择。由市场，由用户来选择。不知道接下来，做为选择者的咱们，又将怎样主导技术的走向？