24 ms·

Some notes about HTTP/3

561 points by BerislavLopac 8y ago

yaht 8y ago
Hahahaha, "pbuh". I love you Rob, I want to bear your child.
adeptima 8y ago
> I mention this because one of the things that's missing from your education about the OSI Model is that it originally envisioned everyone writing to application layer (7) APIs instead of transport layer (4) APIs. There was supposed to be things like application service elements that would handling things like file transfer and messaging in a standard way for different applications. I think people are increasingly moving to that model, especially driven by Google with go, QUIC, protobufs, and so on. HTTP/3 aka QUIC driven by Go & protobufs ? ;))))
meddlepal 8y ago
I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?
- jgh 8y ago
  I believe Akamai has implemented QUIC but I haven't heard of any other CDNs that have.
  - lumisota 8y ago
    A few other CDNs have implementations, but presumably we'll see much wider adoption once it has been standardised.
  - dochtman 8y ago
    Cloudflare is also already testing draft QUIC support.
  - cortesoft 8y ago
    EdgeCast supports QUIC as well https://www.verizondigitalmedia.com/blog/2018/05/quic-announcement/ https://www.verizondigitalmedia.com/blog/2018/05/quic-announ...
- dddddaviddddd 8y ago
  As browsers adopt it I'm sure uptake will be significant given the advantages. I'm looking forward to IP roaming.
  - throwaway2048 8y ago
    as a security person I'm looking forward to massive holes in IP roaming implementations.
- maximilianburke 8y ago
  Azure's load balancers support UDP.
- chuhnk 8y ago
  Disagree. There's more incentive to move considering the advantages it offers. If anything it feels like people were reluctant to adopt http2 and http3 is a bigger leap that we'll all want to move forward with.
  - zamadatix 8y ago
    The challenge for http/3 will be middleboxes not endpoints. Put another way: it won't be hard to break 50% of traffic on http/3 but you will still be running 2 10 years from now if you want to reach the last 10% of users.
    - JBiserkov 8y ago
      Middleboxes will only see UDP, no? From their perspective nothing has changed? Isn’t that the whole idea?
      - Buge 8y ago
        How many middleboxes block all UDP?
        foobiekr 8y ago
        QUIC forcing these boxes out of the network is a feature not a bug.
- paulddraper 8y ago
  AWS was working on UDP load balancing last year. [1] So, maybe 2021 GA. [1] https://forums.aws.amazon.com/thread.jspa?threadID=264282 https://forums.aws.amazon.com/thread.jspa?threadID=264282
- tyingq 8y ago
  Corporate web proxies/filters will likely lag as well. https://support.forcepoint.com/KBArticle?id=000015410 https://support.forcepoint.com/KBArticle?id=000015410
- Tuna-Fish 8y ago
  The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?
  - X-Istence 8y ago
    Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.
    - vertex-four 8y ago
      Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.
      - wmf 8y ago
        Although stateful connection tracking is still a best practice for IPv6 firewalls and home routers.
      - greglindahl 8y ago
        There are a ton of IPv4 firewalls and middleboxes that have stateful tracking even when NAT is not in use.
      - X-Istence 8y ago
        My firewall doesn't do NAT yet is still stateful for IPv6. Also, most firewalls on end-point devices (think built-in to the OS) are stateful firewalls.
    - bb88 8y ago
      If the client side changes it's IP address, it's a lot easier say than if the server side does. Typically because the server won't reject new UDP packets coming in from the internet. The load balancer will route any ongoing sessions with the session id, and not the ip address.
- baby 8y ago
  HTTP/2 works well, so adoption speed isn't that important. On the other hand, HTTP/3 is way, way faster. So there are strong incentives for big players to adopt it as fast as possible :)
romed 8y ago
This post groks QUIC. The most important thing about QUIC is it frees applications from the tyranny of the kernel TCP state machine. Today all TCP sockets (at least, on Linux) are subject to the same system-wide parameters of the TCP state machine, none of which are appropriate for any particular application. With QUIC we will finally have each application in control of its own retry timers and other parameters. That is going to be quite beneficial, especially on mobile where packet loss is so common.
- blitmap 8y ago
  setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, ...) setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, ...) ? I'm not dismissing QUIC, but it is in your control to redefine those defaults. Maybe in 2020 we'll be grappling back toward [sane] defaults.
  - romed 8y ago
    Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are specified in RFCs as 200ms, again completely inappropriate in a low-latency setting. QUIC also frees us from other outdated misfeatures of TCP such as timestamps in milliseconds when they should be in microseconds.
    - tyingq 8y ago
      You can tweak rto_min per route, with ip route.
      - romed 8y ago
        Yep, but it would be inadvisable to set it lower than the peer’s delayed ACK timeout, unless you want to just always resend every packet.
jasonhansel 8y ago
Wish we could just use SCTP instead: https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...
- rrdharan 8y ago
  I'm curious, how does SCTP tunneled over UDP compare to QUIC? https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/rfc6951
  - moderation 8y ago
    Lot's of discussion about SCTP in prior related thread at https://news.ycombinator.com/item?id=18427795 https://news.ycombinator.com/item?id=18427795
  - dcbadacd 8y ago
    It compares in the way that there's not a single SCTP web server implementation compared to QUIC. People here say that we should use HTTP/2 over SCTP, no protocol will be adopted if there's no good implementations of it.
    - derefr 8y ago
      A WebRTC "RTCDataChannel" is an SCTP-over-DTLS-over-UDP stack, and webservers exist to stream to these. They're just mostly proprietary, existing as part of vertically-integrated stacks like that of Google Hangouts (i.e. its "app sharing" feature.)
      - FiveSquared 8y ago
        I wish there was a open source verison king like PyCharm
    - wmf 8y ago
      Perhaps a better question would be why did Google decided to experiment with QUIC in Chrome instead of HTTP/2 over TLS over SCTP over UDP in Chrome. And the answer is probably because TLS over SCTP would require more RTTs.
john37386 8y ago
Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats. I feel this move won't make internet a better and safer place, but let's see.
- tyingq 8y ago
  That's because other UDP based protocols don't have tcp like sequence numbers or other anti-spoofing measures. Quic has a source address token that makes it hard to spoof.
  - PeterisP 8y ago
    As far as I understand, the parent's point is that QUIC makes your network vulnerable to attacks from spoofed non-QUIC services because you have to allow UDP packets to reach your network - their usual practice is to protect yourself by just dropping all UDP, but as soon as you want a single system to serve QUIC, then you can't do that anymore and need to inspect all these UDP packages even if it's an extreme amount of some amplified DDoS garbage.
    - tyingq 8y ago
      Confused. You don't have to allow all UDP traffic. Just port 443 for some specific set of IP addresses.
