小知识，大挑战！本文正在参与「程序员必备小知识」创作活动 本文已参与 「掘力星计划」 ，赢取创作大礼包，挑战创作激励金
序言
HTTP 协议可以算是在人们日常生活、工作用得比较多的协议。我们使用浏览器访问网页，就是通过 HTTP 来传递数据；客户端跟服务器交互，大部分会使用到 HTTP 协议。对于我们做数据采集的人来说，也是再正常不过。Requests 和 Scrapy 都是对 HTTP 进行封装的支持自定义配置的库。
互联网工程任务组（IETF）在去年提议将 HTTP-over-QUIC 重命名为 HTTP/3。我们是做技术的，需要保持一定敏感度。一旦 HTTP/3 标准被定下来，各大产商会相继支持，那会给我们带来什么影响？需要我们回顾下 HTTP 的发展史。
HTTP 0.9
我们把时间拨回到 1991年， 万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（IETF）制定了 HTTP 0.9 标准。因为那个年代互联网还在普及，加上网速带宽低，所以 HTTP 0.9 只支持 GET 请求。
HTTP 1.0
时间来到1996 年 5 月，HTTP/1.0 版本发布，HTTP 协议新增很多内容。首先是请求方式的多样化，从单一的 GET 请求，增加了 POST 命令和 HEAD 命令。除此之外，还支持发送任何格式的内容。这两项新增内容，不仅使得互联网不仅可以传输文字、传输图像、视频、二进制文件，还丰富了浏览器与服务器的互动方式。这为互联网的大发展奠定了基础。
再次，HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。
但 HTTP/1.0 还是存在缺点：
第一点是： 连接无法复用 。 HTTP 1.0 规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。 如果还要请求其他资源，就必须再新建一个连接。
第二点是： Head-Of-Line Blocking（HOLB，队头阻塞） 。 HOLB 是指一系列包（package）因为第一个包被阻塞； 当页面中需要请求很多资源的时候，HOLB 会导致在达到最大请求数量时，剩余的资源需要等待其它资源请求完成后才能发起请求。 这会导致带宽无法被充分利用，以及后续健康请求被阻塞。
HTTP 1.1
W3C 组织为了解决 HTTP 1.0 遗留的问题，在 1997 年 1 月，发布 HTTP/1.1 版本，只比 1.0 版本晚了半年。它进一步完善了 HTTP 协议，一直用到了20年后的今天，直到现在还是最流行的版本。具体优化点：
缓存处理 。 在 HTTP 1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP 1.1则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用 。 针对网络开销大的问题，HTTP 1.1 在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
错误通知的管理 。 在HTTP1.1中新增了24个错误状态响应码。 4 . 长链接。 HTTP/1.1 加入 Connection： keep-alive 可以复用一部分连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
随着网络的发展，HTTP 1.1 还是暴露出一些局限性。
虽然加入 keep-alive 可以复用一部分连接，但域名分片等情况下仍然需要建立多个 connection，耗费资源，给服务器带来性能压力。
pipeling 只部分解决了 HOLB。 HTTP 1.1 尝试使用 pipeling 来解决队头阻塞问题，即浏览器可以一次性发出多个请求（同个域名、同一条 TCP 链接）。 但 pipeling 要求返回是按序的，那么前一个请求如果很耗时（比如处理大图片），那么后面的请求即使服务器已经处理完，仍会等待前面的请求处理完才开始按序返回。
协议开销大。 HTTP/1 在使用时，header 里携带的内容过大，在一定程度上增加了传输的成本，并且每次请求 header 基本不怎么变化，尤其在移动端增加用户流量。
HTTP 2.0
互联网的发展还是受到网络速度的限制。有个调侃的话，永远不要忽略一辆载满磁带的在高速公路上飞驰的卡车的带宽。大概意思说数据量大到一定程度时，物理运输无论是速度、安全性、便捷性都比网络传输好。
谷歌是业务首先提出云计算的概念；加上谷歌的公司文化特点是自己内部信息公开、透明，每个人都能了解到其他任何人当前的工作计划、代码等。谷歌为了解决内部系统传输数据慢的问题，自行研发的 SPDY 协议，目的是以最小化网络延迟，提升网络速度，解决 HTTP/1.1 效率不高的问题。
SPDY 协议是在 TCP 协议之上。相比 HTTP/1 的文本格式，HTTP/2 采用二进制格式传输数据，解析起来更高效。同时，还支持对 Header 压缩，减少头部的包体积大小。
HTTPS加密流程
- client向server发送请求baidu.com，然后连接到server的443端口，发送的信息主要是随机值1和客户端支持的加密算法。
- server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是client发送给server加密算法的子集。
- 随即server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
- 客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）。
- 客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
- 传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥。
- 服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同。
- 客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。
- 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。
