28 ms·

Chrome is deploying HTTP/3 and IETF QUIC

386 points by caution 6y ago

ohnoesjmr 6y ago
Implementing QUIC is not trivial, so I suspect it will be years until it gets reasonable adoption in standard frameworks and languages that prefer not to interop with C.
- amq 6y ago
  I don't think HTTP/3 is even intended as a general-purpose HTTP replacement. Even HTTP/2 is overly complex, so HTTP/1 will most likely stay as a fallback for the foreseeable future.
  - chrismorgan 6y ago
    Sure it is (though it depends a little what you mean). I expect HTTP/2 usage to disappear, leaving HTTP/1.1 and HTTP/3 as the main versions in use. For HTTP traffic (as distinct from other upgraded protocols like WebSocket) HTTP/2 is mostly better for users than HTTP/1.1, but TCP head-of-line blocking is its one particularly serious problem. For users, I would characterise HTTP/3 as generally just the best of both worlds, and once you have it there there’s no reason at all for HTTP/2. HTTP/1.1 will remain popular indefinitely for compatibility with older servers and clients that aren’t being updated to the latest stuff, and for HTTP upgrading mechanisms.
    - anderspitman 6y ago
      I'm excited about HTTP/3, but I sincerely hope HTTP/1.1 never goes away. There's something important about being able to write a compliant web server in a couple lines of code using nothing but a TCP socket.
      - steveklabnik 6y ago
        While this is true... it's also not true. Like, the final chapter of the Rust book does this. We implement a really minimal HTTP server. Turns out that, even though what we do is spec compliant, some versions of Chrome don't properly deal with the responses we give, which has had to lead to errata. Implementing the web means knowing the implementation details of the major implementations, and following them, sadly. It's not actually that simple.
        anderspitman 6y ago
        In a way, you're actually supporting my deeper point, which is that the web (and more particularly the internet) is bigger than google, even though they're dominant at the moment. If Chrome doesn't support my compliant minimal web server, that doesn't mean it isn't useful, or even that I should have to change it. HTTP is the lingua franca of the internet. We need to keep a simple, text-based version of it around, so that the barrier to entry for competing with the big boys remains reasonable. We've already lost that fight with browsers, but HTTP is still in a pretty good place. Even HTTP/3 is reasonable for a small startup to implement. And if you can't manage that, you can implement HTTP/1.1 and sacrifice some performance for simplicity.
        steveklabnik 6y ago
        > If Chrome doesn't support my compliant minimal web server, that doesn't mean it isn't useful, or even that I should have to change it. This is probably where we differ; I pretty much think that you do have to do this in this situation. Or at least, like, sure, you don't have to, but you lose a significant amount of audience, which is one of the major points of bothering with the web in the first place.
        anderspitman 6y ago
        I mean I certainly take your point. If I want the biggest audience today, I need to support chrome. But if that's my goal I'm probably not writing my own server anyway. In terms of building things today, I'm more saying that if you need an internet protocol for moving data around, HTTP is a pretty dang good choice. It has some cruft, but if you were to start making a replacement from scratch you would end up with a large subset of HTTP/1.1. That's not true of HTTP/3. You simply don't need the complexity for a large number of useful tasks. Now, in terms of the future. I think that the internet will long outlive the web (at least as we currently conceive of the web), and I think HTTP as a transport layer will outlive it as well. In that future, I want HTTP/1.1 to still be a thing.
- sayrer 6y ago
  Google first shipped QUIC in 2013. https://blog.chromium.org/2013/06/experimenting-with-quic.html https://blog.chromium.org/2013/06/experimenting-with-quic.ht...
- steveklabnik 6y ago
  There are like, three different QUIC implementations in Rust. And one of them is by (and being used by) Cloudflare, so it's going to have pretty significant production use. (The others may be as well but I am less familiar with where they're used) * https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche * https://github.com/djc/quinn https://github.com/djc/quinn * https://github.com/mozilla/neqo/ https://github.com/mozilla/neqo/
- becauseiam 6y ago
  There are multiple implementations and their interoperability is tested [1], with some implementations already having bindings to higher level languages (aioquic) or into existing servers (nginx). 1: https://interop.seemann.io https://interop.seemann.io
jeffbee 6y ago
Anyone know why there's no new URL scheme for HTTP/3? We didn't rely on Alt-Svc headers for switching to HTTPS. We gave it its own scheme. Why aren't we doing that for HTTP/3?
- mercora 6y ago
  not sure about any details but i would guess its because for HTTPS there are security implications by doing negotiation in the clear whereas this probably doesn't have those.
- floatingatoll 6y ago
  Users don’t need to care about the difference between HTTP, HTTP2, and HTTP3. It’s relevant only to browser engineers and server operators. There’s no reason to ask everyone on the planet to change “https:” to “http3:” when we still can’t even reliably complete the “http:” to “https:” transition. We’ve learned that users simply do not care at all about “http:” or “https:”. We shouldn’t have to ask people to update their QR codes for HTTP3 just because we updated the protocol. Should we have introduced ftpp:// for passive FTP to distinguish it from classic FTP? No: it would only confuse users, cause frustration for pages linking to FTP urls, and both servers and clients are perfectly capable of negotiating this silently without surfacing it to the user. In general the pushback with HTTP3 is that site operators would rather not have to do the extra work to enable it. But from a user’s perspective, there is no work to enable it. It’s just https:// https:// like always and one day it gets faster. Sites that refuse to do the extra work to turn it on will be visibly slower than their peers once it’s widespread enough. If you believe that HTTP3 should have had its own URI spec, you would have needed to make that case a few years ago to the committee implementing it; it’s not going to change now. I assume their discussion about that is in the archives, and I expect it boils down to “this is not relevant to users, they should not be expected to care”.
  - jeffbee 6y ago
    But users don't type or even see the URI scheme any more. It is also an implementation detail. I just think it's weird that we've left ourselves without any way to send a client directly to an HTTP/3 site. Instead they _must_ establish a TCP connection to the site and be redirected via Alt-Svc headers to HTTP/3.
drenvuk 6y ago
Can someone provide the tradeoffs and benefits of QUIC vs WebSockets vs WebRTC? I know websockets are tcp and WebRTC requires some special tunneling logic but aside from that I don't particularly know how quic is better or different aside from using udp.
- jeffbee 6y ago
  That's it. UDP is why it's better. It disintermediates operating system developers and their badly-tuned, slowly-evolving TCP implementations.
  - pmlnr 6y ago
    Right, because all we ever need it is more complexity, no backwards compatibility, and more speed in all terms /s Come on. Networks are extremely FAST by now, TCP or not. It's the silly amount of JS computation pushed to the client that is slow, both in download speed and on the client.
    - Spivak 6y ago
      But we have backwards compatibility right now. That's, like, the whole point of the OSI model. Any device that supports UDP can handle QUIC with no fanfare like it was any other application-layer protocol because it is!
      - pmlnr 6y ago
        We have fallbacks, that's not the same as backwards compatibility. They call this HTTP3, and they shouldn't; it's not HTTP.
        Spivak 6y ago
        That was the case with HTTP2 as well though. The client can negotiate with the server about supported protocols but if a client only spoke HTTP1.1 and the server only spoke HTTP2 they simply couldn't talk. It's just that basically no servers were HTTP2 only.
