Web Socket vs. Long Polling

Web Socket vs. Long Polling

실시간 웹 통신은 현대 웹 애플리케이션의 핵심 요소로 자리 잡았다. 사용자들은 새로고침 없이 즉시 정보를 받아보기를 기대하며, 이러한 기대를 충족시키기 위해 여러 기술이 발전해왔다. 그중에서도 Long Polling과 WebSocket은 실시간 통신을 구현하는 대표적인 방식으로, 각각의 특징과 적용 사례가 다르다.

기본 개념

WebSocket

WebSocket은 TCP 연결을 통해 전이중(full-duplex) 통신 채널을 제공하는 프로토콜이다. 초기 HTTP 핸드셰이크 후 연결이 WebSocket 프로토콜로 업그레이드되어, 서버와 클라이언트 간에 지속적이고 양방향 통신이 가능해진다. 연결이 한 번 수립되면 두 방향으로 동시에 데이터를 주고받을 수 있으며, 별도의 요청 없이도 서버가 클라이언트에 데이터를 푸시할 수 있다.

Long Polling

Long Polling은 기존 HTTP 요청-응답 모델을 확장한 기법으로, 클라이언트가 서버에 요청을 보내면 서버는 새로운 정보가 있을 때까지 응답을 보류한다. 새 데이터가 생기거나 타임아웃이 발생하면 서버가 응답을 완료하고, 클라이언트는 즉시 새로운 요청을 시작한다. 이는 전통적인 Short Polling보다 지연 시간을 줄이고 불필요한 요청을 감소시킨다.

작동 메커니즘

WebSocket 작동 원리

1. 클라이언트는 HTTP 요청으로 WebSocket 연결을 시작한다(Upgrade: websocket 헤더 포함).
2. 서버가 이 요청을 수락하면 HTTP 연결이 WebSocket 프로토콜로 업그레이드된다.
3. 이후 양쪽은 동일한 TCP 연결을 통해 데이터 프레임을 자유롭게 주고받을 수 있다.
4. 연결은 명시적으로 종료되기 전까지 지속된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// WebSocket 클라이언트 예시
const socket = new WebSocket('ws://example.com/socket');

socket.onopen = function(event) {
    console.log('웹소켓 연결이 열렸습니다.');
    socket.send('클라이언트에서 서버로 메시지 전송');
};

socket.onmessage = function(event) {
    console.log('서버에서 메시지 받음:', event.data);
};

socket.onclose = function(event) {
    console.log('웹소켓 연결이 닫혔습니다.');
};

Long Polling 작동 원리

1. 클라이언트가 서버에 HTTP 요청을 보낸다.
2. 서버는 새 데이터가 있으면 즉시 응답하고, 없으면 이벤트가 발생하거나 타임아웃될 때까지 응답을 보류한다.
3. 응답을 받은 클라이언트는 데이터를 처리한 후 즉시 새로운 요청을 시작한다.
4. 이 과정이 계속 반복된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// Long Polling 클라이언트 예시
function longPoll() {
    fetch('/api/events')
        .then(response => response.json())
        .then(data => {
            console.log('서버에서 데이터 받음:', data);
            // 데이터 처리 후 즉시 다음 요청 시작
            longPoll();
        })
        .catch(error => {
            console.error('에러 발생:', error);
            // 에러 발생 시 잠시 대기 후 재시도
            setTimeout(longPoll, 5000);
        });
}

// Long Polling 시작
longPoll();

프로토콜 및 기술적 특성

WebSocket

• 프로토콜: ws:// 또는 wss://(보안) 프로토콜 사용
• 연결 방식: 지속적인 양방향 연결
• 메시지 형식: 이진 프레임 또는 텍스트 프레임
• 상태 관리: 연결 상태를 유지하며, 연결 종료 시 특별한 종료 프레임 사용
• 헤더 오버헤드: 초기 핸드셰이크 이후 매우 적음 (2-14 바이트의 프레임 헤더)

Long Polling

• 프로토콜: 표준 HTTP 프로토콜 사용
• 연결 방식: 요청-응답 패턴의 확장(응답 지연)
• 메시지 형식: HTTP 응답 (JSON, XML 등)
• 상태 관리: 각 요청은 독립적이며, 서버가 클라이언트 상태를 추적해야 함
• 헤더 오버헤드: 매 요청마다 완전한 HTTP 헤더 포함 (수백 바이트)

성능 비교

