App message push services work through a communication framework that connects app servers with clients to deliver messages reliably and efficiently, especially on mobile networks where devices are often asleep or have limited connectivity. Here’s an overview of how these services typically work:
- Registration and Authentication: When a user installs an app integrated with a push service, the app registers with the push notification vendor’s server (such as Jiguang Push or Umeng). This registration usually provides a unique token for that device, which the app server uses to send notifications specifically to that user.
- Persistent Connection with Push Servers: For timely delivery, the client device establishes a persistent, sometimes UDP-based connection with the vendor’s push server. To conserve battery, push services often use low-power UDP packets that can maintain this connection even when the app is not actively running. These UDP packets allow the server to “wake up” the device when a message arrives, ensuring real-time communication.
- Message Routing: When an app server needs to send a message, it communicates with the push notification vendor’s server and provides the target device’s unique token. The vendor then routes the message to the correct device, which receives it via the open, persistent connection.
- Delivery and Notification Handling: Once received, the notification is displayed according to the device’s settings or app-specific preferences. The client app may also retrieve additional information, like images or links, from the server.
These services use UDP packets to keep connections alive, as they’re lightweight and help conserve mobile data and battery life, especially in conditions where maintaining a stable connection with TCP would be less efficient. Vendors like Jiguang Push and Umeng often use proprietary protocols built on top of UDP to optimize this type of background messaging traffic, ensuring users receive timely notifications without draining resources.
Push notification systems rely on a dedicated process, often a background daemon or service, that listens for incoming connections on the device. Here’s how this mechanism generally works:
- Persistent Connection with a Push Daemon: A push notification daemon (like Google’s Firebase Cloud Messaging on Android) runs on the device and maintains a persistent connection with the push server. This daemon typically uses a predefined, vendor-specific port that allows it to remain ready for incoming notifications. When the device first establishes this connection, it will open a port (often dynamically assigned but standardized in the app stack) and maintain a heartbeat with the server.
- Device Identifier and Registration Token: When the app registers with the vendor’s server, it provides a unique identifier (token) specific to the device and app instance. The server stores this mapping so that when a message needs to be sent to the user, it can look up the correct token to target the device.
- Routing and Addressing the Device: The push server uses the device’s registered token to identify the connection path. By having an open and persistent connection maintained via the push daemon, the server doesn’t need to locate the device afresh; it can simply route the message down the already established path.
- Listening on a Specific UDP or TCP Port: While some platforms use TCP, many push services favor UDP for keeping the connection alive. Although the specific port varies by vendor, push services keep this connection stable, allowing notifications to bypass network restrictions, save battery, and ensure reliability.
This is why your phone might frequently show UDP packets related to push traffic—these keep-alive packets refresh the connection so that the server always knows where to find the device when a push notification arrives.
Wi-Fi with NAT and IPv4-only networks present unique challenges that push services must work around. Here’s how push services typically overcome these obstacles:
- Outbound-Only Connection and NAT Traversal: The smartphone’s push daemon initiates an outbound connection to the push server, typically over UDP or TCP. Firewalls generally allow outbound connections, and once established, they often allow responses from the server to come back through the same path. Since the connection is initiated from within the NAT, the router automatically creates a temporary mapping, enabling packets from the server to reach the device.
- Long-Lived Connections and Keep-Alives: The push daemon sends small, periodic keep-alive packets to the server to keep the connection open through the NAT. This ensures that the device’s IP and port mapping stay active on the router, preventing the NAT from closing the path due to inactivity. Keep-alives can be as infrequent as once every few minutes to reduce battery and bandwidth usage.
- Relaying via Vendor Servers if Needed: If NAT traversal fails or the connection times out, push vendors often implement additional techniques. For instance, Google’s Firebase or Apple Push Notification Service (APNs) sometimes fall back on server-based relays to reconnect the device. These mechanisms create a connection again if the original path closes, ensuring that the device eventually receives notifications.
In short, by maintaining these outbound connections with periodic keep-alives, the push service can consistently reach the device, even in complex NAT or firewall setups without IPv6, as long as the outbound path was originally established by the device.
For Google Firebase Cloud Messaging (FCM), in addition to NAT traversal and keep-alive packets, there are a few other sophisticated techniques used to maintain reliable connections for push notifications, especially in restrictive network environments:
- HTTP/2 Fallback: When a persistent connection over UDP or TCP isn’t feasible (due to a restrictive firewall, for example), FCM can fall back to using HTTP/2. HTTP/2 is well-suited for this because it allows multiplexed streams over a single connection, reducing the need to open new connections for each notification. Although it’s not as battery-efficient as a persistent UDP connection, HTTP/2 fallback ensures message delivery through most firewalls.
- Automatic Reconnection Logic: If a connection drops (e.g., due to NAT timeout or network change), FCM’s client library on the device automatically tries to re-establish it. This reconnection attempts to avoid heavy battery usage by gradually increasing the interval between retries, commonly known as “exponential backoff,” until the connection stabilizes.
- Adaptive Heartbeat Intervals: FCM uses adaptive keep-alive intervals based on network conditions to reduce unnecessary traffic while keeping the connection open. On stable Wi-Fi, heartbeats might be less frequent, while on cellular networks, they may be more frequent to adapt to the stricter NAT requirements on mobile networks. This adaptive interval helps keep connections alive without excessive battery drain.
- Network Path Dependency Management: FCM monitors when the device switches between Wi-Fi and mobile networks, adjusting the connection path accordingly. For instance, if a Wi-Fi connection fails, FCM will seamlessly switch to a mobile data connection if available, ensuring that notifications continue to flow without user intervention.
- Batching Notifications: To save battery and data usage, FCM sometimes batches multiple notifications, sending them together in a single packet instead of as individual messages. This is particularly helpful on restricted networks where frequent reconnections are not ideal.
These techniques ensure FCM is robust in delivering push notifications, even on IPv4-only or NAT-constrained networks. However, in rare cases where the network is extremely restrictive, notifications might experience a delay until a connection can be re-established.
