A QUIC implementation in pure go


A QUIC implementation in pure Go

PkgGoDev Travis Build Status CircleCI Build Status Windows Build Status Code Coverage

quic-go is an implementation of the QUIC protocol in Go. It implements the IETF QUIC draft-29 and draft-32.

Version compatibility

Since quic-go is under active development, there's no guarantee that two builds of different commits are interoperable. The QUIC version used in the master branch is just a placeholder, and should not be considered stable.

When using quic-go as a library, please always use a tagged release. Only these releases use the official draft version numbers.


We currently support Go 1.14+, with Go modules support enabled.

Running tests:

go test ./...

QUIC without HTTP/3

Take a look at this echo example.


As a server

See the example server. Starting a QUIC server is very similar to the standard lib http in go:

http.Handle("/", http.FileServer(http.Dir(wwwDir)))
http3.ListenAndServeQUIC("localhost:4242", "/path/to/cert/chain.pem", "/path/to/privkey.pem", nil)

As a client

See the example client. Use a http3.RoundTripper as a Transport in a http.Client.

  Transport: &http3.RoundTripper{},


We are always happy to welcome new contributors! We have a number of self-contained issues that are suitable for first-time contributors, they are tagged with help wanted. If you have any questions, please feel free to reach out by opening an issue or leaving a comment.

  • http3 post request with body failed

    http3 post request with body failed

    this problem origin publish in caddy issue, but i think it is a quic go problems, more info:https://github.com/caddyserver/caddy/issues/3429

    post request has body so can not return response. you can reference this link: https://github.com/caddyserver/caddy/issues/3429

    i am a co-worker with @majc08149 , i find problem reason and code. But I do not know how to modify? @mholt

    I paste problem code : file->net/http/transfer.go:371

    if t.BodyCloser != nil { if err := t.BodyCloser.Close(); err != nil { return err } } the function BodyCloser.Close() call quic-go->http3->body.go Close() like : ` func (r *body) Close() error { // quic.Stream.Close() closes the write side, not the read side if r.isRequest { return r.str.Close() } r.requestDone() r.str.CancelRead(quic.ErrorCode(errorRequestCanceled)) return nil }


    this call quic-go->stream.go function 👍 func (s *stream) Close() error { if err := s.sendStream.Close(); err != nil { return err } return nil }

    the function s.sendStream.Close() will call func (s *sendStream) Close() error , this function call s.ctxCancel() to cancel context. so the request reverseproxy will be canceled.

    please help me how to fix this bug?

    opened by ggjjlldd 53
  • support Go 1.15

    support Go 1.15

    As of https://go-review.googlesource.com/c/go/+/234237 last week, tls.ClientSessionState has been modified, so I see panics on the latest version:

    panic: qtls.ClientSessionState not compatible with tls.ClientSessionState
    goroutine 1 [running]:
    	/home/mvdan/go/pkg/mod/github.com/lucas-clemente/[email protected]/internal/handshake/unsafe.go:26 +0x205

    I assume this requires a bit of extra code to handle the go1.15 build tag. beta1 was released recently, and thankfully it includes that commit, so you can add that tagged version to CI to test the fix. RC1 should be out in about two weeks, and I doubt they'll change the tls package further.

    opened by mvdan 28
  • Connection seems dead for 30s, then closes and starts a new one.

    Connection seems dead for 30s, then closes and starts a new one.

    I have an issue where a QUIC video stream seems dead for about 30 seconds before restarting a new connection (new CHLO etc.), this happens about 8 times in the 10min video.


    • Server: Caddy using QUIC
    • Client: Chromium 58.0.3029.96 with force-quic-on server
    • node in between to limit throughput with tcconfig (using netem/tc) and tcpdump capture

    Might be related to #576 because:

    1. The last packet sent by the server is at 03:31:24.277
    2. everything is congestion limited
    3. The client keeps sending Ack frames (I suppose for earlier video segments)
    4. Everythin seems normal up until (and including) 03:31:35.415
    5. Then no traffic for 20 seconds after which the client sends something strange:
    frames.RstStreamFrame{StreamID:0x7, ErrorCode:0x6, ByteOffset:0x0}
    Ignoring error in session: RST_STREAM received for unknown stream
    1. This is ignored, but another 20 seconds later, the client closes the connection: ConnectionCloseFrame{ErrorCode:0x19, ReasonPhrase:"No recent network activity."}\
    2. After this the client starts a new connection an everything is fine for a while.

    I have a Wireshark capture, but it is 140MB because of the video. [edit: removed log as it cluttered the conversation]

    opened by twdkeule 27
  • pointers for implementing the client

    pointers for implementing the client

    I'd like to try implementing a client, but I can't tell how much of the session code is going to work or needs to change. It looked almost as if a client API just needs to wrap the rest of the protocol / session code, but I figured I would ask first before digging too deep.

    opened by progrium 21
  • Transport Performance in the wild

    Transport Performance in the wild

    I wrote a couple of simple programs to test libp2p transport performance, and specifically compare QUIC to TCP (see https://github.com/vyzo/libp2p-perf-test).

    Running a server in a linode in NJ and a client in a linode in Frankfurt, I have observed the following:

    • QUIC is almost 3x slower than TCP
    • Adding more streams slows down QUIC transfers even further.

    Specifically, I used a 1GiB file with random data, with the timings below.

    Transferring the file 3 times over TCP-vs-QUIC:

    [email protected]:~# for x in {1..3}; do ./go/bin/test-client /ip4/; done
    2020/06/04 18:23:39 Connecting to QmUgxn8vaVgVDnSxM6qhQzyeXTYXesjJM7iG9TomZjpPcR
    2020/06/04 18:23:39 Connected; requesting data...
    2020/06/04 18:23:39 Transfering data...
    2020/06/04 18:24:09 Received 1073741824 bytes in 30.149238941s
    2020/06/04 18:24:09 Connecting to QmUgxn8vaVgVDnSxM6qhQzyeXTYXesjJM7iG9TomZjpPcR
    2020/06/04 18:24:10 Connected; requesting data...
    2020/06/04 18:24:10 Transfering data...
    2020/06/04 18:24:47 Received 1073741824 bytes in 37.456968339s
    2020/06/04 18:24:48 Connecting to QmUgxn8vaVgVDnSxM6qhQzyeXTYXesjJM7iG9TomZjpPcR
    2020/06/04 18:24:48 Connected; requesting data...
    2020/06/04 18:24:48 Transfering data...
    2020/06/04 18:25:17 Received 1073741824 bytes in 29.308343925s
    [email protected]:~# for x in {1..3}; do ./go/bin/test-client /ip4/; done
    2020/06/04 18:25:32 Connecting to QmUgxn8vaVgVDnSxM6qhQzyeXTYXesjJM7iG9TomZjpPcR
    2020/06/04 18:25:32 Connected; requesting data...
    2020/06/04 18:25:32 Transfering data...
    2020/06/04 18:27:17 Received 1073741824 bytes in 1m44.911661928s
    2020/06/04 18:27:18 Connecting to QmUgxn8vaVgVDnSxM6qhQzyeXTYXesjJM7iG9TomZjpPcR
    2020/06/04 18:27:18 Connected; requesting data...
    2020/06/04 18:27:18 Transfering data...
    2020/06/04 18:28:52 Received 1073741824 bytes in 1m34.259246794s
    2020/06/04 18:28:52 Connecting to QmUgxn8vaVgVDnSxM6qhQzyeXTYXesjJM7iG9TomZjpPcR
    2020/06/04 18:28:52 Connected; requesting data...
    2020/06/04 18:28:52 Transfering data...
    2020/06/04 18:30:35 Received 1073741824 bytes in 1m42.629025709s

    Transferring the file twice using 2 parallel streams:

    [email protected]:~# ./go/bin/test-client -streams 2 /ip4/
    2020/06/04 19:21:54 Connecting to QmUgxn8vaVgVDnSxM6qhQzyeXTYXesjJM7iG9TomZjpPcR
    2020/06/04 19:21:55 Connected; requesting data...
    2020/06/04 19:21:55 Transferring data in 2 parallel streams
    2020/06/04 19:22:52 Received 2147483648 bytes in 57.743506072s
    [email protected]:~# ./go/bin/test-client -streams 2 /ip4/
    2020/06/04 19:23:04 Connecting to QmUgxn8vaVgVDnSxM6qhQzyeXTYXesjJM7iG9TomZjpPcR
    2020/06/04 19:23:05 Connected; requesting data...
    2020/06/04 19:23:05 Transferring data in 2 parallel streams
    2020/06/04 19:26:48 Received 2147483648 bytes in 3m43.026014572s

    cc @stebalien

    opened by vyzo 20
  • race condition in sendWindowSize

    race condition in sendWindowSize

    Read at 0x00c0001d0000 by goroutine 25:
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/internal/flowcontrol/base_flow_controller.go:60 +0x51
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/internal/flowcontrol/connection_flow_controller.go:42 +0x4d
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/internal/flowcontrol/stream_flow_controller.go:110 +0x96
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/send_stream.go:98 +0x588
          <autogenerated>:1 +0xcf
          /home/go/src/NGN/common/sm-quic-conn/conn.go:311 +0x101
          /home/go/src/NGN/common/sm-conn/sm-conn.go:165 +0x55a
          /home/go/src/NGN/common/sm-conn/sm-conn.go:224 +0x1a1
          /home/go/src/NGN/cmd/client/client.go:319 +0xbd2
    Previous write at 0x00c0001d0000 by goroutine 15:
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/internal/flowcontrol/base_flow_controller.go:46 +0x79
          <autogenerated>:1 +0x61
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/internal/flowcontrol/stream_flow_controller.go:106 +0xa6
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/send_stream.go:232 +0x55e
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/send_stream.go:178 +0x366
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/send_stream.go:155 +0xa9                                                                     
          <autogenerated>:1 +0x86
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/framer.go:95 +0x44d
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/packet_packer.go:349 +0x5b3
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/packet_packer.go:264 +0x3cd
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/session.go:1105 +0x22b
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/session.go:1013 +0x6f4
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/session.go:426 +0x1688
          /home/go/go/pkg/mod/github.com/lucas-clemente/[email protected]/client.go:269 +0x85
    Goroutine 25 (running) created at:
          XXX/client.go:250 +0x79f
          XXX/client.go:168 +0x6a8
          XXX/client.go:569 +0x139
    opened by apmattil 20
  • only include quic-trace when the quictrace build flag is set

    only include quic-trace when the quictrace build flag is set

    Fixes #2797.

    I'm not ready to drop quic-trace yet, but it turns out to be really easy to hide behind a build tag.

    With quic-trace:

     ❯ go build -tags quictrace -o server example/main.go &&  go build -tags quictrace -o client ./example/client/main.go && du -sh client server
     14M	client
     15M	server

    Without quic-trace:

    ❯ go build -o server example/main.go &&  go build -o client ./example/client/main.go && du -sh client server
    8.8M	client
     13M	server

    Not sure why the difference is so much bigger for the client. @egonelbre any ideas?

    opened by marten-seemann 19
  • PMTUD may be implemented incorrectly

    PMTUD may be implemented incorrectly


    We talked about the DF bit on Windows a while ago, and I submitted https://github.com/lucas-clemente/quic-go/pull/3155. But apparently it led to this unforeseen problem https://github.com/lucas-clemente/quic-go/issues/3273 so PMTUD ended up being disabled on Windows as a dirty fix. As I revisited this today I realized that perhaps there is something fundamentally wrong with the way quic-go currently implements PMTUD, and it's not really a Windows issue.

    Previously we both assumed that the DF bit is enabled by default on Linux. But that's not true, as the man page says this:


    The default behavior on Linux (IP_PMTUDISC_WANT) is to only set DF bit when the packet is smaller than the path MTU, and fragment the packet otherwise. This implies that right now even if quic-go sends a packet larger than the path MTU, it will still be fragmented, sent, and received, nullifying PMTUD altogether. And if you explicitly set it to IP_PMTUDISC_DO, you will get a similar behavior as on Windows - errors when trying to send packets larger than the path MTU, instead of discarding them silently.

    I wrote a demo and verified this on my Ubuntu 20.04 server, which has an MTU of 1500. When it sends packets smaller than 1500, the DF bit is set. When it sends packets larger than 1500, it fragments them and sends them successfully nonetheless.


    help wanted 
    opened by tobyxdd 18
  • Question about setting IP_PKTINFO for QUIC servers listening on wildcard (

    Question about setting IP_PKTINFO for QUIC servers listening on wildcard (

    Hey guys.

    I'm trying to solve the problem raised in https://github.com/lucas-clemente/quic-go/issues/1736 by setting IP_PKTINFO on as sockopt but this doesn't seem to work.

    How can I tell:

    To reproduce this, I have a server behind anycast with a bunch of ips on a single NIC.

    This is the server: https://pastebin.com/wJuVcWya (its the hello world example repurposed a bit).

    My expectation here when I run tcpdump is I should see communication flow the from the same ip both ways but this isn't the case.

    sudo tcpdump -n -i eth0 port 4242 and udp
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on vlan100, link-type EN10MB (Ethernet), capture size 262144 bytes
    14:44:27.742629 IP > UDP, length 1252
    14:44:27.743298 IP > UDP, length 37

    When running my server with strace I also cannot see ipi_addr on sendmsg().

    I'm using the latest revision of quic-go and running go1.17.

    opened by sudarshan-reddy 18
  • implement stream deadlines

    implement stream deadlines

    Fixes #514.

    I ran the benchmark tests a couple of times, and I can't see any performance impact. @lucas-clemente, maybe you have more ideas for benchmarking this?

    opened by marten-seemann 18
  • HTTP/3 request timeout with io.PipeReader body

    HTTP/3 request timeout with io.PipeReader body

    With an http.Request like this:

    pipeR, pipeW := io.Pipe()
    relayReq, err := http.NewRequestWithContext(ctx, "POST", "", pipeR)
    resp, err := rt.RoundTrip(relayReq)
    io.Copy(pipeW, os.Stdin)

    The request fails with the following error.

    $ echo TEST | go run .
    2020/06/21 xx:xx:xx Read on stream 0 canceled with error code 268

    But if the body in http.NewRequestWithContext is a strings.Reader or nil, the request would successfully complete.

    The request body seems to be sent asynchronously. Why would the RoundTrip call get blocked and eventually time out?

    Example code:

    package main
    import (
    func main() {
    	if err := dial(); err != nil {
    func dial() error {
    	http.Handle("/", http.NotFoundHandler())
    	server := http3.Server{
    		Server: &http.Server{
    			Addr: "",
    	go server.ListenAndServeTLS("c", "k")
    	rt := http3.RoundTripper{
    		DisableCompression: true,
    		TLSClientConfig: &tls.Config{
    			InsecureSkipVerify: true,
    	pipeR, pipeW := io.Pipe()
    	ctx, cancel := context.WithTimeout(context.Background(), time.Second)
    	defer cancel()
    	relayReq, err := http.NewRequestWithContext(ctx, "POST", "", pipeR)
    	if err != nil {
    		return err
    	resp, err := rt.RoundTrip(relayReq)
    	if err != nil {
    		return err
    	errCh := make(chan error)
    	go func() {
    		io.Copy(pipeW, os.Stdin)
    		errCh <- nil
    	go func() {
    		io.Copy(os.Stdout, resp.Body)
    		errCh <- nil
    	return nil
    opened by l2dy 17
  • Optimizing (*sentPacketHistory).FirstOutstanding

    Optimizing (*sentPacketHistory).FirstOutstanding

    Hi @marten-seemann,

    quic-go currently spends a lot of CPU time on (*sentPacketHistory).FirstOutstanding when transmitting at high speed over a high packet loss connection. (Of course, usually this can't happen at all, as the built-in CUBIC congestion control slows the connection down to a crawl when packet loss rate is high. I have replaced it with a custom constant-speed CC.)

    The following call graph was generated by a transmission test between 2 servers ($5 AWS Lightsail) @ 200 Mbps, simulated 30ms, 4% packet loss link



    Showing nodes accounting for 3080ms, 28.33% of 10870ms total
          flat  flat%   sum%        cum   cum%   calls calls% + context
                                                1640ms 53.25% |   github.com/lucas-clemente/quic-go/internal/ackhandler.(*sentPacketHistory).HasOutstandingPackets (inline)
                                                1440ms 46.75% |   github.com/lucas-clemente/quic-go/internal/ackhandler.(*sentPacketHandler).PeekPacketNumber (inline)
        2490ms 22.91% 22.91%     3080ms 28.33%                | github.com/lucas-clemente/quic-go/internal/ackhandler.(*sentPacketHistory).FirstOutstanding
                                                 590ms 19.16% |   github.com/lucas-clemente/quic-go/internal/ackhandler.(*PacketElement).Next (inline)
                                                 590ms   100% |   github.com/lucas-clemente/quic-go/internal/ackhandler.(*sentPacketHistory).FirstOutstanding (inline)
         590ms  5.43% 28.33%      590ms  5.43%                | github.com/lucas-clemente/quic-go/internal/ackhandler.(*PacketElement).Next

    FirstOutstanding was taking up nearly 30% of the runtime and was a major CPU bottleneck. The program occupied the entire CPU core, couldn't get faster than a merely 100 Mbps because of it. And it gets worse as I crank up the loss rate. Switching to servers with better CPU performance does improve the situation - I was able to hit ~700 Mbps between two Ryzen 7 machines over the same link.

    Do you have any thoughts on what could be done to optimize this part of the code? Perhaps we can add some kind of cache, or pre-calculate the first outstanding packet every time the linked list is modified, instead of iterating it every call?

    pprof sample attached: pprof.hy_linux_amd64.samples.cpu.002.pb.gz

    enhancement help wanted 
    opened by tobyxdd 1
  • [WIP] Implement initial HTTP/3 datagrams

    [WIP] Implement initial HTTP/3 datagrams

    This is my attempt so far at implementing HTTP/3 datagrams as outlined here: https://datatracker.ietf.org/doc/html/draft-ietf-masque-h3-datagram

    I am not happy with a couple things I had to do to get this to work, mainly the fact datagrams are bound to HTTP/3 streams due to their "Quarter Stream ID" property. Tests currently get stuck, which I need to fix still. Also the receive side is not fully implemented.

    Also keeping track of open streams inside the HTTP/3 server/client, I don't like it, would like input on better ways to solve this (since this property is specific to HTTP/3 datagrams and not QUIC datagrams)

    However, reason I open this PR in a draft state is to source some input if this is a) Wanted at all to be in this repository b) The correct approach

    opened by Doridian 1
  • Add support for providing a custom ConnectionID generator via Config

    Add support for providing a custom ConnectionID generator via Config

    This work makes it possible for servers or clients to control how ConnectionIDs are generated, which in turn will force peers in the connection to use those ConnectionIDs as destination connection IDs when sending packets.

    This is useful for scenarios where we want to perform some kind selection on the QUIC packets at the L4 level.

    opened by joliveirinha 4
  • flaky Packet Handler Map test

    flaky Packet Handler Map test

    Packet Handler Map other operations0-RTT
    deletes queues if no connection is created for this connection ID
    panic: number of 0-RTT queues < 0
    goroutine 6018 [running]:
    	/Users/runner/work/quic-go/quic-go/packet_handler_map.go:420 +0x2c8
    created by time.goFunc
    	/Users/runner/hostedtoolcache/go/1.17.11/x64/src/time/sleep.go:180 +0x31
    Ginkgo ran 9 suites in 1m1.682997488s
    opened by marten-seemann 0
  • v0.27.2(Jun 9, 2022)


    • https://github.com/lucas-clemente/quic-go/pull/3443

    Full Changelog: https://github.com/lucas-clemente/quic-go/compare/v0.27.1...v0.27.2

    Source code(tar.gz)
    Source code(zip)
  • v0.27.1(May 23, 2022)

  • v0.27.0(Apr 5, 2022)

    Most Notable Changes

    This release contains a big breaking change: We renamed the quic.Session to quic.Connection. The term "session" was used in gQUIC, but is not used in the QUIC RFC any more. Instead, it's called a "connection" there. We are aware that this API change will cause breakage for downstream users, but it had to be done sooner or later.

    What's Changed

    • improve code coverage of random number generator test by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3358
    • remove parser logic for HTTP/3 DUPLICATE_PUSH frame by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3356
    • remove the SkipSchemeCheck RoundTripOpt by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3353
    • add support for the Extended CONNECT method by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3357
    • update HTTP/3 Datagram to draft-ietf-masque-h3-datagram-07 by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3355
    • respect the request context when dialing by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3359
    • rename the Session to Connection by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3361
    • remove nextdns from list of projects using quic-go by @ignoramous in https://github.com/lucas-clemente/quic-go/pull/3363
    • improve the error thrown when building with an unsupported Go version by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3364
    • add support for serializing Extended CONNECT requests by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3360
    • stop using the deprecated net.Error.Temporary, update golangci-lint to v1.45.2 by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3367

    New Contributors

    • @ignoramous made their first contribution in https://github.com/lucas-clemente/quic-go/pull/3363

    Full Changelog: https://github.com/lucas-clemente/quic-go/compare/v0.26.0...v0.27.0

    Source code(tar.gz)
    Source code(zip)
  • v0.26.0(Mar 22, 2022)

    Most Notable Changes

    This release

    • fixes a problem with Path MTU Discovery (https://github.com/lucas-clemente/quic-go/issues/3327)
    • adds an environment variable to turn off the receive buffer warning (QUIC_GO_DISABLE_RECEIVE_BUFFER_WARNING)
    • adds http3.Server.ServeListener to allow switching http3.Servers on top of the same quic.Listener
    • adds support for Go 1.18

    What's Changed

    • sendQueue: ignore "datagram too large" error by @zllovesuki in https://github.com/lucas-clemente/quic-go/pull/3328
    • add env to disable the receive buffer warning by @arashpayan in https://github.com/lucas-clemente/quic-go/pull/3339
    • move set DF implementation to separate files & avoid the need for OOBCapablePacketConn by @tobyxdd in https://github.com/lucas-clemente/quic-go/pull/3334
    • don't print a receive buffer warning for closed connections by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3346
    • update for Go 1.18 by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3345
    • Implement http3.Server.ServeListener by @renbou in https://github.com/lucas-clemente/quic-go/pull/3349
    • avoid recursion when skipping unknown HTTP/3 frames by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3354
    • Advertise multiple listeners via Alt-Svc and improve perf of SetQuicHeaders by @renbou in https://github.com/lucas-clemente/quic-go/pull/3352

    New Contributors

    • @zllovesuki made their first contribution in https://github.com/lucas-clemente/quic-go/pull/3328
    • @arashpayan made their first contribution in https://github.com/lucas-clemente/quic-go/pull/3339
    • @renbou made their first contribution in https://github.com/lucas-clemente/quic-go/pull/3349

    Full Changelog: https://github.com/lucas-clemente/quic-go/compare/v0.25.0...v0.26.0

    Source code(tar.gz)
    Source code(zip)
  • v0.25.0(Jan 18, 2022)

    What's Changed

    • add support for Go 1.18 by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3298
    • add a AllowConnectionWindowIncrease config option by @marten-seemann in https://github.com/lucas-clemente/quic-go/pull/3317

    New Contributors

    • @birneee made their first contribution in https://github.com/lucas-clemente/quic-go/pull/3310
    • @user8446 made their first contribution in https://github.com/lucas-clemente/quic-go/pull/3315

    Full Changelog: https://github.com/lucas-clemente/quic-go/compare/v0.24.0...v0.25.0

    Source code(tar.gz)
    Source code(zip)
  • v0.24.0(Oct 21, 2021)

  • v0.23.0(Sep 19, 2021)

  • v0.22.1(Aug 12, 2021)

    This patch release fixes a race condition when Stream.Read and Stream.CancelRead are called concurrently (https://github.com/lucas-clemente/quic-go/issues/3239).

    Source code(tar.gz)
    Source code(zip)
  • v0.22.0(Jul 25, 2021)


    • use ReadBatch to read multiple UDP packets from the socket with a single syscall
    • add a config option (Config.DisableVersionNegotiationPackets) to disable sending of Version Negotiation packets

    Breaking Changes

    • drop support for QUIC draft versions 32 and 34
    • remove the RetireBugBackwardsCompatibilityMode, which was intended to mitigate a bug when retiring connection IDs in quic-go in v0.17.2 and ealier

    Other Notable Changes

    • fix busy-looping caused by a certain loss pattern (#3231)
    • fix behavior of exported errors when using errors.Is (#3215)
    • update qtls to include the fix for the recently discovered crypto/tls panic
    Source code(tar.gz)
    Source code(zip)
  • v0.21.2(Jul 15, 2021)

    • update qtls (for Go 1.15, 1.16 and 1.17rc1) to include the fix for the crypto/tls panic (see https://groups.google.com/g/golang-dev/c/5LJ2V7rd-Ag/m/YGLHVBZ6AAAJ for details)
    • fix busy-looping caused by a certain loss pattern #3231
    Source code(tar.gz)
    Source code(zip)
  • v0.21.1(Jun 18, 2021)

  • v0.21.0(Jun 1, 2021)

  • v0.20.0(Mar 19, 2021)

  • v0.19.2(Nov 20, 2020)

    • fixes the way packets are padded by using PADDING frames instead of random data outside the QUIC packet (#2876), which could lead to invalid packets for very short server certificates
    • fixes usage of the syscall package (#2886)
    Source code(tar.gz)
    Source code(zip)
  • v0.19.0(Nov 11, 2020)

    • adds support for QUIC draft-32 (draft-29 is still supported)
    • add DialEarlyContext and DialAddrEarlyContext (#2814)
    • increase the kernel UDP receive buffer size (#2791)
    • add support for HTTP CONNECT (#2761)
    • read ECN bits and send ECN counts in ACK frames (#2741)
    • fix busy looping when using OpenStreamSync (#2824)
    • fix QPACK static table entry (#2845)

    ... and a lot more

    Source code(tar.gz)
    Source code(zip)
  • v0.18.0(Aug 20, 2020)

    • adds support for Go 1.15 (Go 1.14 is also still supported)
    • doesn't change support QUIC versions (i.e. is wire-compatible with v0.17.x release)
    • adds a new logging / tracing interface, see logging.Tracer

    Please note the release notes of the v0.17.3 release when upgrading a deployment that uses both quic-go clients and servers.

    Source code(tar.gz)
    Source code(zip)
  • v0.17.3(Jul 11, 2020)

    This is a bug-fix release that fixes #2658, which can lead to occasional connection timeouts (see https://github.com/ipfs/go-ipfs/issues/7526 for some real-world data).

    This release cherry-picks #2652, #2651 and #2660. Deployments that have existing deployments of quic-go client and server that cannot be updated all at the same time should set the quic.RetireBugBackwardsCompatibilityMode flag. This flag fixes the connection timeouts, as long as at least one of the peers uses v0.17.3. Note that this flag will be removed in a future release.

    Source code(tar.gz)
    Source code(zip)
  • v0.17.2(Jul 2, 2020)

  • v0.17.1(Jun 20, 2020)

  • v0.17.0(Jun 20, 2020)

  • v0.14.0(Dec 4, 2019)

  • v0.13.0(Nov 5, 2019)

  • v0.11.2(May 31, 2019)

  • v0.10.2(May 31, 2019)

  • v0.11.1(Apr 12, 2019)

Lucas Clemente
Lucas Clemente
quiwi 🥝 - QUIC implementation in Go.

Quiwi ?? QUIC transport protocol (https://quicwg.org/) implementation in Go. The goal is to provide low level APIs for applications or protocols using

GoBurrow 238 Jun 11, 2022
WebTransport implementation based on quic-go (https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/)

webtransport-go webtransport-go is an implementation of the WebTransport protocol, based on quic-go. It currently implements draft-02 of the specifica

Marten Seemann 38 Jun 22, 2022
Antenna RPC is an RPC protocol for distributed computing, it's based on QUIC and Colfer. its currently an WIP.

aRPC - Antenna Remote Procedure Call Antenna remote procedure call (aRPC) is an RPC protocol focused on distributed processing and HPC. aRPC is implem

Raphael de Carvalho Almeida 3 Jun 16, 2021
WebTransport-Go - WebTransport Server based on quic-go

WebTransportServer 基于quic-go的封装,用于支持WebTransport。以下是使用Example import ( "fmt"

dexter 4 May 2, 2022
Pure Go implementation of the WebRTC API

Pion WebRTC A pure Go implementation of the WebRTC API New Release Pion WebRTC v3.0.0 has been released! See the release notes to learn about new feat

Pion 9.5k Jun 23, 2022
A Windows named pipe implementation written in pure Go.

npipe Package npipe provides a pure Go wrapper around Windows named pipes. Windows named pipe documentation: http://msdn.microsoft.com/en-us/library/w

Nate Finch 244 Jun 15, 2022
Pure Go implementation of the WebRTC API

Pure Go implementation of the WebRTC API

Pion 9.5k Jun 26, 2022
🚀 gnet is a high-performance, lightweight, non-blocking, event-driven networking framework written in pure Go./ gnet 是一个高性能、轻量级、非阻塞的事件驱动 Go 网络框架。

English | ???? 中文 ?? Introduction gnet is an event-driven networking framework that is fast and lightweight. It makes direct epoll and kqueue syscalls

Andy Pan 6.6k Jun 20, 2022
Pure-Go library for cross-platform local peer discovery using UDP multicast :woman: :repeat: :woman:

peerdiscovery Pure-go library for cross-platform thread-safe local peer discovery using UDP multicast. I needed to use peer discovery for croc and eve

Zack 546 Jun 20, 2022
Distributed RTC System by pure Go and Flutter

ION is a distributed real-time communication system, the goal is to chat anydevice, anytime, anywhere! Distributed Real-time Communication System ION

Pion 3.5k Jun 21, 2022
A pure Unix shell script implementing ACME client protocol

An ACME Shell script: acme.sh An ACME protocol client written purely in Shell (Unix shell) language. Full ACME protocol implementation. Support ACME v

acme.sh 27.1k Jun 26, 2022
Pure-Go HBase client

Golang HBase client This is a pure Go client for HBase. Current status: beta. Supported Versions HBase >= 1.0 Installation go get github.com/tsuna/goh

Benoit Sigoure 635 Jun 27, 2022
Pure Go Brotli encoder and decoder

This package is a brotli compressor and decompressor implemented in Go. It was translated from the reference implementation (https://github.com/google

Andy Balholm 406 Jun 24, 2022
Snugger is a light weight but fast network recon scanner that is written from pure golang

Snugger is a light weight but fast network recon scanner that is written from pure golang. with this scann you can ARP your network, port scan hosts and host lists, as well as scan for BSSId

RE43P3R 2 May 19, 2022
A go implementation of the STUN client (RFC 3489 and RFC 5389)

go-stun go-stun is a STUN (RFC 3489, 5389) client implementation in golang (a.k.a. UDP hole punching). RFC 3489: STUN - Simple Traversal of User Datag

Cong Ding 509 Jun 22, 2022
Fast RFC 5389 STUN implementation in go

STUN Package stun implements Session Traversal Utilities for NAT (STUN) [RFC5389] protocol and client with no external dependencies and zero allocatio

null 487 Jun 20, 2022
A LWM2M Client and Server implementation (For Go/Golang)

Betwixt - A LWM2M Client and Server in Go Betwixt is a Lightweight M2M implementation written in Go OMA Lightweight M2M is a protocol from the Open Mo

Zubair Hamed 54 May 28, 2022
A Socket.IO backend implementation written in Go

go-socket.io The socketio package is a simple abstraction layer for different web browser- supported transport mechanisms. It is fully compatible with

Jukka-Pekka Kekkonen 405 May 24, 2022
An Etsy StatsD (https://github.com/etsy/statsd) implementation in Go

STATSD-GO Port of Etsy's statsd, written in Go. This was forked from https://github.com/amir/gographite to provide Ganglia submission support. USAGE U

Jeff Buchbinder 45 Mar 5, 2021