SPDY, Speed Tracer and Compressed Data Frames

‹prev | My Chain | next›

I am pretty sure that SPDY data compression is going away in the near future. Still, it is around now and I would like to take another day to investigate. Today, I am going to use the Speed Tracer Chrome extension which also works for SPDY.

Initial investigation yesterday seemed to indicate that zlib compression for small data might even be worse that no compression. Let's see what Speed Tracer says.

First up, uncompressed. Thankfully node-spdy makes the switch between compressed and uncompressed relatively easy (though not quite configurable). In the Response class, I set the data flags to 0x00 (i.e. no compression):

  var dframe = createDataFrame(this.getStreamCompressor(), {
    streamID: this.streamID,
    flags: fin ? enums.DATA_FLAG_FIN : 0,
  }, Buffer.isBuffer(data) ? data : new Buffer(data, encoding));

Then, I access the node-spdy test page, which consists of the page itself, a background JPEG, a single CSS page and an AJAX request:



Checking the Speed Tracer results, I find:

#####
# Summary
URL               https://localhost:8081/style.css
From Cache        false
Method            GET
Http Status       200
Mime-type         text/css
Total Bytes       347 bytes
Request Timing    @77ms for 13ms
Response Timing   @90ms for 33ms
Total Timing      @77ms for 46ms

(I am only showing the summary info for the CSS, there is a lot more data than this in Speed Tracer)

For the compressed frame, I find:

####
# Summary
URL               https://localhost:8081/style.css
From Cache        false
Method            GET
Http Status       200
Mime-type         text/css
Total Bytes       347 bytes
Request Timing    @3887ms for 11ms
Response Timing   @3899ms for 35ms
Total Timing      @3887ms for 47ms

Bah!

There is no difference between those two (aside from very, very slight differences in timing). So, is the data actually being compressed or is Speed Tracer just hiding compression? To answer that question, I drop back down to Wireshark packet sniffing.

The compressed packet:

               +----------------------------------+
 00 00 00 03   |C|       Stream-ID (31bits)       |
               +----------------------------------+
 02 00 00 dd   | Flags (8)  |  Length (24 bits)   |
               +----------------------------------+
 78 9c 64 8f   |               Data               |
 d1 6e c3 20   +----------------------------------+
 0c 45 df f3
...

The flags indicate that the packets are compressed (0x02 == DATA_FLAG_COMPRESSED). The length of the frame is 0xdd, which is 221 bytes. Finally, according to Wireshark, the printable packets are:

xdn EID>![
8k@idp@R`p6]TvhjP?gPW4%Kk]WMm vT#aaN6%A}*J<Ii@HX:N1Kh9?Z7@U\fL DZ!Qy?P'!sW

That certainly looks compressed.

The uncompressed packet:

               +----------------------------------+
 00 00 00 03   |C|       Stream-ID (31bits)       |
               +----------------------------------+
 00 00 01 5b   | Flags (8)  |  Length (24 bits)   |
               +----------------------------------+
 62 6f 64 79   |               Data               |
 20 7b 0a 20   +----------------------------------+
 20 70 61 64
...

Just like last night, the flags are 0x00, which means that the frame is not compressed. The length of the frame is 0x015b, which is 347 bytes. And, according to Wireshark, the printable packets are:

body {
  padding: 0;
  margin: 0;
}

section#main {
...

That is definitely not compressed and that 347 bytes looks quite familiar:

...
Total Bytes       347 bytes
...

So Speed Tracer's output makes SPDY completely transparent. I suspected as much when I have played with it in the past, but to see the data size reported as 347 bytes regardless of the actual frame size really bring the point home.

Also interesting to me is that the times do not change regardless of the compressed / uncompressed streams. I am investigating really small amounts of data here. 347 bytes will fit into a TCP segment regardless of compression. It could make a difference for a larger CSS file. It could also make a difference experimenting with this over the internet rather than doing it all locally.

Still, since data frame compression is going away, I will likely move on to other topics tomorrow.


Day #48