这是一个创建于 655 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在搓 Tracker ，不可避免的深入研究了下 BT 的协议，主要是 Tracker 和 .torrent 文件的部分。
首先注意到的就是在 client 向 tracker 宣告过程中使用 URL 编码的二进制 info_hash…为了省下几个字节，能看得出来 BT 拼劲了全力，但省下来的那么几个字节被拓展协议吃了个精光。
除了给解码带来了一箩筐的麻烦，没有丝毫的好处…
回过头看 .torrent 文件，居然还分成了单文件和多文件两个不同的结构，它们大可都塞进 files 字段里面，毕竟单文件和多文件对于程序来说没有什么差别，都是一起处理…
最近我不解的大概是 BitTorrent Protocol Specification v2 ，为了避免 SHA1 的哈希碰撞，换成了更长的 SHA256 ，但往 Tracker 汇报的时候又只截取前 20 个字节，使得 SHA256 带了的优势瞬间被抹除殆尽，又为了想兼容 v1 ，设计了“混合种子”，导致最后不但种子文件变大了，客户端碰到混合种子全都当 v1 的处理了，对于 v2 没有丝毫的推进意义，反而惯坏了 client 和 tracker 的开发者，毕竟有了混合种子的存在，只需要支持 v1 就好了…
这还不包括各个客户端往种子里塞私货的情况，一个客户端一个样，特别点名 BitComet 最离谱，改的给我看的怀疑人生…
就算只讨论 BitTorrent 的官方文档，也是一坨稀烂，相当多难以理解的地方都没有给出示例，说明也含糊其辞模糊不清。
只能查已有实现的代码才能搞清楚究竟是个什么玩意儿。
跑不跑的起来都靠玄学，整个协议从头到尾都在干魔幻二进制。
文件名和路径用 UTF8 ，其他用 ISO-8859-1 ，但还绷不住有些客户端单开一个 file.utf-8 的字段…
整个 BitTorrent 的世界仿佛都是屎山堆起来的
后来的新人只能一边吃一边试…
文档的作用只能告诉你有这么一个玩意儿，大概长这么个样子，至于背后有什么天坑，只有把雷踩炸了才知道。
首先注意到的就是在 client 向 tracker 宣告过程中使用 URL 编码的二进制 info_hash…为了省下几个字节，能看得出来 BT 拼劲了全力，但省下来的那么几个字节被拓展协议吃了个精光。
除了给解码带来了一箩筐的麻烦，没有丝毫的好处…
回过头看 .torrent 文件，居然还分成了单文件和多文件两个不同的结构，它们大可都塞进 files 字段里面，毕竟单文件和多文件对于程序来说没有什么差别，都是一起处理…
最近我不解的大概是 BitTorrent Protocol Specification v2 ，为了避免 SHA1 的哈希碰撞，换成了更长的 SHA256 ，但往 Tracker 汇报的时候又只截取前 20 个字节，使得 SHA256 带了的优势瞬间被抹除殆尽，又为了想兼容 v1 ，设计了“混合种子”，导致最后不但种子文件变大了，客户端碰到混合种子全都当 v1 的处理了，对于 v2 没有丝毫的推进意义，反而惯坏了 client 和 tracker 的开发者，毕竟有了混合种子的存在，只需要支持 v1 就好了…
这还不包括各个客户端往种子里塞私货的情况，一个客户端一个样，特别点名 BitComet 最离谱，改的给我看的怀疑人生…
就算只讨论 BitTorrent 的官方文档，也是一坨稀烂，相当多难以理解的地方都没有给出示例，说明也含糊其辞模糊不清。
只能查已有实现的代码才能搞清楚究竟是个什么玩意儿。
跑不跑的起来都靠玄学，整个协议从头到尾都在干魔幻二进制。
文件名和路径用 UTF8 ，其他用 ISO-8859-1 ，但还绷不住有些客户端单开一个 file.utf-8 的字段…
整个 BitTorrent 的世界仿佛都是屎山堆起来的
后来的新人只能一边吃一边试…
文档的作用只能告诉你有这么一个玩意儿，大概长这么个样子，至于背后有什么天坑，只有把雷踩炸了才知道。
目前尚无回复
Select Language