Проектирование архитектуры взаимодействия сервера и браузера при отправке пушей

Основные компоненты пуш-уведомлений в вебе

Три кита системы: Service Worker‚ Push API‚ Notifications API. Сначала сайт регистрирует фоновый скрипт‚ затем запрашивает разрешение показывать уведомления‚ после чего браузер генерирует уникальный endpoint и пары ключей. Сервер с этими данными отправляет POST-запрос на push-сервис; При получении сообщения браузер пробуждает Service Worker‚ который создаёт всплывающее уведомление через Notifications API. Записывает ли он ваш endpoint в subscription‚ вы сразу видите пользу: уведомления работают даже при закрытой вкладке.

Роль Service Worker в обработке пушей

Без фонового скрипта не обойтись. Service Worker — JavaScript-скрипт‚ который выполняется отдельно от веб-страницы и может взаимодействовать с локальным хранилищем‚ локальной базой данных и веб-сервером. В браузерах Google Chrome‚ Mozilla Firefox‚ Opera‚ Microsoft Edge‚ Сайфрай‚ Android и др. Service Worker может работать в фоновом режиме‚ независимо от того‚ работает ли на переднем плане сайт. Прямой доступ к API запросов сайта позволяет пушам доходить даже до закрытого сайта.

Именно Service Worker обрабатывает уведомления от пуш-сервера. Сервер посылает в него сообщение; скрипт его проверяет и запускает код для генерации окон-уведомлений; Даже если вы не писали JS‚ всегда можно задействовать готовые библиотеки типа sw-toolbox.

Подписка на пуш-уведомления

Чтобы подписаться на пуш-уведомления‚ необходимо выполнить ряд действий. Сначала сайт регистрирует Service Worker; Затем запрашивает разрешение на показ уведомлений. После этого браузер генерирует уникальный endpoint и пары ключей. Затем эти данные отправляются на сервер‚ который их записывает в базу данных.

Когда сервер отправляет POST-запрос на push-сервис‚ он использует уникальный endpoint и пары ключей для идентификации подписчика. Затем push-сервис отправляет сообщение на браузер‚ который пробуждает Service Worker. Затем Service Worker создаёт всплывающее уведомление через Notifications API.

Для подписки на пуш-уведомления необходимо использовать API PushManager.subscribe. Этот метод возвращает промис‚ который разрешается объектом PushSubscription. Затем этот объект можно использовать для отправки уведомлений на сервер.

Протоколы передачи данных: HTTP/2 и Web Push

Для эффективной доставки пуш-уведомлений используются два протокола: HTTP/2 и Web Push. HTTP/2 обеспечивает быструю передачу данных между сервером и браузером. Он поддерживает мультиплексирование запросов‚ сжатие заголовков и серверный пуш. Эти функции снижают задержки при обмене данными. Например‚ при регистрации Service Worker браузер отправляет запрос на сервер через HTTP/2‚ что ускоряет процесс подписки.

Web Push — это стандарт‚ разработанный для доставки уведомлений через push-сервисы. Сервер отправляет данные на push-сервис через API‚ используя протокол Web Push. Push-сервис‚ в свою очередь‚ передает сообщение браузеру. Для работы требуется endpoint‚ сгенерированный браузером‚ и пара ключей (public и private). Эти данные обеспечивают шифрование сообщений. Пример endpoint: https://fcm.googleapis.com/fcm/send/ABC123. Протокол Web Push работает независимо от открытой вкладки‚ что позволяет получать уведомления даже при закрытом сайте.

HTTP/2 и Web Push решают разные задачи в архитектуре. HTTP/2 используется для синхронных запросов‚ например‚ при получении данных о подписке. Web Push применяется для асинхронной доставки уведомлений. Для реализации системы необходимы оба протокола: HTTP/2 для взаимодействия с сервером‚ Web Push — для связи с push-сервисом. Это повышает надежность и скорость доставки сообщений.

Использование VAPID для аутентификации

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

Чтобы использовать VAPID‚ необходимо сгенерировать пару ключей. Это можно сделать с помощью утилиты web-push. Затем необходимо отправить публичный ключ на сервер‚ который будет использовать его для шифрования сообщений.

При отправке пуш-уведомления сервер должен указать публичный ключ в заголовке Authorization. Это позволяет push-сервису проверить аутентичность сервера и обеспечить безопасность доставки сообщений.

Применение VAPID повышает безопасность доставки пуш-уведомлений‚ поскольку только сервер с правильным приватным ключом может отправлять сообщения. Это защищает от спама и фишинговых атак.

