푸시 기술

Push technology

푸시 기술(Push technology) 또는 서버 푸시(server push)는 특정 트랜잭션에 대한 요청이 게시자 또는 중앙 서버에 의해 시작되는 인터넷 기반 통신의 한 유형입니다.수신자 또는 [1]클라이언트에 의해 정보 전송 요청이 시작되는 pull, 즉 get과 대조됩니다.

푸시 서비스는 종종 게시-구독 모델이라고 불리는 미리 표현된 정보와 데이터 선호도에 기반을 둡니다.클라이언트는 서버가 제공하는 다양한 정보 채널에 "가입"합니다. 이러한 채널 중 하나에서 새로운 컨텐츠를 사용할 수 있을 때마다 서버는 해당 정보를 클라이언트에게 "밀어내"거나 "게시"합니다.

푸시는 특히 들어오는 HTTP 요청을 거부하는 보안 정책이 있는 사이트와 같이 실제 푸시가 불가능한 경우에는 폴링 기법으로 에뮬레이트되기도 합니다.

일반용

푸시 서비스의 예로는 동기식 회의 및 인스턴트 메시징이 있습니다.채팅 메시지와 때때로 파일은 메시징 서비스에 의해 수신되자마자 사용자에게 푸시됩니다.분산형 피어 투 피어 프로그램(WAST 등)과 중앙 집중형 프로그램(IRC 또는 XMPP 등) 모두 파일 푸시를 허용하므로, 수신자가 아닌 송신자가 데이터 전송을 시작합니다.

전자 메일은 푸시 시스템일 수도 있습니다. SMTP는 푸시 프로토콜입니다( 푸시 전자 메일 참조).그러나 메일 서버에서 데스크톱 컴퓨터로 이어지는 마지막 단계는 일반적으로 POP3 또는 IMAP과 같은 풀 프로토콜을 사용합니다.현대의 전자 메일 클라이언트는 메일 서버를 반복적으로 폴링하고 새 메일을 자주 확인함으로써 이 단계가 즉각적인 것처럼 보이게 합니다.IMAP 프로토콜에는 IDLE 명령어가 포함되어 있어 서버는 새로운 메시지가 도착할 때 클라이언트에게 이를 알릴 수 있습니다.원래 BlackBerry는 무선 [citation needed]컨텍스트에서 푸시 이메일의 첫 번째 인기 있는 예였습니다.

또 다른 예로는 1990년대에 널리 다루어진 포인트캐스트 네트워크가 있습니다.뉴스와 주식시장 데이터를 스크린세이버로 전달했습니다.넷스케이프와 마이크로소프트 둘 다 브라우저 전쟁이 한창일 때 CDF(Channel Definition Format)를 통해 푸시 기술을 소프트웨어에 통합했지만 결코 인기가 없었습니다.CDF는 사라지고 당시 브라우저에서 삭제되어 2000년대에 RSS(pull system)로 대체되었습니다.

푸시 가능 웹 애플리케이션의 다른 용도로는 소프트웨어 업데이트 배포("푸시 업데이트"), 시장 데이터 배포(주식 티커), 온라인 채팅/메시지 시스템(웹챗), 경매, 온라인 베팅 및 게임, 스포츠 결과, 콘솔 모니터링 및 센서 네트워크 모니터링 등이 있습니다.

예

웹 푸시

인터넷 엔지니어링 태스크 포스의 웹 푸시 제안은 HTTP 버전 2를 사용하여 적시에 전달(또는 "푸시")할 수 있는 수신 전화나 메시지와 같은 실시간 이벤트를 전달하는 간단한 프로토콜입니다.이 프로토콜은 모든 실시간 이벤트를 단일 세션으로 통합하여 네트워크 및 무선 자원의 보다 효율적인 사용을 보장합니다.단일 서비스는 모든 이벤트를 통합하여 해당 이벤트를 애플리케이션에 제공합니다.이를 위해서는 한 [2]번의 세션만 필요하므로 중복적인 오버헤드 비용을 피할 수 있습니다.

