Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

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

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

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

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

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

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

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

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

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

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

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

Уведомляющие сообщения

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

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

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

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

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

Сообщения с данными

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что мне использовать?

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

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

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

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

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

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

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

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

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

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

Лимит сообщений в восходящем направлении

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

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

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

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

Для отправки сообщения ставок см разветвления дросселирования .

Дросселирование разветвления

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

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

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

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

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

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

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

Открытые порты:

  • 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.clients.google.com
  • device-provisioning.googleapis.com

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

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

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

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

ID проекта Уникальный идентификатор вашего проекта 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.