Кроме того‚ VAPID позволяет избежать ограничений на отправку пуш-уведомлений‚ которые могут быть установлены push-сервисом. Это связано с тем‚ что push-сервис может проверить аутентичность сервера и убедиться‚ что он не занимаеться спамом.

Интеграция с Firebase Cloud Messaging (FCM)

Сервер шлёт POST на https://fcm.googleapis.com/fcm/send‚ добавляя заголовок Authorization: key=AAAA... и тело JSON: {"to":"token"‚"notification":{"title":"привет"‚"body":"это FCM"}}. FCM выдаёт ключ серверного типа в консоли Firebase; он состоит из и валиден круглые сутки без срока действия. Когда пользователь впервые заходит на сайт‚ скрипт получает токен через messaging.getToken и заносит его в PostgreSQL‚ а индекс по столбцу token сокращает поиск до 3 ms при миллионе записей.

Фронтенд получает push даже при закрытой вкладке: FCM преобразует сообщение в Web Push-пакет‚ а Service Worker ловит событие push‚ отрисовывая уведомление за 38 ms согласно замерам в Chrome DevTools. Инфраструктура масштабируется: один бесплатный проект Google поддерживает 3000 запросов в секунду без включения биллинга. Если нужно больше‚ переходишь на Blaze Plan и платишь от $0‚06 за 100 000 сообщений.

Результат: никаких собственных push-прокси‚ лишних контейнеров или SSL-сертификатов. FCM хранит очередь недоставленных сообщений 28 дней‚ отслеживает отписки и возвращает HTTP-код 401 сразу при просроченном токене‚ что исключает лишние попытки отправки и снижает нагрузку на бэкенд.

Работа с APNs для iOS

APNs принимает токены длиной 64 байта‚ выданные iOS-приложением. Сервер формирует JSON вида {"aps":{"alert":"Текст"‚"badge":1}}‚ оборачивает в JWT-токен со сроком действия 3600 секунд и POSTит на https://api.push.apple.com/3/device/токен. TLS-сертификат или .p8-ключ закреплен за Bundle ID приложения.

Сообщение доходит за 300–400 мс по HTTP/2-соединению постоянного типа. Приложенное окно 4096 байт вмещает заголовок‚ текст и бейдж. APNs возвращает код 200 при доставке или 410 при отозванном токене‚ что позволяет удалять старые адреса из Базы Данных без ошибок.

Веб-проект не может обращаться к APNs напрямую; iOS требует нативное приложение. Решение — PWA-оболочка Swift‚ занимающая 23 КБ: она получает токен и передаёт его в JavaScript-часть с помощью WKScriptMessageHandler.

Это сокращает затраты на серверную инфраструктуру: один Apple Developer Cert действует год без ограничений на количество пушей‚ а схема APNs отфильтровывает недействительные токены.

Этапы отправки уведомления от сервера

Разработчик передаёт на сервер токен FCM/Web Push‚ полученный от Service Worker в момент загрузки страницы. Ключ VAPID подпишется через хэш SHA-256 и Яндекс Алиса подтвердит с помощью сервера аутентификации. Чтобы применять качественные push-сообщения‚ несколько разных серверов взаимодействуют разом:

1. Сервер веб-сайта собирает JSON-данные (заголовок‚ тело).
2. Запрос POST вылетает на https://fcm.googleapis.com/fcm/send или https://fcm-alert.golos.vip/push.
3. FCM/WebPush выгружает уведомлений в браузер Safari/Chrome/Opera через push-сервис Apple‚ Google‚ FCM.
4. Service Worker в браузере ловит событие push и запускает Notifications API‚ приняв ответ в виде заголовка‚ тела и иконки.

Время задержки: от 200 ms до 10 секунд. 30% времени маятся на шифровку VAPID‚ 60% раздача push-сервиса‚ 10% на доставку его до клиента‚ поскольку сервисы у Apple и Google занимают до 7 секунд доставки.

Обработка уведомлений в Service Worker

Когда push-сообщение приходит на браузер‚ Service Worker ловит событие push. Затем он запускает обработчик события‚ который получает данные из сообщения и запускает Notifications API.

Notifications API — это интерфейс для создания и управления уведомлениями. Он позволяет указать заголовок‚ текст и иконку уведомления.

Service Worker может также использовать метод waitUntil для асинхронной обработки события push. Это позволяет ему выполнить некоторые действия‚ такие как запрос на сервер или обработка данных‚ перед тем как показать уведомление.

После того‚ как уведомление показано‚ Service Worker может использовать событие notificationclick для обработки клика на уведомление. Это позволяет ему выполнить некоторые действия‚ такие как открытие страницы или запуск приложения.

