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

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

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

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

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

Уведомления содержат предопределённый набор видимых пользователю ключей. Сообщения с данными, напротив, содержат только заданные пользователем пары «ключ-значение». Уведомления могут содержать необязательную полезную нагрузку. Максимальный объём полезной нагрузки для обоих типов сообщений составляет 4096 байт, за исключением отправки сообщений из консоли Firebase , где действует ограничение в 1000 символов.

Используйте уведомления, если вы хотите, чтобы 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.

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

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

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

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

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

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

Транспортный уровень 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 — как дата истечения срока.

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

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

• устанавливает длительное время жизни для Android и веб-платформ, одновременно устанавливая низкий приоритет сообщений APNs (платформы 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 пытается немедленно доставить сообщения с высоким приоритетом, даже если устройство находится в спящем режиме. Сообщения с высоким приоритетом предназначены для контента, доступного пользователю и имеющего срочный характер.

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

Критически важные случаи использования

API FCM не предназначены для экстренных оповещений или других видов деятельности с высоким уровнем риска, где использование или сбой API может привести к смерти, травмам или ущербу окружающей среде (например, эксплуатация ядерных объектов, управление воздушным движением или системы жизнеобеспечения). Любое такое использование прямо запрещено Разделом 4.a.7 Условий использования. Вы несёте исключительную ответственность за соответствие своего приложения Условиям и за любой ущерб, возникший в результате несоблюдения вами этих Условий. Google предоставляет API «как есть» и оставляет за собой право прекратить предоставление API, любой их части или функции, а также вашего доступа к ним по любой причине и в любое время без какой-либо ответственности или каких-либо обязательств перед вами или вашими пользователями.

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

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 , экран включен и нет ограничений по регулированию скорости, сообщение доставляется немедленно.

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

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

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

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

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

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

Регулирование и квоты

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

Регулирование нисходящих сообщений

В API HTTP v1 введены поминутные квоты на отправку сообщений по каждому проекту. Квота по умолчанию в 600 тыс. сообщений в минуту охватывает более 99% разработчиков FCM , обеспечивая при этом стабильность системы и минимизируя влияние нестабильных проектов.

Резкие колебания трафика могут привести к ошибкам превышения квоты. В случае превышения квоты система выдаёт HTTP-код статуса 429 (QUOTA_EXCEEDED) до тех пор, пока квота не будет заполнена в течение следующей минуты. Ответы 429 также могут возвращаться в ситуациях перегрузки, поэтому настоятельно рекомендуется обрабатывать ошибки 429 в соответствии с опубликованными рекомендациями .

Обратите внимание, что:

• Квота нисходящего потока измеряет сообщения, а не запросы.
• Ошибки клиента (коды статуса HTTP 400-499) подсчитываются (исключая 429).
• Квоты поминутные, но эти минуты не привязаны к часам.

Квота мониторинга

Вы можете просмотреть квоту, использование и ошибки в Google Cloud Console:

1. Перейдите в консоль Google Cloud
2. Выберите API и сервисы
3. В списке таблиц выберите Firebase Cloud Messaging API .
4. Выберите КВОТА И СИСТЕМНЫЕ ОГРАНИЧЕНИЯ .

ПРИМЕЧАНИЕ: эти графики не точно соответствуют минутам квоты, то есть сообщения 429 могут обслуживаться, когда трафик оказывается ниже квоты.

Запрос на увеличение квоты

Прежде чем подавать запрос на увеличение квоты, убедитесь, что:

• Ваше использование регулярно составляет ≥ 80% от квоты в течение не менее 5 последовательных минут в день.
• Коэффициент ошибок клиентов составляет < 5%, особенно в периоды пиковой нагрузки.
• Вы придерживаетесь лучших практик широкомасштабной рассылки сообщений .

Если вы соответствуете этим критериям, вы можете подать запрос на увеличение квоты до +25%, и FCM приложит все возможные усилия для выполнения запроса (увеличение квоты не может быть гарантировано).

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

См. также часто задаваемые вопросы о квотах FCM .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Порты 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

Межсетевые экраны с преобразованием сетевых адресов и/или проверкой состояния пакетов:

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

VPN-взаимодействие и обходимость

Firebase Cloud Messaging предпринимает различные меры для обеспечения надёжности и максимальной доступности push-сообщений между телефоном и сервером. Использование VPN усложняет этот процесс.

VPN-сети маскируют базовую информацию, необходимую FCM для настройки соединения с целью максимальной надежности и экономии заряда батареи. В некоторых случаях VPN-сети активно разрывают долговременные соединения, что приводит к ухудшению пользовательского опыта из-за пропущенных или задержанных сообщений, а также к высокому расходу заряда батареи. Если VPN настроен таким образом, мы обходим VPN, используя зашифрованное соединение (по базовой сети Wi-Fi или LTE), чтобы обеспечить надежное и экономичное использование батареи. Использование FCM обходимых VPN характерно для канала push-уведомлений FCM . Другой трафик FCM , например, трафик регистрации, использует VPN, если он активен. Когда соединение FCM обходит VPN, оно теряет дополнительные преимущества, которые может предоставлять VPN, такие как маскировка IP-адресов.

У разных VPN-сервисов разные методы контроля возможности обхода. Инструкции см. в документации к вашей VPN-сети.

Если VPN не настроена на обход, Firebase Cloud Messaging будет использовать VPN-сеть для подключения к серверу. Это может привести к задержкам в доставке сообщений и повышенному расходу заряда батареи, поскольку Cloud Messaging пытается поддерживать соединение через VPN.

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

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