Lecture # 14 TCP/IP - UDP

Lecture # 14 TCP/IP - UDP

Computer Communication & Networks

Today’s Menu

↗ Transmission Control Protocol

↗ Addressing (Port Numbers)

↗ Datagram Format

↗ User Datagram Protocol

↗ TCP vs UDP

Transmission Control Protocol

Functions Performed by TCP

↗ Addressing

↗ Connection Establishment, Management and Termination

↗ Reliability and Transmission Quality Services

↗ Flow Control and Congestion Avoidance


Addressing

↗ A typical host on a TCP/IP internetwork has many different software application processes running concurrently

↗ Each generates data that it sends to either TCP or UDP, which in turn passes it to IP for transmission

↗ The question is: how do we demultiplex a sequence of IP datagrams that need to go to many different application processes?

↗ Let's consider a particular host with a single network interface bearing the IP address 10.10.10.10

↗ Normally, every datagram received by the IP layer will have this value in the IP Destination Address field

↗ Consecutive datagrams received by IP may contains a piece of a file you are downloading with your Web browser, an e-mail sent to you by your brother, and a line of text a buddy wrote in an IRC chat channel

↗ How does the IP layer know which datagrams go where, if they all have the same IP address?




Addressing

↗ TCP and UDP port numbers are 16 bits in length, so valid port numbers can theoretically take on values from 0 to 65,535

↗ These are divided into ranges for different purposes, with certain ports reserved for particular uses

↗ They identify the originating process on the source machine, and the destination process on the destination machine


The Problem: Identifying Particular Processes on a Server

↗ We fire up our Web browser, which is client software that sends requests using the Hypertext Transfer Protocol (HTTP)

↗ We need to know the IP address (domain name) of the Web site we want to access

↗ Once we have the address, the Web browser can generate an HTTP message and send it to the Web site's IP address.

↗ This HTTP message is being sent not “just anywhere” on that IP address: it is intended for the Web server process on the site we are trying to reach

↗ The problem is: how does the Web browser (client process) know which port number has been assigned to the server process on the Web site?

↗ Port numbers can range from 0 to 65,535, which means a lot of choices


The Solution: Reserved Port Numbers

↗TCP/IP reserves certain port numbers for particular applications↗Each common application has a specific port number that is assigned to it for use by server processes that listen for requests for that application and then respond to them↗In our example, the reserved port number for HTTP is 80↗Every Web browser just “knows” that Web sites are designed to listen for requests sent to port 80↗They will thus use this value in requests, to ensure the IP and TCP software on the Web browser direct these HTTP messages to the Web server software↗It is possible for a particular Web server to use a different port number, but in this case, the user of the Web browser must be informed of this number somehow, and must explicitly tell the Web browser to use it instead of the default port number (80)


↗ For this system to work well, universal agreement on port assignments is essential

↗ For TCP/IP, it is the same authority responsible for the assignment and coordination of IP addresses, the Internet Assigned Numbers Authority (IANA)

↗ As we have seen, there are 65,536 port numbers that can be used for processes, the full spectrum of TCP and UDP port numbers is divided into three ranges

↗ Well-Known Port Numbers (0 to 1,023)↗ Registered Port Numbers (1,024 to 49,151)↗ Private/Dynamic Port Numbers (49,152 to 65,535)


↗ Well-Known Port Numbers (0 to 1,023)↗ These port numbers are used only by server processes run by system administrators

or privileged users↗ These generally correspond to processes that implement key IP applications, such as

Web servers, FTP servers and the like↗ For this reason, these are sometimes called system port numbers

↗ Registered Port Numbers (1,024 to 49,151)↗ There are many applications that need to use TCP/IP but are not specified in RFCs, or

are not so universally used↗ To ensure that these various applications do not conflict with each other, IANA uses

the bulk of the overall port number range for registered port numbers↗ Anyone who creates a viable TCP/IP server application can request to reserve one of

these port numbers↗ These port numbers are generally accessible by any user on a system and are

therefore sometimes called user port numbers↗ Private/Dynamic Port Numbers (49,152 to 65,535)

↗ These ports are neither reserved nor maintained by IANA↗ They can be used for any purpose without registration, so they are appropriate for a

private protocol used only by a particular organization


Datagram format


Source Port (16 bits)

↗ The port number of the process that originated the TCP segment on the source device

↗ This will normally be an client port number for a request sent by a client to a server, or a well-known/registered (server) port number for a reply from a server to a client

Destination Port (16 bits)

↗ The 16-bit port number of the process that is the ultimate intended recipient of the message on the destination device

↗ This will usually be a well-known/registered (server) port number for a client request, or an client port number for a server reply


Sequence Number (32 bits)

↗For normal transmissions, the sequence number of the first byte of data in this segment↗In a connection request (SYN) message, this carries the initial sequence number (ISN) of the source TCP

Acknowledgment Number (32 bits)

↗When the ACK bit is set, this segment is serving as an acknowledgment and this field contains the sequence number the source is next expecting the destination to send


Header Length (4 bits)

↗Specifies the number of 32-bit words in the TCP header↗In other words, this value times four equals the number of bytes in the header, which must always be a multiple of four↗It is also called a “data offset” since it indicates by how many 32-bit words the start of the data is offset from the beginning of the TCP segment

Reserved (6 bits)

