undefined | Better HN

0 pointsyoungtaff12y ago0 comments

I've tested SPDY over wired / wifi but not over mobile so my mobile experience is anecdotal.

That said all my mobile browsing (minus HTTPS) is run over SPDY (via the Google proxy) and I wouldn't describe it as sucking.

Even in the HTTP case it will still depend on what resource the packet loss etc., occurs for e.g. if it's something on the critical rendering path will it make that much difference?

0 comments

3 comments · 1 top-level

fredliu12y ago· 2 in thread

Glad that you brought up the critical rendering path, because SPDY uses single connection for all requests, once a packet loss/re-transmission happens, the entire connection's congestion window will be cut, which will affect all requests, so most definitely it'll hurt requests on the critical rendering path. Actually the good old HTTP1.1 doesn't suffer from this because if multiple connections are used, and only one connection suffers packet loss, only the request using that connection will suffer(assuming pipelining is not enabled), the other requests using other connections won't. This actually reduces the chance of resources on critical rendering path suffer from packet loss.

youngtaffOP12y ago

But is there any research into how often the 'independent' connections actually mitigate against packet loss?

Even on HTTP if the packet loss comes in the middle of negotiating the connection for the CSS, the page is still going to be waiting for the three seconds timeout before re-negotiating the connection.

fredliu12y ago

We've seen in our work, that under high RTT, high packet loss rate (you can simulate similar effect by using things like dummynet, but it wont' be exactly what you'd expect on cellular network due to reasons mentioned in ATT lab's paper), SPDY results in performance degradation over raw HTTP. Also, I'm not saying 'independent' connections can mitigate against packet loss, it can't, and for the case you mentioned, definitely we'd get a performance hit (either first paint or pageload). It's just SPDY makes it worse than the default HTTP behavior, and that's understandable because it only uses single connection, and single connection suffers from different sorts of problem, and you seem to agree this from your first comment.

j / k navigate · click thread line to collapse