Comet

이 문서는 위키피디아의 Comet 문서를 번역한 것에 제가 조금 추가했습니다. 원문

Comet?

Comet은 웹에서 전통적인 폴링과 페이지 by 페이지 모델의 제한을 제거하는 기술의 총체적인 개념이다.  Comet을 사용하는 어플리케이션은  지속적인 HTTP 커넥션을 통해서 브라우저에게 업데이트를 제공합으로써

실시간 인터랙션을 제공한다. 브라우저와 프락시는 서버 이벤트 중심으로 만들어지지 않았기 때문에 웹 어플리케이션 개발자는 Comet과 같은것을 구현하려고 하면 의도되지 않은 부작용을 처리해야했다. 특히

HTTP 1.1 스펙에서는 브라우저는 웹서버에 동시 접속을 2개를 초과할 수 없다고 말하고 있다. 실시간 이벤트를 처리하기위해서 하나의 커넥션이 사용되고 있다면 브라우저의 사용성에 부적정인 영향을 주게된다. 

예를들어 브라우저가 이미지들을 받고 있을때 그 브라우저의 새로운 요청은 차단되어 질것이다. 그러나 이것은 실시간 정보 교환을 위해서 새로운 도메인을 만들어서 처리할수 있고 동일한 물리적인 서버에서도 호스팅 될 수있다.

 

Implementation of Comet

 

Streaming

Comet 스트리밍을 사용하는 어플리케이션에서 브라우저는 Comet 이벤트(점진적으로 브라우저측에서 처리되어짐)를 처리하기위해서 하나의 지속적인 커넥션을 연결해 놓는다. 매번 서버는 새로운 이벤트를 브라우저에 보내는데 그것을 처리하는데 연결을 끊지는 않는다.  아래는 Comet 스트리밍을 구현하는 기술들이다.

Hidden IFrame

  동적인 웹 어플리케이션을 위한 기본 기술은 hidden iframe( inline frame, 웹문서에 다른 문서를 포함 시킬 수 있게 만들어 줌)을 사용하는 것이다. 이 보이지 않는 IFrame에  chunked block이 보내어진다. 그것은 암묵적으로 무한정 길 수도있다. 이벤트가 일어날때마다 iframe은 점점 script 태그로 채워지게 된고 그 자바스크립트는 브라우저에 의해 실행되게 된다.  브라우저는 HTML 페이지를 계속 렌더링하기 때문에 스크립트 태그는 그것을 받자마자 실행되어 진다.

이 방법의 장점은 모든 브라우저에서 공통적으로 사용할 수 있는것이다. 그러나 이 방법은 안정적인 에러 핸들링 방법이 부족하고 요청처리의 상태를 트래킹 하기가 불가능하다. 

XMLHttpRequest

  XMLHttpRequest(XHR) 오브젝트는 브라우저와 서버가 커뮤니케이션하기 위해서 사용되어지는 주요 도구이고 또한 몇가지 다른 방법으로 Comet 메세징을 위해서도 사용될 수 있다.  1995년도에 Nescape Navigator 는 "server push"라는 기능을 추가하였는데 그것은 서버가  multipart/x-mixed-replace라는content type을 사용하는 multipart HTTP response를 이용하여 새 버전의 이미지나 HTML페이지를 보낼 수 있게 하였다.  2004년 도에 Gecko 기반의 파이어폭스또한 이 방법을 채용하였는데 이것은 Comet 스트리밍 하기위해서 사용될 수 있다. 서버 측에서 각각의 메세지는 멀티파트 응답의 구별되는 부분으로 인코딩 된다. 그리고 클라이언트에서는 XHR onreadystatechange function라는 콜백함수를 제공함으로서 메세지가 도착하면  핸들링할 수 있는 기능을 제공한다. 그러나 이 기능은 Gecko 기반의 브라우저에서만 동작하고 Webkit에서의 추가는 논의 중에 있다.

멀티파트 응답을 생성하는것 대신에 브라우저에 따라서 투명하게 이벤트를 파싱하고 , XHR 응답을 위한 사용자 데이터 포맷 만드는 것도 가능하다. 그리고 브라우저측의 자바스크립트를 이용하여 각각의 이벤트를 추출하고 새로운 데이터를 받을 때마다 특정 브라우저에 따라 onreadystatechagne콜백 함수를 호출한다.

