2

As the title says, how do I get around a browser's 6 connections per domain limit?

I have a web app that needs to download data from the server as quickly as possible. Currently, I have up to about a dozen connections being opened at once, but in the network tab I see that several of the connections are stalled (Chrome) or blocked (Firefox) shown in gray:

enter image description here

After some digging around I believe this is due to Chrome's 6 connections per domain limit. How do I get around this?

After some searching, I have some reason to believe that one of these options may work, but I would like to know which option is the best (not a hack):

  • Use several subdomains (a.mysite.com, b.mysite.com etc...) and point them to the main server so that Chrome believes that they are different sites. This sounds like the most "hacky" option in my opinion and I don't know how long this will actually work for.
  • Some answers suggest that HTTP2 isn't restricted by the 6 connection limit, but when I look into using HTTP2 it seems like if the browser supports it then it will use it. So I guess this doesn't actually work since I'm still getting the stalled message in Chrome's most recent version.
  • I'm currently using fetch to get a stream of data from the server, would using Web Sockets or WebRTC instead not be limited by the 6 connection limit?

What other options are there?

now_world
  • 940
  • 7
  • 21
  • 56
  • 1
    HTTP2/SPDY also requires the back end to support it too, not just the browser. Also worth pointing out, having more connections doesn't mean things will go faster. In fact in can have a negative effect as you get into something called thrashing.. – Keith Jun 19 '20 at 20:01

1 Answers1

3

I don't think webRTC is limited to 6 connections per domain, since it is often used for P2P mesh connections where that restriction would make no sense.

But I'd be surprised if you got better performance out of 20 datachannels than one HTTP2 connection since the webRTC datachannel is really not optimized for throughput.

You might also want to look at using Service Workers to work around the problem in a different way.

Tim Panton
  • 469
  • 3
  • 4