Re: HTTP/2 and Websockets

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 14/10/2014 11:01 p.m., Robert Collins wrote:
> On 1 October 2014 23:37, Amos Jeffries 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.

If a ws frame *has* to be that long, not doing so would block the
entire HTTP/2 connection until all bytes of that frame were delivered
anyway. So you trade off buffering that single frame at the sender,
versus blocking all HTTP/2 traffic end-to-end.

If the ws data is so critical to get transmitted fast why is that
single ws frame so large to begin with? surely it would be transmitted
faster as a sequence of WS + *WSDATA frames emited as the payload was
available to send.

> 
> 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.

If you do that you loose any and all benefits from HTTP/2 frames.
Everything from ws frame headers to data content becomes semantically
identical to the opaque payload of a DATA frame on an HTTP/2 CONNECT
request. I believe Yutaka is seeking to get away from that situation
where DATA frames may be split, joined or buffered at any point.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUPQJMAAoJELJo5wb/XPRjgOYH/1nA7VOhJ0tzslcadEPD3Hzl
mUWos3c+s2v2lZ2Ao5QglHIjH4FrCR9clyMaf4GyC9YsU4jaJ9nWQvw1MWFS00NG
B2VXS0kIk5M0wqPaSLApVsXv0lHesGwGhqmgDm/vRMCOV5rdwp7FV1Bh3qNY0SuM
frf/OKHz4VPSzzyec6kdBncjGCO8DGxWnraVDSu++Lil918ww5mbfo/kcTms4ykK
usYr6+jMi+CzK50+XB5AfxmIILBXKcgnhJGeRYUbpK2ecF15bBuZ6eZBIe9DHaeG
rCDqqZ2w9Rl54M3Ml34hrmtZ0Wv5EbdFcmvwRs9E+af4bOUuHee9tNTtZ/2/jSY=
=xNsZ
-----END PGP SIGNATURE-----

Received on Tuesday, 14 October 2014 11:01:06 UTC