deleted 6y ago
[deleted]
The_rationalist 6y ago
Where are the benchmarcks for standard tasks?
parhamn 6y ago
Those are pretty modest gains for a layer 4 change. It's going to be much harder to tool/debug this stuff. Is it expected that servers pretty much always support all the HTTP protocols or is the goal to eventually replace the earlier forms?
- ed25519FUUU 6y ago
  Unless your web traffic represents single or double digits of worldwide web traffic, I don't see why anyone would bother.
  - baggy_trough 6y ago
    You would bother if you wanted reduced latency for a better user experience.
    - leothecool 6y ago
      I don't disagree, but I still really really have a hard time caring about < 1ms of latency on a 50ms call. But, if I had to pay the electric bill on 2.5 million servers, I would definitely care about wasting resources sending extra packets.
      - throwaways885 6y ago
        That 1 ms translates to a much larger number in poor countries with everyone on 2G.
        leothecool 6y ago
        I guess I'd have to see the metrics on it in production, but my intuition is that a 2% improvement to latency would be even less noticeable on low bandwidth connections where the download times are measured in whole seconds.
        6y ago
GNOMES 6y ago
I remember a Hacker News post that many of the top Firewall vendors suggest disabling UDP over port 443. Apparently it's hard for packet inspection, restricted browsing etc in the enterprise space. Have there been any leaps in Firewall tech, or will most companies still disable this?
- microcolonel 6y ago
  > Have there been any leaps in Firewall tech, or will most companies still disable this? QUIC is explicitly designed to frustrate this sort of thing, so the enterprise will just have to choose between having and not having it, or switch from MITM to endpoint backdoors.
  - cheschire 6y ago
    Or go full BYOD and forego the network equivalent of 14th century defenses
    - thisisnico 6y ago
      Even with BYOD, you still need a firewall... Source: Am Enterprise IT.
    - unethical_ban 6y ago
      I think you underestimate the complexity of securing data in a privileged network.
    - microcolonel 6y ago
      The solution for us is total endpoint control. Our application endpoints have their own DNS root. :+ )
- driverdan 6y ago
  Defeating firewalls is a feature.
- tialaramex 6y ago
  If you do what the specification told you, in TLS 1.3 or in QUIC, you can build these products and they'll work as intended for web browsing. In TLS 1.3 there is even a whole section of the RFC (under "Invariants") that explains how to do this properly. What you end up with is two connections. A connection from the browser to your product, and then a connection from your product to the web site. Your product is in the middle and can apply any policies whatsoever that it desires. There are two things about this that vendors do not like, or which their customers do not like and the vendors would prefer somebody else take the blame for not them. 1. For this to work the browser needs to trust the product. The product will need to mint its own certificates for each site visited, and it can't make genuine ones, so it'll need to be explicitly trusted by the browser. This requires more honesty from your customer (the product's operator) in regard to their users (employees / students / visitors / whatever) where previously a product might try to snoop unobtrusively. That's no longer an option. 2. Actually doing all this heavy lifting costs money. More CPU power, more RAM, even more network bandwidth because you can't just snoop a few frames at the start of a connection you need to proxy decrypt/ re-encrypt every single byte even if you realised very quickly that it was actually fine. This makes the product more expensive, even though it's also worse because their users ask awkward questions now.
coddle-hark 6y ago
I’m not an expert but QUIC doesn’t seem like enough of an improvement over TCP to warrant replacing it, especially given that it’s even more complex. - 0-RTT handshakes are great but there’s still the problem of slow start. - QUIC’s congestion control mechanism is pretty much the same as TCP’s and doesn’t perform particularly well over e.g. mobile networks. - Mandatory TLS means it’s going to be a huge PITA if you ever need to run a quic service locally (say, in a container). - Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.
- tootie 6y ago
  Isn't there an exception explicitly for localhost?
  - coddle-hark 6y ago
    Not that I know of.
- all_usernames 6y ago
  > Mandatory TLS means it’s going to be a huge PITA Let's Encrypt!
  - coddle-hark 6y ago
    Let’s Encrypt can’t generate certificates for localhost, much less containers accessed via a local network. Sure, you can get anything to work, but it WILL be a huge PITA.
    - mahkoh 6y ago
      Let's Encrypt can generate certificates for your.domain. your.domain can in turn resolve to localhost. I've been using Let's Encrypt for websites behind a VPN for several years.
xfalcox 6y ago
Relying on Alt-Svc for HTTP/3 is really bad, so I hope Chromium is following this with https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ https://blog.cloudflare.com/speeding-up-https-and-http-3-neg... right away.
fenesiistvan 6y ago
After my opinion around 4% performance improvement doesn't justify the introduction of this more complicated protocol (maybe google knows how this benefit their ad business, like forcing everyody to https so they can increase their control over the internet, since their scripts are already included by the majority of the websites, reporting them all the important metrics, regardless of HTTPS)
- tpmx 6y ago
  It adds to a number of other great reasons to break up Google and some other big tech companies. The fact that Google is so dominant (controlling both the discovery, browser and casual video content aspects) that they can unilaterally decide on fundamental internetworking protocols is obviviously a very important issue. "U.S. House's antitrust report hints at break-up of big tech firms: lawmaker (reuters.com)" https://news.ycombinator.com/item?id=24697860 https://news.ycombinator.com/item?id=24697860
  - redant 6y ago
    This argument is false. Google contributed the protocol to IETF. Where the competitors introduced a lot of incompatible changes, which Google then implemented. The blog post is literally Google's announcement that they are moving to that public standard.
    - tpmx 6y ago
      What other company could have done this? Was the fact that Google controls so much of the entire usage chain (chrome, google.com, youtube.com) irrelevant?
      - bb88 6y ago
        Back in the 90s Microsoft had been rumored to be developing their own proprietary TCP replacement -- back when IIS was the king of the world. They could have shut off a large portion of IIS traffic to those that weren't running Internet Explorer.
