서버가 클라이언트한테 실시간 데이터를 전송하는 방법 (feat. Polling, SSE, WebSocket)

 

00. 일반적인 클라이언트-서버 구조

보통의 클라이언트-서버 구조에서 HTTP 요청은 클라이언트가 원하는 데이터를 받기위해 서버한테 요청한다.

그러나 실시간 채팅 알림, 티켓 예매 알림 서비스과 같이 사용자가 구독한 내용이 변경되면 서버가 먼저 데이터를 전달해야 한다.

 

---

 

01. 서버가 클라이언트에게 데이터를 전송하는 방법

1. Polling

 

Polling 방식은 우리가 알던 클라이언트-서버 구조 방식과 동일하다.

클라이언트가 요청하기 전까지는 서버에는 관련된 이벤트가 발생하여 쌓인다.

그리고 클라이언트가 요청하면 발생한 이벤트 데이터를 받을 수 있다.

 

 

Polling의 특징

• 클라이언트가 먼저 요청하는 클라이언트-서버 구조
• 서버에서 이벤트가 발생해도 클라이언트가 요청을 하지 않으면 확인할  수 없음
• HTTP 프로토콜의 특징인 비연결성을 기반으로 클라이언트-서버 통신이 끝나면 연결을 바로 종료

Polling의 장단점

• 받는 데이터가 실시간성이 없다면 다른 방식보다 서버의 부담을 줄일 수 있음
• 통신 완료 시 클라이언트 연결이 종료되므로 더 많은 클라이언트가 서버와 통신할 수 있음

• 실시간에 가까운 데이터를 받기위해 많은 HTTP 요청을 한다면 서버에 부담이 증가함
• 서버에서 이벤트가 발생하지 않았다면 이전과 동일한 데이터를 전송하기에 불필요한 통신 발생
• 응답을 받고나서 직후에 이벤트가 발생하면 실시간에 가까운 데이터를 받지 못함

 

2. Long Polling

 

Long Polling 방식은 클라이언트가 서버와 HTTP 연결을 길게 유지한다.

클라이언트가 요청했을 때, 서버에 이벤트가 없으면 대기하다가 이벤트가 발생하면 그 순간에 데이터를 전달한다.

응답을 마치면 HTTP 연결이 끊기고, 클라이언트가 서버에 다시 요청을 보내야 한다.

 

Long Polling의 특징

• 클라이언트가 요청하고나서 서버에 이벤트가 발생할 때까지 대기했다가 데이터를 받음
• 통신이 끝나면 HTTP 연결이 종료

Long Polling의 장단점

• Polling 방식과 다르게 데이터가 변경되는 경우만 응답하기에 실시간에 가까운 데이터를 받을 수 있음
• 이벤트가 발생할 때만 응답하기에 불필요한 요청이 없어짐

• Polling 방식보단 서버의 부담이 덜하지만, 클라이언트의 요청 간격이 좁아지면 Polling 방식과 차이가 없어짐
• 다수의 클라이언트가 동시에 대기한다면 서버의 부담이 증가

 

3. SSE (Server-Sent Event)

 

SSE는 서버에서 클라이언트로 단방향 데이터를 지속적으로 보내는 HTTP 기술이다. (웹 브라우저와 서버간 이벤트 스트리밍 표준)

클라이언트와 서버가 HTTP로 연결되고, 서버에서 이벤트가 발생하면 클라이언트로 Push한다.

 

SSE의 특징

• 실시간 시세와 같이 서버가 알려주기만 하면 되는 데이터를 단방향 통신으로 처리
• 특수한 프로토콜 전환없이 가벼운 HTTP 프로토콜 네트워크가 잠깐 끊겨도 브라우저가 중단된 시점의 데이터부터 다시 요청

SSE의 장단점

• 자동 재연결: 네트워크가 끊겨도 브라우저가 알아서 처리
• 낮은 리소스 소비: 웹소켓처럼 복잡한 프로토콜 핸들링이 없음

• 연결 제한 (HTTP 1.1의 경우, 한 도메인 당 6개의 연결 제한)
• 서버에서 CORS 설정 필요

4. WebSocket

 

WebSocket은 양방향 통신 지원하기에 클라이언트와 서버가 지속적으로 실시간 데이터를 주고받을 수 있다.

보통의 HTTP 요청과 달리, WebSocket은 HandShake로 연결하고 Header 오버헤드 없이 효율적으로 통신한다.

1. 클라이언트와 서버가 HTTP HandShake를 통해 연결
2. 업그레이드 된 WebSocket 프로토콜로 양방향 실시간 데이터 통신
3. 한쪽에서 통신을 종료

 

WebSocket의 특징

• 실시간 채팅, 문서 동시 수정 등 동시에 데이터를 주고받아야 기능에 적합 (양방향 실시간 데이터 통신)
• HTTP로 통신한다면 누구인지, 어떤 브라우저인지, 쿠키 등 무거운 헤더를 보내지만, 웹소켓은 HandShake를 통해 가벼운 통신으로 오버헤드가 없음
• 다양한 프로토콜 지원 (메시지 형식, 채팅, 실시간 알림), 브라우저 호환성

WebSocket의 장단점

• 양방향 실시간 전송, 서버 푸시 기능 지원
• 연결 유지 (추가 HTTP 요청 X)
• 헤더 오버헤드 최소화

• 비표준 HTTP 방식이라 방화벽, 프록시에 의해 차단될 수 있음
• 네트워크 장애 등으로 끊어지면 개발자가 수동으로 재연결
• CORS 보호가 없으므로 보안 이슈
• 멀티 스레드 환경에서 메시지 순서 보장 필요

 

---

 

02. 비교 및 결론

 

---

 

99. 참조

https://yonghwankim-dev.tistory.com/619

https://velog.io/@awfjol2008/%EC%8B%A4%EC%8B%9C%EA%B0%84-%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EC%8A%A4%ED%8A%B8%EB%A6%AC%EB%B0%8D%EA%B3%BC-%ED%91%B8%EC%8B%9C-%EC%95%8C%EB%A6%BC-%EA%B5%AC%ED%98%84

https://hudi.blog/websocket-with-nodejs/