Re: Re[2]: Some proxy needs

"Nicolas Mailhot" <nicolas.mailhot@laposte.net> Tue, 10 April 2012 10:37 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 8C61B21F85DD for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 10 Apr 2012 03:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.515
X-Spam-Level:
X-Spam-Status: No, score=-10.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, 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 LYenE6SUtp2Q for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 10 Apr 2012 03:37:25 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id ECBD921F8628 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 10 Apr 2012 03:37:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SHYRP-00045g-Rj for ietf-http-wg-dist@listhub.w3.org; Tue, 10 Apr 2012 10:36:51 +0000
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <nicolas.mailhot@laposte.net>) id 1SHYRI-00044r-5I for ietf-http-wg@listhub.w3.org; Tue, 10 Apr 2012 10:36:44 +0000
Received: from smtpout5.laposte.net ([193.253.67.230] helo=smtpout.laposte.net) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <nicolas.mailhot@laposte.net>) id 1SHYRB-0001It-Sv for ietf-http-wg@w3.org; Tue, 10 Apr 2012 10:36:42 +0000
Received: from arekh.dyndns.org ([88.174.226.208]) by mwinf8509-out with ME id wAcA1i00B4WQcrc03AcAjb; Tue, 10 Apr 2012 12:36:11 +0200
Received: from localhost (localhost.localdomain [127.0.0.1]) by arekh.dyndns.org (Postfix) with ESMTP id 5FE478B90; Tue, 10 Apr 2012 12:36:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at arekh.dyndns.org
Received: from arekh.dyndns.org ([127.0.0.1]) by localhost (arekh.okg [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEuqZPK-ZYir; Tue, 10 Apr 2012 12:36:07 +0200 (CEST)
Received: from arekh.dyndns.org (localhost.localdomain [127.0.0.1]) by arekh.dyndns.org (Postfix) with ESMTP; Tue, 10 Apr 2012 12:36:07 +0200 (CEST)
Received: from 192.196.142.27 (SquirrelMail authenticated user nim) by arekh.dyndns.org with HTTP; Tue, 10 Apr 2012 12:36:07 +0200
Message-ID: <9b15ace004eef739f35a92b2d88f55c7.squirrel@arekh.dyndns.org>
In-Reply-To: <CAOXZevCjUMvXa6cdZHpqddF74HAwps1AuU+6tPBo5279ksVQsg@mail.gmail.com>
References: <83903.1333917310@critter.freebsd.dk> <0edc27e8599b098be0f9a3bf18a1653f.squirrel@arekh.dyndns.org> <CAOXZevDfCT4Zk=5v=cHhtfsFWYc++en_Y0FL+MCBg1yAASdNyQ@mail.gmail.com> <a2831da7ae0f6b68d3e006009cd44a52.squirrel@arekh.dyndns.org> <CAOXZevCjUMvXa6cdZHpqddF74HAwps1AuU+6tPBo5279ksVQsg@mail.gmail.com>
Date: Tue, 10 Apr 2012 12:36:07 +0200
From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
To: Per Buer <perbu@varnish-software.com>
Cc: Nicolas Mailhot <nicolas.mailhot@laposte.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
User-Agent: SquirrelMail/1.4.22-7.fc18
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Received-SPF: pass client-ip=193.253.67.230; envelope-from=nicolas.mailhot@laposte.net; helo=smtpout.laposte.net
X-W3C-Hub-Spam-Status: No, score=-1.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01
X-W3C-Scan-Sig: lisa.w3.org 1SHYRB-0001It-Sv 1de8f04af6ba9be3bbf1c4a87679e4f6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Re[2]: Some proxy needs
Archived-At: <http://www.w3.org/mid/9b15ace004eef739f35a92b2d88f55c7.squirrel@arekh.dyndns.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13421
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>
Resent-Message-Id: <E1SHYRP-00045g-Rj@frink.w3.org>
Resent-Date: Tue, 10 Apr 2012 10:36:51 +0000

Le Mar 10 avril 2012 11:23, Per Buer a écrit :
> Nicholas, list,
>
> On Tue, Apr 10, 2012 at 8:56 AM, Nicolas Mailhot
> <nicolas.mailhot@laposte.net> wrote:
>>
>>
>> > So, if the proxy farm fails to hash incoming requests on source IP or
>> > target URL then this might happen.
>>
>> That breaks load balancing as soon as your network is big enough, with
>> different parts that get active at different points of the day.
>
> Sorry if I seem to miss the point, but why would it break? Are you worried
> that one point in the farm would get too hot?

I'm worried first that the activity distribution changes over time (so a
static table does not work), and second that any network-wide state (such as
an hashtable) is a contention point and potential spof. Making an individual
gateway smarter is simple (scaling the farms is just the matter of adding new
boxes). Making balancing smart and robust when some gateways or even some
physical processing sites can go down at any time is hard.

That's why direct browser-to-proxy communication will always be preferred and
more reliable than depending on a magical holistic hashtable balancer.
Round-robin is dumb but robust and stateless.

>> And anyway even if your solution was possible, you still get unhappy users
>> that serial refresh because they're not seeing initial progress in their web
>> clients
>
> If the loadbalancer was balancing on target URLs the request would end up at
> the same proxy. The proxy should be smart enough to coalesce the request
> into the ongoing one and this one could feed the user a couple of bytes so
> at the client understands that there is some progress on the download as
> some proxies have done for years.

Can't do when inspecting for malware. Malware inspection is not streamable,
you need to decompress recursively all the container formats (isos, zips,
jars, etc) to inspect the content before feeding the first byte to clients.
Just decompressing the container often requires the full file to have been
received proxy-side before starting the processing. The gateway could tell the
browser it's working on its request, but not give it part of the file.

-- 
Nicolas Mailhot