티스토리 뷰
728x90
반응형
WebRTC를 이해하기 위해서 어떠한 사전 지식들을 필요로 하는지 알아보고 가겠습니다.
목차
- NAT
- ICE
- STUN Server
- TURN Server
- WebRTC를 구성하는 프로토콜
NAT에 대하여
Network Address Translation
- 사람은 이름으로 구별할 수 있듯이 각 기기에도 자신만의 이름이 있습니다. 그것이 바로 IP이고, 이 IP는 고정 IP, 유동 IP로 나뉘어서 실제 고유의 값일 수도 있고 아닐 수도 있습니다. 더 나아가서 회사망/내부망은 Private IP이기 때문에 다른 네트워크(구글 홈페이지 접속, 네이버 홈페이지 접속) 등 다른 네트워크에서는 일반적으로 쓰이지 않습니다.
- 그렇기 때문에 우리가 통상적인 네트워크에서 데이터를 주고 받기 위해서는 Public IP가 필요합니다.
- NAT는 Private IP를 Public IP로 1대1 대응시켜 변환하는 장치를 말합니다.
- 하지만 WebRTC 통신은 Peer to Peer 방식으로 서로 데이터를 주고 받아야하기 때문에 보내고 받는 Peer의 정보(Public IP)를 알고 있어야하고 NAT 환경은 WebRTC 통신에 많은 문제를 일으킵니다. 이러한 문제들을 STUN, TURN 서버를 이용해서 문제를 해결할 수 있습니다.
NAT가 만들어져 사용된 이유
IPv4의 주소 부족 문제를 해결하기 위한 방법으로 사용
- IPv4가 나온지 얼마 되지 않아 빠른 속도로 주소가 고갈되었습니다. 이러한 문제로 IPv6가 개발되었고, 그 보다 먼저 IPv4 주소가 고갈될 수 있어서 이를 막기 위해 만들어진 기술이 NAT입니다. 실제로 NAT 기술로 인해 IPv6가 모두 개발딘 이후에도 바로 상용화를 하지 않고 그대로 IPv4를 사용하게 되었습니다.
보안성 강화를 목적으로 사용
- NAT를 사용하면 한 디바이스는 내부에서 사용하는 실제 주소와 외부에서 알려지는 통신용 주소로 두 개의 주소를 사용하게 됩니다. 이러한 특징 덕분에 외부에서는 내부에서 사용되는 IP주소를 알 수 없게 되고, 때문에 직접적으로 접근하여 해킹할 수 없으므로 보안을 강화할 수 있습니다.
ICE에 대하여
Interactive Connectivity Establishment
- ICE는 두 디바이스가 서로 통신할 수 있는 최적의 경로를 찾을 수 있도록 도와주는 프레임워크입니다.
- TURN, STUN 서버를 사용하여 최적의 경로를 찾을 수 있습니다.
ICE를 사용해야하는 이유
- 모든 디바이스는 각자의 환경(회사 내부망, 학교 내부망, 집의 네트워크 등)이 다양하기 때문에 Peer A에선 Peer B까지 단순하게 연결되지 않습니다. 방화벽이 존재하는 환경에서는 방화벽을 통과해야하고 디바이스의 Public IP가 없다면 유일한 IP주소를 할당해야하고 라우터가 Peer간의 직접연결을 허용하지 않을 경우에는 테이터를 릴레이해야합니다.
- ICE 프로세스를 사용하면 NAT가 통신을 위해 필요한 모든 포트를 열어두고 두 엔드 포인트 모두 연결할 수 있는 IP주소, 포트에 대한 완전한 정보를 가지게 됩니다. 결국 요청 클라이언트와 미디어 서버 사이의 연결을 통해 미디어(비디오, 음성) 등을 주고 받을 수 있습니다.
- ICE는 혼자서 작동하지 않으며 STUN과 TURN 서버를 사용해야 합니다.
STUN Server
Session Traversal Utilities for NAT
- NAT 트래버셜 작업은 STUN 서버에 의해 이루어집니다. STUN 방식은 디바이스가 자신의 Public IP 주소와 포트를 확인하는 과정에 대한 프로토콜입니다. 클라이언트가 STUN 서버에 요청을 보내면 Public Ip 주소와 함께 통신에 필요한 정보들을 보내주는데 클라이언트는 이를 이용해 다른 기기와 통신을 합니다. 하지만 이러한 경우에도 통신이 되지 않는다면 TURN 서버로 넘기게 됩니다.
TURN Server
Traversal Using Relays around NAT
- STURN 서버를 이용하더라도 항상 자신의 정보를 알아낼 수 있는거는 아닙니다. 어떤 라우터들은 방화벽 청책을 달리할 수도 있고, 이전에 연결된 적이 있는 네트워크만 연결할 수 있게 제한을 걸기도 합니다. 이 때문에 SUTN 서버를 통해 자기 자신의 주소를 찾아내지 못했을 경우 TURN 서버를 대안으로 이용하게 됩니다.
- TURN은 이러한 Symmetric NAT 제약조건을 우회하기 위해 만들어졌습니다. TURN 서버와 연결을 맺고, 이 서버에서는 모든 교환 과정을 중계하게 됩니다. 모든 디바이스는 TURN 서버로 패킷을 보내고, 서버가 이를 포워딩합니다. 하지만 모든 작업을 한 서버에서 처리하는 만틈 오버헤드가 발생할 수 있습니다.
Symmetric NAT란?
- 동일한 IP주소와 포트로부터 출발하고, 특정 IP주소와 포트로 향하는 모든 요청은 동일한 외부 IP주소와 포트로 매핑됩니다. 만약 동일한 내부 IP주소와 포트로부터 출발하지만, 목적지가 다르다면 다른 매핑이 사용됩니다. 게다가 패킷을 수신한 적이 있는 외부 호스트만이 내부 호스트에게로 패킷을 전송할 수 있습니다.
WebRTC를 구성하는 프로토콜
시그널링 (Signaling)
- WebRTC는 P2P 연결을 통해 직접 통신하지만, 이를 중계해주는 과정이 필요합니다. 이를 시그널링이라고 부리며, 이를 수행하는 서버를 시그널 서버라고 말합니다. 시그널 서버는 채팅방과 같은 형태로 연결하고자 하는 Peer 들을 논리적으로 묶고 서로간의 SDP와 Candidate를 교환하여 줍니다.
시그널링의 역할
- Session Control Messages : 통신의 초기화, 종료, 그리고 에러 메시지
- Network Configuration : 외부에서 바라보는 IP와 포트 정보
- Candidate에 서로를 추가
- ICE 프레임워크를 사용하여 서로의 IP와 포트를 찾는 과정
- Media Capabilities : 상호 두 단말의 브라우저에서 사용 가능한 코덱, 해상도
- offer와 answer 로직으로 진행하며, 형식은 SDP
SDP (Session Description Protocol)
- 생성할 세션의 타입 정보를 전송합니다. 통신을 요청하는 걸 offer, 응답하는 걸 Answer라고 합니다.
- offer에는 통신 종류가 video / audio 인지, 인코딩에는 어떤 방식을 사용할 것인지, IP 주소값 등의 정보가 들어 있습니다.
- 이 정보들을 서로 교환해야지만 통신이 가능합니다.
- 일반적으로 Web에서는 Json을 통해 통신하지만, SDP는 key=value 형태로 데이터를 전송하며 아래 7가지의 key값만 사용할 수 있습니다.
Communicationg
RTP (Real-time transport Protocol)
- 홍길동이 call을 요청하는 상황에서 홍길동의 video와 audio stream 값이 상대방에게 전송됩니다.
- 이 전송되는 데이터의 format이 RTP라고 보면 됩니다.
RTCP (Real-time Transort Control Protocol)
- 예를들어 call이 진행중인 상황에서 상대방이 말을 하고 있으면 나는 침묵(경청)을하게됩니다. 그러면 굳이 침묵이 담긴 데이터 패킷을 상대방에게 전송할 필요가 없습니다. 대역폭 낭비이므로 이때 RTCP가 이러한 역할을 해줍니다.
- 일종의 statistic tool for RTP. active call인지 확인해서 대역폭을 낭비하지 않도록 조절을 해줍니다.
SCTP (Stream Control Transmission Protocol)
- RTP / RTCP는 미디어, 오디오, screen sharing할 때만 적용이 가능한 통신 프로토콜입니다.
- SCTP는 File sharing, text message, game 관련 등 비디오나 오디오를 제외한 나머지 데이터를 통신에 활용할 때 쓰입니다.
Security
- DTLS (Datagram Transport Layer Security)
- SRTP (Secure Real-time Transport Protocol)
- 시그널링과정에서 하나의 certificate를 생성하고, 서로 교환합니다. 그러면 서로 교환환 certificate로 데이터를 복호화해서 데이터를 확인할 수 있게됩니다.
- 설령 중간에 해커가 데이터를 가로챈다해도 복호화는 불가능하도록 만드는것입니다.
728x90
반응형
'FrontEnd' 카테고리의 다른 글
WebRTC 구현하기 (feat.P2P) (2) | 2022.04.09 |
---|---|
WebRTC란? (0) | 2022.04.05 |
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
TAG
- spring boot excel download paging
- service based architecture
- transactional outbox pattern
- redis sorted set
- java userThread와 DaemonThread
- spring boot excel download oom
- JDK Dynamic Proxy와 CGLIB의 차이
- 자바 백엔드 개발자 추천 도서
- redis sorted set으로 대기열 구현
- 트랜잭셔널 아웃박스 패턴 스프링 부트 예제
- spring boot 엑셀 다운로드
- java ThreadLocal
- microkernel architecture
- @ControllerAdvice
- redis 대기열 구현
- space based architecture
- 공간 기반 아키텍처
- 서비스 기반 아키텍처
- 트랜잭셔널 아웃박스 패턴 스프링부트
- spring boot redis 대기열 구현
- pipeline architecture
- spring boot redisson 분산락 구현
- 레이어드 아키텍처란
- 람다 표현식
- polling publisher spring boot
- pipe and filter architecture
- spring boot poi excel download
- spring boot redisson sorted set
- spring boot redisson destributed lock
- transactional outbox pattern spring boot
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
글 보관함