Now it's time for the site to return the file. Every time a server sends a document to a browser, it also sends an HTTP/1.0 response with a status (Found or 404 Not Found) to the client. This is followed by a series of headers that describe the content type, when the document was last modified, and the server type.
The server's response looks something like this:
HTTP/1.0 200 Found
Date: Mon, 10 Feb 1997 23:48:22 GMT
Server: Apache/1.1.1 HotWired/1.0
Content-type: text/html
Last-Modified: Tues, 11 Feb 1997 22:45:55 GMT
|
Different Content-type lines are also returned for each type of item on a page that isn't text/html. (If there are GIFs and JPEGs, the content would be image/gif and image/jpeg.) Because of this, the client and server must talk about everything on the page, which can make things a little slow.
TCP and KeepAlive
Here's where things get a little more complicated. When a server sends a document to a browser, it's usually broken into several packets and then reassembled by the client. TCP is so efficient because it allows the network to choose routes for the packets based on the best connection at any given moment.
TCP may guarantee that your data will get from point A to point B in one piece, but it also requires a lot of work. It wasn't long ago that browsers had to make a separate connection for each transaction for every item on a page. That wasted a lot of time and bandwidth. To remedy this problem, KeepAlive was introduced in the HTTP1.1 spec. It allows the client to make several requests from one connection. Most servers support KeepAlive. Until recently, browser support was a little sketchy, but Navigator 3.x and Internet Explorer 3.x seem to have worked out the bugs.