웹 알림은 W3C 표준의 일부이며 최종 사용자 알림을 위한 API를 정의합니다.알림을 사용하면 웹 페이지의 컨텍스트 [3]밖에서 전자 메일 배달과 같은 이벤트를 사용자에게 알릴 수 있습니다.이 표준의 일환으로, Push API는 Chrome, Firefox, Edge에서 완전히 구현되며,[4][5] 2023년 2월 현재 Safari에서 부분적으로 구현됩니다.

HTTP 서버 푸시

HTTP 서버 푸시(Http server push, HTTP streaming)는 웹 서버에서 웹 브라우저로 요청되지 않은(비동기) 데이터를 전송하기 위한 메커니즘입니다.HTTP 서버 푸시는 여러 메커니즘 중 하나를 통해 달성할 수 있습니다.

HTML5의 일부로서 웹 소켓 API는 웹 서버와 클라이언트가 전이중 TCP 연결을 통해 통신할 수 있게 해줍니다.

일반적으로 웹 서버는 클라이언트에게 응답 데이터가 제공된 후 연결을 종료하지 않습니다.웹 서버는 이벤트가 발생한 경우(예: 하나 또는 여러 클라이언트에 보고해야 하는 내부 데이터 변경) 즉시 전송할 수 있도록 연결을 열어 둡니다. 그렇지 않으면 클라이언트의 다음 요청이 수신될 때까지 이벤트가 대기열에 있어야 합니다.대부분의 웹 서버는 CGI(예: Apache HTTP Server의 Non-Parse Headers 스크립트)를 통해 이 기능을 제공합니다.이 방법의 기본 메커니즘은 청크 전송 인코딩입니다.

다른 메커니즘은 다음과 같은 특별한 MIME 유형과 관련이 있습니다.multipart/x-mixed-replace, 그것은 1995년 넷스케이프에 의해 소개되었습니다.웹 브라우저는 서버가 [6]클라이언트에 새로운 버전을 푸시할 때마다 변경되는 문서로 해석합니다.오늘날에도 Firefox, Opera 및 Safari에서 여전히 지원되지만 Internet[7] Explorer에서는 무시되며 부분적으로만 [8]Chrome에서 지원됩니다.HTML 문서 및 웹캠 어플리케이션의 스트리밍 이미지에도 적용할 수 있습니다.

WHATWG Web Applications 1.0[9] 제안에는 클라이언트에 컨텐츠를 푸시하는 메커니즘이 포함되어 있습니다.2006년 9월 1일 오페라 웹 브라우저는 이 새로운 실험 시스템을 "Server-Sent Events"[10][11]라는 기능으로 구현했습니다.그것은 이제 HTML5 [12]표준의 일부입니다.

푸슬렛

이 기법에서 서버는 지속적인 HTTP 연결을 이용하여 응답을 지속적으로 "열린" 상태로 유지하며(즉, 서버는 응답을 절대 종료하지 않음), 초기 페이지 로드가 완료된 것으로 간주된 후 브라우저를 "로딩" 모드로 유지하도록 효과적으로 속입니다.그런 다음 서버는 페이지 내용을 업데이트하기 위해 주기적으로 자바스크립트의 스니펫을 전송하여 푸시 기능을 달성합니다.이 기술을 사용하면 클라이언트는 서버에 열린 연결을 유지하기 위해 Java 애플릿이나 기타 플러그인을 필요로 하지 않습니다. 클라이언트는 서버에 의해 [13][14]자동으로 새로운 이벤트에 대해 알려지게 됩니다.그러나 이 방법의 한 가지 심각한 단점은 서버가 브라우저 타이밍 타임아웃을 제어하지 못한다는 것입니다. 브라우저 끝에서 타임아웃이 발생하면 항상 페이지 새로 고침이 필요합니다.

