Войти
Технология Push или server push - это стиль Интернет - связь на основе, когда запрос данной транзакции инициируется издателем или центральным сервером. Это контрастирует с pull / get, где запрос на передачу информации инициируется получателем или клиентом.
Push-сервисы часто основаны на информационных предпочтениях, выраженных заранее. Это называется моделью публикации / подписки. Клиент «подписывается» на различные информационные «каналы», предоставляемые сервером; всякий раз, когда на одном из этих каналов доступен новый контент, сервер передает эту информацию клиенту.
Push иногда эмулируется с помощью метода опроса, особенно в обстоятельствах, когда настоящий push невозможен, например, на сайтах с политиками безопасности, требующими отклонения входящих запросов HTTP / S.
Синхронная конференция и обмен мгновенными сообщениями Это типичные примеры push-сервисов. Сообщения чата, а иногда и файлы отправляются пользователю, как только они получены службой обмена сообщениями. Как децентрализованные программы одноранговой сети (например, WASTE ), так и централизованные программы (такие как IRC или XMPP ) позволяют передавать файлы, что означает, что отправитель инициирует передачу данных, а не получатель.
Электронная почта также может быть системой push: SMTP - это протокол push (см. Push-сообщение электронной почты ). Однако на последнем этапе - от почтового сервера к настольному компьютеру - обычно используется протокол извлечения, например POP3 или IMAP. В современных почтовых клиентах этот шаг кажется мгновенным, поскольку он постоянно опрашивает почтовый сервер, часто проверяя его на наличие новой почты. Протокол IMAP включает команду IDLE, которая позволяет серверу сообщать клиенту о поступлении новых сообщений. Первоначальный BlackBerry был первым популярным примером push-email в беспроводном контексте.
Другим примером является PointCast Network, которая широко использовалась в 1990-х годах. Он предоставил новости и данные фондового рынка в качестве заставки. И Netscape, и Microsoft интегрировали push-технологию через Channel Definition Format (CDF) в свое программное обеспечение в разгар войн браузеров, но он никогда не был очень популярен. CDF исчез и был удален из браузеров того времени, заменен в 2000-х на RSS (вытягивающая система).
Другие виды использования веб-приложений с поддержкой push включают распространение обновлений программного обеспечения ("push-обновления"), распространение рыночных данных (биржевые тикеры), онлайн-чат / системы обмена сообщениями (веб-чат ), аукционы, онлайн-ставки и игры, спортивные результаты, консоли мониторинга и сенсорная сеть мониторинг.
Предложение Webpush от Инженерной группы Интернета представляет собой простой протокол, использующий HTTP версии 2 для доставлять события в реальном времени, такие как входящие вызовы или сообщения, которые могут быть доставлены (или «отправлены») своевременно. Протокол объединяет все события реального времени в один сеанс, что обеспечивает более эффективное использование сетевых и радиоресурсов. Одна служба объединяет все события, распределяя их по приложениям по мере их поступления. Для этого требуется всего один сеанс, что позволяет избежать дублирования накладных расходов.
Веб-уведомления являются частью стандарта W3C и определяют API для уведомлений конечных пользователей. Уведомление позволяет предупреждать пользователя о происшествии вне контекста веб-страницы, например о доставке электронной почты. Как часть этого стандартного Push API, определенного W3C, в настоящее время реализуется в Chrome, Firefox, Edge и Safari.
HTTP-сервер push (также известный как потоковая передача HTTP) - это механизм для отправки незапрошенных (асинхронных) данных с веб-сервера в веб-браузер. Проталкивание HTTP-сервера может быть выполнено с помощью любого из нескольких механизмов.
Как часть HTML5 WebSocket API позволяет веб-серверу и клиенту обмениваться данными через полнодуплексное TCP-соединение.
Обычно веб-сервер не разрывает соединение после того, как данные ответа были доставлены клиенту. Веб-сервер оставляет соединение открытым, поэтому в случае возникновения события (например, изменение внутренних данных, о которых необходимо сообщить одному или нескольким клиентам), оно может быть отправлено немедленно; в противном случае событие должно быть поставлено в очередь до тех пор, пока не будет получен следующий запрос клиента. Большинство веб-серверов предлагают эту функциональность через CGI (например, сценарии без анализа заголовков на HTTP-сервере Apache ). Основным механизмом для этого подхода является кодирование передачи по частям.
Другой механизм связан со специальным типом MIME, который называется multipart / x-mixed-replace , который был представлен Netscape в 1995 году. Веб-браузеры интерпретируют это как документ, который изменяется всякий раз, когда сервер отправляет новую версию клиенту. Он по-прежнему поддерживается Firefox, Opera и Safari сегодня, но игнорируется Internet Explorer и поддерживается только частично. Google Chrome. Его можно применять к документам HTML, а также для потоковой передачи изображений в приложениях веб-камеры.
Предложение WHATWG Web Applications 1.0 включает механизм для отправки контента клиенту. 1 сентября 2006 г. веб-браузер Opera реализовал эту новую экспериментальную систему в функции под названием «События, отправленные сервером ». Сейчас он стандартизирован как часть HTML5.
. В этом методе сервер использует преимущества постоянных HTTP-соединений, оставляя ответ постоянно «открытым» (т. Е., сервер никогда не завершает ответ), эффективно обманывая браузер, заставляя его оставаться в режиме «загрузки» после того, как начальная загрузка страницы может считаться завершенной. Затем сервер периодически отправляет фрагменты JavaScript для обновления содержимого страницы, тем самым обеспечивая возможность push. Используя этот метод, клиенту не нужны Java-апплеты или другие плагины, чтобы поддерживать открытое соединение с сервером; клиент автоматически уведомляется о новых событиях, отправленных сервером. Однако серьезным недостатком этого метода является отсутствие контроля сервера над тайм-аутом браузера; обновление страницы всегда необходимо, если на стороне браузера происходит тайм-аут.
Долгий опрос сам по себе не является истинным толчком; длинный опрос - это вариант традиционного метода опроса, но он позволяет эмулировать механизм push в обстоятельствах, когда реальный опрос невозможен, например, на сайтах с политиками безопасности, которые требуют отклонения входящих HTTP / S запросов.
При длительном опросе клиент запрашивает информацию у сервера точно так же, как при обычном опросе, но ожидается, что сервер может не ответить немедленно. Если сервер не имеет новой информации для клиента при получении опроса, вместо отправки пустого ответа сервер удерживает запрос открытым и ожидает, пока информация ответа станет доступной. Как только у него появляется новая информация, сервер немедленно отправляет клиенту ответ HTTP / S, завершая открытый запрос HTTP / S. После получения ответа сервера клиент часто сразу же выдает другой запрос сервера. Таким образом устраняется обычная задержка ответа (время между тем, когда информация впервые становится доступной при следующем запросе клиента), в противном случае связанная с опросом клиентов.
Например, BOSH является популярным, долговременная технология HTTP, используемая в качестве альтернативы длительного опроса непрерывному TCP-соединению, когда такое соединение трудно или невозможно использовать напрямую (например, в веб-браузере); это также базовая технология в XMPP, которую Apple использует для поддержки push-уведомлений iCloud.
Этот метод, используемый приложениями chat, использует объект XMLSocket в однопиксельном Adobe Flash ролик. Под управлением JavaScript клиент устанавливает TCP-соединение с однонаправленным ретранслятором на сервере. Сервер ретрансляции ничего не читает из этого сокета ; вместо этого он немедленно отправляет клиенту уникальный идентификатор. Затем клиент выполняет HTTP-запрос к веб-серверу, включая этот идентификатор. Затем веб-приложение может отправлять сообщения, адресованные клиенту, на локальный интерфейс сервера ретрансляции, который передает их через сокет Flash. Преимущество этого подхода состоит в том, что он учитывает естественную асимметрию чтения-записи, которая типична для многих веб-приложений, включая чат, и, как следствие, обеспечивает высокую эффективность. Поскольку он не принимает данные об исходящих сокетах, серверу ретрансляции вообще не нужно опрашивать исходящие TCP-соединения, что позволяет держать открытыми десятки тысяч одновременных соединений. В этой модели ограничением масштабирования является стек TCP базовой операционной системы сервера.
В таких сервисах, как облачные вычисления, для повышения надежности и доступности данных они обычно передаются (реплицируются) на несколько машин. Например, распределенная файловая система Hadoop (HDFS) создает 2 дополнительных копии любого сохраненного объекта. RGDD фокусируется на эффективном преобразовании объекта из одного местоположения во многие, сохраняя при этом полосу пропускания, отправляя минимальное количество копий (только одну в лучшем случае) объекта по любому каналу в сети. Например, Datacast - это схема доставки на многие узлы внутри центров обработки данных, основанная на регулярных и структурированных топологиях, а DCCast - аналогичный подход для доставки в центры обработки данных.
Push-уведомление - это сообщение, которое «проталкивается» с внутреннего сервера или приложения в пользовательский интерфейс, например (но не ограничиваясь ими) мобильные и настольные приложения. Push-уведомления были впервые представлены компанией Apple в 2009 году. В 2010 году Google выпустила собственный сервис Google Cloud to Device Messaging. (С тех пор он был заменен на Google Cloud Messaging, а затем на Firebase Cloud Messaging.) В ноябре 2015 года Microsoft объявила, что Windows Notification Service будет расширен для использования архитектуры универсальной платформы Windows, позволяющей отправлять push-данные в Windows 10, Windows 10 Mobile, Xbox, а также на другие поддерживаемые платформы с использованием универсальных вызовов API и запросов POST.
Push-уведомления в основном делятся на 2 подхода: локальные уведомления и удаленные уведомления. Для локальных уведомлений приложение планирует уведомление с помощью ОС локального устройства или, в качестве альтернативы, устанавливает таймер в самом приложении, если оно может непрерывно работать в фоновом режиме. Когда наступает запланированное время события или соблюдается запрограммированное условие события, сообщение отображается в пользовательском интерфейсе приложения.
Удаленные уведомления обрабатываются удаленным сервером. В этом сценарии клиентское приложение должно быть зарегистрировано на сервере с уникальным ключом (например, UUID ). Затем сервер запускает сообщение с уникальным ключом для доставки сообщения клиентскому приложению через согласованный протокол клиент / сервер, такой как HTTP или XMPP, и клиент отображает полученное сообщение. Когда приходит push-уведомление, он может передавать короткие уведомления и сообщения, устанавливать значки на значках приложений, мигать или постоянно светить светодиодным индикатором уведомлений или воспроизводить звуковые сигналы, чтобы привлечь внимание пользователя. Push-уведомления обычно используются приложениями для привлечения внимания пользователей к информации. Содержание сообщений можно классифицировать по следующим категориям примеров:
Push-уведомления в реальном времени могут вызывать проблемы с конфиденциальностью, поскольку их можно использовать для привязки виртуальных идентификаторов социальных сетей псевдонимы реальных владельцев смартфонов.
Firebase Cloud Messaging, принадлежащий Google, - это кроссплатформенный вариант обмена сообщениями, который позволяет разработчикам бесплатно отправлять push-уведомления. Он функционирует как модуль между сервером и устройством, которое будет получать уведомления о накопителях, которые вы создаете.
