🪵 2. 양방향 웹 통신의 진화: HTTP는 바보~

이번에 웹 환경에서의 클라이언트 - 서버 간 실시간 통신 기술을 사용할 기회가 생겨서 학습하려고 하는 와중에, 먼저 실시간 통신에 대해 심도 있는 배경과 이해가 필요해 이렇게 작성하게 됐습니다.

---

웹은 본래 문서 공유를 위한 플랫폼으로 시작됐습니다. HTTP 프로토콜은 이러한 목적에 맞게 클라이언트의 요청에 서버가 응답하는 단방향 통신 모델을 기반으로 설계됐습니다. 하지만 웹이 발전하면서 실시간 채팅, 온라인 게임, 화상 회의 등 즉각적인 양방향 통신과 더 많은 데이터를 보내줄 필요가 생겼고, 이는 새로운 통신 방식의 필요성을 불러왔습니다.

HTTP의 한계와 해결 시도

이 글에선 HTTP를 이해하고 있다는 조건을 전제하고 있습니다. 혹여나 모른다면 이전에 네트워크 간략한 정의 : IP, TCP/UDP, HTTP(S)에 대해서 먼저 읽고 오시는 걸 추천합니다.

HTTP 통신의 구조적 한계

가장 많이 사용하는 규약인 HTTP/1.1은 아래와 같은 특징을 가지고 있었습니다.

비연결성(Connectionless)

요청-응답 후 연결 종료.

HTTP/1.1은 요청이 오면 서버가 응답을 반환한 후 연결을 끊는 특성을 가지고 있습니다. 즉, 각 요청이 독립적으로 처리되며 클라이언트와 서버는 항상 새로운 연결을 맺고 끊는 과정을 반복하게 됩니다. 이는 리소스가 낭비되는 구조이며, 자주 통신해야 하는 환경에서는 비효율적입니다.

단방향성

클라이언트 요청에 대한 서버 응답만 가능.

HTTP/1.1은 클라이언트가 서버에 요청을 보내고 서버가 응답하는 방식으로 작동합니다. 다시 말해, 서버가 클라이언트에 임의로 데이터를 보낼 수 없는 구조입니다. 이러한 특성은 실시간 데이터 전송이 필요한 애플리케이션에서 한계를 나타내고, 별도의 폴링(polling) 방식 등을 통해 주기적으로 서버 데이터를 요청해야 하는 비효율을 발생시킵니다.

무상태성(Stateless)

이전 요청과 현재 요청 간의 관계가 없음.

HTTP는 무상태 프로토콜로, 각 요청이 서로 독립적이며 이전 요청의 상태를 유지하지 않습니다. 예시를 들자면 사용자가 로그인했다는 상태 정보를 HTTP 자체에서 기억하지 않기 때문에, 세션이나 쿠키 등을 별도로 관리하여 사용자를 식별해야 합니다. 이는 서버와 클라이언트 간의 지속적인 상태 유지를 어렵게 만들고, 데이터가 변경되지 않더라도 매번 재전송해야 하는 단점이 있습니다.

---

위와 같은 특징들은 초기 정적인 웹 페이지 제공에는 적합했으나, 채팅 애플리케이션, 실시간 협업 도구 등 상호작용이 빈번하고 실시간 데이터 처리가 중요한 현대의 웹 애플리케이션에서는 한계를 드러냈습니다. 또한, 1.1의 단점을 없애기 위해 나온 HTTP/2와 HTTP/3로도 서버 임의 요청 불가, 서버 연결 유지에 대한 비효율적 등에 대한 단점이 없어지지 않았습니다.

이를 해결하기 위해 WebSocket 등과 같은 새로운 양방향 통신 프로토콜이 등장하게 되었습니다.

양방향 통신을 위한 해결 방안 및 한계

이러한 HTTP의 구조적 한계로 인해 실시간 상호작용이 중요한 애플리케이션에서는 다양한 해결 방안이 시도됐습니다. 이 항목에서는 그에 대한 해결 방안과 단점 및 한계를 살펴보겠습니다.

Ajax Polling & Long Polling

서버에 주기적으로 요청을 보내고 데이터가 있으면 응답하는 방식 > 실시간 데이터를 얻기 위해 주기적으로 서버에 요청을 보내서 새로운 데이터가 있는지 확인

단방향 통신 프로토콜의 한계를 해결하기 위해, (Ajax) Polling과 Long Polling이 도입되었습니다. 둘의 차이는 응답 지연 방식에 있습니다.

