Why does your browser limit the number of concurrent network calls?
Every browser limits the number of concurrent connections to a single domain as well as it has a limit for overall concurrent connections.
The above image is taken from StackOverflow. It shows the number of parallel connections various browser supports.
But why does the browser limit the number of calls at all?
To understand this lets first understand what happens when a network call is initiated.
What happens when you make a network call?
HTTP 1.0
When you make a network call from your browser using ajax, or when you request a script or a style stored in a CDN, your browser has to establish a TCP connection with the server. This connection requires several round-trips of information between the client and the server, which is also called handshaking.
handshake is an automated process of negotiation between two participants (server and a client) through the exchange of information that establishes the protocols of a communication link at the start of the communication before full communication begins.
So basically, when a network call is made, a tunnel is created between the client and the server.
Can we make multiple requests using the same connection?
HTTP 1.1: Persistent connection
With HTTP 1.0 there were restrictions that only one request can be made per connection. That means for each network request, a new connection channel will be established.
Since creating a connection is an expensive process, HTTP 1.1 came with a concept of a persistent connection. (this feature was added to HTTP 1.0 as well on the later phase)
A persistent connection is one that remains open for some limited period of time and can be reused for several requests, saving the need for a new TCP handshake for each connection request.
Using this feature, we can have multiple requests one after the other through the same connection channel.
Can we not have concurrent requests within a single connection?
HTTP 1.1: HTTP Pipelining
By now we have a tunnel created between a server and a client, but we still have to wait for the response of the first request before making a second request.
To make concurrent requests possible, HTTP 1.1 came up with another concept called Pipelining.
HTTP pipelining is a technique in which multiple HTTP requests are sent on a single connection channel without waiting for the corresponding responses. This means the second request does not wait for the response of the first request.
The following diagram (taken from Mozilla docs) illustrates the above-mentioned concepts.
So you mean we can have any number of concurrent requests using HTTP Pipelining?
HTTP Pipelining did speed up the loading time of HTML pages, but multiple problems incurred with it.
The first problem is that the server must send its responses in the same order that the requests were received — so the entire connection remains first-in-first-out basis.
Another problem is related to HOL Blocking.
Head-of-line blocking (HOL blocking) is a performance-limiting phenomenon that occurs when a line of packets is held up by the first packet.
Hence most browsers disabled this feature by default.
Then how do we achieve concurrent requests now?
The only way possible to achieve concurrent requests is by making use of multiple persistent connections.
So what is the number of connections that a browser can make at a time?
The answer to this is the first part of this article.
Though various browsers have set their own limitation, by convention, a single-user client SHOULD NOT maintain more than 2 connections with any server.
What about our original question? Why limit the number of concurrent connections?
By now you might be aware that each connection requires some resources to be allocated from the server. In addition to this, a server has to maintain information on each and every connection request, hence too many connections imply a lot of burden for the server.
Another reason is a DoS Attack. A Denial of Service(DoS) attack basically means that you try to make the computer so busy trying to deal with you that it’s incapable of dealing with other computers. When the other computers can’t connect, there’s a denial of service.
From the official document: Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion.
What about HTTP 2.0
HTTP 2.0 aka SPDY, unlike HTTP 1.X, can have multiple concurrent requests. more about it here
TL;DR : Concurrent call is achieved by the concurrent connection channel that a browser establishes. Each connection requires some resources to be allocated from the server. In addition to this, a server has to maintain information on each and every connection request from the client. Also, there is high chance of DoS attack. Hence, the server restricts the number of connections fromt the client.
I hope you found this article useful. I would love to hear your thoughts. 😇
Thanks for reading. 😊
Cheers! 😃
If you find this article useful, you can show your appreciation by clicking on the clap button. As the saying goes, ‘When we give cheerfully and accept gratefully, everyone is blessed’.
