О сообщениях FCM

Firebase Cloud Messaging (FCM) предлагает широкий спектр вариантов и возможностей обмена сообщениями. Информация на этой странице предназначена для того, чтобы помочь вам понять различные типы сообщений FCM и то, что вы можете с ними делать.

Типы сообщений

С помощью FCM вы можете отправлять клиентам два типа сообщений:

• Сообщения уведомлений, иногда называемые «отображаемыми сообщениями». Они автоматически обрабатываются FCM SDK.
• Сообщения данных, которые обрабатываются клиентским приложением.

Сообщения уведомлений содержат предопределенный набор видимых пользователю ключей. Сообщения данных, напротив, содержат только ваши пользовательские пары ключ-значение. Сообщения уведомлений могут содержать необязательную полезную нагрузку данных. Максимальная полезная нагрузка для обоих типов сообщений составляет 4000 байт, за исключением отправки сообщений из консоли Firebase, где применяется ограничение в 1024 символа.

	Использовать сценарий	Как отправить
Уведомление	FCM SDK отображает сообщение на устройствах конечных пользователей от имени клиентского приложения, когда оно работает в фоновом режиме. В противном случае, если приложение работает на переднем плане при получении уведомления, код приложения определяет поведение. Уведомляющие сообщения имеют предопределенный набор видимых пользователю ключей и необязательную полезную нагрузку данных в виде настраиваемых пар ключ-значение.	В доверенной среде, такой как облачные функции или ваш сервер приложений, используйте Admin SDK или протоколы сервера FCM : установите ключ notification . Может иметь необязательную полезную нагрузку данных. Всегда разборный. Посмотрите несколько примеров отображения уведомлений и отправки полезных данных запроса. Используйте композитор уведомлений : введите текст сообщения, заголовок и т. д. и отправьте. Добавьте необязательную полезную нагрузку данных, предоставив пользовательские данные.
Сообщение данных	Клиентское приложение отвечает за обработку сообщений данных. Сообщения данных содержат только настраиваемые пары ключ-значение без зарезервированных имен ключей (см. ниже).	В доверенной среде, такой как облачные функции или ваш сервер приложений, используйте Admin SDK или протоколы сервера FCM : задайте только ключ data .

Используйте уведомления, если вы хотите, чтобы FCM SDK автоматически отображал уведомления, когда ваше приложение работает в фоновом режиме. Используйте сообщения данных, если вы хотите обрабатывать сообщения с помощью собственного кода клиентского приложения.

FCM может отправлять уведомляющие сообщения, включая необязательные полезные данные. В таких случаях FCM обрабатывает отображение полезной нагрузки уведомления, а клиентское приложение обрабатывает полезную нагрузку данных.

Уведомления

Для тестирования или для маркетинга и повторного вовлечения пользователей вы можете отправлять уведомления с помощью консоли Firebase . Консоль Firebase обеспечивает A/B-тестирование на основе аналитики, чтобы помочь вам уточнить и улучшить маркетинговые сообщения.

Чтобы программно отправлять уведомления с помощью Admin SDK или протоколов FCM, задайте ключ notification с необходимым предопределенным набором параметров "ключ-значение" для видимой пользователю части сообщения уведомления. Например, вот уведомление в формате JSON в приложении для обмена мгновенными сообщениями. Пользователь может ожидать увидеть сообщение с заголовком «Португалия против Дании» и текстом «отличный матч!» на устройстве:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    }
  }
}

Уведомления доставляются в панель уведомлений, когда приложение находится в фоновом режиме. Для приложений на переднем плане сообщения обрабатываются функцией обратного вызова.

См. справочную документацию для получения полного списка предопределенных ключей, доступных для построения уведомлений:

• Объект уведомления протокола HTTP v1
• Полезная нагрузка уведомления устаревшего протокола HTTP
• Полезная нагрузка уведомления протокола XMPP

Сообщения данных

Установите соответствующий ключ с вашими пользовательскими парами ключ-значение, чтобы отправить полезные данные в клиентское приложение.

Например, вот сообщение в формате JSON в том же приложении обмена мгновенными сообщениями, что и выше, где информация инкапсулирована в общий ключ data , и ожидается, что клиентское приложение интерпретирует содержимое:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    }
  }
}

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

