Открыть сервис

Web Push Protocol

Web Push Protocol — это стандартизированный протокол прикладного уровня, используемый для доставки push-уведомлений от сервера веб-приложения (или сервис-воркера) к клиентскому браузеру через промежуточный push-сервис, предоставляемый производителем браузера. Протокол является частью технологии Web Push, определённой в спецификациях W3C и IETF, и обеспечивает асинхронную, энергоэффективную и безопасную передачу сообщений даже при закрытом веб-сайте.

История

До появления Web Push Protocol уведомления в веб-браузерах были возможны только при активной вкладке с сайтом, используя технологии вроде Server-Sent Events (SSE) или WebSocket. Это требовало постоянного сетевого соединения и потребляло ресурсы устройства. В начале 2010-х годов, с ростом популярности мобильных устройств и прогрессивных веб-приложений (PWA), возникла потребность в стандартизированном механизме доставки сообщений, аналогичном нативным push-уведомлениям.

В 2014 году W3C сформировал рабочую группу по Web Push, а в 2015 году был опубликован первый черновик спецификации. Параллельно IETF разрабатывал протокол HTTP-запросов для взаимодействия с push-сервисами. В 2017 году протокол был стандартизирован как RFC 8030 («Generic Event Delivery Using HTTP Push») и RFC 8292 («Voluntary Application Server Identification (VAPID) for Web Push»). С 2018 года все основные браузеры (Chrome, Firefox, Edge, Opera, Safari с 2020 года) реализовали поддержку протокола.

Архитектура и принцип работы

Протокол основан на модели «издатель-подписчик» с использованием трёх ключевых компонентов:

  1. Клиент (браузер) — генерирует уникальную подписку push-уведомлений, содержащую endpoint (URL push-сервиса) и ключи шифрования.
  2. Push-сервиссерверная инфраструктура, управляемая производителем браузера (например, Firebase Cloud Messaging для Chrome, Mozilla Autopush для Firefox, Apple Push Notification Service для Safari). Он принимает сообщения от сервера приложения и доставляет их на конкретное устройство.
  3. Сервер приложения — веб-сервер, который отправляет push-сообщения через HTTP-запросы к endpoint, полученному от клиента.

Процесс доставки

  1. Подписка: JavaScript-код на веб-странице вызывает метод PushManager.subscribe() в сервис-воркере. Браузер связывается с push-сервисом, получает endpoint и пару криптографических ключей (публичный и приватный). Эти данные отправляются на сервер приложения.
  2. Шифрование: Сообщение шифруется на сервере приложения с использованием публичного ключа клиента (алгоритм AES-GCM, стандарт RFC 8188). Это гарантирует, что push-сервис не может прочитать содержимое уведомления.
  3. Отправка: Сервер приложения отправляет HTTP POST-запрос к endpoint с заголовками Encryption, Crypto-Key и телом зашифрованного сообщения. Для аутентификации используется VAPID (Voluntary Application Server Identification) — JWT-токен, подтверждающий личность сервера.
  4. Доставка: Push-сервис проверяет VAPID-токен, сохраняет сообщение в очереди и, используя собственные механизмы (например, Google Cloud Messaging или APNs), доставляет его на устройство клиента. Если устройство офлайн, сообщение хранится до 4 недель (время зависит от push-сервиса).
  5. Обработка: Сервис-воркер браузера получает событие push, извлекает данные, дешифрует их и отображает уведомление через ServiceWorkerRegistration.showNotification().

Технические характеристики

Транспортный уровень

Протокол использует HTTP/2 (или HTTP/1.1 с поддержкой keep-alive) для отправки сообщений. Endpoint всегда использует HTTPS. Размер тела сообщения ограничен: в Chrome — до 4 КБ, в Firefox — до 4 КБ, в Safari — до 4 КБ (для уведомлений с данными). Для больших полезных нагрузок рекомендуется использовать data-поле в уведомлении, которое хранится локально.

Шифрование

  • Алгоритм: AES-256-GCM с ключом длиной 256 бит.
  • Схема: ECDH (Elliptic Curve Diffie-Hellman) для обмена ключами, с использованием кривой P-256.
  • Стандарт: RFC 8188 (Encrypted Content-Encoding for HTTP) и RFC 8291 (Message Encryption for Web Push).
  • Обязательность: Шифрование является обязательным для всех сообщений, содержащих полезную нагрузку. Пустые уведомления (без тела) могут отправляться без шифрования.

Аутентификация (VAPID)

