使用C++撰寫一個DHT爬蟲,實作從DHT網路爬取BT種子
- 1、前言
- 2、相關術語
- 2.1、P2P網路
- 2.2、DHT網路
- 2.3、Kademlia演算法
- 2.4、KRPC協議
- 2.5、MagNet協議
- 3、BT下載的一些概念梳理
- 3.1、BT軟體下載原理
- 3.2、迅雷獲取種子的速度為什么那么快
- 3.3、資源時效性問題
- 3.4、好用的BT軟體
- 3.5、有沒有已經撰寫好的DHT爬蟲
- 4、使用C++撰寫DHT爬蟲
- 4.1、實作原理
- 4.2、實作DHT協議
- 4.2.1、創建UDP服務
- 4.2.2、加入DHT網路
- 4.2.3、報文決議
- 4.2.4、對不同型別報文進行處理、回復
- 4.2.5、隱藏自己,防止被其他節點拉進黑名單
- 4.2.6、獲取info_hash和peer
- 4.3、實作BitTorrent協議
- 4.3.1、HandShake(握手)
- 4.3.2、Extend HandShake(擴展握手)
- 4.3.3、獲取metadata
- 4.3.4、制作torrent檔案
- 4、總結

1、前言
通過前面兩篇文章的科普,相信大家都一定程度上了解了DHT網路和BT種子的相關知識了,不了解也沒關系,可以倒回去看下面兩篇文章:
- B編碼與BT種子檔案分析,以及模仿json-cpp寫一個B編碼決議器
- DHT協議介紹
雖然前面介紹了很多理論相關的知識,但是光有這些理論是沒用的,中看不中用,接下來我們就實戰一下,自己撰寫一個DHT爬蟲,達到種子自由的目的,不對,是達到提高我們編程水平的目的,

2、相關術語
2.1、P2P網路

對等計算(Peer to Peer,簡稱p2p)可以簡單定義成通過直接交換來共享計算機資源和服務,而對等計算模型應用層形成的網路通常稱為對等網路,相信大家都用過迅雷等p2p軟體,這里就不贅述了,
2.2、DHT網路

