QUIC的0-RTT和TLS介绍

0-RTT

The handshake is structured to permit the exchange of application data as soon as possible. This includes an option for clients to send data immediately (0-RTT), which requires some form of prior communication or configuration to enable.
handshake被构造为允许尽快交换应用程序数据。
这包括客户端立即发送数据（0-RTT）的选项，这需要某种形式的事先通信或配置才能启用。

0-RTT allows application data to be sent by a client before receiving a response from the server. However, 0-RTT provides no protection against replay attacks.
C端接收到S侧的 ACK 前，就发送数据，同时引入了响应攻击（replay attacks）
A server can also send application data to a client before it receives the final cryptographic handshake messages that allow it to confirm the identity and liveness of the client.
S 端还可以在接收最终的加密握手消息（确认客户端的身份 identity 和活动性 liveness ）之前向 C 端发送应用程序数据
These capabilities allow an application protocol to offer the option of trading some security guarantees for reduced latency.
这些功能允许应用程序协议提供选项用于某些安全保证换取延迟降低（ offer the option of trading some security guarantees for reduced latency）
（Trading A for B：拿 A 去换取 B）

Values of Transport Parameters for 0-RTT

Using 0-RTT depends on both client and server using protocol parameters that were negotiated from a previous connection. To enable 0-RTT, endpoints store the values of the server transport parameters with any session tickets it receives on the connection. Endpoints also store any information required by the application protocol or cryptographic handshake. The values of stored transport parameters are used when attempting 0-RTT using the session tickets.

使用 0-RTT 取决于客户端和服务器使用从上一个连接协商的协议参数（protocol parameters that were negotiated from a previous connection，个人理解，因为本次连接还没完成）

为了启用 0-RTT，端点将服务端传输参数（server transport parameters）的值与它在连接上收到的任何会话票证（session tickets）一起存储。端点还存储应用程序协议/加密握手所需的任何信息。当使用会话票证尝试 0-RTT 时，将使用存储的传输参数

Remembered transport parameters apply to the new connection until the handshake completes and the client starts sending 1-RTT packets. Once the handshake completes, the client uses the transport parameters established in the handshake. Not all transport parameters are remembered, as some do not apply to future connections or they have no effect on the use of 0-RTT.

记住的传输参数（Remembered transport parameters）适用于新连接，直到握手完成并且客户端开始发送 1-RTT 数据包（until the handshake completes and the client starts sending 1-RTT packets），一旦握手完成，客户端将使用握手中建立的传输参数
并非所有传输参数都会被记住，因为有些参数不适用于未来的连接，或者它们对 0-RTT 的使用没有影响。

The definition of a new transport parameter MUST specify whether storing the transport parameter for 0-RTT is mandatory, optional, or prohibited. A client need not store a transport parameter it cannot process.

新的传输参数的定义，必须指定（MUST specify ）：为 0-RTT 存储传输参数是强制的、可选的还是禁止的
客户端不需要存储它不能处理的传输参数

A client MUST NOT use remembered values for the following parameters: ack_delay_exponent, max_ack_delay, initial_source_connection_id, original_destination_connection_id, preferred_address, retry_source_connection_id, and stateless_reset_token. The client MUST use the server’s new values in the handshake instead; if the server does not provide new values, the default values are used.

客户端绝对不能使用以下参数的记忆值（remembered values ）:
ack_delay_exponent、max_ack_delay、initial_source_connection_id、original_destination_connection_id、preferred_address、retry_source_connection_id和stateless_reset_token。
客户端必须在握手时使用服务器的新值；如果服务器不提供新值，则使用默认值

A client that attempts to send 0-RTT data MUST remember all other transport parameters used by the server that it is able to process. The server can remember these transport parameters or can store an integrity-protected copy of the values in the ticket and recover the information when accepting 0-RTT data. A server uses the transport parameters in determining whether to accept 0-RTT data.¶
试图发送 0-RTT 数据的客户端，必须记住服务器能够处理的所有其他传输参数
服务器可以记住这些传输参数，或者可以存储 ticket 中 values 的完整性保护副本（an integrity-protected copy of the values ），并在接受 0-RTT 数据时，恢复信息
服务器使用传输参数来决定是否接受 0-RTT 数据

