Entérate de todos los anuncios de Firebase Summit y descubre cómo Firebase puede ayudarte a acelerar el desarrollo de las apps y a ejecutarlas con confianza. Más información

Acerca de los mensajes de FCM

Firebase Cloud Messaging (FCM) ofrece una amplia gama de opciones y capacidades de mensajería. La información de esta página está destinada a ayudarlo a comprender los diferentes tipos de mensajes de FCM y lo que puede hacer con ellos.

Tipos de mensajes

Con FCM, puede enviar dos tipos de mensajes a los clientes:

  • Mensajes de notificación, a veces considerados como "mensajes de visualización". Estos son manejados por el SDK de FCM automáticamente.
  • Mensajes de datos, que son manejados por la aplicación cliente.

Los mensajes de notificación contienen un conjunto predefinido de claves visibles para el usuario. Los mensajes de datos, por el contrario, contienen solo sus pares clave-valor personalizados definidos por el usuario. Los mensajes de notificación pueden contener una carga de datos opcional. La carga útil máxima para ambos tipos de mensajes es de 4000 bytes, excepto cuando se envían mensajes desde Firebase console, que impone un límite de 1024 caracteres.

Escenario de uso Cómo enviar
Mensaje de notificación FCM muestra automáticamente el mensaje a los dispositivos de los usuarios finales en nombre de la aplicación cliente. Los mensajes de notificación tienen un conjunto predefinido de claves visibles para el usuario y una carga de datos opcional de pares clave-valor personalizados.
  1. En un entorno de confianza como Cloud Functions o su servidor de aplicaciones, use Admin SDK o FCM Server Protocols : configure la clave de notification . Puede tener una carga útil de datos opcional. Siempre plegable.

    Vea algunos ejemplos de notificaciones de visualización y cargas útiles de solicitudes de envío.

  2. Use el editor de notificaciones : ingrese el texto del mensaje, el título, etc., y envíelo. Agregue carga útil de datos opcional al proporcionar datos personalizados.
mensaje de datos La aplicación del cliente es responsable de procesar los mensajes de datos. Los mensajes de datos solo tienen pares clave-valor personalizados sin nombres de clave reservados (ver más abajo). En un entorno de confianza como Cloud Functions o su servidor de aplicaciones, use Admin SDK o FCM Server Protocols : configure solo la clave data .

Utilice mensajes de notificación cuando desee que FCM gestione la visualización de una notificación en nombre de su aplicación cliente. Utilice mensajes de datos cuando desee procesar los mensajes en la aplicación de su cliente.

FCM puede enviar un mensaje de notificación que incluye una carga útil de datos opcional. En tales casos, FCM maneja la visualización de la carga de notificación y la aplicación cliente maneja la carga de datos.

Mensajes de notificación

Para realizar pruebas o marketing y volver a involucrar a los usuarios, puede enviar mensajes de notificación mediante la consola de Firebase . La consola Firebase proporciona pruebas A/B basadas en análisis para ayudarlo a refinar y mejorar los mensajes de marketing.

Para enviar mensajes de notificación mediante programación mediante Admin SDK o los protocolos FCM, configure la clave de notification con el conjunto predefinido necesario de opciones de clave-valor para la parte visible del usuario del mensaje de notificación. Por ejemplo, aquí hay un mensaje de notificación con formato JSON en una aplicación de mensajería instantánea. El usuario puede esperar ver un mensaje con el título "Portugal vs. Dinamarca" y el texto "¡gran partido!" en el dispositivo:

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

Los mensajes de notificación se envían a la bandeja de notificaciones cuando la aplicación está en segundo plano. Para las aplicaciones en primer plano, los mensajes son manejados por una función de devolución de llamada.

Consulte la documentación de referencia para ver la lista completa de claves predefinidas disponibles para crear mensajes de notificación:

Mensajes de datos

Establezca la clave adecuada con sus pares clave-valor personalizados para enviar una carga de datos a la aplicación cliente.

Por ejemplo, aquí hay un mensaje con formato JSON en la misma aplicación de mensajería instantánea que la anterior, donde la información se encapsula en la clave data común y se espera que la aplicación del cliente interprete el contenido:

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

El ejemplo anterior muestra el uso del campo data común o de nivel superior, que los clientes interpretan en todas las plataformas que reciben el mensaje. En cada plataforma, la aplicación del cliente recibe la carga útil de datos en una función de devolución de llamada.

