| |||||||||||||
Reducing HTTP latency with SPDYReducing HTTP latency with SPDYPosted Nov 18, 2009 18:53 UTC (Wed) by kjp (subscriber, #39639)Parent article: Reducing HTTP latency with SPDY
Their comment about packet loss makes no sense. In either HTTP pipelining or SPDY, a lost packet stalls the TCP stream... there is nothing SPDY can do to stop that. Now reordering response frames, i.e. images vs a long running cgi page, is clearly a good idea compared to http pipelining.
I like their 'everything is a lowercase key property bag' concept for requests. I don't like the multiple ways to shutdown a stream (set a flag, or send a 0 length frame). That part of the spec needs pruning.
HTTP pipelining does suck for proxies. (I develop one). I ended up supporting it from the client but I don't pipeline up to the server for compatibility, management, and giving myself a headache reasons. It's most annoying because certain magic error codes or conditions kill the whole pipeline connection and you have to start over. Also, for management simply asking what are the current connections and their requests gets more complicated since its many to many... of course with SPDY SSL the proxies won't even know what requests are occuring underneath so in that case it's simpler :)
I also don't know how they figure a server push function doesn't change HTTP/Ajax level apis... sounds like a brand new api to me.
(Log in to post comments)
Reducing HTTP latency with SPDY Posted Nov 18, 2009 19:01 UTC (Wed) by elanthis (guest, #6227) [Link]
Lost packets aren't a problem for regular http multiplexing because browsers just open
multiple connections to he server to download all the page resources. If one image stalls from lost packets it has no effect on the other images and css files and such being downloaded simultaneouslly. If the downloads are pipelines in a single connection then any stall will affect all resources and not just one.
I suppose a question to answer is how often a single connection out of many between two
Reducing HTTP latency with SPDY Posted Nov 18, 2009 19:20 UTC (Wed) by knobunc (subscriber, #4678) [Link]
I think the question is how SPDY is any better than pipelining when encountering packet loss when both are built on TCP, and it is TCP that handles the re-transmits when packets are lost.
All I could find in the article is:
But that is a comparison of plain (non-pipelined) HTTP to SPDY.
Reducing HTTP latency with SPDY Posted Nov 19, 2009 11:36 UTC (Thu) by v13 (subscriber, #42355) [Link]
And HTTP/1.1 always uses pipelining, so it is a comparison of HTTP/1.0 with
SPDY.
Reducing HTTP latency with SPDY Posted Nov 19, 2009 13:22 UTC (Thu) by knobunc (subscriber, #4678) [Link]
Sadly pipelining is off on most browsers.
Summarized from http://en.wikipedia.org/wiki/HTTP_pipelining
Reducing HTTP latency with SPDY Posted Nov 19, 2009 14:26 UTC (Thu) by v13 (subscriber, #42355) [Link]
The konqueror line is obsolete since konqueror 2.0 is from kde 2.0. I just
tested 4.3.2 and it uses pipelining.
Firefox OTOH doesn't (just tested it). The bad thing about Firefox is that
However, the support is there and all HTTP/1.1 servers support it. AFAIK,
Reducing HTTP latency with SPDY Posted Nov 22, 2009 16:38 UTC (Sun) by ibukanov (subscriber, #3942) [Link]
> * Opera - yes AND enabled by default
Yet according to Opera engineers that was not easy. Even after many years of having that enabled by default they still has to tweak their blacklisting database to add new entry disabling the pipelining. If they would know in advance the pain they may not even implement it.
Reducing HTTP latency with SPDY Posted Nov 27, 2009 0:21 UTC (Fri) by efexis (guest, #26355) [Link]
It doesn't, HTTP can only pipeline when the size of the incoming response is known before hand (eg, through sending a Content-length: header at the beginning of the response). Without knowing how big the response is going to be, it doesn't know when the response ends and the next one begins, so the server has to close the TCP connection to let it know it's done.
Reducing HTTP latency with SPDY Posted Nov 27, 2009 1:15 UTC (Fri) by mp (subscriber, #5615) [Link]
Not necessarily. There is also the chunked encoding.
Reducing HTTP latency with SPDY Posted Nov 28, 2009 18:41 UTC (Sat) by efexis (guest, #26355) [Link]
Chunked transfer does also send the size first, that way the other side knows when the chunk it's been receiving has come to an end and the header for the next has begun, the primary difference just being that the message size becomes independant of the document size, but while it may be defined in the HTTP/1.1 spec, it's not mandated... end-to-end support is required for it, and there's a -wide- range of proxy servers out there, at the personal, corporate, and ISP level, transparent and explicit, all to cause problems, not to mention personal firewall/anti-virus software that perhaps can't complete its job until it has the whole document, so being party to chunked transfers isn't going to be so high on the developers list of priorities.
None of these are particularly massive hurdles, but it's still the state of things even in HTTP/1.1 land, so the potential for improvement is very real, and being something that's most important to Google's business, there could actually be some pressure behind it.
Reducing HTTP latency with SPDY Posted Nov 18, 2009 23:21 UTC (Wed) by njs (guest, #40338) [Link]
> I also don't know how they figure a server push function doesn't change HTTP/Ajax level apis... sounds like a brand new api to me.
I was assuming that server-pushed resources just got shoved straight to the cache, so that when the browser got around to looking for them (e.g., because it parsed the HTML page and found the <img> tags), they were already available. That logic works fine for Ajax-style usage too. (But probably isn't as important there, since you can already write an Ajax client that fetches all the needed resources bundled together in a single request and then unpacks them.)
Reducing HTTP latency with SPDY Posted Nov 18, 2009 23:53 UTC (Wed) by martinfick (subscriber, #4455) [Link]
How does the server know that the client doesn't already have this pushed data cached?
Reducing HTTP latency with SPDY Posted Nov 19, 2009 1:05 UTC (Thu) by njs (guest, #40338) [Link]
Ask them? :-) From skimming the docs, it looks like it's a combination of: 1) they may ask the client to tell them whether it's visited this site before in the request headers, and only enable server-push on initial page loads (obviously there are a lot of important details to be worked out here regarding what an "initial page load" is!), 2) the client tells the server how much free bandwidth it's willing to waste on such speculative activities, and the server uses that to throttle the amount of possibly-redundant pushing.
But I didn't see a lot of detail; this seems to be an early still-to-be-fleshed-out draft.
Reducing HTTP latency with SPDY Posted Nov 20, 2009 20:37 UTC (Fri) by pphaneuf (guest, #23480) [Link] I think that functionality is optional, and is indeed something that a web site developer would have to take into account. But for the rest, SPDY looks like it's just something that would make your site faster if both the client and the server support it, sounds like a win to me.
Reducing HTTP latency with SPDY Posted Nov 19, 2009 0:46 UTC (Thu) by BrucePerens (guest, #2510) [Link] That seemed odd to me too. You can't use a TCP stream socket to avoid waiting for packet redelivery or to accept out-of-order delivery without waiting. You'd need to use a datagram service.
Reducing HTTP latency with SPDY Posted Nov 27, 2009 0:42 UTC (Fri) by efexis (guest, #26355) [Link]
Nope :-) The problem with delayed pipelined connections is that the requests are still dealt with one at a time, just without the connection closing in between them. This means a delay of 200ms getting the first request flushed to the client means a 200ms delay in beginning to process the second request. But, with a multiplexed connection, the second request can have been sent before the network delay occurs, and so the server can begin dealing with that request and queueing the packets for sending straight away... it may even be able to get them out the door and to the client, which means that as soon as the client gets the retransmitted packet that got lost, it can piece them all together and pass it into the applications memory, without having to spend as much time waiting for the packets that would have followed it otherwise. Remember that buffers may be in-order at both ends, but that doesn't mean that transmission must be also :-)
Reducing HTTP latency with SPDY Posted Nov 19, 2009 10:25 UTC (Thu) by cate (subscriber, #1359) [Link]
Yes. But it seems that packet losses reduce a lot more the speed of page of
HTTP than in SPDY. But IIRC they don't really understand the cause (other than less packets, so less total lost packets).
OTOH modern websites have both static and dynamic contents. Pipeline usually
|
|||||||||||||