HTTP Operational Model and Client/Server Communication

he Hypertext Transfer Protocol is the application-layer protocol that implements the World Wide Web. While the Web itself has many different facets, HTTP is only concerned with one basic function: the transfer of hypertext documents and other files from Web servers to Web clients. In terms of actual communication, clients are chiefly concerned with making requests to servers, which respond to those requests.

Thus, even though HTTP includes a lot of functionality to meet the needs of clients and servers, when you boil it down, what see is a very simple, client/server, request/response protocol. In this respect, HTTP more closely resembles a rudimentary protocol like BOOTP orARP than it does other application-layer protocols likeFTP andSMTP, which all involve multiple communication steps and command/reply sequences.

Basic HTTP Client/Server Communication

In its simplest form, the operation of HTTP involves only an HTTP client, usually aWeb browser on a client machine, and an HTTP server, more commonly known as aWeb server. After a TCP connection is created, the two steps in communication are as follows:

1. Client Request: The HTTP client sends a request message formatted according to the rules of the HTTP standard—anHTTP Request. This message specifies the resource that the client wishes to retrieve, or includes information to be provided to the server.
   
   
2. Server Response: The server reads and interprets the request. It takes action relevant to the request and creates anHTTP Response message, which it sends back to the client. The response message indicates whether the request was successful, and may also contain the content of the resource that the client requested, if appropriate.
   

   Figure 315: HTTP Client/Server Communication

   In its simplest form, HTTP communication consists of an HTTP Request message sent by a client to a server, which replies with an HTTP Response.

    

   

   
   

In HTTP/1.0, each TCP connection involves only one such exchange, as shown inFigure 315; in HTTP/1.1, multiple exchanges are possible, as we'll see in the next topic. Note also that the server may in some cases respond with one or preliminary responses prior to sending the full response. This may occur if the server sends a preliminary response using the “100 Continue” status code prior to the “real” reply.See the topic on HTTP status codes for more information.

Key Concept:HTTP is a client/server-oriented, request/reply protocol. Basic communication consists of anHTTP Request message sent by an HTTP client to an HTTP server, which returns anHTTP Response message back to the client.

ntermediaries and The HTTP Request/Response Chain

The simple request/response pair between a client and server becomes more complex whenintermediaries are placed in the virtual communication path between the client and server. These are devices such asproxies, gateways or tunnels that are used to improve performance, provide security or perform other necessary functions for particular clients or servers. Proxies are particularly commonly used on the Web, because they can greatly improve response time for groups of related client computers.

When an intermediary is involved in HTTP communication, it acts as a “middleman”. Rather than the client speaking directly to the server and vice-versa, they each talk to the intermediary. This allows the intermediary to perform functions such as caching, translation, aggregation, or encapsulation. For example, consider an exchange through a single intermediary device. The two-step communication process above would become four steps:

1. Client Request: The HTTP client sends a request message to the intermediary device.
   
   
2. Intermediary Request: The intermediary processes the request, making changes to it if necessary. It then forwards the request to the actual server.
   
   
3. Server Response: The server reads and interprets the request, takes appropriate action and then sends a response. Since it received its request from the intermediary, its reply goes back to the intermediary.
   
   
4. Intermediary Response: The intermediary processes the request, again possibly making changes, and then forwards it back to the client.

As you can see, the intermediary acts as if it were a server from the client's perspective, and as a client from the server's viewpoint. Many intermediaries are designed to be able to “intercept” a variety of TCP/IP protocols, by “posing” as the server to a client and the client to a server. Most protocols are unaware of the existence of the interposition of an intermediary in this fashion. HTTP, however, includes special support for certain intermediaries such as proxy servers, providing headers that control how intermediaries handle HTTP requests and replies.

It is possible for two or more intermediaries to be linked together between the client and server. For example, the client might send a request to intermediary 1, which then forwards to intermediary 2, which then talks to the server; see Figure 316. The process is reversed for the reply. The HTTP standard uses the phrase request/response chain to refer collectively to the entire set of devices involved in an HTTP message exchange.

Figure 316: HTTP Request/Response Chain Using Intermediaries

Instead of being connected directly, an HTTP client and server may be linked using one or more intermediary devices such as proxies. In this example, two intermediaries are present. TheHTTP Request sent by the client will actually be transferred three times: from the client to the first intermediary, then to the second, and finally to the server. TheHTTP Response will likewise be created once but transmitted three distinct times. The full set of devices participating in the message exchange is called the request/response chain.

 

Key Concept:The simple client/server operational model of HTTP is complicated when intermediary devices such as proxies, tunnels or gateways are inserted in the communication path between the HTTP client and server. HTTP/1.1 is specifically designed with features to support the efficient conveyance of requests and responses through a series of steps from the client through the intermediaries to the server, and back again. The entire set of devices involved in such a communication is called therequest/response chain.

The Impact of Caching on HTTP Communication

The normal HTTP communication model is changed through the application ofcaching to client requests. Caching is employed by various devices on the Web to store recently-retrieved resources so they can be quickly supplied in reply to a request. The client itself will cache recently-accessed Web documents so that if the user asks for them again they can be displayed without even making a request to a server. If a request is in fact required, any intermediary device can satisfy a request for a file if the file is in its cache.

When a cache is used, the device that has the cached resource requested returns it directly, “short-circuiting” the normal HTTP communication process. In the example above, if intermediary 1 has the file the client needs, it will supply it back to the client directly, and intermediary 2 and the real Web server that the client was trying to reach originally will not even be aware that a request was ever made;the topic on HTTP caching discusses the subject in much more detail.

Note:Most requests for Web resources are made using HTTP URLs based on a Domain Name System (DNS) host name. The first step in satisfying such requests is to resolve the DNS domain name into an IP address, but this process is separate from the HTTP communication itself.