I have built nginx-1.3.3 with patch.spdy-47.txt and openssl-1.0.1c and
my test client is Chrome 22.0 (beta unstable). I know SPDY server push
is not supported, but is SPDY server hint supported? If so, how do I
enable the client to take advantage of server hint?
According to the chromium project docs a “link” header might work. I
added the Link header using the add_header directive in nginx as
stated in their example, but I do not think it is working. For
example:
When I read through the SPDY documents up to version 4 I saw no
mention of server hints at all. I thought I must have missed something
since every news or review article I read mentions SDPY hints, but no
one ever had an example.
BTW, SDPY on Nginx has worked flawlessly in a public beta production
environment for three(3) weeks now. We see an average of 739
concurrent ips connecting with one TCP connection each and asking for
21 objects per un-cached page request. This has reduced the load
(cpu/ram) on our FreeBSD stateful firewall by ~63% due to less states
and decreased client load times by 47%. I can happily report no
crashes, faults or page errors with the current source build. Thanks
for all the hard work.
BTW, SDPY on Nginx has worked flawlessly in a public beta production
environment for three(3) weeks now. We see an average of 739
concurrent ips connecting with one TCP connection each and asking for
21 objects per un-cached page request. This has reduced the load
(cpu/ram) on our FreeBSD stateful firewall by ~63% due to less states
and decreased client load times by 47%.
The last metric is compared to a plain HTTP or HTTPS?
I can happily report no crashes, faults or page errors with the
current source build. Thanks for all the hard work.
When I read through the SPDY documents up to version 4 I saw no
mention of server hints at all. I thought I must have missed something
since every news or review article I read mentions SDPY hints, but no
one ever had an example.
Seems it’s a browser specific feature. It isn’t related to SPDY, or
nginx.
add_header Link "</images/big.jpeg>; rel=prefetch";
with Firefox.
BTW, SDPY on Nginx has worked flawlessly in a public beta production
environment for three(3) weeks now. We see an average of 739
concurrent ips connecting with one TCP connection each and asking for
21 objects per un-cached page request. This has reduced the load
(cpu/ram) on our FreeBSD stateful firewall by ~63% due to less states
and decreased client load times by 47%. I can happily report no
crashes, faults or page errors with the current source build. Thanks
for all the hard work.
Great! Thank you for sharing your experience. We continue work on
improving
SPDY in nginx and eventually merge the patch into the main branch.
We originally started on patch.spdy-44.txt and rebuilt nginx on each
successive patch release. Currently we are using nginx-1.3.3 with
patch.spdy-47.txt and openssl-1.0.1c on the live servers.
The client load time differences were calculated moving from https to
https-spdy. This was not a purely scientific study though as the
hardware did not change, but we did move the Nginx daemon to Freebsd 9
from Ubuntu Linux 12.04.
Still we are very happy with the improvements without changing any html
code.
From what I understand using the “Link” header with the rel=prefetch
directive will download the files once the current page is loaded and
the client connection is idle. This is to pre-load files that the
client may request later on the site. This option seems to be in
Firefox only and available for a few years now.
The Google docs for the “Link” header with the rel=subresource
directive seems to tell the client the files listed are to be
downloaded immediately as they are going to be using on the current
page rendering. In theory the client could ask for the index.html and
the server would send the index.html with the rel=subresource headers
for other jpgs. The client would then immediately ask for the jpgs, if
not already in its cache, instead of decompressing the index.html and
parsing the file to discover the same pictures.
I did a few tests with the following headers which I found searching
the google dev docs. I tested the headers against the latest Firefox
17.0a1 and Chrome 22.0 and nothing seemed to make any difference
according to the browser’s development tool timings.
add_header X-subresource "image/jpeg;/image1.jpg;;
add_header Link “</image1.jpg>; rel=subresource”;
They probably just are not implemented in the browsers at this time.
add_header Link "</images/big.jpeg>; rel=prefetch";
with Firefox.
I’ve just test it myself. It works well with my Firefox 14 on both HTTP
and
HTTPS (pure or over SPDY). But I also found that Firebug doesn’t show
these
prefetched requests on the Net tab.
This is just a quick follow up on this thread of “server hint” for
those interested.
webtide.com has implemented SPDY/3 with server push on some of their
hosts. From the following link it looks like SPDY/3 with server push
will allow a client to deny a server push using a GOAWAY call. So, if
the server is pushing a jpg and the client already has it then the
client can stop the transfer. This method may negate the need for a
server hint entirely and save a few round trip times (RTT).
This is a quote from the article:
“Now you might be wondering what happens if the browser has the
resources already cached? Arent we sending data over the wire which
the browser actually already has? Well, usually we dont. First we use
the if-modified-since header to identify if we should push sub
resources or not and second the browser can refuse push streams. If
the browser gets a syn for a sub resource it already has, then it can
simply reset the push stream. Then the only thing that has been send
is the syn frame for the push stream. Not a big drawback considering
the advantages this has.”
If webtide is correct with their implementation we should be able to
make a best guess about the client cache and server push data to them
to significantly reduce load times. If we get the guess wrong and the
client already has the data the client can stop the transfer saving
bandwidth.
BTW, just made patch.spdy-48.txt live on our servers and everything
looks fine.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.