모바일 개발의 실시간 통신: 정의, 프로토콜 및 작동 방식

실시간 통신: WebSocket, SSE 및 Long Polling 프로토콜

실시간 통신은 클라이언트와 서버 간에 최소 지연 시간으로 데이터 교환을 가능하게 하는 기술입니다. 주요 프로토콜: WebSocket, SSE(Server-Sent Events), Long Polling 및 Short Polling. 각각 고유한 영역이 있습니다: WebSocket은 양방향 통신, SSE는 알림, Long Polling은 오래된 브라우저를 위한 폴백입니다. 모바일 개발에서 실시간은 특히 중요합니다: 사용자는 메시지와 알림의 즉각적인 전달을 기대합니다. 모바일 개발에서의 통신은 바로 이러한 프로토콜을 기반으로 구축됩니다.

WebSocket vs SSE

WebSocket은 전이중 프로토콜입니다(클라이언트 ↔ 서버). 핸드셰이크(HTTP Upgrade) 후 연결이 열린 상태로 유지됩니다. 헤더는 최소화됩니다(2바이트 대 HTTP 헤더). 채팅(WhatsApp, Telegram), 게임, 실시간 트레이딩에 사용됩니다. SSE는 단방향 프로토콜입니다(서버 → 클라이언트). 클라이언트는 이벤트를 구독하고 단일 HTTP 연결을 통해 수신합니다. SSE는 더 간단하고 확장이 쉬우며(일반 HTTP), Twitter 피드, 환율, 푸시 알림에 이상적입니다.

Long Polling은 클라이언트가 HTTP 요청을 하고 서버가 데이터를 보내거나 타임아웃(30~60초)이 될 때까지 열어두는 기술입니다. 데이터 수신 후 클라이언트는 즉시 새 요청을 엽니다. Long Polling은 WebSocket의 폴백입니다. Short Polling — 클라이언트가 N초마다 서버를 폴링합니다. 가장 간단하지만 비효율적입니다(대부분의 요청이 빈 응답을 반환).

시그널링 서버

P2P 연결을 설정하기 전에 장치에는 시그널링 서버가 필요합니다 — 피어 간에 SDP 제안 및 ICE 후보를 교환하기 위한 중개 서버입니다. 시그널링은 WebSocket, SSE 또는 다른 프로토콜을 통해 구현될 수 있습니다. 연결이 설정된 후 시그널링은 더 이상 미디어 트래픽 전송에 참여하지 않습니다.

WebRTC: 오디오 및 비디오 통화를 통한 실시간 통신

WebRTC(Web Real-Time Communication)는 P2P 오디오/비디오/데이터를 위한 개방형 기술입니다. 브라우저 및 네이티브 애플리케이션(iOS, Android)에서 작동합니다. WebRTC는 다음을 포함합니다: getUserMedia(카메라/마이크 액세스), RTCPeerConnection(P2P 연결), RTCDataChannel(데이터 전송). WebRTC는 모바일 애플리케이션에서 실시간 통신을 가능하게 합니다 — 모바일 앱의 통신은 추가 플러그인 없이 작동합니다.

WebRTC 흐름

피어 A가 RTCPeerConnection 및 Offer SDP를 생성합니다. 2단계: Offer가 시그널링 서버를 통해 피어 B로 전송됩니다. 3단계: 피어 B가 Offer를 수신하고 Answer SDP를 생성하여 다시 보냅니다. 4단계: 두 피어 모두 ICE 후보(연결용 주소)를 수집하고 시그널링을 통해 교환합니다. 5단계: ICE 프레임워크가 최적의 경로(P2P 또는 TURN 경유)를 선택합니다. 연결 후 — 미디어 트래픽이 직접 흐릅니다.

SDP(Session Description Protocol)는 연결 매개변수(코덱, IP 주소, 포트)를 설명하는 텍스트 프로토콜입니다. ICE Candidate는 STUN/TURN의 제안입니다: "이 주소에서 나를 찾을 수 있습니다". 후보가 많을수록 P2P 성공 확률이 높아집니다.

Socket.IO는 스타트업을 위한 선두주자입니다: 서버를 제어하고 제한이 없습니다. Pusher 및 Ably는 인프라를 관리하고 싶지 않은 제품을 위한 것입니다. PubNub은 IoT 및 글로벌 사용자를 위한 것입니다. IT Sectr은 자체 백엔드가 있는 프로젝트에는 Socket.IO, 빠른 프로토타입에는 Pusher, 신뢰성 요구사항이 있는 엔터프라이즈에는 Ably를 권장합니다.

