在我大學(xué)二年級(jí)時(shí)，我和我的朋友常常花幾個(gè)小時(shí)在 Omegle 上，與來(lái)自世界各地的隨機(jī)人聊天。這總是充滿樂(lè)趣和驚喜——你永遠(yuǎn)不知道下一個(gè)會(huì)遇到誰(shuí)。當(dāng) Omegle 關(guān)閉後，留下了一片空白。我們懷念那些隨機(jī)連結(jié)的興奮感，就在那時(shí)我想，「為什麼不建構(gòu)我自己的版本呢？」

在這篇部落格中，我將詳細(xì)介紹使用 WebRTC 和 WebSocket 設(shè)計(jì)和建構(gòu)此類平臺(tái)的過(guò)程，重點(diǎn)介紹我面臨的挑戰(zhàn)以及如何克服這些挑戰(zhàn)。讀完本部落格後，您不僅會(huì)了解它的工作原理，還會(huì)為開(kāi)始建立自己的即時(shí)通訊應(yīng)用程式奠定堅(jiān)實(shí)的基礎(chǔ)

我目前正在開(kāi)發(fā)一個(gè)名為 Noto Chats 的項(xiàng)目，其中包括隨機(jī)視訊聊天功能以及其他幾個(gè)令人興奮的功能。該系統(tǒng)已經(jīng)過(guò)徹底測(cè)試並且可以無(wú)縫運(yùn)行。

這是 ramdomvideo 聊天應(yīng)用程式的程式碼連結(jié) https://github.com/Arsh910/RandomVideo-Chat-app

技術(shù)堆疊

前端：用於建立互動(dòng)式使用者介面的 ReactJS。
後端：用於處理 WebSocket 連線的 Django Channels。
訊號(hào)協(xié)定：用於建立 WebRTC 連線的 WebSocket。
媒體串流：用於點(diǎn)對(duì)點(diǎn)視訊和音訊通訊的 WebRTC。

設(shè)計(jì)

雙方都會(huì)嘗試建立連接，先建立的將繼續(xù)

設(shè)計(jì)的組成：

如果您不熟悉 WebRTC 的工作原理，請(qǐng)觀看我學(xué)習(xí)的這個(gè)影片。以下是組件的簡(jiǎn)要概述

1?？蛻舳?1 和客戶端 2
這些代表嘗試連線的兩個(gè)用戶。每個(gè)客戶端負(fù)責(zé)建立報(bào)價(jià)、將其發(fā)送到伺服器並回應(yīng)他們收到的報(bào)價(jià)。

類比：將客戶 1 和客戶 2 視為兩個(gè)想要進(jìn)行對(duì)話的人。他們還不認(rèn)識(shí)，但很想交談。各自主動(dòng)伸手等待對(duì)方回應(yīng)。

2。伺服器
伺服器充當(dāng)媒人的角色。它不處理實(shí)際的對(duì)話，而是透過(guò)在客戶之間傳遞報(bào)價(jià)和答案並幫助交換連接詳細(xì)資訊來(lái)促進(jìn)介紹。

類比：想像一個(gè)共同的朋友在聚會(huì)上介紹兩個(gè)人。朋友沒(méi)有加入他們的談話，但要確保他們知道彼此的姓名和電話號(hào)碼才能開(kāi)始交談。

3。對(duì)等連接
PeerConnection 是一種在兩個(gè)客戶之間建立直接連結(jié)的機(jī)制。它管理媒體（音訊/視訊）交換並確保連接建立後保持穩(wěn)定。就像上圖的peer1和peer 2一樣。

類比：PeerConnection 就像兩棟房子之間的安全、私人隧道。隧道建成後，裡面的人可以在沒(méi)有其他人看到的情況下傳遞紙條、交談，甚至寄包裹。

4。 ICE 候選人
ICE（互動(dòng)式連線建立）候選者是直接連接的建置區(qū)塊。這些是 PeerConnection 嘗試用來(lái)建立最佳連線的路由和網(wǎng)路路徑。

類比：ICE候選人就像地圖，顯示了連接兩棟房子的多條道路。連接找到最佳道路（最短、最平滑）並使用它來(lái)確?？焖倏煽康穆肪€。

5。提議與答覆
連接過(guò)程從一個(gè)客戶端（呼叫者）建立報(bào)價(jià)並透過(guò)伺服器將其傳送到另一個(gè)客戶端開(kāi)始。第二個(gè)客戶端（接收者）建立一個(gè)答案並將其發(fā)回。此交換建立了連線。

類比：想像一個(gè)人發(fā)送一封信說(shuō)：「我們做朋友吧！」另一個(gè)人回答：「當(dāng)然，我也想要！」一旦他們同意，友誼就開(kāi)始了。

6。曲目（音訊/視訊串流）
軌道是指建立連線後在客戶端之間共享的媒體串流（音訊和視訊）。

