I'll try to answer your question directly without going into a huge rant about TCP v UDP.
Basically you need to understand that both HTTP and DNS are completely independent applications/protocols. Sometimes you need to actually send a DNS query to a DNS server, sometimes you don't (if the DNS record is cached locally on your PC/Server).
We do NOT have a DNS record cached.
- http://google.com is entered in the browser.
- Your PC checks the local DNS cache, and sees it does NOT have a record for google.com
- A UDP DNS query is sent to a DNS server, in this case it's most likely your ISP's DNS server.
- The DNS server sends a UDP response back.
- You now have your answer in the form of an IP address, now you can initiate your TCP connection to google.com
- The 3-way handshake occurs between you and google.com (SYN, SYN/ACK, ACK) - if you do not know what this is you can search for "TCP 3 way handshake" and find some good information.
- After the handshake completes, HTTP will render in the form of your favorite search engine.
We HAVE a DNS record cached. There is a very small difference here, but I'm going to include the whole thing so you can see the comparison.
- http://google.com is entered in the browser.
- Your PC checks the local DNS cache, and sees it has a record cached in the form of an IP address.
- You now have your IP address for google.com, now you can initiate your TCP connection to google.com
- The 3-way handshake occurs between you and google.com (SYN, SYN/ACK, ACK)
- After the handshake completes, HTTP will render in the form of your favorite search engine.
So just because you're trying to get to a webpage you do not have to send a UDP DNS query. DNS is independent, visiting a webpage is not the only time you'd need to use DNS. Feel free to comment if you need clarification.
You asked a good question. Don't let anyone tell you otherwise.
Regrettably, there is no rule of thumb for the types of protocols that use TCP verses the types of protocols that use UDP.
The decision whether a protocol uses one or the other come down to whomever wrote/created the protocol to begin with.
If they didn't want to bother with writing their own "reliable delivery" system, then they can simply use TCP which provides all the reliability innately.
If they thought (knowing their own protocol innately) that they could write a better or more appropriate "reliable delivery" system, then they can build that into the protocol itself and simply use UDP as their transport.
As an example, take a look at a UDP TFTP sample capture, you'll notice there are built in acknowledgement systems within TFTP itself -- having both those and the additional acknowledgement systems within TCP would simply be redundant.
Whereas FTP, which runs over TCP, does not have a built-in acknowlegdment system. A user simply request a file, and the sender sends it. There is a "file transfer complete" notification, but nothing that guarantees having received each bit of the file. FTP is relying on TCP's reliability to ensure the file gets all the way across.
That said, I looked through the list of ports on the wiki page you linked, and saw a surprising amount of protocols that supposedly use TCP and UDP. This was foreign to me, and I only know of very few that use both (namely, DNS). But it may be that there is a TFTP implementation that uses TCP, and if so, I'm afraid I have no exposure to it.
Domain Name System (DNS) is traditionally the protocol referred to when discussing protocols that use both TCP and UDP. It doesn't use these at the same time, mind you. But different functions within DNS might call for TCP vs UDP.
For example, when making a simple A-record resolution request, the "request" and "response" are very lightweight, both requiring a single packet. As such, this is typically done over UDP.
But if a request or response requires a larger transfer (above a certain amount of bytes), then DNS chooses to use TCP to ensure "all the bits" get there. This is common with full Zone Transfer requests.
Best Answer
There are registered, well-known port numbers for services and transport protocols that use port numbers as transport addresses.
HTTP, by default, uses TCP at the registered, well-known port number 80, and HTTPS, by default, uses TCP at the registered, well-known port number 443. The browser defaults to the default transport protocol and registered, well-known port number for the browser protocol in use. If the server is listening at a different port number, this can be overridden in the URI by appending
:<port number>
to the FQDN. For example,http://www.example.com:12345
.The protocol is at the beginning of the URI, e.g.
http://
,https://
,ftp://
, etc.The browser will connect (or not if the server is not listening at what the browser tries) based on the URI.
The registered port numbers are maintained by IANA in the Service Name and Transport Protocol Port Number Registry.