본문 바로가기
IT

[Web] 웹 소켓(Web Socket)란? (특징, 동작 과정, 사용 사례, 롱 폴링(LongPolling)과 차이점)

by 유나니나노 2024. 4. 10.
반응형

 

웹 소켓(Web Socket)은 웹 상에서 두 프로그램이 양방향 통신을 할 수 있게 해주는 고급 기술입니다. 즉, 클라이언트와 서버 간에 지속적인 연결을 유지하며 양방향 통신을 가능하게 합니다. 이는 웹 개발에서 실시간 애플리케이션을 구현할 때 매우 유용하며, 채팅 앱, 실시간 게임, 실시간 정보 업데이트가 필요한 서비스 등에 널리 사용됩니다.

 

특징

  • 양방향 통신: 웹 소켓은 서버와 클러이언트가 서로에게 데이터를 주고받을 수 있는 양방향 통신 채널을 제공합니다. 이는 기존의 HTTP 통신 방식과 달리, 서버도 클라이언트에게 직접 데이터를 데이터를 보낼 수 있게 해줍니다.
  • 실시간성: 지속적인 연결을 통해 데이터가 거의 실시간으로 전송됩니다. 이는 웹 애플리케이션에서 실시간으로 정보를 교환해야 하는 경우 매우 유용합니다.
  • 효율성: 웹 소켓 연결은 초기 핸드셰이크(handshake)를 통해 한 번만 설정되며, 이후 동일한 연결을 유지하면서 데이터를 교환합니다. 따라서, 전통적인 HTTP 통신에 비해 헤더 정보가 적어 오버헤드가 줄어들고 통신이 더 효율적입니다.
  • 호환성: 웹 소켓은 대부분의 최신 웹 브라우저에서 지원됩니다. 이는 웹 기반 애플리케이션에서 널리 사용될 수 있음을 의미합니다.
  • 표준화: 웹 소켓은 IETF(Internet Engineering Task Force)에 의해 RFC 6455로 표준화되었습니다. 이는 개발자들이 안정적이고 일관된 방식으로 웹 소켓을 구현할 수 있게 해 줍니다.

 

동작 과정

*간략히

  1. 클라이언트가 서버에 웹 소켓 연결을 요청합니다.(이 과정을 handshake라고 합니다.)
  2. 서버가 이 요청을 수락하면, 클라이언트와 서버 간에 웹 소켓 연결이 설정됩니다.
  3. 이 연결을 통해 클라이언트와 서버는 서로 데이터를 주고받을 수 있습니다.
  4. 어느 한쪽이 연결을 종료하기 전까지 이 양방향 통신 채널이 유지됩니다.

 

1. 핸드셰이크(Handshake)

  • 클라이언트 요청: 웹 소켓 연결 과정은 클라이언트(웹 브라우저 등)가 서버에 웹 소켓 연결을 요청하는 것으로 시작됩니다. 이때, 클라이언트는 HTTP 프로토콜을 사용하여 Upgrade 헤더를 포함한 요청을 보냅니다. 이 헤더는 클라이언트가 현재의 HTTP 연결을 웹 소켓 연결로 업그레이드하고자 함을 나타냅니다.
  • 서버 응답: 서버는 이 요청을 받고 웹 소켓 연결을 지원하는 경우, 101 Switching Protocols 상태 코드와 함께 Upgrade: websocket 헤더를 응답으로 보냅니다. 이로써 클라이언트와 서버 간의 웹 소켓 연결이 성립됩니다.

2. 데이터 전송

  • 연결 성립 후: 핸드셰이크 과정을 통해 성공적으로 웹 소켓 연결이 성립되면, 클라이언트와 서버는 이 연결을 통해 양방향으로 데이터를 주고받을 수 있게 됩니다. 데이터는 프레임(Frame) 단위로 전송되며, 이는 메시지를 작은 단위로 나누어 보내는 방식을 말합니다.
  • 데이터 형식: 전송되는 데이터는 텍스트(문자열) 또는 바이너리(이진 데이터) 형식일 수 있으며, 웹 소켓 프로토콜은 이 두 가지 유형의 데이터 전송을 모두 지원합니다.

