It would be amazing if quic protocol was envisaged. I am currently playing around with this and its astounding for RTC style interaction.
The current c code in google chrome could be codegened to go perhaps.
joeblew99
All 28 comments
Yes, definitely. I've been following the development of the QUIC protocol closely. Unfortunately no public libraries exist for it in Go yet that would be suitable for Caddy. I was looking at the C code and thought about porting it to Go (with codegen), but I don't have enough time/experience right now to do it.
How able and interested would you be in looking into this?
mholt
on 4 May 2015
I could probably work it out. A bit of code gen too because its a huge code base. Its a buggy job to port even then. So right now I have to say no. I am working on the media streaming aspects and octree encoders that will run on top of quic currently, so also can't drop it - otherwise people get pissy :)
Idea though !!
You can also just use the google quic code today in caddy by just running quic as a separate process and tapping it from go over std. It would work fine, and make a good MVP.
joeblew99
on 5 May 2015
+1 to this suggestion. Also glad @mholt is considering it.
If I'm not wrong the https://github.com/bradfitz wanted to implement it.
Then I also found this https://github.com/devsisters/gospdyquic
iMaxopoly
on 17 May 2015
woooh. wow thats awesome
joeblew99
on 17 May 2015
Yeah,Brad is just waiting for the QUIC spec to become more stable. The devsisters library is neat but it uses cgo at this point which makes it unsuitable for this project.
mholt
on 17 May 2015
the ball is rolling though... will be easier to do a conversion from this point
joeblew99
on 17 May 2015
Will be watching the progress of this package (thanks @ApfelUser for the link) - https://github.com/romain-jacotin/quic - if the standard library gets one, we can just use that instead.
mholt
on 5 Jun 2015
@mholt I just found another library: devsisters/goquic. This one seems more complete one.
lenovouser
on 27 Sep 2015
@ApfelUser Thanks for the link. We still can't use it because it uses cgo, unfortunately. However I'm still keeping my eye on that and the one by @romain-jacotin. ;)
mholt
on 27 Sep 2015
HTTP/2 support should render this moot AFAIK
Xe
on 19 Jan 2016
No, it's still relevant. QUIC has no head-of-line blocking and doesn't suffer from slow start like TCP does. QUIC also provides more efficient TLS handshakes though I don't know how that plays with TLS 1.3. Short of it is: QUIC is still of interest.
mholt
on 19 Jan 2016
@Xe Quic gets rid of the TCP issues surrounding HTTP and is implemented in UDP, allowing it to have the QUICness.
Along with MPTCP and MPUDP, QUIC is something I've been watching with a great deal of interest.
faddat
on 22 Apr 2016
Hi there,
We've been building a QUIC library in pure Go over at lucas-clemente/quic-go. We're now at the point where the basic protocol works, and we're able to serve webpages without a problem. There's still a lot of rough edges though, and we are far from suitability for production, but making steady progress :)
To fletch out our public API, I've started on a fork of caddy that adds QUIC support. I don't know the codebase very well though, so it's currently quite hacky ;) Let me know if you're interested in moving forward, so that we could possibly discuss the API needs you have :)
lucas-clemente
on 9 May 2016
@lucas-clemente Your work is obviously very popular :smile: Keep up the great work. I'll be watching it closely, and recommend that any developers who are interested in this should try your project and help its development!
mholt
on 9 May 2016
Hi again, we've made a lot of progress in the past few weeks, and are now thinking about the API in more detail. My current plan is to more or less copy the http.Server struct from the standard lib. Unfortunately it's not an interface, so there's probably gonna be some duplicate code in caddy :/
@mholt: I've seen on twitter that you're currently working on a major rewrite. If any of the stuff using http.Server is affected by that, it'll probably make more sense to base our changes on the new version?
lucas-clemente
on 27 May 2016
@lucas-clemente That's great news! 🙌 Have you thought about proposing your QUIC implementation be worked into the standard library, or at least for now, in the /x/net repos? Or maybe there's a clever way to change or extend http.Server in a way that fits the Go compatibility guarantee and would prevent duplicated code. Duplicated code means that any bug fixes to the original code have to be reflected in the copy...
As for the 0.9 rewrite, indeed a lot is changing but the basic concept is still the same: a custom Server type embeds http.Server and we still call Serve() on that embedded server.
mholt
on 27 May 2016
It probably makes sense to wait with the push to the standard library until QUIC is standardized (or clearly on track, there's some movement at the IETF). I'm not sure whether http.Server is easily adapted, there seem to be a few points where TCP is implicitly assumed (e.g. Serve accepting a net.Listener, which is TCP-only). I will spend some more time thinking about it though, maybe there's an elegant solution that I'm missing.
For caddy, I think the duplicate code would be only very few (<10) duplicate lines, since the custom Server already isolates that stuff quite nicely. Is the 0.9 rewrite happening on the master branch?
lucas-clemente
on 27 May 2016
You're right, incorporating it into the std lib should wait until the spec is more stable.
The 0.9 rewrite is happening here: https://github.com/mholt/caddy/tree/0.9-wip-readonly - that is just a window into my changes; it's not a "working" branch. But I will probably update the branch next week. The stuff that'd be interesting to you is in the caddyhttp/httpserver folder, specifically the server.go file. (That file has received a lot of improvements from what you currently see there, but you'll see those updates next week. Not much has changed with regards to structure.)
< 10 copied lines is okay, I was thinking it might be on the order of hundreds. 😅
mholt
on 27 May 2016
Okay, then I'll wait until next week and have another look then 👍
lucas-clemente
on 27 May 2016
@lucas-clemente I'm a little ahead of schedule. Take a look now. The server is still in caddyhttp/httpserver, in the server.go file. Let me know if you have any questions or trouble finding what you're looking for! I'm quite interested in making QUIC a serious possibility in the future of Caddy.
mholt
on 29 May 2016
Very cool that you're making progress :)
I think I would add a quicServer variable to your httpserver.Server struct, which (the quicServer) embeds a *http.Server. We could then use the same http.Server instance that you embed in httpserver.Server from QUIC, and only need to make sure the quicServer's functions are also called.
One thing that could possibly make this structure more explicit (and imho easier to understand) is to un-embed the *http.Server from your httpserver.Server struct, and make it a named member variable. I don't have a full picture whether that's easy to do (or whether you like that change), what do you think?
lucas-clemente
on 30 May 2016
That should be possible; as you said, there's no interface to implement, so I think I can un-embed it and un-promote *http.Server's methods.
mholt
on 30 May 2016
@lucas-clemente I have un-embedded the *http.Server field - does that make it easier to add in the quic server?
mholt
on 31 May 2016
Looks good! I will try to add QUIC support to your current wip-branch, and then let you know here to get some feedback :)
lucas-clemente
on 31 May 2016
I've opened a pull request (not because I propose merging the changes, just because I like github's diff view there): https://github.com/mholt/caddy/pull/857/files
Note that way I close the quic server there is very un-proper, as the API is not really worked out :)
Let me know what you think!
lucas-clemente
on 31 May 2016
@lucas-clemente That's excellent! I'll work those changes into my 0.9 WIP and try it out. If it seems to be working, the changes in your PR will go out with the first 0.9 beta releases! Thanks!!
mholt
on 31 May 2016
Technically, this is integrated into Caddy in the 0.9-wip branch and will soon be merged into master as an experiment. As QUIC support improves it can leave the experimental label behind it and we're off and away! So I think this issue is now closed. :dancer:
mholt
on 5 Jun 2016
Amazingly quick :) I will be trying out a few things with it.
On Sun, 5 Jun 2016, 07:27 Matt Holt, [email protected] wrote:
Closed #47 https://github.com/mholt/caddy/issues/47.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mholt/caddy/issues/47#event-682086367, or mute the
thread
https://github.com/notifications/unsubscribe/ALcaczLPkXcCQfJP1RPX3sHkOOA3XYFkks5qIl5SgaJpZM4EPr-o
.
joeblew99
on 5 Jun 2016
Related issues
kilpatty
·
3Comments
treviser
·
3Comments
klaasel
·
3Comments
mholt
·
3Comments
dafanasiev
·
3Comments
Most helpful comment
Hi there,
We've been building a QUIC library in pure Go over at lucas-clemente/quic-go. We're now at the point where the basic protocol works, and we're able to serve webpages without a problem. There's still a lot of rough edges though, and we are far from suitability for production, but making steady progress :)
To fletch out our public API, I've started on a fork of caddy that adds QUIC support. I don't know the codebase very well though, so it's currently quite hacky ;) Let me know if you're interested in moving forward, so that we could possibly discuss the API needs you have :)