webpush 如何在 TCP/IP 网络层工作

Posted 2023-02-16

【中文标题】webpush 如何在 TCP/IP 网络层工作

【英文标题】：How webpush work in TCP/IP network layers

【发布时间】：2020-11-28 11:58:10

【问题描述】：

请向我解释 webpush 如何在 TCP/IP 网络层（尤其是第 4-5 层）中工作。

我了解 HTTP 是无状态协议：

协议正在打开 TCP/4 层连接， 'state' 与 cookie/session 一起使用， 然后客户端发送HTTP请求（明文/压缩“HTTP/1.1 /url/here ... Content-Length: ...”）， 然后服务器响应 HTTP 请求（明文/压缩“200 OK ... ...”），

因此，NAT 后面的用户能够查看远程主机的网页是可以理解的（因为 NAT 后面的用户是发起连接的人）；但网络服务器无法启动与客户端的 TCP 连接（浏览器进程）。

但是，有一些例外情况，例如“websocket”，客户端（浏览器）启动连接，然后将其保持打开状态（仅提升到 TCP，不再是 HTTP）。在此架构中，网络服务器可以向客户端发送/发起发送消息（例如“您有新的聊天消息”通知）。

我不明白的是新术语“webpush”。

我观察到它可以将通知从服务器发送到客户端/浏览器（从用户那里，它“感觉”就像是服务器是发起连接的那个） webpush 可以随时发送通知，即使浏览器已关闭/尚未打开（例如刚刚打开设备时），或者刚刚连接到互联网时

它是如何工作的？他们如何做到这一点？以前我认为：

页面中的 javascript 会持续（例如：5 秒间隔）检查服务器中是否有新通知， 或 javascript 启动 websocket（浏览器启动/打开 TCP 连接）并使其保持活动状态，当服务器需要发送某些内容时，它会通过此连接从 web 服务器发送到客户端/浏览器

这是正确的吗？还是我错过了什么？由于我上面的两个猜测在 NAT'd 网络后面都不起作用

Firebase 网络通知也是这种网络推送吗？

我已经在互联网上搜索了关于它在客户端工作的解释，但似乎只有关于“如何发送 webpush”、“如何使用 webpush 营销您的产品”的解释，这些文章只解释了服务器端（应用服务器与推送服务服务器的通信）或有关营销的文章。

另外，如果不是 HTTP，我有兴趣了解它们正在运行的应用层协议（如客户端/服务器相互发送的文本/二进制数据）

【参考方案1】：

Web Push 之所以有效，是因为浏览器（例如 Chrome）和浏览器推送服务（例如 FCM）之间存在持久连接。

当您的应用服务器需要向浏览器发送通知时，它无法通过连接直接访问浏览器，而是联系浏览器推送服务（例如 Chrome 的 FCM），然后由浏览器推送服务发送通知到用户浏览器。

这是可能的，因为浏览器不断尝试与服务器保持开放连接（例如 Chrome 的 FCM）。这意味着 NAT 没有任何问题，因为启动连接的是客户端。还要考虑任何 TCP 连接都是双向的：因此连接的任何一侧都可以随时开始发送数据。不要将 HTTP 等高级协议与普通 TCP 连接混淆。

如果您想了解更多详细信息，我已经写了this article，它用简单的语言解释了 Web Push 的工作原理。您还可以阅读标准：特别是Push API 和IETF Web Push。

注意：Firebase (FCM) 是两个不同的东西，即使文档中并不清楚这一点。它既是向 Chrome 发送通知所需的浏览器推送服务（如 Firefox 的 Mozilla autopush、Edge 的 Windows 推送通知服务和 Safari 的 Apple 推送通知服务），但它也是一项专有服务，具有向任何人发送通知的附加功能浏览器（如 Pushpad、Onesignal 等）。

【讨论】：

因此客户端/用户代理/浏览器（例如：chrome）保持打开的 TCP 连接到推送服务（例如：FCM）；并且连接永远保持活跃？并且浏览器在没有明确执行的情况下执行此操作（例如：用户单击 chrome 图标）？

是的，浏览器和自己的推送服务之间通常存在持久连接。如果在特定操作系统上无法做到这一点（例如，在后台），则使用另一种方法：例如，推送消息从浏览器推送服务转发到操作系统的正常推送服务（例如，这是由 Firefox 完成的在安卓上）。如果您需要确切的实施细节，您需要阅读我上面链接的标准。