https_dns_proxy icon indicating copy to clipboard operation
https_dns_proxy copied to clipboard

How to compile HTTP/3 support version?

Open Haru202 opened this issue 2 years ago • 6 comments

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?

Haru202 avatar Apr 01 '22 08:04 Haru202

Hi,

the current code on master does compile and work with curl 7.82.0 and HTTP/3 support. Please check this commit: https://github.com/baranyaib90/https_dns_proxy/commit/ee40455be63957626ffc7e669978ac85c9318f91 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)

baranyaib90 avatar Apr 01 '22 20:04 baranyaib90

Yes, I suspect you didn't build libcurl with HTTP/3 support. Can you confirm?

On Sat, 2 Apr 2022 at 07:09, baranyaib90 @.***> wrote:

Hi,

the current code on master does compile and work with curl 7.82.0 and HTTP/3 support. Please check this commit: @.*** https://github.com/baranyaib90/https_dns_proxy/commit/ee40455be63957626ffc7e669978ac85c9318f91 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)

— Reply to this email directly, view it on GitHub https://github.com/aarond10/https_dns_proxy/issues/139#issuecomment-1086281936, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABTOXWKKS3AQP35DHRELADVC5JVTANCNFSM5SH5TBLQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

aarond10 avatar Apr 02 '22 00:04 aarond10

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.

Haru202 avatar Apr 02 '22 10:04 Haru202

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.

Haru202 avatar Apr 02 '22 10:04 Haru202

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 avatar Apr 02 '22 20:04 baranyaib90

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.

baranyaib90 avatar Apr 23 '22 11:04 baranyaib90

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.

kimboslice99 avatar Apr 03 '24 07:04 kimboslice99

@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.

aarond10 avatar Apr 10 '24 05:04 aarond10

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

kimboslice99 avatar Apr 10 '24 15:04 kimboslice99

Seems like it might be worth discussing with openwrt. Perhaps here: https://github.com/openwrt/packages/issues/19382

aarond10 avatar Apr 17 '24 22:04 aarond10