4 ms·
So my question is: In what predictable way will QUIC fall flat on its face when people who AREN'T google's ad revenue team get involved?
by postmodest 3y ago
So my question is: In what predictable way will QUIC fall flat on its face when people who AREN'T google's ad revenue team get involved?
- janosdebugs 3y agoI'm not entirely through the RFC, but here are a few snags I see: 1. The QUIC RFC is primarily intended to be implemented in user space. In other words, each application needs to bring their own QUIC stack, which includes TCP-like semantics and TLS. I'd be very surprised if we didn't have a decade of security holes ahead of us. 2. Corporate routers are going to have a hard time dealing with the UDP-based protocol, especially as NAT is concerned. Connection migration to a new IP will also be a challenge. 3. The same goes for network load balancers, which section 5.2.3 talks about. Basically, you now need stateful/application LBs if I'm reading this correctly, or you need to disable connection migration. Also, accidentally exposing your backends via the preferred address will be a fun time if it accidentally happens, not sure how likely it is though. 4. Section 8.1.2 says that the protocol is vulnerable to a traffic amplification attack. In order to avoid it, an extra round trip must be done, which gets rid of the advantage if QUIC being quick in establishing connections. Maybe someone with more know-how could chime in.