Flash socket(is not comet)

  플래쉬에는 소켓이 존재해서 서버와 항상 연결될 수 있습니다. 플래쉬 소켓을 이용해서 서버와 연결된 브라우저는 다른 comet 구현체보다 훨씬 빠른 응답 및 받을 수 있고 장점이 있다. 그러나 세상의 90%이상의 브라우저에 플래쉬가 설치되어있다고 해도 플래쉬는 표준이 아니고 아이폰의 경우 플래쉬를 채용하고 있지 않다. 그리고 인터넷에서 실시간 커뮤니케이션을 위한 플래쉬 소켓은 는 여전히 show-stopping 문제를 가지고 있다. 그리고 그것은 브라우저의 프락시 설정을 따르지 않기 때문에 프락시를 사용하는 곳에서는 작동이 안될 수 있다.

 

 

Ajax with long polling

  Comet 개발자가 브라우저에 따른 복잡한 스트리밍 전송 방식을 구현하기 위해서 생기는 부작용 없이 지금의 모든 브라우저에서 잘 작동하는 long-polling은 결론적으로 많은 Comet 어플리케이션들이 선택할 것이다. 그것은 브라우저 측에서 구현하기 더 쉽고 , 간소하며, XHR을 지원하는 모든 브라우저에서 잘 작동한다. 이름과 같이 long polling은 클라이언트가 이벤트(이벤트 집합)들을 가져오는 것을 필요로한다. 브라우저는 Ajax 스타일의 요청을 서버에게하고 그것은 서버가 브라우저에게 보낼 새로운 데이터가 있을때까지 유지하고 브라우저에게 완전한 응답으로 보내어진다. 브라우저는 다음의 이벤트를 얻기위해서 새로운 long polling 요청을 새로 시작한다. 아래는 long-polling 기술을 구현하는 기술들이다.

XMLHttpRequest long polling

  대부분의 부분에서 XMLHttpRequest long polling 은 다른 표준 XHR의 사용하는 것과 같이 작동한다. 브라우저는 비동기로 서버에 요청하고 응답이 가능한 데이터가 있기 전까지 기다릴 것이다. 응답은 클라이언트에 의해서 핸들링 할 수 있는 XML,JSON,Javascript 로 인코딩된 데이터를 포함할 수 있다. 응답을 처리하고 완료하는 시점에 브라우저는 새로운 XHR을 생성하고 다음 이벤트를 기다린다. 그러므로 브라우저는 항상 서버에 요청할 있고 매 이벤트마다 응답을 받을 수 있다. 

Script tag long polling

  어떠한 Comet 전송이 서브도메인과의 통신에서 가능한 반면에 위에서의 전송방법은 브라우저에서 크로스사이트 스크립트 공격을 예방하게 만들어진 보안 정책때문에 다른 도메인과 통신할 수 없다. 그것은 만약 메인 웹페이지가 특정 도메인에 있고 Comet서버가 다른 도메인에 위치하고 있다면 Comet 이벤트는 메인 웹페이지의 HTML이나 DOM 을 수정할 수 없다. 이것은 메인 페이지와 같은 도메인의 프락시 서버를 만들어서 해결할 수 있지 복잡하고 성능 이유때문에 보통 바람직한 방법이 아닐 수 있다.

IFrame 이나 XMLHttpRequest objects와 같지 않게 script tags는 어떠한 URI도 가질 수 있고 응답으로 한 자바스크립트 코드 또한 현재의 HTML문서에서 실행 될 수 있다. 이 방법은 양쪽 서버 모두 잠재적인 보안 이슈를 만드는데 데이터 공급자(Comet server)에 대한 위험은 "JSONP"를 사용해서 피할 수 있다.

long-polling comet 전송방법은 동적으로 스크립트를 생성해서 만들고 그것의 소스코드를 Comet서버에 설치한다. 그것은 자바스크립트(혹은 JSONP)를 이벤트가 발생했을 경우 돌려 보낸다.  매번 스크립트 요청이 완료되었을 경우 브라우저는 XHR long polling 의 경우와 같이 새로운 요청을 새로 만든다. 이 방법은 크로스 도메인 구현을 필요하는 곳에서 이점이 있다.