TCP <- Terminal Control Protocol. It's made to control transmission.

TCP was created to be a good and diplomatic network citizen. It focuses on making the networking a good experience for everyone, and willingly decreases it's throughput to achieve that. It adjusts to the environment by adding latency. Reasons are for example:

• Receiver detects a missing packet, tells the sender to slow down (halve the rate for a while).
• Receiver detects wrong incoming packet order (maybe they took different network paths), tells the sender to slow down - and btw, the receiver won't accept further packets until the missing one comes in. Dealing with this takes time.
• Sender detects network congestion (eg. slow roundtrip time), adds latency.
• Receiver cannot keep up with the speed (input buffer is getting too full), asks sender to add latency (flow control).
• There is a single slow receiver (high ping bastard, crybaby, what are they called) among receivers, latency (may be) added in the household.

Additionally

• Nagle's algorithm may keep the senders data on hold, until there s more to send (in order to utilise data frames more efficiently). Time critical data gets delayed.
• I believe ordinary home-routers with wlan may do smart things (slow down) to smooth the TCP throughput between multiple clients (the wlan interface being the bottleneck, even if the game doesn't use it). Relates to broadcasting/multicasting, ie. "other" data may decrease your TCP throughput.
• TCP ACKnowledges everything, which is not necessary for a gaming environment. There is no point in ACKing every single physics update. Enough to ackknowledge for example once per second, or similarly. If a client (or a server) is silent for a longer time, then it's time to react.

Despite these, TCP provides the highest figure for (overall transmitted data) / (overall consumed time). Just that it doesn't happen precisely when you want it to happen.

UDP does none of these. It fires upon your will, just that one cannot expect it to hit each time - insead the target must announce that "you haven't shot in a long time, why?". One can still create own custom ACK packets, put multiple records in a single packet, etc. And also important, control NAT traversal. UDP is most certainly suitable for games with low latency demand.

TCP <- Transmission Control Protocol. It's made to control transmission.

TCP was created to be a good and diplomatic network citizen. It focuses on making the networking a good experience for everyone, and willingly decreases it's throughput to achieve that. It adjusts to the environment by adding latency. Reasons are for example:

• Receiver detects a missing packet, tells the sender to slow down (halve the rate for a while).
• Receiver detects wrong incoming packet order (maybe they took different network paths), tells the sender to slow down - and btw, the receiver won't accept further packets until the missing one comes in. Dealing with this takes time.
• Sender detects network congestion (eg. slow roundtrip time), adds latency.
• Receiver cannot keep up with the speed (input buffer is getting too full), asks sender to add latency (flow control).
• There is a single slow receiver (high ping bastard, crybaby, what are they called) among receivers, latency (may be) added in the household.

Additionally

• Nagle's algorithm may keep the senders data on hold, until there s more to send (in order to utilise data frames more efficiently). Time critical data gets delayed.
• I believe ordinary home-routers with wlan may do smart things (slow down) to smooth the TCP throughput between multiple clients (the wlan interface being the bottleneck, even if the game doesn't use it). Relates to broadcasting/multicasting, ie. "other" data may decrease your TCP throughput.
• TCP ACKnowledges everything, which is not necessary for a gaming environment. There is no point in ACKing every single physics update. Enough to ackknowledge for example once per second, or similarly. If a client (or a server) is silent for a longer time, then it's time to react.

Despite these, TCP provides the highest figure for (overall transmitted data) / (overall consumed time). Just that it doesn't happen precisely when you want it to happen.

UDP does none of these. It fires upon your will, just that one cannot expect it to hit each time - insead the target must announce that "you haven't shot in a long time, why?". One can still create own custom ACK packets, put multiple records in a single packet, etc. And also important, control NAT traversal. UDP is most certainly suitable for games with low latency demand.