Polling/Long-Polling/SSE/Web Socket

❗️ 기존 HTTP 요청 방식

• 웹은 HTTP 요청-응답 모델을 기반으로 동작
• 클라이언트의 요청이 있을 시에만 서버가 데이터를 보낼 수 있음(단방향)
• 비연결성 프로토콜(connectionless) -> 서버는 데이터를 보내고 연결을 끊음
• 무상태 프로토콜(stateless) -> 클라이언트의 상태를 저장하지 않음

---

❗️ Polling

클라이언트가 정기적으로 서버에 http 요청을 계속 보내서 데이터를 전달 받는 방식

• 서버는 보낼 데이터가 있든없든 바로 응답을 해줌
• 서버의 상태 변화에 즉각적으로 반응하지 못함
  => 요청을 보내는 주기가 정해져 있기 때문에 실시간으로 보낼 수 없음
• 계속해서 요청을 보내기 때문에 트래픽을 낭비
• http 오버헤드가 발생함
• 일정하게 갱신되는 서버 데이터의 경우에 유용하게 사용

---

❗️ Long-Polling

서버가 클라이언트 요청에 바로 응답하지 않고 접속을 유지하는 방식

응답할 데이터가 없으면 기다렸다가 이벤트가 존재하면 그 때 응답한 후 연결을 해제한다.

연결이 끊어지면 클라이언트는 즉시 다시 요청을 보낸다.

• 클라이언트로부터 요청을 받으면 연결을 끊지 않음
• 이벤트가 발생하거나 시간 초과가 된 경우에만 서버가 응답함
• 서버의 부담 커짐
  => 클라이언트가 요청을 보내고 서버가 응답할 때까지 연결을 유지하기 때문
• 이벤트 시간 간격이 좁다면 polling 방식과 별 차이가 없음

---

❗️ SSE(Sever-Sent-Events)

양방향이 아닌 서버에서 클라이언트로만 전송 가능한 단방향 통신 방식

• 연결이 유지되기 때문에 실시간성이 매우 높다.
• 연결이 끊어지면 자동으로 다시 연결을 시도한다.
• 클라이언트는 수신만 받으면 되는 경우 사용한다.
  ex) 암호 화폐 또는 주가 피드 구독, 라이브 스포츠 점수 받기, 뉴스 업데이트 

---

❗️ Web Socket

양방향 실시간 통신 방식

클라이언트는 요청 헤더에 다음과 같은 내용을 담아 서버에게 Web Socket 연결을 요청하는 http 요청을 보낸다.

GET /chat HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://localhost:9000

 

Upgrade는 프로토콜을 전환하기 위해 사용하는 헤더이다.

서버에서 http 프로토콜을 WebSocket로 전환하였다는 응답이 오면 연결이 완료된다.

지금까지의 과정을 handshake라고 한다.

이후부터 클라이언트와 서버는 http가 아닌 WebSocket 프로토콜로 소통한다.

 

• 하나의 연결을 끝까지 유지
• 적은 자원만 소모하기 때문에 Long Polling 만큼 서버에 부담이 되지 않음
• 최초 접속 시에는 http를 사용하기 때문에 기존의 80, 443 포트로 접속
  => CORS 적용이나 인증 등의 과정을 기존 HTTP와 동일하게 가져갈 수 있음
• 클라이언트의 요청에 서버가 응답을 하지 않아도 됨

---

❗️ Web Socket이랑 TCP/UDP 소켓 차이

속한 OSI 계층이 다르다.

TCP/UDP 소켓은 전송 계층에 속하고, Web 소켓은 응용 계층에 속한다.

Web Socket은 TCP 기반으로 작동하기 때문에 데이터의 순서와 신뢰성 보장된다.

---

❗️ 한계

서버의 설계에 따라 구현이 복잡해질 수 있다.

 

1. 로드 밸런싱이 적용된 서버
   웹 소켓은 한 번 통신을 시작하면 그 서버로만 통신을 해야하기 때문이다.
   => Nginx, HAProxy, AWS ELB 등 WebSocket을 처리할 수 있는 로드 밸런서를 선택하면 된다.
   
   
2. 메시지 크기 제약
   브라우저, 서버, 네트워크 환경마다 WebSocket에서의 메세지 크기에 제한을 둘 수 있다.
   => 대용량 데이터는 분할해서 전송하거나 다른 프토토콜을 사용하면 된다.
   
   
3. Web Socket의 기본 프로토콜인 WS는 통신을 암호화하지 않는다.
   => SSL/TLS를 발급받아서 이를 적용해서 WSS를 설정하면 된다.

---

❗️ 언제 무슨 기술을 사용할까?

- Polling

• 실시간 통신이 중요하지 않은 서비스

- SSE

• 서버에서 일방적인 데이터 전달이 필요한 서비스
• 알림, 실시간 댓글 등을 구현

- WebSocket

• 양방향 통신이 필요한 서비스
• 채팅, 게임과 같이 사용자 간 피드백이 빠르게 이루어져야 하는 상황

Long Polling을 사용하는 경우는 거의 없다고 한다..~

 

서버에서 느끼기에는 Polling/Long-Polling/SSE 방식 모두 똑같다.

계속 DB를 서치하던 루프를 돌리던 데이터를 지켜보고 있어야 되기 때문이다.

가장 큰 차이점은 통신의 오버헤드가 달라진다는 점이다 !