맨위로가기

코멧 (프로그래밍)

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

코멧(Comet)은 웹 서버와 웹 브라우저 간의 양방향 통신 기술로, 서버가 클라이언트의 요청 없이도 데이터를 전송할 수 있게 해준다. 1990년대 후반 자바 애플릿을 통해 처음 시도되었으며, 2006년 알렉스 러셀에 의해 "코멧"이라는 용어가 만들어졌다. 코멧은 웹 페이지를 새로 고침 없이 실시간으로 정보를 업데이트하여, 기존의 폴링 방식과 Ajax 기술의 한계를 극복하려 했다.

코멧은 스트리밍과 롱 폴링 두 가지 주요 구현 방식을 사용한다. 스트리밍은 단일 연결을 지속적으로 유지하며, 롱 폴링은 서버에서 이벤트가 발생할 때까지 연결을 보류하는 방식이다. HTML5의 서버 전송 이벤트와 웹소켓, BOSH, 베유 프로토콜과 같은 기술들이 코멧의 대안으로 제시되었다.

2. 역사

2. 1. 초기 자바 애플릿

자바 애플릿을 브라우저에 내장하는 기능은 1996년 3월 넷스케이프 내비게이터 2.0부터 시작되었으며,[10] 브라우저와 서버 간의 통신을 위해 원시 TCP 소켓[11]을 사용하여 양방향 지속 통신을 가능하게 했다. 이 소켓은 브라우저가 애플릿을 호스팅하는 문서에 있는 한 열린 상태로 유지될 수 있다. 이벤트 알림은 텍스트 또는 바이너리 등 어떤 형식으로든 전송될 수 있으며 애플릿에 의해 디코딩된다.

2. 2. 최초의 브라우저 간 통신 프레임워크