Service Worker может также использовать метод close для закрытия уведомления. Это позволяет ему удалить уведомление из списка уведомлений.

Всего существует несколько событий‚ которые можно использовать для обработки уведомлений в Service Worker:

• push — событие‚ которое срабатывает‚ когда приходит push-сообщение.
• notificationclick — событие‚ которое срабатывает‚ когда пользователь кликает на уведомление.
• notificationclose — событие‚ которое срабатывает‚ когда уведомление закрывается.

Шифрование данных в Web Push

Web Push шифрует полезную нагрузку с помощью ключа‚ который получает из публичного P-256 ключа браузера при подписке. Сервер вычисляет общий секрет ECDH‚ затем формирует 32-байтовый ключ контента AEAD_AES_128_GCM и 16-байтовый вектор инициализации. Стандарт RFC 8291 гарантирует‚ что push-сервис не читает данные: только целевое устройство способно расшифровать их.

Сжатие применяется алгоритмом «aes128gcm» и уменьшает размер сообщения до 4096 байт‚ что экономит трафик и ускоряет доставку. При отсутствии защиты браузеры отвергают пакет‚ возвращая DOMException с кодом 401. Инструмент web-push генерирует токен за 0‚8 мс и пакует структуру Salt (16 байт) + Record Size (4 байта) + Ciphertext без дополнительного кода.

Результат: сообщение приходит защищённым‚ что исключает «трафик в открытую» и подтверждает целостность данных на приёме‚ так как Service Worker проверяет контрольную сумму и только после этого показывает уведомление.

Ошибки и обработка отказов в при отправке пушей

Для проектирования архитектуры взаимодействия сервера и браузера при отправке пушей нужно учитывать возможные ошибки и обработку отказов.

Отказы могут возникнуть из-за того‚ что уведомление не доходит до браузера или пользователь его отбраковывает. В таких случаях сервер должен определить причину отказа и принять меры.

Например‚ при отсутствии подключения к Интернету или в случае несвоевременной отправки сервером уведомления‚ браузер может отказаться от его обработки. В этом случае нужно повторить отправку уведомления и настроить сервер для автоматического повторного отправления.

Если пользователь отбраковывает уведомление‚ сервер должен выдать уведомление об ошибке‚ указав причину и способы её устранения.

Для предотвращения возникновения ошибок и обработки отказов при проектировании архитектуры взаимодействия сервера и браузера при отправке пушей следует:

• Убедиться в наличии лицензии на использование технологии при отправке уведомлений.
• Реализовать мониторинг состояния работы сервера и браузеров пользователей.
• Установить ограничения на количество и время отправки уведомлений.
• Настроить автоматическое повторное отправление уведомлений в случае отказов.
• Использовать механизмы защиты от бракованных и поддельных уведомлений.

Например‚ при использовании технологии Web Push при отправке уведомлений браузером и сервером необходимо следовать протоколу Common Interface для обмена информацией и использовать установленные безопасные соединения.

Таким образом‚ при проектировании архитектуры взаимодействия сервера и браузера при отправке пушей следует следовать рекомендациям и протоколам‚ что позволит минимизировать возможные ошибки и обработать отказы моментально.

Масштабирование системы рассылки

Для обработки миллионов подписок система должна масштабироваться горизонтально. Брокеры сообщений (например‚ Apache Kafka или RabbitMQ) распределяют нагрузку между серверами. Kafka демонстрирует пропускную способность до 2 млн сообщений в секунду на кластер из 3 узлов с дисками NVMe. Балансировщики (Nginx‚ HAProxy) направляют запросы на менее загруженные серверы‚ снижая задержки на 40% при 10 тыс. одновременных подписках.

Шифрование данных увеличивает нагрузку на CPU. Для решения задачи используются отдельные серверы с поддержкой AES-NI. На оборудовании с процессорами Intel Xeon E5-2686v4 (18 ядер‚ 2‚3 ГГц) и 64 ГБ ОЗУ обработка 10 тыс. зашифрованных сообщений занимает 120 мс. Выделенные ресурсы предотвращают блокировку основного потока.

Мониторинг через Prometheus и Grafana отслеживает метрики: задержка доставки‚ процент ошибок 4xx/5xx‚ использование памяти. Алерты срабатывают при превышении средней задержки в 500 мс или падении доставки ниже 99‚5%. Интеграция с PagerDuty обеспечивает уведомления через SMS и email при критических сбоях.

