Как работают push-уведомления iOS?

Каким образом push-уведомления iOS доставляются на конкретное устройство, при этом ему не нужно опрашивать сервер?

Например, предположим, что я получил новое сообщение на Facebook. Facebook уведомляет Apple, что мое устройство должно получать уведомление как таковое. Но как Apple узнает, на какое устройство / IP-адрес отправить сообщение?

Для меня это было слишком много, чтобы так комментировать.

Из документации.

Служба push-уведомлений Apple (APN) распространяет push-уведомления на устройства, на которых зарегистрированы приложения для получения этих уведомлений. Каждое устройство устанавливает аккредитованное и зашифрованное IP-соединение со службой и получает уведомления по этому постоянному соединению. Провайдеры подключаются к APN через постоянный и безопасный канал, отслеживая входящие данные, предназначенные для их клиентских приложений. Когда поступают новые данные для приложения, провайдер подготавливает и отправляет уведомление по каналу в APN, которые отправляют уведомление на целевое устройство.

Я предлагаю прочитать документацию для получения дополнительной информации о том, как использовать и настраивать. Это все есть.

Всплывающее уведомление

Каждое устройство может быть обновлено данными, используя собственные уникальные токены устройства. Эта картина все объясняет. .

Я создал инфографику, чтобы объяснить рабочий процесс push-уведомлений. Надеюсь, это будет полезно.

Обзор APN

Служба Apple Push Notification (APN) - это центральная часть функции удаленных уведомлений. Это надежный, безопасный и высокоэффективный сервис для разработчиков приложений для распространения информации на устройства iOS (и, косвенно, watchOS), tvOS и macOS.

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

Другая половина соединения для отправки уведомлений - постоянный безопасный канал между сервером поставщика и APN - требует настройки в вашей учетной записи онлайн-разработчика и использования предоставленных Apple криптографических сертификатов. Провайдер - это сервер, который вы развертываете и управляете, который вы настраиваете для работы с APN. На рис. 1-1 показан путь доставки удаленного уведомления.

Рисунок 1-1. Доставка удаленного уведомления от поставщика в приложение.

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

Если уведомление для вашего приложения приходит с включенным устройством, но приложение не запущено, система все равно может отображать уведомление. Если устройство выключено, когда APN отправляет уведомление, APN удерживает уведомление и повторяет попытку позже (подробности см. В разделах «Качество обслуживания», «Store-and-Forward» и «Объединенные уведомления»).

Обязанности провайдера

Серверы вашего провайдера имеют следующие обязанности по участию в APN:

• Получение через APN глобально уникальных токенов устройств для конкретных приложений и других соответствующих данных от экземпляров вашего приложения на пользовательских устройствах. Это позволяет провайдеру знать о каждом запущенном экземпляре вашего приложения.
• Определение, в соответствии с дизайном вашей системы уведомлений, когда удаленные уведомления должны быть отправлены на каждое устройство.
• Создание и отправка запросов уведомлений в APN, каждый запрос содержит полезную нагрузку уведомления и информацию о доставке; Затем APN отправляет соответствующие уведомления на предполагаемые устройства от вашего имени.

Для каждого запроса удаленного уведомления, отправляемого поставщиком, он должен:

• Создайте словарь JSON, содержащий полезную нагрузку уведомления, как описано в разделе Создание полезной нагрузки удаленного уведомления.
• Добавьте полезные данные, глобально уникальный токен устройства и другую информацию о доставке в запрос HTTP / 2. Дополнительные сведения о токенах устройств см. В разделах «Доверие подключения APN к устройству» и «Токены устройства». Для получения информации о формате запроса HTTP / 2, а также возможных ответах и ​​ошибках от APN см. Обмен данными с APN.
• Отправьте запрос HTTP / 2 в APN, включая криптографические учетные данные в форме токена или сертификата, по постоянному безопасному каналу.
• Установка этого безопасного канала описана в Архитектуре безопасности.

Использование нескольких провайдеров

На рис. 1-2 изображена виртуальная сеть, которую APN разрешает для устройств, на которых запущены ваши приложения. Чтобы справиться с нагрузкой уведомлений, вы обычно развертываете несколько поставщиков, каждый из которых имеет собственное постоянное и безопасное соединение с APN. Затем каждый провайдер может отправлять запросы на уведомление, нацеленные на любое устройство, для которого у провайдера есть действительный токен устройства.

Рисунок 1-2 Отправка удаленных уведомлений от нескольких поставщиков на несколько устройств

Качество обслуживания, промежуточное хранение и объединенные уведомления

Служба Apple Push Notification включает компонент качества обслуживания (QoS), который выполняет функцию промежуточного хранения. Если APN пытается доставить уведомление, а целевое устройство находится в автономном режиме, APN сохраняет уведомление в течение ограниченного периода времени и доставляет его, когда устройство снова становится доступным. Этот компонент хранит только самые последние уведомления для каждого устройства и приложения. Если устройство находится в автономном режиме, отправка запроса на уведомление, предназначенного для этого устройства, приводит к отклонению предыдущего запроса. Если устройство остается в автономном режиме в течение длительного времени, все его уведомления, хранящиеся в APN, удаляются.

