我对HTTP协议的细微差别感到有些生锈,我想知道它是否可以直接支持发布/订阅?
HTTP是请求响应协议。因此,客户端发送请求,服务器发送回响应。 在HTTP 1.0中,为每个请求建立了新的连接。 现在,HTTP 1.1通过允许客户端保持连接打开并发出多个请求而对HTTP 1.0进行了改进。
我意识到您可以将HTTP连接升级到websocket,以进行快速的2向通信。我很好奇的是,这是否绝对必要?
例如,如果我请求资源“ 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
我觉得这种“可能”有效,因为客户端通常会有一个事件循环来监视连接,但是在技术上是错误的(因为遵循该协议的客户端不需要以这种方式实现)。
但是,如果您使用chunked transfer encoding,则可以使用。
HTTP / 2似乎也允许这样做,但是我不清楚是否进行了某些更改以使其成为可能。
关于发布/订阅,我还没有看到太多讨论,那么如果使用带有或不带有分块编码的纯HTTP / 1.1有什么问题怎么办?
如果这行得通,为什么您需要RSS或ATOM之类的东西?
答案 0 :(得分:1)
一个HTTP请求可以有多个“响应”,但是响应都具有1xx
范围内的状态码,例如102 Processing。
但是,这些响应只是标题,而不是正文。
HTTP / 1.1(例如之前的1.0)是request/response协议。不允许发送未经请求的响应。 HTTP / 2是一个帧协议,它添加了server push,该协议允许服务器建议提供额外的数据并并行处理多个请求,但不会更改其请求/响应性质。
尽管可以保持HTTP连接打开并继续发送更多数据。许多(音频,视频)流服务将使用此功能。
但是,这看起来像是一个连续不断的主体,不断进行流传输,而不是许多多个HTTP响应。
如果这行得通,为什么您需要RSS或ATOM之类的东西
因为打开TCP连接不是免费的。