- derefr 8y ago
  See https://blog.cloudflare.com/the-road-to-quic/#deflectingreflection https://blog.cloudflare.com/the-road-to-quic/#deflectingrefl...
- baby 8y ago
  Or let's actually read about QUIC before quickly commenting on it. QUIC uses two mechanism to make sure you cannot do such attacks: * it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1] * it requires the client's first message (client hello) to be padded to at least the size of the server's response. Which implies that an attacker would require as much bandwidth as is spent by the server performing the attack, making the attack as practical as the attack without QUIC. [2] [1]: https://tools.ietf.org/html/draft-ietf-quic-transport-16#section-8 https://tools.ietf.org/html/draft-ietf-quic-transport-16#sec... [2]: https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9.1 https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9...
popee 8y ago
> Their second upgrade they called QUIC (pronounced "quick"), which is being standardized as HTTP/3. Isn't QUIC new transport layer protocol based on UDP and, if I remember correctly, HTTP/3 will be HTTP bindings for QUIC? You might think this is nitpicking, but HTTP is application layer protocol, so it's little bit confusing to me.
- dharmab 8y ago
  >However, in those discussions, a related concern was identified; confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things. > >To address this, I'd like to suggest that -- after coordination with the HTTP WG -- we rename our the HTTP document to "HTTP/3", and using the final ALPN token "h3". Doing so clearly identifies it as another binding of HTTP semantics to the wire protocol -- just as HTTP/2 did -- so people understand its separation from QUIC. https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0... TL;DR the rename is to resolve the confusion.
  - popee 8y ago
    Aha, thanks for clearing that up
  - yy77 8y ago
    why not just http/quic? using 3 seems strongly suggest that it is the next generation of http. They knew that but pretend it is not relavent.
    - dharmab 8y ago
      Because there's a decent chance that it will be the next generation of HTTP. If it doesn't pan out they'll just move on. Remember IPv5?
- detaro 8y ago
  Google didn't make the distinction between transport layer and HTTP-layer on top when they called their development "QUIC", it was one thing. IETF decided to split these during the standardization.
pfschell 8y ago
>With QUIC, however, the identifier for a connection is not the traditional concept of a "socket" (the source/destination port/address protocol combination), but a 64-bit identifier assigned to the connection. This means that as you move around, you can continue with a constant stream uninterrupted from YouTube even as your IP address changes, or continue with a video phone call without it being dropped. This is the ultimate dream of every surveillance company & gov't. Of course Google is solving this "problem."
- blitmap 8y ago
  This is definitely a risk. There are valid needs to wanting to resume a connection as it hops between gateways, but I definitely see abuse for this. The identifier doesn’t necessarily tie you to a location or name, but once you can associate that it is a risk.
- jetzzz 8y ago
  In a typical scenario, when you connect to a website with one IP address, then change your network and connect again with different IP but using the same device/browser, that website knows that you are the same user. I don't see how having an identifier inside encrypted connection makes anything worse.
- jabl 8y ago
  IIUC, the stream identifier is not a persistent client identifier but more similar to a TCP connection. So yes, as opposed to TCP, it will be able to work with changing IP addresses, but other than that, it's still a relatively short-term identifier. Google et al will still have to use cookies and whatnot to identify users over longer times.
surak 8y ago
Can we assume the main motivation for google is to be able to track mobile users better? Particullary as more users are using various blocking methods and the legal environment regarding 3rd party trackers I questionable. "With QUIC, however, the identifier for a connection is not the traditional concept of a "socket" (the source/destination port/address protocol combination), but a 64-bit identifier assigned to the connection."
- skybrian 8y ago
  I don't see any reason to assume that. As the article explains, portable network connections have been a goal in network research for many years. Also, Google benefits from a faster and more secure Internet and its employees have the freedom to pursue that in a wide variety of ways. They aren't all mustache-twirling villains. But I do think the security and privacy implications should be explored. What could an attacker do with a persistent connection?
  - unilynx 8y ago
    Nothing that a session cookie can't, probably - web servers aren't getting that much of a new tracking mechanism with a QUIC session id. But a session cookie doesn't allow to transfer a stream to a new IP address during a long request/response.
- sgentle 8y ago
  A more likely reason is that Google and other internet companies see internet infrastructure as an economic complement: the better and cheaper the internet is, the better and cheaper the total internet + Google services package is. That's why they do so much web performance advocacy, make their own browser, keep trying to kill off ISPs etc. Every dollar you spend on internet service is a dollar you don't spend on digital subscriptions, and every second you spend waiting for pages to load is a second you're not consuming content and watching ads.
- pmontra 8y ago
  I didn't think about Google spying even more on users but I also frowned when I read that sentence. It seems to lower the bar for hacking into the connection, but probably that 64 bit identifier is embedded in the encrypted data so it should be hard to get it. To be fair to the proponents of QUIC I add the next sentence, which depicts a use case: "This means that as you move around, you can continue with a constant stream uninterrupted from YouTube even as your IP address changes, or continue with a video phone call without it being dropped"
