Re: HTTP/2 and Websockets

On 1 October 2014 23:37, Amos Jeffries <squid3@treenet.co.nz> wrote:

>> All the implementor discussion I've seen during the
>>> HTTP/2 discussions has focused on how intermediaries want to be
>>> scalable: and buffering is anti-scaling. So - is it a pragmatic
>>> concern, or do we expect DATA stream buffering to take place
>>> [outside of protocol gateways converting to HTTP/1.1 where non
>>> upload can require buffering - and note that such a gateway can't
>>> carry ws anyway unless its aware of it, and if its aware of it,
>>> it can make sure it does not buffer].
>
>
> I think the problem is not buffering in HTTP/2 per-se but the DATA
> frame (de-)aggregation that can happen if the frames are buffered by
> general network conditions (ie in TCP bottlenecks). This would not be
> good for a 1:1 relationship between DATA and ws frames.
>
> Amos

So hang on a second here. If we say that ws frames can't be split over
multiple HTTP/2 frames that implies that we have to buffer them until
there is enough in the window to transmit a potentially very large
packet all at once. It also conflicts with RFC6455 - the specific
intent there is to not be a stream based system.

I was suggesting that we just treat the HTTP/2 stream like the TCP
connection in RFC 6455 - the conversation from stream to message based
semantics and so on can take place above that in the ws implementation
- and that we should still apply the transmission windows etc to ws
streams.

-Rob



-- 
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud

Received on Tuesday, 14 October 2014 10:01:34 UTC