Randor 6y ago
With both a DNS-over-HTTP client and potentially a DNS-over-QUIC in the browser and serving advertisements over QUIC... there is a good chance that the world will see unblockable advertisements in our near future. I don't think this is a good idea... about a decade ago... as a research project I ran honeypot farm of 13 machines to learn more about malware. The honeypot machines were autonomously surfing the net, parsing the DOM and choosing random links. I ran them in a sandbox and was getting weekly malware hits. Much to my surprise... most of the malware was coming over advertisement networks on shady websites.
- judge2020 6y ago
  You can still define a custom HTTPS endpoint[0], you just need to trust (within Windows) the self-signed certificate your pihole/etc device has, in order to use it on Chrome; your endpoint setting isn't messed with when you select 'enhanced protection' or anything[1]. The only downside to this is that rogue IoT devices or hacked IoT devices can easily get around DNS filtering, but that was already possible before DoH by using or running some benign free public http api for dns lookups. 0: https://i.judge.sh/hollow/Lyra/chrome_hxURk11GDb.png https://i.judge.sh/hollow/Lyra/chrome_hxURk11GDb.png 1: https://i.judge.sh/bony/Fleet/s4HD5OqNvf.gif https://i.judge.sh/bony/Fleet/s4HD5OqNvf.gif
- tialaramex 6y ago
  > unblockable advertisements in our near future. Why? The user agent will still be able to choose what to display, and protocol improvements don't prevent you choosing an agent that has your interests at heart. Using secure transport means nobody else gets to decide, and I certainly have a long list of people I don't want deciding whether I see things, so that helps.
  - swiley 6y ago
    > The user agent will still be able to choose what to display, Will it? Even on Mozilla Firefox (which fewer and fewer sites are tested against) you're pretty limited in controlling this. I have zero faith that google will keep that working in chrome
The_rationalist 6y ago
Unrelated: chromium 86 bring the backforward cache which make back navigation instantaneous in many cases, this was I believe, the biggest optimization that was Firefox only
Aachen 6y ago
Has the amplification attack been solved recently? Last I checked the spec still said "at most 3x amplification" (which I expect will be enough for attackers) and the server implementation that I was testing went well beyond that. If that's not solved and this gets deployed on a few big networks, I can already tell you what the next popular protocol will be for taking down websites.
- coddle-hark 6y ago
  No, it hasn’t been solved and it won’t be because it can’t be solved without adding more round trips to the handshake. It’ll be down to firewalls to stop this from happening.
  - Aachen 6y ago
    It could use the STK (source address token), which it creates for 0RTT anyway, to identify which sessions to respond to. New sessions from a source IP which shows elevated rates could be dropped X-1/X times (e.g. X=5) because a legitimate client will retry and obtain an STK in, on average, X attempts. This would reduce the amplification factor to below one, assuming the client handshake is <X times smaller than the server handshake (which includes a cert). Firewalls can't block this because then you introduce a denial of service vector. If I can block anyone on the Internet from accessing a service because the service's firewall blocks the source IP... this is why this isn't a solution for dns and other udp protocols' amplification attacks, either. Otherwise we'd block offenders and be done with the problem of amplified DDoS attacks really quickly. The problem is allowing legitimate clients to pass that look (nearly?) identical to what the attacker sends. The STK seems to solve this (in a similar way to TCP, while allowing for 0RTT after the client met the server once), so let's use it? Edit: just noticed you posted another comment critical of QUIC. To be clear, this isn't "QUIC is amazing, let's use this STK and it'll be great". I don't know enough about it for that. Heck, I like the textual property of HTTP/1 and would be fine keeping that as well. I just noticed this security problem with HTTP/3 and would prefer to see it fixed before widespread deployment given how heavily similar services are abused.
The_rationalist 6y ago
Those incremental gains doesn't seems much better than what linux Tcp improvments get each year, especially if turning on state of the art congestion / bufferbloat algorithms. Also Tcp fast open is ridiculously old and I can't see how mainstream equipment still wouldn't support it on average.
The_rationalist 6y ago
If only HTTP3 what based on sctp instead
- M2Ys4U 6y ago
  SCTP will never be deployed outside of small networks. There are too many broken machines on the Internet that can't deal with anything that isn't TCP or UDP.
02020202 6y ago
i would like to see peformance comparison with SRT for example or other udp-based protocol. i mean, it its good for video, it must be good for web too.
djhaskin987 6y ago
Does anyone else think it's weird/futile that they're building a protocol over UDP? QUIC is disabled on our corporate network, simply because the network firewall/SSL inspector can't see what's going on, and can't regulate traffic, so it just blocks all UDP. our internet still works because sites see that QUIC doesn't work and fall back to TCP. Heaven forbid the entire web moves to QUIC or we'd be in trouble.
- sammy2244 6y ago
  I think its weird/futile to block all UDP traffic.
  - gravypod 6y ago
    It's strangely common. As someone who has worked in a few IoT companies that ship devices that run on other people's networks the amount of enterprise gear that just drops all UDP as a default is astonishing. Every single IoT device I've worked on has had some custom, hand rolled, NTP-over-HTTP to get around RTC failures.
  - mr_toad 6y ago
    Many enterprises have a “block everything” mentality and only allow traffic on “expected” ports and protocols.
- judge2020 6y ago
  TCP+UDP will probably be the norm for a decade once it's rolled out, and with this being announced for Chrome, it'll only show the market that there's demand for UDP packet inspection - not that that's the best solution to DLP; endpoint security and MDM gives the most insight and solves the problem of middlemen [who might be a trusted local network operator, or might be a government-controlled ISP] being able to inspect/limit traffic.
- agwa 6y ago
  Frankly, that would be your problem. Enterprise intransigence should not hold back the rest of the Internet.
Ericson2314 6y ago
I am generally pro QUIC, but after seeing https://tools.ietf.org/html/draft-ietf-quic-datagram-01 https://tools.ietf.org/html/draft-ietf-quic-datagram-01 I have to ask, why not have all the streaming stuff on top of this? Then the layering looks like: 1: connections management + encryption 2: streams and multiplexing Seems pretty good to me?
- Matthias247 6y ago
  There's some efficiency gains from having streams at a lower level. E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram. Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data.
  - Ericson2314 6y ago
    > E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram. But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers? > Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data. QUIC packets are individually encrypted so more metadata can be encrypted too. And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes?
    - Matthias247 6y ago
      > But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers? Imagine the following: The users writes a few bytes on a stream, those get immediately transmitted and lost. Before the retransmission, the user enqueues more data. The Quic implementation has now the opportunity to merge everything into a single Quic "packet", and even a single Quic "frame", and send everything together. If those things were on top of datagrams, it might need to send the whole datagram again? There are also other scenarios: E.g. the stream getting reset while transmission is in progress. If that happens none of those data chunks will ever have to be retransmitted. I feel like having an additional layer here will make this harder and less efficient. > And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes? It does! All the TLS/handshake data is transferred in CRYPTO frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#section-19.6 https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). CRYPTO frames are more or less the same as STREAM frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#section-19.8 https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). They both represent an ordered reliable byte stream - just in different namespaces. This is important for the handshake, since the TLS implementation will act on this ordered stream data and kind of treat it as a TLS data over TCP stream.
