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

參考

DTLS1.2，rfc6347

TLS1.2，rfc5246

原文鏈接：https://developer.aliyun.com/article/784107?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的上手 WebRTC DTLS 遇到很多 BUG，怎么解？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。