사용자:Laen0k

위키백과, 우리 모두의 백과사전.

Comet은 브라우저의 명시적 요청없이 long-held HTTP 요청으로 웹 서버가 브라우저에 데이타를 push하는 웹 애플리케이션 모델이다.[1][2] Comet은 이러한 통신을 구현하기 위한 복합적인 기술들을 망라하는 포괄적 개념이다. 이런 모든 기능들은 추가적인 플러그인들보다는 자바스크립트와 같이 브라우저에 기본적으로 포함된 구성을 따른다. Comet은 브라우저가 완성된 웹 페이지를 한번에 요청하는 기존 웹 모델과는 다르게 접근한다. [3]

웹 개발에서 Comet 기술의 사용은 공통적인 기술을 위한 신조어로서의 Comet이란 단어의 사용보다 앞선다. Comet은 Ajax Push,[4][5] Reverse Ajax,[6] Two-way-web,[7] HTTP Streaming,[7] and HTTP server push[8] 와 그외의 것[9] 등을 포함한 몇가지 다른 이름으로 알려져왔다.

적용[편집]

Comet 애플리케이션은 서버와 클라이언트 사이에 오래 지속되는 HTTP 연결을 사용하여 page-by-page 웹 모델과 실시간 통신 제공에 의한 전통적인 폴링의 한계를 제거하려고 시도했다. 브라우져와 프록시가 서버 이벤트를 고려하여 설계되지 않은 이후로, 몇가지 기술들은 이런식으로 개발되어져 왔다(이득과 문제점과는 다르다) - 역자주: 기술적인 이득과 손해의 관점이 아니라 HTTP자체로는 구현 불가능한 문제점이라고 표현한 것으로 보여짐. 가장 큰 장애물은 한 브라우저가 웹 서버와 둘 이상의 동시 연결을 하지않아야 한다고 언급한 HTTP 1.1 표준이다.[10] 그 결과, 실시간 이벤트에 대해 하나의 연결만을 유지하는 것은 브라우저 사용시에 부정적인 영향을 끼친다: 예를들면 연속된 이미지의 경우 브라우저가 이전의 요청결과에 대해 기다리는 동안 새로운 요청을 전송하면 차단될 것이다.

이러한 동일한 물리적 서버에 대한 정의는 실시간 정보로 인한 명백한 호스트명 생성을 우회 처리하게 될 수 있다.

Comet을 적용하는 특수한 기술은 두가지 주요 항목으로 귀결된다: 스트리밍과 롱 폴링


스트리밍[편집]

스트리밍 Comet을 사용하는 어플리케이션은 모든 Comet이벤트에 대해 클라이언트 브라우저에서 서버로 하나의 지속적 연결만을 열어둔다. 매시간 서버가 새로운 이벤트를 보내는(닫혀진 측도 마찬가지) 이런 이벤트는 클라이언트측에서의 처리와 해석을 증가시킨다.[3]

다음에 포함된 것들은 스트리밍 Comet을 완성하기 위한 특수한 기술들이다.

숨겨진 아이프레임(iframe)[편집]

동적인 웹 애플리케이션을 위한 기초적인 기술은 숨겨진 아이프레임 HTML 요소(웹사이트가 HTML문서를 다른문서 안에 끼워넣는것을 허용하는 inline frame)를 사용하는 것이다. 무한정으로 오래가도록(종종 "영구한 프레임"으로 불린다) 암묵적으로 선언한 이 무형의 아이프레임(iframe)은 뭉쳐진 블록으로 전송된다. 이벤트가 발생하면 아이프레임(iframe)은 점차 브라우저에서 실행되는 자바스크립트를 포함하는 <코드>스크립트</코드> 태그들로 채워진다. 브라우저가 HTML 페이지를 계속 만들어내기 때문에 각 스크립트 태그는 받은대로 실행된다. [11][11]

아이프레임(iframe) 기능의 한가지 이점은 일반적인 모든 브라우저에서 작동한다는 것이다. 이 기술의 부정적측면은 신뢰할만한 오류 처리 기능이 부족하고, 프로세스를 호출하는 요청의 상태를 추적하는것이 불가능하다는 것이다. [11]

XMLHttpRequest[편집]

XMLHttpRequest (XHR) 개체, the main tool used by Ajax applications for browser–server communication, can also be pressed into service for server–browser Comet messaging, in a few different ways. 주요 도구는 브라우저를 위한 Ajax 애플리케이션으로 사용한다 - 서버 통신, 또한 서버를위한 서비스내에서 압력을 받는 - 브라우저 Comet 메세징, 조금 다른 방법의