• (Ajax) Polling: 요청 후 즉시 응답, 주기적으로 서버에 새로운 요청 전송.
• Long Polling: 요청 후 서버가 새 데이터가 발생할 때까지 응답 지연(Persisted). 데이터가 발생하면 응답을 보내고 연결을 끊은 후, 클라이언트는 다시 요청 시작.

문제점

단점은 아래와 같습니다.

• 불필요한 HTTP 오버헤드: 둘 모두 요청 시마다 HTTP 헤더와 기타 부가 정보가 포함돼 네트워크 자원이 낭비.
• 서버 자원 낭비
  • Ajax Polling: 새로운 데이터가 없어도 주기적으로 요청 => 서버에게 불필요 리소스 소모 발생.
  • Long Polling: Ajax Polling 다소 개선. But, 많은 연결 유지 => 서버 부담 증가.
• 실시간성의 한계
  • Ajax Polling: 설정된 간격마다 요청 => 그 사이 실시간성 보장 X.
  • Long Polling: 즉각적인 데이터 전송이 가능, But 연결 관리 복잡.
• 확장성 문제: 많은 클라이언트가 동시에 요청할 경우 서버에 큰 부하가 발생해 확장성 하락.

Server-Sent Events (SSE)

서버에서 클라이언트로의 단방향 실시간 데이터 스트림을 제공하는 웹 표준 기술

Polling의 한계를 개선하고 WebSocket보다 간단한 구현을 원하는 경우를 위해 등장한 기술입니다. SSE는 기존 HTTP 연결을 통해 서버가 클라이언트에게 지속적으로 데이터를 보낼 수 있게 해줍니다.

작동 방식

// 클라이언트 측 코드
const eventSource = new EventSource('/api/events');

eventSource.onmessage = (event) => {
  console.log('새로운 데이터:', event.data);
};

// 서버 측 코드 (Node.js 예시)
app.get('/api/events', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive'
  });

  // 새로운 데이터가 있을 때마다 전송
  setInterval(() => {
    res.write(`data: ${JSON.stringify({ time: new Date() })}\n\n`);
  }, 1000);
});

1. 클라이언트가 HTTP 연결을 생성
2. 서버는 연결을 유지하며 text/event-stream 형식으로 데이터 전송
3. 자동 재연결 메커니즘 제공

장점

1. 단순한 구현

   • 일반 HTTP를 사용하여 구현 가능
   • WebSocket보다 서버 구현이 간단
   • 기존 HTTP 인프라 활용 가능 (프록시, 로드밸런서 등)

2. 자동 재연결

   • 연결이 끊어졌을 때 자동으로 재연결 시도
   • 마지막 이벤트 ID를 추적하여 누락된 메시지 복구 가능

3. 브라우저 호환성

   • 대부분의 모던 브라우저에서 지원
   • 폴리필을 통한 하위 호환성 제공

한계

1. 단방향 통신

   • 서버에서 클라이언트로만 데이터 전송 가능
   • 클라이언트에서 서버로의 데이터 전송은 별도의 HTTP 요청 필요

2. 연결 수 제한

   • 브라우저당 동시 연결 수 제한 존재
   • 도메인당 연결 제한으로 인한 확장성 제약

3. 제한된 데이터 형식

   • 텍스트 기반 데이터만 전송 가능
   • 바이너리 데이터 전송 불가

적합한 사용 사례

• 실시간 주식 시세, 뉴스 피드
• 소셜 미디어 업데이트
• 실시간 로그 모니터링
• 진행 상황 업데이트

SSE는 서버에서 클라이언트로의 단방향 실시간 데이터 전송이 필요하고, 구현의 단순성이 중요한 경우에 적합한 선택입니다. WebSocket보다 가벼우면서도 Polling보다 효율적인 중간자적 위치를 차지하고 있습니다.

결론

실시간 통신을 위한 초기 시도였던 두 Polling 형제들은 실시간 데이터 확인을 가능하게 했지만, 지속적인 서버 연결과 실시간성을 보장하기에는 한계가 있었습니다.

이후 등장한 SSE는 서버에서 클라이언트로의 단방향 실시간 스트리밍을 효과적으로 처리할 수 있게 했지만, 양방향 통신이 필요한 상황에서는 여전히 제약이 있었습니다.

