Comment les services de messagerie cloud atteignent-ils les appareils derrière NAT / pare-feu?

Obtenir des notifications push avec des appareils avec une adresse IP locale fonctionne très bien. Je me demande simplement comment cela fonctionne. Est-ce juste uPnP? L'appareil commence la communication avec le service de messagerie cloud, puis IGD intervient? Le mappage reste donc Le client de notification push maintient-il une connexion constante au serveur cloud? J'aimerais penser que ce n'est pas le cas.

Je suis particulièrement intéressé par la façon dont la notification push sait comment atteindre l'appareil étant donné qu'elle se trouve derrière un NAT ou un pare-feu. Existe-t-il un scénario dans lequel les notifications push de Google ne pourraient pas atteindre un appareil?

Comme vous pouvez l'imaginer, Google est assez silencieux en ce qui concerne ses détails de mise en œuvre. Je vais donc simplement décrire cela dans le cas général et sous une forme très basique.

La façon dont le push est fait est que le client (c'est-à-dire le téléphone) ouvre une connexion TCP au serveur de messagerie (par exemple Google). Cette connexion est censée rester ouverte aussi longtemps que le téléphone est allumé. Heureusement, une connexion TCP n'utilise absolument aucune bande passante lorsqu'elle ne transmet rien, elle ne gaspille donc pas beaucoup de données, l'émetteur radio peut s'éteindre, etc.

La connexion peut rester ouverte indéfiniment, mais derrière un NAT, l'infrastructure NAT conserve une table des connexions ouvertes qu'elle gère et supprime les connexions qui sont inactives depuis un certain temps, généralement 10 à 15 minutes. Aucune des deux extrémités n'en reçoit notification. Donc, cela est géré en envoyant un paquet TCP keep-alive qui rafraîchit l'entrée dans la table de connexion NAT de l'opérateur. Cela ne coûte qu'environ 50 octets et ne doit être effectué que toutes les quelques minutes.