In 1995, Netscape Navigator added a feature called “server push”, which allowed servers to send new versions of an image or HTML page to that browser, as part of a multipart HTTP response (see History section, below), using the content type multipart/x-mixed-replace. 1995년 넷츠케이프 네비게이터는 “서버 푸쉬”라고 불리는 구성을 추가했다. 서버가 이미지의 새로운 버전이나 HTML 페이지를 부라우저에 보내는것을 허용하는 것이다. [[다중부분}} HTTP 응답 (), 문장 형식 <코드>multipart/x-mixed-replace</코드>를 사용한다. Since 2004, Gecko-based browsers such as Firefox accept multipart responses to XHR, which can therefore be used as a streaming Comet transport. 2004년 이후 Firefox같은 Gecko-기반 브라우저는 XHR에 다중부분 응답을 채용했다. 그 결과 스트리밍 Comet 전송으로 사용될수 있다.[12] On the server side, each message is encoded as a separate portion of the multipart response, and on the client, the callback function provided to the XHR onreadystatechange function will be called as each message arrives. This functionality is only included in Gecko-based browsers, though there is discussion of adding it to WebKit.[13]

Instead of creating a multipart response, and depending on the browser to transparently parse each event, it is also possible to generate a custom data format for an XHR response, and parse out each event using browser-side JavaScript, relying only on the browser firing the onreadystatechange callback each time it receives new data. 멀티파트 응답을 생성하는 대신, 각 이벤트를 투명하게 분석하는 브라우저상에 의존하고, 또한 XHR 응답을 위한 맞춤 데이타 형식을 생성을 가능하게 하고, 브라우저 측 자바스크립트를 사용하는 각 이벤트를 분석해내고, 매시간 새로운 데이타를 받아 호출하는 <코드>준비된 상태변화</코드>를 버리고 오직 브라우저에 의한다.

Ajax with 롱 폴링[편집]

부정적 측면 없이 현존하는 모든 브라우저에서 작동하는 스트리밍 전송은 없다. 이러한 점이 브라우저에 의존하는 것들을 서로 전환시키는 몇가지 복잡한 스트리밍 전송을 적용하도록 Comet 개발자들을 종용한다. 동시에 많은 Comet 애플리케이션들은 롱 폴링을 사용한다, 이것은 브라우저 측에 적용하기 쉽다, 그리고 잘 작동한다, 최소한으로, XHR을 지원하는 모든 브라우저. 이름을 제의하는 것으로 롱 폴링은 이벤트를 위한 클라이언트의 서버 폴을 요구한다 (혹은 이벤트의 모음). 브라우저는 Ajax-스타일이 서버에 요청하는 것을 만든다, 서버가 브라우저에 새로운 데이타를 보낼때까지 열어둔다, 이것은 안료된 응답내에 브라우저에 보낸다. 브라우저는 다음 이벤트를 입수하기 위해서 새로운 롱 폴링 요청을 개시한다.

다음에 포함된 것들은 롱 폴링을 완성시키기 위한 명시된 기술들이다.

XMLHttpRequest 롱 폴링[편집]

대부분 XMLHttpRequest 롱 폴링은 XHR의 어떤 표준적 쓰임처럼 작동한다. 브라우저는 서버의 비동기적인 요청을 만든다, 이것은 응답전 유용한 데이타를 기다릴 것이다. 응답은 암호화된(전형적인 XML 또는 JSON) 데이타나 클라이언트에 의해 실행되는 자바스크립트를 포함 할 수 있다. 응답 처리의 마지막에 브라우저는 다음 이벤트를 기다리며 또다른 XHR을 생성하고 보낸다. 그러므로 브라우저는 서버와 더불어 각 이벤트 발생에 대응하는 미처리된 요청을 항상 유지한다.

스크립트 태그 롱 폴링[편집]

어떠한 Comet 전송이 서브도메인 전체에 작동하게 만들수 있는 반면, 크로스 사이트 스크립팅 공격을 예방하도록 설계된 브라우저 보안 정책인 다른 2차도메인(SLD) 전역에 걸친 전송에는 사용 될 수 없다.[14]만약 주요 웹 페이지가 하나의 2차 도메인으로부터 또다른 2차 도메인에 위치한 Comet server로 넘겨지면 이런 전송들을 사용하는 Comet 이벤트가 주요 페이지의 HTML과 DOM을 수정하는데 사용될 수 없을 것이다. 이 문제는 한쪽 또는 두쪽에 동일 도메인으로부터 비롯되어 나타난 것들을 만드는 프록시 서버를 만들어 피할 수 있다. 그러나 이것은 복잡성과 성능 때문에 일반적으로 바람직하지는 않다.

