Google's SPDY On Its Way To Standardization
Mark Nottingham, chairman of the IETF HTTPBIS Working Group and W3C Web Services Addressing Working Group has published a rather interesting post to the HTTPBIS mailing list, which suggests that Google's SPDY could be elevated to become a standard.
The HTTPBIS Working Group intends to release an Internet draft of HTTP 2.0 by May of this year and provide a proposal for standardization until July 2013.
Part of that proposal may be at very least a partial integration of Google's SPDY, a technology that was designed to overcome some of the performance shortcomings of HTTP, which was first documented in 1995. Both TCP and HTTP are considered bottlenecks for data downloads today as Internet users have moved well beyond the simple text content HTTP was developed for. HTTP has been questioned because of its latency issues as the protocol can only fetch one resource at a time and servers cannot communicate with a client without a client request. HTTP also uses uncompressed and redundant request and response headers, which are sources for latency. SPDY still uses TCP as the underlying transport layer, but addresses some of the latency problems in HTTP.
SPDY creates room for unlimited connection streams, can prioritize and even block requests if a communication channel gets overloaded and supports header compression. SPDY also allows the server to communicate with a client without a client request. Google, which pioneered SPDY and has been supporting the technology on all of its sites and via its Chrome browser, explained that SPDY uses HTTP methods, headers and “other semantics.” However, the connection management and data transfer formats are modified to achieve up to 60 percent acceleration in page load times, especially on devices with slower Internet connections. Chrome users can monitor SPDY connections via the local URL type chrome://net-internals/#spdy in their browser.
Nottingham wrote that a second browser (Firefox) has integrated SPDY and his communication with "folks" suggested that "the time is ripe to start work on a new version of HTTP in the IETF". Google added a somewhat related, but separate idea to speed up TCP. Developer Yuchung Cheng posted a few thoughts how TCP could be improved, including an increase of the TCP congestion window, a reduction of the TCP timeout, the use of TCP Fast Open and the use of proportional rate reduction for TCP. Cheng said that Google will be posting details how to make TCP faster in the near future.
- NASA Releases Amazing 64-MP 8000x8000 Photo of Earth
- Xbox 720 Won't Play Used Games; Wii U Better Than X360
- Foxconn Worker Says iPhone 5 Arrives This June
- Apple Sees No Threat in Kindle Fire, $200 Tablets
- USPTO: Prior User Rights Essential to Support Innovation
- Pandora Open-Source Netbook/Console Arrives Next Month
- Google Privacy Policy Will Track Users Across All Products
- Facebook is Mass Surveillance, Says Free Software Founder
- Pirate Bay to Offer Downloads of Real, Physical Items
- Nintendo Confirms Wii U is Coming Holiday 2012 Amid Loss
- Amazon Looking to Take on Netflix with Streaming Service
- AT&T Rules the iPhone With 20% of Global Sales Pie
- Xbox 360 Controller Mod Dispenses Hot Pockets
- Hands On: Steam App for Android, iOS Closed Beta
- Tagg Tracks Your Pet With GPS, Charges Monthly
- Is Xbox Live Coming To Android Too?
- This is the World's Largest Video Game Controller
- Using a Tablet Can be a Pain in the Neck, Literally
- Twitter Talks #Censorship, Google Talks +Teens
The time is right to start work on a new version of HTTP?
Better late than never though, as they say. Thanks, Google, for putting strong effort into advancing internet protocols.
I suggest the time was right several years ago, it's way past time now.
They should propose something like compressing TCP packets at hardware level (Ethernet). It will reduce packets count and communication will happen a lot faster.
Basically they should make HTTP binary altogether. I'm not talking about encryption, it's a different thing altogether. CSS for bigger sites can be as big as 100kb. But in binary format It won't become bigger than a few kbs.
SPDY? OMG. If you remove the "D" it becomes SPY!!! What does this mean??? It's a conspiracy.
I'm curious as to how my firewall rules will need to change. Obviously the port will be easy, but with servers initiating requests? Would this still fall into a stateful connection? Of course it sounds like they would be changing the whole stateless connection setup that's in place now. I for one do not want random servers initiating communication with systems in my LAN. But since I'm not the protocol expert, I'm sure the folks at Google are already on this.
@zakaron : I'm curious as to how my firewall rules will need to change.
they won't. SPDY generally takes place inside SSL on port 443 with all TCP connections initiated by the browser - just like you're used to with HTTP/1. When SPDY talks about server-push that means the ability of the server to initiate the transfer of sub-resources on an already existing TCP connection without being asked. (i.e. a.html includes b.png as a subresource, so when the client asks for a.html the server also starts sending b.png so we don't have to wait for the client to actually receive the html, parse it, and send the request for b.png over the network).
@mcmanus: What you describe sounds kind of like multi-part MIME. One "document" can contain multiple files within it - in this case a.html and b.png.
I have questions about how much attention Google might have given to client system security when they designed SPDY. Most engineers think of secuirty as an afterthought - which is how we got into the current internet / virus / malware mess we're in. I'd like to think that Google did differntly, but I have a hard time relying on that.
I got SPDY confused with SPYW and was terrified for a moment!
I wonder if the project's codename was "Gonzales" during development?
Wouldn't this also cause problems with data useage? If you go to site a.html and the server then pushes all related content to the client, you're then using transfer data. but say you never go any deeper than a.html, you've downloaded data that you'll never digest and is therefore wasted data usage possibly pushing you past your limit eventually. yes/no?
@akoegle - you can only push subresources (i.e. the push is tied to an existing request) - so the potential is limited. you can't just push all the files on the website hoping to seed the client's cache. (well, you can push them but the client won't use them outside of the scope of the original resource they were associated with). The client can also rst or zero-window as soon as it starts seeing data, so potential wastage is bounded (but not 0) there as well. Biggest issue is getting pushed stuff that is already cached or interferes with other stuff wanted at a higher priority; those are important and unresolved details but they shouldn't be the headline.
@teramedia - kinda like multipart, yes. but each resource has its own stream and uri so it can be addressed/reused/cached independently, as well as rejected indpendently, downloaded at different rate, etc..