실시간 데이터 전송

HTTP 프로토콜은 비연결성(stateless) 구조라서 서버가 클라이언트와 지속적으로 연결될 수 없음. 그래서 서버가 데이터를 실시간으로 클라이언트에게 푸시(Push)하는 것이 어려움. 이를 해결하는 방법으로 Polling, Long Polling, WebSocket, SSE가 있음!

 

📌 1. Polling (폴링) 방식

• 클라이언트가 일정 주기로 서버에 요청을 보내 데이터를 갱신하는 방식.
• 서버는 새로운 데이터가 있으면 응답하고, 없으면 빈 응답을 보냄.

 

✔️ 장점 

• 구현이 단순함 (HTTP 요청/응답 패턴 그대로 활용 가능) 
• 요청 주기를 길게 설정하면 서버 부하를 줄일 수 있음

 

❌ 단점

• 변경 사항이 없을 때도 요청을 계속 보내야 하므로 리소스 낭비 발생
• 실시간성이 떨어짐 (요청 주기에 따라 데이터 갱신이 지연될 수 있음)

 

➡️ Polling은 실시간성이 덜 중요하고, 특정 주기에 데이터가 갱신될 때 적합!

 

📌 2. Long Polling (롱 폴링) 방식

• 클라이언트가 요청을 보내면, 서버는 새로운 데이터가 있을 때까지 응답을 지연.
• 데이터가 변경되면 서버가 즉시 응답을 보내고, 이후 클라이언트는 다시 요청을 보냄 (반복).

 

✔️ 장점 

• Polling보다 불필요한 요청을 줄일 수 있음 
• 변경 사항이 있을 때만 응답을 받으므로 더 빠른 실시간 대응 가능

 

❌ 단점

• 다수의 클라이언트가 동시에 연결되면 서버 부담 증가
• 유지 시간이 짧으면 일반 Polling과 큰 차이 없음

 

➡️ Long Polling은 데이터 변경이 자주 발생하지 않지만, 실시간성이 중요한 경우 적합!

 

📌 3. WebSocket (웹소켓) 방식

• 클라이언트와 서버가 하나의 연결을 유지하면서 양방향으로 데이터를 주고받을 수 있음.
• 초기 연결(Handshake) 후에는 HTTP 요청 없이 데이터를 주고받을 수 있어 효율적.

 

✔️ 장점 

• 양방향 통신 가능 (서버와 클라이언트가 자유롭게 메시지를 주고받음) 
• HTTP보다 데이터 전송 오버헤드가 적음 (헤더 부담 ↓) 
• 연결된 모든 클라이언트에게 동시에 데이터 전송 가능 (브로드캐스트 기능)

 

❌ 단점

• 구현이 상대적으로 복잡함
• 서버에서 클라이언트 연결 상태를 관리해야 함

 

➡️ WebSocket은 실시간 채팅, 게임, 주식 거래 등 빠른 응답이 필요한 서비스에 적합!

 

📌 4. Server-Sent Events (SSE) 방식

• 서버가 클라이언트에게 단방향(서버 → 클라이언트)으로 지속적으로 데이터 전송.
• HTTP 기반이므로 구현이 간단함.

 

✔️ 장점 

• 구현이 간단 (기존 HTTP 사용, 별도 프로토콜 불필요) 
• 서버가 자동 재연결 지원 (클라이언트가 끊어져도 다시 연결 시도) 
• HTTP 기반이라 방화벽이나 프록시 문제 최소화

 

❌ 단점

• 단방향 통신만 가능 (클라이언트 → 서버 데이터 전송 불가) 
• 연결 유지 비용이 발생 (다수의 클라이언트가 연결되면 서버 리소스 부담 증가)
• 클라이언트가 연결을 닫아도 서버가 이를 감지하기 어려움

 

➡️ SSE는 실시간 알림, 주문 처리 상태 업데이트, 라이브 대시보드 등에 적합!

 

🚀 결론: 언제 어떤 방식을 사용할까?

방식	특징	장점	단점	적합한 상황
Polling	주기적으로 서버에 요청	구현이 단순	리소스 낭비	실시간성이 덜 중요한 데이터 갱신
Long Polling	요청을 보내고 데이터가 생길 때까지 기다림	불필요한 요청 감소	동시 접속 증가 시 서버 부담	이벤트 발생이 빈번하지 않은 실시간 업데이트
WebSocket	지속적인 연결로 양방향 통신	빠른 응답 속도, 오버헤드 적음	구현이 복잡	채팅, 주식 거래, 게임
SSE	서버에서 클라이언트로 실시간 데이터 전송	구현이 간단, 자동 재연결	단방향 통신만 가능	실시간 알림, 대시보드, 주문 상태 업데이트

🔗 이미지 출처 및 참고

https://velog.io/@alswn9938/SSE%EB%9E%80