4 ms·
I've seen a number of comments about http/2 and http/3 being driven by Google. The ideas originated there (SPDY and QUIC respectively) but in both cases many di
by moderation 8y ago
I've seen a number of comments about http/2 and http/3 being driven by Google. The ideas originated there (SPDY and QUIC respectively) but in both cases many different entities backed the ideas and formulated specifications in IETF settings. I'm not sure I buy that somehow Google managed to hoodwink the people that toiled on these specifications in a non-Google environment and managed to influence them in such a way that the output was beneficial to their nefarious goals.
There are already quite a number of http/3 implementations from non-Google companies and projects [0]. Cloudflare seem to be big backers of http/3 [1]. There were some other articles today that are generally positive on the http/3 approach. One was from Tim Bray at AWS [2] and the other from @ErrataRob [3].
0. https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/quicwg/base-drafts/wiki/Implementations
1. https://cloudflare-quic.com/ https://cloudflare-quic.com/
2. https://www.tbray.org/ongoing/When/201x/2018/11/18/Post-REST#p-11 https://www.tbray.org/ongoing/When/201x/2018/11/18/Post-REST...
3. https://blog.erratasec.com/2018/11/some-notes-about-http3.html https://blog.erratasec.com/2018/11/some-notes-about-http3.ht...
- dogecoinbase 8y agoCloudflare seem to be big backers of http/3 [1]. Having the second-largest traffic analyzer on board would seem like more of a cautionary negative than a positive to me.
- nijave 8y agoTinfoil hat off for a second it makes more sense Cloudflare and Google are backing these protocols because they're more efficient which means lower infrastructure costs. They both terminate traffic already so can already see everything regardless of the protocol used.
- anfilt 8y agoI am not the person you responded to. However, I would only be considering things that people in general are eager to use not just a few big companies. Most users of HTTP have never been too concerned with it's overhead. Except maybe the way cookies have been design. It definitely has problems, but most peoples problems are not googles or cloud flares.
- comex 8y agoSo we should be against something that makes all sites faster... because big companies care more about their sites being fast? That just seems like spite to me. If anything, smaller sites have more to gain from HTTP/2 and HTTP/3 than the likes of Google. For example: - Both HTTP/2 and HTTP/3 seek to reduce the number of round trips, mitigating latency between the user and the server. Now, from Google's perspective, the "server" is the nearest load balancer in a globally distributed network, which is probably geographically close to wherever the user is. Thus, users with good Internet connections typically have low enough latency for the improvements not to matter much. But Google still cares about latency because of users with poor internet connections – such as anyone on a cell network in a spotty coverage area. Well, poor connections affect all sites equally. But small sites tend to not be fully distributed; they probably only have a single origin server for application logic, and perhaps a single server period, if they're not using a CDN. That means a fixed geographic location, which will have higher latency to users farther away even if they have a good connection – thus more benefit from latency mitigation. - QUIC can send stream data in the first packet sent to the server, without having to go through a SYN/ACK handshake first. TCP Fast Open lets plain old TCP do the same thing – but only when connecting to a server you've seen in the recent past (and retrieved an authentication tag from). Thus, QUIC is faster when connecting to a server for the first time – which affects smaller sites a lot more than Google.
- rgbrenner 8y agoMost users of HTTP have never been too concerned with it's overhead End users complain all the time about latency. And that includes the latency to your small website hosted on a single server hundreds of milliseconds from your visitor... certainly more than it includes google's websites. What you really mean is that small website operators generally don't care that their visitors are irritated by how slow their website is... and just brush it off and ignore it because they have no solution to the problem. Maybe you should consider h2 as being for the benefit of visitors across the internet, and a benefit for those who care about performance. It says it all that even though h2 is not required, small website have adopted it across the globe... now at 1/3rd of all websites, and growing.
- rocqua 8y agoI don't think cloudfare really does traffic analysis. At least nowhere near the level that google does. It is not their core business.
- auslander 8y agoWhy then they offer free fully functional CDN-like service, free SSL ? Data is new oil, and CF has all data in plaintext - your logins/passwords included.
- jgrahamc 8y agoBecause... a. It's really cheap for us to offer that service b. Lots of those free customers end up upgrading, paying for extras, etc. Between a and b offering the free service makes sense. We make money from the customers who pay us for our service (https://www.cloudflare.com/plans/ https://www.cloudflare.com/plans/), not from doing something nefarious with data. We'd be shooting ourselves in the foot if we did because that data is our customers data. We need to be very careful with that or we'd lose trust and not be in business. Also, free means anybody can try the service and kick the tires. Often those people turn out to me the CIO, CSO, CISO, CTO, ... of big corp.
- auslander 8y agoThe plaintext thing is just too sensitive, and your free service offer makes the reach too wide. Could you be compelled, by warrant, to provide all plaintext traffic from a single user IP?
- deleted 8y ago[deleted]
- anfilt 8y agoIt's just an example of how much weight Google is able to throw around. That's a just one part of what would be needed for a browser. The more parts you add the harder it becomes to build a browser. Also I have read about QUIC there are some things that are interesting about it. However, there are things that I don't like. Moreover, this was something I read from IETF mail archive: "That QUIC isn't yet proven. That's true, but the name won't be formalised or used on the wire until the RFC is published, so we have a good amount of time to back away. Even then, if it fails in the market, we can always skip to HTTP/4 one day, if we need to."[1] I find that pretty concerning. If it does not pan out we can just skip over. That's still something someone has to implement even it's not used much. I would only be considering things that people in general are eager to use not just a few big companies. [1] https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0...
- deleted 8y ago[deleted]
- rgbrenner 8y agoThat's still something someone has to implement even it's not used much. Not true. This is why alpn and the upgrade header exist. You do not need to implement any of the new protocols, and you can certainly skip a version if you don't think it's worth the effort.