Tcp – Difference between UDP and TCP

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.

But the problem is the ACK flag is only set on TCP acknowledgement packets, which do not carry any useful information as far as the end user is concerned, so if you only allow packets that have that flag set, you will drop all useful packets.

While ACK packets may not contain any useful data, the packets themselves are extremely useful. The ACK packet tells the other side of the connection "I received the data you sent and I'm ready for more." If the ACK is not received due to packet loss, a firewall blocking it, or any other reason, the connection sender of the ACK will keep resending that same ACK until the other side sends more data.

Now let's take a step back and discuss the Web server scenario you mentioned.

After the three way handshake completes the client will sends a request for a page. This would contain "useful" data because it tells the server what page the client wants. The server then sends an ACK to let the client know the request has been received. The server then sends back data packets which contain the requested page. The client then sends an ACK or ACKs to let the server know it has received all of the data which was sent.

Note that all of the above took place on a single TCP connection. In other words, both parties can send and receive data over the one connection, they do not need one each.

Finally, just an FYI, blocking traffic based on a TCP flag for security purposes is almost as weak as blocking on port numbers. The reason being that malicious users can craft packets any which way they like so sending all packets with the ACK bit set is no trouble at all. If you're interested in reading more about this take a look at Scapy.