webpush 如何在 TCP/IP 个网络层中工作
How webpush work in TCP/IP network layers
请向我解释一下 webpush 在 TCP/IP 网络层（尤其是第 4-5 层）是如何工作的。
我了解 HTTP 是无状态协议：
- 协议正在打开 TCP/第 4 层连接，
- 'state' 是 'made to work' 和 cookie/session,
- 然后客户端发送 HTTP 请求 (plaintext/compressed "HTTP/1.1 /url/here ... Content-Length: ..."),
- 然后服务器响应 HTTP 请求（plaintext/compressed“200 OK ... ...”），
因此，NAT 后的用户能够查看远程主机的网页是可以理解的（因为 NAT 后的用户是发起连接的用户）；但网络服务器无法启动与客户端（浏览器进程）的 TCP 连接。
但是也有一些例外情况，例如 'websocket' 客户端（浏览器）启动连接，然后保持打开状态（提升到仅 TCP，不再是 HTTP）。在此架构中，网络服务器可以向客户端发送/发起发送消息（例如“您有新的聊天消息”通知）。
我不明白的是新名词'webpush'。
- 我观察到它可以从服务器发送通知到 client/browser（从用户，它 'feels' 就像服务器是发起连接的那个）
- webpush 可以随时发送通知，即使浏览器关闭/尚未打开（如设备刚打开时），或刚连接到互联网时也是如此
它是如何工作的？他们如何做到这一点？以前我认为：
- 页面中的 javascript 连续（例如：5 秒间隔）检查服务器中是否有新通知，
- 或 javascript 启动一个 websocket（浏览器 initiate/open TCP 连接）并保持活动状态，当服务器需要发送某些内容时，它会通过此连接从网络服务器发送到 client/browser
这是正确的吗？或者我错过了什么？因为我上面的两个猜测在 NAT 网络后都不起作用
Firebase web通知也是这种webpush吗？
我已经在互联网上搜索了关于它在客户端工作的原因的解释，但似乎只有 'how to send webpush'、'how to market your product with webpush' 的解释，这些文章只解释了服务器端（应用程序的通信服务器与推送服务服务器）或有关营销的文章。
此外，我有兴趣了解它们 运行 使用的是什么应用层协议（例如 client/server 相互发送的 text/binary 数据），如果它是不是 HTTP
Web 推送之所以有效，是因为浏览器（例如 Chrome）和浏览器推送服务（例如 FCM）之间存在持久连接。
当您的应用服务器需要向浏览器发送通知时，它无法通过连接直接到达浏览器，而是联系浏览器推送服务（例如 Chrome 的 FCM），然后是浏览器向用户浏览器发送通知的推送服务。
这是可能的，因为浏览器不断尝试与服务器保持打开的连接（例如 Chrome 的 FCM）。这意味着 NAT 没有任何问题，因为它是客户端启动连接。还要考虑任何 TCP 连接都是双向的：因此连接的任何一方都可以随时开始发送数据。不要将 HTTP 等更高级别的协议与普通的 TCP 连接混淆。
如果你想要更多细节，我已经写了 this article that explains in simple words how Web Push works. You can also read the standards: Push API and IETF Web Push。
注意：Firebase (FCM) 是两个不同的东西，即使从文档中看不清楚。它既是向 Chrome 发送通知所需的浏览器推送服务（如 Firefox 的 Mozilla autopush，Edge 的 Windows 推送通知服务和 Safari 的 Apple 推送通知服务），但它也是专有服务具有向任何浏览器（如 Pushpad、Onesignal 等）发送通知的附加功能。
请向我解释一下 webpush 在 TCP/IP 网络层（尤其是第 4-5 层）是如何工作的。
我了解 HTTP 是无状态协议：
- 协议正在打开 TCP/第 4 层连接，
- 'state' 是 'made to work' 和 cookie/session,
- 然后客户端发送 HTTP 请求 (plaintext/compressed "HTTP/1.1 /url/here ... Content-Length: ..."),
- 然后服务器响应 HTTP 请求（plaintext/compressed“200 OK ... ...”），
因此，NAT 后的用户能够查看远程主机的网页是可以理解的（因为 NAT 后的用户是发起连接的用户）；但网络服务器无法启动与客户端（浏览器进程）的 TCP 连接。
但是也有一些例外情况，例如 'websocket' 客户端（浏览器）启动连接，然后保持打开状态（提升到仅 TCP，不再是 HTTP）。在此架构中，网络服务器可以向客户端发送/发起发送消息（例如“您有新的聊天消息”通知）。
我不明白的是新名词'webpush'。
- 我观察到它可以从服务器发送通知到 client/browser（从用户，它 'feels' 就像服务器是发起连接的那个）
- webpush 可以随时发送通知，即使浏览器关闭/尚未打开（如设备刚打开时），或刚连接到互联网时也是如此
它是如何工作的？他们如何做到这一点？以前我认为：
- 页面中的 javascript 连续（例如：5 秒间隔）检查服务器中是否有新通知，
- 或 javascript 启动一个 websocket（浏览器 initiate/open TCP 连接）并保持活动状态，当服务器需要发送某些内容时，它会通过此连接从网络服务器发送到 client/browser
这是正确的吗？或者我错过了什么？因为我上面的两个猜测在 NAT 网络后都不起作用
Firebase web通知也是这种webpush吗？
我已经在互联网上搜索了关于它在客户端工作的原因的解释，但似乎只有 'how to send webpush'、'how to market your product with webpush' 的解释，这些文章只解释了服务器端（应用程序的通信服务器与推送服务服务器）或有关营销的文章。
此外，我有兴趣了解它们 运行 使用的是什么应用层协议（例如 client/server 相互发送的 text/binary 数据），如果它是不是 HTTP
Web 推送之所以有效，是因为浏览器（例如 Chrome）和浏览器推送服务（例如 FCM）之间存在持久连接。
当您的应用服务器需要向浏览器发送通知时，它无法通过连接直接到达浏览器，而是联系浏览器推送服务（例如 Chrome 的 FCM），然后是浏览器向用户浏览器发送通知的推送服务。
这是可能的，因为浏览器不断尝试与服务器保持打开的连接（例如 Chrome 的 FCM）。这意味着 NAT 没有任何问题，因为它是客户端启动连接。还要考虑任何 TCP 连接都是双向的：因此连接的任何一方都可以随时开始发送数据。不要将 HTTP 等更高级别的协议与普通的 TCP 连接混淆。
如果你想要更多细节，我已经写了 this article that explains in simple words how Web Push works. You can also read the standards: Push API and IETF Web Push。
注意：Firebase (FCM) 是两个不同的东西，即使从文档中看不清楚。它既是向 Chrome 发送通知所需的浏览器推送服务（如 Firefox 的 Mozilla autopush，Edge 的 Windows 推送通知服务和 Safari 的 Apple 推送通知服务），但它也是专有服务具有向任何浏览器（如 Pushpad、Onesignal 等）发送通知的附加功能。