5 ms·
I think this a good interim "solution", but it won't work for everyone. On a larger scale it's rife with issues: e.g. browsers often have a limit to how many do
by makmanalp 8y ago
I think this a good interim "solution", but it won't work for everyone. On a larger scale it's rife with issues: e.g. browsers often have a limit to how many downloads they'll do from a single domain in parallel, so stuffing API, assets and pages all into the same domain can limit performance. The other thing is that using DNS to load balance between servers is much more lightweight than using an HTTP proxy / load balancer to direct traffic.
- panarky 8y agoHTTP/2 virtually eliminates the limit on concurrent requests. For example Firefox allows 100 concurrent requests by default with H2.
- londons_explore 8y agoNobody has an excuse not to use either HTTP/2 or QUIC on a modern website. They should also use just one domain - DNS lookups are a pretty slow and flaky part of the process of loading a webpage, and downloading loads of HTTPS certificates for all the domains involved isn't great either. Managing just one domain is also a lot easier - less to monitor, less to maintain, simpler architecture, etc. The only remaining reason for extra domains is to act as a security boundary - for example when you're running untrusted user javascript.
- chrismorgan 8y agoYour statements are overly definite. > Nobody has an excuse not to use either HTTP/2 or QUIC on a modern website. Sure they do. HTTP/2 is not uniformly superior to HTTP/1.1, primarily due to head-of-line blocking; so that on a poor quality network connection, with multiple HTTP/1.1 connections it’s quite possible that one will come through while another takes longer due to packet loss, while on HTTP/2 it’s all on one TCP connection, so that packet loss affects all requests. That’s what QUIC is about fixing. HTTP/2 is also currently incompatible with WebSockets (there’s a draft in progress for resolving that), so HTTP/2 offers no benefit for WebSocket domains or little-to-no benefit for WebSocket-heavy stuff. HTTP/2 also works differently from HTTP/1.1, so that certain moderately obscure combinations of types of long-lived requests can’t be cleanly terminated in HTTP/2 as they can be in HTTP/1.1 (sorry I’m being vague—I can’t recall the details off-hand). And there’s just the usual “existing software that doesn’t support HTTP/2” justification as well. (Despite the listed criticisms of HTTP/2, I do agree that almost everyone should be using HTTP/2.) As for QUIC (Google or IETF variant), it’s still experimental, with various unknowns that are being nutted out, and is not suitable for wide deployment by most entities just yet. > The only remaining reason for extra domains is to act as a security boundary No, that’s merely one of the best justifications for additional domains. There are other reasons for using other domains, though I would agree with a less strongly worded version of your initial declaration: that they should try, if convenient, to use just one domain.
- kevin_thibedeau 8y agoThis isn't a practical solution for embedded web servers where even six concurrent requests can be taxing.
- bdcravens 8y agoWouldn't it make sense to put the assets that don't need need API access on other domains?
- deleted 8y ago[deleted]
- tootie 8y agoConcurrent connections per domain is much less of an issue now. The max is high enough most apps will never hit it.