stringtranslate.com

Технология Push

Технология Push, также известная как Server Push, относится к методу коммуникации, где коммуникация инициируется сервером, а не клиентом. Этот подход отличается от метода « pull », где коммуникация инициируется клиентом. [1]

В технологии push клиенты могут выражать свои предпочтения в отношении определенных типов информации или данных, как правило, с помощью процесса, известного как модель публикации-подписки . В этой модели клиент «подписывается» на определенные информационные каналы, размещенные на сервере. Когда на этих каналах появляется новый контент, сервер автоматически отправляет или «проталкивает» эту информацию подписанному клиенту.

При определенных условиях, таких как ограничительные политики безопасности, блокирующие входящие HTTP- запросы, push-технология иногда имитируется с помощью техники, называемой опросом. В этих случаях клиент периодически проверяет сервер на наличие новой информации, а не получает автоматические обновления.

Общего назначения

Синхронные конференции и мгновенные сообщения являются примерами push-сервисов. Сообщения чата и иногда файлы отправляются пользователю сразу после их получения службой обмена сообщениями. Как децентрализованные одноранговые программы (например, WASTE ), так и централизованные программы (например, IRC или XMPP ) позволяют отправлять файлы, что означает, что отправитель инициирует передачу данных, а не получатель.

Электронная почта также может быть push-системой: SMTP — это push-протокол (см. Push e-mail ). Однако последний шаг — от почтового сервера до настольного компьютера — обычно использует pull-протокол, такой как POP3 или IMAP . Современные почтовые клиенты делают этот шаг мгновенным, многократно опрашивая почтовый сервер, часто проверяя его на наличие новой почты. Протокол IMAP включает команду IDLE , которая позволяет серверу сообщать клиенту о поступлении новых сообщений. Оригинальный BlackBerry был первым популярным примером push-email в беспроводном контексте. [ необходима цитата ]

Другим примером является PointCast Network , которая широко освещалась в 1990-х годах. Она доставляла новости и данные фондового рынка в качестве заставки. И Netscape , и Microsoft интегрировали технологию push через Channel Definition Format (CDF) в свое программное обеспечение в разгар войны браузеров , но она никогда не была очень популярной. CDF сошла на нет и была удалена из браузеров того времени, замененная в 2000-х годах на RSS (система pull).

Другие варианты использования веб-приложений с поддержкой push-уведомлений включают распространение обновлений программного обеспечения («push-обновления»), распространение рыночных данных (биржевые тикеры), онлайн-чаты/системы обмена сообщениями ( веб-чаты ), аукционы, онлайн-ставки и игры, результаты спортивных состязаний, консоли мониторинга и мониторинг сенсорных сетей .

Примеры

Веб-толчок

Предложение Web push от Internet Engineering Task Force представляет собой простой протокол, использующий HTTP версии 2 для доставки событий в реальном времени, таких как входящие звонки или сообщения, которые могут быть доставлены (или «продвинуты») своевременно. Протокол объединяет все события в реальном времени в один сеанс, что обеспечивает более эффективное использование сетевых и радиоресурсов. Единая служба объединяет все события, распределяя их по приложениям по мере их поступления. Для этого требуется всего один сеанс, что позволяет избежать дублирования накладных расходов. [2]

Веб-уведомления являются частью стандарта W3C и определяют API для уведомлений конечного пользователя. Уведомление позволяет оповещать пользователя о событии, таком как доставка электронного письма, вне контекста веб-страницы. [3] В рамках этого стандарта Push API полностью реализован в Chrome , Firefox и Edge и частично реализован в Safari по состоянию на февраль 2023 года . [4] [5]

HTTP-сервер push

HTTP-сервер push (также известный как HTTP-потоковая передача) — это механизм отправки незапрошенных (асинхронных) данных с веб-сервера на веб-браузер . HTTP-сервер push может быть реализован с помощью любого из нескольких механизмов.

Являясь частью HTML5, API веб-сокетов позволяет веб-серверу и клиенту взаимодействовать через полнодуплексное TCP-соединение.

