Http2 explained

Re:Http2 explained by necubi on Thursday February 12, 2015 @05:43PM (#9041864)

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.

[ Parent | on HN ]

Re:Http2 explained by serge2k on Thursday February 12, 2015 @07:58PM (#9042298)

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.

[ Parent | on HN ]

Re:Http2 explained by mobiplayer on Friday February 13, 2015 @08:01AM (#9044070)

Google can push that because there's a huge user base with Chrome and you don't want your shiny ecommerce site to be marked as not safe by Chrome, do you?

On the other hand, the packets moved through the wires to send this comment to HN and the ones moved to send this comment to your computer are easily managed by dozens of different people and a handful of different companies with different agendas, budgets, needs and even skills. Cisco definitely manufactured and sold most of the devices out there, but they surely don't manage them or decide when they're upgraded. It gets worse, because actually there's not only Cisco out there.

I'm not saying it can't be done, but just look at the slow IPv6 adoption, despite the efforts of all the big players (Google, Cisco, Juniper, Microsoft, Linux, ... !) supporting it in a timely manner, it's still not there.

[ Parent | on HN ]

Re:Http2 explained by gsnedders on Friday February 13, 2015 @11:41AM (#9045195)

Also remember that everything Google has ever pushed through has been above UDP/TCP, because it's far easier to push through changes on top of that than not. There's a reason why QUIC is being developed on top of UDP instead of as a transport layer in its own right.

[ Parent | on HN ]

Re:Http2 explained by billyhoffman on Friday February 13, 2015 @01:01AM (#9043124)

> Maybe instead of the "good luck" attitude we should start pushing an "upgrade or suffer" attitude.

"Upgrade or suffer" rarely works in practice. Rendering (or rather the lack of rendering) malformed XHTML is a great example of this

[ Parent | on HN ]

Re:Http2 explained by testrun on Thursday February 12, 2015 @07:45PM (#9042268)

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.

[ Parent | on HN ]

Re:Http2 explained by detaro on Thursday February 12, 2015 @10:46PM (#9042772)

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.

[ Parent | on HN ]

Re:Http2 explained by Chlorus on Thursday February 12, 2015 @11:42PM (#9042898)

No kidding, take a look at the presentation[0] for multipath TCP - and that was a relatively 'simple' transport layer modification. Look at slide #30 for a glimpse into the madness caused by crappy middleboxes.

[0]http://multipath-tcp.org/data/MultipathTCP-netsys.pdf

[ Parent | on HN ]

Re:Http2 explained by xorcist on Friday February 13, 2015 @05:13AM (#9043665)

The alternative is to layer something over HTTP. That's may be even worse. There are no simple ways to upgrade global infrastructure.

[ Parent | on HN ]