garganzol 6y ago
The level of complexity of this thing goes way beyond the HTTP over CORBA experiment that took place at the end of millennium. The point is: despite CORBA's convoluted complexity, at least HTTP + CORBA experiment was somewhat sane as it allowed to use multiplexed connections right out of the box and relied upon standard network capabilities without reinventing the wheel. All that in 1999 or so. DNS over HTTPS, QUIC et al look nothing less than a monopolistic attack on open web. Google really wants to own the Internet.
- lgats 6y ago
  not sure why DNS over HTTPS or QUIC are monopolistic attacks, both already have several open-source options for clients and servers: https://awesomeopensource.com/projects/quic https://awesomeopensource.com/projects/quic https://caddyserver.com/ https://caddyserver.com/ https://github.com/m13253/dns-over-https https://github.com/m13253/dns-over-https
  - otabdeveloper4 6y ago
    Microsoft Office has 'several open-source options' too. They're all nigh-unusable because the MS Office so-called "standards" are so convoluted and under-specified as to be practically useless.
evolve2k 6y ago
“Today this changes. We've found that IETF QUIC significantly outperforms HTTP over TLS 1.3 over TCP. In particular, Google search latency decreases by over 2%. YouTube rebuffer time decreased by over 9%, while client throughput increased by over 3% on desktop and over 7% on mobile.“ This is the most sickening sentence for me. The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’. This is just blatant exploitation that’s occurring as there is too much centralised ownership. In my opinion this is predatory behaviour packaged up as open source good for all.
- dheera 6y ago
  Yep, because we've built an economy based on idiotic fiduciary duty instead of duty to technologically advance the civilization. Myopic focus is exactly what the system rewards.
  - aaronblohowiak 6y ago
    What utility function would you propose?
    - dheera 6y ago
      I don't have a well-defined solution, but I think the notion of companies selling shares to people in armchairs who neither necessarily use nor feel the side effects of the product is an issue. To a great degree I don't believe in 100% free market valuation of companies. Rather, I think the people most affected by the company (positively or negatively) should have the biggest say in its value. There also needs to be some adjustment to that valuation based on greater good delivered by the company. If they killed off a bunch of smaller businesses, that's a negative. If they emitted a bunch of carbon, that's a negative. If they caused injuries or deaths, that's a negative. If they contributed to open source products that enabled other companies to exist, that's a positive. Carbon taxes are one step at capturing one very small aspect of this "greater good" factor, but there need to be other adjustments as well. Another vague idea I've had is a hypothetical economic system in which the government doesn't print money (or isn't the only one printing money) but rather money is brought to existence by certain good deeds. Money can also be traded for goods and services, of course, in addition. So while you could make money by selling food or selling phones, you could also literally print your own money (translate: government hands it to you, in a controlled fashion) by sucking carbon out of the environment and proving that you did that to claim your money.
fenollp 6y ago
While this seems good to have a more efficient transport, I can't make sense of this > Since the subsequent IETF drafts 30 and 31 do not have compatibility-breaking changes, we currently are not planning to change the over-the-wire identifier. Are there slow-moving internal software at Google that relies on this nonce? This looks like the kind of thing that some clients will tend to rely on (for a reason yet unknown). That's how clients grow the standard in unintended ways, no? On another note: 3. optionally, the trailer field section, if present, sent as a single HEADERS frame. I see you're paving the way for gRPC on the Web (of browsers) by adding trailers (a header sent after the body), which is not supported today for HTTP/1 not /2 by at least the top 3 browser vendors in volume. I'm divided: I'd be glad to get rid of grpc-gateway and websockets but isn't proto-encoded communication bad for the open Web /in principle/? Maybe it's only a tooling problem.
- gravypod 6y ago
  I think there's a large volume of tools that can be built that will make things much more discoverable as we go along this route. Things like the gRPC reflection, health checks, etc can all be instrumented in tooling with no guess work as to how to directly talk to any API that implements it. No guessing if it's `GET /healthz` or `GET /healthcheck` etc. There's a lot of magic you can do with protos. At my current company we're even generating forms/UIs entirely off of proto message definitions for things like configs. Engineers no longer need to think about how to make something work cross language, manually wiring up a UI, etc. I cant wait to see what doors this opens up for gRPC on the browser as that will bring many more OSS devs into the ecosystem.
gravypod 6y ago
Does anyone know when HTTP/3 is going to get wider support in gRPC. There's an open issue in the github project about this [0]. In IoT use cases where you want to do bi-directional stream of data to/from a location getting rid of some head of line blocking will make me a happy camper. 0 - https://github.com/grpc/grpc/issues/19126 https://github.com/grpc/grpc/issues/19126
ssss11 6y ago
Is this being added to Chromium code? Its hard to tell if its being added (and in which release) or if parts of it or all of it are already in Chrome or Chromium and are just being enabled now
- jrockway 6y ago
  It's in there (and has been for a while). You can open your network inspector, enable the "Protocol" heading, and look for "h3" requests. For example, if I visit cloudflare.com right now, I see a bunch of requests with protocol "h3-29". If I visit Google maps, I see requests with "h3-Q050". (The part after the h3- is the draft number; Cloudflare's servers use draft 29; Google uses their own thing which identifies itself as Q050.)
forgotmypw17 6y ago
I think it's safe to accept that this will become adopted and then HTTP/1.1 will get the cross-out treatment?..
- tialaramex 6y ago
  It is safe to conclude that eventually drafts will settle down further, QUIC and HTTP/3 will pass last call and get published, maybe in 2021. I don't know what "the cross-out treatment" is exactly but if you mean the UI behaviour where non-secure contexts get a red line or the words "Not Secure" then there's no reason that will change. HTTP/1.1 over TLS is still fine, HTTP/1.1 plaintext was already treated that way. The newer protocol isn't really "more secure", than HTTP/1.1 over TLS, but it is as this article notes, faster and more capable.
