WebRTC搭建前端視頻聊天室——信令篇

時間 2019-11-06

標籤 webrtc 搭建前端視頻聊天室信令简体版

原文原文鏈接

這篇文章講述了WebRTC中所涉及的信令交換以及聊天室中的信令交換，主要內容來自WebRTC in the real world: STUN, TURN and signaling，我在這裏提取出的一些信息，並添加了本身在開發時的一些想法。javascript

WebRTC的服務器

WebRTC提供了瀏覽器到瀏覽器（點對點）之間的通訊，但並不意味着WebRTC不須要服務器。暫且不說基於服務器的一些擴展業務，WebRTC至少有兩件事必需要用到服務器：
1. 瀏覽器之間交換創建通訊的元數據（信令）必須經過服務器
2. 爲了穿越NAT和防火牆html

爲何須要信令？

咱們須要經過一系列的信令來創建瀏覽器之間的通訊。而具體須要經過信令交換哪些內容呢？這裏大概列了一下：
1. 用來控制通訊開啓或者關閉的鏈接控制消息
2. 發生錯誤時用來彼此告知的消息
3. 媒體流元數據，好比像解碼器、解碼器的配置、帶寬、媒體類型等等
4. 用來創建安全鏈接的關鍵數據
5. 外界所看到的的網絡上的數據，好比IP地址、端口等html5

在創建鏈接以前，瀏覽器之間顯然沒有辦法傳遞數據。因此咱們須要經過服務器的中轉，在瀏覽器之間傳遞這些數據，而後創建瀏覽器之間的點對點鏈接。可是WebRTC API中並無實現這些。java

爲何WebRTC不去實現信令交換？

不去由WebRTC實現信令交換的緣由很簡單：WebRTC標準的制定者們但願可以最大限度地兼容已有的成熟技術。具體的鏈接創建方式由一種叫JSEP（JavaScript Session Establishment Protocol）的協議來規定，使用JSEP有兩個好處：
1. 在JSEP中，須要交換的關鍵信息是多媒體會話描述（multimedia session description）。因爲開發者在其所開發的應用程序中信令所使用的協議不一樣（SIP或是XMPP或是開發者本身定義的協議），WebRTC創建呼叫的思想創建在媒體流控制層面上，從而與上層信令傳輸相分離，防止相互之間的信令污染。只要上層信令爲其提供了多媒體會話描述符這樣的關鍵信息就能夠創建鏈接，無論開發者用何種方式來傳遞。
2. JSEP的架構同時也避免了在瀏覽器上保存鏈接的狀態，防止其像一個狀態機同樣工做。因爲頁面常常被頻繁的刷新，若是鏈接的狀態保存在瀏覽器中，每次刷新都會丟失。使用JSEP能使得狀態被保存在服務器上git

會話描述協議（Session Description Protocol）

JSEP將客戶端之間傳遞的信令分爲兩種:offer信令和answer信令。他們主要內容的格式都遵循會話描述協議（Session Description Protocal，簡稱SDP）。一個SDP的信令的內容大體上以下：github

 
 
 
 
  
  
  
  1
  
  
  
  2
  
  
  
  3
  
  
  
  4
  
  
  
  5
  
  
  
  6
  
  
  
  7
  
  
  
  8
  
  
  
  9
  
  
  
  10
  
  
  
  11
  
  
  
  12
  
  
  
  13
  
  
  
  14
  
  
  
  15
  
  
  
  16
  
  
  
  17
  
  
  
  18
  
  
  
  19
  
  
  
  20
  
  
  
  21
  
  
  
  22
  
  
  
  23
  
  
  
  24
  
  
  
  25
  
  
  
  26
  
  
  
  27
  
  
  
  28
  
  
  
  29
  
  
  
  30
  
  
  
  31
  
  
  
  32
  
  
  
  33
  
  
  
  34
  
  
  
  35
  
  
  
  36
  
  
  
  37
  
  
  
  38
  
  
  
  39
  
  
  
  40
  
  
  
  41
  
  
  
  42
  
  
  
  43
  
  
  
  44
  
  
  
  45
  
  
  
  46
  
  
  
  47
  
  
  
  48
  
  
  
  49
  
  
  
  50
  
  
  
  51
  
  
  
  52
  
  
  
  53
  
  
  
  54
  
  
  
  55
  
  
  
  56
  
  
  
  57
  
  
  
  58
  
  
  
  59
  
  
  
  60
  
  
  
  61
  
  
  
  62
  
  
  
  63
  
  
  
  64
 
 
 
 