1996년부터 1998년까지 시라큐스 대학교의 북동부 병렬 아키텍처 센터([http://surface.syr.edu/npac/ NPAC])에서 DARPA 자금으로 브라우저 간 통신을 사용한 최초의 응용 프로그램 중 하나인 Tango Interactive를 구현했다.[12] 시라큐스 대학교는 TANGO 아키텍처에 대한 특허를 받았다.[13] TANGO 프레임워크는 원격 교육 도구로 광범위하게 사용되었다.[14] 이 프레임워크는 [http://www.collabworx.com CollabWorx]에 의해 상용화되었으며, 미국 국방부에서 10여 개의 지휘 및 통제, 훈련 응용 프로그램에 사용되었다.

2. 3. 초기 코멧 애플리케이션

2000년대 초반, Pushlets, Lightstreamer, KnowNow 프로젝트와 같은 초기 코멧 구현이 등장했다.[15] Pushlets은 최초의[16] 오픈 소스 구현 중 하나로, 서버 측 Java 서블릿과 클라이언트 측 JavaScript 라이브러리를 기반으로 했다. Netscape 공동 창업자 마크 앤드리슨의 지원을 받은 실리콘 밸리 스타트업 Bang Networks는 전체 웹을 위한 실시간 푸시 표준을 만들고자 했다.[17]

2001년 4월, 칩 모닝스타는 맞춤형 HTTP 서버와 더글러스 크록포드가 설계한 클라이언트 간에 두 개의 통신 채널을 열어두기 위해 두 개의 HTTP 소켓을 사용하는 Java 기반 웹 서버 개발을 시작했다. 2001년 6월부터 작동하는 데모 시스템이 있었으며, 이 시스템은 State Application Framework의 일부로 Sun Microsystems, Amazon.com, EDS 및 Volkswagen에서 사용되었다.

2006년 3월, 소프트웨어 엔지니어 알렉스 러셀은 자신의 블로그에서 코멧이라는 용어를 만들었다.[18] 이는 Ajax (프로그래밍)에 대한 말장난이었다.[19][20][21]

같은 해, Meebo의 웹 기반 채팅 애플리케이션은 사용자가 브라우저를 통해 AOL, Yahoo, Microsoft 채팅 플랫폼에 연결할 수 있도록 했다. 구글은 Gmail에 웹 기반 채팅을 추가했으며, JotSpot은 코멧 기반의 실시간 협업 문서 편집 기능을 구축했다.[22] Java 기반 ICEfaces JSF 프레임워크와 같은 새로운 코멧 변형이 만들어졌다.[4]

3. 구현 방법

코멧 애플리케이션은 서버와 클라이언트 간의 지속적이고 오래 지속되는 HTTP 연결을 사용하여 양방향 지속적 상호 작용을 제공함으로써 페이지 단위 웹 모델과 기존의 폴링의 한계를 제거하려고 시도한다. 브라우저와 프록시는 서버 이벤트를 염두에 두고 설계되지 않았으므로, 이를 달성하기 위한 여러 기술이 개발되었으며 각각 장단점이 있다. 가장 큰 걸림돌은 HTTP 1.1 사양으로, "이 사양은... 클라이언트가 여러 연결을 열 때 신중할 것을 권장한다"고 명시되어 있다.[24] 따라서 실시간 이벤트를 위해 하나의 연결을 열어두면 브라우저 사용성에 부정적인 영향을 미친다. 브라우저는 이전 요청(예: 일련의 이미지)의 결과를 기다리는 동안 새 요청을 보낼 수 없도록 차단될 수 있다. 이는 동일한 물리적 서버의 별칭인 실시간 정보를 위한 별도의 호스트 이름을 생성하여 해결할 수 있다. 이 전략은 도메인 샤딩의 한 예이다.

코멧을 구현하는 구체적인 방법은 스트리밍과 롱 폴링의 두 가지 주요 범주로 나뉜다.

일반적으로 웹 서버는 클라이언트의 요청을 받으면 즉시 응답을 반환한다.

코멧을 이용한 웹 애플리케이션에서는 서버는 클라이언트의 요청에 즉시 응답하지 않고 보류 상태로 두었다가, 서버 상에서 어떠한 이벤트(채팅에서 누군가 발언했다 등)가 발생했을 때 응답을 반환한다. 이렇게 함으로써 서버에서 발생한 이벤트를 즉시 클라이언트에 전송할 수 있다.

3. 1. 스트리밍

스트리밍 코멧을 사용하는 응용 프로그램은 모든 코멧 이벤트에 대해 서버에서 클라이언트 브라우저로 단일 지속적인 연결을 연다. 이러한 이벤트는 서버가 새 이벤트를 보낼 때마다 클라이언트 측에서 점진적으로 처리되고 해석되며, 양쪽 모두 연결을 닫지 않는다.[25]

스트리밍 코멧을 수행하기 위한 특정 기술은 다음과 같다.

일반적으로 웹 서버는 클라이언트의 요청을 받으면 즉시 응답을 반환한다.

코멧을 이용한 웹 애플리케이션에서는 서버는 클라이언트의 요청에 즉시 응답하지 않고 보류 상태로 두었다가, 서버 상에서 어떠한 이벤트(채팅에서 누군가 발언했다 등)가 발생했을 때 응답을 반환한다. 이렇게 함으로써 서버에서 발생한 이벤트를 즉시 클라이언트에 전송할 수 있다.

==== Hidden iframe ====

동적 웹 애플리케이션의 기본적인 기술은 숨겨진 iframe HTML 요소(''인라인 프레임''이라고도 하며, 웹사이트가 다른 HTML 문서 안에 HTML 문서를 포함할 수 있게 한다)를 사용하는 것이다. 이 보이지 않는 iframe은 청크 블록으로 전송되며, 이는 암묵적으로 무한히 길다고 선언한다("영원한 프레임"이라고도 함). 이벤트가 발생하면 iframe은 브라우저에서 실행될 JavaScript를 포함하는 `script` 태그로 점차 채워진다. 브라우저는 HTML 페이지를 점진적으로 렌더링하기 때문에 각 `script` 태그는 수신되는 대로 실행된다. 일부 브라우저는 구문 분석 및 실행을 시작하기 전에 특정 최소 문서 크기가 필요하며, 이는 처음에 1–2 kB의 패딩 공간을 전송하여 얻을 수 있다.[26]

iframe 방식의 장점 중 하나는 모든 일반적인 브라우저에서 작동한다는 것이다. 이 기술의 두 가지 단점은 신뢰할 수 있는 오류 처리 방법이 없다는 것과 요청 호출 프로세스의 상태를 추적하는 것이 불가능하다는 것이다.[26]

==== XMLHttpRequest ====

XMLHttpRequest (XHR) 객체는 Ajax 애플리케이션에서 브라우저-서버 통신에 사용되는 도구이다. XHR 응답에 대한 사용자 정의 데이터 형식을 생성하고 브라우저 측 자바스크립트를 사용하여 각 이벤트를 구문 분석함으로써 서버-브라우저 코멧 메시징에 활용될 수도 있다. 이는 브라우저가 새로운 데이터를 수신할 때마다 `onreadystatechange` 콜백을 실행하는 데만 의존한다.

3. 1. 1. Hidden iframe

동적 웹 애플리케이션의 기본적인 기술은 숨겨진 iframe HTML 요소(''인라인 프레임''이라고도 하며, 웹사이트가 다른 HTML 문서 안에 HTML 문서를 포함할 수 있게 한다)를 사용하는 것이다. 이 보이지 않는 iframe은 청크 블록으로 전송되며, 이는 암묵적으로 무한히 길다고 선언한다("영원한 프레임"이라고도 함). 이벤트가 발생하면 iframe은 브라우저에서 실행될 JavaScript를 포함하는 `script` 태그로 점차 채워진다. 브라우저는 HTML 페이지를 점진적으로 렌더링하기 때문에 각 `script` 태그는 수신되는 대로 실행된다. 일부 브라우저는 구문 분석 및 실행을 시작하기 전에 특정 최소 문서 크기가 필요하며, 이는 처음에 1–2 kB의 패딩 공간을 전송하여 얻을 수 있다.[26]

iframe 방식의 장점 중 하나는 모든 일반적인 브라우저에서 작동한다는 것이다. 이 기술의 두 가지 단점은 신뢰할 수 있는 오류 처리 방법이 없다는 것과 요청 호출 프로세스의 상태를 추적하는 것이 불가능하다는 것이다.[26]

3. 1. 2. XMLHttpRequest

XMLHttpRequest (XHR) 객체는 Ajax 애플리케이션에서 브라우저-서버 통신에 사용되는 도구이다. XHR 응답에 대한 사용자 정의 데이터 형식을 생성하고 브라우저 측 자바스크립트를 사용하여 각 이벤트를 구문 분석함으로써 서버-브라우저 코멧 메시징에 활용될 수도 있다. 이는 브라우저가 새로운 데이터를 수신할 때마다 `onreadystatechange` 콜백을 실행하는 데만 의존한다.

3. 2. 롱 폴링 (Long Polling)

XMLHttpRequest 롱 폴링은 XHR의 표준적인 사용 방식과 유사하게 작동한다. 브라우저는 서버에 비동기 요청을 보내고, 서버는 응답하기 전에 데이터를 사용할 수 있을 때까지 대기할 수 있다. 응답에는 인코딩된 데이터(일반적으로 XML 또는 JSON) 또는 클라이언트가 실행할 자바스크립트가 포함될 수 있다. 응답 처리가 끝나면, 브라우저는 다음 이벤트를 대기하기 위해 다른 XHR을 생성하고 보낸다. 따라서 브라우저는 각 이벤트가 발생할 때마다 응답을 받기 위해 서버에 항상 미결된 요청을 유지한다.

어떤 코멧 전송 방식도 하위 도메인에서 작동하도록 만들 수 있지만, 위에서 언급된 전송 방식은 2단계 도메인 (SLD)이 다른 경우에는 사용할 수 없다. 이는 사이트 간 스크립팅 공격을 방지하기 위해 설계된 브라우저 보안 정책 때문이다.[27] 즉, 메인 웹 페이지가 하나의 SLD에서 제공되고, 코멧 서버가 다른 SLD에 위치한 경우(교차 출처 리소스 공유가 활성화되어 있지 않음), 코멧 이벤트를 사용하여 해당 전송 방식을 통해 메인 페이지의 HTML 및 DOM을 수정할 수 없다. 이 문제는 하나 또는 두 소스 앞에 프록시 서버를 생성하여 동일한 도메인에서 시작된 것처럼 보이게 함으로써 우회할 수 있다. 그러나 이는 복잡성 또는 성능 문제로 인해 종종 바람직하지 않다.

`script` 태그는 iframe 또는 XMLHttpRequest 객체와 달리 모든 URI를 가리킬 수 있으며, 응답의 JavaScript 코드는 현재 HTML 문서에서 실행된다. 이는 관련 서버 모두에게 잠재적인 보안 위험을 초래하지만, 데이터 제공자(이 경우 코멧 서버)에 대한 위험은 JSONP를 사용하여 피할 수 있다.

동적으로 `script` 요소를 생성하고 해당 소스를 코멧 서버의 위치로 설정하여 장기 폴링 코멧 전송을 만들 수 있으며, 코멧 서버는 JavaScript(또는 JSONP)를 페이로드로 일부 이벤트를 다시 보낸다. 스크립트 요청이 완료될 때마다 브라우저는 XHR 장기 폴링의 경우와 마찬가지로 새 스크립트 요청을 연다. 이 방법은 교차 도메인 구현을 허용하면서도 여러 브라우저에서 작동한다는 장점이 있다.[27]

일반적으로 웹 서버는 클라이언트의 요청을 받으면 즉시 응답을 반환한다.

코멧을 이용한 웹 애플리케이션에서는 서버는 클라이언트의 요청에 즉시 응답하지 않고 보류 상태로 두었다가, 서버 상에서 어떠한 이벤트(채팅에서 누군가 발언했다 등)가 발생했을 때 응답을 반환한다. 이렇게 함으로써 서버에서 발생한 이벤트를 즉시 클라이언트에 전송할 수 있다.

3. 2. 1. XMLHttpRequest 롱 폴링

XMLHttpRequest 롱 폴링은 XHR의 표준적인 사용 방식과 유사하게 작동한다. 브라우저는 서버에 비동기 요청을 보내고, 서버는 응답하기 전에 데이터를 사용할 수 있을 때까지 대기할 수 있다. 응답에는 인코딩된 데이터(일반적으로 XML 또는 JSON) 또는 클라이언트가 실행할 자바스크립트가 포함될 수 있다. 응답 처리가 끝나면, 브라우저는 다음 이벤트를 대기하기 위해 다른 XHR을 생성하고 보낸다. 따라서 브라우저는 각 이벤트가 발생할 때마다 응답을 받기 위해 서버에 항상 미결된 요청을 유지한다.

3. 2. 2. Script 태그 롱 폴링

어떤 코멧 전송 방식도 하위 도메인에서 작동하도록 만들 수 있지만, 위에서 언급된 전송 방식은 2단계 도메인 (SLD)이 다른 경우에는 사용할 수 없다. 이는 사이트 간 스크립팅 공격을 방지하기 위해 설계된 브라우저 보안 정책 때문이다.[27] 즉, 메인 웹 페이지가 하나의 SLD에서 제공되고, 코멧 서버가 다른 SLD에 위치한 경우(교차 출처 리소스 공유가 활성화되어 있지 않음), 코멧 이벤트를 사용하여 해당 전송 방식을 통해 메인 페이지의 HTML 및 DOM을 수정할 수 없다. 이 문제는 하나 또는 두 소스 앞에 프록시 서버를 생성하여 동일한 도메인에서 시작된 것처럼 보이게 함으로써 우회할 수 있다. 그러나 이는 복잡성 또는 성능 문제로 인해 종종 바람직하지 않다.

`script` 태그는 iframe 또는 XMLHttpRequest 객체와 달리 모든 URI를 가리킬 수 있으며, 응답의 JavaScript 코드는 현재 HTML 문서에서 실행된다. 이는 관련 서버 모두에게 잠재적인 보안 위험을 초래하지만, 데이터 제공자(이 경우 코멧 서버)에 대한 위험은 JSONP를 사용하여 피할 수 있다.

동적으로 `script` 요소를 생성하고 해당 소스를 코멧 서버의 위치로 설정하여 장기 폴링 코멧 전송을 만들 수 있으며, 코멧 서버는 JavaScript(또는 JSONP)를 페이로드로 일부 이벤트를 다시 보낸다. 스크립트 요청이 완료될 때마다 브라우저는 XHR 장기 폴링의 경우와 마찬가지로 새 스크립트 요청을 연다. 이 방법은 교차 도메인 구현을 허용하면서도 여러 브라우저에서 작동한다는 장점이 있다.[27]

4. 기존 기술과의 비교 및 필요성

과거 방식에서는 웹 페이지는 클라이언트의 요청이 있을 때만 클라이언트에 전달되었다. 클라이언트가 요청할 때마다 브라우저는 서버에 HTTP 연결을 생성하고 웹 서버는 클라이언트에 데이터를 반환하며 해당 연결은 닫혔다. 사용자가 명시적으로 페이지를 새로 고치거나, 새로운 페이지로 이동하는 경우에만 표시되는 페이지가 업데이트되는 단점이 있었다. 페이지를 모두 전송하는 데 오랜 시간이 걸려 페이지 새로 고침은 상당한 지연을 발생시켰다.

이 문제를 해결하기 위해 브라우저에서 변경된 부분만 요청하고 업데이트하는 기술인 Ajax를 사용할 수 있다. 이 방식은 데이터 통신량이 과거 방식보다 적어 지연 정도가 줄어들고 사이트 전체의 성능이 향상된다. 게다가 비동기 통신을 사용함으로써 사용자는 단계적으로 데이터를 수신하면서 작업을 할 수 있으므로 그 의미에서도 성능이 향상된다.

그러나 Ajax를 사용하더라도, 클라이언트가 서버에서 데이터를 가져오기 전에 이에 대한 요청을 보내야 한다는 문제는 여전히 존재한다. 예를 들어 "다른 클라이언트가 데이터를 보냈다"와 같은 서버 상의 이벤트가 발생하기를 기다려야 하는 애플리케이션을 설계할 때 큰 장애가 된다.

서버에서 이벤트가 발생했는지 주기적으로 확인하는 폴링(Polling)방식은 하나의 해결책이 될수 있다. 그러나 이 방법은 애플리케이션이 결국 서버상의 이벤트가 완료되었는지 묻는 데 많은 시간을 소비하고, 네트워크 대역폭도 많이 소비한다.

4. 1. Ajax와의 비교

Ajax는 브라우저에서 변경된 부분만 요청하고 업데이트하는 기술이다. 이 방식은 데이터 통신량이 과거 방식보다 적어 지연 정도가 줄어들고 사이트 전체의 성능이 향상된다. 게다가 비동기 통신을 사용함으로써 사용자는 단계적으로 데이터를 수신하면서 작업을 할 수 있으므로 그 의미에서도 성능이 향상된다.

그러나 Ajax를 사용하더라도, 클라이언트가 서버에서 데이터를 가져오기 전에 이에 대한 요청을 보내야 한다는 문제는 여전히 존재한다.

4. 2. 폴링(Polling)의 문제점

과거 웹 페이지는 클라이언트의 요청이 있을 때만 클라이언트에 전달되었다. 클라이언트가 요청할 때마다 브라우저는 서버에 HTTP 연결을 생성하고 웹 서버는 클라이언트에 데이터를 반환하며 해당 연결은 닫혔다. 사용자가 명시적으로 페이지를 새로 고치거나, 새로운 페이지로 이동하는 경우에만 표시되는 페이지가 업데이트되는 단점이 있었다. 페이지를 모두 전송하는 데 오랜 시간이 걸려 페이지 새로 고침은 상당한 지연을 발생시켰다.

이 문제를 해결하기 위해 브라우저에서 변경된 부분만 요청하고 업데이트하는 기술인 Ajax를 사용할 수 있다. 이 방식은 데이터 통신량이 과거 방식보다 적어 지연 정도가 줄어들고 사이트 전체의 성능이 향상된다. 게다가 비동기 통신을 사용함으로써 사용자는 단계적으로 데이터를 수신하면서 작업을 할 수 있으므로 그 의미에서도 성능이 향상된다.

그러나 Ajax를 사용하더라도, 클라이언트가 서버에서 데이터를 가져오기 전에 이에 대한 요청을 보내야 한다는 문제는 여전히 존재한다. 예를 들어 "다른 클라이언트가 데이터를 보냈다"와 같은 서버 상의 이벤트가 발생하기를 기다려야 하는 애플리케이션을 설계할 때 큰 장애가 된다.

서버에서 이벤트가 발생했는지 주기적으로 확인하는 폴링(Polling)방식은 하나의 해결책이 될수 있다. 그러나 이 방법은 애플리케이션이 결국 서버상의 이벤트가 완료되었는지 묻는 데 많은 시간을 소비하고, 네트워크 대역폭도 많이 소비한다.

5. 대안 기술

브라우저 네이티브 기술은 코멧이라는 용어에 내재되어 있으며, 비폴링 HTTP 통신을 개선하려는 시도는 여러 측면에서 이루어졌다.


  • 웹 하이퍼텍스트 애플리케이션 기술 워킹 그룹(WHATWG)에서 제작한 HTML 5 초안 사양은 이른바 서버 전송 이벤트를 명시하며,[28] 새로운 JavaScript 인터페이스 `EventSource`와 새로운 MIME 유형 `text/event-stream`을 정의한다. 마이크로소프트 인터넷 익스플로러를 제외한 모든 주요 브라우저가 이 기술을 포함하고 있다.
  • HTML 5 WebSocket API 작업 초안은 서버와의 영구적인 연결을 생성하고 `onmessage` 콜백을 통해 메시지를 수신하는 방법을 명시한다.[29]
  • 도조 재단의 베유 프로토콜. 브라우저별 전송 방식을 유지하며, 브라우저와 서버 간의 통신을 위한 상위 수준 프로토콜을 정의하여 여러 코멧 서버에서 클라이언트 측 자바스크립트 코드를 재사용하고, 동일한 코멧 서버가 여러 클라이언트 측 자바스크립트 구현과 통신할 수 있도록 하는 것을 목표로 한다. 베유는 게시/구독 모델을 기반으로 하므로 베유를 지원하는 서버는 게시/구독 기능이 내장되어 있다.[30]
  • XMPP 표준 재단의 BOSH 프로토콜. 두 개의 동기식 HTTP 연결을 사용하여 브라우저와 서버 간의 양방향 스트림을 에뮬레이션한다.
  • 더글러스 크록포드가 제안한 JSONRequest 객체는 XHR 객체의 대안이 될 것이다.[31]
  • 자바 애플릿 또는 독점적인 어도비 플래시와 같은 플러그인 사용(플래시 애플리케이션으로의 데이터 스트리밍을 위해 RTMP 프로토콜 사용). 이러한 방식은 적절한 플러그인이 설치된 모든 브라우저에서 동일하게 작동하며 HTTP 연결에 의존할 필요가 없다는 장점이 있지만, 플러그인을 설치해야 한다는 단점이 있다.
  • 구글은[32] 브라우저에서 클라이언트 JavaScript 라이브러리를 사용하여 코멧과 유사한 API를 구현하는 구글 앱 엔진을 위한 새로운 채널 API를 발표했다.[33] 이 API는 더 이상 사용되지 않는다.[34]

5. 1. 서버 전송 이벤트 (Server-Sent Events, SSE)

HTML 5 초안 사양은 서버 전송 이벤트를 명시하며,[28] 새로운 JavaScript 인터페이스 `EventSource`와 새로운 MIME 유형 `text/event-stream`을 정의한다. 마이크로소프트 인터넷 익스플로러를 제외한 모든 주요 브라우저가 이 기술을 포함하고 있다.

5. 2. 웹소켓 (WebSocket)

HTML 5 표준의 일부로, 서버와 클라이언트 간의 양방향 통신을 위한 프로토콜이다.[29] 웹 하이퍼텍스트 애플리케이션 기술 워킹 그룹(WHATWG)에서 HTML 5 WebSocket API 작업 초안은 서버와의 영구적인 연결을 생성하고 `onmessage` 콜백을 통해 메시지를 수신하는 방법을 명시한다.

5. 3. 기타 기술

브라우저 네이티브 기술은 코멧이라는 용어에 내재되어 있으며, 비폴링 HTTP 통신의 개선은 여러 측면에서 이루어졌다.[28][29][30][31][32][33][34]

웹 하이퍼텍스트 애플리케이션 기술 워킹 그룹(WHATWG)에서 제작한 HTML 5 초안 사양은 서버 전송 이벤트를 명시하며, 새로운 JavaScript 인터페이스 `EventSource`와 새로운 MIME 유형 `text/event-stream`을 정의한다. 마이크로소프트 인터넷 익스플로러를 제외한 모든 주요 브라우저가 이 기술을 포함하고 있다. HTML 5 WebSocket API 작업 초안은 서버와의 영구적인 연결을 생성하고 `onmessage` 콜백을 통해 메시지를 수신하는 방법을 명시한다.

도조 재단의 베유 프로토콜은 브라우저별 전송 방식을 유지하며, 브라우저와 서버 간의 통신을 위한 상위 수준 프로토콜을 정의한다. 이를 통해 여러 코멧 서버에서 클라이언트 측 자바스크립트 코드를 재사용하고, 동일한 코멧 서버가 여러 클라이언트 측 자바스크립트 구현과 통신할 수 있도록 한다. 베유는 게시/구독 모델을 기반으로 하므로 베유를 지원하는 서버는 게시/구독 기능이 내장되어 있다.

XMPP 표준 재단의 BOSH 프로토콜은 두 개의 동기식 HTTP 연결을 사용하여 브라우저와 서버 간의 양방향 스트림을 에뮬레이션한다. 더글러스 크록포드가 제안한 JSONRequest 객체는 XHR 객체의 대안이 될 것이다.

자바 애플릿 또는 독점적인 어도비 플래시와 같은 플러그인 사용(플래시 애플리케이션으로의 데이터 스트리밍을 위해 RTMP 프로토콜 사용)은 적절한 플러그인이 설치된 모든 브라우저에서 동일하게 작동하며 HTTP 연결에 의존할 필요가 없다는 장점이 있지만, 플러그인을 설치해야 한다는 단점이 있다.

구글은 브라우저에서 클라이언트 JavaScript 라이브러리를 사용하여 코멧과 유사한 API를 구현하는 구글 앱 엔진을 위한 새로운 채널 API를 발표했지만, 이 API는 더 이상 사용되지 않는다.

6. 한국의 활용 사례

6. 1. 온라인 게임

6. 2. 포털 사이트

6. 3. 금융 서비스

참조

[1] 웹사이트 AJAX alliance recognizes mashups http://www.infoworld[...] InfoWorld 2007-09-24
[2] 서적 Comet and Reverse Ajax: The Next-Generation Ajax 2.0 Apress 2008-10-13
[3] 간행물 Ajax Push (a.k.a. Comet) with Java Business Integration (JBI) http://developers.su[...] Sun Microsystems, Inc. 2008-06-10
[4] 웹사이트 Ajax Push http://www.icesoft.o[...] ICEfaces.org 2014-10-23
[5] 서적 Comet and Reverse Ajax: The Next Generation Ajax 2.0 Apress 2008-07-01
[6] 서적 Ajax Design Patterns O'Reilly Media 2006-06-01
[7] 웹사이트 More on Ajax and server push http://www.bluishcod[...] 2008-05-05
[8] 웹사이트 The Slow Load Technique/Reverse AJAX http://www.obviously[...] 2008-05-06
[9] 웹사이트 Comet: Low Latency Data for the Browser http://infrequently.[...] 2014-11-02
[10] 웹사이트 Netscape.com http://www27.netscap[...] 2017-08-16
[11] 웹사이트 java.net.Socket (Java 2 Platform SE v1.4.2) http://java.sun.com/[...]
[12] 웹사이트 TANGO - a Collaborative Environment for the World-Wide Web http://surface.syr.e[...] Northeast Parallel Architecture Center, College of Engineering and Computer Science 2016-02-27
[13] Citation United States Patent: 6078948 - Platform-independent collaboration backbone and framework for forming virtual communities having virtual rooms with collaborative sessions http://patft.uspto.g[...] 2016-02-27
[14] 웹사이트 Experiences with Using TANGO Interactive in a Distributed Workshop https://www.dsc.soic[...] CEWES MSRC/PET TR/99-21 2016-02-27
[15] 웹사이트 CometDaily: Comet and Push Technology http://cometdaily.co[...] 2007-12-15
[16] 뉴스 Pushlets: Send events from servlets to DHTML client browsers http://www.javaworld[...] JavaWorld 2000-03-01
[17] 웹사이트 Will the "refresh" button become obsolete? http://news.cnet.com[...] CNET Networks 2008-07-22
[18] 뉴스 Comet: Low Latency Data for the Browser http://alex.dojotool[...] 2006-03-03
[19] 웹사이트 Microsoft Scrubs Comet from AJAX Tool Set http://www.eweek.com[...] eWEEK.com 2008-07-21
[20] 웹사이트 Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon http://en.oreilly.co[...]
[21] 웹사이트 Enterprise Comet & Web 2.0 Live Presentation http://www.web2journ[...]
[22] 뉴스 Jotspot Live: Live, group note-taking Ajaxian 2007-12-15
[23] 뉴스 Startups Board the AJAX Bandwagon DevX News 2008-02-18
[24] 문서 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing http://tools.ietf.or[...] IETF 2014-07-29
[25] 웹사이트 Comet Programming: Using Ajax to Simulate Server Push http://www.webrefere[...] Webreference.com 2010-10-20
[26] 서적 Ajax: The Definitive Guide O'Reilly Media 2008-01-01
[27] 서적 JavaScript the Definitive Guide https://archive.org/[...] O'Reilly Media 2006-08-17
[28] 웹사이트 6.2 Server-sent DOM events http://www.whatwg.or[...] WHATWG 2008-10-07
[29] 웹사이트 The WebSocket API http://www.w3.org/TR[...] W3C 2009-07-21
[30] 웹사이트 Bayeux Protocol - Bayeux 1.0draft1. http://svn.cometd.or[...] Dojo Foundation 2007-12-14
[31] 웹사이트 JSONRequest Duplex http://www.json.org/[...] 2008-05-05
[32] 뉴스 Google App Engine Blog: Happy Holidays from the App Engine team - 1.4.0 SDK released http://googleappengi[...] 2014-04-12
[33] 뉴스 App Engine gets Streaming API and longer background tasks https://arstechnica.[...] 2014-04-12
[34] 웹사이트 Package com.google.appengine.api.channel https://cloud.google[...] 2020-04-30
[35] 웹인용 AJAX alliance recognizes mashups http://www.infoworld[...] InfoWorld 2007-09-24
[36] 서적 Comet and Reverse Ajax: The Next-Generation Ajax 2.0 Apress 2008-10-13
[37] 웹인용 Comet Programming: Using Ajax to Simulate Server Push https://web.archive.[...] Webreference.com 2010-10-20
[38] 연설 Ajax Push (a.k.a. Comet) with Java Business Integration (JBI) http://developers.su[...] Sun Microsystems, Inc. 2007-05-05
[39] 웹인용 Ajax Push http://www.icesoft.o[...] ICEfaces.org 2014-10-23
[40] 서적 Comet and Reverse Ajax: The Next Generation Ajax 2.0 Apress 2008-07
[41] 서적 Ajax Design Patterns 오라일리 미디어 2006-06
[42] 웹인용 More on Ajax and server push http://www.bluishcod[...] 2005-11-05
[43] 웹인용 The Slow Load Technique/Reverse AJAX https://web.archive.[...] 2005-11-01
[44] 웹인용 CometD Bayeux Ajax Push http://www.cometd.or[...]
[45] 웹인용 Comet: Low Latency Data for the Browser http://infrequently.[...] 2006-03-04


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com