25

TCP provides reliability at transport layer while UDP does not. So, UDP is fast. But, a protocol at application layer can implement reliable mechanism while using UDP.

In this sense, why isn't UDP with reliability (implemented on Application layer) a substitute of TCP in the case that UDP is faster than TCP while we need reliability?

  • 6
    Why would every application provides their own reliability mechanism when they can simply rely on another widely available protocol like TCP? – Nakrule Jun 27 at 6:12
  • 14
    and how do you propose to implement reliability at application layer without slowing down the stack? – JFL Jun 27 at 6:59
  • 6
    "Since UDP header is smaller than that of TCP, we can take advantage of data size." The problem with that thinking is that you will probably eat much of the UDP payload with application-layer protocol headers that will decrease the usable data in the UDP payload. The difference between TCP and UDP header size is only 12 bytes. Also, UDP is really designed for small payloads, e.g. 576 bytes; remember that UDP will simply lose datagrams, and the more data in a datagram, the more data is lost when a datagram is lost. – Ron Maupin Jun 27 at 11:16
  • 21
    Stack Overflow is rife with programmers trying, and failing, to create TCP-like protocols using UDP. The more-experienced programmers tell them to give it up and just use TCP. They all think they can do a better job, but it is highly unlikely. – Ron Maupin Jun 27 at 14:21
  • 11
    I know this isn't part of your question directly, but one reason UDP can be better is that you can implement only the reliability parts you need. With TCP you get reliability about ordering and delivery. This means TCP can have hiccups while it waits for a previous message to be resent. With UDP you could decide all you want is delivery, but if any message arrives out of order, you don't wait for the missing ones, you just discard them. The pitfall people run in to is trying to replicate TCP 100%. In that case, just use TCP. – William Mariager Jun 27 at 15:21
47

TCP is about as fast as you can make something with its reliability properties. If you only need, say, sequencing and error detection, UDP can be made to serve perfectly well. This is the basis for most real-time protocols such as voice, video streaming etc, where lag and jitter are more important than "absolute" error correction.

Fundamentally, TCP says its streams can be relied upon eventually. How fast that is depends on the various timers, speeds etc. The time taken to resolve errors can be unpredictable, but the basic operations are as fast as practicable when there are no errors. If a system knows something about the kinds of errors which are likely, it might be able to do something which isn't possible with TCP. For example, if single-bit errors are especially likely, you can use error-correcting coding for those bit errors: however, this is much better implemented in the link layer. As another example, if short bursts of whole-packet loss are common, you can address this with multiple transmission without waiting for loss, but obviously this is expensive in bandwidth. Or alternatively, slow the speed down until the error probability is negligible: also expensive in bandwidth. In the end, a protocol has to pay for reliability with either a) bandwidth or b) delay.

In implementation terms, you would find that the programmer-centuries invested in TCP will make it faster than anything general you could afford to make, as well as more reliable in the obscure edge cases.

TCP provides: a ubiquitious method of connecting (essential where the communicating systems have no common control) giving a reliable, ordered, (and deduplicated), two way, windowed, byte stream with congestion control over arbitrary-distance multi-hop networks.

If an application doesn't require ubiquity (your software runs on both sides), or doesn't need all of TCP's features, many people profitably use other protocols, often on top of UDP. Examples include TFTP (minimalistic, with really inefficient error handling, QUIC which is designed to reduce overheads (still marked as experimental), and libraries such as lidgren, which has fine-grained control over exactly which reliability features are required. [Thanks commenters.]

  • 7
    Custom "UDP with reliability" protocols are also extremely common in video games. There are a ton of networking libraries with various implementations. They usually want packets to be ordered and have error correction, without wanting retransmission of lost packets (and receive delays of all future packets). – BlueRaja - Danny Pflughoeft Jun 27 at 20:19
  • Sounds like you're saying "TCP is the optimal general solution, so it makes to support it natively". +1 – ikegami Jun 27 at 23:01
  • 1
    @BlueRaja-DannyPflughoeft And sometimes you want reliable unordered packets (e.g. visual effects applied to nearby players). – user253751 Jun 28 at 0:38
  • @BlueRaja-DannyPflughoeft if you have a typical example protocol library I'll be happy to incorporate into the answer – jonathanjo Jun 28 at 12:45
  • 1
    @jonathanjo One I've used is lidgren, which supports 5 different delivery methods (scroll to the bottom). Unity and Unreal Engine also have their own networking APIs that are built atop UDP. – BlueRaja - Danny Pflughoeft Jun 28 at 17:19
