IOS WebRTC 의 실현 원 리 를 상세히 설명 하 다.

개술
이 는 2011 년 5 월 에 공사 의 소스 코드 를 개 방 했 고 업계 에서 광범 위 한 지원 과 응용 을 받 아 차세 대 영상 통화 의 기준 이 되 었 다.
WebRTC 의 음성 영상 통신 은 P2P 를 바탕 으로 하 는데 P2P 는 무엇 입 니까?
그것 은 점 대 점 연결 의 영문 줄 임 말이다.
P2P 연결 모드
일반적으로 우리 의 전통 적 인 연결 방식 은 모두 서버 를 중개 하 는 모델 이다.
http 프로 토 콜 유사:클 라 이언 트?서버(물론 이 서버 에서 돌아 오 는 화살 표 는 요청 데 이 터 를 되 돌려 주 는 것 을 의미 합 니 다).
우리 가 실시 간 통신 을 할 때 문자,사진,녹음 등 전송 을 할 때:클 라 이언 트 A?서버클 라 이언 트 B.
점 대 점 의 연결 은 바로 데이터 채널 이 형성 되면 중간 에 서버 를 거치 지 않 고 데 이 터 는 한 클 라 이언 트 에서 다른 클 라 이언 트 로 직접 흐른다.
클 라 이언 트 A?클 라 이언 트 B...클 라 이언 트 A?클 라 이언 트 C...(수많은 클 라 이언 트 간 연결 가능)
여기 서 음성 영상 통화 의 응용 장면 을 생각해 볼 수 있다.우리 서버 는 이들 의 통신 데 이 터 를 얻 을 필요 가 없다.그리고 이렇게 하 는 가장 큰 장점 은 서버 의 스트레스 를 크게 줄 이 는 것 이다.
WebRTC 는 바로 P2P 를 바탕 으로 하 는 음성 영상 통신 기술 이다.
WebRTC 의 서버 와 신호
여기까지 만 말씀 드 리 면 WebRTC 는 서버 가 필요 없다 고 생각 하 시 나 요?이것 은 분명히 잘못된 인식 이다.엄 밀 히 말 하면 서버 가 데이터 중 전 을 할 필요 가 없 을 뿐이다.
웹 RTC 는 브 라 우 저 에서 브 라 우 저(점 대 점)간 의 통신 을 제공 하지만 웹 RTC 가 서버 가 필요 없다 는 것 은 아니다.서버 기반 확장 업 무 는 물론 이 고 WebRTC 는 서버 에 두 가지 이상 사용 해 야 합 니 다.
4.567917.브 라 우 저 간 에 통신 을 만 드 는 메타 데이터(신호)를 교환 하려 면 서버 를 통과 해 야 합 니 다NAT 와 방화벽 을 통과 하기 위해..제1조 이해 하기 쉽 습 니 다.우 리 는 A 와 B 가 P2P 연결 을 구축 해 야 할 때 적어도 서버 가 조 화 를 이 루어 연결 이 시작 되 는 것 을 제어 해 야 합 니 다.연결 이 끊 겼 을 때 도 다른 쪽 P2P 연결 이 끊 겼 음 을 알려 주 는 서버 가 필요 합 니 다.연결 상 태 를 제어 하 는 데 사용 되 는 데 이 터 를 신호 라 고 하 는데,이 는 서버 와 연 결 된 채널 로 WebRTC 에 있어 서 신호 채널 입 니 다.

그림 에서 signalling 은 서버 에 신 호 를 보 낸 다음 에 바 텀 에서 WebRTC 를 호출 하고 WebRTC 는 서버 에서 받 은 신 호 를 통 해 통신 상대방 의 기본 정 보 를 알 게 되 어 오프라인 부분 Media 통신 연결 을 실현 한다.
물론 신령 이 할 수 있 는 일 은 아직 많 습 니 다.여기 서 대충 열거 해 보 았 습 니 다.
4.567917.통신 이 켜 지 거나 닫 히 는 연결 제어 메 시 지 를 제어 하 는 데 사용 된다

오류 가 발생 했 을 때 서로 에 게 알 리 는 소식

