TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Curl HTTP/3 Performance

157 点作者 BitPirate超过 1 年前

14 条评论

hlandau超过 1 年前
Author of the OpenSSL QUIC stack here. Great writeup.<p>TBQH, I&#x27;m actually really pleased with these performance figures - we haven&#x27;t had time yet to do this kind of profiling or make any optimisations. So what we&#x27;re seeing here is the performance prior to any kind of concerted measurement or optimisation effort on our part. In that context I&#x27;m actually very pleasantly surprised at how close things are to existing, more mature implementations in some of these benchmarks. Of course there&#x27;s now plenty of tuning and optimisation work to be done to close this gap.
评论 #39167048 未加载
评论 #39167394 未加载
评论 #39168673 未加载
评论 #39165298 未加载
vitus超过 1 年前
It is promising to see that openssl-quic serial throughput is within 10-20% of more mature implementations such as quiche. (Which quiche, though? Is this Google&#x27;s quiche, written in C++, or Cloudflare&#x27;s quiche, written in Rust? It turns out that&#x27;s approximately the only word that starts with &quot;quic&quot; that isn&#x27;t a derivative of &quot;quick&quot;.)<p>One of QUIC&#x27;s weaknesses is that it&#x27;s known to be much less CPU efficient, largely due to the lack of things like HW offload for TLS.<p>&gt; Also, the HTTP&#x2F;1.1 numbers are a bit unfair since they do run 50 TCP connections against the server.<p>To emphasize this point: no modern browser will open 50 concurrent connections to the same server for 50 GET requests. You&#x27;ll see connection pooling of, uh, 6 (at least for Chrome and Firefox), so the problems of head-of-line blocking that HTTP&#x2F;2 and HTTP&#x2F;3 attempt to solve would have manifested in more realistic benchmarks.<p>Some questions I have:<p>- What kind of CPU is in use? How much actual hw parallelism do you have in practice?<p>- Are these requests actually going over the network (even a LAN)? What&#x27;s the MTU?<p>- How many trials went into each of these graphs? What are the error bars on these?
评论 #39166843 未加载
评论 #39167865 未加载
评论 #39167293 未加载
评论 #39169482 未加载
BitPirate超过 1 年前
The performance difference between H1&#x2F;H2 and H3 in this test doesn&#x27;t really surprise me. The obvious part is the highly optimised TCP stack. But I fear that the benchmark setup itself might be a bit flawed.<p>The biggest factor is the caddy version used for the benchmark. The quic-go library in caddy v2.6.2 lacks GSO support, which is crucial to avoid high syscall overhead.<p>The quic-go version in caddy v2.6.2 also doesn&#x27;t adjust UDP buffer sizes.<p>The other thing that&#x27;s not clear from the blog post is the network path used. Running the benchmark over loopback only would give TCP-based protocols an advantage if the QUIC library doesn&#x27;t support MTU discovery.
评论 #39165265 未加载
nezirus超过 1 年前
Maybe shout out to HAProxy people, like many they&#x27;ve observed performance problems with OpenSSL 3.x series. But having good old OpenSSL with QUIC would be so convenient for distro packages etc<p><a href="https:&#x2F;&#x2F;github.com&#x2F;haproxy&#x2F;wiki&#x2F;wiki&#x2F;SSL-Libraries-Support-Status">https:&#x2F;&#x2F;github.com&#x2F;haproxy&#x2F;wiki&#x2F;wiki&#x2F;SSL-Libraries-Support-S...</a>
samueloph超过 1 年前
Nice write-up.<p>I&#x27;m one of the Debian maintainers of curl and we are close to enabling http3 on the gnutls libcurl we ship.<p>We have also started discussing the plan for enabling http3 on the curl CLI in time for the next stable release.<p>Right now the only option is to switch the CLI to use the gnutls libcurl, but looks like it might be possible to stay with openssl, depending on when non-experimental support lands and how good openssl&#x27;s implementation is.
评论 #39172689 未加载
评论 #39166322 未加载
londons_explore超过 1 年前
Anyone else disappointed that the figures for <i>localhost</i> are in MB&#x2F;s not GB&#x2F;s?<p>The whole lot just seems an order of magnitude slower than I was hoping to see.
评论 #39169347 未加载
mgaunard超过 1 年前
HTTP&#x2F;1 remains the one with the highest bandwidth.<p>No surprise here.
评论 #39164351 未加载
评论 #39164217 未加载
评论 #39164877 未加载
评论 #39165345 未加载
评论 #39170723 未加载
评论 #39164789 未加载
apitman超过 1 年前
Very nice. I would love to see some numbers including simulated packet loss. That&#x27;s theoretically an area h3 would have an advantage.
1vuio0pswjnm7超过 1 年前
Would it be worthwhile to test QUIC using some other TLS library besides OpenSSL, e.g., wolfSSL. I think I read that the the cURL author is working with them, or for them. Apologies if this is incorrect.
jupp0r超过 1 年前
Great writeup, but the diagrams are downright awful. I&#x27;d separate the different facets visually to make it easier to see the difference vs those different colors.
superkuh超过 1 年前
Can cURL&#x27;s HTTP&#x2F;3 implementation work with self signed certs? Pretty much every other HTTP&#x2F;3 lib used by major browsers do not. And since HTTP&#x2F;3 does not allow for null cypher or TLS-less connections this means in order to establish an HTTP&#x2F;3 connection a third party CA must be involved.<p>As is right now it is impossible to host a HTTP&#x2F;3 server visitable by a random person you&#x27;ve never met without a corporate CA continually re-approving your ability to. HTTP&#x2F;3 is great for corporate needs but it&#x27;ll be the death of the human web.
评论 #39167267 未加载
jrpelkonen超过 1 年前
I really don’t want to criticize anyone or their hard work, and appreciate both curl and OpenSSL as a long time user. That said, I personally find it disappointing that in 2024 major new modules are being written in C. Especially so given that a) existing Quic modules written in Rust exist, and b) there’s a precedent for including Rust code in Curl.<p>Of course there are legacy reasons for maintaining existing codebases, but what is it going to take to shift away from using C for greenfield projects?
评论 #39167025 未加载
评论 #39166985 未加载
评论 #39167874 未加载
评论 #39169514 未加载
评论 #39168458 未加载
throwaway892238超过 1 年前
Lol, wait, HTTP2 and HTTP1.1 both trounce HTTP3? Talk about burying the lede. Wasn&#x27;t performance the whole point behind HTTP3?<p>This chart shows that HTTP2 is more than half as slow as HTTP1.1, and HTTP3 is half as slow as HTTP2. Jesus christ. If these get adopted across the whole web, the whole web&#x27;s performance could get up to 75% slower . That&#x27;s insane. There should be giant red flags on these protocols that say &quot;warning: slows down the internet&quot;
评论 #39169585 未加载
评论 #39167699 未加载
jgalt212超过 1 年前
Does Curl performance really matter? i.e. if it&#x27;s too performant, doesn&#x27;t that increase the odds your spider is blocked? Of course, if you&#x27;re sharding horizontally across targets, then any performance increase is appreciated.
评论 #39165828 未加载
评论 #39169447 未加载