v=0 o=- 7806956 075423448571 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video data a=msid-semantic: WMS 5UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g m=audio 1 RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:grnpQ0BSTSnBLroq a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5 a=ice-options:google-ice a=fingerprint:sha-256 01:A3:18:0E:36:5E:EF:24:18:8C:8B:0C:9E:B0:84:F6:34:E9:42:E3:0F:43:64:ED:EC:46:2C:3C:23:E3:78:7B a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=recvonly a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qzcKu22ar1+lYah6o8ggzGcQ5obCttoOO2IzXwFV a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 m=video 1 RTP/SAVPF 100 116 117 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:grnpQ0BSTSnBLroq a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5 a=ice-options:google-ice a=fingerprint:sha-256 01:A3:18:0E:36:5E:EF:24:18:8C:8B:0C:9E:B0:84:F6:34:E9:42:E3:0F:43:64:ED:EC:46:2C:3C:23:E3:78:7B a=setup:actpass a=mid:video a=extmap:2 urn:ietf:params:rtp-hdrext:toffset a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=sendrecv a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qzcKu22ar1+lYah6o8ggzGcQ5obCttoOO2IzXwFV a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=ssrc:3162115896 cname:/nERF7Ern+udqf++ a=ssrc:3162115896 msid:5UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g 221b204e-c9a0-4b01-b361-e17e9bf8f639 a=ssrc:3162115896 mslabel:5UhOcZZB1uXtVbYAU5thB0SpkXbzk9FHo30g a=ssrc:3162115896 label:221b204e-c9a0-4b01-b361-e17e9bf8f639 m=application 1 DTLS/SCTP 5000 c=IN IP40.0.0.0 a=ice-ufrag:grnpQ0BSTSnBLroq a=ice-pwd:N5i4DZKMM2L7FEYnhO8V7Kg5 a=ice-options:google-ice a=fingerprint:sha-256 01:A3:18:0E:36:5E:EF:24:18:8C:8B:0C:9E:B0:84:F6:34:E9:42:E3:0F:43:64:ED:EC:46:2C:3C:23:E3:78:7B a=setup:actpass a=mid:data a=sctpmap:5000 webrtc-datachannel 1024

這些都什麼玩意？說實話我不知道，我這裏放這麼一大段出來，只是爲了讓文章內容顯得不少…若是想深刻了解的話，能夠參考SDP for the WebRTC draft-nandakumar-rtcweb-sdp-04自行進行解析web

其實能夠將其簡化一下，它就是一個在點對點鏈接中描述本身的字符串，咱們能夠將其封裝在JSON中進行傳輸，在PeerConnection創建後將其經過服務器中轉後，將本身的SDP描述符和對方的SDP描述符交給PeerConnection就好了json

信令與RTCPeerConnection創建

在前一篇文章中介紹過，WebRTC使用RTCPeerConnection來在瀏覽器之間傳遞流數據，在創建RTCPeerConnection實例以後，想要使用其創建一個點對點的信道，咱們須要作兩件事：
1. 肯定本機上的媒體流的特性，好比分辨率、編解碼能力啥的（SDP描述符）
2. 鏈接兩端的主機的網絡地址（ICE Candidate）瀏覽器

須要注意的是，因爲鏈接兩端的主機均可能在內網或是在防火牆以後，咱們須要一種對全部聯網的計算機都通用的定位方式。這其中就涉及NAT/防火牆穿越技術，以及WebRTC用來達到這個目的所ICE框架。這一部分在上一篇文章中有介紹，這裏再也不贅述。安全

經過offer和answer交換SDP描述符

大體上在兩個用戶（甲和乙）之間創建點對點鏈接流程應該是這個樣子（這裏不考慮錯誤的狀況，RTCPeerConnection簡稱PC）：

甲和乙各自創建一個PC實例
甲經過PC所提供的createOffer()方法創建一個包含甲的SDP描述符的offer信令
甲經過PC所提供的setLocalDescription()方法，將甲的SDP描述符交給甲的PC實例
甲將offer信令經過服務器發送給乙
乙將甲的offer信令中所包含的的SDP描述符提取出來，經過PC所提供的setRemoteDescription()方法交給乙的PC實例
乙經過PC所提供的createAnswer()方法創建一個包含乙的SDP描述符answer信令
乙經過PC所提供的setLocalDescription()方法，將乙的SDP描述符交給乙的PC實例
乙將answer信令經過服務器發送給甲
甲接收到乙的answer信令後，將其中乙的SDP描述符提取出來，調用setRemoteDescripttion()方法交給甲本身的PC實例

經過在這一系列的信令交換以後，甲和乙所建立的PC實例都包含甲和乙的SDP描述符了，完成了兩件事的第一件。咱們還須要完成第二件事——獲取鏈接兩端主機的網絡地址

