BitTorrent 자석 링크는 어떻게 작동합니까?

처음으로 자석 링크를 사용했습니다 . 그것이 어떻게 작동하는지 궁금해서, 나는 사양을 찾아 보았고 아무런 대답도 찾지 못했습니다. 위키는 xt"정확한 주제"를 의미 btih하며 SHA1 해시 형식 ( 이 경우)이 뒤 따릅니다 . 나는 base32가 문자 당 5 비트와 32 문자임을 알고 언급했으며 정확히 160 비트를 보유하고 있음을 발견했습니다. 이는 정확히 SHA1의 크기입니다.

IP 주소 또는 기타 공간이 없으며 단지 SHA1입니다. 그렇다면 BitTorrent 클라이언트는 실제 파일을 어떻게 찾습니까? URL Snooper를 켜서 TCP를 사용하여 페이지를 방문하거나 조회 등을 수행하는지 확인했지만 아무 일도 일어나지 않았습니다. 클라이언트가 동료를 찾는 방법을 모르겠습니다. 어떻게 작동합니까?

또한 해시는 무엇입니까? 모든 파일 해시의 배열 해시입니까? 어쩌면 실제 토런트 파일의 해시 일 수도 있습니다 (특정 정보를 tri)?

VM에서 uTorrent (새로 설치)와 자석 링크를 시도하고 피어를 찾을 수있었습니다. 첫 번째 동료는 어디에서 왔습니까? 신선했고 다른 급류는 없었습니다.

비트 토런트 자석 링크 식별하여 격류 ¹ 은 "infohash"라고하는 SHA-1, SHA-256 절단 해시 값. 이는 트래커 또는 다른 피어와 통신 할 때 피어 (클라이언트)가 토렌트를 식별하는 데 사용하는 것과 동일한 값입니다. 기존의 .torrent 파일에는 두 개의 최상위 키가있는 데이터 구조가 포함되어 있습니다. announce, 다운로드에 사용할 추적기 식별 info및 토렌트의 파일 이름 및 해시. "infohash"는 인코딩 된 info데이터 의 해시입니다 .

일부 자석 링크에는 트래커 또는 웹 시드가 포함되지만 종종 그렇지 않습니다. 고객은 정보 해시를 제외하고 토런트에 대해 아무것도 모를 수 있습니다. 가장 먼저 필요한 것은 토런트를 다운로드하는 다른 동료를 찾는 것입니다. "분산 해시 테이블"(DHT)을 운영 하는 별도의 피어 투 피어 네트워크 ² 를 사용하여이를 수행합니다 . DHT는 급류 (infohashes로 식별)를 해당 급류 (데이터 또는 메타 데이터 업로드 / 다운로드)에 참여하는 피어 (IP 주소 및 포트로 식별) 목록에 매핑하는 큰 분산 인덱스입니다.

클라이언트가 DHT 네트워크에 처음 가입하면 infohash와 동일한 공간에서 임의의 160 비트 ID를 생성합니다. 그런 다음 클라이언트 개발자가 제어하는 ​​클라이언트의 하드 코딩 된 주소 또는 토런트 떼에서 이전에 발견 된 DHT 지원 클라이언트를 사용하여 DHT 네트워크에 대한 연결을 부트 스트랩합니다. 주어진 토런트에 대한 떼에 참여하고 싶을 때, ID가 infohash에 가능한 한 ^3에 가까운 다른 여러 클라이언트를 DHT 네트워크에서 검색합니다 . 이 클라이언트는 웜에 참여하고 싶다고 알리고, 웜에 참여하고있는 사람을 이미 알고있는 동료의 연결 정보를 요청합니다.

동료가 특정 토렌트를 업로드 / 다운로드 할 때, 동일한 토런트 떼에 참여하고있는 다른 모든 동료에 대해 서로 이야기하려고합니다. 이렇게하면 추적 기나 DHT를 지속적으로 요청하지 않고도 피어가 서로를 빠르게 알 수 있습니다. DHT에서 몇 명의 동료에 대해 알게되면 클라이언트는 필요한 모든 동료를 확보 할 때까지 토런트 떼에서 더 많은 동료의 연결 정보를 해당 동료에게 요청할 수 있습니다.