Обычно веб-сервер не завершает соединение после того, как данные ответа были переданы клиенту. Веб-сервер оставляет соединение открытым, так что если происходит событие (например, изменение внутренних данных, о котором необходимо сообщить одному или нескольким клиентам), оно может быть отправлено немедленно; в противном случае событие должно быть поставлено в очередь до получения следующего запроса клиента. Большинство веб-серверов предлагают эту функциональность через CGI (например, скрипты Non-Parsed Headers на Apache HTTP Server ). Базовый механизм для этого подхода — кодирование передачи по частям .

Другой механизм связан со специальным типом MIME , называемым multipart/x-mixed-replace, который был представлен Netscape в 1995 году. Веб-браузеры интерпретируют его как документ, который изменяется всякий раз, когда сервер отправляет новую версию клиенту. [6] Он по-прежнему поддерживается Firefox , Opera и Safari сегодня, но игнорируется Internet Explorer [7] и лишь частично поддерживается Chrome . [8] Его можно применять к документам HTML , а также для потоковой передачи изображений в приложениях веб-камеры .

Предложение WHATWG Web Applications 1.0 [9] включает механизм передачи контента клиенту. 1 сентября 2006 года веб-браузер Opera реализовал эту новую экспериментальную систему в функции под названием « Server-Sent Events ». [10] [11] Теперь это часть стандарта HTML5 . [12]

Пушлет

В этом методе сервер использует преимущества постоянных HTTP-соединений , оставляя ответ постоянно «открытым» (т. е. сервер никогда не завершает ответ), эффективно обманывая браузер, чтобы он оставался в режиме «загрузки» после того, как начальная загрузка страницы может считаться завершенной. Затем сервер периодически отправляет фрагменты JavaScript для обновления содержимого страницы, тем самым достигая возможности push-уведомлений. При использовании этого метода клиенту не нужны Java-апплеты или другие плагины для поддержания открытого соединения с сервером; клиент автоматически уведомляется о новых событиях, отправляемых сервером. [13] [14] Однако одним серьезным недостатком этого метода является отсутствие контроля со стороны сервера над тайм-аутом браузера; обновление страницы всегда необходимо, если тайм-аут происходит на стороне браузера.

Длинный опрос

Длительный опрос сам по себе не является настоящим push-запросом; длительный опрос — это разновидность традиционной техники опроса, но он позволяет эмулировать механизм push-запроса в ситуациях, когда реальный push-запрос невозможен, например, на сайтах с политиками безопасности, требующими отклонения входящих HTTP-запросов.

При длинном опросе клиент запрашивает дополнительную информацию с сервера точно так же, как и при обычном опросе, но с ожиданием, что сервер может не ответить немедленно. Если у сервера нет новой информации для клиента при получении опроса, то вместо отправки пустого ответа сервер удерживает запрос открытым и ждет, пока информация об ответе станет доступной. Как только у него появляется новая информация, сервер немедленно отправляет HTTP-ответ клиенту, завершая открытый HTTP-запрос. После получения ответа сервера клиент часто немедленно отправляет другой запрос к серверу. Таким образом, обычная задержка ответа (время между тем, когда информация впервые становится доступной, и следующим запросом клиента), в противном случае связанная с опросом клиентов, устраняется. [15]

Например, BOSH — это популярная, долгоживущая технология HTTP, используемая в качестве альтернативы непрерывному TCP-соединению с длительным опросом, когда такое соединение трудно или невозможно использовать напрямую (например, в веб-браузере); [16] это также базовая технология в XMPP , которую Apple использует для поддержки push-уведомлений iCloud.

Реле Flash XML Socket

Этот метод, используемый чат- приложениями, использует объект XML Socket в однопиксельном фильме Adobe Flash . Под управлением JavaScript клиент устанавливает TCP-соединение с однонаправленным ретранслятором на сервере. Ретрансляционный сервер ничего не считывает из этого сокета ; вместо этого он немедленно отправляет клиенту уникальный идентификатор . Затем клиент делает HTTP-запрос к веб-серверу, включая этот идентификатор. Затем веб-приложение может отправлять сообщения, адресованные клиенту, на локальный интерфейс ретрансляционного сервера, который ретранслирует их через сокет Flash. Преимущество этого подхода заключается в том, что он учитывает естественную асимметрию чтения-записи, типичную для многих веб-приложений, включая чат, и, как следствие, обеспечивает высокую эффективность. Поскольку он не принимает данные на исходящих сокетах, ретрансляционному серверу вообще не нужно опрашивать исходящие TCP-соединения , что позволяет держать открытыми десятки тысяч одновременных соединений. В этой модели пределом масштабирования является TCP-стек базовой серверной операционной системы.

Надежная групповая доставка данных (RGDD)

В таких сервисах, как облачные вычисления , для повышения надежности и доступности данных они обычно передаются (реплицируются) на несколько машин. Например, распределенная файловая система Hadoop (HDFS) создает 2 дополнительные копии любого хранимого объекта. RGDD фокусируется на эффективном приведении объекта из одного места во многие, экономя при этом пропускную способность за счет отправки минимального количества копий (в лучшем случае только одной) объекта по любому каналу в сети. Например, Datacast [17] — это схема доставки на множество узлов внутри центров обработки данных, которая опирается на регулярные и структурированные топологии, а DCCast [18] — это аналогичный подход для доставки между центрами обработки данных.

Push-уведомление

Push-уведомление — это сообщение, которое «проталкивается» с внутреннего сервера или приложения в пользовательский интерфейс, например, мобильные приложения [19] или настольные приложения. Apple представила push-уведомления для iPhone в 2009 году, [20] а в 2010 году Google выпустила «Google Cloud to Device Messaging» (замененный Google Cloud Messaging , а затем Firebase Cloud Messaging ). [21] В ноябре 2015 года Microsoft объявила, что служба уведомлений Windows будет расширена для использования архитектуры универсальной платформы Windows, что позволит отправлять push-данные в Windows 10 , Windows 10 Mobile , Xbox и другие поддерживаемые платформы с помощью универсальных вызовов API и запросов POST. [22]

Push-уведомления в основном делятся на два подхода: локальные уведомления и удаленные уведомления. [23] Для локальных уведомлений приложение планирует уведомление с ОС локального устройства. Для удаленных уведомлений приложение устанавливает таймер в самом приложении, при условии, что оно может непрерывно работать в фоновом режиме. Когда наступает запланированное время события или выполняется запрограммированное условие события, сообщение отображается в пользовательском интерфейсе приложения.

Удаленные уведомления обрабатываются удаленным сервером. В этом сценарии клиентское приложение должно быть зарегистрировано на сервере с уникальным ключом (например, UUID ). Затем сервер запускает сообщение с уникальным ключом, чтобы доставить его клиенту через согласованный клиент-серверный протокол, такой как HTTP или XMPP , и клиент отображает полученное сообщение. Когда приходит push-уведомление, оно может передавать короткие уведомления и сообщения, устанавливать значки на значках приложений, мигать или непрерывно светить светодиод уведомления или воспроизводить звуковые сигналы для привлечения внимания пользователя. [24] Push-уведомления обычно используются приложениями для привлечения внимания пользователей к информации. Содержимое сообщений можно классифицировать по следующим примерным категориям:

Push-уведомления в режиме реального времени могут вызывать проблемы с конфиденциальностью, поскольку они могут использоваться для привязки виртуальных личностей псевдонимов социальных сетей к реальным личностям владельцев смартфонов. [26] Использование ненужных push-уведомлений в рекламных целях подвергалось критике как пример кражи внимания. [27]

Смотрите также

