When a computer is sending out traffic it needs to send the data packets from its own IP address (source address) to a destination IP address. So IP will handle the addresses of different devices on a network.
But different programs and services have very different requirements regarding how they prefer that traffic should be sent over the network. To some programs, it is extremely important that not a single data packet is lost, and that no packets are received in the wrong order. Other programs might not care if some errors or packet losses occur. Instead, they might prefer that the traffic is just simply being sent as quickly as possible.
This is where TCP and UDP come into play. They are Transport Protocols that govern how traffic is sent over the network.
A protocol is a compilation of information regarding decisions on how something should be performed. One obvious example of a protocol is a simple meeting protocol that describes what was discussed during the meeting and which decisions that were made.
Networks and computers use loads of different protocols that govern how communication should be handled, how data should be sent and so on. Here are two examples:
The protocols are produced by different standard bodies where experts from many companies and organisations are working together to agree on how the communication should function. This is to guarantee that equipment such as routers from different vendors can work together when you interconnect them. Without these standards, no equipment from any vendor would be able to work together with equipment from any other vendor. |
TCP is absolutely packed with functions that make sure that traffic will arrive in the correct order, that no packets are lost, that any lost packets are automatically sent again, and so on.
UDP, on the other hand, is designed with speed in mind. It has very few safeguards and it doesn’t care if packets are lost or arrive in the wrong order. UDP is made to be fast and simple without any extra controls.
It is the person who creates a computer program that chooses which transport protocol that the program should use when it communicates. The choice is made based on how the program should act and which requirements the program will have for its network communication.
Many programs might use both UDP and TCP for different types of traffic. For example, a lot of online computer games could use TCP for player logins and a lot of other features but might use UDP to transfer live continuous events in the game world between the player and the servers.
Most programs that you use on a daily basis will utilise TCP. This is because the program can then rely on TCP to always deliver all packets correctly. With UDP, the programmer who is creating the program must make a lot of decisions about how the program should detect and handle lost packet and packets that arrive out of order.
Of course, there are a lot of programs and services that prefer UDP. DNS is such an example. Each computer needs DNS to be able to browse the Internet and make domain name lookups. After all, that is how computers find out which IP addresses that different domain names correspond to.
One reason for why DNS uses UDP is that it doesn’t matter much if a DNS query disappears every now and then. The computer will notice that it doesn’t get any DNS reply, and if no reply arrives then the computer will simply send out another DNS query. The only effect is a slight delay in the communication, but once the computer gets the DNS response then the communication can proceed.
Another example where UDP is commonly used is IP telephony, also known as VoIP (Voice over IP), which means making phone calls over the computer network instead of placing calls over the regular telephony network. When you speak with somebody over IP telephony the phone or computer will transform speech into data packets that are sent over the network to the person you are talking to.
Humans don’t have any particular issues with understanding what somebody else says even if a few milliseconds of speech were to disappear here and there. So even if a data packet would be lost every now and then we can still understand what the other person is saying.
If however TCP would be used for IP telephony and a data packet would disappear, then TCP would make sure that every other data packet that contains the speech is put on hold in a queue while the lost packet is re-sent. So the whole conversation is put on hold while TCP is waiting for any lost packets to be retransmitted. Imagine this happening over and over throughout a conversation.
For that reason, it is better for a VoIP call if a few packets here and there are lost (UDP) than if you would have to wait for any lost packets to be re-sent and arrive in the correct order (TCP).
So because different programs have different communication needs and requirements, the various programs will use either TCP or UDP when they want to send out network traffic.
Back to the Ports
Let’s get back to the Ports again now that we have mentioned what TCP and UDP are and how they are different from each other.
The ports that are used are not a part of the Internet Protocol or IP address. Instead, they are a part of the TCP and UDP transport protocols. So any data traffic can be said to be sent to an IP address – meaning which computer or server that the traffic is sent to, and to a Port – meaning which service or program that the traffic is sent to.
When the computer has some data that it wants to transmit it puts the data inside a UDP or TCP message, depending on which protocol that the application wants to use. The computer enters the Port addresses into the UDP or TCP message.
Then the UDP or TCP message is put inside of an IP packet, which is in turn addressed by the computer using IP addresses.
Since applications always listen to a specific Port but also a specific Transport Protocol (UDP or TCP), then you always have to know not just which port that is used, but also which Transport Protocol that the program uses.
A lot of people simplify by saying for example “Program X listens on port 1337”. And even though that statement is not exactly incorrect it also doesn’t provide the full picture.
Instead, you would have to say “This program listens on port 1337 TCP” or “The program listens on port 1337 UDP”. That extra piece of information becomes important when you want to do a Port Forward, or if you were to permit the traffic through a firewall. Of course, you could create a Port Forward for both UDP and TCP just to be sure, but sometimes this could cause problems. Also, it is always best practice in computer networks not to permit more traffic from the Internet than necessary to reach your internal LAN network.
Previous part: |
Next part: |