실시간 데이터 전송 방식 4가지(Polling, Long Polling, SSE, WebSocket)

2025. 3. 31. 13:05ㆍNetwork

개요

일반적으로 클라이언트가 서버로부터 데이터를 전달받기 위해서는 HTTP 프로토콜을 이용하여 전달받습니다. 클라이언트-서버 구조에서 일반적으로 HTTP 요청은 클라이언트에서 부터 시작하게 됩니다. 그러나 몇몇 상황에서는 클라이언트가 아닌 서버에서 먼저 데이터를 전달해야 하는 경우가 있습니다. 대표적인 예시로 알림이나 실시간 채팅과 같은 사례가 있습니다. 이번 글에서는 클라이언트에게 데이터를 전송하는 4가지 방법을 알아봅니다.

Polling

Polling은 무엇인가?

Polling 방식은 클라이언트가 먼저 HTTP Request를 서버에게 전송하여 응답을 받는 방식입니다. 이 방식은 우리가 아는 일반적인 클라이언트-서버 구조에서 HTTP 프로토콜을 이용하여 데이터를 주고받는 방식입니다.
위 그림을 보면 클라이언트가 먼저 서버에게 HTTP Request를 전송하고 서버는 해당 요청에 대해서 HTTP Response를 전달하는 것을 볼수 있습니다. 그리고나서 클라이언트가 추가적인 HTTP Request를 하여 응답을 받기 전까지는 서버쪽에서는 이벤트가 발생하여 데이터가 쌓이게 됩니다. 클라이언트는 HTTP Request를 하기전까지는 서버쪽에서 발생한 이벤트 데이터를 받을 수 없습니다.

Polling 특징

클라이언트-서버 구조에서 HTTP 통신시 일반적으로 클라이언트에서 HTTP 요청이 시작됩니다.
서버에서 이벤트가 발생하여 데이터 변경이 일어나도 클라이언트가 추가적인 HTTP 요청을 하기 전까지 클라이언트는 확인할 수 없습니다.
HTTP 프로토콜의 특징인 비연결성(Connectionless)에 근거하여 클라이언트와 서버간에 HTTP 통신을 완료하면 바로 연결을 종료합니다. Polling 방식또한 통신을 완료하여 연결을 바로 종료합니다.

Polling 장점

전달받는 데이터가 실시간성을 요구하지 않는 경우 다른 방식보다 서버의 부담을 낮출 수 있습니다.
HTTP 프로토콜 비연결성 특징에 의해서 통신 완료시 연결을 바로 종료하기 때문에 더 많은 클라이언트가 서버와 통신이 가능합니다.

Polling 단점

실시간에 가까운 데이터를 전달받기 위해서 클라이언트가 계속 HTTP 요청을 서버에게 전송하면 서버의 부담이 증가하게 됩니다.
서버의 데이터가 변경되지 않았음에도 클라이언트가 HTTP 요청을 하게 되면 동일한 데이터를 전송하기 때문에 불필요한 통신이 발생할 수 있습니다.
HTTP 연결은 통신이 완료되면 바로 종료되기 때문에 실시간에 가까운 데이터를 받지 못할 수 있습니다.
HTTP 오버헤드가 발생할 수 있습니다.

[!NOTE] HTTP Overhead
정보의 신뢰성 판단을 위해서 보내지는 헤더 같은 정보 때문에 오히려 데이터량이나 처리시간이 증가하는 특징을 말합니다.

Long Polling

Long Polling은 무엇인가?

Long Polling 방식은 클라이언트 서버와의 HTTP 연결을 길게 유지하는 방식입니다. 클라이언트가 서버에게 HTTP 요청을 전송하면 서버는 HTTP 응답에 대한 사용 가능한 데이터가 없으면 계속 대기하다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간에 HTTP 응답을 전달하게 됩니다. 응답을 마쳐서 HTTP 통신을 완료하게 되면 연결을 끊게 됩니다. 그리고 다시 클라이언트에서 시작하여 HTTP 요청을 전달하는 과정을 반복합니다.

Long Polling 특징

서버에서 HTTP 요청을 받았다고 바로 응답을 전송하는 것이 아닌 사용 가능한 데이터가 없으면 계속 대기하다가 이벤트가 발생하면 해당 데이터를 HTTP 응답에 실어서 전달합니다.
Polling 방식과 마찬가지로 한번의 HTTP 요청 및 응답 통신을 완료하게 되면 연결을 끊습니다.

Long Polling 장점

