WebRTC를 사용하면 임의의 데이터, 오디오 또는 비디오(또는 이들의 조합)의 피어 투 피어 통신을 브라우저 애플리케이션으로 구축할 수 있습니다.
연결을 설정하는 것부터 더 이상 필요하지 않을 때 연결을 종료하는 것까지 WebRTC 세션의 수명을 살펴보겠습니다.
NAT환경은 피어-투-피어 네트워킹을 시도하는 개발자에게 이는 문제를 야기합니다. 사용자의 문제는 인터넷의 각 개별 컴퓨터가 더 이상 고유한 IP 주소를 가질 필요가 없으며 실제로 각 장치의 IP 주소는 한 네트워크에서 다른 네트워크로 이동할 때뿐만 아니라 네트워크 주소가 변경될 경우에도 변경될 수 있다는 것입니다.
모든 사용자 장치에 대한 고유 식별자가 없으면 인터넷에서 특정 장치에 연결하는 방법을 즉시 자동으로 알 수 없습니다. 누구와 대화하고 싶은지 알고 있어도 연락 방법이나 주소를 반드시 알 필요는 없습니다.
시그널링은 두 장치 간에 제어 정보를 전송하여 통신 프로토콜, 채널, 미디어 코덱 및 형식, 데이터 전송 방법 및 필요한 라우팅 정보를 결정하는 프로세스입니다.
WebRTC의 시그널링 프로세스에 대해 알아야 할 가장 중요한 사항은 사양에 정의되어 있지 않다는 것입니다 .
WebRTC 연결을 설정하는 프로세스의 기본 사항이 사양에서 제외된 이유는 무엇입니까? 대답은 간단합니다. 두 장치가 서로 직접 접촉할 수 있는 방법이 없고 사양이 WebRTC의 가능한 모든 사용 사례를 예측할 수 없기 때문에 개발자가 적절한 네트워킹 기술과 메시징 프로토콜을 선택하도록 하는 것이 더 합리적입니다.
특히, 개발자가 이미 두 장치를 연결하기 위한 방법을 가지고 있는 경우, WebRTC에 대해서만 사양에 정의된 다른 방법을 사용해야 하는 것은 의미가 없습니다.
시그널링을 수행하기 위한 채널이 네트워크를 통해 있을 필요조차 없다는 점도 주목할 가치가 있습니다. 한 피어는 인쇄할 수 있는 데이터 개체를 출력하고, 다른 장치로 물리적으로 운반(도보 또는 운반 비둘기)하고, 해당 장치에 입력한 다음 해당 장치에서 응답을 출력하여 도보로 반환하는 등의 작업을 수행할 수 있습니다. WebRTC 피어 연결이 열릴 때까지. 대기 시간이 매우 길지만 할 수 있습니다.
시그널링 중에 교환해야 하는 세 가지 기본 유형의 정보가 있습니다.
- 통신 채널을 설정하고 열고 닫고 오류를 처리하는 데 사용되는 제어 메시지입니다.
- 연결을 설정하기 위해 필요한 정보: 피어가 서로 대화할 수 있도록 하는 데 필요한 IP 주소 지정 및 포트 정보.
- 미디어 기능 협상: 피어가 이해할 수 있는 코덱 및 미디어 데이터 형식은 무엇입니까? WebRTC 세션을 시작하기 전에 동의해야 합니다.
시그널링이 성공적으로 완료되면 WebRTC 피어 연결을 여는 진정한 프로세스가 시작될 수 있습니다. 시그널링 서버는 실제로 신호를 보내는 동안 두 피어가 이를 통해 교환하는 데이터를 이해하거나 아무 것도 할 필요가 없다는 점에 주목할 가치가 있습니다. 시그널링 서버는 본질적으로 릴레이입니다. 즉, 시그널링 데이터가 이를 통해 전송될 수 있음을 알고 양측이 연결하는 공통 지점입니다. 서버는 어떤 식으로든 이 정보에 반응할 필요가 없습니다.
WebRTC 세션을 시작할 수 있도록 하기 위해 발생해야 하는 일련의 작업이 있습니다.
- 각 피어는 WebRTC 세션의 끝을 나타내는
RTCPeerConnection객체를 생성합니다. - 각 피어는
icecandidate이벤트에 대한 핸들러를 설정하여 시그널링 채널을 통해 해당 후보를 다른 피어로 보내는 작업을 처리합니다. - 각 피어는 원격 피어가 스트림에 트랙을 추가할 때 수신되는 트랙 이벤트에 대한 핸들러를 설정합니다. 이 코드는
- 호출자는 시그널링 서버의 코드로 그들 사이의 호출을 식별할 수 있도록 고유 식별자 또는 일종의 토큰을 생성하고 수신 피어와 공유합니다. 이 식별자의 정확한 내용과 형식은 귀하에게 달려 있습니다.
- 각 피어는 메시지 교환 방법을 알고 있는 WebSocket 서버와 같은 합의된 시그널링 서버에 연결합니다.
- 각 피어는 동일한 WebRTC 세션(4단계에서 설정된 토큰으로 식별됨)에 참여하기를 원한다고 시그널링 서버에 알립니다.
- descriptions, candidates, etc
때때로 WebRTC 세션이 진행되는 동안 네트워크 조건이 변경됩니다. 예를 들어 사용자 중 한 명이 셀룰러에서 Wi-Fi 네트워크로 전환하거나 네트워크가 정체될 수 있습니다.
이 경우 ICE 에이전트는 ICE 재시작을 수행하도록 선택할 수 있습니다.
이것은 네트워크 연결이 재협상되는 프로세스로, 한 가지 예외를 제외하면 초기 ICE 협상이 수행되는 것과 똑같은 방식입니다. 미디어는 새 네트워크 연결이 시작되어 실행될 때까지 원래 네트워크 연결을 통해 계속 흐릅니다.
그런 다음 미디어가 새 네트워크 연결로 이동하고 이전 연결이 닫힙니다.
서로 다른 브라우저는 서로 다른 조건에서 ICE 다시 시작을 지원합니다. 예를 들어 네트워크 정체로 인해 모든 브라우저가 ICE 재시작을 수행하는 것은 아닙니다.
어떤 식으로든 연결 구성을 변경해야 하는 경우(예: 다른 ICE 서버 집합으로 변경) ICE를 다시 시작하기 전에 업데이트된 구성 개체로 RTCPeerConnection.setConfiguration()을 호출하여 ICE를 다시 시작하기 전에 변경할 수 있습니다.
명시적으로 ICE 재시작을 트리거하려면 true 값으로 iceRestart 옵션을 지정하고 RTCPeerConnection.createOffer()를 호출하여 재협상 프로세스를 시작합니다.
이렇게 하면 재협상 프로세스 및 결과 연결에서 사용되는 ICE 사용자 이름 조각(ufrag) 및 암호에 대한 새 값이 생성됩니다.
ICE ufrag 및 ICE 암호에 대한 새 값이 감지되면 연결의 응답자 측에서 자동으로 ICE 재시작을 시작합니다.