QUIC library "libquic" and Go binding

[Brian Hong]

Hello QUIC team,

Me and my colleague have been working on creating a working QUIC Go binding.

Since QUIC is a transport layer, we have also tried to create a socket-like APIs

along with HTTP QUIC server/client support.

# libquic

In order to do this work, we needed to seperate QUIC code from Chromium

codebase. The result: https://github.com/devsisters/libquic

It is a minimally patched QUIC code extracted from Chromium codebase.

From the library programmers perspective, QUIC code has many unneeded/unused

dependencies. Manually looking for the unneeded dependencies are very tedious.

We have managed to do this anyway and created simple scripts to make syncing

from the upstream Chromium codebase easy as possible.

There have been many patches to utilitity classes and functions. Most of them

are `#if 0` macro patches. They remove unused functions from QUIC. Some patches

actually replace existing functions to remove third-party library dependencies.

All the needed patches are in the repository directory:

[patch](https://github.com/devsisters/libquic/tree/master/patch)

We replaced two components. Class `base::debug::BreakDebugger` and utility

component `url/base/net_util.cc`. The replaced `BreakDebugger` does absolutely

nothing. Replaced `net_util.cc` file removes dependencies to `url/url_parse.h`

which requires Mozilla URL parsing library. Since the functions required by QUIC

were simple, We have reimplemented needed functions with no external dependency.

All the replaced components are in the directory:

[custom](https://github.com/devsisters/libquic/blob/master/custom/)

The result is that the only required dependency is BoringSSL. We have not been

able to replace this with OpenSSL since the functions used by QUIC only exist in

BoringSSL.

# goquic/gospdyquic

This is a work-in-progress QUIC implementation for Go. And is in a *highly

experimental* status. There is some problems when the library is under high

concurrency. We plan to debug this problem, and when we feel certain that the

problem might be from the underlying upstream codebase, we plan to issue it here

too.

The link to the project: https://github.com/devsisters/goquic

There is also gospdyquic: https://github.com/devsisters/gospdyquic

This adds QUIC support to existing Go HTTP server framework. The basic gist is

that you can create QUIC client and servers very easily. See the examples:

  * https://github.com/devsisters/gospdyquic/blob/master/example/client.go

  * https://github.com/devsisters/gospdyquic/blob/master/example/server.go

  * https://github.com/devsisters/gospdyquic/blob/master/example/reverse_proxy.go

# quicbench

Using gospdyquic, we modified existing `gobench` program to benchmark QUIC

servers: https://github.com/devsisters/quicbench

# Preliminary benchmark results

Here are some preliminary benchmark results. Details are in the `goquic` site.

| Payload Size | Requests per Second |
| ------------ | ------------------: |
| 30 B         | 23832.18            |
| 1 kB         | 21704.84            |
| 5 kB         | 9343.58             |
| 10 kB        | 5312.75             |

On 10kB case, calculating the total network throughput is `435Mbps`.

Connection performance results are `2905.58 CPS`.

Details: https://github.com/devsisters/goquic#preliminary-benchmarks

# Conclusion

We hope that our work would help QUIC ecosystem prosper. We've also licensed

our code with same 3-clause BSD license from Chromium. We don't intent to fork

from Chromium project. The code will be frequently synced from upstream. The

syncing process itself is also designed to be effortless as possible.

(see: https://github.com/devsisters/libquic#syncing-from-upstream )

Also, one more thing. :) If Chromium team would somehow 'bless' our project,

it would be very great. Let's find ways to collaborate.

Thank you for reading this. Contact me for any questions regarding this project.

Best regards,

Sung-jin Brian Hong

--

Sung-jin (Brian) Hong

Senior Technical Lead

Devsisters Corp.

+82-2-544-2950 (Work)

+82-2-544-3625 (Fax)

+82-10-6247-8846 (Mobile)

CONFIDENTIALITY. This communication is intended only for the use of the intended recipient(s) and may contain information that is privileged and confidential.  If you are not the intended recipient, please note that any dissemination of this communication is prohibited.  If you have received this communication in error, please erase all copies of the message, including all attachments, and please also notify the sender immediately.  Thank you for your cooperation. 

[Ryan Hamilton]

Exciting work! Thanks for sharing this.

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Dave Taht]

awesome. now we can finally benchmark quic with netperf-wrapper
against fq_codel and other fq/aqm systems.

--
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

[Jana Iyengar]

Very cool, and thanks for the work!!

[Derek Perez]

Wow, great work! Excited to try this out in Go.

Derek Perez |

Software Engineer |

p...@google.com |

650-564-7562

[Juan Benet]

@Brian: this is great!! Thank you so much for doing this. Excited to try it out. 

Will also add it to IPFS soon. If you need any help with things feel free to ask 

us to test things out / give feedback / etc.

@QUIC team: perhaps it may be time to pickup the earlier discussion on this 

list about having standalone (canonical) QUIC repos? Perhaps parting from 

the work Brian +team have done will make this much easier.

I'm really excited about the recent Google push towards making open source 

projects more accessible. From moving projects to github (Go, protobuf, ...) to 

open sourcing grpc, bazel, etc... It would be fantastic to be able to use QUIC 

and collaborate on its development without the significant hurdles working 

within the large chromium repo.

Thanks everyone!

Juan

[袁九江]

Hi,excellent work to make libquic, I am wondering how to use libquic or goquic, do you have some docs or other help? Best wishes.

在 2015年3月16日星期一 UTC+8下午3:34:57，Brian Hong写道：

[Brian Hong]

You should build examples from gospdyquic: https://github.com/devsisters/gospdyquic

There are simple server and reverse proxy examples.

--

You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Raik Aissaoui]

Dear Mr.Brian,

With which language libquic is written? and is it possible to use it with C code?

[袁九江]

I see. But can I use quic without spdy?Just use quic and http? If I can use quic without spdy, what do I need to do next? Best Wishes

在 2015年6月11日星期四 UTC+8下午4:26:30，Brian Hong写道：

[Brian Hong]

QUIC is basically a SPDY/4 or HTTP/2 replacement protocol. It is a application/transport layer hybrid. Although recent QUIC development seems to focus on P2P transport aspects[1].

So, the library name `gospdyquic` might be a little confusing, but it's basically just 'quic and http'. :) So I'm planning to merge `gospdyquic` and `goquic` together to resolve this kind of confusion.

Thanks!

[1]: https://codereview.chromium.org/474383003/

[袁九江]

Thank you for answering me. I saw the code gospdyquic request and response are spdy or http2 style. Is it ok for http1.0. What should I do next? realize "POST" method?

在 2015年6月25日星期四 UTC+8上午10:33:22，Brian Hong写道：