Can all the HTTP headers be compressed?

[Sam]

Can all the HTTP headers be compressed by SPDY? Why?

[Adam Langley]

On Fri, Dec 17, 2010 at 10:07 AM, Sam <emine...@gmail.com> wrote:
> Can all the HTTP headers be compressed by SPDY? Why?

Yes, SPDY deflate compresses all HTTP headers.

AGL

[Sam]

Thanks.

Then is the data also compressed using gzip other than the HTTP
header?

Sam

On 12月17日, 下午11時12分, Adam Langley <a...@chromium.org> wrote:

[Adam Langley]

On Fri, Dec 17, 2010 at 10:34 AM, Sam <emine...@gmail.com> wrote:
> Then is the data also compressed using gzip other than the HTTP
> header?

SPDY, as a transport layer, doesn't compress the payloads. However, it
does require that the client be able to support the standard HTTP gzip
Content-Encoding.

AGL

[Markus Isomäki]

Hi,

 

I've understood that people pretty much think that SPDY should always be run on top of TLS. If that's the case, what would be the tradeoff between using TLS compression for regular HTTP vs. SPDY? I suppose the compression wrt. HTTP headers would be quite similar.

 

Of course SPDY still has other features like request chunking/muxing that makes it different from HTTP/TLS. But based on the tests we have done with SPDY, the speed-up we have seen has mosly been due to the header compression. That may be because our tests have been done over relatively low-capacity links where the pipes get full quite quickly and after that the page load time is merely a function of how many bytes there are to deliver.

 

Regards,

Markus

[Mike Belshe]

On Thu, Dec 23, 2010 at 2:50 AM, Markus Isomäki <markus....@gmail.com> wrote:

Hi,

 

I've understood that people pretty much think that SPDY should always be run on top of TLS. If that's the case, what would be the tradeoff between using TLS compression for regular HTTP vs. SPDY? I suppose the compression wrt. HTTP headers would be quite similar.

I haven't tested specifically, so I could be wrong, but here are my thoughts.

Two things:

  a) TLS compression would then be compressing all data, not just header data.  Given that much of the web is already compressed, this would be redundant.

  b) gzip will use a 32KB window; so if you compress headers, then compress 32KB of data, then compress headers, the context of the previous headers is completely lost.  Since most bodies are less than 32KB, you won't always lose your header state, but sometimes you will.  This will result in more bytes.

 

 

Of course SPDY still has other features like request chunking/muxing that makes it different from HTTP/TLS. But based on the tests we have done with SPDY, the speed-up we have seen has mosly been due to the header compression. That may be because our tests have been done over relatively low-capacity links where the pipes get full quite quickly and after that the page load time is merely a function of how many bytes there are to deliver.

Sounds mostly right to me; on low-speed links HTTP can achieve 70-80% of channel capacity today.  So in terms of total page time, there isn't a huge difference because HTTP can already use the full pipe.  This is not true at higher bandwidths.

One other thing to look at would be responsiveness (time-to-first-paint, or time-to-load without images, or what not).  Due to SPDY prioritization of resources, it can load the important elements (html, css, js) before the less important ones, yielding a usable page earlier than HTTP can.    Most people don't measure this, because it's a squishy measurement at best, full of subjectivity.

Mike

[Lars Eggert]

On 2010-12-23, at 19:42, Mike Belshe wrote:
> One other thing to look at would be responsiveness (time-to-first-paint, or
> time-to-load without images, or what not).

Binoy and Aki have been looking into measuring those, but AFAIK ran into problems because it wasn't immediately obvious how to make chrome report those timings. Any hints would be greatly appreciated.

Lars