✅ Polling
HTTP 연결에서는 Stateless와 Connectionless 특징을 가지기 때문에 서버가 클라이언트에게 발송한 데이터가 생기더라고 서버가 일방적으로 클라이언트에게 응답을 보낼 수 없다.
요청을 받아야 응답을 보내는 구조로 클라이언트가 요청을 보낼 때까지 기다려야 한다.
이것을 해결한 방식이 Polling 방식이다. 요청을 주기적으로 계속 보내면서 서버가 전달 하고자 하는 내용이 있는지, 이벤트가 발생했는지 확인해서 가져오는 것이다.
HTTP 오버헤드가 상당히 증가한다는 단점을 지니고 있다.
- 적합한 서비스
- 실시간 메시지 전달이 중요하지 않은 서비스
- 잦은 요청에 대응할 수 있는 서버를 지닌곳
✅ Long Polling
Polling과 유사하게 동작하지만 조건과 설정이 추가된 형태이다.
- 폴링 하나의 생명주기의 시간을 늘린다.
- 이벤트가 발생할 때 까지 대기한다.
Polling은 계속 요청을 날렸다면 Long Polling은 시간을 최대 한 늘려서 이벤트가 발생할 때까지 대기하도록 설계한다.
HTTP 요청 빈도를 줄여서 개선한 모델
적합한 서비스 - 실시간 메세지 전달이 중요하지만, 잦은 데이터 전달이 없는 경우
✅ WebSocket
소켓 통신은 HTTP 통신이 아닌 TCP에서 동작한다. HTTP와 달리 Stateful 하며 Polling 처럼 주기적으로 요청받을 필요가 없다.
WebSocket HandShake 요청을 통해서 HTTP→ Socket 통신으로 전환하는 과정을 거치면서 일어난다.
양측에서 언제든지 원하는 데이터를 보낼 수 있는 구조를 가지고 있다.
적합한 서비스
- 양방향 통신이 필요하고, Socket 통신을 위한 전용 서버를 구축할 환경이 되는 곳
✅ Server Sent Event
서버에서 클라이언트로 단방향 데이터를 전달할 수 있는 HTML5 표준 기술
WebSocket과 다르게 별도의 프로토콜을 구축할 필요도 없고, Polling 처럼 요청을 주기적으로 보내서 응답을 받을 필요가 없다.
- 적합한 서비스
- 서버에서 일방적인 데이터 전달이 필요한 곳
- 스트리밍 서비스
WebRTC앞선 기술들은 Clinet-Server 구조로 동작 하지만, WebRTC는 P2P 방식으로 통신이 이루어진다. 일반적인 경우 UDP로 통신을 하기 때문에 빠른 장점이 있다.
하지만 P2P 방식인 만큼, 사용자가 많아질 수록 성능이 안 좋아진다는 단점이 있다.
- 적합한 서비스
- 정말 실시간 통신이 최우선인 서비스
- 1:1 혹은 소규모 대상 실시간 통신이 중점인 서비스
