HTTP/3

TCP创建链接时间

最先你们使用TCP来运输HTTP，TCP想必你们很熟悉了，须要三次握手，创建了TCP虚拟通道，那么这三次握手须要几个RTT（Round Trip Time的缩写，通俗地说，就是通讯一来一回的时间）时间呢？

 

 

 

一去 （SYN）

二回 （SYN+ACK）

三去 （ACK）

至关于一个半来回，故TCP链接的时间 = 1.5 RTT 。

 

HTTP交易时间

这意味着，用户在浏览器里输入的网址URL，直到时间流逝了1.5RTT以后，TCP才开始运输HTTP Request，浏览器收到服务器的HTTP Response，又要等待的时间为：

一去（HTTP Request）

二回 （HTTP Responses）

故HTTP的交易时间 = 1 RTT

HTTP通讯时间总和 = TCP链接时间 + HTTP交易时间 = 1.5 RTT + 1 RTT = 2.5 RTT

 

安全加密通讯

随着互联网的爆发式增加，人类发现彻底明文传输的HTTP通讯很不安全。作为OSI七层参考模型的现实实现的TCP/IP协议，在设计之初没有考虑安全加密的环节。

互联网先驱Netscape公司，创造性发明了SSL（Secure Socket Layer），SSL位于TCP与HTTP之间，作为HTTP的安全供应商，全权负责HTTP的安全加密工做。

IP / TCP / SSL / [HTTP]

各个通讯模块之间的站位如上所示，将HTTP用[ ]括起来，表示HTTP被SSL安全加密了。

随着SSL的名气攀升，互联网标准化组织IETF，以为SSL是一个好东西，就拿来用了。 

但SSL最初只是用于加密HTTP的，IETF以为这是一个硬伤，为何不能用来作为全部应用层协议的安全供应商呢？来传输邮件、文件、新闻等等。实现这一点很简单，只要在协议里增长一个Application Protocol 类型字段。

在Application Protocol 有一个类型是“IP”, 意味着TLS不只能够运输应用层协议如HTTP、FTP，还能够运输IP，这就是Cisco Any Connect的应用场景。

 

TLS (Transport Layer Security)

因而，IETF在SSL 3.0版本的基础上，从新设计并命名了这个协议，其全新的名字为TLS，最初的版本为1.0版本。从其名字就能够看出，其核心使命就是保证传输层的安全。各个通讯部门成员的占位与SSL占位一致：

IP / TCP / TLS / [HTTP]

到目前为止，浏览器支持的TLS版本为TLS 1.0、1.一、1.2，固然版本越高越成熟、越安全。

 

HTTPS

一般将TLS安全保护的HTTP通讯，称之为HTTPS，以区别于没有TLS安全防御的HTTP明文通讯。

 

来看看自从引入了TLS安全防御，看看HTTPS通讯的RTT增长到了多少？

TLS 1.2

以1.2 版本为例，看看HTTPS通讯一共要消耗几个RTT时间？

1. 浏览器给服务器发送的Client Hello消息（一去）

2. 服务器给浏览器发送的Server Hello消息（二回）

3. 浏览器给服务器发送的Key Exchange消息（三去）

双方的HTTP通讯将使用TLS加密了。一共花费了1.5个RTT时间。

HTTPS通讯时间总和 = TCP链接时间 + TLS 链接时间 + HTTP交易时间 = 1.5 RTT + 1.5 RTT + 1 RTT = 4 RTT

 

若是浏览器与服务器物理距离很近，RTT < 10 ms，即便4 RTT最大也不过40 ms的时间，用户压根感受不到慢。

若是浏览器与服务器相隔上万千米，一个RTT时间一般在200ms以上，4RTT时间一般在1秒以上，用户会明显感受到网速慢了。

 

HTTP 1.x

浏览器从服务器获取的一个页面，一般由不少资源连接所组成。

服务器给浏览器推送的第一个页面，页面里一般嵌入了图片资源文本连接、以及动态页面资源连接、或第三方网站的连接资源，还须要浏览器根据这些文本连接内容，去连接所对应的服务器，继续下载连接所对应的内容。

浏览器一般采用的流程是，从新创建一个TCP链接、TLS链接、HTTP交易。

这又是一个漫长的4RTT等待过程，用户看到浏览器完整页面的时间为

完整页面加载时间 = 4RTT *2 = 8RTT

 

HTTP /2

天然有人会问，既然第一次页面与第二次页面都是同一个网站服务器，为什么第二次页面要从新创建一个TCP链接，一个TLS链接？

若是重用第一个TCP链接，那么就少了1.5 RTT + 1.5 RTT = 3 RTT的时间。

这是一个好主意，就是用户的多个HTTP Request请求，使用同一个逻辑通道进行运输，这样会大大减小从新创建链接所花费的时间。

可是，这样会带来一个反作用，多个HTTP流使用同一个TCP链接，遵照同一个流量状态控制。只要第一个HTTP流遭遇到拥塞，剩下的HTTP流压根无法发出去，这就是头部阻塞（Head of line Blocking）。

 

IP / UDP / QUIC

QUIC协议集成了TCP可靠传输机制、TLS安全加密、HTTP /2 流量复用技术，其页面的加载时间为2.5 RTT时间。

此外，完成QUIC交易的链接的Session ID会缓存在浏览器内存里，若是用户再次打开该页面，无需创建TLS链接，直接使用缓存Session ID 对应的加密参数，服务器能够根据Session ID在缓存里查找对应的加密参数，并完成加密。

换句话说，重连TLS链接是一个0 RTT 事件，用户所要等待的页面加载事件 = HTTP交易事件 = 1 RTT。

 

HTTP /3

这一次IETF又以为QUIC是一个好东西，可是但愿QUIC不只能够运输HTTP，还能够运输其它协议，把QUIC与HTTP分离，最终各合伙人的占位以下所示：

IP / UDP / QUIC / HTTP

这样总体的页面加载时间为2 RTT。

 

TLS 1.3

IETF的QUIC标准集成了TLS 1.3版本，1.3版本更简练，创建TLS链接再也不须要1.5 RTT，而只须要1 RTT，是由于浏览器第一次就把本身的密钥交换的素材发给服务器，这样就节省了第三次消息，少了0.5个RTT时间。

页面的总体加载时间 = TLS 1.3链接时间 + HTTP交易时间 = 1RTT + 1RTT = 2 RTT

重连页面的加载时间 = HTTP交易时间 = 1 RTT

上文协议的进化过程就是人类与RTT斗争史，目标是减小用户等待页面加载时间、同时保证用户看到的页面安全，没有在传输过程当中被偷窥、篡改。

 

HTTP /3所带来的挑战

99%+以上的手机移动终端、电脑终端，都使用私有IP，都须要NAT设备来完成私有IP与全球IP的转换。这意味着NAT设备一般会记忆用户的通讯状态，一旦用户完成了通讯，NAT设备会释放这些记忆。

对于基于TCP的HTTP、HTTPS传输，NAT设备能够根据TCP报文头的SYN / FIN状态位，知道通讯何时开始，何时结束，对应记忆的开始、记忆的结束。

可是基于UDP传输的HTTP/3，NAT设备收到流量会知道链接何时开始，可是却没法知道流量何时结束。

NAT设备的记忆若是短于用户会话时间，则用户会话会中断。

NAT设备的记忆若是大大长于用户会话时间，则意味着NAT设备的端口资源会白白被占用！

最直接的解决方案是，在QUIC的头部模仿TCP的SYN/FIN状态，让沿途的NAT设备知道会话何时开始、何时结束。但这须要升级全球全部的NAT设备的软件