Context description
Recently, I was working on a web disk product. Users can upload folders by operation, or upload multiple files by multiple selection. During the project testing, I encountered the bug of HTTP request uploading a large number of files.
Browser pit (limit on the number of concurrent browser requests)
Here are a few things to say about concurrent browser requests with domain names, directly quoted here:
Due to the number of ports and the overhead of thread switching, it is impossible for browsers to make unlimited concurrent requests, hence the concurrency limit and HTTP/1.1 Keep Alive. Therefore, IE6/7 has only 2 concurrency under HTTP/1.1, but HTTP/1.0 has 4. With the development of technology, load balancing and a large number of applications of all kinds of NoSQL are basically enough to deal with the problem of C10K. But not every site knows how to use domain hash, or multiple domain names, to speed up access. As a result, the new browser increases the concurrency limit, but still keeps it under eight
- Due to the limitation of TCP protocol, PC only 65536 ports can be used to send connections to the outside, and the operating system has a limit on the number of half-open connections to protect the operating system TCP\IP protocol stack resources are not quickly exhausted, so the browser is not good to send too many TCP connections, Instead, the TCP connection can be reused after it is used up or simply re-established.
- If you use a blocking socket model to establish connections, issuing multiple connections at the same time will force the browser to open several more threads, and threads are sometimes not a lightweight resource because a context switch is expensive.
- This is the browser protecting the server as a conscientious client. Like the Collision detection mechanism of Ethernet, clients must determine a waiting period before using common resources. When more than two clients want to use a common resource, a strong, evil client can cause a weak client to completely lose access to the common resource. Once upon a time Thunderbolt was spray is because it is not a conscience of the client, it as HTTP protocol client did not consider the pressure of the server, as BT client did not consider their own upload obligations.
The following are the limits on the number of concurrent requests for the same domain name in each browser for your reference:
Because there is a limit to the number of requests for the same domain name, the number of requests exceeding the limit will be blocked, which is why front-end requests will time out.
Server pit
HTTP code 429:
In HTTP, the response status code 429 Too Many Requests indicates that the user sent Too Many Requests within a certain period of time, exceeding the frequency limit. In the response, a retry-after header can be provided to indicate how long the user needs to wait before sending a new request.
The server is in a security policy to prevent attacks. Therefore, the server limits the number of upload pairs within the same IP address. If the number exceeds this time, 429 requests are directly rejected. This is why we see 429 failures in the current request.
The solution
At present, the browser side of the operation is appropriate release timeout, request fragmentation, request record. The transformation of the server side is to support fragment uploading and provide the interface of batch operation.