Indeed, nearly all FPS/MMO/RTS games are realtime and need UDP, only some messages need to be reliable/ACK'd or ordered and TCP is overkill except for turn based games.
Real-time games have to be UDP or more typically a variation of Reliable UDP (RUDP) [1]. Many networking kits are based on reliable UDP and common early implementations as the core/base of their network layers such as enet [2] or RakNet [3] (Unity, Unreal, Sony, Oculus and more). RUDP or variants are UDP with channels, ordering, priority as well as ACKs where needed for reliable/must deliver messages through the use of a return UDP ACK datagram for verification. Reliable UDP is a set of service enhancement such as congestion control, retransmission, thinning server algorithms that allow a Real-time Transport Protocol (RTP) for media broadcasts even in the presence of packet loss and network congestion.
Reliable UDP ACKS are used commonly in areas like global events such as game start, game end, player entered, player died, player hit etc, all other positioning/action is UDP broadcast with dropped packets lerped [5] and slerped [6] out with interpolation [7] and extrapolation to deal with lag compensation [8] and client prediction [9][10][11]. Sometimes this also involves channels and grid/graph areas where only messages to players around you or in that area are required to ACK when needed i.e. player hit/death.
Most large real-time games are just UDP broadcast for 99% of action. TCP is almost never used in real-time action games like FPS, MMO, RTS etc.
Rarely are TCP and UDP combined, rather RUDP or later something like SCTP, allows streaming/real-time capable broadcasts with enough verification/reliable messages where needed. Combining TCP and UDP can end up with queuing issues that affect both TCP and UDP traffic [4] so most games just go with reliable variant of UDP.
Gaffer on Games has a good section on why UDP is used in games [12]
> The web is built on top of TCP, which is a reliable-ordered protocol.
> To deliver data reliably and in order under packet loss, it is necessary for TCP to hold more recent data in a queue while waiting for dropped packets to be resent. Otherwise, data would be delivered out of order.
> This is called head of line blocking and it creates a frustrating and almost comedically tragic problem for game developers. The most recent data they want is delayed while waiting for old data to be resent, but by the time the resent data arrives, it’s too old to be used.
> Unfortunately, there is no way to fix this behavior under TCP. All data must be received reliably and in order. Therefore, the standard solution in the game industry for the past 20 years has been to send game data over UDP instead.
> How this works in practice is that each game develops their own custom protocol on top of UDP, implementing basic reliability as required, while sending the majority of data as unreliable-unordered. This ensures that time series data arrives as quickly as possible without waiting for dropped packets to be resent.
> So, what does this have to do with web games? The main problem for web games today is that game developers have no way to follow this industry best practice in the browser. Instead, web games send their game data over TCP, causing hitches and non-responsiveness due to head of line blocking.
> This is completely unnecessary and could be fixed overnight if web games had some way to send and receive UDP packets.
Real-time games have to be UDP or more typically a variation of Reliable UDP (RUDP) [1]. Many networking kits are based on reliable UDP and common early implementations as the core/base of their network layers such as enet [2] or RakNet [3] (Unity, Unreal, Sony, Oculus and more). RUDP or variants are UDP with channels, ordering, priority as well as ACKs where needed for reliable/must deliver messages through the use of a return UDP ACK datagram for verification. Reliable UDP is a set of service enhancement such as congestion control, retransmission, thinning server algorithms that allow a Real-time Transport Protocol (RTP) for media broadcasts even in the presence of packet loss and network congestion.
Reliable UDP ACKS are used commonly in areas like global events such as game start, game end, player entered, player died, player hit etc, all other positioning/action is UDP broadcast with dropped packets lerped [5] and slerped [6] out with interpolation [7] and extrapolation to deal with lag compensation [8] and client prediction [9][10][11]. Sometimes this also involves channels and grid/graph areas where only messages to players around you or in that area are required to ACK when needed i.e. player hit/death.
Most large real-time games are just UDP broadcast for 99% of action. TCP is almost never used in real-time action games like FPS, MMO, RTS etc.
Rarely are TCP and UDP combined, rather RUDP or later something like SCTP, allows streaming/real-time capable broadcasts with enough verification/reliable messages where needed. Combining TCP and UDP can end up with queuing issues that affect both TCP and UDP traffic [4] so most games just go with reliable variant of UDP.
Gaffer on Games has a good section on why UDP is used in games [12]
> The web is built on top of TCP, which is a reliable-ordered protocol.
> To deliver data reliably and in order under packet loss, it is necessary for TCP to hold more recent data in a queue while waiting for dropped packets to be resent. Otherwise, data would be delivered out of order.
> This is called head of line blocking and it creates a frustrating and almost comedically tragic problem for game developers. The most recent data they want is delayed while waiting for old data to be resent, but by the time the resent data arrives, it’s too old to be used.
> Unfortunately, there is no way to fix this behavior under TCP. All data must be received reliably and in order. Therefore, the standard solution in the game industry for the past 20 years has been to send game data over UDP instead.
> How this works in practice is that each game develops their own custom protocol on top of UDP, implementing basic reliability as required, while sending the majority of data as unreliable-unordered. This ensures that time series data arrives as quickly as possible without waiting for dropped packets to be resent.
> So, what does this have to do with web games? The main problem for web games today is that game developers have no way to follow this industry best practice in the browser. Instead, web games send their game data over TCP, causing hitches and non-responsiveness due to head of line blocking.
> This is completely unnecessary and could be fixed overnight if web games had some way to send and receive UDP packets.
[1] https://www.ietf.org/proceedings/44/I-D/draft-ietf-sigtran-r...
[2] http://enet.bespin.org/
[3] https://en.wikipedia.org/wiki/RakNet
[4] https://web.archive.org/web/20180704154418/https://www.isoc....
[5] https://en.wikipedia.org/wiki/Linear_interpolation
[6] https://en.wikipedia.org/wiki/Slerp
[7] https://developer.valvesoftware.com/wiki/Interpolation
[8] https://developer.valvesoftware.com/wiki/Lag_compensation
[9] https://developer.valvesoftware.com/wiki/Prediction
[10] https://gafferongames.com/post/snapshot_compression/
[11] https://gafferongames.com/post/snapshot_interpolation/
[12] https://gafferongames.com/post/why_cant_i_send_udp_packets_f...