Advertisement
Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.
| |||||||||||||
|
| |||||||||||||
Reducing HTTP latency with SPDYReducing HTTP latency with SPDYPosted Nov 27, 2009 0:21 UTC (Fri) by efexis (guest, #26355)In reply to: Reducing HTTP latency with SPDY by v13 Parent article: Reducing HTTP latency with SPDY
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.
(Log in to post comments)
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.
|
|
||||||||||||