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