HTTP

一、HTTP定义

HTTP定义：HTTP 是超文本传输协议，也就是 HyperText Transfer Protocol。HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。PS：HTTP 不止是从互联网服务器传输超文本到本地浏览器的协议，还是服务器到服务器之间的传输协议。

HTTP解析

HTTP是构建于TCP/IP协议之上，是应用层协议，默认端口号80
HTTP协议是无连接无状态的

HTTP请求报文格式：

HTTP响应报文格式：

请求行

请求行是由请求方法、url字段以及HTTP协议版本字段三个部分组成，它们用空格分开。

HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
而常见的有如下几种：

1.1 GET

当客户端要从服务器读取数据时，点击网页上的链接，或者通过在浏览器的地址栏输入网址来浏览网页的，使用的都是GET方式。GET的方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET的方法，请求参数和对应的值附加在URL后面，利用问号（？），代表URL的结尾和请求参数的开始，传递的参数长度受到限制。例如，www.baidu.com/index.html?id=1&password=123,这样通过GET的方式传递的数据直接显示在地址上，所以我们可以将请求以链接的方式发送给接收方。可以看到GET的请求一般不包含“请求内容”的部分，请求数据以地址的形式表现在请求行中，地址？？？之后的部分就是通过GET发送的数据，我们可以在地址栏中看到各种数据之间用 & 符号隔开。

但是这种方式显然不能传递私密的数据
另外不同浏览器对地址的字符长度限制有不同的数据，一般最多不超过1024个字符，所以大量的数据传输，不适合使用GET方式。

1.2 POST

对于以上适合使用GET方式的情况下，可以使用POST方式，因为使用POST的方法允许客户端给服务端提供较多的信息。POST将请求参数封装在HTTP的请求数据中，可以大量的传递数据，理论上对数据得大小的没有限制，但实际各个WEB服务器会规定对post提交数据大小进行限制。而且可以不显示在URL中。下图是用wireshark抓的一个POST请求的报文，红色为请求报文，蓝色为响应报文。可以看到POST方式的请求行中不包括字符串数据，这些内容保存在“请求内容”部分，各个数据之间也是以 & 符号隔开。

请求头	含义
User-Agent	产生请求的浏览器类型，User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器
Accept	客户端可识别的响应内容类型列表。eg：Accept：image/gif，表明客户端希望接受GIF图象格式的资源；Accept：text/html，表明客户端希望接受html文本。
Accept-Language	客户端可接受的自然语言
Accept-chartset	客户端可接受应答的字符集。eg：Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。
Accept-Encoding	客户端可接受的编码压缩格式
HOST	请求的主机名称，允许多个域名同处一个IP之地，即虚拟主机
Connection	连接方式（close或keep-alive）
Cookie	存储于客户端扩展字段，向同一域名的服务端发送该域的cookie
Authorization	Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（

1.3 GET 和 POST 基本区别

GET产生一个TCP数据包；POST产生两个TCP数据包。

对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST没有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。

参考： https://www.cnblogs.com/logsharing/p/8448446.html

HTTP 状态码

http各个状态码的含义：由三位数字组成，第一位定义了状态码的类型

2开头：（请求成功）表示成功处理了请求的状态代码

200：（成功）服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。
201：（已创建）请求成功并且服务器创建了新的资源
202：（已接受）服务器已接受请求，但尚未处理
203：（非授权信息）服务器已成功处理了请求，但返回的信息可能来自另一资源。
204：（无内容）服务器成功处理了请求，但没有返回任何内容
205：（重置内容）服务器成功处理了请求，但没有返回任何内容
206：（部分内容）服务器成功处理了部分 GET 请求

3开头：（请求被重定向）表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向

300：（多种选择）针对请求，服务器可执行多种操作。服务器可根据请求者（user agent）选择一项操作，或提供操作列表供请求者选择
301：（永久移动）请求的网页已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新的位置
302：（临时移动）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
303：（查看其他位置）请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码
304：（未修改）自从上次请求后，请求的网页未修改过。服务器返回此响应，不会返回网页内容
305：（使用代理）请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理
307：（临时重定向）服务器目前从不同位置的网页响应请求，但请求者继续使用原有位置来进行以后的请求

4开头：（请求错误）这些状态码表示请求可能出错，妨碍了服务器的处理

