Ex.

No:5-c Date: STUDY OF UDP/TCP PERFORMANCE

AIM: To study the performance of the UDP/TCP protocols The TCP Connection TCP provides multiplexing, demultiplexing, and error detection (but not recovery) in exactly the same manner as UDP. Nevertheless, TCP and UDP differ in many ways. The most fundamental difference is that UDP is connectionless, while TCP is connectionoriented. UDP is connectionless because it sends data without ever establishing a connection. TCP is connection-oriented because before one application process can begin to send data to another, the two processes must first "handshake" with each other -- that is, they must send some preliminary segments to each other to establish the parameters of the ensuing data transfer. As part of the TCP connection establishment, both sides of the connection will initialize many TCP "state variables" (many of which will be discussed in this section and in Section 3.7) associated with the TCP connection. The TCP "connection" is not an end-to-end TDM or FDM circuit as in a circuit-switched network. Nor is it a virtual circuit (see Chapter 1), as the connection state resides entirely in the two end systems. Because the TCP protocol runs only in the end systems and not in the intermediate network elements (routers and bridges), the intermediate network elements do not maintain TCP connection state. In fact, the intermediate routers are completely oblivious to TCP connections; they see data grams, not connections.

A TCP connection provides for full duplex data transfer. That is, application-level data can be transferred in both directions between two hosts - if there is a TCP connection between process A on one host and process B on another host, then application-level data can flow from A to B at the same time as application-level data flows from B to A. TCP connection is also always point-to-point, i.e., between a single sender and a single receiver. So called "multicasting" (see Section 4.8) -- the transfer of data from one sender to many receivers in a single send operation -- is not possible with TCP. With TCP, two hosts are company and three are a crowd! Let us now take a look at how a TCP connection is established. Suppose a process running in one host wants to initiate a connection with another process in another host. Recall that the host that is initiating the connection is called the client host, while the other host is called the server host. The client application process first informs the client TCP that it wants to establish a connection to a process in the server. Recall from Section 2.6, a Java client program does this by issuing the command: Socket clientSocket = new Socket ("hostname", "port number"); The TCP in the client then proceeds to establish a TCP connection with the TCP in the server. We will discuss in some detail the connection establishment procedure at the end of this section. For now it suffices to know that the client first sends a special TCP segment; the server responds with a second special TCP segment; and finally the client responds again with a third special segment. The first two segments contain no "payload," i.e., no application-layer data; the third of these segments may carry a payload. Because three segments are sent between the two hosts, this connection establishment procedure is often referred to as a three-way handshake.

Once a TCP connection is established, the two application processes can send data to each other; because TCP is full-duplex they can send data at the same time. Let us consider the sending of data from the client process to the server process. The client process passes a stream of data through the socket (the door of the process), as described in Section 2.6. Once the data passes through the door, the data is now in the hands of TCP running in the client. As shown in the Figure 3.5-1, TCP directs this data to the connection's send buffer, which is one of the buffers that is set aside during the initial three-way handshake. From time to time, TCP will "grab" chunks of data from the send buffer. The maximum amount of data that can be grabbed and placed in a segment is limited by the Maximum Segment Size (MSS). The MSS depends on the TCP implementation (determined by the operating system) and can often be configured; common values are 1,500 bytes, 536 bytes and 512 bytes. (These segment sizes are often chosen in order to avoid IP fragmentation, which will be discussed in the next chapter.) Note that the MSS is the maximum amount of application-level data in the segment, not the maximum size of the TCP segment including headers. (This terminology is confusing, but we have to live with it, as it is well entrenched.) Figure 3.5-1: TCP send and receive buffers TCP encapsulates each chunk of client data with TCP header, thereby forming TCP segments. The segments are passed down to the network layer, where they are separately encapsulated within network-layer IP data grams. The IP data grams are then sent into the network. When TCP receives a segment at the other end, the segment's data is placed in the TCP connection's receive buffer. The application reads the stream of data from this buffer. Each side of the connection has its own send buffer and its own receive buffer. The send and receive buffers for data flowing in one direction are shown in Figure 3.5-1.

We see from this discussion that a TCP connection consists of buffers, variables and a socket connection to a process in one host, and another set of buffers, variables and a socket connection to a process in another host. No buffers or variables are allocated to the connection in the network elements (routers, bridges and repeaters) between the hosts.

Structure of a TCP segment When a TCP application sends a data, it divides into number of TCP segments. These segments include part of the data along with the header that defines various parameters used in the TCP communication between the source and the destination. These TCP segments are then encapsulated within the data portion of an IP datagram and sent on their way. If TCP are sent inside IP datagram, and I just said that IP is unreliable. How can TCP possibly be reliable? The trick is that, unlike straight IP, TCP expects a response from its TCP computer on receiving end. Think of this way: Imagine mailing a letter again!!, to someone and including a Post-it Note on the letter that specifies your phone number and tells the recipient to call you when she receives the letter. If you don't hear from her, you know she didn't get the letter. To ensure reliable communication, TCP includes a "Post-it Note" in its header that does two things:
o

