혜성 (프로그래밍)

Comet (programming)

Comety는 오랜 기간 유지된 HTTPS 요청이 브라우저에 데이터를 푸시할 수 있도록 하는 웹 애플리케이션 모델이다.[1][2]혜성은 이 상호작용을 달성하기 위한 여러 기법을 포괄하는 우산 용어다.이러한 모든 방법은 기본이 아닌 플러그인이 아닌 자바스크립트와 같은 브라우저에서 기본적으로 포함된 기능에 의존한다.혜성 접근법은 브라우저가 한 번에 완전한 웹 페이지를 요청하는 웹의 원래 모델과는 다르다.[3]

웹 개발에 혜성 기법을 사용하는 것은 혜성이라는 단어를 집단 기법의 신조어로 사용하는 것보다 앞서 있다.혜성은 아약스 푸시,[4][5] 리버스 아약스,[6] 양방향 웹,[7] HTTP 스트리밍,[7] HTTP 서버 푸시[8] 등 여러 이름으로 알려져 있다.[9]혜성이라는 용어는 약어가 아니지만, 알렉스 러셀이 2006년 블로그 포스트 Comet: Low Latency Data for the Browser에서 만들었다.[10]

최근 몇 년 동안 WebSocket 및 Server-sent 이벤트의 표준화 및 광범위한 지원은 Comet 모델을 쓸모없게 만들었다.

역사

초기 자바 애플릿

자바 애플릿을 브라우저에 내장할 수 있는 능력(1996년[11] 3월 Netscape Navigator 2.0을 시작으로)은 원시 TCP[12] 소켓을 사용하여 브라우저와 서버 간의 통신을 통해 양방향 지속 통신이 가능하도록 했다.이 소켓은 브라우저가 애플릿을 호스팅하는 문서에 있는 한 열린 상태로 유지될 수 있다.이벤트 알림은 텍스트 또는 이진 형식에 관계없이 전송되며 애플릿으로 디코딩된다.

첫 번째 브라우저 간 통신 프레임워크

브라우저와 브라우저 간 통신을 사용한 최초의 애플리케이션은 Tango Interactive로,[13][failed verification] DARPA 자금후원을 이용하여 시러큐스 대학교의 NPAC(Northround Parallel Architectures Center)에서 1996-98년에 구현되었다.탱고 건축은 시러큐스 대학에서 특허를 얻었다.[14]탱고 프레임워크는 원거리 교육 도구로 널리 사용되어 왔다.[15]이 프레임워크는 CollaborWorx에 의해 상용화되었고 미국 국방부에서[citation needed] 십여 개의 Command&Control and Training 애플리케이션에서 사용되었다.

퍼스트 혜성 애플리케이션

첫 번째 Comet 구현 세트는 Pushlets, Lightstreamer 및 KnowNow 프로젝트와 함께 2000년으로 거슬러 올라간다.[16][unreliable source?]Just van den Broecke가 만든 프레임워크인 푸시렛은 최초의[17] 오픈 소스 구현 중 하나였다.푸시렛은 서버측 자바 서블릿과 클라이언트측 자바스크립트 라이브러리를 기반으로 했다.Netscape 공동 창업자 Marc Andreessen의 지원을 받는 실리콘 밸리의 스타트업인 Bang Networks는 웹 전체를 위한 실시간 푸시 표준을 만들기 위해 아낌없는 시도를 했다.[18]

2001년 4월, 칩 모닝스타는 Java 기반 (J2SE) 웹 서버를 개발하기 시작했는데, J2SE 웹 서버는 그가 디자인한 사용자 지정 HTTP 서버와 Douglas Crockford에 의해 디자인된 클라이언트 사이에 두 개의 통신 채널을 열어두기 위해 두 개의 HTTP 소켓을 사용했다. 2001년 6월 현재 기능하는 데모 시스템이 존재했다.[citation needed]서버와 클라이언트는 주 소프트웨어, 주식회사의 설립자들이 크록포드의 제안에 따라 JSON으로 코인하는 메시징 형식을 사용했다.전체 시스템, 클라이언트 라이브러리, 즉 JSON과 서버라고 알려진 메시징 형식은 State Application Framework가 되었고, 일부는 Sun Microsystems, Amazon.com, EDS, 폭스바겐이 판매하고 사용하였다.[citation needed]