아이프레임(iframe)이나 XMLHttpRequest 개체와는 다른, <코드>스크립트 태그는 어떠한 URI에서든 지적될 수 있다, 응답에서의 자바스크립트 코드는 현재 HTML 문서에서 실행될 것이다. 이것은 서버와 뒤엉켜 양쪽다 잠재적 보안 위험을 만든다, JSONP를 사용하여 데이타 제공시에 위험성을 피할 수 있을지라도.

롱 폴링 Comet 전송은 <코드>스크립트</코드> 요소 생성을 동적으로 만들어낼 수 있다, Comet 서버에 위치한 그 원본을 설정, 몇가지의 이벤트를 포함한 해당 적재비용을 포함한 자바스크립트의 되돌려 보내기. 매 시간 스크립트 요청은 완료된다, 브라우저는 새로 열어두고, XHR 롱 폴링 설정에 바로. 이 기능은 크로스 도메인 실행을 허용하는 동안에는 크로스 브라우저의 이점을 가진다.[14]

History[편집]

Early Java applets[편집]

The ability to embed Java applets into browsers (starting with Netscape 2.0 in March 1996[15]) made real-time communications possible, using a raw TCP socket[16] to communicate between the browser and the server. This socket can remain open as long as the browser is at the document hosting the applet. Event notifications can be sent in any format — text or binary — and decoded by the applet.

First Comet applications[편집]

In March 2006, software engineer Alex Russell coined the term Comet in a post on his personal blog.[17] The new term was a play on Ajax (Ajax and Comet both being household cleaners common in the USA).[18][19][20]

In 2006, while not really using the term Comet, some applications exposed those techniques to a wider audience: Meebo’s multi-protocol web-based chat application enables users to connect to AOL, Yahoo, and Microsoft chat platforms through the browser; Google added web-based chat to Gmail; JotSpot, a startup since acquired by Google, built Comet-based real-time collaborative document editing.[21] New Comet companies and enterprise solutions were created, such as the Java-based ICEfaces JSF framework (although they prefer the term "Ajax Push"[5]). Others that had previously used Java-applet based transports switched instead to pure-JavaScript implementations.[22]

Alternatives[편집]

Browser-native technologies are inherent in the term Comet. Attempts to improve non-polling HTTP communication have come from multiple sides:

  • The HTML 5 draft specification produced by the Web Hypertext Application Technology Working Group (WHATWG) specifies so called server-sent events,[23] which defines a new Javascript interface EventSource and a new MIME type text/event-stream. Experimental implementation of this feature was introduced in Opera 9.[24]
  • The HTML 5 WebSocket API working draft specifies a method for creating a persistent connection with a server and receiving messages via an onmessage callback.[25]
  • The Bayeux protocol by the Dojo Foundation. It leaves browser-specific transports in place, and defines a higher-level protocol for communication between browser and server, with the aim of allowing re-use of client-side JavaScript code with multiple Comet servers, and allowing the same Comet server to communicate with multiple client-side JavaScript implementations. Bayeux is based on a publish/subscribe model, so servers supporting Bayeux have publish/subscribe built-in.[26]
  • The BOSH protocol by the XMPP standards foundation. It emulates a bidirectional stream between browser and server by using two synchronous HTTP connections.
  • The JSONRequest object, proposed by Douglas Crockford, would be an alternative to the XHR object.[27]
  • Use of plugins, such as Java applets or the proprietary Adobe Flash (Java BlazeDS is a server plugin which streams events to Flash applications). These have the advantage of working identically across all browsers with the appropriate plugin installed and need not rely on HTTP connections, but the disadvantage of requiring the plugin to be installed
  • Google announced[28] a new Channel API for Google App Engine,[29] implementing a Comet-like API with the help of a client Javascript library on the browser. It could be later replaced by HTML5 WebSockets, however.

See also[편집]

