Changing Lives One Smile At A Time!

TCP and UDP


Before we head back to L3 and start work with routing protocols, let’s take a few minutes to go into more details about the going-on at the Transport Layer(OSI Layer4).

TCP and UDP get the job done here, but they do so in wildly different styles.

TCP:

  • Guarantees delivery of segments.
  • Performs error detection and recovery.
  • Performs “windowing”.
  • Is connection-oriented, meaning there’s a two-way communication between sender and sendee before the data is actually sent. (There is an underlying agreement on a couple of values.)

UDP:

  • “best-effort” delivery
  • No error detection
  • No windowing
  • Is “connectionless”, meaning there’s no communication before data is sent – it’s just sent!

That first TCP bullet point might be enough for us to decide to use TCP for everything. Guaranteed delivery vs. “we’ll do our best” – I love the idea of a guarantee! Why wouldn’t I want guaranteed delivery of every data segment?

There must be a reason to use UDP, since our networks use it every minute of every day. UDP’s “clients” include DHCP(if your network uses DHCP which it probably does, that’s the protocol that dynamically assigns IP addresses, and UDP handles that) , and also UDP  is used to handle our most delay-sensitive type of network traffic – voice and video!

If TCP is so great, why is UDP so popular? Keep that question in mind as we have a look at the details of these TCP features, starting with the three-way handshake.

A Three-Way Handshake?

That’s what I said the first time I heard about TCP. How can you have a three-way handshake? And even if you can have one, why would you want one?

With TCP, there’s work to be done before segment transmission. The involved devices have to agree on basic parameters of the conversion before the conversation can occur, and this agreement happens during our three-way handshake:

The initiator sends a TCP segment with the synchronization (SYN) bit set. The TCP sequence number, a major part of TCP functions, is the primary value that is synced at this point.

So even though we have a three-way handshake, we have two devices involved.

So we have the “SYN” that goes out first. The second part of that shake is when the server responds here to the first host and it’s called a SYN/ACK, because the server is synchronizing and also acknowledging that it received that first SYN in the first place.

Finally the third part of that handshake is an acknowledgement of an acknowledgment or an ACK of the ACK. But when Host A responds then it’s just an ACK.

So it’s SYN and then SIN/ACK and then ACK and then that’s a three-way handshake and once that’s done, the segments can begin flying.

TCP Error Detection And Recovery

The TCP header contains separate fields for the sequence number and the acknowledgement number, and it’s these two values that allow TCP to detect lost segments and in turn recover from that loss. (I’ll refer to “acknowledgement” as “ack” from here on out.)

Here, a host is sending four 2000-byte segments after the three-way handshake is complete. The sequence numbers are used by the recipient to determine the order of the segments and to anticipate the number on the next segment.

Your TCP sequence numbers are not going to be this neat. They can have 7, 8, 9 numbers but for our theory I want us to stick with something a bit friendlier.

So your host could send four segments over to the server and it’s got four sequenced numbers 2000, 4000, 6000, 8000 and we can certainly figure out what the next one’s going to be.

The recipient will send an ack back to the transmitting host, and that ack serves two purposes:

Obvious: The ack lets the sender know the recipient received the segment. After all, it is an ack

Not-so-obvious: The acknowledgement number in that ack allows the sender to determine if any segment were lost during transmission. If they were, the sender will re-send them.

The ack number is not set to the number of the last segment received. Instead, it is set to the number of the next segment the recipient expects to see. With this pattern, that would be 10000. This cumulative acknowledgment scheme allows the sender to identify segment loss.

In this situation, the server receives 2000, 4000, 8000 but segment 6000 got lost along the way. So what happens in this situation?

Let’s just have a quick note here on this cumulative acknowledgment scheme.

Here is the visual for it where the server is sending that acknowledgment back and also indicating the next sequence number it expects to see, and that’s why you’ll also see this called Forward Acknowledgment.

So cumulative acknowledgment and forward acknowledgment are really the same thing.

That’s the entire principle where the recipient is sending the ack back and saying OK here’s the next  sequence number I expect to see, and that’s where error recovery does come in.

