2023-02-02

현재 프로젝트에서 SSE 를 적용하기 위해서 조원분께서 제법 오랫동안 붙잡고 계셨는데 내가 맡은 일이 마무리됨에 따라 몇일전 부터 같이 붙어서 코드를 보게 되었다.

다만, 나는 SSE 담당이 아니었고 도중부터 참여해서 보게 되었기 때문에 우선은 SSE 를 적용하게된 경위부터 개념까지 그것에 대한것을 알아야 하기에 이 글에는 그것에 대한 정리부터 시작...

 

 

 

SSE 를 선택한 경위

SSE 를 적용하게 되는 부분은 기존에 우리 프로젝트에서는 대기실에서 방 리스트를 불러오는데 방 리스트를 가져오는 API 를 클릭해서 호출하는 수동적인 방법이었다.
그래서 우리는 이 부분을 어떻게 해결할까에 대해서 고민을 하다가 "폴링, 롱폴링, SSE" 이 셋 중에서 어떤 기술을 고를지를 고민이 되었다.
다만, 뭐가 더 효율적이며 우리는 웹RTC 와 SockJs 를 이용해서 계속해서 클라이언트와 서버가 정보를 주고 받는 상태이기 때문에 더이상의 부담을 늘리지 않기 위해서 원하는 때에 클라이언트로 방정보만을 보내줄 수 있는 SSE 방식으로 방 리스트를 자동으로 업데이트 하기로 결정했다.

 

 

 

 

 

폴링(Polling)

클라이언트가 http request 를 서버로 계속 보내서 이벤트 내용을 전달하는 방식이다.
클라이언트가 계속적으로 request 를 보내기 때문에 클라이언트가 많아지면 서버의 부담이 급증하는 문제가 있다.
실시간 정도의 빠른 응답을 보내기 위해서는 주기를 짧게 설정해야 하는 문제가 있다.
Http OverHead 가 발생산다.
- 정보의 신뢰성을 판단하기 위해서 보내지는 헤더 정보(전송 데이터와 관련없는 정보)로 데이터량, 처리시간이 증가

 

롱 폴링(Long Polling)

서버에서 접속 시간을 길게하는 방식
  - 클라이언트에서 서버로 http request 전송
  - 서버 응답 데이터가 없으면 기다림, 이벤트가 존재하면 그 순간 response 메시지를 전달 후 연결 해제
  - 클라이언트에서 다시 http request 를 전송하여 서버의 다음 이벤트 대기
Polling 방식보다 서버 부담이 줄지만, 이벤트 시간 간격이 좁다면 차이가 없다.
다수의 클라이언트에게 이벤트가 동시에 발생하면 서버 부담이 급증한다.

 

SSE(Server-Sent-Events)

서버의 데이터를 실시간, 지속적으로 Streaming 하는 기술이며 어느정도 웹소켓의 역할을 하면서 더 경량화된 방식이다.
양방향이 아닌 server -> client 단방향
재접속의 저수준 처리 자동지원

 

웹소켓(Websocket)

양방향 채널을 이용한 양방향 통신 기술이다.
ws 프로토콜을 통해 웹소켓 포트에 연결되어 있는 모든 클라이언트에게 이벤트 방식으로 응답한다.
최초 접속이 http request 를 통한 HandShaking 과정을 통해 이루어진다.
HandShaking
  - 데이터를 전송할 때, 두 장치 간에 동기를 맞추기 위하여 일련의 신호를 주고받는 것

 

 

Polling / Long Polling / SSE / WebSocket