Cifrado para mensajes de datos

La capa de transporte de Android (consulte la arquitectura FCM ) utiliza el cifrado de punto a punto. Dependiendo de sus necesidades, puede decidir agregar cifrado de extremo a extremo a los mensajes de datos. FCM no proporciona una solución de extremo a extremo. Sin embargo, existen soluciones externas disponibles como Capillary o DTLS .

Mensajes de notificación con carga de datos opcional

Tanto mediante programación como a través de Firebase console, puede enviar mensajes de notificación que contengan una carga útil opcional de pares clave-valor personalizados. En el redactor de notificaciones , utilice los campos de datos personalizados en las opciones avanzadas .

El comportamiento de la aplicación al recibir mensajes que incluyen cargas útiles de notificación y datos depende de si la aplicación está en segundo plano o en primer plano; básicamente, si está activa o no en el momento de la recepción.

  • Cuando están en segundo plano, las aplicaciones reciben la carga útil de notificación en la bandeja de notificaciones y solo manejan la carga útil de datos cuando el usuario toca la notificación.
  • Cuando está en primer plano , su aplicación recibe un objeto de mensaje con ambas cargas útiles disponibles.

Aquí hay un mensaje con formato JSON que contiene tanto la clave de notification como la clave data :

{
  "message":{
    "token":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1...",
    "notification":{
      "title":"Portugal vs. Denmark",
      "body":"great match!"
    },
    "data" : {
      "Nick" : "Mario",
      "Room" : "PortugalVSDenmark"
    }
  }
}

Personalización de un mensaje entre plataformas

Tanto el SDK de administración de Firebase como el protocolo HTTP de FCM v1 permiten que sus solicitudes de mensajes configuren todos los campos disponibles en el objeto del message . Esto incluye:

  • un conjunto común de campos que deben interpretar todas las instancias de la aplicación que reciben el mensaje.
  • conjuntos de campos específicos de la plataforma, como AndroidConfig y WebpushConfig , interpretados solo por las instancias de la aplicación que se ejecutan en la plataforma especificada.

Los bloques específicos de la plataforma le brindan flexibilidad para personalizar los mensajes para diferentes plataformas para garantizar que se manejen correctamente cuando se reciban. El backend de FCM tendrá en cuenta todos los parámetros especificados y personalizará el mensaje para cada plataforma.

Cuándo usar campos comunes

Utilice campos comunes cuando esté:

  • Dirigirse a instancias de aplicaciones en todas las plataformas: Apple, Android y web
  • Envío de mensajes a temas

Todas las instancias de la aplicación, independientemente de la plataforma, pueden interpretar los siguientes campos comunes:

Cuándo usar campos específicos de la plataforma

Utilice campos específicos de la plataforma cuando desee:

  • Enviar campos solo a plataformas particulares
  • Envíe campos específicos de la plataforma además de los campos comunes

Siempre que desee enviar valores solo a plataformas particulares, no use campos comunes; utilizar campos específicos de la plataforma. Por ejemplo, para enviar una notificación solo a las plataformas Apple y la web, pero no a Android, debe usar dos conjuntos de campos separados, uno para Apple y otro para la web.

Cuando envíe mensajes con opciones de entrega específicas, utilice los campos específicos de la plataforma para establecerlas. Puede especificar diferentes valores por plataforma si lo desea. Sin embargo, incluso cuando desee establecer esencialmente el mismo valor en todas las plataformas, debe usar campos específicos de la plataforma. Esto se debe a que cada plataforma puede interpretar el valor de forma ligeramente diferente; por ejemplo, el tiempo de vida se configura en Android como un tiempo de caducidad en segundos, mientras que en Apple se configura como una fecha de caducidad.

Ejemplo: mensaje de notificación con opciones de entrega específicas de la plataforma

La siguiente solicitud de envío v1 envía un título y contenido de notificación común a todas las plataformas, pero también envía algunas anulaciones específicas de la plataforma. En concreto, la solicitud:

  • establece un tiempo de vida prolongado para las plataformas web y Android, al tiempo que configura la prioridad de mensajes de APN (plataformas de Apple) en una configuración baja
  • establece las teclas apropiadas para definir el resultado de un toque del usuario en la notificación en Android y Apple: click_action y category , respectivamente.
{
  "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"
       }
     }
   }
 }

