http://www.okjsp.pe.kr/seq/131233
2008년 07월 29일
Comet 에 대하여
Reverse Ajax, Ajax Push, Two-Way-Web, HTTP server PUSH 등등으로 불리던 말이 이제 Comet 이라는 용어로 통일되어 가는 거 같다. 개념이 나온지는 꽤 되었지만 자바 서블릿 컨테이너가 이를 효과적으로 지원하지 않아 그간 관심만 가지고 있었다. 그런데 요즘 여러 서블릿 컨테이너들이 이를 지원하기 시작했고 Servlet API로의 표준화도 논의되고 있는 거 같다. 그래서 Comet 에 관련하여 한번 정리해 보고자 한다.
Comet 이란 웹 클라이언트(보통 웹 브라우저)의 명시적인 요청이 없어도 서버에서 클라이언트로 데이타를 밀어넣는(Push) 방식으로 동작하는 웹 프로그래밍 모델을 일컫는 말이다. 다만 HTTP 트랜잭션을 웹 서버가 먼저 시작할 수는 없으므로 클라이언트가 먼저 서버에 접속하여 접속을 계속 유지한 상태에서 서버가 데이타를 전송한다. 서버가 먼저 클라이언트로 접속을 열어 데이타를 전송할 수는 없다.
원래 HTTP라는 것이 웹 브라우저에서 요청을 보내면 서버가 응답을 전송하고 끝마치는 간단한 구조라 서버에서 클라이언트로 데이타를 밀어넣는 것은 구현하기가 힘들다. 이런 어려움을 어떻게든 극복하고자 여러 시도가 있었고 이들이 Comet 이라는 이름으로 정리되어 가는 중인 거다.
Comet 은 구체적인 구현 방법을 가리키는 말은 아니며 여러 방식들을 통칭하는 말이다. HTTP server push 를 구현하는 방법은 여러 방식이 있는데 이중의 부분 집합을 Comet 이라 할 수 있다. HTTP Server push 방법에는 다음과 같은 것들이 있다.
1. Polling
일정 간격으로 서버에 요청을 보내어 서버의 이벤트를 받는 방식이다. 요청 간격을 줄이면 거의 실시간으로 서버의 이벤트를 받을 수 있다. 그러나 서버의 자원과 대역을 많이 소모하므로 실제로 쓰기는 어려운 방식이다.
2. Long Polling
클라이언트가 서버에 접속을 하면 서버는 계속 접속을 유지하고 있다가 이벤트가 발생하면 클라이언트로 전송하고 HTTP 트랜잭션을 마친다. 클라이언트는 메시지를 받으면 다시 서버에 접속을 하여 위의 과정을 반복한다.
3. Streaming
클라이언트와 서버의 접속을 계속 유지한 채 서버에서 이벤트가 발생할 때마다 메시지를 HTTP Chunked 방식으로 보낸다. 가장 이상적인 방법이겠으나 ajax로 구현할 때 ie 에서는 제대로 작동하지 않는다(readyState = 3 이벤트가 발생하지 않는다). iframe 을 사용하여 <script> 태그로 둘러싼 메시지를 보내는 방식을 사용할 수 있지만 이 방식은 접속 오류를 제대로 처리하기 힘들다.
이중 Long Polling 과 Streaming 을 Comet 이라고 한다. Server PUSH 로는 Streaming 이 이상적이겠지만 위의 한계점 때문에 보통 Long Polling 방식을 주로 사용한다. Streaming 방식을 지원하는 것이 HTML5에서 논의 중인 것으로 보여 앞으로 이것이 구체화되면 Streaming 방식으로 좀더 효율적으로 Comet 을 구현할 수 있을 것이다.
Comet 모델을 구현하는 데 또 한 가지 걸림돌은 웹 서버의 지원이다. Long Polling 이든 Streaming 이든 HTTP 커넥션을 계속 유지할 필요가 있는데 대부분의 웹 서버(자바 서블릿 컨테이너도 포함)들은 짧은 HTTP 트랙잭션에 맞춰져 있기 때문에 Comet 을 지원하는데 효율적이지 못하다. 특히 자바 서블릿 컨테이너는 HTTP 요청이 각각 스레드에 할당되어 처리되기 때문에 Comet 을 지원하게 되면 많은 스레드가 생성되게 된다. 스레드는 대부분 단지 커넥션을 유지하고 있을 뿐 거의 동작을 하지 않다가 서버측 이벤트가 있을 경우에만 잠깐 동작할 뿐이다. 이렇게 많은 Idle 스레드가 생기면 스레드 생성 및 컨텍스트 교환에 따른 오버헤드가 무시못하게 된다.
Comet 을 효율적으로 지원하기 위해서는 다른 고성능 서버 프로그램처럼 하나의 스레드가 여러 커넥션(이 경우 웹 요청)을 처리할 수 있어야 한다. 현재 서블릿 API에서는 이것이 불가능하다. 따라서 이에 대한 대안이 여럿 등장했다. Comet 요청을 전용으로 처리하고자 하는 서버도 있었으며 서블릿 컨테이너 중에는 Jetty 가 최초로 Continuation 방식의 API 를 선보였다. 이후 Tomcat 6.0, Resin 3.1 에서도 각기 나름의 API 를 선보였다. 현재 Early Draft Review 상태에 있는 Servlet 3.0 에서 Jetty의 Continuation 과 비슷한 방식으로 지원이 논의되고 있다.
다음 포스트에서 서블릿 컨테이너별로 Comet 을 지원하는 기능을 살펴보고자 한다.
Comet 이란 웹 클라이언트(보통 웹 브라우저)의 명시적인 요청이 없어도 서버에서 클라이언트로 데이타를 밀어넣는(Push) 방식으로 동작하는 웹 프로그래밍 모델을 일컫는 말이다. 다만 HTTP 트랜잭션을 웹 서버가 먼저 시작할 수는 없으므로 클라이언트가 먼저 서버에 접속하여 접속을 계속 유지한 상태에서 서버가 데이타를 전송한다. 서버가 먼저 클라이언트로 접속을 열어 데이타를 전송할 수는 없다.
원래 HTTP라는 것이 웹 브라우저에서 요청을 보내면 서버가 응답을 전송하고 끝마치는 간단한 구조라 서버에서 클라이언트로 데이타를 밀어넣는 것은 구현하기가 힘들다. 이런 어려움을 어떻게든 극복하고자 여러 시도가 있었고 이들이 Comet 이라는 이름으로 정리되어 가는 중인 거다.
Comet 은 구체적인 구현 방법을 가리키는 말은 아니며 여러 방식들을 통칭하는 말이다. HTTP server push 를 구현하는 방법은 여러 방식이 있는데 이중의 부분 집합을 Comet 이라 할 수 있다. HTTP Server push 방법에는 다음과 같은 것들이 있다.
1. Polling
일정 간격으로 서버에 요청을 보내어 서버의 이벤트를 받는 방식이다. 요청 간격을 줄이면 거의 실시간으로 서버의 이벤트를 받을 수 있다. 그러나 서버의 자원과 대역을 많이 소모하므로 실제로 쓰기는 어려운 방식이다.
2. Long Polling
클라이언트가 서버에 접속을 하면 서버는 계속 접속을 유지하고 있다가 이벤트가 발생하면 클라이언트로 전송하고 HTTP 트랜잭션을 마친다. 클라이언트는 메시지를 받으면 다시 서버에 접속을 하여 위의 과정을 반복한다.
3. Streaming
클라이언트와 서버의 접속을 계속 유지한 채 서버에서 이벤트가 발생할 때마다 메시지를 HTTP Chunked 방식으로 보낸다. 가장 이상적인 방법이겠으나 ajax로 구현할 때 ie 에서는 제대로 작동하지 않는다(readyState = 3 이벤트가 발생하지 않는다). iframe 을 사용하여 <script> 태그로 둘러싼 메시지를 보내는 방식을 사용할 수 있지만 이 방식은 접속 오류를 제대로 처리하기 힘들다.
이중 Long Polling 과 Streaming 을 Comet 이라고 한다. Server PUSH 로는 Streaming 이 이상적이겠지만 위의 한계점 때문에 보통 Long Polling 방식을 주로 사용한다. Streaming 방식을 지원하는 것이 HTML5에서 논의 중인 것으로 보여 앞으로 이것이 구체화되면 Streaming 방식으로 좀더 효율적으로 Comet 을 구현할 수 있을 것이다.
Comet 모델을 구현하는 데 또 한 가지 걸림돌은 웹 서버의 지원이다. Long Polling 이든 Streaming 이든 HTTP 커넥션을 계속 유지할 필요가 있는데 대부분의 웹 서버(자바 서블릿 컨테이너도 포함)들은 짧은 HTTP 트랙잭션에 맞춰져 있기 때문에 Comet 을 지원하는데 효율적이지 못하다. 특히 자바 서블릿 컨테이너는 HTTP 요청이 각각 스레드에 할당되어 처리되기 때문에 Comet 을 지원하게 되면 많은 스레드가 생성되게 된다. 스레드는 대부분 단지 커넥션을 유지하고 있을 뿐 거의 동작을 하지 않다가 서버측 이벤트가 있을 경우에만 잠깐 동작할 뿐이다. 이렇게 많은 Idle 스레드가 생기면 스레드 생성 및 컨텍스트 교환에 따른 오버헤드가 무시못하게 된다.
Comet 을 효율적으로 지원하기 위해서는 다른 고성능 서버 프로그램처럼 하나의 스레드가 여러 커넥션(이 경우 웹 요청)을 처리할 수 있어야 한다. 현재 서블릿 API에서는 이것이 불가능하다. 따라서 이에 대한 대안이 여럿 등장했다. Comet 요청을 전용으로 처리하고자 하는 서버도 있었으며 서블릿 컨테이너 중에는 Jetty 가 최초로 Continuation 방식의 API 를 선보였다. 이후 Tomcat 6.0, Resin 3.1 에서도 각기 나름의 API 를 선보였다. 현재 Early Draft Review 상태에 있는 Servlet 3.0 에서 Jetty의 Continuation 과 비슷한 방식으로 지원이 논의되고 있다.
다음 포스트에서 서블릿 컨테이너별로 Comet 을 지원하는 기능을 살펴보고자 한다.
# by | 2008/07/29 19:32 | 트랙백 | 핑백(3) | 덧글(0)
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
... 이전글: Comet 에 대하여 Jetty 는 버전 6.0에서부터 Continuation 이라는 것을 도입해서 Comet 스타일의 웹 프로그래밍을 효과적으로 구현할 수 있게 되었다. jet ... more
... 이전글 Comet 에 대하여 자바 서블릿 컨테이너의 Comet 지원 1 - Jetty Tomcat 에서는 버전 6.0의 Advanced IO 지원을 통해 Comet 모델을 효과적으로 구현할 수 있 ... more
... 이전글 Comet 에 대하여 자바 서블릿 컨테이너의 Comet 지원 1 - Jetty자바 서블릿 컨테이너의 Comet 지원 2 - Tomcat Resin 은 버전 3.1에서 Comet 모델을 지원 ... more