7 ms·

>QUIC improves there, TLS handshake starts immediately and UDP setup needs less round-times compared to TCP. hmmm abit skeptical on the less round-times. Are t

>QUIC improves there, TLS handshake starts immediately and UDP setup needs less round-times compared to TCP. hmmm abit skeptical on the less round-times. Are the all the round-times in TCP to ensure the integrity of the connection. With UPD it is my understanding that no confirmation of receiving packet is issued. So a server can send out a signal, but never can be sure if the client got it. I can see it can be great for multiplexing/broadcasting, but the switch the whole http protocol over like this, I can't imagine there won't be tons integrity and security issues.

simiones 5y ago
QUIC is a combination of TLS and TCP essentially, implemented over UDP so that there is some chance that middle-boxes will allow it to pass (there's very little chance to actually use a completely new protocol over IP directly and have your packets received by the vast majority of networks). HTTP over QUIC will probably do a similar number of round-trips compared to HTTP over TCP, but it will do much fewer than HTTP over TLS over TCP. There's no getting away from SYN/SYN-ACK/ACK for a reliable protocol, but QUIC can put certificate negotiation information directly here, instead of the TLSoTCP approach of SYN/SYN-ACK/ACK/ClientHello/ServerHello/ClientKeyExchange/ServerKeyExchange. Additionally, QUIC supports multiple streams over a single physical connection, and correctly implements packet ordering constraints and retries for them. TCP supports a single stream over a connection: any delayed packet will delay the entire stream. In QUIC, a delayed packet will only delay packets from the same logical stream, packets from other streams can still be received successfully on the same connection. This feature is heavily used by HTTP/3: HTTP/2 introduced a concept of HTTP streams, but all HTTP streams were run over the same TCP connection, so over a single TCP stream: a slow packet on HTTP/2 stream 1 will delay all packets from HTTP/2 streams 2, 3 etc. With QUIC, an HTTP/3 stream is a QUIC stream, so a single slow request will not blkc other packets from other requests from being received.
- benmmurphy 5y ago
  Weirdly enough I think QUIC often does something that is not much better because of address validation. It is not safe for the QUIC server to send a bunch of large packets back to the client source address without being confident the client controls the address. We run QUIC in production so I’ll grab an example conversation to show how many round trips connection setup takes. I guess we might not be optimising connection setup correctly because we are using long running QUIC connections to transport our own protocol and I don’t care how long the connection setup takes. so we are using a slightly older version of QUIC than the RFC and using go-quic on server and client. and this is what i see when creating a connection: 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) address validation is covered in RFC 9000: https://datatracker.ietf.org/doc/html/rfc9000#section-8.1 https://datatracker.ietf.org/doc/html/rfc9000#section-8.1 probably what go-quic does is not optimal because you don't always have to validate the address. 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).
dtech 5y ago
TCP is not the only way to ensure integrity, QUIC protocol ensures it, using UDP as transport. This is how all new protocols do it since there's too many hardware and software roadblocks to use anything but TCP and UDP.
- salawat 5y ago
  Only because no one wants to upgrade their damn backbone NICS. SCTP solved things way better than QUIC imo except for the infrastructure inertia part. The infrastructure inertia part isn't even so much a question of technical infeasibility, but greed. So much spending was slotted to carriers to improve their networks, but instead of investing in capacity and protocol upgrades, it all went to lobbying/exec bonuses.
  - lttlrck 5y ago
    SCTP runs over UDP too. The main reason for not picking it is likely the TLS handshake optimizations they wanted.
    - salawat 5y ago
      It does not run on UDP. It provides a UDP like best-effort transmission mode though, while also optionally allowing for interweaving reliable connection features. If SCTP really ran on UDP. I'd have no reason to be salty, because we'd already be using it.
      - Dylan16807 5y ago
        RFC 6951. It can run over UDP if you want it to, with a clear guide for how to do it. > I'd have no reason to be salty, because we'd already be using it. Direct OS support is a big deal, and UDP gets messed with too. If someone made SCTP-over-UDP the default mode, while changing nothing else, I don't think it would affect adoption at all.
    - xibo9 5y ago
      Nope, SCTP runs at the same layer as UDP.

simiones 5y ago

QUIC is a combination of TLS and TCP essentially, implemented over UDP so that there is some chance that middle-boxes will allow it to pass (there's very little chance to actually use a completely new protocol over IP directly and have your packets received by the vast majority of networks). HTTP over QUIC will probably do a similar number of round-trips compared to HTTP over TCP, but it will do much fewer than HTTP over TLS over TCP. There's no getting away from SYN/SYN-ACK/ACK for a reliable protocol, but QUIC can put certificate negotiation information directly here, instead of the TLSoTCP approach of SYN/SYN-ACK/ACK/ClientHello/ServerHello/ClientKeyExchange/ServerKeyExchange. Additionally, QUIC supports multiple streams over a single physical connection, and correctly implements packet ordering constraints and retries for them. TCP supports a single stream over a connection: any delayed packet will delay the entire stream. In QUIC, a delayed packet will only delay packets from the same logical stream, packets from other streams can still be received successfully on the same connection. This feature is heavily used by HTTP/3: HTTP/2 introduced a concept of HTTP streams, but all HTTP streams were run over the same TCP connection, so over a single TCP stream: a slow packet on HTTP/2 stream 1 will delay all packets from HTTP/2 streams 2, 3 etc. With QUIC, an HTTP/3 stream is a QUIC stream, so a single slow request will not blkc other packets from other requests from being received.

benmmurphy 5y ago
Weirdly enough I think QUIC often does something that is not much better because of address validation. It is not safe for the QUIC server to send a bunch of large packets back to the client source address without being confident the client controls the address. We run QUIC in production so I’ll grab an example conversation to show how many round trips connection setup takes. I guess we might not be optimising connection setup correctly because we are using long running QUIC connections to transport our own protocol and I don’t care how long the connection setup takes. so we are using a slightly older version of QUIC than the RFC and using go-quic on server and client. and this is what i see when creating a connection: 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) address validation is covered in RFC 9000: https://datatracker.ietf.org/doc/html/rfc9000#section-8.1 https://datatracker.ietf.org/doc/html/rfc9000#section-8.1 probably what go-quic does is not optimal because you don't always have to validate the address. 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).

dtech 5y ago

TCP is not the only way to ensure integrity, QUIC protocol ensures it, using UDP as transport. This is how all new protocols do it since there's too many hardware and software roadblocks to use anything but TCP and UDP.

salawat 5y ago
Only because no one wants to upgrade their damn backbone NICS. SCTP solved things way better than QUIC imo except for the infrastructure inertia part. The infrastructure inertia part isn't even so much a question of technical infeasibility, but greed. So much spending was slotted to carriers to improve their networks, but instead of investing in capacity and protocol upgrades, it all went to lobbying/exec bonuses.
- lttlrck 5y ago
  SCTP runs over UDP too. The main reason for not picking it is likely the TLS handshake optimizations they wanted.
  - salawat 5y ago
    It does not run on UDP. It provides a UDP like best-effort transmission mode though, while also optionally allowing for interweaving reliable connection features. If SCTP really ran on UDP. I'd have no reason to be salty, because we'd already be using it.
    - Dylan16807 5y ago
      RFC 6951. It can run over UDP if you want it to, with a clear guide for how to do it. > I'd have no reason to be salty, because we'd already be using it. Direct OS support is a big deal, and UDP gets messed with too. If someone made SCTP-over-UDP the default mode, while changing nothing else, I don't think it would affect adoption at all.
  - xibo9 5y ago
    Nope, SCTP runs at the same layer as UDP.