tialaramex 8y ago
The discussion of standards seems like it unhelpfully conflates the reality of standardisation by bodies like the IETF that have no discernible authority and don't want it even if it were possible - with "de facto" standards which it says are just whatever people do in practice. Not so. The IETF is not a conventional SDO, nor indeed a conventional organisation of any sort, since it has no members, and it operates on "rough consensus" rather than having some specific formal process that invariably (see Microsoft's interaction with ECMA and ISO) would be gamed by scumbags. But nevertheless those are de jure standards that come out the far end, the result of "getting all major stakeholders in a room" albeit that room is most often a mailing list since only a hardcore few can attend every IETF physical meeting. The IETF even explicitly marks standards track RFCs distinctly from non-standards track ones. If you contribute documentation for a complete working system, rather than (as Google did with QUIC) a proposal based on such a system that needs further refinement, it'll just get published as an Informational RFC. Such RFCs are how a bunch of Microsoft network protocols are documented, by Microsoft. Whereas months of arguing and back-and-forth technical discussion have shaped the IETF's QUIC and will continue to do so, the documentation for MSCHAPv2 (commonly used in corporate WiFi deployments) is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say "Er, this protocol is stupid, change it not to shove zero bytes into this key labelled C or else anybody can crack user passwords after spoofing the AP". So they didn't, and you can. [Edited: wording tweaks near start, sorry]
- nneonneo 8y ago
  > is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say... Which is ironic, considering “RFC” stands for “Request for Comments”.
  - kerneis 8y ago
    To be fair, the parent comment is slightly misleading. I don't know the exact story of MSCHAPv2 but note that it is an informational RFC published by the pppext WG: https://tools.ietf.org/html/rfc2759 https://tools.ietf.org/html/rfc2759 For an RFC to be published by a WG, it must first be "adopted" by the group, which means a first draft is submitted by the author, and then debatted (sometimes lightly) until the group agrees that it fits the topic and is suitable for adoption. Similarly, once the RFC is adopted, it goes through a series of calls by the WG chair where people have opportunities to comment, until it is finally published. Informational RFCs have lighter requirements than standard tracks one, so they are easier to get published, but they still get some amount of review and comments before publication. It took 14 months and 4 drafts for MSCHAPv2 to get published: https://datatracker.ietf.org/doc/rfc2759/ https://datatracker.ietf.org/doc/rfc2759/ In fact, even "independent submissions" with "experimental" status (that do not go through a WG at all, https://tools.ietf.org/html/rfc2026#section-4.2.1 https://tools.ietf.org/html/rfc2026#section-4.2.1) get reviewed before publication. The reviews in that case are private, but a RFC editor is responsible for sanity-checking the document and sometimes requests additional input from reviewers specialized in the domain area covered by the draft. [Edit: the actual WG for MSCHAPv2 was https://tools.ietf.org/wg/pppext/ https://tools.ietf.org/wg/pppext/, not "Networking" which is just the generic name on top of the RFC]
jokoon 8y ago
Not sure I understand it very well, but that mean http3 is going to use UDP, but does that mean there is going to be a new TCP named TCP/2?
- jabl 8y ago
  > but that mean http3 is going to use UDP Yes. > there is going to be a new TCP named TCP/2 No. There is a new protocol called QUIC, which runs on top of UDP. That is, to routers/firewalls/middleboxes etc. that are not specifically aware of QUIC, it will just look like UDP traffic. QUIC provides TCP-like features (reliable streams, with retransmissions of dropped packets etc.) plus more. As to why QUIC instead of improving TCP; experience has suggested that TCP has essentially become ossified, meaning that middleboxes will drop TCP packets using new features (see e.g. ECN). Thus in QUIC there's a focus on ossification-resistance (mandatory encryption, and as little information as possible exposed outside the encryption, etc.). HTTP3 runs on top of QUIC (which runs on top of UDP). Hopefully that makes it clearer.
  - jokoon 8y ago
    Thanks for the explanation, that's clearer now. Just another question, are the "middleboxes" well prepared for a massive switch towards UDP traffic? I don't know the network hardware world very well. Also I thought TCP traffic was benefitting from hardware implementation and optimization, I guess that's also wrong.
    - jabl 8y ago
      > Just another question, are the "middleboxes" well prepared for a massive switch towards UDP traffic? I don't know the network hardware world very well. I'm not an expert either, but AFAIK QUIC development has been heavily influenced by the requirement to work on the "real" internet with various middleboxes of varying quality. And it's not like it's going to be an instant change. QUIC is AFAIK already used between Chrome and google/youtube, and once QUIC & HTTP3 are official, it'll be a very long tail. > Also I thought TCP traffic was benefitting from hardware implementation and optimization, I guess that's also wrong. Well, going all the way (that is, TOE), hasn't been that popular, and e.g. the Linux kernel has refused to support such cards in the mainline kernel. What is common, and very useful, is checksum and segmentation offloads. Checksums are present in both TCP and UDP, and AFAIK NIC's capable of TCP checksum offload can also do UDP checksum offloading. Similarly for segmentation offloading, except in the UDP world it's called fragmentation offload. Though I guess for QUIC, receive fragmentation offloading won't work as long as the kernel and HW don't understand QUIC, as they won't understand that two incoming UDP packets can be merged.
tor_user 8y ago
have any of you geniuses figured out this will break websites for tor users yet?
- zmanian 8y ago
  Tor doesn't support UDP so no HTTP/3 but one would expect most services would be available for the foreseeable future over HTTP/2 as well.
  - tor_user 8y ago
    like websites without javascript?
    - Dylan16807 8y ago
      Working without javascript requires development time. Running old versions of HTTP doesn't. Version 1.1 is going to be fully supported for a long time.
      - tor_user 8y ago
        Working without javascript requires money. Running old versions of HTTP requires ????.
        penagwin 8y ago
        Running old versions of HTTP requires nothing because people will need to support legacy devices for a long time, and it's obviously already implemented in all major components (Servers, CDNs, Clients, etc.)
        tor_user 8y ago
        ???? != nothing. Why run HTTP/3 if HTTP/1 costs nothing? Where I work legacy gets dropped sooner rather than later. I hope this bombs, er tanks.
geo_mer 8y ago
Is QUIC only built for HTTP or can it be also used as a secure infrastructure for any L7 protocol?
- deleted 8y ago
  [deleted]
- M2Ys4U 8y ago
  The latter. In fact, as I understand it, the point of the rename to HTTP/3 is to distinguish the QUIC-HTTP bindings from the QUIC-by-itself protocol.
aaaaaaaaaab 8y ago
Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested link with another one implementing BBR, the BBR grabs the lion's share of the bandwidth: >https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf >QUIC specifies NewReno as default and mentions CUBIC, but the choice of algorithm is left to the implementation. I can easily envision Google using BBR for connections between Chrome and Google properties, which means Google traffic would be prioritized over competitors'. Over time, more players would implement BBR in a race to the bottom (or a tragedy of the commons) and Internet brown-outs as in the 1980s and 1990s would come back. https://blog.erratasec.com/2018/11/some-notes-about-http3.html?showComment=1542664152300&m=1#c2719702969623179467 https://blog.erratasec.com/2018/11/some-notes-about-http3.ht...
- piannucci 8y ago
  Race to the bottom is one thing. Yes, so-called “TCP unfriendly” protocols will muscle out any protocol that reacts to probability p random packet drops by a one-over-root-p reduction in throughput. But that does NOT mean that BBR will fail to avoid congestive collapse. The one-over-root-p behavior is outdated and actually harmful on wireless links, anyway; it was designed for the assumption that all losses are congestive losses; but today, many losses are purely random and not an indicator of congestion. BBR and other modern TCP-unfriendly congestion control protocols are a necessary step. TCP-friendliness must die.
  - richardwhiuk 8y ago
    WiFi generally doesn't drop packets - it's usual failure mode is for latency to spike horribly for a clump of packets.
    - piannucci 8y ago
