19 replies to this topic

[Mr.L]

I've sometimes wondered how much faster than TCP is UDP, and go about what percentage it lost.

[Madhed]

You can't really compare them like that.
UDP is a very very basic protocol that enforces nothing but intact packets. TCP in comparison is a beast of a protocol. It implements a lot of integrity rules that you may not need for the situation at hand.

Use UDP if you need low latency, TCP if you need steady throughput.

[Olof Hedman]

Also remember there is no guarantee a UDP packet arrives at the other end at all, or in any specific order.
TCP will automatically resend packages if needed, and make sure they are delivered in order to the application

So you must make sure the protocol you implement on top of it has no problem with lost packages and doesn't care about package order.

[frob]

When you have a good connection through the Internet their performance will be essentially equal; packets will arrive in order and on time, and both protocols have minimal overhead.

That describes almost all the time on the Internet. It is mostly very stable. In the general case of uncongested lines and stable hardware there will be no significant difference in performance.



The rare problems come when there is congestion, routing changes, or hardware failures along the line (which are not very often). In that case you need to handle the situation correctly; TCP handles all that for you in a very robust way. UDP assumes you know what you are doing and will handle it correctly by yourself. Can you handle it yourself, with performance better than TCP? That is a harder question.

[Olof Hedman]

That describes almost all the time on the Internet. It is mostly very stable.

Really?
Granted I don't have a lot of networking experience, and most of it a 7-8 years ago, my experience is the opposite.
Specially if you mix some wireless into it, which is pretty much the normal case nowadays.

One of the "bottlenecks" of TCP is the window size, it will only send a certain amount of packages before making sure the first one has arrived.
This will limit the speed when you have high latency.
Also, it eats some of the bandwidth in the "other direction", sending ACK packages, this could be nice to avoid if you have to handle a lot of traffic.

UDP is great if your protocol has no need of packages being in perfect order or lost, if you do need that, TCP is the better choice.

[frob]

That describes almost all the time on the Internet. It is mostly very stable.

Really?
Granted I don't have a lot of networking experience, and most of it a 7-8 years ago, my experience is the opposite.
Specially if you mix some wireless into it, which is pretty much the normal case nowadays.

Congestion and saturation are the major causes of lost packets. If you saturate your line you are more likely to lose packets. If you are flooding your line it doesn't matter if you are on wired or wireless connections, once it gets saturated it won't take any more.

One of the "bottlenecks" of TCP is the window size, it will only send a certain amount of packages before making sure the first one has arrived.
This will limit the speed when you have high latency.

Window sizes are negotiated at protocol start and are dynamically resized up to 1GB windows; that is part of the protocol. In practice this is rarely an issue.

Also, it eats some of the bandwidth in the "other direction", sending ACK packages, this could be nice to avoid if you have to handle a lot of traffic.

Traffic needs are asymmetric, and ack commands are very small. If you implement your own control system with UDP you will still need to implement something similar.

UDP is great if your protocol has no need of packages being in perfect order or lost, if you do need that, TCP is the better choice.

Some people have other needs. Many networking packages for games implement their own TCP-style layer on top of UDP where they can mix reliable information (such as game state) with unreliable information (such as delta-updates). If you have the means to do such a thing you can get slightly better performance than raw TCP in the general case along with all its benefits.

That type of solution is generally outside the reach of most beginners.

[hplus0603]

I've sometimes wondered how much faster than TCP is UDP, and go about what percentage it lost.

If there is no packet loss, then TCP and UDP are exactly the same speed.
If there is packet loss, then UDP gives you nothing (so, infinitely slow) whereas TCP will delay and retry until the data gets through (so, slower than immediate.)
You use UDP when you'd rather have no data than slow data. You use TCP when you'd rather have all the data, in order.

[Mr.L]

so you mean for a little network game I could also easily accept TCP?

[zoneweb]

If there is no packet loss, then TCP and UDP are exactly the same speed.

Even if there's no packet loss, TCP requires the receiver to send acknowledgements of received data.

[hplus0603]

If there is no packet loss, then TCP and UDP are exactly the same speed.

Even if there's no packet loss, TCP requires the receiver to send acknowledgements of received data.

That does not affect the speed of data transfer. In the distance past, long-distance transfers would slow down because of window exhaustion, but with window scaling that hasn't been a problem for a long time.

[Net Gnome]

TCP is always slower than UDP because TCP has more overhead (ACK/NACK, etc.) in that it requires all packets to reach destination -in order-. UDP is basically fire-n-forget, while TCP is best-attempt. This is why real-time media uses UDP where not all of the packets have to be recieved to continue whereas TCP requires all data to reach its destination and is used when packet-x must reach the destination before packet-y to continue. With UDP you can accept the loss or implement an ACK/NACK stack of your own (usually you can get more efficient than TCP, since its AIMD - Additive incline, multiplicative decline).

[BeerNutts]

so you mean for a little network game I could also easily accept TCP?

Unless you really know what you are doing, I would suggest using TCP/IP for your little networked game to guarantee all your data arrives in the right order.

[DvDmanDT]

Also remember that there are plenty of libraries out there, such as the Lidgren Networking Library if you are using C# or some other .NET language. Such libraries are often much easier to use and tends to implement reliable UDP. I preferr reliable UDP to TCP mostly due to the concept of packages instead of streams. If you use such a library, you can also get some nice features such as data channels which may reduce slowdown caused by packetloss since not all data needs to wait for a single package etc.

[hplus0603]

TCP is always slower than UDP because TCP has more overhead (ACK/NACK, etc.)