Polling 방식과는 다르게 데이터가 변경되는 경우에만 HTTP 응답을 하기 때문에 클라이언트가 실시간에 가깝게 데이터를 받을 수 있습니다.
HTTP 요청이 응답될때까지 요청을 보내지 않기 때문에 불필요한 요청을 줄일 수 있습니다.

Long Polling 단점

일반적인 Polling 방식보다는 서버의 부담이 줄겠지만, 클라이언트로 보내는 HTTP 요청 간격이 좁아지게 된다면 Polling 방식과 차이가 없게 됩니다.
다수의 클라이언트가 동시에 요청을 하여 연결을 하게 되면 서버의 부담이 증가하게 됩니다.

Server-Sent Events

Server-Sent Events란 무엇인가?

Server-Sent Events(SSE) 는 서버에서 클라이언트로 단방향 데이터를 지속적으로 전송할 수 있도록 해주는 HTTP 기반 기술입니다. 웹 브라우저와 서버 간의 이벤트 스트리밍을 위한 표준입니다.
위 그림을 보면 우선 클라이언트와 서버간에 HTTP 연결을 맺습니다. 그리고나서 서버쪽에서 이벤트가 발생하게 되면 서버쪽에서 클라이언트로 지속적으로 푸시(Push)하여 데이터를 전달합니다. 그런 다음에 시간이 일정 시간 지난 후 연결을 끊습니다.

Server-Sent Events 특징

단방향 통신 : 서버에서 클라이언트로 데이터를 전달합니다.
HTTP 프로토콜 : 기존 HTTP 프로토콜을 사용하여 통신합니다.
자동 재연결 지원 : 클라이언트가 네트워크 문제 등으로 연결이 끊어지면 자동으로 재연결을 시도합니다.
최신 브라우저 지원 : 대부분의 최신 브라우저에서 기본적으로 SSE 기능을 지원합니다.

Server-Sent Events 장점

실시간 전송 : 클라이언트 요청 없이 실시간으로 데이터 전송이 가능합니다.
간편한 구현 : WebSocket과는 다르게 추가적인 설정 없이 간단하게 구현이 가능합니다.
자동 재연결 : 자동 재연결 기능을 지원하기 때문에 도중에 네트워크가 끊어져도 안정적인 연결 유지가 가능합니다.
넓은 호환성 : 최신 브라우저에서 기능을 지원하기 때문에 별도의 라이브러리 없이 손쉽게 적용이 가능합니다.
낮은 리소스 소비 : WebSocket보다 CPU, 메모리 소비가 적습니다.

Server-Sent Events 단점

양방향 통신 불가 : 해당 기술이 단방향 통신 방식이기 때문에 실시간으로 양방향 통신이 불가능합니다.
연결 제한 : 한 도메인당 6개의 연결 제한이 있습니다.
CORS 설정 필요 : 다른 도메인에서 데이터를 수신하기 위해서는 서버에서 별도의 CORS 설정이 요구됩니다.

WebSocket

WebSocket란 무엇인가?

WebSocket은 양방향 통신을 지원하는 프로토콜로써 클라이언트와 서버 간에 지속적인 연결을 유지하며 데이터를 실시간으로 주고받을 수 있습니다.
일반적인 HTTP 요청과는 달리, WebSocket은 핸드쉐이크(Handshake) 이후에는 헤더 오버헤드 없이 양방향 통신이 가능하여 빠르고 효율적인 데이터 전송을 제공합니다.
위 그림을 보면 클라이언트와 서버간에 HTTP 핸드쉐이크 과정을 거쳐서 연결되고 WebSocket 프로토콜로 업그레이드 됩니다. WebSocket 프로토콜로 업그레이드되면 클라이언트와 서버는 실시간으로 메시지를 서로 주고받습니다. 그리고나서 어느 한쪽에서 통신을 종료하게 됩니다.

WebSocket 특징

양방향 통신
- 서버와 클라이언트 간에 양방향 통신을 지원하고 서로 실시간으로 데이터를 주고 받을 수 있습니다.
지속적인 연결
- WebSocket 연결은 HTTP 핸드셰이크(HandShake)를 통해 처음 연결되고 이후에는 열린 연결을 유지합니다. 연결이 유지되는 동안 연결을 끊지 않고 데이터를 주고받을 수 있습니다.
낮은 지연시간
- 클라이언트와 서버가 실시간 연결되어 있기 때문에 어느 한쪽에서 데이터 전송시 응답이 빠르고 지연 시간이 적습니다. 연결이 유지되고 있어서 새로운 연결을 할 필요 없이 빠르게 데이터를 전송할 수 있습니다.
헤더 오버헤드 최소화
- WebSocket은 데이터 전송에 필요한 헤더가 작기 때문에 전송 효율이 높습니다. HTTP와 비교시 데이터 전송에 대한 오버헤드가 적습니다.
다양한 프로토콜 지원
- WebSocket은 다양한 종류의 프로토콜을 사용할 수 있으며, 메시지 형식도 자유롭습니다. 이로 인해서 다양한 애플리케이션에서 채팅, 게임, 실시간 알림 등에 활용됩니다.
브라우저 호환성
- 대부분의 최신 브라우저에서 WebSocket을 기본 지원합니다. 웹 애플리케이션에서 실시간 통신을 구현할 때 주로 사용됩니다.