Ссылки

  1. ^ "Push Technology". Techopedia . 2012-11-18 . Получено 2023-07-23 .
  2. ^ M. Thomson, E. Damaggio и B. Raymor (22 октября 2016 г.). «Доставка общих событий с использованием HTTP Push». Internet Draft . Internet Engineering Task Force . Получено 28 октября 2016 г.
  3. ^ "Стандарт API уведомлений". notifications.spec.whatwg.org . Получено 30 апреля 2024 г. .
  4. ^ "Push API" . Получено 30 апреля 2024 г.
  5. ^ "Push API - Web API | MDN". developer.mozilla.org . 2023-02-22 . Получено 2023-05-16 .
  6. ^ CGI-программирование в World Wide Web, книга О'Рейли, объясняющая, как использовать Netscape server-push
  7. ^ Документы Server-Push (HTML и XHTML: Полное руководство) Архивировано 17 апреля 2008 г. в книге Wayback Machine О'Рейли, объясняющей server-push
  8. ^ Удалить поддержку для основных ресурсов multipart/x-mixed-replace
  9. ^ «Спецификация веб-приложений 1.0».
  10. ^ "Потоковая передача событий в веб-браузеры". 2006-09-01 . Получено 2007-03-23 .
  11. ^ "Opera занимает лидирующие позиции с поддержкой AJAX среди браузеров: более эффективная потоковая передача". 2006-09-01. Архивировано из оригинала 2007-03-18 . Получено 2007-03-23 .
  12. ^ "HTML Standard – Server-sent events". html.spec.whatwg.org . 31 марта 2022 г. . Получено 1 апреля 2022 г. .
  13. ^ "Pushlets introduction". Архивировано из оригинала 2009-08-05 . Получено 2008-06-05 .
  14. ^ Van Den Broecke, Just (1 марта 2000 г.). "Pushlets: Send events from servlets to DHTML client browsers". JavaWorld . Получено 13 июля 2020 г.
  15. ^ Сент-Андре, Питер; Лорето, Сальваторе; Сальсано, Стефано; Уилкинс, Грег (апрель 2011 г.). "RFC6202 — Известные проблемы и передовой опыт использования длинных опросов и потоковой передачи в двунаправленном HTTP". tools.ietf.org . doi :10.17487/RFC6202 . Получено 14.05.2016 .
  16. ^ "XEP-0124: Двунаправленные потоки по синхронному HTTP (BOSH)" . Получено 2012-06-26 .
  17. ^ C. Guo; et al. (1 ноября 2012 г.). «Datacast: масштабируемая и эффективная надежная групповая служба доставки данных для центров обработки данных». Microsoft Research . ACM . Получено 6 июня 2017 г. .
  18. ^ M. Noormohammadpour; et al. (10 июля 2017 г.). "DCCast: Эффективные передачи данных из точки в многоточку через центры обработки данных". USENIX . Получено 6 июня 2017 г. .
  19. ^ Wohllebe, Atilla. (2020). «Принятие потребителями push-уведомлений приложений: систематический обзор влияния частоты». Международный журнал интерактивных мобильных технологий . 14 (13): 36–47. doi : 10.3991/ijim.v14i13.14563 .
  20. ^ "Анонсирован сервис push-уведомлений iPhone для разработчиков". Engadget . Получено 2016-10-18 .
  21. ^ "Google Cloud Messaging для Android (GCM) анонсирован, чтобы заменить C2DM Framework". InfoQ . Получено 2016-10-18 .
  22. ^ mijacobs. "Обзор служб push-уведомлений Windows (WNS)". docs.microsoft.com . Получено 20.10.2017 .
  23. ^ «Локальные и удаленные уведомления в деталях». developer.apple.com . Получено 2016-10-18 .
  24. ^ "Android и iOS Push Notifications – Блог – JatApp". jatapp.com . Архивировано из оригинала 20 октября 2017 г. Получено 20 октября 2017 г.
  25. ^ «Как настроить мобильные push-уведомления от Facebook? | Справочный центр Facebook | Facebook». www.facebook.com . Получено 18.10.2016 .
  26. ^ Лорети, Пьерпаоло; Браччиале, Лоренцо; Капони, Альберто (2018). «Атака Push: связывание виртуальных и реальных идентификаторов с помощью мобильных push-уведомлений». Future Internet . 10 (2): 13. doi : 10.3390/fi10020013 .
  27. ^ Макфедрис, Пол (22 мая 2014 г.). «Стой, внимание, вор!». IEEE Spectrum . Институт инженеров по электротехнике и электронике . Получено 9 августа 2021 г.

Внешние ссылки