我正在实现多个哈希值的 HTTP 抓取。 尽管我知道抓取工具并未被客户广泛使用（我唯一知道的是传输，如果您了解更多，请告诉我），但是抓取工具处理和响应的信息哈希的合理限制可能是多少？
对于 UDP 跟踪器，一次为 74 个。
目前我的想法是10。
在访问数据库更新统计数据之前，抓取响应的最佳缓存 ttl 应该是多少？
在抓取时，我们是否必须在编码文件数组或截断的文件数组中提供完整的 v2 信息哈希值？
附注 另外，记录对等方的侦听端口而不是在 &port GET 参数中发送的端口以帮助 NAT 后面的某些对等方是个好主意吗？
刮刀处理和响应的信息哈希的合理限制是多少？
接受和处理 TCP/HTTP 连接已经消耗了一些资源。因此，支持信息哈希是合理的，只要它只增加边际成本。 具体多少取决于您的跟踪器实施。如果您将所有数据保存在高效的内存数据结构中（因为对等列表大多是短暂的）并且不需要查询外部数据库，那么应该可以在微秒内查找到该数据。
对您的跟踪器进行基准测试，并找到与连接成本相比，每个 infohash 的额外成本仍然很小的点。
在访问数据库更新统计数据之前，抓取响应的最佳缓存 ttl 应该是多少？
正如我上面所写，你真的不应该使用数据库。但如果您无论如何都这样做，那么您可能希望根据群体行为动态调整 TTL。一个新的 torrent 可能会比已经存在几天的 torrent 更有活力。
在抓取时，我们是否必须在编码文件数组或截断的文件数组中提供完整的 v2 信息哈希值？
跟踪器应该忽略 v1 和 v2 的区别，因为它们只看到来自客户端的哈希值，这意味着截断的哈希值应该用于 v2。
虽然我知道抓取并没有被客户广泛使用（我唯一知道的是传输，如果你知道更多，请告诉我），
libtorrent 支持抓取，所以我希望基于它的任何客户端也支持它。
附注另外，记录对等方的侦听端口而不是在 &port GET 参数中发送的端口以帮助 NAT 后面的某些对等方是个好主意吗？
这似乎与刮伤完全无关。