마지막으로 info파일 이름과 해시 목록이 포함 된 토런트의 메타 데이터 를이 피어에게 요청할 수 있습니다 . 이 정보를 다운로드하고 알려진을 사용하여 올바른지 확인한 후에는 infohash일반 .torrent파일로 시작 하여 포함 된 추적기에서 피어 목록을 얻은 클라이언트와 거의 같은 위치 에 있습니다.

다운로드가 시작될 수 있습니다.

_{¹ infohash는 일반적으로 16 진으로 인코딩되지만 일부 오래된 클라이언트는 대신 32를 사용했습니다. v1 ( urn:btih:)은 SHA-1 다이제스트를 직접 사용하는 반면 v2 ( urn:bimh:)는 멀티 해시 접두사를 추가 하여 해시 알고리즘과 다이제스트 길이를 식별합니다.
² "기본"DHT와 Azureus에서 사용하는보다 복잡한 프로토콜의 두 가지 주요 DHT 네트워크가 있습니다.
³ 거리는 XOR로 측정됩니다.}

추가 자료

• BEP-3 : 비트 토런트 프로토콜 사양
• BEP-52 : BitTorrent 프로토콜 사양 v2
• BEP-5 : DHT 프로토콜
• BEP-9 : 피어가 메타 데이터 파일을 보내도록 확장
• BEP-10 : 확장 프로토콜
• BEP-11 : 피어 교환 (PEX)
• Azureus DHT 설명

피어 검색과 리소스 검색 (귀하의 파일)은 서로 다른 두 가지입니다.

JXTA에 익숙하지만 모든 P2P 네트워크는 동일한 기본 원칙에 따라 작동합니다.

가장 먼저 일어날 일은 피어 발견입니다.

피어 디스커버리

대부분의 p2p 네트워크는 "시드 된"네트워크입니다. 처음 시작할 때 피어는 잘 알려진 (하드 코딩 된) 주소에 연결하여 실행중인 피어 목록을 검색합니다. dht.transmissionbt.com피어가 다른 피어 네트워크 주소의 일반 텍스트 목록 만 제공하는 주소에 연결하는 JXTA에서 일반적으로 수행되는 다른 게시물 또는 간접 시드에 언급 된 것과 같은 직접 시드가 될 수 있습니다 .

첫 번째 (몇 개) 피어와 연결이 설정되면 연결 피어는 다른 피어를 검색하고 (요청을 보내어) 테이블을 유지 관리합니다. 다른 피어의 수가 많을 수 있으므로 연결 피어는 피어의 분산 해시 테이블 (DHT)의 일부만 유지합니다. 연결 피어가 유지해야하는 테이블 부분을 결정하는 알고리즘은 네트워크에 따라 다릅니다. BitTorrent는 Kademlia를 160 비트 식별자 / 키와 함께 사용합니다.

자원 발견

연결 피어가 몇 명의 피어를 발견하면 후자가 피어의 리소스 검색 요청을 보냅니다. 마그넷 링크는 이러한 리소스를 식별하고 리소스의 "서명"인 방식으로 구축되어 모든 피어 중에서 요청 된 콘텐츠를 고유하게 식별합니다. 연결 피어는 자석 링크 / 리소스에 대한 발견 요청을 주변의 피어에게 보냅니다. DHT는 리소스를 먼저 요청해야하는 피어를 결정하는 데 도움이되는 방식으로 구축됩니다 (자세한 내용은 Wikipedia의 Kademlia를 참조하십시오). 요청 된 피어가 요청 된 리소스를 보유하지 않으면 일반적으로 자체 DHT에서 가져온 추가 피어로 쿼리를 "전달"합니다.

쿼리를 전달할 수있는 "홉"수는 일반적으로 제한됩니다. 4는 JXTA 유형 네트워크에서 일반적인 숫자입니다.

피어가 리소스를 보유하면 전체 세부 정보로 응답합니다. 그런 다음 연결 피어는 리소스를 보유한 피어에 직접 또는 릴레이를 통해 연결하고 여기에서 자세히 설명하지 않습니다.

P2P 네트워크의 리소스 / 서비스는 네트워크 주소에 직접 연결 되지 않습니다 . 분산되어 있으며 이는 확장 성이 뛰어난 네트워크의 아름다움입니다.

나는 같은 질문에 스스로 궁금했다. 전송 코드를 읽으면서 다음을 발견했습니다 libtrnasmission/tr-dht.c.

3248:     bootstrap_from_name( "dht.transmissionbt.com", 6881,
                               bootstrap_af(session) );

