【翻译】ietf-quic-draft-24: 7. Cryptographic and Transport Handshake

英文原文链接：7、加密握手

7.2 Negotiating Connection IDs

 如 5.1 所述，一个连接 ID 用于确保 QUIC 包被正确路由到目标机器。长包头包含两个连接 ID：
目的 ID 的值由包的接收者选取，同时也被用于路由；源 ID 会被对端用于设置目的 ID。
在握手期间，带有长包头的包用于建立各个端点要使用的连接 ID。每个端点使用源 ID 字段 
来指定将要发送给自己的包的目的 ID 字段的连接 ID。一旦接收到一个包，端点可以将待发送包
的目的 ID 设置为接收到的包的源 ID。

 当一个没有收到过服务端 Initial 包或 Retry 包的客户端发出一个 Initial 包时，这个包的目的 ID 
字段会被填充一个不可预知的值（译者注：可以是随机值），这个目的 ID 至少要有 8 个字节的长度。后续
当从服务端收到一个包时，客户端必须使用这个不可预知的值除非它中止这条连接的建立并开始创建一条新的。
初始的目的 ID 被用于确定 Initial 包的保护密钥。

  客户端选择一个值来填充源 ID 字段，同时设置 SCID 字段来表明源 ID 的长度。
  第一个 0-RTT 的包使用相同的目的 ID 和源 ID 作为客户端的第一个 Initial 包。

  一旦第一次接收到来自服务端的 Initial 包或 Retry 包，客户端将使用服务端提供源 ID 作为后
续要发送包的目的 ID，包括后续所有的 0-RTT 包。这意味着客户端可能会在连接建立阶段改变
目的 ID 两次，一次是响应服务端的 Retry 包，一次是响应服务端的第一个 Initial 包。一旦客户
端从服务端接收到了 Initial 包，它必须丢弃所有使用不同源 ID 的包。
  
  客户端必须只在响应服务端的第一个 Initial 包或第一个 Retry 包时才改变随后要发送包的目的 
ID。服务端必须根据 Initial 包来设置它的目的 ID。在任何其他情况下客户端不允许的改变目的
ID 的值，如果后续的 Initial 包或 Retry 包包含了一个其他的源 ID，客户端必须丢弃它们。这样
可以避免客户端无状态的处理多个带有不同连接 ID 的 Initial 包是引起的问题。

在一个连接的生命周期内，连接 ID 是可以改变的，特别是在响应连接迁移的时候。

7.3. Transport Parameters

   在连接建立阶段，两端都需要对他们的传输参数进行认证性的声明。这些声明由一端单方面的生成。端点被要
求遵守这些参数的限制；
   每个参数的描述包括了它们如何被处理。
   传输参数的编码方式详见 18 小节。
   QUIC 在加密握手阶段包含了编码的传输参数。一旦握手完成，对端声明的传输参数就可以被使用。端点需要
验证对端提供的参数的有效性。
    传输参数的定义见 18.2 小节。
    端点在接收到无效的传输参数的值时必须发送一个 TRANSPORT_PARAMETER_ERROR 类型的连接错误。
    端点不可以在一个给定的传输参数扩展中发送多次传输参数。端点应该在收到重复的传输参数时发送一个
  TRANSPORT_PARAMETER_ERROR 类型的连接错误。
    服务端必须在 Retry 包中加上一个 original_connection_id 传输参数来使这个 Retry 包有效，
 详见 17.2.5 小节。

