HTTP面试知识汇总（二）

HTTP 2.0

HTTP2 基于 SPDY，专注于性能，最大的一个目标是在用户和网站间只用一个连接。

特点

• 二进制分帧，HTTP2.0通过在应用层和传输层之间增加一个二进制分层帧，突破了HTTP1.1的性能限制，改进传输性能。
• 多路复用(链接共享) — 真并行传输

1. 流(stream)：已建立连接上的双向字节流；
   
2. 消息：与逻辑消息对应的完整的一系列数据帧；
   
3. 帧(frame)：HTTP2.0通信的最小单位，每个帧包含头部，至少也会标识出当前所属的流(stream_id)。
   **分帧有什么好处？**服务器单位时间接收到的请求数变多，可以提高并发数。最重要的是，为多路复用提供了底层支持。
   

所有HTTP2.0通信都在一个TCP链接上完成，这个链接可以承载任意流量的双向数据流。 每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符(Stream_id)重新封装。

多路复用(连接共享)可能会导致关键字被阻塞，HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回客户端，数据流还可以依赖其他的子数据流。

可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量的HTTP请求。而这个强大的功能基于“二进制分帧”的特性。

• 头部压缩，在HTTP1.X中，头部元数据都是以纯文本的形式发送的，通常会给每个请求增加500-8000字节的负荷。比如cookie，默认情况下，浏览器会在每次请求的时候，把cookie附在header上面发给服务器。
  HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header_files表，既避免重复header的传输，又减少了需要传输的大小。
  高效的压缩算法可以很大的压缩header，减少发送包的数量从而降低延迟。
• 服务器推送，服务器除了最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确的需求。

一个域名对应一个连接，一个流代表了一个完整的请求-响应过程。帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。多路复用，就是在一个 TCP 连接中可以存在多个流。

HTTP2 的缺陷

1. TCP 以及 TCP+TLS 建立连接的延时
   建连延时
   TCP 连接需要和服务器进行三次握手，即消耗完 1.5 个 RTT 之后才能进行数据传输。
   TLS 连接有两个版本—— TLS1.2 和 TLS1.3，每个版本建立连接所花的时间不同，大致需要 1~2 个 RTT。
   RTT（Round-Trip Time）: 往返时延。表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。
   
2. TCP 的队头阻塞并没有彻底解决
   TCP 为了保证可靠传输，有一个“超时重传”机制，丢失的包必须等待重传确认。HTTP2 出现丢包时，整个 TCP 都要等待重传，那么就会阻塞该 TCP 连接中的所有请求。
   
   RTO：英文全称是 Retransmission TimeOut，即重传超时时间； RTO 是一个动态值，会根据网络的改变而改变。RTO 是根据给定连接的往返时间 RTT 计算出来的。 接收方返回的 ack 是希望收到的下一组包的序列号。
   
3. 多路复用导致服务器压力上升
   多路复用没有限制同时请求数。请求的平均数量与往常相同，但实际会有许多请求的短暂爆发，导致瞬时 QPS 暴增。
   
4. 多路复用容易 Timeout
   大批量的请求同时发送，由于 HTTP2 连接内存在多个并行的流，而网络带宽和服务器资源有限，每个流的资源会被稀释，虽然它们开始时间相差更短，但却都可能超时。
   即使是使用 Nginx 这样的负载均衡器，想正确进行节流也可能很棘手。 其次，就算你向应用程序引入或调整排队机制，但一次能处理的连接也是有限的。如果对请求进行排队，还要注意在响应超时后丢弃请求，以避免浪费不必要的资源。
   

HTTP 3.0

主要特点：

