▲

GN⁺: 웹소켓 대 서버 전송 이벤트 대 롱 폴링 대 WebRTC 대 WebTransport 비교

 (rxdb.info)
4P by neo 2달전 | favorite | 댓글 1개

웹소켓 대 서버 전송 이벤트 대 롱 폴링 대 WebRTC 대 WebTransport

  • 현대의 실시간 웹 애플리케이션에서 서버에서 클라이언트로 이벤트를 전송하는 기능은 필수적임.
  • 이 필요성으로 인해 여러 방법들이 개발되었으며, 각각의 장단점을 가지고 있음.
  • 초기에는 롱 폴링만이 사용 가능한 옵션이었으나, 이후 양방향 통신을 위한 더 견고한 솔루션인 웹소켓이 등장함.
  • 웹소켓 이후 서버에서 클라이언트로 단방향 통신을 위한 더 간단한 방법인 서버 전송 이벤트(SSE)가 제공됨.
  • WebTransport 프로토콜은 더 효율적이고 유연하며 확장 가능한 접근 방식을 제공하며, 이 분야를 더욱 혁신할 것으로 보임.
  • 특정 사용 사례를 위해 WebRTC도 서버-클라이언트 이벤트에 고려될 수 있음.

롱 폴링이란?

  • 롱 폴링은 HTTP를 통해 브라우저에서 사용할 수 있는 서버-클라이언트 메시징 방법을 가능하게 하는 최초의 "해킹" 기술임.
  • 클라이언트가 정기적으로 서버에 데이터를 요청하는 전통적인 폴링과 달리, 롱 폴링은 새로운 데이터가 사용 가능할 때까지 열려 있는 서버로의 연결을 설정함.
  • 서버에 새로운 정보가 있으면 클라이언트에게 응답을 보내고 연결을 닫음.
  • 클라이언트는 서버의 응답을 받은 직후 새로운 요청을 시작하고, 이 과정이 반복됨.
  • 이 방법은 더 즉각적인 데이터 업데이트를 가능하게 하고 불필요한 네트워크 트래픽과 서버 부하를 줄임.
  • 그러나 여전히 통신 지연을 초래할 수 있으며 웹소켓과 같은 다른 실시간 기술보다 덜 효율적임.

웹소켓이란?

  • 웹소켓은 클라이언트와 서버 간의 단일 지속적인 연결을 통해 전이중 통신 채널을 제공함.
  • 이 기술은 HTTP 요청-응답 주기의 오버헤드 없이 브라우저와 서버 간의 데이터 교환을 가능하게 하여, 실시간 데이터 전송에 적합함.
  • 웹소켓은 전통적인 HTTP에 비해 큰 진보를 나타내며, 연결이 설정되면 양쪽 모두 독립적으로 데이터를 보낼 수 있어 낮은 지연 시간과 높은 빈도의 업데이트가 필요한 시나리오에 이상적임.

서버 전송 이벤트란?

  • 서버 전송 이벤트(SSE)는 HTTP를 통해 서버 업데이트를 클라이언트로 푸시하는 표준 방법을 제공함.
  • 웹소켓과 달리 SSE는 서버에서 클라이언트로의 단방향 통신에만 설계되어 있어, 클라이언트가 서버로 데이터를 보낼 필요 없이 실시간으로 업데이트를 받아야 하는 상황에 이상적임.

WebTransport API란?

  • WebTransport는 웹 클라이언트와 서버 간의 효율적이고 낮은 지연 시간의 통신을 위해 설계된 최신 API임.
  • HTTP/3 QUIC 프로토콜을 활용하여 다양한 데이터 전송 기능을 가능하게 함.
  • WebTransport는 실시간 게임, 라이브 스트리밍, 협업 플랫폼과 같이 고성능 네트워킹이 필요한 애플리케이션에 강력한 도구임.
  • WebTransport는 현재 작업 초안 단계에 있으며 아직 널리 채택되지 않음.

WebRTC란?

  • WebRTC(웹 실시간 통신)는 웹 브라우저와 모바일 애플리케이션 내에서 복잡한 서버 인프라나 추가 플러그인 설치 없이 실시간 통신(RTC) 기능을 가능하게 하는 오픈소스 프로젝트 및 API 표준임.
  • WebRTC는 브라우저 간에 오디오, 비디오, 데이터 교환을 위한 피어 투 피어 연결을 지원함.
  • WebRTC는 NAT 및 방화벽을 통해 작동하도록 설계되었으며, ICE, STUN, TURN과 같은 프로토콜을 사용하여 피어 간의 연결을 설정함.