1. 지연 시간

   • WebSocket: 연결이 이미 수립되어 있어 메시지 전달 지연이 최소화된다.
   • Long Polling: 서버 이벤트 발생 시 즉시 응답하지만, 응답 후 새 요청을 설정하는 시간만큼 지연이 발생한다.

2. 네트워크 효율성

   • WebSocket: 헤더 오버헤드가 적어 데이터 전송이 효율적이며, 불필요한 연결 재설정이 없다.
   • Long Polling: 각 메시지마다 새로운 HTTP 요청이 필요하여 헤더 오버헤드가 크고, 연결 설정에 추가 비용이 발생한다.

3. 서버 부하

   • WebSocket: 지속적인 연결 유지로 메모리 사용량이 증가하지만, CPU 사용량은 메시지 전송 시에만 발생한다.
   • Long Polling: 연결 설정/해제가 자주 발생하여 CPU 부하가 높을 수 있으며, 활성 연결도 리소스를 소비한다.

4. 확장성

   • WebSocket: 동시 연결 수에 따라 서버 메모리 사용량이 증가하므로, 대규모 확장에는 특별한 관리가 필요하다.
   • Long Polling: 요청-응답 주기로 인해 대규모 사용자에 대한 확장이 어려울 수 있으며, 서버 리소스 점유 문제가 있다.

구현 및 호환성

1. 개발 복잡성

   • WebSocket: 클라이언트와 서버 모두 WebSocket 프로토콜을 구현해야 하며, 연결 관리와 오류 처리가 필요하다.
   • Long Polling: 표준 HTTP를 기반으로 하므로 상대적으로 구현이 간단하지만, 요청 타임아웃 관리와 연결 상태 추적이 필요하다.

2. 브라우저 지원

   • WebSocket: 현대 브라우저에서는 거의 대부분 지원하지만, 일부 오래된 브라우저나 제한된 환경에서는 사용할 수 없을 수 있다.
   • Long Polling: 모든 브라우저에서 완벽하게 지원된다.

3. 네트워크 인프라 호환성

   • WebSocket: 일부 프록시, 방화벽, 로드 밸런서는 WebSocket 연결을 차단하거나 제대로 처리하지 못할 수 있다.
   • Long Polling: HTTP 기반이므로 대부분의 네트워크 인프라와 호환된다.

사용 사례 비교

WebSocket 적합 사례

• 실시간 양방향 통신이 빈번하게 필요한 애플리케이션(온라인 게임, 협업 도구)
• 낮은 지연 시간이 중요한 실시간 대시보드, 모니터링 시스템
• 채팅 애플리케이션, 실시간 알림 시스템
• 주식 거래 플랫폼, 스포츠 중계 등 실시간 데이터 스트리밍

Long Polling 적합 사례

• WebSocket을 지원하지 않는 환경을 위한 폴백 메커니즘
• 메시지 교환이 비교적 드물게 발생하는 시스템
• 서버에서 클라이언트로의 단방향 알림 위주의 애플리케이션
• 기존 HTTP 인프라를 활용해야 하는 레거시 시스템 통합

비교

실제 사용 사례 연구

WebSocket 사용 사례: 실시간 협업 도구

Google Docs와 같은 실시간 문서 협업 도구는 WebSocket을 활용하여 여러 사용자의 동시 편집을 지원한다. 문서 변경이 발생할 때마다 양방향 통신을 통해 즉각적으로 모든 참여자에게 변경 사항이 전달되어 실시간 협업이 가능해진다.

Long Polling 사용 사례: 웹 기반 알림 시스템

이메일 서비스의 새 메일 알림과 같은 시스템은 Long Polling으로 구현될 수 있다. 브라우저가 서버에 새 메일이 있는지 요청하고, 서버는 새 메일이 도착하거나 타임아웃이 발생할 때까지 응답을 보류한다.

하이브리드 접근법

많은 현대 애플리케이션은 WebSocket을 기본으로 사용하되, WebSocket을 지원하지 않는 환경을 위해 Long Polling을 폴백(fallback) 메커니즘으로 구현한다. Socket.IO와 같은 라이브러리는 이러한 하이브리드 접근법을 자동으로 관리해 개발자가 통합된 API를 통해 실시간 기능을 구현할 수 있게 한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// Socket.IO 클라이언트 예시 (WebSocket 우선, Long Polling 폴백)
const socket = io('https://example.com', {
    transports: ['websocket', 'polling']
});

socket.on('connect', () => {
    console.log('서버에 연결됨');
});

socket.on('news', (data) => {
    console.log('새로운 뉴스:', data);
    socket.emit('response', { feedback: '받았습니다' });
});

용어 정리

참고 및 출처