10

UDP with reliability can indeed be a substitute for TCP. We already have an example of it: it's called QUIC.

From Wikipedia:

Among other applications, QUIC improves performance of connection-oriented web applications that are currently using TCP. It does this by establishing a number of multiplexed connections between two endpoints over User Datagram Protocol (UDP).

The advantage of using UDP versus creating a brand new transport-layer protocol is that routers and other network devices already understand it.

  • QUIC has a bit different characteristic from TCP. In some scenarios (reliable network or no encryption needed) it actually is slower: quora.com/… – freakish Jun 28 at 10:42
  • You can also add WebRTC datachannels to the list which uses UDP via sctp. In fact, when UDP connections are not possible between peers WebRTC will fail over to TCP leaving a noticable drop in performance. – JSON Jun 30 at 9:42
  • @freakish slower is a generalization in this case. For example QUIC adds additional data to packets to reduce retransmission which effects throughput but not latency. – JSON Jun 30 at 9:50
4

You could use UDP to implement TCP functionality at the application layer (reliability, adaptability). You could just as well use TCP in the first place unless something your application really needs can't be done with TCP. If you implement those functions yourself you very likely end off much worse than with TCP. The added overhead decreases overall efficiency as well.

TCP isn't slow - it just requires a handshake before transmitting and the transmission window to adapt to the channel. It can very well shape its throughput to the transmission channel at hand and adapt to changes during the flow, all of which UDP can't do (by itself).

However, protocols above the transport layer are off-topic here.

  • 3
    "You could use UDP to implement TCP functionality at the application layer (reliability, adaptability)" -- I believe that's practically how QUIC, µTP, and often SCTP are already implemented. (Despite that, I usually consider them as being in the upper half of the transport layer, while UDP sits in the lower half.) – grawity Jun 27 at 15:43
  • 1
    @grawity That depends on your POV - from the application perspective, an intermediate layer is an extension of the transport layer. Formally and from the network (device) perspective, it's all part of the application layer. – Zac67 Jun 27 at 18:17
4

On a clean network they are pretty equivalent. There are cases where TCP will hang for periods (Anyone ever seen an HTTP screen freeze on load?) but it will not deliver garbage or mix up packets and rarely gives up completely.

UDP can give the application layer more control over the traffic at the cost of an awful lot of work.

The answer to your question is, sometimes it is done that way. Games that require low latency often do exactly that. It's a good deal more work, but the ability to control exactly how many outstanding packets you can have and how often they are retried is often worth it.

So overall the difference is that TCP is a very good general purpose implementation, but there are specific purposes that UDP can do that TCP either does very poorly or not at all--for instance:

  • NEVER giving up (with TCP the connection sometimes hangs and you have to break the connection and restart it)
  • Sending a fast stream of packets that don't require replies and you don't mind missing some occasionally (where only the most recent packet is important, any others can be discarded)--think game position updates--you might get a little "Jump" rather than each step, but you get the same result faster and more reliably.
  • Dealing with iffy networks by analyzing packet drops and dynamically altering how often and how soon you retry--maybe even max packet size.

But in general it's not worth it, TCP is pretty optimal so why go to all the extra work and add a (large) chance of adding bugs and security flaws?

3

UDP isn't fast because it is UDP. TCP isn't slow because it is TCP.

Both protocols are designed with certain guarantees and raw TCP has more guarantees than raw UDP.

And the rule of thumb is: the price for guarantees is performance.

There's nothing prohibiting you from implementing TCP guarantees over UDP. But then you get more guarantees and so you have to pay the price. Therefore you reduce the performance to TCP or worse (due to UDP overhead). Unless you know better TCP implementation, which is unlikely. And if you do then (hopefuly) you reveal it and we make the standard TCP faster. And we are back where we started. :)

