HTTP多哈希刮削的数量限制、缓存TTL等技术问题咨询

支持HTTP刮削的客户端 #

除了你提到的Transmission，还有这些主流客户端支持HTTP刮削：

• qBittorrent
• Deluge
• rTorrent
• Tixati
• Vuze（Azureus）

单次处理info-hashes的合理数量限制 #

UDP tracker限制74个是因为UDP数据包大小的硬性约束，HTTP没有这个限制，但要平衡服务器负载和请求效率：

• 你初步设为10是完全合理的，属于保守且安全的数值，能有效降低单请求的处理压力。
• 如果服务器性能充足，可以把上限调整到20-30个——这也是不少公共HTTP tracker的常用设置，兼顾请求批量性和服务器稳定性。
• 无论设多少，都要加上参数校验逻辑，当请求的哈希数量超过上限时，返回明确的错误提示（比如bencode格式的错误响应）。

刮削响应的最优缓存TTL #

缓存TTL的核心是平衡数据新鲜度和数据库查询压力，建议分场景调整：

• 热门资源（种子活跃peer数多）：TTL设1-5分钟，保证统计数据不会滞后太多。
• 小众/冷门资源：TTL设10-15分钟，这类资源的统计数据变化慢，更长的缓存能大幅减少DB查询次数。
• 通用兜底值：如果不想做差异化处理，设5分钟是比较稳妥的选择，避免短缓存导致DB频繁被打。

v2 info-hashes在files数组中的格式要求 #

必须提供完整的32字节v2 info-hashes，绝对不能截断。
v2的info-hash是基于文件树结构的完整SHA-256哈希，截断后客户端无法正确匹配对应的资源。如果你的tracker同时支持v1和v2，要分别为两种哈希类型提供完整值，不要混用格式。

记录peer监听端口而非GET参数port的方案可行性 #

这个方案是有实际价值的，但要注意落地细节：

• 优势：GET参数里的port通常是NAT映射后的外部端口，而peer的实际监听端口是内部端口。对于同一NAT网络内的peer，直接返回内部端口可以减少NAT穿越的开销，提升连接成功率。
• 注意事项：
  1. 监听端口需要通过客户端的扩展协议（如PEX、UTP握手消息）获取，不能仅依赖客户端主动上报——很多客户端默认不会在HTTP请求里携带监听端口。
  2. 不能完全抛弃GET参数的port，要把监听端口作为补充字段：对于跨NAT的peer，依然需要返回外部端口；只有同网段的peer才返回内部端口。
  3. 要做好端口校验，避免客户端上报无效的监听端口。

内容的提问来源于stack exchange，提问作者vlad