我对 HTTP 协议的细微差别有点生疏，我想知道它是否可以直接支持发布/订阅？
HTTP 是一种请求响应协议。因此，客户端发送请求，服务器发回响应。 在 HTTP 1.0 中，每个请求都会建立一个新连接。 现在，HTTP 1.1 在 HTTP 1.0 的基础上进行了改进，允许客户端保持连接打开并发出多个请求。
我意识到您可以将 HTTP 连接升级到 Websocket，以实现快速的双向通信。我好奇的是这是否是绝对必要的？
例如，如果我请求资源“http://somewhere.com/fetch/me/slowly”
服务器有空直接回复两次吗？ 比如先用202接受 然后不久之后当内容准备好时， 但客户端没有先发送额外的请求？
即
Client: GET http://somewhere.com/fetch/me/slowly
Server: 202 "please wait..."
Server: 200 "here's your document"
以这种方式实现发布/订阅服务是否正确？ 例如：
Client: http://somewhere.com/subscribe
Server: item 1
...
Server: item 2
我的印象是这“可能”有效，因为客户端通常会有一个事件循环来监视连接，但在技术上是错误的（因为遵循协议的客户端不需要以这种方式实现）。
但是，如果您使用分块传输编码，这将起作用。
HTTP/2 似乎也允许这样做，但我不清楚是否进行了某些更改以使其成为可能。
我还没有看到太多与 pub/sub 相关的讨论，所以如果使用带或不带分块编码的纯 HTTP/1.1 有问题怎么办？
如果这有效，为什么你需要 RSS 或 ATOM 之类的东西？
一个 HTTP 请求可以有多个“响应”，但除最终响应外，所有响应的状态码都在
1xx但是，这些响应只是标题，而不是正文。
HTTP/1.1（与之前的 1.0 一样）是一个 请求/响应 协议。不允许未经请求发送响应。 HTTP/2 是一种框架协议，它添加了服务器推送，允许服务器提供额外的数据并并行处理多个请求，但不会改变其请求/响应性质。
可以保持 HTTP 连接打开并继续发送更多数据。许多（音频、视频）流媒体服务都会使用它。
但是，这看起来只是一个持续流式传输的连续体，而不是许多多个 HTTP 响应。
如果这有效，为什么你需要 RSS 或 ATOM 之类的东西
因为保持 TCP 连接打开并不是免费的。