Five-minute technical talk | The underlying origin of scene broadband

Part 01

QoS Service  

Domestic operator networks generally provide QoS. QoS refers to the use of various basic technologies by the network to provide better service capabilities to support specific network communications. It is a network security mechanism designed to solve problems such as network latency and congestion. Simply put, when the network is congested, the operator will give priority to important traffic packets and discard some unimportant packets. Which packets are discarded depends on the usage scenario and the operator's strategy.

For users who are subject to QoS restrictions, the following symptoms may occur: reduced network speed, packet loss, and unstable ping values. In this case, users in different scenarios often want to obtain better network quality to meet the scenario usage, such as higher bandwidth, less packet loss, and lower latency.

It should be noted that QoS does not distinguish between TCP and UDP. For UDP, in addition to the regular QoS restrictions, there may be more stringent restrictions, and even UDP may be blocked in some extreme cases. This is mainly because UDP's connectionless, stateless, broadcast support and best-effort transmission characteristics make it more costly for network operators to control UDP.

Part 02

The difference between TCP and UDP in gaming scenarios

Generally, in order to ensure the real-time performance of the game, it is common to use UDP for network transmission. For example, in a shooting game, when the character encounters a network lag while walking, the screen will be stuck, but when it recovers, the character in the screen has jumped to the next position, as if the frame was skipped. This is the characteristic of UDP, which tries its best to transmit and allows packet loss.

In contrast, if you use TCP, when the network freezes, you will find that the game screen pauses and the character moves forward frame by frame like it is stuck on a slide. This is because TCP is connection-oriented, and the lost packets will be retransmitted and will continue after confirmation. Of course, not only UDP and TCP are used in games, higher-level protocols such as HTTP may also be used, which depends entirely on the game's requirements for latency.

Part 03

Scenario selection of TCP and UDP

So should we use UDP or TCP in different usage scenarios?

If the client intermittently initiates stateless queries and occasional delays are acceptable (for example, querying academic papers, reference information, etc.), then consider using HTTP/HTTPS.

If both the client and the server can send packets independently, but occasional delays are tolerable (such as online card games and many MMO games), then consider using TCP persistent connections.

If both the client and server can send packets independently and cannot tolerate delays (such as most multiplayer action games, some MMO games, live broadcast interactions, etc.), then consider using UDP.

When accessing some foreign academic websites and game servers, direct connection may not be effective, so you need to use scene broadband to achieve optimization. Take games as an example, because games usually use UDP for transmission, and ordinary operator networks will have a greater interference with UDP, so scene broadband needs to do some processing on the connection between the game client and the proxy server.

Part 04

QoS issues of UDP protocol

Each time a UDP socket sends a data packet, the source port changes randomly. If a device sends UDP packets frequently, a large number of five-tuples (source IP address, source port, destination IP address, destination port, protocol) will be generated in a short period of time. Traditional stateful firewalls and stateful NAT use a five-tuple to track a connection. If there are too many connections, it will put tremendous pressure on the device that saves the state.

This pressure is mainly reflected in two aspects: storage pressure and processor pressure .

Storage pressure means that the device needs to be configured with a large amount of memory to store a large number of connections.

Processor stress means that the device needs to spend more time matching the connection when packets arrive.

Due to the stateless nature of the UDP protocol, there is no message indicating when to create or destroy a connection. The device must be able to age the created UDP connections on its own and make decisions in a trade-off. If the aging time is too short, UDP connections with low communication frequency will be destroyed. If the aging time is too long, invalid UDP connections will consume a lot of memory, providing an attack surface for DDoS attacks. The attacker only needs to construct different UDP five-tuple messages to pass through the state device. Since the UDP message does not have control information for connection creation or destruction, the state device has to treat all newly arrived five-tuples, create connections for them and specify the same aging time.

The TCP protocol is completely different. With control information such as syn, fin, and rst, the state device can specify different aging times for TCP connections in different states. The aging time of the connection in the ESTABLISHED state is significantly longer. This makes it more difficult to implement the same attack using TCP. Why can't the effect of UDP be achieved by quickly constructing different TCP five-tuples? If you blindly use different source ports to send syn without a real response from the other end, this connection state will age quickly (in 10 seconds or even less). If you construct a large number of real TCP connections using different ports, in addition to causing damage to the state device, the attacker himself must also pay a huge price to maintain these connections. You initiate a TCP connection, and in order for the state device to save the connection, you must also save the connection. Unless a large number of reflection hosts simultaneously initiate real connections, this attack is difficult to succeed on a single or a small number of hosts. For stateless devices, we no longer need to worry about maintaining the five-tuple connection.

However, the large number of 5-tuples constructed by UDP in a short period of time will still affect the normal operation of the packet classification algorithm of the stateless device. The priority queue and cache management based on the packet classification algorithm are almost all calculated based on the 5-tuple. The characteristics of UDP make it difficult for stateless devices to control its traffic. As a result, even if UDP traffic fills up queues and caches at all levels, it cannot be accurately identified. Even if BBR (Bottleneck Bandwidth and Round-trip propagation time) encounters UDP traffic, it can only reduce the pacing rate, with no other solution.

Ordinary carrier networks are more friendly to TCP and less friendly to UDP, but they are also unable to deeply detect the authenticity of TCP connections. A simple example is to change the protocol field of normal TCP data to UDP. Doing so will cause communication problems and even prevent effective transmission:

 if (iph->protocol == IPPROTO_TCP) { iph->protocol = IPPROTO_UDP; ip_send_check(iph); udph->check = 0; } else if (iph->protocol == IPPROTO_UDP) { iph->protocol = IPPROTO_TCP; ip_send_check(iph); }

Part 05

Conclusion

So far, we have basically explained from a basic perspective why there is a need for further network acceleration services in scenarios such as academics, games, and real-time audio. The main difficulties of acceleration services are two: first, how to handle the UDP connection between the client and the accelerator server; second, how to let the game client connect to the accelerator (generally, game clients do not have the function of setting up a proxy server). Scenario broadband is designed to solve these problems mentioned above in specific scenarios, provide a smoother and faster network experience for specific network application scenarios, and build more diversified and high-quality network services in the future.