3. 지속적인 통신

  • 실시간 통신: 웹 소켓 연결이 유지되는 동안, 클라이언트와 서버는 필요할 때마다 언제든지 데이터를 주고받을 수 있습니다. 이는 채팅 애플리케이션, 실시간 게임, 실시간 데이터 피드 등에서 매우 유용합니다.

4. 연결 종료

  • 종료 요청: 클라이언트 또는 서버 어느 한쪽이 연결을 종료하고자 할 때, 연결 종료 요청을 보냅니다. 웹 소켓 프로토콜은 연결을 정상적으로 종료하기 위한 절차를 정의하고 있으며, 이는 데이터 손실 없이 깔끔한 연결 종료를 보장합니다.
  • 연결 해제: 연결 종료 요청이 수락되면, 클라이언트와 서버 간의 웹 소켓 연결이 해제됩니다. 이후 같은 클라이언트와 서버 간에 다시 통신을 하고자 한다면, 새로운 연결 과정을 거쳐야 합니다.

 

사용 사례

  1. 채팅 애플리케이션: 웹 소켓은 실시간 채팅 애플리케이션에 특히 많이 사용됩니다. 사용자 간의 메시지가 거의 실시간으로 전송되어야 하기 때문에, 웹 소켓은 이러한 요구 사항을 충족시키는 이상적인 기술입니다. Slack, WhatsApp 웹 버전 등이 이에 해당합니다.
  2. 온라인 게임: 웹 소켓은 멀티플레이어 온라인 게임에서도 널리 사용됩니다. 플레이어의 움직임, 게임 상태의 변화 등이 실시간으로 다른 플레이어에게 전달되어야 하므로, 웹 소켓이 이를 가능하게 합니다.
  3. 금융 거래: 주식, 외환, 암호화폐 거래 플랫폼에서도 웹 소켓이 사용됩니다. 실시간으로 변하는 시장 가격 정보, 거래 주문 등을 사용자에게 전달해야 하므로, 웹 소켓이 중요한 역할을 합니다. 예를 들어, 사용자는 웹 소켓을 통해 거의 실시간으로 가격 변동을 확인하고 즉각적인 거래 결정을 내릴 수 있습니다.
  4. 실시간 알림 시스템: 소셜 미디어 플랫폼, 이메일 클라이언트, 고객 지원 시스템 등에서 실시간 알림 기능을 구현할 때 웹 소켓을 사용할 수 있습니다. 사용자가 중요한 업데이트나 메시지를 즉시 받아볼 수 있도록 해줍니다.
  5. 협업 도구: 구글 문서 도구(Google Docs)와 같은 실시간 협업 편집 도구에서도 웹 소켓이 필수적입니다. 여러 사용자가 동시에 문서를 편집할 때, 각각의 변경 사항이 실시간으로 다른 사용자에게 반영되어야 합니다.
  6. 위치 기반 서비스: 실시간 위치 추적을 필요로 하는 애플리케이션, 예를 들어 라이드 셰어링 서비스(Uber, Lyft 등)에서도 웹 소켓이 사용됩니다. 운전자와 승객의 위치를 실시간으로 상호교환하여, 서로의 위치를 지도 위에 실시간으로 표시할 수 있습니다.

*롱 폴링(Long Polling)

  • 롱 폴링은 웹 애플리케이션에서 서버로부터 실시간으로 데이터를 받아오기 위한 한 가지 방법으로, 폴링(polling)의 일종입니다. 클라이언트가 서버에 요청을 보내고, 서버에 새로운 데이터가 있을 때까지 서버가 응답을 지연시키는 방식입니다. 새로운 데이터가 준비되면, 서버는 그 데이터를 클라이언트에게 전송하고 연결을 종료합니다. 클라이언트는 응답을 받은 후 즉시 다음 요청을 보내어 연결을 유지합니다. 이 방식을 서버로부터 새로운 데이터를 수신할 때까지 대기하므로, 웹 소켓에 비해 효율이 떨어질 수 있습니다.

