Re:True for JAVA, but not generally true...
on
Java IO Faster Than NIO
·
· Score: 4, Interesting
Unfortunately, nothing I can publish without permission. I can say that I'm in charge of maintaining the software that terminates all HTTP traffic for Google. Draw your own conclusions.
True for JAVA, but not generally true...
on
Java IO Faster Than NIO
·
· Score: 4, Interesting
This may be true for Java. It isn't true for C/C++.
With C/C++ and NPTL, the many-thread blocking IO style yields slightly lower latency at low IO rates, but offers significant latency variability and sharply decreased thruput at higher IO rates. It seems that the linux scheduler is much to blame for this-- the number of times that a thread is scheduled on a different CPU increases dramatically with more threads, and this trashes the caches. I've seen order-of-magnitude decreases in performance and order-of-magnitude increases in latency as a result of what appears to be the cache trashing.
So long as ONE character set is required, then it works. It was the latin charset, it may as well have stayed that. Now, we'll have places where you simply cannot type in the domain name. Hurrah for allowing china's censors another easy way to cut off access to anything else!
Note that this isn't always true. There are extensions (implemented my many browsers) in TLS which allow it to tell the server which host the connection is intended to be for in the handshake. I don't believe that IE implements this, but it could only be IE6. I forget.
This is important, since we're running out of IPs and people do want to use virtual hosting in the same manner that they do for HTTP-- symmetry is easy to maintain!
They are attempting to add it to Chromium and get it into HTTP servers.
http://dev.chromium.org/spdy
There is a link to the code somewhere there. If not, just search the chromium repo as that is where it lives.
It is open and you can play with it too. There is also an Apache mod for it, I believe, though I haven't searched for that lately. More numbers and studies are available there.
In this case you need to put a root cert on the school's computers, and do a MITM for SSL. SSL doesn't mean no MITM. It means no *unauthorized* MITM...
If it is logical to kill anyone who speaks against you because you can get away with it (and the outcome is more beneficial to you, you believe), then it is reasonable to kill people for speaking out against you?
logic != ethical.
All of the logical arguments that show that our ethics have evolved don't apply in this case. When we create systems where one entity has nearly absolute power we've thrown our millions of years of evolution out the window and face extinction. This would be one logical outcome-- nature will evolve to adapt to that people's future non-existence...
The road to hell is also paved with standing by and doing nothing when they take your freedom away from you. If the companies have say over what does and doesn't go over their network, what do you think they're gonna do? They'll happily let customers gab about how they such? Ha, right. How about letting their customers offer a competing service? Ha. What about letting anyone else offer a competing service? Uh no.
Look, sometimes government is there for a good reason. It is *HARD* to go and get rights to lay cable, not even counting the expense of doing it. Look at the companies that have been suing local gov'ts when they've been laying their own cable (and *WINNING* the argument, if not the case, by out-spending the local gov'ts).
No, unfortunately, I actually know what I'm talking about while you're being irrational and insulting. The analogy was an attempt to get you to understand the loadbalancing problem, which I'd really like for you to understand.
Ann Eschoo represents much of Silicon Valley. I'm pretty dang happy with most of what she does. I wish there were more Reps out there like her (maybe one day she can be Senator... that'd be great)!
In SPDY, the client always is the thing that defines the priority of the fetch, with PUSH data being low-priority unless the client has defined it otherwise.
When we implement flow control, we also want to have the client indicate how best to ratelimit data sent to it. This is so that if the client is making more than one connection (still likely to happen if resources are fetched from a different IP), then it needs to be able to tell one host to slow down so that it is always getting the highest priority data from either connection.
A very nice side effect of this is that you can get high priority data and tell the low priority data to fsck off before it uses too much of your bandwidth (or any, depending on your set limits).
This allows the clients to choose what cost/speed tradeoff they want.. and really, that is where the tradeoff MUST be decided because only the client has that data.
As for servers pushing ads.. Servers are going to do what they're going to do. If the server is going to not pay attention to the protocol spec, or what the user wants.. don't browse that site! As protocol writers, we don't have control over what people do (unless they use our reference implementation!).. We only have control over saying what they should be doing. In today's world a server implementor can stick the ads/images/flash, whatever inline, in which case you have no ability to say no. With SPDY depending on how well they adhere to the spec, either it only gets better, or it is the same.
Well, I don't really know how to answer that. As with any protocol design, we want to provide mechanisms that are as generic as possible while attaining our goal.
In this case, we've talked about having 'priority' groups, which have flow control settings on their own. If the application chooses to assign a priority (which potentially could be exposed via javascript or tags eventually?) then the application in the webbrowser has control over it. This is probably as it should be-- your extensions would do whatever they want to these things anyway...
I can understand that One of the proposals was that the HELLO message indicates how much bandwidth the user wants the server to use for 'speculative' purposes. Hopefully we'd figure out how to auto-tune based on connection parameters (e.g. if the browser tells us it is a phone), and so the user wouldn't have to set any defaults that would hurt in other cases.
IE didn't for javascript some time ago, certain mobile browsers and built-in browsers in various appliances don't (though the may advertise it) as well.
Nope-- we've seen 65% latency reduction without SSL, and 55% with. In other words, SSL doesn't hurt us that much. For HTTPS, it is much worse, since you have to make more connections and deal with setting up the connection that many more times.
I work with some of the OpenSSL maintainers, and we've figured out a way of advertising protocol support (whether it be SPDY, YGNDMA, WHTSTHISNEWPROTO, whatever:) ).
During the SSL handshake, a string is sent which includes the protocols that the server/client would like to advertise. This is *during* the handshake, not after it. It isn't a large amount of data, and thus you don't incur an extra RTT or any other latency penalty. SSL implementations which don't expose this field would just ignore it.
If after the handshake, a side that supports SPDY (or whatever), sees that the other side also supports it, then it can use that protocol instead of HTTP over SSL.
So, what we're proposing is 100% compatible with the way things work today-- it shouldn't break anything at all. If it isn't true, then we simply wouldn't do it that way. Using another port isn't a good idea, incidentally. In addition to the fact that many personal NAT/firewall/routers will filter out strange new ports, and given that asking everyone to upgrade either the settings or the hardware is essentially impossible... we're stuck. Even if we're successful at using a new port (imagine that the rest of the problems go away), there is still the problem that we have to continue to support HTTP/HTTPS indefinitely. Many sites will continue to exist only with HTTP/HTTPS. For those sites, attempting a new connection on a different port may not be great. You can use some interesting heuristic, but you'll always get into a race, even if the site supports all the protocols..
Huh? The protocol uses significantly less bandwidth for the same content (thanks to compressing the headers). Surprisingly, compressing the headers makes a big difference.
The server can push the content to you using SPDY, but the client can close that stream (not the connection, so you still get the data you really want). In other words, the server will not push a terribly large amount of data before your browser can kill it with a FIN message. (It is 1-RTTs worth if the server is doing things according to spec).
Plus, since the priority of server pushed data is low (lowest) any request will immediately pre-empty any pushing that the server is doing.
Also note that just because the server pushes info, doesn't mean that the browser has to use it. It may simply put it into the cache to be used "in the future".. this is essentially how it works in the hacked-up chrome that we have today.
All of your adblockers, etc. should continue to function.:)
It is an application-layer protocol. It is on top of TCP/IP, not a replacement for TCP/IP. The reason it is 'between' HTTP and TCP is that the web/javascript authors see the same interface that they had before (requests, responses, headers, cookies,etc) with HTTP... but the representation on the wire has changed.
Yup. They're pretty big (cookies can be HUGE!) Take a look here: http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper
"Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request header compression in particular, led to significant page load time improvements for certain sites (i.e. those that issued large number of resource requests). We found a reduction of 45 - 1142 ms in page load time simply due to header compression."
Slashdot Mirror
In that case you install the application on your phone instead. The app requires no net access at all-- it just generates a code.
I love slashdot!! :)
Unfortunately, nothing I can publish without permission.
I can say that I'm in charge of maintaining the software that terminates all HTTP traffic for Google. Draw your own conclusions.
This may be true for Java.
It isn't true for C/C++.
With C/C++ and NPTL, the many-thread blocking IO style yields slightly lower latency at low IO rates, but offers significant latency variability and sharply decreased thruput at higher IO rates.
It seems that the linux scheduler is much to blame for this-- the number of times that a thread is scheduled on a different CPU increases dramatically with more threads, and this trashes the caches.
I've seen order-of-magnitude decreases in performance and order-of-magnitude increases in latency as a result of what appears to be the cache trashing.
So long as ONE character set is required, then it works.
It was the latin charset, it may as well have stayed that.
Now, we'll have places where you simply cannot type in the domain name. Hurrah for allowing china's censors another easy way to cut off access to anything else!
Note that this isn't always true.
There are extensions (implemented my many browsers) in TLS which allow it to tell the server which host the connection is intended to be for in the handshake.
I don't believe that IE implements this, but it could only be IE6. I forget.
This is important, since we're running out of IPs and people do want to use virtual hosting in the same manner that they do for HTTP-- symmetry is easy to maintain!
They are attempting to add it to Chromium and get it into HTTP servers.
http://dev.chromium.org/spdy
There is a link to the code somewhere there. If not, just search the chromium repo as that is where it lives.
It is open and you can play with it too. There is also an Apache mod for it, I believe, though I haven't searched for that lately.
More numbers and studies are available there.
disclosure: I'm one of the SPDY authors
In this case you need to put a root cert on the school's computers, and do a MITM for SSL.
SSL doesn't mean no MITM. It means no *unauthorized* MITM...
If it is logical to kill anyone who speaks against you because you can get away with it (and the outcome is more beneficial to you, you believe), then it is reasonable to kill people for speaking out against you?
logic != ethical.
All of the logical arguments that show that our ethics have evolved don't apply in this case. When we create systems where one entity has nearly absolute power we've thrown our millions of years of evolution out the window and face extinction. This would be one logical outcome-- nature will evolve to adapt to that people's future non-existence...
Anyway... your point is absurd :)
The road to hell is also paved with standing by and doing nothing when they take your freedom away from you. If the companies have say over what does and doesn't go over their network, what do you think they're gonna do? They'll happily let customers gab about how they such? Ha, right. How about letting their customers offer a competing service? Ha. What about letting anyone else offer a competing service? Uh no.
Look, sometimes government is there for a good reason. It is *HARD* to go and get rights to lay cable, not even counting the expense of doing it. Look at the companies that have been suing local gov'ts when they've been laying their own cable (and *WINNING* the argument, if not the case, by out-spending the local gov'ts).
Pull your head out of the sand and look around.
No, unfortunately, I actually know what I'm talking about while you're being irrational and insulting.
The analogy was an attempt to get you to understand the loadbalancing problem, which I'd really like for you to understand.
If I sign a contract with Johnny, and Johnny signs a contract with Mike to do something to me, that still doesn't make it legal to do something to me.
Ann Eschoo represents much of Silicon Valley.
I'm pretty dang happy with most of what she does. I wish there were more Reps out there like her (maybe one day she can be Senator... that'd be great)!
In SPDY, the client always is the thing that defines the priority of the fetch, with PUSH data being low-priority unless the client has defined it otherwise.
When we implement flow control, we also want to have the client indicate how best to ratelimit data sent to it. This is so that if the client is making more than one connection (still likely to happen if resources are fetched from a different IP), then it needs to be able to tell one host to slow down so that it is always getting the highest priority data from either connection.
A very nice side effect of this is that you can get high priority data and tell the low priority data to fsck off before it uses too much of your bandwidth (or any, depending on your set limits).
This allows the clients to choose what cost/speed tradeoff they want.. and really, that is where the tradeoff MUST be decided because only the client has that data.
As for servers pushing ads.. Servers are going to do what they're going to do. If the server is going to not pay attention to the protocol spec, or what the user wants.. don't browse that site! As protocol writers, we don't have control over what people do (unless they use our reference implementation!).. We only have control over saying what they should be doing.
In today's world a server implementor can stick the ads/images/flash, whatever inline, in which case you have no ability to say no. With SPDY depending on how well they adhere to the spec, either it only gets better, or it is the same.
No- the protocol has nothing to do with proxying.
Well, I don't really know how to answer that. As with any protocol design, we want to provide mechanisms that are as generic as possible while attaining our goal.
In this case, we've talked about having 'priority' groups, which have flow control settings on their own. If the application chooses to assign a priority (which potentially could be exposed via javascript or tags eventually?) then the application in the webbrowser has control over it. This is probably as it should be-- your extensions would do whatever they want to these things anyway...
I can understand that
One of the proposals was that the HELLO message indicates how much bandwidth the user wants the server to use for 'speculative' purposes.
Hopefully we'd figure out how to auto-tune based on connection parameters (e.g. if the browser tells us it is a phone), and so the user wouldn't have to set any defaults that would hurt in other cases.
IE didn't for javascript some time ago, certain mobile browsers and built-in browsers in various appliances don't (though the may advertise it) as well.
Nope-- we've seen 65% latency reduction without SSL, and 55% with. In other words, SSL doesn't hurt us that much. For HTTPS, it is much worse, since you have to make more connections and deal with setting up the connection that many more times.
I work with some of the OpenSSL maintainers, and we've figured out a way of advertising protocol support (whether it be SPDY, YGNDMA, WHTSTHISNEWPROTO, whatever :) ).
During the SSL handshake, a string is sent which includes the protocols that the server/client would like to advertise. This is *during* the handshake, not after it. It isn't a large amount of data, and thus you don't incur an extra RTT or any other latency penalty. SSL implementations which don't expose this field would just ignore it.
If after the handshake, a side that supports SPDY (or whatever), sees that the other side also supports it, then it can use that protocol instead of HTTP over SSL.
So, what we're proposing is 100% compatible with the way things work today-- it shouldn't break anything at all. If it isn't true, then we simply wouldn't do it that way.
Using another port isn't a good idea, incidentally. In addition to the fact that many personal NAT/firewall/routers will filter out strange new ports, and given that asking everyone to upgrade either the settings or the hardware is essentially impossible... we're stuck.
Even if we're successful at using a new port (imagine that the rest of the problems go away), there is still the problem that we have to continue to support HTTP/HTTPS indefinitely. Many sites will continue to exist only with HTTP/HTTPS. For those sites, attempting a new connection on a different port may not be great. You can use some interesting heuristic, but you'll always get into a race, even if the site supports all the protocols..
Huh? The protocol uses significantly less bandwidth for the same content (thanks to compressing the headers).
Surprisingly, compressing the headers makes a big difference.
The server can push the content to you using SPDY, but the client can close that stream (not the connection, so you still get the data you really want).
In other words, the server will not push a terribly large amount of data before your browser can kill it with a FIN message. (It is 1-RTTs worth if the server is doing things according to spec).
Plus, since the priority of server pushed data is low (lowest) any request will immediately pre-empty any pushing that the server is doing.
Also note that just because the server pushes info, doesn't mean that the browser has to use it. It may simply put it into the cache to be used "in the future".. this is essentially how it works in the hacked-up chrome that we have today.
All of your adblockers, etc. should continue to function. :)
It is an application-layer protocol. It is on top of TCP/IP, not a replacement for TCP/IP.
The reason it is 'between' HTTP and TCP is that the web/javascript authors see the same interface that they had before (requests, responses, headers, cookies,etc) with HTTP... but the representation on the wire has changed.
Yea, sorry about that-- I tend to represent my thoughts with lots of parenthesis. :)
Yup. They're pretty big (cookies can be HUGE!)
Take a look here:
http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper
"Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request header compression in particular, led to significant page load time improvements for certain sites (i.e. those that issued large number of resource requests). We found a reduction of 45 - 1142 ms in page load time simply due to header compression."