Acerca de los mensajes de FCM

Firebase Cloud Messaging (FCM) ofrece una amplia variedad de funciones y opciones de mensajería. La información de esta página tiene por objetivo ayudarte a comprender los diferentes tipos de mensajes de FCM y lo que puedes hacer con ellos.

Tipos de mensajes

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

  • Mensajes de notificación, que a veces se consideran "mensajes de pantalla". El SDK de FCM maneja automáticamente estos mensajes
  • Mensajes de datos, que maneja la app cliente

Los mensajes de notificación contienen un conjunto predefinido de claves visibles para el usuario. Los mensajes de datos, por el contrario, solo contienen pares clave-valor personalizados definidos por el usuario. Los mensajes de notificación pueden contener una carga útil de datos opcional. La carga útil máxima para ambos tipos de mensajes es de 4,000 bytes, excepto cuando se envían mensajes desde Firebase console. Esta consola aplica de manera forzosa un límite de 1,024 caracteres.

Caso de uso Modo de envío
Mensaje de notificación El SDK de FCM muestra el mensaje en los dispositivos de los usuarios finales en nombre de la app cliente cuando se ejecuta en segundo plano. De lo contrario, si la app se está ejecutando en primer plano cuando se recibe la notificación, el código de la app determina el comportamiento. Los mensajes de notificación tienen un conjunto predefinido de claves visibles para el usuario y una carga útil de datos opcional de pares clave-valor personalizados.
  1. En un entorno de confianza, como Cloud Functions o tu servidor de apps, usa el SDK de Admin o los protocolos de servidor de FCM: Configura la clave notification. Puede tener una carga útil de datos opcional. Siempre se puede contraer.

    Consulta algunos ejemplos de notificaciones visuales y envía cargas útiles de solicitud.

  2. Usa el Compositor de Notifications: Ingresa el mensaje, el texto, el título, etc. y envíala. Ingresa datos personalizados para agregar una carga de datos opcional.
Mensaje de datos La app 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 a continuación). En un entorno de confianza, como Cloud Functions o tu servidor de apps, usa el SDK de Admin o los protocolos de servidor de FCM: Configura solo la clave data.

Si quieres que el SDK de FCM se encargue de mostrar una notificación automáticamente cuando tu app se ejecuta en segundo plano, usa mensajes de notificación. Si quieres procesar los mensajes con tu propio código de app cliente, usa mensajes de datos.

FCM puede enviar un mensaje de notificación que incluya una carga útil de datos opcional. En estos casos, FCM se encarga de mostrar la carga de notificaciones y la app cliente controla la carga de datos.

Mensajes de notificación

Para realizar pruebas, campañas de marketing y volver a generar la participación de los usuarios, puedes enviar mensajes de notificación con Firebase console. Firebase console proporciona pruebas A/B basadas en estadísticas para perfeccionar y mejorar los mensajes de marketing.

Para enviar mensajes de notificación de manera programática con el SDK de Admin o los protocolos de FCM, configura la clave notification con el conjunto predefinido de opciones clave-valor necesarias para la parte del mensaje de notificación que es visible para el usuario. Por ejemplo, el siguiente es un mensaje de notificación con formato JSON en una app de IM. El usuario debería ver un mensaje con el título “Portugal vs. Denmark” y el texto “great match!” 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 notificación cuando la app se ejecuta en segundo plano. En el caso de las apps en primer plano, una función de devolución de llamada controla los mensajes.

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

Mensajes de datos

Configura la clave apropiada con tus pares clave-valor personalizados para enviar una carga útil de datos a la app cliente.

Por ejemplo, el siguiente es un mensaje con formato JSON en la misma app de IM anterior, cuya información está encapsulada en la clave data común y la app cliente debe interpretar el contenido:

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

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

Encriptación para mensajes de datos

La capa de transporte de Android (consulta la arquitectura de FCM) usa encriptación de punto a punto. Según tus necesidades, puedes agregar encriptación de extremo a extremo a los mensajes de datos. FCM no proporciona una solución de extremo a extremo. Sin embargo, hay soluciones externas disponibles, como Capillary o DTLS.

