I can transfer the data from my application(assume java application) through either of three protocols i.e. http/TCP/UDP

HTTP example for java client is

TCP example for java client is

UDP example for java client is

I understand HTTP works at application while TCP and UDP works at transport layer.

My understanding :-

HTTP In HTTP client, high level which abstracts the socket layer . It can also with DNS instead of ip address. It has its own rules like GET/POST request. headers, etc. API will structure the data for me per HTTP rules. HTTP will also manage the required encoding(part of presentation layer) and manage the session(like when connection needs to be closed)

TCP In TCP client, api is dealing directly with socket layer . It needs to deal ip address. It does not have specific rules like HTTP above. It just collects the data from application and send it across in chunks reliably in ordered fashion

UDP In UDP client is like TCP only but with less reliability and better speed.

Is my understanding correct ?

closed as unclear what you're asking by DavidPostill Mar 6 at 9:33

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • And where/what is a question? – Akina Mar 6 at 6:30

Familiarize yourself with the OSI model. Read the Wikipedia thoroughly, it will probably answer the questions you'll have after reading this answer.

HTTP and TCP aren't alternatives. These protocols work in two different layers. HTTP needs some transport layer protocol. HTTP only defines common "language" for client and server, but not how to send data - that's not a job for application layer. It assumes existence of a reliable transport layer protocol. HTTP is almost always transported over TCP.

HTTP usually uses IP. Again, HTTP as an application layer protocol only defines common language. It doesn't, however, define how client and server are identified and how client specifies which server it wants to talk to. That's a job for IP which is used for addressing clients.

DNS isn't an alternative to IP. DNS doesn't even make much sense without IP. Well, technically it could work just as well with other addressing protocols, but that's what everyone uses nowadays. DNS is an Internet phone book. My IP address is currently and you probably can't remember that. What's more, it will change in 5 minutes, because I'm leaving home and I'll be using mobile connection instead of my Wi-Fi. DNS is a service with a known, unchanging IP address that translates domain names (such as superuser.com) to IP addresses.

So when you type superuser.com:

  • Your browser resolves superuser.com to an IP address
  • It opens a TCP connection with that IP address
  • It sends a HTTP request over that connection

UDP In UDP client is like TCP only but with less reliability and better speed.

More or less. Larger messages are fragmented into bite-sized packets by UDP and TCP. TCP guarantees that all packets arrive and are in correct order, otherwise nothing is received. This can take some time and a few retries. UDP doesn't care.


OSI Model should help you to get an idea of where you're at. HTTP is a whole different thing in comparison to UDP/TCP. It does use TCP on the lower levels.

As for TCP and UDP you're correct that ones is that it's connection oriented at the other is not. UDP is a best effort fire and forget while TCP tries to make sure that stuff arrives in the way you expected it to and reliably.

In the end the choice should depend on what you actually need and what you feel fine tackling yourself. Just want to send a single bit? Might be a bit heavy to use HTTP. Want to transfer your highly confidential valuable data? You probably don't want to use UDP. Want to do VOIP? You likely want to use UDP.

Not the answer you're looking for? Browse other questions tagged or ask your own question.