Ir a la consola

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 de datos opcional. La carga de datos máxima para ambos tipos de mensajes es de 4 KB, excepto cuando se envían mensajes desde Firebase console. Esta consola impone un límite de 1024 caracteres.

Caso de uso Modo de envío
Mensaje de notificación FCM muestra automáticamente el mensaje en los dispositivos del usuario final en nombre de la app 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 tu servidor de apps, usa el SDK de Admin o los protocolos de servidor de FCM: Configura la clave notification. Puede tener una carga de datos opcional. Siempre se puede contraer.
  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. 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 deseas que FCM se encargue de mostrar una notificación en nombre de la app cliente, usa mensajes de notificación. Si deseas procesar los mensajes en tu app cliente, usa mensajes de datos.

FCM puede enviar un mensaje de notificación que incluya una carga 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"
    }
  }
}

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

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

Puedes enviar mensajes de notificación que contengan una carga 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 la clave notification y la clave data:

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

Cómo personalizar 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 pueden interpretar las instancias de la app que se ejecutan en la plataforma específica

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 orientarte a las instancias de la app que se ejecutan en todas las plataformas: iOS, 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, usa campos específicos de la plataforma en su lugar. Por ejemplo, para enviar una notificación solo a iOS y la Web, pero no a Android, debes usar dos conjuntos independientes de campos: uno para iOS 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 vida se configura como un tiempo de vencimiento expresado en segundos, mientras que, en iOS, 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 vida prolongado para las plataformas Android y Web, al tiempo que establece la prioridad de los mensajes APN (iOS) 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 en iOS (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 iOS y Web. Por ejemplo, el comportamiento de los mensajes "contraíbles" es compatible con Android a través de collapse_key de FCM, con iOS a través de apns-collapse-id y con JavaScript/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 de uso 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. FCM permite que el servidor de apps utilice un máximo de cuatro claves de contracción diferentes por dispositivo Android en cualquier momento. En otras palabras, 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.

¿Cuál debería usar?

Los mensajes contraíbles son una mejor opción desde el punto de vista del rendimiento, siempre y cuando tu app no necesite usar mensajes no contraíbles. Sin embargo, si usas mensajes contraíbles, recuerda que FCM solo permite que el servidor de conexiones de FCM use 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 iOS
  • Topic en Web
  • collapse_key en protocolos heredados (todas las plataformas)

Configuración de la prioridad de un mensaje

En Android, hay dos opciones para asignar una prioridad de entrega a los mensajes descendentes: prioridad normal y alta. La entrega de los mensajes con prioridad normal o alta funciona de la siguiente manera:

  • Prioridad normal. Esta es la prioridad predeterminada para los mensajes de datos. Los mensajes con prioridad normal se entregan de inmediato cuando la app está en primer plano. Cuando el dispositivo está en Descanso, la entrega podría retrasarse para conservar la batería. 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.

    Cuando recibas un mensaje de prioridad normal en Android que solicite una sincronización de datos en segundo plano para tu app, debes programar una tarea con WorkManager para controlarla cuando la red esté disponible.

  • Prioridad alta. FCM intenta entregar los mensajes de alta prioridad de inmediato, lo que permite que el servicio de FCM active un dispositivo inactivo cuando es necesario y ejecute un procesamiento limitado (incluido el acceso de red altamente limitado). En general, los mensajes con prioridad alta generan la interacción de los usuarios con la app o sus notificaciones. Si FCM detecta un patrón en el que no lo hacen, puede reducir la prioridad de los mensajes. Android P presentó depósitos de App Standby que limitan la cantidad de mensajes de alta prioridad de FCM que puedes enviar a tu app y que no conducen a que el usuario use la app o vea una notificación. Si, en respuesta a un mensaje de alta prioridad, se muestra una notificación de una forma visible para el usuario, entonces la cuota del depósito de App Standby no se consumirá con ese mensaje.

    Como una pequeña porción de la población móvil de Android se encuentra en redes de alta latencia, evita abrir una conexión a tus servidores antes de mostrar una notificación. La devolución de llamadas al servidor antes del final del tiempo de procesamiento permitido puede ser algo arriesgado para los usuarios en redes de alta latencia. En lugar de eso, incluye el contenido de la notificación en el mensaje de FCM y muéstralo de inmediato. Si necesitas sincronizar contenido adicional de la app en Android, puedes programar una tarea con WorkManager para controlar el proceso en segundo plano.

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 regula 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 de time_to_live de 0 significa que los mensajes que no se pueden enviar 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 tiempo de vida (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"
      }
    }
  }
}

