- From: Andy Green <andy@warmcat.com>
- Date: Mon, 16 Oct 2017 10:57:53 +0800
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, Cory Benfield <cory@lukasa.co.uk>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 10/16/2017 10:51 AM, Martin Thomson wrote:
> On Mon, Oct 16, 2017 at 1:38 PM, Andy Green <andy@warmcat.com> wrote:
>> Here's what I think it means for RTT... first the default as it is
>>
>> Client Server
>>
>> - SETTINGS - SETTINGS
>> - GET /index.html
>> - 200 HEADERS + DATA
>>
>> - :method CONNECT
>> - 200 HEADERS
>>
>> - DATA ws handshake
>> - DATA ws handshake final
>>
>> - DATA ... - DATA...
>>
>> So after the h2 link is up, he needs 3 x roundtrips to send some ws data.
>
> I think that you are exaggerating the cost here. The ws handshake and
Eh... why do you say that? It takes less than 3 RTs?
> CONNECT can be sent together. The only real burden that Patrick's
> design adds is the need to test that the server is willing to use this
> design.
Maybe it's not clear from the formatting, but I based this from p4 of
Patrick's draft, here is the original
[[ From Client ]] [[ From Server ]]
SETTINGS
ENABLE_CONNECT_PROTOCOL = 1
HEADERS + END_HEADERS
:method = CONNECT
:protocol = websocket
:scheme = wss
:path = /chat
:authority = server.example.com:443
HEADERS + END_HEADERS
:status = 200
DATA
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
DATA
HTTP/1.1 101 Plead The Fifth
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept:
s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
DATA
WebSocket Data
DATA + END_STREAM
WebSocket Data
DATA + END_STREAM
WebSocket Data
That is 3 RTT, right?
> FWIW, if this were me, I would look at trimming the websocket
> handshake instead. Much of the overhead there is what will hurt the
He needs to support dumb http/1 ws clients that find themselves hitching
a ride on a h2 bundle. So they need all the headers they expect.
That's why I don't suggest any changes there, but as an optimization for
h2-aware ws client skip all that legacy junk and just provide the end
result in the PUSH_PROMISE.
> overall latency. If you took the setting as an indication that this
> was an acceptable protocol, you could remove all the Upgrade business
> and just start sending ws frames. But I think that Patrick is right
> to start with the minimal thing; I would recommend only doing that
> with a new protocol identifier.
That is what I suggested on both counts :-)
-Andy
Received on Monday, 16 October 2017 02:58:34 UTC