Google's SPDY Could Be Incorporated Into Next-Gen HTTP 275
MojoKid writes "Google's efforts to improve Internet efficiency through the development of the SPDY (pronounced 'speedy') protocol got a major boost today when the chairman of the HTTP Working Group (HTTPbis), Mark Nottingham, called for it to be included in the HTTP 2.0 standard. SPDY is a protocol that's already used to a certain degree online; formal incorporation into the next-generation standard would improve its chances of being generally adopted. SPDY's goal is to reduce web page load times through the use of header compression, packet prioritization, and multiplexing (combining multiple requests into a single connection). By default, a web browser opens an individual connection for each and every page request, which can lead to tremendous inefficiencies."
Re:What about pipelining and keep-alive? (Score:5, Informative)
When pipelining first came out, there were many buggy implementations. As a result, many browsers and web servers disabled the feature. Maybe it's time to turn it on for everything.
Re:What about pipelining and keep-alive? (Score:5, Informative)
Re:What about pipelining and keep-alive? (Score:5, Informative)
Re:What about pipelining and keep-alive? (Score:5, Informative)
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
It'd be a faster still without all the redirects (Score:2, Informative)
Says it all. The connection setup isn't the problem, it's being bounced to 10 different sites other than the one you wanted to visit, half of which are overloaded at any given time.
Fix that instead Google and there's no need to mess with the standards anyway.
Re:What above the layer below? (Score:5, Informative)
That's a really poor way of describing SCTP. Firstly the relationship between TCP and UDP is such that TCP could be built entirely ontop of UDP, the only reason it isn't physically is so that the port numbers for UDP and TCP are distinct. On the other side the best description of UDP is actually "Bare IP packets with port numbers".
SCTP is not that, it would probably be most accurate to describe it as being a protocol with multiple TCP streams in both directions within one connection. Because it's within a single connection a 'stream' can be very small (ie a little message) and still be efficient and because there are multiple streams messages don't have to wait for each other; though they can if you want. It is probably simpler that TCP, but only because TCP has had so much bolted on.
But you are absolutely correct, this would be a very good protocol for throwing a load of tiny requests at a web server and getting the results back as soon as they're ready. BUT, mixing it with SSL would not be very simple, I guess you'd have to do what OpenVPN does.
Re:Adds bufferbloat and reduces VoIP sound quality (Score:5, Informative)
By increasing the initial window size from 3 to 10 they add to the bufferbloat effect (at the microscopic level) and increase Jitter from tolerable 38 ms to intolerable 126 ms on a 1 Mbit/s ADSL line.
I can't really see how increasing the window size would increase jitter. Network bandwidth aside, the throughput of a TCP connection is a function of latency and window size. Increasing the window size simply increases the throughput on high-latency networks.
You're still limited to MTU-size packets (probably 1500 octets), and if you're using a priority queuing discipline this gives you a network jitter of about 12ms on a 1Mbps connection: (1500*8)/1000000 = 0.012 since the priority queue will insert the small high priority RTP packets between the large low priority packets.
When you improve the performance of your application, you should think about how it degrades the performance of other applications. If someone recommended increasing the O/S priority level of the web browser to the maximum, so all your other applications slowed down to a halt while the web browser was running, you would probably object. The increased initial window size is a comparable recommendation, but at a network buffering level, so very few people understand its negative side effects.
Increasing the window size is not comparable to increasing the priority of the traffic. I would agree with you if the application were setting the ToS flags(*) in an abusive way, but the window size just affects the maximum throughput for a connection given a specific latency connection. Given that latency isn't something generally very controllable, this can't even be regarded as an effective method of intentionally throttling throughput (shaping the traffic on the router would be more sensible here).
(* routers out on the internet won't generally pay attention to ToS flags, so setting them abusively wouldn't normally give you any advantage anyway. However, routers at the ends of low bandwidth links, such as ADSL, should be paying attention to ToS flags in order to prioritise latency-sensitive protocols. If you're not doing this and just relying on FIFO queuing then you're pretty much screwed already for VoIP unless you're using the connection for nothing else).
Re:What about pipelining and keep-alive? (Score:5, Informative)
Yes, the layer-4 protocol still requires in-order delivery. But lost packets is not the sort of problem SPDY is trying to solve. SCTP might also be a good idea, but you'd still want SPDY on top of it instead of HTTP because it's faster even assuming perfect, in-order packet arrival.
But SPDY adds encapsulation within the TCP stream so data frames from multiple SPDY streams can be interleaved. It's like opening a bunch of separate TCP streams (like browser do now) but with a lot less overhead. It's also less complicated to implement than HTTP pipelining because each request/response gets its own SPDY stream so the underlying HTTP server can treat them as fully independent connections.
Using with HTTP, even with pipelining, the server must respond to requests in the order they are received. So if you request something slow -- say a DB query -- and then a bunch of static images, HTTP will have to wait for the slow request, send that response, and then send the images. Using SPDY each request creates a new SPDY stream, and the server can send back responses in each stream without respect for the order in which they arrived. So in the same slow-DB + static images scenario SPDY would be able to immediately start sending back images and then send back the DB response when it was ready. SPDY could even start sending images, and when it sees that the DB response is half-ready and has a higher priority, interrupt the image transfer, send the first half of the DB response, complete the image response, and then complete the DB response.
Supported since Firefox 11 (Score:5, Informative)
Go to about:config and switch network.http.spdy.enabled.
Mozilla has been quite critical of some Google technologies (Dart, Native Client, ...) that it saw as not truly open and closing down the internet to be the GoogleWeb. SPDY got implemented though. So I guess it's a a keeper and might see wider adoption.
Re:Parent is trolling (Score:5, Informative)
As one of the creators of SPDY I can say: SPDY as specified today requires TLS and is only deployed using TLS.