If 0-RTT data is accepted by the server, the server MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data. In particular, a server that accepts 0-RTT data MUST NOT set values for the following parameters that are smaller than the remembered values of the parameters.
如果 0-RTT 数据被服务器接受，服务器绝对不能降低任何限制 / 更改客户端可能违反的 0-RTT 数据的任何值
特别地，一个接受 0-RTT 数据的服务器，绝对不能为以下参数设置小于参数记忆值的值

• active_connection_id_limit
• initial_max_data
• initial_max_stream_data_bidi_local
• initial_max_stream_data_bidi_remote
• initial_max_stream_data_uni
• initial_max_streams_bidi
• initial_max_streams_uni

Omitting or setting a zero value for certain transport parameters can result in 0-RTT data being enabled but not usable. The applicable subset of transport parameters that permit the sending of application data SHOULD be set to non-zero values for 0-RTT. This includes initial_max_data and either (1) initial_max_streams_bidi and initial_max_stream_data_bidi_remote or (2) initial_max_streams_uni and initial_max_stream_data_uni.

省略/设置某些传输参数的零值，可能导致启用 0-RTT 数据，但无法使用。对于 0-RTT，允许发送的应用程序数据（permit the sending of application data）的传输参数的可用子集（applicable subset）应该设置为非零值

这包括如下之一
initial_max_data和 initial_max_stream_data_bidi_remote
initial_max_streams_uni和initial_max_stream_data_uni

A server might provide larger initial stream flow control limits for streams than the remembered values that a client applies when sending 0-RTT. Once the handshake completes, the client updates the flow control limits on all sending streams using the updated values of initial_max_stream_data_bidi_remote and initial_max_stream_data_uni.

服务器可能为流提供更大的初始流控限制（比客户端在发送 0-RTT 时应用的记住值 the remembered values还大 ）
一旦握手完成，客户端使用 initial_max_stream_data_bidi_remote 和 initial_max_stream_data_uni的更新值，更新所有发送流（all sending streams）的流控限制

A server MAY store and recover the previously sent values of the max_idle_timeout, max_udp_payload_size, and disable_active_migration parameters and reject 0-RTT if it selects smaller values. Lowering the values of these parameters while also accepting 0-RTT data could degrade the performance of the connection. Specifically, lowering the max_udp_payload_size could result in dropped packets, leading to worse performance compared to rejecting 0-RTT data outright.

服务器可以存储和恢复之前发送的 max_idle_timeout, max_udp_payload_siz e和disable_active_migration 参数的值，如果选择较小的值，则拒绝 0-RTT
在接受 0-RTT 数据的同时降低这些参数的值可能会降低连接的性能
具体来说（Specifically），降低 max_udp_payload_size 可能会导致丢包，与直接（outright）拒绝 0-RTT 数据相比，这会导致更差的性能

A server MUST reject 0-RTT data if the restored values for transport parameters cannot be supported.
如果不支持传输参数的恢复值，服务器必须拒绝 0-RTT 数据

When sending frames in 0-RTT packets, a client MUST only use remembered transport parameters; importantly, it MUST NOT use updated values that it learns from the server’s updated transport parameters or from frames received in 1-RTT packets. Updated values of transport parameters from the handshake apply only to 1-RTT packets. For instance, flow control limits from remembered transport parameters apply to all 0-RTT packets even if those values are increased by the handshake or by frames sent in 1-RTT packets. A server MAY treat the use of updated transport parameters in 0-RTT as a connection error of type PROTOCOL_VIOLATION.
当在 0-RTT 包中发送帧时，客户端必须只能使用记住的传输参数（remembered transport parameters），绝对不能使用从服务器更新的传输参数 / 从 1-RTT 数据包中接收到的帧中学习到的更新值；从握手开始更新的传输参数值，只适用于 1-RTT 报文
例如，记住的传输参数的流控限制适用于所有 0-RTT 数据包，即使这些值通过握手或在 1-RTT 数据包中发送的帧而增加
服务器可能会将 0-RTT 中使用更新的传输参数（the use of updated transport parameters）视为“类型为协议违反的连接错误”
（个人理解：专款专用）

