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

서버의 event를 클라이언트로 보내는 4가지 방법

---

---

polling

• 클라이언트가 평범한 http request를 서버로 계속 날려서 이벤트 내용을 전달받는 방식이다.
• 가장 쉬운 방법이지만 클라이언트가 계속적으로 request를 날리기 때문에 클라이언가 많아지면 서버의 부담이 급증하게 된다. 또한 http request connection을 맺고 끊는것 자체가 부담이 많은 방식이다. 그리고 클라이언트에서 실시간정도의 빠른 응답을 기대하기도 어렵다.
• polling은 http 오버헤드가 발생한다는 단점이 있다.
• 하지만 일정하게 갱신되는 서버 데이터의 경우 유용하게 사용할 수 있는 방식이다. (ex. 대시보드 갱신)

※ 참고

Http Overhead 란?

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

HTTP Overhead 란?

 

 

long-polling

• 서버 측에서 접속을 열어두는 시간을 길게하는 방식.
  • 클라이언트에서 서버로 http request를 날린다.
    
  • 서버에 응답에 대한 사용 가능한 데이터가 없으면 계속 기다리다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그순간 response 메시지를 전달하면서 연결이 종료된다.
    
  • 클라이언트에서는 곧바로 다시 http request를 날려서 서버의 다음 이벤트를 기다리게 되는 방식이다.
• 일반 polling 방식보다는 서버의 부담이 줄겠지만 클라이언트로 보내는 이벤트들의 시간간격이 좁다면 polling 과 별 차이가 없게 되며, 다수의 클라이언트에게 동시에 이벤트가 발생될 경우에는 곧바로 다수의 클라이언트가 서버로 접속을 시도하면서 서버의 부담이 급증하게 된다.
• hang걸린것 처럼 응답을 보류하기 때문에 hang get 이라고도 불린다.
• 특성상 구현을 위해 무한 iframe에 script tag를 추가하는 것과 같은 꼼수가 필요하다.

---

websocket

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

 

---

SSE (Server-Sent Events)

• HTML5 표준안이며 어느 정도 웹소켓의 역할을 하면서 더 가볍다.
• websocket 과 같이 양방향이 아닌 server -> client 단방향이기에 서버의 event 나 message를 client 로 push 하는 작업에 유용하게 사용될 수 있다.
• 양방향이 아니기에 요청 시 ajax로 쉽게 이용할 수 있다.
• 재접속 처리 같은 대부분의 저수준 처리가 자동으로 지원된다.

Server Sent Events 정리

 

 

---

참고

• https://tecoble.techcourse.co.kr/post/2022-10-11-server-sent-events/
• https://velog.io/@dev_jazziron/Polling-Long-Polling-SSE-WebSocket