Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HN supports SPDY

spdycheck.org

Post reply on HN
Print view View original

61–70 of 79 posts

Re: HN supports SPDY

#61

Post by eco »

joosters wrote: post #33
peterfschaadt wrote: post #23

Earlier quoted context omitted.

Here is the SPDY indicator I use for Chrome. It's also simple and works well. https://chrome.google.com/webstore/detail/spdy-indicator/mpb...

Chrome addon permissions are terrifying. 'Access your data on all websites', 'Access your tabs and browsing history'. All this when the code is a one-liner: chrome.extension.sendRequest({ spdy: window.chrome.loadTimes().wasFetchedViaSpdy }); It's not the extension's fault, but Google's. I guess they want us to get used to ignoring the scary permissions? (Also, wouldn't it be good if the Chrome store had a link to the…

I remember at the last Google I/O the Chrome team said they were working on a more granular permissions system and recognized how scary "Access your data on all websites" was. Not sure when that's supposed to debut though.

Re: HN supports SPDY

#62

Post by bri3d »

jedberg wrote: post #36
kogir wrote: post #17

Earlier quoted context omitted.

That behavior shouldn't get you banned, but some of your requests will get dropped if you make too many too quickly. You will see 304s for static resources, like images and CSS. Efficiently handling HEAD requests for dynamically generated pages is actually painful, and many frameworks support it by handling the request like a GET and just omitting the body. In our case, most pages contain fnids and will never be the…

Well, it drops every request I make for about 12 hours, so that's equivalent to a ban. :) And I'm aware of how painful it is to handle HEAD requests for a dynamic page, having had to deal with it on reddit. There are some easy hacks to make it work pretty well. One is to just keep a cache of the last update time of each page, and then use that cache when you get a HEAD request. I'm not sure what an fnid is, but if yo…

PG and friends are using Continuations ( http://en.wikipedia.org/wiki/Continuation ), which are supported first-class in Racket, as the pattern underlying HN.

Their specific implementation of continuations means that each time a page is generated, each user-specific/authenticated link off of the page (Flag, Voting, Delete) is evaluated as a possible continuation of the user's state and the user-and-action specific hash "fnid" (Function ID) is cached and interpolated into the HTML.

Hence, the hash absolutely changes for every logged-in user every page load.

Lots of older sites still use continuations to great effect; Continuations were popular in the WebObjects days but since they require lots of user state information to be stored server-side they're comparatively difficult to scale.

Continuations are a really cool pattern to study, since most hacking in HTTP-backed web services comes from the inherently stateless nature of the protocol, and continuation-based programming helps prevent the inverted control flow that page-based programming lends itself to.

Re: HN supports SPDY

#63

Post by born2web »

kogir wrote: post #17
jedberg wrote: post #12

Great! Now if only they would implement allowing HEAD requests and support for any of the various headers that would allow me to get a 304. The reason I ask is because every time my Safari crashes, if I have 50 HN tabs open (as I often do on by Friday [1]) I'll get IP banned from HN because Safari will do a GET request on each page, but it can't pass any of the headers necessary to get back a 304, because HN doesn't…

That behavior shouldn't get you banned, but some of your requests will get dropped if you make too many too quickly. You will see 304s for static resources, like images and CSS. Efficiently handling HEAD requests for dynamically generated pages is actually painful, and many frameworks support it by handling the request like a GET and just omitting the body. In our case, most pages contain fnids and will never be the…

Actually, it does get one banned. It happened to me once and it was the most nerve wracking experience trying to figure out what exactly happened and why i was separated from my favorite site.

I came up with the following simple :-) hack: When there is a need to open a bunch of HN links (either saved tab sessions or more importantly when restoring a crashed browser session), I disconnect the network connection. Once all the tabs are launched, I turn the network connection back on and refresh each tab when i get around to reading it.

Re: HN supports SPDY

#64

Post by erifneerg »

reeses wrote: post #19
rdl wrote: post #13

Earlier quoted context omitted.

Isn't that how everyone uses HN?

This is why tldr.io is useful. I can get my HN lazy-tabs down to 40 per visit.

Too bad that is chrome only at the moment and the commenter is using safari.

And for the too lazy to copy paste: http://tldr.io

Re: HN supports SPDY

#65

Post by hobohacker »

dsl wrote: post #25
ericflo wrote: post #22

Has anyone built an NSURLProtocol subclass for SPDY? I did a quick GitHub search and found nothing. Seems to me that's one big use case that SPDY could dramatically improve, is all these native mobile apps which open SSL connections to their APIs.

SPDY has no benefit for mobile APIs. Make sure you turn on HTTP Keep-Alive and all your requests will be pipelined over a single TLS connection.

Why do you assert it has no benefit for mobile APIs? Here are a few that I can think of off the top of my head:

* SPDY Multiplexing is superior to HTTP pipelining. Pipelining requires in-order responses, which leads to head of line blocking.

* SPDY header compression is a win for mobile, since mobile uplink bandwidth is often a bottleneck. Request header compression allows for fitting more requests into fewer packets.