經過ICE框架創建NAT/防火牆穿越的鏈接

這個網絡地址應該是能從外界直接訪問，WebRTC使用ICE框架來得到這個地址。RTCPeerConnection在創立的時候能夠將ICE服務器的地址傳遞進去，如：

 
 
 
 
  
  
  
  1
  
  
  
  2
  
  
  
  3
  
  
  
  4
  
  
  
  5
  
  
  
  6
 
 
 
 
var iceServer = {     "iceServers": [{         "url": "stun:stun.l.google.com:19302"     }] }; var pc = new RTCPeerConnection(iceServer);

固然這個地址也須要交換，仍是以甲乙兩位爲例，交換的流程以下（RTCPeerConnection簡稱PC）：

甲、乙各建立配置了ICE服務器的PC實例，併爲其添加onicecandidate事件回調
當網絡候選可用時，將會調用onicecandidate函數
在回調函數內部，甲或乙將網絡候選的消息封裝在ICE Candidate信令中，經過服務器中轉，傳遞給對方
甲或乙接收到對方經過服務器中轉所發送過來ICE Candidate信令時，將其解析並得到網絡候選，將其經過PC實例的addIceCandidate()方法加入到PC實例中

這樣鏈接就創立完成了，能夠向RTCPeerConnection中經過addStream()加入流來傳輸媒體流數據。將流加入到RTCPeerConnection實例中後，對方就能夠經過onaddstream所綁定的回調函數監聽到了。調用addStream()能夠在鏈接完成以前，在鏈接創建以後，對方同樣能監聽到媒體流

聊天室中的信令

上面是兩個用戶之間的信令交換流程，但咱們須要創建一個多用戶在線視頻聊天的聊天室。因此須要進行一些擴展，來達到這個要求

用戶操做

首先須要肯定一個用戶在聊天室中的操做大體流程：

打開頁面鏈接到服務器上
進入聊天室
與其餘全部已在聊天室的用戶創建點對點的鏈接，並輸出在頁面上
如有聊天室內的其餘用戶離開，應獲得通知，關閉與其的鏈接並移除其在頁面中的輸出
若又有其餘用戶加入，應獲得通知，創建於新加入用戶的鏈接，並輸出在頁面上
離開頁面，關閉全部鏈接

從上面能夠看出來，除了點對點鏈接的創建，還須要服務器至少作以下幾件事：

新用戶加入房間時，發送新用戶的信息給房間內的其餘用戶
新用戶加入房間時，發送房間內的其餘用戶信息給新加入房間的用戶
用戶離開房間時，發送離開用戶的信息給房間內的其餘用戶

實現思路

以使用WebSocket爲例，上面用戶操做的流程能夠進行如下修改：

瀏覽器與服務器創建WebSocket鏈接
發送一個加入聊天室的信令（join），信令中須要包含用戶所進入的聊天室名稱
服務器根據用戶所加入的房間，發送一個其餘用戶信令（peers），信令中包含聊天室中其餘用戶的信息，瀏覽器根據信息來逐個構建與其餘用戶的點對點鏈接
如有用戶離開，服務器發送一個用戶離開信令（remove_peer），信令中包含離開的用戶的信息，瀏覽器根據信息關閉與離開用戶的信息，並做相應的清除操做
如有新用戶加入，服務器發送一個用戶加入信令（new_peer），信令中包含新加入的用戶的信息，瀏覽器根據信息來創建與這個新用戶的點對點鏈接
用戶離開頁面，關閉WebSocket鏈接

服務器實現

因爲用戶能夠只是創建鏈接，可能尚未進入具體房間，因此首先咱們須要一個容器來保存全部用戶的鏈接，同時監聽用戶是否與服務器創建了WebSocket的鏈接：

 
 
 
 
  
  
  
  1
  
  
  
  2
  
  
  
  3
  
  
  
  4
  
  
  
  5
  
  
  
  6
  
  
  
  7
  
  
  
  8
  
  
  
  9
  
  
  
  10
  
  
  
  11
  
  
  
  12
 
 
 
 
