Here's a quote by Sam Jansen from a comment on gafferongames.com:
Speaking as a network researcher and not a game developer, the conclusion to never use TCP and UDP together seems a bit strong. TCP will only have packet loss if it is sending too much data; in some ways just like the UDP data you are sending. The difference is you have no direct control on the rate TCP sends at, this is hidden to you.
If you just need to send some reliable data and do not want to worry about retransmission and implementing a reliable protocol, and you know the rate will be low, then there wont be any problems with using both TCP and UDP.
The relationship isn’t all that complex between the two really: TCP merely increases its send rate (if there is data to send) until it gets packet loss, in which case it dials back its rate, then starts increasing the rate again (this time more slowly). When its increase in rate causes packet loss, it is quite likely to hit any other streams of data as well, including your UDP packets.
The paper Characteristics of UDP Packet Loss: Effect of TCP Traffic got its results by opening multiple TCP connections at once and flooding the network with data. This leads to the congestion followed by global synchronization, both of which cause dropped packets. Obviously, a game client will not open a dozen connections at once and flood the network with data, and so your results will be different.
To answer your question:
I'm wondering if it makes sense to use both TCP and UDP at the same time, but for different things [...]
Yes, this is an acceptable thing to do assuming you stay within your bandwidth limits.
- TCP for sending information that is sent infrequently, but should be guaranteed to arrive reliably.
Such as score updates, a player's name, or even the on/off state of a light in the game world.
When using both TCP and UDP, you should always prefer to send as much as possible over UDP and as little as possible over TCP.
Now, I ask you this: Is it really necessary to send the score, the player's name, and the state of a light over TCP? While it is true that you need to receive this data eventually, is it true that you need to receive this data strictly-in-order and exactly once?
UDP works fine for these cases, and Quake 3 is a good example of how.
So what's a good example of TCP alongside UDP then? Well, think of a game's chatbox. The updates to this chatbox (that is, the new lines of text) need to be sent both reliably and strictly-in-order. Thus, TCP is a good fit.