本文做者 Janus 項目做者 Lorenzo Miniero,10 月 25 日未來到北京,在 RTC 2019 大會的「WebRTC Workshop」工做坊中分享 WebRTC 服務端開發及 Janus 開發的技巧,並與聽衆小範圍深刻交流,名額有限,如今便可報名:2019.rtcexpo.org/html
本文摘要:抓取WebRTC流量看起來相對簡單,大多數狀況下確實是這樣:你只須要在其中一人的機器上安裝相似tcpdump或wireshark的抓包工具,而後查看產生的文件,大多數狀況會是.pcap或.pcapng文件。這些活動對於診斷鏈接問題或其它與WebRTC相關的問題頗有用:實際上,wireshark能夠自動檢測出STUN,DTLS之類的標準協議,這些是WebRTC PeerConnections所關注的。git
大多數狀況下你不須要查看內容。正如期待的那樣,你依然能夠查看加密RTP包的標題,也就是最常被用到的信息。無論怎樣,對於RTCP並不能這樣說:實際上,一條RTCP信息可能實際上包含不止一個包,而且不存在一個共享的標題。除此以外,查看RTP負載可能會有效。github
這意味着抓取加密流量是可行的,可是爲了診斷目的抓取無加密數據效果可能更好。不幸的是,無其它幫助下這是不可能的:實際上,WebRTC狀況下瀏覽器常常發送加密數據,即便有一些容許你抓取無加密數據進行測試,可是你仍是須要依靠其它工具來獲取媒體流,才能進行這項工做。web
咱們一年前就是這樣想的,被Firefox所激勵,咱們首先添加了text2pcap dump的支持,採起的方法很直接:json
1.使用Admin API,開始抓取Janus處理文件的信息。 2.全部輸入輸出的RTP/RTCP包都被轉化爲文本格式,保存到相關文件中。 3.抓取結束後,使用text2pcap App 將抓取文件轉化爲與Wiresharak或其它工具兼容的格式。後端
請求的語法很簡單:api
POST /admin/sessionId/handleId
{
"janus" : "start_text2pcap",
"folder" : "<folder to save the dump to; optional, current folder if missing>",
"filename" : "<filename of the dump; optional, random filename if missing>",
"truncate" : "<number of bytes to truncate at; optional, won't truncate if 0 or missing>",
"transaction" : "<random alphanumeric string>",
"admin_secret" : "<password specified in janus.cfg, if any>"
}
複製代碼
若是已知了相關session和handle Id,能夠輕易生成一句代碼來對handle開始抓取:瀏覽器
curl -X POST -H "Content-Type: application/json" -d '{"janus": "start_text2pcap", "folder": "/tmp", "filename": "my-test2pcap-dump.txt", "transaction": "123", "admin_secret": "janusoverlord"}' http://localhost:7088/admin/8412133783240844/2377476017639045
複製代碼
最終,你將會以相似的文本文件結束:安全
I 18:47:14.126004 000000 80 e0 6c 5d [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
O 18:47:14.128251 000000 80 e0 04 83 [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
I 18:47:14.136577 000000 80 6f 54 8d [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
O 18:47:14.136659 000000 80 6f 03 9f [..] JANUS_TEXT2PCAP_RTP [session=3740061776621518][handle=3149681776118503]
複製代碼
你對此文件不能作太多:咱們看到一些輸入輸出包,在某個時間被保存,還能夠看到16進制的負載值,每一行結尾有一些環境信息。你須要把它傳給其它工具,例如text2pcap,將它轉化爲你能夠讀懂的文件:bash
text2pcap -D -n -l 1 -i 17 -u 1000,2000 -t '%H:%M:%S.' /tmp/my-test2pcap-dump.txt /tmp/my-test2pcap-dump.pcapng
複製代碼
你能夠參考說明書詳細學習應該怎樣作和工具提供的功能,上面的一行基本能夠遍歷文本文件,將每一個包轉化爲pcapng格式,使用不一樣IP和端口供兩方交流,更容易區分彼此。
我很高興你問了這個問題!
那是對的:儘管上述方法簡單易行,而且出色的完成了它的工做,可是耗費了大量的CPU。這意味着,儘管看起來不錯,你不能將此方法應用於產品環境中,由於這樣作會影響你機器的性能。
咱們須要另一種方法,在Janus中直接保存到原始pcap文件中,而不是將其轉化爲文本文件,以後進行處理。這個方法模擬了文本抓取,可是有輕微的不一樣之處: 1.就像以前,你使用Admin API開始對Janus中的一個文件進行抓取,可是使用不一樣的請求 2.Pcap全局標題在抓取以前就被保存。 3.全部的輸入輸出RTP/RTCP包都被保存爲文件,可是首先要創建一些假的以太網/IP/UDP標題,而且都移pcap包標題爲前綴。
你可能注意到了這裏不包括寫入處理:因爲咱們直接保存到pcap文件中,這意味着,咱們一中止抓取,文件就立刻被生成,利用,使用適當的工具。除此以外,因爲不須要文本序列化,而是直接寫入文件,這個過程變得輕量化,影響基本可忽略,而且與Janus中的媒體記錄特性很好的契合。
儘管你使用了不一樣的方法保存爲.pcap文件,並且命名爲start_pcap,而不是start_text2pcap,它的語法與另外一個徹底同樣:這意味着你能夠提供與以前同樣的信息,並保存它,不管是否縮短。觀察前面的例子,接着,下面是請求的格式:
curl -X POST -H "Content-Type: application/json" -d '{"janus": "start_pcap", "folder": "/tmp", "filename": "my-pcap-dump.pcap", "transaction": "123", "admin_secret": "janusoverlord"}' http://localhost:7088/admin/8412133783240844/2377476017639045
複製代碼
注意,咱們只改變了請求名稱和目標文件的擴展名。其它徹底同樣。
目前爲止,咱們解釋了Jauns對於抓取未加密數據所提供的功能,如何使用Admin API請求利用這個特性。無論怎樣,你可能不想手動作這些事,或經過命令行。幸運的是,我準備了一個虛擬接口來作這些事!
Janus報告帶來一些可供使用的網絡演示,包括了Admin API接口。這個接口在以前的文章中已經詳細介紹過,特別是使用它提供的信息達到診斷問題的目的。咱們不會重複這些細節,可是咱們會關注一點,你應該如何在Janus中開始或中止抓取一個特定文件。固然了,咱們假定了你以前在HTTP插件配置中開啓了Admin API後端。
若是你有Janus演示的最近的版本,打開Admin API,嘗試導航現有session,選擇一個特定的handle。你應該在實際處理信息前看到一個叫作開啓抓取的勾選框。
點擊它,以下:
大多數設置應該清晰易懂,由於當介紹Admin API請求語法時,咱們介紹了它們。第一個容許你選擇抓取類型,以前講到過,或者是直接保存到pcap,或者是轉化爲文本文件以後處理。
接着你被要求設置保存文件的路徑:
你應該只關心包的第一個byte,而不是所有,這將會使在保存以前縮短包變得有效。你可使用縮短選擇:
當抓取開始時,網頁將會改變相關的勾選框,將其轉化爲控制信息,讓你隨時能夠暫停正在進行的抓取。
當前的抓取狀態也會顯示在handle信息中:
一旦抓取完成,不論是否須要text2pcap,使用wireshark,最終你會獲得你可使用的文件。假設使用了Wireshark,抓取界面以下所示:
正如期待,咱們能夠看到兩個不一樣的IP(10.1.1.1和10.2.2.2)在不一樣端口相互交流。當Janus抓取流量時,10.1.1.1:1000老是peer的地址,10.2.2.2:2000老是Janus本身的地址。
固然,Wireshark本身並不能分辨這些UDP包的內容是RTP和RTCP信息。這是咱們須要告訴它的,將流量信息解碼爲RTP。
以後,Wireshark顯示的信息會變化:
如你所見,Wireshark負責解釋RTP標題,使咱們能夠觀察和分析它。對於負載也能夠這樣說,它將會被解密,而且被咱們看到。
Wireshark一個不多被人知道的特性,是它也支持對某些媒體編解碼器的解封裝。這意味着,若是你告訴Wireshark一個包內含有特定編解碼器編碼的媒體信息,它將會給你一個具體的編解碼信息。VP8和H.264編解碼器處於其中,所以,若是在設置中將負載類型96和VP8穩定關聯起來,顯示的信息將會再一次改變:
儘管這張截圖與以前的類似,仍是存在一些關鍵區別:例如, 注意對於敷在類型96的全部包,協議一列如何從RTP轉化爲VP8。這意味着Wireshark正在使用更高級的解碼,也能夠觀察負載:在VP8狀況下,這意味着獲取以VP8負載描述爲前綴的實際媒體流內容。固然,這些超出了本文的範圍,惟一的做用是展現你應該如何獲取這些信息:若是你想要學習診斷此類內容的更多細節,你能夠參考一篇很棒的文章,它是由Philipp Hancke寫的。