Understanding the UDP Protocol

Most everyone is already familiar with TCP as a transport protocol. Not as many though are as knowledgeable with UDP as a transport protocol. That is for a good reason. Almost every piece of data out there whether it be application, session, or other layer is transported via trusty old TCP. This brings to mind another thing I hear quite often from people, “Yes, TCP is guaranteed to get there, you know.” This statement, in fact, is quite wrong.

TCP or Transmission Control Protocol is only connection oriented. UDP or User Datagram Protocol however is connectionless. What does that mean exactly? Well, if you have read the articles of mine on TCP you will have noted that TCP has a great many metrics included in its header. These very same metrics, i.e.: TCP sequence number, acknowledgement number, are what makes it connection oriented. Lastly, TCP had a standard header length of twenty bytes, vice eight for UDP.

How does UDP differ?

Well our UDP protocol only has a length of eight bytes to be exact. That is twelve bytes less then TCP. Due to this, UDP is much faster as there is less to transmit. An extra twelve bytes may not sound like a lot, but multiply it by thousands of packets, and you will quickly notice a difference on your network. Seen as an UDP header is that much smaller, exactly what does it look like, you ask? Good question! Please see below for a diagram of what a UDP header looks like.

_____________________________________________________
Two byte source port number |  Two byte destination port number
_____________________________________________________
Two byte UDP packet length  |  Two bytes UDP checksum value
_____________________________________________________
Data if any

So we can see from the above that not having the extra twelve bytes of overhead in the UDP header does indeed make a substantial difference. This would account for the lack of “connection oriented” for UDP. You may note, that we also have a checksum in the header for UDP. I would like to take this time to point out that all of the four core protocols, those being; IP, TCP, UDP, ICMP all have checksums. In all of the four core protocols the checksum will cover the protocol header and any data, if present. One of the last things I would like to mention about UDP and its checksum is that its use is optional. In essence, it does not have to be used, whereas in TCP, ICMP, and IP, it does.

Is it guaranteed? Heck no!

Well, now knowing that UDP actually offers no guarantees of delivery, much less any built in metrics for it, why would you want to use it? With that in mind, it is normally decided by the developer, aka the programmer, what transport protocol they want to use when designing a new application, or other layer protocol. There could very well be instances where speed and size of a packet is a consideration. Should these factors be a consideration to the developer then the odds are that they will choose UDP as their transport protocol.

Hmmmmm, well all that is good and great, but do any application layer, or other protocols actually use UDP? Excellent question, and the answer is yes. There are quite a few applications that use UDP for transport. One of the best known to most is DNS or domain name system. The vast bulk of traffic generated by DNS is actually ferried about using UDP. On a side note, DNS is one of those protocols that will actually use both UDP and DNS. That being said most DNS activity is actually DNS queries and responses. These, as just mentioned, are carried via UDP.

Are we ever going to see a UDP packet!

Well seen as I can sense your anticipation to get into the guts of UDP how about we look at a UDP packet, and go over the various fields described above in my snazzy diagram.

02:00:04.079943 192.168.1.100.53 > 192.168.1.200.57746: [udp sum ok]  60865 FormErr% [0q] 0/0/0 (12) (DF) (ttl 253, id 9987, len 40)
0x0000   4500 0028 2703 4000 fd11 619a c0a8 0164        E..(‘.@…a…..
0x0010   c0a8 01c8 0035 e192 0014 ba83 edc1 8091        …..5……….
0x0020   0000 0000 0000 0000 0000 0000 0000             …………..

Now if you have been reading all of my articles you will realize that there is an excellent resource to walk through packets. In case you have not please go here and download the TCP/IP and tcpdump flyer. It is under the “Additional Resources” section. With this document in hand we are now ready to navigate the packets contents byte by byte.

One of the ways to quickly orient yourself in a packet is to go to the destination address in the IP header. That is found on line 0x0010 and is the following four bytes of info; c0a8 01c8. We know that unless there are options in our IP header that the protocol following the IP header  (in this case UDP) as evidenced by the 11 in hex. The 11 is seen on the first line 0x00 and is in the following “fd11”.  Using some of the IP header metrics will allow you to quickly orient yourself to where the follow on protocol starts.

So with that said the first byte of our UDP header is then found at 0035 on the line 0x0010. It is noted on our downloaded TCP/IP cheatsheet that the first two bytes of the UDP header are devoted to the source port. Well if we convert our hex value of 0035 we will see that it indeed corresponds to the source port noted above in the packet ie: port 53.

So far, so good? Now after the source port the next two bytes are for the destination port as evidenced by the hex values of e192, or as it should be represented by me for clarity 0xe192. Once we convert this to decimal we see that it indeed matches the destination port in the packet pasted above.

Excellent, we are well on our way through the UDP header! Following this is the UDP packet length as represented by the hex value of 0x0014, which converts to 20 in decimal. That is indeed as it should be. Next up is the UDP checksum value, and that is assigned two bytes much like all of the previous metrics seen so far ie: source port number, destination port number, and UDP packet length. The checksum value in this case is 0xba83. We do not actually see this value represented in the packet header but that is as it should be. Just be aware that this is where it would be found.

Well now seen as this is the end of the UDP header, following right after it is where the application layer data would be. In this case that would be the DNS information. There is a lot more to the UDP protocol then this alone, but I would suggest that be further reading done on your part to help enhance your knowledge of this unappreciated protocol. As always, I sincerely hope this was of use to you, and I always welcome commentary.

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top