WebRTC의 연결 과정

이전 부분의 예표 후에 P2P 오디오 및 비디오 상호 작용 프로세스에 대한 일반적인 이해가 있어야 하며 프로세스가 번거롭고 네트워크의 최하위 계층까지 포함한다고 느낄 수 있습니다. 하지만 걱정하지 마세요. WebRTC는 오디오와 비디오를 쉽게 개발할 수 있도록 많은 도움을 주었습니다. 그렇다면 WebRTC는 정확히 무엇입니까?

WebRTC (Web Real-Time Communications)는 네트워크 응용 프로그램 또는 사이트가 비디오 스트리밍 및/또는 전송을 달성하기 위해 중개자 없이 브라우저 간에 피어 투 피어(Peer-to-Peer) 연결을 설정할 수 있는 실시간 통신 기술입니다. 오디오 스트림 또는 기타 임의 데이터. WebRTC에 포함된 이러한 표준을 통해 사용자는 플러그인이나 타사 소프트웨어를 설치하지 않고도 피어 투 피어(Peer-to-Peer) 데이터 공유 및 화상 회의를 만들 수 있습니다.

WebRTC는 Google의 독창적인 기술이 아닙니다. 2010년 Google은 VoIP 소프트웨어 개발업체인 Global IP Solutions를 약 6,820만 달러에 인수하여 회사 소유의 WebRTC 기술을 인수했습니다. 오늘날 인터넷의 오디오 및 비디오 통신 서비스 기술은 일반적으로 스카이프 와 같은 독점 기술이며, 통신 기능을 구현하려면 플러그인 또는 데스크톱 클라이언트를 설치해야 합니다. Google은 웹 개발자가 브라우저에서 직접 비디오 또는 음성 채팅 애플리케이션을 만들 수 있기를 희망합니다.Global IP Solutions는 이전에 Android, Windows Mobile 및 iPhone용 WebRTC 기반 모바일 클라이언트를 제작했습니다. Google은 브라우저 제조업체가 웹 개발자를 용이하게 하기 위해 브라우저에 기술을 직접 포함할 수 있기를 바라면서 이번에 WebRTC 오픈 소스를 만들었습니다.

개념 보충

앞에서 언급한 개념 외에도 몇 가지 관련 개념을 추가하겠습니다.

인터랙티브 링크 기능

ICE( Interactive Connectivity Establishment): 브라우저가 피어 브라우저와 연결을 설정할 수 있도록 하는 프로토콜 프레임워크입니다. 실제 네트워크에서 A에서 B로의 간단한 직접 연결이 원하는 대로 완료되지 않는 데는 여러 가지 이유가 있습니다. 이렇게 하려면 연결 설정을 방해하는 방화벽을 우회하고 장치에 고유하게 보이는 주소를 할당해야 합니다(일반적으로 대부분의 장치에는 고정된 공용 네트워크 주소가 없습니다). 라우터가 호스트가 직접 연결하는 것을 허용하지 않는 경우 서버가 데이터를 전달합니다. 이 ICE는 STUN 및 TURN과 같은 이전 연결 방법의 요약이라는 것을 발견했을 수 있습니다 공식적으로 ICE 프레임워크로 인해 개발 작업이 크게 단순화되었으며 ICE는 우선 순위에 따라 자동으로 연결 방법을 선택합니다.

시그널링 서버

시그널 서버 (signal server): 피어간 통신 주소를 교환하고, STUN을 통해 자신의 통신 주소를 획득한 후 시그널링 서버에 등록하여 장치 간 통신 주소를 교환함으로써 P2P 연결을 완료합니다.

세션 설명 프로토콜

세션 설명 프로토콜 (Session Description Protocol, SDP): 해상도, 형식, 인코딩, 암호화 알고리즘 등과 같은 멀티미디어 연결 내용을 설명하는 프로토콜입니다. P2P 연결을 시작하기 전에 양 당사자가 지원하는 세션 프로토콜을 협상해야 합니다. 사용자가 다른 사용자에게 WebRTC 호출을 시작하면 제안이라는 특정 설명 이 생성됩니다. 설명에는 발신자가 제안한 통화 구성에 대한 모든 정보가 포함됩니다. 그런 다음 수신자 는 통화 종료에 대한 설명인 응답 으로 응답합니다. 이렇게 두 장치는 미디어 데이터 교환에 필요한 정보를 서로 공유하는데 SDP는 다음과 같이 내용을 기술한다.

v=0
o=- 212360934117607227 2 IN IP4 127.0.0.1
s=-
t=0 0
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
a=rtpmap:111 opus/48000/2
......
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 35 36 124 119 123 118 114 115 116
a=rtpmap:96 VP8/90000
......

SDP 디스크립션은 하나의 세션과 여러 개의 미디어 디스크립션으로 구성되며, 세션 디스크립션은 v=부터 첫 번째 미디어 디스크립션까지(1~4줄), 미디어 디스크립션은 m=부터 다음 미디어 디스크립션까지(5~6줄— - 오디오, 라인 8-9 - 비디오).

세션 수준 설명

많은 세션 설명 필드가 있으며 가장 중요한 것은 4개의 필드입니다.

v=: 마이너 버전을 제외한 UDP 버전 번호* o=: 세션 개시자에 대한 설명 > o=* <username>: 사용자 이름, 사용자 이름이 중요하지 않은 경우 대신 "-"를 사용할 수 있습니다. * <session id>: 숫자 문자열, 전체 세션에서 고유해야 하며 NTP 타임스탬프 사용 권장 * <version>: 버전 번호, 세션 데이터가 수정될 때마다 버전 값이 증가함 * <network type>: 네트워크 유형, 일반적으로 "IN", "인터넷"을 의미합니다. * <address type>: 주소 유형, 일반적으로 IP4; * <address>: IP 주소
세션 이름: 세션을 나타냄 * t=: 시작 시간과 종료 시간에 대한 설명, t=<start time> <stop time>, 두 이벤트가 모두 0일 때 영구 세션을 의미 ##### SDP in WebRTC

