Google стремится продвигать расовую справедливость для черных сообществ. Смотри как.
Эта страница была переведа с помощью Cloud Translation API.
Switch to English

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

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

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

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

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

Уведомительные сообщения содержат предопределенный набор видимых пользователем ключей. Напротив, сообщения данных содержат только ваши пользовательские пары ключ-значение. Уведомительные сообщения могут содержать дополнительную полезную информацию. Максимальная полезная нагрузка для обоих типов сообщений составляет 4 КБ, за исключением случаев отправки сообщений из консоли Firebase, что обеспечивает ограничение в 1024 символа.

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

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

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

Уведомления

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

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

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

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

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

Данные сообщения

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

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

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

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

Уведомительные сообщения с дополнительной полезной нагрузкой данных

Как программно, так и через консоль 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 и протокол FCM v1 HTTP позволяют вашим запросам на сообщение устанавливать все поля, доступные в объекте message . Это включает:

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

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

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

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

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

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

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

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

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

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

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

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

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

  • устанавливает длительное время жизни для платформ Android и Web, при этом для приоритета сообщения APNs (iOS) устанавливается низкий уровень
  • устанавливает соответствующие ключи, чтобы определить результат нажатия пользователем уведомления на Android и iOS - 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, и позволяет использовать аналогичные параметры в iOS и в Интернете. Например, поведение «свертываемого» сообщения поддерживается в Android с помощью collapse_key FCM, в iOS через apns-collapse-id и в JavaScript / Web через Topic . Подробнее см. Описания в этом разделе и соответствующую справочную документацию.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот пример сообщения с обычным приоритетом, отправляемого по протоколу 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"
      }
    }
  }
}

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

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

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 позволяет нескольким сторонам отправлять сообщения одному клиентскому приложению. Например, предположим, что клиентское приложение представляет собой агрегатор статей с несколькими участниками, и каждый из них должен иметь возможность отправлять сообщение при публикации новой статьи. Это сообщение может содержать URL, чтобы клиентское приложение могло загрузить статью. Вместо того, чтобы централизовать все действия по отправке в одном месте, FCM дает вам возможность позволить каждому из этих участников отправлять свои собственные сообщения.

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

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

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

Обратите внимание, что существует ограничение в 100 отправителей.

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

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

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

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

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

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

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

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

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

Дросселирование и масштабирование

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

Регулируемый объем складывающихся сообщений

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

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

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

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

Регулирование XMPP-сервера

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

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

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

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

Верхний предел сообщения

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

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

Лимит темы сообщения

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

Скорость отправки сообщений приведена в разделе Регулирование разветвления .

Раздувание

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

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

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

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

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

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

Порты, которые нужно открыть для входящих сообщений:

  • 5228
  • 5229
  • 5230
  • 443

Порты для разрешения исходящих соединений:

Один из них (вариант № 1 является предпочтительным):

  1. Нет ограничений IP
  2. Все IP-адреса, содержащиеся в IP-блоках, перечислены в ASN Google 15169 . Не забывайте обновлять это по крайней мере раз в месяц.

Межсетевые экраны трансляции сетевых адресов и / или Stateful Packet Inspection:

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

полномочия

В зависимости от того, какие функции 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, iOS и браузера отклоняются FCM.