Gmail Technical Rant

[Graycode]

(Feb. 23, 2009 06:03 PM)sidki3003 Wrote:  Although it's a normal 204 reply (no content, no content-type), it keeps the connection open here for exactly 1 minute. So, while browsing a Picasa member directory, i end up with a bunch of open connections.

It's a bit surprising that Google is retaining the connection for that long. I think the use of long-term persistence may become less frequent.

As you mentioned, the 204 shouldn't have any content.

Code:

HTTP/1.1 204 No Content
Set-Cookie: _rtok=_TZCpJWNfBg1; Path=/
Set-Cookie: S=photos_html=cgJ3-InHjgaIXlwt69mDUw; Domain=.google.com; Path=/; HttpOnly
Date: Mon, 23 Feb 2009 18:16:20 GMT
X-Content-Type-Options: nosniff
Server: GFE/2.0

The server isn't explicitly specifying its Connection preference, so for HTTP/1.1 it defaults to being re-usable for subsequent requests. But then the questions become: For how long should the server remain connected, and for how long should the client proxy | browser hold on to it? For each, now many of those connections should be retained?

Some servers don't seem to be configured for particular persistent timeouts, it's an area that web software has been paying more attention to lately. I believe Apache still needs a resource (either a thread or process) for each persistent connection that's waiting for possible re-use. As more client browsers and speed-hungry users configure themselves for more connections & longer persistence, the servers now have to defend their available resources more.

IE version 8 has increased its number of persistent connections to each server. Opera used to be the most agressive at it. Mozilla's has also been "tweaking" their connection limits to push servers harder, and they've alreay responded to what IE 8 will do. I also noticed just the other day that a default Firefox installation was sending "Keep-Alive: 300" to Servers, indicating its intent of 5 minutes of persistence for every connection.

This weekend's new release of Privoxy now tries to retain server connections for several minutes indepenently of each client-side connection. I forget whether their default is 180 seconds or 300 for everything, and that proxy doesn't seem to be looking for or honoring any timeout that a server might specify in its Keep-Alive: header.

Some people who recommend increasing a browser's max-connections are really just demanding that servers defend themselves more & more. Examples include the sticky thread and related FAQ at http://www.dslreports.com/forum/mozilla

When a proxy is used, most browsers aren't bothering to abide by their "max-connections-per-Server" guidelines. They're leaving that completely up to the proxy and instead just oversee their total browser "max-connections". So, by using a proxy it's even more likely to have a lot of connections to a particular server if nothing's managing that aspect.

The battle rule is that clients & servers will play that game until the other side closes the connection. "I'm the fastest browser" does things that tries to defeat "I'm the most stable server".

I think recent Apache distributions are limiting the server's keep-alive persistence to 15 seconds by default.

This site's Apache uses 5 seconds, and after that amount of quiet time the server really does close the connections.

Code:

Keep-Alive: timeout=5, max=100
Connection: Keep-Alive

Some of that was mentioned in http://prxbx.com/forums/showthread.php?tid=639&page=5

Sorry I can't tell you how Proxo manages connections. If you'd like I could describe how my proxy does it, but that isn't necessarily going to be helpful to Proxo.

(Feb. 23, 2009 06:03 PM)sidki3003 Wrote:  The main pages OTOH come as "Transfer-Encoding: chunked". Quite often, and after a long delay, i see this instead of the rendered HTML:

I haven't seen that one before. It looks like the server connection was re-used, and the first "0" was the trailing part of a previous request's chunked response. That bogus header having the error URL sure implies it's another Google server screw-up mixing multiple responses together.