[Network] 서버의 이벤트를 클라이언트로 보내는 방법

서론

홈페이지를 이용하면서 언젠가 한번쯤은 아무 액션도 취하지 않으면 일정 시간 이후에 “세션이 만료되었습니다.”라는 알림창이 발생하는 것을 경험해봤을 것입니다.
평소에는 대수롭지 않게 여겼지만, 직접 개발하는 입장이 되어보니 각 방법들에 대해 장단점을 안다뤄볼 수가 없게 되었습니다.
따라서 이번 포스트에서는 시스템 동작 방식에 대해서 소개하는 시간을 가져보겠습니다.

Polling 방식

• 클라이언트가 일정 시간마다 서버에게 요청을 보내는 방식입니다.
• 가장 구현이 쉬운만큼, 요청 텀이 짧아질수록 부하가 심해지고 이에 따른 비용이 증가합니다.
• http 연결을 맺고 끊는 것 자체가 부담이 많은 방식이며, 클라이언트에서 실시간만큼의 빠른 응답을 기대하기 어렵습니다.
• http 오버헤드가 발생합니다.
• 일정하게 갱신되는 서버 데이터를 다룰경우 유용한 방식이 될 수 있습니다.

  (클라이언트) 뭐해?
  (클라이언트) 뭐해?
  (클라이언트) 뭐해?
  (서버) 공부해!
  (연결종료)

Loing Polling 방식

• 기본적인 개념은 폴링 방식과 동일하나, 클라이언트가 서버의 이벤트를 기다린다는 점에서 차이가 납니다.
• 폴링 방식보다는 서버의 부하가 줄어들지만, 이는 클라이언트로 보내는 이벤트들의 텀이 짧아지면 폴링 방식과 다르지 않게 됩니다.
• 다수의 클라이언트에게 동시에 이벤트가 발생될 경우, 즉시 다수의 클라이언트가 서버로 접속을 시도하면서 서버의 부담이 급증하게 됩니다.
• 응답을 보류하기 때문에 “hang get”이라고도 불립니다.

  (클라이언트) 뭐해?
  …
  (서버) 아무것도 안해!
  (클라이언트) 뭐해?
  …
  (서버) 공부해!

웹소켓

• 웹소켓을 이용하면 양방향 채널을 이용해 실시간 양방향 통신이 가능합니다.
• 기존 http 요청 응답 방식은 요청한 해당 클라이언트에만 응답이 가능했는데, ws 프로토콜을 통해 웹소켓 포트에 접속해 있는 모든 클라이언트에게 이벤트 방식으로 응답한다.
• 최초 접속은 일반 http 요청을 통해 이루어지기 때문에, 기존의 80, 443 포트로 접속하므로 추가로 방화벽 개방을 안해도 양방향 통신이 가능하고, http 규격인 CORS 적용이나 인증 등의 과정을 동일하게 가져갈 수 있는 것이 장점이다.
• 단, websocket 프로토콜을 처리하기 위해 전이중 연결과 새로운 웹소켓 서버가 필요하다.

SSE (Server-Sent Events)

• HTML5 표준안이며 어느정도 웹소켓의 역할을 하면서 더 가볍다.
• websocket과 같이 양방향이 아닌 sever -> client 단방향이기에 서버의 event나 message를 client로 push하는 작업에 유용하게 사용될 수 있다.
• 양방향이 아니기에 요청 시 ajax로 쉽게 이용할 수 있다.
• 재접속 처리같은 대부분의 저수준 처리가 자동으로 지원된다.
• IE는 기본적으로 지원하지 않지만, polyfill을 이용할 경우 IE를 포함한 크로스 브라우징이 가능하다.

출처

• Polling / Long Polling / Server Sent Event / WebSocket 정리