백엔드 통신 디자인패턴

Short Polling

• 클라이언트가 주기적으로 서버에 요청을 보내 최신 데이터를 받음
• 연결은 요청마다 새로 생성
• 실시간성이 낮고, 트래픽이 많아질 수 있음

• Http Request Connection
  • Request를 계속 보내기 때문에 클라이언트가 많아진다면?
  • 연결, 끊기 자체가 부담스럽다
  • 실시간 정도의 빠른 응답 기대하기 어렵다
• Http 오버헤드 발생
• 유용: 일정하게 갱신되는 서버 데이터의 경우

💡 Http OverHead? = 이 사람이 좋은 사람인지 알아보는 시간

• 정보의 신뢰성을 판단하기 위한 보내지는 헤더 정보(전송 데이터와 관련없는 정보)로 데이터량, 처리시간이 증가함

Long Polling

• 클라이언트가 서버에 요청을 보내고, 서버는 새 데이터가 생길 때까지 연결을 유지
• 데이터가 생기면 응답 후 연결 종료, 클라이언트는 다시 요청
• 실시간성이 높으나, 연결 재설정 오버헤드 존재
  

SSE (Server-Sent Events)

• 서버가 클라이언트에 일방향으로 지속적으로 데이터를 푸시
• HTTP 기반, 브라우저 지원, 자동 재연결
• 실시간 피드, 알림 등에 적합

WebSocket

• 클라이언트-서버 간 양방향, 지속적 연결
• 실시간 채팅, 게임 등 빠른 반응이 필요한 서비스에 적합

요청-응답(REST API 등)

- 요청 후 응답을 기다리는 동기적 방식
    
- 단순하고 범용적, CRUD 작업에 적합
    

Publish-Subscribe (Pub/Sub)

- 메시지 브로커를 통해 여러 서비스가 비동기적으로 데이터 교환
    
- 대규모, 분산 시스템에서 이벤트 기반 처리에 적합

주요 차이점

Polling(short) vs Long polling

1. 응답 대기 시간
   Polling: 즉시 응답을 받는다. (데이터의 유무와 관계없이)
   Long Polling: 새 데이터가 있을 때까지 기다린다.

2. 서버 부하
   Polling: 주기적인 요청으로 서버 부하가 높다.
   Long Polling: 불필요한 요청을 줄여 서버 부하를 감소시킨다.

3. 실시간성
   Polling: 주기적 요청으로 인한 지연이 있다.
   Long Polling: 데이터 발생 즉시 응답하여 더 실시간에 가깝다

HTTP vs WebSocket

1. 통신 방식
   HTTP는 단방향 통신으로, 클라이언트가 요청을 보내면 서버가 응답한다. WebSocket은 양방향 통신이 가능해서, 클라이언트와 서버가 실시간으로 데이터를 주고받을 수 있다.

2. 연결 유지
   HTTP는 비연결성 프로토콜이라서, 각 요청-응답 후 연결이 종료된다. WebSocket은 한 번 연결을 맺으면 그 연결을 계속 유지해서 실시간 통신이 가능하다.

3. 오버헤드
   HTTP는 각 요청마다 헤더 정보를 포함해야 해서 오버헤드가 크다. WebSocket은 초기 연결 설정 이후에는 최소한의 오버헤드로 데이터를 주고받는다.

4. 실시간성
   HTTP는 실시간 업데이트를 하려면 폴링 같은 추가 기술이 필요하다. WebSocket은 기본적으로 실시간 통신을 지원한다.

5. 사용 사례
   HTTP는 웹 페이지 로딩, RESTful API 등 전통적인 웹 애플리케이션에 적합하다. WebSocket은 실시간 채팅, 온라인 게임, 주식 시세 업데이트 등 실시간 데이터 교환이 필요한 애플리케이션에 적합하다.[

6. 성능
   HTTP는 연결 설정과 해제 때문에 지연이 발생할 수 있다. WebSocket은 연결을 계속 유지하기 때문에 지연이 적고 처리량이 높다

Reference

https://velog.io/@dev_jazziron/Polling-Long-Polling-SSE-WebSocket