4.567917.미디어 스 트림 메타 데이터,예 를 들 어 디코더,디코더 의 설정,대역 폭,미디어 유형 등4.567917.안전 연결 을 구축 하 는 관건 적 인 데이터외부 에서 본 네트워크 상의 데이터,예 를 들 어 IP 주소,포트 등연결 을 구축 하기 전에 클 라 이언 트 간 에 데 이 터 를 전달 할 방법 이 분명히 없다.그래서 저 희 는 서버 의 중간 을 통 해 클 라 이언 트 간 에 이 데 이 터 를 전달 한 다음 에 클 라 이언 트 간 의 점 대 점 연결 을 구축 해 야 합 니 다.그러나 WebRTC API 에 서 는 이 를 실현 하지 못 했 으 니 이 를 우리 가 실현 해 야 한다.
제2 조 의 NAT 라 는 개념 은 글 iOS 인 스 턴 트 메 신 저 를 참고 하여 입문 부터'포기'까지?NAT 시간 초과 에 대비 한 TCP 연결 중단 에 불과 하 다 는 언급 도 있 었 다.여기 서 우 리 는 전개 하지 않 고 이야기 할 것 입 니 다.관심 있 는 것 은 NAT 백과 입 니 다.
NAT 기술 의 등장 은 IPV 4 의 IP 주소 부족 을 해결 하기 위 한 것 임 을 간략하게 설명 하 겠 습 니 다.예 를 들 어 보통 우 리 는 하나의 공유 기 아래 에 있 는데 공유 기 가 우리 에 게 배정 한 주 소 는 192.168.0.1,192.168.0.2 이다.만약 에 n 개의 장치 가 있 으 면 192.168.0.n 으로 분 배 될 수 있다.이 IP 주 소 는 내부 네트워크 의 IP 주소 일 뿐이다.이런 공유 기의 공공 네트워크 주 소 는 n 개의 내부 네트워크 의 주소 에 대응 된다.소량의 공유 IP 주 소 를 사용 하 는 것 은 비교적 많은 개인 IP 주 소 를 대표 하 는 방식 으로 사용 가능 한 IP 주소 공간의 고갈 을 늦 추 는 데 도움 이 될 것 이다.
그러나 이것 은 일련의 문 제 를 가 져 왔 다.예 를 들 어 여기 점 대 점 연결 에서 이런 문 제 를 초래 할 수 있다.
만약 에 클 라 이언 트 A 가 클 라 이언 트 B 에 게 데 이 터 를 보 내 려 고 하면 데 이 터 는 클 라 이언 트 B 가 있 는 공유 기 에 와 서 NAT 에 의 해 차단 되 고 B 는 A 의 데 이 터 를 받 을 수 없다.
그러나 A 의 NAT 는 이때 B 라 는 주 소 를 알 고 있 었 기 때문에 B 가 A 에 게 데 이 터 를 보 낼 때 NAT 가 막 지 않 아 A 가 B 의 데 이 터 를 받 을 수 있 었 다.이것 이 바로 우리 가 NAT 타임 슬립 을 하 는 핵심 사고방식 이다.
그래서 우 리 는 다음 과 같은 생각 이 들 었 다.
우 리 는 하나의 공공 네트워크 IP 서버 를 빌려 a,b 가 모두 공공 네트워크 IP/PORT 에 가방 을 보 내 면 공공 네트워크 서버 에서 a,b 의 IP/PORT 를 알 수 있 고 a,b 가 자발적으로 공공 네트워크 IP 서버 에 가방 을 보 내기 때문에 공공 네트워크 서버 는 NAT A,NAT B 를 관통 하여 a,b 에 게 가방 을 보 낼 수 있다.
그래서 인터넷 IP 가 b 의 IP/PORT 를 a,a 의 IP/PORT 를 b 에 게 보 내 면 됩 니 다.이렇게 하면 다음 에 a 와 b 가 서로 소식 을 전하 면 NAT 에 의 해 저지 되 지 않 을 것 이다.
WebRTC 의 NAT/방화벽 통과 기술
상술 한 사고방식 을 바탕 으로 실 현 된 것:
점대 점 채널 을 구축 하 는 흔 한 문 제 는 바로 NAT 타임 슬립 기술 이다.NAT 장 치 를 사용 하 는 개인 TCP/IP 네트워크 에 있 는 호스트 간 연결 이 필요 할 때 NAT 타임 슬립 기술 을 사용 해 야 합 니 다.기 존 에는 VoIP 분야 에서 이 문 제 를 자주 겪 었 다.현재 이미 많은 NAT 타임 슬립 기술 이 있 지만,NAT 의 행동 이 비 표준화 되 어 있 기 때문에 완벽 한 것 은 하나 도 없다.이 기술 들 은 대부분 공공 서버 를 사 용 했 는데 이 서 비 스 는 전 세계 어느 곳 에서 든 접근 할 수 있 는 IP 주 소 를 사용 했다.RTCPeeConnection 에서 ICE 프레임 워 크 를 사용 하여 RTCPeerConnection 이 NAT 타임 슬립 을 실현 할 수 있 도록 보장 합 니 다.

여기 서 ICE 프로 토 콜 의 구 조 를 언급 했다.이 는 다음 과 같은 몇 가지 기술 과 협의 로 구 성 된 것 이다.STUN,NAT,TURN,SDP 등 프로 토 콜 기술 은 ICE 가 공동으로 NAT/방화벽 타임 슬립 을 실현 하도록 도와 준다.
이상 은 IOS WebRTC 의 실현 원 리 를 상세 하 게 설명 하 는 상세 한 내용 입 니 다.IOS WebRTC 의 실현 원리 에 관 한 자 료 는 저희 의 다른 관련 글 을 주목 하 시기 바 랍 니 다!