類比：曲目就像來(lái)自兩個(gè)攝影機(jī)和麥克風(fēng)的即時(shí)回饋。每個(gè)人都可以即時(shí)看到和聽(tīng)到對(duì)方正在分享的內(nèi)容，就像即時(shí)視訊通話一樣。

7。訊號(hào)流程
信令過(guò)程涉及透過(guò)伺服器交換報(bào)價(jià)、答案和 ICE 候選人。這可確保兩個(gè)客戶端都擁有建立直接對(duì)等連線所需的資訊。

類比：訊號(hào)過(guò)程就像郵政系統(tǒng)在兩個(gè)想要聯(lián)繫的人之間傳遞訊息。郵差（服務(wù)器）確保信件（報(bào)價(jià)、答復(fù)）到達(dá)正確的收件人，以便對(duì)話可以開(kāi)始。

雙重角色挑戰(zhàn)

要理解設(shè)計(jì)，首先要抓住一個(gè)關(guān)鍵挑戰(zhàn)。

在傳統(tǒng)的電話通話中，連接過(guò)程涉及一個(gè)人充當(dāng)呼叫者，另一個(gè)人充當(dāng)接收者。然而，在這樣的聊天應(yīng)用程式中，情況就不同了。在這裡，每個(gè)用戶都在發(fā)起連線並等待其他人接受它。這意味著每個(gè)人都必須同時(shí)充當(dāng)呼叫者和接收者，創(chuàng)建一個(gè)兩個(gè)角色融合以實(shí)現(xiàn)無(wú)縫連接的系統(tǒng)。

這就是為什麼我使用兩個(gè)對(duì)等連接，peer1 和peer2。

一些重要的功能：

OnIceCandidateFunc
處理 ICE 候選交換以建立點(diǎn)對(duì)點(diǎn)連線。當(dāng)從 STUN 伺服器收到 Ice 候選時(shí)，它會(huì)將 ICE 候選發(fā)送到伺服器。

OnTrackFunc
處理從對(duì)等方接收的媒體軌道（音訊/視訊）。當(dāng)對(duì)等方傳輸曲目時(shí)啟動(dòng)。在接收者的介面上顯示媒體。

handle_ice
處理從其他客戶收到的冰候選人。它會(huì)添加收到的ice候選並將它們添加到對(duì)等連接中。

取得隨機(jī)使用者
此函數(shù)從線上用戶清單中隨機(jī)選擇一個(gè)用戶，不包括目前用戶。如果列表為空，則會(huì)拋出錯(cuò)誤。這確保了聊天的公平隨機(jī)配對(duì)。

送比賽
此函數(shù)會(huì)向伺服器發(fā)送選定隨機(jī)使用者的連線請(qǐng)求。它建構(gòu)一個(gè) WebSocket 訊息，通知伺服器連接的意圖。

檢查匹配
此函數(shù)驗(yàn)證伺服器的回應(yīng)是否確認(rèn)成功匹配。它檢查其他人選擇了該用戶。它檢查該用戶是否選擇了其他用戶。它檢查calling_clicked標(biāo)誌是否為true（重要的是其他使用者也點(diǎn)擊了呼叫）。

如果滿足所有條件，則傳回true；否則，傳回 false。此步驟可確保在繼續(xù)之前正確驗(yàn)證連線。

了解配對(duì)過(guò)程的範(fàn)例

雙方都會(huì)發(fā)送和接收，先接收的一方被佔(zhàn)領(lǐng)

Webrtc連線流程

對(duì)等 1 和對(duì)等 2
為了建立連接，兩個(gè)對(duì)等點(diǎn)（對(duì)等點(diǎn) 1 和對(duì)等點(diǎn) 2）扮演不同的角色：

Peer 1：負(fù)責(zé)建立報(bào)價(jià)並接收答案。
對(duì)等 2：處理報(bào)價(jià)、產(chǎn)生答案並將其發(fā)回。
連接過(guò)程
以下是匹配後連接過(guò)程的展開(kāi)方式：

1 正在初始化對(duì)等點(diǎn) 1：
Peer 1 在兩個(gè)客戶端上建立（例如客戶端 1 和客戶端 2）。
Peer 1 附加了兩個(gè)關(guān)鍵事件：
OnTrackFunc：管理來(lái)自其他對(duì)等點(diǎn)的傳入音訊/視訊串流。
OnIceCandidateFunc：每當(dāng)從 STUN 伺服器收到新候選時(shí)，將 ICE 候選傳送到伺服器。

2 建立並發(fā)送報(bào)價(jià)：
Peer 1 產(chǎn)生一個(gè)報(bào)價(jià)，該報(bào)價(jià)被設(shè)定為其 localDescription。
此優(yōu)惠由兩個(gè)客戶端發(fā)送給匹配的用戶（透過(guò)信令伺服器）。
3 與同業(yè) 2 處理報(bào)價(jià)：