WebRTC에서 SDP에 대한 일부 수정이 이루어졌으며 원본을 기반으로 일부 다른 설명이 추가되었습니다.

// 音频使用9端口收发; 
// UDP / TLS / RTP / SAVPF 表示使用 dtls / srtp 协议对数据加密传输;
m = audio 9 UDP / TLS / RTP / SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
// 网络描述, webRTC不使用
c = IN IP4 0.0.0.0
// 设置rtcp地址和端口, webRTC不使用
a = rtcp: 9 IN IP4 0.0.0.0
// 安全验证信息
a=ice-ufrag:duP8
a=ice-pwd:/7pIrSvgESATKPZUVzHhLQ0E
a=ice-options:trickle
// 音频流媒体描述
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000

미디어 설명

m=: 세션을 의미 m=<media> <port> <transport> <fmt list>* <media>: 오디오/비디오 등의 미디어 타입 * <port>: 포트 * <transport>: 전송 프로토콜로 RTP/AVP와 UDP 두 종류가 있음 * <fmt list>: 미디어 형식 즉, 데이터 페이로드 유형(Payload Type ) 목록.
a=*: a=<type>또는 a=<type>:<value>유형에는 rtpmap 및 fmap의 두 가지 유형이 있습니다 .

이제 이전 게이트웨이의 회로도를 개선하고 여기에 몇 가지 개념을 추가해 보겠습니다.

후보 주소 수집

소위 후보 주소의 집합은 앞에서 언급한 STUN 서버를 통해 자신의 통신 가능한 주소를 얻는 것입니다.

종류	별명	동료에게 보내는 방법	용법
호스트 후보	주최자	시그널링 서버	네트워크 카드에서 얻은 로컬 전송 주소, 이 주소가 NAT 뒤에 있으면 인트라넷 주소입니다.
서버 반영 후보	srflx	시그널링 서버	스턴 서버로 보낸 Binding check에서 얻은 전송 주소입니다. 이 주소가 NAT 뒤에 있으면 가장 바깥쪽 NAT의 공용 네트워크 주소입니다.
동료 반영 후보	prflx	스턴 바인딩 요청	피어가 보낸 Stun Binding 요청에서 얻은 전송 주소입니다. 이것은 연결 확인 중에 발생하는 새로운 유형의 후보입니다.
릴레이 후보	계전기	시그널링 서버	미디어 릴레이 서버의 전송 주소입니다. TURN 할당 요청을 사용하여 획득

후보 주소 교환

A는 1단계에서 수집한 후보 주소를 시그널링 서버를 통해 B에게 보내고, B도 수집한 후보 주소를 A에게 보냅니다. B의 후보 주소를 모두 받은 후 A는 자신의 후보 주소와 피어 후보 주소를 비교합니다. 전체 배열 및 상태 테이블에 저장합니다. 예를 들어 이때 A의 호스트는 192.168.0.100:60000, srflx는 11.102.30.3:30110, B의 호스트는 192.168.0.15:10001, srflx는 1.10.108.25:30110이고 상태 테이블은 다음과 같습니다.

로컬 네트워크 카드 주소	피어 주소	상태
192.168.1.105:60001	192.168.0.204:40001	스턴 체크 미수행
172.16.40.6:60003	192.168.0.204:40001	스턴 체크 미수행
192.168.1.105:60001	11.92.14.8:50002	스턴 체크 미수행
172.16.40.6:60003	11.92.14.8:50002	스턴 체크 미수행
192.168.1.105:60001	192.168.0.181:40003	스턴 체크 미수행
172.16.40.6:60003	192.168.0.181:40003	스턴 체크 미수행

이때 모든 기록 상태는 STUN 검사가 되지 않으며, 다음 단계에서 각 기록의 STUN 검사가 진행됩니다.

기절 확인

이전에 STUN 검사 프로세스를 도입했습니다. 잊어 버리면 p2p 홀 펀칭 을 검토할 수 있습니다.

연결, 부팅 미디어

STUN 검사가 완료되면 연결이 준비됩니다. 이때 P2PTransportChannel의 상태 테이블에는 각 레코드의 비용(Stun 요청을 보내고 응답을 받기까지 경과된 시간과 같은 많은 요소가 포함됨)이 기록되어 있습니다. .).

**전송할 비디오 Rtp 데이터가 있는 경우 상태 테이블의 첫 번째 레코드를 확인하고 상태가 전송 준비가 되었다고 판단되면 이 연결을 사용하여 전송합니다. 그렇지 않으면 전송 작업을 직접 포기하십시오. **즉, 미디어 모듈의 작업은 연결 상태에 영향을 받지 않고 전송하려고 할 때 상태를 확인하고 연결되지 않으면 전송을 포기합니다.

NAT 매핑 및 필터링 규칙이 미디어 세션 중에 시간 초과되지 않도록 하기 위해 ICE는 사용 중인 후보에 대해 스턴 연결 검사를 지속적으로 보냅니다. 평신도 용어로 "폴링"입니다. STUN의 응답 시간이 초과되면 비용이 증가하고 우선 순위가 낮아짐에 따라 상태 테이블에 반영됩니다. 즉, P2PTransportChannel 상태 테이블은 실시간입니다.