11–20 of 66 posts
I think QUIC is supposed to address this: http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
It doesn't matter if SPDY offers and technical improvements or not to our good, robust and lasting protcols HTTP. It's Google who is promoting it and all the "hip" hackers will rally for its cause.
That's something that can be worked on and indeed there's a recommendation for improving it. I'd hope something like this would be included in HTTP/2.0, or at least in a subsequent revision.
I really don't see the point of stuff like SPDY and WEBP/WEBM. They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
The former is generally more performant that HTTP, and the latter also offer benefits versus other options.
They're just google doing what Microsoft did in the 1990s, setting their own proprietary 'standards' instead of working to improve things.
This is dangerously wrong, for two reasons:
1. These are open standards. They're not proprietary. 2. What is "improving things" if not proposing open, alternative standards which solve existing problems?
I'm not a fan of SPDY at all. HTTP was simple to implement and understand. This is neither. And it matters. The small gains in performance are not worth the complexity.
HTTP remains pretty simple, and SPDY doesn't replace it - it's essentially a wrapper around HTTP. That said, you're correct in that it requires an additional layer, and that it's no longer plaintext. It will require additional debugging tools, but I'm not convinced that's actually a problem.
Earlier quoted context omitted.
Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
Because it's a binary protocol without the documentation, intuitiveness, and openness of HTTP. Yes, implementations exist for $whateverWebserver, but most people who add them won't understand the protocol, and can't debug when something goes wrong.
I think QUIC is supposed to address this: http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
I think QUIC is supposed to address this: http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
Earlier quoted context omitted.
Saying "instead of working to improve things" means that you think SPDY is not an improvement. Why do you think that?
Because it's a binary protocol without the documentation, intuitiveness, and openness of HTTP. Yes, implementations exist for $whateverWebserver, but most people who add them won't understand the protocol, and can't debug when something goes wrong.
It's a documented binary protocol, is open and reasonably easy to understand - spdyshark will help.
The research question (sort of): Is SPDY, which was designed to make HTTP work better on connections with more bandwidth and not worse on less bandwidth, increase performance on connections with less bandwidth (and not really related more latency)?
Their answer (sort of): no, as designed SPDY only increases performance on connections with more bandwidth, and performs similar to HTTP on smaller bandwidths.
Their conclusion (sort of): TCP is not very suitable for transmitting data on high bandwidth (relatively) high latency connections, we should use a different transport layer protocol.
What your reaction should be (sort of): No shit sherlocks, that's exactly what everyone thought 15 years ago and only now the idea is picking up steam, with HTML5 including SCTP in the spec, and Google working on the QUIC effort.