nly 8y ago
Is it me or does this part make no sense > But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once. TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer (containing multiple HTTP messages) in to userspace in one syscall.
- TazeTSchnitzel 8y ago
  They're not talking about receiving TCP packets there.
  - deleted 8y ago
    [deleted]
- detaro 8y ago
  HTTP requests are small, and a read() call only gets you the data from a single connection, so you get one to few packet(s) worth of data per syscall. In contrast, recvmmsg can get you a large bunch of packets across all "connections" in a single syscall.
  - nly 8y ago
    Good point. Only that makes sense for servers though since for clients (web browsers etc) sockets will be 'connected' and they will still have lots of sockets anyway. They'll still be epoll()ing or similar. Not withstanding the other benefits of QUIC, the UDP vs TCP thing wrt to crossing the kernel-userspace boundary doesn't seem that significant.
    - detaro 8y ago
      For clients these numbers don't matter as much, many thousands of packets per second doesn't really happen to them. For a server with a fast pipe it does happen. I hope one of the big providers will share numbers. I don't think many of them actually use user-space stacks with TCP, would be interesting if QUIC improves performance measurably.
nly 8y ago
I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.
- CharlesW 8y ago
  I don't know much about this, so do you mind elaborating? Wouldn't userspace implementations be safer and easier to update as we spend the next few years sussing out security and performance issues?
  - paulddraper 8y ago
    IDK about "safer", but they will be more numerous and harder to update. (It's not as simple as making sure your kernel is up-to-date.)
    - paulddraper 8y ago
      I am evidently wrong about something, but I'm not sure what.
- ris 8y ago
  But the whole point of QUIC is that it is a userspace implementation. From the QUIC viewpoint (and I take no sides in this) kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems. This is why they found they couldn't "just improve TCP".
  - the8472 8y ago
    There have been plenty of improvements to TCP over time. New congestion controllers, new extension headers, fast open, ECN, etc.
    - netheril96 8y ago
      How long does each improvement achieve widespread adoption?
winwares 8y ago
So theoretically speaking, any secure protocol running over TCP can be run over QUIC? Like FTPS, SMTPS, IMAP etc?
freediver 8y ago
“The top 5 corporations in the world are, in order, Apple-Google-Microsoft-Amazon-Facebook” I literally can not find a criteria that would support this claim. Market cap - no. Revenue - no. Customer satisfaction? Employee satisfaction? Contribution to society? No.
- owaislone 8y ago
  They are seen as the top five tech giants. That's probably what the author meant.
  - freediver 8y ago
    Define the criteria please.
- zamadatix 8y ago
  If you take Facebook out I'm pretty sure the market cap question flips to "true" in which case I'd cut the author some slack.
- ComputerGuru 8y ago
  What does this contribute to the discussion regarding the actual content of the article?
- grzm 8y ago
  Looking at market cap, for 2018 Q1: 1. Apple 2. Alphabet (Google) 3. Microsoft 4. Amazon ... 8. Facebook Q2: 1. Apple 2. Amazon 3. Alphabet (Google) 4. Microsoft 5. Facebook. Q3: 1. Apple 2. Amazon 3. Microsoft 4. Alphabet ... 6. Facebook https://en.wikipedia.org/wiki/List_of_public_corporations_by_market_capitalization#2018 https://en.wikipedia.org/wiki/List_of_public_corporations_by... If you want to quibble that the five listed aren't always the top five or that the order isn't exactly that listed in the article, or that this isn't valid criteria, go ahead, but this seems like a pretty minor point and tangential to the article.
saagarjha 8y ago
I’m no web standards expert, but I’m surprised that this standard will be implemented in userspace rather than in the kernel. Seems like a rather odd choice: will there be a way to string together the requisite kernel calls together to achieve the same functionality, or will I be forced to link against a “priveleged” library that makes these calls for me?
- lozenge 8y ago
  It's not a privileged library. You can choose an HTTP/3 implementation like choosing an HTTP 1 implementation.
- ysleepy 8y ago
  Part of the advantage is that you can update the protocol implementation independently of the OS. So google does not have to lobby OS vendors to implement TCP fast-open and other extensions to make their stack faster.
- zamadatix 8y ago
  To the kernel QUIC is just a UDP socket managed by your application, it's nothing special in that regard.
Kenji 8y ago
Microsoft owns a popular operating system, so it's innovations are driven by what it can do within that operating system. its* A fantastic article ruined by a nasty grammar mistake (I'm kidding, of course).
scrame 8y ago
> As an old protocol guy I don't buy it. you have 4 posts from this year, and this is an angry incoherent rant from someone who is about 26, max.
- dang 8y ago
  Please don't cross into personal attack on HN. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
white-flame 8y ago
I searched the page for proxying and tunneling, neither of which is discussed. I'm sure switching to UDP will have dramatic consequences for these features.
rustcharm 8y ago
It's getting very complicated to understand everything that happens when you click on a link in a browser. And I wonder if these UDP protocols are better than fixing the issues with TCP. Of course, it may allow loading from several servers simultaneously a la bittorrent.
exabrial 8y ago
Is it possible to turn encryption off? If I'm running a cluster of sensors on a remote airgapped network, the ease of using tools like tcpdump and nc far outweigh the need for encryption, especially if one is power constrained.
- askvictor 8y ago
  Presumably you're not being forced to use http/3 and can continue to use whatever you're using now? Or is there a particular reason that you want to move to http/3 for that network?
anderspitman 8y ago
Is there much hope of this leading to us being able to set up QUIC transport connections (ie without HTTP) in the browser? This could be huge for browser games and other low latency apps. WebRTC is powerful but seems to be limited by not having a good portable server implementation, due to complexity.

561 points by BerislavLopac 8y ago

yaht 8y ago

Hahahaha, "pbuh". I love you Rob, I want to bear your child.

> I mention this because one of the things that's missing from your education about the OSI Model is that it originally envisioned everyone writing to application layer (7) APIs instead of transport layer (4) APIs. There was supposed to be things like application service elements that would handling things like file transfer and messaging in a standard way for different applications. I think people are increasingly moving to that model, especially driven by Google with go, QUIC, protobufs, and so on. HTTP/3 aka QUIC driven by Go & protobufs ? ;))))

meddlepal 8y ago

I feel like the adoption of HTTP/3 is going to be much much slower than HTTP/2... Besides Google Cloud do any of the major cloud providers have UDP load balancers?

jgh 8y ago
I believe Akamai has implemented QUIC but I haven't heard of any other CDNs that have.
- lumisota 8y ago
  A few other CDNs have implementations, but presumably we'll see much wider adoption once it has been standardised.