DHT(Distributed Hash Table,分布式哈希表),DHT由節點組成,它存盤peer的位置,是一種分布式存盤方法,在不需要服務器的情況下,每個客戶端負責一個小范圍的路由,并負責存盤一小部分資料,從而實作整個DHT網路的尋址和存盤,其中BT客戶端包含一個DHT節點,用來聯系DHT中其他節點,從而得到peer的位置,進而通過
BitTorrent協議下載,
簡單點來說DHT就是負責管理提供資訊和服務節點的管理與路由功能,這里有兩個需要區分的概念:
- peer:是在一個 TCP 埠上監聽的客戶端/服務器,它實作了BitTorrent協議
- 節點:是在一個 UDP 埠上監聽的客戶端/服務器,它實作了DHT(分布式哈希表) 協議
2.3、Kademlia演算法
Kademlia是DHT網路的一種實作,在Kademlia網路中,距離是通過異或(XOR)計算的,結果為無符號整數,distance(A, B) = |A xor B|,數值越小表示越近兩個節點越接近,詳細說明可以自行百度查閱,
2.4、KRPC協議
KRPC是節點之間的互動協議,是由B編碼組成的一個簡單的RPC結構,它使用UDP報文發送,一個獨立的請求包發出去,然后由另一個獨立的包來回復(這也是UDP無連接特性所決定的,所以協議中肯定也會有讓我們區分報文包的方法),要注意的是這個協議沒有重發機制,
2.5、MagNet協議
MagNet協議,也就是磁力鏈接,是一個通過sha1演算法生成一個20位元組長的字串,P2P客戶端使用磁力鏈接,下載資源的種子檔案,然后根據種子檔案下載資源,
3、BT下載的一些概念梳理
3.1、BT軟體下載原理
BT軟體使用
DHT協議,通過擊鼓傳花的方式,在DHT網路上搜尋磁力鏈接對應的資源,當找到擁有此資源的peer之后,使用BitTorrent協議先將種子下載下來,然后根據種子檔案內容下載對應的資源,
3.2、迅雷獲取種子的速度為什么那么快
從理論上來講,由于BT軟體要先去DHT網路搜尋種子,這個程序時需要耗費一定時間的,所以要做到大部分資源都迅速回應是不可能的,迅雷那么快的原因只有一個,就是迅雷自己有種子庫,里面快取了其他用戶下載過的種子或者迅雷自己平時在DHT上面爬取的種子,
3.3、資源時效性問題
當DHT網路上持有某一資源的peer全部停止作業后,資源自然也就下不了了,迅雷由于自己有服務器快取了以往一些熱門的資源,所以往往會給人造成資源還在的假象,其實此時是迅雷自己充當服務器給你下發資源而已(這也就是為什么有些資源充了VIP才能下的原因了,畢竟服務器不能讓你白用),
3.4、好用的BT軟體
既然BT的原理都是
DHT協議加上BitTorrent協議,所以不同軟體下載速度啥的應該差別不大(有服務器快取支撐的軟體除外),比較出名的BT軟體有迅雷、uTorrent、qBittorrent、位元彗星、Transmission、aria2等等,大家可以自行去百度去搜索,
3.5、有沒有已經撰寫好的DHT爬蟲
答案當然是有的啦,所有BT軟體肯定都實作了
DHT協議和BitTorrent協議,可以看一些開源的BT軟體里面的實作方法,有個叫做libtorrent的庫非常著名,很多BT軟體都是將其套個殼做出來的,只不過代碼寫的比較復雜,看起來有點難受,于是乎就想看看有沒有人已經用比較簡單的方式實作了DHT爬蟲,而通過查閱了很多文章,發現有些人是只實作了DHT協議,然后拿那些通過DHT網路爬取到的hash去開源種子庫獲取種子,有些就是沒有把BitTorrent協議的實作方法開源出來,所以萌生了自己做一個完整的DHT爬蟲的想法(開源庫無法獲取到最新的資源,而且速度肯定是不如直接在DHT網路爬取的),
4、使用C++撰寫DHT爬蟲
4.1、實作原理
偽裝成DHT節點加入DHT網路中收集資訊,爬蟲主要收集get_peer、announce_peer這兩個請求的資訊,當收到get_peer或者announce_peer的請求時,直接使用BitTorrent協議從請求發起者下載對應的種子資訊(獲取不到種子的概率會比較大,原因大家自行完整看一下DHT協議就明白了)
這里有一個疑問,要如何加入DHT網路,通過查看其他大神們的開源代碼,我發現基本都是ping下面三個節點來加入DHT網路的
| 域名 | 埠 |
|---|---|
| router.utorrent.com | 6881 |
| router.bittorrent.com | 6881 |
| dht.transmissionbt.com | 6881 |
4.2、實作DHT協議
4.2.1、創建UDP服務
創建一個UDP服務,監聽6881埠(DHT默認埠,可以自行修改,理論上啥埠都可以)
4.2.2、加入DHT網路
通過ping上面那幾個節點來將自己加入到DHT網路中,這樣才能獲取到節點的訊息,實作如下:
void DhtSearch::ping_root()
{
std::vector<std::pair<const char*, const char*>> ip_addr =
{
{"router.utorrent.com", "6881"},
{"router.bittorrent.com", "6881"},
{"dht.transmissionbt.com", "6881"}
};
for (auto addr : ip_addr)
{
struct addrinfo hints, *info;
memset(&hints, 0, sizeof(hints));
hints.ai_socktype = SOCK_DGRAM;
hints.ai_family = AF_UNSPEC;
int error = getaddrinfo(addr.first, addr.second, &hints, &info);
if (error)
{
log_error << "getaddrinfo fail, error=" << error << ", errstr=" << gai_strerror(error);
}
else
{
struct addrinfo* p = info;
while (p)
{
if (p->ai_family == AF_INET)
{
send_ping((struct sockaddr_in*)p->ai_addr, "");
log_debug << addr.first << ":" << addr.second << " is AF_INET";
}
else
{
log_debug << addr.first << ":" << addr.second << " is no support the family(" << p->ai_family << ")";
}
p = p->ai_next;
}
freeaddrinfo(info);
}
}
}
4.2.3、報文決議
收到其他節點發過來的報文之后,進行報文決議,DHT網路中互相之間通信的格式是B編碼,不了解B編碼的可以去看這篇文章《B編碼與BT種子檔案分析,以及模仿json-cpp寫一個B編碼決議器》,決議報文的代碼如下:
// private
int DhtSearch::parse(const char* buf, int len, std::string& tid, std::string& id,
std::string& info_hash, unsigned short& port, std::string& nodes)
{
#define XX(str) \
log_error << str; \
return -1
int ret;
BEncode::Value root;
size_t start = 0;
if (BEncode::decode(buf, start, len, &root) || root.getType() != BEncode::Value::BCODE_DICTIONARY)
{
XX("bencode message is invalid");
}
// tid(始終在頂層)
{
auto value = root.find("t");
if (value != root.end())
{
if (value->getType() != BEncode::Value::BCODE_STRING)
{
XX("\"t\" value is must be string");
}
tid = value->asString();
}
}
// y(始終在頂層)
auto type_y = root.find("y");
if (type_y != root.end() && type_y->getType() == BEncode::Value::BCODE_STRING)
{
std::string value = type_y->asString();
if (value == "r")
ret = REPLY;
else if (value == "e")
{
XX("remote reply ERROR value");
}
else if (value == "q")
{
auto type_q = root.find("q");
if (type_q != root.end() && type_q->getType() == BEncode::Value::BCODE_STRING)
{
std::string v = type_q->asString();
if (v == "ping")
ret = PING;
else if (v == "find_node")
ret = FIND_NODE;
else if (v == "get_peers")
ret = GET_PEERS;
else if (v == "announce_peer")
ret = ANNOUNCE_PEER;
else if (v == "vote" || v == "sample_infohashes")
return -1;
else
{
XX("\"q\" value(" + v + ") is invaild");
}
}
else
{
XX("not found \"q\" value");
}
}
else
{
XX("\"y\" value(" + value + ") is invaild");
}
}
else
{
XX("not found \"y\" value");
}
BEncode::Value::iterator body_value;
if (ret == REPLY)
{
body_value = root.find("r");
if (body_value == root.end() || body_value->getType() != BEncode::Value::BCODE_DICTIONARY)
{
XX("not found \"r\" value");
}
}
else
{
body_value = root.find("a");
if (body_value == root.end() || body_value->getType() != BEncode::Value::BCODE_DICTIONARY)
{
XX("not found \"a\" value");
}
}
// id
{
auto value = body_value->find("id");
if (value != body_value->end())
{
if (value->getType() != BEncode::Value::BCODE_STRING)
{
XX("\"id\" value is must be string");
}
id = value->asString();
if (id.size() != 20)
id.clear();
}
else
id.clear();
}
// info_hash
{
auto value = body_value->find("info_hash");
if (value != body_value->end())
{
if (value->getType() != BEncode::Value::BCODE_STRING)
{
XX("\"info_hash\" value is must be string");
}
info_hash = value->asString();
if (info_hash.size() != 20)
info_hash.clear();
}
else
info_hash.clear();
}
// port
{
auto value = body_value->find("port");
if (value != body_value->end())
{
if (value->getType() != BEncode::Value::BCODE_INTEGER)
{
XX("\"port\" value is must be int");
}
port = (unsigned short)(value->asInt());
}
else
port = 0;
}
// nodes
{
auto value = body_value->find("nodes");
if (value != body_value->end())
{
if (value->getType() != BEncode::Value::BCODE_STRING)
{
XX("\"nodes\" value is must be string");
}
nodes = value->asString();
}
else
nodes.clear();
}
return ret;
#undef XX
}
4.2.4、對不同型別報文進行處理、回復
決議完成后,如果報文有效,則進行后續處理,由于我們的需求只是爬取其他人的種子,自己不進行主動查詢,所以并不需要完整實作DHT協議,即不快取其他節點資訊,別人的請求有用的就接受,沒用的回傳一些假的資訊給請求節點,通過這種騙、偷襲的方法可以使得撰寫出的爬蟲的復雜度大大降低,接下來分析各個請求的回應方法(不知道DHT協議的請看這篇文章《DHT協議介紹》,請務必看完,不然接下來的內容很有可能無法看懂)
| 請求型別 | 回復方法 |
|---|---|
| PING | 直接按標準格式回復PONG就行 |
| FIND_NODE | 由于我們并沒有快取其他節點資訊,來我們這里查找節點是不可能做到的,所以回傳一個空的節點串列給它 |
| GET_PEERS | 這個對于我們是有用的,我們要通過GET_PEERS請求的發起者來下載種子檔案,但是由于我們既沒有快取節點,也沒有快取peer,所以回復它一個空串列 |
| ANNOUNCE_PEER | 和GET_PEERS處理方式一樣 |
| REPLY | 由于我們始終沒有在主動查詢任何資源,所以基本不太可能受到回復,收到的話檢測報文中有沒有nodes,有的話把里面的節點拿出來ping一遍,加入到更多的網路之中 |
4.2.5、隱藏自己,防止被其他節點拉進黑名單
由于整個程序中欺騙其他節點的成分很大,所以每次回復別人錯誤資訊的時候最好修改一下自己的node id,防止被其他節點加入黑名單
4.2.6、獲取info_hash和peer
通過獲取GET_PEERS或者ANNOUNCE_PEER訊息中的info_hash還有對端地址就可以開始使用BitTorrent協議來下載種子資訊了(此時將對端節點視為peer,下載失敗的概率會挺大,畢竟對端節點也有可能只是在找種子而已,而不是持有種子在下載資源)
4.3、實作BitTorrent協議
要想實作BitTorrent協議,就得先仔細看完下面兩篇官方檔案
http://www.bittorrent.org/beps/bep_0009.html
http://www.bittorrent.org/beps/bep_0010.html
里面的介紹非常簡短,建議全部看完
4.3.1、HandShake(握手)
從bep_0010中可以看到,握手的報文訊息格式為:19的ASCII碼 + BitTorrent protocol + \x00\x00\x00\x00\x00\x10\x00\x04 + infohash的十六進制解碼 + 二十位元組長的nodeid,infohash是種子的hash,nodeid就是我們自己的id了,需要注意的是BitTorrent協議除了握手訊息之外的其他所有的訊息的開頭四個位元組是訊息長度(不包含長度域),對端收到訊息之后,會給你回傳一個至少68位元組的回復資訊(為什么是至少,下面擴展握手那里會講),至于如何判斷對端是接受了我們的握手呢,判斷回傳資訊的第25位和27位即可(這個是看其他開源代碼這樣寫的,具體原因沒去深究,通過測驗之后證明確實是這樣)
// 握手
std::string handshake_message;
handshake_message.resize(28);
handshake_message[0] = 19;
memcpy(&handshake_message[1], "BitTorrent protocol", 19);
char ext[8];
memset(ext, 0x00, sizeof(ext));
ext[5] = 0x10;
ext[7] = 0x04;
memcpy(&handshake_message[20], ext, 8);
handshake_message += m_info_hash + m_node_id;
m_sock->send(&handshake_message[0], handshake_message.size());
int len = m_sock->recv(buf, BUF_LEN);
if (len < 68)
{
log_debug << COMMON_PART << "(handshake) message size=" << len
<< " is too short(must be >= 68)";
delete buf;
return false;
}
std::string handshake_reply(buf, 68);
std::string ext_message;
if (len > 68)
ext_message = std::string(buf + 68, len - 68);
if (handshake_reply.substr(0, 20) != handshake_message.substr(0, 20))
{
log_debug << COMMON_PART << "(handshake) protocol fail, message:"
<< std::endl << dump(handshake_reply);
delete buf;
return false;
}
if ((int)handshake_reply[25] & 0x10 == 0)
{
log_debug << COMMON_PART << "(handshake) peer does not support extension protocol, message:"
<< std::endl << dump(handshake_reply);
delete buf;
return false;
}
if ((int)handshake_reply[27] & 0x04 == 0)
{
log_debug << COMMON_PART << "(handshake) peer does not support fast protocol, message:"
<< std::endl << dump(handshake_reply);
delete buf;
return false;
}
下面是請求報文示例

