aarond10/https_dns_proxy

How to compile HTTP/3 support version?

Closed this issue · 10 comments

Haru202 commented

Hello,

I notice that https_dns_proxy support HTTP/3 currently, but it can't be enabled in my compilation.

As you know, I install lastest curl 7.82.0 from the official webiste following the instrustion here.
https://curl.se/docs/http3.html

Eventually, I install curl from source. Besides, I also install packeges regarding c-ares (>=1.11.0) and libev (>=4.25).

After the successful compilation of https_dns_proxy, it still can't support HTTP/3.

./https_dns_proxy -v

WARNING: Running as root without dropping privileges is NOT recommended.

[W] 1648800892.815781 main.c:231 HTTP/2 is not supported by current libcurl
[W] 1648800892.815889 main.c:236 HTTP/3 is not supported by current libcurl
[F] 1648800892.816088 /home/https_dns_proxy/src/https_client.c:633 CURLMOPT_MAX_TOTAL_CONNECTIONS error 6: Unknown option

Is there something wrong with the compilation?
Is there a simple tutorial regarding the HTTP/3 version?

baranyaib90 commented

Hi,

the current code on master does compile and work with curl 7.82.0 and HTTP/3 support.
Please check this commit: baranyaib90@ee40455
I was using Ubuntu 20.04 and worked perfectly.

When you did the steps of https://curl.se/docs/http3.html I hope you have checked the output of ngtcp2 and curl configure commands.
You should check, if openssl (and other libs) were detected accordingly like: OpenSSL: yes (CFLAGS='...')
And in case of curl configure, if you see such line: HTTP3: enabled (ngtcp2 + nghttp3)

aarond10 commented
Haru202 commented

I can confirm that I have already built libcurl with HTTP/3 support judging from the terminal output.

The good news is that I have successfully compiled https_dns_proxy with HTTP/3 support thanks to the guidance from baranyaib90. I suspect whether it can find the correct libcurl location or not which is built from source by myself since the instruction use the option "--prefix" to compile curl.

After checking out baranyaib90's commit, I modified the .gitignore and CMakeLists.txt as baranyaib90 did.
All of them were compiled again and finally it works with HTTP/3 support.

  • 👍1
Haru202 commented

It is strange that the HTTP/3 resolve latency is higher than HTTP/2 each time except the first DNS query by means of looking up domains via dig command.

baranyaib90 commented

About latency:

  • If all libraries are compiled in debug mode (and not in release) it's not so surprising.
  • If libcurl always exchanges new encryption key at the beginning of every HTTP/3 request, that could be a problem and need to be optimized.I will test this later on.
baranyaib90 commented

Haru202 you are right, with debug curl build, latency is strange:

  • HTTP/2 is around 70 ms in average for me
  • HTTP/3 is more like 200-300 ms typically

Sadly I don't know why.
If I will have the time, I will check with release build.

kimboslice99 commented

Being this is a pain to compile, why do we expect people to compile it? and even to go so far as adding a nag within luci about it, yet no packages available to support this.

We should not be pointing people to a doc page which says to build it 😕 We shouldnt need to compile anything just to get up-to-date libs.

aarond10 commented

@kimboslice99, it's not really my place to say. The binary was written around libcurl, libares and libev. These were decided long long ago because they were common on systems like OpenWRT and with dynamic linking this meant a very small binary footprint. HTTP/3 support comes via libcurl. I think you might want to talk to libcurl folk or the OpenWRT libcurl maintainers.

  • 👍1
kimboslice99 commented

Seems someone else had the same thought as I, cURL HTTP/3 pre-built packages

aarond10 commented

Seems like it might be worth discussing with openwrt. Perhaps here: openwrt/packages#19382