大文件上传下载用搭建哪种服务好？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 393 天前的主题，其中的信息可能已经有所发展或是发生改变。

上古时期都是搭个 FTP ，但是由于不安全，越多越多的地方不让用了。但有加密传输的 SFTP 之类的，安全性如何？感觉很多单位只要对带 FTP 的就很敏感，SFTP 也不让用，有什么合理的理由么那系统里如果需要大文件上传下载服务，如果不选择现在商业第三方的组件的话，还有什么替代选择么？或者 SFTP 就是没问题的

sftp

FTP

上传

下载

30 条回复 • 2023-08-25 09:22:28 +08:00

BG7ZAG

2023-08-23 15:02:22 +08:00

试试 SCP

mightybruce

2023-08-23 15:02:40 +08:00

你需要一个专门的存储系统。
存储系统总体来分，可以分为：块存储，对象存储和文件存储。
简单一点的小文件存储系统，比如 fastdfs
对象存储系统比如 minio

对象存储适合的场景：
1 、一次写，不修改，多次读。（比如互联网的图片，音视频等）上传结束就是文件修改结束。
2 、基本没有随机访问共享数据内部位置的需求。
3 、没有多个客户端同时修改一个文件的需求。
4 、平坦结构，没有类似目录的层级关系。（有人会挑战说对象的 key 可以是个带有/前缀字符串来模拟目录，但其实跟文件目录差距非常大，后面我们讨论）

文件存储适合的场景：
1 、可以修改文件数据，随时修改，随时读。文件系统没有文件“修改结束”这个概念。
2 、支持文件内容的随机访问。
3 、多客户端通过文件系统交换数据，客户端 1 写数据（修改数据），客户端 2 ，读数据。我们比较一下文件存储和对象存储的异同。文件存储：客户端 1 写共享文件存储上的文件，写完之后关闭。客户端 2 直接打开共享存储上文件读。对象存储：客户端 1 ，在本地写数据，写完数据，要把整个文件上传，客户端 2 下载数据到客户端 2 本地，然后再打开本地文件读文件。可以发现对象写本地，上传远端，相当于写了两次；下载到本地，读本地文件，相当于读了两次。从交换数据的效率来看，频繁在客户端之间交换数据的应用场景不适合对象，适合文件。因此高通量计算/批量计算基本上倾向于文件存储。
4 、文件存储支持两个客户端同时修改一个文件，比如高性能计算 MPI 。
5 、无论是 NAS 还是私有客户端的共享文件存储基本上都会为了性能设计客户端的缓存系统，因此性能比较高。对象存储的客户端自己是不带缓存系统的，因为对象操作的数据要不就是本地数据待上传，要不就是得把数据完全下载到本地才能访问，因此不需要什么客户端缓存系统，性能角度要比文件存储差。
6 、目录层级关系。文件的目录和对象 key 的带有/前缀有啥差别？差别大了，rename/mv 高层目录，对文件系统而言只是目录改名，代价很小。对象存储 prefix 如果想模拟目录改名那么只能是所有带有 prefix 的 key 的批量更新。
7 、文件存储中各种软/硬链接等复杂语义对象存储没有对应的实现。（很多人认为文件存储是个树形结构，其实是错误的，因为有 hardlink 所以文件存储系统是个图结构，两个树枝的叶节点可以交汇）

ruixue

2023-08-23 15:12:04 +08:00

基于 https 的 webdav 就挺好的，无论兼容性、传输效率还是安全性都不错

zedpass

2023-08-23 15:14:08 +08:00

如果要放在公网，提供给多人使用的话，还是使用云厂商的对象存储吧

Kumo31

2023-08-23 15:20:54 +08:00

感觉 2 楼说偏了，文件、块和对象都只是上层接口而已，面向的“使用者“不同，Ceph 就都用 osd 对象存储的模式存。**简单来说，没有特殊需求的情况下**，直接读写裸盘的程序用块存储，直接给人用的上文件存储，而普通程序不需要像数据库或者 OS 一样直接对块级别做细粒度的管理，也不需要文件这种形式的抽象，对象存储的 KV 语义是最适合的。

laqow

2023-08-23 15:24:58 +08:00

p2p 单次链接单次下载就 croc 或者基于 udp 的 wormhole

cnbatch

2023-08-23 17:12:17 +08:00

SFTP 是基于 SSH 的，SCP 也一样，可以认为是基于 SSH 分出来两种不同的传输程序，其中 SFTP 比 SCP 完善得多

FTPS 才是原始 FTP 套一层 TLS/SSL

FTP 与 FTPS 的关系，就如同 HTTP 和 HTTPS 的关系

许多单位不懂这些其实不算奇怪，他们的技术水准甚至连半桶水都没有，顶多也就是塑料瓶的几滴水。这本来没什么，问题在于他们还十分懒，稍微查下资料都懒得查，表层理解都不愿理解。

cnbatch

2023-08-23 17:14:08 +08:00

个人觉得，对于这种单位，直接给他们部署 SMB 得了

tabris17

2023-08-23 17:40:29 +08:00

对于“传统”公司，刻 DVD 快递

srliuhao

2023-08-23 17:43:22 +08:00

@BG7ZAG 您说的是 Linux 下的 SCP 命令么，我的场景下不行，面相客户端的，在 windows 甚至下 web 下进行的上传下载

srliuhao

2023-08-23 17:45:22 +08:00

@tabris17 超大文件确实有刻盘这一选项，不过一般的文件还是需要在线传输的^_^

srliuhao

2023-08-23 17:46:01 +08:00

@mightybruce 感谢回复，不过我这个场景还不在存储的设计上，需要解决客户端传输文件的问题

srliuhao

2023-08-23 17:46:13 +08:00

@ruixue 感谢，我查查看

srliuhao

2023-08-23 17:46:29 +08:00

@zedpass 单位自建机房的，就头疼

srliuhao

2023-08-23 17:47:02 +08:00

@cnbatch 是这样的，主要是没人愿意担责……

layxy

2023-08-23 18:49:51 +08:00

minio

nuk

2023-08-23 18:57:28 +08:00

丢云盘让客户自己下载

cnbatch

2023-08-23 19:01:01 +08:00

那就可以考虑给他们同时提供两种做法：Web 的就 HTTPS ，客户端就 SMB （既可以 Linux+SAMBA ，也可以直接就用 Windows 共享文件夹）。
这样可以覆盖大多数场景了，而且弄起来也不算特别复杂。

leaflxh

2023-08-23 19:08:05 +08:00

搞个 nextcluod 之类的，可以做用户权限控制

不搞第三方商业产品的话那就 nginx 搭个 webdav 然后手撸权限控制吧

安装 nginx 模块：

apt-get install libnginx-mod-http-dav-ext
nginx 配置文件：

server {
listen 4500;
server_name _;

location /dav
{
client_max_body_size 5G;
#目录
alias /mnt/slice256;
index index.html index.htm;
autoindex on;
client_body_temp_path /tmp;

dav_methods PUT DELETE MKCOL COPY MOVE;
create_full_put_path on;

dav_ext_methods PROPFIND OPTIONS;
#偷个懒，单纯用 ip 段限制访问。后续添加 http auth
allow 192.168.0.104;
deny all;
}
}
在 Windows 的文件管理器 - 右键此电脑 - 映射网络驱动器 - 输入 http://ip:port/dav/即可挂载

浏览器直接访问 http://ip:port/dav/即可下载