var server = new WebSocketServer(); var sockets = [];  server.on('connection', function(socket){     socket.on('close', function(){         var i = sockets.indexOf(socket);         sockets.splice(i, 1);         //關閉鏈接後的其餘操做     });     sockets.push(socket);     //鏈接創建後的其餘操做 });

因爲有房間的劃分，因此咱們須要在服務器上創建一個容器，用來保存房間內的用戶信息。顯然對象較爲合適，鍵爲房間名稱，值爲用戶信息列表。

同時咱們須要監聽上面所說的用戶加入房間的信令（join），新用戶加入以後須要向新用戶發送房間內其餘用戶信息（peers）和向房間內其餘用戶發送新用戶信息（new_peer），以及用戶離開時向其餘用戶發送離開用戶的信息（remove_peer）:

因而乎代碼大體就變成這樣：

 
 
 
 
  
  
  
  1
  
  
  
  2
  
  
  
  3
  
  
  
  4
  
  
  
  5
  
  
  
  6
  
  
  
  7
  
  
  
  8
  
  
  
  9
  
  
  
  10
  
  
  
  11
  
  
  
  12
  
  
  
  13
  
  
  
  14
  
  
  
  15
  
  
  
  16
  
  
  
  17
  
  
  
  18
  
  
  
  19
  
  
  
  20
  
  
  
  21
  
  
  
  22
  
  
  
  23
  
  
  
  24
  
  
  
  25
  
  
  
  26
  
  
  
  27
  
  
  
  28
  
  
  
  29
  
  
  
  30
  
  
  
  31
  
  
  
  32
  
  
  
  33
  
  
  
  34
  
  
  
  35
  
  
  
  36
  
  
  
  37
  
  
  
  38
  
  
  
  39
  
  
  
  40
  
  
  
  41
  
  
  
  42
  
  
  
  43
  
  
  
  44
  
  
  
  45
  
  
  
  46
  
  
  
  47
  
  
  
  48
  
  
  
  49
  
  
  
  50
  
  
  
  51
  
  
  
  52
  
  
  
  53
  
  
  
  54
  
  
  
  55
  
  
  
  56
  
  
  
  57
  
  
  
  58
  
  
  
  59
  
  
  
  60
  
  
  
  61
  
  
  
  62
  
  
  
  63
  
  
  
  64
  
  
  
  65
  
  
  
  66
  
  
  
  67
  
  
  
  68
  
  
  
  69
  
  
  
  70
  
  
  
  71
  
  
  
  72
  
  
  
  73
  
  
  
  74
  
  
  
  75
  
  
  
  76
  
  
  
  77
  
  
  
  78
  
  
  
  79
  
  
  
  80
  
  
  
  81
  
  
  
  82
  
  
  
  83
  
  
  
  84
  
  
  
  85
  
  
  
  86
  
  
  
  87
  
  
  
  88
  
  
  
  89
 
 
 
 
var server = new WebSocketServer(); var sockets = []; var rooms = {};  /* join信令所接收的格式 { "eventName": "join", "data": { "room": "roomName" } } */ var joinRoom = function(data, socket) {     var room = data.room || "__default";     var curRoomSockets; //當前房間的socket列表     var socketIds = []; //房間其餘用戶的id      curRoomSockets = rooms[room] = rooms[room] || [];      //給全部房間內的其餘人發送新用戶的id     for (var i = curRoomSockets.length; i--;) {         socketIds.push(curRoomSockets[i].id);         curRoomSockets[i].send(JSON.stringify({             "eventName": "new_peer",             "data": {                 "socketId": socket.id             }         }));     }      //將新用戶的鏈接加入到房間的鏈接列表中     curRoomSockets.push(socket);     socket.room = room;      //給新用戶發送其餘用戶的信息，及服務器給新用戶本身賦予的id     socket.send(JSON.stringify({         "eventName": "peers",         "data": {             "socketIds": socketIds,             "you": socket.id         }     })); };  server.on('connection', function(socket) {     //爲socket構建一個特有的id，用來做爲區分用戶的標記     socket.id = getRandomString();     //用戶關閉鏈接後，應作的處理     socket.on('close', function() {         var i = sockets.indexOf(socket);         var room = socket.room;         var curRoomSockets = rooms[room];         sockets.splice(i, 1);         //通知房間內其餘用戶         if (curRoomSockets) {             for (i = curRoomSockets.length; i--;) {                 curRoomSockets[i].send(JSON.stringify({                     "eventName": "remove_peer",                     "data": {                         "socketId": socket.id                     }                 }));             }         }         //從room中刪除socket         if (room) {             i = this.rooms[room].indexOf(socket);             this.rooms[room].splice(i, 1);             if (this.rooms[room].length === 0) {                 delete this.rooms[room];             }         }         //關閉鏈接後的其餘操做     });     //根據前臺頁面傳遞過來的信令進行解析，肯定應該如何處理     socket.on('message', function(data) {         var json = JSON.parse(data);         if (json.eventName) {             if (json.eventName === "join") {                 joinRoom(data, socket);             }         }     });     //將鏈接保存     sockets.push(socket);     //鏈接創建後的其餘操做 });