Кэширование токенов и подписок в Redis ускоряет доступ к данным. База из 1 млн записей обслуживается за 0‚5 мс на сервере с 32 ГБ ОЗУ. TTL для записей устанавливается на 24 часа‚ чтобы исключить устаревшие токены. Снижение обращений к основной БД (PostgreSQL‚ MySQL) повышает общую пропускную способность на 30%.

Горизонтальное масштабирование реализуется через Kubernetes. При росте нагрузки автоматически запускаются новые поды с контейнерами. Тесты показывают‚ что кластер из 5 серверов (по 8 ядер и 64 ГБ ОЗУ) масштабируется до 20 узлов за 90 секунд при пике в 50 тыс. подписок. Это обеспечивает стабильную работу даже при внезапном увеличении трафика.

Тестирование пушей в браузере

Чтобы протестировать пуш-уведомления в браузере‚ необходимо выполнить ряд действий. Сначала нужно убедится‚ что браузер поддерживает пуш-уведомления. Для этого можно использовать сервис Can I Use.

Затем необходимо зарегистрировать Service Worker и получить токен для отправки пуш-уведомлений. Это можно сделать с помощью метода registration.pushManager.subscribe.

После получения токена можно отправить тестовое пуш-уведомление с помощью утилиты web-push. Если уведомление доставлено успешно‚ браузер должен отобразить уведомление.

Для автоматизации тестирования можно использовать инструменты типа Selenium или Cypress. Они позволяют имитировать действия пользователя и проверить доставку пуш-уведомлений.

Также необходимо протестировать сценарии отказа‚ такие как отсутствие подключения к Интернету или блокировка пуш-уведомлений браузером. Для этого можно использовать инструменты типа BrowserStack или LambdaTest.

Тестирование пуш-уведомлений в браузере позволяет убедиться‚ что они доставляются корректно и работают как ожидается.

Альтернативы Web Push

Три технологии заменяют Web Push без Service Worker: WebSocket с флагом keep-alive‚ Server-Sent Events (SSE) и Push API на базе iOS/Android SDK.

WebSocket устанавливает TCP-соединение‚ поддерживающее 65 536 одновременных каналов на один IP и обеспечивает доставку за 40 мс внутри одной зоны DNS. Сервер шлёт JSON-фреймы‚ браузер ловит onmessage и отрисовывает уведомление уведомлением через new Notification. Потребляет 70 КБ памяти на 1000 клиентов в Chrome DevTools.

SSE работает через обычный HTTP/1.1‚ требует лишь одного TCP-транспорта и поддерживает автоматический перезапуск при разрывах. Пропускная способность до 50 000 сообщений в секунду на слабом VPS с 1 Gb RAM за счёт gzip-сжатия. Ограничение: данные идут от сервера к клиенту‚ обратный путь не предусмотрен.

Нативные SDK для iOS и Android (FCM‚ APNs) принимают пуш-уведомления при полностью закрытом браузере. Компания Gravitec.net зафиксировала‚ что FCM доставляет 97 % сообщений за первые 17 секунд‚ APNs — за 21 секунду. SDK требуют APK/IPA весом от 18 КБ и выдают токен длиной 64 байта.

Выбор: используйте WebSocket или SSE‚ если важен диалог с сервером без инсталляции приложений; Web Push или нативные SDK‚ если нужны фоновые пуши при минимальном расходе трафика и батареи.

FAQ: Вопрос-Ответ

Почему без Service Worker не обойтись?
Service Worker, единственный механизм‚ который работает в фоновом режиме‚ даже если вкладка закрыта. Он ловит события push‚ расшифровывает данные и вызывает Notifications API. Без него уведомления не будут показываться при неактивной странице.

Как VAPID защищает от спама?
VAPID использует пару ключей: публичный и приватный. Сервер шифрует сообщение с помощью приватного ключа‚ а push-сервис проверяет подпись через публичный. Если подпись не совпадает‚ сообщение отбрасывается. Это исключает отправку уведомлений от несанкционированных источников.

Почему на iOS пуши не работают через браузер?
iOS не поддерживает Web Push напрямую. Для доставки требуется нативное приложение‚ которое получает токен от APNs и передаёт его в JavaScript-код через WKScriptMessageHandler. Без этого браузер Safari не может подписаться на уведомления.

Как проверить пуши без сервера?
Используйте утилиту web-push. Сгенерируйте пару ключей‚ отправьте публичный ключ в браузер‚ а приватный, в команду web-push send-notification. Это позволит тестировать доставку без настройки серверной инфраструктуры.

Почему FCM лучше‚ чем собственная система?
FCM масштабируется автоматически: бесплатный тариф поддерживает 3000 запросов в секунду‚ а Blaze Plan — до 100 000 сообщений за $0‚06. Это исключает необходимость развертывания собственных серверов‚ балансировщиков и очередей сообщений.

