대학 2학년 때 나와 내 친구는 Omegle에서 전 세계의 무작위 사람들과 채팅을 하며 몇 시간을 보내곤 했습니다. 항상 재미와 놀라움이 뒤섞였습니다. 다음에 누구를 만날지 전혀 알 수 없었습니다. Omegle이 종료되면 공백이 생겼습니다. 우리는 무작위로 연결되는 즐거움이 그리워서 "나만의 버전을 만들어 보는 것은 어떨까?"라고 생각했습니다.
이 블로그에서는 WebRTC와 WebSocket을 사용하여 이러한 플랫폼을 설계하고 구축하는 과정을 분석하고 제가 직면한 과제와 이를 극복한 방법을 강조하겠습니다. 이 블로그를 마치면 작동 방식을 이해할 수 있을 뿐만 아니라 자신만의 실시간 커뮤니케이션 애플리케이션을 구축하기 위한 탄탄한 기반을 갖추게 될 것입니다
저는 현재 Noto Chats라는 프로젝트를 진행하고 있습니다. 이 프로젝트에는 무작위 영상 채팅 기능과 기타 여러 가지 흥미로운 기능이 포함되어 있습니다. 시스템은 철저한 테스트를 거쳤으며 원활하게 작동합니다.
ramdomvideo 채팅 앱용 코드 링크는 다음과 같습니다 https://github.com/Arsh910/RandomVideo-Chat-app
프런트엔드: 대화형 사용자 인터페이스 구축을 위한 ReactJS
백엔드: WebSocket 연결을 처리하기 위한 Django 채널.
신호 프로토콜: WebRTC 연결을 설정하는 WebSocket.
미디어 스트리밍: P2P 비디오 및 오디오 통신을 위한 WebRTC.
양측 동료는 연결을 시도하고 먼저 연결하는 쪽이 진행됩니다
WebRTC 작동 방식에 익숙하지 않다면 제가 배운 이 동영상을 확인해 보세요. 구성 요소에 대한 간략한 개요는 다음과 같습니다
1. 클라이언트 1과 클라이언트 2
이는 연결을 시도하는 두 명의 사용자를 나타냅니다. 각 클라이언트는 제안을 생성하고, 이를 서버에 보내고, 받은 제안에 응답하는 일을 담당합니다.
유추: 고객 1과 고객 2를 대화를 원하는 두 사람으로 생각하십시오. 그들은 아직 서로를 모르지만 이야기를 나누고 싶어합니다. 각자가 주도적으로 연락하고 상대방의 응답을 기다립니다.
2. 서버
서버는 중매인 역할을 합니다. 실제 대화를 처리하지는 않지만 클라이언트 간에 제안과 답변을 전달하고 연결 세부 정보를 교환하도록 도와줌으로써 소개를 용이하게 합니다.
비유: 파티에서 두 사람을 소개하는 친구가 있다고 상상해 보세요. 친구는 대화에 참여하지 않지만 대화를 시작하기 위해 서로의 이름과 전화번호를 알고 있는지 확인합니다.
3. 피어커넥션
PeerConnection은 두 클라이언트 간의 직접 링크를 설정하는 메커니즘입니다. 미디어(오디오/비디오) 교환을 관리하고 일단 설정된 연결이 안정적으로 유지되도록 보장합니다. 위 그림의 Peer1과 Peer 2와 같습니다.
비유: PeerConnection은 두 집 사이의 안전한 개인 터널과 같습니다. 터널이 건설되면 내부 사람들은 다른 사람이 보지 못한 채 메모를 주고받고, 이야기를 나누고, 심지어 소포를 보낼 수도 있습니다.
4. ICE 후보자
ICE(대화형 연결 설정) 후보는 직접 연결을 위한 구성 요소입니다. PeerConnection이 최상의 연결을 설정하기 위해 사용하려고 하는 경로 및 네트워크 경로는 다음과 같습니다.
비유: ICE 후보는 두 집을 연결하는 여러 도로를 보여주는 지도와 같습니다. 연결은 최적의 도로(최단, 가장 부드러운)를 찾아 이를 사용하여 빠르고 안정적인 경로를 보장합니다.
5. 제안 및 답변
연결 프로세스는 한 클라이언트(발신자)가 제안을 생성하고 이를 서버를 통해 다른 클라이언트로 보내는 것으로 시작됩니다. 두 번째 클라이언트(수신자)는 답변을 생성하여 다시 보냅니다. 이 교환으로 연결이 설정됩니다.
비유: 한 사람이 "친구가 되자!"라고 편지를 보낸다고 상상해 보세요. 상대방은 “물론이죠, 저도 그랬으면 좋겠어요!”라고 대답합니다. 동의하면 우정이 시작됩니다.
6. 트랙(오디오/비디오 스트림)
트랙은 연결이 설정된 후 클라이언트 간에 공유되는 미디어 스트림(오디오 및 비디오)을 나타냅니다.
비유: 트랙은 두 대의 카메라와 마이크에서 나오는 라이브 피드와 같습니다. 각 사람은 실시간 화상 통화처럼 상대방이 공유하는 내용을 실시간으로 보고 들을 수 있습니다.
7. 신호처리
신호 프로세스에는 서버를 통한 제안, 답변 및 ICE 후보자의 교환이 포함됩니다. 이렇게 하면 두 클라이언트 모두 직접 PeerConnection을 설정하는 데 필요한 정보를 얻을 수 있습니다.
비유: 신호 프로세스는 연결하려는 두 사람 사이에 메시지를 전달하는 우편 시스템과 같습니다. 우체부(서버)는 대화가 시작될 수 있도록 편지(제안, 답변)가 올바른 수신자에게 전달되도록 합니다.
디자인을 이해하려면 먼저 핵심 과제를 파악하는 것이 중요합니다.
기존 전화 통화에서 연결 프로세스에는 한 사람이 발신자 역할을 하고 다른 사람이 수신자 역할을 하게 됩니다. 하지만 이와 같은 채팅 앱에서는 상황이 다릅니다. 여기에서 모든 사용자는 연결을 시작하고 다른 사람이 연결을 수락하기를 기다리고 있습니다. 즉, 모든 사람이 발신자와 수신자 역할을 동시에 수행해야 하며 두 역할이 통합되어 원활하게 진행되는 시스템을 만들어야 합니다.
그래서 저는 두 개의 Peer 연결인 Peer1과 Peer2를 사용했습니다.
OnIceCandidateFunc
P2P 연결 설정을 위한 ICE 후보 교환을 처리합니다. STUN 서버로부터 Ice Candidate가 수신되면 ICE Candidate를 서버로 보냅니다.
OnTrackFunc
피어로부터 수신된 미디어 트랙(오디오/비디오)을 처리합니다. 피어가 트랙을 전송할 때 활성화됩니다. 수신기의 인터페이스에 미디어를 표시합니다.
얼음처리
다른 클라이언트로부터 받은 아이스 후보를 처리합니다. 수신된 아이스 후보를 추가하여 Peer 연결에 추가합니다.
GetRandomUser
현재 사용자를 제외한 온라인 사용자 목록에서 임의의 사용자를 선택하는 기능입니다. 목록이 비어 있으면 오류가 발생합니다. 이렇게 하면 채팅에 대한 공정한 무작위 페어링이 보장됩니다.
일치 보내기
이 기능은 선택된 임의의 사용자에 대해 서버에 연결 요청을 보냅니다. WebSocket 메시지를 구성하여 서버에 연결 의도를 알립니다.
체크매치
이 함수는 서버의 응답이 성공적인 일치를 확인하는지 확인합니다. 다른 사람이 이 사용자를 선택했는지 확인합니다. 이 사용자가 다른 사용자를 선택했는지 확인합니다. calling_clicked 플래그가 true인지 확인합니다(다른 사용자도 통화를 클릭하는 것이 중요합니다).
모든 조건이 충족되면 true를 반환합니다. 그렇지 않으면 false를 반환합니다. 이 단계에서는 계속 진행하기 전에 연결이 제대로 검증되었는지 확인합니다.
매칭 과정을 이해하는 예시
양쪽에서 보내고 받는데, 먼저 받는 쪽이 차지합니다
Peer 1 및 Peer 2
연결을 설정하기 위해 피어 1과 피어 2라는 두 피어가 서로 다른 역할을 수행합니다.
피어 1: 제안을 생성하고 답변을 받는 역할을 담당합니다.
피어 2: 제안을 처리하고 답변을 생성한 후 다시 보냅니다.
연결과정
매치가 이루어진 후 연결 과정은 다음과 같습니다.
1 피어 1 초기화 중:
피어 1은 두 클라이언트(예: 클라이언트 1 및 클라이언트 2) 모두에서 생성됩니다.
피어 1에는 두 가지 주요 이벤트가 연결되어 있습니다.
OnTrackFunc: 다른 피어로부터 들어오는 오디오/비디오 스트림을 관리합니다.
OnIceCandidateFunc: STUN 서버로부터 새로운 후보가 수신될 때마다 ICE 후보를 서버로 보냅니다.
2 제안 생성 및 보내기:
피어 1은 localDescription으로 설정된 제안을 생성합니다.
이 제안은 두 클라이언트 모두에 의해 (신호 서버를 통해) 일치하는 사용자에게 전송됩니다.
3 피어 2와 함께 제안 처리:
제안을 받으면 양쪽에 Peer 2가 생성됩니다.
피어 1과 유사하게 피어 2는 OnTrackFunc 및 OnIceCandidateFunc 이벤트로 초기화됩니다.
수신된 제안은 Peer 2의 RemoteDescription으로 설정됩니다.
4 답변 생성 및 보내기:
피어 2는 localDescription으로 설정된 답변을 생성합니다.
이 답변은 양측에서 (서버를 통해) 다른 클라이언트에게 다시 전송됩니다.
5 연결 완료:
답변을 받으면 Peer 1의 원격 설명으로 설정됩니다.
이제 두 클라이언트 모두 직접 연결을 설정하는 데 필요한 정보를 갖게 되었습니다.
양측이 보내고 받습니다
6 ICE 후보자 처리:
ICE 후보가 교환되면서 OnIceCandidateFunc가 트리거됩니다.
수신된 ICE 후보는 연결 설정에 따라 적절한 피어(피어 1 또는 피어 2)에 추가되는 handler_ice 함수를 사용하여 처리됩니다.
7 미디어 스트림 설정:
OnTrackFunc 이벤트는 미디어 트랙(오디오/비디오)이 수신되면 트리거됩니다.
이렇게 하면 원격 비디오 및 오디오 스트림이 두 클라이언트 모두에 표시됩니다.
양측이 보내고 받습니다
사용자 선택의 무작위성 및 처리 지연으로 인해 연결 프로세스가 양쪽에서 동시에 발생하지 않습니다. 먼저 설정을 완료한 클라이언트가 "발신자"가 되고 다른 클라이언트가 "수신자" 역할을 합니다.
WebRTC 연결이 성공적으로 설정되면 두 사용자 모두 원활한 영상 채팅 경험을 즐길 수 있습니다.
재연결 중 리소스 누출이나 오류와 같은 향후 연결 문제를 방지하려면 WebRTC 호출을 올바르게 종료하는 것이 중요합니다. 통화 종료를 적절하게 처리하기 위한 자세한 지침은 다음과 같습니다.
1 ICE 후보 제거:
ICE 후보는 피어 간의 연결을 설정하는 데 사용됩니다.
통화를 종료하기 전에 저장된 ICE 후보를 모두 지워 향후 연결을 방해하지 않도록 하세요.
2 다른 고객에게 알림:
상대방에게 통화가 종료됨을 알립니다.
이는 신호 서버를 통해 수행되어 양쪽 연결을 정상적으로 종료할 수 있습니다.
3 피어 연결에서 트랙 제거:
피어 연결과 관련된 모든 미디어 트랙(오디오/비디오)을 제거하여 리소스를 확보하세요.
이렇게 하면 통화가 끝난 후 미디어 스트림이 계속되는 것을 방지할 수 있습니다.
4 통화 상태 재설정:
call_clicked 변수를 null(또는 애플리케이션에서 이에 상응하는 값)로 설정합니다.
이렇게 하면 애플리케이션이 진행 중인 활성 통화가 없음을 알 수 있습니다.
피어 1과 피어 2를 null로 재설정합니다.
이렇게 하면 피어 연결에 할당된 메모리가 해제되고 이전 개체가 실수로 재사용되는 것을 방지할 수 있습니다.
RemoteStream을 null로 설정하세요.
이렇게 하면 애플리케이션 인터페이스에서 원격 오디오/비디오 스트림이 지워집니다.
한쪽만, 클라이언트 중 한 쪽만 종료를 시작하므로
랜덤 영상 채팅 앱을 만드는 것은 앱을 사용하는 것만큼 흥미진진합니다! 이 과정에는 상당한 어려움과 학습 기회가 따르지만, 자신의 창작물이 살아 움직이는 것을 보는 만족감은 정말 보람있습니다.
컴퓨터과학과 3학년인 저는 이 프로젝트에 열정과 호기심을 쏟았습니다. 모든 것이 원활하게 작동하도록 최선을 다했지만 항상 개선의 여지가 있습니다. 결점을 발견했거나 이 프로젝트를 개선하기 위한 제안 사항이 있으면 주저하지 말고 저에게 연락해 주세요. 여러분의 통찰력을 듣고 싶습니다!
키보드를 들고 코드를 자세히 살펴보세요. 온라인 커뮤니케이션 분야에서 차세대 혁신을 만들어낼 수도 있습니다.
즐거운 코딩하세요! ?
위 내용은 Webrtc, Websocket 및 Django를 사용하여 무작위 영상 채팅 웹 앱을 구축하는 방법.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
