Re: HTTP/2 and Websockets

On 15 October 2014 00:00, Amos Jeffries <squid3@treenet.co.nz> wrote:
> -----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 agree that its inconsistent which is why I don't think it matters
and mapping down to h2 frames as a sequence of octets would be fine.
But you seem to both agree with my reasoning and disagree with my
conclusion. This is confusing.

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

Sorry, I just don't follow that. We have a primitive which appears to
fit ws entirely, with the only caveat being that we haven't defined
the mapping from the high level frames to the h2 primitives. If the
spec identifies how ws is negotiated and framed within h2, its not
opaque at all. And ws implementations that support raw ws (which
they'll do for quite some time...) have to deal with tcp which offers
no better semantics than this.

-Rob

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

Received on Thursday, 20 November 2014 20:12:22 UTC