WebRTC을 처음 접하기전 알아야 할 배경지식들

과거에는 웹으로 실시간 영상을 송·수신을 하는 방법이 마땅치 않았다. HLS방식을 통해서 약 6~10초, LL-HLS를 이용하여 3.5초 정도의 딜레이를 가진채 방송하는 방법이 있고, 영상 발신이라면 <Canvas>등을 이용해 Moving-Picture (Motion JPEG 등)을 만든 후 WebSocket등으로 보내는 방법이 전부였다. 하지만 각각 높은 딜레이와 높은 발신 트래픽(대역폭)이 문제였다.

WebRTC를 사용하면 RTP를 이용해서 영상을 수·발신 할 수 있다. 즉, 실시간으로 영상을 송·수신 할 있다는 것이다.

네트워크 세상에서는 서로간 통신하기 위해서는 상대방의 IP 주소 등의 정보를 알아야 한다.

• STUN (Session Traversal Utilities for NAT): 내 공인 IP주소를 알아내기 위해 쓰인다.
• SDP (Session Description Protocol): WebRTC로 서로간 연결하기 위해서는 내 정보와 상대방의 정보를 알아야 한다. SDP라는 형태에 내 정보가 담겨져 있고, 이것을 상대에게 보낸다.
• ICE: “상대방측과 연결하기 위한 실제 로직”이다. 주어진 SDP를 기반으로 상대방측과 연결을 시도한다. 네트워크를 조금 다루신 분들이라면 “홀펀칭을 실시하고 서로간 연결되게 하는 로직” 으로 이해할 수 있다.

P2P 환경에서는 서로간 연결이 불가능한 경우도 있다. 각 클라이언트가 공유기(NAT) 아래에 있는데, 서로가 Symmetric NAT의 경우라면 홀펀칭이 불가능하기 때문이다. 이때 사용되는게 TURN이다

• TURN (Traversal Using Relays around NAT): 서로간 직결로 연결이 불가능 할 경우 중계서버를 통해 서로간 통신하는 방법.

TURN을 사용한다는 것은 “서로간 P2P로 연결 할 수 없는 환경”에서 눈물을 머금고 내 서버를 중계서버로서 데이터를 거치게 한다는 뜻이 된다.

시그널링이 끝나면 서로 교신이 가능한 상태이다. TCP위에서 HTTP가 돌아가는 것 처럼, 실제 데이터 송신에는 SCTP 또는 (RTP + RTCP)가 동작한다.

• RTP: 영상 정보를 전송하는데 쓰인다. RTP위에서 H264, VP8, Opus등의 미디어 정보가 전송된다
• RTCP: RTP를 제어하는데 쓰인다. 영상에 깨져서 나오면 키프레임을 요청하기 위해 PLI, FIR을 보내거나, 영상의 재생 상태를 피드백용으로 서로 교신한다.
• SCTP: 영상을 제외한 텍스트, 데이터를 주고 받는데 쓰인다. (DataChannel에 해당한다)

WebRTC의 예시 코드를 보면 WebRTC 연결을 만들고 나서 DataChannel 또는 RTPStream을 만든다. DataChannel 또는 RTPStream을 위해 내부적으로 별개의 프로토콜이 동작한다. 후술하겠지만 브라우저 또는 서버는 패킷내 식별번호를 통해서 SCTP이면 DataChannel로, RTP(RTCP)면 영상 처리로 분기한다.

HTTP에서는 HTTPS라는 이름으로 데이터가 암호화 된다. HTTPS 기저에서 SSL, TLS라는것이 실제 암호화를 담당한다. WebRTC도 DTLS/SRTP로 통신 암호화를 진행한다.

• DTLS: Datagram TLS이다. 즉, UDP 기반의 SSL이다. Data Channel 사용시 DTLS가 사용된다.
• SRTP: Secure RTP이다. 즉, RTP를 암호화 한 통신이다. 영상 데이터는 SRTP를 통해 데이터가 전송된다.

이 개념을 활용하면 “일단 되든 말든 상대측 IP:Port에 STUN 을 쏴봐”가 된다. 내가 상대에게 보낸SDP에 나의 IP주소(STUN Server Reflective IP):Port가 있고, 상대가 나한테 보내준 SDP에 상대 IP주소:Port가 있다. 주소를 서로 알기 시작하면 서로가 상대측 주소로 연결이 뚫릴때 까지 UDP를 쏜다. 그러면 서로간의 공유기(NAT)에 “내 Port로 상대측 IP:Port패킷이 오면 지정된 휴대폰으로 보내야겠다” 라는 정보가 새겨진다.