* Mobile connections are more likely to hang, so using SPDY PINGs (https://insouciant.org/tech/connection-management-in-chromiu...) will help fail fast.

* Multiplexing more requests over fewer connections will help with mobile power usage (https://insouciant.org/tech/connection-management-in-chromiu...).

Re: HN supports SPDY

#66

Post by hobohacker »

powertower wrote: post #46
da_n wrote: post #44

Great, but interested in why it still loads up pages only marginally faster than PayPal? Seems to have kept the same page load performance this despite all the news about better servers etc. I know we don't want this place to become Reddit[1] but is there also a built-in delay implemented? [1] I can only imagine this is why the pagination still appears completely broken (unknown or expired link).

From the looks of it, real world SPDY performance increases are non-existent for most websites due to how they are organized and served. You have to really change how your website gets served (at the cost to non-SPDY users) to get an increase in performance. Which usually ends up not even being 25%. From what I've been able to gather, especially with little to no reports of any real-world benefits (I've only seen cri…

http://www.chromium.org/spdy/spdy-whitepaper has data on improvements in lab tests. http://googlecode.blogspot.com/2012/01/making-web-speedier-a... has a blurb where Google announces that they've made search (already highly optimized) faster with SPDY. This is a fascinating result, because this result was obtained after Google Search switched to using HTTPS, which typically makes websites slower, but in Google's case, made it faster because of SPDY. Note that Twitter and Facebook have also adopted SPDY. I'd be rather skeptical that Google, Twitter, and Facebook would all switch to SPDY if there weren't real world benefits.

Re: HN supports SPDY

#67

Post by drivebyacct2 »

peterfschaadt wrote: post #23
shmerl wrote: post #5

Just noticed that the indicator turned on :) https://addons.mozilla.org/En-us/firefox/addon/spdy-indicato...

Here is the SPDY indicator I use for Chrome. It's also simple and works well. https://chrome.google.com/webstore/detail/spdy-indicator/mpb...

Erm, it doesn't light up on HN for me.

Re: HN supports SPDY

#68

Post by powertower »

hobohacker wrote: post #66
powertower wrote: post #46

Earlier quoted context omitted.

From the looks of it, real world SPDY performance increases are non-existent for most websites due to how they are organized and served. You have to really change how your website gets served (at the cost to non-SPDY users) to get an increase in performance. Which usually ends up not even being 25%. From what I've been able to gather, especially with little to no reports of any real-world benefits (I've only seen cri…

http://www.chromium.org/spdy/spdy-whitepaper has data on improvements in lab tests. http://googlecode.blogspot.com/2012/01/making-web-speedier-a... has a blurb where Google announces that they've made search (already highly optimized) faster with SPDY. This is a fascinating result, because this result was obtained after Google Search switched to using HTTPS, which typically makes websites slower, but in Google's case…

When you enable SPDY for your average website, you'll get some real world results.

When you talk about Google, or Facebook, or Twitter using it to squeeze out a few extra percentage points out of their latency or bandwidth or load-time - in their very highly specialized and optimized and conditional and resourceful environment, that's about as non real world as it get for the rest of us.

The fact that SPDY adaptation has mostly failed for the rest of the internet, says more about it than any white-paper or lab-result can.

Again, I hope I'm wrong here.

Re: HN supports SPDY

#69

Post by lstamour »

powertower wrote: post #68
hobohacker wrote: post #66

Earlier quoted context omitted.

http://www.chromium.org/spdy/spdy-whitepaper has data on improvements in lab tests. http://googlecode.blogspot.com/2012/01/making-web-speedier-a... has a blurb where Google announces that they've made search (already highly optimized) faster with SPDY. This is a fascinating result, because this result was obtained after Google Search switched to using HTTPS, which typically makes websites slower, but in Google's case…

When you enable SPDY for your average website, you'll get some real world results. When you talk about Google, or Facebook, or Twitter using it to squeeze out a few extra percentage points out of their latency or bandwidth or load-time - in their very highly specialized and optimized and conditional and resourceful environment, that's about as non real world as it get for the rest of us. The fact that SPDY adaptation…

I can say you're going to be wrong ;-) Lots of sites are adopting it through services like CloudFlare and large shared ISPs will likely turn it on as a feature (or for all users) once the Apache/Nginx pagespeed plugins stabilize and SSL grows cheaper thanks to IPv6 addresses. The main problem is that SPDY adoption basically goes hand-in-hand with SSL adoption, and SSL hasn't taken off though it should. You wouldn't say SSL has failed, would you? ;-)

Re: HN supports SPDY

#70

Post by billyhoffman »

mooism2 wrote: post #26

If you ask spdycheck.org to check a site that doesn't support spdy, and customise that site's Server header to include arbitrary html, spdycheck.org will include that header, verbatim and unescaped, in the page it presents to you (or anyone else who checks that site). I don't know that it's a security flaw in this context, but it's sloppy.

Ahhh. Thanks. All info from the web server, such as the protocols returned in the NPN extension and the Server header were passing through an HTML Encode function. Except there was one case where, if the site didn't support SPDY, and SPDY check could not determine the type of web server, the Server header output was not getting HTML encoded.

Thanks for letting us know.

Billy Hoffman (founder and CTO @ zoompf)

Post reply on HN