基于推送 (Push-based) 的流式传输和基于拉取 (Pull-based) 的流式传输是处理服务器和客户端之间数据流的两种方法。在基于推送的流式传输中，服务器在数据可用时主动将其发送给客户端，而无需显式请求。这在实时系统中很常见，例如实时视频流或聊天应用程序，在这些系统中，即时性至关重要。例如，在体育比分应用程序中，服务器会在进球后立即将比分更新推送给所有连接的客户端。相比之下，基于拉取的流式传输依赖于客户端以固定间隔重复向服务器请求新数据。这种方法通常用于实时更新不太关键的场景，例如获取每日天气报告或检查系统日志。在这里，客户端控制数据检索的时间，就像移动应用程序每 5 分钟轮询一次 API 以获取新通知一样。
推送和拉取之间的选择通常取决于用例需求。基于推送的系统在低延迟场景中表现出色，在这些场景中，延迟是不可接受的。例如，金融交易平台使用推送模型将股票价格变化立即广播给交易者。但是，这要求服务器与客户端保持打开的连接，这会在扩展到数百万用户时消耗资源。基于拉取的系统虽然实现起来更简单，但引入了权衡。客户端每小时检查一次后端服务以获取软件更新，可能会错过关键补丁，直到下一次轮询。拉取模型降低了服务器负载，因为连接是瞬态的，但如果轮询间隔太长，它们可能会冒着提供陈旧数据的风险。混合方法（如 HTTP 长轮询）结合了两者的各个方面：客户端启动请求，但服务器保持连接打开，直到新数据准备好“推送”，从而平衡了响应能力和资源效率。
技术考虑因素也不同。基于推送的流式传输通常依赖于诸如 WebSockets 或服务器发送事件 (SSE) 之类的协议，这些协议维护持久连接。这些需要仔细处理网络中断 - 例如，重新连接实时视频源中掉线的 WebSocket。基于拉取的系统通常使用标准 REST API 或 HTTP 端点，从而更易于缓存（例如，使用 CDN 缓存静态内容）。但是，频繁轮询可能会导致不必要的网络流量，尤其是在数据很少更改的情况下。开发人员必须权衡延迟容忍度、可伸缩性需求和基础架构复杂性等因素。例如，实时协作文档编辑器需要推送来立即同步编辑，而博客平台可能会选择拉取来以最小的后端开销来提供文章。该决定最终取决于在实时需求和系统约束之间取得平衡。