quic使用秘鑰（過段時間更換一次）對應用資料加密後，需要單獨對包頭加密。
長報頭加密字段:
±±±±±±±±+
|1|1|t t|e e e e|
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| version -> length fields …
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
短報頭加密字段:
±±±±±±±±+
|0|1|s|e e e e e|
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| destination connection id (0/32…144) …
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
普通字段:
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|e e e e e e e e epacket number (8/16/24/32)e e e e e e e e…
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| [protected payload (8/16/24)] …
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| sampled part of protected payload (128) …
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| protected payload remainder (*) …
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
報文示例：
initial packet
1-rtt packet
因為接收端收到報文解密時，提取抽樣需要跟傳送端一致才能正確解密，而包編號的長度不是固定值，所以解密假設包編號長度為4位元組，那麼傳送端抽樣需要從4位元組後開始，所以會出現跳過部分（即protected payload (0…24), # skipped part），用於補足4位元組。
使用秘鑰+抽樣進行加密，個人猜測是因為應對側通道攻擊，因為包頭保護的秘鑰在連線期間不能改變，需要加入抽樣擾亂每個資料報的加密能量規律。
先根據秘鑰和抽樣由特定的加密演算法（建鏈協商決定）得到mask，mask使用異或保護報頭字段。分組的第一位元組的最低有效位被mask第乙個位元組的最低有效位加密，包編號用剩餘位元組加密：
mask = aes-ecb(hp_key, sample)
pn_length = (packet[0] & 0x03) + 1
if (packet[0] & 0x80) == 0x80:
#長報頭: 4 bits masked
packet[0] ^= mask[0] & 0x0f
else:
# 短報頭: 5 bits masked
packet[0] ^= mask[0] & 0x1f
# pn_offset是包編號欄位的起始位置.
packet[pn_offset:pn_offset+pn_length] ^= mask[1:1+pn_length]
QUIC協議文件翻譯 什麼是QUIC
quic是乙個谷歌提出的新的網際網路協議。quic解決出現在現在網路協議的一些傳輸層和應用層的問題，而且幾乎不需要應用更改。quic和tcp tls http2十分相似，但是基於udp實現。使用quic作為乙個獨立的協議可以做到一些別的協議做不到的創新，因為它們受到傳統客戶端和中介軟體的阻礙。和tc...
QUIC簡單介紹
quic 即quick udp internet connection，類似於spdy 相同也是由google公司在現有已存協議之上進行了擴充套件設計，而旨在降低網路延遲。之前我曾介紹過spdy的相關資訊，spdy工作在應用層，而這裡的quic工作在傳輸層。儘管quic的名字暗示著它類似於乙個被改動...
QUIC簡單介紹
quic 即quick udp internet connection，類似於spdy 相同也是由google公司在現有已存協議之上進行了擴充套件設計，而旨在降低網路延遲。之前我曾介紹過spdy的相關資訊，spdy工作在應用層，而這裡的quic工作在傳輸層。儘管quic的名字暗示著它類似於乙個被改動...