In the web world a web browser makes a new request for every static file it has to retrieve, so; a stylesheet, javascript file, inline image - all initiate a new server request. Whilst my knowledge of the web is pretty good, the underlying technologies like websockets are somewhat new to me in how they work and what they are capable of.
My question is rather theoretical, but I am wondering if it's possible now or would ever be possible to serve static files via a websocket? Considering websockets are a persistent connection from the client (web browser) to the server, it makes sense that websockets could be used for serving some if not all static content as it would just be one connection as opposed to many.
To clarify a little bit.
I realise my wording about connections was incorrect as pointed out by Greg below. But from what I understand the reason CDN's were created and are still used today is to address the issue with browsers and or servers having a hard limit on the number of concurrent downloads, once you hit that limit your requests are then queued thus adding to the page load time. I am aware they were also created to provide cookie-less requests as well. So really my question should be: "Can websockets be used in place of a CDN?"
BrowserScope has some useful metrics, it appears as though the request limit is about 6 per hostname for most modern browsers and even IE8. But as I said sometimes people have more than 6 resources, does this mean they're being queued and slowing the page load time where websockets could potentially reduce this to one?
In the web world a web browser makes a new request for every static file it has to retrieve, so; a stylesheet, javascript file, inline image - all initiate a new server request. Whilst my knowledge of the web is pretty good, the underlying technologies like websockets are somewhat new to me in how they work and what they are capable of.
My question is rather theoretical, but I am wondering if it's possible now or would ever be possible to serve static files via a websocket? Considering websockets are a persistent connection from the client (web browser) to the server, it makes sense that websockets could be used for serving some if not all static content as it would just be one connection as opposed to many.
To clarify a little bit.
I realise my wording about connections was incorrect as pointed out by Greg below. But from what I understand the reason CDN's were created and are still used today is to address the issue with browsers and or servers having a hard limit on the number of concurrent downloads, once you hit that limit your requests are then queued thus adding to the page load time. I am aware they were also created to provide cookie-less requests as well. So really my question should be: "Can websockets be used in place of a CDN?"
BrowserScope has some useful metrics, it appears as though the request limit is about 6 per hostname for most modern browsers and even IE8. But as I said sometimes people have more than 6 resources, does this mean they're being queued and slowing the page load time where websockets could potentially reduce this to one?
Share Improve this question edited Apr 2, 2012 at 1:57 Dwayne Charrington asked Apr 2, 2012 at 1:31 Dwayne CharringtonDwayne Charrington 6,6228 gold badges42 silver badges63 bronze badges 5- 1 Your initial assumption is incorrect - each image etc is a separate HTTP transaction, not necessarily a separate request. See HTTP persistent connection. – Greg Hewgill Commented Apr 2, 2012 at 1:35
- It is possible now. IIRC, web browser and servers optimised the use of connections, maybe more than 10 years ago. They do not open a new connection for each file. – gbulmer Commented Apr 2, 2012 at 1:36
- You are correct Greg, pletely phrased that part of my question wrong. There's still a limit on persistent connections though, right? So if you have 15 static files (not really a high number) you're going over the limit. Could websockets be used to serve files faster bypassing the maximum or am I over-thinking the capabilities of websockets? – Dwayne Charrington Commented Apr 2, 2012 at 1:38
- As I said my knowledge of underlying web technologies is rather limited, I guess I'm really only an API user of these technologies. Am I wrong in assuming that modern browsers and servers aren't capable of multiple-concurrent downloads of static files and that it's still a bottleneck issue like it was a few years ago? – Dwayne Charrington Commented Apr 2, 2012 at 1:40
- The cost of setting up 15 concurrent web socket connections may be higher than creating a small number of http connections then piplining your 15 GETs. This'll certainly be true for mobile clients. – simonc Commented Apr 2, 2012 at 13:46
2 Answers
Reset to default 10It's definitely possible but there are a few reasons why you probably don't want to use this for static resources:
- You need at least one resource that is statically delivered over the standard HTTP mechanism which means you need something capable of serving static resources anyways. Generally you want to keep Javascript separate from your HTML which would mean another static load. Or you can be messy and put the WebSocket code embedded on the main page, but you still are really any better off yet.
- You can't open WebSocket connections until a script on the page starts running. Establishing the WebSocket connection adds some initial latency.
- Most browsers will load non-conflicting static resources in parallel (some older browsers have a severe limit on the number of parallel connections, but they still have some parallelization). You could open multiple WebSocket connections for different static resources, but doing this reliably and efficiently is going to take a lot of effort. Browsers have already solved most of these issues for static resources.
- Each WebSocket connection is a guaranteed order message based transport. Combined with the serialized nature of Javascript execution this effectively means you get to process one WebSocket message at a time. You could use Web Workers to be able to process more than one WebSocket connection in parallel, but the main render script will still be serialized across those connections. You could certainly make this efficient, but once again, this isn't a trivial problem and browsers have already solved a lot of these static resource loading problems.
- Many web servers support gziping resources before delivering them. WebSocket does not yet have pression support (it's being discussed as an extension in the working group). This means if you want to press your resources over WebSocket you will have to do this in Javascript which will add more latency.
If you have parts of your page that are dynamically updated using static resources (e.g. loading in new images into a HTML5 canvas game), then WebSockets may be your best option because an already established WebSocket connection will have low latency and overhead for getting pushed updates from the server then getting these delivered over HTTP. But I wouldn't remend using WebSockets for the initial static resources when you page first loads.
This answer does not really address your web sockets question, but it may make it obsolete:
The next generation technology that is supposed to solve the problem of transferring several assets over a single connection is SPDY, which is was a candidate for HTTP 2.0. It has working implementations in Chrome and Firefox and already some experimental server-side support by the likes of Google and Twitter.
Edit: SPDY protocol is now deprecated. You can however look into it for research purposes.