Re: HTTP/2 and Websockets

On 21 November 2014 15:03:03 GMT+08:00, Yutaka Hirano <yhirano@google.com> wrote:
>On Fri, Nov 21, 2014 at 3:15 PM, Andy Green <andy@warmcat.com> wrote:
>
>>
>>
>> On 21 November 2014 13:13:02 GMT+08:00, Andy Green <andy@warmcat.com>
>> wrote:
>> >
>> >
>> >On 21 November 2014 12:33:45 GMT+08:00, Yutaka Hirano
>> ><yhirano@google.com> wrote:
>> >>>
>> >>>  - WSDATA's 8-bit flags field, is the ws flags
>[fin][rsv1-3][opcode]
>> >>
>> >>We may want END_STREAM as well.
>> >
>> >Good point... and to be friendly with http2's obfuscation goals,
>> >PADDING.
>> >
>> >It means we need an extra byte to hold all the flags... well it's
>not
>> >too bad per-frame.
>> >
>> >If so, we could also do everything the same reusing using DATA with
>a
>> >flag "WS", indicating the payload is [WS_FLAGS byte + ws payload].
>> >That has an advantage --->
>> >
>> >>Corresponding http2 frames can substitue ping / pong / close (note:
>> >>WebSocket ones have payload though h2 ones don't). Shoud we have
>> >>opcodes
>> >>for them?
>> >
>> >We should probably keep the ws ones too.  Things like ws echo
>services
>> >do use the payload.  Actually endpoints can prefer the http2 ones if
>> >the see they can use them and know how to.  But supporting both
>> >everyone's happy.
>> >
>> >Ws has his own close codes and payload, if we try mapping those on
>> >http2 codes etc it might be a step too far.  So keeping ws close
>frame
>> >will be good.
>> >
>> >Close is a bit tricky if we try to say that a WSDATA close is an
>> >implicit http2 stream close everybody has to understand that, even
>if
>> >they were intermediaries that didn't really understand WSDATA and
>were
>> >just passing it through.  That's probably too much to ask.
>> >
>> >If we re-use DATA with a WS flag, the extra advantage is all http2
>> >intermediaries and endpoints already know the meaning of DATA frame
>> >with END_STREAM, so even if they do not follow what WS flag on DATA
>> >means, they can still follow the stream lifecycle without extra
>work.
>> >
>> >How realistic is it to get a DATA flag bit assigned now?
>>
>> Ah since the endpoints negotiated ws using HEADERS, actually we could
>do
>> without a WS flag on DATA.
>>
>> The fact that it's DATA for stream ID xxx and that ID went through a
>ws
>> handshake means both sides and all intermediaries present during the
>ws
>> handshake can know it is ws protocol in the DATA without an explicit
>flag.
>>
>> So we could just use DATA for this without any modification.  Peers
>that
>> understand websockets can know in some streams there's a WS_FLAGS
>byte at
>> the start of the DATA payload.  Peers that don't understand
>websockets just
>> move opaque DATA payloads around as usual and only see normal DATA
>> semantics going on.
>>
>> I don't like the idea of using the existing DATA frame.
>
>1. An intermediary must flush data when it sees an end of message
>(FIN).
>IIUC we don't have such flag in the plain http2 (we had END_SEGMENT but
>it
>is gone). So "just move opaque DATA payloads around" is not enough.

Hm he can only flush what he can send due to tx credit and priority.  But okay.

Maybe he should use priority to make ws connections more realtimey... no intermediary is going to want to hang on to stuff for long because the memory costs money.

And any peer in the path that's smart enough to note that stream did a ws upgrade can snoop the flags byte and follow this explicitly.

>2. With explicit negotiation, I know that all peers in the
>communication
>path understand ws-over-http2 perfectly and there is no chance to

Yeah.

I suggest it because it reduces the demands on http2 itself to handle this to nothing.... no new flags and no new frame type.

>misunderstand DATA in http2 and DATA in ws2, in theoretically. In
>reality,
>that is not true. The history of WebSocket is the history of battles
>with
>mis-implemented proxies (Note that the native WebSocket has the
>explicit
>negotiation but proxies modify payloads without understanding it). I
>would
>like to reduce the possibility of such confusion.

What I witnessed in Hybi is "the history of Websockets is the history of battles" to get agreement about any specific implementation that can go forward ^^

Well there are two other choices discussed today then

1) DATA with a WS flag

2) WSDATA

If it's going to be WSDATA, interoperability might be much worse if it's not widely understood since it's not part of http2, and peers just drop what they don't understand.

If there was a WS flag on DATA, is it reasonable to think we can still get than in as part of http2 or has that boat sailed?

-Andy

Received on Friday, 21 November 2014 07:38:27 UTC