2006년 3월 소프트웨어 엔지니어 알렉스 러셀은 자신의 개인 블로그에 올린 글에서 혜성이라는 용어를 만들었다.[19]새로운 용어는 아약스에 관한 연극이었다.[20][21][22]

2006년에 일부 애플리케이션은 이러한 기술을 더 많은 시청자들에게 노출하였다.미보의 멀티프로토콜 웹 기반 채팅 애플리케이션은 사용자가 브라우저를 통해 AOL, 야후, 마이크로소프트 채팅 플랫폼에 접속할 수 있게 했고, 구글은 Gmail에 웹 기반 채팅을 추가했으며, 구글이 인수한 이후 스타트업인 JotSpot은 혜성 기반의 실시간 협업 문서 편집을 구축했다.[23]Java 기반의 ICEfaces JSF 프레임워크와 같은 새로운 Comety 변형이 만들어졌다("Ajax Push"[5]라는 용어를 선호하지만).이전에 Java-Applet 기반 전송을 사용했던 다른 전송들은 대신 순수 JavaScript 구현으로 전환되었다.[24]

구현

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

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

스트리밍

스트리밍 Comet을 사용하는 애플리케이션은 모든 Comet 이벤트에 대해 클라이언트 브라우저에서 서버로 단일 영구 연결을 연다.이러한 이벤트는 서버가 새로운 이벤트를 전송할 때마다 클라이언트 측에서 점진적으로 처리되고 해석되며, 어느 쪽도 연결을 닫지 않는다.[3]

스트리밍 혜성 달성을 위한 구체적인 기법은 다음과 같다.

숨겨진 iframe

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

iframes 방법의 한 가지 이점은 모든 공통 브라우저에서 작동한다는 것이다.이 기법의 두 가지 단점은 신뢰성 있는 오류 처리 방법의 부재와 요청 호출 프로세스의 상태를 추적할 수 없다는 점이다.[26]

XMLHttpRequest