References[편집]

  1. ↑ Krill, Paul (2007년 9월 24일). “AJAX alliance recognizes mashups”. InfoWorld. 2010년 10월 20일에 확인함. 
  2. ↑ Crane, Dave; McCarthy, Phil (2008년 10월 13일). 《Comet and Reverse Ajax: The Next-Generation Ajax 2.0》. Apress. ISBN 978-1590599983. 
  3. ↑ 가 나 Gravelle, Rob. “Comet Programming: Using Ajax to Simulate Server Push”. Webreference.com. 2010년 10월 20일에 확인함. 
  4. ↑ Egloff, Andreas (2007년 5월 5일). 《Ajax Push (a.k.a. Comet) with Java Business Integration (JBI)》 (연설). JavaOne 2007, San Francisco, California: Sun Microsystems, Inc. 2008년 6월 10일에 확인함. 
  5. ↑ 가 나 “Ajax Push”. ICEfaces.org. 2008년 7월 21일에 확인함. 
  6. ↑ Crane, Dave; McCarthy, Phil (2008년 7월). 《Comet and Reverse Ajax: The Next Generation Ajax 2.0》. Apress. ISBN 1590599985. 
  7. ↑ 가 나 Mahemoff, Michael (2006년 6월). 〈Web Remoting〉. 《Ajax Design Patterns》. O'Reilly Media. 19; 85쪽. ISBN 0596101805. 
  8. ↑ Double, Chris (2005년 11월 5일). “More on Ajax and server push”. 《Different ways of doing server push》. 2008년 5월 5일에 확인함. 
  9. ↑ Nesbitt, Bryce (2005년 11월 1일). “The Slow Load Technique/Reverse AJAX”. 《Simulating Server Push in a Standard Web Browser》. 2008년 5월 5일에 확인함. 
  10. ↑ HTTP 1.1 specification, section 8.1.4. W3C. Retrieved 30 November 2007
  11. ↑ 가 나 Holdener III, Anthony T. (2008년 1월). 〈Page Layout with Frames that Aren't〉. 《Ajax: The Definitive Guide》. O'Reilly Media. 320쪽. ISBN 0596528388. 
  12. ↑ Johnny Stenback, et al. (March–April 2004). “Bug 237319 – Add support for server push using multipart/x-mixed-replace with XMLHttpRequest”. Mozilla bug tracking. Retrieved 29 November 2007. Also see:
    Alex Russell (6 August 2005). “Toward server-sent data w/o iframes”. Alex Russell’s blog. Retrieved 29 November 2007.
  13. ↑ Rob Butler, et al. (June 2006). “Bug 14392: Add support for multipart/x-mixed-replace to XMLHttpRequest”. Webkit bug tracking. Retrieved 29 November 2007.
  14. ↑ 가 나 Flanagan, David (2006년 8월 17일). 〈13.8.4 Cross-Site Scripting〉. 《JavaScript the Definitive Guide》. The Definitive Guide. O'Reilly Media. 994쪽. ISBN 0596101996. 
  15. ↑ http://web.archive.org/web/19961115203505/www27.netscape.com/comprod/products/navigator/version_2.0/index.html Netscape.com from 1996 (via Archive.org)
  16. ↑ http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html
  17. ↑ Alex Russell (3 March 2006). “Comet: Low Latency Data for the Browser”. Alex Russell’s blog. Retrieved 29 November 2007.
  18. ↑ K. Taft, Darryl (2006년 5월 12일). “Microsoft Scrubs Comet from AJAX Tool Set”. eWEEK.com. 2008년 7월 21일에 확인함. 
  19. ↑ Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon
  20. ↑ Enterprise Comet & Web 2.0 Live Presentation
  21. ↑ Dion Almaer (29 September 2005). “Jotspot Live: Live, group note-taking” (interview with Abe Fettig). Ajaxian. Retrieved 15 December 2007.
    Matt Marshall (15 December 2006). “Renkoo launches event service — in time to schedule holiday cocktails”. Venture Beat. Retrieved 15 December 2007.
  22. ↑ Clint Boulton (27 December 2005). “Startups Board the AJAX Bandwagon”. DevX News. Retrieved 18 February 2008.
  23. ↑ Ian Hickson, 편집. (2007년 10월 27일). “6.2 Server-sent DOM events”. 《HTML 5 - Call For Comments》. WHATWG. 2008년 10월 7일에 확인함. 
  24. ↑ Bersvendsen, Arve (2006년 9월 1일). “Event Streaming to Web Browsers”. Opera Software. 2009년 6월 1일에 확인함. 
  25. ↑ Hickson, Ian (2009년 4월 23일). “The Web Sockets API”. w3c. 2009년 7월 21일에 확인함. 
  26. ↑ Alex Russell; 외. (2007). “Bayeux Protocol - Bayeux 1.0draft1.”. Dojo Foundation. 2007년 12월 14일에 확인함. 
  27. ↑ Crockford, Douglas (2006년 4월 17일). “JSONRequest Duplex”. 《An alternative to XMLHttpRequest for long lasting server initiated push of data》. 2008년 5월 5일에 확인함. 
  28. ↑ http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html
  29. ↑ http://arstechnica.com/web/news/2010/12/app-engine-gets-streaming-api-and-longer-background-tasks.ars

External links[편집]

원본 주소 "https://ko.wikipedia.org/w/index.php?title=사용자:Laen0k&oldid=8320686"