全面理解HTTP&HTTPS协议

该文章是我本身学习笔记及理解，但愿通篇读完能让你对HTTP和HTTPS有一个更全面的理解，若是错误地方烦请指正。文字较多，全篇预计阅读耗时20分钟。

HTTP

介绍

超文本传输协议（英语：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协做式和超媒体信息系统的应用层协议[1]。HTTP是万维网的数据通讯的基础。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。经过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。《维基百科》

从 1990 年开始HTTP就在 WWW 上普遍应用。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户 信息和内容的相似于MIME的消息结构。服务器以一个状态行做为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。

• HTTP是基于TCP/IP通讯协议来传递数据（HTML 文件, 图片文件, 查询结果等）
• HTTP协议一般承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了咱们常说的HTTPS。
• HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。
• HTTP默认的端口号为80，HTTPS的端口号为443

发展

HTTP刚出现是为了将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器，随着WEB的持续发展，例如CSS、JS丰富了页面展现和基于HTTP协议的ajax增长了咱们向服务器获取数据的方式，HTTP也不断的进行优化迭代。

版本	发布时间	主要内容	现状
HTTP/0.9	1991	无状态、只支持GET请求、无协议头、只支持纯文本	已过期
HTTP/1.0	1996	有协议头、支持GET/POST/HEAD等方法、传输内容不限	仍被采用
HTTP/1.1	1999	默认持久链接、请求管道化、增长缓存处理、增长Host字段、支持断点传输、增长错误通知处理	目前最被普遍使用
HTTP/2	2015	新的二进制格式（帧）、多路复用、header压缩、请求优先级、服务端推送	将来的发展趋势
HTTP/3	2018.11	新的二进制格式（帧）、多路复用、header压缩、请求优先级、服务端推送	发展中

HTTP/2

HTTP/2继承于Google的SPDY协议。HTTP/2: the Future of the Internet | Akamai这是Akamai公司用来讲明HTTP/2的优点所建立的demo。同时请求379张图片，HTTP/2速度占了绝对的优点。

1. 二进制分帧

HTTP 2.0 的全部帧都采用二进制编码

• 帧：客户端与服务器经过交换帧来通讯，帧是基于这个新协议通讯的最小单位。
• 消息：是指逻辑上的 HTTP 消息，好比请求、响应等，由一或多个帧组成。
• 流：流是链接中的一个虚拟信道，能够承载双向的消息；每一个流都有一个惟一的整数标识符（一、2 … N）；

2. 多路复用

之因此速度能有如此优化，主要得益于HTTP2.0的多路复用技术。
有了新的分帧机制后，HTTP/2再也不依赖多个TCP 链接去处理更多并发的请求，每一个数据流都拆分红不少互不依赖的帧，而这些帧能够交错（乱序发送），还能够分优先级。最后再在另外一端根据每一个帧首部的流标识符把它们从新组合起来。从始至终，客户端与服务器之间只须要一个链接(同个域名下)便可。

3. 头部压缩

HTTP 协议不带有状态，每次请求都必须附上全部信息。因此，请求的不少字段都是重复的，好比Cookie和User Agent，如出一辙的内容，每次请求都必须附带，这会浪费不少带宽，也影响速度。
HTTP/2 对这一点作了优化，引入了头信息压缩机制（header compression）。一方面，头信息使用gzip或compress压缩后再发送；另外一方面，客户端和服务器同时维护一张头信息表，全部字段都会存入这个表，生成一个索引号，之后就不发送一样字段了，只发送索引号，这样就提升速度了。

4. 数据流

由于 HTTP/2 的数据包是不按顺序发送的，同一个链接里面连续的数据包，可能属于不一样的回应。所以，必需要对数据包作标记，指出它属于哪一个回应。
HTTP/2 将每一个请求或回应的全部数据包，称为一个数据流（stream）。每一个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪一个数据流。另外还规定，客户端发出的数据流，ID一概为奇数，服务器发出的，ID为偶数。
数据流发送到一半的时候，客户端和服务器均可以发送信号（RST_STREAM帧），取消这个数据流。1.1版取消数据流的惟一方法，就是关闭TCP链接。这就是说，HTTP/2 能够取消某一次请求，同时保证TCP链接还打开着，能够被其余请求使用。
客户端还能够指定数据流的优先级。优先级越高，服务器就会越早回应。