- dochtman 8y ago
  Cloudflare is also already testing draft QUIC support.
- cortesoft 8y ago
  EdgeCast supports QUIC as well https://www.verizondigitalmedia.com/blog/2018/05/quic-announcement/ https://www.verizondigitalmedia.com/blog/2018/05/quic-announ...
dddddaviddddd 8y ago
As browsers adopt it I'm sure uptake will be significant given the advantages. I'm looking forward to IP roaming.
- throwaway2048 8y ago
  as a security person I'm looking forward to massive holes in IP roaming implementations.
maximilianburke 8y ago
Azure's load balancers support UDP.
chuhnk 8y ago
Disagree. There's more incentive to move considering the advantages it offers. If anything it feels like people were reluctant to adopt http2 and http3 is a bigger leap that we'll all want to move forward with.
- zamadatix 8y ago
  The challenge for http/3 will be middleboxes not endpoints. Put another way: it won't be hard to break 50% of traffic on http/3 but you will still be running 2 10 years from now if you want to reach the last 10% of users.
  - JBiserkov 8y ago
    Middleboxes will only see UDP, no? From their perspective nothing has changed? Isn’t that the whole idea?
    - Buge 8y ago
      How many middleboxes block all UDP?
      - foobiekr 8y ago
        QUIC forcing these boxes out of the network is a feature not a bug.
paulddraper 8y ago
AWS was working on UDP load balancing last year. [1] So, maybe 2021 GA. [1] https://forums.aws.amazon.com/thread.jspa?threadID=264282 https://forums.aws.amazon.com/thread.jspa?threadID=264282
tyingq 8y ago
Corporate web proxies/filters will likely lag as well. https://support.forcepoint.com/KBArticle?id=000015410 https://support.forcepoint.com/KBArticle?id=000015410
Tuna-Fish 8y ago
The protocol has been designed so that both the endpoints of a stream can seamlessly change IP addresses. This ought to make load balancing easier?
- X-Istence 8y ago
  Not unless you want to get through firewalls seamlessly. UDP "state" tracking is a thing, and if my firewall sees a UDP packet destined for it without knowing the remote IP address it's going to drop it.
  - vertex-four 8y ago
    Which is yet another reason to migrate to IPv6, which doesn’t require stateful NAT.
    - wmf 8y ago
      Although stateful connection tracking is still a best practice for IPv6 firewalls and home routers.
    - greglindahl 8y ago
      There are a ton of IPv4 firewalls and middleboxes that have stateful tracking even when NAT is not in use.
    - X-Istence 8y ago
      My firewall doesn't do NAT yet is still stateful for IPv6. Also, most firewalls on end-point devices (think built-in to the OS) are stateful firewalls.
  - bb88 8y ago
    If the client side changes it's IP address, it's a lot easier say than if the server side does. Typically because the server won't reject new UDP packets coming in from the internet. The load balancer will route any ongoing sessions with the session id, and not the ip address.
baby 8y ago
HTTP/2 works well, so adoption speed isn't that important. On the other hand, HTTP/3 is way, way faster. So there are strong incentives for big players to adopt it as fast as possible :)

romed 8y ago

This post groks QUIC. The most important thing about QUIC is it frees applications from the tyranny of the kernel TCP state machine. Today all TCP sockets (at least, on Linux) are subject to the same system-wide parameters of the TCP state machine, none of which are appropriate for any particular application. With QUIC we will finally have each application in control of its own retry timers and other parameters. That is going to be quite beneficial, especially on mobile where packet loss is so common.

blitmap 8y ago
setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, ...) setsockopt(fd, SOL_SOCKET, SO_SNDTIMEO, ...) ? I'm not dismissing QUIC, but it is in your control to redefine those defaults. Maybe in 2020 we'll be grappling back toward [sane] defaults.
- romed 8y ago
  Those do not affect TCP state machine parameters like RTO(min), ATO, and TLP timeout. These are internal to the kernel and are either static, or can only be set systemwide. For example the minimum delayed ack timeout in Linux is just 40ms and can't be changed except by recompiling the kernel. 40ms is a totally inappropriate number for ATO in a datacenter or other low-latency setting. Other numbers like RTO(min) are specified in RFCs as 200ms, again completely inappropriate in a low-latency setting. QUIC also frees us from other outdated misfeatures of TCP such as timestamps in milliseconds when they should be in microseconds.
  - tyingq 8y ago
    You can tweak rto_min per route, with ip route.
    - romed 8y ago
      Yep, but it would be inadvisable to set it lower than the peer’s delayed ACK timeout, unless you want to just always resend every packet.

jasonhansel 8y ago

Wish we could just use SCTP instead: https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_Protocol https://en.m.wikipedia.org/wiki/Stream_Control_Transmission_...

rrdharan 8y ago
I'm curious, how does SCTP tunneled over UDP compare to QUIC? https://tools.ietf.org/html/rfc6951 https://tools.ietf.org/html/rfc6951
- moderation 8y ago
  Lot's of discussion about SCTP in prior related thread at https://news.ycombinator.com/item?id=18427795 https://news.ycombinator.com/item?id=18427795
- dcbadacd 8y ago
  It compares in the way that there's not a single SCTP web server implementation compared to QUIC. People here say that we should use HTTP/2 over SCTP, no protocol will be adopted if there's no good implementations of it.
  - derefr 8y ago
    A WebRTC "RTCDataChannel" is an SCTP-over-DTLS-over-UDP stack, and webservers exist to stream to these. They're just mostly proprietary, existing as part of vertically-integrated stacks like that of Google Hangouts (i.e. its "app sharing" feature.)
    - FiveSquared 8y ago
      I wish there was a open source verison king like PyCharm
  - wmf 8y ago
    Perhaps a better question would be why did Google decided to experiment with QUIC in Chrome instead of HTTP/2 over TLS over SCTP over UDP in Chrome. And the answer is probably because TLS over SCTP would require more RTTs.

john37386 8y ago

Most of the deadliest DDoS attacks happen over UDP. Spoofing, reflection and amplification just to name a few. Many businesses just deny UDP to protect themself against the on going DDoS threats. I feel this move won't make internet a better and safer place, but let's see.

tyingq 8y ago
That's because other UDP based protocols don't have tcp like sequence numbers or other anti-spoofing measures. Quic has a source address token that makes it hard to spoof.
- PeterisP 8y ago
  As far as I understand, the parent's point is that QUIC makes your network vulnerable to attacks from spoofed non-QUIC services because you have to allow UDP packets to reach your network - their usual practice is to protect yourself by just dropping all UDP, but as soon as you want a single system to serve QUIC, then you can't do that anymore and need to inspect all these UDP packages even if it's an extreme amount of some amplified DDoS garbage.
  - tyingq 8y ago
    Confused. You don't have to allow all UDP traffic. Just port 443 for some specific set of IP addresses.
