Yes. Each browser vendor runs a push notification backend, where browsers automatically connect to. Each end user browser instance has a unique identifier with that push backend.
As a matter of fact, Mozilla's backend is even open source and written in rust:
EDIT: And to send push notifications to an end user as a service provider, you (in simple terms) receive an encoded version of that URI from the push service, along with an authentication token that authorizes you to send notifications to the push service, which will be forwarded to the user that corresponds to the URI.
You can look at your registered service workers by going to about:debugging#/runtime/this-firefox You'll see the ones that can do push give you the URL, something like updates.push.services.mozilla.com/wpush/v2/...
I haven't looked into this at all, but for desktop I would expect the browser to maintain a WebSocket connection (for all websites) to the browser vendor's "push server", if WebSockets doesn't work for some reason, then it can fall back to long polling.
For mobile devices it's discouraged to maintain your own TCP connections for power usage reasons. So I would expect browser developers to have their mobile browsers use the mobile's native push service (e.g. for Android or iOS) to register for pushes, then the browser's backend push service sends push notifications via Apple/Google's push servers which in turn send it to mobile devices themselves.
As a matter of fact, Mozilla's backend is even open source and written in rust:
https://github.com/mozilla-services/autopush-rs/
EDIT: And to send push notifications to an end user as a service provider, you (in simple terms) receive an encoded version of that URI from the push service, along with an authentication token that authorizes you to send notifications to the push service, which will be forwarded to the user that corresponds to the URI.