Consulte la documentación de referencia de HTTP v1 para obtener detalles completos sobre las claves disponibles en los bloques específicos de la plataforma en el cuerpo del mensaje. Para obtener más información sobre la creación de solicitudes de envío que contienen el cuerpo del mensaje, consulte Creación de solicitudes de envío .

Opciones de entrega

FCM proporciona un conjunto específico de opciones de entrega para los mensajes enviados a dispositivos Android y permite opciones similares en las plataformas y la web de Apple. Por ejemplo, el comportamiento de mensaje "plegable" se admite en Android a través de contract_key de FCM, en Apple a través apns-collapse-id collapse_key en JavaScript/Web a través de Topic . Para obtener más información, consulte las descripciones de esta sección y la documentación de referencia relacionada.

Mensajes plegables y no plegables

Un mensaje no plegable indica que cada mensaje individual se entrega al dispositivo. Un mensaje no plegable ofrece contenido útil, a diferencia de un mensaje plegable como un "ping" sin contenido a la aplicación móvil para contactar al servidor para obtener datos.

Algunos casos típicos de uso de mensajes no colapsables son mensajes de chat o mensajes críticos. Por ejemplo, en una aplicación de mensajería instantánea, le gustaría entregar todos los mensajes, porque cada mensaje tiene un contenido diferente.

Para Android hay un límite de 100 mensajes que se pueden almacenar sin colapsar. Si se alcanza el límite, todos los mensajes almacenados se descartan. Cuando el dispositivo vuelve a estar en línea, recibe un mensaje especial que indica que se alcanzó el límite. Luego, la aplicación puede manejar la situación correctamente, generalmente solicitando una sincronización completa del servidor de la aplicación.

Un mensaje colapsable es un mensaje que puede ser reemplazado por un mensaje nuevo si aún no se ha entregado al dispositivo.

Un caso de uso común de los mensajes contraíbles son los mensajes que se usan para indicarle a una aplicación móvil que sincronice los datos del servidor. Un ejemplo sería una aplicación de deportes que actualiza a los usuarios con la última puntuación. Solo el mensaje más reciente es relevante.

Para marcar un mensaje como contraíble en Android, incluya el parámetro collapse_key en la carga útil del mensaje. De forma predeterminada, la clave de contracción es el nombre del paquete de la aplicación registrado en Firebase console. El servidor FCM puede almacenar simultáneamente cuatro mensajes plegables diferentes por dispositivo, cada uno con una clave de colapso diferente. Si excede este número, FCM solo conserva cuatro claves de contracción, sin garantías sobre cuáles se conservan.

Los mensajes de tema sin carga útil se pueden contraer de forma predeterminada. Los mensajes de notificación siempre se pueden collapse_key .

¿Cuál debo usar?

Los mensajes plegables son una mejor opción desde el punto de vista del rendimiento, siempre que su aplicación no necesite usar mensajes no plegables. Sin embargo, si usa mensajes colapsables, recuerde que FCM solo permite que FCM use un máximo de cuatro claves colapsables diferentes por token de registro en un momento dado. No debe exceder este número, o podría causar consecuencias impredecibles.

Escenario de uso Cómo enviar
no plegable Cada mensaje es importante para la aplicación del cliente y debe entregarse. A excepción de los mensajes de notificación, todos los mensajes no se pueden contraer de forma predeterminada.
Plegable Cuando hay un mensaje más nuevo que hace que un mensaje anterior relacionado sea irrelevante para la aplicación cliente, FCM reemplaza el mensaje anterior. Por ejemplo: mensajes utilizados para iniciar una sincronización de datos desde el servidor o mensajes de notificación obsoletos. Establezca el parámetro apropiado en su solicitud de mensaje:
  • collapseKey en Android
  • apns-collapse-id en Apple
  • Topic en la Web
  • collapse_key en protocolos heredados (todas las plataformas)

Establecer la prioridad de un mensaje

Tiene dos opciones para asignar la prioridad de entrega a los mensajes descendentes: prioridad normal y alta. Aunque el comportamiento difiere ligeramente entre plataformas, la entrega de mensajes de prioridad normal y alta funciona así:

  • Prioridad normal. Los mensajes de prioridad normal se entregan inmediatamente cuando la aplicación está en primer plano. Para aplicaciones en segundo plano, la entrega puede retrasarse. Para mensajes menos sensibles al tiempo, como notificaciones de nuevos correos electrónicos, mantener su interfaz de usuario sincronizada o sincronizar datos de aplicaciones en segundo plano, elija la prioridad de entrega normal.

  • Alta prioridad. FCM intenta entregar mensajes de alta prioridad inmediatamente, incluso si el dispositivo está en modo Doze. Los mensajes de alta prioridad son para contenido sensible al tiempo y visible para el usuario.

