Comment by ameshkov
8 hours ago
More or less, built on top of it with added udp/icmp.
When writing server and client a lot of time is consumed by additional features, not on implementing the spec itself. For instance, in order to be truly stealthy we have to make sure that it looks *exactly* like Chromium on the outside, and then maintain this similarity as Chromium changes TLS implementation from version to version. Or here’s another example: on the server-side we need to have an anti-probing protection to make it harder to detect what the server does.
QUIC CONNECT supports UDP too now.
We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow.
And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing.
We’re considering switching to it though (or having an option to use it) just to make the server compatible with more clients.
Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.
1 reply →
> QUIC is not bad, but there are places where it either does not work at all or works too slow.
Curious: in your experience where does QUIC work bad/slow?
1 reply →