Polling / Long Polling / SSE / WebSocket 정리

Server 에서 발생한 Event 를 클라이언트에게 보내는 4가지 방법이 있다.

Polling / Long Polling / Server Sent Event (SSE) / Web Socket 이 있다.

이 4가지 방법에 대해 알아보자.

 

1. Polling

클라이언트가 주기적으로 서버에 요청(http request)을 계속 보내는 방법이다.

일정 시간마다 서버에 요청을 보내 데이터가 갱신되었는지(이벤트가 발생하였는지) 확인하여 갱신된 값이 있다면(이벤트가 발생했다면) 데이터를 응답받는 방법이다.

 

Polling 예시

 

• 클라이언트, 서버 모두 구현이 간단하고 가장 쉬운 방법이지만 클라이언트가 계속적으로 request를 날리기 때문에 클라이언트가 많아지면 서버의 부담이 급증하게 된다.
• http request connection을 맺고 끊는 것 자체가 부담이 많은 방식이다. 또한, 클라이언트에서 실시간 정도의 빠른 응답을 기대하기 어렵다.
• polling 은 http 오버헤드가 발생한다는 단점이 있다.
• 서버가 요청에 대한 부담이 크지 않으며, 실시간성이 중요하지 않다면 사용할 수 있는 방법이다. 또한 일정하게 갱신되는 서버 데이터의 경우 유용하게 사용할 수 있다. 예를 들면 대시보드 갱신이 있다.

Http Overhead란?
정보의 신뢰성 판단을 위해 보내지는 헤더 같은 정보 때문에 오히려 데이터량이나 처리시간이 증가하는것을 의미한다.

 

 

 

2. Long Polling

Long Polling은 요청을 보낸 후 서버에서 변경이 일어날 때까지 기다리는 방법이다. 즉, 서버 측에서 접속을 열어두는 시간을 길게하는 방식이다.

• 클라이언트에서 서버로 http request를 보낸다.
• 서버에 응답에 대한 사용 가능한 데이터가 없으면(이벤트가 없으면) 계속 기다리다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 response 메시지를 전달하면서 연결이 종료된다.
• 클라이언트에서는 곧바로 다시 http request 를 날려서 서버의 다음 이벤트를 기다리게 된다.

 

Long Polling 예시1

Long Polling 예시2

 

• 일반 Polling 방식보다 서버의 부담이 줄겠지만 클라이언트로 보내는 이벤트들의 시간간격이 좁다면 (상태가 빈번하게 바뀐다면) 연결 요청이 늘어나고 polling 과 별 차이가 없게 된다.
• 다수의 클라이언트에게 동시에 이벤트가 발생하게 될 경우에는 곧바로 다수의 클라이언트가 서버로 접속을 시도하면서 서버의 부담이 급증한다.
• hang 걸린 것 처럼 응답을 보류하기 때문에 hang get 이라고도 불린다.

행 (hang)
시스템, 네트워크, 애플리케이션이 동작하지 않고 서비스가 응답하지 않는 상태, 즉 시스템 입출력에 대한 반응이 없는 상태로 시스템 운영이 불가능한 상태를 뜻한다.

 

• 실시간 메시지 전달이 중요하지만 서버의 상태가 빈번하게 변경되지 않는 경우에 적합한 방식이다.

 

 

 

3. Web Socket

WebSocket 방식은 클라이언트와 서버가 HTTP 기반으로 HandShaking 한 후 ws프로토콜을 통해 상호 간 응답을 하는 방법이다.

 

WebSocket 예시

 

• 양방향 채널을 이용하여 채팅방처럼 양방향 통신이 가능하다.
• 기존의 http 요청 응답 방식은 요청한 그 클라이언트에게만 응답이 가능했지만, WebSocket의 경우 ws프로토콜을 통해 웹 소켓 포트에 접속해 있는 모든 클라이언트에게 이벤트 방식으로 응답할 수 있다.

 

 

 

4. Server Sent Event (SSE)

Server Sent Event 방식은 HTML5 표준안이며, 클라이언트와 서버가 한 번 연결을 맺고 난 후 일정시간동안 서버에서 변경이 발생할 때마다 데이터를 전송받는 방식이다.

즉, 서버의 데이터를 실시간으로, 지속적으로 Streaming 하는 기술이다.

 

Server Sent Event 예시1

 

Server Sent Event 예시2

 

• WebSocket과 같이 양방향이 아닌 Server→ Client 단방향이기 때문에 서버의 event나 message를 client로 push 하는 작업에 유용하게 사용될 수 있다.
• Long Polling 방식에 비해 Server Sent Event는 다시 요청을 안해도 된다는 장점이 있다.
• 브라우저는 서버가 생성한 Stream을 계속 받는다. (Server 에서 보내는 Stream으로 Read Only)
• 연결이 끊어지면 EventSource가 오류 이벤트를 발생시키고 자동으로 연결을 시도 (error recovery)
• Server Sent Event 사용 시점
  • 효율적인 단방향 통신이 필요한 경우
  • 실시간 데이터 스트리밍에 HTTP 를 사용하려는 경우 (RestFul의 GET method 와 유사)
  • 예시 (클라이언트는 수신만 받음)
    • 암호 화폐 또는 주가 피드 구독
    • Twitter 피드 구독
    • 라이브 스포츠 점수 받기
    • 뉴스 업데이트 또는 알림

 

 

 

5. WebSocket vs Server Sent Event

이 둘의 대표적인 차이점은 WebSocket은 양방향으로 데이터를 주고 받을 수 있지만, SSE(Server-Sent-Event)는 클라이언트만 데이터 수신 가능이라는 점이다.

 

	WebSocket	Server-Sent-Event (SSE)
브라우저 지원	대부분 브라우저에서 지원	대부분 모던 브라우저 지원
통신 방향	양방향	단방향(서버 -> 클라이언트)
리얼타임	O	O
데이터 형태	Binary, UTF-8	UTF-8
자동 재접속	X	O (3초마다 재시도)
최대 동시 접속 수	브라우저 연결 한도는 없지만 서버 셋업에 따라 다름	HTTP를 통해서 할 때는 브라우저당 6개 까지 가능 / HTTP2로는 100개가 기본
프로토콜	websocket	HTTP
배터리 소모량	큼	작음
Firewall 친화적	X	O

 

웹소켓은 주로 리얼타임이 필요한 곳에서 많이 사용된다.

• 카카오톡 쳇
• 주식 트레이딩 데이터
• 크립토 실시간 차트

SSE는 알람을 줄 때 많이 사용된다.

• Twitter에서 피드를 받을 때
• 페이스북에서 친구 추가 요청을 받았을 때

클라이언트는 데이터를 받기만 하면 되고 완전히 실시간일 필요는 없기 때문이다.

 

SSE는 전통적인 HTTP를 통해 전송되어 즉, 작동하려면 특별한 프로토콜이나 서버 구현이 필요하지 않다.
반면 WebSocket은 프로토콜을 처리하기 위해 전이중 연결과 같은 새로운 웹 소켓 서버가 필요하다.