TLS1.3/QUIC 是怎样做到 0-RTT 的

发表于2018-03-10由daniel

在《低延迟与用户体验杂谈》中，我们提到了TLS1.3以及QUIC协议可以有效的降低传输层的延迟，改善用户体验。而TLS1.3和QUIC降低用户延迟有一个共同点，那就是在提供同等功能特性下，减少Round-Trip Time (RTT)次数。你甚至会经常听到QUIC和TLS1.3的拥趸说TLS1.3和QUIC可以做到0-RTT，基本消灭了（安全）传输层的延迟。事实真的是这样吗？

TLS RTT

我们先看一下TLS1.2 (以ECDH为例)的建立加密连接的过程:

从上图可以看出，在发送应用数据之前，TLS安全传输层需要经过2-RTT才能完成握手。如果是恢复会话，TLS1.2可以采用Session ID或Session Ticket进行快速握手：

从上图可以看到，在使用Session Ticket的情况下，需要1-RTT。

那么TLS1.3是如何进一步优化的呢？

TLS 1.3完全握手：

在完全握手情况下，TLS 1.3需要1-RTT建立连接。与TLS1.2有两点不同：握手过程中移除了ServerKeyExchange和ClientKeyExchange, DH (Diffie-Hellman) 参数通过 key_share 传输。

TLS1.3恢复会话握手

TLS1.3恢复会话可以直接发送加密后的应用数据，不需要额外的TLS握手。因此，我们常说的TLS1.3 0-RTT握手其实是指恢复加密传输层会话不需要额外的RTT。但是，在第一次进行完全握手时，是需要1-RTT的。

与TLS1.2比较，无论是完全握手还是恢复会话，TLS1.3均比TLS1.2少1-RTT。因此，TLS1.3从被提上draft草案开始获得了各方面的好评。从nginx和Chrome支持此特性的速度可见一斑。

但是TLS1.3也并不完美。TLS 1.3 O-RTT无法保证前向安全性(Forward secrecy). 简单讲就是，如果当攻击者通过某种手段获取到了Session Ticket Key，那么该攻击者可以解密以前的加密数据。

这个问题不是TLS1.3独有，TLS1.2也存在这个问题。对于TLS1.3来说，要缓解该问题可以通过设置ServerConfiguration中的Expiration Date字段，使得与Session Ticket Key相关的DH静态参数在短时间内过期（一般几个小时）。

使用TLS最多的场景是HTTPS和HTTP/2. 以HTTP/2为例，一个完整的 HTTP Request需要经历的RTT如下：

	HTTP/2 over TLS1.2首次连接	HTTP/2 over TLS1.2连接复用	HTTP/2 over TLS1.3首次连接	HTTP/2 over TLS1.3连接复用
DNS解析	1-RTT	0-RTT	1-RTT	0-RTT
TCP握手	1-RTT	0-RTT	1-RTT	0-RTT
TLS握手	2-RTT	1-RTT	1-RTT	0-RTT
HTTP Request	1-RTT	1-RTT	1-RTT	1-RTT
总计	5RTT	2-RTT	4-RTT	1-RTT

从上表可以看出：

首次连接发起HTTP请求是非常昂贵的。因此，如果你是用HTTPS作一些不可告人的代理应用的话，一定尽量保持长连接，避免频繁建立新连接。
连接的multlplexing(多路复用)可以有效减少RTT次数，降低延迟。在连接复用的情况下，TLS1.3将整个http request的RTT降低到了1个，达到理论的最小值。

QUIC RTT

当客户端首次发起QUIC连接时，客户端想服务器发送一个client hello消息，服务器回复一个server reject消息。该消息中有包括server config，类似于TLS1.3中的key_share交换。这需要产生1-RTT. 事实上，QUIC加密协议的作者也明确指出当前的QUIC加密协议是「注定要死掉的」(destined to die), 未来将会被TLS1.3代替。只是在QUIC提出来的时候，TLS1.3还没出生?，这只是一个临时的加密方案。
当客户端获取到server config以后，就可以直接计算出密钥，发送应用数据了，可以认为是0-RTT。密钥推导可以参见Key derivation.
因此，QUIC握手除去首次连接需要产生1-RTT，理论上，后续握手都是0-RTT的。
假设1-RTT=100ms, QUIC建立安全连接连接的握手开销为0ms, 功能上等价于TCP+TLS, 但是握手开销比建立普通的TCP连接延迟都低：