브라우저-서버 통신에 Ajax 응용프로그램이 사용하는 도구인 XMLHtpRequest(XHR) 오브젝트는 XHR 응답을 위한 사용자 정의 데이터 형식을 생성하고 브라우저 쪽 JavaScript를 사용하여 각 이벤트를 구문 분석하여 서버-브라우저 Cometer 메시징용으로도 사용할 수 있다.onreadystatechange새로운 데이터를 수신할 때마다 콜백(callback.

폴링이 긴 아약스

위의 스트리밍 전송 중 어떤 것도 부정적인 부작용 없이 현대의 모든 브라우저에서 작동하지 않는다.이것은 Comet 개발자들이 여러 개의 복잡한 스트리밍 전송을 실행하도록 강요하고, 브라우저에 따라 그것들 사이를 전환한다.결과적으로, 많은 Comet 애플리케이션은 브라우저 쪽에서 구현하기 더 쉬운 긴 폴링을 사용하며, 최소한 XHR을 지원하는 모든 브라우저에서 작동한다.이름에서 알 수 있듯이 긴 폴링에는 클라이언트가 이벤트(또는 이벤트 집합)에 대해 서버를 폴링해야 한다.브라우저는 서버에 Ajax 스타일의 요청을 하는데, Ajax 스타일의 요청은 서버가 브라우저로 전송할 새 데이터를 가질 때까지 열려 있으며, 완전한 응답으로 브라우저로 전송된다.브라우저는 후속 이벤트를 얻기 위해 새로운 긴 폴링 요청을 시작한다.IETF RFC 6202 "양방향 HTTP에서 긴 폴링 및 스트리밍 사용을 위한 알려진 문제와 모범 사례"는 긴 폴링과 HTTP 스트리밍을 비교한다.롱 폴링 달성을 위한 구체적인 기술은 다음과 같다.

XMLHttp긴 폴링 요청

대부분의 경우, XMLHttpRequest는 XHR의 표준 사용과 같은 긴 폴링이 작동한다.브라우저는 서버의 비동기식 요청을 하며, 응답하기 전에 데이터를 사용할 수 있을 때까지 기다릴 수 있다.응답은 클라이언트가 실행할 암호화된 데이터(일반적으로 XML 또는 JSON) 또는 Javascript를 포함할 수 있다.응답 처리가 끝나면 브라우저는 다음 이벤트를 기다리기 위해 또 다른 XHR을 만들어 보낸다.따라서 브라우저는 항상 서버에서 미결 요청을 유지하여 각 이벤트가 발생할 때 응답한다.

스크립트 태그 긴 폴링

Comet 전송은 하위 도메인 전체에 걸쳐 작동하도록 만들 수 있지만, 사이트 간 스크립팅 공격을 방지하도록 설계된 브라우저 보안 정책 때문에 위의 전송 중 다른 2차 도메인(SLD)에 걸쳐 사용할 수 있는 것은 없다.[27]즉, 메인 웹 페이지가 한 SLD로부터 제공되고, Cometer 서버가 다른 SLD에 위치하는 경우(교차 오리진 자원 공유가 활성화되지 않은 경우), 해당 전송을 사용하여 메인 페이지의 HTML과 DOM을 수정하는 혜성 이벤트를 사용할 수 없다.이 문제는 하나 또는 두 소스 앞에 프록시 서버를 만들어 동일한 도메인에서 발생한 것처럼 보이게 함으로써 피할 수 있다.그러나 이는 복잡성이나 성능상의 이유로 바람직하지 않은 경우가 많다.

iframes 또는 XMLHtpRequest 객체와 달리,script태그는 모든 URI를 가리킬 수 있으며, 응답의 자바스크립트 코드는 현재 HTML 문서에서 실행될 것이다.이는 데이터 제공자(우리의 경우 Comety 서버)에 대한 위험을 JSONP를 사용하여 피할 수 있지만, 관련된 두 서버 모두에 잠재적인 보안 위험을 발생시킨다.

긴 대기 혜성 수송은 동적으로 창조함으로써 만들어질 수 있다.script요소 및 해당 소스를 Comet 서버 위치로 설정한 다음 JavaScript(또는 JSONP)를 페이로드로 다시 전송한다.스크립트 요청이 완료될 때마다 브라우저는 XHR 긴 폴링 케이스와 마찬가지로 새 폴링 요청을 연다.이 방법은 교차 도메인 구현을 허용하면서 크로스 브라우저라는 장점이 있다.[27]

대안

브라우저 고유 기술은 혜성이라는 용어에 내재되어 있다.비 폴링 HTTP 통신을 개선하려는 시도는 다방면에서 나왔다.

  • WHTWG(Web Hypertext Application Technology Working Group)에서 작성한 HTML 5 초안 사양은 새로운 JavaScript 인터페이스를 정의하는 소위 서버 송신 이벤트를 지정한다.[28]EventSource그리고 새로운 MIME 유형text/event-stream마이크로소프트 Internet Explorer를 제외한 모든 주요 브라우저에는 이 기술이 포함되어 있다.
  • HTML 5WebSocket API 작업 초안은 서버와의 지속적인 연결을 만들고 메시지를 수신하는 방법을 지정한다.onmessage콜백[29]
  • 도조 재단의 바이룩스 의정서.여러 Comety 서버와 클라이언트측 JavaScript 코드의 재사용을 허용하고, 동일한 Comet 서버가 여러 클라이언트측 JavaScript 구현과 통신할 수 있도록 하는 것을 목적으로, 브라우저와 서버 간의 통신을 위한 상위 수준의 프로토콜을 정의한다.바이룩스는 게시/구독 모델을 기반으로 하기 때문에 바이룩스를 지원하는 서버에는 게시/구독이 내장되어 있다.[30]
  • XMPP 표준 기반에 의한 BOSH 프로토콜.두 개의 동기식 HTTP 연결을 사용하여 브라우저와 서버 사이의 양방향 스트림을 에뮬레이션한다.
  • 더글러스 크록포드가 제안한 JSONRequest 객체는 XHR 객체에 대한 대안이 될 것이다.[31]
  • Java 애플릿 또는 독점 Adobe Flash와 같은 플러그인 사용(플래시 애플리케이션으로 데이터를 스트리밍하는 데 RTMP 프로토콜 사용)이들은 적절한 플러그인이 설치된 모든 브라우저에서 동일하게 작동할 수 있는 이점이 있으며 HTTP 연결에 의존할 필요가 없고 플러그인의 설치를 요구할 수 있는 단점이 있다.
  • 구글은 구글 앱엔진을 위한 새로운 채널 API를 발표하면서[32] 브라우저에 클라이언트 자바스크립트 라이브러리의 도움을 받아 Comety 유사 API를 구현했다.[33]이 API는 더 이상 사용되지 않는다.[34]

참고 항목

참조

  1. ^ Krill, Paul (September 24, 2007). "AJAX alliance recognizes mashups". InfoWorld. Retrieved 2010-10-20.
  2. ^ Crane, Dave; McCarthy, Phil (October 13, 2008). Comet and Reverse Ajax: The Next-Generation Ajax 2.0. Apress. ISBN 978-1-59059-998-3.
  3. ^ a b Gravelle, Rob. "Comet Programming: Using Ajax to Simulate Server Push". Webreference.com. Archived from the original on 2010-10-18. Retrieved 2010-10-20.
  4. ^ Egloff, Andreas (2007-05-05). Ajax Push (a.k.a. Comet) with Java Business Integration (JBI) (Speech). JavaOne 2007, San Francisco, California: Sun Microsystems, Inc. Retrieved 2008-06-10.{{cite speech}}: CS1 maint : 위치(링크)
  5. ^ a b "Ajax Push". ICEfaces.org. Retrieved 2014-10-23.
  6. ^ Crane, Dave; McCarthy, Phil (July 2008). Comet and Reverse Ajax: The Next Generation Ajax 2.0. Apress. ISBN 1-59059-998-5.
  7. ^ a b Mahemoff, Michael (June 2006). "Web Remoting". Ajax Design Patterns. O'Reilly Media. pp. 19, 85. ISBN 0-596-10180-5.
  8. ^ Double, Chris (2005-11-05). "More on Ajax and server push". Different ways of doing server push. Retrieved 2008-05-05.
  9. ^ Nesbitt, Bryce (2005-11-01). "The Slow Load Technique/Reverse AJAX". Simulating Server Push in a Standard Web Browser. Archived from the original on 2006-02-08. Retrieved 2008-05-06.
  10. ^ Russell, Alex (2006-03-04). "Comet: Low Latency Data for the Browser". Retrieved 2014-11-02.
  11. ^ "Netscape.com". Archived from the original on November 15, 1996. Retrieved 2017-08-16.{{cite web}}: CS1 maint : bot : 원본 URL 상태 미상(링크)
  12. ^ "java.net.소켓(Java 2 플랫폼 SE v1.4.2)" 2009년 5월 19일 웨이백 머신에 보관
  13. ^ Beca, Lukasz (1997). "TANGO - a Collaborative Environment for the World-Wide Web". Syracuse University SURFACE. Northeast Parallel Architecture Center, College of Engineering and Computer Science. Retrieved 27 February 2016.
  14. ^ Podgorny, Marek; Beca, Lukasz; Cheng, Gang; Fox, Geoffrey C.; Jurga, Tomasz; Olszewski, Konrad; Sokolowski, Piotr; Walczak, Krzysztof; PL (June 20, 2000), United States Patent: 6078948 - Platform-independent collaboration backbone and framework for forming virtual communities having virtual rooms with collaborative sessions, retrieved 2016-02-27
  15. ^ Baer, Troy (1999). "Experiences with Using TANGO Interactive in a Distributed Workshop" (PDF). CEWES Major Shared Resource Center. CEWES MSRC/PET TR/99-21. Retrieved 27 February 2016.
  16. ^ "CometDaily: Comet and Push Technology". Archived from the original on 2007-11-13. Retrieved 2007-12-15.
  17. ^ just van den Broecke (2000년 3월 1일)"Pushlets: servlet에서 DHTML 클라이언트 브라우저로 이벤트 전송"자바월드.2014년 8월 1일 검색됨
  18. ^ Borland, John (2001-04-01). "Will the "refresh" button become obsolete?". CNET Networks. Retrieved 2008-07-22.
  19. ^ 알렉스 러셀(2006년 3월 3일)."Comet: Wayback Machine에 보관된 2008-08-12 브라우저용 짧은 대기 시간 데이터"알렉스 러셀의 블로그야2007년 11월 29일 회수.
  20. ^ K. Taft, Darryl (2006-05-12). "Microsoft Scrubs Comet from AJAX Tool Set". eWEEK.com. Retrieved 2008-07-21.
  21. ^ 궤도:대중을 위한 혜성 구현: OSCON 2008 - O'Reilly Conference, 2008년 7월 21일 - 25일, 포틀랜드, 오리건 주
  22. ^ Wayback Machine에 보관된 Enterprise Comet & Web 2.0 라이브 프레젠테이션 2008-05-20
  23. ^ 디온 알마이어(2005년 9월 29일).'조트스팟 라이브: 라이브, 단체 노트 테이킹'(아베 페티그 인터뷰)아약시안의2007년 12월 15일 회수.
    맷 마셜(2006년 12월 15일)."렌쿠는 휴일 칵테일을 예약하는 시간에 맞춰 이벤트 서비스를 시작한다."벤처 비트.2007년 12월 15일 회수.
  24. ^ 클린트 볼턴(2005년 12월 27일)."스타트업자들은 AJAX 시류에 편승한다."데브엑스 뉴스.2008년 2월 18일 회수
  25. ^ 하이퍼텍스트 전송 프로토콜(HTTP/1.1):메시지 구문 및 라우팅, 섹션 6.4. IETF.검색된 2014-07-29
  26. ^ a b Holdener III, Anthony T. (January 2008). "Page Layout with Frames that Aren't". Ajax: The Definitive Guide. O'Reilly Media. p. 320. ISBN 0-596-52838-8.
  27. ^ a b Flanagan, David (2006-08-17). "13.8.4 Cross-Site Scripting". JavaScript the Definitive Guide. The Definitive Guide. O'Reilly Media. p. 994. ISBN 0-596-10199-6.
  28. ^ Ian Hickson, ed. (2007-10-27). "6.2 Server-sent DOM events". HTML 5 - Call For Comments. WHATWG. Retrieved 2008-10-07.
  29. ^ Hickson, Ian (2009-04-23). "The WebSocket API". W3C. Retrieved 2009-07-21.
  30. ^ Alex Russell; et al. (2007). "Bayeux Protocol - Bayeux 1.0draft1". Dojo Foundation. Retrieved 2007-12-14.
  31. ^ Crockford, Douglas (2006-04-17). "JSONRequest Duplex". An alternative to XMLHttpRequest for long lasting server initiated push of data. Retrieved 2008-05-05.
  32. ^ 앱, 더. (2010-12-02) 구글 앱 엔진 블로그: 앱 엔진 팀의 해피 홀리데이 - 1.4.0 SDK 출시구글앱엔진.blogspot.com2014-04-12년에 검색됨
  33. ^ Paul, Ryan. (2010-12-06) App Engine은 스트리밍 API와 더 긴 백그라운드 작업을 얻는다.아르스 테크니카.2014-04-12년에 검색됨
  34. ^ "Package com.google.appengine.api.channel". Google. 2019-11-16. Retrieved 2020-04-30. This API has been deprecated.

외부 링크