플랫폼: Socket.IO, Pusher, Ably, PubNub

실시간 플랫폼은 WebSocket 및 SSE를 위한 준비된 서버 인프라를 제공합니다. 자체 실시간 서버를 작성하고 WebSocket 연결을 분산 및 확장해야 하는 필요성을 없애줍니다. 플랫폼 선택은 예산, 신뢰성 요구사항 및 서버 관리 의지에 따라 달라집니다. 모바일 개발의 실시간을 위해 플랫폼은 준비된 클라이언트 SDK 및 인프라를 제공합니다.

Socket.IO

Socket.IO는 Node.js 및 클라이언트(iOS, Android, 웹)를 위한 라이브러리입니다. WebSocket 기반이지만 폴백으로 HTTP 폴링을 사용합니다. 룸, 네임스페이스, ACK 확인을 지원합니다. 개발용 — socket.io-client-java(Android) 및 socket.io-client-swift(iOS)가 있습니다. Socket.IO의 모바일 앱 통신은 자동 재연결 덕분에 안정적으로 처리됩니다.

Pusher 및 Ably

Pusher는 실시간 SaaS 플랫폼입니다. 간단한 통합: 채널을 만들고 이벤트를 구독하세요. Pusher Channels(알림), Pusher Beams(푸시 알림). Ably는 7개 데이터 센터에 글로벌 복제를 갖춘 엔터프라이즈급입니다. Exactly-once 전달을 보장합니다. IoT를 위한 SSE, WebSocket, MQTT를 지원합니다. 두 플랫폼 모두 서버 코드 작성 없이 모바일 개발의 통신 작업을 해결합니다.

실시간 인프라: WebRTC의 STUN, TURN, 시그널링

STUN(Session Traversal Utilities for NAT)은 NAT 뒤에 있는 장치의 외부 IP 및 포트를 발견하도록 도와주는 서버입니다. 장치가 STUN 요청을 보내면 서버가 응답합니다: "203.0.113.5:45678로 보입니다". STUN은 무료로 사용됩니다(Google STUN: stun.l.google.com:19302). 실시간 인프라의 맥락에서 STUN은 P2P 채널 설정의 첫 번째 단계입니다.

STUN vs TURN

TURN(Traversal Using Relays around NAT)은 P2P 연결이 불가능한 경우(예: 두 장치 모두 대칭 NAT 뒤에 있는 경우) 미디어 트래픽을 중계하는 릴레이 서버입니다. TURN은 서버 대역폭을 소비하므로 비용이 많이 듭니다. WebRTC에서 ICE 프레임워크는 먼저 P2P를 시도한 다음 최후의 수단으로 TURN을 사용합니다. 기업 네트워크를 통해 연결할 때 모바일 앱의 통신을 위한 실시간 개발에는 TURN이 필요합니다.

ICE(Interactive Connectivity Establishment)는 가능한 모든 연결 경로(로컬 IP, STUN을 통한 외부 IP, TURN 릴레이)를 수집하고 최상의 경로를 선택하는 프레임워크입니다. ICE Candidate는 각각의 가능한 경로입니다. 후보가 많을수록 성공적인 P2P 확률이 높아집니다.

피어투피어

P2P는 미디어 트래픽을 위한 중개 서버 없이 두 장치 간의 직접 연결입니다. P2P는 지연 시간(100ms 미만)과 서버 비용을 줄입니다. 단점: NAT 보호 취약, STUN/TURN 필요. WebRTC는 기본적으로 P2P를 사용합니다.

P2P 및 ICE

피어투피어(P2P)는 장치 간에 데이터가 직접 전송되는 아키텍처입니다. 실시간 통신의 맥락에서 P2P는 WebRTC에서 지연 시간을 최소화하는 데 사용됩니다. ICE(Interactive Connectivity Establishment)는 P2P 연결을 위한 최상의 경로를 찾는 메커니즘입니다. 개발 측면에서 P2P는 모바일 앱에서 실시간으로 통신을 구성하는 최적의 방법입니다.

ICE 작동 방식

ICE는 세 가지 유형의 ICE Candidate를 수집합니다: 1) host(로컬 IP), 2) srflx(STUN 경유), 3) relay(TURN 경유). 모든 후보가 정렬되고 ICE는 우선순위 순서로 각각에 연결을 시도합니다. 첫 번째 성공적인 연결이 사용됩니다. P2P가 불가능한 경우 TURN이 사용됩니다(그러나 비용이 많이 듭니다).