Stories with Tag QUIC

• Go-msquic: A new QUIC/HTTP3 library for Go

  permalink

  Posted: 2025-02-19 04:48:09

  Verbose tl;dr

  go-msquic is a new QUIC and HTTP/3 library for Go, built as a wrapper around the performant msquic library from Microsoft. It aims to provide a Go-friendly API while leveraging msquic's speed and efficiency. The library supports both client and server implementations, offering features like stream management, connection control, and cryptographic configurations. While still under active development, go-msquic represents a promising option for Go developers seeking a fast and robust QUIC implementation backed by a mature, production-ready core.

  This GitHub repository, go-msquic, introduces a new QUIC and HTTP/3 library specifically designed for the Go programming language. It leverages the underlying msquic library, which is Microsoft's implementation of the QUIC protocol. This distinction is crucial as it separates go-msquic from other Go QUIC libraries that might rely on different implementations like the Google QUIC library or a completely independent one.

  The core purpose of go-msquic is to provide Go developers with a performant and robust way to utilize the QUIC protocol and, by extension, the HTTP/3 protocol. The library focuses on exposing the functionality of msquic to the Go ecosystem, allowing developers to build applications that can benefit from the improved speed, reliability, and security offered by QUIC.

  The repository provides a relatively straightforward API, designed to be idiomatic Go. This allows developers familiar with Go's networking packages to easily integrate QUIC functionality into their projects. The examples included in the repository showcase common use cases such as setting up a QUIC server and client, establishing a connection, and sending and receiving data. This practical approach aims to lower the barrier to entry for developers wanting to experiment with or deploy QUIC-based applications.

  A key advantage of using msquic as the foundation is its mature development and backing by Microsoft. This implies a level of stability, performance optimization, and ongoing maintenance that can be beneficial for projects relying on go-msquic. Moreover, it likely ensures compatibility with other systems and applications utilizing the msquic implementation.

  While the library is functional and demonstrates core QUIC features, the repository's documentation indicates it's still under development. This suggests that there might be ongoing additions, refinements, and potential breaking changes as the library progresses towards a more stable release. It also implies that not all features of the underlying msquic library might be currently exposed or fully implemented within the Go wrapper. Despite this, the existing functionality provides a valuable starting point for Go developers interested in exploring the world of QUIC and HTTP/3.

  • Go
  • Golang
  • msquic
  • QUIC
  • HTTP3
  • HTTP/3
  • networking
  • Library
  • performance
  • Internet Protocol
  • Web Development

  Summary of Comments ( 15 )
  https://news.ycombinator.com/item?id=43098690

  Verbose tl;dr

  Hacker News users discussed the go-msquic library, primarily focusing on its use of CGO and the implications for performance and debugging. Some expressed concern about the complexity introduced by CGO, potentially leading to harder debugging and build processes. Others pointed out that leveraging the mature msquic library from Microsoft might offer performance benefits that outweigh the downsides of CGO, especially given Microsoft's significant investment in QUIC. The potential for improved performance over pure Go implementations and the trade-offs between performance and maintainability were recurring themes. A few commenters also touched upon the lack of HTTP/3 support in the standard Go library and the desire for a more robust solution.

  The Hacker News post "Go-msquic: A new QUIC/HTTP3 library for Go" discussing the go-msquic library has generated several comments exploring various aspects of the project and QUIC in general.

  Several commenters discuss the performance characteristics of go-msquic. One commenter expresses interest in seeing benchmark comparisons between go-msquic and other popular Go QUIC libraries like quic-go. They specifically ask about performance differences and whether go-msquic leverages specific features of MsQuic to achieve better performance. Another commenter, seemingly knowledgeable about MsQuic's internals, suggests that go-msquic's performance is likely limited by the single OS thread utilized by MsQuic, hindering its ability to fully leverage multi-core processors. They further explain that this limitation stems from MsQuic's internal architecture and its integration with the Windows kernel, which is not optimized for multi-threaded performance in user mode.

  The discussion also touches upon the cross-platform compatibility of MsQuic and go-msquic. A commenter points out that MsQuic, the underlying library, is Windows-only, therefore limiting the portability of any Go library built upon it. This observation leads to a broader conversation about the challenges of building cross-platform QUIC libraries and the desire for a truly portable, performant solution in the Go ecosystem.

  One commenter expresses skepticism about using cgo, which go-msquic employs to interface with the underlying MsQuic C API. They voice concerns about the performance overhead and complexity introduced by cgo and suggest exploring alternatives that minimize or eliminate its usage.

  The thread also briefly delves into the development history of QUIC libraries in Go, mentioning the initial work on a pure Go implementation within the quic-go project and subsequent efforts to incorporate MsQuic for potentially better performance. This context provides a glimpse into the evolving landscape of QUIC adoption within the Go community.

  Finally, some comments raise questions about the maturity and long-term support for go-msquic, given its relatively recent release. The commenters express hope for continued development and broader community adoption to ensure the project's viability.

