When sending data we start at the top of the model and work our way down we’re going to ignore the application layer as it’s largely out of our control and start at the transport layer the two primary network protocols at this layer are TCP and UDP.
A Computer network application has to choose how to send its data that choice comes down to, do I want to send it reliably, or do I want to send it unreliably? Both reliable and unreliable have their advantages and disadvantages.
The transmission control protocol (TCP)
The first thing to understand is when we send data, this file, it’s not sent all in one piece it’s send in lots of different pieces of data.
The receiving computer then collects these pieces puts them all together and then spits out the file and that’s fine but what happens if some of the data we send gets lost along the way?
The receiving computer won’t be able to put the pieces together and you’ll probably end up with a corrupted file so that is the reason we need some method to reliably send data.
Something that can resend and resolve missing or corrupted data and this is exactly what TCP does.
TCP is the most widely chosen option for transmitting data this is because it can reliably send and receive data.
If there is a network blip and some of the segments are lost along the way TCP can recover them meaning the user experience shouldn’t be compromised with half-loaded websites or corrupted documents.
The way TCP can provide such a stable and reliable connection is in three ways
1 A uses acknowledgment numbers,
2 It uses sequence numbers
3 TCP adds a checksum
But before any of that can happen first we need to start a strong connection. TCP does this by using what’s called a three-way handshake First the sender computer sends a message called an SYN which is short for synchronization.
The receiving computer then replies with an ACK message, this is short an acknowledgment and it also includes an SYN message of its own, so this message is called an SYN-ACK lastly the sending computer acknowledges with an ACK message.
Now we have an open TCP connection.
A similar process is also following when closed in this connection down ok so the next step is to look at sequence numbers.
TCP will assign numbers to segments as they are sent this way the receiving device can collect these segments record them correctly and determine if any segments are missing.
The sequence number is just one field in the TCP header. These messages are then acknowledged it’s almost like saying ‘’sending data’’ and the receiving computer says ‘’got it’’ and so on.
The way this works is by using sequence numbers and acknowledgment numbers so I also mentioned a checksum.
The checksum is a result of a simple calculation ran against the data. If the data has been transmitted successfully the checksum ran on the receiving side should match the checksum ran on the sender’s side.
If there have been some problems along the way and some bits got messed up then there will be a checksum mismatch and the segment will be discarded as we’ve already seen a TCP header is added to the application data to create this is a TCP header.
The sequence and acknowledgment numbers and the checksum is, for now, there’s so need to worry about the other bits of information.
User datagram protocol (UDP)
Now unreliable communication comes in the form of UDP has none of the error handling Sequencing or reliability of TCP.
You can think of UDP as a kind of machine gun of data just firing and firing not caring if data is lost or not it has one goal that goal is to send data.
So why would we ever consider using UDP if it’s so unreliable?
While TCP offers a great connection and reliability, it all comes at a price of resource and latency this is great for most common tasks such as web browsing, file transfers, etc.
Where we don’t mind the latency issue in return for a stable connection where UDP is useful is in the situations where we need a live real-time connection, for example, voice calls, video calls, and gaming alone need fast real-time connections.
We can’t afford latencies in this situation we can handle a loss of voice data because who cares about a bit of jitter in a voice call on the other hand if we start trying to resend voice data then this could cause latency and make the call inaudible.
So now let’s look at a UDP header
As you can see there is a lot less information here than there is on the TCP header we only have the port numbers the length of the data and a checksum the small header means less information but is lighter and is quicker perfect for real-time traffic.
That’s it for TCP and UDP two ways to send data for two different purposes.