Este es un ejemplo de un mensaje de prioridad normal enviado a través del protocolo FCM HTTP v1 para notificar a un suscriptor de una revista que hay nuevo contenido disponible para descargar:

{
  "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"
      }
    }
  }
}

Para obtener más detalles específicos de la plataforma sobre cómo configurar la prioridad de los mensajes:

Configuración de la vida útil de un mensaje

FCM generalmente entrega los mensajes inmediatamente después de que se envían. Sin embargo, esto puede no ser siempre posible. Por ejemplo, si la plataforma es Android, el dispositivo podría estar apagado, fuera de línea o no disponible. O FCM podría retrasar intencionalmente los mensajes para evitar que una aplicación consuma recursos excesivos y afecte negativamente la duración de la batería.

Cuando esto sucede, FCM almacena el mensaje y lo entrega tan pronto como sea posible. Si bien esto está bien en la mayoría de los casos, hay algunas aplicaciones para las que es posible que nunca se entregue un mensaje tardío. Por ejemplo, si el mensaje es una llamada entrante o una notificación de chat de video, solo es significativo durante un breve período de tiempo antes de que finalice la llamada. O si el mensaje es una invitación a un evento, no sirve de nada si se recibe una vez finalizado el evento.

En Android y Web/JavaScript, puede especificar la vida útil máxima de un mensaje. El valor debe tener una duración de 0 a 2.419.200 segundos (28 días), y corresponde al período máximo de tiempo durante el cual FCM almacena e intenta entregar el mensaje. Las solicitudes que no contienen este campo por defecto tienen un período máximo de cuatro semanas.

Estos son algunos usos posibles de esta función:

  • Llamadas entrantes de chat de video
  • Eventos de invitación que caducan
  • Eventos del calendario

Otra ventaja de especificar la vida útil de un mensaje es que FCM nunca acelera los mensajes con un valor de tiempo de vida de 0 segundos. En otras palabras, FCM garantiza el mejor esfuerzo para los mensajes que deben entregarse "ahora o nunca". Tenga en cuenta que un valor time_to_live de 0 significa que los mensajes que no se pueden entregar de inmediato se descartan. Sin embargo, debido a que tales mensajes nunca se almacenan, esto proporciona la mejor latencia para enviar mensajes de notificación.

Este es un ejemplo de una solicitud que incluye 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"
      }
    }
  }
}

Duración de un mensaje

Cuando un servidor de aplicaciones publica un mensaje en FCM y recibe un ID de mensaje, no significa que el mensaje ya se entregó al dispositivo. Más bien, significa que fue aceptado para la entrega. Lo que sucede con el mensaje después de que se acepta depende de muchos factores.

En el mejor de los casos, si el dispositivo está conectado a FCM, la pantalla está encendida y no hay restricciones de limitación, el mensaje se envía de inmediato.

Si el dispositivo está conectado pero en Doze, el FCM almacena un mensaje de prioridad baja hasta que el dispositivo está fuera de Doze. Y ahí es donde juega un papel la bandera de collapse_key : si ya hay un mensaje con la misma clave de colapso (y token de registro) almacenado y en espera de entrega, el mensaje anterior se descarta y el nuevo toma su lugar (es decir, el mensaje anterior). el mensaje está colapsado por el nuevo). Sin embargo, si no se establece la clave de contracción, tanto los mensajes nuevos como los antiguos se almacenan para entregas futuras.

Si el dispositivo no está conectado a FCM, el mensaje se almacena hasta que se establece una conexión (nuevamente respetando las reglas de la clave de colapso). Cuando se establece una conexión, FCM envía todos los mensajes pendientes al dispositivo. Si el dispositivo nunca se vuelve a conectar (por ejemplo, si se restableció la configuración de fábrica), el mensaje finalmente se agota y se descarta del almacenamiento de FCM. El tiempo de espera predeterminado es de cuatro semanas, a menos que se establezca el indicador time_to_live .

Para obtener más información sobre la entrega de un mensaje:

    Para obtener más información sobre la entrega de mensajes en plataformas Android o Apple, consulte el panel de informes de FCM , que registra la cantidad de mensajes enviados y abiertos en dispositivos Apple y Android, junto con datos de "impresiones" (notificaciones vistas por los usuarios) para aplicaciones de Android

