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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Quinn 0.2.0: QUIC protocol implementation in Rust

207 点作者 whoisnnamdi超过 6 年前

12 条评论

trishume超过 6 年前
I&#x27;m really excited about QUIC and Quinn because I think a lot of networking problems map on to the &quot;many serial streams in parallel&quot; model. QUIC libraries will make it easier to write those apps than plopping them on top of TCP, while getting better performance with lower latency.<p>QUIC makes great progress on so many different networking problems: head of line blocking, connection establishment latency, connection migration, multiplexing...
bacon_waffle超过 6 年前
In case anyone else wasn&#x27;t familiar with QUIC: it appears to be a Google-developed protocol that&#x27;s similar to TCP+TLS+HTTP&#x2F;2, but lower latency and with several other advantages, implemented on top of UDP. <a href="https:&#x2F;&#x2F;www.chromium.org&#x2F;quic" rel="nofollow">https:&#x2F;&#x2F;www.chromium.org&#x2F;quic</a>
评论 #18966238 未加载
评论 #18966205 未加载
ggm超过 6 年前
I maybe have this wrong, but earlier versions of QUIC did PMTU like &quot;tasting&quot; of the viable MTU inside the protocol to get to big, from small. Thus, working around the external IP level pMTU blockers.<p>I think they backed off to a simpler model of just using small inside QUIC.<p>I kind of liked the former: one day we need to get rid of dependencies on small packets, and move to Jumbo in the wide.<p>(dreamer..)
评论 #18965027 未加载
gmueckl超过 6 年前
I really like the idea of having independent streams in a single connection. But for some applications I would like to have the ability to have unordered and optionally unreliable datagram channels in the same conmection as well. I have my own networking library that does this based on UDP, but I would rather spend my times on other things than maintaining that.
评论 #18964918 未加载
评论 #18964886 未加载
评论 #18969303 未加载
walterbell超过 6 年前
Other than Google, who uses QUIC in production?
评论 #18964878 未加载
评论 #18964506 未加载
评论 #18964462 未加载
评论 #18967103 未加载
评论 #18964515 未加载
评论 #18965669 未加载
评论 #18964530 未加载
评论 #18964647 未加载
bayesian_horse超过 6 年前
The problem is not so much the browser implementation, but rather the server software and network infrastructure like proxies and firewalls. I already ran into problems with Http 2 or websockets in some cases. QUIC being UDP can only exacerbate these issues..
评论 #18966403 未加载
评论 #18967486 未加载
mtgx超过 6 年前
And here&#x27;s the (more modern) Noise-based nQUIC version:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;rot256&#x2F;ninn" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rot256&#x2F;ninn</a>
评论 #18964702 未加载
评论 #18966232 未加载
dogecoinbase超过 6 年前
Remember: <a href="https:&#x2F;&#x2F;blog.apnic.net&#x2F;2018&#x2F;01&#x2F;29&#x2F;measuring-quic-vs-tcp-mobile-desktop&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.apnic.net&#x2F;2018&#x2F;01&#x2F;29&#x2F;measuring-quic-vs-tcp-mobi...</a><p><i>In fact, our experiments showed that QUIC always consumes more than half of the bottleneck bandwidth, even as the number of competing TCP flows increases.</i>
rapsey超过 6 年前
Are there any numbers out there how often 443 udp is blocked on wifis?
评论 #18965920 未加载
the_other_guy超过 6 年前
is GQUIC going to be supported by Envoy any time soon?
eeZah7Ux超过 6 年前
A reusable library in C would be more useful.
评论 #18967568 未加载
mbgaxyz超过 6 年前
Tangential point... is it accurate for the project to describe itself as a &quot;pure-Rust implementation of the QUIC protocol&quot; when it uses platform dependent unsafe code? <a href="https:&#x2F;&#x2F;github.com&#x2F;djc&#x2F;quinn&#x2F;blob&#x2F;ce514af89a73f530e1366e79e5819008ef666648&#x2F;quinn&#x2F;src&#x2F;platform&#x2F;cmsg.rs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;djc&#x2F;quinn&#x2F;blob&#x2F;ce514af89a73f530e1366e79e5...</a>
评论 #18965822 未加载
评论 #18966530 未加载
评论 #18965810 未加载