The User Datagram Protocol (UDP)

The User Datagram Protocol (UDP) is a transport layer protocol defined for use with the IP
network layer protocol. It is defined by RFC 768 written by John Postel. It provides a best-effort
datagram service to an End System (IP host).

The service provided by UDP is an unreliable service that provides no guarantees for delivery
and no protection from duplication (e.g. if this arises due to software errors within an
Intermediate System (IS)). The simplicity of UDP reduces the overhead from using the protocol
and the services may be adequate in many cases.

UDP provides a minimal, unreliable, best-effort, message-passing transport to applications and

upper-layer protocols. Compared to other transport protocols, UDP and its UDP-Lite variant are
unique in that they do not establish end-to-end connections between communicating end
systems. UDP communication consequently does not incur connection establishment and
teardown overheads and there is minimal associated end system state. Because of these
characteristics, UDP can offer a very efficient communication transport to some applications, but
has no inherent congestion control or reliability. A second unique characteristic of UDP is that it
provides no inherent On many platforms, applications can send UDP datagrams at the line rate of
the link interface, which is often much greater than the available path capacity, and doing so
would contribute to congestion along the path, applications therefore need to be designed
responsibly [RFC 4505].

One increasingly popular use of UDP is as a tunneling protocol, where a tunnel endpoint
encapsulates the packets of another protocol inside UDP datagrams and transmits them to
another tunnel endpoint, which decapsulates the UDP datagrams and forwards the original
packets contained in the payload. Tunnels establish virtual links that appear to directly connect
locations that are distant in the physical Internet topology, and can be used to create virtual
(private) networks. Using UDP as a tunneling protocol is attractive when the payload protocol is
not supported by middleboxes that may exist along the path, because many middleboxes support
UDP transmissions.

UDP does not provide any communications security. Applications that need to protect their
communications against eavesdropping, tampering, or message forgery therefore need to
separately provide security services using additional protocol mechanisms.

Protocol Header

A computer may send UDP packets without first establishing a connection to the recipient. A
UDP datagram is carried in a single IP packet and is hence limited to a maximum payload of
65,507 bytes for IPv4 and 65,527 bytes for IPv6. The transmission of large IP packets usually
requires IP fragmentation. Fragmentation decreases communication reliability and efficiency and
should theerfore be avoided.
To transmit a UDP datagram, a computer completes the appropriate fields in the UDP header
(PCI) and forwards the data together with the header for transmission by the IP network layer.

The UDP protocol header consists of 8 bytes of Protocol Control Information (PCI)