Mensajes de notificación con carga útil de datos opcional

Puedes enviar mensajes de notificación que contengan una carga útil opcional de pares clave-valor personalizados, ya sea de forma programática o a través de Firebase console. En el Compositor de Notifications, usa los campos Datos personalizados en las Opciones avanzadas.

El comportamiento de la app cuando recibe mensajes que incluyen cargas de notificaciones y de datos depende de si la app se encuentra en segundo plano o en primer plano; en otras palabras, si está activa o no cuando recibe los mensajes.

  • Cuando está en segundo plano, la app recibe la carga de notificaciones en la bandeja de notificaciones y solo maneja la carga de datos cuando el usuario presiona la notificación.
  • Cuando está en primer plano, la app recibe un objeto de mensaje con ambas cargas disponibles.

El siguiente mensaje con formato JSON contiene las claves notification y data:

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

Personaliza un mensaje en diferentes plataformas

El SDK de Firebase Admin y el protocolo de HTTP v1 de FCM te permiten configurar todos los campos disponibles del objeto message de las solicitudes de mensajes. Incluye lo siguiente:

  • un conjunto común de campos que pueden interpretar todas las instancias de la app que reciben el mensaje
  • conjuntos de campos específicos de la plataforma, como AndroidConfig y WebpushConfig, que solo las instancias de la app que se ejecutan en la plataforma específica pueden interpretar

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

Cuándo usar campos comunes

Usa campos comunes en las siguientes circunstancias:

  • Cuando quieras segmentar las instancias de la app a todas las plataformas: Apple, Android y la Web
  • Cuando quieras enviar mensajes a temas

Todas las instancias de la app, independientemente de la plataforma, pueden interpretar los siguientes campos comunes:

Cuándo usar campos específicos de la plataforma

Usa campos específicos de la plataforma en las siguientes circunstancias:

  • Cuando quieras enviar campos solo a plataformas específicas
  • Cuando quieras enviar campos específicos de la plataforma además de campos comunes

Cuando desees enviar valores solo a plataformas específicas, no uses campos comunes, utiliza campos específicos de la plataforma en su lugar. Por ejemplo, para enviar una notificación solo a plataformas de Apple y a la Web, pero no a Android, debes usar dos conjuntos independientes de campos: uno para Apple y otro para la Web.

Cuando envíes mensajes con opciones de entrega específicas, usa campos específicos de la plataforma para configurarlas. Puedes especificar valores diferentes por plataforma si lo deseas. Sin embargo, debes usar campos específicos de la plataforma incluso cuando quieras configurar el mismo valor en distintas plataformas. Esto se debe a que cada plataforma puede interpretar el valor de manera levemente distinta. Por ejemplo, en Android, el tiempo de actividad se configura como un tiempo de vencimiento expresado en segundos, mientras que, en Apple, se configura como una fecha de vencimiento.

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

La siguiente solicitud de envío v1 envía el mismo título de la notificación y el mismo contenido a todas las plataformas, pero también envía algunas anulaciones a plataformas específicas. En detalle, la solicitud realiza lo siguiente:

  • Configura un tiempo de actividad prolongado para las plataformas Android y web, a la vez que establece la prioridad de los mensajes APNS (plataformas de Apple) en una opción baja.
  • Configura las claves apropiadas para determinar la acción que se realizará cuando un usuario presione 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"
       }
     }
   }
 }

Consulta la documentación de referencia de HTTP v1 para obtener detalles 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, consulta cómo compilar 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 habilita opciones similares en plataformas de Apple y la Web. Por ejemplo, el comportamiento de los mensajes “contraíbles” es compatible con Android a través de collapse_key de FCM, con Apple a través de apns-collapse-id y con JavaScript/la Web a través de Topic. Para obtener detalles, consulta las descripciones de esta sección y la documentación de referencia relacionada.

Mensajes contraíbles y no contraíbles