You can play with those guarantees as well. Slightly modify this, slightly modify that. And then you end up with a protocol like QUIC which is over UDP and it is very similar to TCP+TLS. In many cases it is faster than TCP (although according to this article latency up to 5% and buffering up to 15% which IMO is not a big deal) but in some scenarios (e.g. reliable network or no need for encryption) it actually is slower (see an explanation here).

You can also weaken those guarantees and then it makes more sense. For example say you are streaming and so old packets are not interesting. Only the most recent. But congestion is still important. So you take some guarantees from TCP, but not all. And yes, people actually do that (e.g. real-time games). This gives you better performance at the cost of some guarantees.

1

Your idea would be good in deep space.

The correct answer is "it depends" and "because that would damage the network as a whole". TCP/IP is very kind to networks and automatically adjusts to about the right speed to be fast but not generate tonnes of ICMP return packets.

When a router with not enough RAM suddenly receives a lot of any kind of packet - say from Tsunami, Bittorrent or FDT - it drops it and fires back to the sender a small failure dis-acknowledgement packet. Now your UDP server has to track and re-transmit that part manually. Some ISP routers shape Bittorrent so many this hurts Tsunami?

The Tsunami protocol uses UDP with a control channel in TCP. http://tsunami-udp.sourceforge.net/ I found a study which shows it to be slower than a thing called FDT.

The legendary Fast Data Transfer (FDT) protocol from CERN is capable of saturating any network using multiple TCP streams. Probably it is faster, because it causes less re-transmits that Tsunami, which floods the network with so much UDP, some of it does not make it all the way across.

UDP is used by unreliable applications: streaming audio, game input/update IO, "ping" is actually ICMP but is not guaranteed, Bittorrent, mosh ssh is awesomely responsive, VOIP telephony, multicast, DNS is sent over UDP AFAIK. Anything that does not mind the odd missing packet and can "catchup" instantly.

TCP/IP was really the killer invention that allowed app devs so just set and forget. A socket is a pair of IP address and ports, and were designed to be able to be setup and remain for hours, days, even weeks without re-connecting. Email, web, IRC and literally all the killer apps use TCP. But you can get strange pauses in the download that suddenly go faster... and in deep space the connections may time out making Tsunami style transfers best for interstellar file transfers - you could be onto something there!!

The proof is in the final remarks of this science study extract, which mention the increasing distance thing I'm going on about re: deep space From: https://uscholar.univie.ac.at/get/o:300623.pdf

Without congestion, performance of FDT and GridFTP with TCP is higher than Tsunami and UDT. The highest through- put of FDT is 2.34 Gb/s with a 1 ms RTT but it decreases rapidly after 100 ms compared to GridFTP, which performs better than FDT when link RTT is longer than 100 ms. Interestingly, the throughput of Tsunami did not decrease over increasing RTT, showing it has the most effective congestion control with increasing RTT.

Then again... there is actually a space protocol that is a lot like email which would be better for space. The apps have to not mind time-out values such as forever.

0

TCP != UDP + Reliability

TCP is not simply UDP with added reliability. TCP offers more features than just reliability. You can read about them in many of the RFCs.

Any of these features "could" be implemented at the application layer. Eventually there becomes a point where you start reinventing the wheel.

To name a few features TCP has...

  • Connections creation and termination: performs handshakes and connection closures

  • Flow Control: ensures that sender and receiver transmit at rates where both can handle the data rate.

  • End to end congestion control: allows end nodes to throttle their throughput based on losses. Read about slow start, congestion avoidance, and fast recovery.

In my experience, UDP is used when speed is a concern over reliability. You can add some level of reliability at the application level that is not 100% as reliable as TCP. For example if you still want fast performance, you can implement forward error correction (FEC) where you transmit the data more than once. You still get good performance and some level of reliability (note quite TCP reliability) without all of the back and forth chit chat to get lost packets. The trade of is that it increases the network utilization but may be suitable for real time applications like gaming or streaming.

  • You could describe at those extra features as being about reliability, ultimately. – user207421 Jun 29 at 23:46

protected by Ron Maupin Jun 28 at 14:43

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.