Why would you ever use TCP instead of UDP if you implement your own error checking?

Question

I've read a lot of stuff online about why you would use UDP or TCP, but I still need help understanding something.

If I implement error checking and re-transmission in my application why would I ever even consider using TCP? Is it just more convenient for developers to utilize the built in features of TCP instead of implementing them themselves at the application layer? I know TCP includes flow control which makes it friendlier to other services on the network, but, if I'm a selfish bastard who could give a damn about everybody else and want my app to be as fast as possible wouldn't I choose UDP in every case?

Is it a considerable undertaking to re-implement the features of TCP in your application? I just need help understanding why, if UDP is so much faster, every application doesn't use UDP in every case.

Answer 1

TCP offers more than just error checking so there's a lot to implement if you want to replace it. Here are some things that come to mind in no particular order:

1. Standardization

You've written your own transport protocol. Congrats! Have fun using it with yourself since yours is the only implementation. TCP on the other hand, exists and is well tested on any platform. It is supported by firewalls, proxies, routers, and everything else your traffic might run into in a network.

2. Congestion Control

This is what you thought of when you said "Flow Control" (see next bullet). Congestion control throttles the TCP stream in response to network congestion. But you're a selfish bastard (and that's fine!) so you're asking why should you care. Well, the bottleneck of most of your network usage is the link between you and your provider. Your provider is usually well provisioned and has network engineers at his disposal. These guys know how to protect the network from over-usage and how to avoid hotspots. So TCP's congestion control really protects you and your applications most of all, making sure that a single application can't choke the whole connection. It helps to make sure that you don't do anything foolish like send 1Gbps worth of traffic over your 50Mbps connection just because the link from your PC to the router can support 1Gbps.

3. Flow Control

Flow control is NOT congestion control. In a nutshell, flow control is telling the other side to shut up when you're no longer able to process the incoming information. Think about a mobile phone trying to load a heavy web page from a nearby HTTP server. The server can dump the entire page on the network in a fraction of the time it takes the phone to process it. In such cases the bottleneck is not the network but one of the devices. Your TCP alternative would have to solve this issue too.

4. In-order delivery

In addition to error detection, TCP guarantees that the data will arrive in the correct order. This is not the same as error detection, it's an additional feature.

5. Security

The TCP three way handshake and the way in which modern operating systems generate initial sequence numbers practically guarantees to both parties that the IP address of the other host is real and not spoofed. This wasn't always the case. Back when initial sequence numbers were easy to predict, these attacks existed.

Additionally, implementing all of TCP's features is hard, and complexity breeds bugs. Many TCP implementations have been known to contain various bugs such as buffer overflows some of which had severe security implications. Hopefully, there were all found and fixed by now. New protocols and new implementations always run the risk of introducing new security vulnerabilities.

6. Performance

Network cards and modern operating systems take the load of managing TCP off your application, and they do it WELL by now. You want to use your own sequence numbers and error detection? You'll have to implement them yourself in user space (and suffer the performance penalties, especially if your application is written in something like Java) or be prepared to write kernel and driver patches.

Additionally, the existing TCP implementations themselves have reviewed and optimized by entire generations of engineers by now. It would be very challenging to create something as polished by yourself.

Answer 2

You can build your own TCP lookalike out of UDP. Google is doing that with QUIC. They are trying to fix TCP deficiencies in an internet-compatible way which pretty much only leaves UDP as the underlying transport.

The main innovations of QUIC are:

• Multiple streams. Packet loss only delays a single stream. The others continue.
• Forward error correction in order to not stall at all in case of packet loss.

As you can see it is totally feasible and valid to replace TCP.

It's very likely not to be worth it. QUIC does it not for throughput but for latency. The intended use case surely is web browsing. UDP certainly is not "much faster". Why would it be? Both TCP and UDP can operate at line speed minus some rather small overhead.

A popular hybrid scheme is to send data over UDP first. If retry is needed resend over TCP.

Answer 3

I just need help understanding why, if UDP is so much faster, every application doesn't use UDP in every case.

UDP is not faster by itself. It can even be slower:

• UDP is datagram based, that is each send makes a new packet with all the associated overhead. TCP instead is stream based and tries to create packets with the best size (MTU) by merging multiple send together. Thus it achieves less overhead by auto-tuning, whereas with UDP you need an explicit tuning to achieve the same performance.
• On packet loss TCP backs off with the sending speed, so that it will not loose much more packets. With UDP you either have to be below the maximum connection of the line to be safe or you have to expect lots of packet loss. Of course you could implement a similar method to TCP or you could implement an even better method which is not general purpose but fits better in your use case.
• UDP can be faster for short connections because you don't have the initial handshake. But you still have to take care of packet loss, see SIP (RFC3261) for an example on how one can deal with this.
• UDP is often used for real-time streaming of audio/video. But this is not because it is faster, but because it is much more important to have a low latency and the codecs used can deal with packet loss. Retransmission of data as done with TCP is useless in this case.
• TCP instead is used for transferring large amount of data in a reliable way, like done in FTP and HTTP.

Answer 4

Another reason for choosing TCP anyway might be:

When you need to communicate over a NAT router you don't have to send that many IP packets when using TCP. The reason for this is, that on any protocol the NAT router will drop the association between the internal and external network address after some time (it might be that both ends just have died). But using TCP timeouts for on a typical NAT router are in the tens of minutes while the timeout for the same on UDP is in the tens of seconds.

This is especially important on mobile devices which get their battery drained for every packet that is sent. Because of this many mobile phones prefere using the SIP protocol over a TCP connection instead of using UDP.