㈠ HTTP 1.0、1.1、2.0、3.0区别
1.0的HTTP版本，是一种无状态，无连接的应用层协议。 HTTP1.0规定浏览器和服务器保持短暂的链接。
浏览器每次请求都需要与服务器建立一个TCP连接，服务器处理完成以后立即断开TCP连接(无连接)，服务器不跟踪也每个客户单，也不记录过去的请求(无状态)。
这种无状态性可以借助cookie/session机制来做身份认证和状态记录。
HTTP1.1继承了HTTP1.0的简单，克服了HTTP1.0性能上的问题。
深入理解可参考这篇文章： https://mp.weixin.qq.com/s/a83_NE-ww36FZsy320MQFQ
所有HTTP2.0通信都在一个TCP链接上完成，这个链接可以承载任意流量的双向数据流。
每个数据流以消息的形式发送，而消息由一或多个帧组成。这些帧可以乱序发送，然后再根据每个帧头部的流标识符(Stream_id)重新封装。
多路复用(连接共享)可能会导致关键字被阻塞，HTTP2.0里每个数据流都可以设置优先级和依赖，优先级高的数据流会被服务器优先处理和返回客户端，数据流还可以依赖其他的子数据流。
可见，HTTP2.0实现了真正的并行传输，它能够在一个TCP上进行任意数量的HTTP请求。而这个强大的功能基于“二进制分帧”的特性。
基于Google的QUIC，HTTP3 背后的主要思想是放弃 TCP，转而使用正脊基于 UDP 的 QUIC 协议。
与 HTTP2 在技术上允许未加密的通信不同，QUIC 严格要求加密后才能建立连接。此外，加密不仅适用于 HTTP 负载，还适用于流经连接的所有数据，从而避免了一大堆安厅李全问题。建立持久连接、协商加密协议，甚至发送第一批数据都被合并到 QUIC 中的单个请求/响应周期中，从而大大减少了连接等待时间。如果客户端具有本地缓存的密码参数，则可以通过简化的握手（0-RTT）重新建立与已知主机的连接。
为了解决传输级别的线头阻塞问题，通过 QUIC 连接传输的数据被分为一些流。流是持久性 QUIC 连接中短暂、独立的“子连接”。每个流都处理自己的错误纠正和传递保证，但使用连接全局压缩和加密属性。每个客户端发起的 HTTP 请求都在单独扮清迟的流上运行，因此丢失数据包不会影响其他流/请求的数据传输。
㈡ http和https的区别http与TCP/IP区别http/TCP三次握手四次挥手
https, 全称Hyper Text Transfer Protocol Secure，相比http，多了一个secure，这一个secure是怎么来的呢？这是由TLS（SSL）提供的，这个又是什么呢？估计你也不想知道。大概就是一个叫openSSL的library提供的。https和http都属于册慎application layer，基于TCP（以及UDP）协议，但是又完全不一样。TCP用的port是80， https用的是443（值得一提的是，google发明了一个新的协议，叫QUIC，并不基于TCP，用的port也是443， 同样是用来给https的。谷歌好牛逼啊。）总体来说，https和http类似，但是比http安全。
http缺省工作在TCP协议80端口(需要国内备案），用户访问网站http://打头的都是标准http服务，http所封装的信息都是明文的，通过抓包工具可以分析其信息内容，如果这些信息内容包含你的银行卡账号、密码，你肯定无法接受这种服务，那有没有可以加密这些敏感信息的服务呢？那就是https！
https是http运行在SSL/TLS之上，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。此外客户端可以验证服务器端的身份，如果配置了客户端验证，服务器方也可以验证客户端的身份。
https缺省工作在tcp协议443端口，它的工作流程一般如以下方式：
1、完成tcp三次同步握手；
2、客户端验证服务器数字证书，通过，进入橘蔽步骤3；
3、DH算法协商对称加密算法的密钥、hash算法的密钥；
4、SSL安全加密隧道协商完成；
5、网页以加密的方式传输，用协商的对称加密算法和密钥加密，保证数据机密性；用协商的hash算法进行数据完整性保护，保证数据不被篡改。
附：https一般使用的加密与hash算法如下：
非对称加密算法：RSA，DSA/DSS
对称加密算法：AES，RC4，3DES
hash算法：MD5，SHA1，SHA256
如果https是网银服务，以上SSL安全隧道成功建立才会要求用户输入账户信息，账户信息是在安全隧道里传输，所以不会泄密！
TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。Web使用HTTP协议作应用层协议，以封装HTTP 文本信息，然后使用TCP/IP做传输层协议将它发到网络上。
下面的图表试图显示不同的TCP/IP和其他的协议在最初OSI（Open System Interconnect）模型中的位置：
CA证书是什么？
CA（Certificate Authority）是负责管理和签发证书的第三方权威机构，是所有行业和公众都信任的、认可的。
CA证书，就是CA颁发的证书，可用于验证网站是否可信（针对HTTPS）、验证某文件是否可信（是否被篡改）等，也可以用一个证书来证明另一个证书是真实可信，最顶级的证书称为根证书。除了根证书（自己证明自己是可靠），其它证书都要依靠上一级的证书，来证明自己。
https大致过程：
1、建立服务器443端口连接 ；
2、SSL握手：随机数，证书，密钥，加密算法；
3、发送加密请求 ；
4、发送加密响应；
5、关闭SSL；
6、关闭TCP.
SSL握手大致过程：
1、客户端发送随机数1，支持的加密方法（如RSA公钥加密）；
2、服务端发送随机数2，和服务器公钥，并确认加密方法；
3、客户端发送用服务器公钥加密的随机数3；
4、服务器用私钥解密这个随机数3，用加密方法计算生成对称加密的密钥给客户端；
5、接下来的报文都用双方协定好的加密方法和密钥，进行加密.
1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数圆姿州据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流（流模式）;UDP是面向报文的（报文模式），UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP要求系统资源较多，UDP较少。TCP首部开销20字节;UDP的首部开销小，只有8个字节
SYN：同步序列编号; ACK=1: 确认序号 ; FIN附加标记的报文段（FIN表示英文finish）
一个TCP连接必须要经过三次“对话”才能建立起来，其中的过程非常复杂，只简单的 描述下这三次对话的简单过程：主机A向主机B发出连接请求数据包：“我想给你发数据，可以吗？”，这是第一次对话；主机B向主机A发送同意连接和要求同步 （同步就是两台主机一个在发送，一个在接收，协调工作）的数据包：“可以，你什么时候发？”，这是第二次对话；主机A再发出一个数据包确认主机B的要求同 步：“我现在就发，你接着吧！”，这是第三次对话。三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据。
为什么需要“三次握手”?
在谢希仁着《计算机网络》第四版中讲“三次握手”的目的是“ 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误 ”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不一样的表述其实阐明的是同一个问题。
谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。 本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。 采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。 主要目的防止server端一直等待，浪费资源。
为什么需要“四次挥手”？
可能有人会有疑问，在tcp连接握手时为何ACK是和SYN一起发送，这里ACK却没有和FIN一起发送呢。原因是 因为tcp是全双工模式，接收到FIN时意味将没有数据再发来，但是还是可以继续发送数据。
握手，挥手过程中各状态介绍:
3次握手过程状态：
LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了。
SYN_SENT : 当客户端SOCKET执行CONNECT连接时，它首先发送SYN报文，因此也随即它会进入到了SYN_SENT状态，并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。（发送端）
SYN_RCVD : 这个状态与SYN_SENT遥想呼应这个状态表示接受到了SYN报文，在正常情况下，这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次TCP握手过程中最后一个 ACK报文不予发送。因此这种状态时，当收到客户端的ACK报文后，它会进入到ESTABLISHED状态。（服务器端）
ESTABLISHED ：这个容易理解了，表示连接已经建立了。
4次挥手过程状态：（可参考下图）：
FIN_WAIT_1: 这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是： FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态， 当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
FIN_WAIT_2： 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示 半连接 ，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）
TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文 ，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）
CLOSING（比较少见）: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？ 当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。 所以你在 CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。 （被动方）
LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）
CLOSED: 表示连接中断。
TCP的具体状态图可参考：
㈢ QUIC协议有什么作用呢
在Google新版的Chrome浏览器中，支持QUIC协议，在 Chrome 浏览器中打开“实验性功能”页面（chrome://flags/），启用“实验性 QUIC 协议”和“经由实验性 QUIC 协议发出的 HTTPS 请求”，重启浏览器后可以正常登陆 Google 相关服务(被薯圆扰DNS污染的除外)。对于被DNS污染的Google服务，还需要设置Hosts的IP，然后通过HTTPS才能访问。
㈣ 详解基于UDP的低延时网络传输层协议——QUIC
Quic 全称 quick udp internet connection [1]，“快速 UDP 互联网连接”，（和英文 quick 谐音，简称“快”）是由 Google 提出的使用 udp 进行多路并发传输的协议。
Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势 [2]：
减少了 TCP 三次握手及 TLS 握手时间；
改进的拥塞控制；
避免队头阻塞的多路复用；
连接迁移；
前向冗余纠错。
从上个世纪 90 年代互联网开始兴起一直到现在，大部分的互联网流量传输磨禅只使用了几个网络协议。使用 IPv4 进行路由，使用 TCP 进行连接层面的流量控制，使用 SSL/TLS 协议实现传输安全，使用 DNS 进行域名解析，使用 HTTP 进行应用数据的传输。
而且近三十年来，这几个协议的发展都非常缓慢。TCP 主要是拥塞控制算法的改进，SSL/TLS 基本上停留在原地，几个小版本的改动主要是密码套件的升级，TLS1.3[3] 是一个飞跃式的变化，但截止到今天，还没有正式发布。IPv4 虽然有一个大的进步，实现了 IPv6，DNS 也增加了一个安全的 DNSSEC，但和 IPv6 一样，部署进度较慢。
随着移动互联网快速发展以及物联网的逐步兴起，网络交互的场景越来越丰富，困困网络传输的内容也越来越庞大，用户对网络传输效率和 WEB 响应速度的要求也越来越高。
一方面是历史悠久使用广泛的古老协议，另外一方面用户的使用场景对传输性能的要求又越来越高。
如下几个由来已久的问题和矛盾就变得越来越突出：
协议历史悠久导致中间设备僵化；
依赖于操作系统的实现导致协议本身僵化；
建立连接的握手延迟大；
队头阻塞。
可能是 TCP 协议使用得太久，也非常可靠。所以我们很多中间设备，包括防火墙、NAT 网关，整流器等出现了一些约定俗成的动作。
比如有些防火墙只允许通过 80 和 443，不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部，有可能导致双方无法使用新的传输格式。整流器和中间代理有时候出于安全的需要，会删除一些它们不认识的选项字段。
TCP 协议本来是支持端口、选项及特性的增加和修改。但是由于 TCP 协议和知名端口及选项使用的历史太悠久，中间设备已经依赖于这些潜规则，所以对这些内容的修改很容易遭到中间环节的干扰而失败。
而这些干扰，也导致很多在 TCP 协议上的优化变得小心谨慎，步履维艰。
TCP 是由操作系统在内核西方栈层面实现的，应用程序只能使用，不能直接修改。虽然应用程序的更新迭代非常快速和简单。但是 TCP 的迭代却非常缓慢，原因就是操作系统升级很麻烦。
现在移动终端更加流行，但是移动端部分用户的操作系统升级依然可能滞后数年时间。PC 端的系统升级滞后得更加严重，windows xp 现在还有大量用户在使用，尽管它已经存在快 20 年。
服务端系统不依赖用户升级，但是由于操作系统升级涉及到底层软件和运行库的更新，所以也比较保守和缓慢。
这也就意味着即使 TCP 有比较好的特性更新，也很难快速推广。比如 TCP Fast Open。它虽然 2013 年就被提出了，但是 Windows 很多系统版本依然不支持它。 即时通讯聊天软件开发可以咨询蔚可汪游念云。
不管是 HTTP1.0/1.1 还是 HTTPS，HTTP2，都使用了 TCP 进行传输。HTTPS 和 HTTP2 还需要使用 TLS 协议来进行安全传输。
这就出现了两个握手延迟：
1）TCP 三次握手导致的 TCP 连接建立的延迟；
2）TLS 完全握手需要至少 2 个 RTT 才能建立，简化握手需要 1 个 RTT 的握手延迟。
对于很多短连接场景，这样的握手延迟影响很大，且无法消除。
队头阻塞主要是 TCP 协议的可靠性机制引入的。TCP 使用序列号来标识数据的顺序，数据必须按照顺序处理，如果前面的数据丢失，后面的数据就算到达了也不会通知应用层来处理。
另外 TLS 协议层面也有一个队头阻塞，因为 TLS 协议都是按照 record 来处理数据的，如果一个 record 中丢失了数据，也会导致整个 record 无法正确处理。
概括来讲，TCP 和 TLS1.2 之前的协议存在着结构性的问题，如果继续在现有的 TCP、TLS 协议之上实现一个全新的应用层协议，依赖于操作系统、中间设备还有用户的支持。部署成本非常高，阻力非常大。
所以 QUIC 协议选择了 UDP，因为 UDP 本身没有连接的概念，不需要三次握手，优化了连接建立的握手延迟，同时在应用程序层面实现了 TCP 的可靠性，TLS 的安全性和 HTTP2 的并发性，只需要用户端和服务端的应用程序支持 QUIC 协议，完全避开了操作系统和中间设备的限制。
0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。那什么是 0RTT 建连呢？
这里面有两层含义：
传输层 0RTT 就能建立连接；
加密层 0RTT 就能建立加密连接。
TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复 [22]。
QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。
从拥塞算法本身来看，QUIC 只是按照 TCP 协议重新实现了一遍，那么 QUIC 协议到底改进在哪些方面呢？主要有如下几点。
【可插拔】：
什么叫可插拔呢？就是能够非常灵活地生效，变更和停止。体现在如下方面：
1）应用程序层面就能实现不同的拥塞控制算法，不需要操作系统，不需要内核支持。这是一个飞跃，因为传统的 TCP
拥塞控制，必须要端到端的网络协议栈支持，才能实现控制效果。而内核和操作系统的部署成本非常高，升级周期很长，这在产品快速迭代，网络爆炸式增长的今天，显然有点满足不了需求；
2）即使是单个应用程序的不同连接也能支持配置不同的拥塞控制。就算是一台服务器，接入的用户网络环境也千差万别，结合大数据及人工智能处理，我们能为各个用户提供不同的但又更加精准更加有效的拥塞控制。比如 BBR 适合，Cubic 适合；
3）应用程序不需要停机和升级就能实现拥塞控制的变更，我们在服务端只需要修改一下配置，reload 一下，完全不需要停止服务就能实现拥塞控制的切换。
STGW 在配置层面进行了优化，我们可以针对不同业务，不同网络制式，甚至不同的 RTT，使用不同的拥塞控制算法。
【单调递增的 Packet Number】：
TCP 为了保证可靠性，使用了基于字节序号的 Sequence Number 及 Ack 来确认消息的有序到达。
QUIC 同样是一个可靠的协议，它使用 Packet Number 代替了 TCP 的 sequence number，并且每个 Packet Number 都严格递增，也就是说就算 Packet N 丢失了，重传的 Packet N 的 Packet Number 已经不是 N，而是一个比 N 大的值。而 TCP 呢，重传 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不变，也正是由于这个特性，引入了 Tcp 重传的歧义问题。
QUIC 的流量控制 [22] 类似 HTTP2，即在 Connection 和 Stream 级别提供了两种流量控制。为什么需要两类流量控制呢？主要是因为 QUIC 支持多路复用。
Stream 可以认为就是一条 HTTP 请求。
Connection 可以类比一条 TCP 连接。多路复用意味着在一条 Connetion 上会同时存在多条 Stream。既需要对单个 Stream 进行控制，又需要针对所有 Stream 进行总体控制。
QUIC 实现流量控制的原理比较简单：
通过 window_update 帧告诉对端自己可以接收的字节数，这样发送方就不会发送超过这个数量的数据。
通过 BlockFrame 告诉对端由于流量控制被阻塞了，无法发送数据。
QUIC 的流量控制和 TCP 有点区别，TCP 为了保证可靠性，窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包，就算接收到了更大序号的 Segment，窗口也无法超过这个序列号。
但 QUIC 不同，就算此前有些 packet 没有接收到，它的滑动只取决于接收到的最大偏移字节数。
QUIC 的多路复用和 HTTP2 类似。在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (stream)。但是 QUIC 的多路复用相比 HTTP2 有一个很大的优势。
QUIC 一个连接上的多个 stream 之间没有依赖。这样假如 stream2 丢了一个 udp packet，也只会影响 stream2 的处理。不会影响 stream2 之前及之后的 stream 的处理。
这也就在很大程度上缓解甚至消除了队头阻塞的影响。
㈤ 更好的 TLS 1.3 协议解析
网络安全篇，面对复杂多变的网络环境，我们需要掌握哪些关于网络安全的相关知识，聊一聊与网络安全相关的：HTTPS、SSL、TLS 等。
《 网络安全 — HTTPS 》
《 网络安全的基石（上）— 加密 》
《 网络安全的基石（下）— 完整性与身份认证 》
《 公钥信任问题 — 数字证书与 CA 》
《 信任始于握手 — TLS 连接过程详解 》
《TLS 1.3 特性解析》
《 如何优化 HTTPS 连接 》- 待完善
早在 2013 年，IETF（互联网工程小组） 就对 TLS 1.2 的过时设计和两次往返开销心生不满，因此开始着手准备新版本的 TLS。同年 8 月由 Eirc Rescorla 提议出新版本 TLS 的 功能愿望清单 。在经过一番 辩论 后，最终该提议内容被定义为 TLS 1.3。推动 TLS 1.3 设计的主要问题大概有：
终于在 2018 年 8 月 10 日，历经 4 年时间，TLS 1.3 最终版本发布了 — RFC-8446 。新的协议使得互联网变得更快、更安全；随着 TLS 1.3 的采用率不断提高，它势必会长远影响互联网的发展；同时尽快将 TLS 1.3 平滑应用到线上环境无疑是势在必行。
不过在这之前， TLS 1.2 的应用也已经有 10 年（2008 年）的时间了，毕竟历经了种种考验，新的协议在推广和部署上必定会带来新的挑战。接下来我们就来看看新版本的 TLS 是如何做的？
由于 TLS 1.1/1.2 等协议已经出现了很多年，很多应用软件、中间代理（Middlebox）只认老的记录协议格嫌和蠢式，更新改造很困难，甚至僵化。
可部署性
正式由于这些中间代理/软件（Middlebox）在新的更改中表现不佳，即使是对 TLS 1.3 协议的细微更改（例如消除冗余的 ChangeCipherSpec 消息，版本号从 0x03 升级为 0x04），也最终导致了某些设备的连接失败问题。这也是 TLS 1.3 从草稿到最终发布花费了这么长时间的重要原因之一。
为了保证这些被广泛部署的“旧设备”能够继续使用，TLS 1.3 不得不做出妥协，通过“伪装”来实现兼容：保持现有的记录格式不变，使得 TLS 1.3 看上去“像是” TLS 1.2。
扩展协议
那么，如何区分是 1.2 还是 1.3 呢？
这里用到一个新的 扩展协议 （Extension Protocol），它有点“补充条款”的意思，通过在记录末尾添加一系列的“扩展字段”来增加新的功能，旧版本的 TLS 不认识它可以直接忽略，这就实现了“向后兼容”。
TLS 1.3 正是利用扩展实现了许多重要的功能，比如 “supported_groups” “key_share” “signature_algorithms” “server_name” 等。
在经历十余年的实践中获得许多宝贵经验的 TLS 1.2 陆续发现了很多的漏洞和加密算法的弱点。因此消除潜在的危险设计来纠正以前的错误成为 TLS 1.3 的设计目标之一。所以新版本的 TLS 协议里要修补这些不安全的因素。
例如：
固定密钥交换
经过这样一番“减肥瘦身”之后，TLS 1.3 的密钥交换算法只有 ECDHE 和 DHE 了，关于椭圆曲线（ECC）也被“砍”到只剩 P-256 和 x25519 等 5 种。
首先来说下废除 RSA 和 DH 密钥交换算法的原因：
由于客户端默认会选择 ECDHE 而非 RSA 做密钥交换，这是因为它不具有“ 前向安全 ”（Forward Secrecy）：“假设有人长期记录了加密的数据，然后在后续的某个时间段获得了服务器的 RSA 私钥，那么黑客就能够使用该私钥棚碰解密出之前芹陪所有报文的 “Pre-Master”，再计算出会话密钥，破解所有密文。这便是 今日截获，明日破解 ”
而 ECDHE 算法在每次握手时都会生成一对临时公钥和私钥，每次通信的秘钥对都是不同的，也就是“一次一密”，即使黑客花大力气破解了这一次的会话密钥，也只是这次通信被攻击，之前的历史消息不会受到影响，仍然是安全的。
所以现在主流的服务器和客户端在握手阶段都已经不再使用 RSA，改用 ECDHE，而 TLS 1.3 在协议里明确废除了 RSA 和 DH 则在标准层面保证了“前向安全”。
固定密码
多年以来，密钥交换机制不是唯一引起安全漏洞的部分，对称密钥部分也有相当一部分问题。
同样，用于对称加密的算法在经过“减肥瘦身”之后也只保留了 AES、ChaCha20 ，分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要算法也只能用 SHA 256、SHA 384。
这样原来众多的加密算法、参数组合导致密码套件非常复杂，难以选择。而经过瘦身之后的 TLS 1.3 只剩下 5 个套件，使得客户端或服务端在选择密码套件时变得“更加容易”。然而更重要的是，这些算法在 TLS 长期的实践过程中先后已经被证实是构成不安全的因素，从而导致安全漏洞。
修复数字签名
经过前面的学习，相信你也知道 TLS 另一个重要部分是身份验证。在每个连接中服务都是用具有公钥的数字证书向客户端提供身份认证。在 RSA 加密模式下，服务器通过解密预主密钥并通过对话记录计算 MAC 来证明其对私钥的所有权。在 Diffie-Hellman 模式下，服务器使用数字签名来证明私钥的所有权。
在 TLS 1.2 和更早的版本中，服务器的签名仅涵盖部分握手。用于协商使用哪种对称密码的部分没有由私钥签名。这也导致许多引人注目的漏洞 FREAK ， LogJam 等。而在 TLS 1.3 由于服务器对整个握手记录进行签名，因此可以避免这些情况。
HTTPS 建立连接时除了要做 TCP 握手，还要做 TLS 握手，在 TLS 1.2 中会多花两个消息往返（2 - RTT），这可能导致几十毫秒甚至上百毫秒的延迟，在移动网络中延迟还会更严重。
1-RTT 模式
密码套件的大幅度简化，也就没有必要再像以前那样走复杂的的协商流程了。TLS 1.3 压缩了以前的 “Hello” 协商过程，删除了 “Key Exchange” 消息，把握手时间减少到了 “1-RTT”，效率提高了一倍。
下面是 TLS 1.3 握手过程的简图，注意与前面介绍的 TLS 1.2 对比区别在哪里。
0-RTT 恢复
除了标准的 “1-RTT” 握手，受 QUIC 协议的启发，客户端可以在其第一条消息中将加密的数据发送到服务器，与未加密的 HTTP 相比，没有额外的延迟成本。
在 TLS 1.2 中，有两种恢复连接的方法：会话 ID 和会话 Ticket，而 1.3 则将他们组合在一起形成称为 PSK（pre-shared key，预共享密钥）恢复的新模式。
握手分析
目前 Nginx 等 Web 服务器都能够很好的支持 TLS 1.3，但是要求底层的 OpenSSL 必须是 1.1.1。因此如果要部署需要先升级你的 OpenSSL 版本。
首先TCP 建立连接之后，浏览器首先还是发一个 “ Client Hello ”。
由于 1.3 的消息要兼容 1.2，所以开头的版本号、支持的密码套件和随机数（Client Random）结构都是一样的（这时的随机数是 32 个字节）。
注意 “Client Hello” 里的扩展，“ supported_versions ” 表示这是 TLS 1.3，“ supported_groups ” 是支持的曲线，“ key_share ”是曲线对应的参数。
这有点是像是“有话尽量一口气说完”，还是按照老规矩进行“打招呼”，我这边有这些信息，考虑到版本升级，所以附带了一些信息，可能后面会用到。
服务器收到 “Client Hello” 同样返回 “Server Hello” 消息，还是要给出一个 随机数 （Server Random）和选定密码套件。
表面上看 Version 和 TLS 1.2 是一样的，重点是后面的扩展。“ supported_versions ” 里确认使用的是 TLS 1.3，然后在 “ key_share ” 扩展带上曲线和对应的公钥参数。
服务器的回应还是老套路，服务端对客户端的提供的信息作出选择，另外服务端还要再附加上几个参数，这次加密就协商定了。
可以看到相比 TLS 1.2 的握手过程，TLS 1.3 仅用两条消息就共享了 4 个信息： Client Random 和 Server Random 、 Client Params 和 Server Params 。两边就可以各自用 DH 算出 “ Pre-Master ”，再用 HKDF 生成主密钥 “ Master Secret ”，效率比 TLS 1.2 提高了一大截。
在计算出主密钥后，服务器立刻发出 “ Change Cipher Spec ” 消息，比 TLS 1.2 提早进入加密通信，后面的证书等就都是加密的了，减少握手时明文信息泄露。
TLS 1.3 还多了一个 “ Change Cipher Spec ” 消息，服务器用私钥把前面的曲线、套件、参数等握手数据加了签名，作用和 “ Finished ” 消息差不多。但由于是私钥签名，所以强化了身份认证和防篡改。
两个“打招呼”消息之后，客户端验证服务器证书，再发 “Finished” 消息，就正式完成了握手，开始收发 HTTP 报文。
现在已经有很多网站都支持了 TLS 1.3，例如 GitHub ：
今天我们主要介绍了 TLS 1.3 的一些新特性，简单总结下来主要包含下面几点：
TLS 1.3 涉及的内容很多，有关它的更详细信息请去参照 RFC-8446 ，关于这部分大家还有哪些要分享的呢？欢迎您的留言或指正。
网络安全系列专题
扩展阅读
㈥ 三次握手、七次握手、四次挥手
TCP/IP 传输协议的 TCP 协议是面向连接的，也就是传输数据之前，必须建立可靠的连接。建立连接的过程中，需交换信息（如选取哪种协议、协议版本等），这个过程称为 握手 handshaking 。
握手过程中会协商后续通信使用的参数，如传输速率、编码方式、校验，袜氏以及其他协议选取、硬件支持的功能等。握手是两个实体之间的通信，但在 TCP/IP 中握手常指 TCP 的三次握手。
TCP 中的数据传输、连接建立与终止都由特定控制参数管理，控制参数有以下这些：
建立 TCP 连接需要三次握手：
TCP 连接的双方通过三次握手确定 TCP 连接的初始序列号、窗口大小以及最大数据段，这样通信双方就能利用连接中的初始序列号保证双方数据段的不重不漏，通过窗口大小控制流量，并使用最大数据段避免 IP 协议对数据包分片。
换个角度看为什么需要三次握手？客户端和服务端通信前要进行连接，三次握手就是为了确保自己和对方的收发能力是正常的。
三次握手后，客户端、服务端才确认了自己的接收、发送能力均是正常的。
HTTP 协议中的数据是明文传输的，任何中间人（man-in-the-middle）都可以读取传输的数据，因此 HTTP 是一种不安全的协议。
HTTPS 是 HyperText Transfer Protocol Secure 的缩写。但 HTTPS 协议自身不告枝散能加密数据，它需要借助 SSL 或 TLS 协议层进行加密。
HTTP 协议和 TLS 协议都位于 application layer。TCP 三次握手建立连接后，使用 TLS 握手建立安全连接，后续使用协商的加密算法先对数据进行加密，再通过 HTTP 传输。
数据加密后，中间人即使获得了数据，也无法读取数据内容，进而避免了中间人攻击（man-in-the-middle-attack）。
HTTP 协议和 TLS 协议一起使用时，称为 HTTPS 协议。App 想要使用 TLS 加密通信，只需网址使用 https:// 前缀即可。
要了解 TLS 工作原理，需先了解加密的工作原理，以及各种加密算法。加密就是将数据从一种格式编码为另一种格式，编码时使用一些数学算法、秘密参数。使用相同算法、参数，可以解密数据，这个过程中的参数称为密钥（key）。
非对称加密算法有两个 key：
最流行的非对称加密算法是 RSA 加密算法，广泛用于密钥交换和数字签名验证。但现在正逐步迁移至更安全高效的 Diffie-Hellman （缩写为 D-H）算法。
非对称加密算法通常速度慢，更耗费 CPU，且 key、数据越长，加密、解搭哪密耗费时间也越长。因此，数据量大时不要使用非对称加密，而应使用对称加密（symmetric key cryptography），对称加密速度更快、性能更高。非对称加密用于传输对称加密密钥。
对称加密算法也称为共享密钥加密（shared key），它使用相同的 key 加密、解密。
对称加密算法主要用于受信任两者之间建立加密通道。因为第三方无法获取对称密钥，因此只有建立通道的双方才可以解密数据。
最流行的对称加密算法是 AES（Advanced Encryption Standard 的缩写，即高级加密标准），
SSL 协议由 Netscape 团队设计，于1995年发布 SSL 2.0版本，之后发布了 SSL 3.0版本，IETF 已于2015年不推荐使用 SSL 3.0。
目前，TLS 协议已经替代了 SSL 协议，SSL 协议已不再使用。
TLS 是旨在提供安全通信的加密协议，使用 TLS 可以加密与服务器的所有通信。当前使用最广的是 TLS 1.2、TLS 1.3。
TLS 1.3 发布于2018年，是对 TLS 1.2 的全面修订，在性能和安全性方面都有很大提升，并且减少了建立安全连接所需的握手次数。
TLS 1.3 只支持 Diffie-Hellman 非对称加密算法，移除了 RSA 算法。
使用 HTTPS 发送 HTTP 请求时，首先使用三次握手建立可靠的 TCP 连接，之后就通过 TLS 四次握手交换双方的密钥。
下面介绍 TLS 1.2 连接建立过程：
TLS 握手的关键在于利用通信双方生成的随机字符串和服务端的公钥生成一个双方经过协商后的密钥，通信双方后续使用这个对称密钥加密数据，防止中间人监听和攻击，保障通信安全。
在 TLS 1.2 中，需要 2-RTT（Round-Trip Time，往返延迟）才能建立 TLS 连接。在 TLS 1.3 中，客户端不仅发送 ClientHello、支持的协议、加密算法，还尝试猜测服务器将选择哪种密钥协商算法，并为此发送共享密钥。这样服务端选取加密算法后，因为已经有了 client key，可以立即生成 key，进而减少一次 RTT。
建立连接时需要发送三个 packet，但终止连接时需要四个 packet，也称为四次挥手。因为 TCP 连接是全双工的，每个方向都必须独立终止。
终止 TCP 连接的四次挥手：
在第二次挥手时，如果服务端也想终止连接，可以为 FIN 设置不同于客户端 FIN 的序列号。客户端收到 FIN 后，发送 ACK，它的 acknowledgement number 为 FIN sequence number 加一。这一过程结束后，服务端与客户端的连接也终止了，这样的话整个过程进行了三次挥手。
客户端想要通过 HTTP 请求访问服务端时，需要经过三次握手；通过 HTTPS 访问服务端时，需要额外增加四次握手。
总结一下 HTTP 建立连接、终止连接：
需要注意的是，本文所说的三次握手、七次握手、四次挥手都是基于特定版本的协议，不同版本的协议所需握手次数可能不同。HTTP/3 就是一个例子，它使用基于 UDP 的 QUIC 协议进行握手，将 TCP 和 TLS 握手过程结合起来，握手次数从七次减少到了三次。
参考资料：
欢迎更多指正： https://github.com/pro648/tips
本文地址： https://github.com/pro648/tips/blob/master/sources/三次握手、七次握手、四次挥手.md
㈦ 拥塞算法
基于包丢失检测的 Reno、NewReno 或者 cubic 为代表，其主要问题有 Buffer bloat 和长肥管道两种。和这些算法不同，bbr 算法会以时间窗口内的最大带宽 max_bw 和最小 RTT min_rtt，并以此计算发送速率和拥塞窗口
RTProp : round-trip propagation time BtlBW : bottleneck bandwidth，bbr 算法关于拥塞窗口的核心就是计算 BtlBW 和 RTprop，根据这两者值计算 BDP
bbr 算法输出 pacing_rate 和 cwnd 两个数据。pacing_rate 决定发包速率，cwnd 为窗口大小
TCP Tahoe 和 Reno
这两个算法是根据其第一次加入到4.3BSD的时间回溯命名的，两个名字对应自其第一次出现时BSD的代号，而代号分别取自太浩湖（Lake Tahoe）和其附近的城市里诺市
• Tahoe：如果收到三次重复确认——即第四次收到相同确认号的分段确认，并且分段对应包无负载分段和无改变接收窗口——的话，Tahoe算法则进入快速重传，将慢启动阈值改为当前拥塞窗口的一半，将拥塞窗口降为1个MSS，并重新进入慢启动阶段
• Reno：如果收到三次重复确认，Reno算法则进入快速重传，只将拥塞窗口减半来跳过慢启动阶段，将慢启动阈值设为当前新的拥塞窗口值，进入一个称为“快速恢复”的新设计阶段
Fast recovery
是Reno算法新引入的一个阶段，在将丢失的分段重传后，启动一个超时定时器，并等待该丢失分段包的分段确认后，再进入拥塞控制阶段。如果仍然超时，则回到慢启动阶段
TCP Vegas
至1990年代中期，TCP量度延迟和RTT都是以传输缓存中最后一个被传送的分段包为准。vegas通过度量传输缓存中每个传送分段包来代替只量度一个分段包，通过每次度量的平均值来增加拥塞窗口。该算法取名自内华达州最大的城市拉斯维加斯。不过由于一些资源公平性原因，该算法并没有在彼得森的实验室之外广泛部署。一些研究认为该算法和其他拥塞算法混合使用，可能会导致性能竞争不及其他算法。在各种TCP拥塞算法的比较研究中，Vegas被认为是最平滑的控制算法，其次为CUBIC
TCP New Reno
TCP New Reno是对TCP Reno中快速恢复阶段的重传进行改善的一种改进算法，其定义于RFC 6582，覆盖了原有在RFC 3782和RFC 2582的旧定义。
在Reno的快速恢复中，一旦出现3次重复确认，TCP发送方会重发重复确认对应序列号的分段并设置定时器等待该重发分段包的分段确认包，当该分段确认包收到后，就立即退出快速恢复阶段，进入拥塞控制阶段，但如果某个导致重复确认的分段包到遇到重复确认期间所发送的分段包存在多个丢失的话，则这些丢失只能等待超时重发，并且导致拥塞窗口多次进入拥塞控制阶段而多次下降。而New Reno的快速恢复中，一旦出现3次重复确认，TCP发送方先记下3次重复确认时已发送但未确认的分段的最大序列号，然后重发重复确认对应序列号的分段包。如果只有该重复确认的分段丢失，则接收方接收该重发分段包后，会立即返回最大序列号的分段确认包，从而完成重发；但如果重复确认期间的发送包有多个丢失，接收方在接收该重发分段后，会返回非最大序列号的分段确认包，从而发送方继续保持重发这些丢失的分段，直到最大序列号的分段确认包的返回，才退出快速恢复阶段。
New Reno在低错误率时运行效率和“选择确认”（Selective ACKnowledgement，SACK）相当，在高错误率仍优于Reno
TCP Hybla
TCP Hybla旨在消除由于高延迟地面线路或者卫星无线链路下导致的RTT过长而对TCP链接的影响。它通过对拥塞窗口动态分析来修改，来减少对RTT的性能依赖
TCP BIC 和 CUBIC
TCP BIC（Binary Increase Congestion control）旨在优化高速高延迟网络（即根据RFC 1072所定义的“长肥网络”（long fat network，LFN））的拥塞控制，其拥塞窗口算法使用二分搜索算法尝试找到能长时间保持拥塞窗口最大值的值。Linux内核在2.6.8至2.6.18使用该算法作为默认TCP拥塞算法。
CUBIC则是比BIC更温和和系统化的分支版本，其使用三次函数代替二分算法作为其拥塞窗口算法，并且使用函数拐点作为拥塞窗口的设置值。Linux内核在2.6.19后使用该算法作为默认TCP拥塞算法
TCP Westwood和Westwood+
TCP Westwood改良自New Reno，不同于以往其他拥塞控制算法使用丢失来测量，其通过对确认包测量来确定一个“合适的发送速度”，并以此调整拥塞窗口和慢启动阈值。其改良了慢启动阶段算法为“敏捷探测（Agile Probing）”，和设计了一种持续探测拥塞窗口的方法来控制进入“敏捷探测”，使链接尽可能地使用更多的带宽。Westwood+使用更长的带宽估计间隔和优化的滤波器来修正Westwood对ACK压缩场景对带宽估计过高的问题。通过以上改良，TCP Westwood系列算法在有线网络和无线网络的拥塞控制上获取平衡，尤其研究中针对于无线通信网络上
Compound TCP
复合TCP（Compound TCP）是微软自己实现的TCP拥塞控制算法，通过同时维护两个拥塞窗口，来实现在长肥网络有较好的性能而又不损失公平性。该算法在Windows Vista和Windows Server 2008开始广泛部署，并通过补丁的方式回溯支持到Windows XP和Windows Server 2003。在Linux上也有一个旧版本的移植实现
TCP PRR
TCP PRR（TCP Proportional Rate Rection ）是旨在恢复期间提高发送数据的准确性。该算法确保恢复后的拥塞窗口大小尽可能接近慢启动阈值。在Google进行的测试中，能将平均延迟降低3~10%，恢复的超时减少5%。PRR算法之后作为Linux内核3.2版本的默认拥塞算法
TCP BBR
TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）是由Google设计，于2016年发布的拥塞算法。以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR则基于模型主动探测。该算法使用网络最近出站数据分组当时的最大带宽和往返时间来创建网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。该算法认为随着网络接口控制器逐渐进入千兆速度时，与缓冲膨胀相关的延迟相比丢包更应该被认为是识别拥塞的主要决定因素，所以基于延迟模型的拥塞控制算法（如BBR）会有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法，例如CUBIC
QUIC Quick UDP Internet Connections
QUIC旨在提供几乎等同于TCP连接的可靠性，但延迟大大减少。它主要通过两个理解HTTP流量的行为来实现这一点：
第一个变化是在连接创建期间大大减少开销。由于大多数HTTP连接都需要TLS，因此QUIC使协商密钥和支持的协议成为初始握手过程的一部分。 当客户端打开连接时，服务器响应的数据包包括将来的数据包加密所需的数据。
QUIC使用UDP协议作为其基础，不包括丢失恢复。相反，每个QUIC流是单独控制的，并且在QUIC级别而不是UDP级别重传丢失的数据。这意味着如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务
QUIC包括许多其他更普通的更改，这些更改也可以优化整体延迟和吞吐量
每个数据包是单独加密的，因此加密数据时不需要等待部分数据包。 在TCP下通常不可能这样做，其中加密记录在字节流中，并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商，但QUIC旨在通过单个握手过程完成这些
QUIC的另一个目标是提高网络切换期间的性能，例如当移动设备的用户从WiFi热点切换到移动网络时发生的情况。 当这发生在TCP上时，一个冗长的过程开始了：每个现有连接一个接一个地超时，然后根据需要重新创建。期间存在较高延迟，因为新连接需要等待旧连接超时后才会创建。 为解决此问题，QUIC包含一个连接标识符，该标识符唯一地标识客户端与服务器之间的连接，而无论源IP地址是什么。这样只需发送一个包含此ID的数据包即可重新创建连接，因为即使用户的IP地址发生变化，原始连接ID仍然有效
QUIC在应用程序空间中实现，而不是在操作系统内核中实现。当数据在应用程序之间移动时，这通常会由于上下文切换而调用额外的开销。 但是在QUIC下协议栈旨在由单个应用程序使用，每个应用程序使用QUIC在UDP上托管自己的连接
Chromium的网络堆栈同时打开QUIC和传统TCP连接，并在QUIC连接失败时以零延迟回退到TCP连接
㈧ quic 协议分析
HTTP 3 ，它来了，QUIC（quick udp internet connection “快速 UDP 互联网连接”）正如其名一样，它就是快。其正在标准化为新一代的互联网传输协议。是由google提出的使用udp进行多路并发的传输协议。
QUIC解决了什么问题呢？从上世纪90年代至今，互联网一直按照一成不变的尘孙帆模式发展着。使用ipv4进行路由，使用tcp进行连接层面的拥塞控制，并保证其传输的可靠性，使用tls层进行安全加密和身份验证，使用http进行应用的数据传输。
这么多年的发展，这些协议只是小部分或者细节上有了改变，tcp提出了几个新的拥塞控制算法，tls改变了加密方式，http层进化出了h2。但是互联网发展至今，网络传输的内容越来越大，用户对传输的时延，带宽提出越来越大的要求。
tcp虽然也在拥塞控制上提出了一些优秀的拥塞控制算法，如BBR但是限制于其对操作系统内核版本的要求，tcp 的 TFO，windows操作系统又支持不好等。导致想要切换成更高效的协议成本巨大。
这里列出几个主要的矛盾。
1、协议历史悠久导致中间设备僵化。
2、依赖于操作系统的实现导致协议本身僵化派雹。
3、建立连接的握手延迟大。
4、队头阻塞。
QUIC孕育而生，其抛开了TCP直接采用UDP，如一些拥塞算法，可靠性保证机制，不再依赖操作系统内核，而是可以自定义。
Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势：
1、减少了 TCP 三次握手及 TLS 握手时间。
2、改进的拥塞控制。
3、避免队头阻塞的多路复用。
4、连接迁移。
5、前向冗余纠错。
有些防火墙只允许通过 80 和 443，不放通其他端口。NAT 网关在转换网络地址时重写传输层的头部，有可能导致双方无法使用新的传输格式。因为通信协议栈都是固化到操作系统中的，只能通过内核参数进行调整，但是这样的调整极其有限，如果想要新加协议，只能重新编译内核。而现实是，可能还有一些Centos5 还作为某些古董公司的线上服务器。另外，windows xp 可能还是某些事业单位的办公电脑上装的操作系统，尽管xp的时代已经过去20年了。另外TCP Fast Open 也在2013年就提出了，但是windows操作系统也有些不支持。
知道一个首次https网站的访问都要有哪些步骤吗？dns解析需要1个RTT，TCP三次握手，HTTP 302 跳转 HTTPS又需要RTT，TCP重新握手。TLS握手再消耗2个。解析CA的DNS（因为浏览器获取到证书后，有可能需要发起 OCSP 或者 CRL 请求，查询证书状态）再对CA进行TCP握手，OCSP响应。密钥协商又是RTT。当然这种情况是最极端的，大部分情况下不是所有流程都需要走一遍的。（参考 大型网站的 HTTPS 实践（二）-- HTTPS 对性能的影响 ）
基于以上的原因，QUIC选择了UDP。没有了三次握手，在应用层面完成了传输的可靠性，拥塞控制还有TLS的安全性。只要凯余应用软件的客户端和服务端支持就行，绕开了操作系统内核版本这个硬骨头。
在HTTPS over TCP+TLS的时代。HTTPS需要3个RTT，在session 复用的情况下是2个RTT。而QUIC做到了1RTT和会话复用的0RTT。
QUIC的TLS只能使用TLS1.3，这就可以做到PSK的0RTT。
TCP 的拥塞控制实际上包含了四个算法：慢启动，拥塞避免，快速重传，快速恢复。其中TCP中拥塞控制是被编译进内核中的，如果想要更改就需要改变内核参数，但是想要对已有的拥塞控制算法进行更改就需要重新编译内核，Linux 4.9 中引入了基于时延的拥塞控制算法 BBR，这打破了以往是靠丢包驱动的拥塞控制算法，但是想要在TCP中使用，就必须升级内核至4.9以上。
QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6]，同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。
QUIC和TCP的对比
其中α 从 0到 1（RFC 推荐 0.9），越大越平滑
如 UBOUND为1分钟，LBOUND为 1 秒钟， β从 1.3 到 2 之间
对于QUIC
参考： 科普：QUIC协议原理分析 罗成
㈨ quic 协议总结
client和server协商过程:
1. 客户端发送CHLO到服务端
2. 服务端回送的REJ信息给客户端，同时携带上原地址标识信息和服务端证书信息
3. 客户端再次发送CHLO到服务端
拥塞控制：
QUIC参考TCP的CUBIC拥塞控制算法，并在试探尝试其他拥塞控制算法
试探尝试新的拥塞控制算法：例如每个数据包的转发(包括原始数据包和重传包)都携带一个新的sequece序列化，这样可以避免TCP的重传模糊问题
QUIC-ACK会携带上接收数据包的时间以及发送ack的时间，这样有利于计算往返时延
QUIC-ACK相比TCP的SACK，跟容易实现包的重组，当有包丢失或者
FEC
通过FEC可以从一组FEC报文组中恢复网络传输中丢失的数据包，具体优化方案由发送端决定
连接复用
QUIC连接通过一个64位的连接标识符标识，该标识符由客户端产生。
QUIC的连接建立将版本协商与加密和传输握手交织在一起以减少连接建立延迟。我们将在下面首先描述版本协商。
连接建立延迟
灵活的拥塞控制
多路复用而不存在队首阻塞
认证和加密的首部和载荷
流和连接的流量控制
连接迁移
QUIC采用了两级密钥机制：初始密钥和会话密钥。初次连接时不加密，并协商初始密钥。初始密钥协商完毕后会
马上再协商会话密钥，这样可以保证密钥的前向安全性，之后可以在通信的过程中就实现对密钥的更新。接收方意
识到有新的密钥要更新时，会尝试用新旧两种密钥对数据进行解密，直到成功才会正式更新密钥，否则会一直保留
旧密钥有效。
QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数
会周期性的更新。初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。
0-RTT握手过程
QUIC握手的过程是需要一次数据交互，0-RTT时延即可完成握手过程中的密钥协商，比TLS相比效率提高了5倍，且具有更高的安全性。
QUIC在握手过程中使用Diffie-Hellman算法协商初始密钥，初始密钥依赖于服务器存储的一组配置参数，该参数会周期性的更新。
初始密钥协商成功后，服务器会提供一个临时随机数，双方根据这个数再生成会话密钥。
具体握手过程如下：
(1) 客户端判断本地是否已有服务器的全部配置参数，如果有则直接跳转到(5)，否则继续
(2) 客户端向服务器发送inchoate client hello(CHLO)消息，请求服务器传输配置参数
(3) 服务器收到CHLO，回复rejection(REJ)消息，其中包含服务器的部分配置参数
(4) 客户端收到REJ，提取并存储服务器配置参数，跳回到(1)
穗备 (5) 客户端向服务器发送full client hello消息，开始正式握手，消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数，可以计算出初始猜闷毁密钥。
(6) 服务器收到full client hello，如果不同意连接就回复REJ，同(3)；如果同意连接，根据客户端的公开数计算出初始密钥，回罩裂复server hello(SHLO)消息，SHLO用初始密钥加密，并且其中包含服务器选择的一个临时公开数。
(7) 客户端收到服务器的回复，如果是REJ则情况同(4)；如果是SHLO，则尝试用初始密钥解密，提取出临时公开数
(8) 客户端和服务器根据临时公开数和初始密钥，各自基于SHA-256算法推导出会话密钥
(9) 双方更换为使用会话密钥通信，初始密钥此时已无用，QUIC握手过程完毕。之后会话密钥更新的流程与以上过程类似，只是数据包中的某些字段略有不同。
QUIC包含三种报文包类型：
协商Package、公用复位package、普通帧信息Package
Version Negotiation Packets and Public Reset Packets, and regular packets containing frames.
如果客户端的版本不被服务器接受，则将导致1-RTT的延迟。服务器将发送一个版本协商包给客户端。这个包将设置版本标记，并将包含服务器支持的版本的集合。
当客户端从服务器收到一个版本协商包，它将选择一个可接受的协议版本并使用这个版本重发所有包。
为了避免流ID冲突，流 ID 必须是偶数，如果流是由服务器初始化的话，如果流由客户端初始化则必须为奇数。
0不是一个有效的流 ID。流 1 被保留用来加密握手，它应该是第一个客户端初始化的流。当基于QUIC使用HTTP/2时，
流 3 被保留来为其它流传输压缩的首部，以确保首部的处理和传送可靠且有序。
各种帧格式参考:QUICWireLayoutSpecification.pdf
官方参考地址:https://www.chromium.org/quic
㈩ 互联网基础资源技术协议的安全发展趋势
文 中国互联网络信息中心 姚 健康
一、国际互联网工程任务组是互联网技术协议发展大本营
互联网的发展改变了世界。互联网运行的核心技术标准和核心技术协议主要来自国际互联网工程任务组（IETF）。IETF 创立于 1986 年初，是负责制订互联网方面技术标准的重要组织，主要任务是负责互联网相关技术标准的研发和制定，超过90% 的互联网技术标准由其制定。IETF 通过技术标准的制定，保障了互联网的长期稳定运行。IETF大量的技术性工作均由其内部的各种工作组（WG）承担和完成。这些工作组依据各项不同类别的研究课题而组建。在成立工作组之前，IETF 通常会先设立兴趣小组（BOF）开展工作组筹备工作。筹备工作完成后，经过 IETF 高层研究认可，可正式成立工作组。IETF 汇聚了全球顶尖的互联网技术工程师，每年举行三次会议，参会规模均在千人以上。
互联网架构委员会（IAB）成立于 1983 年，是 IETF 的最高管理机构，由包括 IETF 主席在内的 13 名委员组成。IAB 的主要职责之一是负责互联网协议体系结构的监管，把握互联网技术的长期演进方向，保护互联网的长期发展，负责确定互联网标准的制订规则，指导互颂激联网技术标准的编辑出版，负责互联网的编号管理，并协调与其他国际标准化组织的工作。
IETF 将工作组分类为不同的领域，每个领域由几个领域主任（Area Director）负责管理。领域主任组成互联网工程指导委员会（IESG），具体领域如下。
一是应用和实时研究领域（Applications andReal-Time Area）。该领域主要研究应用层相关的标准，也包括实时相关的网络协议。
二是通用研究领域（General Area）。该研究领域用于包括不适合放在其他研究领域的研究内容。
三是网际互联研究领域（Internet Area）。网际互联研究领域主要研究 IP 数据包如何在不同的网络环境中进行传输。
四是运营管理研究领域（Operations andManagement Area）。该研究领域主要涉及互联网的运营与管理方面的内容。随着互联网的快速发展与普及，对网络的运营与管理提出了更高的要求，因此，该研究领域也越来越受到重视。
五是路由研究领域（Routing Area）。该研究领域主要负责制订如何在网络中确定传输路径以将IP 数据包路由到目的地的相关标准。
六是安全研究领域（Security Area）。该研究领域主要负责研究 IP 网络中的授权、认证、审计等与私密性保护有关的协议与标准。互联网的安全性越来越受到人们的重视，因此，该领域也成为IETF 中最活跃的研究领域之一。
七是传输研究领域（Transport Area）。该领域主要负责研究特殊类型或特殊用途的数据包在网络中的端到端的传输方式。
在上述领域，除了安全研究领域专门研究安全技术以外，其他领域也会涉及安全问题。如何提高互联网技术协议的安全是 IETF 长期研究的重点议题。
二、互联网基础资源技术协议利用公钥信任链加强安全
IETF 互联网基础资源技术协议从默认信任数据转向保障数据来源可信、数据完整和防篡改等方向发展。
（一）域名系统协议利用公钥信任链加强安全
域名系统协议（DNS）是互联网的启答核心协议，是一种将域名映射为某些预定义类型资源记录（如IP 地址）的分布式互联网服务系统。作为一种互联网应用层的资源寻址基础服务，域名服务是其他互联网络应用服务的基础。常见的互联网络应用服务如网页远程访问服务、电子邮件服务、文件远程访问服务等一般都以域名服务为基础，实现资源的寻址和定位。
DNSSEC 协议是一个针对 DNS 协议的安全扩展，它通过给 DNS 的应答消息添加基于非对称加密算法的数字签名，保证数据未经篡改且来源正确；再通过域名体系自下而上逐级向父域提交自己公共密钥，实现整个域野旁袜名体系的逐级安全认证。DNSSEC 为 DNS 数据提供了三方面的安全保障：一是数据来源验证，保证 DNS 应答消息来自被授权的权威服务器；二是数据完整性验证，保证 DNS 应答消息在传输途中未经篡改；三是否定存在验证，当用户请求一个不存在的域名时，DNS服务器也能够给出包含数字签名的否定应答消息，以保证这个否定应答的可靠性。
综上所述，DNSSEC 本质上是在域名系统树型授权体系的基础上，再建立一套基于密码学手段的签名/验证体系，也就是信任链体系，通过信任链上的逐级安全验证，确保 DNS 查询结果的真实可靠性、数据完整性和非否认性。
互联网名称与数字管理机构（ICANN）一直在全球推进 DNSSEC 的部署，2010 年 7 月，ICANN 正式用 DNSSEC 签署根域。为了更好地管理根密钥，ICANN 制订了根密钥管理计划。该计划在全球选择信任社区代表（TCR），负责生成管理根密钥。ICANN 一共选出 21 名 TCR 和一些后备TCR，所有的候选人都是来自互联网社区的个人。其中 14 名 TCR 是密码管理员（CO），美国东海岸和西海岸各 7 名，负责参与生成根密钥。另外 7名 TCR 是恢复密钥持有人（RKSH），负责硬件安全模块（HSM）内容的备份和管理，用于紧急状态时候恢复 HSM 工作状态。2010 年 6 月，在美国弗吉尼亚州的库尔佩珀（Culpeper）召开了全球第一次 DNSSEC 根密钥生成仪式会议。
ICANN 有两套完全相同的 HSM，分别放在美国东海岸和西海岸，用于根密钥的生成。启动HSM 的密钥由 CO 保管。根密钥生成仪式，轮流在东西海岸进行。如果 HSM 出现问题或者根密钥出现紧急情况，需要 RKSH 赴美恢复 HSM，重新恢复根秘钥。根据 ICANN 制定的根密钥管理规则，没有 TCR 的参与，ICANN 是无法生成根密钥的。通过 TCR 的参与生成和管理根密钥，使 ICANN 的根密钥生成管理更加透明，形成了全球参与根密钥生成管理的局面。
DNSSEC 机制利用公钥信任链机制构建了可信的域名查询体系，全球根服务器中的互联网顶级域名数据需要利用根秘钥进行签名，保证数据的安全可信。DNSSEC 只是保证了 DNS 数据的可信性，但是，并没有对 DNS 数据本身进行加密。
（二）资源公钥基础设施协议通过公钥信任链应对路由通告伪造问题
作为支撑互联互通的互联网基础设施，域名系统和域间路由系统对互联网的安全有着至关重要的影响。由于边界网关协议（BGP）缺乏对路由通告内容真实性的保证，因此黑客的蓄意攻击以及错误的网络参数配置都可以导致路由劫持现象的发生。路由劫持对互联网的正常运行影响极大，可能导致大面积的网络瘫痪。于是，IETF 提出了资源公钥基础设施（RPKI）协议。RPKI 的概念最早便诞生于描述安全边界网关协议（S-BGP）方案的论文中。S-BGP 提出了一种附加签名的 BGP 消息格式，用以验证路由通告中 IP 地址前缀和传播路径上自治域（AS）号的绑定关系，从而避免路由劫持。基于这样的设计，数字证书和签名机制被引入BGP 范畴，并利用了公钥基础设施（PKI）。为验证路由通告签名者所持有的公钥，该签名者的 IP地址分配上级为其签发证书，一方面，验证其公钥，另一方面，验证该实体对某个 IP 地址前缀的所有权。基于 IP 地址资源分配关系而形成的公钥证书体系，RPKI 的基本框架就此形成。
RPKI 体系由三大关键模块组成：基础资源公钥证书体系（RPKI）、数字签名对象、储存 RPKI签名对象的分布式 RPKI 资料库。这三大模块能够确保一个实体验证谁是某个 IP 地址或者 AS 号码的合法持有者。RPKI 可以使 IP 地址的合法持有者授权某个 AS 作为该地址的路由源，并进行验证。这种可以验证的授权，可以用来构建更加安全的路由表过滤项。
为了推动 RPKI 的部署，RPKI 架构充分利用了现有的技术和实践。RPKI 的结构可与现有的资源分配体系对应，可以看作是目前资源管理组织运行模式的自然技术延伸，而且现有的资源分配和回收方式在这套新体系中都有明确地相关定义。
（三）传输服务协议通过公钥信任链应对域名证书伪造和客户端认证问题
互联网上用于安全认证的证书一般由被称为认证机构（CA）颁发。然而，CA 模型比较容易受攻击，在互联网上受信任的 CA 有成千上万个，这些 CA 在理论上可以颁发任何一个证书。一个 CA可能存在恶意颁发或者错误颁发不属于互联网域名使用者的证书，从而形成中间人攻击，造成互联网安全的隐患。IETF 在 RFC6698 技术标准中提出了基于 DNS 的名字实体认证协议（DANE）技术，DANE 可以通过称为传输层安全认证（TLSA）的DNS 资源记录进行域名证书的认证和颁发，使只有控制域名的实际控制人才能颁发相应域名的安全证书，保证了 TLS 证书的安全。DANE 使用 DNSSEC基础设施存储和签署密钥，以及 TLS 使用的证书。DANE 提供了将公钥绑定到 DNS 域名的机制。由于管理公钥数据和管理DNS 域名的实体是同一个，减少了利用域名进行中间人攻击的机会。与域名关联的密钥只能由该父级域名密钥签名与关联。例如，“example.cn”钥匙只能由“cn”的密钥签名，“cn”的密钥只能由 DNS 根钥匙签名。任何域名的签名密钥都可以通过使用标准 DNSSEC 协议查询和分发签名密钥，通过 DANE 可以部署用户自签名证书。原本自签名证书被认为是不安全的，但是通过DNSSEC 的加持，针对域名自有域名的自签名证书在 DANE 里可以安全使用。
2021 年，IETF 又成立了网络客户端 DANE 认证（DANCE）工作组，利用 DANE 加强网络客户端相关协议的安全。目前，相关技术标准正在制定过程中。各种传输服务协议可以通过 DANE 机制中的公钥信任链应对域名证书伪造和客户端认证问题，使通信更加安全。
三、互联网基础资源技术协议向保护隐私化发展
2013 年的斯诺登事件爆发后，IETF 的最高技术管理机构 IAB 组织了专门的技术研讨会，研讨如何加强互联网的隐私保护，防止中间人进行窃听和信息截取。IAB 认为，IETF 的技术协议需要全面加强端到端的加密，以避免中间人攻击。此后，IETF 的各项协议都加强了安全的考虑，以保护用户的隐私不被中间人截取，推动互联网协议向保护隐私化发展。
（一）互联网传输协议向快速安全连接QUIC 协议演进
快速 UDP 互联网连接（Quick UDP InternetConnection，QUIC）协议是以谷歌开发和部署的网络协议为基础进行研究的基础传输协议，并被IETF 进行了标准化工作。谷歌认为传输控制协议（TCP）存在诸多问题，想设计一种新的传输协议，在 2012 年提出基于 UDP 进行设计的思路，并在2013 年 8 月发布的 Chromium 版本 29 中首次公开。QUIC 是众多对 TCP 进行完善的传输层网络协议之一。QUIC 协议于 2021 年 5 月正式发布，并编号为RFC9000。
QUIC 可以被认为是数据报传输应用程序。使用 QUIC 的应用程序协议使用 UDP 端口 443 发送和接收数据包。QUIC 很好地解决了当今传输层和应用层面临的各种需求，包括处理更多的连接，具有更好的安全性和低延迟性。QUIC 基于 UDP 传输，融合了包括 TCP、安全传输层协议（TLS）、超文本传输协议第 2 版（HTTP/2）等协议的特性，使传输协议更加高效。QUIC 的一个主要目标就是减少连接延迟，当客户端第一次连接服务器时，QUIC 只需要 1 次往返时延（RTT）的延迟就可以建立可靠安全的连接，相对于 TCP+TLS 的 1 3次 RTT，前者要更加快捷。之后，客户端可以在本地缓存加密的认证信息，当再次与服务器建立连接时，可以实现 0 RTT 的延迟。QUIC 同时重复使用了 HTTP/2 协议的多路复用功能，而且利用 UDP 成功避免了 HTTP/2 的队头阻塞问题。
（二）DNS 传输协议向保护用户隐私方向发展
由于 DNS 的明文设计，因此用户查询域名DNS 数据会泄露用户的行为，同时，第三方服务器会收集用户的查询日志，DNS 隐私保护方面的技术发展主要包括 2 个方面。
一是查询最小化机制。即递归解析器每次只发送必要的查询信息，不向根和顶级服务器暴露完整的域名。同时，有研究者提出，将每次真实的查询混淆在多个虚拟查询中，及服务器主动进行热点域名广播等方法，用来缓解用户隐私泄露的风险。
二是基于 HTTPS 的 DNS（DoH）和基于 TCP的 DNS（DoT）机制，分别利用 HTTPS、TCP 技术，实现 DNS 的加密，二者的底层都是基于 TLS。目前，二者已相继发布为 IETF RFC 技术标准。IETF 成立DNS 隐私传输交换工作组，专门研究 DNS 隐私保护相关的课题，基于 QUIC 的 DNS（DoQ）也在该工作组推动过程中。另一方面，HTTP-over-QUIC已被命名为 HTTP/3。DoH/DoT 发布为正式标准后，IETF 隐私相关的议题主要集中在对具有加密技术的解析器的自动发现及递归到权威解析器的隐私加密机制研究方面。
（三）传输层安全协议进行扩展以支持更隐私化技术
TLS 1.3 是 IETF 制定的 TLS 新标准。TLS 用于保护 Web（以及更多其他领域），提供加密并确保每个 HTTPS 网站和应用程序编程接口（API）的真实性。TLS 1.3 所属的 RFC 8446 标准在 2018 年发布，这是该协议的第一次重大改革，带来了重大的安全性和性能改进。TLS 1.3 基于更早的 TLS 1.2，但与 TLS 1.2 也有较大的 区 别， 例 如，TLS1.3 可以减少协议握手的延迟时间，提高抗攻击性，设计将密钥协商和认证算法从密码包中分离出来，移除脆弱和较少使用的算法，例如移除信息摘要算法 （MD5）和安全散列算法（SHA-224）的支持等。TLS1.3 将大部分传输信息进行了加密处理，但是 TLS 1.3 提供的服务器名字指示信息（SNI）并未在发送客户端问候（ClientHello）会话时加密。第三方可以轻松获取 TLS 1.3 双方交换信息时的服务器名字指示信息。IETF 目前正在推动如何把服务器名字指示信息（SNI）也进行加密的技术（ECH）。如果 ECH技术部署后，通信双方的服务器名字指示信息（SNI）将进行加密，第三方很难获知 SNI 信息，使双方通信更加隐私化。
四、互联网基础资源技术协议向全面安全可信发展
互联网已经融入了生活和工作的方方面面，互联网传输的数据越来越重要。互联网基础资源技术协议的数据从明文传输方式，逐步过渡到认证明文数据的来源可靠性、完整性和防篡改性，并对部分核心数据进行了加密，对有些协议参数也进行了加密。通过签名、信任链和加密等方式保证了互联网数据传输的可靠性和安全性，减少了中间人获取隐私信息的可能。基于上述分析，可以有以下判断。
一是 QUIC 协议展现了比 TCP 协议更好的性能，互联网的 TCP 协议有可能被 QUIC 协议逐步取代。在未来十年，QUIC 协议将逐步蚕食 TCP 协议的领地，更多的应用程序将基于 QUIC 协议传输而不是 TCP 协议。
二 是 TLS 1.3 协议正在逐步得到部署，逐步取代旧版本的协议，如果未来配合ECH 技术的部署，使互联网的端到端传输更加安全可靠，但是这项技术可能导致利用服务器名字指示信息（SNI）进行安全策略管理的防火墙的部分功能失效。
三是 RPKI 由于存在信任链和信任锚的安全管理问题，短期内很难得到大规模部署。如果 RPKI操作不当，证书错误配置或者恶意撤销也会引发一系列的安全问题。
四是自从互联网全球域名根区部署 DNSSEC技术十多年以来，由于技术部署投入和带来的收益不成正比，因此目前部署率不是很高。在下一个十年，如果没有关键应用的支持，DNSSEC 也很难进行大规模普及应用。
（本文刊登于《中国信息安全》杂志2022年第4期）