Чтобы разрешить объединение похожих уведомлений, вы можете включить идентификатор свертывания в запрос уведомления. Обычно, когда устройство находится в сети, каждый запрос уведомления, который вы отправляете в APN, приводит к доставке уведомления на устройство. Однако, когда ключ apns-collapse-id присутствует в заголовке вашего запроса HTTP / 2, APN объединяет запросы, значение которых для этого ключа одинаково. Например, служба новостей, которая дважды отправляет один и тот же заголовок, может использовать одно и то же значение идентификатора свертывания для обоих запросов. Затем APN объединяют два запроса в одно уведомление для доставки на устройство. Подробнее о ключе apns-collapse-id.

Архитектура безопасности

APN обеспечивает сквозную криптографическую проверку и аутентификацию с использованием двух уровней доверия: доверие подключения и доверие токенов устройства.

Доверие подключения работает между провайдерами и APN, а также между APN и устройствами.

Доверие токенов устройства работает от начала до конца для каждого удаленного уведомления. Это гарантирует, что уведомления маршрутизируются только между правильной начальной (поставщик) и конечной (устройство) точками.

Токен устройства - это непрозрачный экземпляр NSData, который содержит уникальный идентификатор, присвоенный Apple определенному приложению на определенном устройстве. Только APN могут декодировать и читать содержимое токена устройства. Каждый экземпляр приложения получает свой уникальный токен устройства при регистрации в APN и должен затем переслать токен своему провайдеру, как описано в разделе Настройка поддержки удаленных уведомлений. Провайдер должен включать токен устройства в каждый запрос push-уведомления, нацеленный на связанное устройство; APNs использует токен устройства, чтобы уведомление было доставлено только той уникальной комбинации приложение-устройство, для которой оно предназначено.

APN могут выдавать новый токен устройства по разным причинам:

• Пользователь устанавливает ваше приложение на новое устройство
• Пользователь восстанавливает устройство из резервной копии
• Пользователь переустанавливает операционную систему
• Другие системные события

В результате приложения должны запрашивать токен устройства во время запуска, как описано в разделах «Доверие подключения APN к устройству» и «Токены устройства». Примеры кода см. В разделе «Регистрация для получения удаленных уведомлений».

Чтобы установить сеансы TLS на основе HTTP / 2 с APN, вы должны убедиться, что корневой сертификат GeoTrust Global CA установлен на каждом из ваших провайдеров. Если провайдер использует macOS, этот корневой сертификат по умолчанию находится в связке ключей. В других системах для этого сертификата может потребоваться явная установка. Вы можете скачать этот сертификат с веб-сайта корневых сертификатов GeoTrust. Вот прямая ссылка на сертификат.

На рис. 1-3 показано использование API провайдера APN на основе HTTP / 2 для установления доверия и использование токенов аутентификации провайдера JWT для отправки уведомлений.

Рисунок 1-3 Установление и использование доверительных отношений с провайдером на основе токенов

Как показано на рисунке 1-3, доверие провайдера на основе токенов работает следующим образом:

Ваш провайдер запрашивает безопасное соединение с APN с использованием безопасности транспортного уровня (TLS), что показано на рисунке стрелкой с надписью «инициирование TLS».

Затем APNs предоставляет вашему провайдеру сертификат APNs, представленный следующей стрелкой на рисунке (помеченный «Сертификат APN»), который затем проверяет ваш провайдер.

На этом этапе установлено доверие к соединению, и ваш сервер провайдера может отправлять запросы удаленного push-уведомления на основе токенов в APN. Каждый запрос уведомления, который отправляет ваш провайдер, должен сопровождаться токеном аутентификации JWT, представленным на рисунке в виде стрелки с надписью «Уведомление push».

APN отвечает на каждое нажатие, представленное на рисунке стрелкой с надписью «HTTP / 2 response».

Подробную информацию об ответах, которые ваш провайдер может получить на этом этапе, см. В разделе «Ответ HTTP / 2 от APN».

На рис. 1-4 показано использование сертификата SSL, выпущенного Apple, для установления доверия между провайдером и APN. В отличие от рисунка 1-3, на этом рисунке не показано собственно push-уведомление, но оно останавливается при установлении соединения безопасности транспортного уровня (TLS). В схеме доверия на основе сертификатов запросы push-уведомлений не аутентифицируются, но проверяются с помощью соответствующего токена устройства.

Рисунок 1-4 Установление доверия к соединению с провайдером на основе сертификатов

Как показано на рис. 1-4, доверие между поставщиками и APN на основе сертификатов работает следующим образом:

Ваш провайдер запрашивает безопасное соединение с APN с использованием безопасности транспортного уровня (TLS), что показано на рисунке стрелкой с надписью «инициирование TLS».

Затем APNs предоставляет вашему провайдеру сертификат APNs, представленный следующей стрелкой на рисунке (помеченный «Сертификат APN»), который затем проверяет ваш провайдер.

Затем ваш провайдер должен отправить свой сертификат поставщика, предоставленный Apple (который вы ранее получили из своей учетной записи онлайн-разработчика, как описано в разделе «Создание универсального клиентского SSL-сертификата APN» в справке Xcode) обратно в APN, представленные стрелкой с надписью «Provider» сертификат ».