롱 폴링

롱 폴링은 그 자체로 진정한 푸시가 아닙니다. 롱 폴링은 전통적인 폴링 기법의 변형이지만, 들어오는 HTTP 요청을 거부해야 하는 보안 정책이 있는 사이트와 같이 실제 푸시가 불가능한 상황에서는 푸시 메커니즘을 에뮬레이트할 수 있습니다.

폴링이 긴 경우, 클라이언트는 일반 폴링과 동일하게 서버에 정보를 요청하지만 서버가 즉시 응답하지 않을 수 있습니다.폴링이 수신될 때 서버에 클라이언트에 대한 새로운 정보가 없는 경우, 빈 응답을 보내는 대신 서버는 요청을 연 상태로 유지하고 응답 정보를 사용할 수 있을 때까지 기다립니다.새 정보가 있으면 서버는 즉시 HTTP 응답을 클라이언트로 전송하여 열린 HTTP 요청을 완료합니다.서버 응답을 받은 클라이언트는 다른 서버 요청을 즉시 실행합니다.이러한 방식으로 폴링 클라이언트와 관련된 일반적인 응답 지연 시간(다음 클라이언트 요청 시 정보를 처음 사용할 수 있게 되는 시간 사이의 시간)[15]이 제거됩니다.

예를 들어, BOSH는 지속적인 TCP 연결이 직접 사용하기 어렵거나 불가능한 경우(예: 웹 [16]브라우저에서), 지속적인 TCP 연결의 긴 폴링 대안으로 사용되는 인기 있는 긴 수명의 HTTP 기술입니다. 또한 이 기술은 Apple이 iCloud 푸시 지원을 위해 사용하는 XMPP의 기본 기술이기도 합니다.

플래시 XML 소켓 릴레이

채팅 응용 프로그램에서 사용되는 이 기술은 단일 픽셀 Adobe Flash 동영상에서 XML Socket 개체를 사용합니다.클라이언트는 JavaScript의 제어 하에 서버의 단방향 릴레이에 TCP 연결을 설정합니다.릴레이 서버는 이 소켓에서 아무것도 읽지 않으며 클라이언트에 고유 식별자를 즉시 전송합니다.다음으로 클라이언트는 웹 서버에 이 식별자를 포함한 HTTP 요청을 합니다.그런 다음 웹 응용 프로그램은 클라이언트에 수신된 메시지를 릴레이 서버의 로컬 인터페이스로 푸시할 수 있으며, 릴레이 서버는 플래시 소켓을 통해 메시지를 릴레이합니다.이 접근 방식의 장점은 채팅을 포함한 많은 웹 애플리케이션에서 전형적으로 나타나는 자연스러운 읽기-쓰기 비대칭성을 인식하고 결과적으로 높은 효율성을 제공한다는 것입니다.송신 소켓에 대한 데이터를 허용하지 않기 때문에 릴레이 서버는 송신 TCP 연결을 폴링할 필요가 전혀 없어 수만 개의 동시 연결을 유지할 수 있습니다.이 모델에서 확장 한계는 기본 서버 운영 체제의 TCP 스택입니다.

안정적인 그룹 데이터 전송(RGDD)

클라우드 컴퓨팅과 같은 서비스에서는 데이터의 신뢰성과 가용성을 높이기 위해 일반적으로 여러 기계에 푸시(복제)됩니다.예를 들어, HDFS(Hadoop Distributed File System)는 저장된 모든 개체에 대해 2개의 복사본을 추가로 만듭니다.RGDD는 네트워크를 통해 링크를 통해 객체의 최소 복사본 수(최상의 경우 하나만)를 전송함으로써 대역폭을 절약하면서 한 위치에서 여러 위치로 객체를 효율적으로 캐스팅하는 데 중점을 둡니다.예를 들어, Datacast는[17] 정기적이고 구조화된 토폴로지에 의존하는 데이터 센터 내의 많은 노드에 전달하기 위한 계획이며, DCCast는[18] 데이터 센터 전반에 걸쳐 제공하기 위한 유사한 접근 방식입니다.

