Ttdfjt

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.]

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.

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.

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?

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.

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.

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.