FIGURE 2.1 HTTP client/ server interaction

FIGURE 2.1 HTTP client/ server interaction document (infocom/index.html), and the protocol version that the browser is using (HTTP/1.0). The server daemon identifies the three components of the message and attempts to locate the file (step 4).

In step 5 the daemon sends a status line and a description of the information that it will send. Result code 200 indicates that the client request was successful and that the document is to follow. The message also contains information about the server software, the length of the document (414 bytes), and the content type of the document (text/html). If the request was for an image, the type might be image/gif. If the request is not successful, the server sends a different result code, which usually indicates the type of failure, for example, 404 when a document is not found.

In step 6 the HTTP daemon sends the file over the TCP connection and then proceeds to close the connection (step 7). In the meantime, the client receives the file and displays it (step 8). To fetch images that may follow the above document, the browser must initiate additional TCP connections followed by GET interactions.2

The HTTP example clearly indicates that a protocol is solely concerned with the interaction between the two peer processes, that is, the client and the server. The protocol assumes that the message exchange between peer processes occurs directly as shown in Figure 2.1. Because the client and server machines are not usually connected directly, a connection needs to be set up between them. In the case of HTTP, we require a two-way connection that transfers a stream of bytes in correct sequential order and without errors. The TCP protocol provides this type of communication service between two machines connected to a network. Each HTTP process inserts its messages into a buffer, and TCP transmits the contents of the buffer to the other TCP process in blocks of information called segments, as shown in Figure 2.2. Each segment contains port number information in addition to the HTTP message information. HTTP is said to use the service provided by TCP in an underlying layer. Thus the transfer of messages between HTTP client and server in fact is virtual and occurs indirectly via the TCP connection as shown in Figure 2.2. Later you will see that TCP, in turn, uses the service provided by IP.

2The student may verify the above message exchange by using a Telnet program. See problem 49.

FIGURE 2.2 TCP provides a pipe between the HTTP client and HTTP server

Example—DNS Query

The HTTP example notes that the client needs to first perform a DNS query to obtain the IP address corresponding to the domain name. This step is done by sending a message to a DNS server. The DNS is a distributed database that resides in multiple machines on the Internet and is used to convert between names and addresses and to provide e-mail routing information. Each machine maintains its own database and acts as a DNS server that other systems can query. A protocol has been defined whereby a DNS query can initiate a series of interactions in the DNS system to resolve a name or address. We now consider a simple case where the resolution takes place in the first server. Table 2.2 shows the basic steps required for this example.

After receiving the address request, a process in the host, called the resolver, composes the message shown in step 2 and sends it to the local server using the User Datagram Protocol (UDP) communication service. The OPCODE value in the header indicates that the message is a standard query. The question portion of the query contains the following information: QNAME identifies the domain name that is to be translated. The DNS server can handle a variety of queries, and the type is specified by QTYPE. In the example, QTYPE = A requests a translation of a name to an IP address. QCLASS requests an Internet address (some name servers handle non-IP addresses).

The message returned by the server has the Response and Authoritative Answer bits set in the header. This setting indicates that the response comes from an authority that manages the domain name. The question portion is identical to that of the query. The answer portion contains the domain name for which the address is provided. This portion is followed by the Time-to-Live field, which specifies the time in units of seconds that this information is to be cached by the client. Next are the two values for QCLASS and QTYPE. IN again indicates that it is an Internet address. Finally, the address of the domain name is given.

In this example the DNS query and response messages are transmitted by using the communication service provided by the User Datagram Protocol. The UDP client attaches a header to the user information to provide port

Event Message content

1. Application requests name to address translation.

2. Resolver composes query message.

3. Resolver sends UDP datagram encapsulating the query message.

4. DNS server looks up address and prepares response.

5. DNS sends UDP datagram encapsulating the response message.

TABLE 2.2 DNS query and response information (port 53 for DNS) and encapsulates the resulting block in an IP packet. The UDP service is connectionless; no connection setup is required, and the datagram can be sent immediately. Because DNS queries and responses consist of short messages, UDP is ideally suited for conveying them.

The DNS example shows again how a protocol, in this case the DNS query protocol, is solely concerned with the interaction between the client and server processes. The example also shows how the transfer of messages between client and server, in fact, is virtual and occurs indirectly via UDP datagrams.

Was this article helpful?

0 0

Post a comment