Hacker News Reader

> If I want to read an article that is 50kB of text, it's not unreasonable to expect that information to be here before my finger leaves the ENTER key, regardless of how its transmitted.

I mean no, but it can be unreasonable to expect that physical limits get beaten if you have in mind that some people just have a few hundred to a thousand KM between their computer and the server they access.

E.g., in my hometown I may get latencies of 200 ms and more to a few sites, especially simpler ones that have no CDN but are a single server on the other end of the world. Don't get me started if I'm travelling between Vienna and South Tyrol using the train, in some parts (cough Germany) the internet is really spotty and latency spikes up to 10 to 20s are (sadly) rather normal for a few minutes here and there.

Now, with HTTP 1.1 over TCP and TLS involved the setup time already gets me to almost a second of wait time (more than the few tens of ms my finger needs to leave the Enter key) in the former setup and in the latter I may need 30 to 60s, or it even just times out when travelling by train and being in a bad spot, connectivity wise.

QUIC improves there, TLS handshake starts immediately and UDP setup needs less round-times (none) compared to TCP (even with TCP fast-open).

So simple websites can profit too from QUIC, initial load time can get reduced a lot, browsing them is finally doable also on remote, spotty connections. Also, I happen to develop applications that are delivered as web app, they just tend to acquire a certain complexity even if one tries to stay simple, so loading that faster even if nothing is already cached is a welcome thing to me.

Bloated page still will be slow, sure faster than with HTTP 1.1 but still slow, and I definitively would like to see that getting improved, but that's not really related to the issues that QUIC improves on, as simple websites win too when using it; it's just less noticeable there if you already have a somewhat OK connection.

In summary: Why not invent a new protocol if you can significantly reduce overhead for everyone, especially if it can coexist with the simple and established one.

View on HN

Client: Initial (1284 bytes) includes client hello Server: Retry (166 bytes) includes retry token Client: Initial (1284 bytes) including retry token and client hello Server: Server Hello/Encrypted Extensions/Cert Request/Certificate/Certificate Verify/Finished (1284 bytes) Client: Certificate/Certificate Verify/Finished (1284 bytes)

Prior to validating the client address, servers MUST NOT send more than three times as many bytes as the number of bytes they have received. This limits the magnitude of any amplification attack that can be mounted using spoofed source addresses. For the purposes of avoiding amplification prior to address validation, servers MUST count all of the payload bytes received in datagrams that are uniquely attributed to a single connection. This includes datagrams that contain packets that are successfully processed and datagrams that contain packets that are all discarded.

A server might wish to validate the client address before starting the cryptographic handshake. QUIC uses a token in the Initial packet to provide address validation prior to completing the handshake. This token is delivered to the client during connection establishment with a Retry packet (see Section 8.1.2) or in a previous connection using the NEW_TOKEN frame (see Section 8.1.3).