收到報(bào)價(jià)後，雙方都會(huì)建立 Peer 2。
與 Peer 1 類似，Peer 2 透過(guò) OnTrackFunc 和 OnIceCandidateFunc 事件進(jìn)行初始化。
收到的報(bào)價(jià)被設(shè)定為 Peer 2 的遠(yuǎn)端描述。

4 產(chǎn)生並發(fā)送答案：
Peer 2 產(chǎn)生一個(gè)答案，該答案被設(shè)定為其 localDescription。
這個(gè)答案由雙方傳回另一個(gè)客戶端（透過(guò)伺服器）。

5 完成連線：
一旦收到答案，它就會(huì)被設(shè)定為對(duì)等點(diǎn) 1 的遠(yuǎn)端描述。
兩個(gè)客戶端現(xiàn)在都擁有建立直接連線所需的資訊。

雙方都會(huì)發(fā)送和接收

6 處理 ICE 候選人：
當(dāng) ICE 候選者交換時(shí)，OnIceCandidateFunc 被觸發(fā)。
使用handle_ice函數(shù)處理收到的ICE候選者，該函數(shù)根據(jù)連接設(shè)定將它們新增至適當(dāng)?shù)膶?duì)等點(diǎn)（對(duì)等點(diǎn)1或?qū)Φ赛c(diǎn)2）。

7 設(shè)定媒體串流：
當(dāng)接收到媒體軌道（音訊/視訊）時(shí)，會(huì)觸發(fā) OnTrackFunc 事件。
這可確保遠(yuǎn)端視訊和音訊串流在兩個(gè)用戶端上顯示。

雙方都會(huì)發(fā)送和接收

由於使用者選擇的隨機(jī)性和處理延遲，連接過(guò)程不會(huì)在雙方同時(shí)發(fā)生。首先完成設(shè)定的客戶端將成為“呼叫者”，而另一個(gè)則充當(dāng)“接收者”。

WebRTC 連線成功建立後，雙方使用者都可以享受無(wú)縫的視訊聊天體驗(yàn)。

結(jié)束通話

正確結(jié)束 WebRTC 呼叫對(duì)於避免未來(lái)連接期間出現(xiàn)問(wèn)題至關(guān)重要，例如資源洩漏或重新連接時(shí)出現(xiàn)錯(cuò)誤。以下是正確處理呼叫終止的詳細(xì)指南：

1 刪除 ICE 候選人：
ICE 候選人用於在同行之間建立聯(lián)繫。
在結(jié)束通話之前，請(qǐng)清除所有儲(chǔ)存的 ICE 候選項(xiàng)，以確保它們不會(huì)幹?jǐn)_未來(lái)的連線。

2 通知其他客戶：
通知另一位客戶通話即將結(jié)束。
這可以透過(guò)信令伺服器來(lái)完成，以優(yōu)雅地終止雙方的連線。

3 從對(duì)等連結(jié)中刪除曲目：
刪除與對(duì)等連接關(guān)聯(lián)的所有媒體軌道（音訊/視訊）以釋放資源。
這可以防止通話結(jié)束後繼續(xù)播放媒體串流。

4 重設(shè)通話狀態(tài)：
將變數(shù) Calling_clicked 設(shè)定為 null（或應(yīng)用程式中的等效值）。
這可確保應(yīng)用程式知道沒(méi)有正在進(jìn)行的活動(dòng)呼叫。
將 Peer 1 和 Peer 2 重設(shè)為空。
這會(huì)釋放為對(duì)等連接分配的內(nèi)存，並避免意外重複使用舊物件。
將remoteStream 設(shè)定為null。
這可確保從應(yīng)用程式介面清除遠(yuǎn)端音訊/視訊串流。

只有一側(cè)，因?yàn)橹挥幸粋€(gè)客戶端發(fā)起結(jié)束

總結(jié)

建立隨機(jī)視訊聊天應(yīng)用程式與使用它一樣令人興奮！這個(gè)過(guò)程伴隨著相當(dāng)多的挑戰(zhàn)和學(xué)習(xí)機(jī)會(huì)，但看到你的創(chuàng)作變成現(xiàn)實(shí)的滿足感是真正值得的。

作為一名電腦科學(xué)專業(yè)三年級(jí)學(xué)生，我將我的熱情和好奇心傾注到了這個(gè)專案中。雖然我已盡最大努力確保一切順利進(jìn)行，但總有改進(jìn)的空間。如果您發(fā)現(xiàn)任何缺陷或有建議讓這個(gè)專案變得更好，請(qǐng)隨時(shí)與我聯(lián)繫 - 我很樂(lè)意學(xué)習(xí)您的見(jiàn)解！

所以，拿起你的鍵盤，深入研究程式碼，誰(shuí)知道呢 - 你可能會(huì)創(chuàng)造線上交流中的下一個(gè)重大事件。

編碼愉快！ ？

以上是如何使用 Webrtc、Websocket 和 Django 建立隨機(jī)視訊聊天 Web 應(yīng)用程式。的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！