下面是回應報文示例,大家可以自己算一下,從第四行第7個位元組0x13開始算起到報文結尾,長度確實是超過了68

4.3.2、Extend HandShake(擴展握手)
從bep_0010中可以看到,握手之后就要進行擴展握手了,而擴展握手是至關重要的,報文訊息格式為:訊息長度 + MSG_ID的ASCII + EXTEND_ID的ASCII + B編碼的字典{‘m’:{‘ut_metadata’:1}}
其中MSG_ID為20,由于是擴展握手,EXTEND_ID是0,完成之后,peer的回應報文里面會包含了兩個我們下一步用得到的鍵值:ut_metadata、和metadata_size,這兩個非常重要,拿到之后要找個變數存起來
注意事項:協議中本來是要求握手協議和擴展握手是分開兩步進行的,但是在實際測驗中發現了很多peer會直接在第一次握手時就把全部資料發過來了,也就是把原本屬于擴展握手的訊息的應答也一并發過來,而且還有幾率發不全,剛開始在寫代碼的時候,由于不知道這點,導致一直擴展握手失敗,差點懷疑智商和碼生,到后來通過抓包才了解到這個東西,所以在最終實作時必須這樣做,就是第一次握手之后,如果資料量大于68個位元組,把多余的內容保存下來,然后進行擴展握手,擴展握手后,把握手剩余的內容和擴展握手的內容一加,就得到正確的擴展握手資料了
代碼實作如下:
// 擴展握手
std::string ext_handshake_message;
ext_handshake_message.append(1, 20);
ext_handshake_message.append(1, 0);
ext_handshake_message += "d1:md11:ut_metadatai2ee1:v" + std::to_string(m_v.size()) + ":" + m_v + "e";
std::string ext_handshake_message_size_str;
ext_handshake_message_size_str.resize(4);
uint32_t ext_handshake_message_size = ext_handshake_message.size();
ext_handshake_message_size = littleByteSwap(ext_handshake_message_size);
memcpy(&ext_handshake_message_size_str[0], &ext_handshake_message_size, 4);
ext_handshake_message = ext_handshake_message_size_str + ext_handshake_message;
m_sock->send(&ext_handshake_message[0], ext_handshake_message.size());
len = 0;
while (1)
{
int cur_len = m_sock->recv(buf + len, BUF_LEN - len);
if (cur_len <= 0)
break;
len += cur_len;
if (len >= BUF_LEN)
break;
}
std::string ext_reply;
if (len > 0)
ext_reply = ext_message + std::string(buf, len);
else if (!ext_message.empty())
ext_reply = ext_message;
else
{
log_debug << COMMON_PART << "(ext handshake) fail";
delete buf;
return false;
}
// 摘取資料
// ut_metadata
size_t pos = ext_reply.find("ut_metadata");
if (pos == std::string::npos)
{
log_debug << COMMON_PART << "(ext handshake) parse ut_metadata fail, message:"
<< std::endl << dump(ext_reply);
delete buf;
return false;
}
pos += 12;
size_t pos_e = ext_reply.find("e", pos);
if (pos_e == std::string::npos)
{
log_debug << COMMON_PART << "(ext handshake) parse ut_metadata fail, message:"
<< std::endl << dump(ext_reply);
delete buf;
return false;
}
std::string ut_metadata_str = ext_reply.substr(pos, pos_e - pos);
uint32_t ut_metadata = atoi(ut_metadata_str.c_str());
// metadata_size
pos = ext_reply.find("metadata_size");
if (pos == std::string::npos)
{
log_debug << COMMON_PART << "(ext handshake) parse metadata_size fail, message:"
<< std::endl << dump(ext_reply);
delete buf;
return false;
}
pos += 14;
pos_e = ext_reply.find("e", pos);
if (pos_e == std::string::npos)
{
log_debug << COMMON_PART << "(ext handshake) parse metadata_size fail, message:"
<< std::endl << dump(ext_reply);
delete buf;
return false;
}
std::string metadata_size_str = ext_reply.substr(pos, pos_e - pos);
int64_t metadata_size = atoll(metadata_size_str.c_str());
下面是請求報文示例

