41–50 of 66 posts
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.
As a developer you never deal with SPDY. You just deal with HTTP and HTTP headers. SPDY is just a configuration option in your web server. There is no complexity to deal with, it just works.
> However, we have measured as much as a 30% decrease in latency in the wild for API requests carried over SPDY relative to those carried over HTTP.
> In particular, we’ve observed SPDY helping more as a user’s network conditions get worse.
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.
SPDY is just HTTP, just like TLS is. TLS does not replace HTTP: it wraps HTTP. Same thing for SPDY. As a developer you never deal with SPDY. You just deal with HTTP and HTTP headers. SPDY is just a configuration option in your web server. There is no complexity to deal with, it just works.
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 difference is that Google has actually submitted SPDY as a possible basis for HTTP/2.0. Too bad that it looks like it's going to be accepted, but that's a different issue alltogether (yeah. I don't like where HTTP/2.0 is going, but I can only "blame" the IETF, not Google). Microsoft back then had no intention of submitting their changes to any standards body and was actually using patents and copyrights to ensure…
Earlier quoted context omitted.
Where does HTML5 include SCTP? Searching for SCTP in the HTML spec finds nothing! (And why would it, it is agnostic towards the transport layer!)
It's part of the WebRTC part, which extends the HTML5 environment with UDP communication. Documented here: http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-...
Earlier quoted context omitted.
It's part of the WebRTC part, which extends the HTML5 environment with UDP communication. Documented here: http://tools.ietf.org/html/draft-jesup-rtcweb-data-protocol-...
Okay, so you're taking "HTML5" to mean the Web Platform, rather than HTML5 itself (or its spec).
I think QUIC is supposed to address this: http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
My understanding is QUIC is being used as a proof of concept for protocol experiments - it may be pushed towards standardisation or the the lessons from it may be pushed into other protocols
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.
SPDY is just HTTP, just like TLS is. TLS does not replace HTTP: it wraps HTTP. Same thing for SPDY. As a developer you never deal with SPDY. You just deal with HTTP and HTTP headers. SPDY is just a configuration option in your web server. There is no complexity to deal with, it just works.
Why did they take the effort to produce an entire paper, over a research question that has a simple logical answer? 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 incre…
You're wrong on all counts. First, the results aren't obvious (nor the underlying reasons). In fact Google published results a couple of years ago that got massive amounts of coverage suggesting the opposite ( http://googledevelopers.blogspot.com/2012/05/spdy-performanc... ). I've worked on TCP optimization of mobile networks for the past 3 years, publicly criticized Google's study when it came out, and still the res…
The conclusion I drew from the paper was a little different from "SPDY no faster than HTTP on mobile." My conclusion was "Mobile sucks equally hard for any application layer protocol."
Earlier quoted context omitted.
The difference is that Google has actually submitted SPDY as a possible basis for HTTP/2.0. Too bad that it looks like it's going to be accepted, but that's a different issue alltogether (yeah. I don't like where HTTP/2.0 is going, but I can only "blame" the IETF, not Google). Microsoft back then had no intention of submitting their changes to any standards body and was actually using patents and copyrights to ensure…
What don't you like about where HTTP/2.0 is going?
The whole process had the feel of a sham. SPDY should have evolved as its own protocol, continuing under the spdy name, and http/2.0 should have simply evolved to a semantically-driven protocol with standard negotiation mechanisms for choosing the wire protocol (which could be the MIMEish thing we have now or SPDY). This would have been a good way to ensure the web has a solid upgrade path.