О сообщениях 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 в приложении IM. Пользователь может ожидать увидеть сообщение с заголовком «Португалия против Дании» и текстом «отличный матч!» на устройстве:

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

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

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

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

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

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

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

Вот сообщение в формате 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 учтет все указанные параметры и настроит сообщение для каждой платформы.

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

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

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

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

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

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

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

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

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

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

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

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

• устанавливает длительное время жизни для 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 и в Интернете. Например, поведение сообщения "collapsible" поддерживается на Android через FCM 's collapse_key , на Apple через apns-collapse-id и на JavaScript/Web через Topic . Подробности см. в описаниях в этом разделе и соответствующей справочной документации.

Несворачиваемые и сворачиваемые сообщения

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

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

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

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

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

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

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

Какой вариант мне использовать?

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

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

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

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

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

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

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

HTTP v1 API ввел квоты на проект и на минуту для нисходящего обмена сообщениями. Квота по умолчанию в 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 QPS для отдельного проекта не является редкостью, но это число не является гарантией и является результатом общей нагрузки на систему. Важно отметить, что доступная емкость разветвления делится между проектами, а не между запросами разветвления. Таким образом, если в вашем проекте выполняется два разветвления, то каждое разветвление будет видеть только половину доступной скорости разветвления. Рекомендуемый способ максимизировать скорость разветвления — это иметь только один активный разветвитель в процессе одновременно.

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

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

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

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

Мы ограничиваем сворачиваемые сообщения пакетом из 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 специфично для канала FCM Push Notification. Другой трафик FCM , такой как трафик регистрации, использует VPN, если он активен. Когда соединение FCM обходит VPN, оно теряет дополнительные преимущества, которые может предоставить VPN, такие как маскировка IP.

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

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

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

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