Squid’s HTTP Acceleration Mode

I have recently configured a server of mine to use the Squid Cache in HTTP Acceleration mode. So what’s this anyway?

A typical request to a webserver looks like this: Client browser opens connection to server port 80, server sends back the data through that connection. For the time of the transfer the server “loses” one child process. So if a client with a slow connection requests a large file this can take some minutes. If many slow clients block child processes, eventually too few will be left for “ordinary” clients.

A solution for this is to prepend a proxy server to the HTTP server. The proxy server is lightweight and does the communication with the client browser. The communication with the web server is done via a high speed interface (either loopback when it’s just one server or an lan with 100(0) mbit), so almost no time is spent waiting for a transfer to finish.

Setup is easy, and I’ve covered this in my thesis already.

But I’ve got some more real-life info for you.

There are two usual ways for setting this up.

  1. Set the web server to listen on port 81, Squid on 80.
  2. Web server still listens on port 80 but just for 127.0.0.1, the loopback interface. Squid listens on port 80 on the external interface.

What makes number two the favourable is that you are not haveing a server process listening on an unconventional port, and, for redirects (Location: /somewhereelse) the port number is correct (see the corresponding question in the Squid FAQ). For existing configurations with virtual hosts there is no need to change a < VirtualHost *:80> to < VirtualHost *:81>.

So in ports.conf of Apache, for example, you change this:

# Listen 80
Listen 127.0.0.1:80

In squid.conf you do these changes (apart from those listed in my thesis):

# http_port 3128
http_port ip.add.re.ss:80

So this works nice already, but there is one more thing. Now the source address for a http request is 127.0.0.1. So if you want to do some processing with the REMOTE_ADDR, for example in PHP, you’d have to insert something like this before you’d could use the address again.

if (isset($_SERVER["HTTP_VIA"])) {
// squid http accel
$_SERVER["REMOTE_ADDR"] = $_SERVER["HTTP_X_FORWARDED_FOR"];
}

Also in the log files there is now a 127.0.0.1 as source instead of the real ip address. The following changes things back to normal (in apache2.conf):

# LogFormat "%h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined
LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined

This should be all for now. Happy speed-boosting ;)

News about E-Ink

E Ink: Entwickler-Kit mit elektronischem Papier – Golem.de
(the corresponding PR announcement)

go on, go on, go on. that’s what i want. i don’t like reading on the screen very much. i waste tons of paper just for printing internet pages and reading them, e.g. while travelling around through vienna by tram.

unfortunately the e-book device development seems to have stopped in 2002. i hope that this will push forward new products, although i believe there wouldn’t be an affordable one within 2 years. in the u.s. give europe another year. :o/

an additional note to the hardware developers: don’t even think about a two-display/double-page e-book device. that’s what i always hated about books. when reading while lying the next page is always uncomfortable to read.

still one more: don’t mess around with supporting a lot of document formats. just pdf will do (flexible os’es let you save any printed document as pdf).

ahh. one more: underlining words on such a device would be too much comfort for the beginning. needing a touchable display it would be too much work. postpone it. please.

now for the last point: use e-ink. it only needs energy for displaying new pages. this will make the battery as long lasting as i want it to be.

e-ink, e-book, pdf