- 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