分类：
2009-12-09 11:49:14
The User Datagram Protocol (UDP) is a transport layer protocol defined for use with the network layer protocol. It is defined by RFC 768 written by John Postel. It provides a datagram service to an .
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 (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 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.
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:
Like for other transport protocols, the UDP header and data are not processed by (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 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 ).
UDP and UDP-Lite also may be used for multicast and broadcast, allowing senders to transmit to multiple receivers.
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. ).
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 !
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.
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.
The Datagram Congestion Control Protocol (DCCP) (RFC4340) provides a more sophisticated datagram service, particularly suited to unicast streaming services.
See also:
Standards Documents:
J. Postel. .
R.T. Braden, D.A. Borman, C. Partridge,
L. Eggert, G. Fairhurst,
