Or let's actually read about QUIC before quickly commenting on it.
QUIC uses two mechanism to make sure you cannot do such attacks:
* it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1]
* it requires the client's first message (client hello) to be padded to at least the size of the server's response. Which implies that an attacker would require as much bandwidth as is spent by the server performing the attack, making the attack as practical as the attack without QUIC. [2]
But, since it runs on UDP, a hacker could attack few DNS servers and amplify a UDP attack toward a Quic server. This is true for all reflection and amplification attacks.
Hence, Quic is vulnerable to receive huge amplification attacks +100Gb and soon 1Tbps.
It will not make internet a safer and better place.
Even video game companies used to use UDP and they move away because UDP is too dangerous. They now use TCP with a kind of websocket techno to not allow UDP.
Many big enterprises don't allow UDP toward their critical infrastructure.
Games like agar.io and slither.io use websockets over TCP because browsers don't allow you to use UDP packets. The author of one of them (sorry I forget which) blogged about their adventure, and IIRC they still have lag issues, and there isn't a way to resolve them without switching to UDP.
I've personally worked on multiplayer game engine code and I assure you that UDP is far superior for VOIP and game state packets. TCP requires far too much overhead, requires packets be received in order, etc.
These make no sense for a game engine. If we have a sequence of player movements, lets say their X position [1, 2, 3], but we miss a packet [1, -, 3] we're fine, we only want their most recent packet. But the protocol will require acknowledgment and that packet to be resent, so it will require 8 different packets be sent, instead of 3! We don't even need the packet!
A lot of games are implementing web based technologies for their UIs (Panorama for example) and those will of course use TCP but that's not what the actual game server uses for VOIP/game state
Agreed. For most fast paced multiplayer games, UDP would be better. It depends on the specific use case though. TCP has some advantages when you need features like authentication and encryption because packets are guaranteed to be delivered in-order for the life of the connection; this feature is important for TLS block ciphers. With UDP, you may end up having to reinvent some features that are already offered by TCP and your solution might end up worse overall. So you have to find the balance between code simplicity and performance.
TCP can cover more use cases than UDP but for some use cases this will be at the expense of performance.
Slither.io and Agar.io use exclusively TCP but that's only because browsers don't allow you to send/receive UDP packets. If you've ever played those games on any network or device with shaky internet then you'll know those games have lag issues, and the only way to optimize it more would be to switch to UDP (Which they can't)
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.
QUIC uses two mechanism to make sure you cannot do such attacks:
* it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1]
* it requires the client's first message (client hello) to be padded to at least the size of the server's response. Which implies that an attacker would require as much bandwidth as is spent by the server performing the attack, making the attack as practical as the attack without QUIC. [2]
[1]: https://tools.ietf.org/html/draft-ietf-quic-transport-16#sec...
[2]: https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9...