Here you can see we’ve lost sequenced 6000. So 2000, 4000, 8000 get through, the servers looking at it and saying: “ OK the next number I really expect to see is 6000 because I see the pattern. This one didn’t get here. I haven’t seen it yet. So I’m going to send an ack back.”, And that is where the error recovery comes in.

The error recovery is really being performed by the sender because when Host A gets that ack back from server A and says “acknowledgment 6000”, the host is going to say “wait a second! I sent that one and then I sent another one after that!”

So it’s going to say : “OK I realize what’s going on. Let’s retransmit.  It expects to see 6000 next. So that’s what I’m going to do.”

So once that one is sent, then the server gets that one. It gets 6000. Now it already has next one in line (8000), so then just that quickly we’re back on track with server A saying: “OK I’m acknowledging 10000 which is the next sequence number I expect to see.

Now two questions comes to mind:

How does the sender know how many segments to send before waiting for an ACK?

Wouldn’t it be easier to detect problems if the recipient sent an ACK for every segment?

Let’s answer those questions while we take a look at two more great TCP features!

Flow Control and Windowing

One of the values negotiated during the three-way handshake is the size of the window, the number of bytes the sender can send without receiving an ack. There is a limit and when that limit is reached, it’s like “OK I’ve got to hear an acknowledgment or I can’t send anything else.”

The host might say “7000 byte at a time.” And the server might respond: “let’s start with 4000 bytes and go from there.”

The important thing to remember about this window is that it is dynamic. It is not static. So when they come to this agreement (say it 4000 bytes), that doesn’t mean the size of the window is going to stay at 4000 bytes.  So that’s why you’ll see this called a dynamic window. You’ll see it called a “sliding window” because the window value itself can change.

What happens is: as recipient in this case is receiving the data and saying “I’m not seeing any errors creep in and not dropping any segments. We should go a little faster.”

So one of the acks says: ”Hey here’s your ack and by the way let’s enlarge the size of the window to 5000 bytes.”  and then later as the server sees little errors start to creep in (maybe some segments get lost), then it says : “ Hey here’s your ack. Let’s slow it down a little bit.”

So it’s interesting to note that it’s the recipient of the data that’s actually controlling the flow. (You think it would be the sender , and the sender just keeps going and going a little faster!  Doesn’t work that way!)

It’s actually the recipient that’s continually saying: “Hey let’s pick it up a little bit. Let’s hit the gas! Hey wait a minute ! Let’s slow down a little bit!”

This is that TCP Header. We’ve seen all the advantages of TCP. We’ve seen the error recovery, We just saw flow control, We just saw windowing, and you can see actually some of the fields that we’ve referred to. There is the source port and destination port, sequence number, acknowledgement number, window… and finally the data.

This is UDP header. It has much fewer fields. It can’t do windowing because there is no window field. It can’t do sequence numbering. It can’t do error recovery. It can’t do acknowledgement because there is no place to put an acknowledgment number and a sequence number.

All of these great TCP features come with a cost, and that cost is higher overhead.

The headers you see here are attached to every segment. The header size difference really adds up, especially with the delay-sensitive voice and video traffic found on today’s networks.

(Everything we do on a Cisco device or any vendor’s device like a tablet or laptop or a switch or a router, comes with a cost. A little heat to the CPU, a little extra work here, a little extra work there. TCP overhead doesn’t seem to be that big a deal when you’re just looking at one segment. But we’re not looking at one segment! We’re looking at a lot of segments. So that’s a header that not only gets attached to every segment, that’s a little extra work. It takes up a whole extra bandwidth because the header is bigger, and of course the device on the other side of that connection has to unpack that header  so it’s a little slower. )

Another issue is that TCP’s three-way handshake and forward acknowledgment schemes, while generally seen as positives, use bandwidth that UDP does not.

So the reason you see  UDP with so many important network features including DHCP, is it has much less overhead that TCP does.

Note: remember this for the switches and routers as well. Don’t use all the features they have at the beginning! Just turn on the ones that are going to do you some good. Because everything we ask the switch  or router to do , there would be a little bit of a cost, and that cost does accumulates.

