실시간 통신 기술

Polling

HTTP 연결에서는 Stateless와 Connectionless 특징을 가진다.
서버가 클라이언트에게 발송한 데이터가 생기더라도 서버가 일방적으로 클라이언트에게 응답을 보낼 수 없다.
요청을 받아야 응답을 보내는 구조로 클라이언트가 요청을 보낼 때까지 기다려야 한다.
이것을 해결한 방식이 Polling 방식이다. 

• 요청을 주기적으로 계속 보내면서 서버가 전달하고자 하는 내용이 있는지 확인해서 가져오는 것이다.
• 하지만 HTTP 오버헤드가 상당히 증가한다는 단점이 있다.

적합한 서비스: 실시간 메시지 전달이 중요하지 않고, 잦은 요청에 대응할 수 있는 서버를 지닌 곳

Long Polling

Polling과 유사하게 동작하지만 조건과 설정이 추가된 형태이다.

• Polling은 계속 요청을 날렸다면 Long Polling은 시간을 최대한 늘려 이벤트가 발생할 때까지 대기한다.
• HTTP 요청 빈도를 줄여서 개선한 모델이다

적합한 서비스: 실시간 메시지 전달이 중요하지만, 잦은 데이터 전달이 없는 경우

WebSocket

• HTTP가 아닌 TCP위에서 동작하며, Stateful 하기 때문에 주기적으로 요청받을 필요도 없다.
• WebSocket HandShake 요청을 통해서 HTTP -> Socket 통신으로 전환하는 과정을 거치면서 일어난다.
• 양측에서 언제든지 원하는 데이터를 보낼 수 있는 구조를 가지고 있다.

적합한 서비스: 양방향 통신이 필요하고, Socket 통신을 위한 전용 서버를 구축할 환경이 되는 곳

Server Sent Event (SSE)

• 서버에서 클라이언트로 단방향 데이터를 전달할 수 있는 HTML5 표준 기술이다.
• WebSocket과 다르게 별도의 프로토콜을 구축할 필요가 없고, Polling처럼 요청을 주기적으로 보내며 응답을 받을 필요도 없다.

적합한 서비스: 스트리밍 서비스

WebRTC

• 앞선 기술들은 Client-Server 구조로 동작하지만, WebRTC는 P2P 방식으로 통신이 이루어진다.
• UDP로 통신하기 때문에 빠르다는 장점이 있지만 P2P방식인 만큼, 사용자가 많아질수록 성능이 안 좋아진다는 단점이 있다.\

적합한 서비스: 실시간 통신이 최우선이며 1 : 1 혹은 소규모 실시간 통신이 중점인 서비스