Шифрование сообщений данных

Транспортный уровень Android (см. архитектуру FCM ) использует двухточечное шифрование. В зависимости от ваших потребностей вы можете добавить сквозное шифрование к сообщениям данных. FCM не предоставляет комплексного решения. Однако доступны внешние решения, такие как Capillary или DTLS .

Сообщения уведомлений с необязательными полезными данными

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

Поведение приложения при получении сообщений, содержащих как уведомления, так и полезные данные, зависит от того, находится ли приложение в фоновом или на переднем плане — по сути, от того, активно оно или нет во время получения.

• В фоновом режиме приложения получают полезные данные уведомлений в области уведомлений и обрабатывают полезные данные только тогда, когда пользователь нажимает на уведомление.
• Находясь на переднем плане , ваше приложение получает объект сообщения с обеими доступными полезными нагрузками.

Вот сообщение в формате JSON, содержащее как ключ notification , так и ключ data :

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Настройка сообщения на разных платформах

Firebase Admin SDK и HTTP-протокол FCM v1 позволяют вашим запросам сообщений устанавливать все поля, доступные в объекте message . Это включает в себя:

• общий набор полей, которые должны интерпретироваться всеми экземплярами приложения, получающими сообщение.
• специфичные для платформы наборы полей, такие как AndroidConfig и WebpushConfig , которые интерпретируются только экземплярами приложений, работающими на указанной платформе.

Блоки для конкретных платформ позволяют гибко настраивать сообщения для разных платформ, чтобы гарантировать их правильную обработку при получении. Бэкэнд FCM примет во внимание все указанные параметры и настроит сообщение для каждой платформы.

Когда использовать общие поля

Используйте общие поля, когда вы:

• Ориентация на экземпляры приложений на всех платформах — Apple, Android и в Интернете.
• Отправка сообщений в темы

Все экземпляры приложения, независимо от платформы, могут интерпретировать следующие общие поля:

• message.notification.title
• message.notification.body
• message.data

Когда использовать поля для конкретной платформы

Используйте поля для конкретной платформы, если вы хотите:

• Отправка полей только на определенные платформы
• Отправка полей для конкретной платформы в дополнение к общим полям

Всякий раз, когда вы хотите отправлять значения только на определенные платформы, не используйте общие поля; использовать поля, зависящие от платформы. Например, чтобы отправить уведомление только на платформы Apple и в Интернет, но не на Android, необходимо использовать два отдельных набора полей: один для Apple и один для Интернета.

Когда вы отправляете сообщения с определенными параметрами доставки , используйте поля для конкретной платформы, чтобы установить их. Вы можете указать разные значения для каждой платформы, если хотите. Однако даже если вы хотите установить практически одно и то же значение для разных платформ, вы должны использовать поля для конкретных платформ. Это связано с тем, что каждая платформа может интерпретировать это значение немного по-разному — например, время жизни задается в Android как время истечения срока действия в секундах, а в Apple — как дата истечения срока действия.

Пример: уведомление с параметрами доставки для конкретной платформы

Следующий запрос на отправку v1 отправляет общий заголовок и содержимое уведомления на все платформы, а также отправляет некоторые переопределения для конкретных платформ. В частности, запрос:

• устанавливает длительное время жизни для Android и веб-платформ, а также устанавливает низкий приоритет сообщений APN (платформы Apple)
• устанавливает соответствующие клавиши для определения результата нажатия пользователем на уведомление на Android и Apple — click_action и category соответственно.

{
  "message":{
     "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
     "notification":{
       "title":"Match update",
       "body":"Arsenal goal in added time, score is now 3-0"
     },
     "android":{
       "ttl":"86400s",
       "notification"{
         "click_action":"OPEN_ACTIVITY_1"
       }
     },
     "apns": {
       "headers": {
         "apns-priority": "5",
       },
       "payload": {
         "aps": {
           "category": "NEW_MESSAGE_CATEGORY"
         }
       }
     },
     "webpush":{
       "headers":{
         "TTL":"86400"
       }
     }
   }
 }

Полную информацию о ключах, доступных в блоках для конкретных платформ в теле сообщения, см. в справочной документации по HTTP v1 . Дополнительные сведения о построении запросов на отправку, содержащих тело сообщения, см. в разделе Создание запросов на отправку .

