You'll probably come across programmers who say this isn't even a question – use TCP because all the hard work is done for you. In many applications this is true and using TCP can make your life as a programmer very easy. However TCP has one very big drawback in embedded or low level applications – when a packet gets lost or a remote device doesn't respond you have to wait for the TCP stack to retry the communication several times, each after successively longer delays before it finally gives up. This is TCP's big advantage and drawback at the same time. With UDP there is no re-try – if a packet gets lost you need to notice that you've not had a reply and send it again. To the hardened high level programmer this is a task often not worthy of their genius, but to an embedded programmer or someone working at a low level this is something that can make UDP incredibly powerful and fast in time critical applications. Was it ever really a problem having to notice that a remote device hadn't responded when talking to it using RS232? Well its no different when talking using UDP and you can use the same simple approaches to defining your communications link. UDP also has one other great advantage – it allows you to broadcast packets so that every device on the local network or in the devices subnet receives them – you can't do that with TCP.

So the answer is, it depends on what you are doing. In terms of how the packets of data travel over the Ethernet links and internet there is no difference – both get routed in exactly the same way. TCP is fantastic at offloading work from you as a programmer for many applications, but UDP is the obvious choice in a great many other applications where you need that raw control of what you are sending and receiving.