400：（错误请求）服务器不理解请求的语法
401：（未授权）请求要求身份验证。对于需要登录的网页，服务器可能返回此响应
403：（禁止）服务器拒绝请求
404：（未找到）服务器找不到请求的网页
405：（方法禁用）禁用请求中指定的方法
406：（不接受）无法使用请求的内容特性响应请求的网页
407：（需要代理授权）此状态代码与 401 （未授权）类似，但指定请求者应当授权使用代理
408：（请求超时）服务器等候请求时发生超时
409：（冲突）服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息
410：（已删除）如果请求的资源已永久删除，服务器就会返回此响应
411：（需要有效长度）服务器不接受不含有效内容长度标头字段的请求
412：（未满足前提条件）服务器未满足请求者在请求中设置的其中一个前提条件
413：（请求实体过大）服务器无法处理请求，因为请求实体过大，超出服务器的处理能力
414：（请求的 URI 过长）请求的URI（通常为网址）过长，服务器无法处理
415：（不支持的媒体类型）请求的格式不受请求页面的支持
416：（请求范围不符合）如果页面无法提供请求的范围，则服务器返回此状态代码
417：（未满足期望值）服务器未满足“期望”请求标头字段要求

5开头：（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。

500：（服务器内部错误）服务器遇到错误，无法完成请求
501：（尚未实施）服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码
502：（错误网关）服务器作为网关或代理，从上游服务器收到无效响应
503：（服务不可用）服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态
504：（网关超时）服务器作为网关或代理，但是没有及时从上游服务器收到请求
505：（HTTP 版本不受支持）服务器不支持请求中所用的 HTTP 协议版本

参考：https://www.cnblogs.com/maigy/p/11480011.html

HTTP特性

优点是「简单、灵活和易于扩展、应用广泛和跨平台」。

简单：HTTP 基本的报文格式就是 header + body ，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。
灵活和易于扩展：HTTP 协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层， HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC。
应用广泛和跨平台：互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，同时天然具有跨平台的优越性。 HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

无状态：
- 无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
- 无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。这样每操作一次，都要验证信息，这种体验对用户来说很不友好。对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了。
明文传输：
- 不安全
- 方便阅读

HTTP不同版本的特点

HTTP 1.0

HTTP1.0 的缺陷

高延迟 — 队头阻塞(Head-Of-Line Blocking)
无状态特性 — 阻碍交互
明文传输 — 不安全性
不支持服务端推送

1.0版本的HTTP，是一种无状态，无连接的应用层协议。HTTP1.0规定浏览器和服务器保持短暂的链接。

浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接(无连接)，服务器不跟踪也每个客户单，也不记录过去的请求(无状态)。这种无状态性可以借助cookie/session机制来做身份认证和状态记录。

存在的问题

（1）队头阻塞

队头阻塞：队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。

（2）无状态连接

（3）不安全性

无法复用连接，每次发送请求，都需要进行一次TCP连接，而TCP的连接释放过程又是比较费事的。这种无连接的特性会使得网络的利用率变低。
队头阻塞(head of line blocking)，由于HTTP1.0规定下一个请求必须在前一个请求响应到达之前才能发送，假设前一个请求响应一直不到达，那么下一个请求就不发送，后面的请求就阻塞了。
不支持断点续传，也就是说，每次都会传送全部的页面和数据。

HTTP 1.1

HTTP1.1继承了HTTP1.0的简单，克服了HTTP1.0性能上的问题。

针对队头阻塞：

将同一页面的资源分散到不同域名下，提升连接上限。虽然能公用一个 TCP 管道，但是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。
减少请求数量
内联一些资源：css、base64图片等
合并小文件减少资源数

无状态特性：无状态是指协议对于连接状态没有记忆能力。纯净的 HTTP 是没有 cookie 等机制的，每一个连接都是一个新的连接。上一次请求验证了用户名密码，而下一次请求服务器并不知道它与上一条请求有何关联，换句话说就是掉登录态。
不安全性：传输内容没有加密，中途可能被篡改和劫持。

（4）SPDY协议

SPDY 是由 google 推行的改进版本的 HTTP1.1 （那时候还没有 HTTP2）。

特点：

多路复用 — 解决队头阻塞