Затем APN проверяет ваш сертификат провайдера, тем самым подтверждая, что запрос на соединение исходит от законного провайдера, и устанавливает ваше TLS-соединение.

На этом этапе установлено доверие к соединению, и сервер вашего провайдера может отправлять запросы удаленного push-уведомления на основе сертификатов в APN.

Доверие подключения APN к устройству и токены устройства

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

Каждое устройство имеет криптографический сертификат и частный криптографический ключ, предоставляемый операционной системой при первоначальной активации устройства и хранящийся в связке ключей устройства. Во время активации APN аутентифицирует и проверяет соединение с устройством на основе сертификата и ключа, как показано на рисунке 6-5.

Рисунок 1-5 Установление доверительного соединения между устройством и APN

Как показано на рис. 1-5, доверительные отношения между APN и устройством работают следующим образом:

• Согласование доверия начинается, когда устройство инициирует соединение TLS с APN, как показано в верхней стрелке на рисунке.
• APNs возвращает на устройство сертификат APNs.
• Операционная система проверяет этот сертификат, а затем, как показано стрелкой «Сертификат устройства», отправляет сертификат устройства в APN.
• Наконец, как показано нижней стрелкой на рисунке, APN проверяет сертификат устройства, устанавливая доверие.
• Если между APN и устройством установлено TLS-соединение, приложения на устройстве могут регистрироваться в APN, чтобы получать свои специфичные для приложения токены устройства для удаленных уведомлений. Дополнительные сведения и примеры кода см. В разделе «Регистрация для получения удаленных уведомлений» в разделе «Настройка поддержки удаленных уведомлений».

После получения токена устройства приложение должно подключиться к поставщику, связанному с приложением, и переслать ему токен. Этот шаг необходим, потому что провайдер должен включить токен устройства позже, когда он отправит запрос уведомления в APN, нацеленные на устройство. Код, который вы пишете для пересылки токена, также показан в разделе «Регистрация для получения удаленных уведомлений».

Независимо от того, активирует ли пользователь устройство в первый раз или APN выпустили новый токен устройства, процесс аналогичен и показан на рисунке 6-6.

Рисунок 1-6 Управление токеном устройства

Получение и обработка токена устройства для конкретного приложения работает следующим образом:

Ваше приложение регистрируется в APN для удаленных уведомлений, как показано в верхней стрелке. Если приложение уже зарегистрировано и токен устройства для конкретного приложения не изменился, система быстро возвращает существующий токен приложению, и этот процесс переходит к шагу 4.

Когда требуется новый токен устройства, APN генерирует его, используя информацию, содержащуюся в сертификате устройства. Он шифрует токен с помощью ключа токена и возвращает его на устройство, как показано средней стрелкой вправо.

Система доставляет токен устройства обратно в ваше приложение, вызывая ваше application: didRegisterForRemoteNotificationsWithDeviceToken: метод делегата.

После получения токена ваше приложение (в методе делегата) должно переслать его вашему провайдеру в двоичном или шестнадцатеричном формате. Ваш провайдер не может отправлять уведомления на устройство без этого токена. Дополнительные сведения см. В разделе «Регистрация для получения удаленных уведомлений» в разделе «Настройка поддержки удаленных уведомлений».

ВАЖНЫЙ

Токены устройств APN имеют переменную длину. Не фиксируйте их размер жестко.

Когда ваш провайдер отправляет запрос push-уведомления в APN, он включает в себя токен устройства, который определяет уникальную комбинацию приложение-устройство. Этот шаг показан стрелкой «Token, Payload» между провайдером и APN на Рисунке 6-7. APNs расшифровывает токен, чтобы убедиться в действительности запроса и определить целевое устройство. Если APN определяет, что отправитель и получатель являются законными, он затем отправляет уведомление на идентифицированное устройство.

Рисунок 1-7 Путь удаленного уведомления от провайдера к устройству

После того, как устройство получит уведомление (и после последнего шага, показанного на рис. 1-7), система пересылает удаленное уведомление вашему приложению.

Ссылка: Служба push-уведомлений Apple

Теперь посмотрите здесь, чтобы понять технический поток: как реализовать службу уведомлений Apple Push в приложении iOS?

Устройство не опрашивает сервер для получения push-уведомлений.

Для простоты рассмотрим, что iPhone подключен к Интернету. При подключении к Интернету iPhone устанавливает соединение с сервером Apple Push Notifications, это соединение является открытым, что означает, что данные могут быть отправлены на iPhone с сервера в момент их поступления на сервер.

Apple не использует протокол HTTP для push-уведомлений, но если вы понимаете протокол HTTP, это почти аналогичная методология.

http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push

В этой статье есть действительно хорошее объяснение push-уведомлений .

В iOS приложения не могут многое делать в фоновом режиме. Приложениям разрешено выполнять только ограниченный набор действий, чтобы экономить заряд батареи.

Но что, если произойдет что-то интересное, и вы хотите сообщить об этом пользователю, даже если он в настоящее время не использует ваше приложение?