If the server to which you're connecting is authoritative for all of the redirected sites, and you're using server push with SPDY... actually you could eliminate the RTTs for the redirects even if they were still there (by server pushing them all in sequence).... but that is just too cute. Getting rid of the redirects would be better:)
SCTP sadly isn't deployable in a world with NATs. It is definitely one of the solutions we examined before embarking on this journey. Things like UDT (and other non-TCP protocols) are very interesting... but not yet deployable, which means that these kinds of changes are further down the line.
SPDY goes further-- not only are requests and responses on separate streams asynchronous, but the parts of the different responses can be interleaved. The only head-of-line blocking here is based on the TCP buffering or the maximum frame size for SPDY (we typically use 4k frames).
Using SPDY, servers are able to publish a setting (whenever they want, including at connect time) which advertises how many concurrent streams are allowed. In all cases SPDY gives more control than HTTP.
And, if you multiplex connections over one SPDY connection, you often end up using less resources overall (including memory) as compared to HTTP connections. The average page uses ~40 connections, nowhere near just one connection!
If you don't care about resource utilization, it still speeds web up web pages...
No, HTTP suffers from head-of-line blocking. There is no way around that. HTTP also doesn't have header compression (which matters quite a bit on low-bandwidth pipes) nor prioritization to ensure that your HTTP, javascript and CSS load before the lolkittens:)
The Constitution is a wonderful document, but it doesn't guarantee anything. It specifies something. The Gov't is supposed to follow the specification, at which point we have a guarantee.
That is the biggest load of bullshit I've ever heard-- MOST creative people do it for the joy of having creating. A minority of them are in it only for the money. And today that is what we have. A bunch of people who are only in it for the money (many of them creative enough only to purchase patents) suing people who are creative and who likely just though whatever the heck it was is so obvious that it didn't cross their minds that it should be patentable.
The Judge's test is a poor one. He should have held up some random combinations of ipads and galaxy tabs and asked if he was holding up two of the same thing. The important part is that they're different, not that you can pick which one is the tab.
How is it different to having politician's random falsehoods enter into my brain against my will? You can carry these analogies to ridiculous extremes without trying.
Using the above (access to my brain), the obvious choice is to ensure that the politicians cannot contact my brain by turning off the communications device.
FYI, it has been done before. The computer did better than the GPs (and this was decades ago), however, noone was wanting to be the liable party.. and so, it never saw real use outside the study.
Score some more "benefit" for lawyers and the people who litigate.
performance measurement: In the whitepaper, as per my recollection, Chrome was the client for all of the measurements that we did.
Since top sites have more resources than most sites, on average more than 6 per host, and since Chrome has a low connection limit and had blocking problems preventing parallel loads (since there's no data on the metrics there's no way to know what webkit bugs were present) the results are then far less impressive. In fact, these performance numbers are pretty much meaningless, wouldn't you agree?
They are perfectly meaningful. If you don't like our findings, the most productive thing to do is to create an experiment that shows something better!
HTTPs fault handling is terrible, actually. When you're sending a request and you don't receive the response, you don't know if the request was processed or not. This is particularly fun for non-idempotent transactions like say.. charging your credit card. SPDY includes mechanisms for telling the client (assuming the connection wasn't broken) that the server rejected the request
What? When do you "not receive a response" for a request and it isn't a broken connection? If the server rejected a request then you get back an error status right? In any case charging your card twice is not a failing in HTTP, so I'm not sure what you are trying to say here. I have a hard time taking this point seriously, but maybe I don't understand HTTP well enough to understand your point.
I'm one of the people who maintain the servers which terminate all of these HTTP connections, and yes, when rebooting servers, when loadbalancing switches for whatever reason, etc. the request gets lost. It is preferable for a server to signal to the rest of the network (including any connected clients with idle connections) that it is going away. Since HTTP offers no mechanism to push any notification to the client, a server can either close the connection (and possibly thus swallow a request), or attempt to serve all requests until it goes away later (and the connection is closed). It ends up being the same-- the HTTP server has no mechanism to tell a client that it is going away and resolve the race.
In any case, you're talking about doing http-pipelining plus response reordering.
That's right, and you didn't respond to the fact that a connection problem would leave only one resource partially transferred instead of several, so I assume you accept that.
I think you're over simplifying. Certainly that is one of many possible scenarios. Another possible scenario is that it is also possible that you successfully transferred zero items using pipelining since the first element was large (or the server had significant think time), whereas SPDY successfully transfers N-1 items out of N. Making an experiment and testing against real-world behaviors is the best way to say whether or not it works. The possible state space is very large. In any case if you decide to use HTTP-pipelining like semantics with SPDY, you can. If you decide that there are higher priority items you'd like to receive, you signal the server that and it responds appropriately by preempting the low priority streams and/or interleaving the responses as per its heuristics.
How would you handle the following scenario: User opens video in one tab, creates another in which he or she looks up the Dow Jones index for the day. The video is still being displayed in the other tab. You have a head-of-line blocking issue. How do you deal with it?
That's incredibly contrived. You almost certainly wouldn't be serving videos from the same host as stock data so it would be a separate connection. Problem solved. You also probably wouldn't want the video streamed
Heya-- one of the SPDY developers here. It doesn't cut page load time in half (it could, but you'd have to have a truly *terrible* site design). It does provide some pretty good latency decreases, however. I wish the OP had quoted more real numbers...
You've got it right, essentially. Server push puts a file into the cache which will be referenced by the page that is loading. I don't recall if Chrome still supports it, but at one point it most certainly did.
A single IP != a single server. HTTP pipelining doesn't play well with proxies, and since you're never quite sure (on port 80) whether or not you're using a proxy, well, you end up with lots of fun heuristics about whether or not you can use it.
If you think that you're only limited by bandwidth, you should try taking the open-source SPDY implementation, modifying it, and then run an analysis of its behaviors over a similar dataset to the one we used (alexa-500). Data speaks volumes! Conjecture on its own isn't all that useful.
SCTP doesn't have enough flow control to make proxies safe or eliminate head-of-line blocking, good implementations don't exist on all platforms, and most damaging, it doesn't play well with IPv4 NAT. Not playing with IPv4 NAT is a killer.
SCTP was certainly one of the evaluated choices-- it had a lot of theoretically nice things going for it.
The protocol is documented externally, and the implementation is open source. We've begun talking with people at IETF about it and we have a public mailing list. I don' t know how it could be more open.
server push: We have some debates about this internally, but it seems the market is deciding that push is important-- e.g. image inlining into the HTML. Server push allows you to accomplish the same, but gives the benefit of having them known as individual resources by a single name, and thus cacheable. I believe it may be particularly beneficial for people on high-rtt devices like mobile. If you look at data just about anywhere, you can see that RTT is the real killer. 100ms RTTs are fairly normal for mobile devices. I'd much rather have the server push that data to me rather than having to wait 100ms between each round of requests-- it can make literally seconds of difference for complex pages.
Why "SPDY": The name we first chose would have made money for the lawyers... and so we picked another.
performance measurement: In the whitepaper, as per my recollection, Chrome was the client for all of the measurements that we did.
"supposed" benefit+pipelining: HTTPs fault handling is terrible, actually. When you're sending a request and you don't receive the response, you don't know if the request was processed or not. This is particularly fun for non-idempotent transactions like say.. charging your credit card. SPDY includes mechanisms for telling the client (assuming the connection wasn't broken) that the server rejected the request, and thus disambiguating the situation. In such cases, the client knows that it is safe to retry. In any case, you're talking about doing http-pipelining plus response reordering. How would you handle the following scenario: User opens video in one tab, creates another in which he or she looks up the Dow Jones index for the day. The video is still being displayed in the other tab. You have a head-of-line blocking issue. How do you deal with it? Canceling the video request is a poor choice-- the user likely will come back to it later. Waiting for the video to finish is a poor choice-- the user probably wants to see the Dow right now instead of 15 minutes later. Opening a new connection incurs additional cost in the network (NAT), on the servers and worse yet, incurs the latency penalty of a new connection setup plus whatever other protocols you're negotiating. I don't want to wait 2 RTTs before I get my content. I'm impatient. I want it now!:)
I'd suggest taking the open sourced code that we've provided and implementing your solution. You can then run the same battery of tests against your solution that we've done (in the lab) for SPDY. Data is extremely convincing when collected properly. If your solution worked better, then we'd have a basis for re-analysis.
Slashdot Mirror
If the server to which you're connecting is authoritative for all of the redirected sites, and you're using server push with SPDY... actually you could eliminate the RTTs for the redirects even if they were still there (by server pushing them all in sequence). ... but that is just too cute. Getting rid of the redirects would be better :)
SCTP sadly isn't deployable in a world with NATs. It is definitely one of the solutions we examined before embarking on this journey.
Things like UDT (and other non-TCP protocols) are very interesting... but not yet deployable, which means that these kinds of changes are further down the line.
FYI, the compression of headers in SPDY actually compresses headers down to ~10% of their original size on average.
SPDY goes further-- not only are requests and responses on separate streams asynchronous, but the parts of the different responses can be interleaved. The only head-of-line blocking here is based on the TCP buffering or the maximum frame size for SPDY (we typically use 4k frames).
Using SPDY, servers are able to publish a setting (whenever they want, including at connect time) which advertises how many concurrent streams are allowed. In all cases SPDY gives more control than HTTP.
And, if you multiplex connections over one SPDY connection, you often end up using less resources overall (including memory) as compared to HTTP connections.
The average page uses ~40 connections, nowhere near just one connection!
If you don't care about resource utilization, it still speeds web up web pages...
As one of the creators of SPDY..
No, HTTP suffers from head-of-line blocking. There is no way around that. :)
HTTP also doesn't have header compression (which matters quite a bit on low-bandwidth pipes) nor prioritization to ensure that your HTTP, javascript and CSS load before the lolkittens
mod this one up please.
The Constitution is a wonderful document, but it doesn't guarantee anything. It specifies something.
The Gov't is supposed to follow the specification, at which point we have a guarantee.
Wish it were so.
That is the biggest load of bullshit I've ever heard-- MOST creative people do it for the joy of having creating. A minority of them are in it only for the money.
And today that is what we have. A bunch of people who are only in it for the money (many of them creative enough only to purchase patents) suing people who are creative and who likely just though whatever the heck it was is so obvious that it didn't cross their minds that it should be patentable.
The Judge's test is a poor one.
He should have held up some random combinations of ipads and galaxy tabs and asked if he was holding up two of the same thing.
The important part is that they're different, not that you can pick which one is the tab.
That was a horribly shitty experiment.
How is it different to having politician's random falsehoods enter into my brain against my will?
You can carry these analogies to ridiculous extremes without trying.
Using the above (access to my brain), the obvious choice is to ensure that the politicians cannot contact my brain by turning off the communications device.
FYI, it has been done before. The computer did better than the GPs (and this was decades ago), however, noone was wanting to be the liable party.. and so, it never saw real use outside the study.
Score some more "benefit" for lawyers and the people who litigate.
This.
Damn, that is one of the funniest comments I've seen in a LONG time!
increment/decrement is *extremely* cheap.
performance measurement: In the whitepaper, as per my recollection, Chrome was the client for all of the measurements that we did.
Since top sites have more resources than most sites, on average more than 6 per host, and since Chrome has a low connection limit and had blocking problems preventing parallel loads (since there's no data on the metrics there's no way to know what webkit bugs were present) the results are then far less impressive. In fact, these performance numbers are pretty much meaningless, wouldn't you agree?
They are perfectly meaningful. If you don't like our findings, the most productive thing to do is to create an experiment that shows something better!
HTTPs fault handling is terrible, actually. When you're sending a request and you don't receive the response, you don't know if the request was processed or not. This is particularly fun for non-idempotent transactions like say.. charging your credit card. SPDY includes mechanisms for telling the client (assuming the connection wasn't broken) that the server rejected the request
What? When do you "not receive a response" for a request and it isn't a broken connection? If the server rejected a request then you get back an error status right? In any case charging your card twice is not a failing in HTTP, so I'm not sure what you are trying to say here. I have a hard time taking this point seriously, but maybe I don't understand HTTP well enough to understand your point.
I'm one of the people who maintain the servers which terminate all of these HTTP connections, and yes, when rebooting servers, when loadbalancing switches for whatever reason, etc. the request gets lost. It is preferable for a server to signal to the rest of the network (including any connected clients with idle connections) that it is going away. Since HTTP offers no mechanism to push any notification to the client, a server can either close the connection (and possibly thus swallow a request), or attempt to serve all requests until it goes away later (and the connection is closed). It ends up being the same-- the HTTP server has no mechanism to tell a client that it is going away and resolve the race.
In any case, you're talking about doing http-pipelining plus response reordering.
That's right, and you didn't respond to the fact that a connection problem would leave only one resource partially transferred instead of several, so I assume you accept that.
I think you're over simplifying. Certainly that is one of many possible scenarios. Another possible scenario is that it is also possible that you successfully transferred zero items using pipelining since the first element was large (or the server had significant think time), whereas SPDY successfully transfers N-1 items out of N. Making an experiment and testing against real-world behaviors is the best way to say whether or not it works. The possible state space is very large.
In any case if you decide to use HTTP-pipelining like semantics with SPDY, you can. If you decide that there are higher priority items you'd like to receive, you signal the server that and it responds appropriately by preempting the low priority streams and/or interleaving the responses as per its heuristics.
How would you handle the following scenario: User opens video in one tab, creates another in which he or she looks up the Dow Jones index for the day. The video is still being displayed in the other tab. You have a head-of-line blocking issue. How do you deal with it?
That's incredibly contrived. You almost certainly wouldn't be serving videos from the same host as stock data so it would be a separate connection. Problem solved. You also probably wouldn't want the video streamed
Yes, it is enabled in production for Chrome for any site that advertises SPDY.
Google definitely does advertise SPDY compatibility, thus Chrome may speak SPDY when talking to Google pages.
Heya-- one of the SPDY developers here.
It doesn't cut page load time in half (it could, but you'd have to have a truly *terrible* site design). It does provide some pretty good latency decreases, however. I wish the OP had quoted more real numbers...
You've got it right, essentially. Server push puts a file into the cache which will be referenced by the page that is loading. I don't recall if Chrome still supports it, but at one point it most certainly did.
A single IP != a single server.
HTTP pipelining doesn't play well with proxies, and since you're never quite sure (on port 80) whether or not you're using a proxy, well, you end up with lots of fun heuristics about whether or not you can use it.
If you think that you're only limited by bandwidth, you should try taking the open-source SPDY implementation, modifying it, and then run an analysis of its behaviors over a similar dataset to the one we used (alexa-500). Data speaks volumes! Conjecture on its own isn't all that useful.
SCTP doesn't have enough flow control to make proxies safe or eliminate head-of-line blocking, good implementations don't exist on all platforms, and most damaging, it doesn't play well with IPv4 NAT. Not playing with IPv4 NAT is a killer.
SCTP was certainly one of the evaluated choices-- it had a lot of theoretically nice things going for it.
The protocol is documented externally, and the implementation is open source. We've begun talking with people at IETF about it and we have a public mailing list. I don' t know how it could be more open.
I'm one of the other people who works on SPDY.
server push: We have some debates about this internally, but it seems the market is deciding that push is important-- e.g. image inlining into the HTML. Server push allows you to accomplish the same, but gives the benefit of having them known as individual resources by a single name, and thus cacheable. I believe it may be particularly beneficial for people on high-rtt devices like mobile. If you look at data just about anywhere, you can see that RTT is the real killer. 100ms RTTs are fairly normal for mobile devices. I'd much rather have the server push that data to me rather than having to wait 100ms between each round of requests-- it can make literally seconds of difference for complex pages.
Why "SPDY": The name we first chose would have made money for the lawyers... and so we picked another.
performance measurement: In the whitepaper, as per my recollection, Chrome was the client for all of the measurements that we did.
"supposed" benefit+pipelining: HTTPs fault handling is terrible, actually. When you're sending a request and you don't receive the response, you don't know if the request was processed or not. This is particularly fun for non-idempotent transactions like say.. charging your credit card. SPDY includes mechanisms for telling the client (assuming the connection wasn't broken) that the server rejected the request, and thus disambiguating the situation. In such cases, the client knows that it is safe to retry. In any case, you're talking about doing http-pipelining plus response reordering. :)
How would you handle the following scenario: User opens video in one tab, creates another in which he or she looks up the Dow Jones index for the day. The video is still being displayed in the other tab. You have a head-of-line blocking issue. How do you deal with it? Canceling the video request is a poor choice-- the user likely will come back to it later. Waiting for the video to finish is a poor choice-- the user probably wants to see the Dow right now instead of 15 minutes later. Opening a new connection incurs additional cost in the network (NAT), on the servers and worse yet, incurs the latency penalty of a new connection setup plus whatever other protocols you're negotiating. I don't want to wait 2 RTTs before I get my content. I'm impatient. I want it now!
I'd suggest taking the open sourced code that we've provided and implementing your solution. You can then run the same battery of tests against your solution that we've done (in the lab) for SPDY. Data is extremely convincing when collected properly. If your solution worked better, then we'd have a basis for re-analysis.
Then, if you don't want an SMS, you install the application on your phone which requires zero access to the 'net.
Well, you can always choose to not do it. You get increased convenience that way, with the expected tradeoff...