Un mensaje no contraíble indica que cada mensaje individual se entrega al dispositivo. Un mensaje no contraíble entrega cierto contenido útil, a diferencia de un mensaje contraíble como un "ping" que no tiene contenido, destinado a comunicarse con el servidor y recuperar datos.

Algunos casos prácticos típicos de mensajes no contraíbles son los mensajes de chat o los mensajes críticos. Por ejemplo, en una app de IM, querrás enviar cada mensaje, ya que cada mensaje tiene un contenido diferente.

En Android, existe 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. Entonces, la app puede manejar la situación de manera adecuada, por lo general a través de una solicitud de sincronización completa desde el servidor de apps.

Un mensaje contraíble es un mensaje que se puede reemplazar por un mensaje nuevo si todavía no se ha enviado al dispositivo.

Un caso de uso común de los mensajes contraíbles son los mensajes que se utilizan para indicar a una app para dispositivos móviles que sincronice los datos del servidor. Un ejemplo sería una app de deportes que muestra marcadores actualizados a los usuarios. Solo el mensaje más reciente es relevante.

Para marcar un mensaje como contraíble en Android, incluye el parámetro collapse_key en la carga útil del mensaje. Según la configuración predeterminada, la clave de contracción es el nombre del paquete de la app registrado en Firebase console. El servidor de FCM puede almacenar simultáneamente cuatro mensajes contraíbles diferentes por dispositivo, cada uno con una clave de contracción diferente. Si excedes esta cantidad, FCM únicamente conserva cuatro claves de contracción, sin garantizar cuáles.

De forma predeterminada, se pueden contraer los mensajes por temas sin carga útil. Los mensajes de notificación siempre se pueden contraer y, además, omitirán el parámetro collapse_key.

¿Cuál debería usar?

Los mensajes contraíbles son una mejor opción desde el punto de vista del rendimiento, siempre que tu app no necesite usar mensajes no contraíbles. Sin embargo, si usas mensajes contraíbles, recuerda que FCM solo permite el uso de un máximo de cuatro claves de contracción diferentes por token de registro en cualquier momento. No debes exceder esta cantidad, o podría causar consecuencias impredecibles.

Caso de uso Modo de envío
No contraíble Cada mensaje es importante para la app cliente y debe entregarse. Excepto para los mensajes de notificación, todos los mensajes son no contraíbles de forma predeterminada.
Contraíble Cuando hay un mensaje más reciente que procesa un mensaje más antiguo relacionado que es irrelevante para la app cliente, FCM reemplaza el mensaje más antiguo. Por ejemplo, los mensajes que se utilizan para iniciar una sincronización de datos del servidor o los mensajes de notificación desactualizados. Determina el parámetro apropiado en tu solicitud de mensaje:
  • collapseKey en Android
  • apns-collapse-id en Apple
  • Topic en la Web
  • collapse_key en protocolos heredados (todas las plataformas)

Configura la prioridad de un mensaje

Tienes dos opciones para asignar una prioridad de entrega a los mensajes descendentes: prioridad normal y alta. Aunque el comportamiento difiere levemente entre las plataformas, la entrega de mensajes con prioridad normal y alta funciona de la siguiente manera:

  • Prioridad normal. Los mensajes con prioridad normal se entregan de inmediato cuando la app está en primer plano. En el caso de las apps en segundo plano, es posible que se retrase la entrega. Para los mensajes menos urgentes, como las notificaciones de correos electrónicos nuevos, la sincronización de IU o la sincronización de datos de app en segundo plano, selecciona la prioridad de entrega normal.

  • Prioridad alta. FCM intenta entregar los mensajes de alta prioridad de inmediato, incluso si el dispositivo está en modo Descanso. Los mensajes con prioridad alta son para el contenido visible para los usuarios y sensible al tiempo.

A continuación, se muestra un ejemplo de un mensaje con prioridad normal enviado mediante el protocolo FCM HTTP v1 para notificar a un suscriptor de una revista que existe contenido nuevo 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 sobre la configuración de prioridad de los mensajes en diferentes plataformas, revisa los siguientes artículos:

