[양방향 통신 방법] Polling vs WebSocket

기존의 양방향 통신 방법

HTML5 표준 기술인 웹소켓 방식 이전에는 마치 실시간인 것처럼 작동하게 하는 방법들이 있었다.

Polling(폴링)

클라이언트가 n초 간격으로 request를 서버로 계속 날려서 response를 전달받는 방식이다.

장점

• 비교적 구현이 쉽다. 

단점

• 서버측에서 보낼 내용이 없어도 클라이언트는 알 수 없기 때문에 계속해서 request를 통한 확인이 필요하다.
• HTTP는 단발성 통신이기 때문에 header가 매우 무거운 프로토콜 중 하나로 이 프로토콜이 계속해서 requeset를 날리면 서버의 부담이 증가한다.
• 초 간격을 늘린다면 실시간성이라고 보기 어렵다.

 

Long Polling(롱 폴링)

클라이언트의 요청에 대해 응답을 보내지 않고 timeout이 날 때까지 기다리다가, 이벤트가 발생했을때 응답을 리턴하는 방식이다.

클라이언트는 pending 상태로 대기하고 있다가 응답이 오면(연결이 떨어지면) 다시 연결하는 것을 반복한다.

장점

폴링 방식보다 서버의 부담이 줄어든다.

단점

데이터의 업데이트가 빈번해진다면 일반 폴링 방식과 큰 차이가 없다.

 

Streaming(스트리밍)

클라이언트가 request를 보내면 커넥션을 맺고, 이 커넥션을 유지하면서 서버가 계속 데이터를 보내는 방식이다. 클라이언트가 서버에 메시지를 보내고 싶다면 새로운 커넥션을 맺어야 한다.

 

WebSoket

웹소켓은 HTML5 표준 기술로, 사용자의 브라우저와 서버 사이의 동적인 양방향 연결 채널을 구성한다.

Websocket API를 통해 서버로 메세지를 보내고, 요청 없이 응답을 받아오는 것이 가능하다.

 

웹소켓은 매우 단순한 API로 구성이 되어있으며, 하나의 HTTP 접속으로 양방향 메시지를 자유롭게 주고받을 수 있다.

 

웹소켓 통신과 비교하면 XMLHttprequest에서는 통신할 때마다 요청 헤더가 부여되기 때문에 불과 1바이트의 정보를 송신하기 위한 경우에도 필요하지 않은 쓸데없는 정보를 보낸다. 예를 들어, 채팅 입력을 한 문자마다 서버에 송신하고 싶은 경우처럼, 실시간 추구한 애플리케이션에서는 이 점이 성능 차이로 이어질 가능성이 크다.

 

HTTP 통신방법과 WebSocket의 차이점

WebSocket 프로토콜은 접속 확입에 HTTP를 사용하지만, 그 후의 통신은 WS라는 프로토콜을 이용한다. header가 상당히 작아 overhead가 적다는 특징이 있다.

장시간 접속을 전제로 하기 대문에, 접속한 상태라면 클라이언트나 서버로부터 데이터 송신이 가능하다. 더불어 데이터의 송신과 수신에 각각 커넥션을 맺을 필요가 없어, 하나의 커넥션으로 데이터를 송수신할 수 있다.

 

WebSocket이 필요한 경우

• 실시간 양방향 데이터 통신이 필요한 경우
• 많은 수의 동시 접속자를 수용해야하는 경우
• 브라우저에서 TCP 기반의 통신으로 확장해야 하는 경우
• 개발자에게 사용하기 쉬운 API가 필요한 경우
• 클라우드 환경이나 웹을 넘어 SOA(Service Oriented Architecture)로 확장해야 하는 경우

 

 

---

Reference

[WEB] 🌐 웹 소켓 (Socket) 정리 (역사부터 차근차근)

Polling vs Websocket

WebSocket 개념과 장점, 그리고 왜 사용하는지 알아보자