41–50 of 67 posts
Clear explanations, a very pleasant layout, and useful visual metaphors for the trickier parts of the spec. I found it to be both enjoyable and informative.
A really nice example of documentation done well.
Earlier quoted context omitted.
I think he/she is not talking about the transport protocol (TCP/UDP), but the higher up layers (5 - 7) cramming functionality from the lower layers. Might be reading it the wrong way.
They only try to cram functionality from lower levels into higher ones because establishing new lower ones is nearly impossible. SCTP (or variants of it) would implement a lot that is now build on higher levels, but there is a reason it's only used in private networks.
Earlier quoted context omitted.
Moreover, it's bad from a QoS standpoint. Opening many TCP streams in parallel is not fair to other users sharing the routers between you and the server. You'd get more than your fair share of bandwidth.
Doesn't that depend entirely on the queuing and session mapping algorithm? If you profile for bandwidth-per-source-ip, shouldn't that apply exactly the same restriction regardless of how many connections are started? (with multiple-connections people losing a bit because connection start/stop takes bandwidth they could use for data instead)
What we really want is something more like bandwidth-per-end-host caps.
Earlier quoted context omitted.
Good luck getting everybody to upgrade their kernel to support your new transport protocol. Realistically, UDP and TCP are what we have. We may wish they were more suited to modern use cases, but realistically we must build on those foundations. If that means violating "layering" for performance, so be it.
Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude. Seems far more reasonable than letting things stagnate for years. It's what chrome is doing with sha1 certs. Give a timeframe, if you don't get your upgrade in then too bad.
"Upgrade or suffer" rarely works in practice. Rendering (or rather the lack of rendering) malformed XHTML is a great example of this
Earlier quoted context omitted.
Probably Apple, there is another mention of them later on in the document.
Could be. Mobile Safari uses pipelining, so for Apple there's not a lot of benefit from HTTP2. It isn't a big enough deal for them to push a new protocol, like it is to say Google that doesn't have pipelining in their browser.
http://zoompf.com/blog/2014/06/spdy-coming-to-safari-future-...
At the risk of not being quite critical enough for HN - that was an excellent read. Clear explanations, a very pleasant layout, and useful visual metaphors for the trickier parts of the spec. I found it to be both enjoyable and informative. A really nice example of documentation done well.
Earlier quoted context omitted.
Why not just have the wire sniffer decode the frames before presenting them. If you're interested in what's going on at the HTTP level, you aren't reading packetwise IP packet dumps, because it's hard to make sense of anything and everything is all mixed together; you're looking at abstracted, higher-level flows, where it's just taken for granted that you have a set of linear TCP streams. HTTP2 is a(n SCTPish) transp…
> Why not just have the wire sniffer decode the frames before presenting them. Certainly possible, but why make our lives harder by implementing HTTP/2 such that it requires a decoder to read in the first place? If the number of bytes sent remains the same, why not make the fields as self-documenting as possible? > Everything that speaks HTTP2 also speaks HTTP1.1 No, they have fundamentally different wire formats. Th…
I cannot imagine anyone that has written a compliant HTTP parser, or attempted to make a fast HTTP implementation thinking the new framing is harder.
As the article mentions, yeah, it would be nice to be able to look through raw captures. But overall, it's simply too much of a massive downside. It wastes space and burns CPU for nearly zero benefit.
Text protocols make developers start treating them like text than protocols, so you end up with a nightmare of things that look ok to humans but introduce compatibility or security issues when parsing. Even getting line endings right is a pain.