기술의 한계

  • 양방향으로 데이터를 보내는 기능은 웹소켓과 WebTransport만이 가능함.
  • 도메인당 6개의 요청 제한으로 인해 모든 지속적인 서버-클라이언트 메시징 방법의 사용성이 제한됨.
  • 모바일 앱에서는 운영 체제가 일정 시간 동안 활동이 없으면 앱을 자동으로 백그라운드로 이동시켜 열려 있는 연결을 닫음.
  • 기업 환경에서는 많은 프록시와 방화벽이 비 HTTP 연결을 차단하여 웹소켓 서버를 인프라에 통합하기 어려움.

성능 비교

  • 웹소켓, SSE, 롱 폴링, WebTransport의 성능을 직접 비교하려면 지연 시간, 처리량, 서버 부하, 다양한 조건에서의 확장성 등 주요 측면을 평가해야 함.

지연 시간

  • 웹소켓: 단일 지속적인 연결을 통한 전이중 통신으로 가장 낮은 지연 시간을 제공함.
  • 서버 전송 이벤트: 서버에서 클라이언트로의 통신에 대해 낮은 지연 시간을 제공하지만, 추가 HTTP 요청 없이 서버로 메시지를 보낼 수 없음.
  • 롱 폴링: 각 데이터 전송에 대해 새로운 HTTP 연결을 설정하는 데 의존하기 때문에 더 높은 지연 시간을 초래함.
  • WebTransport: 웹소켓과 유사한 낮은 지연 시간을 제공할 것으로 예상되며, HTTP/3 프로토콜을 활용하여 더 효율적인 멀티플렉싱과 혼잡 제어의 이점을 가짐.

처리량

  • 웹소켓: 지속적인 연결로 인해 높은 처리량을 달성할 수 있지만, 클라이언트가 서버가 보낼 수 있는 속도만큼 데이터를 처리할 수 없을 때 처리량이 저하될 수 있음.
  • 서버 전송 이벤트: 웹소켓보다 적은 오버헤드로 많은 클라이언트에게 메시지를 방송할 수 있어 단방향 서버-클라이언트 통신에 대해 더 높은 처리량을 달성할 수 있음.
  • 롱 폴링: 연결을 자주 열고 닫는 오버헤드로 인해 일반적으로 더 낮은 처리량을 제공함.
  • WebTransport: 단일 연결 내에서 양방향 및 단방향 스트림 모두에 대해 높은 처리량을 지원할 것으로 예상되며, 다중 스트림이 필요한 시나리오에서 웹소켓을 능가할 수 있음.

확장성 및 서버 부하

  • 웹소켓: 많은 수의 웹소켓 연결을 유지하는 것은 서버 부하를 크게 증가시켜 많은 사용자가 있는 애플리케이션의 확장성에 영향을 줄 수 있음.
  • 서버 전송 이벤트: 웹소켓보다 연결 오버헤드가 적기 때문에 주로 서버에서 클라이언트로 업데이트가 필요한 시나리오에서 더 확장 가능함.
  • 롱 폴링: 빈번한 연결 설정으로 인해 발생하는 높은 서버 부하로 인해 확장성이 가장 낮음.
  • WebTransport: HTTP/3의 연결 및 스트림 처리 효율성을 활용하여 설계되었기 때문에 웹소켓 및 SSE에 비해 서버 부하를 줄이면서 높은 확장성을 가짐.

권장 사항 및 사용 사례 적합성

  • 서버-클라이언트 통신 기술의 환경에서 각각은 독특한 장점과 사용 사례 적합성을 가짐.
  • 서버 전송 이벤트(SSE)는 구현하기 가장 간단하며, 기업 방화벽 제한을 우회하여 기술적 문제를 피할 수 있음.
  • 웹소켓은 지속적인 양방향 통신이 요구되는 시나리오에서 뛰어남.
  • WebTransport는 채택에 어려움이 있으며, Node.js를 포함한 서버 프레임워크에서 널리 지원되지 않고 사파리와 호환되지 않음.
  • 롱 폴링은 비효율적이고 새로운 HTTP 연결을 반복적으로 설정하는 높은 오버헤드로 인해 대부분의 사용 사례에서 사용이 권장되지 않음.

알려진 문제점

  • 모든 실시간 스트리밍 기술에는 알려진 문제점이 있음.
  • 클라이언트가 연결, 재연결 또는 오프라인일 때 서버에서 발생한 이벤트를 놓칠 수 있음.
  • 기업 방화벽은 스트리밍 기술 사용에 문제를 일으킬 수 있음.