이 방법으로 공유기(NAT)에 서로간 통신할 수 있는 구멍을 뚫는 것을 홀펀칭이라고 한다. 서로가 “상대방 서버로 접속하고 싶어요”라고 UDP를 보내면 공유기(NAT)에서 상대 주소를 받아드릴수 있게 된다.

조금 주제가 벗어나서 부록으로 적어보자면, 왠만한 NAT는 Source Port를 그대로 사용한다. 즉, 패킷의 출발지 주소가 192.168.0.3:1234 라면 왠만해선 공인 IP만 바꾼 111.222.111.222:1234 를 사용한다. 그리고 1234 포트를 192.168.0.3 에 할당해 준다.
그렇다면 이미 다른 컴퓨터가 해당 포트를 사용한다면 어떨까? 192.168.0.2:1234가 먼저 포트를 선점했다고 하자. 그러면 192.168.0.3:1234는 111.222.111.222:1235로 연결될 가능성이 크다.

중요한 포인트는, 홀펀칭은 NAT가 출발지 IP주소:포트 만 같다면 동일한 외부 포트를 할당해 줄 것이라는 것을 기저에 깔고 진행된다는 것이다. 출발지 IP주소:포트 -> 121.144.252.70:80 이든 출발지 IP주소:포트 -> 118.112.119.111:8080 상관없이, 출발지 IP주소:포트 가 같기 때문에 포트가 변환됐을지라도 두개 모두 동일한 SRC 포트를 쓸 것이라는 기대를 하고 만든 방법이다.

그렇지 않고 출발지 IP주소:포트가 같아도 상대측 주소(121.144.252.70:80, 118.112.119.111:8080)에 따라 다른 SRC 포트를 할당하는 NAT를 Symmetric NAT 이라고 하며, 한쪽이라도 Symmetric NAT 를 가지고 Port Restricted Cone 이상의 제약이 있다면 서로간 직결이 불가능하다. 그때는 TURN으로 패킷 중계를 해야할 수 밖에 없다.

왠만한 NAT는 P2P를 고려하기 때문에 Symmetric NAT 를 쓰지 않는다. Symmetric NAT를 쓰면 사용자가 P2P로 통신하는 게임·프로그램이 작동하지 않는다고 불만을 표할 가능성이 매우 높다. 그래서라도 왠만한 공유기(NAT)는 출발지 IP주소:포트가 같다면 동일한 외부 포트를 제공할 가능성이 높다. 그럼에도 만에 하나라도 Symmetric NAT 라면 TURN을 써서 통신 중계를 해줘야 한다.

인터넷에서 상대가 나를 접속하려면 공인 IP를 알아야 한다. 그러나 내 컴퓨터는 나에게 할당된 사설 IP밖에 알지 못한다. 그래서 외부 STUN 서버에 “내 IP가 뭐에요?” 라고 물어본다. 그러면 STUN 서버는 “너의 공인 IP는 111.222.111.222이고, 너의 SRC 포트는 1234이다” 라고 답해준다.

이때, STUN 서버에서 보인 IP, 포트를 (STUN) Server reflexive address 라고 한다. 한글로 직번역 하면 “서버에서 비춰진(보여진) IP주소” 이다.

공유기 아래에 … 공유기 아래에 … 공유기 아래에 … n개의 공유기가 있더라도 STUN 서버로 패킷이 나가면서 각자의 NAT에 기록이 생긴다. 그렇기 때문에, 최종적으로 나온 공인 IP 주소:포트번호로 패킷을 보내면 역방향으로 돌아가서 내 PC에 들어온다.

SDP에는 후보군 설명만 있는것이 아니다. 연결에 관한 다른 정보도 있다. 예를 들어, DataChannel로 데이터를 주고 받는다고 하자. SDP내에 DataChannel에 관한 정보가 쓰여져 있다. 영상·음성도 마찬가지이다.

즉, SDP는 실제 통신을 하기위해 필요한 정보를 교환하는 데이터 구조라고 생각하면 된다. 이것을 파싱해서 연결에 필요한 정보, 데이터 송·수신에 필요한 트랙·스트림 정보를 서로간 교환한다.