Какие ошибки чаще всего возникают при отправке?
Код 401, истёк срок действия токена. Код 403 — превышен лимит сообщений. Код 404, неверный endpoint. Сервер должен обрабатывать эти ошибки‚ удалять недействительные токены и повторять отправку через 30 минут.

Можно ли отправлять медиа в уведомлениях?
Да‚ но только через Notifications API. Добавьте параметр icon в JSON-данные. Например: {"title": "Фото"‚ "body": "Новое изображение"‚ "icon": "https://example.com/image.png"}. Размер иконки не должен превышать 4096 байт.

Как уменьшить задержку доставки?
Используйте HTTP/2 для синхронных запросов и Web Push для асинхронных. Задержка через FCM составляет 200–400 мс‚ через APNs — 300–700 мс. Для критичных данных применяйте WebSocket с флагом keep-alive.

Зачем нужны брокеры сообщений в масштабировании?
Брокеры (Kafka‚ RabbitMQ) распределяют нагрузку между серверами. Kafka обрабатывает до 2 млн сообщений в секунду на кластер из 3 узлов‚ снижая риск перегрузки основного сервера и обеспечивая стабильную доставку при пиковых нагрузках.

Как тестировать пуши на разных браузерах?
Используйте BrowserStack или LambdaTest. Эти инструменты позволяют проверять доставку на Chrome‚ Firefox‚ Safari и мобильных устройствах. Тестирование занимает 10–15 минут и покрывает сценарии блокировки уведомлений и отсутствия интернета.

Почему шифрование увеличивает нагрузку на CPU?
Шифрование данных через AES-128-GCM требует вычисления общего секрета ECDH и генерации ключей. На сервере с Intel Xeon E5-2686v4 обработка 10 тыс. сообщений занимает 120 мс. Для оптимизации выделяйте отдельные ресурсы под шифрование.

Как отслеживать статистику доставки?
Интегрируйте Prometheus и Grafana. Они отслеживают задержку доставки‚ процент ошибок и использование памяти. Алерты срабатывают при превышении средней задержки в 500 мс или падении доставки ниже 99‚5%.

Комментарий эксперта

Архитектура пуш-уведомлений требует баланса между надежностью и производительностью.
Сервисы вроде FCM и APNs обеспечивают доставку‚ но их ограничения (лимиты‚ задержки) требуют резервного копирования токенов и очередей сообщений. Например‚ FCM поддерживает 3000 запросов в секунду на бесплатном тарифе‚ а APNs для iOS требует обновления токенов каждые 28 дней. Используйте Redis для кэширования подписок и автоматического удаления устаревших записей по TTL.

Шифрование данных в Web Push — не опциональный шаг‚ а обязательное требование.
При передаче через HTTP/2 и Web Push данные шифруются через AES-128-GCM. На сервере с AES-NI обработка 10 тыс. сообщений занимает 120 мс. Отказ от шифрования приводит к ошибке DOMException с кодом 401. Для генерации ключей применяйте web-push, он создает VAPID-токен за 0‚8 мс.

Масштабирование системы начинается с брокеров сообщений.
Kafka обрабатывает до 2 млн сообщений в секунду на кластер из 3 узлов с NVMe-дисками. RabbitMQ подходит для сценариев с частыми ошибками: он сохраняет сообщения в очередях и повторяет отправку при кодах 4xx/5xx. Балансировщики (Nginx‚ HAProxy) снижают задержки на 40% при 10 тыс. подписках.

Тестирование — этап‚ который нельзя игнорировать.
Используйте BrowserStack для проверки доставки на Chrome‚ Firefox‚ Safari и мобильных устройствах. Интегрируйте Prometheus и Grafana для мониторинга: отслеживайте задержку доставки‚ процент ошибок и использование памяти. Алерты должны срабатывать при превышении средней задержки в 500 мс.

Альтернативы Web Push оправданы в узких сценариях.
WebSocket с флагом keep-alive подходит для диалога с сервером‚ но потребляет 70 КБ памяти на 1000 клиентов. SSE через HTTP/1.1 дешевле‚ но односторонний. Нативные SDK (FCM‚ APNs) — единственный способ доставить пуши при закрытом браузере на iOS/Android.

Интегрируйте их в систему аналитики: отслеживайте клики по уведомлениям‚ отписки и время отклика. Используйте данные для сегментации рассылки: например‚ отправляйте критические уведомления через FCM‚ а рекламные, через Web Push. Это повысит вовлеченность на 23% согласно исследованиям Gravitec.net.