From owner-freebsd-hackers Sun Mar 8 07:42:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA07359 for freebsd-hackers-outgoing; Sun, 8 Mar 1998 07:42:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA07333 for ; Sun, 8 Mar 1998 07:42:10 -0800 (PST) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id IAA20732; Sun, 8 Mar 1998 08:42:02 -0700 (MST) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id IAA05393; Sun, 8 Mar 1998 08:31:21 -0700 (MST) Date: Sun, 8 Mar 1998 08:31:21 -0700 (MST) From: Marc Slemko To: Mike Smith cc: hackers@FreeBSD.ORG Subject: Re: kernel wishlist for web server performance In-Reply-To: <199803080802.AAA09131@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 8 Mar 1998, Mike Smith wrote: > > On Sat, 7 Mar 1998, Mike Smith wrote: > > > > > this regard (ie. have specific HTTP-transmit-file system calls > > > everywhere)? > > > > Now, if you want to talk about HTTP-transmit-file calls and things being > > specialized for just one protocol, I was actually joking about that > > earlier today. > > > > HTTP-NG, which is currently under very initial development, will > > almost certainly allow for multiplexed transfers. ie. multiple > > documents multiplexed over a single TCP connection. > > Ugh. Why multiplex over an already-multiplexing protocol? This sounds > like yet another attempt at trying to get around a problem with a new > solution rather than fixing the original one. No, there are very valid reasons for this. With HTTP/1.0, the web consists of many short flows. TCP's congestion control doesn't really handle them very well because of how short they are, plus you have too much overhead in terms of latency from establishing connections. With HTTP/1.1 and persistent and pipelined connections, it is better and almost ideal from a total transfer time point of view. However, total transfer time isn't what is important for web browsers: it is time to view. There are a lot of things involved here that I won't go into; eg. you can't have small responses stuck behind a large one. Simultaneous short connections are bad for the network in terms of congestion control, especially when you get to the point (which can be all to easy with a slow link and some dumb clients) where you have enough connections and a big enough MSS to result in extremely high numbers of unnecessary retransmissions. To get around this, you have to lower the MSS which isn't a good thing. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message