Firebase Cloud Messaging (FCM) ofrece una amplia gama de opciones y capacidades de mensajería. La información de esta página tiene como objetivo ayudarle a comprender los diferentes tipos de mensajes FCM y lo que puede hacer con ellos.
Tipos de mensajes
Con FCM, puedes enviar dos tipos de mensajes a los clientes:
- Mensajes de notificación, a veces considerados "mensajes para mostrar". Estos son manejados automáticamente por el SDK de FCM.
- 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 los 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 4000 bytes, excepto cuando se envían mensajes desde Firebase console, que impone un límite de 1000 caracteres.
| Escenario de uso | Cómo enviar | |
|---|---|---|
| Mensaje de notificación | FCM SDK muestra el mensaje a los dispositivos de los usuarios finales en nombre de la aplicación cliente cuando se ejecuta en segundo plano. De lo contrario, si la aplicación se está ejecutando en primer plano cuando se recibe la notificación, el código de la aplicación 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. |
|
| mensaje de datos | La aplicación 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 confiable como Cloud Functions o su servidor de aplicaciones, use el SDK de administración o los protocolos del servidor FCM . En la solicitud de envío, establezca la clave data . |
Utilice mensajes de notificación cuando desee que el SDK de FCM se encargue de mostrar una notificación automáticamente cuando su aplicación se esté ejecutando en segundo plano. Utilice mensajes de datos cuando desee procesar los mensajes con su propio código de aplicación 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 útil de notificación y la aplicación cliente maneja la carga útil de datos.
Mensajes de notificación
Para realizar pruebas o para marketing y volver a involucrar al usuario, puede enviar mensajes de notificación mediante Firebase console . Firebase console proporciona pruebas A/B basadas en análisis para ayudarte a refinar y mejorar los mensajes de marketing.
Para enviar mensajes de notificación mediante programación mediante el SDK de administración o los protocolos FCM, configure la clave notification con el conjunto predefinido necesario de opciones clave-valor para la parte visible para el 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 se manejan mediante una función de devolución de llamada.
Consulte la documentación de referencia del objeto de notificación del protocolo HTTP v1 para obtener la lista completa de claves predefinidas disponibles para crear mensajes de notificación.
Mensajes de datos
Configure la clave adecuada con sus pares clave-valor personalizados para enviar una carga útil 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 el anterior, donde la información está encapsulada en la clave data común y se espera que la aplicación 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 es interpretado por los clientes en todas las plataformas que reciben el mensaje. En cada plataforma, la aplicación cliente recibe la carga útil de datos en una función de devolución de llamada.
Cifrado de mensajes de datos.
La capa de transporte de Android (consulte la arquitectura FCM ) utiliza cifrado 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 un extremo a otro. Sin embargo, existen soluciones externas disponibles como Capillary o DTLS .
Mensajes de notificación con carga útil de datos opcional
Tanto mediante programación como a través de Firebase console, puedes 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 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; esencialmente, si está activa o no en el momento de la recepción.
- Cuando están en segundo plano , las aplicaciones reciben la carga de notificación en la bandeja de notificaciones y solo manejan la carga 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 disponibles.
A continuación se muestra un mensaje con formato JSON que 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"
}
}
}Personalizar un mensaje entre plataformas
El SDK de Firebase Admin y el protocolo HTTP FCM v1 permiten que sus solicitudes de mensajes establezcan todos los campos disponibles en el objeto message . Esto incluye:
- un conjunto común de campos que serán interpretados por todas las instancias de la aplicación que reciben el mensaje.
- conjuntos de campos específicos de la plataforma, como
AndroidConfigyWebpushConfig, interpretados solo por instancias de aplicaciones que se ejecutan en la plataforma especificada.
Los bloques específicos de la plataforma le brindan flexibilidad para personalizar 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 utilizar campos comunes
Utilice campos comunes cuando esté:
- Orientación a instancias de aplicaciones en todas las plataformas: Apple, Android y web
- Enviar mensajes a temas
Todas las instancias de aplicaciones, independientemente de la plataforma, pueden interpretar los siguientes campos comunes:
Cuándo utilizar campos específicos de la plataforma
Utilice campos específicos de la plataforma cuando desee:
- Enviar campos solo a plataformas particulares
- Enviar campos específicos de la plataforma además de los campos comunes
Siempre que desee enviar valores sólo a plataformas particulares, no utilice campos comunes; Utilice campos específicos de la plataforma. Por ejemplo, para enviar una notificación solo a las plataformas web y de Apple, pero no a Android, debe utilizar dos conjuntos de campos separados, uno para Apple y otro para la web.
Cuando envíe mensajes con opciones de entrega específicas, utilice campos específicos de la plataforma para configurarlas. Puede especificar diferentes valores por plataforma si lo desea. Sin embargo, incluso cuando desee establecer esencialmente el mismo valor en todas las plataformas, debe utilizar campos específicos de la plataforma. Esto se debe a que cada plataforma puede interpretar el valor de manera ligeramente diferente; por ejemplo, el tiempo de vida se establece en Android como un tiempo de vencimiento en segundos, mientras que en Apple se establece 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 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 largo tiempo de vida para las plataformas Android y Web, mientras establece la prioridad de mensajes de APN (plataformas Apple) en una configuración baja
- establece las claves apropiadas para definir el resultado de un toque de usuario en la notificación en Android y Apple:
click_actionycategory, 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 bloques específicos de la plataforma en el cuerpo del mensaje. Para obtener más información sobre cómo crear solicitudes de envío que contienen el cuerpo del mensaje, consulte Crear solicitudes de envío .
Opciones de entrega
FCM proporciona un conjunto específico de opciones de entrega para mensajes enviados a dispositivos Android y permite opciones similares en plataformas y web de Apple. Por ejemplo, el comportamiento de mensajes "contraíbles" se admite en Android a través collapse_key de FCM, en Apple a través de apns-collapse-id y 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 no plegables y 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 y recuperar datos.
Algunos casos de uso típicos de mensajes no plegables son mensajes de chat o mensajes críticos. Por ejemplo, en una aplicación de mensajería instantánea, querrás entregar cada mensaje, 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, se descartan todos los mensajes almacenados. 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 adecuadamente, generalmente solicitando una sincronización completa al servidor de la aplicación.
Un mensaje plegable 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 mensajes plegables son los mensajes que se utilizan para indicarle a una aplicación móvil que sincronice datos del servidor. Un ejemplo sería una aplicación de deportes que actualiza a los usuarios con la puntuación más reciente. Sólo 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 para contraer 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 colapso, sin garantías sobre cuáles se conservarán.
Los mensajes de tema sin carga útil se pueden contraer de forma predeterminada. Los mensajes de notificación siempre son plegables e ignorarán el parámetro 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 utiliza mensajes plegables, recuerde que FCM solo permite que FCM utilice un máximo de cuatro claves de colapso diferentes por token de registro en un momento dado. No debes 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 relacionado más antiguo sea irrelevante para la aplicación cliente, FCM reemplaza el mensaje más antiguo. Por ejemplo: mensajes utilizados para iniciar una sincronización de datos desde el servidor o mensajes de notificación desactualizados. | Establezca el parámetro apropiado en su solicitud de mensaje:
|
Establecer la prioridad de un mensaje
Tiene dos opciones para asignar prioridad de entrega a mensajes posteriores: prioridad normal y alta. Aunque el comportamiento difiere ligeramente entre plataformas, la entrega de mensajes normales y de alta prioridad 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 urgentes, como notificaciones de nuevos correos electrónicos, mantener sincronizada la interfaz de usuario 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 visible para el usuario y urgente.
A continuación se muestra 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 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 específicos de la plataforma sobre cómo configurar la prioridad de los mensajes:
- Documentación de APN
- Establecer y administrar la prioridad de los mensajes (Android)
- Urgencia de mensajes push web
Establecer la vida útil de un mensaje
FCM suele entregar los mensajes inmediatamente después de su envío. Sin embargo, es posible que esto no siempre sea 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 cuales 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 vídeo, será significativo sólo 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 tienen por defecto un período máximo de cuatro semanas.
A continuación se muestran algunos usos posibles de esta característica:
- Llamadas entrantes de video chat
- Eventos de invitación vencidos
- Eventos del calendario
Otra ventaja de especificar la vida útil de un mensaje es que FCM no aplica limitación de mensajes plegables a mensajes con un valor de tiempo de vida de 0 segundos. FCM proporciona el mejor manejo de 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 inmediatamente se descartan. Sin embargo, como dichos 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 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 haya entregado al dispositivo. Más bien significa que fue aceptado para su entrega. Lo que sucede con el mensaje una vez aceptado 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 entrega de inmediato.
Si el dispositivo está conectado pero en Doze, FCM almacena un mensaje de baja prioridad hasta que el dispositivo salga de Doze. Y ahí es donde el indicador collapse_key juega un papel: si ya hay un mensaje con la misma clave de colapso (y token de registro) almacenado y esperando ser entregado, el mensaje antiguo se descarta y el nuevo mensaje ocupa su lugar (es decir, el mensaje antiguo). el mensaje está colapsado por el nuevo). Sin embargo, si no se establece la clave para contraer, tanto los mensajes nuevos como los antiguos se almacenan para su entrega futura.
Si el dispositivo no está conectado a FCM, el mensaje se almacena hasta que se establezca una conexión (nuevamente respetando las reglas de la clave de colapso). 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ó la configuración de fábrica), el mensaje eventualmente caduca 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 inmediatamente. 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 adecuadamente, generalmente solicitando una sincronización completa al servidor de la aplicación.
Finalmente, cuando FCM intenta enviar un mensaje al dispositivo y la aplicación se desinstaló, FCM descarta ese mensaje de inmediato e invalida el token de registro. Los intentos futuros de enviar un mensaje a ese dispositivo dan como resultado un error NotRegistered .
Estrangulamiento y escalado
Nuestro objetivo es entregar siempre todos los mensajes enviados a través de FCM. Sin embargo, entregar todos los mensajes a veces resulta en una mala experiencia general del usuario. En otros casos, debemos establecer límites para garantizar que FCM proporcione un servicio escalable para todos los remitentes.
Limitación de mensajes plegables
Como se describió anteriormente, los mensajes plegables son notificaciones sin contenido diseñadas para colapsar unas encima de otras. En el caso de que un desarrollador repita el mismo mensaje en una aplicación con demasiada frecuencia, retrasamos (regulamos) 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, podríamos 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. Esta limitación 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 ráfagas altas, entonces los mensajes no plegables pueden ser la opción correcta. Para dichos mensajes, asegúrese de incluir el contenido de dichos mensajes para reducir el costo de la batería.
Limitamos los mensajes plegables a una ráfaga de 20 mensajes por aplicación y por dispositivo, con una recarga de 1 mensaje cada 3 minutos.
Aceleración del servidor XMPP
Limitamos la velocidad a la que puede conectarse a 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 del sistema. Para cada proyecto, FCM permite 2500 conexiones en paralelo.
Para la mensajería ascendente con XMPP, FCM limita los mensajes ascendentes a 1.500.000/minuto por proyecto para evitar la sobrecarga de los servidores de destino ascendentes.
Limitamos los mensajes ascendentes por dispositivo a 1000/minuto para proteger contra el consumo de batería debido al mal comportamiento de la aplicación.
Tasa máxima de mensajes a un solo dispositivo
Para Android, puedes enviar hasta 240 mensajes/minuto y 5000 mensajes/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 el envío de la lógica agoten inadvertidamente la batería de un dispositivo.
Para iOS, devolvemos un error cuando la tasa excede los límites de APN.
Límite de mensajes de tema
La tasa de agregar/eliminar 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 distribución
La distribución de mensajes es el proceso de enviar un mensaje a múltiples 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, por lo que ocasionalmente hay varias distribuciones en curso al mismo tiempo. Limitamos el número de distribución 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 que ya están en progreso.
La tasa de distribución real alcanzable está influenciada por la cantidad de proyectos que solicitan distribución al mismo tiempo. Una tasa de distribución de 10 000 QPS para un proyecto individual no es infrecuente, pero ese número no es una garantía y es el resultado de la carga total del 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 progreso, cada una de ellas 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 progreso 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 de 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 IP específicas porque nuestro rango de IP cambia con demasiada frecuencia y sus reglas de firewall podrían quedar obsoletas, lo que afectaría la experiencia de sus usuarios. Lo ideal es incluir 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 permitida todas las direcciones IP enumeradas en goog.json . Esta gran lista se actualiza periódicamente y se recomienda actualizar 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 blanca 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 funcionar o no 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
- dispositivo-provisioning.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 traducción de direcciones de red (NAT) o 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 conectividad confiable y al mismo tiempo reducir el consumo de batería de los dispositivos móviles de sus usuarios.
Interacciones VPN y capacidad de omisión
Firebase Cloud Messaging toma varias medidas para garantizar que la conexión de mensajería push desde el teléfono al servidor sea confiable y esté disponible con la mayor frecuencia posible. El uso de una VPN complica este esfuerzo.
Las VPN enmascaran la información subyacente que FCM necesita para ajustar su conexión y maximizar la confiabilidad y la duración de la batería. En algunos casos, las VPN interrumpen activamente conexiones de larga duración, lo que genera una mala experiencia de usuario debido a mensajes perdidos o retrasados o un alto costo de la batería. Cuando la VPN está configurada para permitirnos hacerlo, la omitimos utilizando una conexión cifrada (a través de la red base wifi o LTE) para garantizar una experiencia confiable y sin batería. El uso de VPN que se pueden omitir por parte de FCM es específico del canal de notificaciones push de FCM. Otro tráfico FCM, como el tráfico de registro, utiliza la VPN si está activa. Cuando la conexión FCM omite la VPN, pierde beneficios adicionales que la VPN puede proporcionar, como el enmascaramiento de IP.
Diferentes VPN tendrán diferentes métodos para controlar si se puede omitir o no. Consulte la documentación de su VPN específica para obtener instrucciones.
Si la VPN no está configurada para que se pueda omitir, Firebase Cloud Messaging utilizará la red VPN para conectarse al servidor. Esto puede provocar períodos de tiempo en los que los mensajes se retrasan y puede provocar un mayor uso de la batería, ya que Cloud Messaging trabaja para mantener la conexión a través de la conexión VPN.
Cartas credenciales
Dependiendo de 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 utiliza en solicitudes al punto final HTTP de FCM v1. Este valor está disponible en el panel de configuración de Firebase console . |
| token 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 creas tu proyecto de Firebase, disponible en la pestaña Mensajería en la nube del panel Configuración de Firebase console. El ID del remitente se utiliza 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 el envío de solicitudes . |
| Clave de servidor (para protocolos heredados **obsoletos**) | 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 obsoletos de Firebase Cloud Messaging. Importante: No incluya la clave del servidor en ninguna parte de su código de cliente. Además, asegúrese de utilizar únicamente claves de servidor para autorizar su servidor de aplicaciones. FCM rechaza las claves de Android, plataforma Apple y navegador. |