Para dispositivos Android con mensajería de canal directo habilitada, si el dispositivo no se ha conectado a FCM durante más de un mes, FCM aún acepta el mensaje pero lo descarta de inmediato. Si el dispositivo se conecta dentro de las cuatro semanas posteriores al último mensaje de datos que le envió, su cliente recibe la devolución de llamada onDeletedMessages() . Luego, la aplicación puede manejar la situación correctamente, generalmente solicitando una sincronización completa del servidor de la aplicación.

Finalmente, cuando FCM intenta enviar un mensaje al dispositivo y se desinstaló la aplicación, FCM descarta ese mensaje de inmediato e invalida el token de registro. Los futuros intentos de enviar un mensaje a ese dispositivo dan como resultado un error NotRegistered .

Limitación y escalado

Nuestro objetivo es entregar siempre cada mensaje enviado a través de FCM. Sin embargo, la entrega de todos los mensajes a veces da como resultado una mala experiencia general del usuario. En otros casos, debemos proporcionar límites para garantizar que FCM proporcione un servicio escalable para todos los remitentes.

Limitación de mensajes contraíbles

Como se describió anteriormente, los mensajes plegables son notificaciones sin contenido diseñadas para colapsarse una encima de la otra. En el caso de que un desarrollador repita el mismo mensaje en una aplicación con demasiada frecuencia, retrasamos (aceleramos) los mensajes para reducir el impacto en la batería del usuario.

Por ejemplo, si envía una gran cantidad de nuevas solicitudes de sincronización de correo electrónico a un solo dispositivo, podemos retrasar la siguiente solicitud de sincronización de correo electrónico unos minutos para que el dispositivo pueda sincronizarse a una velocidad promedio más baja. Este estrangulamiento se realiza estrictamente para limitar el impacto de la batería que experimenta el usuario.

Si su caso de uso requiere patrones de envío de alta ráfaga, entonces los mensajes no contraíbles pueden ser la opción correcta. Para tales mensajes, asegúrese de incluir el contenido en dichos mensajes para reducir el costo de la batería.

Limitamos los mensajes plegables a una ráfaga de 20 mensajes por aplicación por dispositivo, con una recarga de 1 mensaje cada 3 minutos.

Limitación del servidor XMPP

Limitamos la velocidad a la que puede conectarse a los servidores FCM XMPP a 400 conexiones por minuto por proyecto. Esto no debería ser un problema para la entrega de mensajes, pero es importante para garantizar la estabilidad de nuestro sistema.

Para cada proyecto, FCM permite 2500 conexiones en paralelo.

Tasa máxima de mensajes a un solo dispositivo

Para Android, puede enviar hasta 240 mensajes por minuto y 5000 mensajes por hora a un solo dispositivo. Este umbral alto está destinado a permitir ráfagas de tráfico a corto plazo, como cuando los usuarios interactúan rápidamente a través del chat. Este límite evita que los errores en la lógica de envío agoten inadvertidamente la batería de un dispositivo.

Para iOS, devolvemos un error cuando la tarifa supera los límites de APN.

Límite de mensajes ascendentes

Limitamos los mensajes ascendentes a 1 500 000 por minuto por proyecto para evitar sobrecargar los servidores de destino ascendentes.

Limitamos los mensajes ascendentes por dispositivo a 1000/minuto para proteger contra el agotamiento de la batería debido al mal comportamiento de la aplicación.

Límite de mensaje de tema

La tasa de adición/eliminación de suscripción de temas está limitada a 3000 QPS por proyecto.

Para conocer las tasas de envío de mensajes, consulte Fanout Throttling .

Limitación de fanout

Distribución de mensajes es el proceso de enviar un mensaje a varios dispositivos, como cuando se dirige a temas y grupos, o cuando utiliza el redactor de notificaciones para dirigirse a audiencias o segmentos de usuarios.

La distribución de mensajes no es instantánea y, por lo tanto, ocasionalmente tiene varias distribuciones en curso al mismo tiempo. Limitamos el número de fanouts de mensajes simultáneos por proyecto a 1000. Después de eso, podemos rechazar solicitudes de distribución adicionales o posponer la distribución de las solicitudes hasta que se completen algunas de las distribuciones ya en curso.

