“The Internet is a giant international network of intelligent, informed computer enthusiasts, by which I mean, “people without lives.” We don’t care. We have each other.”
Humorist Dave Barry
Making Your “Net Work” for You…
We’re sure it’s no surprise that many of our Learn Blog articles have already explored different aspects of internet protocols. You can rely on past articles with topics like peer verification and competing encryption algorithms as reference material. Here at NetBurner, we’re all about helping you cut through the fog to make the internet truly useful. In this article, we introduce and compare two of the most widely used internet protocols, TCP and UDP, in order to give you a leg up in understanding their similarities and differences.
Alphabet Soup: The ABCs of TCP and UDP
Let’s compare TCP and UDP.
The TCP acronym stands for Transmission Control Protocol. You’ve probably seen it most often paired with IP, the Internet Protocol, as TCP/IP. It is arguably the most-used protocol among the many protocols classified as Internet Standards.
The UDP acronym stands for User Datagram Protocol. While you’re more likely to see UDP mentioned on its own, it is occasionally referred to as UDP/IP.
Both are Internet Standard network communication protocols. (Standards are clearly identified in the RFC Index as “Status: INTERNET STANDARD.” An RFC is a “Request For Comments,” the source of all de facto-standards maintained by the Internet Engineering Task Force (IETF), that define how the internet actually works. Both UDP and TCP were formalized in the early 1980’s with the publication of RFCs 768 (UDP) and 793 (TCP).
Both TCP and UDP are potentially useful for IoT, the Internet of Things. So how do you choose between the two when you have to decide for your particular application?
A Restaurant vs Cafeteria Simile
In our ongoing effort to give you an intuitive understanding of important technologies, we’re going to use a simile to help compare and contrast TCP/IP and UDP.
And, no, we did NOT say a ‘smile;’ we said—and meant—a ‘simile.’ Of course, you’ve gotta admit that NetBurner products and our Learn Blog articles do make you smile, right?
In today’s simile, you’ll learn that TCP is like taking your date to a fancy restaurant, while UDP is more like grabbing a quick bite at the company cafeteria.
TCP is Like Dining at a Fancy Restaurant
When you take your date to Chez Posh, once you’ve made the reservation, you pretty much want the details for the rest of the evening to be someone else’s problem.
You’re not in any particular hurry. You expect the restaurant staff to do all the work. They’ll recommend entrées to suit your taste. The Chez Posh staff attends to your every need, so you can focus completely on enjoying a pleasant conversation with your date.
At the end of the evening, there’s nothing for you to clean up; you don’t have to clear the table or wash the dishes. You simply settle the check and take your date home.
UDP is Closer to the Company Cafeteria
You might think of UDP as more like chowing down at your company cafeteria. You’ve only got fifteen minutes before a meeting with the boss? Quick, hit the cafeteria, grab a tray, go to the buffet, select a dish or two, eat, and then get your tail to that meeting on time!
Nobody’s going to serve you, and you don’t expect them to. You know that you have to fend for yourself. You even have to clean up after yourself, placing your tray and dishes on the washer rack. But you don’t mind, because you can get in and out fast.
Breaking it Down: Some Gritty Details
We aren’t going to go deep today; that’s not our purpose. If you need them right now, you can get all the bit and byte level details from the links we provide throughout this article.
We will, however, look at specifics of some of the most important operational differences between TCP and UDP so you can make an informed choice between them for any project you may be working on.
Connection vs Datagram
TCP is connection oriented. In our fancy restaurant analogy, from the time you’re seated, your “connection” to the kitchen is managed by the wait staff, taking your orders in one direction and serving your requested food and drink in the other. Your multi-course “meal protocol” continues right up until you settle the check and walk out the door.
Similarly, TCP establishes a durable connection between your application and an app running on a remote server. As long as the network is operating, it’s almost as if both client and server are in the same room. And your connection isn’t over until you close it.
UDP, on the other hand, never “connects.” It simply issues a datagram (a single internet packet unassociated with any other, as defined in RFC 1594), after which it is done. UDP doesn’t know, or care, if that datagram ever gets to its destination.
In the cafeteria analogy, it’s a bit like realizing you forgot the butter; you just go back and grab a pat or two, but it’s not part of some overall plan you made before you arrived.
State vs Stateless
Your dinner at Chez Posh is a well-planned, continuous series of events that take place in a well-defined order. It may start with drinks in the bar, and then progress through appetizers, your entrée, and end with dessert and coffee. You and your date expect good service, and your fancy waiter knows how to make it happen.
Similarly, your app need not worry about details. TCP maintains, transitions through, and updates quite a few “states” during a session. A connection is ESTABLISHED. TCP exchanges packets in both directions between client and server. It tracks what’s happening until the connection is intentionally CLOSED by your application.
But, at the cafeteria; who knows why you’re there?
Maybe you just stopped by to put a twenty on your tab. Maybe you’re there to suck down some coffee while you read the latest Learn Blog article. The manager doesn’t have a clue that you’re on your way to a meeting, and he really doesn’t care.
Likewise, with UDP, a datagram could be coming in or going out for any reason at all. The UDP software doesn’t know and doesn’t care; it’s all up to your application.
Byte Stream vs Packets
During a TCP connection, your application enjoys a steady stream of bytes in both directions, much as, once you and your date place your orders, you enjoy a steady supply of food and beverages. You don’t need to go back and forth to and from the kitchen. You don’t have to refill your own drinks.
But in the cafeteria, you have to get up and get your own damn refill, or grab another slice of toast; there’s no waiter hovering nearby to do it for you. Similarly, if an app using UDP needs its data refreshed, it has to invoke UDP to send another datagram. UDP sends it and forgets it; the app has to keep track of the “meaning” of everything.
Chicken or Egg? Data Order…
At Chez Posh, the Deviled Eggs will always come before the Chicken Cordon Bleu; whereas, in the company cafeteria, you may just eat the Buffalo Chicken Wings before your Egg Custard dessert.
In other words, data sequencing is important to TCP. TCP guarantees that data bytes arrive in the same order that your app sent them.
On the other hand, UDP packets may show up in any order—if they show up at all.
Reliable vs Lossy
At that cafeteria, while rushing to your table, one of your three egg rolls rolls off the tray and bounces under a table… Do you stop to pick it up? Nope; you can’t be late for your meeting! UDP is a bit like that; raw speed is more important than getting every packet through.
TCP, on the other hand, ensures that every data byte either makes it to the destination app or that both client and server are aware if it doesn’t.
Much like TCP, your fancy waiter at Chez Posh makes sure that not a single item you ordered is left in the kitchen, or he apologizes with great sincerity if he discovers that the entrée you ordered is actually sold out.
Error Free vs Corrupted
When you take a seat on the mass-produced resin chair at the formica table in your tacky company cafeteria, you notice that you accidentally grabbed the macaroni instead of the potato salad. Damn! Oh, well, you’re not going back, but you aren’t going to eat that slop either.
What happens to a UDP datagram when, for example, a CRC error occurs? It gets dumped, just like that (yecch!) macaroni salad you can’t stand.
Your Chez Posh experience is totally different. Because your fancy waiter wants a healthy gratuity, you can be quite sure that every detail of your dinner will be très magnifique.
Likewise, when the TCP protocol discovers a corrupted packet, it sends back a NAK, requesting a replacement packet. This may take a bit longer, but accurate delivery is ensured. Your app can be sure the byte stream is perfect.
Handshake/Ack vs None
TCP starts out with a ‘Syn – Syn/Ack – Ack’ handshake that establishes a connection:
The connection ends with a similar back and forth handshake that ultimately leaves both client and server in a “CLOSED” state.
The “handshake” that begins your evening at Chez Posh starts with ‘Reservation – Hostess Seating – Waiter introduction:’
“I’m Jaques, and I’ll be your server tonight.”
When the evening ends, your credit card going back and forth to settle the check is the “CLOSE” handshake.
In contrast, UDP has no handshake; a datagram is issued to an address; that’s it. Likewise, at the cafeteria, it’s all on you. Show up, leave, eat, pay, handle things any way you like. The same goes for UDP; how and why you use it is all up to your application.
Flow Control or Let ‘er Rip?
Do you want your application to have to constantly check to see if the data channel is available?
We didn’t think so. Of course, there are a couple of approaches to this; you could have someone else (TCP) check for you, or simply open the valve on your fire-hose (UDP) and let it blast!
At Chez Posh, your waiter keeps a close eye on your dining progress, and won’t bring dessert until you’ve finished your entrée. Similarly, TCP automatically starts and stops data flow as the network, buffers, and connected devices are able to accommodate it.
UDP, on the other hand, is like a fire hose… Open the valve, and blast away! The cafeteria equivalent of UDP might be like you operating the yogurt machine yourself… If that cute cafeteria worker distracts you, and you forget to turn off the spigot in time, some yogurt is bound to end up on the floor.
Slow vs Fast
For a lot of use cases, speed may be your most important consideration. Like the cafeteria option, UDP eliminates a lot of overhead. This allows you to cut to the chase and get things done quickly. Because UDP makes no assumptions about one-way vs two-way traffic, data sequence, error correction, etc., it can be blazing fast.
TCP on the other hand is considerably slower. Just as you don’t have to worry about a thing during your relaxed evening out with your date, TCP handles all the nitty-gritty details that you may not want your application code to worry about. It’s an obvious trade-off. Your application has less to do, but TCP is substantially slower than UDP.
Point to Point vs Multicast
When you step up to the cafeteria salad bar, you aren’t alone. Several co-workers are right there alongside you, getting salad from the same place. UDP, like that salad bar, can dish out packets and have them routed to many destinations at once. This is called IP Multicast, and is covered in Internet Standard RFC 1112.
In contrast, at Chez Posh, you and your date have an exclusive “foodie” connection with the chef, mediated by your professional waiter. Likewise, TCP maintains a one-on-one relationship between client and server from the time a connection is established until it is closed.
Typical Use Cases
Now that we’ve looked at many detailed differences between the two, let’s get down to brass tacks and pick one for the project at hand.
In the final analysis, why might you choose TCP?
Pick TCP for reliability. Go for TCP if you want to write a simple application. TCP is actually the transport layer already used in many higher-level protocols, some of which you use all the time.
TCP is used by these popular protocols:
Here are some major examples:
- Serving up a web page using HTTPS
- Downloading a file via FTP
- Sending an email report anywhere using SMTP
- Connecting a service technician via Telnet
- M2M via DDS
- Sensor data flow via MQTT
If your application invokes any of these protocols, you are already indirectly using TCP. Your applications can of course invoke TCP directly, establishing a reliable bidirectional (i.e. full duplex) byte stream between two endpoints.
Alternatively, why might you choose UDP?
UDP shines when it comes to speed, real-time apps, and custom-designed tasks. Like TCP, UDP is also used by many common higher-level internet protocols.
UDP is used by these popular protocols:
Examples of UDP-based protocols include:
- Resolving a domain name using DNS
- Automating configuration of a local network with DHCP
- Quick and dirty data file transfer with TFTP
- Network management with SNMP
- Internet routing with RIP
- Telephony using VOIP
- M2M via DDS
- A Web of Things via CoAP (Constrained Application Protocol)
- Custom protocols; e.g. that monitor IoT sensors and control devices
You’ll want to pick UDP for audio and video. Go with UDP for real time applications. Use UDP for things that are repeatedly updated. Maybe you’re sending constantly changing weather data. Like Mark Twain said of New England weather: “If you don’t like the weather in New England now, just wait a few minutes.” Other examples of transient data might include stock quotes, video streaming, and gaming apps.
Is our simile slightly stretched?
Perhaps just slightly…
But we hope that, like a stand-up comic (see what we did there?) it’s been entertaining as well as educational. We also hope that we’ve supplied enough background for you to make an informed choice for your next network enabled project.
TCP is like “dining in style,” as long as you’ve got the time. UDP is cafeteria style, but you can rockin’ get your task done fast. Now that you understand the difference, go forth and network!
NetBurner Supports Both TCP and UDP
Pick a device; (almost) any device. All NetBurner products (except non-networked MOD5213) support both TCP and UDP protocols, and so you can configure your NetBurner product according to your project needs.
NetBurner Support: We’re Here for You
Please leave us a comment or question below. You can reach us by email at [email protected]. We really want to help you with your particular internet applications, and we’ve got a large stable of products to offer that will get you up and running fast.
Other TCP and UDP Resources
RFC Source Documents
Request For Comments (RFC) Index — RFC Index
Internet Protocol (IP) — RFC: 791
User Datagram Protocol (UDP) — RFC: 768
Transmission Control Protocol (TCP) — RFC: 793
Protocols that use TCP and/or UDP
Some IoT protocols — Internet of Things (IoT) Protocols and Connectivity Options: An Overview
CoAP for micros – CoAP Protocol Tutorial: Step by step guide
Comparing two M2M protocols — What’s The Difference Between DDS And AMQP?