State of QUIC proxy support

[klzgrad]

Caddy v1's QUIC was not working with Chrome in Jan 2019.

It was working in March 2019.

It was in flux in October 2019, see #23.

Caddy v2's IETF QUIC is not working with Chrome 83 to Chrome 85 yet.

I'll keep track of this until it's supported.

[klzgrad]

Ok, QUIC is working all along for regular HTTP/3. Only that CONNECT method is not working in quic-go. The error was too cryptic for me to realize it's the same old issue.

Edit: And don't get your hopes up. QUIC's performance is bad as usual.

[klzgrad]

The whole pipeline is still more or less buggy.

• QUIC proxy support in Chromium upstream is still in limbo (v87) after I exploded it.
• Caddy forwardproxy support is easier to fix klzgrad/forwardproxy@5fbc551.
• Caddy's QUIC is not too hard to fix Support CONNECT method quic-go/quic-go#2748.
• HTTP/3 Fast Open is broken for reasons I've yet to understand.
• Even without QUIC Fast Open, the UDP traffic is throttled real hard in practice. This is the most crucial factor. Without traffic efficiency the whole ordeal is moot.
• Also there is one more hidden bug that breaks long downloads. Not sure Caddy's or Chromium's.

[klzgrad]

QUIC support can be tested as following:

• Use naiveproxy v85.0.4183.83-4 or newer
• Caddyfile:

{
  experimental_http3
}
:443, example.com
tls me@example.com
route {
  forward_proxy {
    basic_auth user pass
    hide_ip
    hide_via
    probe_resistance secret.com
  }
  file_server {
    root /var/www/html
  }
}

• Naive config.json:

{
  "listen": "socks://127.0.0.1:1080",
  "proxy": "quic://user:pass@example.com",
  "log": ""
}

[klzgrad]

Caddy's QUIC is based on quic-go, which is not yet optimized, cf. quic-go/quic-go#341 quic-go/quic-go#302. So the benchmark shows ~3MB/s. This situation should improve as quic-go gets optimized.

Using Chromium's epoll_quic_server and epoll_quic_client with BBR etc the benchmark shows ~15MB/s (this should still be artificial throttling by ISP), slower than kcptun's 20MB/s and slower than multiple TCP connections 40MB/s.

[ghost]

Is it possible to integrate epoll_quic_server and epoll_quic_client into the naive proxy binary?

Can't wait to see how quic with BBR performs :)

[felixding]

If I recall correctly, compared to TCP, quic falls behind even with BBR. There are some test results on Facebook's mvst issue tracker.

[klzgrad]

No epoll_quic_server in naiveproxy #23 (comment)

[GWONGJYULEI]

• Naive config.json:

{
  "listen": "socks://127.0.0.1:1080",
  "proxy": "quic://user:pass@example.com",
  "log": ""
}

After I changed the config.json from "https://user:pass@example.com" to "quic://user:pass@example.com", I can not run the naive.exe but just flash by.
And I used the naiveproxy-v85.0.4183.83-4-win-x64

[klzgrad]

Issue is fixed.

[lxhao61]

可对QUIC支持进行如下测试：

• 使用naiveproxy v85.0.4183.83-4或更高版本
• 建立球童2：

git clone -b naive https://github.com/klzgrad/forwardproxy
git clone -b v0.18.0 https://github.com/lucas-clemente/quic-go
cd quic-go
git config user.email me@here
git config user.name me
git cherry-pick c81eeb8bb855eeba6df52660efd99be6d74e6c87
cd ..
go get -u github.com/caddyserver/xcaddy/cmd/xcaddy
~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy=$PWD/forwardproxy --with github.com/lucas-clemente/quic-go=$PWD/quic-go
sudo setcap cap_net_bind_service=+ep ./caddy

• Caddyfile：

{
  experimental_http3
}
:443, example.com
tls me@example.com
route {
  forward_proxy {
    basic_auth user pass
    hide_ip
    hide_via
    probe_resistance secret.com
  }
  file_server {
    root /var/www/html
  }
}

• 天真的config.json：

{
  "listen": "socks://127.0.0.1:1080",
  "proxy": "quic://user:pass@example.com",
  "log": ""
}

The current quic-go version has reached v0.19.3. How to upgrade the quic-go version to the latest version of this application?y

可对QUIC支持进行如下测试：

• 使用naiveproxy v85.0.4183.83-4或更高版本
• 建立球童2：

git clone -b naive https://github.com/klzgrad/forwardproxy
git clone -b v0.18.0 https://github.com/lucas-clemente/quic-go
cd quic-go
git config user.email me@here
git config user.name me
git cherry-pick c81eeb8bb855eeba6df52660efd99be6d74e6c87
cd ..
go get -u github.com/caddyserver/xcaddy/cmd/xcaddy
~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy=$PWD/forwardproxy --with github.com/lucas-clemente/quic-go=$PWD/quic-go
sudo setcap cap_net_bind_service=+ep ./caddy

• Caddyfile：

{
  experimental_http3
}
:443, example.com
tls me@example.com
route {
  forward_proxy {
    basic_auth user pass
    hide_ip
    hide_via
    probe_resistance secret.com
  }
  file_server {
    root /var/www/html
  }
}

• 天真的config.json：

{
  "listen": "socks://127.0.0.1:1080",
  "proxy": "quic://user:pass@example.com",
  "log": ""
}

The current quic-go version has reached v0.19.3. How to upgrade the quic-go version to the latest version of Build Caddy2?

[klzgrad]

Something like

git clone -b naive https://github.com/klzgrad/forwardproxy
go get -u github.com/caddyserver/xcaddy/cmd/xcaddy
~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy=$PWD/forwardproxy --with github.com/lucas-clemente/quic-go@master
sudo setcap cap_net_bind_service=+ep ./caddy

I haven't test it.

[lxhao61]

Something like

git clone -b naive https://github.com/klzgrad/forwardproxy
go get -u github.com/caddyserver/xcaddy/cmd/xcaddy
~/go/bin/xcaddy build --with github.com/caddyserver/forwardproxy=$PWD/forwardproxy --with github.com/lucas-clemente/quic-go@master
sudo setcap cap_net_bind_service=+ep ./caddy

I haven't test it.

Tested according to the method you gave, but the compilation failed and could not be completed.

[klzgrad]

but the compilation failed

It works for me.

---

This issue is concluded in this release https://github.com/klzgrad/naiveproxy/releases/tag/v88.0.4324.96-1.

[ArcCal]

在新版caddy中，开启quic支持，貌似需要使用类似下列的global options
{
servers :443 {
protocol {
experimental_http3
}
}
}

喜爱用quic模式的朋友可以关注

[diwenx]

And don't get your hopes up. QUIC's performance is bad as usual.

https://blog.cloudflare.com/masque-building-a-new-protocol-into-cloudflare-warp/
https://blog.cloudflare.com/unlocking-quic-proxying-potential/
Could the QUIC performance issue be due to the double reliability layer when used as a proxy?

[klzgrad]

Could the QUIC performance issue be due to the double reliability layer when used as a proxy?

My direct observation of QUIC performance issue is a single kind of data points: I run a (E: non proxied) file download over h2 or quic over the same network route, and quic is much slower in throughput. I guess this is mostly due to ISP discrimination.

I read before some other blog posts from the big vendors about large scale performance benchmarks of quic and the improvement is not as big as in some microbenchmarks.