A 0-RTT packet uses long headers with a type value of 0x01, followed by the Length and Packet Number fields The first byte contains the Reserved and Packet Number Length bits.
A 0-RTT packet is used to carry “early” data from the client to the server as part of the first flight, prior to handshake completion. As part of the TLS handshake, the server can accept or reject this early data.
0-RTT包用于在握手完成之前，将“早期”数据（“early” data）作为第一次飞行的一部分（part of the first flight）从客户端传送到服务器。
作为 TLS 握手的一部分，服务器可以接受/拒绝这些早期数据

Packet numbers for 0-RTT protected packets use the same space as 1-RTT protected packets.
After a client receives a Retry packet, 0-RTT packets are likely to have been lost or discarded by the server. A client SHOULD attempt to resend data in 0-RTT packets after it sends a new Initial packet. New packet numbers MUST be used for any new packets that are sent; as described in Section 17.2.5.3, reusing packet numbers could compromise packet protection.
0-RTT 保护数据包（0-RTT protected packets）的数据包编号与 1-RTT 保护数据包（1-RTT protected packets）使用相同的空间

客户端收到 Retry 数据包（Retry packet）后，0-RTT 数据包很可能已丢失/被服务器丢弃。
客户端在发送新的初始数据包后，应尝试重发 0-RTT 数据包中的数据（resend data in 0-RTT packets）
New packet numbers MUST be used for any new packets that are sent，要发送的新包必须使用新的 packet numbers，重复使用数据包编号可能会损害数据包保护（compromise packet protection）

A client only receives acknowledgments for its 0-RTT packets once the handshake is complete.
A client MUST NOT send 0-RTT packets once it starts processing 1-RTT packets from the server. This means that 0-RTT packets cannot contain any response to frames from 1-RTT packets. For instance, a client cannot send an ACK frame in a 0-RTT packet, because that can only acknowledge a 1-RTT packet. An acknowledgment for a 1-RTT packet MUST be carried in a 1-RTT packet.

客户端只有在握手完成后才会收到 0-RTT 数据包的确认
（不是0-RTT没有ACK，只是握手完成后才有）

客户端一旦开始处理来自服务器的 1-RTT 数据包，就不能发送 0-RTT 数据包。这意味着 0-RTT 报文不能包含对 1-RTT 报文帧的任何响应（0-RTT packets cannot contain any response to frames from 1-RTT packets）。
例如，客户端不能在 0-RTT 报文中发送 ACK 帧，因为 ACK 帧只能确认 1-RTT 报文。对 1-RTT 包的确认必须在 1-RTT 包中携带。

A server SHOULD treat a violation of remembered limits (Section 7.4.1) as a connection error of an appropriate type (for instance, a FLOW_CONTROL_ERROR for exceeding stream data limits).
服务器应该将违反记住的限制视为适当类型的连接错误
（例如，超过流数据限制的 FLOW_CONTROL_ERROR）

TLS

Transport Layer Security (TLS)
how QUIC [QUIC-TRANSPORT] is secured using TLS [TLS13].

TLS 1.3 provides critical latency improvements for connection establishment over previous versions.
（与以前的版本相比，TLS 1.3 为建立连接提供了关键的延迟改进）
Absent packet loss, most new connections can be established and secured within a single round trip; on subsequent connections between the same client and server, the client can often send application data immediately, that is, using a zero round-trip setup.
在没有数据包丢失的情况下，大多数新连接都可以在一次往返中建立和保护；在同一客户端和服务器之间的后续连接中，客户端通常可以立即发送应用程序数据，即使用零往返设置（zero round-trip setup）。

TLS provides two endpoints with a way to establish a means of communication over an untrusted medium (for example, the Internet). TLS enables authentication of peers and provides confidentiality (ˌkɒnfɪˌdenʃiˈæləti, 机密性) and integrity protection for messages that endpoints exchange.
TLS 为两个端点提供了一种通过不受信任的介质（例如 Internet）建立通信方式的方法。TLS 支持对等方进行身份验证，并为终结点交换的消息提供机密性和完整性保护。
Each content-layer message (e.g., handshake, alerts, and application data) is carried as a series of typed TLS records by the record layer. Records are individually cryptographically protected and then transmitted over a reliable transport (typically TCP), which provides sequencing and guaranteed delivery.每个内容层消息（例如握手、警报和应用程序数据）都由记录层（the record layer）作为一系列类型化的 TLS 记录（a series of typed TLS records）进行传输。记录（Records）受到单独加密保护（are individually cryptographically protected），然后通过可靠的transport（通常是 TCP）传输，该传输提供排序和保证传递（provides sequencing and guaranteed delivery）

