The principle of Game VPN
General games in order to ensure real-time, will use UDP for network transmission, for example, when the character of the shooting game is walking, the network is stuck, but less than a second the game character has moved to the next position, this is the performance of UDP, it does its best to deliver, allowing packet loss. Suppose it is TCP, network card, you will find that the game screen paused, the character slides forward like the card, because the TCP is connection-oriented, packet loss will be resent, arrival will be confirmed.
Of course, the game is not all UDP,TCP and even higher-level HTTP, it all depends on the delay requirements of the game.
So is UDP or TCP used in the game?
If the client initiates stateless queries intermittently, and occasional delays can be tolerated, use HTTP/HTTPS.
If both the client and server can send packets independently, but occasional delays can be tolerated (for example, online card games, many MMO games), consider using TCP persistent connections.
If both the client and the server can send packets independently and cannot tolerate delays (for example, most multiplayer action games, some MMO games), consider using UDP
When playing some foreign server games (the game server is abroad), the direct connection effect is poor, so we need to add a layer of agent, that is, the vpn for game, to achieve the acceleration effect, because the game is generally UDP transmission, but the operator interferes seriously with UDP, so we need to do some processing on the connection between the game client and the proxy server. The principle of the accelerator is very simple, that is, the UDP proxy. The main difficulty lies in two points: one is how to deal with the UDP connection between the game client and the accelerator server, and the other is how to let the game client connect to the vpn for game. (generally, the game client does not set up the proxy server function)
The QoS,UDP socket for UDP changes a different source port every time it sends a packet. If a device sends UDP packets crazily, it will create a large number of quintuples in a short time. In traditional stateful firewalls, stateful NAT uses a quintuple to track a connection. If there are too many connections, it will put a lot of pressure on these state-saving devices, which is mainly reflected in two aspects:
Storage pressure: the device has to configure a large amount of memory to hold a large number of connections.
Processor pressure: the device has to spend more time matching a connection when the packet arrives.
Due to the stateless nature of UDP, there is no message indicating when a connection should be created and when it should be destroyed. The device must have the ability to age the created UDP connection on its own and have to make a choice in tradeoff:
If the aging time is too short, it will destroy the UDP connection with normal communication but low communication frequency.
If the aging time is too long, it will cause invalid UDP connections to consume a lot of memory, which will create an attack surface for DDoS attacks.
The attacker only needs to use different UDP quintuples to construct messages to pass through the state device. Because the UDP message does not have any control information indicating connection creation and destruction, the state device has to treat any new quintuple equally, that is, to create connections for them and specify the same aging time. TCP is completely different. Due to the existence of control information such as syn,fin,rst, state devices can specify different aging times for TCP connections in different states. Obviously, the aging time of connections in ESTABLISHED state is much longer than that in other states.
This makes it much more difficult to use TCP to implement the same attack. Why can't constructing different UDP quintuples quickly achieve the same effect as TCP? If you just blindly send syn over a different source port, the connection in this state will quickly age out (within 10 seconds or less) without a real peer response.
If you build a large number of real TCP connections using different ports, you will have to pay a high price to maintain these connections while the stateful device is compromised. You initiate a TCP connection, and you have to save it yourself in order for the stateful device to save the connection. Unless you initiate a real connection through a large number of reflective hosts at the same time, this kind of attack will not work on a single or even a small number of hosts.
For stateless devices, we no longer have to worry about keeping a five-tuple connection. However, the ability of UDP to construct massive quintuples in a short time will still affect the normal operation of stateless device packet classification algorithm. Based on the priority queue of packet classification algorithm, cache management is almost completed by five-tuple computing, and the characteristics of UDP will make it difficult for stateless devices to control their traffic. As a result, there is no way to accurately identify UDP traffic as it fills all levels of queue caches, and even if BBR encounters UDP traffic, it can only drop pacing rate.
There are two ways to deal with UDP, one is protocol nesting dolls, which covers the game's UDP packet with a layer of TCP (UDP over TCP), then unpacks the TCP into UDP at the destination, and finally sends it to the game server, and the returned data packet is also processed in the same way; the other is forged TCP (FakeTCP), adding fake TCP header to the UDP packet to make it look like the TCP protocol, deceiving the operator.
