In the huge world of software development, there is in most cases, the use of networking which comes in the shape of using application protocols like SMTP, HTTP/S, DNS, FTP, XMPP(Chats), RTP , WebSockets and more…

All of these protocols as specified are application layer protocols.
Regarding the OSI model, a application layer has lower level protocols which they use.

Sometimes, due to many protocols it might be confusing how everything actually works, and I wanted to help clarify that.

What it means, is that if we’re using HTTP, we’re also using TCP under the hood. Our entire communication flow regarding the HTTP protocol is guaranteed by TCP, to make our messages to be sent/received without any errors and also the integrity of it, but not necessarily secure.

Off course if errors in terms of the connection will be appeared, TCP will alert about it to the HTTP layer so we can react appropriately as we wish in our application. This alerting is off course depended on the implementation of the relevant software.

All of it might sound simple and all, but I wanted to go from top to bottom in order to help understand what actually the OSI model does in action.

I do recommend to go to another post I’ve made in the past, which will truly help out to understand what we’re actually going to talk about.
You can read mostly the first parts, regarding networking.

The computer

Each and every computer(IPTV, laptops, smart phones/watches, etc..) has their own kernel.

From now I’m going to say a endpoint which refers to each entity that has a CPU and networking utility, like those we specified above.

The kernel is responsible to receive with the help of the hardware, all network traffic which is designated to the endpoint.
How does he do all of this? Simple! It uses the kernel built-in libraries which comes with it, and use them appropriately to each relevant task.

Each networking packet that comes inside, by the kernel goes each layer by layer, to understand how to parse the binary data from bottom to the top.
Each layer it goes, that layer whole logic functionality is being done on the packet.
Meaning, if a packet was arriving not in the same order accordingly to TCP, the packet can be dropped, it can also be put aside so we wait for the missing ones and more… accordingly to the kernel implementation of the TCP protocol.

So what we understand, each layer of protocols are stacked all together and are depended on one another(only from top to the bottom), so they give in a whole some kind of service for us as developers.

So what is TCP all about?!

TCP is the guy you can count on, to send your messages and be relaxed that he’s going to take care of it for us, while we chill out on the beach and drink Pina Colada or Burbon.

So how does he do all of this? TCP has many features which gives the ability for reliable data delivery and the main one is acknowledgements on messages.

The acknowledgement for the messages, are helping us to know that when we sent message X, we can receive an ACK, that tells us the message X was received on the other end.

This allows us to fully understand the flow of messages between 2 clients, because we can see the network traffic back and forth.
The way we can see the network traffic is by using a cool tool Wireshark.

Off course, when using TCP all this acknowledge base mechanism it comes with a cost.
The benefit off course is having reliable connection end to end, but the speed of the entire session is being downgraded.

TCP is quite cool because it actually gives us a fully connected and manged session from end to end.

Is there a way to send something fast? Yes but also there’s a cost for it 🙂

Hello my name is UDP

Basically the opposite from TCP.
UDP offers a way to send messages without being aware if they’ve arrived to the other endpoint, which means what you sent has been forgotten and we continue to the rest of the packets to send.

You might be asking yourself… why should I use UDP?

Well the simple short answer is speed. Because there’s no acknowledgements for each message, it allows for faster transmission of the data.

When to use each one?

Usually when using some kind of service, that needs to be reliable end to end, as the name reliable was included, it usually suggests we need to use TCP.

Short and great examples are file transfer(SFTP/FTP), web browsing(HTTP), mailing(SMTP) and more…
These services can’t allow that a file which is transferred on the internet using SFTP, to lose packets, because if it does a part of the file is missing and therefore the file would be broken.

Regarding UDP, we talked about speed which is greatly needed in real time communications. Real time is usually regards the use of sending video/audio on the internet.

Think for an example when seeing a video on some website, you wouldn’t really be aware of a missing bytes/frames when you have a continuous video or audio in front of you, therefore use cases of some sort can suffer from data loss, but achieving faster transmissions of data.

Before we will continue, I’ll you down on a little secret. Some cases we even use TCP for audio/video.
You might think that I’m messing with you but it’s actually true for cases of security and more special occasions.
I’m saying this, because these are types of networking I’ve met myself, and I want you to know that it’s possible to send audio/video over TCP as well.

But how actually those application protocols work?

If we have a socket which is based on TCP or UDP, we can send plain data on it which the other end simply receive and do what he wants with it.

When saying we have HTTP server, who listens to HTTP traffic, it’s simply a TCP socket who listens to port 80/8080 and parses the packets accordingly to HTTP RFC.
It doesn’t necessarily needs to listen to port 80/8080 if you wish to use other port for HTTP, it only need to parse the data like HTTP needs to.

Like the HTTP server, when saying we have a SFTP server, it simply receives data on a TCP socket and it parses the data as SFTP mentions in it’s RFC.

When we’re talking about UDP based protocols like RTP, it needs to do the same as the last 2 examples.

In conclusion

I hope we’ve made fine overview about network communications regarding TCP and UDP, and it is clear now if something wasn’t until this point.

If you wish to further your knowledge regarding network communications, I suggest to read more about OSI Model on Wikipedia or any other source, because from there you can reach a wide variety of very interesting subjects.

As always, I do hope you enjoyed reading this piece, and if you have any suggestion to improve this article so everyone else will enjoy it and have a better experience, I’ll be very glad to hear 🙂

Thank you again and have a great journey!