（正常体为首次建立连接的延迟，粗体部分为后续握手的延迟）

HTTP/2 over TLS 1.3 vs QUIC

当前，QUIC普遍的应用场景是 HTTP/2 over QUIC. 我们以一个完整的 HTTP Request需要经历的RTT为例，比较TLS1.3与QUIC的RTT开销：

	HTTP/2 over TLS1.3首次连接	HTTP/2 over TLS1.3连接复用	HTTP/2 over QUIC首次连接	HTTP/2 over QUIC连接复用
DNS解析	1-RTT	0-RTT	1-RTT	0-RTT
TCP握手	1-RTT	0-RTT	–	–
TLS握手	1-RTT	0-RTT	–	–
QUIC握手	–	–	1-RTT	0-RTT
HTTP Request	1-RTT	1-RTT	1-RTT	1-RTT
总计	4RTT	1-RTT	3-RTT	1-RTT

从上表可以看出：HTTP/2 over QUIC相比HTTP/2 over TLS 1.3最大的优势是首次连接是的RTT开销降低了1-RTT(25%)。在连接复用的情况，QUIC的RTT开销与TLS1.3相等。

前面我们提到，QUIC（UDP+QUIC Crypto）在功能层面等价于TCP+TLS, 并且其加密协议(QUIC Crypto)未来会被TLS1.3代替。而在连接复用的情况下QUIC与TLS1.3的RTT开销旗鼓相当，那么是否意味着在HTTP/2的应用场景下，TCP+TLS1.3就可以完全替代QUIC呢？答案是否定的，主要原因如下：

QUIC从数据包级别解决了队头阻塞的问题，而TCP+TLS只能解决http request级别的队头阻塞问题。具体原理可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么》.
QUIC与HTTP/2结合更加紧密，比如HTTP/2的stream, frame, Header Compression都可以直接映射到QUIC的stream, packet, Header Compression. 从协议分层看这会使得应用层和传输层紧耦合，但是在HTTP/2这个具体场景下，QUIC可以接管HTTP/2的拥塞控制，相较于HTTP/2 over TLS 1.3会受到TCP和HTTP/2两层的拥塞控制来说，无疑具有更直接有效的控制策略。并且，QUIC的拥塞控制是应用层可插件化的。虽然你也可以为TCP编写拥塞控制模块，但那是一个内核模块，稍不注意就会让系统崩溃。如果你有兴趣的话，实现一个QUIC的BBR拥塞控制模块是很容易的。
QUIC支持连接迁移（Connection Migration），即在客户端切换网络IP以后，也能够保持连接不间断。这对于移动网络这种漫游网络特别友好，再加上QUIC在首次连接上RTT比TLS1.3低25%，因此会有更好的用户体验。虽然Multipath TCP, MPTCP也可以吃支持连接迁移，但这受限于操作系统和网络协议栈，要想普及，任重道远。
QUIC支持Forward Error Correction，利用一定的数据包冗余，提供丢包时恢复丢包数据的能力。减少了包重传的数量，进而减少延迟，提高带宽利用率。如果你使用过kcptun，你会发现它也采用了FEC，对于弱网和高丢包环境下，效果尤其好。

当然，QUIC也是有缺点的。比如很多运营商对UDP的QoS级别是比TCP低的，甚至只允许DNS 53端口的UDP包，其他UDP包都是被封掉的。在IDC中，UDP的优先级一般也比TCP低。因此，即使以后大规模普及QUIC，也不会完全替代TCP+TLS，毕竟需要确保在QUIC不可用时，可以回落到TCP+TLS.

总结