La tasa de fanout real alcanzable está influenciada por la cantidad de proyectos que solicitan fanouts al mismo tiempo. Una tasa de fanout de 10 000 QPS para un proyecto individual no es poco común, pero ese número no es una garantía y es el resultado de la carga total en el sistema. Es importante tener en cuenta que la capacidad de distribución disponible se divide entre proyectos y no entre solicitudes de distribución. Por lo tanto, si su proyecto tiene dos distribuciones en curso, cada distribución solo verá la mitad de la tasa de distribución disponible. La forma recomendada de maximizar la velocidad de distribución es tener solo una distribución activa en curso a la vez.

Puertos FCM y su firewall

Si su organización tiene un firewall para restringir el tráfico hacia o desde Internet, debe configurarlo para permitir que los dispositivos móviles se conecten con FCM para que los dispositivos en su red reciban mensajes. FCM normalmente usa el puerto 5228, pero a veces usa 443, 5229 y 5230.

Para los dispositivos que se conectan a su red, FCM no proporciona direcciones IP específicas porque nuestro rango de direcciones IP cambia con demasiada frecuencia y las reglas de su firewall podrían quedar obsoletas, lo que afectaría la experiencia de sus usuarios. Idealmente, incluya en la lista de permitidos los puertos 5228-5230 y 443 sin restricciones de IP. Sin embargo, si debe tener una restricción de IP, debe incluir en la lista de permitidos todas las direcciones IP enumeradas en goog.json . Esta gran lista se actualiza con regularidad y se recomienda que actualice sus reglas mensualmente. Los problemas causados ​​por las restricciones de IP del firewall suelen ser intermitentes y difíciles de diagnosticar.

Ofrecemos un conjunto de nombres de dominio que se pueden incluir en la lista de permitidos en lugar de direcciones IP. Esos nombres de host se enumeran a continuación. Si comenzamos a usar nombres de host adicionales, actualizaremos la lista aquí. El uso de nombres de dominio para su regla de firewall puede o no ser funcional en su dispositivo de firewall.

Puertos TCP para abrir:

  • 5228
  • 5229
  • 5230
  • 443

Nombres de host para abrir:

  • 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
  • aprovisionamiento de dispositivos.googleapis.com
  • firebaseinstallations.googleapis.com

Cortafuegos de traducción de direcciones de red y/o inspección de paquetes con estado:

Si su red implementa la traducción de direcciones de red (NAT) o la inspección de paquetes con estado (SPI), implemente un tiempo de espera de 30 minutos o más para nuestras conexiones a través de los puertos 5228-5230. Esto nos permite brindar una conectividad confiable mientras reducimos el consumo de batería de los dispositivos móviles de sus usuarios.

Cartas credenciales

Según las funciones de FCM que implementes, es posible que necesites las siguientes credenciales de tu proyecto de Firebase:

Projecto ID Un identificador único para su proyecto de Firebase, que se usa en las solicitudes al extremo HTTP de FCM v1. Este valor está disponible en el panel Configuración de Firebase console .
ficha de registro

Una cadena de token única que identifica cada instancia de la aplicación cliente. El token de registro es necesario para la mensajería de un solo dispositivo y de un grupo de dispositivos. Tenga en cuenta que los tokens de registro deben mantenerse en secreto.

identificación del remitente Un valor numérico único creado cuando crea su proyecto de Firebase, disponible en la pestaña Cloud Messaging del panel de configuración de la consola de Firebase. La ID del remitente se usa para identificar a cada remitente que puede enviar mensajes a la aplicación cliente.
token de acceso Un token OAuth 2.0 de corta duración que autoriza solicitudes a la API HTTP v1. Este token está asociado con una cuenta de servicio que pertenece a su proyecto de Firebase. Para crear y rotar tokens de acceso, siga los pasos descritos en Autorizar solicitudes de envío .
Clave del servidor (para protocolos heredados)

Una clave de servidor que autoriza a su servidor de aplicaciones a acceder a los servicios de Google, incluido el envío de mensajes a través de los protocolos heredados de Firebase Cloud Messaging. Obtienes la clave del servidor cuando creas tu proyecto de Firebase. Puede verlo en la pestaña Cloud Messaging del panel de configuración de Firebase console.

Importante: No incluya la clave del servidor en ninguna parte de su código de cliente. Además, asegúrese de usar solo claves de servidor para autorizar su servidor de aplicaciones. FCM rechaza las claves de Android, plataforma Apple y navegador.