Configuración de la duración de un mensaje

Comúnmente, FCM envía los mensajes apenas se envían. Sin embargo, esto no siempre es posible. Por ejemplo, si la plataforma es Android, el dispositivo puede estar apagado, sin conexión o no disponible. O bien, FCM puede retrasar los mensajes de manera intencional para evitar que una app consuma recursos en exceso y perjudique la duración de la batería.

Cuando esto sucede, FCM almacena el mensaje y lo entrega tan pronto como sea factible. Esto es correcto en la mayoría de los casos. Sin embargo, para algunas apps, enviar un mensaje tarde es lo mismo que no entregarlo. Por ejemplo, si el mensaje es una notificación de llamada entrante o chat de video, solo es relevante durante un breve período antes de que finalice la llamada. Por otra parte, si el mensaje es una invitación a un evento, es inútil recibirlo una vez finalizado el evento.

En Android y Web/JavaScript, puedes especificar la duración máxima de un mensaje. El valor debe ser una duración de entre 0 y 2,419,200 segundos (28 días). Esto indicará el período máximo durante el cual FCM almacenará y tratará de entregar el mensaje. Las solicitudes que no contienen este campo reciben de forma predeterminada el período máximo de cuatro semanas.

A continuación, se muestran algunos usos posibles para esta función:

  • Llamadas entrantes de chat de video
  • Invitaciones a eventos vencidas
  • Eventos del calendario

Otra ventaja de especificar la duración de un mensaje es que FCM nunca limita mensajes con un valor de tiempo de vida de 0 segundos. En otras palabras, FCM garantiza el mejor esfuerzo para los mensajes que se deben enviar "ahora o nunca". Ten 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, dado que estos mensajes nunca se almacenan, esto proporciona la mejor latencia para enviar mensajes de notificación.

A continuación, se muestra un ejemplo de una solicitud que incluye el 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 apps publica un mensaje en FCM y recibe un ID de mensaje de vuelta, no significa que el mensaje ya se entregó al dispositivo. Más bien, significa que se aceptó 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 existen restricciones de regulación, el mensaje se entrega de inmediato.

Si el dispositivo está conectado, pero en modo Descanso, FCM almacena un mensaje con prioridad baja hasta que el dispositivo sale del modo Descanso. Ahí es cuando la marca collapse_key cumple una función: Si ya existe un mensaje con la misma clave de contracción (y el mismo token de registro) almacenado y a la espera de ser entregado, el mensaje antiguo se descarta y el mensaje nuevo ocupa su lugar (es decir, el mensaje nuevo contrae el mensaje antiguo). Sin embargo, si no se configura la clave de contracción, tanto el mensaje nuevo como el antiguo se almacenan para su futuro envío.

Si el dispositivo no está conectado a FCM, el mensaje se almacena hasta que se establece una conexión (una vez más, se respetan las reglas de las claves de contracción). Cuando se establece una conexión, FCM entrega todos los mensajes pendientes al dispositivo. Si el dispositivo nunca se vuelve a conectar (por ejemplo, si se restableció de fábrica), el tiempo de espera del mensaje finalmente se agota y se descarta del almacenamiento de FCM. El tiempo de espera predeterminado es de cuatro semanas, a menos que se configure la marca time_to_live.

Para obtener más información útil sobre la entrega de un mensaje, revisa lo siguiente:

    Para obtener más información sobre la entrega de mensajes en Android o plataformas de Apple, consulta el panel de informes de FCM, que registra la cantidad de mensajes que se enviaron y abrieron en dispositivos Apple y Android, junto con datos de “impresiones” (las notificaciones que ven los usuarios) de las apps para Android.

En el caso de los dispositivos Android que tienen habilitado el canal de mensajería directa, si el dispositivo no se conectó a FCM durante más de un mes, FCM acepta el mensaje de todas formas, pero lo descarta de inmediato. Si el dispositivo se conecta en un plazo de cuatro semanas desde el último mensaje de datos que le enviaste, tu cliente recibe la devolución de llamada onDeletedMessages(). Entonces, la app puede manejar la situación de manera adecuada, por lo general a través de una solicitud de sincronización completa desde el servidor de apps.