VAPID (Voluntary Application Server Identification) — это механизм, позволяющий серверу приложения подтвердить свою личность перед push-сервисом. Он включает:

  • Публичный ключ: сервер генерирует пару ключей (алгоритм ECDSA, кривая P-256).
  • JWT-токен: содержит sub (идентификатор сервера, обычно email или URL) и exp (время истечения). Токен подписывается приватным ключом сервера.
  • Передача: публичный ключ передаётся в заголовке Crypto-Key, а JWT — в заголовке Authorization HTTP-запроса.

VAPID позволяет push-сервису идентифицировать источник сообщений, что помогает в борьбе со спамом и позволяет серверу приложения получать статистику доставки.

Реализация и поддержка браузерами

Статус поддержки

  • Google Chrome: с версии 42 (2015), использует Firebase Cloud Messaging (FCM) в качестве push-сервиса. Для работы требуется регистрация проекта в Firebase Console.
  • Mozilla Firefox: с версии 44 (2016), использует Mozilla Autopush. Не требует регистрации, поддерживает VAPID с версии 46.
  • Microsoft Edge: с версии 79 (2020, на базе Chromium), использует FCM.
  • Apple Safari: с версии 16.1 (2022) на macOS, с версии 16.4 (2023) на iOS. Использует APNs, требует регистрации в Apple Developer Program.
  • Opera: с версии 42 (2016), использует FCM.

Ограничения

  • iOS: до версии 16.4 push-уведомления не поддерживались. Начиная с iOS 16.4, работают только при добавлении сайта на домашний экран (как PWA).
  • Android: поддержка полная, включая Chrome, Firefox, Samsung Internet, Opera.
  • Desktop: все основные браузеры поддерживают, но пользователь должен явно разрешить уведомления.

Применение

Web Push Protocol используется в следующих сценариях:

  • Прогрессивные веб-приложения (PWA): доставка уведомлений о новых сообщениях, обновлениях контента, напоминаниях.
  • Новостные сайты: оповещения о срочных новостях, публикациях.
  • Электронная коммерция: уведомления о скидках, статусе заказа, брошенных корзинах.
  • Социальные сети: уведомления о лайках, комментариях, подписчиках.
  • Мессенджеры: доставка сообщений при закрытом приложении (например, Telegram Web, WhatsApp Web).
  • Коллаборативные сервисы: уведомления о задачах, изменениях в документах (Google Docs, Trello).

Критика и ограничения

  1. Зависимость от push-сервисов: Протокол требует, чтобы производители браузеров предоставляли push-сервисы. Если сервис недоступен (например, из-за блокировок), доставка нарушается. В России с 2022 года наблюдаются перебои в работе FCM из-за технических ограничений.
  2. Размер сообщения: Ограничение в 4 КБ для полезной нагрузки недостаточно для передачи сложных данных. Разработчики вынуждены использовать дополнительные запросы к серверу.
  3. Задержки доставки: Push-сервисы могут задерживать сообщения для экономии батареи, особенно на мобильных устройствах. Время доставки не гарантируется.
  4. Конфиденциальность: Хотя сообщения шифруются, push-сервис знает, что сообщение было отправлено, и может отслеживать метаданные (время, отправитель, получатель). VAPID частично решает эту проблему, но не полностью.
  5. Сложность реализации: Требуется настройка серверной инфраструктуры, генерация ключей, шифрование, обработка ошибок. Для упрощения существуют библиотеки (например, web-push для Node.js, pywebpush для Python).

Интересные факты

  • Протокол не требует постоянного соединения между браузером и сервером приложения — push-сервис выступает в роли брокера, что экономит энергию на мобильных устройствах.
  • В 2020 году Mozilla объявила о закрытии собственного push-сервиса Autopush, но позже отменила решение под давлением сообщества. В 2023 году сервис продолжает работать.
  • В Китае протокол не работает из-за блокировки Google и Apple сервисов. Для китайских пользователей существуют альтернативные реализации, например, на базе Baidu Push.
  • По данным Google, в 2023 году через Web Push Protocol было доставлено более 1 триллиона уведомлений в месяц.

Источники

  • RFC 8030 (Generic Event Delivery Using HTTP Push)
  • RFC 8292 (Voluntary Application Server Identification for Web Push)
  • RFC 8188 (Encrypted Content-Encoding for HTTP)
  • W3C Push API Specification (рабочий проект)
  • Mozilla Developer Network: Web Push API
  • Google Developers: Web Push Notifications
  • Apple Developer Documentation: Web Push for Safari

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →