[WEB] Polling과 WebSocket (... socket.io)

socket.io라는 것을 학습해보면서 polling이라는 단어를 접했다. 예전에 들어봤지만 정확한 개념을 알지 못하고 각각 어떤 차이가 있는지 몰랐기에 적어두려고 한다.

 

 기존의 HTTP 프로토콜 

HTTP규격은 애초에 클라이언트에서 서버로의 단방향 통신을 위해 만들어진 방법이다. 이렇기에 클라이언트의 요청이 있어야만 서버가 응답을 할 수가 있고 반대로  서버가 먼저 보내는 요청은 클라이언트가 받을 수 없다. 이는 웹이 발전하면서 다양한 콘텐츠에서 단점으로 작용한다.

이러한 단점을 보완하기 위해 일반적인 HTTP request에 약간의 트릭을 사용해 실시간 통신인 것처럼 작동하는 기술이 Polling이다.

 

 

 Polling 

Polling은 클라이언트 측에서 일정 시간을 두고 request를 계속해서 보내면서 받을 게 잇는지 확인하는 방법이다.

장점으로는 구현하기가 쉽다는 점이 있다. 단점으로는 서버 측에서 응답해줄 내용이 없어도 클라이언트는 알 수 없기 때문에 계속해서 request를 보내 확인해야 되며 연결과 해제 과정에서 계속된 handshake는 서버 측에 부담이 되며 병목현상을 야기한다. 이를 개선하기 위한 기술이 Long Polling이다.

 

 

 Long Polling 

클라이언트 측에서 서버로 request를 보내면 서버는 시간을 두고 기다린다. 그 후 만약 서버에서 해당 클라이언트에게 응답할 이벤트가 있다면 response를 전달하고 연결이 종료된다. 이때 클라이언트는 pending 상태로 대기하다가 서버로부터 응답이 오면 다시 request를 보내 다음 이벤트를 기다린다.

이러한 방식은 polling방식보다는 서버의 부담이 줄 수는 있지만 만약 클라이언트로 보내는 이벤트가 빈번하게 발생한다면 polling방식과 큰 차이가 없어지게 된다.

 

 

 Streaming 

Streaming은 Polling방식의 단점을 개선한 또 다른 방법이다.

클라이언트가 request를 보내면 서버에서 이벤트를 전달할 때 해당 요청을 끊지 않고 계속해서 응답을 보내는 방식이다. 클라이언트가 서버에 다른 request를 보내고 싶다면 새로운 커넥션을 맺어야 한다.

 

위의 방법들은 단방향 통신을 이용해 마치 양방향이 통신하는 것처럼 보이지만 클라이언트 측에서 요청을 보낼 시에는 많은 불편이 있을 것 같다.

단방향의 틀에서 벗어나 양방향 통신이 가능하게 하기 위해서 HTML5 표준의 일부로 webSocket이 만들어졌다고 한다.

 

 

 WebSocket 

webSocket은 클라이언트와 서버 사이의 동적인 양방향 연결 채널을 구성하는 프로토콜이다.

동작은 최초 통신 시 일반 HTTP request를 통해 연결을 확립하며, 그 후의 통신은 webSocket 독자의 프로토콜로 이어간다. 즉 하나의 커넥션으로 데이터 송수신이 가능하다.

header가 상당히 작아 overhead가 적다는 특징이 있다. 또한 HTTP request를 그대로 사용하기 때문에 기존의 80, 433 포트로 접속을 하므로 추가로 방화벽을 열지 않고도 양방향 통신이 가능하며 HTTP 구격인 CORS적용이나 인증 등의 과정을 기존과 동일하게 가져갈 수 있다는 장점이 있다.

 

하지만 webSocket은 HTML5의 기술이기 때문에 오래된 버전의 웹 브라우저에서는 지원하지 않는다고 한다.

이를 해결하기 위해 고안된 기술 중 하나가 socket.io라고 한다.

 

 

 socket.io 

socket.io는 JavaScript로 작성된 Node.JS 모듈이다.

webSocket이 지원되지 않는 브라우저에서도 양방향과 같은 통신이 가능하게 하도록 해주는 기술 중 하나이다.

웹페이지가 열리는 브라우저가 webSocket을 지원한다면 webSocket방식으로 통신을 이어가고, 만약 지원하지 않는 브라우저라면 일반적인 HTTP를 이용한 Polling방식을 통신으로 양방향 통신을 흉내 내준다.

Socket.IO