nly 6y ago
Does anyone know what the maturity of standalone C-compatible implementations is like? Curl seem to be evaluating two different stacks: ngtcp2+nghttp3 (C, seems to be from developers behind aria2) and Quiche (Rust, from Cloudflare) Then there's Google's C++ QUICHE implementation which seems to not be used by anyone outside of Chromium (Even node.js apparently isn't using this, unless the code is just old). There are several more: https://en.wikipedia.org/wiki/HTTP/3#Libraries https://en.wikipedia.org/wiki/HTTP/3#Libraries It's a bit of a mess, and until Curl makes a decision I'm not sure where to go.

386 points by caution 6y ago

Implementing QUIC is not trivial, so I suspect it will be years until it gets reasonable adoption in standard frameworks and languages that prefer not to interop with C.

amq 6y ago
I don't think HTTP/3 is even intended as a general-purpose HTTP replacement. Even HTTP/2 is overly complex, so HTTP/1 will most likely stay as a fallback for the foreseeable future.
- chrismorgan 6y ago
  Sure it is (though it depends a little what you mean). I expect HTTP/2 usage to disappear, leaving HTTP/1.1 and HTTP/3 as the main versions in use. For HTTP traffic (as distinct from other upgraded protocols like WebSocket) HTTP/2 is mostly better for users than HTTP/1.1, but TCP head-of-line blocking is its one particularly serious problem. For users, I would characterise HTTP/3 as generally just the best of both worlds, and once you have it there there’s no reason at all for HTTP/2. HTTP/1.1 will remain popular indefinitely for compatibility with older servers and clients that aren’t being updated to the latest stuff, and for HTTP upgrading mechanisms.
  - anderspitman 6y ago
    I'm excited about HTTP/3, but I sincerely hope HTTP/1.1 never goes away. There's something important about being able to write a compliant web server in a couple lines of code using nothing but a TCP socket.
    - steveklabnik 6y ago
      While this is true... it's also not true. Like, the final chapter of the Rust book does this. We implement a really minimal HTTP server. Turns out that, even though what we do is spec compliant, some versions of Chrome don't properly deal with the responses we give, which has had to lead to errata. Implementing the web means knowing the implementation details of the major implementations, and following them, sadly. It's not actually that simple.
      - anderspitman 6y ago
        In a way, you're actually supporting my deeper point, which is that the web (and more particularly the internet) is bigger than google, even though they're dominant at the moment. If Chrome doesn't support my compliant minimal web server, that doesn't mean it isn't useful, or even that I should have to change it. HTTP is the lingua franca of the internet. We need to keep a simple, text-based version of it around, so that the barrier to entry for competing with the big boys remains reasonable. We've already lost that fight with browsers, but HTTP is still in a pretty good place. Even HTTP/3 is reasonable for a small startup to implement. And if you can't manage that, you can implement HTTP/1.1 and sacrifice some performance for simplicity.
        steveklabnik 6y ago
        > If Chrome doesn't support my compliant minimal web server, that doesn't mean it isn't useful, or even that I should have to change it. This is probably where we differ; I pretty much think that you do have to do this in this situation. Or at least, like, sure, you don't have to, but you lose a significant amount of audience, which is one of the major points of bothering with the web in the first place.
        anderspitman 6y ago
        I mean I certainly take your point. If I want the biggest audience today, I need to support chrome. But if that's my goal I'm probably not writing my own server anyway. In terms of building things today, I'm more saying that if you need an internet protocol for moving data around, HTTP is a pretty dang good choice. It has some cruft, but if you were to start making a replacement from scratch you would end up with a large subset of HTTP/1.1. That's not true of HTTP/3. You simply don't need the complexity for a large number of useful tasks. Now, in terms of the future. I think that the internet will long outlive the web (at least as we currently conceive of the web), and I think HTTP as a transport layer will outlive it as well. In that future, I want HTTP/1.1 to still be a thing.
sayrer 6y ago
Google first shipped QUIC in 2013. https://blog.chromium.org/2013/06/experimenting-with-quic.html https://blog.chromium.org/2013/06/experimenting-with-quic.ht...
steveklabnik 6y ago
There are like, three different QUIC implementations in Rust. And one of them is by (and being used by) Cloudflare, so it's going to have pretty significant production use. (The others may be as well but I am less familiar with where they're used) * https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche * https://github.com/djc/quinn https://github.com/djc/quinn * https://github.com/mozilla/neqo/ https://github.com/mozilla/neqo/
becauseiam 6y ago
There are multiple implementations and their interoperability is tested [1], with some implementations already having bindings to higher level languages (aioquic) or into existing servers (nginx). 1: https://interop.seemann.io https://interop.seemann.io

jeffbee 6y ago

Anyone know why there's no new URL scheme for HTTP/3? We didn't rely on Alt-Svc headers for switching to HTTPS. We gave it its own scheme. Why aren't we doing that for HTTP/3?

mercora 6y ago
not sure about any details but i would guess its because for HTTPS there are security implications by doing negotiation in the clear whereas this probably doesn't have those.
floatingatoll 6y ago
Users don’t need to care about the difference between HTTP, HTTP2, and HTTP3. It’s relevant only to browser engineers and server operators. There’s no reason to ask everyone on the planet to change “https:” to “http3:” when we still can’t even reliably complete the “http:” to “https:” transition. We’ve learned that users simply do not care at all about “http:” or “https:”. We shouldn’t have to ask people to update their QR codes for HTTP3 just because we updated the protocol. Should we have introduced ftpp:// for passive FTP to distinguish it from classic FTP? No: it would only confuse users, cause frustration for pages linking to FTP urls, and both servers and clients are perfectly capable of negotiating this silently without surfacing it to the user. In general the pushback with HTTP3 is that site operators would rather not have to do the extra work to enable it. But from a user’s perspective, there is no work to enable it. It’s just https:// https:// like always and one day it gets faster. Sites that refuse to do the extra work to turn it on will be visibly slower than their peers once it’s widespread enough. If you believe that HTTP3 should have had its own URI spec, you would have needed to make that case a few years ago to the committee implementing it; it’s not going to change now. I assume their discussion about that is in the archives, and I expect it boils down to “this is not relevant to users, they should not be expected to care”.
- jeffbee 6y ago
  But users don't type or even see the URI scheme any more. It is also an implementation detail. I just think it's weird that we've left ourselves without any way to send a client directly to an HTTP/3 site. Instead they _must_ establish a TCP connection to the site and be redirected via Alt-Svc headers to HTTP/3.

drenvuk 6y ago

Can someone provide the tradeoffs and benefits of QUIC vs WebSockets vs WebRTC? I know websockets are tcp and WebRTC requires some special tunneling logic but aside from that I don't particularly know how quic is better or different aside from using udp.

jeffbee 6y ago
That's it. UDP is why it's better. It disintermediates operating system developers and their badly-tuned, slowly-evolving TCP implementations.
- pmlnr 6y ago
  Right, because all we ever need it is more complexity, no backwards compatibility, and more speed in all terms /s Come on. Networks are extremely FAST by now, TCP or not. It's the silly amount of JS computation pushed to the client that is slow, both in download speed and on the client.
  - Spivak 6y ago
    But we have backwards compatibility right now. That's, like, the whole point of the OSI model. Any device that supports UDP can handle QUIC with no fanfare like it was any other application-layer protocol because it is!
    - pmlnr 6y ago
      We have fallbacks, that's not the same as backwards compatibility. They call this HTTP3, and they shouldn't; it's not HTTP.
      - Spivak 6y ago
        That was the case with HTTP2 as well though. The client can negotiate with the server about supported protocols but if a client only spoke HTTP1.1 and the server only spoke HTTP2 they simply couldn't talk. It's just that basically no servers were HTTP2 only.

