On Mon, 30 Oct 2017, Dmitri Tikhonov wrote:
Hi Dmitri,
Thanks for bringing this topic to the table. I'm really keen on seeing some
movement in this area and I'm thrilled to see you here pulling strings to make
things happen. I'll do my best to aid this effort!
This point is obvious, but it bears repeating: all but one (file:) protocol
that curl supports use TCP. It may mean that some of the curl guts may need
to be changed. Certainly, this is something to be on the lookout for.
Actually, TFTP is supported by libcurl and it is UDP-based. But I don't think
it changes much. QUIC is different than "just" UDP since it is a whole
protocol built on top of it so it still need a lot of special sauce and magic.
When HTTP/1.x is upgraded to HTTP/2, the same TCP connection is used.
Upgrading to QUIC would require opening a UDP socket and then replacing the
existing TCP socket with it once QUIC connection has been established. It
may make sense to not support HTTP/QUIC upgrade functionality, at least
initially.
Upgrading to HTTP/2 within curl when using plain (non-TLS) HTTP, is basically
done the same way that we handle redirects. The fact that it re-uses the same
connection is just a minor detail. Do a request, figure out some details and
aks for a subsequent request to be done with other properties set.
Doing QUIC after a Alt-Svc: response to a HTTP request could be done
similarly. And that Alt-Svc: response should then populate a "Alt-Svc cache"
so that we can go quic at once for a while into the future for that particular
origin.
But we can certainly skip the negotiation part to begin with, for simplity and
to get something early going first. I'm all for doing things one step at a
time.
On the other hand, QUIC has no scheme of its own [3], so there is no good
way to tell curl to fetch a resource using QUIC.
Unless we add an option for it, like we can set CURLOPT_HTTP_VERSION to
CURL_HTTP_VERSION_2_PRIOR_KNOWLEDGE, to ask for HTTP/2 directly without
"upgrade". I imagine we can have something similar to that for QUIC. Or
perhaps even a way to pre-populate the (pending) "alt-svc"-cache with some
"use quic on this origin" instruction.
QUIC gives clients ability to keep a connection open using a PING frame.
Alternatively, we can say that since establishing QUIC connection is cheap
(0-RTT), curl should not go out of its way to keep a connection open.
I don't think this is much different than TCP keepalive from curl's point of
view.
Kicking -- or ticking -- QUIC often enough
------------------------------------------
QUIC requires frequent "ticking" in order to maintain connection
performance. I am not sure how curl could support QUIC using the easy
interface -- the user would have to call *something* to drive the QUIC
connection along.
The libcurl API already has a timeout system that makes it require that the
application calls it again no later than at a certain amount of time so I
think that system should work even for QUIC's much shorter timeout
requirements. Properly written applictions should work fine still.
I think the best plan is to get something working, punting some of
the considerations above, and then make it more portable:
- Pretend that "httpq:" is a real scheme, at least to get
started.
I'm not convinced a new dedicated scheme is the right forward since no user in
the real world will use such URLs. I think setting a dedication libcurl option
for "direct-to-quic" is a better approach since it would then still use the
same URL others would use, just shortcut the negotiation phase.
- Use LSQUIC without bothering with abstracting SSL functions.
I'm perfectly fine with that. We should just keep in mind that someone might
still at some later point in time add support for ANOTHER quic library so we
shouldn't make things too lsquic specific. I'm not saying we should bend over
backwards for it, just not close doors we could otherwise keep open.
We started out with a fixed SSL using system, we now have 12 backends. We
started out with one resolver system, we now have three. Even the SSH system
is right now being split up into two separate backends. We have a long history
of people coming up with use cases where they want pluggable backend systems
where we are powered by 3rd party libraries...
- Add new curl protocol handler for QUIC. (I do not know enough
yet to break this into subitems.)
I think inspiration can be sought in the HTTP/2 backend, but I too don't have
a lot of extra to bring to the table on this right now for me it is primarily
because I haven't properly read up on how the lsquic API works.
--
/ daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
