User Datagram Protocol (UDP)

UDP lies between the application layer and IP layer. Like TCP, UDP serves as the interme- diary between the application programs and network operations. UDP uses port numbers to accomplish a process-to-process communication. The UDP provides a flow-and-control mechanism at the transport level. In fact, it performs very limited error checking. UDP can only receive a data unit from the process, and deliver it to the receiver unreliably. The data unit must be small enough to fit in a UDP packet. If a process wants to send a small message and does not care much about reliability, it will use UDP. UDP is a connectionless protocol. It is often used for broadcast-type protocols, such as audio or video traffic. It is quicker and uses less bandwidth because a UDP connection is not continuously maintained. This protocol does not guarantee delivery of information, nor does it repeat a corrupted transfer, as does TCP.

UDP header

UDP receives the data and adds the UDP header. UDP then passes the user datagram to the IP with the socket addresses. IP adds its own header. The IP datagram is then passed to the data link layer. The data link layer receives the IP datagram, adds its own header and a trailer (possibly), and passes it to the physical layer. The physical layer encodes bits into electrical or optical signals and sends it to the remote machine. Figure 2.12 shows the encapsulation of a UDP datagram as an IP datagram. The IP datagram contains its total length in bytes, so the length of the UDP datagram is this total length minus the length of the IP header.

The UDP header is shown by the fields illustrated in Figure 2.13.

• Source port numbers (16 bits): This 16-bit port number identifies the sending process running on the source host. Since the source port number is 16 bits long, it can range from 0 to 65 656 bytes. If the source host is the client, the client program is assigned a random port number called the ephemeral port number requested by the process and chosen by the UDP software running on the source host. If the source host is the server, the port number is a universal port number.

IP header

UDP

header UDP data

UDP datagram IP datagram

20 bytes 8 bytes

Figure 2.12 UDP encapsulation.

Source port number (16 bits) Destination port number (16 bits)

UDP length (16 bits) Checksum (16 bits)

Data (if any)

0 15 16 31

Header (8 bytes)

Figure 2.13 UDP header.

• Destination port numbers (16 bits): This is the 16-bit port number used by the process running on the destination host. If the destination host is the server, the port number is a universal port number, while if the destination host is the client, the port number is an ephemeral port number.

• Length (16 bits): This is a 16-bit field that contains a count of bytes in the UDP datagram, including the UDP header and the user data. This 16-bit field can define a total length of 0 to 65 535 bytes. However, the minimum value for length is eight, which indicates an UDP datagram with only header and no data. Therefore, the length of data can be between 0 to 65 507 bytes, subtracting the total length 65 535 bytes from 20 bytes for an IP header and 8 bytes for an UDP header. The length field in a UDP user datagram is redundant. The IP datagram contains its total length in bytes, so the length of the UDP datagram is this total length minus the length of the IP header.

• Checksum (16 bits): The UDP checksum is used to detect errors over the entire user datagram covering the UDP header and the UDP data. UDP checksum calculations include a pseudoheader, the UDP header and the data coming from the application layer. The value of the protocol field for UDP is 17. If this value changes during transmission, the checksum calculation at the receiver will detect it and UDP drops the packet.

The checksum computation at the sender is as follows: 1. Add the pseudoheader to the UDP datagram.

2. Fill the checksum field with zero. 3. Divide the total bits into 16-bit words.

4. If the total number of bytes is not even, add padding of all 0s. 5. Complement the 16-bit result and insert it in the checksum field. 6. Drop the pseudoheader and any added padding.

7. Deliver the UDP datagram to the IP software for encapsulation. The checksum computation at the receiver is as follows:

1. Add the pseudoheader to the UDP datagram. 2. Add padding if needed.

3. Divide the total bits into 16-bit words. 4. Add all 16-bit sections using arithmetic. 5. Complement the result.

6. If the result is all 0s, drop the pseudoheader and any added padding and accept the user datagram. Otherwise, discard the user datagram.

Multiplexing and demultiplexing

In a host running a TCP/IP suite, there is only one UDP but there may be several processes that may want to use the services of UDP. To handle this situation, UDP needs multiplexing and demultiplexing.

• Multiplexing: At the sender side, it may have several processes that need user data- grams. But there is only one UDP. This is a many-to-one relationship and requires multiplexing. UDP accepts messages from different processes, differentiated by their assigned port numbers. After adding the header, UDP passes the user datagram to IP.

• Demultiplexing: At the receiver side, there is only one UDP. However, it may happen to be many processes that can receive user datagrams. This is a one-to-many rela- tionship and requires demultiplexing. UDP receives user datagrams from IP. After error checking and dropping of header, UDP delivers each message to the appropriate process based on the port numbers.

UDP is suitable for a process that requires simple request-response communication with little concern for flow and error control. It is not suitable for a process that needs to send bulk data, like FTP. However, UDP can be used for a process with internal flow and error control mechanisms such as the Trivial File Transfer Protocol (TFTP) process. UDP is also used for management processes such as SNMP.

2.3

World Wide Web

The World Wide Web (WWW) is a repository of information spread all over the world and linked together. The WWW is a distributed client-server service, in which a client using a browser can access a service using a server. The Web consists of Web pages that are accessible over the Internet.

The Web allows users to view documents that contain text and graphics. The Web grew to be the largest source of Internet traffic since 1994 and continues to dominate, with a much higher growth rate than the rest of the internet. By 1995, Web traffic overtook FTP to become the leader. By 2001, Web traffic completely overshadowed other applications.

2.3.1

Hypertext Transfer Protocol (HTTP)

The protocol used to transfer a Web page between a browser and a Web server is known as Hypertext Transfer Protocol (HTTP). HTTP operates at the application level. HTTP is a protocol used mainly to access data on the World Wide Web. HTTP functions like a combination of FTP and SMTP. It is similar to FTP because it transfers files, while HTTP is like SMTP because the data transferred between the client and the server looks like SMTP messages. However, HTTP differs from SMTP in the way that SMTP messages are stored and forwarded; HTTP messages are delivered immediately.

As a simple example, a browser sends an HTTP GET command to request a Web page from a server. A browser contacts a Web server directly to obtain a page. The browser begins with a URL, extracts the hostname section, uses DNS to map the name into an equivalent IP address, and uses the IP address to form a TCP connection to the server. Once the TCP connection is in place, the browser and Web server use HTTP to communicate. Thus, if the browser sends a request to retrieve a specific page, the server responds by sending a copy of the page.

A browser requests a Web page, and the server transfers a copy to the browser. HTTP also allows transfer from a browser to a server. HTTP allows browsers and servers to negotiate details such as the character set to be used during transfers. To improve response time, a browser caches a copy of each Web page it retrieves. HTTP allows a machine along the path between a browser and a server to act as a proxy server that caches Web pages and answers a browser’s request from its cache. Proxy servers are an important part of the Web architecture because they reduce the load on servers.

In summary, a browser and server use HTTP to communicate. HTTP is an application- level protocol with explicit support for negotiation, proxy servers, caching and persistent connections.