1. 简介
1. 简介
移动设备与嵌入式设备上的许多应用需要持续访问网络通信, 以便实时事件 (例如来电或消息) 能够及时被投递 (或 "推送"). 这些设备的电量通常有限, 因此找到更高效的方式来满足应用需求对整个应用生态大有裨益.
功耗的重要来源之一是无线电 (radio). 无线通信会消耗无线设备能量预算的很大一部分.
多个应用对持久连接或会话的不协调使用会导致设备无线电被不必要地使用, 因为每个独立会话都可能带来各自的开销. 特别是, 用于确保中间盒不会过早让会话超时的保活流量可能造成显著浪费. 长期来看, 维护流量往往占主导, 因为事件相对稀少.
将所有实时事件合并到单个会话中可确保更高效地使用网络与无线电资源. 单一服务汇总所有事件, 并在事件到达时分发给各应用. 这只需要一个会话, 可避免重复的开销.
W3C Push API [API] 描述了一种使 Web 应用能够使用汇总式推送服务 (consolidated push service) 的 API. 本文档在此基础上扩展, 描述可用于下列目的的协议:
-
请求将推送消息 (push message) 投递给用户代理 (user agent),
-
创建新的推送消息投递订阅 (subscription), 以及
-
监视新的推送消息.
标准化的事件投递方法对 W3C Push API 尤为重要, 因为应用服务器可能需要使用多个推送服务. 订阅、管理与监视功能目前由专有协议实现, 这些协议虽可接受, 但不具备标准化带来的任何优势.
本文档有意不描述如何发现推送服务. 若事实证明确有必要, 推送服务的发现留待未来工作. 预期用户代理会配置推送服务的 URL.
1.1. Conventions and Terminology (约定与术语)
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 以及 "OPTIONAL" 应按 [RFC2119] 所述解释.
本文档定义下列术语:
application (应用): 推送消息的发送方与最终消费者. 许多应用在用户代理上运行部分组件, 在服务器上运行其他组件.
application server (应用服务器): 应用通常在服务器上运行并请求投递推送消息的组件.
push message subscription (推送消息订阅): 在用户代理与推送服务 (push service) 之间建立、并与应用服务器共享的消息投递上下文. 所有推送消息都与某一推送消息订阅关联.
push message subscription set (推送消息订阅集合): 在用户代理与推送服务之间建立、将多个推送消息订阅收集为一个集合的消息投递上下文.
push message (推送消息): 由应用服务器经推送服务发送给用户代理的消息.
push message receipt (推送消息回执): 由推送服务发往应用服务器的消息投递确认.
push service (推送服务): 向用户代理投递推送消息的服务.
user agent (用户代理): 作为推送消息接收方的设备与软件.
本文档中的示例使用 HTTP/1.1 消息格式 [RFC7230]. 许多交互可使用 HTTP/1.1 完成:
-
订阅推送消息 (第 4 节)
-
请求投递推送消息 (第 5 节)
-
替换推送消息 (第 5.4 节)
-
确认推送消息 (第 6.2 节)
当示例依赖 HTTP/2 服务器推送时, 使用 [RFC7540] 中更冗长的帧格式:
-
为订阅接收推送消息 (第 6 节)
-
为订阅集合接收推送消息 (第 6.1 节)
-
接收推送消息回执 (第 6.3 节)
所有示例均使用默认端口 (443) 上的 HTTPS, 而非已注册端口 (1001). 推送服务部署可能偏好此配置以最大化用户代理到达服务的机会. 推送服务可使用 HTTP 替代服务 (HTTP alternative services) 将用户代理重定向到已注册端口 (1001), 从而在获得标准化 HTTPS 端口好处的同时不牺牲可达性 (见第 3 节). 这仅在用户代理发往推送服务的请求中出现 Alt-Used 头字段 [RFC7838] 时才会在示例中显现.
示例不包含推送消息加密或应用服务器身份验证的具体方法, 因为协议未规定强制系统. Voluntary Application Server Identification [VAPID] 与 Message Encryption for WebPush [ENCRYPT] 中的示例展示了 W3C Push API [API] 为满足其需求所采用的做法.