The TLS authenticated key exchange（密钥交换） occurs between two endpoints: client and server. The client initiates the exchange and the server responds. If the key exchange completes successfully, both client and server will agree on a secret. TLS supports both pre-shared key (PSK) and Diffie-Hellman over either finite fields or elliptic curves ((EC)DHE) key exchanges（有限域/椭圆曲线）. PSK is the basis for Early Data (0-RTT); the latter provides forward secrecy (FS) when the (EC)DHE keys are destroyed. The two modes can also be combined to provide forward secrecy while using the PSK for authentication.
TLS 身份验证密钥交换发生在两个终结点之间：客户端和服务器。客户端启动交换，服务器响应。如果密钥交换成功完成，则客户端和服务器将就密钥达成一致。
TLS 支持有限域或椭圆曲线 （（EC）DHE） 密钥交换上的预共享密钥 （PSK） 和 Diffie-Hellman。
PSK 是早期数据（Early Data） （0-RTT） 的基础
Diffie-Hellman 在 （EC）DHE 密钥被销毁时提供前向保密 （forward secrecy，FS）
这两种模式可组合使用，以在使用 PSK 进行身份验证的同时，提供前向保密

After completing the TLS handshake, the client will have learned（强调某个动作在将来某个特定时间点之前完成，并且对那个时间点产生一定的影响） and authenticated an identity for the server, and the server is optionally able to learn and authenticate an identity for the client.
TLS supports X.509 [RFC5280] certificate-based authentication（基于证书的认证） for both server and client. When PSK key exchange is used (as in resumption，比如在恢复中), knowledge of the PSK serves to authenticate the peer（这说的是服务端吧）.
完成 TLS 握手后，客户端将学习并验证服务器的身份，并且服务器可以选择学习和验证客户端的身份。
TLS 支持服务器和客户端的 X.509 [RFC5280] 基于证书的身份验证。当使用 PSK 密钥交换时（如在恢复中），PSK 的知识用于对对等方进行身份验证。

The TLS key exchange is resistant（rɪˈzɪstənt） to tampering（ˈtæmpə®，做手脚、篡改） by attackers, and it produces shared secrets（共享密钥的好处） that cannot be controlled by either participating peer（参与的对方）.
TLS 密钥交换可以抵抗攻击者的篡改，并且它会产生任何一个参与的对等方都无法控制的共享密钥。
TLS provides two basic handshake modes of interest to QUIC:
TLS 为 QUIC 提供了两种基本的握手模式：

• A full 1-RTT handshake, in which the client is able to send application data after one round trip and the server immediately responds after receiving the first handshake message from the client.
  完整的 1-RTT 握手，其中客户端能够在一次往返后发送应用程序数据，服务器在收到来自客户端的第一次握手消息后立即响应。
• A 0-RTT handshake, in which the client uses information it has previously learned about the server to send application data immediately. This application data can be replayed by an attacker, so 0-RTT is not suitable for carrying instructions that might initiate any action（启动任何动作） that could cause unwanted effects if replayed.
  0-RTT 握手，其中客户端使用之前了解的有关服务器的信息立即发送应用程序数据。攻击者可以重放此应用程序数据，因此 0-RTT 不适合携带可能启动任何操作的指令，如果重放，这些操作可能会导致不良影响。

A simplified TLS handshake with 0-RTT application data is shown:

()：受 Early Data (0-RTT) Keys 保护的消息
{}：受 HandShake Keys 保护的消息
[]：受 Application Data（1-RTT）保护的消息

Data is protected using a number of encryption levels （多个加密等级）:

• Initial keys 初始键
• Early data (0-RTT) keys
  早期数据 （0-RTT） 密钥