1. 改进的拥塞控制、可靠传输
   从拥塞算法和可靠传输本身来看，QUIC 只是按照 TCP 协议重新实现了一遍，那么 QUIC 协议到底改进在哪些方面呢？主要有如下几点：
   1. 可插拔 — 应用程序层面就能实现不同的拥塞控制算法。
   一个应用程序的不同连接也能支持配置不同的拥塞控制。 应用程序不需要停机和升级就能实现拥塞控制的变更，可以针对不同业务，不同网络制式，甚至不同的 RTT，使用不同的拥塞控制算法。
   关于应用层的可插拔拥塞控制模拟，可以对 socket 上的流为对象进行实验。
   2. 单调递增的 Packet Number — 使用 Packet Number 代替了 TCP 的 seq。
   每个 Packet Number 都严格递增，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。而 TCP 重传策略存在二义性，比如客户端发送了一个请求，一个 RTO 后发起重传，而实际上服务器收到了第一次请求，并且响应已经在路上了，当客户端收到响应后，得出的 RTT 将会比真实 RTT 要小。当 Packet N 唯一之后，就可以计算出正确的 RTT。
   3. 不允许 Reneging — 一个 Packet 只要被 Ack，就认为它一定被正确接收。
   Reneging 的意思是，接收方有权把已经报给发送端 SACK（Selective Acknowledgment） 里的数据给丢了（如接收窗口不够而丢弃乱序的包）。
   QUIC 中的 ACK 包含了与 TCP 中 SACK 等价的信息，但 QUIC 不允许任何（包括被确认接受的）数据包被丢弃。这样不仅可以简化发送端与接收端的实现难度，还可以减少发送端的内存压力。
   4. 前向纠错（FEC）
   早期的 QUIC 版本存在一个丢包恢复机制，但后来由于增加带宽消耗和效果一般而废弃。FEC 中，QUIC 数据帧的数据混合原始数据和冗余数据，来确保无论到达接收端的 n 次传输内容是什么，接收端都能够恢复所有 n 个原始数据包。FEC 的实质就是异或。示意图：
   
   5. 更多的 Ack 块和增加 Ack Delay 时间。
   QUIC 可以同时提供 256 个 Ack Block，因此在重排序时，QUIC 相对于 TCP（使用 SACK）更有弹性，这也使得在重排序或丢失出现时，QUIC 可以在网络上保留更多的在途字节。在丢包率比较高的网络下，可以提升网络的恢复速度，减少重传量。
   TCP 的 Timestamp 选项存在一个问题：发送方在发送报文时设置发送时间戳，接收方在确认该报文段时把时间戳字段值复制到确认报文时间戳，但是没有计算接收端接收到包到发送 Ack 的时间。这个时间可以简称为 Ack Delay，会导致 RTT 计算误差。现在就是把这个东西加进去计算 RTT 了。
   6. 基于 stream 和 connection 级别的流量控制。
   为什么需要两类流量控制呢？主要是因为 QUIC 支持多路复用。 Stream 可以认为就是一条 HTTP 请求。 Connection 可以类比一条 TCP 连接。多路复用意味着在一条 Connetion 上会同时存在多条 Stream。
   QUIC 接收者会通告每个流中最多想要接收到的数据的绝对字节偏移。随着数据在特定流中的发送，接收和传送，接收者发送 WINDOW_UPDATE 帧，该帧增加该流的通告偏移量限制，允许对端在该流上发送更多的数据。
   除了每个流的流控制外，QUIC 还实现连接级的流控制，以限制 QUIC 接收者愿意为连接分配的总缓冲区。连接的流控制工作方式与流的流控制一样，但传送的字节和最大的接收偏移是所有流的总和。
   最重要的是，我们可以在内存不足或者上游处理性能出现问题时，通过流量控制来限制传输速率，保障服务可用性。
   
   
2. 快速握手
   由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现 0-RTT 或者 1-RTT 来建立连接，可以大大提升首次打开页面的速度。
   
3. 集成了 TLS 1.3 加密
   TLS 1.3 支持 3 种基本密钥交换模式：

(EC)DHE (基于有限域或椭圆曲线的 Diffie-Hellman)
PSK - only
PSK with (EC)DHE

1. 在完全握手情况下，需要 1-RTT 建立连接。 TLS1.3 恢复会话可以直接发送加密后的应用数据，不需要额外的 TLS 握手，也就是 0-RTT。
   TLS 1.3 0-RTT 简单原理示意（基于 DHE）：
   
   但是 TLS1.3 也并不完美。TLS 1.3 的 0-RTT 无法保证前向安全性(Forward secrecy)。简单讲就是，如果当攻击者通过某种手段获取到了 Session Ticket Key，那么该攻击者可以解密以前的加密数据。
   要缓解该问题可以通过设置使得与 Session Ticket Key 相关的 DH 静态参数在短时间内过期（一般几个小时）。
2. 多路复用
   QUIC 是为多路复用从头设计的，携带个别流的的数据的包丢失时，通常只影响该流。QUIC 连接上的多个 stream 之间并没有依赖，也不会有底层协议限制。假如 stream2 丢了一个包，也只会影响 stream2 的处理。
   
3. 连接迁移
   TCP 是按照 4 要素（客户端 IP、端口, 服务器 IP、端口）确定一个连接的。而 QUIC 则是让客户端生成一个 Connection ID （64 位）来区别不同连接。只要 Connection ID 不变，连接就不需要重新建立，即便是客户端的网络发生变化。由于迁移客户端继续使用相同的会话密钥来加密和解密数据包，QUIC 还提供了迁移客户端的自动加密验证。
   

基于Google的QUIC，HTTP3 背后的主要思想是放弃 TCP，转而使用基于 UDP 的 QUIC 协议。