7.3.1. Values of Transport Parameters for 0-RTT

       端点都需要存储某一条连接的服务端的传输参数，并且可以在随后的连接中通过 0-RTT 包发送给对端，不包括那些显式排除的参数。
    记录的传输参数可以在新的连接中使用直到握手完成并且客户端开始发送 1-RTT 包。一旦握手完成，客户端将使用握手阶段建立的传
    输参数进行后续的数据传输。
       新传输参数的定义必须指明它们是“必须”、“可以” 还是 “必须不” 保存来完成 0-RTT。客户端不需要保存它不会处理的传输参数。
       客户端不可以使用这些参数的记录值：original_connection_id, preferred_address, stateless_reset_token, 
    ack_delay_exponent and active_connection_id_limit，而是必须使用在握手阶段从服务端取得的新的值，否则使用默认值。
       客户端在尝试发送 0-RTT 的数据是必须记录服务端使用的其他参数；服务端可以记录这些参数，或者存储一份受完整性保护的拷贝到
    票据中，在接收到 0-RTT 数据时它可以从票据中恢复这些参数。服务端使用传输参数来确定是否接受 0-RTT 数据。

       如果 0-RTT 数据被服务端接收，那么服务端通过 0-RTT 数据来改变任何客户端可能会违反的限制值或者数据。接受了 0-RTT 数据
    的服务端不可以将如下参数的值设置为一个比记录值更小的值：
        o initial_max_data
        o initial_max_stream_data_bidi_local
        o initial_max_stream_data_bidi_remote
        o initial_max_stream_data_uni
        o initial_max_streams_bidi
        o initial_max_streams_uni
       忽略或者设置特定传输参数的 0 值可能会启用 0-RTT 数据，但数据本身不可用。允许发送应用数据的传输参数在用于发送 0-RTT 
    数据时应该被设置为非零值，这些参数包括：initial_max_data，initial_max_streams_bidi，
    initial_max_stream_data_bidi_remote，initial_max_streams_uni，initial_max_stream_data_uni。

       如果传输参数的值是不支持的，那么服务端必须拒绝 0-RTT 数据或者中止握手。
       在 0-RTT 包中发送数据帧时，客户端必须只使用传输参数的记录值，而不可以使用从服务端取得的更新值或者从 1-RTT 包中获取
    到的更新值。传输参数在握手阶段更新的值只能用于 1-RTT 包。例如，从记录的传输参数中获取的流控限制可以应用于 0-RTT 包，即使流
    控限制在握手阶段或者已发送的 1-RTT 包中增加了。服务端可以把在 0-RTT 中使用传输参数的更新值作为一个 PROTOCOL_VIOLATION 类
    型的连接错误。

7.3.2. New Transport Parameters

       新的传输参数可以被用于协商新的协议行为。端点必须忽略它不支持的传输参数。缺少某些传输参数会造成对应的协议特征不可用，这些特征
    必须通过这些缺少的参数协商后才开启；如 18.1 小节所述，部分保留的标识符用于执行这项要求。
       新的传输参数可以根据 22.1 小节中的规则来注册。

7.4.Cryptographic Message Buffering

      QUIC 的实现需要维持一个缓冲区，存放乱序接收到的 CRYPTO 数据。因为 CRYPTO 帧没有流控，
    端点要能够强制它的对端缓冲无上限的数据。
      QUIC 的实现必须支持接收至少 4096 字节的乱序 CRYPTO 帧，端点可以选择在握手阶段允许缓冲
    更多的数据，一个更大的上限意味着握手阶段可以交换更大的密钥或者证书。在连接的生命周期内，端点
    的缓冲大小不需要保持为一个常量。
    
      在握手期间无法缓冲 CRYPTO 帧会导致连接失败。如果端点的缓冲区在握手期间溢出了，它可以临时
    扩大该缓冲区以完成握手；如果端点不扩大它的缓冲区，那么它必须关闭该连接，并发送一个 
    CRYPTO_BUFFER_EXCEEDED 类型的错误。
      一旦完成握手，如果端点无法缓冲一个 CRYPTO 帧的所有数据，那么它可以丢弃该 CRYPTO 帧 以及
    将会接收到的所有 CRYPTO 帧；或者它可以关闭该连接，并发送一个 CRYPTO_BUFFER_EXCEEDED 类
    型的错误。包含被丢弃 CRYPTO 帧的包必须被确认，因为这些包已经被传输层接收和处理，即使它的  
    CRYPTO 帧被丢弃了。