socket.io를 써보자

그 전에 설명하는 배경

참고 : http://bcho.tistory.com/896

참고 : http://blog.naver.com/musasin84/60190946052

웹 소켓의 등장 배경

초창기 웹은 콘텐츠를 전달하는 역할만을 수행했다. 그래서 초창기 CERN과 같은 연구기관에서 사용했던 것과 같은 전형적인 브라우저 랜덩링 방식인 HTTP 요청에 대한 HTTP 응답을 받아서 브라우저의 화면을 모두 지우고 받은 내용을 새로 표시하는 방식을 사용해도 문제가 없었다.

하지만 Ajax와 같이 사용자와 긴밀히 상호작용하는 RIA(Rich Internet Application)와 같은 웹 서비스가 발달하면서 웹 소켓이 등장하게 되었다. 이러한 방식은 숨겨진 프레임(Hidden Frame)을 이용하거나 Long Polling, Stream 등의 방법을 사용했다. 이는 브라우저가 HTTP 요청을 보내고 웹 서버가 이 요청에 대해서 웹 서버가 HTTP 응답을 보내는 단방향의 메시지 교환 방식을 유지하는 선에서 구현되는 방식이다. 이것은 기존의 방법에 일종의 트릭을 사용한 방법이기 때문에 기존의 웹 기술을 이용하여 실시간 웹 서비스를 만드는 일은 복잡하고 어려웠다.

이러한 불편함을 해소하고 사용자와 서버가 긴밀히 상호작용하는 웹 페이지를 만들기 위해 자유로운 양방향 메시지 송수신 방법으로서 HTML5 표준안의 일부인 웹 소켓 API가 등장했다. 하지만 아직까지 웹 소켓 프로토콜은 확정된 상태가 아니다.

일반적인 웹 푸쉬 방식은 클라이언트에서 서버로 요청을 보내면 서버가 응답을 하는 단방향성 통신이다. 이것이 Polling 방식이다.

하지만 채팅과 같은 실시간 양방향 어플리케이션을 구현하기 위해 Long Poll과 Streaming 같이 단방향 통신에서 양방향 통신을 구현하는 기법이 생겼다.

Polling

클라이언트는 서버에 주기적으로 Polling(request를 보내는 기법)한다. 즉, 클라이언트는 주기적으로 자신이 처리해야할 이벤트가 있는지 없는지 체크한다. 

Polling 주기가 10분 일 때 클라이언트는 10분마다 서버의 DB를 쿼리해야한다. 또한 Polling 이후에 바로 이벤트가 들어왔을 경우 다음 Polling까지 대기해야 한다. 그래서 Polling 주기가 길수록 서버에 부하는 덜 가지만 푸쉬 메시지의 실시간성은 보장할 수가 없다. 반대로 주기가 짧을수록 실시간성을 주기가 길 때에 비해서 실시간성을 더 많이 보장할 수 있지만 서버에는 기하급수적인 부하가 간다. 그래서 Pollign 방식을 사용할 때는 클라이언트로 보내는 푸쉬 메시지의 실시간성이 필요하지 않는 경우에 사용한다. 서버의 관점에서는 보통 Polling 주기를 길게 설정하기 때문에 서버의 부하가 상대적으로 적다. 또한 기존의 웹백엔드 인프라 (Tomact과 같은 미들웨어)를 그대로 활용할 수 있는 장점이 있다.

Long Polling

Polling 과 다르게 즉시성을 갖는다. HTTP Request를 보내고 rerquest를 일정시간 동안 열어 놓는다. 서버에서 클라이언트로 보내는 메시지가 있으면 HTTP Response로 실어 보내고 해당 connection을 끊는다. 일정 시간 도안 보낼 메시지가 없는 경우에도 HTTP 연결을 끊는다.

연결이 끊어지면 바로 재연결을 한다. 이 때 클라이언트가 서버에 연결해서 응답을 요청하는 방식이 Polling의 형태이고 Response를 기다리는 시간이 길기 때문에 이런 방식의 웹 푸쉬를 Long Polling이라고 한다. 

Long Polling은 이렇게 클라이언트가 서버에 항상 연결되어 있기 때문에 서버에 연결 가능한 클라이언트의 수는 서버에서 지원 가능한 최대 동시 연결자 수에 따라서 결정된다. 

단, 이 방법은 서버가 푸쉬 메시지를 받으면 연결을 다시 해야되기 때문에 클라이언트가 푸쉬하는 내용이 적은 경우에 사용한다. 그래서 실시간 채팅과 같이 푸쉬해야 하는 메시지의 양이 많은 경우에는 사용하지 않는다.

Streaming

일반적인 TCP Connection 처럼 클라이언트가 서버와 연결을 맺은 후에 이 연결을 통해 서버가 이벤트를 보내는 방시기다. 한 번 연결된 것을 계속 사용하기 때문에 Long Polling과 다르게 재연결에 대한 부하가 없다.

WebSocket

HTML5 표준 기술. Polling, Long Polling, Streaming을 AJAX로 구현하니 구현 방식이 브라우저마다 차이가 발생했다. http:// 대신 ws://로 시작하는 주소를 가지며 Streaming과 유사한 방식으로 푸쉬를 지원한다.

API는 W3C에서, 프로토콜은 IETF(Internet Engineering Tas Force)에서 관리하고 있다. 웹 소켓은 HTTP와 같은 80번 포트를 사용하고 있는데, 이런 이유 때문에 클라이언트의 웹 브라우저와 서버의 웹 서버도 웹 소켓의 기능을 지원해야 한다.

socket.io

socket.io 모듈은 WebSocket을 지원함과 동시에 WebSocket을 지원하지 않는 브라우저에 대해서는 AJAX Long Polling, MultiPart Streaming, Iframe을 이용한 푸쉬와 JSON Polling, Flash Socket 등의 방법을 사용해 푸쉬 메시지를 일관되게 보내는 것을 지원한다.