BT9G LABS / DHT 심층 분석 #11

BEP 10 Extension Protocol: 호환성을 깨지 않고 BitTorrent 기능을 확장하는 방법

extended handshake, 동적 message ID, ut_metadata와 PEX의 기반이 되는 BEP 10을 설명합니다.

BT9G Labs게시일 2026-09-163 분 읽기

BT9G Labs / DHT Deep Dive #11. 각 Peer connection에서 확장 기능을 동적으로 협상해 오래된 클라이언트와의 호환성을 유지하는 방식을 이해합니다.

BEP 10 Extension Protocol: 호환성을 깨지 않고 BitTorrent 기능을 확장하는 방법

빠른 요약

주제: BEP 10 Extension Protocol: 호환성을 깨지 않고 BitTorrent 기능을 확장하는 방법
핵심 키워드: BEP 10, Extension Protocol, extended handshake, ut_metadata, BitTorrent
대상 독자: 백엔드 엔지니어, 프로토콜 연구자, 검색 엔지니어, BitTorrent 구현자
목표: DHT와 BitTorrent의 동작 원리를 실제 크롤러, 인덱싱, 검색 아키텍처 설계에 활용할 수 있을 정도로 정확하게 설명합니다.

시스템 뷰

Peer HandshakeExtension BitExtended HandshakeName -> Message IDExtensions

Peer Handshake → Extension Bit; Extension Bit → Extended Handshake; Extended Handshake → Name -> Message ID; Name -> Message ID → Extensions

호환성 문제를 해결하는 확장 계층

오래 살아남는 P2P protocol은 새로운 기능을 추가하면서 구형 client도 깨뜨리지 않아야 합니다. BEP 10은 기본 handshake의 reserved bits로 extension protocol 지원을 표시하고, 이후 extended handshake에서 구체적인 capability를 교환합니다.

이 덕분에 기본 Peer Wire Protocol을 크게 바꾸지 않고 새로운 extension을 추가할 수 있습니다.

Extended handshake와 동적 ID

m dictionary는 extension name과 현재 connection에서 사용할 message ID의 매핑을 전달합니다. client version, listening port, metadata_size 같은 정보가 함께 올 수도 있습니다.

중요한 점은 message ID가 connection-local이라는 것입니다. 모든 Peer에서 ut_metadata가 같은 숫자라고 가정해서는 안 됩니다.

인덱서에 중요한 이유

Magnet 기반 인덱서는 보통 BEP 9에 의존하고, BEP 9의 ut_metadata 지원 여부는 BEP 10에서 알게 됩니다. TCP/uTP connection, basic handshake, extension support, ut_metadata support, Metadata complete를 따로 측정하면 실제 conversion 손실 구간을 찾을 수 있습니다.

unsupported extension과 network failure를 같은 에러로 처리하지 않는 것도 중요합니다.

구현 스케치

Base handshake
  reserved bit says: extension protocol supported
        |
        v
Extended handshake
  m = { "ut_metadata": 3, "ut_pex": 1 }
  metadata_size = 48321
        |
        v
Extended message 3 now means ut_metadata for this connection

BT9G Labs 엔지니어링 노트

BT9G 같은 인덱싱 시스템에서는 이벤트 수 자체보다 콘텐츠 식별자, 수명이 짧은 네트워크 관측값, 수집 상태, 검색용 문서를 분리하는 것이 중요합니다. DHT나 Peer에서 얻은 필드에는 출처와 타임스탬프를 남기고, discovery, 연결, handshake, 확장 지원, Metadata 수집, 검증, 저장, 검색 반영을 단계별로 측정해야 실제 병목을 찾을 수 있습니다.

흔한 오해

모든 Peer가 BEP 10을 지원한다고 가정하는 것.
extension message ID를 전역 고정값으로 쓰는 것.
extended handshake 전에 ut_metadata를 보내는 것.
unsupported와 network failure를 같은 에러로 합치는 것.

참고 자료

다음 글: Tracker vs DHT vs PEX: BitTorrent Peer Discovery 3가지 방식 비교 →

이 글은 공개 BitTorrent 프로토콜의 동작을 엔지니어링 및 연구 목적으로 설명하며, 관측된 모든 Swarm이 사용 가능하거나 유효하거나 재배포 허가를 받았음을 의미하지 않습니다.