- From: 陈智昌 <willchan@chromium.org>
- Date: Tue, 8 Jul 2014 18:17:14 -0700
- To: Mike Belshe <mike@belshe.com>
- Cc: Jeff Pinner <jpinner@twitter.com>, Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAA4WUYhEOA7SsCDEPvAcc3xCuQMyo95zUbSVvr_woAkZn20qWg@mail.gmail.com>
On Tue, Jul 8, 2014 at 5:50 PM, Mike Belshe <mike@belshe.com> wrote: > > > > On Tue, Jul 8, 2014 at 5:33 PM, William Chan (陈智昌) <willchan@chromium.org> > wrote: > >> On Tue, Jul 8, 2014 at 3:01 PM, Mike Belshe <mike@belshe.com> wrote: >> >>> >>> >>> >>> On Tue, Jul 8, 2014 at 9:39 AM, Jeff Pinner <jpinner@twitter.com> wrote: >>> >>>> To be clear, the proposal is: >>>> >>>> 1) Remove the reference set from HPACK (use "Linear-H") >>>> >>> >>> +1; Kazu's data convinces me entirely. >>> >>> >>>> 2) Increase the frame size to 16-bits >>>> >>> >>> +1 to increase the size. I would support going larger; the artificial >>> limits never provided value in SPDY nor H2. I liked Greg's proposal >>> generally. >>> >> >> Just chiming in to note that this statement is factually incorrect, since >> Patrick identified several instances where serialization latency of large >> DATA frames was substantial. You can subjectively say this is little value, >> but saying it has no value is simply false. >> > > We all know that depending on what network/configuration/content you're > rendering you'll see different results between 4kb, 12kb, and 16kb. These > tests go back to the origin of SPDY. What I was trying to say is that you > can have a larger maximum size and yet use a smaller size to get better > performance if that suits you. So the "little value" means that it doesn't > inhibit using well suited frame sizes. Conversely, if you are running a > case where larger frames would help, you cannot go beyond an artificially > low maximum. > > I believe most implementations will voluntarily use smaller sizes for > performance reasons without having to put a hard coded constant in the > frame size. We certainly did this in the early spdy implementations, and > it worked. Since it was working, clearly the artificially smaller frame > size is optional - you can still achieve good performance without it, and > that is why I claim it has minimal value. > This is totally a valid point of view, but I'm more skeptical than you are about the quality of implementations. I submit as evidence that both Apache's mod_ssl and nginx's openssl usage did/do not use small TLS record sizes despite the far more drastic impact on latency. For example, despite web perf advocates like yourself publicizing TLS record size issues, nginx still uses 16kb records by default: http://lxr.nginx.org/source/src/event/ngx_event_openssl.h#0109. Maybe the landscape has changed now though and more people care about web performance and will notice these issues. But Patrick showed us that a number of SPDY implementations, which theoretically implement for web performance reasons and thus should be paying attention to this, still get this wrong. > Mike > > > > > > > > >> >> >>> >>> >>>> 3) Allow interleaving of HEADERS frames >>>> 4) Remove the "\0" separator hack. >>>> >>> >>> +1; these were hacks unresolved due to the global compressor. >>> >>> >>>> >>>> Coupling this with my earlier proposal to add a "SYN_STREAM" header >>>> would also allow us to: >>>> >>>> 5) Remove CONTINUATION frames entirely >>>> >>> >>> +1; this makes things much simpler. >>> >>> >>>> 6) Move END_* flags to the last HEADERS frame >>>> >>> >>> +1; makes things simpler. >>> >>> >>>> 7) Flow control HEADERS frames >>>> >>> >>> +1; this is just simpler too. >>> >>> Mike >>> >>> >>> >>> >>> >> >
Received on Wednesday, 9 July 2014 01:17:41 UTC