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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

S2n-QUIC (Rust implementation of QUIC)

105 点作者 jeffbarr大约 3 年前

3 条评论

batisteo大约 3 年前
<a href="https:&#x2F;&#x2F;github.com&#x2F;quinn-rs&#x2F;quinn" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;quinn-rs&#x2F;quinn</a>
评论 #30379300 未加载
评论 #30379084 未加载
JoshTriplett大约 3 年前
Is there a &quot;can I use&quot; for networks&#x2F;middleboxes&#x2F;etc and the problems that arise with them, that talks about the real-world aspects of trying to use QUIC universally?<p>I&#x27;d love to use QUIC between a (non-browser) client and server for which both ends are code I&#x27;ve written, without having to have fallbacks to HTTP&#x2F;1.1 or HTTP&#x2F;2. (Among other things, I love the idea of just establishing one connection and using it for two-way communication, without worrying about things like WebSocket.)<p>However, the client also needs to run in random places, and while it doesn&#x27;t necessarily need to support <i>hostile</i> networks, it does need to support <i>broken</i> networks, which to a first approximation can be similar.<p>Are there statistics available for whether and how often QUIC (or more generally UDP) works with:<p>- Random ISPs of varying quality - Cell data connections - Shops and airports and similar, which commonly use captive portals and try to intercept traffic when they shouldn&#x27;t, and come pretty close to being hostile networks - Vaguely reasonable corporate networks, that aren&#x27;t <i>trying</i> to block QUIC but might do so through misconfiguration or through some misguided policy put in place for unrelated reasons (e.g &quot;our firewall rules are written about TCP and just drop all UDP and ICMP, and people complain but nobody with the power to change it&quot;) - Somewhat less reasonable corporate networks, that force everything through a proxy and may require things like CONNECT-UDP or SOCKS, but still aren&#x27;t actively <i>trying</i> to block QUIC<p>I&#x27;m hoping that efforts like fly.io&#x27;s userspace wireguard stack (which uses UDP) might have data here.<p>I&#x27;m specifically not asking about the case of networks that are actually <i>trying</i> to be hostile (to QUIC or otherwise), both because such networks may break any number of things including TLS or WebSockets, and because I&#x27;d like to avoid restarting the recurring discussion about whether QUIC&#x2F;etc are a conspiracy to disempower network administrators. I&#x27;d love to know the statistics there too, though, if they&#x27;re available.<p>I&#x27;m also curious about the best-known method to reliably and efficiently tunnel QUIC out of a network within a client, for the purposes of separating always-QUIC logic from weird-network-handling logic. Does it make sense, for instance, to have a standard way to tunnel a secure QUIC connection through an insecure TCP connection?
评论 #30381448 未加载
评论 #30379322 未加载
rektide大约 3 年前
there&#x27;s a bunch of bullet points going through some staple material, but the last bullet point has some absurdly good high grade features!<p>&gt; <i>and much more, including CUBIC congestion controller support, packet pacing, Generic Segmentation Offload support, Path MTU discovery, and unique connection identifiers detached from the address</i><p>also, a blog announcement appeared for this, <a href="https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;security&#x2F;introducing-s2n-quic-open-source-protocol-rust&#x2F;" rel="nofollow">https:&#x2F;&#x2F;aws.amazon.com&#x2F;blogs&#x2F;security&#x2F;introducing-s2n-quic-o...</a>
评论 #30379680 未加载