一个关于分享资源的不成熟想法
1351
引入
2023年,我在zhelper search上查书,了解到了ipfs技术。当时并没有觉得有什么,便不再理它。
时隔一年后(2024年),我在下galgame的时候知道了梓零的网站。当时下得非常开心,但是没一两月E5炸了,梓零倒了。于是我在想有什么办法能成本低地分享大文件,并且还不容易挂。这时我突然想起了ipfs协议,并浅浅地学习了一下。
开端
ipfs协议是一个非常新的东西(2012年面世),但是它却非常地NB(原谅我词穷了)。我认为ipfs协议NB之处有四点:
-
资源比较稳定(只要不过于冷门,一般不会丟失)
-
理论上永远不会被墙
-
免费上传,免费下载
看到这里,可能资源大佬觉得与种子差不多,但是ipfs协议与种子有一个最大的区别,就是:
无需做种,资源是否冷门只决定资源存在时长,不决定下载速度
发展
那么怎么用ipfs协议呢？论坛已有大佬给出教程。我这里再补一个网关和测速的:
虽说ipfs协议比较稳定,但是速度也只稳定在80-100kB/s,这也是很多大佬放弃ipfs协议的原因。难道ipfs协议真的只是空有的...NB吗?
高潮
ipfs协议之所以低速,是因为ipfs不支持多线程下载。如果大佬们浅浅了解ipfs/web3的话,便会知道ipfs从技术上就不支持多线程下载。
那么ipfs真的没救了吗?
托马斯·维德曾言“前进，前进！不择手段地前进！”如果ipfs不支持多线程的话,那么我们便强行让它支持就可以了。
我们使用BinaryCutting-Tool切分文件为n个1MB左右的文件,之后写一个index.html,可以多线程地下载这n个文件,之后再合并成原文件下载。这样就解决了多线程的问题。
下面附上demo的index.html(用文心一言生的,不过我觉得不行。这也是我发这个话题的原因——请大佬修改出一个更好的代码)
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Parallel Download</title>
</head>
<body>
<h1>Parallel Download Example</h1>
<button id="downloadButton">Start Download</button>
<div id="status"></div>
<script>
const TOTAL_PARTS = n; // Replace n with the actual number of parts
const BASE_URL = 'https://example.com/';
const OUTPUT_FILE_NAME = 'file.name';
document.getElementById('downloadButton').addEventListener('click', async () => {
const statusDiv = document.getElementById('status');
statusDiv.textContent = 'Downloading...';
const partPromises = [];
for (let i = 1; i <= TOTAL_PARTS; i++) {
partPromises.push(downloadPart(i));
}
try {
const parts = await Promise.all(partPromises);
const blob = new Blob(parts);
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.style.display = 'none';
a.href = url;
a.download = OUTPUT_FILE_NAME;
document.body.appendChild(a);
a.click();
window.URL.revokeObjectURL(url);
statusDiv.textContent = 'Download complete!';
} catch (error) {
statusDiv.textContent = `Error: ${error.message}`;
}
});
async function downloadPart(partNumber) {
const response = await fetch(`${BASE_URL}${partNumber}.bin`);
if (!response.ok) {
throw new Error(`Failed to download part ${partNumber}: ${response.statusText}`);
}
return response.arrayBuffer();
}
// If you want to use Web Workers for better performance,
// you can implement a worker script and manage the download tasks there.
// However, for simplicity, we'll stick with the main thread here.
</script>
</body>
</html>
结尾
2024年,对于许多资源大佬而言,是一个不算好的年。E5崩了,onedrive开始割韮菜,各大网盘也开始整活,加强了API防护与资源审查,国内做种环境变差的同时还有某雷吸血。各位大佬在改后缀名、不断压缩与hash混淆中与各大网盘斗智斗勇,而各位"贫民"在与网盘限速、找解压密码和工具中过得水深火热
我希望,2025年是一个各位大佬不被封号和不再炸链的一年,是一个各位"贫民"轻松下gal的一年,是一个让所有人都能玩gal的一年。这是我引入ipfs技术的原因。虽然目前方案并不成熟,但是我相信在各位大佬的帮助下,我们一定可以建造更美好的未来。
最后,祝大家新年快乐!同时谢谢过去一年因无私分享而付出努力的大佬们!
4834
刚刚在 Telegram 群讨论了一下这个问题，有几个朋友一致觉得太慢了
30-01-2025 - 16:10
1119
对于一个百度网盘免费用户，感觉80KB-100KB的下载速度也不是不行？
但既然搞文件分享的大佬们说这样太慢了，不适合分享，我没有异议。不过，我认为重点在于作为一个P2P协议，IPFS安全性如何？就像类似torrent这种基于文件hash的协议基本上是明文的，会不会受国内缺乏公网ip的影响，或者被运营商/网络代理（机场）通过流量探测判断协议类型封禁两点？倘若这种去中心化的协议若能实现，自然没问题。
不过既然说了这是一个“理论上永远不会被墙”的协议，以上问题或许有些对策了吧。总之，感谢分享。
https://ipfs.tech/
https://en.wikipedia.org/wiki/InterPlanetary_File_System
30-01-2025 - 16:59
你的担忧应该是ipfs会不会像p2p杀手类似的技术给ban掉。这个问题我是比较难回答的,因为ipfs与p2p有差别的,但说不好这个差别会不会被识别到。我能解释的只有一句话:与其说ipfs像p2p吧,不如说ipfs更像比特币(指Filecoin,并且ipfs跟以太坊有很大关联)+p2p+git+...如果你真地想问个所以然的话,你可以去[登链社区](https://learnblockchain.cn)。不过ipfs协议还是很抽象的,如果你以后不专攻web3的话,我还是建议你只是把ipfs当成一个网盘
4834
31-01-2025 - 06:30
这位大佬估计指的是ipfs存储网盘,这个确实是只剩下了国外的在服务,并且上传极慢。但是ipfs是可以自己搭网关的(指ipfs desktop)。如果是自搭网关的话,上传速度是十分可观的(今年一月份我在上传2.7G的东西时跑到了10M/s左右的速度)。这里还有人做的测试数据(https://zhuanlan.zhihu.com/p/518262755?utm_id=0)当然,这里还用热心大佬做的图床(https://app.img2ipfs.org/)(这个图床的服务器性能不太好,上传大文件不行,但是几M的图片还是可以的,并且上传速度也差不多在500k-1M/s(这是我才试的,附上链接https://i0.img2ipfs.com/ipfs/QmRry1AhEB6jY7Sxbm8yzUTAfGTc1EePjhKz2RFpymbWnz?filename=b_bg01.png))(但是ipfs下载真的太慢了,不过目前我了解的是ipfs可以同时下载好几个文件(可以并行下载),所以才有了分片下载的设想(只可惜没有demo)。如果真想下大文件的话,建议用ipfs本地网关先pin上几个小时再下载)
Emmm，把CID挂到galgame区？（虽然wikipedia只说了brave和opera支持ipfs协议） 按照拆分文件的思路的话，因为同时存在很多小文件，以这种方式分享的资源难以通过单独的一个链接下载，既然服务器没有多余算力整合资源，那么一个更加可行的方式是下载一个列表，然后通过可信？的客户端下载 这部分内容也许可以另开一个教程，毕竟大部分都还仅存于理论中（可不要一不小心就把小站变成技术论坛了）