GN⁺의 의견

  • 이 기사는 실시간 웹 애플리케이션을 구축할 때 개발자들이 사용할 수 있는 다양한 통신 기술을 비교하고 있어, 기술 선택에 대한 유용한 정보를 제공함.
  • 웹소켓과 SSE는 이미 널리 사용되고 있으며, 특히 웹소켓은 실시간 채팅이나 게임과 같은 양방향 통신이 필요한 애플리케이션에서 매우 인기가 있음.
  • WebTransport는 아직 초안 단계이며, 널리 지원되지 않는다는 점에서 실제 프로젝트에 적용하기에는 무리가 있을 수 있음. 그러나 향후 HTTP/3 기반의 기술로서 많은 잠재력을 가지고 있어 주목할 만함.
  • 롱 폴링은 오래된 기술이지만, 특정 상황에서는 여전히 유용할 수 있으며, 특히 레거시 시스템과의 호환성이 중요한 경우에 사용될 수 있음.
  • 실시간 통신 기술을 선택할 때는 애플리케이션의 요구 사항, 지원되는 브라우저 및 서버 인프라, 그리고 기술의 성숙도를 고려해야 함.
▲
neo 2달전  [-]
Hacker News 의견

  • Server Sent Events(SSE)에 대한 애정을 표현하면서, WebSockets의 흐름 제어(백프레셔)와 멀티플렉싱 부재, SSE의 바이너리 데이터 전송 불가능성, WebTransport의 잠재적인 도입 문제를 언급함.

    "Server Sent Events에 대한 애정이 있으며, WebSockets의 흐름 제어와 멀티플렉싱 부재, SSE의 바이너리 데이터 전송 제한, WebTransport의 도입 문제에 대한 우려를 표함."

  • 기업 환경에서 실시간 기능 구현의 어려움과 관료주의로 인한 문제 해결의 한계를 지적하며, 간단한 해결책으로 새로고침 버튼 추가를 제안함.

    "기업 환경에서 실시간 기능 구현의 어려움과 관료주의 문제를 지적하고, 새로고침 버튼 추가를 간단한 해결책으로 제안함."

  • HTTP/2 이상을 가정할 때, EventSource와 fetch()의 조합이 단일 TCP 연결을 사용하는 다른 프로토콜과 비슷하게 좋을 것 같다는 의견과 HTTP/3의 UDP 사용에 대한 언급이 있음.

    "HTTP/2 이상을 사용할 경우 EventSource와 fetch() 조합의 효율성과 HTTP/3의 UDP 사용에 대한 긍정적인 의견을 제시함."

  • WebSockets와 SSE가 초기 요청에서 헤더 전송을 지원하지 않는 이유를 모르겠다며, 실시간 서비스의 인증을 구현하는 사람에게 맡겨진 상황을 지적함.

    "WebSockets와 SSE의 초기 요청 시 헤더 전송 미지원에 대한 의문과 실시간 서비스 인증의 구현자 의존성 문제를 지적함."

  • WebSockets와 SSE의 대규모 관리 문제, 백엔드의 특별한 관찰 요구, 모바일 디바이스에서의 디버깅 어려움, 네트워크 연결의 비용 문제, 상태 유지의 어려움 등을 언급함.

    "WebSockets와 SSE의 대규모 관리 문제, 백엔드와 모바일 디바이스에서의 디버깅 어려움, 네트워크 연결 비용 및 상태 유지 문제에 대한 언급이 있음."

  • 90년대에 설계된 온라인 경매 시스템에서 실시간 업데이트를 서버 푸시/HTTP 스트리밍으로 처리했던 경험을 공유함.

    "90년대 온라인 경매 시스템에서 서버 푸시/HTTP 스트리밍을 통한 실시간 업데이트 처리 경험을 공유함."

  • Long polling의 단순함을 그리워하며, WebRTC에 대한 긍정적인 평가를 함께 언급함.

    "Long polling의 단순함에 대한 그리움과 WebRTC에 대한 긍정적인 평가를 표함."

  • Stream에서 일하는 사람으로서, 대부분의 경우 30초마다 keep-alive 핑을 보내는 websockets 사용을 권장하며, WebTransport의 낮은 지연 시간과 실시간 게임이나 음성 데이터 전송에 대한 고려를 언급함.

    "Websockets의 keep-alive 핑 사용 권장과 WebTransport의 낮은 지연 시간 및 실시간 게임과 음성 데이터 전송에 대한 고려를 제안함."

  • WebRTC의 UDP 기반 통신 장점을 언급하지 않은 기사에 대한 비판적인 의견을 제시함.

    "기사에서 WebRTC의 UDP 기반 통신 장점을 누락한 점에 대한 비판적인 의견을 제시함."

답변달기