derefr 8y ago
See https://blog.cloudflare.com/the-road-to-quic/#deflectingreflection https://blog.cloudflare.com/the-road-to-quic/#deflectingrefl...
baby 8y ago
Or let's actually read about QUIC before quickly commenting on it. QUIC uses two mechanism to make sure you cannot do such attacks: * it requires a proof of IP ownership (exactly like TCP sequence numbers) to setup a connection ID (pretty much, you're able to receive the server's response to finalize the connection) [1] * it requires the client's first message (client hello) to be padded to at least the size of the server's response. Which implies that an attacker would require as much bandwidth as is spent by the server performing the attack, making the attack as practical as the attack without QUIC. [2] [1]: https://tools.ietf.org/html/draft-ietf-quic-transport-16#section-8 https://tools.ietf.org/html/draft-ietf-quic-transport-16#sec... [2]: https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9.1 https://tools.ietf.org/html/draft-ietf-quic-tls-16#section-9...

popee 8y ago

> Their second upgrade they called QUIC (pronounced "quick"), which is being standardized as HTTP/3. Isn't QUIC new transport layer protocol based on UDP and, if I remember correctly, HTTP/3 will be HTTP bindings for QUIC? You might think this is nitpicking, but HTTP is application layer protocol, so it's little bit confusing to me.

dharmab 8y ago
>However, in those discussions, a related concern was identified; confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things. > >To address this, I'd like to suggest that -- after coordination with the HTTP WG -- we rename our the HTTP document to "HTTP/3", and using the final ALPN token "h3". Doing so clearly identifies it as another binding of HTTP semantics to the wire protocol -- just as HTTP/2 did -- so people understand its separation from QUIC. https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0... TL;DR the rename is to resolve the confusion.
- popee 8y ago
  Aha, thanks for clearing that up
- yy77 8y ago
  why not just http/quic? using 3 seems strongly suggest that it is the next generation of http. They knew that but pretend it is not relavent.
  - dharmab 8y ago
    Because there's a decent chance that it will be the next generation of HTTP. If it doesn't pan out they'll just move on. Remember IPv5?
detaro 8y ago
Google didn't make the distinction between transport layer and HTTP-layer on top when they called their development "QUIC", it was one thing. IETF decided to split these during the standardization.

pfschell 8y ago

>With QUIC, however, the identifier for a connection is not the traditional concept of a "socket" (the source/destination port/address protocol combination), but a 64-bit identifier assigned to the connection. This means that as you move around, you can continue with a constant stream uninterrupted from YouTube even as your IP address changes, or continue with a video phone call without it being dropped. This is the ultimate dream of every surveillance company & gov't. Of course Google is solving this "problem."

blitmap 8y ago
This is definitely a risk. There are valid needs to wanting to resume a connection as it hops between gateways, but I definitely see abuse for this. The identifier doesn’t necessarily tie you to a location or name, but once you can associate that it is a risk.
jetzzz 8y ago
In a typical scenario, when you connect to a website with one IP address, then change your network and connect again with different IP but using the same device/browser, that website knows that you are the same user. I don't see how having an identifier inside encrypted connection makes anything worse.
jabl 8y ago
IIUC, the stream identifier is not a persistent client identifier but more similar to a TCP connection. So yes, as opposed to TCP, it will be able to work with changing IP addresses, but other than that, it's still a relatively short-term identifier. Google et al will still have to use cookies and whatnot to identify users over longer times.

surak 8y ago

Can we assume the main motivation for google is to be able to track mobile users better? Particullary as more users are using various blocking methods and the legal environment regarding 3rd party trackers I questionable. "With QUIC, however, the identifier for a connection is not the traditional concept of a "socket" (the source/destination port/address protocol combination), but a 64-bit identifier assigned to the connection."

skybrian 8y ago
I don't see any reason to assume that. As the article explains, portable network connections have been a goal in network research for many years. Also, Google benefits from a faster and more secure Internet and its employees have the freedom to pursue that in a wide variety of ways. They aren't all mustache-twirling villains. But I do think the security and privacy implications should be explored. What could an attacker do with a persistent connection?
- unilynx 8y ago
  Nothing that a session cookie can't, probably - web servers aren't getting that much of a new tracking mechanism with a QUIC session id. But a session cookie doesn't allow to transfer a stream to a new IP address during a long request/response.
sgentle 8y ago
A more likely reason is that Google and other internet companies see internet infrastructure as an economic complement: the better and cheaper the internet is, the better and cheaper the total internet + Google services package is. That's why they do so much web performance advocacy, make their own browser, keep trying to kill off ISPs etc. Every dollar you spend on internet service is a dollar you don't spend on digital subscriptions, and every second you spend waiting for pages to load is a second you're not consuming content and watching ads.
pmontra 8y ago
I didn't think about Google spying even more on users but I also frowned when I read that sentence. It seems to lower the bar for hacking into the connection, but probably that 64 bit identifier is embedded in the encrypted data so it should be hard to get it. To be fair to the proponents of QUIC I add the next sentence, which depicts a use case: "This means that as you move around, you can continue with a constant stream uninterrupted from YouTube even as your IP address changes, or continue with a video phone call without it being dropped"

tialaramex 8y ago

The discussion of standards seems like it unhelpfully conflates the reality of standardisation by bodies like the IETF that have no discernible authority and don't want it even if it were possible - with "de facto" standards which it says are just whatever people do in practice. Not so. The IETF is not a conventional SDO, nor indeed a conventional organisation of any sort, since it has no members, and it operates on "rough consensus" rather than having some specific formal process that invariably (see Microsoft's interaction with ECMA and ISO) would be gamed by scumbags. But nevertheless those are de jure standards that come out the far end, the result of "getting all major stakeholders in a room" albeit that room is most often a mailing list since only a hardcore few can attend every IETF physical meeting. The IETF even explicitly marks standards track RFCs distinctly from non-standards track ones. If you contribute documentation for a complete working system, rather than (as Google did with QUIC) a proposal based on such a system that needs further refinement, it'll just get published as an Informational RFC. Such RFCs are how a bunch of Microsoft network protocols are documented, by Microsoft. Whereas months of arguing and back-and-forth technical discussion have shaped the IETF's QUIC and will continue to do so, the documentation for MSCHAPv2 (commonly used in corporate WiFi deployments) is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say "Er, this protocol is stupid, change it not to shove zero bytes into this key labelled C or else anybody can crack user passwords after spoofing the AP". So they didn't, and you can. [Edited: wording tweaks near start, sorry]