• Handshake keys 握手键
• Application data (1-RTT) keys
  应用数据 （1-RTT） 键
  Application data can only appear in the early data and application data levels. Handshake and alert messages may appear in any level.
  应用程序数据只能出现在早期数据和应用程序数据级别。握手和警报消息可能出现在任何级别。

The 0-RTT handshake can be used if the client and server have previously（ˈpriːviəsli） communicated.
In the 1-RTT handshake, the client is unable to send protected application data until it has received all of the handshake messages sent by the server.
如果客户端和服务器之前已通信，则可以使用 0-RTT 握手。在 1-RTT 握手中，客户端在收到服务器发送的所有握手消息之前，无法发送受保护的应用程序数据。

QUIC 中的 TLS

QUIC [QUIC-TRANSPORT] assumes responsibility（承担责任） for the confidentiality and integrity protection of packets. For this it uses keys derived from a TLS handshake [TLS13], but instead of carrying TLS records over QUIC (as with TCP), TLS handshake and alert messages are carried directly over the QUIC transport, which takes over the responsibilities（接管了职责） of the TLS record layer, as shown in Figure 3.

QUIC [ QUIC-TRANSPORT] 负责数据包的机密性和完整性保护。为此，它使用派生自 TLS 握手 [ TLS13] 的密钥，但不是用 QUIC 传输 TLS records（像 TCP 那样），而是直接通过 QUIC transport 传输 TLS handshake 和 alert 消息，QUIC transport 接管了 TLS 记录层（the TLS record layer）的职责
（个人理解：像是 QUIC 又类似地实现了一遍 TLS Record Layer）

QUIC also relies on TLS for authentication and negotiation of parameters that are critical to security and performance.
QUIC 还依赖 TLS 对对安全性和性能至关重要的参数进行身份验证和协商。¶

Rather than a strict layering（不是严格的分层）, these two protocols cooperate: QUIC uses the TLS handshake; TLS uses the reliability, ordered delivery, and record layer provided by QUIC.
这两种协议不是严格的分层，而是合作：

• QUIC 使用 TLS 握手
• TLS 使用 QUIC 提供的可靠性、有序投放和记录层（record layer ）

At a high level, there are two main interactions between the TLS and QUIC components:
概括地说，TLS 和 QUIC 组件之间有两个主要交互：

• The TLS component sends and receives messages via the QUIC component, with QUIC providing a reliable stream abstraction to TLS.
  TLS 组件通过 QUIC 组件发送和接收消息，QUIC 为 TLS 提供可靠的流抽象
• The TLS component provides a series of updates to the QUIC component, including (a) new packet protection keys to install and (b) state changes such as handshake completion, the server certificate, etc.
  TLS 组件对 QUIC 组件进行了一系列更新，包括
  • （a） 要安装的新数据包保护密钥和
  • （b） 状态更改，例如握手完成、服务器证书等

shows these interactions in more detail, with the QUIC packet protection being called out specially.

Unlike TLS over TCP, QUIC applications that want to send data do not send it using TLS Application Data records. Rather, they send it as QUIC STREAM frames or other frame types, which are then carried in QUIC packets.
与基于 TCP 的 TLS 不同，想要发送数据的 QUIC 应用程序，不会使用 TLS 应用程序数据记录（TLS Application Data records）发送数据。相反，它们将其作为 QUIC STREAM 帧或其他帧类型发送，然后以 QUIC 数据包（carried in QUIC packets）的形式传输

UDP没有握手协议

1. 使用其他协议：在某些情况下，应用程序可能会结合使用 UDP 和其他协议（如 TCP）来实现握手。例如，应用程序可以使用 TCP 来建立连接，然后切换到 UDP 进行数据传输。（这也可以？）
2. 心跳机制：在 UDP 通信中，由于没有连接状态，应用程序可以通过定期发送心跳数据包来检测连接是否仍然有效。如果接收方在一定时间内没有收到心跳数据包，它可以认为连接已经断开。
3. 序列号：虽然 UDP 不保证数据包的顺序，但应用程序可以在数据包中包含序列号，以便接收方可以重新排序数据包。这可以作为一种简单的握手机制，用于确认数据包的接收。