want to use UDP
want to send big buffers of data
- need shortest possible latency and cannot ever (that is, rarely) afford to wait for a resend
- do not care too much if some bit of data is lost (i.e. you can simply and quickly ignore lost datagrams)
- do this purely out of academic interest or for the fun of hacking together your own protocol
you are probably doing it wrong by using UDP.
UDP is not any better or faster than TCP, but it is much more complicated to get right since it has no congestion control, does not enforce order and has no reliability layer. In particular, sending large amounts of data is non-trivial to get right.
Using TCP, you can throw kilobytes or megabytes of data at the socket (usually with a single API call -- on my Debian box, send will happily accept hundreds of megabytes in one chunk) and you are guaranteed that it will arrive on the other end. And no, sending a megabyte of data via TCP will not be any slower than sending it via UDP.
The notable difference between UDP and TCP is that TCP will resend packets that are lost and provide the data on the other end in the correct order with no "holes". That means that in presence of packet loss, TCP may sometimes have slightly more latency because it may have to wait for a resent packet. Other than that, they perform exactly identical.
Except of course, TCP's flow control will dynamically adapt to path MTU and router capacity whereas UDP will simply throw your datagrams away when you exceed some obscure limit such as filling a router's forward queue.
For urgent realtime applications where you can just use the next tiny datagram that arrives instead of the lost one (say, for position updates in a fast-paced game that come in 10-20 times per second), UDP is a big win. However, for bulk data, you should really, really, really use TCP.