Варианты доставки

FCM предоставляет определенный набор вариантов доставки сообщений, отправляемых на устройства Android, и позволяет использовать аналогичные параметры на платформах Apple и в Интернете. Например, «сворачиваемое» поведение сообщения поддерживается на Android с помощью FCM collapse_key , на Apple с помощью apns-collapse-id и на JavaScript/Web с помощью Topic . Дополнительные сведения см. в описаниях в этом разделе и соответствующей справочной документации.

Неразборные и разборные сообщения

Неразборное сообщение означает, что каждое отдельное сообщение доставляется на устройство. Несворачиваемое сообщение доставляет некоторый полезный контент, в отличие от сворачиваемого сообщения, такого как «пинг» без содержимого для мобильного приложения, чтобы связаться с сервером для получения данных.

Некоторыми типичными вариантами использования несворачиваемых сообщений являются сообщения чата или критические сообщения. Например, в приложении для обмена мгновенными сообщениями вы хотели бы доставлять каждое сообщение, потому что каждое сообщение имеет разное содержимое.

Для Android существует ограничение в 100 сообщений, которые можно хранить без сворачивания. Если лимит достигнут, все сохраненные сообщения удаляются. Когда устройство снова подключается к сети, оно получает специальное сообщение о том, что лимит достигнут. Затем приложение может правильно справиться с ситуацией, обычно запрашивая полную синхронизацию с сервера приложений.

Сворачиваемое сообщение — это сообщение, которое может быть заменено новым сообщением, если оно еще не доставлено на устройство.

Распространенными вариантами использования сворачиваемых сообщений являются сообщения, используемые для указания мобильному приложению синхронизировать данные с сервера. Примером может служить спортивное приложение, которое обновляет пользователей последним счетом. Актуально только самое последнее сообщение.

Чтобы пометить сообщение как сворачиваемое на Android, включите параметр collapse_key в полезные данные сообщения. По умолчанию ключ свертывания — это имя пакета приложения, зарегистрированное в консоли Firebase. Сервер FCM может одновременно хранить четыре разных сворачиваемых сообщения на устройство, каждое с другим ключом свертывания. Если вы превысите это число, FCM сохранит только четыре ключа свертывания, без каких-либо гарантий относительно того, какие из них будут сохранены.

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

Что я должен использовать?

Сворачиваемые сообщения — лучший выбор с точки зрения производительности, при условии, что вашему приложению не нужно использовать несворачиваемые сообщения. Однако, если вы используете сворачиваемые сообщения, помните, что FCM позволяет FCM использовать максимум четыре разных ключа свертывания для каждого регистрационного токена в любой момент времени. Вы не должны превышать это число, иначе это может привести к непредсказуемым последствиям.

	Использовать сценарий	Как отправить
Неразборный	Каждое сообщение важно для клиентского приложения и должно быть доставлено.	За исключением сообщений уведомлений, все сообщения по умолчанию не являются сворачиваемыми.
Складной	Когда появляется более новое сообщение, которое делает старое связанное сообщение нерелевантным для клиентского приложения, FCM заменяет старое сообщение. Например: сообщения, используемые для запуска синхронизации данных с сервера, или устаревшие сообщения уведомлений.	Установите соответствующий параметр в запросе сообщения: collapseKey на Android apns-collapse-id на Apple Topic в Интернете collapse_key в устаревших протоколах (все платформы)

Установка приоритета сообщения

У вас есть два варианта назначения приоритета доставки нисходящим сообщениям: обычный и высокий приоритет. Хотя поведение немного различается на разных платформах, доставка обычных и высокоприоритетных сообщений работает следующим образом:

• Нормальный приоритет. Сообщения с обычным приоритетом доставляются немедленно, когда приложение находится на переднем плане. Для фоновых приложений доставка может быть отложена. Для менее срочных сообщений, таких как уведомления о новой электронной почте, синхронизация пользовательского интерфейса или синхронизация данных приложения в фоновом режиме, выберите обычный приоритет доставки.

• Высокий приоритет. FCM пытается немедленно доставить сообщения с высоким приоритетом, даже если устройство находится в режиме ожидания. Сообщения с высоким приоритетом предназначены для чувствительного ко времени контента, видимого пользователю.

