REST streaming API是否通过HTTP Keep-Alive头部报文实现？

Shodan流式API保活机制问题解答 #

你提到的Shodan REST流式API在暂无新数据可下发时，确实会定期发送HTTP保活报文维持长连接，这是这类公开流式API的通用设计：一般会每隔15~30秒发送一次空包、空白行或者注释类的心跳内容，避免网络链路中的网关、代理或者客户端本身因为连接长时间空闲触发超时断开。

REST流式API的其他实现方案 #

• 分块传输编码（Chunked Transfer Encoding）：HTTP/1.1原生支持的能力，不需要额外协议扩展，服务端返回Transfer-Encoding: chunked响应头后，就可以将数据拆分为任意大小的块逐个下发，空闲期可以发送0长度空块作为心跳保活，是目前纯REST流式API最常用的实现方案，Shodan的流式API就是基于这个机制实现的。
• 服务器发送事件（SSE）：W3C定义的标准单向流式传输协议，底层依然基于HTTP协议，本身内置了心跳保活逻辑，客户端可以用浏览器原生的EventSource接口直接对接，不需要额外的第三方依赖，开发成本极低，非常适合仅需要服务端向客户端单向推送数据的场景。
• WebSocket：虽然不属于传统REST规范的范畴，但目前很多类REST的流式服务都会选择WebSocket作为传输层，相比纯HTTP流，WebSocket支持双向通信，保活帧、数据帧的控制更灵活，还支持客户端随时向服务端发送指令调整流的过滤条件、传输速率等，适合交互逻辑更复杂的流式场景。
• HTTP/2 服务器推送：基于HTTP/2原生的推送特性，客户端发起一次请求后，服务端可以持续向客户端推送数据流，相比HTTP/1.1的分块传输，HTTP/2的多路复用特性可以有效避免队头阻塞，同一个连接下可以同时承载多个独立的数据流，高并发场景下性能优势更明显。
• 长轮询（Long Polling）：属于流式能力的降级兼容方案，客户端发起请求后服务端会挂起连接，直到有新数据返回或者达到超时阈值，客户端收到响应后立刻发起下一次请求模拟流式效果，实现逻辑最简单，对不支持长连接的老旧网络环境、客户端兼容性最好，但频繁创建销毁连接的开销远高于真流式方案。

内容的提问来源于stack exchange，提问作者AryhjkXK9d7zoj83