The point I made was that this statement, while often made, is simply not true most of the time. It is certainly not true if there is no packet loss.

No packet loss by implication means that the amount you need to send is less than the maximum capacity of the channel (this is necessary but not sufficient to make no packet loss,) which in turn is a necessary condition for any networked real-time game.


The size difference between TCP and UDP headers also often get swallowed in the packetizing of the underlying protocol (ATM or similar.)
You also erroneously state that TCP contains NACK packets. There are no NACKs in TCP.

[DvDmanDT]

One thing you should note if using TCP is the NAGLE algorithm or whatever it's called. It's an algorithm that tries to increase throughput by decreasing protocol overhead, which it does by sending as much as possible in every package. In other words, it holds of sending your data until it has X or more bytes to send, or until Y ms has passed. This makes it more efficient when sending larger amounts of data such as maps/saves etc, but can increase latency while sending small amounts of data such as player positions.

You can easily disable this algorithm though, just google TCP_NODELAY.

[Net Gnome]

TCP is always slower than UDP because TCP has more overhead (ACK/NACK, etc.)

The point I made was that this statement, while often made, is simply not true most of the time. It is certainly not true if there is no packet loss.

No packet loss by implication means that the amount you need to send is less than the maximum capacity of the channel (this is necessary but not sufficient to make no packet loss,) which in turn is a necessary condition for any networked real-time game.


The size difference between TCP and UDP headers also often get swallowed in the packetizing of the underlying protocol (ATM or similar.)
You also erroneously state that TCP contains NACK packets. There are no NACKs in TCP.

RFC (3.7. Data Communication). my apologizes, they're not NACKs, but packets classified UNA. But no network is ever pristine, and should never be designed around those considerations. The reason UDP is faster, is that it doesn't care about this type of information at all, i.e., it just uses IP as the protocol, and thus has almost no overhead (RFC) since there are no acknowledgements, window syncs, etc., i.e., nothing to cause a hold-up.

Anyway, I'm not saying UDP is better than TCP (it isnt), its just not correct to say TCP is as-fast as UDP, since UDP will always put more data packets downstream faster than TCP, it just wont do anything more than that.

[samoth]

Anyway, I'm not saying UDP is better than TCP (it isnt), its just not correct to say TCP is as-fast as UDP, since UDP will always put more data packets downstream faster than TCP, it just wont do anything more than that.

While this is technically correct, it is mostly irrelevant, as hplus0603 pointed out. Many underlying "wire" protocols will hide this fact.

For example, ATM always transmits 53 byte cells (of which 48 bytes are payload). Whether you have 1, 5, 20, 40, or 48 bytes to send is exactly the same. Ethernet has a minimum payload of 48 bytes, and a mimimum interframe gap of 96 bits, whether you send zero or 48 bytes is exactly the same. The next frame cannot possibly be sent any earlier than a given minimum time (in case no one else uses the wire at that time, in which case your card will back off). Therefore, it does not really matter whether the header is a little bigger or not. Besides, TCP/IPv6 has header compression defined, in a similar manner to how PPP did it two decades earlier. I'm not aware that UDP/IPv6 does a similar thing. Header compression is a quite substantial saving -- so following your logic, TCP might actually be faster.

Being able to submit packets faster doesn't matter either, on many underlying wire protocols (take FDDI or TokenRing as examples). If you don't have a token, you're going to wait, end of story. It doesn't matter how fast you can send, you won't.

The necessity of ACK also means, technically, that TCP must be slower. In practice, ACKs often go piggyback or several are collapsed into one. So you end up having a few extra packets during a longer transmission, which really makes no difference. There are some odd packets on the wire all the time, from people scanning random ports on random IP addresses to ARP requests and other "secret stuff" that happens without you knowing or having to worry. They normally don't impact performance in any way. If you run Wireshark on your computer, you'll be surprised how many packets are sent and received when "nothing" happens.
Also, if you want to transmit a larger contiguous amount of data with UDP, you will need to acknowledge in some way, too. I can't seem to figure how you would do otherwise.

The only reason why I would agree on "TCP is slower" other than by irrelevant sophistries is the fact that data is guaranteed to arrive as an in-order stream. This may require your network stack to wait on data in some conditions. However, as pointed out by others earlier, these conditions are rare.
And, if they do occur, TCP is not necessarily any better either. It may in fact be worse. When a router is with its back to the wall, it will simply drop any packets that come in, until it can handle more. That means, it will drop TCP's packets just the same as it will drop UDP's packets.
With one notable difference... due to UDP being used for "live, hard realtime" stuff like telephony or video, many routers are configured to drop TCP first.

[Mr.L]

okay so i keep using TCP.
Thanks

[turch]

If you run Wireshark on your computer, you'll be surprised how many packets are sent and received when "nothing" happens.

Recently did that on a company LAN with ~100 salespeoples' computers, many of which have dropbox installed. Holy crap

[hplus0603]

its just not correct to say TCP is as-fast as UDP

But nobody has said that. What we've said is that, absent packet loss, TCP and UDP are the same speed.
The "overhead" you talk about doesn't matter, for two reasons I already mentioned:
1) for a game to work at all, you must be sending less data than the max capacity of the channel, and therefore the overhead disappears in the noise
2) because of the way networks are actually physically implemented, packet sizes are usually quantized in such a way that the same data through TCP and UDP will actually use the same amount of physical network bandwidth

The behavior under packet loss is different between the two protocols, which is to be expected. However, the question was about "speed," not "behavior under loss."