PubNub Developer Relations웹 애플리케이션은 처음에 클라이언트-서버 아키텍처로 설계되었습니다. 클라이언트는 특정 정보를 요청하거나 수정하기 위해 지정된 서버에 HTTP/HTTPS 요청을 생성합니다. 예를 들어, 기본 웹 애플리케이션은 비슷한 흐름을 따릅니다.
클라이언트가 서버에 데이터를 요청합니다.
로드 밸런서가 요청을 적절한 서버로 라우팅합니다.
서버가 해당 데이터베이스에 일부 데이터를 쿼리합니다.
데이터베이스가 쿼리된 데이터를 서버로 반환합니다.
서버가 데이터를 처리하여 클라이언트로 데이터를 다시 보냅니다.
간단한 HTTP 요청은 서버 정보를 받는 가장 일반적인 방법입니다. 하지만 데이터가 데이터베이스에 추가되거나 서버로 전송되는 즉시 데이터를 다시 받고 싶다면 어떻게 해야 할까요? 클라이언트-서버 아키텍처로 설계된 기본 웹 애플리케이션에서는 데이터베이스에 새로운 정보가 추가되었는지 확인하기 위해 이 프로세스를 계속해서 반복해야 합니다. 이 프로세스를 폴링 또는 짧은 폴링이라고도 합니다. 이 접근 방식의 단점은 서버가 새로운 정보를 수신하지 않았기 때문에 대부분의 경우 데이터가 반환되지 않는다는 것입니다. 이 문제를 해결하고 롱 폴링과 웹소켓의 장단점에 대해 논의해 보겠습니다.
개요: 롱 폴링과 웹소켓 비교
롱 폴링
롱 폴링은 접근 방식 으로, 클라이언트가 서버에 API 요청을 보내지만 서버로부터 즉각적인 응답을 받는 대신 HTTP 연결을 유지하는 방식입니다. HTTP 연결을 유지하면 나중에 데이터를 사용할 수 있게 되거나 시간 초과 임계값에 도달했을 때 서버가 응답할 수 있습니다. 응답을 받은 클라이언트는 즉시 후속 요청을 보냅니다.
폴링에서처럼 서버가 새로운 정보를 수신할 때까지 여러 요청을 반복해서 보내는 대신, 클라이언트는 서버에 한 번의 요청만 보내면 최신 정보를 얻을 수 있습니다. 데이터를 수신한 후 클라이언트는 새 요청을 시작하여 이 과정을 필요한 만큼 반복할 수 있습니다.
롱 폴링의 흐름은 다음과 같습니다:
클라이언트 측에서 서버에 일부 데이터를 요청하는 HTTP 요청을 합니다.
서버는 요청된 정보에 즉시 응답하지 않고 새로운 정보를 사용할 수 있을 때까지 기다립니다.
새로운 데이터를 사용할 수 있게 되면 서버는 새로운 정보로 응답합니다.
클라이언트는 해당 데이터를 수신하고 즉시 서버에 다른 요청을 전송하여 프로세스를 다시 시작합니다.
웹 소켓
웹 소켓은 최신 기술 최신 기술입니다. HTTP 프로토콜과의 유일한 관계는 HTTP 서버가 핸드셰이크를 해석하여 연결을 설정한다는 점입니다. 이 프로토콜은 양방향입니다, 전이중 프로토콜로, 클라이언트와 서버 간의 연결은 어느 한쪽이 연결을 종료하기로 결정할 때까지 지속됩니다.
반이중 솔루션에 불과한 롱 폴링과 달리 서버로부터 최신 정보를 수신한 후에도 프로세스를 반복할 필요가 없습니다. 웹소켓 기술을 사용하면 새 정보가 반환된 후에도 연결을 유지하고 양방향 업데이트를 수행할 수 있습니다. 클라이언트는 동일한 요청으로 정보를 서버로 다시 전송하고 추가 정보를 수신할 수 있습니다.
웹소켓 연결 흐름은 다음과 같습니다:
클라이언트 측에서 통신 프로토콜을 웹소켓 프로토콜로 전환하기 위해 업그레이드 헤더가 포함된 요청을 전송하여 웹소켓을 시작합니다.
서버가 연결을 설정할 수 있고 클라이언트의 조건에 동의하는 경우, 서버는 웹소켓 핸드셰이크 요청을 승인하는 응답을 클라이언트에 보냅니다.
클라이언트가 WebSocket 연결에 성공하면 이제 클라이언트와 서버는 양방향 데이터 전송을 시작하여 실시간 통신을 할 수 있습니다.
서버 또는 클라이언트가 연결 종료를 결정합니다.
롱 폴링과 웹소켓 중 언제 선택해야 할까?
롱 폴링 또는 웹소켓 프로토콜을 언제 사용할지에 대한 논쟁이 있습니다. 둘 다 장점과 한계가 있으며 종종 다른 용도로 사용됩니다. 이 섹션에서는 롱 폴링과 웹소켓의 주요 이점에 대해 설명합니다.
롱 폴링과 웹소켓의 장점
호환성: 롱 폴링은 더 오래 전부터 사용되어 온 기술이기 때문에 웹소켓보다 호환성이 높은 옵션입니다. 이는 다음을 기반으로 구축됩니다. XMLHttpRequest를 기반으로 구축되어 더 광범위한 웹 브라우저 및 네트워크 구성과 호환됩니다.
네트워크: 오늘날의 기술로 인해 사람들은 3G에서 LTE, WiFi로 끊임없이 네트워크를 전환합니다. 네트워크 연결의 변화에 적응할 수 있도록 웹소켓을 구성해야 합니다. 이 구성은 서버와의 연결을 다시 설정해야 하며 클라이언트가 연결을 닫도록 선택한 후에는 연결을 되살릴 수 없기 때문입니다. 롱 폴링을 사용하면 미리 정해진 시간(보통 20초) 후에 클라이언트가 서버와의 연결을 자동으로 다시 설정하는 다른 요청을 보내도록 설정되므로 문제가 되지 않으며, 웹소켓과 같이 오류 상태로 처리할 필요가 없습니다.
웹 소켓보다 긴 폴링을 선택하는 사용 사례
롱 폴링과 WebSocket은 일반적으로 실시간 업데이트가 필요한 경우에 사용됩니다. 인앱 채팅, 실시간 가격 책정, 위치 추적, IoT 등이 그 예입니다.
롱 폴링은 실시간 업데이트 빈도가 낮은 사용 사례에서 웹소켓보다 이점을 제공합니다. 롱 폴링은 연결을 다시 설정해야 하는 반실시간 솔루션이기 때문에 이러한 이점이 있습니다. 또한 위에서 언급했듯이 사용자가 대역폭이 낮거나 네트워크 공급자가 불안정한 환경에 있는 경우, 롱 폴링은 추가적인 문제 없이 연결을 다시 설정하도록 설계되어 있습니다. 그러나 롱 폴링은 실시간 업데이트를 수행하기 위한 오래된 기술/기법입니다. 따라서 웹소켓보다 덜 발전되고 유연성이 떨어지지만 레거시 시스템에 대한 지원은 더 많습니다.
웹소켓과 롱 폴링을 선택해야 하는 경우
웹 소켓과 롱 폴링의 장점 비교
리소스 사용률 감소: 웹소켓은 클라이언트와 서버 간의 연결을 영구적으로 유지하므로 실시간 업데이트를 할 때마다 새 연결을 설정하는 데 드는 오버헤드가 줄어듭니다. 지속적인 연결은 네트워크 대역폭, 메모리, CPU와 관련된 클라이언트 및 서버 측의 리소스 사용률을 줄여 실시간 통신을 가능하게 합니다.
확장성 향상: 클라이언트와 서버 간의 양방향 통신을 지원하는 웹소켓의 특성상 서버가 실시간으로 클라이언트에 업데이트를 푸시할 수 있어 전송되는 요청 횟수를 줄일 수 있습니다. 긴 폴링은 클라이언트가 새로운 정보를 필요로 할 때마다 연결을 다시 설정해야 합니다. 사용자 기반이 확장됨에 따라 개별 서버에 많은 부담을 줄 수 있습니다.
고급 기능: 웹소켓은 실시간 데이터 전송과 짧은 지연 시간을 실현하는 전이중 통신 채널을 제공합니다. 롱 폴링은 반실시간 솔루션에 불과하며 트래픽이 많은 시나리오나 실시간 업데이트가 필요한 사용 사례에는 적합하지 않은 경우가 있습니다. 고급 기능을 사용하면 애플리케이션에 대한 보다 원활한 업데이트를 받을 수 있으므로 최종 사용자 경험이 더욱 원활해집니다.
긴 폴링 대신 WebSocket을 선택해야 하는 사용 사례
웹소켓은 빈번한 업데이트가 필요한 애플리케이션에 더 적합합니다. 예를 들면 다음과 같습니다. 채팅 애플리케이션 또는 실시간 데이터 피드. 영구 연결은 효율적인 전송을 가능하게 하여 최종 사용자에게 보다 원활한 경험을 제공합니다. 멀티플레이어 게임과 협업 도구도 일반적으로 웹소켓을 사용합니다. 양방향 양방향 통신을 통해 서버는 클라이언트에 신호를 보낼 수 있으며, 이는 다른 클라이언트로부터 실시간 업데이트를 수신하는 데 유용할 수 있습니다. 예를 들어, 서버는 클라이언트에 신호를 보내 다른 플레이어의 행동에 따라 위치를 업데이트하도록 지시할 수 있습니다.
확장성 측면에서 또는 사용자 기반이 확장되기 시작할 때 웹소켓 프로토콜로 전환하는 것이 이상적입니다. 클라이언트 기반이 긴 폴링 기술을 사용하는 경우 개별 서버에 가해지는 부담이 너무 커집니다. 20초마다 요청을 전송하면 활용도가 떨어지고 시간이 지남에 따라 서버 속도가 느려져 지연 시간 를 증가시킵니다.
긴 폴링과 웹소켓을 비교했을 때 PubNub가 적합한 방법
웹소켓과 롱 폴링은 실시간 애플리케이션을 만드는 데 유용한 솔루션을 제공합니다. 그러나 이러한 사용 사례를 구축할 때는 다른 많은 고려 사항이 필요합니다. 오늘날의 기술로는 한 클라이언트에서 다른 클라이언트로 메시지나 데이터를 전송하는 것만큼 간단한 일은 없습니다. 개발자가 만들고자 하는 실시간 시스템에는 거의 항상 필요한 기능이 있습니다. 예를 들어, 인앱 채팅에서는 사용자가 온라인 상태일 때 현재 상태 업데이트(시그널링), 욕설 필터링, 메시지 읽기/전달 등의 기능을 사용할 수 있습니다.
특정 기능을 추가하는 것 외에도 확장성 처리의 복잡성 등 기본 인프라에 대한 문제도 여전히 존재합니다. 다음과 같은 특정 기술을 사용하는 경우 Socket.io 와 같은 특정 기술을 사용하여 웹소켓을 생성하는 경우, 개발자는 각 서버의 사용률을 관리하기 위해 로드 밸런서 뒤에서 전 세계의 서버를 동적으로 생성하는 작업을 여전히 처리해야 합니다. 이러한 문제는 규모를 확장할수록 점점 더 복잡해집니다.
PubNub의 실시간 데이터 API를 사용하면 특정 사용 사례에 관계없이 모든 기기에서 실시간 커뮤니케이션을 촉진하는 강력한 이벤트 기반 애플리케이션을 개발할 수 있습니다. PubNub은 웹 애플리케이션을 위한 JavaScript SDK와 IoT 애플리케이션을 위한 C-Core SDK 등 다양한 SDK를 제공하여 선택한 디바이스와의 원활한 통합을 보장합니다. PubNub을 사용하면 적합한 대안을 선택하거나 실시간 솔루션 구현의 근본적인 복잡성에 대해 걱정할 필요가 없습니다.
이제 언제 롱 폴링을 사용해야 하는지, 웹소켓을 사용해야 하는지 이해하셨으니 무료 평가판에 등록하세요 또는 데모 예약 에 등록하거나 데모를 예약하여 PubNub로 무엇을 구축할 수 있는지 살펴보세요.
펍넙이 어떤 도움이 될까요?
이 문서는 원래 PubNub.com에 게시되었습니다.
저희 플랫폼은 개발자가 웹 앱, 모바일 앱 및 IoT 기기를 위한 실시간 인터랙티브를 구축, 제공 및 관리할 수 있도록 지원합니다.
저희 플랫폼의 기반은 업계에서 가장 크고 확장성이 뛰어난 실시간 에지 메시징 네트워크입니다. 전 세계 15개 이상의 PoP가 8억 명의 월간 활성 사용자를 지원하고 99.999%의 안정성을 제공하므로 중단, 동시 접속자 수 제한, 트래픽 급증으로 인한 지연 시간 문제를 걱정할 필요가 없습니다.
PubNub 체험하기
라이브 투어를 통해 5분 이내에 모든 PubNub 기반 앱의 필수 개념을 이해하세요.
설정하기
PubNub 계정에 가입하여 PubNub 키에 무료로 즉시 액세스하세요.
시작하기
사용 사례나 SDK에 관계없이 PubNub 문서를 통해 바로 시작하고 실행할 수 있습니다.