下面是正常回應報文示例

下面是需要用拼接的回應報文示例(和握手剩余內容拼接),可以很想看出報文沒有以字母d開頭(B編碼表示的報文都需要d開頭表示整體是一個物件)

4.3.3、獲取metadata
我們在握手完畢,收到ut_metadata、metadata_size后就能進行下載了,為什么需要這兩個值,因為請求的格式為:訊息長度 + MSG_ID的ASCII + ut_metadata的ASCII + B編碼的字典{‘msg_type’:0,‘piece’:piece}
這里MSG_ID為20,ut_metadata必須為2,不然peer不會給你回復的,piece值為分片標記,協議中說,一個piece分片的長度為 16KB=16*1024B,所以我們需要拿metadata_size和16*1024除法計算分片標記,代碼如下
std::string data;
int piece = 0;
while (metadata_size > 0)
{
std::string get_metadata_message;
get_metadata_message.append(1, 20);
get_metadata_message.append(1, 2);
get_metadata_message += "d8:msg_typei0e5:piecei" + std::to_string(piece) + "ee";
std::string get_metadata_message_size_str;
get_metadata_message_size_str.resize(4);
uint32_t get_metadata_message_size = get_metadata_message.size();
get_metadata_message_size = littleByteSwap(get_metadata_message_size);
memcpy(&get_metadata_message_size_str[0], &get_metadata_message_size, 4);
get_metadata_message = get_metadata_message_size_str + get_metadata_message;
m_sock->send(&get_metadata_message[0], get_metadata_message.size());
len = 0;
while (1)
{
int cur_len = m_sock->recv(buf + len, BUF_LEN - len);
if (cur_len <= 0)
break;
len += cur_len;
if (len >= BUF_LEN)
break;
}
if (len <= 0)
break;
int i = 6;
while (i < len - 1)
{
if (buf[i] == 'e' && buf[i + 1] == 'e')
{
i += 2;
break;
}
i++;
}
if (i < len)
{
data.append(buf + i, len - i);
metadata_size -= (len - i);
piece++;
}
else
{
log_debug << COMMON_PART << "get metadata message is invaild, message:"
<< std::endl << dump(std::string(buf, len));
if (data.empty())
{
delete buf;
return false;
}
else
{
data.append(buf, len);
break;
}
}
}
delete buf;
下面是請求報文示例

下面是回應報文示例,可以看到第一行第7個位元組開始到第四行第3個位元組結束,這段是報文訊息的元資料,要把他剔除,因為他不屬于種子資訊,這點和bep_0009描述的一致

4.3.4、制作torrent檔案
將metadata資訊寫入檔案中就形成種子檔案了,要注意的是在前面回圈獲取metadata時,每一次都要把元資料資訊給剔除了,因為元資料是訊息的一部分,而不是種子檔案的一部分
4、總結
本文介紹了DHT和BitTorrent的相關知識,并且實作了一個C++版本的DHT爬蟲,源代碼已經上傳到github了,大家覺得有用的話麻煩給專案點一下star,覺得本文有用的話可以點贊收藏關注我一下,謝謝
原始碼github地址:https://github.com/bifang-fyh/gude
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/287776.html
標籤:其他
下一篇:被鵝廠面怕了!