푸시알림

참고 항목:모바일 마케팅 § Push 알림

푸시 알림은 백엔드 서버 또는 애플리케이션에서 모바일 애플리케이션[19] 또는 데스크톱 애플리케이션과 같은 사용자 인터페이스로 "푸시"되는 메시지입니다.푸시 알림은 2009년 [20][dubious – discuss]애플에 의해 처음 도입되었습니다.2010년 구글은 구글 클라우드 투 디바이스 메시징이라는 자체 서비스를 출시했습니다(이후 구글 클라우드 메시징으로 처음 대체되었고 파이어베이스 클라우드 [21]메시징으로 대체되었습니다).2015년 11월, 마이크로소프트는 윈도우 알림 서비스가 윈도우 10, 윈도우 10 모바일, 엑스박스 [22]및 기타 지원 플랫폼들로 푸시 데이터가 전송될 수 있도록 윈도우 알림 서비스를 확장할 것이라고 발표했습니다.

푸시 알림은 주로 로컬 알림과 원격 [23]알림의 두 가지 접근 방식으로 구분됩니다.로컬 알림의 경우 애플리케이션이 로컬 장치의 OS로 알림을 예약합니다.원격 알림의 경우 백그라운드에서 계속 실행할 수 있는 경우 응용프로그램 자체에서 타이머를 설정합니다.이벤트의 예약 시간에 도달하거나 이벤트의 프로그램된 조건이 충족되면 메시지가 응용 프로그램의 사용자 인터페이스에 표시됩니다.

원격 알림은 원격 서버에서 처리합니다.이 시나리오에서는 클라이언트 애플리케이션을 고유 키(예: UUID)로 서버에 등록해야 합니다.그런 다음 서버는 HTTP 또는 XMPP와 같은 합의된 클라이언트/서버 프로토콜을 통해 클라이언트에 전달하기 위해 고유 키에 대해 메시지를 실행하고 클라이언트는 수신된 메시지를 표시합니다.푸시 알림이 도착하면 짧은 알림과 메시지를 전송하거나, 애플리케이션 아이콘에 배지를 설정하거나, 알림 LED를 깜빡이거나 계속 켜거나, 사용자의 [24]주의를 끌 수 있도록 경고음을 재생할 수 있습니다.푸시 알림은 일반적으로 응용 프로그램에서 사용자의 주의를 끌기 위해 사용됩니다.메시지 내용은 다음 예제 범주로 분류할 수 있습니다.

  • 다른 [25]사용자가 보낸 Facebook Messenger와 같은 메시지 응용 프로그램의 채팅 메시지입니다.
  • 벤더 특별 제안: 벤더는 자신의 제안을 고객에게 광고하고 싶어할 수 있습니다.
  • 이벤트 알림: 일부 응용 프로그램은 고객이 특정 시간에 대해 알림 또는 알림을 생성할 수 있도록 허용할 수 있습니다.
  • 등록한 항목 변경 내용:예를 들어 사용자는 자신의 위치에 있는 날씨에 대한 업데이트를 받거나 웹 페이지를 모니터링하여 변경 사항을 추적할 수 있습니다.

실시간 푸시 알림은 소셜 네트워크 가명의 가상 ID를 스마트폰 [26]소유자의 실제 ID에 결합하는 데 사용될 수 있기 때문에 프라이버시 문제를 야기할 수 있습니다.홍보 목적으로 불필요한 푸시 알림을 사용하는 것은 주의 [27]절도의 한 예로 비판받아 왔습니다.

참고 항목