The UDP header consists of four fields each of 2 bytes in length:

 Source Port (UDP packets from a client use this as a service access point (SAP) to
indicate the session on the local client that originated the packet. UDP packets from a
server carry the server SAP in this field)

 Destination Port (UDP packets from a client use this as a service access point (SAP) to
indicate the service required from the remote server. UDP packets from a server carry the
client SAP in this field)

 UDP length (The number of bytes comprising the combined UDP header information
and payload data)

 UDP Checksum (A checksum to verify that the end to end data has not been corrupted
by routers or bridges in the network or by the processing in an end system. The algorithm
to compute the checksum is the Standard Internet Checksum algorithm. This allows the
receiver to verify that it was the intended destination of the packet, because it covers the
IP addresses, port numbers and protocol number, and it verifies that the packet is not
truncated or padded, because it covers the size field. Therefore, this protects an
application against receiving corrupted payload data in place of, or in addition to, the data
that was sent. In the cases where this check is not required, the value of 0x0000 is placed
in this field, in which case the data is not checked by the receiver.

Like for other transport protocols, the UDP header and data are not processed by Intermediate
Systems (IS) in the network, and are delivered to the final destination in the same form as
originally transmitted.

At the final destination, the UDP protocol layer receives packets from the IP network layer.
These are checked using the checksum (when >0, this checks correct end-to-end operation of the
network service) and all invalid PDUs are discarded. UDP does not make any provision for error
reporting if the packets are not delivered. Valid data are passed to the appropriate session layer
protocol identified by the source and destination port numbers (i.e. the session service access
points).
UDP and UDP-Lite also may be used for multicast and broadcast, allowing senders to transmit to
multiple receivers.

Using UDP

Application designers are generally aware that UDP does not provide any reliability, e.g., it does
not retransmit any lost packets. Often, this is a main reason to consider UDP as a transport.
Applications that do require reliable message delivery therefore need to implement appropriate
protocol mechanisms in their applications (e.g. tftp).

UDP's best effort service does not protect against datagram duplication, i.e., an application may
receive multiple copies of the same UDP datagram. Application designers therefore need to
verify that their application gracefully handles datagram duplication and may need to implement
mechanisms to detect duplicates.

The Internet may also significantly delay some packets with respect to others, e.g., due to routing
transients, intermittent connectivity, or mobility. This can cause reordering, where UDP
datagrams arrive at the receiver in an order different from the transmission order. Applications
that require ordered delivery must restore datagram ordering themselves.

The burdon of needing to code all these protocol mechanims can be avoided by using TCP!

Ports

Generally, clients set the source port number to a unique number that they choose themselves -
usually based on the program that started the connection. Since this number is returned by the
server in responses, this lets the sender know which "conversation" incoming packets are to be
sent to. The destination port of packets sent by the client is usually set to one of a number of
well-known ports. These usually correspond to one of a number of different applications, e.g.
port 23 is used for telnet, and port 80 is used for web servers.

A server process (program), listens for UDP packets received with a particular well-known port
number and tells its local UDP layer to send packets matching this destination port number to the
server program. It determines which client these packets come from by examining the received
IP source address and the received unique UDP source port number. Any responses which the
server needs to send to back to a client are sent with the source port number of the server (the
well-known port number) and the destination port selected by the client. Most people do not
memorise the well known ports, instead they look them up in table (e.g. see below).
20 FTP-DATA File Transfer [Default Data]
21 FTP File Transfer [Control]
23 TELNET Telnet
25 SMTP Simple Mail Transfer
37 TIME Time
69 TFTP Trivial File Transfer
79 FINGER Finger
110 POP3 Post Office Protocol v 3
123 NTP Network Time Protocol
143 IMAP2 Interim Mail Access Prot. v2
161 SNMP Simple Network Man. Prot.

Some well-known UDP/IP port numbers

(a full list is provided in the link at the bottom of this page).

If a client/server application executes on a host with more than one IP interface, the application
needs to ensure that it sends any UDP responses with an IP source address that matches the IP
destination address of the UDP datagram that carried the request.

UDP-Lite

A special class of applications can derive benefit from having partially damaged payloads
delivered, rather than discarded, when using paths that include error-prone links. Such
applications can tolerate payload corruption and may choose to use the Lightweight User
Datagram Protocol (UDP-Lite) [RFC3828] variant of UDP instead of basic UDP. The header
format closely follows that of UDP. UDP-Lite changes the semantics of the UDP "payload
length" field to that of a "checksum coverage length" field. Otherwise, UDP-Lite is identical to
UDP. The interface of UDP-Lite differs from that of UDP by the addition of a single (socket)
option that communicates a checksum coverage length value: at the sender, this specifies the
intended checksum coverage, with the remaining unprotected part of the payload called the
"error insensitive part".
By default, the UDP-Lite checksum coverage extends across the entire datagram. If required, an
application may dynamically modify this length value, e.g., to offer greater protection to some
messages. UDP-Lite always verifies that a packet was delivered to the intended destination, i.e.,
always verifies the header fields. Errors in the insensitive part will not cause a UDP datagram to
be discarded by the destination. Applications using UDP-Lite therefore must not make
assumptions regarding the correctness of the data received in the insensitive part of the UDP-Lite
payload (this may have been changed). The sending application therefore needs to specify a
minimum checksum coverage that include all sensitive protocol headers.

[RFC4505] provides guidance on how to use UDP.

The Datagram Congestion Control Protocol

The Datagram Congestion Control Protocol (DCCP) [RFC4340] provides a more sophisticated
datagram service, particularly suited to unicast streaming services.

Description:

Protocol suite: TCP/IP.

Protocol type: Connectionless transport layer protocol.
IP Protocol: 17.
Ports:
Related protocols: UDP-Lite, Lightweight User Datagram Protocol.
SNMP MIBs: iso.org.dod.internet.mgmt.mib-2.udp (1.3.6.1.2.1.7).
iso.org.dod.internet.mgmt.mib-2.udpMIB (1.3.6.1.2.1.50).
iso.org.dod.internet.experimental.ipv6UdpMIB (1.3.6.1.3.87).
Working groups:
Links:

RFC 1122, section 4.1:

The User Datagram Protocol offers only a minimal transport service -- non-guaranteed datagram
delivery -- and gives applications direct access to the datagram service of the IP layer. UDP is
used by applications that do not require the level of service of TCP or that wish to use
communications services (e.g., multicast or broadcast delivery) not available from TCP.

UDP is almost a null protocol; the only services it provides over IP are checksumming of data
and multiplexing by port number. Therefore, an application program running over UDP must
deal directly with end-to-end communication problems that a connection-oriented protocol
would have handled -- e.g., retransmission for reliable delivery, packetization and reassembly,
flow control, congestion avoidance, etc., when these are required. The fairly complex coupling
between IP and TCP will be mirrored in the coupling between UDP and many applications using
UDP.
MAC header IP header UDP header Data :::

UDP header:

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Source Port Destination Port
Length Checksum
Data :::

Source Port. 16 bits.

The port number of the sender. Cleared to zero if not used.

Destination Port. 16 bits.

The port this packet is addressed to.

Length. 16 bits.
The length in bytes of the UDP header and the encapsulated data. The minimum value for this
field is 8.

Checksum. 16 bits.
Computed as 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 as needed with zero bytes
at the end to make a multiple of two bytes. If the checksum is cleared to zero, then checksuming
is disabled. If the computed checksum is zero, then this field must be set to 0xFFFF.

When transported by IPv4, the pseudo header contains the following fields:

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Source IPv4 address
Destination IPv4 address
0 Protocol Total length

The checksum is not optional when transported by IPv6. In this case, the pseudo header contains
the following fields:

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Source IPv6 address :::
Destination IPv6 address :::
Upper layer packet length
0 Next header

Data. Variable length.

User Datagram Protocol


 Tweet

Abbreviated UDP, a connectionless protocol that, like TCP, runs on top of IP networks. Unlike
TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct way to send
and receive datagrams over an IP network. It's used primarily for broadcasting messages over a
network.

TCP

The Transmission Control Protocol (TCP) is one of the two original core protocols of the
Internet protocol suite (IP), and is so ubiquitous that the entire suite is often called TCP/IP. TCP
provides reliable, ordered, error-checked delivery of a stream of octets between programs
running on computers connected to an intranet or the public Internet.

Browsers use it when they connect to servers on the World Wide Web sites, and it is used to
accurately deliver email and transfer files from one location to another. Applications that do not
require the reliability of a TCP connection may instead use the connectionless User Datagram
Protocol (UDP), which emphasizes low-overhead operation and reduced latency rather than error
checking and delivery validation.

Abbreviation of Transmission Control Protocol, and pronounced as separate letters. TCP is one of the
main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two
hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also
guarantees that packets will be delivered in the same order in which they were sent.
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)is a transportation
protocol that is one of the core protocols of the Internet protocol suite. Both TCP and UDP work
at transport layer TCP/IP model and both have very different usage.