Вот пример сообщения с обычным приоритетом, отправляемого по протоколу FCM HTTP v1 для уведомления подписчика журнала о том, что новый контент доступен для загрузки:

{
  "message":{
    "topic":"subscriber-updates",
    "notification":{
      "body" : "This week's edition is now available.",
      "title" : "NewsMagazine.com",
    },
    "data" : {
      "volume" : "3.21.15",
      "contents" : "http://www.news-magazine.com/world-week/21659772"
    },
    "android":{
      "priority":"normal"
    },
    "apns":{
      "headers":{
        "apns-priority":"5"
      }
    },
    "webpush": {
      "headers": {
        "Urgency": "high"
      }
    }
  }
}

Для получения более подробной информации об установке приоритета сообщения для конкретной платформы:

• документация по APN
• Установка приоритета сообщений и управление им (Android)
• Срочность веб-push-сообщения

Установка срока жизни сообщения

FCM обычно доставляет сообщения сразу после их отправки. Однако это не всегда возможно. Например, если используется платформа Android, устройство может быть выключено, находиться в автономном режиме или быть недоступным по какой-либо иной причине. Или FCM может намеренно задерживать сообщения, чтобы предотвратить потребление приложением чрезмерных ресурсов и негативное влияние на срок службы батареи.

Когда это происходит, FCM сохраняет сообщение и доставляет его, как только это становится возможным. Хотя в большинстве случаев это нормально, есть некоторые приложения, для которых запоздалое сообщение может никогда не быть доставлено. Например, если сообщение является входящим вызовом или уведомлением о видеочате, оно имеет смысл только в течение короткого периода времени, прежде чем вызов будет завершен. Или, если сообщение является приглашением на мероприятие, оно бесполезно, если получено после окончания мероприятия.

В Android и Web/JavaScript вы можете указать максимальную продолжительность жизни сообщения. Значение должно иметь продолжительность от 0 до 2 419 200 секунд (28 дней) и соответствует максимальному периоду времени, в течение которого FCM сохраняет и пытается доставить сообщение. Запросы, которые не содержат это поле, по умолчанию имеют максимальный период в четыре недели.

Вот несколько возможных вариантов использования этой функции:

• Входящие звонки в видеочате
• Истечение срока действия приглашений
• События календаря

Еще одним преимуществом указания продолжительности жизни сообщения является то, что FCM никогда не блокирует сообщения со значением времени жизни, равным 0 секундам. Другими словами, FCM гарантирует максимальные усилия для сообщений, которые должны быть доставлены «сейчас или никогда». Имейте в виду, что значение time_to_live равное 0, означает, что сообщения, которые не могут быть доставлены немедленно, отбрасываются. Однако, поскольку такие сообщения никогда не сохраняются, это обеспечивает наилучшую задержку для отправки уведомлений.

Вот пример запроса, который включает TTL:

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "data":{
      "Nick" : "Mario",
      "body" : "great match!",
      "Room" : "PortugalVSDenmark"
    },
    "apns":{
      "headers":{
        "apns-expiration":"1604750400"
      }
    },
    "android":{
      "ttl":"4500s"
    },
    "webpush":{
      "headers":{
        "TTL":"4500"
      }
    }
  }
}

Время жизни сообщения

Когда сервер приложений отправляет сообщение в FCM и получает обратно идентификатор сообщения, это не означает, что сообщение уже было доставлено на устройство. Скорее, это означает, что он был принят к сдаче. Что происходит с сообщением после его принятия, зависит от многих факторов.

В лучшем случае, если устройство подключено к FCM, экран включен и нет ограничений по троттлингу, сообщение доставляется сразу.

Если устройство подключено, но находится в спящем режиме, FCM сохраняет сообщение с низким приоритетом до тех пор, пока устройство не выйдет из спящего режима. И здесь играет роль флаг collapse_key : если сообщение с таким же ключом свертывания (и регистрационным токеном) уже сохранено и ожидает доставки, старое сообщение отбрасывается, а новое сообщение занимает его место (то есть старое сообщение). сообщение свернуто новым). Однако, если ключ свертывания не установлен, и новые, и старые сообщения сохраняются для доставки в будущем.

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

