5 ms·
Oh wonderful, it appears to use SPDY-like header compression. Why don't we just create a new compression algorithm and predefine common HTML tags and words to i
by Aloisius 13y ago
Oh wonderful, it appears to use SPDY-like header compression. Why don't we just create a new compression algorithm and predefine common HTML tags and words to improve compression of the response body too! But we shouldn't base it on any known compression scheme and only use it for the case where the content length is less than 220,498 bytes but more than 8,494 bytes to optimize the behavior of today's more common MTU settings for PPPoE in Scandinavian countries minus of course the most common size of compressed headers today. It will be particularly optimized for the kind of responses Google sends back to minimize their own server load and common adwords will of course be included in the predefined list of compressed tokens.
/sarcasm
What happened to simple protocols? Seriously, per-hop flow control (which works best with which of the dozen version of TCPv4 or TCPv6 flow control?)? TCPv4-like framing with weird limits (16383 bytes)? Keepalives/Ping? Truly ridiculous specialized compression for headers which ignores the role of HTTP proxies? QoS?
Why not just implement the whole protocol over a raw IP connection and stop pretending like we're operating in layer 4+? I get that multiplexing is difficult without flow control, but good lord does this thing look overdesigned for what few benefits it offers over HTTP/1.1.
- tptacek 13y agoRecapitulating a comment from downthread, but, look at DNS for an example of how the IETF botches compression in its "simple" protocols. Not that compression isn't fraught (look at TLS), but I see its use as a sign of maturity.
- angersock 13y agoWell, we had a nice thing for a while, and now it's time to fuck that all up. The wheel turns. Look on the bright side--if everyone decides the public Internet is too insecure, maybe we can convince them to keep using the old standards on darknets?
- nly 13y agoI can't help thinking some of the pain could be resolved if we had a reliable datagram protocol between UDP and TCP. Delimiting a TCP stream to create a messaging protocol is already suboptimal and error prone, and it's the root cause of the head-of-line blocking problem experienced by HTTP ('fixed' in SPDY).
- ldng 13y agoYou mean like SCTP ? It's struggling to get traction.
- jahaja 13y agoSomething like QUIC? I reckon a few of the authors of this draft is also involved in QUIC. http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm...
- Camillo 13y agoThere can be no new layer 4 protocols due to NAT. You have to use either TCP or UDP.
- neuroscr 13y agoSo instead of doing things properly, we'll hack around it... Isn't that what we're all complaining about? Let's do it right and then fix NAT
- nly 13y agoSo we can move from IPv4 to IPv6 but not introduce a new transport because of NAT? Hmm...
- wmf 13y agoThe IPv6 transition is not going that much better than SCTP. So many people have v4-only home routers that they have no plans to ever upgrade.
- osth 13y ago"What happened to simple protocols?" Answer: The Internet is still running on them, 30 years later. Whenever I read something like "simplicity is hard", it makes me cringe. I hear that a lot, and I see evidence of gratuitous complexity everywhere I look these days. I'd hazard a guess the engineers behind SDPY would find simplicity (and reliability) boring. Debugging binary protocols is either great job security for over eager engineers like the SPDY team or a great waste of our collective time. I'll let you all decide which.