Re: HTTP 2.0 and a Faster, more Mobile-friendly web
Mike Belshe <mike@belshe.com> Tue, 31 July 2012 04:36 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CFB11E80C5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 30 Jul 2012 21:36:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.475
X-Spam-Level:
X-Spam-Status: No, score=-9.475 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2YVkVTQbFhK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 30 Jul 2012 21:36:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1846611E80D2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 30 Jul 2012 21:36:36 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Sw4Ab-0005A4-Cg for ietf-http-wg-dist@listhub.w3.org; Tue, 31 Jul 2012 04:34:57 +0000
Resent-Date: Tue, 31 Jul 2012 04:34:57 +0000
Resent-Message-Id: <E1Sw4Ab-0005A4-Cg@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mike@belshe.com>) id 1Sw4AM-00059E-RF for ietf-http-wg@listhub.w3.org; Tue, 31 Jul 2012 04:34:42 +0000
Received: from mail-lpp01m010-f43.google.com ([209.85.215.43]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <mike@belshe.com>) id 1Sw4AK-0005vL-BR for ietf-http-wg@w3.org; Tue, 31 Jul 2012 04:34:42 +0000
Received: by lahg1 with SMTP id g1so3731523lah.2 for <ietf-http-wg@w3.org>; Mon, 30 Jul 2012 21:34:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/i3wzlLGtneKHGswxM+QIiC+wzwoW5l1vimbZ6DuKxI=; b=oIuHJ5Pb8PlkxDI+OZw3aBBzddBpK6zNkBcJEc0PyvMkHdUBfdBSGV1y3BEbuBaAfA PIaIJByj8cY/n1ttyxak7gaxia3R+PnkdC/jgQNJ6CIlFkfFhnkDZPulBoyrCTYfmlQH Fb/v7ugkdtGyFxww1NA+0gnODrJmuTbuyURK6IdZJ8RrloxB5/iCvnvrzCRD1iItGqPd 7woPRvmrBvANuB+H03l3upPqMXqbbGNjUm5v8B+OqItF9HXwZh8MWFUYjYwlzCIAoIeD mj7lnGtcYmN+aaIq+4KQ1qCt5De90EJ18bgKCLAq8MV8kghymQed9BIgY69OcG3plD96 ZkAA==
MIME-Version: 1.0
Received: by 10.152.48.37 with SMTP id i5mr13472824lan.36.1343709253294; Mon, 30 Jul 2012 21:34:13 -0700 (PDT)
Received: by 10.112.99.1 with HTTP; Mon, 30 Jul 2012 21:34:13 -0700 (PDT)
In-Reply-To: <723b83d47f93417290cca860e2925703@CH1PR03MB622.namprd03.prod.outlook.com>
References: <723b83d47f93417290cca860e2925703@CH1PR03MB622.namprd03.prod.outlook.com>
Date: Mon, 30 Jul 2012 21:34:13 -0700
Message-ID: <CABaLYCvsAPy9FTRp+3cWEH_ssZ5KNp+=a3yaH4SFN4YFts=MUw@mail.gmail.com>
From: Mike Belshe <mike@belshe.com>
To: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Rob Trace <Rob.Trace@microsoft.com>, "Adalberto Foresti (MS OPEN TECH)" <aforesti@microsoft.com>
Content-Type: multipart/alternative; boundary="bcaec5523980b95b0c04c618b08e"
X-Gm-Message-State: ALoCoQnV0DDwC+50NnR0lRpEAT7Zfwt8RfNcd/6rx2dvDzpE2XgwADjQCyC3/byk4ICuAmjAXN0h
Received-SPF: none client-ip=209.85.215.43; envelope-from=mike@belshe.com; helo=mail-lpp01m010-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-2.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7
X-W3C-Scan-Sig: maggie.w3.org 1Sw4AK-0005vL-BR f8bd6dc58b3ccf49f95afc709181defc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP 2.0 and a Faster, more Mobile-friendly web
Archived-At: <http://www.w3.org/mid/CABaLYCvsAPy9FTRp+3cWEH_ssZ5KNp+=a3yaH4SFN4YFts=MUw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/14842
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Henrik and team - Awesome paper! One thing I notice is that your test pages did not use many resources. (3 for the dummy web page and 11 for the cnn page). As you know ( http://httparchive.org/trends.php) pages today tend to have ~80 resources per page. Its the large-resource pages where HTTP slows down, as it can only fetch 6 at a time (2 if you stick to the spec). It would be interesting to load up a more modern page, like a facebook.com wall page, with dozens of images and resources to really exercise the multiplexing. The biggest conclusion I read from this is that SSL is hard to make fast (and also very true!) :-) I'm glad you benchmarked with Chromium because it uses SSL FalseStart to reduce a round trip. I'm curious if you did anything for certificate validation in this test? It looks like you're generally seeing a 2RTT overhead of SSL in your tests, which is indicative of the SSL cold-start case. Can you confirm you wiped the session-ID cache between runs? It's also indicative of not really exercising the multiplexing, where the SSL overhead gets mitigated as HTTP slows down with 6-at-a-time round trips. Mike On Sun, Jul 29, 2012 at 1:14 PM, Henrik Frystyk Nielsen < henrikn@microsoft.com> wrote: > Dear All,**** > > ** ** > > We remain committed to the HTTP/2.0 standards process and look forward to > seeing many of you this week at the IETF meeting in Vancouver to continue > the discussion. In the spirit of open discussion, we wanted to share some > observations in advance of the meeting and share the latest progress from > prototyping and testing. **** > > ** ** > > There are currently three different proposals that the group is working > through:**** > > ** ** > > * SPDY (http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy),**** > > * HTTP Speed+Mobility ( > http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility),**** > > * Network-Friendly HTTP Upgrade ( > http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly). **** > > ** ** > > The good news is that everyone involved wants to make the Web faster, more > scalable, more secure, and more mobile-friendly, and each proposal has > benefits in different areas that the discussion can choose from.**** > > ** ** > > --- A Genuinely Faster Web ---**** > > ** ** > > The SPDY proposal has been great for raising awareness of Web performance. > It takes a “clean slate” approach to improving HTTP.**** > > ** ** > > To compare the performance of SPDY with HTTP/1.1 we have run tests > comparing download times of several public web sites using a controlled > tested study. The test uses publically available software run with mostly > default configurations while applying all the currently available > optimizations to HTTP/1.1. You can find a preliminary report on the test > results here: http://research.microsoft.com/apps/pubs/?id=170059. The > results mirror other data ( > http://www.guypo.com/technical/not-as-spdy-as-you-thought) that indicate > mixed results with SPDY performance.**** > > ** ** > > Our results indicate almost equal performance between SPDY and HTTP/1.1 > when one applies all the known optimizations to HTTP/1.1. SPDY’s > performance improvements are not consistent and significant. We will > continue our testing, and we welcome others to publish their results so > that HTTP/2.0 can choose the best changes and deliver the best possible > performance and scalability improvements compared to HTTP/1.1.**** > > ** ** > > ** ** > > --- Taking the Best from Each ---**** > > ** ** > > Speed is one of several areas of improvement. Currently, there’s no clear > consensus that any one of the proposals is the clear choice or even > starting point for HTTP/2.0 (based on our reading the Expressions of > Interest and discussions on this mailing list. A good example of this is > the vigorous discussion around mandating TLS encryption ( > http://tools.ietf.org/html/rfc5246) for HTTP/2.0. **** > > ** ** > > We think a good approach for HTTP/2.0 is to take the best solution for > each of these areas from each of the proposals. This approach helps us > focus the discussion for each area of the protocol. Of course, this > approach would still allow the standard to benefit from the extensive > knowledge gained from implementing existing proposals. **** > > ** ** > > We believe that the group can converge on consensus in the following > areas, based on our reading of the Expressions of Interest, by starting > from the different proposals.**** > > ** ** > > ------------------|------------------**** > > Area | Opinion that **** > > | seems to prevail**** > > ------------------|------------------**** > > 1. Compression | SPDY or Friendly**** > > ------------------|------------------**** > > 2. Multiplexing | SPDY**** > > ------------------|------------------**** > > 3. Mandatory TLS | Speed+Mobility**** > > ------------------|------------------**** > > 4. Negotiation | Friendly or**** > > | Speed+Mobility**** > > ------------------|------------------**** > > 5. Client Pull/ | Speed+Mobility**** > > Server Push | **** > > ------------------|------------------**** > > 6. Flow Control | SPDY**** > > ------------------|------------------**** > > 7. WebSockets | Speed+Mobility**** > > ------------------|------------------**** > > ** ** > > Below, we discuss each HTTP/2.0 element and the current consensus that > appears to be forming within the Working Group.**** > > ** ** > > 1. Compression**** > > ** ** > > Compression is simple to conceptualize and implement, and it is important. > Proxies and other boxes in the middle on today’s Web often face problems > with it. The HTTP/2.0 discussion has been rich but with little consensus.* > *** > > **** > > Though some studies suggest that SPDY’s header compression approach shows > promise, other studies show this compression to be prohibitively onerous > for intermediary devices. More information here would help us make sure > we’re making the Web faster and better. **** > > ** ** > > Also, an entire segment of implementers are not interested in compression > as defined in SPDY. That’s a challenge because the latest strawman for the > working group charter ( > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0784.html) > states that the “resulting specification(s) are expected to be meet these > goals for common existing deployments of HTTP; in particular, … > intermediation (by proxies, corporate firewalls, ‘reverse’ proxies and > Content Delivery Networks).” **** > > ** ** > > We think the SPDY or Friendly proposals is a good starting point for > progress.**** > > ** ** > > 2. Multiplexing**** > > ** ** > > All three proposals define similar multiplexing models. We haven’t had > substantial discussion on the differences. This lack of discussion suggests > that there is rough consensus around the SPDY framing for multiplexing. ** > ** > > ** ** > > We think that the SPDY proposal is a good starting point here and best > captures the current consensus.**** > > ** ** > > 3. Mandating Always On TLS **** > > ** ** > > There is definitely no consensus to mandate TLS for all Web communication, > but some major implementers have stated they will not to adopt HTTP/2.0 > unless the working group supports a “TLS is mandatory” position. A very > preliminary note from the chair ( > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0601.html) > states that there is a lack of consensus for mandating TLS. **** > > ** ** > > We think the Speed+Mobility proposal is a good starting point here as it > provides options to turn TLS on (or not).**** > > ** ** > > 4. Negotiation**** > > ** ** > > Only two of the proposals actually discuss how different endpoints agree > to use HTTP/2.0. **** > > ** ** > > (The SPDY proposal does not specify a negotiation method. Current > prototype implementations use the TLS-NPN ( > http://tools.ietf.org/html/draft-agl-tls-nextprotoneg) extension. While > the other proposals use HTTP Upgrade to negotiate HTTP/2.0, some parties > have expressed non-support for this method as well.) **** > > ** ** > > We think either of the Friendly or Speed+Mobility proposals is a good > starting point because they are the only ones that have any language in > this respect. **** > > ** ** > > 5. Client Pull and Server Push**** > > ** ** > > There are tradeoffs between a server push model and a client pull model. > The main question is how to improve performance while respecting bandwidth > and client caches. **** > > ** ** > > Server Push has not had the same level of implementation and > experimentation as the other features in SPDY. More information here would > help us make sure we’re making the Web faster and better. **** > > ** ** > > We think the Speed+Mobility proposal is a good starting point here, > suggesting that this issue may be better served in a separate document > rather than tied to the core HTTP/2.0 protocol. **** > > ** ** > > 6. Flow Control**** > > ** ** > > There has only been limited discussion in the HTTPbis working group on > flow control. Flow Control offers a lot of opportunity make the Web faster > as well as to break it; for example, implementations need to figure out how > to optimize for opposing goals (like throughput and responsiveness) at the > same time. **** > > ** ** > > The current version of the SPDY proposal specifies a flow control message > with many settings are that are not well-defined. The Speed+Mobilty > proposal has a simplified flow control model based on certain assumptions. > More experimentation and information here would help us make sure we’re > making the Web faster and better. **** > > ** ** > > We think that the SPDY proposal is a good starting point here. **** > > ** ** > > 7. WebSockets**** > > ** ** > > We see support for aligning HTTP/2.0 with a future version of WebSockets, > as suggested in the introduction of the Speed+Mobility proposal.**** > > ** ** > > ** ** > > --- Moving forward ---**** > > ** ** > > We’re excited for the Web to get faster, more stable, and more capable, > and HTTP/2.0 is an important part of that. **** > > ** ** > > We believe that bringing together the best elements of the current SPDY, > HTTP Speed+Mobility, and Network-Friendly HTTP Upgrade proposals is the > best approach to make that happen. **** > > ** ** > > Based on the discussions on the HTTPbis mailing list, we’ve suggested > which proposals make the most sense to start from for each of the areas > that HTTP/2.0 is addressing. Each of these areas needs more prototyping and > experimentation and data. We’re looking forward to the discussion this week. > **** > > ** ** > > Sincerely,**** > > ** ** > > Henrik Frystyk Nielsen**** > > Principal Architect, Microsoft Open Technologies, Inc.**** > > ** ** > > Gabriel Montenegro**** > > Principal Software Development Engineer, Microsoft Corporation**** > > ** ** > > Rob Trace**** > > Senior Program Manager Lead, Microsoft Corporation**** > > ** ** > > Adalberto Foresti**** > > Senior Program Manager, Microsoft Open Technologies, Inc.**** > > ** ** > > ** ** >
- HTTP 2.0 and a Faster, more Mobile-friendly web Henrik Frystyk Nielsen
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Martin Nilsson
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Roberto Peon
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Amos Jeffries
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Figroc Chen
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… patrick mcmanus
- RE: HTTP 2.0 and a Faster, more Mobile-friendly w… Henrik Frystyk Nielsen
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Poul-Henning Kamp
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… William Chan (陈智昌)
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… patrick mcmanus
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Poul-Henning Kamp
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… patrick mcmanus
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… patrick mcmanus
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Yoav Nir
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Martin Nilsson
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Poul-Henning Kamp
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Martin Nilsson
- RE: HTTP 2.0 and a Faster, more Mobile-friendly w… Jitu Padhye
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Jonathan Ballard
- Re[2]: HTTP 2.0 and a Faster, more Mobile-friendl… Adrien W. de Croy
- RE: HTTP 2.0 and a Faster, more Mobile-friendly w… Henrik Frystyk Nielsen
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Mike Belshe
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Roberto Peon
- RE: HTTP 2.0 and a Faster, more Mobile-friendly w… Jitu Padhye
- RE: HTTP 2.0 and a Faster, more Mobile-friendly w… Jitu Padhye
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… James M Snell
- RE: HTTP 2.0 and a Faster, more Mobile-friendly w… Jitu Padhye
- RE: HTTP 2.0 and a Faster, more Mobile-friendly w… Benjamin Carlyle
- Re: HTTP 2.0 and a Faster, more Mobile-friendly w… Rajeev Bector