Slashdot Mirror
Varnish Author Suggests SPDY Should Be Viewed As a Prototype
An anonymous reader writes "The author of Varnish, Poul-Henning Kamp, has written an interesting critique of SPDY and the other draft protocols trying to become HTTP 2.0. He suggests none of the candidates make the cut. Quoting: 'Overall, I find the design approach taken in SPDY deeply flawed. For instance identifying the standardized HTTP headers, by a 4-byte length and textual name, and then applying a deflate compressor to save bandwidth is totally at odds with the job of HTTP routers which need to quickly extract the Host: header in order to route the traffic, preferably without committing extensive resources to each request. ... It is still unclear for me if or how SPDY can be used on TCP port 80 or if it will need a WKS allocation of its own, which would open a ton of issues with firewalling, filtering and proxying during deployment. (This is one of the things which makes it hard to avoid the feeling that SPDY really wants to do away with all the "middle-men") With my security-analyst hat on, I see a lot of DoS potential in the SPDY protocol, many ways in which the client can make the server expend resources, and foresee a lot of complexity in implementing the server side to mitigate and deflect malicious traffic.'"
Parsing a HTTP session with multi-part mime attachments using chunked encoding is murderous. Now true, many people don't have to worry about this, but the fact is the protocol leaks like a sieve. For instance, you can't send a header after you've entered the body of the HTTP session. You can't mix chunked-length encoded elements with fixed content-length elements with HTTP1.1. Once you've sent your headers and encoding, you're screwed. The web has a solution - AJAX, but then you need JavaScript.
I'd be all for something new. I'd suggest base it on XML with a header section and header-element to get the transfer started then accept any kind of structured data including additional header elements. With this, you can still use HTTP headers for back-wards compatibility, but once recognized as "HTTP 2.0" the structured XML can be used to set additional headers, etc. With the right rules, you can send chunks of files or headers in any arbitrary order and have them reconstructed.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
TFA is talking about in reverse proxies (of which Varnish is one of many), which are very commonplace. In fact, you're seeing this page through (at least) one, as Slashdot uses Varnish.
Game! - Where the stick is mightier than the sword!
TFA is talking about in reverse proxies (of which Varnish is one of many), which are very commonplace. In fact, you're seeing this page through (at least) one, as Slashdot uses Varnish.
Publicly cached data is outside SPDY's use-case. It is aimed at reducing latency, and its main target is rich "web application" pages. Now it may well be possible to design a protocol that supports caching as well as reduced latency, but this is not what SPDY was designed to do.
Much of what the web has become is no longer fitting the "fetch a document" model that HTTP (and GOPHER before it) are designed to do. This is why we have hacks like cookie managed sessions. We are effectively treating the document as a fat UDP datagram. The replacement ... and I do mean replacement, for HTTP, should integrate the session management with it, among other things. The replacement needs to hold the TCP connection (or better, the SCTP session), in place as a matter of course, integrated into the design, instead of patched around as HTTP does now. With SCTP, each stream can manage its own start and end, with a simpler encryption startup based on encrypted session management on stream 0. Then you can have multiple streams for a variety of serviced functions from nailed up streams for continuous audio/video, to streams used on the fly for document fetch. No chunking is needed since it's all done in SCTP.
now we need to go OSS in diesel cars
Then it cannot replace HTTP and should be withdrawn, or it's been wrongfully sorted in under "HTTP/2.0 Proposals"
By the time a replacement of HTTP 2 is standardized, XP will be fully out of support. I get flamed whenever I say this, but it will be time to let XP die. I'm considering replacing my grandmother's box with an ASUS Transformer, as that'll handle all of her needs. (*And* the rest of my family won't say 'we don't know how to reboot the router because we don't know how to use the Linux netbook you set her up with.) Quickbooks runs on Vista and Win7. Tools and other things which require Windows XP are becoming scarcer, and workarounds and alternatives are becoming cheaper.
Eventually, XP will be like that DOS box that sits in some shops...used only for some specific, very limited purposes. Any shop cheaping out and still using it in lab environments (such as call centers) can work around it by installing a global self-signed cert and using a proxy server to rewrap SSL and TLS connections. Yes, this is bad behavior. So is continuing to use XP. At some point, the rest of Internet needs to move on.
tasks(723) drafts(105) languages(484) examples(29106)
As a static data format its just about passable, but as a low overhead network protocol??
Wtf have you been smoking??
But that is something you need to support as long as multiple domains are hosted on the same IP address. Lots of things gets easier if you can have a separate IP address for each domain you want to host. But there has been a shortage of IP addresses.
However there is a solution. You just have to move to IPv6, then you will no longer have a shortage on IP addresses. So what if some people find themselves in a situation where they cannot deploy SPDY on IPv4 (because of limitations in their proxies)? I don't see how that is a bad thing. They can keep using plain HTTP for IPv4 users and SPDY for IPv6 users, where there is no need to host multiple domains on a single IP address.
You might think it is a problem to have this difference between the IPv4 deployment and the IPv6 deployment. It is not a problem, it is a little bit of extra work, but any transitioning is a little bit of extra work. For any domain where you want to have dual stack support, you have to host the IPv4 and IPv6 version of the site on different IP addresses (that's sort of obvious, but needs to be pointed out to make the rest of the argumentation clearer). You can make your two (or more) domains resolve to the same IPv4 address, which is your HTTP proxy, additionally you can make the domains resolve to different IPv6 addresses, which are routed either directly to webservers or through some loadbalancer. You don't need to ever route the IPv6 addresses to the HTTP proxy, it can be routed to a load balancer that only knows TCP and none of the higher levels.
IPv4 support doesn't have to be a design goal in a new protocol designed today. Before a new standard can be agreed upon another continent or two will have run out of IPv4 addresses. There may still be other arguments against SPDY.
Do you care about the security of your wireless mouse?
"If someone proposed HTTP today, it wouldn't pass muster by these experts either."
And with good reason. Berners-Lee might have invented the web as we know it but like all first attempts (yes I know about hypercard and all the rest , they weren't networked!) it could really do with some serious improvement. Unfortunately the best solution would be to bin it and start again but its way to late for that so its make do and mend which almost always ends up in a total mess. Which is we what we have today.
That's what you get when someone designs a protocol and then someone ELSE decides to change it in different ways of thinking. If the first one was well designed, changes should end up looking like they were part of the original. If the first one was poorly designed, make a whole new one.
now we need to go OSS in diesel cars
If you think home ISPs haven't been scrambling to catch up on IPv6, you haven't been paying attention! Comcast is rolling it out right now. DSL providers are deploying 6rd. Mobile providers are deploying. Within a year, most end-users (in the US) will have access to IPv6 from their ISP. Within two years, most end-users will have replaced their non-IPv6 CPEs with ones which support IPv6. But IPv6 isn't the only solution to the problem, either.
Right now, most small website operators should avoid TLS if they only have static content. Otherwise, they need to make a decision between supporting XP and shelling out for a dedicated IP. Me, I'd probably drop support for XP, and let the end-user click through a cert warning if that's what they're inclined to do.
How much more per month are we talking about for a dedicated IP, anyway? I know how you'd set up joe random guy with a dedicated IPv4 address using a proxy server on a $5-7/mo VPS. Seems cheap to me, especially compared to what joe already spent to get a valid SSL cert.
As far as Android...a number of websites are pushing their users to use simple apps instead of the Android browser. As a user, this annoys me, as my LG-509 doesn't have much space unless I root it and clean it...but I can see how it offers a better interface to the server, and how it changes authentication and connectivity concerns.
tasks(723) drafts(105) languages(484) examples(29106)
I'd suggest base it on XML with a header section and header-element to get the transfer started then accept any kind of structured data including additional header elements.
Haven't we learned enough already from industrial pain to stay away from XML? JSON, BSON, YAML, compact RELAX NG, ASN.1, extended Backus-Naur Form. Any one of them, or something inspired by any (or all) of them, that is compact, unambiguos (there should be only one canonical form to encode a type), not necesarily readable, possibly binary, but efficiently easy to dump into an equally compact readable form. Compact and easy to parse/encode, with the lowest overhead possible. That's what one should look for.
But XML, no, no, no, for Christ's sake, no. XML was cool when we didn't know any better and we wanted to express everything as a document... oh, and the more verbose and readable, the better!!(10+1). We really didn't think it through that much back then. Let's not commit the same folly again, please.
The flipside of this is that a lot of the proposals to replace HTTP suffer badly from the second system effect, where the protocol designer decides to add proper support for all of the edge cases and ends up with a protocol that is gigantic and difficult to implement.
I read the internet for the articles.
I was the member of the IETF committee that proposed the standard (while working for Microsoft), and I agree its not very good but I can tell you that getting standards through various bodies is more politics than technology. Late in the cycle we tried to change it to XML but people thought we (MS) were playing mind games with the committee so the idea was abandoned
when your page is important, the user will use a browser which is supported.
Imagine google only working with sni. How long will it take until no one uses IE8 anymore? Only a few days, and even the dumbest has found a friend who can download him a real browser.
SPDY is encrypted by design. There is no option for middle-men, and frankly, that is the way I like it myself, as i would assume most people. I don't like when devices mess with my traffic.
As for most of the other complaints - given than Google is running SPDY just fine on all of it's servers, and they're basically one of the largest (if not the largest) hosts on the internet, I think they are all strawmen. If it is working for Google then it will work for others.
My experience using SPDY, as a user, is nothing short of spectacular. The performance gains in on Google properties with SPDY are incredible and very noticeable.
Conspiracy minded folks would think that SPDY is mainly about Google being able to ensure that advertisements are served before the content. Putting it inside of SSL also ensures that any intermediate carriers won't be stripping Google's adverts.
Translation: SSL libraries are big and scary, SSL is big and confusing and I have no idea what the hell it does so it's bad.
Actually, the better argument I've heard is that it OpenSSL is very poorly documented. And I've heard this complaint from numerous people...to the point where some even started looking into fresh implementations.
tasks(723) drafts(105) languages(484) examples(29106)
I have heard the complaint from numerous folks that SSL libraries really are a mess, which is why periodically we get nasty vulnerabilities in them; supposedly, auditing the code is an exercise in futility.
Conspiracy minded folks would think that SPDY is mainly about Google being able to ensure that advertisements are served before the content. Putting it inside of SSL also ensures that any intermediate carriers won't be stripping Google's adverts.
It also improves user's privacy by preventing personal content from being read by ISPs, proxies, and other men-in-the-middle. If any other web site turned on SSL, we would thank them for choosing to improve user's privacy. But this is Google, so it must be a bad thing.
Google turned on SSL for search a month before they launched personalized search, where the search results can include things only the logged-in user has permission to see (if the user logs in and enables it). If they had not enabled SSL, people would (rightly) be upset that any man in the middle could see photos, documents, and G+ posts shared only with you.
If you punish companies for doing the right thing, expect them to stop. Every company has people for and against any idea. When you punish good behavior, the people who fight for it will not win the argument next time.
I have never once seen documentation written in English that didn't leave something important unclear.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.