참고문헌

  1. ^ "Push Technology". Techopedia. 2012-11-18. Retrieved 2023-07-23.
  2. ^ M. Thomson, E. Damaggio and B. Raymor (October 22, 2016). "Generic Event Delivery Using HTTP Push". Internet Draft. Internet Engineering Task Force. Retrieved October 28, 2016.
  3. ^ "Web Notifications".
  4. ^ "Web Push API".
  5. ^ "Push API - Web APIs MDN". developer.mozilla.org. 2023-02-22. Retrieved 2023-05-16.
  6. ^ World Wide Web O'Reilly 책의 CGI 프로그래밍 넷스케이프 서버 푸시 사용법 설명
  7. ^ 서버-Push 문서 (HTML & XHTML : The Definitive Guide) 2008-04-17 Wayback Machine O'Reilly에서 보관 서버-Push에 대해 설명하는 책
  8. ^ 멀티파트/x-혼합 교체 주 리소스에 대한 지원 제거
  9. ^ "Web Applications 1.0 specification".
  10. ^ "Event Streaming to Web Browsers". 2006-09-01. Retrieved 2007-03-23.
  11. ^ "Opera takes the lead with AJAX support among browsers: More efficient streaming". 2006-09-01. Archived from the original on 2007-03-18. Retrieved 2007-03-23.
  12. ^ "HTML Standard – Server-sent events". html.spec.whatwg.org. 31 March 2022. Retrieved 1 April 2022.{{cite web}}: CS1 유지 : url-status (링크)
  13. ^ 푸쉬렛 소개
  14. ^ Van Den Broecke, Just (1 March 2000). "Pushlets: Send events from servlets to DHTML client browsers". JavaWorld. Retrieved 2020-07-13.
  15. ^ Saint-Andre, Peter; Loreto, Salvatore; Salsano, Stefano; Wilkins, Greg (April 2011). "RFC6202 - Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP". doi:10.17487/RFC6202. Retrieved 2016-05-14. {{cite journal}}:저널 요구사항 인용 journal=(도움말)
  16. ^ "XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)". Retrieved 2012-06-26.
  17. ^ C. Guo; et al. (November 1, 2012). "Datacast: A Scalable and Efficient Reliable Group Data Delivery Service For Data Centers". Microsoft Research. ACM. Retrieved Jun 6, 2017.
  18. ^ M. Noormohammadpour; et al. (July 10, 2017). "DCCast: Efficient Point to Multipoint Transfers Across Datacenters". USENIX. Retrieved Jun 6, 2017.
  19. ^ Wohllebe, Atilla. (2020). "Consumer Acceptance of App Push Notifications: Systematic Review on the Influence of Frequency". International Journal of Interactive Mobile Technologies. 14 (13): 36–47. doi:10.3991/ijim.v14i13.14563.
  20. ^ "iPhone push notification service for devs announced". Engadget. Retrieved 2016-10-18.
  21. ^ "Google Cloud Messaging for Android (GCM) Unveiled, to Replace C2DM Framework". InfoQ. Retrieved 2016-10-18.
  22. ^ mijacobs. "Windows Push Notification Services (WNS) overview". docs.microsoft.com. Retrieved 2017-10-20.
  23. ^ "Local and Remote Notifications in Depth". developer.apple.com. Retrieved 2016-10-18.
  24. ^ "Android and iOS Push Notifications – Blog – JatApp". jatapp.com. Retrieved 2017-10-20.
  25. ^ "How do I adjust my mobile push notifications from Facebook? Facebook Help Center Facebook". www.facebook.com. Retrieved 2016-10-18.
  26. ^ Loreti, Pierpaolo; Bracciale, Lorenzo; Caponi, Alberto (2018). "Push Attack: Binding Virtual and Real Identities Using Mobile Push Notifications". Future Internet. 10 (2): 13. doi:10.3390/fi10020013.
  27. ^ McFedries, Paul (22 May 2014). "Stop, Attention Thief!". IEEE Spectrum. Institute of Electrical and Electronics Engineers. Retrieved 9 August 2021.

외부 링크