• Trust, 2-Party Relays, and QUIC

  permalink

  Posted: 2025-02-11 18:44:48

  Verbose tl;dr

  The blog post explores the challenges of establishing trust in decentralized systems, particularly focusing on securely bootstrapping communication between two untrusting parties. It proposes a solution using QUIC and 2-party relays to create a verifiable path of encrypted communication. This involves one party choosing a relay server they trust and communicating that choice (and associated relay authentication information) to the other party. This second party can then, regardless of whether they trust the chosen relay, securely establish communication through the relay using QUIC's built-in cryptographic mechanisms. This setup ensures end-to-end encryption and authenticates both parties, allowing them to build trust and exchange further information necessary for direct peer-to-peer communication, ultimately bypassing the relay.

  The blog post "Trust, 2-Party Relays, and QUIC" explores the complexities of establishing trust in decentralized communication networks, particularly focusing on a proposed architecture utilizing two-party relays and the QUIC transport protocol. The author begins by highlighting the fundamental challenge of bootstrapping trust in a system where no pre-existing relationships or central authorities exist. They argue that traditional Public Key Infrastructures (PKIs) are inadequate for this purpose due to their reliance on centralized Certificate Authorities (CAs), which introduce single points of failure and control.

  The post then introduces the concept of a "web of trust," where trust is established through a network of interconnected individuals vouching for each other. While conceptually appealing, the author points out the practical difficulties of managing and scaling such a system, particularly in the context of large, dynamic networks.

  As a potential solution, the author proposes a two-party relay architecture. In this system, communication between two parties, Alice and Bob, is facilitated by two relay servers, Alice's relay and Bob's relay. Crucially, these relays do not decrypt or interfere with the content of the messages; they simply forward encrypted packets between the two parties. This preserves end-to-end encryption and minimizes the trust placed in the relays. The relays' primary function is to act as rendezvous points, enabling Alice and Bob to discover each other and establish a direct, encrypted connection using QUIC.

  The choice of QUIC is significant. Its built-in features, such as connection migration and address validation, are particularly well-suited to this architecture. Connection migration allows the communication channel to remain stable even if the IP addresses of Alice or Bob change, which is common in mobile or dynamic network environments. Address validation helps prevent impersonation attacks by ensuring that the parties are communicating with the intended recipients.

  The post then elaborates on the trust model within this system. Trust is primarily established between Alice and her chosen relay, and similarly between Bob and his relay. This localized trust relationship is significantly simpler to manage than the complex web of trust required in fully decentralized systems. Furthermore, the relays themselves don't need to trust each other, simplifying the overall architecture.

  The author acknowledges that the proposed system is not a complete solution to the problem of trust bootstrapping. Questions remain about how users choose their relays, how to prevent malicious relays, and how to handle relay failures. However, the post presents a promising approach that leverages the capabilities of QUIC to simplify the complexities of decentralized communication and offers a potential pathway towards more robust and trustworthy decentralized networks. The use of two relays, instead of a single relay, helps mitigate some of the risks associated with relying on a single intermediary. The post concludes by suggesting that this architecture could form the foundation for future explorations into decentralized communication and trust establishment.

  • Trust
  • Security
  • networking
  • QUIC
  • HTTP/3
  • Relays
  • Two-Party Relays
  • Bootstrapping
  • Cryptography
  • Internet Protocols
  • Web Performance
  • privacy

  Summary of Comments ( 29 )
  https://news.ycombinator.com/item?id=43016574

  Verbose tl;dr

  Hacker News users discuss the complexity and potential benefits of the proposed trust bootstrapping system using 2-party relays and QUIC. Some express skepticism about its practicality and the added overhead compared to existing solutions like DNS and HTTPS. Concerns are raised regarding the reliance on relay operators, potential centralization, and performance implications. Others find the idea intriguing, particularly its potential for censorship resistance and improved privacy, acknowledging that it represents a significant departure from established internet infrastructure. The discussion also touches upon the challenges of key distribution, the suitability of QUIC for this purpose, and the need for robust relay discovery mechanisms. Several commenters highlight the difficulty of achieving true decentralization and the risk of malicious relays. A few suggest alternative approaches like blockchain-based solutions or mesh networking. Overall, the comments reveal a mixed reception to the proposal, with some excitement tempered by pragmatic concerns about its feasibility and security implications.

  The Hacker News post titled "Trust, 2-Party Relays, and QUIC," linking to an article on bootstrapping trust, has generated several comments discussing various aspects of trust and relay systems.

  One commenter questions the feasibility of the proposed system surviving in a hostile environment, suggesting that regulatory bodies could compel major players like Google or Cloudflare to block certain relays, effectively neutralizing the system. This raises concerns about the resilience of decentralized systems against centralized pressure.

  Another comment highlights the potential for middleboxes to interfere with QUIC connections, drawing a parallel to past issues with middleboxes disrupting peer-to-peer technologies. This raises the importance of considering how such interference might impact the practicality of the proposed relay system.

  A further comment focuses on the necessity of addressing Sybil attacks, a known vulnerability in decentralized systems where malicious actors create multiple fake identities to gain undue influence. The commenter suggests that solutions like proof-of-work or proof-of-stake could be employed to mitigate this threat, but also acknowledges the complexities and trade-offs associated with these approaches.

  The discussion also touches on the broader issue of trust in online interactions. One comment emphasizes that the challenge isn't establishing trust, but rather the subsequent issue of maintaining that trust over time. This highlights the dynamic nature of trust and the need for ongoing mechanisms to ensure its continued validity.

  Finally, a commenter notes the potential legal ramifications of such a system, suggesting that relays could be compelled to hand over user data or face legal repercussions. This raises important legal and ethical considerations for designing and deploying such relay networks.

  Several other comments express general interest in the concept and offer suggestions for related technologies or projects, indicating a general curiosity and engagement with the topic of trust and relay systems within the Hacker News community. The overall tone of the discussion is one of cautious optimism, acknowledging the potential benefits of the proposed system while also recognizing the significant challenges that need to be addressed.