간접적으로는 효율적인 처리를 위해 내부적으로 EndPoint와 WebRTC 연결 객체를 이어주는데 쓰이기 때문이다. 리눅스 커널이 5-Tuple을 가져서 정확한 fd에 데이터를 넣어주는 것 처럼 우리도 어플리케이션 단에서 5-Tuple을 유지할 필요가 있다.

// Candidate가 여러개일 수 있다. 그러므로 N:1로 구성해야 한다.
HashMap<(srcIpAddr, srcPort, dstIpAddr, dstIpPort, Protocol), WebRTC_ClientId>

HashMap<WebRTC_ClientId, WebRTC_Client>

위와 같이 5-tuple을 관리하는 객체를 만들어야 대량의 처리를 효율적으로 받을 수 있다. 이때, STUN과 최초 SDP에서 교환한 Candidate가 근거가 된다. STUN이 heartbeat 처럼 계속 온다면 연결된 객체를 유지하고, n초 이상 오지 않는다면 객체를 정리하면 된다.

새로운 IP로 STUN이 오는 경우가 있을 수 있다. 예를 들어, LTE, 5G 같은 네트워크에서 통신사의 외부 IP가 바뀔 수 있다. 이 경우에는 SDP의 Candidate에 해당 IP가 있을 경우에만 5-Tuple Table에 등록해야 한다.

ufrag는 공개되지만, MESSAGE-INTEGRITY 는 누군가가 위조할 수 없어야 한다. 그렇기에 처음에 SDP를 교환할 때 ice-pwd 라는 항목으로 서로 자신의 HMAC 키를 상대에게 알려준다.

정리하자면 SDP에 단순히 트랙정보, 연결 후보(Candidate) 뿐 아니라 ufrag와 ice-pwd도 있다.

우선 한가지 알고 가야하는것이 있다. DTLS는 Self-Signed 인증서를 허용한다. 실제로도 모두가 Self-Signed 인증서를 쓰고있다.

Self-Signed 인증서의 문제는 “상대방이 생성한 인증서가 맞는가?”를 검증할 수 없다는데 있다. 악의적인 사용자가 MITM을 해서 자신의 인증서를 끼어넣을 수 있기에 브라우저들이 막는다. 그러나, SDP에 인증서의 Figerprint가 기제되므로서 상대방이 생성한 인증서가 맞음을 확인할 수 있다.

그래서 Self-Signed 안전함이 확보된 이상 문제가 없다. 오히려 매번 키가 바뀜으로서 더 안전하다고 까지 한다. 인증서의 유효기간 문제도 있기에, 많은 클라이언트들이 DTLS용 인증서를 요청이 온 순간순간 만들어서 쓴다.

WebRTC는 UDP를 기본으로 사용한다. TCP와 달리 UDP는 더더욱 패킷 단위이다. 데이터를 수신받을때도 패킷 크기만큼 읽히고, 보낼때도 데이터의 크기만큼의 패킷이 생성된다.

TCP에서는 한번의 read()시 버퍼에 쌓여있는 데이터가 한번에 들어오지만, UDP에서는 패킷 단위로 읽힌다. write()시에도 TCP는 데이터를 wmem에 쌓아두고 softirq가 적절한 크기의 패킷으로 짤라서 알아서 발송한다.

하지만 UDP에서는 “순서 보장이 없기 때문에” read()시 패킷 크기만큼만 읽힌다. All-or-Nothing 처럼 무조건 Packet단위로는 읽힌다는 제약덕에 UDP 소켓을 실제 쓸 수 있다. 만약 버퍼가 있다면 한번 읽었을때 순서가 뒤바뀐채 데이터 구분이 안될 것이다. write()시에도 무조건 데이터 크기만큼이 보내진다. (단, IP의 Fragment는 현재 고려하지 않는다.)

그렇기 때문에, 암호화도 패킷 단위로 발생한다. TCP였으면 1GB파일 전송시 1GB를 블록으로 암호화 하면 됐다. 그러나 WebRTC에서는 근본적으로 불가능하기 때문에 패킷 단위로 암호화를 해야한다. 1500 MTU (=1480 MSS) 기준으로 6800번 정도의 암호 연산이 발생한다.