6 번 시도하고 40 초 동안 기다립니다. 구성 파일을 삭제하고 ( ~/.config/transmissionUNIX에서) 모든 통신을 차단하고 dht.transmissionbt.com어떤 일이 일어나는지 확인하십시오 (최소 240 초 이상 기다리십시오).

따라서 클라이언트에 부트 스트랩 노드가 내장 된 것으로 보입니다. 물론 일단 네트워크에 들어가면 더 이상 부트 스트랩 노드가 필요하지 않습니다.

마침내 사양을 찾았습니다. 처음으로 구글은 도움이되지 않았다 . (위키는 기본 사이트 인 bittorrent.com에 링크되어 있습니다. 개발자 링크를 클릭 한 후 오른쪽의 bittorrent.org 탭을 확인하면 쉽게 찾을 수 있습니다. 클릭 수).

모든 급류에는 동료 네트워크가있는 것처럼 보입니다. 트래커에서 동료를 찾아 세션간에 유지합니다. 네트워크를 통해 동료 및 기타 정보를 찾을 수 있습니다. 자석 링크 와 함께 사용되는 방법을 읽지 못했지만 새로운 클라이언트가 동료를 찾는 방법이 정의되지 않은 것 같습니다. 아마도 일부는 구워 지거나 클라이언트에 내장 된 홈 서버 또는 알려진 추적기를 사용하여 네트워크의 첫 번째 피어를 얻습니다.

내가 당신의 질문에 대답하기 시작했을 때, 나는 당신이 자석 방식이 어떻게 작동하는지 묻고 있다는 것을 몰랐습니다. 비트 토렌트 프로토콜과 관련된 부분이 어떻게 생성되는지 알고 싶다고 생각했습니다.

자석 URI에 나열된 해시는 base32로 인코딩 된 토렌트의 정보 해시입니다. 정보 해시는 토렌트의 벤 코딩 된 정보 블록의 sha1 해시입니다.

이 파이썬 코드 는 계산 방법을 보여줍니다.

나는 벤코 더를 가지고 있지 않았기 때문에 이것을 테스트하기 위해 (매우 순진한) C # 구현을 작성했으며 클라이언트에서 예상되는 것과 일치합니다.

static string CalculateInfoHash(string path)
{
    // assumes info block is last entry in dictionary
    var infokey = "e4:info";
    var offset = File.ReadAllText(path).IndexOf(infokey) + infokey.Length;
    byte[] fileHash = File.ReadAllBytes(path).Skip(offset).ToArray();
    byte[] bytes;
    using (SHA1 sha1 = SHA1.Create())
        bytes = sha1.ComputeHash(fileHash, 0, fileHash.Length - 1); // need to remove last 'e' to compensate for bencoding
    return String.Join("", bytes.Select(b => b.ToString("X2")));
}

내가 이해 했듯이이 해시는 추적기를 찾는 방법에 대한 정보가 포함되어 있지 않으므로 클라이언트는 다른 방법 (제공 된 URL 발표)을 통해이를 찾아야합니다. 이것은 추적기에서 한 급류와 다른 급류를 구별하는 것입니다.

비트 토렌트 프로토콜과 관련된 모든 것은 여전히 트래커를 중심으로 진행됩니다. 그것은 여전히 ​​떼 사이의 주요 의사 소통 수단입니다. 자석 URI 방식은 비트 토렌트 용으로 특별히 설계되지 않았습니다. 모든 P2P 프로토콜에서 대체 통신 형식으로 사용됩니다. Bittorrent 클라이언트는 더 이상 .torrent 파일을 다운로드 할 필요가없는 토런트를 식별하는 또 다른 방법으로 자석 링크를 허용하도록 조정되었습니다. 자석은 여전히 tr클라이언트가 참여할 수 있도록 위치를 찾기 위해 애커 를 지정해야합니다 . 다른 프로토콜에 대한 정보를 포함 할 수 있지만 비트 토렌트 프로토콜과는 관련이 없습니다. 비트 토렌트 프로토콜은 궁극적으로 트래커 없이는 작동하지 않습니다.

동료 목록은 아마도 클라이언트를 업그레이드하는 토렌트에서 채워질 것입니다 (예 : 클라이언트를 업그레이드하는 토렌트가 있습니다). 모두가 동일한 클라이언트를 사용하는 한 업그레이드를 공유 할 수밖에 없기 때문에 좋습니다.