英文原文鏈接：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 幀被丟棄了。