5. 服务器推送

HTTP/2 容许服务器未经请求，主动向客户端发送资源，这叫作服务器推送（server push）。常见场景是客户端请求一个网页，这个网页里面包含不少静态资源。服务端能在客户端请求静态资源前主动把这些静态资源随着网页一块儿发给客户端了，省去了客户端创建链接、发起请求等过程，极大提高了速度。

存在的问题

因为底层支持TCP协议的缺陷，致使HTTP/2仍是存在一些问题。

• TCP+TLS创建链接耗时 HTTP/2使用TCP协议来传输的，而若是使用HTTPS的话，还须要使用TLS协议进行安全传输，而使用TLS也须要一个握手过程。整个启动过程须要耗时3~4个RTT（往返时延）。
• 队头阻塞 虽然HTTP/2的传输连接能够多路复用，但TCP为了保证传输可靠有序，有个特别的“丢包重传”机制，丢失的包必需要等待从新传输确认，HTTP/2出现丢包时，整个 TCP 都要开始等待重传。例如单个TCP连接同时承载了三路连接，当其中某一路出现丢包，则其余两路都会受到影响，必须从丢包时刻开始重传。若是丢包率太高时，HTTP/2传输不如HTTP/1.1。

HTTP/3

因为TCP从1970年发明至今已经存在了太多年，存在于各类设备中，去修改TCP协议是不可能完成的事。HTTP/3 抛弃 TCP 协议，以全新的视角从新设计 HTTP。其底层支撑是 QUIC 协议，该协议基于 UDP，有 UDP 特有的优点，同时它又取了 TCP 中的精华，实现了即快又可靠的协议

• 实现了相似TCP的流量控制、传输可靠性的功能。 虽然UDP不提供可靠性的传输，但QUIC在UDP的基础之上增长了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其余一些TCP中存在的特性。
• 实现了快速握手功能。 因为QUIC是基于UDP的，因此QUIC能够实现使用0-RTT或者1-RTT来创建链接，这意味着QUIC能够用最快的速度来发送和接收数据，这样能够大大提高首次打开页面的速度。0RTT 建连能够说是 QUIC 相比 HTTP2 最大的性能优点。
• 集成了TLS加密功能。 目前QUIC使用的是TLS1.3，相较于早期版本TLS1.3有更多的优势，其中最重要的一点是减小了握手所花费的RTT个数。
• 多路复用，完全解决TCP中队头阻塞的问题 和TCP不一样，QUIC实现了在同一物理链接上能够有多个独立的逻辑数据流（以下图）。实现了数据流的单独传输，就解决了TCP中队头阻塞的问题。

HTTP/3相比于HTTP/2改动很大，因此目前还存在一些问题，例如与旧设备的兼容、服务器的推送滥用、缺乏配套调试工具等，相信随着时间流逝，HTTP/3会愈来愈完善。

HTTP请求过程

1. 域名解析。如用浏览器访问http://hackr.jp/xss/web页面，须要域名系统DNS解析域名hackr.jp,得主机的IP地址 20X.189.105.112，接着结合本机信息封装成HTTP请求数据包。
2. 创建链接(TCP三次握手)。在HTTP工做开始以前，客户端首先要经过网络与服务器创建链接，该链接是经过TCP来完成的，通常TCP链接的端口号是80。
3. 客户端发送请求。创建链接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可内容。
4. 服务器响应。服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
5. 服务器关闭链接。 通常状况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP链接，而后若是浏览器或者服务器在其头信息加入了这行代码: Connection:keep-alive，TCP链接在发送后将仍然保持打开状态，因而，浏览器能够继续经过相同的链接发送请求。保持链接节省了为每一个请求创建新链接所需的时间，还节约了网络带宽。

Request

一个完整的请求由请求行、请求头和请求体三部分组成。

请求行