与 HTTP2 在技术上允许未加密的通信不同，QUIC 严格要求加密后才能建立连接。此外，加密不仅适用于 HTTP 负载，还适用于流经连接的所有数据，从而避免了一大堆安全问题。建立持久连接、协商加密协议，甚至发送第一批数据都被合并到 QUIC 中的单个请求/响应周期中，从而大大减少了连接等待时间。如果客户端具有本地缓存的密码参数，则可以通过简化的握手（0-RTT）重新建立与已知主机的连接。

为了解决传输级别的线头阻塞问题，通过 QUIC 连接传输的数据被分为一些流。流是持久性 QUIC 连接中短暂、独立的“子连接”。每个流都处理自己的错误纠正和传递保证，但使用连接全局压缩和加密属性。每个客户端发起的 HTTP 请求都在单独的流上运行，因此丢失数据包不会影响其他流/请求的数据传输。

0-RTT — QUIC协议相比HTTP2.0的最大优势

缓存当前会话的上下文，下次恢复会话的时候，只需要将之前的缓存传递给服务器，验证通过，就可以进行传输了。

0-RTT建连可以说是QUIC相比HTTP2最大的性能优势。

什么是0-RTT建连?

• 传输层0-RTT就能建立连接
• 加密层0-RTT就能建立加密连接

为什么要有HTTP3.0：HTTP/2底层TCP的局限带来的问题

由于HTTP/2使用了多路复用，一般来说，同一个域名下只需要使用一个TCP链接，但当这个连接中出现了丢包的情况，就会导致HTTP/2的表现情况反倒不如HTTP/2了。

原因是： 在出现丢包的额情况下，整个TCP都要开始等待重传，导致后面的所有数据都被阻塞。

但是对于HTTP/1.1来说，可以开启多个TCP连接，出现这种情况只会影响其中一个连接，剩余的TCP链接还可以正常传输数据。

总结

HTTP 1.0

• 无状态，无连接；
• 短连接：每次发送请求都要重新建立tcp请求，即三次握手，非常浪费性能；
• 无host头域，也就是http请求头里的host；
• 不允许断点续传，而且不能只传输对象的一部分，要求传输整个对象。

HTTP 1.1

• 长连接，流水线，使用connection:keep-alive使用长连接；
• 请求管道化；
• 增加缓存处理(新的字段如cache-control)；
• 增加Host字段，支持断点传输等；
• 由于长连接会给服务器造成压力。

HTTP 2.0

• 二进制分帧；
• 多路复用(或连接共享)，使用多个stream，每个stream又分帧传输，使得一个tcp连接能够处理多个http请求；
• 头部压缩，双方各自维护一个header的索引表，使得不需要直接发送值，通过发送key缩减头部大小；
• 服务器推送(Sever push)。

HTTP 3.0

• 基于google的QUIC协议，而quic协议是使用udp实现的；
• 减少了tcp三次握手时间，以及tls握手时间；
• 解决了http 2.0中前一个stream丢包导致后一个stream被阻塞的问题；
• 优化了重传策略，重传包和原包的编号不同，降低后续重传计算的消耗；
• 连接迁移，不再用tcp四元组确定一个连接，而是用一个64位随机数来确定这个连接；
• 更合适的流量控制。

历代 HTTP 速度测试

参考链接：

http://events.jianshu.io/p/cd70b8e90d00

https://zhuanlan.zhihu.com/p/102561034

HTTP的缺点

HTTP虽然使用极为广泛, 但是却存在不小的安全缺陷, 主要是其数据的明文传送和消息完整性检测的缺乏, 而这两点恰好是网络支付, 网络交易等新兴应用中安全方面最需要关注的 [3] 。

关于 HTTP的明文数据传输, 攻击者最常用的攻击手法就是网络嗅探, 试图从传输过程当中分析出敏感的数据, 例如管理员对 Web 程序后台的登录过程等等, 从而获取网站管理权限, 进而渗透到整个服务器的权限。即使无法获取到后台登录信息, 攻击者也可以从网络中获取普通用户的隐秘信息, 包括手机号码, 身份证号码, 信用卡号等重要资料, 导致严重的安全事故。进行网络嗅探攻击非常简单, 对攻击者的要求很低。使用网络发布的任意一款抓包工具, 一个新手就有可能获取到大型网站的用户信息 [3] 。

另外,HTTP在传输客户端请求和服务端响应时, 唯一的数据完整性检验就是在报文头部包含了本次传输数据的长度, 而对内容是否被篡改不作确认。 因此攻击者可以轻易的发动中间人攻击, 修改客户端和服务端传输的数据, 甚至在传输数据中插入恶意代码, 导致客户端被引导至恶意网站被植入木马 [3] 。

二、HTTPS

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。 HTTPS 存在不同于 HTTP 的默认端口及一个加密/身份验证层（在 HTTP与 TCP 之间）。这个系统提供了身份验证与加密通讯方法。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面 。

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

相较于HTTP的改进：

HTTPS 协议是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。设计目标主要有三个。