When the application requests that the data be sent a remote location, TCP constructs an initial segment that attempts to set up the socket interface between the two systems. No data is sent until TCP hears back from the receiving system that the sockets are in place and that's ready to receive the data.

When the sockets are ready to go, TCP starts sending within its segments and always asks receiving TCP to acknowledge that these data segments

have arrived. If no acknowledgement is received, the sending TCP retransmits the segments.

Here is the exact format of TCP header. Field Bits Description Source Port 0 to 15 The source port number Destination Port 16 toThe destination number 31 Sequence Number32 63 Acknowledgement64 95 Data Offset Reserved Control Bits 96 toIn the overall sequence of bytes being sent, this field specifies the position in this sequence of the segment's first data byte. toIn the ACK control Bit is set, this field contains the value of the next sequence number the sender of the segments is expecting the receiver to acknowledge. toThe length of the TCP segment header, in 32 bit words.This tells the

99 receiving socket where the data starts. 100 toThis field is reserved for future use! 105 106 toThose codes specify various aspects of the communication.When set to 1, 111 each bit controls a particular code as listed here: 106 URG: Urgent pointer field significant. 107 ACK:Acknowledgment Number field to be used. 108 PSH: Push Function. 109 RST: Reset the connection. 110 SYN: Synchronize sequence numbers.This bit is set when the connection is opened. 111 FIN: No more data form sender, so close the connection. 112 toThe number of data bytes that the sender can currently accept. This sliding 127 window lets the sender and the receiver vary the number of bytes sent and

Windows

Checksum Urgent Pointer Options

thus increase efficiency. 128 toThis value lets the receiver determine the integrity of the data. 143 144 toIf the URG control bit is set, this field indicates the location in the data 159 160 and over where the urgent resides. This variable-length field specifies extra TCP options such as the maximum segment size.

TCP Header Format TCP segments are sent as internet datagrams. The Internet Protocol header carries several information fields, including the source and destination host addresses [2]. A TCP header follows the internet header, supplying information specific to the TCP protocol. This division allows for the existence of host level protocols other than TCP. TCP Header Format Source Port: 16 bits The source port number. Destination Port: 16 bits The destination port number. Sequence Number: 32 bits The sequence number of the first data octet in this segment (except When SYN is present). If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1. Acknowledgment Number: 32 bits

If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent. Data Offset: 4 bits The number of 32 bit words in the TCP Header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits long. Reserved: 6 bits Reserved for future use. Must be zero. Control Bits: 6 bits (from left to right): URG: Urgent Pointer field significant ACK: Acknowledgment field significant PSH: Push Function RST: Reset the connection SYN: Synchronize sequence numbers FIN: No more data from sender

Window: 16 bits The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept. Checksum: 16 bits

The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros. The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. This gives the TCP protection against misrouted segments. This information is carried in the Internet Protocol and is transferred across TCP/Network interface in the arguments or results of calls by the TCP on the IP. +--------+--------+--------+--------+ | Source Address |

+--------+--------+--------+--------+ | Destination Address |

+--------+--------+--------+--------+ | Zero | PTCL | TCP Length |

+--------+--------+--------+--------+

The TCP Length is the TCP header length plus the data length in octets (this is not an explicitly transmitted quantity, but is computed), and it does not count the 12 octets of the pseudo header. Urgent Pointer: 16 bits This field communicates the current value of the urgent pointer as a positive offset from the sequence number in this segment. The urgent pointer points to the sequence

number of the octet following the urgent data. This field is only be interpreted in segments with the URG control bit set. Options: variable Options may occupy space at the end of the TCP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option: Case 1: A single octet of option-kind. Case 2: An octet of option-kind, an octet of option-length, and the actual option-data octets. The option-length counts the two octets of option-kind and option-length as well as the option-data octets. Note that the list of options may be shorter than the data offset field might imply. The content of the header beyond the End-of-Option option must be header padding (i.e.zero).

A TCP must implement all options. Currently defined options include (kind indicated in octal): Kind ---0 1 Length -----Meaning ------End of option list. No-Operation.

Maximum Segment Size.

Specific Option Definitions End of Option List +--------+ |00000000| +--------+ Kind=0 This option code indicates the end of the option list. This might not coincide with the end of the TCP header according to the Data Offset field. This is used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the TCP header.