请求行包含:请求方法、请求地址（URL）和协议版本。

请求方法

方法名	功能
GET	向指定的资源发出“显示”请求，使用 GET 方法应该只用在读取数据上，而不该该用于产生“反作用”的操做中
POST	指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求文本中。这个请求可能会建立新的资源或者修改现有资源，或二者皆有。
PUT	向指定资源位置上传其最新内容
DELETE	请求服务器删除 Request-URI 所标识的资源
OPTIONS	使服务器传回该资源所支持的全部HTTP请求方法。用*来代替资源名称，向 Web 服务器发送 OPTIONS 请求，能够测试服务器功能是否正常运做
HEAD	与 GET 方法同样，都是向服务器发出指定资源的请求，只不过服务器将不传回资源的本文部分，它的好处在于，使用这个方法能够在没必要传输所有内容的状况下，就能够获取其中关于该资源的信息（原信息或称元数据）
TRACE	显示服务器收到的请求，主要用于测试或诊断
CONNECT	HTTP/1.1 中预留给可以将链接改成通道方式的代理服务器。一般用于 SSL 加密服务器的连接（经由非加密的 HTTP 代理服务器）

请求头

请求头包含客户端主机名和客户端环境信息。 常见的请求头：

名称	做用
Authorization	用于设置身份认证信息
User-Agent	用户标识，如：OS 和浏览器的类型和版本
Accept-Encoding	告诉服务器能接受什么编码格式，如 gzip、deflate
If-Modified-Since	值为上一次服务器返回的Last-Modified值，用于肯定某个资源是否被更改过，没有更改过就从缓存中读取
If-None-Match	值为上一次服务器返回的 ETag 值，通常会和If-Modified-Since
Cookie	已有的Cookie
Referer	标识请求引用自哪一个地址，好比你从页面 A 跳转到页面 B 时，值为页面 A 的地址
Host	请求的主机和端口号

通用的首部字段：

名称	做用
Cache-Control	响应输出到客户端后,服务端经过该属性告诉客户端该怎么控制响应内容的缓存
Date	代表HTTP报文建立的日期和时间
Trailer	报文某段的的首部一览
Warning	错误通知

请求体

请求体（又叫请求正文）是 post 请求方式中的请求参数，以 key = value 形式进行存储，多个请求参数之间用&链接，若是请求当中请求体，那么在请求头当中的 Content-Length 属性记录的就是该请求体的长度

Response

一个完整的响应由响应行、响应头和响应体三部分组成。

响应行

响应行包含：协议版本、状态码和状态描述。

响应状态码

• 2XX成功

  • 200(OK) 客户端发过来的数据被正常处理
  • 204(Not Content) 正常响应，没有实体
  • 206(Partial Content) 范围请求，返回部分数据，响应报文中由Content-Range指定实体内容

• 3XX重定向

  • 301(Moved Permanently) 永久重定向
  • 302(Found) 临时重定向，规范要求，方法名不变，可是都会改变
  • 303(See Other) 和302相似，但必须用GET方法
  • 304(Not Modified) 状态未改变， 配合(If-Match、If-Modified-Since、If-None_Match、If-Range、If-Unmodified-Since)
  • 307(Temporary Redirect) 临时重定向，不应改变请求方法

• 4XX客户端错误

  • 400(Bad Request) 请求报文语法错误
  • 401 (unauthorized) 须要认证
  • 403(Forbidden) 服务器拒绝访问对应的资源
  • 404(Not Found) 服务器上没法找到资源

• 5XX服务器错误

  • 500(internal sever error)表示服务器端在执行请求时发生了错误
  • 503(service unavailable)代表服务器暂时处于超负载或正在停机维护，没法处理请求

响应头

同请求头同样，用来传递附加信息。 常见的响应头：

名称	做用
Accept-Ranges	是否接受字节范围请求
ETag	表示你请求资源的版本,若是该资源发生啦变化,那么这个属性也会跟着变
Location	在重定向中或者建立新资源时使用
Set-Cookie	服务端能够设置客户端的cookie

响应体