Чтобы получить больше информации о доставке сообщения:

Чтобы получить больше информации о доставке сообщений на платформах Android или Apple, см. информационную панель отчетов FCM , которая регистрирует количество сообщений, отправленных и открытых на устройствах Apple и Android, а также данные о «показах» (уведомлениях, просмотренных пользователями) для Android-приложения.

Для устройств Android с включенным прямым обменом сообщениями канала, если устройство не подключалось к FCM более одного месяца, FCM по-прежнему принимает сообщение, но немедленно отбрасывает его. Если устройство подключается в течение четырех недель после отправки последнего сообщения с данными, ваш клиент получает обратный вызов onDeletedMessages() . Затем приложение может правильно справиться с ситуацией, обычно запрашивая полную синхронизацию с сервера приложений.

Наконец, когда FCM пытается доставить сообщение на устройство, а приложение было удалено, FCM сразу отбрасывает это сообщение и делает недействительным токен регистрации. Будущие попытки отправить сообщение на это устройство приводят к ошибке NotRegistered .

Регулирование и масштабирование

Наша цель — всегда доставлять каждое сообщение, отправленное через FCM. Однако доставка каждого сообщения иногда приводит к ухудшению общего взаимодействия с пользователем. В других случаях нам нужно указать границы, чтобы гарантировать, что FCM предоставляет масштабируемый сервис для всех отправителей.

Сворачиваемое регулирование сообщений

Как описано выше, сворачиваемые сообщения — это уведомления без содержания, предназначенные для свертывания друг над другом. В случае, если разработчик слишком часто повторяет одно и то же сообщение в приложении, мы задерживаем (регулируем) сообщения, чтобы уменьшить влияние на аккумулятор пользователя.

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

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

Мы ограничиваем сворачиваемые сообщения пакетом из 20 сообщений на приложение на устройство с пополнением на 1 сообщение каждые 3 минуты.

Дросселирование сервера XMPP

Мы ограничиваем скорость подключения к серверам FCM XMPP до 400 подключений в минуту на проект. Это не должно быть проблемой для доставки сообщений, но важно для обеспечения стабильности нашей системы.

Для каждого проекта FCM допускает 2500 параллельных подключений.

Максимальная скорость отправки сообщений на одно устройство

Для Android вы можете отправлять до 240 сообщений в минуту и ​​5000 сообщений в час на одно устройство. Этот высокий порог предназначен для кратковременных всплесков трафика, например, когда пользователи быстро взаимодействуют в чате. Это ограничение предотвращает непреднамеренную разрядку аккумулятора устройства из-за ошибок в логике отправки.

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

Лимит восходящих сообщений

Мы ограничиваем исходящие сообщения до 1 500 000 сообщений в минуту на проект, чтобы избежать перегрузки исходящих серверов назначения.

Мы ограничиваем исходящие сообщения на устройство до 1000 в минуту, чтобы защитить аккумулятор от разрядки из-за плохого поведения приложения.

Лимит сообщений в теме

Скорость добавления/удаления темы в рамках подписки ограничена 3000 запросов в секунду на проект.

Скорости отправки сообщений см. в разделе Fanout Throttling .

Регулирование разветвления

Разветвление сообщений — это процесс отправки сообщения на несколько устройств, например, когда вы ориентируетесь на темы и группы или когда вы используете компоновщик уведомлений для целевых аудиторий или сегментов пользователей.

Разветвление сообщений не является мгновенным, поэтому иногда у вас одновременно происходит несколько разветвлений. Мы ограничиваем количество одновременных разветвлений сообщений на проект до 1000. После этого мы можем отклонить дополнительные запросы разветвления или отложить разветвление запросов до завершения некоторых из уже выполняемых разветвлений.

На фактическую достижимую скорость разветвления влияет количество проектов, запрашивающих разветвления одновременно. Скорость разветвления 10 000 QPS для отдельного проекта не является чем-то необычным, но это число не является гарантией и является результатом общей нагрузки на систему. Важно отметить, что доступная емкость разветвления распределяется между проектами, а не между запросами разветвления. Таким образом, если в вашем проекте выполняется два разветвления, то каждое разветвление будет видеть только половину доступной скорости разветвления. Рекомендуемый способ максимизировать скорость разветвления — иметь только одно активное разветвление одновременно.

