3 ms·

The proliferation of future protocols that will never fully be adopted is simply creating an fractious and overly complicated mess. examples: IPv6 migration.

by erickj 8y ago

The proliferation of future protocols that will never fully be adopted is simply creating an fractious and overly complicated mess. examples: IPv6 migration. This is the best case, given that it was a necessity to combat the exhausting pool of IPv4 addresses. Even such only ~25% client adoption after 10 years. And worse support from websites in the alexa top 1,000,000 (https://www.internetsociety.org/resources/2018/state-of-ipv6-deployment-2018/ https://www.internetsociety.org/resources/2018/state-of-ipv6...) HTTP/2. Roughtly 35% adoption (by site) in the Alexa top 1,000,000. https://http2.netray.io/stats.html https://http2.netray.io/stats.html HTTP/3. Obviously less. Now I'm not trying to make this point from the position of the grumpy old man who doesn't want to learn something new. I love new tech, and obviously the research and development of new protocols over the past 30'ish years has created an explosion of new industry and communication patterns that have indisputably changed the world and shaped modern life. However... the marginal benefit of each protocol advancement is directly related to it's usage (so I assume). The benefit the world saw (from the user perspective) when switching from HTTP/2.0 from HTTP/1.1 was arguably zero (I'm not saying it was exactly "zero", but I could argue that it was imperceptible). With bridge technologies like WebSockets and BOSH/Comet/"Hanging POSTS" it could be argued that HTTP/2 was effectively a bandwidth optimization in most users lives (those users that use the sites that offer support). However, the additional complexity for developers to leverage these optimizations is detracting from the development of otherwise useful service offerings in the form of opportunity cost. This is because nearly every optimization inherently incurs a complexity cost, e.g. supporting both HTTP/1.1 and HTTP/2 is obviously more complex than simply supporting the former. And you are supporting it even if your deployment process abstracts the details away from you, e.g. debugging customer issues. Formulating HTTP/3 when support for HTTP/2 is below 30% is simply an example of standards bodies working on a tiny "easy" problem (make the web go faster.. which is important) rather than face the bigger problem, i.e. helping to scale the worlds service providers a seamless migration path to adopt said new technology. /rant from a grumpy old man

Meai 8y ago
I think adoption could be improved so much if the standards commitee released a javascript and C library for whatever they end up deciding. The javascript implementation should be heavily commented, super easy to understand and basically be the documentation of the standard and the C library (or libraries) should be performance tuned tiny modules that can be called upon by other languages. You may ask: Why javascript? Well the reasons are too many to enumerate and immediately 50 people would come here to disagree and say that they prefer their own language but basically it boils down to there being no fancy features to get in the way of understanding an algorithm. The reasons for C are almost the same, it's easy to understand but with the added advantage of being interopable with just about anything on the planet and fast. Even for http2 after many many years and lots of searching, you basically have to use nghttp2 as the only usable http2 C library and its source code is mixed together with various c++ components. Isn't it always like this? I mean don't these standards committees have to write the algorithms out anyway, why not make a usable module out of it in source code form? I suspect it's because in reality the standard gets sponsored by Google whose engineers have already written c++ implementations that are tied to dozens of their own libraries and subcomponents and integrated into the chrome build system etc etc. Well that still doesn't change the fact that it would be better for everyone else if they released a simple to understand implementation in js and C.
21 8y ago
I'm not sure what you're talking about. Supporting HTTP/2.0 for my site was literally just adding the "http2" word to the listen directive of nginx. Since it's also used as a reverse proxy, the backend app server remained HTTP/1.1. And you still notice the difference in site loading speed if your site has a lot of static assets.
- erickj 8y ago
  How much traffic does your site serve? I'm not saying that turning the feature on is difficult. Anyone reading hacker news can go and configure their webserver to start serving this traffic.... but I can tell you that a site serving serious production loads (let's just say 100 qps)... nobody is just "flipping a config" and sending the protocol out the door.

by erickj 8y ago

Meai 8y ago

I think adoption could be improved so much if the standards commitee released a javascript and C library for whatever they end up deciding. The javascript implementation should be heavily commented, super easy to understand and basically be the documentation of the standard and the C library (or libraries) should be performance tuned tiny modules that can be called upon by other languages. You may ask: Why javascript? Well the reasons are too many to enumerate and immediately 50 people would come here to disagree and say that they prefer their own language but basically it boils down to there being no fancy features to get in the way of understanding an algorithm. The reasons for C are almost the same, it's easy to understand but with the added advantage of being interopable with just about anything on the planet and fast. Even for http2 after many many years and lots of searching, you basically have to use nghttp2 as the only usable http2 C library and its source code is mixed together with various c++ components. Isn't it always like this? I mean don't these standards committees have to write the algorithms out anyway, why not make a usable module out of it in source code form? I suspect it's because in reality the standard gets sponsored by Google whose engineers have already written c++ implementations that are tied to dozens of their own libraries and subcomponents and integrated into the chrome build system etc etc. Well that still doesn't change the fact that it would be better for everyone else if they released a simple to understand implementation in js and C.

21 8y ago

I'm not sure what you're talking about. Supporting HTTP/2.0 for my site was literally just adding the "http2" word to the listen directive of nginx. Since it's also used as a reverse proxy, the backend app server remained HTTP/1.1. And you still notice the difference in site loading speed if your site has a lot of static assets.

erickj 8y ago
How much traffic does your site serve? I'm not saying that turning the feature on is difficult. Anyone reading hacker news can go and configure their webserver to start serving this traffic.... but I can tell you that a site serving serious production loads (let's just say 100 qps)... nobody is just "flipping a config" and sending the protocol out the door.