IPFS Transports: TCP vs. QUIC Explained

This series' libp2p article described security and stream multiplexing as separate negotiated steps on top of a connection, without dwelling on what that connection actually runs over. Transport is that underlying layer, and IPFS doesn't commit to just one: TCP and QUIC both work, and understanding what QUIC actually changes explains why a modern IPFS node dials both at once instead of picking one and moving on.

TL;DR:

• libp2p is transport-agnostic by design, covered briefly in this series' libp2p article; TCP and QUIC are the two primary transports non-browser IPFS nodes use to connect to each other
• TCP connections need two full round-trips before any encrypted application data can flow: one for the TCP handshake, one more for the TLS or Noise handshake layered on top
• QUIC collapses that into one round-trip for a new connection, and can send application data immediately, zero extra round-trips, when resuming a connection to a peer it's talked to before
• QUIC also eliminates head-of-line blocking: TCP exposes one ordered byte stream, so one lost packet stalls every stream multiplexed on top of it, while QUIC's streams are independent at the transport level
• Since go-ipfs 0.6.0, QUIC has been enabled by default alongside TCP, and libp2p dials every transport a peer advertises in parallel, so a slow or failed QUIC attempt doesn't hold up the connection if TCP succeeds first

Transport: The Layer Underneath Everything Else in This Series

Every connection-level detail this series has already covered, PeerID verification, the Noise or TLS security handshake, Yamux stream multiplexing, assumes a working connection already exists between two peers. Transport is what actually establishes that connection: the literal network protocol carrying bytes between machines. libp2p doesn't hardcode one transport, which is exactly why this series' libp2p article listed "transport agnostic" as one of its core design goals. TCP and QUIC are the two that matter most for non-browser IPFS nodes talking to each other.

TCP's Cost: Two Round-Trips Before Anything Useful Happens

A plain TCP connection needs its own handshake before any application-level protocol can start, and IPFS layers real work on top of that: the Noise or TLS security handshake this series' libp2p article covers has to happen after TCP connects, not before. That ordering means a new connection costs two full round-trips before any encrypted application data can move: one round-trip to establish TCP itself, a second for the security handshake on top of it. On a slow or high-latency link, that's real, measurable delay before a single Bitswap message or DHT query can even be sent.

What QUIC Actually Changes

QUIC is a transport protocol built on top of UDP that bakes encryption in as a first-class part of the handshake instead of layering it on afterward. That combination is what collapses the two-round-trip cost: establishing a new QUIC connection takes a single round-trip, and resuming a connection to a peer it has valid session state for can send application data with zero additional round-trips, immediately. The other structural difference matters just as much: TCP exposes a single ordered byte stream to whatever's multiplexing on top of it, so if one packet gets lost, every stream sharing that connection stalls until it's retransmitted and reordered, the head-of-line blocking problem. QUIC's streams are independent at the transport level, so a lost packet on one stream doesn't block delivery on the others.

Why IPFS Dials Both At Once Instead of Choosing

Since go-ipfs 0.6.0, QUIC has been enabled by default for both inbound and outbound connections, alongside TCP rather than replacing it. When connecting to a new peer, libp2p dials every transport that peer has advertised in parallel, TCP and QUIC simultaneously, rather than trying one and falling back to the other only on failure. That parallel-dial approach means a slow or blocked QUIC path, some network environments still restrict UDP traffic, doesn't cost the connection anything: TCP can complete first and the connection proceeds, while QUIC remains available for peers and networks where it works cleanly and gets to skip the two-round-trip cost this article describes.

What About Browsers?

Everything above describes non-browser nodes, which can open raw TCP and QUIC sockets directly. A browser can't; it's restricted to the connection types a browser environment actually exposes, which is why this series' libp2p and Helia coverage both mention Circuit Relay and WebRTC-based options for browser-based peers specifically. WebTransport, built on top of QUIC, is the newer option purpose-built for this gap: a browser-compatible way to get QUIC's low-latency, no-head-of-line-blocking benefits without needing the raw socket access a browser sandbox won't grant. A browser-based Helia node choosing between these isn't picking TCP versus QUIC the way a server-side node does, it's picking among the specific subset of transports a browser is actually allowed to open at all.

Why This Doesn't Show Up in Gateway Requests

Everything above is specific to peer-to-peer libp2p connections, the same DHT lookups and Bitswap exchanges this series has already covered in depth. A request to an AIOZ Pin gateway, or any HTTP gateway, is a plain HTTPS request, running over ordinary TCP-plus-TLS the same way any web request does, not a libp2p connection at all. The transport choice covered in this article is invisible to that path entirely, it only matters for genuine peer-to-peer retrieval, where two IPFS nodes are establishing a direct connection to exchange DHT and Bitswap traffic with each other.

Frequently Asked Questions

Does IPFS use TCP or QUIC? Both. libp2p is transport-agnostic, and since go-ipfs 0.6.0, QUIC has been enabled by default alongside TCP, with both dialed in parallel when connecting to a new peer.

What makes QUIC faster than TCP for a new connection? QUIC collapses connection setup and the security handshake into a single round-trip, where TCP-plus-TLS or TCP-plus-Noise needs two: one for TCP itself, one more for the security layer on top.

What is head-of-line blocking, and why does QUIC avoid it? TCP exposes one ordered byte stream, so a single lost packet stalls every multiplexed stream sharing that connection until it's retransmitted. QUIC's streams are independent at the transport level, so one stream's lost packet doesn't block the others.

Why does libp2p dial both TCP and QUIC instead of just using QUIC? Some networks restrict UDP traffic, which QUIC needs. Dialing both in parallel means a blocked or slow QUIC path doesn't cost anything, since TCP can still complete the connection.

Does QUIC matter for requests to an AIOZ Pin gateway? No. A gateway request is a plain HTTPS request over ordinary TCP, not a libp2p connection. Transport choice between TCP and QUIC only applies to direct peer-to-peer libp2p connections.

Is QUIC encryption separate from the Noise handshake this series covers elsewhere? QUIC bakes encryption into its own connection setup. On top of that, libp2p connections, regardless of transport, still negotiate their own security layer the same way this series' libp2p article describes.

Related Reading

• libp2p: The Networking Layer Underneath IPFS - the connection-establishment sequence this article's transport layer sits underneath
• How IPFS Finds and Retrieves Your Files: DHT Provider Records and Bitswap Explained - the peer-to-peer traffic that actually runs over the transports covered here
• IPFS Private Networks: Swarm Keys Explained - another connection-layer restriction, enforced above the transport rather than by changing it
• What Actually Determines IPFS Retrieval Speed - where this article's connection-setup cost fits among the other costs that add up to total latency

References

• libp2p: QUIC
• IPFS Blog: go-ipfs 0.6.0 is here: QUIC, Noise, Peering and more