웹소켓 대안
Published: 2023-12-14 09:18:52

인터넷의 급속한 성장으로 인해 실시간 기술에 대한 수요가 증가하면서 클라이언트와 서버 간의 통신이 향상되었습니다. 웹소켓의 인기가 높아지면서 이제는 실시간 통신을 가능하게 하는 가장 인기 있는 방법 중 하나가 되었습니다. 하지만 특정 사용 사례에 따라 기술 선택이 달라지므로 웹소켓이 항상 최선의 선택은 아닐 수 있습니다. 특정 상황에 더 적합할 수 있는 다양한 대체 옵션이 있습니다.

웹소켓이란 무엇인가요?
------------

[웹소켓은](https://www.pubnub.com/guides/what-are-websockets-and-when-should-you-use-them/) 다음을 제공하는 프로토콜입니다. [전이중](https://en.wikipedia.org/wiki/Duplex_(telecommunications)) 통신 및 웹을 통한 클라이언트와 서버 간의 양방향 통신 채널을 제공하는 프로토콜입니다. 이 프로토콜을 사용하면 서버에 다시 연결하지 않고도 클라이언트 측과 클라이언트-서버 간에 실시간 데이터 전송이 가능합니다. 기존 [HTTP 프로토콜과](https://www.pubnub.com/guides/http/) 달리 웹소켓은 클라이언트와 서버가 언제든지 통신을 시작하고 데이터를 전송할 수 있으므로 실시간 데이터 전송에 이상적입니다.

![](https://images.ctfassets.net/3prze68gbwl1/7LukONcMxY3FxnW3B4xkYI/0ffd1c3ffbbbffc614155918de821e9c/WebSocket-Diagram.png)

왜 웹소켓 대안을 선택해야 할까요?
-------------------

개발자가 실시간 통신을 고려할 때 거의 모든 경우 웹소켓을 사용합니다. 왜 그럴까요? 사용 사례에 관계없이 실시간 전송을 달성하기 위한 유일한/최선의 선택일까요?

간단히 말해, 웹소켓은 고급 기능을 제공하지만 사용 사례에 따라 프로젝트의 복잡성을 빠르게 증가시킬 수 있는 많은 단점이 있을 수 있습니다. 이 문제를 해결하기 위해 개발자가 왜 웹소켓을 대안으로 선택하는지 생각해 봅시다.

성능: 웹소켓은 고급 기능으로 가장 잘 알려져 있지만 때로는 과도한 솔루션이 되어 성능 저하로 이어질 수 있습니다. 웹소켓 사용을 결정할 때는 사용 사례를 고려하는 것이 중요합니다. 예를 들어, 높은 연결 동시성이 필요한 경우 WebSocket보다 더 나은 솔루션이 있습니다. 웹소켓 연결은 클라이언트와 서버 간에 계속 유지되어야 하므로 확장에 따라 서버와 기본 인프라의 부하가 증가하게 됩니다.

상호 운용성: 웹소켓은 모든 최신 웹 브라우저/네트워크에서 지원됩니다. 혹시라도 소프트웨어가 레거시 브라우저나 네트워크에서 사용 중이라면 해당 레거시 시스템에서 웹소켓이 지원되는지 고려해야 합니다. 또한 네트워크와 프록시가 웹소켓 연결을 완전히 차단하는 경우도 있으므로 소프트웨어를 사용하는 곳도 고려해야 할 또 다른 요소입니다.

보안: 웹소켓은 일부 대체 수단만큼 안전하지 않으며 악의적인 공격자가 악용할 수 있는 취약점이 있습니다. 웹소켓이 다른 프로토콜보다 보안성이 떨어지는 이유로는 사이트 간 웹소켓 하이재킹과 오리진 스푸핑 등이 있습니다.

웹소켓 대안
------

#### 롱 폴링

[롱 폴링](https://www.pubnub.com/guides/long-polling/) 은 클라이언트가 서버에 HTTP/HTTPS 요청을 보내지만 서버로부터 즉각적인 응답을 받는 대신 HTTP 연결을 유지하는 방식입니다. HTTP 연결을 유지하면 나중에 데이터를 사용할 수 있게 되거나 시간 초과 임계값에 도달했을 때 서버가 응답할 수 있습니다. 응답을 받은 클라이언트는 즉시 후속 요청을 전송합니다.

롱 폴링은 웹소켓이 제공하는 양방향 통신 채널 없이도 실시간 통신이 가능합니다. 핵심적인 차이점은 웹소켓처럼 지속적인 연결을 유지하는 대신 클라이언트가 서버와의 연결을 다시 설정하기 위해 여러 요청을 보낸다는 것입니다.

![](https://images.ctfassets.net/3prze68gbwl1/2FEB0j6VRCXSe28P5ruiSZ/a149b8fdbbdb77e5f3bb81aab9902dac/HTTP_Long_Polling.png)

#### MQTT

[MQTT](https://www.pubnub.com/guides/mqtt/) 는 네트워크 대역폭이 제한된 디바이스가 있는 원격지를 위해 설계된 경량, [게시-구독](https://www.pubnub.com/guides/everything-you-need-to-know-about-pub-sub/) 방식의 머신 간 네트워크 프로토콜입니다. 스마트 센서, 웨어러블 및 기타 IoT 디바이스는 일반적으로 리소스 제약으로 인해 이러한 프로토콜을 사용해야 합니다. 웹소켓은 다양한 애플리케이션에 사용할 수 있지만, MQTT는 명시적으로 기계 간 통신을 위해 설계되었기 때문에 이러한 사용 사례에서 대안으로 간주됩니다. MQTT는 낮은 오버헤드, 효율적인 메시지 전송, 오프라인 작동 지원 등의 기능을 제공합니다.

![](https://images.ctfassets.net/3prze68gbwl1/2R4S3y5yDtT3r91DvpbI8t/2df1e001799058ec32cadd3a887a8fbd/MQTT_Glossary_Broker_copy_4.png)

#### WebRTC

[WebRTC는](https://www.pubnub.com/guides/webrtc/) 웹 브라우저와 모바일 디바이스에 실시간 통신 기능을 제공하는 [C++](https://www.pubnub.com/docs/sdks/posix-cpp) 및 [JavaScript로](https://www.pubnub.com/docs/sdks/javascript) 작성된 무료 오픈소스 프로젝트입니다. WebRTC는 [구축](https://dolby.io/blog/adding-pubnub-in-app-chat-to-your-webrtc-live-stream-app/) 서버 측 연결이나 추가 플러그인 없이도 피어 투 피어에서 직접 오디오와 비디오를 스트리밍할 수 있습니다. 라이브 스트리밍, 화상 회의 또는 그룹 통화와 같은 사용 사례의 경우, 이러한 기능은 WebRTC API를 사용하여 HTML5 및 [JavaScript를](https://www.pubnub.com/guides/javascript/) 통해 신속하게 엔지니어링할 수 있습니다. 요약하자면, WebRTC의 피어 투 피어 특성은 이러한 사용 사례에서 웹소켓에 비해 서버 부하를 줄이고 더 효율적이고 고품질의 커뮤니케이션 경험을 제공하는 데 도움이 될 수 있습니다.

### 웹트랜스포트와 웹소켓 비교

[웹트랜스포트는](https://www.pubnub.com/guides/webtransport/) 클라이언트와 서버 간에 지연 시간이 짧고 처리량이 많은 연결을 제공하는 새로운 웹 통신 프로토콜입니다. 웹소켓과 같은 기존 프로토콜의 몇 가지 한계를 해결하고 오늘날 웹 애플리케이션의 요구 사항을 더 잘 처리할 수 있는 최신 대안을 제공하기 위해 만들어졌습니다.

웹소켓은 일반적으로 HTTP/1.1 업그레이드 요청으로 시작하지만, 웹트랜스포트는 HTTP/2를 포함한 여러 프로토콜을 지원합니다, [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3), 그리고 [QUIC](https://en.wikipedia.org/wiki/QUIC)등 다양한 프로토콜을 지원하며, [UDP 기반](https://www.pubnub.com/guides/udp/) 전송입니다. 또한 웹트랜스포트는 스트림 API를 통해 안정적으로 데이터를 전송할 수 있고, 데이터그램 API를 통해 불안정하게 데이터를 전송할 수도 있습니다. 이 새로운 기술은 웹소켓과 어떻게 비교되며, 웹트랜스포트 프로토콜로 전환하면 어떤 이점이 있을까요?

고급 기능: 웹소켓의 문제점은 단일 연결을 통해 이미지와 텍스트 등 서로 다른 유형의 데이터를 전송하기 어렵다는 것입니다. 이 문제는 데이터를 패킷이라는 작은 단위로 나누어 [TCP](https://www.pubnub.com/guides/tcp-ip/) 연결을 통해 전송하기 때문에 발생합니다. 데이터를 패킷으로 나눌 때 데이터에 포함된 일반 텍스트와 인코딩된 이미지를 구분할 수 있는 방법이 없습니다. 이 문제를 해결하기 위해 웹소켓은 종종 서버와 클라이언트 사이에 그림과 텍스트에 대해 두 개의 별도 연결을 만들어야 합니다. 하지만 웹트랜스포트는 멀티플렉싱으로 알려진 다중 스트림을 지원함으로써 이 문제를 해결할 수 있습니다. 다중 스트림을 지원함으로써 개발자는 하나의 연결을 통해 다양한 유형의 데이터를 전송할 수 있으므로 수많은 연결을 설정하고 유지하는 데 따른 오버헤드를 줄일 수 있습니다. 이는 서버가 많은 클라이언트를 지원해야 할 때 필수적인 기능입니다. 웹소켓에서와 같이 클라이언트당 여러 개의 연결이 있으면 서버가 확장되기 시작할 때 복잡해질 수 있습니다.

성능 향상: 웹트랜스포트는 웹소켓과 같은 TCP 기반 프로토콜보다 성능이 뛰어난 UDP 기반 전송 프로토콜입니다. UDP 기반이기 때문에 오류 수정이나 재전송이 없습니다. 오류 수정은 전송된 데이터에서 발생할 수 있는 오류를 감지하고 수정하는 것을 말합니다. 재전송은 네트워크를 통해 손실되거나 손상된 데이터 패킷을 다시 보내는 처리를 말합니다. 수정 및 재전송에 대한 오버헤드가 없기 때문에 WebTransport의 [지연](https://www.pubnub.com/guides/whats-so-important-about-low-latency/) 시간이 줄어듭니다. 또한 웹 전송은 요청의 처리량과 지연 시간을 최적화할 수 있는 웹 전송 혼잡 제어 구성을 제공합니다. 둘째, QUIC 핸드셰이크를 통해 WebTransport로 새 연결을 설정하는 것이 일반적으로 TCP over TLS보다 빠릅니다.

신뢰성: 오류 수정 및 재전송 기능이 없기 때문에 개발자는 WebTransport가 WebSockets보다 안정성이 떨어진다고 생각할 수 있습니다. 그렇지 않습니다. 웹 전송은 설계상 특히 고대역폭 통신과 까다로운 네트워크 조건이 있는 시나리오에서 웹 소켓보다 더 높은 안정성을 제공합니다. 웹 전송 [는](https://www.w3.org/TR/webtransport/) 안정적인 단방향(WebTransportReceiveStreams) 또는 양방향(WebTransportBidirectionalStream) 데이터 전송을 위한 스트림 API를 제공합니다. 이 API 엔드포인트는 안정적인 데이터 전송이 필수적인 시나리오에서 연결이 TCP 폴백을 갖도록 허용할 수 있는 WebTransportReliabilityMode와 같은 구성을 제공합니다.

보안: 웹 전송은 웹 소켓보다 더 안전한 프로토콜을 제공합니다. 기본적으로 종단 간 암호화를 제공하여 클라이언트와 서버 간의 데이터를 전송 중에 가로채거나 수정할 수 없도록 보장합니다. 이러한 보안 기능 중 하나는 서버가 요청이 신뢰할 수 있는 소스에서 오는지 확인할 수 있는 방법을 제공하는 '오리진' 헤더를 사용하는 것입니다. 이는 사이트 간 요청 위조(CSRF) 공격을 방지하는 데 도움이 됩니다.

### 다른 대안

#### 서버에서 보낸 이벤트

[서버 전송 이벤트(SSE)](https://www.pubnub.com/guides/server-sent-events/) 는 서버가 단일 HTTP 연결을 통해 클라이언트에 데이터를 푸시할 수 있는 서버 푸시 기술입니다. SSE는 웹 페이지나 애플리케이션에 실시간 업데이트를 전송하기 위한 간단하고 효율적인 프로토콜로, 특정 사용 사례에 적합합니다. 한 번의 응답 후 연결을 닫는 기존 HTTP 요청과 달리 SSE는 서버와 클라이언트 간에 수명이 긴 연결을 열어 서버가 동일한 연결을 통해 여러 개의 업데이트를 전송할 수 있도록 합니다. 웹소켓의 양방향 연결에 비해 서버 전송 이벤트는 단방향으로만 연결됩니다. 클라이언트는 연결을 시작하고 닫기만 하면 됩니다. 하지만 서버 전송 이벤트의 제한된 기능 덕분에 구현과 디버깅이 더 쉽습니다. 서버 전송 이벤트는 [EventSource](https://developer.mozilla.org/en-US/docs/Web/API/EventSource) API의 시작이었으며, 웹 브라우저에서 쉽게 구현할 수 있습니다.

![Server Sent Events exchange](https://images.ctfassets.net/3prze68gbwl1/7hGVCgK5DEFPKeakTFWKxu/7462285d9e144607b97f93a58d82a609/Server-Sent.png)

웹소켓 대체 프로토콜에 대한 PubNub의 지원 방법
-----------------------------

웹소켓 프로토콜과 그 대안인 웹트랜스포트는 모두 실시간 통신을 처리하는 데 유용한 솔루션입니다. 그러나 어떤 솔루션을 선택하든 기본 인프라를 구현하는 데 시간이 낭비되고 확장할 때 복잡해집니다. 예를 들어, [Socket.io와](https://www.pubnub.com/guides/what-is-socket-io/) 같은 특정 기술을 사용하여 웹소켓 서버를 생성하는 경우 개발자는 각 웹 서버의 사용률을 관리하기 위해 로드 밸런서 뒤에서 전 세계에 서버를 동적으로 생성하는 작업을 처리해야 합니다.

PubNub의 [실시간 데이터 API를](https://www.pubnub.com/learn/glossary/what-is-real-time-data/) 사용하면 특정 사용 사례에 관계없이 모든 기기에서 실시간 통신을 지원하는 강력한 이벤트 기반 애플리케이션을 개발할 수 있습니다. PubNub은 웹 애플리케이션을 위한 [JavaScript SDK와](https://www.pubnub.com/docs/sdks/javascript) IoT 애플리케이션을 위한 [C-Core SDK](https://www.pubnub.com/docs/sdks/c-core) 등 다양한 SDK를 제공하여 선택한 디바이스와의 원활한 통합을 보장합니다. PubNub을 사용하면 적합한 대안을 선택하거나 실시간 솔루션 구현의 근본적인 복잡성에 대해 걱정할 필요가 없습니다.

이제 웹소켓을 사용해야 할 때와 다른 대안을 사용해야 할 때를 이해하셨으니, 이제 바로 시작하세요, [무료 평가판에 등록](https://admin.pubnub.com/#/register) 또는 [데모 예약](https://www.pubnub.com/company/contact-sales/) 를 예약하여 PubNub로 무엇을 구축할 수 있는지 살펴보세요.

PubNub이 어떤 도움이 될까요?
===================

이 문서는 원래 [PubNub.com에](https://pubnub.com/blog/websockets-alternatives/) 게시되었습니다.

저희 플랫폼은 개발자가 웹 앱, 모바일 앱 및 IoT 기기를 위한 실시간 인터랙티브를 구축, 제공 및 관리할 수 있도록 지원합니다.

저희 플랫폼의 기반은 업계에서 가장 크고 확장성이 뛰어난 실시간 에지 메시징 네트워크입니다. 전 세계 15개 이상의 PoP가 8억 명의 월간 활성 사용자를 지원하고 99.999%의 안정성을 제공하므로 중단, 동시 접속자 수 제한, 트래픽 급증으로 인한 지연 시간 문제를 걱정할 필요가 없습니다.

PubNub 체험하기
-----------

[라이브 투어를](https://www.pubnub.com/tour/introduction/) 통해 5분 이내에 모든 PubNub 기반 앱의 필수 개념을 이해하세요.

설정하기
----

PubNub [계정에](https://admin.pubnub.com/signup/) 가입하여 PubNub 키에 무료로 즉시 액세스하세요.

시작하기
----

사용 사례나 [SDK에](https://www.pubnub.com/docs) 관계없이 [PubNub 문서를](https://www.pubnub.com/docs) 통해 바로 시작하고 실행할 수 있습니다.