No-Operation +--------+ |00000001| +--------+ Kind=1 This option code may be used between options, for example, to align the beginning of a subsequent option on a word boundary. There is no guarantee that senders will use

this option, so receivers must be prepared to process options even if they do not begin on a word boundary. Maximum Segment Size +--------+--------+---------+--------+ |00000010|00000100| max seg size | +--------+--------+---------+--------+ Kind=2 Length=4 Maximum Segment Size Option Data: 16 bits If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This field must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). If this option is not used, any segment size is allowed.

Padding: variable The TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is composed of zeros. User Datagram Protocol The User Datagram Protocol (UDP) is one of the core members of the Internet Protocol Suite, the set of network protocols used for the Internet. With UDP, computer applications can send messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP) network without requiring prior communications to set up special

transmission channels or data paths. UDP is sometimes called the Universal Datagram Protocol. Packet structure UDP provides application multiplexing (via port numbers) and integrity verification (via checksum) of the header and payload. If transmission reliability is desired, it must be implemented in the user's application. bits 0 32 64 0 - 15 Source Port Length Data 16 - 31 Destination Port Checksum

The UDP header consists of 4 fields. The use of two of those is optional in IPv4 (pink background in table). In IPv6 only the source port is optional (see below).

Source port This field identifies the sending port when meaningful and should be assumed to be the port to reply to if needed. If not used, then it should be zero. Destination port This field identifies the destination port and is required. Length A 16-bit field that specifies the length in bytes of the entire datagram: header and data. The minimum length is 8 bytes since that's the length of the header. The

field size sets a theoretical limit of 65,535 bytes (8 byte header + 65527 bytes of data) for a UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes. Checksum The 16-bit checksum field is used for error-checking of the header and data. The algorithm for computing the checksum is different for transport over IPv4 and IPv6. If the checksum is omitted in IPv4, the field uses the value all-zeros. This field is not optional for IPv6. Checksum computation Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. In other words, all 16-bit words are summed using one's complement arithmetic. The sum is then one's complemented to yield the value of the UDP checksum field.

If the checksum calculation results in the value zero (all 16 bits 0) it should be sent as the one's complement (all 1's). The difference between IPv4 and IPv6 is in the data used to compute the checksum. IPv4 When UDP runs over IPv4, the checksum is computed using a pseudo-header that contains information from the IPv4 header: bits 0 32 64 0-7 8 - 15 16 - 23 24 - 31 Source address Destination address Zeros Protocol UDP length

96 Source Port 128 Length 160 Data

Destination Port Checksum

The source and destination addresses are those in the IPv4 header. The protocol is that for UDP (see List of IP protocol numbers): 17. The UDP length field is the length of the UDP header and data. UDP checksum computation is optional for IPv4. If a checksum is not used it should be set to the value zero.

IPv6 When UDP runs over IPv6, the checksum is mandatory. The method used to compute it is changed as documented in RFC 2460: Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6 to include the 128-bit IPv6 addresses. When computing the checksum, a pseudo-header is used that mimics the IPv6 header: bits 0 - 7 8 - 15 16 - 23 0 Source address 32 64 96 128 Destination address 24 - 31

160 192 224 256 288 320 352 384

UDP length Zeros Source Port Length Data

Next Header Destination Port Checksum

The source address is the one in the IPv6 header. The destination address is the final destination; if the IPv6 packet doesn't contain a Routing header, that will be the destination address in the IPv6 header; otherwise, at the originating node, it will be the address in the last element of the Routing header, and, at the receiving node, it will be the destination address in the IPv6 header. The value of the Next Header field is the protocol value for UDP: 17. The UDP length field is the length of the UDP header and data. Difference between TCP and UDP Protocol TCP (Transmission Control Protocol). TCP UDP (User Datagram Protocol). is a connection-oriented protocol, a connection can be made from client to server, and from then on any data can be sent along that connection. A simpler message-based connectionless protocol. With UDP you send messages(packets) across the network in

chunks. Reliable when you send a message along a Unreliable When you send a message, you TCP socket, you know it will get there unless dont know if itll get there, it could get lost the connection fails completely. If it gets lost on the way. along the way, the server will re-request the lost part. This means complete integrity, things dont get corrupted. Ordered if you send two messages along a Not ordered If you send two messages out,

connection, one after the other, you know the you dont know what order theyll arrive in. first message will get there first. You dont have to worry about data arriving in the wrong order. Heavyweight when the low level parts of the TCP stream arrive in the wrong order, resend requests have to be sent, and all the out of sequence parts have to be put back together, so requires a bit of work to piece together. Lightweight No ordering of messages, no tracking connections, etc. Its just fire and forget! This means its a lot quicker, and the network card / OS have to do very little work to translate the data back from the packets.

RESULT: Thus the UDP/TCP protocols was studied successfully