사실 이것이 WebRTC 서버가 CPU 지원을 많이 필요로 하는 이유가 된다. 영상을 전송한다면 초당 300~500 패킷은 발송된다. 뷰어가 1천명만 있다 해도 초당 400 * 1000의 암호화가 필요한 셈이다. 그 외, RTCP 응답 복호화 등등이 발생하면 더 많은 CPU가 소모된다.

그러나 파이어폭스는 이들 중 하나의 순서만 바뀌어도 DTLS 수립이 되지 않는다. Firefox뿐 아니라 다른 간단한 WebRTC 클라이언트들도 동일한 문제가 있을 것이다. 그러므로, DTLS의 경우 Jitter 이상의 간격을 두고 Handshake 패킷을 전송하는 로직이 추가로 필요하다.

괴담이 있다. LTE, 5G 네트워크는 조금만 움직여도 IP가 계속 바뀐다는 것이다. 필자는 큰 지역(광역시)을 벗어나면 IP가 바뀌지 않을까 내심 걱정했었다. 몇일간 테스트 해 본 결과에 따르면, 큰 걱정은 할 필요 없다는 것이 필자의 판단이다.

KT에서는 (1) 부산에서 살다가 (2) 부산-서울을 KTX를 타고 와서 (3) 서울(노량진)에서 지내고 (4) 홍대쪽에 출·퇴근을 하는동안 IP가 동일했다. 옛날 같았으면 각 지역별 모바일 백본의 경계를 넘어갔을때 IP가 바뀌었을지 모르겠지만, 이제는 그렇지 않다.

LG에서는 서울 전역을 돌아다녀도 IP가 바뀌지 않음을 확인 할 수 있었다. 테스트 구간에 지하철을 포함해서 [홍대입구 -(2호선)- 당산역 -(9호선)- 노량진역 – 용산]을 업무차 몇번 왕복 했는데 동일한 IP가 유지 됐다.

다들 KTX나 고속도로에서도 모바일 게임을 잘 하지 않는가. 온라인 게임 중 stateful한 게임도 꽤 있을것인데 영향이 없다는것은 걱정할 필요가 없다는 반증이다.

다만, KTX 및 고속도로에서는 기지국 Handover 과정에서 수초간 네트워크 상태가 좋지 못했다. HLS나 버퍼 관리가 가능한 곳에서는 buffer time을 길게 가져가면 되는데 비해, WebRTC는 버퍼기간을 직접 관리하기 힘들다. 이에 대한 유저 불만은 조심하자.

Handover에서도 IP가 유지되는 대신에 IPv4/v6 모두 TCP MSS가 1378b 밖에 되지 않았다. 일반적으로 쓰이는 1460 MSS (=1500 MTU) 보다 훨씬 낮을 뿐더러 UDP이니 패킷 크기 관리를 잘 해야 한다.

다만, SKT에 한해서 큰 지역을 벗어나면 IP가 바뀌는 현상이 있긴 했다. 홍대 입구역에서 파주로 넘어가기 위해 강변북로를 올라타자 IP의 끝자리가 바뀌었다. 반대로 파주에서 강변북로를 타고 들어올 때 합정역 즈음에서 IP의 끝자리가 바뀌었다.

[홍대] 111.222.111.10 --> [강변북로] 111.222.111.40 --> [파주] 111.222.111.40
[파주] 111.222.111.40 --> [합정역 부근] 111.222.111.10

그래도 바뀌는 IP는 매번 동일하다. 매일 출퇴근을 해도 계속해서 동일한 IP로 바뀌는것으로 보아 SKT는 “지역별 백본·IP” 같은것이 있는것 같다. 아마 서울내 지역별 IP와 고양·파주쪽 IP가 분리되어 있는것 같다.

Wifi를 켜도 마찬가지이다. 인텔리젼스 Wi-Fi의 “Wi-Fi 연결시에도 LTE 켜기” 기능을 끈 상태임에도 불구하고, (1) LTE에서 WebRTC를 연결한 상태에서 (2) Wi-Fi에 접속도 (=) LTE를 통해 WebRTC 통신이 이어져나갔다.

사용자 입장에서는 Wi-Fi를 켰음에도 데이터가 소진되는 경험을 하게 된다. 화면 상단의 LTE 신호세기 아이콘도 사라져서 더 알아체기 힘들다. 심지어는 필자도 “데이터 사용량 안내 문자”가 와서 알았다.