결국 이러한 한계들을 근본적으로 해결하기 위해 WebSocket 등의 양방향 통신 프로토콜이 등장하게 되었습니다. 반쪽짜리가 아닌 웹에서의 실시간 양방향 통신이 WebSocket의 등장으로 구현될 수 있었던 겁니다!

WebSocket의 등장

WebSocket 프로토콜의 탄생 배경

2008년 TCP 연결 관련 논의에서, Michael Carter가 주도해 WebSocket 프로토콜을 제안했습니다. '웹 양방향 통신 문제를 근본적으로 해결하기 위해서' 였죠. HTML5 표준화 과정에서 WebSocket은 중요한 부분으로 자리잡았고, 2011년 RFC 6455로 표준화되었습니다.

WebSocket 주요 특징

1. Single TCP Connection (단일 TCP 연결)

• HTTP 프로토콜 위에서 Handshaking 최초 수행.
• 최초 연결 수립 후 동일한 연결 재사용.
  1. Upgrade: websocket 헤더로 요청.
  2. Connection: Upgrade 헤더로 응답 및 연결.
• HTTP처럼 매 요청마다 새로운 연결 맺지 않음.
• 연결 수립에 따른 리소스 소모 최소화.

HTTP는 요청마다 3-way handshake가 필요했지만, WebSocket은 최초 1회 handshake 후 계속 사용하는 특징을 가지고 있습니다.

2. Full-Duplex Communication (진짜진짜 양방향 통신)

• 클라이언트와 서버가 독립적으로 메시지 전송 가능.
• 서버가 클라이언트의 요청 없이도 데이터 전송 가능.
• 즉, 실시간 알림, 채팅 등에 이상적.

// 서버에서 클라이언트로 자발적 메시지 전송 예시
webSocket.send(
  JSON.stringify({
    type: 'notification',
    message: '새로운 메시지가 도착했습니다.',
  }),
);

위처럼 연결된 webSocket 객체의 send 메소드를 활용하면 클라이언트의 요청 없이도 응답을 아주 가볍게 보낼 수 있습니다.

3. Minimal Protocol Overhead (최소한의 프로토콜 오버헤드)

