Re: HTTP/2 and Websockets

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

On 21/11/2014 7:58 p.m., Andy Green wrote:
> 
> 
> On 21 November 2014 14:41:19 GMT+08:00, Yutaka Hirano
> <yhirano@google.com> wrote:
>> On Fri, Nov 21, 2014 at 12:38 PM, Andy Green <andy@warmcat.com>
>> wrote:
>> 
>>> 
>>> 
>>> On 21 November 2014 11:30:46 GMT+08:00, Yutaka Hirano
>> <yhirano@google.com>
>>> wrote:
>>>> On Fri, Nov 21, 2014 at 11:42 AM, Andy Green
>>>> <andy@warmcat.com>
>> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 21 November 2014 10:02:28 GMT+08:00, Yutaka Hirano
>>>> <yhirano@google.com>
>>>>> wrote:
>>>>>>> 
>>>>>>> I think you have to take the atomic large ws frame
>>>>>>> thing as a
>>>> genuine
>>>>>>> problem because http2 has the transmit credit concept.
>>>>>>> So even
>> if
>>>>>> you
>>>>>>> buffered one ws frame, you can't sit there spewing as
>>>>>>> much
>> http2
>>>> DATA
>>>>>> frame
>>>>>>> as it needs to atomically encapsulate it, without
>>>>>>> sizing your
>>>> http2
>>>>>> frame
>>>>>>> to suit the tx credit. But it's OK because the
>>>>>>> implementation can transparently
>> fragment
>>>> the
>>>>>> ws
>>>>>>> data using the ws message semantics... I think there's
>>>>>>> no
>> choice
>>>> but
>>>>>> to
>>>>>>> take that approach.
>>>>>> 
>>>>>> Sorry I don't understand what you are proposing. Can you
>>>>>> explain?
>>>>> 
>>>>> I'm agreeing with what was already written by someone else
>>>>> on the
>>>> thread.
>>>>> 
>>>>> Talking about buffering huge ws frames until you have
>>>>> enough to
>> issue
>>>> it
>>>>> all in one big http2 DATA frame will not fly.
>>>>> 
>>>>> If you're using this putative ws-over-http2 scheme, and you
>>>>> get
>> given
>>>> a
>>>>> huge ws frame to transmit, you should fragment it using
>>>>> RFC6455
>>>> message
>>>>> semantics to some implementation-defined limit that is
>>>>> friendly
>> for
>>>> mux'd
>>>>> http2 transport.
>>>>> 
>>>> Thanks.
>>>> 
>>>> Strictly speaking, RFC6455 allows an extension to give
>>>> meaning to WebSocket frames, so merging / fragmenting frames
>>>> breaks such extensions. We discussed this problem in HyBi and
>>>> many of us said "don't care".
>>> 
>>> Yeah extensions except for compression have just not come into
>> existence.
>>> 
>>> So I also see it as don't care.  I'm not even sure it's true
>>> since
>> the
>>> intention during ws discussion was an intermediary can
>>> fragment
>> frames same
>>> as how tcp packets may be fragmented.
>>> 
>>>> In any case, an http/2 frame cannot be bigger than 2^24 (or
>>>> 2^14 without an explicit permission), so I think we don't
>>>> have to worry about DoS.
>>> 
>>> ... I don't see that.  If I keep spamming 16MB frames even on
>>> one
>> stream
>>> on a consumer link your latency goes to pieces and if something
>>> is
>> doing
>>> multiple instances of it even a big pipe will feel pain.
>>> 
>>> 
>> The spec says: Length: The length of the frame payload expressed
>> as an unsigned 24-bit integer. Values greater than 2^14 (16,384)
>> MUST NOT be sent unless the receiver has set a larger value for
>> SETTINGS_MAX_FRAME_SIZE. So by default 2^14 is the upper limit.
>> Larger frames will be used only if the receiver wants.
> 
> Okay.  But if buffering whole ws frames no matter how big was the
> plan, and the one end wanted to send a 16MB ws frame, the other end
> would say, "sure" you can send me >16K and he'd spam his 16MB
> frames.  Default 16K limit doesn't help much because the server is
> complicit in thinking sending huge ws frames is good.
> 

You switched between "receiver" and "server" there in your concepts.

Overlooking the fact that intermediaries in HTTP can cut DATA up into
smaller frames and stitch them together into larger ones as needed
hop-by-hop. So what your sender gets told it can send on the
client->proxy connection may not be what gets delivered to the server.

That was the major reason for WSDATA not being HTTP/2 DATA. That flags
byte being mentioned at the beginning of DATA payload will get screwed
over and moved around too much. Unless it is at fixed positions of the
total WS stream inside the DATA payloads.

But then, as has been mentioned since HEADERS initiated a WS stream,
why is DATA needing to be re-flagged specially? it is opaque payload
bytes of the stream already flagged as being a WS transaction.

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

iQEcBAEBAgAGBQJUbxqJAAoJELJo5wb/XPRjdp8H/1s4aNBEEwSItqQSOYilrCZC
+OHb1mTSTHHW5np5zPdbk3qOlyoz0jZJw1l5RAivq5xFYBsR2uyoaTBfgePAaYND
j3rX7oA57h3smbq7mKeYi+fwJNOtqYwL6sJgDwd3dho1TFbL9+EfhOuWOpidl9SG
FgpiK1k1KzZ/67pnZx9bcsI+yyOghYvU1l14O2Wx5nKA6hudo8HJgAZDQok1OMin
j/z8QRZcuS+zUq8skSIpv4TUDYXoUUG8ztz4VDwmXt+MglEahLkaw6nucO3Rx3l8
RCKDz+MZD+Q1lGOeSaf9XC/Y+XUUcEaYyvBnnhs8omr3yLyTFid8946qVvz/u4Q=
=Lxws
-----END PGP SIGNATURE-----

Received on Friday, 21 November 2014 10:57:56 UTC