Let’s leave the TCP-UDP differences behind for a moment and remind ourselves of their similarities:

  • They both run at the Transport Layer.
  • They both perform multiplexing, which we’ll take a closer look at right now.

What is multiplexing?

How does a server handle multiple and simultaneously flows from a host?

Host A at 10.1.1.1 is sending three separate flows of data to server A, and at least one of these protocols should be familiar to you.

The server has to have a way to keep those flows separate, or recognize them as they come in because the server in this case has got to look at TFTP. It’s a trivial file transfer protocol. When that flow comes in, the server has to say “OK I want to send that to my TFTP application.”

When another flow (data for another protocol) comes in, it has to be able to look at some value and say “OK this is HTTP traffic. I know how to handle that.”

The server needs a way to keep those incoming flows separate in order to send the TFTP data to the application that is designed to handle that data, SMTP data to the appropriate application, and so forth. That’s where well-known port numbers come into play.

These port numbers might not be well known to you (yet), but our network devices know every single one of them, from the common to the obscure. The three protocols mentioned in that list each have a well-known port number.

The three protocols that were mentioned above, each have a well-known port number of their own.

TFTP always runs on UDP port 69

HTTP always runs on TCP port 80

SMTP always runs on TCP port 25

Why are these assignments made? Because when a server receives data, and in this particular situation the destination IP address for all of this data is 10.1.1.2 (it’s all coming into that server), the server is going to have a way to know which data is TFTP, which data is HTTP.

What it does, it looks at the port number. The destination port number is how the server keeps these data flow separate.

So when data comes in on UDP port 69, the server always knows that’s TFTP data. If something comes in on TCP port 25, server knows it’s SMTP.

And that’s where the port numbers come in.

It also makes multiplexing possible because it would not be very efficient if Host A had to announce the server A : “ OK I’m now sending a flow of SMTP traffic and that’s it!” and then it just sent SMTP traffic while buffering the other traffic that it could also be sending at the same time. But it couldn’t if we didn’t have port numbers,

But with the port numbers, that makes multiplexing possible, and multiplexing is just a fancy way of saying “ we are allowing the mixing of traffic during transmission.”

So we can mix SMTP traffic with TFTP traffic which we can mix with HTTP traffic and so forth.

The mixing of it doesn’t matter because when the server gets it, it can look at those port numbers and say: “ OK I know what’s going on!  Here is data coming in on this port! It goes with that application, coming in on TCP port 80 goes to that application, and so forth…”

So multiplexing is really just a fancy way of saying we’re allowing mixing of traffic.

“Socket to ME?”

The term “socket” suggests a physical item, but in this context. It’s strictly logical. A socket is the combination of IP address and port number. For example, the socket for TFTP traffic at host 10.1.1.2 is 10.1.1.2:69. Occasionally, you’ll see a socket expressed in this format:

IP address, transport protocol, port number

In that case, the TFTP socket would be  (10.1.1.2. UDP, 69)

And Now For Something Slightly Different

You might not want to hear this, but TCP has a four-way handshake you should be aware of.

(They are not just adding something to the three-way handshake! This happens at the end of a TCP-based communication because once the segments have all been sent, we don’t want the overhead of keeping up that little control conversation.so we’re now going to have an orderly termination of the communication).

That’s right. We figured out a way to get another “way” in there! You won’t see this at the beginning of a TCP-based communication, though, as the four-way handshake is the termination of the communication. The FIN (”finish”) bit wasn’t involved in the 3-way shake, but it’s at the core of this operation.

Basically you have FIN,ACK   ACK    FIN,ACK   ACK

The originator of the conversation sends over a fin,ack  and basically it’s saying: “ OK It’s time to tear this baby down.”

The server will acknowledge that and then sends an ack,fin of its own, and then Host A would ack that.

( as you saw, it was orderly)

So it’s a very polite tear down of the conversation. But again each device will send a fin,ack and an ack during this tear down (the four-way handshake) at the end of the TCP communication and that’s that.

Obvious Note:  UDP doesn’t have those! Because UDP doesn’t have a fin bit, so it can even begin to do this.  

Leave a Reply

Your email address will not be published. Required fields are marked *