基于Kademlia的P2P系统：UDP与TCP传输协议选型咨询

Great question—this is a super common pain point when building Kademlia implementations, especially once you start dealing with message types that outgrow the "safe" UDP payload size. Let’s break down your options and tradeoffs clearly:

Why Kademlia Specifies UDP #

First, it’s worth remembering why the original Kademlia paper leaned into UDP:

• Low latency for frequent interactions: Kademlia’s core operations (like PING, FIND_NODE) are lightweight and happen constantly as nodes maintain their routing tables. UDP avoids TCP’s three-way handshake overhead, making these fast and efficient.
• Loose, stateless node interactions: Kademlia relies on communicating with hundreds of nodes over time. UDP’s connectionless model means you don’t have to maintain persistent connections, which saves system resources and fits the decentralized, dynamic nature of P2P networks.
• Original design constraints: The spec was written with small, compact messages in mind—early use cases (like BitTorrent’s DHT) didn’t require large payloads for core routing.

Handling UDP Payloads Larger Than 548 Bytes #

Your concern about FIND_NODE responses exceeding 548 bytes is valid, but this doesn’t mean you need to jump to TCP. Here are proven solutions used in production Kademlia implementations:

• Implement message fragmentation: Split large messages into smaller UDP packets, adding a simple header with fragment IDs, total fragments, and a message ID to reassemble them on the receiving end. Most mature Kademlia libraries use this approach seamlessly.
• Optimize message encoding: Ditch verbose formats (like JSON) for compact binary encodings (Protobuf, MessagePack, or even custom binary schemas). This can cut payload sizes dramatically—for example, a list of node entries in Protobuf is often 50-70% smaller than the same data in JSON.
• Path MTU Discovery (PMTU): While 548 bytes is the minimal safe payload size (IPv6’s minimum MTU minus headers), most modern networks support larger MTUs (1500 bytes for Ethernet). Implement PMTU to detect the maximum payload size your network can handle without fragmentation, and fall back to smaller sizes or fragmentation if needed.

The Downsides of Switching to TCP #

If you fully replace UDP with TCP for core Kademlia operations, you’ll hit significant drawbacks:

• Increased latency for core routing: Every PING or FIND_NODE request requires a TCP handshake, which adds hundreds of milliseconds of latency—this slows down routing table maintenance and overall network responsiveness.
• Connection state bloat: Maintaining persistent TCP connections with hundreds of nodes will eat up file descriptors and memory, especially on resource-constrained devices.
• Poor handling of dynamic nodes: P2P networks have nodes going online/offline constantly. TCP connections can hang or require re-establishment, whereas UDP’s stateless model handles node churn much more gracefully.
• Compatibility issues: Almost all existing Kademlia-based systems (BitTorrent DHT, IPFS DHT) use UDP. Switching to TCP would make your implementation incompatible with the broader Kademlia ecosystem.

When to Consider TCP (Hint: Not for Core Routing) #

If your system needs to transfer large payloads (like file blocks, not just routing metadata), a hybrid approach is better:

• Use UDP for all core Kademlia operations (PING, FIND_NODE, STORE/RETRIEVE for metadata).
• Negotiate a TCP connection for large data transfers once the DHT has located the target node. This is how many modern P2P systems balance efficient routing with reliable large-data delivery.

Final Recommendation #

Don’t replace UDP with TCP for your Kademlia core. Instead, implement fragmentation, compact encoding, and PMTU handling to address large payloads. If you need to transfer big files or blobs, add a TCP layer for those specific operations while keeping UDP for the DHT routing logic.

内容的提问来源于stack exchange，提问作者bw_dev