Por último, si FCM intenta entregar un mensaje al dispositivo y la app se desinstaló, FCM descarta el mensaje de inmediato y anula la validez del token de registro. Los intentos posteriores de enviar un mensaje a ese dispositivo darán como resultado un error NotRegistered.

Regulación y escalamiento

Nuestro objetivo es entregar siempre cada mensaje que se envía mediante FCM. Sin embargo, cuando se entregan todos los mensajes, en ocasiones se genera una experiencia general deficiente para el usuario. En otros casos, debemos definir límites a fin de garantizar que FCM proporcione un servicio escalable para todos los remitentes.

Regulación de mensajes contraíbles

Como se describió anteriormente, los mensajes contraíbles son notificaciones sin contenido diseñadas para contraerse una sobre otra. Si un desarrollador envía el mismo mensaje hacia una app con demasiada frecuencia, retrasaremos (regularemos) los mensajes a fin de disminuir el impacto sobre la batería del usuario.

Por ejemplo, si envías una gran cantidad de solicitudes de sincronización de correo electrónico nuevo a un solo dispositivo, es posible que retrasemos la siguiente solicitud unos minutos para que el dispositivo se pueda sincronizar a una tasa promedio más baja. La regulación se realiza exclusivamente para limitar el impacto sobre la batería del usuario.

Los mensajes no contraíbles pueden ser la opción adecuada si tu caso práctico requiere patrones de envío con picos de actividad elevados. Para tales mensajes, asegúrate de incluir el contenido en estos a fin de disminuir el consumo de batería.

Los mensajes contraíbles se limitan a picos de actividad de 20 mensajes por app y por dispositivo, con una reposición de 1 mensaje cada 3 minutos.

Regulación de servidores XMPP

Limitamos la tasa de conexiones a servidores XMPP de FCM a 400 por minuto y por proyecto. Esto no debería representar un problema para la entrega de mensajes, pero es importante a fin de garantizar la estabilidad de nuestro sistema.

Para cada proyecto, FCM permite 2,500 conexiones paralelas.

Tasa máxima de envío de mensajes a un solo dispositivo

En Android, puedes enviar hasta 240 mensajes por minuto y 5,000 mensajes por hora a un solo dispositivo. El propósito de este umbral alto es permitir que se produzcan aumentos de actividad de tráfico a corto plazo, como cuando los usuarios interactúan rápidamente por chat. Con este límite, se evita que se generen errores en los que la lógica de envío consume la batería de un dispositivo involuntariamente.

En iOS, se muestra un error cuando la tasa supera los límites de APNS.

Límite de mensajes ascendentes

El límite de los mensajes ascendentes es de 1,500,000 por minuto y por proyecto a fin de evitar la sobrecarga de los servidores de destino ascendentes.

Por dispositivo, el límite es de 1,000 por minuto a fin de evitar que el mal comportamiento de una app consuma la batería.

Límite de los mensajes por temas

La tasa de adición o eliminación de suscripciones a temas se limita a 3,000 QPS por proyecto.

Consulta Regulación de la distribución para obtener información sobre las tasas de envío de mensajes.

Regulación de la distribución

La distribución de mensajes es el proceso de enviar mensajes a varios dispositivos, como cuando te orientas a temas y grupos, o usas el Compositor de Notifications para orientarte a públicos o segmentos de usuarios.

La distribución de mensajes no es una acción instantánea y rara vez habrá varias en curso simultáneamente. Limitamos a 1,000 la cantidad de distribuciones de mensajes simultáneas por proyecto. Cuando se alcance ese límite, es posible que rechacemos las solicitudes de distribución adicionales o aplacemos la distribución de las solicitudes hasta que se completen algunas que ya estén en curso.

