Usually, when using various network disk tools or downloading large files on the website, you will encounter the problem of current limitation. For example, the actual broadband purchased by the user from the broadband operator is 100 Mb/s, but in the process of downloading files, the download speed can only reach 10 Mb/s or lower, this situation can be considered as The server or client has done speed limit processing.
From the customer's point of view, the speed limit is indeed an offensive mechanism. The download speed is slow, and a file often takes a long time to download. Although you have applied for high-speed broadband, you cannot enjoy high-speed downloads. Cause customer resentment, so why add this extra layer of restrictions? In fact, there are many reasons for server current limit, the most common reasons are as follows:
Protect the server: processing a large number of requests on the server may cause the server to be overloaded, affecting the performance and stability of the server. Current limiting can ensure that the server runs within a reasonable load range, thereby ensuring the overall availability of the service;
Balanced traffic: Flow limiting can balance the traffic of the server, preventing individual users from occupying too much bandwidth, and causing other users' requests to be unable to get a reasonable response.
For commercial considerations: The purpose of limiting the speed of ordinary users is to provide higher bandwidth and faster download speeds to paying users and ensure the experience of paying users.
2. Common speed limit methods
Common speed limit methods are roughly divided into two types: client speed limit and server speed limit:
Client (front-end) speed limit: refers to the flow control between the server and the client, that is, to limit the data transmission rate when the client initiates a request. Common front-end speed limit methods include: bandwidth limit, IP address limit, port limit , application restrictions, etc., the front-end speed limit is usually carried out at the network level, and the flow of the entire network is controlled by limiting the rate of client requests;
Server (backend) speed limit: refers to flow control when the server processes requests, that is, to limit the data transmission rate of the server in response to client requests. Common backend speed limit methods include: download speed limit, download quota limit, download Time limit, IP address limit, etc., the backend rate limit is usually implemented at the application level, and controls the traffic and load of the server by limiting the rate at which the server responds to requests.
Compared with the front-end speed limit, the back-end speed limit is more effective and safe, and the back-end speed limit is more difficult to bypass. It can limit the global access rate of the entire service, and it is easier to manage and monitor in a centralized manner. In contrast, front-end rate limiting can only affect a single client, needs to be enforced on each client, and may require updating client code, making managing and monitoring rate limiting measures more complex. Of course, in some cases, the front-end speed limit may also be a necessary measure.
3. Commonly used backend speed limit algorithm
Commonly used backend rate limiting algorithms:
Token Bucket Algorithm: Limit traffic based on the idea of token bucket, and realize speed limit by limiting the rate at which each request obtains tokens from the token bucket.
Leaky bucket algorithm: based on the idea of leaky buckets to limit traffic, through leaky buckets to limit the rate of request sending.
Fixed window algorithm: Limit the sending rate of requests through a fixed time window.
Sliding window algorithm: Limit the sending rate of requests through sliding windows, allowing the request rate in each window not to exceed the specified rate.
Seeing the algorithm, many developers may feel some pressure. How to implement it and whether it is stable after implementation will become problems encountered in the development process. In order to solve the distress of developers, and to make developers focus more on the implementation of business and functions, EdgerOS has added the Throttle current limiting module in version 1.10.0 of the JSRE engine, and developers can easily use this module for flow control limit.
4. Implementation principle of Throttle module
During EdgerOS development, we can import the Throttle class in the Stream module through the Require() method.
const Throttle =require('stream').Throttle
Throttle class object, which can limit the rate of data streams to protect backend services. Specifically, Throttle can control the rate at which data is read from another readable stream, and can set a rate limit to ensure that the specified maximum rate. This implementation is very important, because when a large amount of data is read from a service at the same time, the performance of the service may be affected, so limiting the rate of data flow can ensure that the service can always maintain good performance.
There is a complete set of rate limits inside the Throttle class. Specifically, Throttle uses internal properties to store rate limits and other information. The class contains information such as timers, timestamps, rates, and reads from source readable streams. The data. Throttle judges whether there is data to be read through the events of the source stream, and how to implement the rate limit. While ensuring data consistency, it also takes into account the needs of fast response.
5. How to use Throttle to limit speed?
const Throttle =require('stream').Throttle
// Create a stream that reads the specified file
var src = fs.createReadStream('./data.txt');// Create a stream with a read rate of 50 KBytes/s
var thr = new Throttle(src,{
rate:50*1024});// Start time
var start = Date.now();// Read data from throttle readable stream
thr.on('data',()=>{
});
thr.on('end',()=>{
var cost = Date.now()- start;
console.log('cost:', cost,'ms');});
The JSRE installed in EdgerOS is a Javascript runtime that aims to lower the barriers to entry for developers. In continuous iterations, from the Device module to the SyncTable database, as well as the newly added CloudHost module and Throttle module.
It has been providing developers with the most streamlined packaging of complex protocols and business scenarios, so that developers can fully focus on business development and improve developers' work efficiency. As EdgerOS and JSRE mature, it is believed that more easy-to-use functional modules will appear in the EdgerOS development ecosystem in the future.