GCM推送通知中设备识别机制及相关技术疑问解析

Great question! Let’s break down how GCM (Google Cloud Messaging, now integrated into Firebase Cloud Messaging or FCM) identifies devices and manages the persistent connections that make push notifications work—since you’re right that IP addresses aren’t reliable for this use case.

Core Device Identifier: Registration Tokens #

Instead of relying on IP addresses (which are dynamic, change with network switches, and often hidden behind NAT) or MAC addresses (limited to local networks and with privacy concerns), GCM uses registration tokens as the primary way to uniquely identify devices. Here’s how the registration process works:

• When your app first launches on a device, the GCM SDK sends a registration request to Google’s push servers. This request includes metadata like your app’s package name, device-specific hardware context (not used as the main ID), and authentication credentials tied to your GCM project.
• Google’s servers generate a unique, cryptographically signed registration token for that specific app-device pair. This token is tied to both your app and the device, so it won’t conflict with tokens from other apps on the same device.
• The device sends this token to your backend server, where you’ll store it alongside any user/device context you need (like a user ID). This is the key your backend will use when it wants to send a push notification to that device.

The Persistent TCP Connection Mechanism #

You’re correct that GCM relies on long-lived TCP sockets to deliver notifications. Here’s the step-by-step breakdown:

• After registration, the GCM SDK on the device establishes a persistent TCP connection with Google’s push servers. This connection stays open even when the app is in the background (Android uses optimized wake locks and network handling to keep it alive without excessive battery drain).
• Google’s servers maintain a mapping between each registration token and the active TCP connection for that device. This is critical because IP addresses can change (e.g., when a user switches from Wi-Fi to cellular), but the registration token remains constant.
• When your backend wants to send a notification, it sends a request to GCM’s API that includes the target registration token(s) and the notification content.
• GCM’s servers look up the registration token in their mapping to find the corresponding active TCP connection, then deliver the notification directly over that socket to the device.

Why IP Addresses Aren’t Enough for Push #

You hit on a key point: IP addresses work great for client-initiated requests (like your device loading a webpage), but they’re terrible for server-initiated push because:

• Most mobile devices are behind NAT (Network Address Translation), which means their internal IP isn’t accessible from the public internet. Google’s servers can’t just send a request to a device’s IP address because they can’t reach it directly.
• IP addresses are dynamic. Mobile devices get new IPs every time they connect to a new network, so even if you could use an IP, it would be outdated within hours (or minutes) for many users.

Wrapping up: The combination of registration tokens (to uniquely identify app-device pairs) and persistent TCP connections (to maintain a reliable channel for server-to-device communication) solves the problem of delivering push notifications to devices that don’t have stable, publicly accessible IP addresses.

内容的提问来源于stack exchange，提问作者Manish Kumar Sharma