“Design depends largely on constraints.” — Charles Eames
Friday, 15 January 2010
If you haven’t seen it already, check out the Call for Papers for the First International Workshop on RESTful Design (WS-REST 2010), where I’m on the program committee, along with many of the usual suspects.
Submissions due February 8, 2010, 23.59 Hawaii time. If only I were there to receive them…
this entry’s page ( 1 comment )
Wednesday, 16 December 2009
Australia has apparently decided, through its elected leaders, to filter its own Internet connection.
Since many, many other people are discussing whether this is advisable or indeed effective, I’ll focus here on what this will do to HTTP, and by extension the Web.
Reading the white paper, there are three different technologies for filtering the Web on the table;
Most of the ISPs that participated in the pilot chose the “pass-by hybrid” solution, for the very good reason that it doesn’t require an ISP to shove all of their traffic through a single box and hope it can keep up, thereby supporting claims that filtering won’t hurt Web performance.
However, if a site’s IP address is on the list, it does get sent to another box. Presumably, this is a box that acts as a pass-through filter or a proxy, so it inherits their problems for those sites. Given that some of those sites are likely to be YouTube, Flickr and so on, this isn’t just a corner case.
Pass-through filters need to be able to parse the entire request stream to pull out request-URIs and make a filtering decision. When they’re not blocking a URL and not overloaded, presumably they’ll perform adequately.
The interesting part comes when they do decide to block a URL. A simple implementation will presumably just block the HTTP response and splice in a canned, generic “blocked” one. However, that will break — sometimes spectacularly — a client that’s doing HTTP pipelining.
For example, if Alice and Bob are behind a corporate proxy which is pipelining away through a pass-through filter, and Alice makes a request to get blocked content, it can affect Bob’s request. Worse, if Bob requests a blocked URL after Alice does, a naive implementation could block Alice’s request.
The only way to properly block requests like this is to keep state about the request and the response around, so as to assure that you’re inserting the “blocked” response in the right place. In other words, you might as well be a proxy.
I will grant that pipelining isn’t widely used on the open Internet (although Opera does use it, and FireFox can be convinced to), but I can’t help but see the irony, given that it is one of the primary techniques for speeding up an HTTP connection — especially over long distances, which I hear we have in abundance down here.
Proxies, for better or worse, are a much more well-understood beast. Generally, you’re at the mercy of a proxy; if it decides to forbid certain HTTP methods (as is common), you can’t use them. If it doesn’t support Upgrade, Expect/Continue or chunked encoding, you won’t be able to use these HTTP features.
People don’t just use HTTP for browsing Web pages any more; it’s used for everything from desktop weather widgets to major system software updates to online gaming to document editing. People are also using HTTP in weird and wonderful ways to get things like Comet, BOSH and WebSockets happening.
By forcing ISPs to deploy middleboxes — without regard to protocol conformance or impact on these uses — we’re effectively profiling what people can do on the Web in Australia. This hurts the Web’s ability to grow and evolve, and it hurts Australia, by putting us at a competitive disadvantage to the rest of the world.
Furthermore, if “additional content” is filtered by ISPs, that means that — by the government’s own calculations — somewhere around 3% of HTTP requests will either get a non-standard error page, or mysteriously drop connections.
Think about that for a second; depending on how it’s calculated, you could easily be looking at several blank Web pages throughout your day, and sometimes your iPhone apps, your desktop widgets, your software updates just won’t work for some reason.
Companies like Google, Yahoo!, Amazon and Akamai spend lots of time and money making the Web go faster. While the white paper claims that filtering doesn’t slow the Web down in their tests, this ignores the opportunity cost that it introduces. Optimising YouTube, Flickr, GMail or any other performance-sensitive site is going to be much more difficult through a morass of content filters.
It’s true that Web sites already have to do with a multitude of proxies and other middleboxes on the open Internet anyway, but the difference is that if users don’t like what an ISP does to their packets, they can walk with their feet. There is no such option when the middlebox is mandated.
If the Government persists in mandating these filters (again, I’m just looking at the technical side here!), there are a few things that they can do to help, including:
Bad Gateway response with a descriptive header. This way, non-browser clients can detect when they’ve been blocked.One final thought. What will the Government’s reaction be once sites start deploying protocols like SPDY, which are going to be much less amenable to filtering, but much more powerful? Will we block them completely, thereby shutting ourselves off from the rest of the world?
this entry’s page ( 3 comments )
Friday, 13 November 2009
A couple of nights ago, I had a casual chat with Google’s Mike Belshe, who gave me a preview of how their “Let’s make the Web faster” effort looks at HTTP itself.
SPDY (nee FLIP) is an alternate application protocol that’s in Chromium, but buried so deeply that you have to enable it with a command-line option (—use-flip). AFAICT there aren’t even any public servers that support it yet, but it’s still a very exciting development.
Why? In a nutshell, it’s a binary, frame-based protocol for multiplexing bidirectional data streams over TCP (to start with). See flip_protocol.h for an idea of what it looks like, as well as the whitepaper.
HTTP-over-TCP has some pretty basic limits; most seriously, you can practically only have one request or response in flight on a connection at the same time.
Pipelining was designed to alleviate this, but at best it’s only a partial fix (head-of-line blocking is still an issue), and implementation problems means it’s almost unusable on the open Web (although Serf has had success in using pipelining in Subversion). It also can’t be used for methods like POST, which is important for interactive applications.
This drives people to use multiple, parallel TCP connections — something that we’ve accommodated in HTTPbis by lifting the two-connection limit for clients. However, that’s not a great solution either; TCP doesn’t allow you to share connection state between them, which brings problems when dealing with congestion.
These problems are well-known and have been discussed for years, all the way back to HTTP-NG, WebMUX and other efforts. More recently, Roy Fielding has been working behind the scenes on WAKA, with similar goals. So similar that I had to smile when Belshe explained what they were doing; it’s very similar to how Roy explains WAKA’s use of the transport.
However, I wouldn’t say that SPDY is competing with WAKA — yet. Belshe goes out of his way to point out that SPDY is more about doing real-world experimentation rather than saying “this is the protocol we’ll use.” In his words;
We're hoping to put theories to the test; while many of the ideas are not new, we're aggregating them, making them cooperate together, implementing them, and then measuring them. We hope that others will appreciate and expand this effort so that we can all evolve toward a protocol we think is universally better in a relatively quick timeframe.
In other words, they seem to be positioning this as input to the eventual design of HTTP/2.0, WAKA or whatever, rather than a browser-specific push to define a new protocol alone.
The other interesting aspect, of course, is the relationship to WebSockets, especially since there was a pretty strong sense in the IETF earlier this week in Hiroshima that a Working Group to standardise it should be started. if SPDY really does eventually follow the path of WAKA, it could be that some HTTP-like use cases that people have planned for WebSockets may have another outlet instead.
Finally, you might ask what bearing this has on our efforts in HTTPbis. Right now, the answer is “nothing”, in that we’re chartered explicitly NOT to create a new version of HTTP. However, I think that our work — especially in splitting up the spec (a decision driven by Roy a long time ago) — will help any eventual successor protocol, whether it be WAKA, SPDY, their child or something completely different.
That’s because the minimum bar to entry for replacing HTTP/1.1 is to exactly support its semantics and capabilities, while making it more efficient. The fact that all of the wire-level goop in HTTP is now moving to a single, separate document helps that.
The last thing that I’d mention is that when we started HTTPbis a couple of years ago, there was a strong sentiment against creating a new protocol, both because of the can of worms it would open, and because of deployment problems in doing so. However, I’ve recently heard many people complaining about the limitations of HTTP over TCP, and it seems that one way or another, we’re going to start tackling that problem soon.
this entry’s page ( 6 comments )
Friday, 30 October 2009
A long time ago*, the word in high-performance proxy-caching was Inktomi’s Traffic Server. It was so fast it was referred to being “carrier grade” and this could be said without people smirking, and it was deployed by the likes of AOL, when AOL was still how most people accessed the Internet.
Then, in 2001, Yahoo! bought Inktomi. They did this because they wanted to be a player in Search, and they happened to get a proxy/caching product for free. It promptly went on the shelf, to be forgotten by all (except the original engineers, a few customers, and the company that support was contracted out to).
A few years ago, some Yahoo! engineers found that code sitting on a shelf and decided to have a play. What they found was that it was still faster than pretty much every thing else out there. So they started using it, and built a team around it.
Fast forward to today, when the source code for Traffic Server is suddenly available as an Apache Incubator Project.
I’m sure you’ll be hearing more about it from its developers (I’m just a bystander, relatively), but from my point of view, this is only goodness; another general-purpose high-performance HTTP proxy/cache implementation is sorely needed, for reasons I’ve discussed before.
So take a look at the source, have a play with it, and come to the MeetUp at ApacheCon next week to see where this thing is going.
* Not a long, long time ago, when the word in proxy/caching was Harvest, the granddaddy of them all. But that’s another story.
Update: Leif (one of the core developers) gives his take.
this entry’s page ( 6 comments )
Monday, 19 October 2009
Dear Ms. Gillard,
I am a US citizen who moved back to Melbourne almost three years ago with my Australian wife. We did so largely because we wanted our sons to grow up in Australia and go to Australian schools.
So, it’s with quite a bit of interest that I read about your understanding with the US government regarding education. We did a fair amount of research about Australian schools, and are very confident that we enjoy some of the best schools in the world, in terms both of outcomes and overall experience.
Which leads me to a question — what, specifically, are you looking to emulate in the US education system?
Is it the systemic focus on results, leading all subjects that don’t impact standardised testing to be shunned? To the point where many schools don’t teach “wasteful” things like music, science and art [1]?
Or is it the fact that US teachers are chronically overworked, with more contact hours per year than any other country [2]?
Perhaps you’re interested in duplicating the disparity of education quality endemic in the US system, where a family is forced to live in a wealthy neighbourhood — with correspondingly high house prices — to get their children a decent education.
When I lived in Baltimore (just up the road from Washington D.C., where you met those slightly perplexed students) those children that bothered to show up to city schools were treated to crumbling, asbestos-riddled buildings and forced to share scarce and outdated textbooks with other students. Meanwhile, those who lived in the richer suburbs were treated to swimming programs, new athletic facilities and media centres full of computers.
More recently, California shows how America really works. Public schools there are dependent upon funding from “private education foundations.” In rich neighbourhoods, they’re able to raise thousands of dollars per student [3]; is this the future you want for Australia?
Or, perhaps you want to save money. In California, class sizes are approaching 50 students [4] and teachers are being asked to work without pay.
Of course, I know you don’t want these things for Australian schools. However, you must realise that the US education system is in a fundamentally different place than Australia’s, and therefore they need different solutions. Most US school districts would give anything to have the funding, facilities and staff that we do; their education system faces very large problems that we don’t suffer from, to the point where they don’t even know what direction to take next [5].
Following their lead is going backwards, not forwards. Please listen to your critics and look further afield.
Kind regards,
Mark Nottingham
1. New York Times, “Schools Cut Back Subjects to Push Reading and Math” 26 Mar, 2006
2. OECD, “Education at a Glance 2008”
3. Forum, “School Foundations” 30 Nov 2007
4. San Francisco Chronicle, “State’s schools feel squeeze of larger classes” 27 Sep 2009
5. San Francisco Chronicle, “Schools fail to meet No Child Left Behind goals” 22 Sept 2009