Порты FCM и ваш брандмауэр

Если в вашей организации есть брандмауэр для ограничения трафика в Интернет или из Интернета, вам необходимо настроить его, чтобы разрешить мобильным устройствам подключаться к FCM, чтобы устройства в вашей сети могли получать сообщения. FCM обычно использует порт 5228, но иногда использует порты 443, 5229 и 5230.

Для устройств, подключающихся к вашей сети, FCM не предоставляет конкретные IP-адреса, потому что наш диапазон IP-адресов меняется слишком часто, а правила вашего брандмауэра могут устареть, что повлияет на работу ваших пользователей. В идеале добавьте в белый список порты 5228–5230 и 443 без ограничений IP. Однако если у вас должно быть ограничение по IP-адресу, вы должны внести в белый список все IP-адреса, перечисленные в goog.json . Этот большой список регулярно обновляется, и вам рекомендуется ежемесячно обновлять свои правила. Проблемы, вызванные ограничениями IP-адресов брандмауэра, часто возникают периодически и их трудно диагностировать.

Мы предлагаем набор доменных имен, которые можно внести в белый список вместо IP-адресов. Эти имена хостов перечислены ниже. Если мы начнем использовать дополнительные имена хостов, мы обновим список здесь. Использование доменных имен для правила брандмауэра может работать или не работать на вашем устройстве брандмауэра.

Порты TCP для открытия:

• 5228
• 5229
• 5230
• 443

Имена хостов для открытия:

• mtalk.google.com
• mtalk4.google.com
• mtalk-staging.google.com
• mtalk-dev.google.com
• alt1-mtalk.google.com
• alt2-mtalk.google.com
• alt3-mtalk.google.com
• alt4-mtalk.google.com
• alt5-mtalk.google.com
• alt6-mtalk.google.com
• alt7-mtalk.google.com
• alt8-mtalk.google.com
• android.apis.google.com
• device-provisioning.googleapis.com
• firebaseinstallations.googleapis.com

Трансляция сетевых адресов и/или брандмауэры Stateful Packet Inspection:

Если в вашей сети реализована трансляция сетевых адресов (NAT) или проверка пакетов с отслеживанием состояния (SPI), установите 30-минутный или более тайм-аут для наших соединений через порты 5228-5230. Это позволяет нам обеспечивать надежное подключение и при этом снижать потребление заряда батареи мобильными устройствами ваших пользователей.

Реквизиты для входа

В зависимости от того, какие функции FCM вы реализуете, вам могут потребоваться следующие учетные данные из вашего проекта Firebase:

Идентификатор проекта	Уникальный идентификатор вашего проекта Firebase, используемый в запросах к конечной точке HTTP FCM v1. Это значение доступно на панели настроек консоли Firebase .
Токен регистрации	Уникальная строка токена, идентифицирующая каждый экземпляр клиентского приложения. Маркер регистрации требуется для обмена сообщениями с одним устройством или группой устройств. Обратите внимание, что регистрационные токены должны храниться в секрете.
Удостоверение личности отправителя	Уникальное числовое значение, созданное при создании проекта Firebase, доступное на вкладке Cloud Messaging панели настроек консоли Firebase. Идентификатор отправителя используется для идентификации каждого отправителя, который может отправлять сообщения клиентскому приложению.
Токен доступа	Краткосрочный токен OAuth 2.0, который авторизует запросы к API HTTP v1. Этот токен связан с учетной записью службы, принадлежащей вашему проекту Firebase. Чтобы создать и чередовать токены доступа, выполните действия, описанные в разделе Авторизация отправки запросов .
Ключ сервера (для устаревших протоколов)	Ключ сервера, который разрешает вашему серверу приложений доступ к службам Google, включая отправку сообщений через устаревшие протоколы Firebase Cloud Messaging. Вы получаете ключ сервера при создании проекта Firebase. Вы можете просмотреть его на вкладке Cloud Messaging панели настроек консоли Firebase. Важно: Не включайте ключ сервера в свой клиентский код. Кроме того, убедитесь, что вы используете только ключи сервера для авторизации вашего сервера приложений. Android, платформа Apple и ключи браузера отклоняются FCM.