跳到主要内容

7. 运维考量

7. 运维考量​

7.1. Load Management (负载管理)​

推送服务很可能需要维持大量打开的 TCP 连接. 对这些连接的有效管理可能取决于能否在服务器实例之间迁移连接.

用户代理必须 (MUST) 支持 307 (Temporary Redirect) 状态码 [RFC7231], 推送服务可在请求新订阅时使用它来再分配负载.

希望再分配负载的服务器可使用 HTTP 替代服务 [RFC7838]. HTTP 替代服务允许在保持各种资源 URI 不变的情况下再分配负载. 用户代理在建立替代连接后可通过使用 GOAWAY 帧确保平稳过渡.

7.2. Push Message Expiration (推送消息过期)​

基于 TTL 头字段存储推送消息可能占用推送服务大量存储空间. 推送服务无义务无限期存储消息. 推送服务能够使用 TTL 头字段 (第 5.2 节) 向应用服务器表明其打算保留消息的时长.

不主动监视推送消息的用户代理将不会收到在该间隔内过期的消息.

已存储且尚未投递给用户代理的推送消息在用户代理恢复监视时投递. 已存储的推送消息应当 (SHOULD) 包含 Last-Modified 头字段 ([RFC7232] 第 2.2 节), 指明应用服务器请求投递的时间.

对仅含已过期消息的推送消息订阅资源的 GET 请求产生的响应如同从未发送过推送消息.

推送服务可能需要限制所存储推送消息的大小与数量以避免过载. 为限制消息大小, 推送服务可以 (MAY) 对包含过大实体体的请求返回 413 (Payload Too Large) 状态码 [RFC7231]. 推送服务禁止 (MUST NOT) 对大小为 4096 字节或更小的实体体的响应返回 413 状态码.

为限制所存储推送消息数量, 推送服务可以 (MAY) 以短于应用服务器在投递请求 (第 5.2 节) 中所提议的生存时间响应. 消息一旦被接受, 推送服务可以 (MAY) 在其公布的生存时间之前使消息过期. 若应用服务器请求了投递回执, 推送服务必须 (MUST) 返回失败响应 (第 6.2 节).

7.3. Subscription Expiration (订阅过期)​

某些情况下可能需要终止订阅以便刷新. 这适用于推送消息订阅与回执订阅.

推送服务可以 (MAY) 随时使订阅过期. 若存在来自用户代理的对已过期推送消息订阅资源 (第 6 节) 的未决请求, 或来自应用服务器的对已过期回执订阅资源 (第 6.3 节) 的未决请求, 必须通过返回 404 (Not Found) 状态码来表明.

若应用服务器尝试向已过期的推送消息订阅发送推送消息, 推送服务必须 (MUST) 返回 404 (Not Found) 状态码.

用户代理可通过向对应 URI 发送 DELETE 请求来移除其推送消息订阅. 应用服务器可通过向对应 URI 发送 DELETE 请求来移除其回执订阅.

7.3.1. Subscription Set Expiration (订阅集合过期)​

推送服务可以 (MAY) 随时使订阅集合过期, 且必须 (MUST) 同时使集合中所有推送消息订阅过期. 若用户代理对推送订阅集合 (第 6.1 节) 有未决请求, 必须通过返回 404 (Not Found) 状态码来表明.

用户代理可通过向订阅集合 URI 发送 DELETE 请求来请求移除订阅集合. 这也必须 (MUST) 移除集合中的所有推送消息订阅.

若作为订阅集合成员的特定推送消息订阅过期或被移除, 则也必须 (MUST) 从其订阅集合中移除.

7.4. Implications for Application Reliability (对应用可靠性的影响)​

若推送服务不支持在间歇性网络连接或设备上故障应用之间的可靠投递, 会迫使设备直接向应用服务器确认收到, 从而因建立并维持 (通常安全的) 到各应用服务器的连接而产生额外耗电.

若消息包含对应用状态至关重要的信息, 推送消息可靠性可能很重要. 修复状态可能代价高昂, 尤其对通信能力有限的设备. 知晓推送消息已被正确接收可避免重传、轮询与状态再同步.

推送消息投递回执的可用性确保应用开发者不会倾向于在推送服务未能投递关键消息时创建替代投递机制. 为弥补这些不足而建立轮询机制或备用消息通道几乎会抵消推送服务提供的全部优势.

然而, 对瞬时消息 (例如来电) 或很快被取代的消息 (例如当前未读邮件数), 可靠性可能并非必要.

7.5. Subscription Sets and Concurrent HTTP/2 Streams (订阅集合与并发 HTTP/2 流)​

若推送服务要求用户代理使用推送消息订阅集合, 则可以 (MAY) 通过 HTTP/2 SETTINGS 帧 [RFC7540] 内的 SETTINGS_MAX_CONCURRENT_STREAMS 参数限制并发活动流数量. 用户代理可以 (MAY) 被限制为一条并发流用于管理推送消息订阅, 以及推送服务返回的每个订阅集合各一条并发流. 这可能迫使用户代理对推送服务的订阅请求进行串行化.

最后于 更新