La tasa real alcanzable de distribución varía según la cantidad de proyectos que soliciten distribuciones al mismo tiempo. No es inusual ver una tasa de distribución de 10,000 QPS en un proyecto individual, pero esa cantidad no se garantiza y proviene de la carga total del sistema. Cabe destacar que la capacidad de distribución disponible se divide entre los proyectos y no entre las solicitudes de distribución. Por lo tanto, si un proyecto tiene dos distribuciones en curso, cada una de estas solo podrá acceder a la mitad de la tasa de distribución disponible. Para maximizar la velocidad de distribución, se recomienda tener solo una distribución activa a la vez.

Los puertos de FCM y el firewall

Si tu organización tiene un firewall para restringir el tráfico hacia o desde Internet, debes configurarlo para permitir que los dispositivos móviles se conecten con FCM de modo que los dispositivos en tu red puedan recibir mensajes. Normalmente, FCM utiliza el puerto 5228, pero en ocasiones utiliza los puertos 443, 5229 y 5230.

Para los dispositivos que se conectan a tu red, FCM no proporciona IP específicas, ya que nuestro rango de IP cambia con demasiada frecuencia, y las reglas de tu firewall podrían quedar desactualizadas, lo que afectaría la experiencia de los usuarios. Lo ideal es incluir en la lista permitida los puertos del 5228 al 5230 y el 443 sin restricciones de IP. Sin embargo, si necesitas implementar una restricción de IP, debes incluir en la lista permitida todas las direcciones IP enumeradas en goog.json. Esta lista grande se actualiza con frecuencia y se recomienda que actualices tus reglas de forma mensual. A menudo, los problemas causados por las restricciones de IP del firewall son intermitentes y difíciles de diagnosticar.

Ofrecemos un conjunto de nombres de dominio que se pueden incluir en la lista de entidades permitidas en lugar de las direcciones IP. Estos nombres de host se indican a continuación. Si comenzamos a usar nombres de host adicionales, actualizaremos la lista. Es posible que el uso de nombres de dominio para tu regla de firewall funcione o no en tu dispositivo de firewall.

Puertos TCP que se deben permitir:

  • 5228
  • 5229
  • 5230
  • 443

Nombres de host que se deben permitir:

  • 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

Firewalls de traducción de direcciones de red o inspección de paquetes con estado:

Si tu red implementa la traducción de direcciones de red (NAT) o la inspección de paquetes con estado (SPI), implementa un tiempo de espera de 30 minutos o más para nuestras conexiones a través de los puertos 5228, 5229 y 5230. Esto nos permite proporcionar una conectividad confiable y, al mismo tiempo, reducir el consumo de batería de los dispositivos móviles de los usuarios.

Credenciales

Es posible que necesites las siguientes credenciales de tu proyecto de Firebase, según las características de FCM que implementes:

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

Una string de token único que identifica a cada instancia de la app cliente. El token de registro es obligatorio para la mensajería a dispositivos individuales y a grupos de dispositivos. Ten en cuenta que los tokens de registro se deben mantener en secreto.

ID de remitente Un valor numérico único que se genera cuando se crea un proyecto de Firebase, disponible en la pestaña Cloud Messaging del panel Configuración de Firebase console. El ID de remitente se usa para identificar cada remitente que puede enviar mensajes a la app cliente.
Token de acceso Un token de OAuth 2.0 de corta duración que autoriza las solicitudes a la API de HTTP v1. Este token se asocia a una cuenta de servicio que pertenece a tu proyecto de Firebase. Para crear y rotar tokens de acceso, sigue los pasos que se describen en Autoriza solicitudes de envío.
Clave de servidor (para protocolos heredados)

Una clave de servidor que autoriza a tu servidor de apps para 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 de servidor cuando creas el proyecto de Firebase. Puedes verla en la pestaña Cloud Messaging del panel Configuración de Firebase console.

Importante: No incluyas la clave de servidor en ninguna parte del código de cliente. Además, asegúrate de usar solo claves de servidor para autorizar tu servidor de apps. FCM rechaza las claves de Android, de las plataformas de Apple y del navegador.