차이점

  • 연결 유지: 웹 소켓은 연결을 한 번 맺은 후 지속적으로 유지되는 반면, 롱 폴링은 요청마다 서버와의 연결을 재설정해야 합니다.
  • 통신 방식: 웹 소켓은 양방향 통신을 지원하여 서버와 클라이언트가 동시에 데이터를 주고받을 수 있지만, 롱 폴링은 클라이언트가 요청을 보낸 후 서버의 응답을 기다리는 단방향 통신입니다.
  • 리소스 사용: 웹 소켓은 연결이 지속되는 동안 리소스를 효율적으로 사용하지만, 롱 폴링은 반복적인 요청으로 인해 리소스 사용이 더 많을 수 있습니다.
  • 실시간 성능: 웹 소켓은 실시간 통신에 최적화되어 있어 롱 폴링에 비해 더 빠르고 효율적입니다.

 

웹 소켓이 아닌 롱 폴링 사용 이유

  1. 호환성: 웹 소켓은 비교적 최신의 기술이며, 모든 웹 브라우저나 환경에서 지원되지 않을 수 있습니다. 특히 구형 브라우저나 특정 제한적인 네트워크 환경에서는 웹 소켓을 제대로 지원하지 않을 수 있습니다. 반면, 롱 폴링은 HTTP 요청을 기반으로 하기 때문에 거의 모든 웹 환경에서 호환됩니다.
  2. 구현의 단순성: 롱 폴링은 전통적인 HTTP 요청/응답 패턴을 사용하기 때문에 개발자들이 이미 익숙한 패턴을 따릅니다. 따라서 복잡한 실시간 애플리케이션이 아니라면, 롱 폴링을 사용하여 빠르고 간단하게 구현하는 것이 가능합니다. 반면, 웹 소켓을 새로운 프로토콜과 API를 학습해야 하며, 구현이 더 복잡할 수 있습니다.
  3. 서버 부하 관리: 롱 폴링은 서버에 동시에 유지되는 연결 수가 상대적으로 적기 때문에, 서버의 부하를 더 쉽게 관리할 수 있습니다. 웹 소켓은 지속적인 연결을 유지하므로, 대규모 사용자를 지원하기 위해서는 서버의 연결 관리와 리소스 할당에 더 많은 주의가 필요합니다.
  4. 방화벽 및 프록시 호환성: 일부 네트워크 환경에서는 방화벽이나 프록시 서버가 웹 소켓 연결을 차단하거나 제한할 수 있습니다. HTTP 기반의 롱 폴링은 이러한 네트워크 제한을 우회하기 쉽기 때문에, 일부 환경에서는 롱 폴링이 더 안정적인 통신이 될 수 있습니다.
  5. 기술 스택과의 호환성: 어떤 경우에는 사용 중인 웹 서버나 백엔드 프레임워크가 웹 소켓을 직접 지원하지 않거나, 웹 소켓을 효율적으로 사용하기 위한 추가적인 설정이나 리소스가 필요할 수 있습니다. 이러한 상황에서 개발 팀은 기존 인프라와 더 잘 호환되는 롱 폴링을 선택할 수 있습니다.

 

오늘은 웹 소켓에 대해서 알아보았습니다.

채팅 애플리케이션 관련해서 MQTT와 Firebase도 함께 알아두시면 좋습니다!

2024.04.17 - [IT] - [MQTT] MQTT란? (개념, 특징, 장단점, 사용 사례)

 

[MQTT] MQTT란? (개념, 특징, 장단점, 사용 사례)

MQTT (Message Queuing Telemetry Transport)는 경량의 메시징 프로토콜로, IoT(Internet of Things) 기기 간의 효율적이고 간단한 메시지 교환을 목적으로 설계되었습니다. 199년 IBM에 의해 개발되었으며, 네트워크

yuna-ninano.tistory.com

2024.04.22 - [IT] - [FCM] Firebase Cloud Messaging이란? (개념, 특징, 작동 과정, 사용 사례, 고려 사항)

 

[FCM] Firebase Cloud Messaging이란? (개념, 특징, 작동 과정, 사용 사례, 고려 사항)

FCM(Firebase Cloud Messaging)은 구글이 제공하는 클라우드 기반의 메시징 서비스입니다. 이 서비스를 통해 개발자는 웹, 안드로이드, iOS 등 다양한 플랫폼에서 사용자의 디바이스로 메시지를 무료로

yuna-ninano.tistory.com

반응형