在我大学二年级时，我和我的朋友常常花几个小时在 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中文网其他相关文章！