Recepción de mensajes de varios remitentes

FCM permite que varias partes envíen mensajes a la misma app cliente. Por ejemplo, supongamos que la app cliente es un agregador de artículos con varios colaboradores, y cada uno de ellos debe poder enviar un mensaje cuando publican un artículo nuevo. Este mensaje puede contener una URL para que la app cliente pueda descargar el artículo. En lugar de tener que centralizar toda la actividad de envío en una ubicación, FCM permite que cada uno de estos colaboradores envíe sus propios mensajes.

Para habilitar esta función, asegúrate de tener el valor de ID de remitente de cada remitente. Cuando solicita un registro, la app cliente recupera el token varias veces, cada vez con un ID de remitente diferente en el campo de público, mediante el método de recuperación de tokens para la plataforma determinada:

Asegúrate de no agregar varios ID de remitente a una solicitud de token individual. De lo contrario, se pueden generar resultados impredecibles. Realiza cada llamada por separado, una vez por cada ID de remitente.

Por último, comparte el token de registro con los remitentes correspondientes para que puedan enviar mensajes a la app cliente con sus propias claves de autenticación.

Ten en cuenta que hay un límite de 100 remitentes múltiples.

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 donde 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 mensaje finalmente se agota y se descarta del almacenamiento de FCM. El tiempo de espera predeterminado es 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:

  • En iOS y Android: Consulta el panel de informes de FCM, en el que se registra la cantidad de mensajes enviados y abiertos en dispositivos iOS y Android, junto con los datos de las “impresiones” (notificaciones vistas por los usuarios) en apps para Android.
  • En Android: Si deseas recibir una notificación cuando la aplicación reciba un mensaje correctamente, puedes usar la función delivery_receipt_requested según estos lineamientos. Para ello, debes configurar un servidor XMPP.

En el caso de los dispositivos Android y los dispositivos iOS que tienen habilitado el canal directo, si el dispositivo no se conecta a FCM por 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.

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

Puedes enviar un máximo de 240 mensajes por minuto y 5,000 mensajes por hora a un dispositivo único. El propósito de este límite alto es permitir que se produzcan picos 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.

Límite de mensajes ascendentes

El límite de los mensajes ascendentes es de 15,000 por minuto y por proyecto, y su fin es 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 de Firebase console.

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 5229 y 5230.

Para las conexiones salientes, FCM no proporciona IP específicas, ya que nuestro rango de IP cambia con demasiada frecuencia, y las reglas de tu firewall pueden quedar desactualizadas y afectar la experiencia de los usuarios. Lo ideal es incluir en la lista blanca los puertos entre 5228 y 5230 sin restricciones de IP. Sin embargo, si necesitas implementar una restricción de IP, debes incluir en la lista blanca todas las direcciones IP de los bloques IPv4 e IPv6 que se indican en el ASN de 15169 de Google. Esta es una lista extensa; debes planear una actualización mensual de tus reglas. A menudo, los problemas causados por las restricciones de IP del firewall son intermitentes y difíciles de diagnosticar.

Puertos que se deben abrir para los mensajes entrantes:

  • 5228
  • 5229
  • 5230

Puertos para permitir conexiones salientes:

Uno de los siguientes (se prefiere la opción n.º 1):

  1. Sin restricciones de IP.
  2. Todas las direcciones IP contenidas en los bloques IP indicados en el ASN de 15169 de Google. No olvides actualizar esta lista al menos una vez al mes.

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 Autorizar 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, iOS y del navegador.