HTTP 基本概念

• HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

  • 超文本: 文字、图片、视频等的混合体.最关键有超链接，能从一个超文本跳转到另外一个超文本。
  • 传输: HTTP 协议是一个双向协议.

• 特点:

  • HTTP 是无连接：无连接的含义是限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接，采用这种方式可以节省传输时间。
  • HTTP 是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送，客户端以及服务器指定使用适合的 MIME-type 内容类型。
  • HTTP 是无状态：HTTP 协议是无状态协议，无状态是指协议对于事务处理没有记忆能力，缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大，另一方面，在服务器不需要先前信息时它的应答就较快。

• 常见状态码

  分类	分类描述
  1**	信息，服务器收到请求，需要请求者继续执行操作
  2**	成功，操作被成功接收并处理
  3**	重定向，需要进一步的操作以完成请求
  4**	客户端错误，请求包含语法错误或无法完成请求
  5**	服务器错误，服务器在处理请求的过程中发生了错误

  状态码	状态码英文名称	中文描述
  100	Continue	继续。客户端应继续其请求
  101	Switching Protocols	切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
  200	OK	请求成功。一般用于GET与POST请求
  201	Created	已创建。成功请求并创建了新的资源
  202	Accepted	已接受。已经接受请求，但未处理完成
  203	Non-Authoritative Information	非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
  204	No Content	无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
  205	Reset Content	重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
  206	Partial Content	部分内容。服务器成功处理了部分GET请求
  300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
  301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
  302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
  303	See Other	查看其它地址。与301类似。使用GET和POST请求查看
  304	Not Modified	未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
  305	Use Proxy	使用代理。所请求的资源必须通过代理访问
  306	Unused	已经被废弃的HTTP状态码
  307	Temporary Redirect	临时重定向。与302类似。使用GET请求重定向
  400	Bad Request	客户端请求的语法错误，服务器无法理解
  401	Unauthorized	请求要求用户的身份认证
  402	Payment Required	保留，将来使用
  403	Forbidden	服务器理解请求客户端的请求，但是拒绝执行此请求
  404	Not Found	服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
  405	Method Not Allowed	客户端请求中的方法被禁止
  406	Not Acceptable	服务器无法根据客户端请求的内容特性完成请求
  407	Proxy Authentication Required	请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
  408	Request Time-out	服务器等待客户端发送的请求时间过长，超时
  409	Conflict	服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突
  410	Gone	客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
  411	Length Required	服务器无法处理客户端发送的不带Content-Length的请求信息
  412	Precondition Failed	客户端请求信息的先决条件错误
  413	Request Entity Too Large	由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
  414	Request-URI Too Large	请求的URI过长（URI通常为网址），服务器无法处理
  415	Unsupported Media Type	服务器无法处理请求附带的媒体格式
  416	Requested range not satisfiable	客户端请求的范围无效
  417	Expectation Failed	服务器无法满足Expect的请求头信息
  500	Internal Server Error	服务器内部错误，无法完成请求
  501	Not Implemented	服务器不支持请求的功能，无法完成请求
  502	Bad Gateway	作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
  503	Service Unavailable	由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
  504	Gateway Time-out	充当网关或代理的服务器，未及时从远端服务器获取请求
  505	HTTP Version not supported	服务器不支持请求的HTTP协议的版本，无法完成处理

URL