• 매우 작은 헤더 크기. (2-14 바이트)
• HTTP의 무거운 헤더와 비교해 데이터 전송 효율성 높음.
• HTTP 헤더 예시. (약 200바이트)

  GET /api/data HTTP/1.1
  Host: example.com
  User-Agent: Mozilla/5.0 ...
  Accept: */*
  Connection: keep-alive
  Cookie: session=abc123...
  

• WebSocket 프레임 헤더 예시. (2-14바이트)

  FIN RSV1-3 Opcode
  MASK Payload len
  [Extended payload length]
  [Masking key]
  

4. Standardized Error Handling (표준화된 에러 처리)

• 연결 상태 모니터링을 위한 내장 메커니즘.
• ping/pong 프레임을 통한 연결 생존 확인.
• 자동 재연결 구현 용이.

class WebSocketClient {
  constructor(url) {
    this.url = url;
    this.reconnectAttempts = 0;
    this.connect();
  }

  connect() {
    this.ws = new WebSocket(this.url);

    // 연결 상태 모니터링
    this.ws.onclose = (event) => {
      if (event.code !== 1000) {
        // 비정상 종료
        this.reconnect();
      }
    };

    // 주기적인 ping/pong 체크
    this.heartbeat = setInterval(() => {
      if (this.ws.readyState === WebSocket.OPEN) {
        this.ws.send('ping');
      }
    }, 30000);
  }

  reconnect() {
    if (this.reconnectAttempts < 5) {
      setTimeout(() => {
        this.reconnectAttempts++;
        this.connect();
      }, 1000 * Math.pow(2, this.reconnectAttempts));
    }
  }
}

그 외 WebSocket 프로토콜의 서브프로토콜 지원 및 커스텀 프로토콜 구현도 가능하고, Text 및 Binary 등의 데이터 같은 다양한 메시지 포맷도 지원이 됩니다. WebSocket은 이러한 특징들을 통해 실시간 양방향 통신이 필요한 현대 웹 애플리케이션의 요구사항을 효과적으로 충족시켜 큰 발전을 이루었습니다.

WebSocket의 단점

WebSocket은 실시간 상호작용이 필요한 웹 애플리케이션에서 큰 발전을 이루었지만, 몇 가지 중요한 단점이 있습니다. 이러한 단점 때문에 WebRTC와 같은 P2P 실시간 통신 프로토콜이 개발됐습니다.

1. 중앙 서버 의존성

Client A → Server → Client B

WebSocket은 무조건 중앙 서버를 통해 모든 데이터를 전송해야 합니다. 클라이언트 간의 직접 통신이 필요할 경우에도 서버가 중개 역할을 해야 하므로, 지연 시간이 늘어나고 서버 자원이 추가로 소모됩니다.

2. 실시간 미디어 전송에 한계

// WebSocket으로 비디오 스트림 전송 시도 예시
const ws = new WebSocket('wss://example.com');

// 비효율적인 미디어 데이터 전송
videoStream.getTracks().forEach((track) => {
  track.addEventListener('sample', (event) => {
    ws.send(event.sample.buffer); // 무거운 미디어 데이터를 서버 경유로 전송
  });
});

WebSocket은 텍스트 또는 이진 데이터 등인 메시지 포맷 전송에 최적화돼 있습니다. 다시 말해, 더 많은 기술을 웹에 사용하기 위해 고품질 영상 및 음성 데이터 등을 담은 화상 회의나 실시간 음성 통화를 지원해야하는데, WebSocket은 고품질 미디어 스트리밍에는 적합하지 않습니다.

다시 말해, 그 무거운 데이터를 최적화도 없이 서버 경유를 거친다는 것 자체가 비효율적이라는 겁니다.

3. 네트워크 환경 변화에 대한 유연성 부족

class WebSocketConnection {
  constructor() {
    this.ws = null;
    this.reconnectAttempts = 0;
  }

  connect() {
    this.ws = new WebSocket('wss://example.com');

    // 네트워크 변화 대응이 제한적
    this.ws.onclose = () => {
      // 단순 재연결 시도만 가능
      this.reconnect();
    };
  }

  // 제한적인 네트워크 대응
  reconnect() {
    if (this.reconnectAttempts < 5) {
      setTimeout(() => {
        this.connect();
      }, 1000 * Math.pow(2, this.reconnectAttempts));
    }
  }
}

WebSocket은 TCP 기반으로 설계되어 있어, 네트워크 환경 변화에 대한 적응력이 부족합니다. 예를 들자면, 모바일 환경에서 네트워크가 Wi-Fi에서 LTE로 전환될 경우 연결이 끊기기 쉽습니다.

---

이러한 WebSocket의 단점들은 다음 세대의 필요성을 강조하는 이유가 됐습니다. 특히 서버 통신이 필요없는 웹이나 고품질 실시간 미디어 전송이 필요한 환경에서는 이러한 단점들이 더더욱 부각됐습니다.

WebRTC의 등장 및 혁신

2010년대 초반, Google은 웹에서 실시간 통신을 P2P 방식으로 구현할 수 있도록 하는 새로운 프로토콜을 발표했습니다. 이 프로토콜이 바로 **WebRTC(Web Real-Time Communication)**입니다.

WebRTC 탄생 배경 및 발전

왜 필요한가?

WebRTC는 WebSocket이 해결하지 못한 문제들을 극복하기 위해 등장했습니다. 특히, 실시간으로 고품질 미디어 전송하는 기술과 P2P 통신을 지원하는 WebRTC는 웹 상에서의 실시간 통신을 보다 효율적으로 구현하기 위한 기술로 주목받았습니다.

• 플러그인 의존성 제거: 기존에는 Flash나 Silverlight 같은 플러그인 통해 실시간 통신을 구현, 하지만 추가 설치가 필요하고 보안 문제 발생 증가.
• 중앙 서버 경유로 인한 지연: 중앙 서버를 통한 데이터 중계로 인해 지연 발생, 서버 리소스 소모 증가. 서버 없이 클라이언트 간 직접 통신이 가능한 프로토콜이 필요해졌음.
• 높은 대역폭 비용: 고품질 미디어 전송을 위한, 네트워크 대역폭을 효율적으로 사용하는 미디어 전송 최적화 기능 필요.

WebRTC의 공개와 발전

그래서 2011년, Google은 Global IP Solutions을 인수하고 WebRTC 프로젝트를 오픈소스로 공개하면서 본격적인 개발이 시작되었습니다. WebRTC는 기존의 중앙 서버 방식(e.g. Client → Server → Client)을 **P2P 방식(e.g. Client ←→ Client)**으로 발전시켜 실시간 데이터 전송을 효율화했습니다. (물론 연결을 위한 최소한의 시그널링 서버가 필요하긴 하지만요)

WebRTC 특징

1. 자동화된 네트워크 처리

   • ICE(Interactive Connectivity Establishment) 프레임워크를 통한 최적 경로 자동 선택.
   • NAT 통과 자동 처리.
     • 클라이언트 간 연결을 원활하게 설정 가능.
   • 네트워크 변화에 동적 대응.

2. 최적화된 미디어 처리

   • 자동 비트레이트 조정.
     • 네트워크 상태에 맞춰 미디어 품질 조정.
   • 패킷 손실 복구 및 지연 최소화 기능을 제공.
     • 음성 통화, 화상 회의 등 실시간 통신에서 높은 품질을 유지.

3. 통합된 보안

   • 기본적으로 DTLS/SRTP 암호화.
   • 인증서 기반 보안.
   • 중간자 공격 방지.

4. 브라우저 네이티브 지원

   • 플러그인 없는 실시간 통신
   • 표준화된 API.
     • Mozilla
     • 공식 문서
     • RFC 8835
   • Chrome, Firefox, Safari 등 크로스 브라우저 가능.

WebRTC는 이와 같은 특징들 덕분에 실시간 커뮤니케이션을 필요로 하는 애플리케이션(화상 회의, 파일 공유, 실시간 게임 등)에서 효율적인 P2P 연결과 고품질 미디어 전송을 구현할 수 있는 중요한 기술로 자리 잡았습니다.

만능같아 보이지만 단점도 존재합니다. 네트워크 및 NAT 문제(ICE로 완화 가능), 네트워크 대역폭 관련 성능 문제, 복잡한 구현 및 설정, P2P 연결에 의한 확장성 문제(SFU나 MCU로 완화 가능), 구형 브라우저 미지원 등의 단점이 있긴 합니다.

결론

지금까지 웹 통신의 변화를 살펴봤습니다. HTTP의 한계부터 P2P 통신까지 말이죠. 글을 잘 보신 독자님이라면 알겠지만 각각의 기술은 장단점이 있어 나에게 맞는 기술을 선택하는 것이 중요할 것입니다.

1. HTTP의 한계 극복

수박 겉핥기, 반쪽짜리 양방향 통신.

• 문서 공유 중심의 단방향 통신에서 시작.
• Polling과 Long Polling으로 실시간성 모방.
• 하지만 근본적인 한계 존재.

2. WebSocket의 등장

서로의 클라이언트 데이터를 중개해주는 아빠 서버.

• 진정한 양방향 통신 실현.
• 단일 연결을 통한 효율성 향상.
• 실시간 애플리케이션의 기반 마련.
• 그러나 서버 중심 아키텍처의 한계 존재.

3. WebRTC의 혁신

• P2P 기반의 클라이언트 직접 통신 실현.
• 미디어 스트리밍 최적화.
• 보안과 성능의 균형.

어쨌든 2, 3번 두 기술의 등장으로, 웹은 단순한 문서 공유를 넘어 풍부한 실시간 상호작용이 가능한 플랫폼으로 진화했습니다. WebSocket과 WebRTC는 각기 다른 문제를 해결하기 위해 설계되었으며, 현대 웹 애플리케이션에서 중앙 서버 기반의 메시징과 P2P 미디어 전송이라는 상호 보완적인 역할을 수행하고 있습니다. 앞으로도 웹은 더욱 진화해 많은 역할을 담당할 수 있을 것입니다.

다음 글에서는 직접 WebRTC를 써보며 딥다이브해보는 시간을 가져볼 것 같습니다. 기대해주세요!@@

참고

• 🌐 Polling / Long Polling / Server Sent Event / WebSocket 정리
• [Web] 웹 소켓(Web Socket)이란? 등장 배경과 목적, 동작 방식 (feat. Polling, Long polling, Server-Sent Event)
• 카카오톡 시스템 디자인 | WebSocket | 메시지 큐 | SQL vs NoSQL
• JAVASCRIPT.INFO 네트워크 요청
• 2008년 TCP 연결 관련 논의
• RFC 6455
• WebSockets Demystified, Part 1: Understanding the Protocol
• 네트워크 간략한 정의 : IP, TCP/UDP, HTTP(S)
• WebRTC? WebSockets? 5분 개념정리!
• WebRTC Mozilla
• WebRTC 공식 문서
• WebRTC RFC 8835