deleted 6y ago

[deleted]

The_rationalist 6y ago

Where are the benchmarcks for standard tasks?

parhamn 6y ago

Those are pretty modest gains for a layer 4 change. It's going to be much harder to tool/debug this stuff. Is it expected that servers pretty much always support all the HTTP protocols or is the goal to eventually replace the earlier forms?

ed25519FUUU 6y ago
Unless your web traffic represents single or double digits of worldwide web traffic, I don't see why anyone would bother.
- baggy_trough 6y ago
  You would bother if you wanted reduced latency for a better user experience.
  - leothecool 6y ago
    I don't disagree, but I still really really have a hard time caring about < 1ms of latency on a 50ms call. But, if I had to pay the electric bill on 2.5 million servers, I would definitely care about wasting resources sending extra packets.
    - throwaways885 6y ago
      That 1 ms translates to a much larger number in poor countries with everyone on 2G.
      - leothecool 6y ago
        I guess I'd have to see the metrics on it in production, but my intuition is that a 2% improvement to latency would be even less noticeable on low bandwidth connections where the download times are measured in whole seconds.
        6y ago

GNOMES 6y ago

I remember a Hacker News post that many of the top Firewall vendors suggest disabling UDP over port 443. Apparently it's hard for packet inspection, restricted browsing etc in the enterprise space. Have there been any leaps in Firewall tech, or will most companies still disable this?

microcolonel 6y ago
> Have there been any leaps in Firewall tech, or will most companies still disable this? QUIC is explicitly designed to frustrate this sort of thing, so the enterprise will just have to choose between having and not having it, or switch from MITM to endpoint backdoors.
- cheschire 6y ago
  Or go full BYOD and forego the network equivalent of 14th century defenses
  - thisisnico 6y ago
    Even with BYOD, you still need a firewall... Source: Am Enterprise IT.
  - unethical_ban 6y ago
    I think you underestimate the complexity of securing data in a privileged network.
  - microcolonel 6y ago
    The solution for us is total endpoint control. Our application endpoints have their own DNS root. :+ )
driverdan 6y ago
Defeating firewalls is a feature.
tialaramex 6y ago
If you do what the specification told you, in TLS 1.3 or in QUIC, you can build these products and they'll work as intended for web browsing. In TLS 1.3 there is even a whole section of the RFC (under "Invariants") that explains how to do this properly. What you end up with is two connections. A connection from the browser to your product, and then a connection from your product to the web site. Your product is in the middle and can apply any policies whatsoever that it desires. There are two things about this that vendors do not like, or which their customers do not like and the vendors would prefer somebody else take the blame for not them. 1. For this to work the browser needs to trust the product. The product will need to mint its own certificates for each site visited, and it can't make genuine ones, so it'll need to be explicitly trusted by the browser. This requires more honesty from your customer (the product's operator) in regard to their users (employees / students / visitors / whatever) where previously a product might try to snoop unobtrusively. That's no longer an option. 2. Actually doing all this heavy lifting costs money. More CPU power, more RAM, even more network bandwidth because you can't just snoop a few frames at the start of a connection you need to proxy decrypt/ re-encrypt every single byte even if you realised very quickly that it was actually fine. This makes the product more expensive, even though it's also worse because their users ask awkward questions now.

coddle-hark 6y ago

I’m not an expert but QUIC doesn’t seem like enough of an improvement over TCP to warrant replacing it, especially given that it’s even more complex. - 0-RTT handshakes are great but there’s still the problem of slow start. - QUIC’s congestion control mechanism is pretty much the same as TCP’s and doesn’t perform particularly well over e.g. mobile networks. - Mandatory TLS means it’s going to be a huge PITA if you ever need to run a quic service locally (say, in a container). - Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.

tootie 6y ago
Isn't there an exception explicitly for localhost?
- coddle-hark 6y ago
  Not that I know of.
all_usernames 6y ago
> Mandatory TLS means it’s going to be a huge PITA Let's Encrypt!
- coddle-hark 6y ago
  Let’s Encrypt can’t generate certificates for localhost, much less containers accessed via a local network. Sure, you can get anything to work, but it WILL be a huge PITA.
  - mahkoh 6y ago
    Let's Encrypt can generate certificates for your.domain. your.domain can in turn resolve to localhost. I've been using Let's Encrypt for websites behind a VPN for several years.

xfalcox 6y ago

Relying on Alt-Svc for HTTP/3 is really bad, so I hope Chromium is following this with https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ https://blog.cloudflare.com/speeding-up-https-and-http-3-neg... right away.

fenesiistvan 6y ago

After my opinion around 4% performance improvement doesn't justify the introduction of this more complicated protocol (maybe google knows how this benefit their ad business, like forcing everyody to https so they can increase their control over the internet, since their scripts are already included by the majority of the websites, reporting them all the important metrics, regardless of HTTPS)

tpmx 6y ago
It adds to a number of other great reasons to break up Google and some other big tech companies. The fact that Google is so dominant (controlling both the discovery, browser and casual video content aspects) that they can unilaterally decide on fundamental internetworking protocols is obviviously a very important issue. "U.S. House's antitrust report hints at break-up of big tech firms: lawmaker (reuters.com)" https://news.ycombinator.com/item?id=24697860 https://news.ycombinator.com/item?id=24697860
- redant 6y ago
  This argument is false. Google contributed the protocol to IETF. Where the competitors introduced a lot of incompatible changes, which Google then implemented. The blog post is literally Google's announcement that they are moving to that public standard.
  - tpmx 6y ago
    What other company could have done this? Was the fact that Google controls so much of the entire usage chain (chrome, google.com, youtube.com) irrelevant?
    - bb88 6y ago
      Back in the 90s Microsoft had been rumored to be developing their own proprietary TCP replacement -- back when IIS was the king of the world. They could have shut off a large portion of IIS traffic to those that weren't running Internet Explorer.

Randor 6y ago

With both a DNS-over-HTTP client and potentially a DNS-over-QUIC in the browser and serving advertisements over QUIC... there is a good chance that the world will see unblockable advertisements in our near future. I don't think this is a good idea... about a decade ago... as a research project I ran honeypot farm of 13 machines to learn more about malware. The honeypot machines were autonomously surfing the net, parsing the DOM and choosing random links. I ran them in a sandbox and was getting weekly malware hits. Much to my surprise... most of the malware was coming over advertisement networks on shady websites.

