Re: Experiences with HTTP/2 server push
Kazuho Oku <kazuhooku@gmail.com> Thu, 01 September 2016 05:03 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 0027612D0A4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Aug 2016 22:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.569
X-Spam-Level:
X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipTsIZ7ra_CU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 Aug 2016 22:03:04 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F9912D0D1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 31 Aug 2016 22:03:03 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bfK4m-0000Kf-O7 for ietf-http-wg-dist@listhub.w3.org; Thu, 01 Sep 2016 04:58:08 +0000
Resent-Date: Thu, 01 Sep 2016 04:58:08 +0000
Resent-Message-Id: <E1bfK4m-0000Kf-O7@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1bfK4b-0000JW-Iw for ietf-http-wg@listhub.w3.org; Thu, 01 Sep 2016 04:57:57 +0000
Received: from mail-wm0-f54.google.com ([74.125.82.54]) by lisa.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1bfK4O-00017T-30 for ietf-http-wg@w3.org; Thu, 01 Sep 2016 04:57:54 +0000
Received: by mail-wm0-f54.google.com with SMTP id c133so59113784wmd.1 for <ietf-http-wg@w3.org>; Wed, 31 Aug 2016 21:57:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Y6N/gQM8SiksJM33t9Swv+RrntAOf8Zvl1dKGQ4I9LM=; b=JmYAO+kZVBjb4WAFPsnNnZm7aCcNmo5PeEZYMBMlQNkVylj7nMrT6XkP98tGUWZGd2 sQyK2kAdN6Q7L4S698M7iD6nvSFMjhYdkvUCp6eR5CsK+Txbdjyo7whaI/+iND44kst2 VDdBONgPJQ+v3SDAlezF1qMkmXI7bYgCQspd6C7MIhRT0MsF4ZrlAv9UeTZU1ha3Ae17 22gTEuHTSUoLl4w08m1LaeFEZzIEdbAlVC7ZXqXMAhcvaX4JjOiWT+0Gp3iBd6nyfINu 1f28XGTS4b8oWXWECF2GGJFF/5s4ly4ul9x2GVmWS81ryr/gygjkgKTJRTQnlbUGMM0r Fptw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y6N/gQM8SiksJM33t9Swv+RrntAOf8Zvl1dKGQ4I9LM=; b=D7k3kwNuwsB/E1rxLhPocLewOQcV7xq0ek8COlOssu/NyAHBXWVe2q2XgeDnPpKRIF C4uxkyCIPAJFo1tmeYytXN7v7fruFm+aNIbMQZ4sLiIola25mFrb+uLrOERUfV/NVZYt Oi9PGt+vcBiI39KZEfY5CQmw7Rom/ol9bPKq6mZ7/d0aGJN9OsBf8pq+mui8lMEkD2Vf 8I5c690+EIqhj3XM+1+06DNapeJd1KWP9WG/ZWihukcz9noiNJf9GzYmhYNQvPwC37bL uF0CAtZq/ZyWElD1lQWqzp9f6RITdLW8U93ItDRm/eevNQmCW1Oal+WwDdipRG+gVLGe QmEQ==
X-Gm-Message-State: AE9vXwO/kWmn2VddnGGmrs0uknxs3wgEupErgMyae5eKqK8eM9oxBna8pFs9ebXb1tz4lbJ+9yo9TzHaAc1AKQ==
X-Received: by 10.28.212.211 with SMTP id l202mr13424391wmg.109.1472705836599; Wed, 31 Aug 2016 21:57:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.122.67 with HTTP; Wed, 31 Aug 2016 21:57:15 -0700 (PDT)
In-Reply-To: <CACZw55mUg_VjN3Q6TqPCb6udo3mQpoWQVNV5e2iYiNj=hC-2kw@mail.gmail.com>
References: <CACZw55mUg_VjN3Q6TqPCb6udo3mQpoWQVNV5e2iYiNj=hC-2kw@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 01 Sep 2016 13:57:15 +0900
Message-ID: <CANatvzz0rBjkgV4yS+2hgspUj7wZ6y=NqojPyzHiPpvZVXzwEA@mail.gmail.com>
To: Tom Bergan <tombergan@chromium.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=74.125.82.54; envelope-from=kazuhooku@gmail.com; helo=mail-wm0-f54.google.com
X-W3C-Hub-Spam-Status: No, score=-5.0
X-W3C-Hub-Spam-Report: AWL=-1.280, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=1, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: lisa.w3.org 1bfK4O-00017T-30 b6b4c57b492fb3c769e393e2ff319e51
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Experiences with HTTP/2 server push
Archived-At: <http://www.w3.org/mid/CANatvzz0rBjkgV4yS+2hgspUj7wZ6y=NqojPyzHiPpvZVXzwEA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32368
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>
Hi, 2016-08-04 9:21 GMT+09:00 Tom Bergan <tombergan@chromium.org>: > Hi all, > > Our team has been experimenting with H2 server push at Google for a few > months. We found that it takes a surprising amount of careful reasoning to > understand why your web page is or isn't seeing better performance with H2 > push. We also encountered a lack of good documentation: How should one go > about using H2 push? What are the best practices? We tried to distill our > experiences into five "rules of thumb" that are described in this doc: > https://docs.google.com/document/d/1K0NykTXBbbbTlv60t5MyJvXjqKGsCVNYHyLEXIxYMv0 Sorry for the late response. I have recently had a chance to discuss the details of the document. It is a great summary of what the issues related to push are. On the other hand, it makes me sad that the fifth rule states "Consider Preload Instead of Push". While I understand that not using push could be a short term answer on some deployments, I think we need to discuss how we should fix the issues (detailed as first four rules) to make the Web faster using push in the long term. And my take against the issues raised in the document are as follows: "Rule 1: Push Enough to Fill Idle Network Time, and No More": Technically, HoB caused by a low-priority stream is an issue irrelevant to push. Consider the case where a large HTML that loads a CSS is sent over the wire. In a typical implementation, the server will pass a block of HTML much larger than INITCWND to the TCP stack before recognizing the request for CSS. So the client would need to wait for multiple RTTs before starting to receive the CSS. It is only the case that such inversion of priority (a lower-prioritized response blocking a higher one) might happen more frequently when push is used. That said, as discussed at the workshop, it is possible to implement a HTTP/2 server that does not get affected by HoB between the different streams (see https://github.com/HTTPWorkshop/workshop2016/blob/master/talks/tcpprog.pdf). I would suggest that regardless of whether or not push is used, server implementors should consider adopting such approach to minimize the impact of HoB. It should also be noted that with QUIC such HoB would not be an issue since there would no longer be a send buffer within the kernel. "Rule 2: Push Resources in the Right Order" My take is that the issue can / should be solved by clients sending PRIORITY frames for pushed resources when they observe how the resources are used, and that until then servers should schedule the pushed streams separately from the client-driven prioritization tree (built by using the PRIORITY frames). Please refer to the discussion in the other thread for details: https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0453.html "Rule 3: Don’t Push Resources the Client has Already Cached" As the document states, the short-time solution would be for a server to track what it has pushed to the client, and ultimately (and hopefully) the standardization of cache-digests would solve the issue. "Rule 4: Use the Right Cookies" I think this is a very interesting point. As a server implementor, I have always dreamt of cancelling a push after sending a PUSH_PROMISE. In case a resource we want to push exists on a dedicate cache that cannot be reached synchronously from the HTTP/2 server, the server needs to send PUSH_PROMISE without the guarantee that it would be able to push a valid response. It would be great if we could have an error code that can be sent using RST_STREAM to notify the client that it should discard the PUSH_PROMISE being sent, and issue a request by itself. With such an error code, it would be possible for a server to speculatively push a resource by fetching it on behalf of the client (without cookies etc.) and if it fails, then let the client fetch the resource (with all the appropriate credentials / conditions). > The doc is a little long, but the first two pages give a decent tl;dr. I > suspect the ideas and conclusions will be "obvious" to many people on this > mailing list, at least in hindsight. Hopefully other folks interested in H2 > server push will find this useful. Let us know if you have any comments. > > -Tom, Simon, and Michael -- Kazuho Oku
- Re: Experiences with HTTP/2 server push Matthew Kerwin
- Re: Experiences with HTTP/2 server push Kazuho Oku
- Re: Experiences with HTTP/2 server push Martin Thomson
- Re: Experiences with HTTP/2 server push Kazuho Oku
- Re: Experiences with HTTP/2 server push Tom Bergan
- Re: Experiences with HTTP/2 server push Martin Thomson
- Re: Experiences with HTTP/2 server push Alcides Viamontes E
- Re: Experiences with HTTP/2 server push Tom Bergan
- Re: Experiences with HTTP/2 server push Amos Jeffries
- Re: Experiences with HTTP/2 server push Alcides Viamontes E
- Re: Experiences with HTTP/2 server push Martin Thomson
- Experiences with HTTP/2 server push Tom Bergan
- Re: Experiences with HTTP/2 server push Tom Bergan
- Re: Experiences with HTTP/2 server push Kazuho Oku
- Re: Experiences with HTTP/2 server push Tom Bergan
- Re: Experiences with HTTP/2 server push Tom Bergan
- Re: Experiences with HTTP/2 server push Kazuho Oku
- Re: Experiences with HTTP/2 server push Bryan McQuade