（1）数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么 。

（2）数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收 。

（3）身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方 。

三、HTTPS与HTTP原理区别

HTTPS 主要由两部分组成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过 TLS 进行加密，所以传输的数据都是加密后的数据。

HTTP 原理

① 客户端的浏览器首先要通过网络与服务器建立连接，该连接是通过TCP 来完成的，一般 TCP 连接的端口号是80。 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和许可内容 。

② 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容 。

具体的可以看前文总结的HTTP请求报文、HTTP响应报文格式。

HTTPS 原理

① 客户端将它所支持的算法列表和一个用作产生密钥的随机数发送给服务器 ；

② 服务器从算法列表中选择一种加密算法，并将它和一份包含服务器公用密钥的证书发送给客户端；该证书还包含了用于认证目的的服务器标识，服务器同时还提供了一个用作产生密钥的随机数 [2] ；

③ 客户端对服务器的证书进行验证（有关验证证书，可以参考数字签名），并抽取服务器的公用密钥；然后，再产生一个称作 pre_master_secret 的随机密码串，并使用服务器的公用密钥对其进行加密（参考非对称加 / 解密），并将加密后的信息发送给服务器 ；

④ 客户端与服务器端根据 pre_master_secret 以及客户端与服务器的随机数值独立计算出加密和 MAC密钥（参考 DH密钥交换算法） ；

⑤ 客户端将所有握手消息的 MAC 值发送给服务器 ；

⑥ 服务器将所有握手消息的 MAC 值发送给客户端 。

优缺点：

优点

1. 使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器 ；
2. HTTPS 协议是由 SSL+HTTP构建的可进行加密传输、身份认证的网络协议，要比 HTTP安全，可防止数据在传输过程中被窃取、改变，确保数据的完整性 。
3. HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本 。

缺点

1. 相同网络环境下，HTTPS 协议会使页面的加载时间延长近 50%，增加 10%到 20%的耗电。此外，HTTPS 协议还会影响缓存，增加数据开销和功耗 。
2. HTTPS 协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用 。
3. 最关键的是，SSL 证书的信用链体系并不安全。特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行 。
4. 成本增加。部署 HTTPS 后，因为 HTTPS 协议的工作要增加额外的计算资源消耗，例如 SSL 协议加密算法和 SSL 交互次数将占用一定的计算资源和服务器成本。在大规模用户访问应用的场景下，服务器需要频繁地做加密和解密操作，几乎每一个字节都需要做加解密，这就产生了服务器成本。随着云计算技术的发展，数据中心部署的服务器使用成本在规模增加后逐步下降，相对于用户访问的安全提升，其投入成本已经下降到可接受程度 。

参考：https://baike.baidu.com/item/HTTPS/285356?fr=aladdin

四、中间人攻击

中间人攻击(Man-in-the-MiddleAttack，简称“MITM攻击”)是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方 直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。中间人攻击是一个(缺乏)相互认证的攻击。大多数的加密协议都专门加入了一些特殊的认证方法以阻止中间人攻击。例如，SSL协议可以验证参与通讯的一方或双方使用的证书是否是由权威的受信 任的数字证书认证机构颁发，并且能执行双向身份认证。

中间人攻击过程：

1. 客户端发送请求到服务端，请求被中间人截获。
   
2. 服务器向客户端发送公钥。
   
3. 中间人截获公钥，保留在自己手上。然后自己生成一个伪造的公钥，发给客户端。
   
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器。
   
5. 中间人获得加密hash值，用自己的私钥解密获得真秘钥。同时生成假的加密hash值，发给服务器。
   
6. 服务器用私钥解密获得假密钥。然后加密数据传输给客户端。
   

中间人攻击的几种攻击方式，一般说来，中间人攻击的方式有嗅探、数据包注入、会话劫持和SSL剥离。

1. 嗅探：嗅探或数据包嗅探 是一种用于捕获流进和流出系统/网络的数据包的技术。网络中的数据包嗅探就好像电话中的监听。
   
2. 数据包注入：在这种技术中，攻击者会将恶意数据包注入常规数据中。这样用户便不会注意到文件/恶意软件，因为它们是合法通讯流的一部分。在中间人攻击和拒绝式攻击中，这些文件是很常见的。
   
3. 会话劫持：当客户端和服务器端在进行一个会话时，会话中包含了很多重要信息，一些黑客会潜伏在这个会话中，最终控制这个会话，这既是 会话劫持。
   
4. SSL剥离：SSL/TLS证书通过加密保护着我们的通讯安全。在SSL剥离攻击中，攻击者使SSL/TLS连接剥落，随之协议便从安全的HTTPS变成了不安全的HTTP。
   

如何避免中间人攻击呢？

• 暂时未知，后续知道了，补充到这里，或者有知道的欢迎评论区告诉我。