在首次连接的时候，无论是TLS1.3还是QUIC都需要1-RTT，在连接复用的情况下，两者才能做到0-RTT. 在HTTP/2的应用场景中，QUIC可以有效的降低首次连接的RTT次数，并且支持连接迁移、FEC以及更加灵活高效的拥塞控制，因此可以在移动网络、弱网环境提供低延迟的用户体验。

扩展阅读

Ubuntu 14.04开启nginx http2支持的方法

发表于2018-03-01由daniel

再过不到两个月，Ubuntu18.04就要出来了，但是手上还有一些老机器还停留在14.04?：

Ubuntu 18.04 release date:

30th November: Feature Definition Freeze
4th January: Alpha 1 release
1st February: Alpha 2 release
1st March: Feature Freeze
8th March: First beta release
5th April: Final beta release
19th April: Final Freeze
26th April: Stable Ubuntu 18.04 LTS release

Ubuntu 18.04 release date:

30th November: Feature Definition Freeze

4th January: Alpha 1 release

1st February: Alpha 2 release

1st March: Feature Freeze

8th March: First beta release

5th April: Final beta release

19th April: Final Freeze

26th April: Stable Ubuntu 18.04 LTS release

没有足够的时间和动力来升级这几台老机器，但是一些常用的软件准备顺手升级一下。最基本的自然是升级nginx支持http2. http2的优势可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么？》以及《低延迟与用户体验杂谈》。

Ubuntu 14.04开启nginx http2支持的前置条件

nginx >=1.9.5
openSSL >= 1.0.2

第一个条件大家一般都不会漏掉。但是第二个条件一般是http2无法成功开启时才发现。这是因为随14.04一起分发的openSSL版本是1.0.1f. 那么要开启http2支持，有两种方式：

使用他人编译好的ngingx with http2 support package安装；
升级本地openSSL版本，然后从源码编译安装。

而随Ubuntu 18.04一起分发的openSSL版本为1.1.0g, 因此不存在这个问题。

使用packaege安装（懒人专用）

这里需要注意一下，很多为提供14.04提供nginx安装包的源虽然可以让你安装更高版本的nginx，但是大多是使用openSSL 1.0.1编译的，因此无法支持http2, 比如jessis, nginx mainline为14.04提供的安装包是使用1.0.1编译的，因此不支持http2的。这里我们使用ondrej提供的源。

卸载已经安装的nginx（会保留配置文件，take is easy）:

sudo apt-get remove nginx nginx-common

1 2	sudo apt-get remove nginx nginx-common

添加ondrej nginx安装源：

sudo add-apt-repository ppa:ondrej/nginx

1 2	sudo add-apt-repository ppa:ondrej/nginx

如果出现如下错误：

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 92: ordinal not in range(128)

1 2	UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 92: ordinal not in range(128)

应该是终端编码问题，尝试使用LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/nginx解决。

更新源，并安装：

sudo apt-get update
sudo apt-get install nginx

sudo apt-get update

sudo apt-get install nginx

从源码安装

修改nginx配置开启http2

设置nginx支持http2最关键是在https端口添加http2指令：

listen 443 ssl http2;

1 2	listen 443 ssl http2;

一个网站的参考配置模板如下：

server {
  listen              443 ssl http2;
  ssl_certificate     your_chained.pem;
  ssl_certificate_key your_domain.key;
  ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers         HIGH:!aNULL:!MD5;

  server_name your_domain.com;

  location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://127.0.0.1:18010;
  }
}

