上一篇《詳解 WebRTC 傳輸安全機制：一文讀懂 DTLS 協議》詳細闡述了 DTLS。本文將結合 DTLS 開發中遇到的問題，詳細解讀 DTLS 的一些基礎概念以及 Fragment 的機制，並進一步深究 DTLS 協議。
作者｜泰一
審校｜進學、莫戰
前言
最近在做 J 和 G 這兩套 RTC 系統的 DTLS-SRTP 握手加密工作，要求使用 CA 機構頒發的證書。在本機除錯的過程中發現：G 系統使用 CA 證書，DTLS 握手成功，而 J 系統則握手失敗。
經過幾番除錯與分析，定位到了原因：J 系統相較於 G 系統多了一個 TURN 轉發模組，該模組設定的接收緩衝區的上限值為 1600 位元組，而 CA 證書的大小則有近 3000 位元組，因此 TURN 模組轉發給客戶端的證書不完整，導致 DTLS 握手失敗。
大家都知道， WebRTC 的 DTLS 使用的是自簽名的證書，這個證書一般不會太大，如下圖所示，只有 286 位元組。
然而，如果要使用 CA 頒發的證書，那麼這個證書可能會很大，如下圖所示，竟達到了 2772 位元組，顯然超出了 TURN 模組的接收緩衝區的大小。
上圖中，你可能注意到了這個 CA 證書被分成了兩片（two fragments），這其實是 DTLS 協議層做的。不過值得思考的是，CA 證書的每一片的大小都未超出 TURN 模組接收緩衝區的 1600 位元組的限制，但是為什麼 J 系統的 TURN 轉發模組依然會接收失敗呢？
這是因為證書雖然被分片，但是在傳送到 TURN 模組時並沒有按照分片獨立傳送，仍然是全部打包到了同一個 UDP 資料包中進行傳送，所以接收肯定會失敗。
下面，我們將一起了解下 DTLS Fragment 的機制。首先要理清幾個概念。
Message、Record、Flight
DTLS 協議分為兩層：底層的 record protocol 和上層的 handshake protocol、change cipher spec protocol、alert protocol 以及 application data protocol。
Remark：握手協議、密碼規格變更協議、警告協議、應用資料協議均在 DTLS 記錄協議的上層，這四種協議統稱為 DTLS 握手協議。
Note：關於記錄和握手這兩層協議各自的作用，這裡就不再贅述，可以參考 WebRTC 中 DTLS 的應用。
DTLS Message 是一條完整的 DTLS 訊息。比如握手訊息：Client Hello、Certificate、Client Key Exchange 等；比如密碼規格變更訊息：Change Cipher Spec。
DTLS Record 是記錄層（Record Layer）的概念，可以認為它是一個殼子，裡面裝載著 DTLS Message，如下圖：
Message 和 Record 是一對一或者一對多的關係。也就是說，一個 Record 不一定裝了一條完整的 Message。因為有可能是多個 Record 組成一個完整的 Message。
如果 Message 很小，未超過 MTU 的限制，那麼一個 Record 足以裝下一條 Message；如果 Message 很大，超過 MTU 的限制，那麼就需要多個 Record 來裝這條 Message。即這條 DTLS Message 會被分割為多個 Fragment，然後分別裝入多個 Record。
Remark：最大傳輸單元（Maximum transmission Unit, MTU）是資料鏈路層的概念，MTU 限制的是資料鏈路層的 payload 大小，也就是其上層協議的大小，比如 IP、ICMP。在乙太網中，鏈路層的 MTU 是 1500 位元組。
比如，Certificate 這個握手訊息，證書大小很容易就超過 MTU 的限制，那麼這個訊息就會被分割為多個 Fragment 並被分別存放到多個 DTLS Record，每個 Fragment 的大小要保證不超過 MTU 的限制（PS：導讀的第二張圖就是一個實際的例子）。
Flight 中文解釋為 “航班” 或者 “航程”，是一個或者一組打包好的 Message，這組 Message 屬於同一個 “航程”，視為一個整體，通過單個 UDP 資料包傳送。
如上圖所示，本次 DTLS 握手一共有 4 個 Flight。Flight2 是 Server Hello、Certificate、Server Hello Done 這三條 Message 的組合，其中 Certificate 這條 Message 被分割為兩個 Fragment，裝到兩個 Record 中。Flight2 通過大小為 2969 位元組的 UDP 資料包傳送出去。
Remark：Flight2 這個 2969 位元組的 UDP 包是在本機環境下除錯、抓包得到的，並不代表 MTU 有這麼大，在實際的網路中，不會出現這種遠超 MTU 限制的資料包。
到這裡，關於 Message、Record、Flight 的概念就講完了，三者之間的關如下圖：
Fragment
下面我們談談，DTLS 為什麼要對 DTLS Message 做分片。
我們知道，受乙太網 MTU 影響，UDP 資料包最大為 1500 位元組，超出這個限制就會被 IP 層分片（PS：乙太網 MTU 設定為 1500 位元組是為了最大化通道傳輸利用率）。
但是如果 IP 層分片機制被禁止呢？這就會導致大於 1500 位元組的 UDP 資料包在 IP 層被丟棄。因此，DTLS 要對訊息做分片，來滿足 IP 層對報文大小的要求。DTLS1.2: Message Size 這一節解釋了這個原因。
By contrast, UDP datagrams are often limited to < 1500 bytes if IP fragmentation is not desired. In order to compensate for this limitation, each DTLS handshake message may be fragmented over several DTLS records, each of which is intended to fit in a single IP datagram.
因此，DTLS 的分片機制很簡單：在傳送時把 DTLS Message 分割成多個連續的 DTLS Record，在接收時快取分片，直到擁有完整的 DTLS Message。
我們可以使用 OpenSSL 的這兩個 API 設定 MTU 的大小：
SSL_set_options(dtls, SSL_OP_NO_QUERY_MTU);
SSL_set_mtu(dtls, 1500);
上面的程式碼設定了 MTU 為 1500，那麼當 DTLS Message 大小超過 1500 位元組，就會觸發 DTLS 的分片機制，同理，如果設定 MTU 為 300，那麼當 DTLS Message 大小超過 300 位元組，就會分片。如果不進行設定，那麼 MTU 會走預設值，如下圖所示，證書訊息被分割成了若干個大小為 288 位元組的固定的 Fragment。
Remark：TLS 底層是 TCP 協議，為位元組流式傳輸，因此 TLS 沒有訊息分片機制。
我們還可使用下面的 API 設定 Fragment 的大小的上限：
SSL_set_max_send_fragment(dtls, 1500);
最後，我們回到導讀描述的問題：證書訊息實際上確實被分割為兩片並分別儲存到兩個 Record，但是由於在傳送的時候還是打包到了一個 UDP 資料包，因此，過大的 UDP 資料包導致 TURN 模組並未接收完整。
更詳細的原因是：我們使用的是記憶體型的 BIO，在應用層呼叫 BIO_get_mem_data 得到的是關於 DTLS Message 的一塊連續的記憶體（雖然這塊記憶體中的證書訊息已經被 DTLS 切成兩個連續的 Fragment 並存在兩個 Record 中），而應用層在獲取到這塊記憶體後就直接通過 sendto 函式傳送給了對端，因此，這個 UDP 報文當然還是特別大，導致接收失敗。
回過頭來再看下導讀中證書訊息分片的這張圖，兩個 Record 的 message sequence 欄位值相同，說明這是同一個 DTLS Message 的兩個 Fragment。且每個 Record 都有 fragment offset 和 fragment length 這兩個欄位，用來標識分片的邊界。所以，我們可以根據這兩個欄位去解析出每一個獨立的 Fragment。
當然，根據 Record 頭部的 Length 欄位足以確定邊界，這會使應用層的解析更加方便。所以，要解決這個問題，應用層要做的是：對從 BIO 獲取到的這塊訊息記憶體進行解析，得到每個 Record 的邊界，然後將每個 Record 以獨立的 UDP 報文傳送出去。具體的解析程式碼這裡就不貼出來了，非常簡單。
最後，在實踐中發現，DTLS Record 不能跨 UDP 資料包傳送，DTLS 1.2: Transport Layer Mapping 這一節也交代了這一點。也就是說，應用層要嚴格的按照 Record 的邊界解析出每一個 Record，分別通過獨立的 UDP 資料包傳送，而不能按照自己的意願隨意劃分為若干個 UDP 資料包傳送。因為這可能會導致某個 DTLS Record 被切分到多個 UDP 資料包傳送，從而導致接收端 DTLS 無法將收到的 DTLS Records 重組為完整的 DTLS Message。
下圖是 DTLS 分片獨立傳送後的效果：
有興趣的讀者可以參考我寫的 DTLS demo，它實現了簡單的 DTLS 握手和分片獨立傳送。也可以參考 開源視訊伺服器 SRS 的 DTLS 實現，更加簡潔和詳盡。
總結
對於超過 MTU 限制的 DTLS Message，DTLS 會把它分割為多個 Fragment， 並分別儲存到各個 DTLS Record 中，因此一個 Fragment 一定是一個 DTLS Record。對於未超過 MTU 限制的 DTLS Message，則不會被分片，也是儲存到 DTLS Record 中，因此一個 DTLS Record 不一定是一個 Fragment，也有可能是一個完整的 DTLS Message。另外，MTU 的大小以及 Fragment 的最大值都可以使用 OpenSSL 的 API 進行設定。
由於我們通過記憶體型 BIO 獲取到了儲存了各個 DTLS Message 的這塊連續記憶體後，直接將其打包為 Flight，並通過單獨的 UDP 資料包文傳送，因此這個 UDP 包仍然還是那麼大，超出了 TURN 模組接收緩衝區的上限和 MTU 的限制。所以為了做到真正的分片獨立傳送，需要應用層自己去做 Fragment 的解析（其實就是解析 Record 的邊界），並分別通過獨立的 UDP 報文傳送。
我們在解決了一個問題後，還要再問一下自己有沒有引入新的問題。
獨立傳送每個 DTLS Record，雖然解決了 DTLS Message 超過 MTU 限制的問題，但是這也增加了 UDP 報文的數量，因此丟包的概率也會相應的增加，DTLS 重傳次數增加，握手的成功率降低。解決這個問題的一個方法是：不必每個 DTLS Record 都單獨 UDP 傳送，可以多個 DTLS Record 傳送，只要能保證它們加起來的大小不超過 MTU 的限制就可以。
同時，我們也要問一下自己有沒有更好的方法。
比如目前的解決方法是應用層自己實現 Record 解析並獨立傳送，那麼 OpenSSL 是否已經有相關的 API 實現類似的功能，再比如 BIO 有沒有相關的 API 可以告訴我們讀取的記憶體資料中 Record 的數量以及每個 Record 的邊界？這個問題，以後有時間再調研吧。
感謝閱讀。
參考
「視訊雲技術」你最值得關注的音視訊技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。公眾號後臺回覆【技術】可加入阿里雲視訊雲技術交流群，和作者一起探討音視訊技術，獲取更多行業最新資訊。