• 超文本传输协议（HTTP）的统一资源定位符将从因特网获取信息的五个基本元素包括在一个简单的地址中：
  • 传送协议。
  • 层级URL标记符号(为[//],固定不变)
  • 访问资源需要的凭证信息（可省略）
  • 服务器。（通常为域名，有时为IP地址）
  • 端口号。（以数字方式表示，若为HTTP的默认值“:80”,https默认端口(443)可省略）
  • 路径。（以“/”字符区别路径中的每一个目录名称）
  • 查询。（GET模式的窗体参数，以“?”字符为起点，每个参数以“&”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题）
  • 片段.锚点。以“#”字符为起点

HTTP 请求与响应格式

• http请求格式(request请求,浏览器给服务器发送的消息)

  • get请求没有请求数据

  

• http响应格式(response 响应,服务器返回给浏览器的信息)

  

常见请求头

协议头	说明	示例	状态
Accept	可接受的响应内容类型（Content-Types）。	Accept: text/plain	固定
Accept-Charset	可接受的字符集	Accept-Charset: utf-8	固定
Accept-Encoding	可接受的响应内容的编码方式。	Accept-Encoding: gzip, deflate	固定
Accept-Language	可接受的响应内容语言列表。	Accept-Language: en-US	固定
Accept-Datetime	可接受的按照时间来表示的响应内容版本	Accept-Datetime: Sat, 26 Dec 2015 17:30:00 GMT	临时
Authorization	用于表示HTTP协议中需要认证资源的认证信息	Authorization: Basic OSdjJGRpbjpvcGVuIANlc2SdDE==	固定
Cache-Control	用来指定当前的请求/回复中的，是否使用缓存机制。	Cache-Control: no-cache	固定
Connection	客户端（浏览器）想要优先使用的连接类型	Connection: keep-alive``Connection: Upgrade	固定
Cookie	由之前服务器通过Set-Cookie（见下文）设置的一个HTTP协议Cookie	Cookie: $Version=1; Skin=new;	固定：标准
Content-Length	以8进制表示的请求体的长度	Content-Length: 348	固定
Content-MD5	请求体的内容的二进制 MD5 散列值（数字签名），以 Base64 编码的结果	Content-MD5: oD8dH2sgSW50ZWdyaIEd9D==	废弃
Content-Type	请求体的MIME类型 （用于POST和PUT请求中）	Content-Type: application/x-www-form-urlencoded	固定
Date	发送该消息的日期和时间（以RFC 7231 (opens new window)中定义的"HTTP日期"格式来发送）	Date: Dec, 26 Dec 2015 17:30:00 GMT	固定
Expect	表示客户端要求服务器做出特定的行为	Expect: 100-continue	固定
From	发起此请求的用户的邮件地址	From: user@itbilu.com	固定
Host	表示服务器的域名以及服务器所监听的端口号。如果所请求的端口是对应的服务的标准端口（80），则端口号可以省略。	Host: www.itbilu.com:80``Host: www.itbilu.com	固定
If-Match	仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要用于像 PUT 这样的方法中，仅当从用户上次更新某个资源后，该资源未被修改的情况下，才更新该资源。	If-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd"	固定
If-Modified-Since	允许在对应的资源未被修改的情况下返回304未修改	If-Modified-Since: Dec, 26 Dec 2015 17:30:00 GMT	固定
If-None-Match	允许在对应的内容未被修改的情况下返回304未修改（ 304 Not Modified ），参考 超文本传输协议 的实体标记	If-None-Match: "9jd00cdj34pss9ejqiw39d82f20d0ikd"	固定
If-Range	如果该实体未被修改过，则向返回所缺少的那一个或多个部分。否则，返回整个新的实体	If-Range: "9jd00cdj34pss9ejqiw39d82f20d0ikd"	固定
If-Unmodified-Since	仅当该实体自某个特定时间以来未被修改的情况下，才发送回应。	If-Unmodified-Since: Dec, 26 Dec 2015 17:30:00 GMT	固定
Max-Forwards	限制该消息可被代理及网关转发的次数。	Max-Forwards: 10	固定
Origin	发起一个针对跨域资源共享 (opens new window)的请求（该请求要求服务器在响应中加入一个Access-Control-Allow-Origin的消息头，表示访问控制所允许的来源）。	Origin: http://www.itbilu.com	固定: 标准
Pragma	与具体的实现相关，这些字段可能在请求/回应链中的任何时候产生。	Pragma: no-cache	固定
Proxy-Authorization	用于向代理进行认证的认证信息。	Proxy-Authorization: Basic IOoDZRgDOi0vcGVuIHNlNidJi2==	固定
Range	表示请求某个实体的一部分，字节偏移以0开始。	Range: bytes=500-999	固定
Referer	表示浏览器所访问的前一个页面，可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer其实是Referrer这个单词，但RFC制作标准时给拼错了，后来也就将错就错使用Referer了。	Referer: http://itbilu.com/nodejs	固定
TE	浏览器预期接受的传输时的编码方式：可使用回应协议头Transfer-Encoding中的值（还可以使用"trailers"表示数据传输时的分块方式）用来表示浏览器希望在最后一个大小为0的块之后还接收到一些额外的字段。	TE: trailers,deflate	固定
User-Agent	浏览器的身份标识字符串	User-Agent: Mozilla/……	固定
Upgrade	要求服务器升级到一个高版本协议。	Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11	固定
Via	告诉服务器，这个请求是由哪些代理发出的。	Via: 1.0 fred, 1.1 itbilu.com.com (Apache/1.1)	固定
Warning	一个一般性的警告，表示在实体内容体中可能存在错误。	Warning: 199 Miscellaneous warning	固定

HTTPS

• HTTPS是以安全为目标的HTTP通道，简单将就是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL。其所用的端口是443

1. HTTPS 工作流程

1. 获取连接证书

   SSL客户端通过TCP和服务器建立连接后（443端口），并且在一般的TCP连接协商过程中请求证书。即客户端发出一个消息给服务器，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个数据包，这里面确定了这次通信所需要的算法，然后服务器向客户端返回证书。（证书里面包含了服务器信息：域名。申请证书的公司，公共密钥）

2. 证书验证

   客户端在收到服务器返回的证书后，判断签发这个证书的公共签发机构，并使用这个机构的公共密钥确认签名是否有效，客户端还会确保证书中列出的域名就是它正在连接的域名

3. 数据加密和传输:

   如果确认证书有效，那么生成对称密钥并使用服务器的公共密钥进行加密。然后发送给服务器，服务器使用它的密钥进行解密，这样两台计算机可以开始进行对称加密进行通信。

2. 证书机制

• 作为服务器端，首先先把自己的公钥给证书颁发机构，向证书颁发机构申请证书
• 证书颁发机构自己也有一堆公钥和私钥。机构利用自己的私钥来解密Key1，通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给服务端。
• 当客户端向服务端请求通信的时候，服务端不再直接返回自己的公钥，而是把自己申请的证书返回给客户端。
• 客户端收到证书以后，要做的第一件事就是验证证书的真伪，需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥，所以客户端只需要知道是哪个机构颁发的证书，就可以从本地找到对应的机构公钥，解密出证书签名。

3. 对称加密和非对称加密

• 对称加密就是客户端服务端都有密钥，客户端通过密钥加密的数据传输给服务器，服务端通过密钥解密加密数据，如此进行收发消息；
  • 对称加密算法: DES、3DES、AES、Blowfish、IDEA、RC5、RC6, base64
• 非对称加密就是服务端将公钥发送给客户端，客户端使用公钥加密对称密钥，然后将加密的对称密钥发给服务端，服务端通过私钥解密，获取对称密钥，然后客户端和服务端都有了对称密钥，就可以通过对称加密收发消息；
  • RSA, DSA, ECDSA

http 和 https 的区别

1. HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
2. HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
3. HTTP 的端口号是 80，HTTPS 的端口号是 443。
4. HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

http1.0 和 http1.1区别

• http1.0 不能创建长连接, http1.1 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
• http1.1增加了更多的缓存策略，比E-Tag、If-None-Match，http1.0使用的是last-modified、If-Modified-Since
• 双方都存在的问题
  1. 每一次传输数据都需要重新建立连接，延迟较多
  2. 传输均为明文，客户端和服务端均无法验证双方身份，存在一定的数据安全
  3. 请求的header部分内容较大，增加传输成本，且很多时候header部分是不变的
  4. 虽然http1.1有长连接的功能，但长连接使用过多也给服务端带来了更大的性能压力，特别是对于一些图片类视频类等资源型的服务器，如果长期保持长连接他是没必要的，但给服务器是大的性能浪费
  5. 请求只能从客户端开始，服务器只能被动响应。

http1.1 和 http2.0区别

• HTP/2采用二进制格式而非文本格式
• HTP/2使用一个连接可实现多路复用
• http2使用报头压缩，HTTP/2降低了开销
• HTP/2让服务器可以将响应主动“推送”到客户端缓存

http2.0 和 http3.0区别

1. HTTP/2的缺点

• HTTP/2 通过头部压缩、二进制编码、多路复用、服务器推送等新特性大幅度提升了 HTTP/1.1 的性能，而美中不足的是 HTTP/2 协议是基于 TCP 实现的，于是存在的缺陷有三个。

  • 队头阻塞；

  • TCP 与 TLS 的握手时延迟；

  • 网络迁移需要重新连接；

1.1 队头阻塞

• HTTP/2 多个请求是跑在一个 TCP 连接中的，那么当 TCP 丢包时，整个 TCP 都要等待重传，那么就会阻塞该 TCP 连接中的所有请求。

• 因为 TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且有序的，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是请求被阻塞了。

• 举个例子，如下图：

  

  • 图中发送方发送了很多个 packet，每个 packet 都有自己的序号，你可以认为是 TCP 的序列号，其中 packet 3 在网络中丢失了，即使 packet 4-6 被接收方收到后，由于内核中的 TCP 数据不是连续的，于是接收方的应用层就无法从内核中读取到，只有等到 packet 3 重传后，接收方的应用层才可以从内核中读取到数据，这就是 HTTP/2 的队头阻塞问题，是在 TCP 层面发生的。

1.2 TCP 与 TLS 的握手时延迟

• 发起 HTTP 请求时，需要经过 TCP 三次握手和 TLS 四次握手（TLS 1.2）的过程，因此共需要 3 个 RTT 的时延才能发出请求数据。

  

• 另外， TCP 由于具有「拥塞控制」的特性，所以刚建立连接的 TCP 会有个「慢启动」的过程，它会对 TCP 连接产生"减速"效果。

1.3 网络迁移需要重新连接

• 一个 TCP 连接是由四元组（源 IP 地址，源端口，目标 IP 地址，目标端口）确定的，这意味着如果 IP 地址或者端口变动了，就会导致需要 TCP 与 TLS 重新握手，这不利于移动设备切换网络的场景，比如 4G 网络环境切换成 WIFI。

• 这些问题都是 TCP 协议固有的问题，无论应用层的 HTTP/2 在怎么设计都无法逃脱。要解决这个问题，就必须把传输层协议替换成 UDP，这个大胆的决定，HTTP/3 做了！

  

2. QUIC 协议的特点

• UDP 是一个简单、不可靠的传输协议，而且是 UDP 包之间是无序的，也没有依赖关系。

• UDP 是不需要连接的，也就不需要握手和挥手的过程，所以天然的就比 TCP 快。

• HTTP/3 不仅仅只是简单将传输协议替换成了 UDP，还基于 UDP 协议在「应用层」实现了 QUIC 协议，它具有类似 TCP 的连接管理、拥塞窗口、流量控制的网络特性，相当于将不可靠传输的 UDP 协议变成“可靠”的了，所以不用担心数据包丢失的问题。

• QUIC 协议的优点有很多，比如：

  • 无队头阻塞；

  • 更快的连接建立；

  • 连接迁移；

2.1 无队头阻塞

• QUIC 协议也有类似 HTTP/2 Stream 与多路复用的概念，也是可以在同一条连接上并发传输多个 Stream，Stream 可以认为就是一条 HTTP 请求。

• 由于 QUIC 使用的传输协议是 UDP，UDP 不关心数据包的顺序，如果数据包丢失，UDP 也不关心。

• 不过 QUIC 协议会保证数据包的可靠性，每个数据包都有一个序号唯一标识。当某个流中的一个数据包丢失了，即使该流的其他数据包到达了，数据也无法被 HTTP/3 读取，直到 QUIC 重传丢失的报文，数据才会交给 HTTP/3。

• 而其他流的数据报文只要被完整接收，HTTP/3 就可以读取到数据。这与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。

• 所以，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。

  

2.2 更快的连接建立

• 对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、openssl 库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先 TCP 握手，再 TLS 握手。

• HTTP/3 在传输数据前虽然需要 QUIC 协议握手，这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。

• 但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。

• 如下图右边部分，HTTP/3 当会话恢复时，有效负载数据与第一个数据包一起发送，可以做到 0-RTT：

  

2.3 连接迁移

• 基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接，那么当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接，而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延，以及 TCP 慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。

• 而 QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

3. HTTP/3 协议

• HTTP/3 同 HTTP/2 一样采用二进制帧的结构，不同的地方在于 HTTP/2 的二进制帧里需要定义 Stream，而 HTTP/3 自身不需要再定义 Stream，直接使用 QUIC 里的 Stream，于是 HTTP/3 的帧的结构也变简单了。

  

• 从上图可以看到，HTTP/3 帧头只有两个字段：类型和长度。

• 根据帧类型的不同，大体上分为数据帧和控制帧两大类，HEADERS 帧（HTTP 头部）和 DATA 帧（HTTP 包体）属于数据帧。

• HTTP/3 在头部压缩算法这一方便也做了升级，升级成了 QPACK。与 HTTP/2 中的 HPACK 编码方式相似，HTTP/3 中的 QPACK 也采用了静态表、动态表及 Huffman 编码。

• 对于静态表的变化，HTTP/2 中的 HPACK 的静态表只有 61 项，而 HTTP/3 中的 QPACK 的静态表扩大到 91 项。

• HTTP/2 和 HTTP/3 的 Huffman 编码并没有多大不同，但是动态表编解码方式不同。

• 所谓的动态表，在首次请求-响应后，双方会将未包含在静态表中的 Header 项更新各自的动态表，接着后续传输时仅用 1 个数字表示，然后对方可以根据这 1 个数字从动态表查到对应的数据，就不必每次都传输长长的数据，大大提升了编码效率。

• 可以看到，动态表是具有时序性的，如果首次出现的请求发生了丢包，后续的收到请求，对方就无法解码出 HPACK 头部，因为对方还没建立好动态表，因此后续的请求解码会阻塞到首次请求中丢失的数据包重传过来。

• HTTP/3 的 QPACK 解决了这一问题，那它是如何解决的呢？

• QUIC 会有两个特殊的单向流，所谓的单项流只有一端可以发送消息，双向则指两端都可以发送消息，传输 HTTP 消息时用的是双向流，这两个单向流的用法：

  • 一个叫 QPACK Encoder Stream， 用于将一个字典（key-value）传递给对方，比如面对不属于静态表的 HTTP 请求头部，客户端可以通过这个 Stream 发送字典；

  • 一个叫 QPACK Decoder Stream，用于响应对方，告诉它刚发的字典已经更新到自己的本地动态表了，后续就可以使用这个字典来编码了。

• 这两个特殊的单向流是用来同步双方的动态表，编码方收到解码方更新确认的通知后，才使用动态表编码 HTTP 头部。

4. 总结

• HTTP/2 虽然具有多个流并发传输的能力，但是传输层是 TCP 协议，于是存在以下缺陷：

  • 队头阻塞，HTTP/2 多个请求跑在一个 TCP 连接中，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是多个请求被阻塞了；

  • TCP 和 TLS 握手时延，TCL 三次握手和 TLS 四次握手，共有 3-RTT 的时延；

  • 连接迁移需要重新连接，移动设备从 4G 网络环境切换到 WIFI 时，由于 TCP 是基于四元组来确认一条 TCP 连接的，那么网络环境变化后，就会导致 IP 地址或端口变化，于是 TCP 只能断开连接，然后再重新建立连接，切换网络环境的成本高；

• HTTP/3 就将传输层从 TCP 替换成了 UDP，并在 UDP 协议上开发了 QUIC 协议，来保证数据的可靠传输。

• QUIC 协议的特点：

  • 无队头阻塞，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，也不会有底层协议限制，某个流发生丢包了，只会影响该流，其他流不受影响；

  • 建立连接速度快，因为 QUIC 内部包含 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与 TLS 密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。

  • 连接迁移，QUIC 协议没有用四元组的方式来“绑定”连接，而是通过「连接 ID 」来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本；

• 另外 HTTP/3 的 QPACK 通过两个特殊的单向流来同步双方的动态表，解决了 HTTP/2 的 HPACK 队头阻塞问题。

grpc 为什么使用 http2.0

1. 优点

• HTTP/2 是一个经过实践检验的标准

  HTTP/2是先有实践再有标准，这个很重要。很多不成功的标准都是先有一大堆厂商讨论出标准后有实现，导致混乱而不可用，比如CORBA。HTTP/2的前身是Google的SPDY，没有Google的实践和推动，可能都不会有HTTP/2。

• HTTP/2 天然支持物联网、手机、浏览器

  实际上先用上HTTP/2的也是手机和手机浏览器。移动互联网推动了HTTP/2的发展和普及。 基于HTTP/2 多语言客户端实现容易 只讨论协议本身的实现，不考虑序列化。

  每个流行的编程语言都会有成熟的HTTP/2 Client HTTP/2 Client是经过充分测试，可靠的 用Client发送HTTP/2请求的难度远低于用socket发送数据包/解析数据包

• HTTP/2支持Stream和流控

  在业界，有很多支持stream的方案，比如基于websocket的，或者rsocket。但是这些方案都不是通用的。

  HTTP/2里的Stream还可以设置优先级，尽管在rpc里可能用的比较少，但是一些复杂的场景可能会用到。

• 基于HTTP/2 在Gateway/Proxy很容易支持

  nginx对gRPC的支持：https://www.nginx.com/blog/nginx-1-13-10-grpc/ envoy对gRPC的支持：https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/grpc#

• HTTP/2 安全性有保证

  HTTP/2 天然支持SSL，当然gRPC可以跑在clear text协议（即不加密）上。 很多私有协议的rpc可能自己包装了一层TLS支持，使用起来也非常复杂。开发者是否有足够的安全知识？使用者是否配置对了？运维者是否能正确理解？ HTTP/2 在公有网络上的传输上有保证。比如这个CRIME攻击，私有协议很难保证没有这样子的漏洞。

• HTTP/2 鉴权成熟

  从HTTP/1发展起来的鉴权系统已经很成熟了，可以无缝用在HTTP/2上 可以从前端到后端完全打通的鉴权，不需要做任何转换适配

2. 总结

• 覆盖广: 在标准推出后, HTTP2 就被主流浏览器和网关等支持, 最小可用的硬件标准十分的低, 手机端/电脑端/服务器端/iot端 受网络的推动, HTTP2发展普及很快
• 简单性: 大量的网络框架和组件/网关等支持简单的开启HTTP2, 开发者无需关注更底层的socket处理, 专心业务.
• 免费开放: 是开放的标准, 任何人都可以使用
• 天然支持物联网/手机/浏览器: 互联网推动
• 高性能: 相比1.1有长足的进步
• 流控: HTTP2维持一个TCP连接, 所以对流控制比较简单
• 安全性: 天然支持SSL
• 鉴权成熟: 从HTTP1发展出的鉴权系统很完善, 可以使用到2上
• 使用http2的缺点
  • 传输还不够高效: 虽然有HPACK, 但是对于RPC来讲, 还可以更加的简单快速, 比如将某个功能标记为一个int数字, 客户端直接传入数字即可标识调用服务端的哪个功能
  • gRPC使用HTTP2需要解码两次, 一次是HEADERS一次是DATA
  • HTTP2标准是本身只有一个TCP, 但是其实gRPC的实现会有多个TCP