# 웹소켓 대 서버 전송 이벤트 대 롱 폴링 대 WebRTC 대 WebTransport 비교 > Clean Markdown view of GeekNews topic #13888. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=13888](https://news.hada.io/topic?id=13888) - GeekNews Markdown: [https://news.hada.io/topic/13888.md](https://news.hada.io/topic/13888.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2024-03-19T16:36:06+09:00 - Updated: 2024-03-19T16:36:06+09:00 - Original source: [rxdb.info](https://rxdb.info/articles/websockets-sse-polling-webrtc-webtransport.html) - Points: 4 - Comments: 1 ## Topic Body ### 웹소켓 대 서버 전송 이벤트 대 롱 폴링 대 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 기반의 기술로서 많은 잠재력을 가지고 있어 주목할 만함. - 롱 폴링은 오래된 기술이지만, 특정 상황에서는 여전히 유용할 수 있으며, 특히 레거시 시스템과의 호환성이 중요한 경우에 사용될 수 있음. - 실시간 통신 기술을 선택할 때는 애플리케이션의 요구 사항, 지원되는 브라우저 및 서버 인프라, 그리고 기술의 성숙도를 고려해야 함. ## Comments ### Comment 23851 - Author: neo - Created: 2024-03-19T16:36:06+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=39745993) - 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 기반 통신 장점을 누락한 점에 대한 비판적인 의견을 제시함."