The essential difference is that UDP is "fire and forget" (and like a bullet, if it misses it doesn't tell you...) - there's no acknowledgement of UDP traffic from the receiver built into the protocol, no flow-control, error-correction or windowing (packet segmentation/sequencing/reassembly/size-negotiation) - all these are parts of the TCP protocol specification, there are clues in the names - User Datagram Protocol (like a telegram, you send it and *may* get a reply depending on what the destination does but no guarantee) and Transmission Control Protocol (like a phone call, there's an end-to-end transmission path in both directions and negotiations between end-points, it's "connection oriented" where UDP is "connectionless").
Much of the activity in a TCP connection is needed because of the non-deterministic, unreliable nature of the Datalink layer - much of Ethernet has been handed down from the Alohanet (networking over a single radio channel with collision avoidance by carrier sensing), and until the advent of store-and-forward switches and routers there was no guarantee of delivery. Things are better now, but UDP is still an inferior choice if reliability matters!
The essential difference is that UDP is "fire and forget" (and like a bullet, if it misses it doesn't tell you...) - there's no acknowledgement of UDP traffic from the receiver built into the protocol, no flow-control, error-correction or windowing (packet segmentation/sequencing/reassembly/size-negotiation) - all these are parts of the TCP protocol specification, there are clues in the names - User Datagram Protocol (like a telegram, you send it and *may* get a reply depending on what the destination does but no guarantee) and Transmission Control Protocol (like a phone call, there's an end-to-end transmission path in both directions and negotiations between end-points, it's "connection oriented" where UDP is "connectionless").
Much of the activity in a TCP connection is needed because of the non-deterministic, unreliable nature of the Datalink layer - much of Ethernet has been handed down from the Alohanet (networking over a single radio channel with collision avoidance by carrier sensing), and until the advent of store-and-forward switches and routers there was no guarantee of delivery. Things are better now, but UDP is still an inferior choice if reliability matters!
Hi:
Mr. David Hicks , from where you get this description of UDP, it is Excellent.
I just add that UDP very faster than TCP for that , it used in real-time task like live audio call through wep
I'm afraid it's not from a book, it's from 20 years as a network engineer!
It's ideal for live audio / video as there's not the overhead you find in TCP, as you don't have the syn/ack 3-way handshake which is part of the TCP protocol, precisely to make TCP connection-oriented, or the windowing (adjusting TCP packet size by end-to-end negotiation) or error-correction (which in TCP can require retransmission). UDP although an "unreliable" protocol has speed and simplicity in its favour, and the random loss of a few packets will normally still allow for usable audio/video - people are much better at error-correction than we acknowledge!
For communications requiring accurate, reliable delivery, TCP is the way to go - you wouldn't want your bank to guess at the figures on your salary cheque because a UDP packet went astray...
Thanks for your comments, Mohamed and David. Just want to make a few additions. We carry out majority of measurement on the network using TCP and UDP packets because they constitute most of the traffic on the internet. In UDP (although a simple protocol) packets are not guaranteed to arrive at their destinations and if they do arrive, they are not guaranteed to arrive in the order in which they were sent. In other words the sender does not get an acknowledgment of the transmission. However these characteristics make UDP very ideal for video or voice streaming applications since retransmissions and acknowledgements required in TCP constitutes a waste of bandwidth and the transmissions can make use of the low overhead associated with UDP.
TCP guarantees that packets arrive and arrive in the order transmitted. TCP also attempts to avoid network congestion by sometimes delaying the transmission of packets using contention avoidance schemes. As we earlier mentioned, TCP has a higher overhead than UDP. However since this overhead is not significantly larger than that for UDP, it is widely used in non-streaming applications especially where packet loss is a big issue..
To precisely model the hot spot network performance, the presence of both TCP and UDP flows is necessary to relax, or modify, several assumptions usually adopted to derive the saturation throughput of 802:11-based wireless networks.
In case of Delay UDP is Better than TCP because it works on fire and forget (Send and forget)concept and there is no ACK policy in UDP, but in case of Packet loss TCP is better than UDP because it works with the ACK policy.
- Badges
- Science topic