在前一天的文章中我們設定了 wireshark 對於 QUIC 的支持，今天我們將來介紹在 RFC9000 中描述 Handshark 的流程，因為加密的詳細敘述都描述在 RFC9001 QUIC-TLS 內，RFC9000 更注重的是以封包的角度，整個 Handshake 是怎麼進行的，今天的文章內出現的一些專有名詞都在之前基本術語介紹的文章中都有大略提過了，如果不熟悉的小夥伴也可以翻回去參考看看。
這邊簡單回顧一下，QUIC 本身是基於 UDP 協定的，所以由大到小大概可以這樣分
UDP datagram → QUIC packet → QUIC frame → HTTP/3 frame
在 QUIC 中封包又分為兩種
Long Header Packet
Short Header Packet
所以 QUIC 的 Packet 與 Frame 是獨立的兩個層次，針對 Packet header 的保護，其實 QUIC 也會對部份 Long Header Packet 的 Header 某些欄位用別的加密方式保護，之後也會介紹到。
上圖是以封包交換的角度描述 1-RTT 的建立連線過程，每一行都是一個單獨的 QUIC 封包，冒號後面則是這個封包內包含的 frame。
建立連線由 Client 發起:
Initial[0] 封包帶有 Client Hello 的 CRYPTO frame。
這邊我們用昨天的實驗中 wireshark 撈到的封包交互過程，看到第一個封包，由 Client 端發起的 Initial 封包
點開 QUIC IETF 欄位可以看到一些 Header 資訊
根據 Type 我們知道他是 Initial Packet，我們可以參考 RFC 來看每個欄位詳細的定義，請參考 RFC9000 - 17.2.2. Initial Packet
在 Payload 的部份可以繼續往下看到 CRYPTO frame
像這樣在收錄完封包後，可以用 wireshark 觀察封包交互的行為。
後續的每個步驟也能照個上面的想法利用 wireshark 觀察。
今天剛好邁入第十天了，來寫個階段性的心得，因為筆者第一次參加鐵人賽，十分做死的沒有囤稿就來挑戰了...選的題目又是剛接觸的新知識，所以筆者每天都是現學現寫的XD
一開始認為用 wireshark 觀察交互似乎是個不錯的學習方式，但是後來發現像是 Handshake 這種有固定流程的機制，在講解原理跟演算法時好像就把整個流程都介紹的差不多了.. wireshark 只能觀察那些欄位的值，再去跟 RFC 文檔的做對比，如果只是為了這樣好像意義不大..?
如果想知道 CRYPTO frame 代表的值，其實自己去查文檔就足夠了，實作 library 的人會照著 RFC 的規範把資料填到對應的欄位，我覺得更重要的是這些 frame / packet 代表的意義，流程比欄位的值更重要，所以從明天開始可能會少一點 wireshark 的觀察，讓讀者們有興趣可以自己實驗，筆者之後的文章會更重視機制的解釋，像是 Connection ID 怎麼生成， flow control 的流程等等，有必要的時候我們再用 wireshark 來觀察。
我認為 wireshark 最好用的時機是自己在寫協定或者擴充時，可以用撈封包的方式代替在程式裡面加一堆 debug 的 info，如果哪邊欄位的 offset 填錯了，可以直接觀察封包來偵錯。
那反思就到這邊告一段落了，筆者要去思考一下明天要寫什麼 感謝!
iThome鐵人賽
看影片追技術