nneonneo 8y ago
> is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say... Which is ironic, considering “RFC” stands for “Request for Comments”.
- kerneis 8y ago
  To be fair, the parent comment is slightly misleading. I don't know the exact story of MSCHAPv2 but note that it is an informational RFC published by the pppext WG: https://tools.ietf.org/html/rfc2759 https://tools.ietf.org/html/rfc2759 For an RFC to be published by a WG, it must first be "adopted" by the group, which means a first draft is submitted by the author, and then debatted (sometimes lightly) until the group agrees that it fits the topic and is suitable for adoption. Similarly, once the RFC is adopted, it goes through a series of calls by the WG chair where people have opportunities to comment, until it is finally published. Informational RFCs have lighter requirements than standard tracks one, so they are easier to get published, but they still get some amount of review and comments before publication. It took 14 months and 4 drafts for MSCHAPv2 to get published: https://datatracker.ietf.org/doc/rfc2759/ https://datatracker.ietf.org/doc/rfc2759/ In fact, even "independent submissions" with "experimental" status (that do not go through a WG at all, https://tools.ietf.org/html/rfc2026#section-4.2.1 https://tools.ietf.org/html/rfc2026#section-4.2.1) get reviewed before publication. The reviews in that case are private, but a RFC editor is responsible for sanity-checking the document and sometimes requests additional input from reviewers specialized in the domain area covered by the draft. [Edit: the actual WG for MSCHAPv2 was https://tools.ietf.org/wg/pppext/ https://tools.ietf.org/wg/pppext/, not "Networking" which is just the generic name on top of the RFC]

jokoon 8y ago

Not sure I understand it very well, but that mean http3 is going to use UDP, but does that mean there is going to be a new TCP named TCP/2?

jabl 8y ago
> but that mean http3 is going to use UDP Yes. > there is going to be a new TCP named TCP/2 No. There is a new protocol called QUIC, which runs on top of UDP. That is, to routers/firewalls/middleboxes etc. that are not specifically aware of QUIC, it will just look like UDP traffic. QUIC provides TCP-like features (reliable streams, with retransmissions of dropped packets etc.) plus more. As to why QUIC instead of improving TCP; experience has suggested that TCP has essentially become ossified, meaning that middleboxes will drop TCP packets using new features (see e.g. ECN). Thus in QUIC there's a focus on ossification-resistance (mandatory encryption, and as little information as possible exposed outside the encryption, etc.). HTTP3 runs on top of QUIC (which runs on top of UDP). Hopefully that makes it clearer.
- jokoon 8y ago
  Thanks for the explanation, that's clearer now. Just another question, are the "middleboxes" well prepared for a massive switch towards UDP traffic? I don't know the network hardware world very well. Also I thought TCP traffic was benefitting from hardware implementation and optimization, I guess that's also wrong.
  - jabl 8y ago
    > Just another question, are the "middleboxes" well prepared for a massive switch towards UDP traffic? I don't know the network hardware world very well. I'm not an expert either, but AFAIK QUIC development has been heavily influenced by the requirement to work on the "real" internet with various middleboxes of varying quality. And it's not like it's going to be an instant change. QUIC is AFAIK already used between Chrome and google/youtube, and once QUIC & HTTP3 are official, it'll be a very long tail. > Also I thought TCP traffic was benefitting from hardware implementation and optimization, I guess that's also wrong. Well, going all the way (that is, TOE), hasn't been that popular, and e.g. the Linux kernel has refused to support such cards in the mainline kernel. What is common, and very useful, is checksum and segmentation offloads. Checksums are present in both TCP and UDP, and AFAIK NIC's capable of TCP checksum offload can also do UDP checksum offloading. Similarly for segmentation offloading, except in the UDP world it's called fragmentation offload. Though I guess for QUIC, receive fragmentation offloading won't work as long as the kernel and HW don't understand QUIC, as they won't understand that two incoming UDP packets can be merged.

tor_user 8y ago

have any of you geniuses figured out this will break websites for tor users yet?

zmanian 8y ago
Tor doesn't support UDP so no HTTP/3 but one would expect most services would be available for the foreseeable future over HTTP/2 as well.
- tor_user 8y ago
  like websites without javascript?
  - Dylan16807 8y ago
    Working without javascript requires development time. Running old versions of HTTP doesn't. Version 1.1 is going to be fully supported for a long time.
    - tor_user 8y ago
      Working without javascript requires money. Running old versions of HTTP requires ????.
      - penagwin 8y ago
        Running old versions of HTTP requires nothing because people will need to support legacy devices for a long time, and it's obviously already implemented in all major components (Servers, CDNs, Clients, etc.)
        tor_user 8y ago
        ???? != nothing. Why run HTTP/3 if HTTP/1 costs nothing? Where I work legacy gets dropped sooner rather than later. I hope this bombs, er tanks.

geo_mer 8y ago

Is QUIC only built for HTTP or can it be also used as a secure infrastructure for any L7 protocol?

deleted 8y ago
[deleted]
M2Ys4U 8y ago
The latter. In fact, as I understand it, the point of the rename to HTTP/3 is to distinguish the QUIC-HTTP bindings from the QUIC-by-itself protocol.

aaaaaaaaaab 8y ago

Interesting comment under the post: >The problem is fairness in the presence of network congestion. To a large extent it depends on most TCP implementations using the same congestion control algorithm, or at least algorithms that have the same general behavior. Google's developed a new algorithm called BBR that is robust, but also unfair. When a TCP connection implementing the NewReno algorithm shares a congested link with another one implementing BBR, the BBR grabs the lion's share of the bandwidth: >https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf https://ripe76.ripe.net/presentations/10-2018-05-15-bbr.pdf >QUIC specifies NewReno as default and mentions CUBIC, but the choice of algorithm is left to the implementation. I can easily envision Google using BBR for connections between Chrome and Google properties, which means Google traffic would be prioritized over competitors'. Over time, more players would implement BBR in a race to the bottom (or a tragedy of the commons) and Internet brown-outs as in the 1980s and 1990s would come back. https://blog.erratasec.com/2018/11/some-notes-about-http3.html?showComment=1542664152300&m=1#c2719702969623179467 https://blog.erratasec.com/2018/11/some-notes-about-http3.ht...