↗6 bits reserved for future use; sent as all zeros


Control Bits or Flags (6 bits)

↗URG: (Urgent Bit) When set to 1, indicates that the priority data transfer has been invoked for this segment and that the urgent pointer field is valid↗ACK: (Acknowledgment Bit) When set to 1, indicates that this segment is carrying an acknowledgment and the value of the acknowledgment number field is valid and carrying the next sequence expected from the destination of this segment↗PSH: (Push Bit) The sender of this segment is using the TCP push feature, requesting that the data in this segment be immediately pushed to the application on the receiving device↗RST: (Reset Bit) The sender has encountered a problem and wants to reset the connection↗SYN: (Synchronize Bit) This segment is a request to synchronize sequence numbers and establish a connection; the sequence number field contains the initial sequence number of the sender of the segment↗FIN: (Finish Bit) The sender of the segment is requesting that the connection be closed


Window (16 bits)

↗Indicates the number of octets of data the sender of this segment is willing to accept from the receiver at one time↗This normally corresponds to the current size of the buffer allocated to accept data for this connection↗This field is, in other words, the current receive window size for the device sending this segment, which is also the send window for the recipient of the segment

Checksum (16 bits)

↗A checksum for data integrity protection, computed over the entire TCP datagram↗It is used to protect the entire TCP segment against not just errors in transmission, but also errors in delivery


Urgent Pointer (16 bits)

↗Used in conjunction with the URG control bit for priority data transfer↗This field contains the sequence number of the last byte of urgent data

Options and Padding (Variable)

↗TCP includes a generic mechanism for including one or more sets of optional data in a TCP segment↗If the Options field is not a multiple of 32 bits in length, enough zeroes are added to pad the header so it is a multiple of 32 bits

Data (Variable)

↗The data being sent in the segment

User Datagram Protocol

↗ UDP is simple and fast↗ It serves as an interface between application processes running at the higher

layers and the internetworking capabilities of IP↗ UDP is a fast protocol specifically because it doesn't have all the bells and

whistles of TCP↗ This makes it suitable for use by some applications because this is exactly what

they want from a transport layer protocol.↗ It takes their data and quickly shuffles it down to the IP layer with a minimum of

fuss

↗ UDP is basically just IP with transport-layer port addressing


What UDP Does Not

As a transport protocol, some of the most important things UDP does not do include the following:

↗ UDP does not establish connections before sending data; It just packages it and off it goes

↗ UDP does not provide acknowledgments to show that data was received↗ UDP does not provide any guarantees that its messages will arrive↗ UDP does not detect lost messages and retransmit them↗ UDP does not ensure that data is received in the same order that they were sent↗ UDP does not provide any mechanism to manage the flow of data between

devices, or handle congestion


Datagram format

In keeping with the goal of efficiency, the UDP header is only eight bytes in length; this contrasts with the TCP header size of 20 bytes or more


Source Port (16 bits)

↗The 16-bit port number of the process that originated the UDP message on the source device↗This will normally be an client port number for a request sent by a client to a server, or a well-known/registered (server) port number for a reply from a server to a client

Destination Port (16 bits)

↗The 16-bit port number of the process that is the ultimate intended recipient of the message on the destination device↗This will usually be a well-known/registered (server) port number for a client request, or an client port number for a server reply


Length (16 bits)

The length of the entire UDP datagram, including both header and Data fields

Checksum (16 bits)

An optional checksum computed over the entire UDP datagram

Data (variable)

The encapsulated higher-layer message to be sent

Summary Comparison of UDP & TCP

UDP

General DescriptionSimple, high-speed, low-functionality

“wrapper” that interfaces applications to the network layer and does little else

Protocol Connection SetupConnectionless; data is sent without setup

Data Interface To ApplicationMessage-based; data is sent in discrete

packages by the application

Reliability and AcknowledgmentsUnreliable, best-effort delivery without

acknowledgments

TCP

General DescriptionFull-featured protocol that allows applications

to send data reliably without worrying about network layer issues

Protocol Connection SetupConnection-oriented; connection must be

established prior to transmission

Data Interface To ApplicationStream-based; data is sent by the application

with no particular structure

Reliability and AcknowledgmentsReliable delivery of messages; all data is

acknowledged


UDP

RetransmissionsNot performed; Application must detect lost

data and retransmit if needed

Features Provided to Manage Flow of DataNone

OverheadVery low

Transmission SpeedVery high

TCP

RetransmissionsDelivery of all data is managed, and lost data

is retransmitted automatically

Features Provided to Manage Flow of DataFlow control using sliding windows; window

size adjustment heuristics; congestion avoidance algorithms

OverheadLow, but higher than UDP

Transmission SpeedHigh, but not as high as UDP


UDP

Types of Applications That Use The ProtocolApplications where data delivery speed

matters more than completeness, where small amounts of data are sent; or where multicast/broadcast are used

Well-Known Applications and ProtocolsMultimedia applications, DNS, BOOTP, DHCP,

TFTP, SNMP, RIP

TCP

Types of Applications That Use The ProtocolMost protocols and applications sending data

that must be received reliably, including most file and message transfer protocols

Well-Known Applications and ProtocolsFTP, Telnet, SMTP, DNS, HTTP, POP, NNTP,

IMAP, BGP, IRC

Documents

Lecture # 14 TCP/IP - UDP