Difference between TCP and UDP

TCP UDP
Reliability: TCP is connection-oriented protocol. Reliability: UDP is connectionless protocol.
When a file or message send it will get delivered When you a send a data or message, you don't
unless connections fails. If connection lost, the know if it'll get there, it could get lost on the
server will request the lost part. There is no way. There may be corruption while
corruption while transferring a message. transferring a message.
Ordered: If you send two messages along a Ordered: If you send two messages out, you
connection, one after the other, you know the don't know what order they'll arrive in i.e. no
first message will get there first. You don't have ordered
to worry about data arriving in the wrong order.
Heavyweight: - when the low level parts of the Lightweight: No ordering of messages, no
TCP "stream" arrive in the wrong order, resend tracking connections, etc. It's just fire and
requests have to be sent, and all the out of forget! This means it's a lot quicker, and the
sequence parts have to be put back together, so network card / OS have to do very little work to
requires a bit of work to piece together. translate the data back from the packets.
Streaming: Data is read as a "stream," with Datagrams: Packets are sent individually and
nothing distinguishing where one packet ends are guaranteed to be whole if they arrive. One
and another begins. There may be multiple packet per one read call.
packets per read call.
Examples: World Wide Web (Apache TCP port Examples: Domain Name System (DNS UDP
80), e-mail (SMTP TCP port 25 Postfix MTA), port 53), streaming media applications such as
File Transfer Protocol (FTP port 21) and Secure IPTV or movies, Voice over IP (VoIP), Trivial
Shell (OpenSSH port 22) etc. File Transfer Protocol (TFTP) and online
multiplayer games etc