响应体也就是网页的正文内容，通常在响应头中会用 Content-Length 来明确响应体的长度，便于浏览器接收，对于大数据量的正文信息，也会使用 chunked 的编码方式。

HTTPS

介绍

回到开篇的图片可知，HTTPS是在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并保护交换数据的隐私与完整性。为了解决HTTP的明文通讯，没法验证对方身份和报文的完整性等问题，网景公司（Netscape）在1994年提出了HTTPS协议，随后拓展到互联网上。目前HTTPS已经取代HTTP成为主流协议，并且HTTP/2以后都只能用于HTTPS加密链接。

安全通讯的实现

HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

1.保证通讯内容不被窃听

• 对称加密 对称密钥（Symmetric-key algorithm）又称为共享密钥加密，加密和解密使用相同的密钥。常见的对称加密算法有DES、3DES、AES、RC五、RC6。对称密钥的优势是计算速度快，可是它有缺点，双方须要都知道密钥才能加解密，所以如何安全的发送密钥给接收者成为了一个问题。

• 非对称加密 公开密钥加密（public-key cryptography）简称公钥加密。公钥能够随意分发，发送方使用公钥进行加密处理，接收方用本身的私有私钥进行解密。这种方式没必要担忧密钥被攻击者窃听而盗走，但服务器没法验证公钥信息，存在被中间人截获替换的风险，另外非对称加密的传输效率比对称加密低。

• 解决方案：对称加密+非对称加密 对称加密效率高，非对称加密能够防止传输内容被截获。结合二者的优点，HTTPS在交换秘钥阶段采用非对称加密，创建通讯后经过对称加密来传递信息。例如发送信息的一方先使用对方的公钥加密对称密钥，对方接收到信息后用私钥进行解密得到对称密钥，以后双方的通讯都用对称密钥进行加解密。

2.保证报文不被篡改

• 解决方案：数字签名 因为存在中间节点，传递的信息没法被解密，但仍然可能被随意篡改。为了保证双方发出和接受的是信息一致，可采用数字签名的方式。 发送者先将公钥、我的信息和其余信息用Hash算法生成消息摘要，再用私钥加密生成数字签名。接收方收到公钥、我的信息、其余信息和数字签名，从新用Hash算法生成消息摘要，并用公钥解密数字签名获得的摘要进行校验是否相同。 到此为止，还存在一个最关键的问题：如何在互联网上将公钥安全的传递给对方？

3.验证对方身份

• 解决方案：数字证书 为了防止中间人攻击，掉包公钥，咱们须要一个第三方权威机构来管理，让第三方机构用其私钥加密生成数字签名，当接受到身份信息和公钥后再用第三方机构的公钥进行解密来比对信息摘要，这个第三方机构就是CA(Certification Authority)。向CA提交公钥、组织信息、我的信息等信息并申请认证，认证经过后CA会向申请者颁发CA证书，证书内包含：申请者公钥、申请者的组织信息和我的信息、签发机构、CA的信息、有效时间、证书序列号等信息的明文，同时包含一个数字签名。 CA自身的数字证书在咱们操做系统刚安装好的时候，这些CA自身的数字证书就已经被微软（或者其它操做系统）安装在操做系统中了。而CA的公钥就包含在其中。这样，CA就能够经过自身的私钥对发布的数字证书进行签名，而在客户端就可以用对应的公钥来对其进行解密，确保了双方能安全传输服务器公钥。

完整过程

1. 客户端本地会存放着CA证书机构的公钥，在发起HTTPS请求时，会首先向服务器第索要CA证书，并告发送随机数A、支持的对称加密算法、Hash算法等。
2. 服务器收到信息后会将证书、加密算法、Hash算法、随机数B等发给客户端。
3. 客户端验证证书是否有效，并使用CA证书机构的公钥解密证书中的数字签名，进行信息比对校验。而后经过验证事后的公钥加密会话秘钥（pre-master key）发送给服务器，这是惟一使用非对称加密的地方。
4. 服务器会使用私钥解密获得会话密钥，并经过以前获得的随机数A、随机数B和双方肯定的加密算法生成一个最终的会话密钥（master secret），服务器加密一段信息发给客户端进行加密验证。
5. 客户端也经过以前随机数A、随机数B和会话密钥生成最终的会话密钥，并对服务器的信息进行解密，若解密成功，双方便结束验证，用会话密钥进行通讯。

