上手 WebRTC DTLS 遇到很多 BUG？淺談 DTLS Fragment

上一篇《詳解 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 的邊界？這個問題，以后有時間再調研吧，

感謝閱讀，

參考

DTLS 1.2
TLS 1.2

「視頻云技術」你最值得關注的音視頻技術公眾號，每周推送來自阿里云一線的實踐技術文章，在這里與音視頻領域一流工程師交流切磋，公眾號后臺回復【技術】可加入阿里云視頻云技術交流群，和作者一起探討音視頻技術，獲取更多行業最新資訊，

標籤：其他

上一篇：“新內容 新互動”全球視頻云創新挑戰賽復賽啟幕

下一篇：easy-flows原始碼研習