piannucci 8y ago
Race to the bottom is one thing. Yes, so-called “TCP unfriendly” protocols will muscle out any protocol that reacts to probability p random packet drops by a one-over-root-p reduction in throughput. But that does NOT mean that BBR will fail to avoid congestive collapse. The one-over-root-p behavior is outdated and actually harmful on wireless links, anyway; it was designed for the assumption that all losses are congestive losses; but today, many losses are purely random and not an indicator of congestion. BBR and other modern TCP-unfriendly congestion control protocols are a necessary step. TCP-friendliness must die.
- richardwhiuk 8y ago
  WiFi generally doesn't drop packets - it's usual failure mode is for latency to spike horribly for a clump of packets.
  - piannucci 8y ago

nly 8y ago

Is it me or does this part make no sense > But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once. TCP is a streaming protocol, there are no datagrams to read one at a time. Nothing stops you from reading the entire kernel buffer (containing multiple HTTP messages) in to userspace in one syscall.

TazeTSchnitzel 8y ago
They're not talking about receiving TCP packets there.
- deleted 8y ago
  [deleted]
detaro 8y ago
HTTP requests are small, and a read() call only gets you the data from a single connection, so you get one to few packet(s) worth of data per syscall. In contrast, recvmmsg can get you a large bunch of packets across all "connections" in a single syscall.
- nly 8y ago
  Good point. Only that makes sense for servers though since for clients (web browsers etc) sockets will be 'connected' and they will still have lots of sockets anyway. They'll still be epoll()ing or similar. Not withstanding the other benefits of QUIC, the UDP vs TCP thing wrt to crossing the kernel-userspace boundary doesn't seem that significant.
  - detaro 8y ago
    For clients these numbers don't matter as much, many thousands of packets per second doesn't really happen to them. For a server with a fast pipe it does happen. I hope one of the big providers will share numbers. I don't think many of them actually use user-space stacks with TCP, would be interesting if QUIC improves performance measurably.

nly 8y ago

I hope we get in-kernel implementations of QUIC at some point because having to find a portable third-party library for userspace sounds about as appealing as installing Winsock on Windows 95.

CharlesW 8y ago
I don't know much about this, so do you mind elaborating? Wouldn't userspace implementations be safer and easier to update as we spend the next few years sussing out security and performance issues?
- paulddraper 8y ago
  IDK about "safer", but they will be more numerous and harder to update. (It's not as simple as making sure your kernel is up-to-date.)
  - paulddraper 8y ago
    I am evidently wrong about something, but I'm not sure what.
ris 8y ago
But the whole point of QUIC is that it is a userspace implementation. From the QUIC viewpoint (and I take no sides in this) kernel implementation is death for a protocol because it freezes its specification and behaviour in slow-to-update systems. This is why they found they couldn't "just improve TCP".
- the8472 8y ago
  There have been plenty of improvements to TCP over time. New congestion controllers, new extension headers, fast open, ECN, etc.
  - netheril96 8y ago
    How long does each improvement achieve widespread adoption?

winwares 8y ago

So theoretically speaking, any secure protocol running over TCP can be run over QUIC? Like FTPS, SMTPS, IMAP etc?

freediver 8y ago

“The top 5 corporations in the world are, in order, Apple-Google-Microsoft-Amazon-Facebook” I literally can not find a criteria that would support this claim. Market cap - no. Revenue - no. Customer satisfaction? Employee satisfaction? Contribution to society? No.

owaislone 8y ago
They are seen as the top five tech giants. That's probably what the author meant.
- freediver 8y ago
  Define the criteria please.
zamadatix 8y ago
If you take Facebook out I'm pretty sure the market cap question flips to "true" in which case I'd cut the author some slack.
ComputerGuru 8y ago
What does this contribute to the discussion regarding the actual content of the article?
grzm 8y ago
Looking at market cap, for 2018 Q1: 1. Apple 2. Alphabet (Google) 3. Microsoft 4. Amazon ... 8. Facebook Q2: 1. Apple 2. Amazon 3. Alphabet (Google) 4. Microsoft 5. Facebook. Q3: 1. Apple 2. Amazon 3. Microsoft 4. Alphabet ... 6. Facebook https://en.wikipedia.org/wiki/List_of_public_corporations_by_market_capitalization#2018 https://en.wikipedia.org/wiki/List_of_public_corporations_by... If you want to quibble that the five listed aren't always the top five or that the order isn't exactly that listed in the article, or that this isn't valid criteria, go ahead, but this seems like a pretty minor point and tangential to the article.

saagarjha 8y ago

I’m no web standards expert, but I’m surprised that this standard will be implemented in userspace rather than in the kernel. Seems like a rather odd choice: will there be a way to string together the requisite kernel calls together to achieve the same functionality, or will I be forced to link against a “priveleged” library that makes these calls for me?

lozenge 8y ago
It's not a privileged library. You can choose an HTTP/3 implementation like choosing an HTTP 1 implementation.
ysleepy 8y ago
Part of the advantage is that you can update the protocol implementation independently of the OS. So google does not have to lobby OS vendors to implement TCP fast-open and other extensions to make their stack faster.
zamadatix 8y ago
To the kernel QUIC is just a UDP socket managed by your application, it's nothing special in that regard.

Kenji 8y ago

Microsoft owns a popular operating system, so it's innovations are driven by what it can do within that operating system. its* A fantastic article ruined by a nasty grammar mistake (I'm kidding, of course).

scrame 8y ago

> As an old protocol guy I don't buy it. you have 4 posts from this year, and this is an angry incoherent rant from someone who is about 26, max.

dang 8y ago
Please don't cross into personal attack on HN. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

white-flame 8y ago

I searched the page for proxying and tunneling, neither of which is discussed. I'm sure switching to UDP will have dramatic consequences for these features.

rustcharm 8y ago

It's getting very complicated to understand everything that happens when you click on a link in a browser. And I wonder if these UDP protocols are better than fixing the issues with TCP. Of course, it may allow loading from several servers simultaneously a la bittorrent.

exabrial 8y ago

Is it possible to turn encryption off? If I'm running a cluster of sensors on a remote airgapped network, the ease of using tools like tcpdump and nc far outweigh the need for encryption, especially if one is power constrained.

askvictor 8y ago
Presumably you're not being forced to use http/3 and can continue to use whatever you're using now? Or is there a particular reason that you want to move to http/3 for that network?

anderspitman 8y ago

Is there much hope of this leading to us being able to set up QUIC transport connections (ie without HTTP) in the browser? This could be huge for browser games and other low latency apps. WebRTC is powerful but seems to be limited by not having a good portable server implementation, due to complexity.