UDP vs TCP, how much faster is it?

Question

For general protocol message exchange, with loss tolerant. How much more efficient is UDP over TCP?

Answer 1

UDP is slightly quicker in my experience, but not by much. The choice shouldn't be made on performance but on the message content and compression techniques.

If it's a protocol with message exchange, I'd suggest that the very slight performance hit you take with TCP is more than worth it. You're given a connection between two end points that will give you everything you need. Don't try and manufacture your own reliable two-way protocol on top of UDP unless you're really, really confident in what you're undertaking.

Answer 2

Each TCP connection requires an initial handshake before data is transmitted. Also, the TCP header contains a lot of overhead intended for different signals and message delivery detection. For a message exchange, UDP will probably suffice if a small chance of failure is acceptable. If receipt must be verified, TCP is your best option.

Answer 3

UDP is really faster than TCP, and the simple reason is because it's non-existent acknowledge packet (ACK) that permits a continuous packet stream, instead of TCP that acknowledges each packet.

For more information I recommend the simple, but very comprehensible Skullbox explanation

Answer 4

Keep in mind that TCP usually keeps multiple messages on wire. If you want to implement this in UDP you'll have quite a lot of work if you want to do it reliably. Your solution is either going to be less reliable, less fast or an incredible amount of work. There are valid applications of UDP, but if you're asking this question yours probably is not.

Answer 5

@Andrew, I beg to differ. UDP is the choice in some kinds of application because of performance requirements. One classic example is video conferencing. This kind of application doesn't respond well to TCP control.

Other aspect to take in consideration is if you're going to need multicast. If so, use UDP.

Answer 6

with loss tolerant

Do you mean "with loss tolerance" ?

Basically, UDP is not "loss tolerant". You can send 100 packets to someone, and they might only get 95 of those packets, and some might be in the wrong order.

For things like video streaming, and multiplayer gaming, where it is better to miss a packet than to delay all the other packets behind it, this is the obvious choice

For most other things though, a missing or 'rearranged' packet is critical. You'd have to write some extra code to run on top of UDP to retry if things got missed, and enforce correct order. This would add a small bit of overhead in certain places.

Thankfully, some very very smart people have done this, and they called it TCP.

Think of it this way: If a packet goes missing, would you rather just get the next packet as quickly as possible and continue (use UDP), or do you actually need that missing data (use TCP). The overhead won't matter unless you're in a really edge-case scenario.

Answer 7

People say that the major thing TCP gives you is reliability. But that's not really true. The most important thing TCP gives you is congestion control: you can run 100 TCP connections across a DSL link all going at max speed, and all 100 connections will be productive, because they all "sense" the available bandwidth. Try that with 100 different UDP applications, all pushing packets as fast as they can go, and see how well things work out for you.

On a larger scale, this TCP behavior is what keeps the Internet from locking up into "congestion collapse".

Things that tend to push applications towards UDP:

• Group delivery semantics: it's possible to do reliable delivery to a group of people much more efficiently than TCP's point-to-point acknowledgement.

• Out-of-order delivery: in lots of applications, as long as you get all the data, you don't care what order it arrives in; you can reduce app-level latency by accepting an out-of-order block.

• Unfriendliness: on a LAN party, you may not care if your web browser functions nicely as long as you're blitting updates to the network as fast as you possibly can.

But even if you care about performance, you probably don't want to go with UDP:

• You're on the hook for reliability now, and a lot of the things you might do to implement reliability can end up being slower than what TCP already does.

• Now you're network-unfriendly, which can cause problems in shared environments.

• Most importantly, firewalls will block you.

You can potentially overcome some TCP performance and latency issues by "trunking" multiple TCP connections together; iSCSI does this to get around congestion control on local area networks, but you can also do it to create a low-latency "urgent" message channel (TCP's "URGENT" behavior is totally broken).

Answer 8

Actually, in some applications TCP is actually faster ( gives better throughput ) than UDP.

This is the case when doing lots of small writes relative to the MTU size. For example, I read an experiment in which a stream of 300 byte packets was being sent over Ethernet ( 1500 byte MTU ) and TCP was 50% faster than UDP.

The reason is because TCP will try and buffer the data and fill a full network segment thus making more efficient use of the available bandwidth.

UDP on the other hand puts the packet on the wire immediately thus congesting the network with lots of small packets.

You probably shouldn't use UDP unless you have a very specific reason for doing so. Especially since you can give TCP the same sort of latency as UDP by disabling the Nagle algorithm ( for example if you're transmitting real-time sensor data and you're not worried about congesting the network with lot's of small packets ).