source: http://thinkr.egloos.com/2488915
리얼타임 웹이란 무엇일까요? 웹의 기본 프로토콜인 HTTP 프로토콜을 기반으로 하여 그 위에 실시간성의 어떤 것들을 가미한 것이 리얼타임 웹이겠죠?
흔히 사용되는 기법 중 하나는 주기적으로 폴링(polling)을 하는 것입니다. 매 시간, 예를 들면 1분 간격으로 서버에 요청을보내고 다시 응답을 받고 하는 과정을 반복하면서 새로운 이벤트가 감지되면 응답에 실어 클라이언트 브라우저로 보내는 방법입니다.주로 Ajax 호출을 사용하기 때문에 흔히 Ajax Polling이라고도 부릅니다.
이 방법이 간단하긴 하지만 몇 가지 문제가 있습니다. 폴링 주기를 어떻게 주느냐에 따라 실시간성이 조금 떨어질 수 있고 또 폴링 주기를 짧게 가져갈수록 서버의 처리 부담이 커지는 문제가 대표적입니다.
그래서 나온 생각들이 웹 상에서 푸시(PUSH)를 구현하자는 것이고, 이렇게 웹 서버가 클라이언트 브라우저로 푸시하는 기법들을 총칭하여 'Comet'이라고 부릅니다.
Comet은 그 구현방법이 아주 다양합니다만, 크게 보면 스트리밍(Streaming) 방식과 롱폴링(Long Polling) 방식으로흔히 구별할 수 있습니다. 그 중 스트리밍 방식은 하나의 웹 요청에 대해 웹 접속(connection)을 계속 열어두고서, 새로무언가 이벤트가 발생하면 그 때 마다 부분적인 응답을 브라우저로 보내는 방식입니다.
다른 한 가지는 롱폴링(Long Polling)인데, 이 방식은 앞서 설명한 주기적 폴링과 비슷하지만, 서버 측에서 접속을열어두는 시간이 길다는 차이점이 있습니다. 왼쪽 그림에서 보면 노란색 선으로 표시된 부분이 서버의 접속 시간입니다. 앞서보여드린 주기적 폴링과 비교하면 확실히 접속 시간이 깁니다. 롱폴링에서는 이벤트가 발생하면 바로 응답이 이루어지기 때문에실시간성이 아주 높으며, 스트리밍 방식과 달리 웹 브라우저 환경에 관계없이 사용할 수 있기 때문에 흔히 사용되는 방식입니다.
Comet을 처리하는 서버는 Apache나 Tomcat 같은 통상적인 HTTP 서버 보다는 이벤트 기반 I/O를 사용하는 서버들이 성능상 유리합니다.
Comet이 총체적 개념이다 보니 다양한 구현체들이 존재할 수 밖에 없으며, 아직 어느 것이 어느 것보다 우수하다 아니다고 말하기에는조금 이른 상태입니다. 여기 소개한 구현기술들은 그 중 일부에 불과하며 보다 상세한 목록과 내용은 참고자료를 참고하면 됩니다
한 가지 유의할 점은 Comet의 구현은 서버측과 클라이언트측에서 동시에 이루어져야 하며, 어느 한 측만으로는 작동하지 않는다는 점입니다.
이 그림은 실제로 웹 애플리케이션 프레임워크와 함께 Comet을 통합할 경우 구성할 수 있는 시스템 아키텍처 중 하나입니다. 여기서는 파이썬의 Twisted 기반 Comet 구현체인 Orbited를 사용하고 있으며, 메시징 프로코톨로는 표준 프로토콜인 STOMP를 사용하여 MQ로 메시지를 처리합니다.
Comet과는 관계가 없지만, 흔히 리얼타임 처리에 사용되는 기법 중에 WebHook이라는 것이 있습니다. 이 방식은 몇 년 전PayPal에서 사용한 이후로 많은 웹 서비스들에서 사용하는 방식인데, 웹 요청이 서버로 들어오면 서버에서는 미리 지정해 둔별개의 URL(일종의 Callback입니다)로 POST 요청을 보냄으로써 실시간 통합을 처리할 수가 있습니다.
구글의 오픈소스 프로젝트 중 하나인 PubsubHubbub역시 이 기법에 기반하고 있으니, 관심있는 분들은 참고 바랍니다.
다음으로 소개할 기술은 XMPP입니다. XMPP는 HTTP 프로토콜과 동일한 수준의 프로토콜이며, HTTP와는 달리 XML 기반의연결지향 프로토콜입니다. XMPP는 Message, Presense, Iq라고 하는 세 가지 stanza로 주고 받는 모든메시지를 표시할 수 있는 확장성이 아주 높은 프로토콜입니다.
XMPP는 그 자체로도 방대한 내용을 가지고 있기 때문에 자세한 설명은 생략합니다.
XMPP는 원래 Jabber라는 이름으로 2001년에 처음 선보인 프로토콜이지만 더 유명해 진 것은 구글이 Google Talk에서자체적으로 구현한 XMPP를 웹에 적용하면서 부터입니다. 이후 Facebook의 채팅서비스, 최근의 구글 Wave 등에서도XMPP가 큰 몫을 차지하고 있습니다.
XMPP자체는 웹을 기반으로 하는 프로토콜이 아니기 때문에 웹과 연계하기 위해서는 별도의 기법들이 필요합니다. XMPP의 확장(XEP)중 BOSH라고 하는 표준 명세(spec)가 있는데, 이 명세에서 XMPP와 HTTP 간의 연계 방식을 규정해 두고 있습니다.
자세한 내용을 모두 설명드릴 순 없지만, 클라이언트와 XMPP 서버 간에 접속 관리자(CM)라는 일종의 프록시를 두어 패킷스위칭을 처리합니다. 서버에서 클라이언트 측으로 PUSH를 하기 때문에 BOSH 역시 일종의 Comet입니다.
리얼타임 웹의 구현 방법은 다양하며, 루비온레일스 기반 애플리케이션에서라면 Juggernaut 이라고 하는 플러그인을 사용하기도 합니다.
이 플러그인은 클라이언트측에서 플래시 socket 객체와 자바스크립트 코드를 사용하여 일종의 Comet을 구현합니다. Juggernaut은 EventMachine 기반의 자체적인 서버를 가집니다.
아주 아주 오래 전 웹 초창기부터 사용해 오던 방식으로는, 자바 애플릿이 있습니다. 애플릿에서는 소켓통신으로 서버와 연동을 하여리얼타임 웹을 구현하게 됩니다. 사실 오늘날의 자바가 있게 만든 일등공신인 애플릿은 지금도 여전히 많은 곳에서 사용되고 있는기술이기도 합니다.
어떻게 이 모든 것들이 따지고 보면 HTTP 프로토콜 자체가 연결이 없는(connectionless) 프로토콜이며, 브라우저에서 소켓과 같은 것을 지원하지 않기 때문에 생겨난 발명들이라 할 수 있습니다.
앞으로 나올 HTML5에서는 WebSocket이 적용됩니다. 아직 HTML5가 적용된 브라우저가 흔치 않은 탓에 현재로서는Comet을 사용하는 것이 가장 현실적인 대안이 아닐까 생각합니다만, 언젠가는 더 간단하고 편리한 세상이 오겠죠?
* 참고: Comet is dead long live websockets
================최신 동향===============
HTML5의 웹소켓을 통해 기존 stateless http protocol의 태생적 한계를 극복했음.
리얼타임 웹이란 무엇일까요? 웹의 기본 프로토콜인 HTTP 프로토콜을 기반으로 하여 그 위에 실시간성의 어떤 것들을 가미한 것이 리얼타임 웹이겠죠?
흔히 사용되는 기법 중 하나는 주기적으로 폴링(polling)을 하는 것입니다. 매 시간, 예를 들면 1분 간격으로 서버에 요청을보내고 다시 응답을 받고 하는 과정을 반복하면서 새로운 이벤트가 감지되면 응답에 실어 클라이언트 브라우저로 보내는 방법입니다.주로 Ajax 호출을 사용하기 때문에 흔히 Ajax Polling이라고도 부릅니다.
이 방법이 간단하긴 하지만 몇 가지 문제가 있습니다. 폴링 주기를 어떻게 주느냐에 따라 실시간성이 조금 떨어질 수 있고 또 폴링 주기를 짧게 가져갈수록 서버의 처리 부담이 커지는 문제가 대표적입니다.
그래서 나온 생각들이 웹 상에서 푸시(PUSH)를 구현하자는 것이고, 이렇게 웹 서버가 클라이언트 브라우저로 푸시하는 기법들을 총칭하여 'Comet'이라고 부릅니다.
Comet은 그 구현방법이 아주 다양합니다만, 크게 보면 스트리밍(Streaming) 방식과 롱폴링(Long Polling) 방식으로흔히 구별할 수 있습니다. 그 중 스트리밍 방식은 하나의 웹 요청에 대해 웹 접속(connection)을 계속 열어두고서, 새로무언가 이벤트가 발생하면 그 때 마다 부분적인 응답을 브라우저로 보내는 방식입니다.
다른 한 가지는 롱폴링(Long Polling)인데, 이 방식은 앞서 설명한 주기적 폴링과 비슷하지만, 서버 측에서 접속을열어두는 시간이 길다는 차이점이 있습니다. 왼쪽 그림에서 보면 노란색 선으로 표시된 부분이 서버의 접속 시간입니다. 앞서보여드린 주기적 폴링과 비교하면 확실히 접속 시간이 깁니다. 롱폴링에서는 이벤트가 발생하면 바로 응답이 이루어지기 때문에실시간성이 아주 높으며, 스트리밍 방식과 달리 웹 브라우저 환경에 관계없이 사용할 수 있기 때문에 흔히 사용되는 방식입니다.
Comet을 처리하는 서버는 Apache나 Tomcat 같은 통상적인 HTTP 서버 보다는 이벤트 기반 I/O를 사용하는 서버들이 성능상 유리합니다.
Comet이 총체적 개념이다 보니 다양한 구현체들이 존재할 수 밖에 없으며, 아직 어느 것이 어느 것보다 우수하다 아니다고 말하기에는조금 이른 상태입니다. 여기 소개한 구현기술들은 그 중 일부에 불과하며 보다 상세한 목록과 내용은 참고자료를 참고하면 됩니다
한 가지 유의할 점은 Comet의 구현은 서버측과 클라이언트측에서 동시에 이루어져야 하며, 어느 한 측만으로는 작동하지 않는다는 점입니다.
이 그림은 실제로 웹 애플리케이션 프레임워크와 함께 Comet을 통합할 경우 구성할 수 있는 시스템 아키텍처 중 하나입니다. 여기서는 파이썬의 Twisted 기반 Comet 구현체인 Orbited를 사용하고 있으며, 메시징 프로코톨로는 표준 프로토콜인 STOMP를 사용하여 MQ로 메시지를 처리합니다.
Comet과는 관계가 없지만, 흔히 리얼타임 처리에 사용되는 기법 중에 WebHook이라는 것이 있습니다. 이 방식은 몇 년 전PayPal에서 사용한 이후로 많은 웹 서비스들에서 사용하는 방식인데, 웹 요청이 서버로 들어오면 서버에서는 미리 지정해 둔별개의 URL(일종의 Callback입니다)로 POST 요청을 보냄으로써 실시간 통합을 처리할 수가 있습니다.
구글의 오픈소스 프로젝트 중 하나인 PubsubHubbub역시 이 기법에 기반하고 있으니, 관심있는 분들은 참고 바랍니다.
다음으로 소개할 기술은 XMPP입니다. XMPP는 HTTP 프로토콜과 동일한 수준의 프로토콜이며, HTTP와는 달리 XML 기반의연결지향 프로토콜입니다. XMPP는 Message, Presense, Iq라고 하는 세 가지 stanza로 주고 받는 모든메시지를 표시할 수 있는 확장성이 아주 높은 프로토콜입니다.
XMPP는 그 자체로도 방대한 내용을 가지고 있기 때문에 자세한 설명은 생략합니다.
XMPP는 원래 Jabber라는 이름으로 2001년에 처음 선보인 프로토콜이지만 더 유명해 진 것은 구글이 Google Talk에서자체적으로 구현한 XMPP를 웹에 적용하면서 부터입니다. 이후 Facebook의 채팅서비스, 최근의 구글 Wave 등에서도XMPP가 큰 몫을 차지하고 있습니다.
XMPP자체는 웹을 기반으로 하는 프로토콜이 아니기 때문에 웹과 연계하기 위해서는 별도의 기법들이 필요합니다. XMPP의 확장(XEP)중 BOSH라고 하는 표준 명세(spec)가 있는데, 이 명세에서 XMPP와 HTTP 간의 연계 방식을 규정해 두고 있습니다.
자세한 내용을 모두 설명드릴 순 없지만, 클라이언트와 XMPP 서버 간에 접속 관리자(CM)라는 일종의 프록시를 두어 패킷스위칭을 처리합니다. 서버에서 클라이언트 측으로 PUSH를 하기 때문에 BOSH 역시 일종의 Comet입니다.
리얼타임 웹의 구현 방법은 다양하며, 루비온레일스 기반 애플리케이션에서라면 Juggernaut 이라고 하는 플러그인을 사용하기도 합니다.
이 플러그인은 클라이언트측에서 플래시 socket 객체와 자바스크립트 코드를 사용하여 일종의 Comet을 구현합니다. Juggernaut은 EventMachine 기반의 자체적인 서버를 가집니다.
아주 아주 오래 전 웹 초창기부터 사용해 오던 방식으로는, 자바 애플릿이 있습니다. 애플릿에서는 소켓통신으로 서버와 연동을 하여리얼타임 웹을 구현하게 됩니다. 사실 오늘날의 자바가 있게 만든 일등공신인 애플릿은 지금도 여전히 많은 곳에서 사용되고 있는기술이기도 합니다.
어떻게 이 모든 것들이 따지고 보면 HTTP 프로토콜 자체가 연결이 없는(connectionless) 프로토콜이며, 브라우저에서 소켓과 같은 것을 지원하지 않기 때문에 생겨난 발명들이라 할 수 있습니다.
앞으로 나올 HTML5에서는 WebSocket이 적용됩니다. 아직 HTML5가 적용된 브라우저가 흔치 않은 탓에 현재로서는Comet을 사용하는 것이 가장 현실적인 대안이 아닐까 생각합니다만, 언젠가는 더 간단하고 편리한 세상이 오겠죠?
* 참고: Comet is dead long live websockets
================최신 동향===============
HTML5의 웹소켓을 통해 기존 stateless http protocol의 태생적 한계를 극복했음.
good
답글삭제