0-RTT#
0-RTT: Zero round-trip time
这是 TLS1.3 新加的一个特性.
用途: 可以用于快速的发送一部分数据
“快速” 的含义：通常的 TLS 连接， 只有 TLS 握手成功之后， 才能开始发送应用层数据。但是当使用 0-RTT 特性发送消息时， 不需要等待握手结束，便可以提交发送一小部分数据。 因为不需要等待 TLS 握手流程进行完毕，因此比较快。
代价是牺牲部分 TLS 的安全性。
如何工作的？#
并不是任何情况下都能直接发送 0-RTT 数据包。 客户端需要提前有一个和服务器端共享的 PSK.
这个 PSK 的获取方式可以是： 从之前的链接上获取，或者通过其他外部方式。
这里的 PSK 主要用于 TLS 1.3 会话恢复(session resumption)，
也就是意味着客户端和服务器已经有一组共享的密钥，可以用来生成加解密 0-RTT 数据的密钥(0-RTT traffic keys)
如下流程， 0-RTT 数据直接跟在客户端的 ClientHello 之后或者 Change Cipher Spec 之后.()
(Change Cipher Spec 在 TLS1.3 中不是必须的，但是为了兼容旧的版本，允许发送 Change Cipher Spec)
Client Server ClientHello+ early_data+ key_share*+ psk_key_exchange_modes+ pre_shared_key(Application Data*)（0-RTT Data） --------> ServerHello + pre_shared_key + key_share* {EncryptedExtensions} + early_data* {Finished} <-------- [Application Data*](EndOfEarlyData){Finished} -------->[Application Data] <-------> [Application Data] Figure 4: Message Flow for a 0-RTT Handshake代价#
0-RTT 数据的安全性是明显弱于正常握手后发送的 TLS 数据的。
尤其是以下几点：
- 这些数据的不是前向保密的(forward secret)。 因为加密这些数据的密钥是从
PSK直接生成的。 - 不能保证这些数据在不同链接上不会被重播(replay)。 1-RTT 数据的防止重播 的机制是依赖于
ServerHello.Random的值，而0-RTT数据的加密不依赖于这个值，因此没有这样的保护。
实例#
1-5 是前一个连接， 主要是为了获取 PSK, 这里的 PSK 由服务器端发送的 New Session Ticket 得到。
6-9 是当前连接(一条新的连接)。 我们注意到红框圈起来的部分便是 0-RTT 数据。 它是直接跟在 Change Cipher Spec 之后的， 也就是我们当前连接的 TCP 连接建立起来之后， 直接便发送 Client Hello, Change Cipher Spec 和 0-RTT 数据， 而不需要等待 TLS 握手完成。
这里我们在第 6 步便把数据发送出去了， 第 8 步才是 TLS 握手成功的节点。
这里依然有一些细节需要注意，我们下面逐一解析：
[5] NewSessionTicket.early_data#
Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: New Session Ticket Opaque Type: Application Data (23) Version: TLS 1.2 (0x0303) Length: 82 Handshake Protocol: New Session Ticket Handshake Type: New Session Ticket (4) Length: 61 TLS Session Ticket Session Ticket Lifetime Hint: 7200 seconds (2 hours) Session Ticket Age Add: 953680565 Session Ticket Nonce Length: 8 Session Ticket Nonce: 0000000000000001 Session Ticket Length: 32 Session Ticket: ....af85e4152440 Extensions Length: 8 Extension: early_data (len=4) Type: early_data (42) Length: 4 Maximum Early Data Size: 16384第 5 步中的 New Session Ticket 携带了一个扩展 early_data, 用于表明当前 Session ticket 可以用于发送 0-RTT 数据。
并且这个 early_data 中携带一个 Maximum Early Data Size 表明服务器端愿意接收 0-RTT 数据的最大值，超过这个值会被拒绝。 （这也就是我们开始说可以发送“一部分数据”的原因了， 不能像 1-RTT 那样发送任意数量的数据)
[6] ClientHello.early_data#
Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 309 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 305 Version: TLS 1.2 (0x0303) Random: ...1081762b162 Session ID Length: 32 Session ID: ,,,8218132ba7 Cipher Suites Length: 8 Cipher Suites (4 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 224 .... Extension: early_data (len=0) Type: early_data (42) Length: 0 Extension: pre_shared_key (len=91) Type: pre_shared_key (41) Length: 91 Pre-Shared Key extension Identities Length: 38 PSK Identity (length: 32) PSK Binders length: 49 PSK Binders early_data 扩展：这个扩展没有实际数据，就是一个标识符，表明当前握手过程中，客户端会发送 0-RTT 数据。
这里同时还要携带 pre_shared_key（这是前提）， 并且这是使用的 PSK 必须是从带有 early_data 扩展的 New Session Ticket 中计算得来的。
[7] EncryptedExtensions.early_data#
Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Encrypted Extensions Opaque Type: Application Data (23) Version: TLS 1.2 (0x0303) Length: 27 [Content Type: Handshake (22)] Handshake Protocol: Encrypted Extensions Handshake Type: Encrypted Extensions (8) Length: 6 Extensions Length: 4 Extension: early_data (len=0) Type: early_data (42) Length: 0early_data 扩展： 用于向客户端表明服务器端接受了客户端的 0-RTT 数据。
[8] EndOfEarlyData#
Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: End of Early Data Opaque Type: Application Data (23) Version: TLS 1.2 (0x0303) Length: 21 [Content Type: Handshake (22)] Handshake Protocol: End of Early Data Handshake Type: End of Early Data (5) Length: 0EndOfEarlyData 是客户端发送给服务器的一个消息， 用于表明自己的 0-RTT 数据已经发送完毕，解析来的数据将是平常的 TLS 加密的数据了。
这个消息也是空的，只是用于表明自己 0-RTT发送完毕了。
实例: 0-RTT数据被拒绝#
也存在一些场景，客户端发送的 0-RTT 数据不被服务器端接受.这里我们来看看响应的流程.
(这里我是用一个过期的 PSK 来模拟这种场景的)
在步骤 1 中, 我们依然是发送 ClientHello 以及相应的 0-RTT 数据(Application Data 中)
ClientHello 中依然携带 pre_shared_key 和 early_data 扩展. 但是这里的 pre_shared_key 是已经过期了. 因此,此次 TLS 会话恢复(Session resumption) 会失败,因此服务器端无法正常解密我们的 0-RTT 数据,因此拒绝接受它.
在步骤 2中, 服务器回复的 Encrypted Extensions 中便没有携带 early_data 扩展, 以表示不接受我们的 0-RTT 数据.
Transport Layer Security TLSv1.3 Record Layer: Handshake Protocol: Encrypted Extensions Opaque Type: Application Data (23) Version: TLS 1.2 (0x0303) Length: 23 [Content Type: Handshake (22)] Handshake Protocol: Encrypted Extensions Handshake Type: Encrypted Extensions (8) Length: 2 Extensions Length: 0因为,客户端的 0-RTT 已经被明确的拒绝接受了,因此,客户端也不需要再发送 EndOfEarlyData 消息了.