WebSocket 장점

양방향 통신
- 클라이언트와 서버가 동시에 데이터를 주고받을 수 있기 때문에 실시간성이 뛰어납니다.
지속적인 연결 유지
- HTTP 요청-응답 방식과는 달리, WebSocket은 한 번 연결되면 계속 유지되어 추가 요청이 필요없습니다.
네트워크 오버 헤드 감소
- HTTP 요청마다 헤더를 포함하는 방식과 달리, 초기 핸드쉐이크 이후에는 오버헤드 없이 메시지만 전송이 가능합니다.
빠른 데이터 전송 속도
- HTTP 요청을 보낼 필요 없이 즉시 데이터를 주고 받을 수 있기 때문에 지연율(Latency)가 낮습니다.
서버 푸시 기능 지원
- 서버가 클라이언트 요청 없이도 데이터를 자동으로 푸시할 수 있습니다.
- 예를 들어 실시간 알림, 주식 가격 업데이트
연결 유지 비용 감소
- 다수의 HTTP 요청을 줄이고, 연결을 재사용하므로 서버 부하 감소

WebSocket 단점

브라우저 지원 제한
- 최신 브라우저는 지원하지만, 일부 구형 브라우저에서는 동작하지 않을 수 있습니다.
프록시 및 방화벽 문제
- WebSocket은 비표준 HTTP 방식(Upgrade 요청 사용)이라 방화벽이나 프록시에서 차단될 가능성이 있씁니다.
서버 리소스 사용 증가
- 지속적인 연결 유지로 인해서 서버의 메모리 및 네트워크 리소스 소비가 증가됩니다.
재연결 처리 필요
- 네트워크 장애 등으로 연결이 끊어지면 재연결을 수동으로 구현해야 합니다.
보안 이슈
- WebSocket은 기본적으로 CORS 보호를 받지 않습니다. 이로 인해서 보안 취약점이 생길 수 있습니다.
메시지 순서 보장 필요
- TCP 기반이지만 애플리케이션 레벨에서 메시지 순서를 보장하는 로직을 추가로 구현해야 할수도 있습니다.

4가지 전송 방식 비교

데이터 전송 방식

Polling: 단방향(client->server)
Long Polling: 단방향(client->server)
SSE: 단방향(server->client)
WebSocket: 양방향(client<->server)

서버 부하(효율성)

Polling: 높음 (주기적 요청인 경우)
Long Polling: 중간 (응답 시간이 늦어질수록 부하 감소)
SSE: 낮음 (필요할 때만 전송)
WebSocket: 낮음 (항상 연결 윶)

실시간성

Polling: 낮음 (주기적 요청인 경우)
Long Polling: 중간(이벤트 발생시 즉시 응답)
SSE: 높음(서버에서 즉시 전송)
WebSocket: 최고(양방향 지속 연결)

브라우저 지원

Polling, Long Polling: 모든 브라우저 지원
SSE: IE 미지원, 대부분의 브라우저에서 지원
WebSocket: 대부분 지원, 방화벽 문제가 발생할 수 있음

지속 연결 여부

Polling, Long Polling: 매 요청마다 새 연결
SSE: 지속 연결(단방향)
WebSocket: 지속 연결(양방향)

사용 사례

Polling: 주기적인 데이터 조회, 예를 들어 이메일 확인 등이 있음
Long Polling: 실시간 채팅, 실시간 알림
- WebSocket을 대신하지만 HTTP 긴 연결로 인해서 서버 부담이 증가됨
SSE: 실시간 뉴스, 주식 가격 업데이트
WebSocket: 실시간 채팅, 주식 거래

References

'Network' 카테고리의 다른 글

Cross-Origin Resource Sharing과 Preflight Request를 하는 이유에 대해서 (0)	2024.06.15
브라우저에서 네이버를 입력하면 페이지가 보이기까지 무슨일이 일어나는가 (0)	2023.02.17
[Network] 2. 네트워크의 구성 (0)	2022.01.09
[Network] 1. 네트워크의 이해와 설정 (0)	2021.12.02

김용환 블로그