Wouldn't this be easier to maintain a websocket/socket.io type of connection with the web page? And just push new events from the server to the page directly?
It would open up a powerful new avenue for tracking users if every browser maintained a permanent, identifiable TCP connection, even when the page was closed, and kept it up as the user moves between wifi and mobile data.
Is there a meaningful difference between waking up the CPU from sleep to maintain a single tcp connection vs waking it up to maintain 50? Provided of course all 50 require a keepalive packet at the same time, I don't think so. But feel free to correct me.
Yes, because the single connection to the push server is hard optimized to stay alive regardless of NAT etc. Cellular carriers have special handling for APNS and GCM, for example. (And I assume there's some kernel & firmware hacks in devices to further offload some handling of APNS/GCM protocol)
Not off the top of my head, but I remember the iPhone in its early years required specific carrier support because of that permanent APNS connection. Can't find a source for this now but I remember that being one of the reasons that iPhone 2G/3G/3GS wouldn't work (well) on other carriers even after SIM unlocking.
I assume nowadays it's more to do with GCNAT pruning connections to APNS/GCM less heavily than other "regular" connections (which is doable given that APNS has specific ports[1]), or cell carriers having different routing & handling for push notifications IPs, but that's just speculation.
Here’s the page about browser support. https://github.com/web-push-libs/web-push/tree/master#browse...