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

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

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

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

Жизненно важные случаи использования

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

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

См. также FAQ о квотах FCM .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На 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
• устройство-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: