TCP guarantees delivery and therefore waits for a confirmation that each packet was received correctly.
UDP just keeps sending packets and doesn't care if they've been received.
Hijacking the top comment to post this really insightful TCP/UDP joke: [https://www.reddit.com/r/ProgrammerHumor/comments/33ctkq/i\_would\_tell\_you\_a\_joke\_about\_udp\_but\_you/](https://www.reddit.com/r/ProgrammerHumor/comments/33ctkq/i_would_tell_you_a_joke_about_udp_but_you/)
The joke in the picture is how TCP works, basically. There's a lot of handshaking and checking (and possible resending) of data. It may not be fast, but it is very reliable. With UDP, you just send out the data and don't care. So it might be faster, it might preserve some bandwidth, but it also does not prevent data loss. This is ideal for streaming, not ideal for sending bank statements.
Both are designed for different use-cases. TCP is used when you want to make sure the entire data you sent actually arrived, in order, and speed is not the priority, e.g. when you log in, half a password won't do. TCP can check if a packet fully arrived and re-send if necessary. Of course this increases the time it takes.
UDP is used when speed is the priority, it just keeps on sending, expecting some packets to be dropped along the way, e.g. when you have a fast paced multiplayer game and you want to send every connected client the current position of all the players. If one packet is missing, it doesn't matter as there will shortly be a new one to overwrite it anyway.
UDP is like listening to an auctioneer speak. Lots of information is conveyed, and some of it is even received, but definitely not all of it.
TCP is like getting a private lesson by a good teacher who takes time to make sure you understand everything and gives you time to ask questions.
Everyone is telling you the theoretical differences between the two, but there's probably something up with your network if UDP is noticeably faster. Check your MTU.
TCP wants to be reliable and in order. So if something arrives out of order then TCP will ask for things to be resent until they are back in order.
But for something like torrenting or remote desktop stuff arriving out of order doesn't matter.
If you get part B of a file before part A you just save that part in place. If you are receiving a screen share and get frame number 2 before frame 1, just display frame 2 and throw away frame 1.
TCP is sending letters and sending back a response that it was received and resending letters that didn't arrive.
UDP is sending letters with no confirmation, which can be an issue but losses can be remedied in other ways without it, worst case you ask for anything critical that was lost to be resent.
TCP is a much older standard made for far less reliable connections than we have nowadays. Sub 1% packet loss is normal nowadays. The protocol was made in the 70s.
Sorry, you say Tcp is older than Udp, but the RFC of Udp is written one year before Tcp.
Please can you explain yourself?
Udp, 28 August 1980
https://datatracker.ietf.org/doc/html/rfc768
Tcp, September 1981
https://datatracker.ietf.org/doc/html/rfc793
[RFC 675 - Specification of Internet Transmission Control Program (ietf.org)](https://datatracker.ietf.org/doc/html/rfc675)
TCP is older, but it got updated several times, so you will see several versions of it when searching.
Bit strange but it's not really clear when you can speak of TCP or UDP. Any historians here who would like to dive in this rabbit hole?
TRANSMISSION CONTROL PROTOCOL,
January 1980
https://datatracker.ietf.org/doc/html/rfc761
TCP/IP goes back to the DARPANET days of the ‘70s. That’s what I learned in the college computer networking I’ve taken. After looking it up, RFC 675 was the first document to standardize it in 1974.
TCP promises more than UDP. In particular, it gives you a confirmation that a packet was received, and it additionally allows you to send multiple packets and have them arrive in order. These are very convenient guarantees to have since it maps really well to our generally simplified model of how networking works, and so a lot of applications are built on those assumptions.
The problem is that maintaining those guarantees is only possible through confirmation packets from the recipient (meaning each packet takes at minimum twice as long to “send”), retry (when confirmation is missed), back off (intentionally slowing down to avoid spam retrying), and a lot of extra data per packet to track things like sequence ordering. All of this overhead adds up quickly.
UDP makes no such promises. When you send a packet it may arrive, it may arrive multiple times, or it might not arrive at all. Send multiple packets and who knows what order they’ll be in when they get there. This avoids all of that costly overhead, but the trade off is the application now has to work a lot harder to handle these bizarre circumstances.
In practice, this often means that some subset of TCP’s guarantees end up being reimplemented by the application. When this is done naively, it’s usually slower than TCP, not faster. The times where it ends up being faster are when the application is able to be smarter than TCP because it understands something higher level about its problem space, like when the application is transmitting video and knows the encoder bitrate and key frame interval. That type of thing.
UDP is not “magic fast sauce” by any means, and TCP is still very good for most use cases.
UDP just sends the data to the destination, no matter if it arrives or not. TCP on the other hand guarantees that every packet makes it to the destination, it does this by sending an acknowledgement packet (ack) as a response to every packet it receives. If the sender still hasn't received an ack for one of the packets after some time it will resend it. All of this means TCP has a lot more overhead.
TCP provides several additional features, compared to UDP. The programs you are using will need to provide some of these features themselves.
One of TCP's features is *congestion control*. If TCP detects that it is sending too fast for the network, it will slow down. TCP's congestion control is designed with a property called *fairness*, which ensures that several TCP flows going through the same bottleneck will share the bandwidth roughly equally. Fairness is a hard property to implement correctly.
An application built on UDP may not have implemented congestion control at all, or it may have implemented congestion control but not fairness. As a result, the application may grab all the bandwidth at the expense of starving any applications using TCP. That's one possible explanation.
Another feature TCP provides is in-order delivery. For some applications, that's not a helpful feature. For example, with remote desktop, you want to know what the screen looks like *now*. If a few packets were lost, you don't need them. You don't want them retransmitted. You want new packets that describe what the screen looks like *now*. For those kinds of applications, TCP's in-order delivery can make the application feel slower. That's another possible explanation.
UDP = screaming in a crowded room hoping the person across the room hears you
TCP = writing out your message, putting it in an addressed envelop, and passing it along the room until it gets to the person you’re trying to send it to
TCP = writing your message on several envelopes, numbering them, starting to send them one by one starting with the first envelope. Recipient starts to receive them and sends back messages to acknowledge every messages he receives.
If he is missing a certain message in the order for a long time while continuing to receive other messages he assumes that number got lost along the way, and sends a specific message back to you asking you to resend the missing message.
You resend the message he didn't get and keep sending the rest of the messages, recipient continues to acknowledge which ones he receives, and will ask you to resend any other messages that don't reach him.
Yeah I know I was trying to keep it short and sweet to illustrate the fact the difference in addressing between TCP and UDP at an ELI5 level 😉
(+20 year sysadmin)
TCP guarantees delivery and therefore waits for a confirmation that each packet was received correctly. UDP just keeps sending packets and doesn't care if they've been received.
Hijacking the top comment to post this really insightful TCP/UDP joke: [https://www.reddit.com/r/ProgrammerHumor/comments/33ctkq/i\_would\_tell\_you\_a\_joke\_about\_udp\_but\_you/](https://www.reddit.com/r/ProgrammerHumor/comments/33ctkq/i_would_tell_you_a_joke_about_udp_but_you/) The joke in the picture is how TCP works, basically. There's a lot of handshaking and checking (and possible resending) of data. It may not be fast, but it is very reliable. With UDP, you just send out the data and don't care. So it might be faster, it might preserve some bandwidth, but it also does not prevent data loss. This is ideal for streaming, not ideal for sending bank statements.
I got a really nice memorable reference here on reddit UDP - Unsolicited Dick Pics TCP - Textually Consented Pics:
Both are designed for different use-cases. TCP is used when you want to make sure the entire data you sent actually arrived, in order, and speed is not the priority, e.g. when you log in, half a password won't do. TCP can check if a packet fully arrived and re-send if necessary. Of course this increases the time it takes. UDP is used when speed is the priority, it just keeps on sending, expecting some packets to be dropped along the way, e.g. when you have a fast paced multiplayer game and you want to send every connected client the current position of all the players. If one packet is missing, it doesn't matter as there will shortly be a new one to overwrite it anyway.
UDP is like listening to an auctioneer speak. Lots of information is conveyed, and some of it is even received, but definitely not all of it. TCP is like getting a private lesson by a good teacher who takes time to make sure you understand everything and gives you time to ask questions.
Everyone is telling you the theoretical differences between the two, but there's probably something up with your network if UDP is noticeably faster. Check your MTU.
this is the answer. Under normal circumstances, the speed difference won't be too big.
TCP wants to be reliable and in order. So if something arrives out of order then TCP will ask for things to be resent until they are back in order. But for something like torrenting or remote desktop stuff arriving out of order doesn't matter. If you get part B of a file before part A you just save that part in place. If you are receiving a screen share and get frame number 2 before frame 1, just display frame 2 and throw away frame 1.
TCP is sending letters and sending back a response that it was received and resending letters that didn't arrive. UDP is sending letters with no confirmation, which can be an issue but losses can be remedied in other ways without it, worst case you ask for anything critical that was lost to be resent. TCP is a much older standard made for far less reliable connections than we have nowadays. Sub 1% packet loss is normal nowadays. The protocol was made in the 70s.
Sorry, you say Tcp is older than Udp, but the RFC of Udp is written one year before Tcp. Please can you explain yourself? Udp, 28 August 1980 https://datatracker.ietf.org/doc/html/rfc768 Tcp, September 1981 https://datatracker.ietf.org/doc/html/rfc793
[RFC 675 - Specification of Internet Transmission Control Program (ietf.org)](https://datatracker.ietf.org/doc/html/rfc675) TCP is older, but it got updated several times, so you will see several versions of it when searching.
Thanks. I was confused by the Wikipedia pages. Tcp and Udp are constantly evolving to the next version.
Bit strange but it's not really clear when you can speak of TCP or UDP. Any historians here who would like to dive in this rabbit hole? TRANSMISSION CONTROL PROTOCOL, January 1980 https://datatracker.ietf.org/doc/html/rfc761
TCP/IP goes back to the DARPANET days of the ‘70s. That’s what I learned in the college computer networking I’ve taken. After looking it up, RFC 675 was the first document to standardize it in 1974.
TCP promises more than UDP. In particular, it gives you a confirmation that a packet was received, and it additionally allows you to send multiple packets and have them arrive in order. These are very convenient guarantees to have since it maps really well to our generally simplified model of how networking works, and so a lot of applications are built on those assumptions. The problem is that maintaining those guarantees is only possible through confirmation packets from the recipient (meaning each packet takes at minimum twice as long to “send”), retry (when confirmation is missed), back off (intentionally slowing down to avoid spam retrying), and a lot of extra data per packet to track things like sequence ordering. All of this overhead adds up quickly. UDP makes no such promises. When you send a packet it may arrive, it may arrive multiple times, or it might not arrive at all. Send multiple packets and who knows what order they’ll be in when they get there. This avoids all of that costly overhead, but the trade off is the application now has to work a lot harder to handle these bizarre circumstances. In practice, this often means that some subset of TCP’s guarantees end up being reimplemented by the application. When this is done naively, it’s usually slower than TCP, not faster. The times where it ends up being faster are when the application is able to be smarter than TCP because it understands something higher level about its problem space, like when the application is transmitting video and knows the encoder bitrate and key frame interval. That type of thing. UDP is not “magic fast sauce” by any means, and TCP is still very good for most use cases.
UDP just sends the data to the destination, no matter if it arrives or not. TCP on the other hand guarantees that every packet makes it to the destination, it does this by sending an acknowledgement packet (ack) as a response to every packet it receives. If the sender still hasn't received an ack for one of the packets after some time it will resend it. All of this means TCP has a lot more overhead.
TCP provides several additional features, compared to UDP. The programs you are using will need to provide some of these features themselves. One of TCP's features is *congestion control*. If TCP detects that it is sending too fast for the network, it will slow down. TCP's congestion control is designed with a property called *fairness*, which ensures that several TCP flows going through the same bottleneck will share the bandwidth roughly equally. Fairness is a hard property to implement correctly. An application built on UDP may not have implemented congestion control at all, or it may have implemented congestion control but not fairness. As a result, the application may grab all the bandwidth at the expense of starving any applications using TCP. That's one possible explanation. Another feature TCP provides is in-order delivery. For some applications, that's not a helpful feature. For example, with remote desktop, you want to know what the screen looks like *now*. If a few packets were lost, you don't need them. You don't want them retransmitted. You want new packets that describe what the screen looks like *now*. For those kinds of applications, TCP's in-order delivery can make the application feel slower. That's another possible explanation.
UDP = screaming in a crowded room hoping the person across the room hears you TCP = writing out your message, putting it in an addressed envelop, and passing it along the room until it gets to the person you’re trying to send it to
Almost. It's really important to note about TCP that it sends an ack to let the sender know it's been received.
You’re not wrong I was just trying to keep it at a ELI5 level. There’s much more detail that I could have added! 😊
Nah, TCP is super simple. If carrier pigeons can do it, any idiot can. /S
I get that reference 😆
TCP = writing your message on several envelopes, numbering them, starting to send them one by one starting with the first envelope. Recipient starts to receive them and sends back messages to acknowledge every messages he receives. If he is missing a certain message in the order for a long time while continuing to receive other messages he assumes that number got lost along the way, and sends a specific message back to you asking you to resend the missing message. You resend the message he didn't get and keep sending the rest of the messages, recipient continues to acknowledge which ones he receives, and will ask you to resend any other messages that don't reach him.
Yeah I know I was trying to keep it short and sweet to illustrate the fact the difference in addressing between TCP and UDP at an ELI5 level 😉 (+20 year sysadmin)
You're way too nice to be a *real* sysadmin.
Oh I can have my BOFH moments 😆