judge2020 6y ago
You can still define a custom HTTPS endpoint[0], you just need to trust (within Windows) the self-signed certificate your pihole/etc device has, in order to use it on Chrome; your endpoint setting isn't messed with when you select 'enhanced protection' or anything[1]. The only downside to this is that rogue IoT devices or hacked IoT devices can easily get around DNS filtering, but that was already possible before DoH by using or running some benign free public http api for dns lookups. 0: https://i.judge.sh/hollow/Lyra/chrome_hxURk11GDb.png https://i.judge.sh/hollow/Lyra/chrome_hxURk11GDb.png 1: https://i.judge.sh/bony/Fleet/s4HD5OqNvf.gif https://i.judge.sh/bony/Fleet/s4HD5OqNvf.gif
tialaramex 6y ago
> unblockable advertisements in our near future. Why? The user agent will still be able to choose what to display, and protocol improvements don't prevent you choosing an agent that has your interests at heart. Using secure transport means nobody else gets to decide, and I certainly have a long list of people I don't want deciding whether I see things, so that helps.
- swiley 6y ago
  > The user agent will still be able to choose what to display, Will it? Even on Mozilla Firefox (which fewer and fewer sites are tested against) you're pretty limited in controlling this. I have zero faith that google will keep that working in chrome

The_rationalist 6y ago

Unrelated: chromium 86 bring the backforward cache which make back navigation instantaneous in many cases, this was I believe, the biggest optimization that was Firefox only

Aachen 6y ago

Has the amplification attack been solved recently? Last I checked the spec still said "at most 3x amplification" (which I expect will be enough for attackers) and the server implementation that I was testing went well beyond that. If that's not solved and this gets deployed on a few big networks, I can already tell you what the next popular protocol will be for taking down websites.

coddle-hark 6y ago
No, it hasn’t been solved and it won’t be because it can’t be solved without adding more round trips to the handshake. It’ll be down to firewalls to stop this from happening.
- Aachen 6y ago
  It could use the STK (source address token), which it creates for 0RTT anyway, to identify which sessions to respond to. New sessions from a source IP which shows elevated rates could be dropped X-1/X times (e.g. X=5) because a legitimate client will retry and obtain an STK in, on average, X attempts. This would reduce the amplification factor to below one, assuming the client handshake is <X times smaller than the server handshake (which includes a cert). Firewalls can't block this because then you introduce a denial of service vector. If I can block anyone on the Internet from accessing a service because the service's firewall blocks the source IP... this is why this isn't a solution for dns and other udp protocols' amplification attacks, either. Otherwise we'd block offenders and be done with the problem of amplified DDoS attacks really quickly. The problem is allowing legitimate clients to pass that look (nearly?) identical to what the attacker sends. The STK seems to solve this (in a similar way to TCP, while allowing for 0RTT after the client met the server once), so let's use it? Edit: just noticed you posted another comment critical of QUIC. To be clear, this isn't "QUIC is amazing, let's use this STK and it'll be great". I don't know enough about it for that. Heck, I like the textual property of HTTP/1 and would be fine keeping that as well. I just noticed this security problem with HTTP/3 and would prefer to see it fixed before widespread deployment given how heavily similar services are abused.

The_rationalist 6y ago

Those incremental gains doesn't seems much better than what linux Tcp improvments get each year, especially if turning on state of the art congestion / bufferbloat algorithms. Also Tcp fast open is ridiculously old and I can't see how mainstream equipment still wouldn't support it on average.

The_rationalist 6y ago

If only HTTP3 what based on sctp instead

M2Ys4U 6y ago
SCTP will never be deployed outside of small networks. There are too many broken machines on the Internet that can't deal with anything that isn't TCP or UDP.

02020202 6y ago

i would like to see peformance comparison with SRT for example or other udp-based protocol. i mean, it its good for video, it must be good for web too.

djhaskin987 6y ago

Does anyone else think it's weird/futile that they're building a protocol over UDP? QUIC is disabled on our corporate network, simply because the network firewall/SSL inspector can't see what's going on, and can't regulate traffic, so it just blocks all UDP. our internet still works because sites see that QUIC doesn't work and fall back to TCP. Heaven forbid the entire web moves to QUIC or we'd be in trouble.

sammy2244 6y ago
I think its weird/futile to block all UDP traffic.
- gravypod 6y ago
  It's strangely common. As someone who has worked in a few IoT companies that ship devices that run on other people's networks the amount of enterprise gear that just drops all UDP as a default is astonishing. Every single IoT device I've worked on has had some custom, hand rolled, NTP-over-HTTP to get around RTC failures.
- mr_toad 6y ago
  Many enterprises have a “block everything” mentality and only allow traffic on “expected” ports and protocols.
judge2020 6y ago
TCP+UDP will probably be the norm for a decade once it's rolled out, and with this being announced for Chrome, it'll only show the market that there's demand for UDP packet inspection - not that that's the best solution to DLP; endpoint security and MDM gives the most insight and solves the problem of middlemen [who might be a trusted local network operator, or might be a government-controlled ISP] being able to inspect/limit traffic.
agwa 6y ago
Frankly, that would be your problem. Enterprise intransigence should not hold back the rest of the Internet.

Ericson2314 6y ago

I am generally pro QUIC, but after seeing https://tools.ietf.org/html/draft-ietf-quic-datagram-01 https://tools.ietf.org/html/draft-ietf-quic-datagram-01 I have to ask, why not have all the streaming stuff on top of this? Then the layering looks like: 1: connections management + encryption 2: streams and multiplexing Seems pretty good to me?

Matthias247 6y ago
There's some efficiency gains from having streams at a lower level. E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram. Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data.
- Ericson2314 6y ago
  > E.g. if it's known that a transmission of a particular chunk of a stream failed, the next transmission can capture that chunks plus additional data from that stream instead of just blindly retransmitting a full datagram. But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers? > Besides that the crypto and handshake parts also need streams with guaranteed delivery and ordering, since they carry TLS stream data. QUIC packets are individually encrypted so more metadata can be encrypted too. And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes?
  - Matthias247 6y ago
    > But QUIC Datagrams do have ACKs, and don't have retries. Maybe we don't want them to have ACKs, but as long as it's opt-in, is that not enough for the upper layers? Imagine the following: The users writes a few bytes on a stream, those get immediately transmitted and lost. Before the retransmission, the user enqueues more data. The Quic implementation has now the opportunity to merge everything into a single Quic "packet", and even a single Quic "frame", and send everything together. If those things were on top of datagrams, it might need to send the whole datagram again? There are also other scenarios: E.g. the stream getting reset while transmission is in progress. If that happens none of those data chunks will ever have to be retransmitted. I feel like having an additional layer here will make this harder and less efficient. > And I don't think connection establishment uses any sort of stream abstraction either since people speak of n-packet handshakes? It does! All the TLS/handshake data is transferred in CRYPTO frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#section-19.6 https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). CRYPTO frames are more or less the same as STREAM frames (https://tools.ietf.org/html/draft-ietf-quic-transport-30#section-19.8 https://tools.ietf.org/html/draft-ietf-quic-transport-30#sec...). They both represent an ordered reliable byte stream - just in different namespaces. This is important for the handshake, since the TLS implementation will act on this ordered stream data and kind of treat it as a TLS data over TCP stream.