至此，完成了服务器向客户端的单向验证，若要使客户端对服务器也进行验证操做（双向验证），则须要将CA证书放在客户端。 若采用双向验证，则在步骤2服务器会额外向客户端请求客户端的CA证书信息，客户端在步骤3验证服务器证书后，会将客户端证书发给服务器进行验证。 双向验证能更好的预防中间人攻击，客户端内置了仅接受指定域名的证书，保障了客户端与服务端通讯的惟一性和安全性，但要注意证书续期后需从新将证书放入到客户端中。

用信鸽来解释HTTPS

文章 用信鸽来解释 HTTPS 详细描述了整个过程，这里再也不累述，想了解的能够自行阅读。

优势&缺点

• 优势(安全性) 尽管HTTPS并不是绝对安全，掌握根证书的机构、掌握加密算法的组织一样能够进行中间人形式的攻击，但HTTPS还是现行架构下最安全的解决方案，大幅增长了中间人攻击的成本。
• 缺点(成本&资源占用) SSL证书需向CA机构购买，功能越强大费用越高;握手过程至少要增长1~2个RTT，且与纯文本通讯相比，加密通讯会消耗更多的CPU及内存资源。(能够经过性能优化提高性能)

HTTPS性能优化

• CDN接入 HTTPS 增长的延时主要是传输延时 RTT，RTT 的特色是节点越近延时越小，CDN 自然离用户最近，所以选择使用 CDN 做为 HTTPS 接入的入口，将可以极大减小接入延时。CDN 节点经过和业务服务器维持长链接、会话复用和链路质量优化等可控方法，极大减小 HTTPS 带来的延时。
• 会话缓存 虽然前文提到 HTTPS 即便采用会话缓存也要至少1*RTT的延时，可是至少延时已经减小为原来的一半，明显的延时优化;同时，基于会话缓存创建的 HTTPS 链接不须要服务器使用RSA私钥解密获取 Pre-master 信息，能够省去CPU 的消耗。若是业务访问链接集中，缓存命中率高，则HTTPS的接入能力讲明显提高。当前TRP平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际能够承载13k/的接入，收效很是可观。
• 硬件加速 为接入服务器安装专用的SSL硬件加速卡，做用相似 GPU，释放 CPU，可以具备更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡能够提供35k的解密能力，至关于175核 CPU，至少至关于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡能够实现接近10台服务器的接入能力。
• 远程解密 本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则能够充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器能够选择 CPU 负载较低的机器充当，实现机器资源复用，也能够是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。
• SPDY/HTTP2 前面的方法分别从减小传输延时和单机负载的方法提升 HTTPS 接入性能，可是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优点，经过修改协议的方法来提高 HTTPS 的性能，提升下载速度等。

Charles抓包HTTPS原理

Charles的抓包原理是假装成中间人，拦截服务器响应，用Charles制做的CA证书替换服务器证书发给客户端，再拦截客户端响应用以前拦截的服务器证书公钥从新加密发给服务器，让双方误觉得仍是在正常的验证通讯中。这一切发生的前提是客户端选择信任并安装Charles的CA证书，不然客户端校验不过CA证书就会报错并停止校验。 具体过程如图：

参考连接

HTTP 协议入门
HTTP 0.9 HTTP 1.0 HTTP 1.1 HTTP 2.0区别
HTTP 基础与变迁
5分钟让你明白HTTP协议
程序员都该懂点 HTTP
前端必备HTTP技能之HTTP请求头响应头中经常使用字段详解
解密HTTP/2与HTTP/3 的新特性
深刻理解HTTPS工做原理
也许，这样理解HTTPS更容易
HTTP与HTTPS的区别
HTTPS协议详解（五）：HTTPS性能与优化
扯一扯HTTPS单向认证、双向认证、抓包原理、反抓包策略