Internet Technologies. Session 7

Internet Technologies I, Session 7. HTTP. 7 December 01.

0. History

"There is an experimental W3 server for the SPIRES High energy Physics preprint database, thanks to Terry Hung, Paul Kunz and Louise Addis of SLAC. It's only just been put up, so don't expect perfection" (Tim Berners-Lee, www-talk mailing list, 13 December 1991, commenting on the setting up of the first web server in the U.S.).

1. HTTP

HTTP is one of the principal components of "the web". These consist of some data formats (HTML...), an addressing scheme (URI), and a network protocol (HTTP)
- "The value of a common document language has been so enormous that HTML has gained a dominance on the Web, but it does not play a fundamental key role. Web applications are required to be able to process HTML, as it is the connective tissue of the Web, but it has no special place architecturally" (Berners-Lee, http://www.w3.org/DesignIssues/Architecture.html)
- "The most fundamental specification of Web architecture, while one of the simpler, is that of the Universal Resource Identifier, or URI" (Berners-Lee, http://www.w3.org/DesignIssues/Architecture.html)
- "Actually, the HTTP protocol is not t[h]e most important thing for people to use. There will always be many S&R ...[i.e., search and retrieve]... protocols. The W3 addressing syntax is much more important" (Berners-Lee, www-talk mailing list, 18 February 1992)
HTTP is a stateless, request/response application protocol that has evolved over time.
- Stateless: HTTP doesn't inherently involve a notion of a "session" (regardless of how a sequence of HTTP requests and responses may happen to map to underlying TCP connections). Unfortunately we desperately need state for many web applications (shopping-carts...). State has been glued onto HTTP in the form of "cookies" (Set-Cookie and Cookie headers), the use of which is described in protocol documents (RFCs 2964 and 2965) supplemental to the main one (HTTP 1.1 is defined in RFC 2616 of 6/99).
- Evolution: HTTP history can be described schematically in terms of a sequence of official versions (0.9, 1.0, 1.1), but the real history is far messier--this is one case in which implementation and standardization have, at times, had little to do with one another. One thing that's notable about HTTP is that there's not currently major revision work underway--basically we're going to be stuck for awhile with HTTP as we now have it.
Elements using HTTP: clients (browsers, spiders...), servers, proxies (caching, filtering, transforming, anonymizing...)
Interactions with the transport layer (TCP and HTTP aren't really optimally suited for one another; each has been modified to a degree to accommodate the presence of the other)
- HTTP originally required a separate TCP connection per web object transferred. As web pages became increasingly composite in character--in particular as they came typically to include numerous embedded graphics--this entailed an increasing amount of protocol overhead. Improvements:
  - Run multiple connections simultaneously (early Netscape browsers)
  - Use persistent connections (after the initial transfer, leave the connection open--on the chance that the client will make another request)
  - Persistence and pipelining (use persistent connections and allow the client to pipeline requests--i.e., send a bundle of requests simultaneously rather than waiting 'til a given transfer completes to send the next request. Persistence and pipelining is default behavior under HTTP 1.1; however servers in the wild don't necessarily leave connections open forever (each open connection entails resource allocation at the server); further, persistent + pipelined HTTP connections can still run into difficulties under some circumstance--consider "head of line blocking": responses still need to come back in sequential order, and if there's delay for some reason in completing the first of a set of requests, all subsequent ones are also delayed)
- "The war of mice and elephants": part of TCP's adaptive behavior consists of trying to find an appropriate data transfer rate by gradually ramping up the send rate from the start of a connection (= "slow start"). Since however HTTP transfers are typically small, it's often the case that these transfers complete before TCP has found the optimal transmission rate (= web objects are often transferred more slowly than they really need to be). One response to this situation has been to relax the restrictions imposed by slow start--originally the initial "congestion window" for a connection was defined to be one Maximum Segment Size (MSS), i.e., one packet; recent RFCs now allow a sender to send up to four segments at the beginning of a connection.
HTTP messages
- HTTP is a text-based protocol whose messages (since 1.0) take the form of a request or status line (depending on whether the message is a request or a response), followed by a set of header lines, followed by a blank line, followed by a body
- ...where a request line takes the form: {method} (the kind of operation requested--by far most commonly GET, but also POST and HEAD) + {URL} + HTTP/{version}; and where a status line takes the form: HTTP/{version} + {status code} + {reason phrase} (a text blurb elaborating on the status code); and where a header takes the form: {keyword} + : + {value}
- HTTP 1.0 headers
  - Prior to HTTP 1.0, HTTP responses included no header material: the server just blasted out the response body and then shut down the TCP connection. The client didn't know in advance how much data was coming; nor did the client have any way of differentiating among data types--the only thing that could be sent was text, possibly with HTML markup. Among the headers introduced in HTTP 1.0 is Content-Type, which takes as a value a string representing a MIME type, and whose inclusion allows a server to signal to a client the type of material being delivered. Further Content-Length informs the client how much data's coming down the pipe.
  - Authentication-related: server sends "WWW-Authenticate: Basic realm={foo}" in a 401 response, client responds with "Authorization: Basic {base64 encoded userid + pw}". N.b. base64 encoding amounts to sending your password in plaintext.
  - Caching-related: server can send a response with "Expires" and "Last-Modified". The client can subsequently do a conditional fetch on the object with "If-Modified-Since".
- HTTP 1.1
  - Support for TCP persistent connections, as above
  - Additional request methods (PUT, DELETE, OPTIONS, TRACE, CONNECT)
  - Headers
    - Support for "name-based" virtual hosting with the "Host" header. Web serving originally didn't scale very well in the sense that hosting a single domain essentially required a distinct server and a distinct IP address. This was a consequence of the fact that the URL in the HTTP request line only specifies an on-machine path--there was no way to host multiple domains and distinguish among requests for them from the URL alone (whose "/index.html" is being referred to?). IP-based virtual hosting involved assigning multiple IP addresses to a server's network interface, associating each of those addresses with a different domain-to-be-served, and distinguishing intended request domain from the destination address of an in-bound request. This helped economize on the total number of machines needed to serve web material, but wasn't economical with (scarce) IP addresses. Name-based virtual hosting allows a server to distinguish intended request domain on the basis of the HTTP request itself--not from the URL, but from the Host header, obligatory in 1.1. Apache can be configured to do both name- and IP-based virtual hosting. Here's a chunk from httpd.conf on zonorus.marlboro.edu showing what the configuration of each looks like:
```
<VirtualHost 216.114.150.12>
DocumentRoot /home/uww/html
ServerName www.unitedwaywindham.org
Options None
ErrorLog logs/unitedwaywindham_error_log
TransferLog logs/unitedwaywindham_access_log
</VirtualHost>

<VirtualHost marlboro.vt.us>
DocumentRoot /home/town/html
ServerName marlboro.vt.us
ErrorLog logs/town_error_log
TransferLog logs/town_access_log
ScriptAlias /cgi-bin/ /home/town/html/cgi-bin/
</VirtualHost>
        
```
    - Better support for caching with the Cache-Control and Etag headers
    - Support for content negotiation with Accept*
    - Support for fetching partial objects with Range/Content-Range
- Two request/response examples from nature:
```
; request apparently from a regular browser
GET /Images/paint.jpg HTTP/1.1
Accept: */*
Referer: http://www.marlboro.edu/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)
Host: www.marlboro.edu
Connection: Keep-Alive

HTTP/1.1 200 OK
Date: Fri, 07 Dec 2001 17:34:54 GMT
Server: Apache
Last-Modified: Wed, 05 Dec 2001 17:14:07 GMT
ETag: "5874-bdd-3c0e55df"
Accept-Ranges: bytes
Content-Length: 3037
; "timeout" = timeout value for the connection; "max" = number of
; requests to accept over the connection; these values relate to
; the settings for KeepAliveTime and MaxKeepAliveRequests in Apache
Keep-Alive: timeout=15, max=93
Connection: Keep-Alive
Content-Type: image/jpeg


; request apparently from a search engine's crawler
; notice the 1.1 Host header in the 1.0 request
HEAD /~jamdalea/bicycle.au HTTP/1.0
Host: www.marlboro.edu
Accept: */*
User-Agent: Slurp.so/1.0 (slurp@inktomi.com; http://www.inktomi.com/slurp.html)
From: slurp@inktomi.com

HTTP/1.1 404 Not Found
Date: Fri, 07 Dec 2001 17:35:02 GMT
Server: Apache
Last-Modified: Tue, 27 Feb 2001 14:45:12 GMT
ETag: "31663-4aab-3a9bbd78"
Accept-Ranges: bytes
Content-Length: 19115
Connection: close
Content-Type: text/html
    
```

2. Web caching and replication

Motivation for caching
- Economize on network bandwidth utilization
- Reduce latency for users
- Reduce load on origin servers
It's not as if caching had to be discovered in the web context: this is a well-understood principle in computer system design in general.
Forms
- Browser-level caching
  - Typically the user gets to set values for cache size and frequency of cache consistency checks
  - There are a number of different products that claim to enhance the native caching scheme of browsers (e.g. "pre-fetchers")
  - The browser cache only benefits the individual browser user
- Network (shared) caching
  - There are many, many ways of implementing network caching. These range from software-only solutions (e.g. public domain Squid) to very sophisticated, and very expensive dedicated "appliances" (e.g. Network Appliance NetCache).
  - Explicitly point browsers at the cache (aka 'proxy'). Of course the browser has to let you do this, but it's painless in current versions--you set a preference and then the browser handles things automatically (note that the browser needs to know to change the form of a URL passed to a proxy to include the hostname); in the stone age you had to pass concatenated proxy-name + target-URL strings to the browser). Nonetheless, manual configuration is still required. There are some auto-config proposals on the table (e.g. WPAD), but they haven't exactly taken the world by storm
  - Sequence: request goes from browser to proxy: if object cached (and 'fresh'), return it immediately to the client; if object in cache (and 'stale'), revalidate; if object not in cache, contact origin server. Server responds to the proxy, proxy passes the object back to the client and also (if it's an object of the right type) caches it.
  - A cache can also be inserted in front of a web server. This is known as "reverse proxy" or "server accelerator". The idea is to offload some processing to an optimized device.
  - The idea of caching has also been further elaborated to include a multiplicity of caches, arranged either hierarchically or in a distributed model. A number of inter-cache protocols have been developed, most notably ICP and CARP. You can think of these on analogy to the inter-router protocols used in regular IP forwarding.
  - Transparent (aka "interception") caching. Something in the normal datapath--a router or switch--is watching out for packets with a destination port of TCP/80, and automatically redirecting them to a proxy.
    
    Notice that the redirecting device is now looking 'deeper' into the packet than it would be for simple packet-forwarding purposes. We'll see that routers acting as packet-filtering firewalls do this kind of thing all the time, nonetheless there's been a marked movement towards hardware devices that read ever further into packets.
    Transparent caching is currently used extensively by ISPs. It's very controversial technology for both technical and political/legal reasons
    Here's an example of transparent proxy setup on a Linux router, using the "netfilter" facility:
```
#!/bin/sh
IPT=/sbin/iptables

# Add a rule to the prerouting rule chain of the NAT rules table. If you see a packet
# coming in on eth0 from an address other than that of the proxy device, and that
# packet is heading to TCP port 80 somewhere, change the destination addressing of the
# packet to that of the proxy device, TCP port 3128
$IPT -t nat -A PREROUTING -i eth0 -s ! 216.114.150.170 -p tcp --dport 80 -j DNAT --to 216.114.150.170:3128
# Now add a rule to the post-routing chain of the NAT table: if you see a packet with a
# local address going to the proxy box, change its source address to that of the
# router (i.e., if the router applies the first rule and changes the destination of a
# packet to be the proxy, it wants the proxy to return the response packets to the router
# (so it can "un-NAT" them).
$IPT -t nat -A POSTROUTING -s 216.114.150.0/23 -d 216.114.150.170 -j SNAT --to 216.114.150.1
# Basically the same rule as the previous one, only for a different block of internal
# addresses
$IPT -t nat -A POSTROUTING -s 10.0.0.0/14 -d 216.114.150.170 -j SNAT --to 216.114.150.1
```
Issues
- Technical
  - What do we cache? (where the possibilities include: static HTML, images, dynamically generated content, authenticated content, encrypted content...)
  - How long do we cache objects? Here we're up against the relative immaturity of web-related protocols--there's nothing as nice, neat, and simple (and universally observed) as the DNS TTL. HTTP is getting better at supporting caching, the difficulty is that the new headers aren't either generally used or generally honored. In the absence of explicit direction (i.e., from the origin server, in the form of HTTP headers), caches resort to various heuristics to determine object freshness (e.g. we take the ratio of time-since-last-validity check and age-of-object-at-last-validity-check, and say that 'fresh' = below a certain threshold)
  - Security (the cache makes an inviting target for hacking; do you trust your cache manager(s) anyway?)
- Non-technical
  - It messes with hit counts (there's a 'Hit Metering Proposal' that speaks to this issue; the idea is to have caches report hits back to origin servers)
  - The proxy is perfectly located to do filtering (should it?)
  - What rights does the cache owner have over cache logs? (per entry?; in aggregate?)
  - Copyright?
Replication
- Caching in the various forms discussed above involves the "on-demand" redistribution of objects from center (server) to periphery (user). There are also reasons for doing replication on the server-side: redundancy; load sharing (e.g. we load balance among different machines serving a very high volume website); economizing on network bandwidth (e.g. we distribute the load among different geographically-dispersed servers)
- Of course we could do this in the form of classical 'mirroring' (copy from central machine to n replicas; let the user choose which one he/she wants to access), but wouldn't it be nice if it happened automatically?
  - Round robin DNS: we keep multiple A records for a domain, lookups return the different IPs in turn. Nice, but pretty mechanical--we don't know whether a given machine is particularly busy, whether it's particularly close to the source of the request.
  - Load balancing. We've got a front-end box that users can get to via a publicly advertised domain name. It's connected to a set of servers whose performance it monitors, and to one of which it hands (following some algorithm) the next inbound request.
    - Again these products takes different forms: software only (IBM, Resonate...), dedicated hardware (Cisco LocalDirector, Alteon switches...)
    - Possible load-balancing algorithms: round-robin; static weights (by some notion of machine capacity); smallest number of current connections; least loaded, by some metric determined either externally or via some agent installed on the server
    - These devices are increasingly able to direct also based on URL or some other piece of HTTP request information (e.g. "everybody who wants static content should go to one of these machines over here"; or "this customer who's got an open shopping cart should always get directed to this particular server")
  - Distributed load balancing. Same basic scenario as above, only now the servers are geographically dispersed; and the algorithm used by the front-end box now involves consulting the network infrastructure to determine which server is topologically closest to the client. See for example Cisco Distributed Director.
  - "Content delivery networks" (CDNs). But you don't have to roll out your own distributed network, a number of companies--most notably Akamai--now offer this service. What this involves is:
    - First you tag your content (i.e. mark the links to the objects you're going to replicate with names in the domain of your CDN)
    - Then the objects are replicated
    - The CDN's nameserver directs the client to the "closest" server

IT Home | Notes