Difference between Transmission Control Protocol (TCP) and User Datagram

Protocol (UDP)

Transmission Control Protocol (TCP)

1) Transmission Control Protocol (TCP) is a connection oriented protocol, which means the
devices should open a connection before transmitting data and should close the connection
gracefully after transmitting the data.

2) Transmission Control Protocol (TCP) assure reliable delivery of data to the destination.
3) Transmission Control Protocol (TCP) protocol provides extensive error checking mechanisms
such as flow control and acknowledgment of data.

4) Sequencing of data is a feature of Transmission Control Protocol (TCP).

5) Delivery of data is guaranteed if you are using Transmission Control Protocol (TCP).

6) Transmission Control Protocol (TCP) is comparatively slow because of these extensive error
checking mechanisms

7) Multiplexing and Demultiplexing is possible in Transmission Control Protocol (TCP) using

TCP port numbers.

8) Retransmission of lost packets is possible in Transmission Control Protocol (TCP).

User Datagram Protocol (UDP)

1) User Datagram Protocol (UDP) is Datagram oriented protocol with no overhead for opening,
maintaining, and closing a connection.

2) User Datagram Protocol (UDP) is efficient for broadcast/multicast transmission.

3) User Datagram protocol (UDP) has only the basic error checking mechanism using
checksums.

4) There is no sequencing of data in User Datagram protocol (UDP) .

5) The delivery of data cannot be guaranteed in User Datagram protocol (UDP) .

6) User Datagram protocol (UDP) is faster, simpler and more efficient than TCP. However, User
Datagram protocol (UDP) it is less robust then TCP

7) Multiplexing and Demultiplexing is possible in User Datagram Protcol (UDP) using UDP port
numbers.

8) There is no retransmission of lost packets in User Datagram Protcol (UDP).

User Datagram Protocol (UDP)

It is part of the base protocols of the Internet Protocol Suite. Programs on networked computers can
send short messages sometimes called datagrams. UDP does not guarantee any reliability (it happens
that datagram may be out of order, duplicated, or goes missing without any notice). The fact that no
checking whether all packets are actually delivered is made, UDP proves to be faster and more efficient,
for applications that do not need guaranteed delivery. UDP find its uses in such situations:

 Time-sensitive applications. The problems due to delayed packets are avoided.

  It is also useful for servers that answer small queries from huge numbers of clients. UDP
supports packet broadcast (conveys to all on local network) and multicasting (conveys to all
subscribers).

Transmission Control Protocol (TCP)

It is often referred to as TCP/IP due to the importance of this protocol in the Internet Protocol Suite. TCP
operates at a higher level, concerned only with the two end systems, (e.g. between web browser and a
web server). TCP provides reliable, sequential delivery of a stream of data from one program on one
computer to another program on another computer. Common uses of TCP are:

 e-mailing support

 file transfer

 Web applications.

When should I use UDP instead of TCP?

UDP is good for sending messages from one system to another when the
order isn't important and you don't need all of the messages to get to
the other machine. This is why I've only used UDP once to write the
example code for the faq. Usually TCP is a better solution. It saves
you having to write code to ensure that messages make it to the
desired destination, or to ensure the message ordering. Keep in mind
that every additional line of code you add to your project in another
line that could contain a potentially expensive bug.

If you find that TCP is too slow for your needs you may be able to get
better performance with UDP so long as you are willing to sacrifice
message order and/or reliability.

UDP must be used to multicast messages to more than one other machine
at the same time. With TCP an application would have to open separate
connections to each of the destination machines and send the message
once to each target machine. This limits your application to only
communicate with machines that it already knows about.