server {

listen 443 ssl http2;

ssl_certificate your_chained.pem;

ssl_certificate_key your_domain.key;

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

ssl_ciphers HIGH:!aNULL:!MD5;

server_name your_domain.com;

location / {

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header Host $host;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_pass http://127.0.0.1:18010;

}

小结

nginx开启http2的支持不要忘记了对openSSL最低版本的要求。其实http2已经不再时髦啦，http2+TLS1.3才是未来，可以参见《低延迟与用户体验杂谈》。后面会讲讲docker+nginx开启http2和TLS1.3的方式，这种方式即可以方便的尝试各个nginx版本，同时也不会破坏本地的nginx环境。

低延迟与用户体验杂谈

发表于2018-02-27由daniel

最近在做系统设计梳理的时候，明显感觉到「低延迟」已经成为被提及越来越频繁、考量权重越来越大的因素。并且，越是靠用户近的系统，对延迟越敏感，对用户体验影响越大，对低延迟要求越高。

HTTP/2如今（2018.02）已经逐渐普及，其设计的第一目标就是降低延迟。主要采用了两个手段来解决：

TCP连接复用。连接复用减少了TCP每次握手带来的延迟，同时避免了每次新建TCP连接的窗口慢启动带来的数据吞吐开启延迟。
使用数据分帧解决队头阻塞问题。当然，这个问题HTTP/2解决得不彻底，具体可以参见《当我们在谈论HTTP队头阻塞时，我们在谈论什么？》了解细节。

HTTP/2毕竟只能解决应用层的低延迟问题。如果要继续降级延迟，就需要下潜到传输层。因此，Google的QUIC和TLS 1.3应运而生。QUIC目前主要是Google主导，除去其自家的服务，如Google搜索首页，G+等，支持的网站还非常少。TLS 1.3则由标准化组织加持，目前在最新的OpenSSL、nginx已经支持。TLS 1.3能够做到新连接3RTT，恢复连接2RTT（TLS 1.2分别是4RTT, 3RTT；而2RTT已经与http的RTT持平！），的确非常吸引人。

回顾WEB技术过去十几年的发展，很多的特性引入和改进都是基于降低延迟。有些是技术层面的，比如上面提到的HTTP/2的低延迟设计、DNS查询缓存、HTTP1.1并发多个TCP连接请求资源、雪碧图等；有些是用户体验层面的，比如异步加载/预加载js资源、优先加载影响首屏渲染的CSS资源、避免使用大表布局、图片渐变加载、过渡动画等。

而这些年技术层面的发展其实都是受物理定律限制的。祭出程序员延迟心经Latency Numbers Every Programmer Should Know:

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
Disk seek                           10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from disk    20,000,000   ns   20,000 us   20 ms  80x memory, 20X SSD
Send packet CA-&gt;Netherlands-&gt;CA    150,000,000   ns  150,000 us  150 ms

Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Credit
------
By Jeff Dean:               http://research.google.com/people/jeff/
Originally by Peter Norvig: http://norvig.com/21-days.html#answers

Contributions
-------------
Some updates from:       https://gist.github.com/2843375
'Humanized' comparison:  https://gist.github.com/2843375
Visual comparison chart: http://i.imgur.com/k0t1e.png
Animated presentation:   http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/latency.txt

Latency Comparison Numbers

--------------------------

L1 cache reference 0.5 ns

Branch mispredict 5 ns

L2 cache reference 7 ns 14x L1 cache

Mutex lock/unlock 25 ns

Main memory reference 100 ns 20x L2 cache, 200x L1 cache

Compress 1K bytes with Zippy 3,000 ns 3 us

Send 1K bytes over 1 Gbps network 10,000 ns 10 us

Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD

Read 1 MB sequentially from memory 250,000 ns 250 us

Round trip within same datacenter 500,000 ns 500 us

Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory

Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip

Read 1 MB sequentially from disk 20,000,000 ns 20,000 us 20 ms 80x memory, 20X SSD

Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms

Notes

-----

1 ns = 10^-9 seconds

1 us = 10^-6 seconds = 1,000 ns

1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

Credit

------

By Jeff Dean: http://research.google.com/people/jeff/

Originally by Peter Norvig: http://norvig.com/21-days.html#answers

Contributions

-------------

Some updates from: https://gist.github.com/2843375

'Humanized' comparison: https://gist.github.com/2843375

Visual comparison chart: http://i.imgur.com/k0t1e.png

Animated presentation: http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/latency.txt

软件工程师无论是做什么职位和方向，心里都应该对此有B树。

有了这些当前人类所认识的物理极限，才能做到在「在边界内做事情」(这句话不是我说的，第一次看到这句话是吴军老师的《硅谷来信》)。

举个例子，当前人类认知范围内最快的速度是光速，这是一个上限，而广泛使用的光纤通信速度大概是光速的2/3。那么，要想优化上海到加州的网络延迟，无论你如何优化线缆布设以及质量，RTT都不可能低于127ms. 因此，如你所见，这些年虽然新架设了不少新的跨太平洋光缆，但是最优网络延迟没有什么太大变化，反倒是这些光缆带来的扩容让网络拥塞得到了缓解，让我们感觉出口网络「好像」更快了。

那么在光速这个物理边界的限制下，我们要如何降低延迟呢？显然，固定的两点之间的网络延迟是无法突破该边界的（这里不讨论空间扭曲力场?‍♀️）。但是，很多时候，我们要解决的问题是「让用户感觉延迟低」就可以了。

在这个思想下，CDN应运而生。将内容分发到距离用户近的网络节点来降低用户访问延迟。这个idea非常简单，甚至简陋，但是非常有效，并且廉价。

顺着这个思路下去，如果把算力分发到距离用户近的节点，那是不是也可以让用户觉得计算任务也变快了呢？在一定程度上，这是可以做到的。比如，我们使用了数十年运行于浏览器的javascript，以及我们的多IDC、多主架构方案，都有这方面的考量。近来流行的serverless、边缘计算其实也可以是认为是将算力部署到离用户尽可能近的物理位置或业务流程中。

有时候，技术参数指标的提升在短期内是难以低成本解决的。这个时候，尽量避免死磕参数，投入100%的精力去换取1%的性能提升。可以尝试从设计交互上给用户形成反应很快的体验，降低体感延迟。比如，1）耗时的任务后台化并给出进度条；2）区块处理的逻辑任务尝试修改成流处理，加速部分处理结果的输出，典型应用如以视频直播服务为代表的流媒体服务全力优化首屏播放延迟；批处理任务每处理完一个子任务就反馈结果等。

不仅软件系统的延迟影响着用户体验，硬件更是如此。现在人们普遍认为iPhone的用户体验是优于安卓的。因素有很多，那些复杂的系统参数普通用户未必搞得懂，但是很多用户却承认在滑动屏幕的时候iPhone比安卓更加「跟手指」，打开应用也「感觉更快」。「跟手指」这个体验跟苹果的软件+硬件的技术优化有关，目前安卓阵营也没有赶上。打开app快则是典型的交互优化：苹果打开app未必真的比安卓快，但是从点击app图标到显示story board的确非常快。无论苹果是否鸡贼，至少从这个层面看，它的确是非常了解延迟与用户体验之间的奥义的。至于苹果每次升级系统「故意」让老设备变卡……咳，咳，同学，你怎么有又抬杠呢?

喜欢汽车并且喜欢驾驶的朋友一定知道甚至深入研究过这几款车：马自达3/6/BRZ/86-宝马M2/M4-保时捷718/911。排名分先后，每一辆都是不同级别的驾驶者之车，也是很多玩车朋友的玩车升级路线。这些车都是「运动取向」，这是一个非常抽象的概念，普通消费者未必明白，但是你会发现他们的消费者大多会用「操控好」「响应快」来评价这些车。如果你是参数党，你会发现其实这些车在同级别中都不是最好的，但却是给人愉悦感最强的。

由物及人，当上司交给你一个任务的时候，有反馈好过无反馈，快反馈好过慢反馈。

总结

在节奏日益变快的今天，低延迟很多时候意味着良好的用户体验。而做到低延迟可以通过技术优化，也可以通过一些产品的交互方式和有选择的强调某些方面来让用户感觉很快。内容比较分散，但是都是顺着这根主线，希望你也有所思考和收获。

参考文献

Introducing Zero Round Trip Time Resumption (0-RTT)

行思錄 | Travel Coder

Arch, Coding, Life

标签归档：TLS1.3