On Mon, Oct 30, 2017 at 10:39:14PM +0100, Daniel Stenberg wrote:
> On Mon, 30 Oct 2017, Dmitri Tikhonov wrote:
>
> >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.

Ah, I missed this part.

> 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.

Certainly.

> >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.

I see, so it is much more doable than I thought.

> 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.

OK, sounds good.

> >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.

I think this is exactly what we want -- I take back the made-up httpq:
scheme.

> >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.

OK, we can probably even use the same values for QUIC.

> >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.

This is good -- I will look for it.

> >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.

I agree -- using an option is better (see above).

> > - 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.

Sure -- we would come up with an API so that a QUIC implementation
could provide a plugin. LSQUIC API is flexible: there is more than
one way to use it.

> > - 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,

I will read that module.

> 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.

I will write a high-level overview of the LSQUIC APIs (and some of its
internals) to go along with the doxygen docs [1]. I will try to post
it to this list soon.

1. https://rawgit.com/litespeedtech/lsquic-client/master/docs/

  - Dmitri.
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-10-31