在我大學二年級時，我和我的朋友常常花幾個小時在 Omegle 上，與來自世界各地的隨機人聊天。這總是充滿樂趣和驚喜——你永遠不知道下一個會遇到誰。當 Omegle 關閉後，留下了一片空白。我們懷念那些隨機連結的興奮感，就在那時我想，「為什麼不建構我自己的版本呢？」
在這篇部落格中，我將詳細介紹使用 WebRTC 和 WebSocket 設計和建構此類平台的過程，重點介紹我面臨的挑戰以及如何克服這些挑戰。讀完本部落格後，您不僅會了解它的工作原理，還會為開始建立自己的即時通訊應用程式奠定堅實的基礎
我目前正在開發一個名為 Noto Chats 的項目，其中包括隨機視訊聊天功能以及其他幾個令人興奮的功能。該系統已經過徹底測試並且可以無縫運行。
這是 ramdomvideo 聊天應用程式的程式碼連結 https://github.com/Arsh910/RandomVideo-Chat-app
前端：用於建立互動式使用者介面的 ReactJS。
後端：用於處理 WebSocket 連線的 Django Channels。
訊號協定：用於建立 WebRTC 連線的 WebSocket。
媒體串流：用於點對點視訊和音訊通訊的 WebRTC。
雙方都會嘗試建立連接，先建立的將繼續
如果您不熟悉 WebRTC 的工作原理，請觀看我學習的這個影片。以下是組件的簡要概述
1。客戶端 1 和客戶端 2
這些代表嘗試連線的兩個用戶。每個客戶端負責建立報價、將其發送到伺服器並回應他們收到的報價。
類比：將客戶 1 和客戶 2 視為兩個想要進行對話的人。他們還不認識，但很想交談。各自主動伸手等待對方回應。
2。伺服器
伺服器充當媒人的角色。它不處理實際的對話，而是透過在客戶之間傳遞報價和答案並幫助交換連接詳細資訊來促進介紹。
類比：想像一個共同的朋友在聚會上介紹兩個人。朋友沒有加入他們的談話，但要確保他們知道彼此的姓名和電話號碼才能開始交談。
3。對等連接
PeerConnection 是一種在兩個客戶之間建立直接連結的機制。它管理媒體（音訊/視訊）交換並確保連接建立後保持穩定。就像上圖的peer1和peer 2一樣。
類比：PeerConnection 就像兩棟房子之間的安全、私人隧道。隧道建成後，裡面的人可以在沒有其他人看到的情況下傳遞紙條、交談，甚至寄包裹。
4。 ICE 候選人
ICE（互動式連線建立）候選者是直接連接的建置區塊。這些是 PeerConnection 嘗試用來建立最佳連線的路由和網路路徑。
類比：ICE候選人就像地圖，顯示了連接兩棟房子的多條道路。連接找到最佳道路（最短、最平滑）並使用它來確保快速可靠的路線。
5。提議與答覆
連接過程從一個客戶端（呼叫者）建立報價並透過伺服器將其傳送到另一個客戶端開始。第二個客戶端（接收者）建立一個答案並將其發回。此交換建立了連線。
類比：想像一個人發送一封信說：「我們做朋友吧！」另一個人回答：「當然，我也想要！」一旦他們同意，友誼就開始了。
6。曲目（音訊/視訊串流）
軌道是指建立連線後在客戶端之間共享的媒體串流（音訊和視訊）。
類比：曲目就像來自兩個攝影機和麥克風的即時回饋。每個人都可以即時看到和聽到對方正在分享的內容，就像即時視訊通話一樣。
7。訊號流程
信令過程涉及透過伺服器交換報價、答案和 ICE 候選人。這可確保兩個客戶端都擁有建立直接對等連線所需的資訊。
類比：訊號過程就像郵政系統在兩個想要聯繫的人之間傳遞訊息。郵差（服務器）確保信件（報價、答复）到達正確的收件人，以便對話可以開始。
要理解設計，首先要抓住一個關鍵挑戰。
在傳統的電話通話中，連接過程涉及一個人充當呼叫者，另一個人充當接收者。然而，在這樣的聊天應用程式中，情況就不同了。在這裡，每個用戶都在發起連線並等待其他人接受它。這意味著每個人都必須同時充當呼叫者和接收者，創建一個兩個角色融合以實現無縫連接的系統。
這就是為什麼我使用兩個對等連接，peer1 和peer2。
OnIceCandidateFunc
處理 ICE 候選交換以建立點對點連線。當從 STUN 伺服器收到 Ice 候選時，它會將 ICE 候選發送到伺服器。
OnTrackFunc
處理從對等方接收的媒體軌道（音訊/視訊）。當對等方傳輸曲目時啟動。在接收者的介面上顯示媒體。
handle_ice
處理從其他客戶收到的冰候選人。它會添加收到的ice候選並將它們添加到對等連接中。
取得隨機使用者
此函數從線上用戶清單中隨機選擇一個用戶，不包括目前用戶。如果列表為空，則會拋出錯誤。這確保了聊天的公平隨機配對。
送比賽
此函數會向伺服器發送選定隨機使用者的連線請求。它建構一個 WebSocket 訊息，通知伺服器連接的意圖。
檢查匹配
此函數驗證伺服器的回應是否確認成功匹配。它檢查其他人選擇了該用戶。它檢查該用戶是否選擇了其他用戶。它檢查calling_clicked標誌是否為true（重要的是其他使用者也點擊了呼叫）。
如果滿足所有條件，則傳回true；否則，傳回 false。此步驟可確保在繼續之前正確驗證連線。
了解配對過程的範例
雙方都會發送和接收，先接收的一方被佔領
對等 1 和對等 2
為了建立連接，兩個對等點（對等點 1 和對等點 2）扮演不同的角色：
Peer 1：負責建立報價並接收答案。
對等 2：處理報價、產生答案並將其發回。
連接過程
以下是匹配後連接過程的展開方式：
1 正在初始化對等點 1：
Peer 1 在兩個客戶端上建立（例如客戶端 1 和客戶端 2）。
Peer 1 附加了兩個關鍵事件：
OnTrackFunc：管理來自其他對等點的傳入音訊/視訊串流。
OnIceCandidateFunc：每當從 STUN 伺服器收到新候選時，將 ICE 候選傳送到伺服器。
2 建立並發送報價：
Peer 1 產生一個報價，該報價被設定為其 localDescription。
此優惠由兩個客戶端發送給匹配的用戶（透過信令伺服器）。
3 與同業 2 處理報價：
收到報價後，雙方都會建立 Peer 2。
與 Peer 1 類似，Peer 2 透過 OnTrackFunc 和 OnIceCandidateFunc 事件進行初始化。
收到的報價被設定為 Peer 2 的遠端描述。
4 產生並發送答案：
Peer 2 產生一個答案，該答案被設定為其 localDescription。
這個答案由雙方傳回另一個客戶端（透過伺服器）。
5 完成連線：
一旦收到答案，它就會被設定為對等點 1 的遠端描述。
兩個客戶端現在都擁有建立直接連線所需的資訊。
雙方都會發送和接收
6 處理 ICE 候選人：
當 ICE 候選者交換時，OnIceCandidateFunc 被觸發。
使用handle_ice函數處理收到的ICE候選者，該函數根據連接設定將它們新增至適當的對等點（對等點1或對等點2）。
7 設定媒體串流：
當接收到媒體軌道（音訊/視訊）時，會觸發 OnTrackFunc 事件。
這可確保遠端視訊和音訊串流在兩個用戶端上顯示。
雙方都會發送和接收
由於使用者選擇的隨機性和處理延遲，連接過程不會在雙方同時發生。首先完成設定的客戶端將成為“呼叫者”，而另一個則充當“接收者”。
WebRTC 連線成功建立後，雙方使用者都可以享受無縫的視訊聊天體驗。
正確結束 WebRTC 呼叫對於避免未來連接期間出現問題至關重要，例如資源洩漏或重新連接時出現錯誤。以下是正確處理呼叫終止的詳細指南：
1 刪除 ICE 候選人：
ICE 候選人用於在同行之間建立聯繫。
在結束通話之前，請清除所有儲存的 ICE 候選項，以確保它們不會幹擾未來的連線。
2 通知其他客戶：
通知另一位客戶通話即將結束。
這可以透過信令伺服器來完成，以優雅地終止雙方的連線。
3 從對等連結中刪除曲目：
刪除與對等連接關聯的所有媒體軌道（音訊/視訊）以釋放資源。
這可以防止通話結束後繼續播放媒體串流。
4 重設通話狀態：
將變數 Calling_clicked 設定為 null（或應用程式中的等效值）。
這可確保應用程式知道沒有正在進行的活動呼叫。
將 Peer 1 和 Peer 2 重設為空。
這會釋放為對等連接分配的內存，並避免意外重複使用舊物件。
將remoteStream 設定為null。
這可確保從應用程式介面清除遠端音訊/視訊串流。
只有一側，因為只有一個客戶端發起結束
建立隨機視訊聊天應用程式與使用它一樣令人興奮！這個過程伴隨著相當多的挑戰和學習機會，但看到你的創作變成現實的滿足感是真正值得的。
作為一名電腦科學專業三年級學生，我將我的熱情和好奇心傾注到了這個專案中。雖然我已盡最大努力確保一切順利進行，但總有改進的空間。如果您發現任何缺陷或有建議讓這個專案變得更好，請隨時與我聯繫 - 我很樂意學習您的見解！
所以，拿起你的鍵盤，深入研究程式碼，誰知道呢 - 你可能會創造線上交流中的下一個重大事件。
編碼愉快！ ？
以上是如何使用 Webrtc、Websocket 和 Django 建立隨機視訊聊天 Web 應用程式。的詳細內容。更多資訊請關注PHP中文網其他相關文章！