SPDY 允许在一个连接上无限制并发流。因为请求在一个通道上，TCP 效率更高（参考 TCP 拥塞控制中的慢启动）。更少的网络连接，发出更密集的包。
头部压缩 — 解决巨大的 HTTP 头部

使用专门的 HPACK 算法，每次请求和响应只发送差异头部，一般可以达到 50%~90% 的高压缩率。
请求优先级 — 先获取重要数据

虽然无限的并发流解决了队头阻塞的问题，但如果带宽受限，客户端可能会因防止堵塞通道而阻止请求。在网络通道被非关键资源堵塞时，高优先级的请求会被优先处理。
服务端推送 — 填补空缺

服务端推送（ServerPush），可以让服务端主动把资源文件推送给客户端。当然客户端也有权利选择是否接收。
提高安全性

支持使用 HTTPS 进行加密传输。

特点

长连接，HTTP1.1增加Connection字段，对于同一个host，通过设置Keep-Alive保持HTTP连接不断。避免每次客户端与服务器请求都要重复建立释放建立TCP连接。提高了网络的利用率。如果客户端想关闭HTTP连接，可以在请求头中携带Connection:false来告知服务器关闭请求。
支持断点续传，通过使用请求头中的 Range 来实现。
可以使用管道传输，多个请求可以同时发送，但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为「队头堵塞」。

HTTP 2.0

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

特点

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

流(stream)：已建立连接上的双向字节流；
消息：与逻辑消息对应的完整的一系列数据帧；
帧(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 的缺陷

TCP 以及 TCP+TLS 建立连接的延时

建连延时

TCP 连接需要和服务器进行三次握手，即消耗完 1.5 个 RTT 之后才能进行数据传输。

TLS 连接有两个版本—— TLS1.2 和 TLS1.3，每个版本建立连接所花的时间不同，大致需要 1~2 个 RTT。

RTT（Round-Trip Time）: 往返时延。表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。
TCP 的队头阻塞并没有彻底解决

TCP 为了保证可靠传输，有一个“超时重传”机制，丢失的包必须等待重传确认。HTTP2 出现丢包时，整个 TCP 都要等待重传，那么就会阻塞该 TCP 连接中的所有请求。

RTO：英文全称是 Retransmission TimeOut，即重传超时时间； RTO 是一个动态值，会根据网络的改变而改变。RTO 是根据给定连接的往返时间 RTT 计算出来的。接收方返回的 ack 是希望收到的下一组包的序列号。
多路复用导致服务器压力上升

多路复用没有限制同时请求数。请求的平均数量与往常相同，但实际会有许多请求的短暂爆发，导致瞬时 QPS 暴增。
多路复用容易 Timeout

大批量的请求同时发送，由于 HTTP2 连接内存在多个并行的流，而网络带宽和服务器资源有限，每个流的资源会被稀释，虽然它们开始时间相差更短，但却都可能超时。

即使是使用 Nginx 这样的负载均衡器，想正确进行节流也可能很棘手。其次，就算你向应用程序引入或调整排队机制，但一次能处理的连接也是有限的。如果对请求进行排队，还要注意在响应超时后丢弃请求，以避免浪费不必要的资源。

HTTP 3.0

主要特点：

改进的拥塞控制、可靠传输

从拥塞算法和可靠传输本身来看，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 接收者愿意为连接分配的总缓冲区。连接的流控制工作方式与流的流控制一样，但传送的字节和最大的接收偏移是所有流的总和。

最重要的是，我们可以在内存不足或者上游处理性能出现问题时，通过流量控制来限制传输速率，保障服务可用性。
快速握手

由于 QUIC 是基于 UDP 的，所以 QUIC 可以实现 0-RTT 或者 1-RTT 来建立连接，可以大大提升首次打开页面的速度。
集成了 TLS 1.3 加密

TLS 1.3 支持 3 种基本密钥交换模式：
```
(EC)DHE (基于有限域或椭圆曲线的 Diffie-Hellman)
PSK - only
PSK with (EC)DHE
```
在完全握手情况下，需要 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 静态参数在短时间内过期（一般几个小时）。
多路复用

QUIC 是为多路复用从头设计的，携带个别流的的数据的包丢失时，通常只影响该流。QUIC 连接上的多个 stream 之间并没有依赖，也不会有底层协议限制。假如 stream2 丢了一个包，也只会影响 stream2 的处理。
连接迁移

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链接还可以正常传输数据。

总结