Push 알림 기능 개발기 (1) ‐ 실시간 웹을 구현하는 방법들 - YJGwon/connectruck GitHub Wiki

💡 전통적인 Http 통신에서는 client의 요청 없이는 server가 먼저 client에게 데이터를 전달할 수 없었다. 이를 극복하고 user action 없이 client와 server의 상태를 동기화는 몇 가지 방법들이 있다.

Motivation

  • 푸드트럭에 신규 주문이 발생하면 사장님이 별도로 새로고침을 하지 않아도 알 수 있어야 한다. user action 없이 주문 알림을 띄우고, 주문 목록을 갱신해야 한다.
  • push 알림을 third party solution에 의존하지 않고 구현해보고 싶다.

Polling

컴퓨터 과학에서 polling: 하나의 장치가 다른 장치의 상태를 주기적으로 검사하는 방식

Http 통신에서 polling: client가 server의 상태를 주기적으로 검사하는 것

  • Short Polling: client가 일정 주기로 요청을 보내는 방법
  • Long Polling: client의 요청에 대해 server 측의 상태 변경이 일어날 때 까지 대기한 후 응답하는 방법
    • client는 응답을 받은 즉시 다시 요청 전송 → 요청 주기가 server측의 상태 변화를 따라가게 됨

장점

  • short polling의 경우 구현이 간단
  • 브라우저 버전, 종류 상관없이 잘 동작함

단점

  • short polling의 경우 실시간 동기화 X (client의 요청 주기 만큼 동기화가 지연)
  • long polling의 경우 서버 상태가 자주 바뀐다면 잦은 요청으로 인한 서버 부담

Server Sent Events(SSE)

server → client push를 위한 HTML5 표준

한 번의 connection 연결 → 추가 요청 없이도 server가 원할 때 event를 전송(단방향 event stream)

vs Long Polling

장점

  • Browser에서 표준 Web API 지원(EventSource) → reconnection도 browser에서 자동으로 처리
  • 한 번 요청하면 일정 시간 동안 여러 event 수신 → 요청이 덜 빈번

단점

  • 응답 형식 제한적 (MIME Type text/event-stream - UTF-8 text data만 사용)
  • IE 지원 X (그러나 polyfill 있어 IE까지 커버 가능하므로 사실상 단점 아님)
  • browser당 최대 동시 접속 제한(HTTP 1.1 기준 6개)

Web Socket

하나의 TCP connection으로 client ↔ server 전이중 통신을 제공하는 프로토콜

vs SSE

장점

  • IE 포함 대부분 browser에서 지원(그러나 위에서 언급했듯 SSE도 polyfill로 IE에서 사용 가능)
  • SSE는 단방향인데 비해 WebSocket은 양방향

단점

  • 자동 재접속 지원 X
  • SSE는 HTTP 프로토콜로 동작하는 반면 WebSocket은 새로운 프로토콜 → learning curve, 구현 난이도 높음

결론 - SSE

주문 알림은 양방향 통신이 필요하지 않다. 이런 경우에는 SSE에 비해 WebSocket이 갖는 장점을 찾기 힘들기 때문에 Server Sent Events로 구현하기로 결정했다.

reference