garganzol 6y ago

The level of complexity of this thing goes way beyond the HTTP over CORBA experiment that took place at the end of millennium. The point is: despite CORBA's convoluted complexity, at least HTTP + CORBA experiment was somewhat sane as it allowed to use multiplexed connections right out of the box and relied upon standard network capabilities without reinventing the wheel. All that in 1999 or so. DNS over HTTPS, QUIC et al look nothing less than a monopolistic attack on open web. Google really wants to own the Internet.

lgats 6y ago
not sure why DNS over HTTPS or QUIC are monopolistic attacks, both already have several open-source options for clients and servers: https://awesomeopensource.com/projects/quic https://awesomeopensource.com/projects/quic https://caddyserver.com/ https://caddyserver.com/ https://github.com/m13253/dns-over-https https://github.com/m13253/dns-over-https
- otabdeveloper4 6y ago
  Microsoft Office has 'several open-source options' too. They're all nigh-unusable because the MS Office so-called "standards" are so convoluted and under-specified as to be practically useless.

evolve2k 6y ago

“Today this changes. We've found that IETF QUIC significantly outperforms HTTP over TLS 1.3 over TCP. In particular, Google search latency decreases by over 2%. YouTube rebuffer time decreased by over 9%, while client throughput increased by over 3% on desktop and over 7% on mobile.“ This is the most sickening sentence for me. The myopic internal focus. ‘Look we’ve made our new thing a standard and look it makes our products run faster’. This is just blatant exploitation that’s occurring as there is too much centralised ownership. In my opinion this is predatory behaviour packaged up as open source good for all.

dheera 6y ago
Yep, because we've built an economy based on idiotic fiduciary duty instead of duty to technologically advance the civilization. Myopic focus is exactly what the system rewards.
- aaronblohowiak 6y ago
  What utility function would you propose?
  - dheera 6y ago
    I don't have a well-defined solution, but I think the notion of companies selling shares to people in armchairs who neither necessarily use nor feel the side effects of the product is an issue. To a great degree I don't believe in 100% free market valuation of companies. Rather, I think the people most affected by the company (positively or negatively) should have the biggest say in its value. There also needs to be some adjustment to that valuation based on greater good delivered by the company. If they killed off a bunch of smaller businesses, that's a negative. If they emitted a bunch of carbon, that's a negative. If they caused injuries or deaths, that's a negative. If they contributed to open source products that enabled other companies to exist, that's a positive. Carbon taxes are one step at capturing one very small aspect of this "greater good" factor, but there need to be other adjustments as well. Another vague idea I've had is a hypothetical economic system in which the government doesn't print money (or isn't the only one printing money) but rather money is brought to existence by certain good deeds. Money can also be traded for goods and services, of course, in addition. So while you could make money by selling food or selling phones, you could also literally print your own money (translate: government hands it to you, in a controlled fashion) by sucking carbon out of the environment and proving that you did that to claim your money.

fenollp 6y ago

While this seems good to have a more efficient transport, I can't make sense of this > Since the subsequent IETF drafts 30 and 31 do not have compatibility-breaking changes, we currently are not planning to change the over-the-wire identifier. Are there slow-moving internal software at Google that relies on this nonce? This looks like the kind of thing that some clients will tend to rely on (for a reason yet unknown). That's how clients grow the standard in unintended ways, no? On another note: 3. optionally, the trailer field section, if present, sent as a single HEADERS frame. I see you're paving the way for gRPC on the Web (of browsers) by adding trailers (a header sent after the body), which is not supported today for HTTP/1 not /2 by at least the top 3 browser vendors in volume. I'm divided: I'd be glad to get rid of grpc-gateway and websockets but isn't proto-encoded communication bad for the open Web /in principle/? Maybe it's only a tooling problem.

gravypod 6y ago
I think there's a large volume of tools that can be built that will make things much more discoverable as we go along this route. Things like the gRPC reflection, health checks, etc can all be instrumented in tooling with no guess work as to how to directly talk to any API that implements it. No guessing if it's `GET /healthz` or `GET /healthcheck` etc. There's a lot of magic you can do with protos. At my current company we're even generating forms/UIs entirely off of proto message definitions for things like configs. Engineers no longer need to think about how to make something work cross language, manually wiring up a UI, etc. I cant wait to see what doors this opens up for gRPC on the browser as that will bring many more OSS devs into the ecosystem.

gravypod 6y ago

Does anyone know when HTTP/3 is going to get wider support in gRPC. There's an open issue in the github project about this [0]. In IoT use cases where you want to do bi-directional stream of data to/from a location getting rid of some head of line blocking will make me a happy camper. 0 - https://github.com/grpc/grpc/issues/19126 https://github.com/grpc/grpc/issues/19126

ssss11 6y ago

Is this being added to Chromium code? Its hard to tell if its being added (and in which release) or if parts of it or all of it are already in Chrome or Chromium and are just being enabled now

jrockway 6y ago
It's in there (and has been for a while). You can open your network inspector, enable the "Protocol" heading, and look for "h3" requests. For example, if I visit cloudflare.com right now, I see a bunch of requests with protocol "h3-29". If I visit Google maps, I see requests with "h3-Q050". (The part after the h3- is the draft number; Cloudflare's servers use draft 29; Google uses their own thing which identifies itself as Q050.)

forgotmypw17 6y ago

I think it's safe to accept that this will become adopted and then HTTP/1.1 will get the cross-out treatment?..

tialaramex 6y ago
It is safe to conclude that eventually drafts will settle down further, QUIC and HTTP/3 will pass last call and get published, maybe in 2021. I don't know what "the cross-out treatment" is exactly but if you mean the UI behaviour where non-secure contexts get a red line or the words "Not Secure" then there's no reason that will change. HTTP/1.1 over TLS is still fine, HTTP/1.1 plaintext was already treated that way. The newer protocol isn't really "more secure", than HTTP/1.1 over TLS, but it is as this article notes, faster and more capable.

nly 6y ago

Does anyone know what the maturity of standalone C-compatible implementations is like? Curl seem to be evaluating two different stacks: ngtcp2+nghttp3 (C, seems to be from developers behind aria2) and Quiche (Rust, from Cloudflare) Then there's Google's C++ QUICHE implementation which seems to not be used by anyone outside of Chromium (Even node.js apparently isn't using this, unless the code is just old). There are several more: https://en.wikipedia.org/wiki/HTTP/3#Libraries https://en.wikipedia.org/wiki/HTTP/3#Libraries It's a bit of a mess, and until Curl makes a decision I'm not sure where to go.