我们公司正在与另一方建立 B2B 集成，这需要他们向我们提供大量在三个小时内处理约 100,000 个 XML 文件，每个文件大小约为 10-15 KB每天。我们计划利用我们的FTPS 服务器 (TLS/SSL)对于此交换来说，它具有高可用性并且在 Linux 上运行。
另一方对 FTPS 的读写开销提出了一些担忧，称传输可能会超出允许的时间范围。我们的基础设施专家向我保证，只要我们在文件获取后删除，通过 FTPS 传输这么多文件不会有问题，尤其是在 HA Linux 服务器上。
我想证实上述方法。有人通过 FTPS 实现了高容量传输吗？这是一个坏主意吗？我们应该实施基于队列的方法吗？
在负载测试期间发现问题为时已晚。如果问题有点开放，请见谅。如果您需要具体细节，我可以提供。非常感谢
答案1
简短回答： 如果服务器距离较近，你也许可以这样做，如果服务器距离较远，你很可能会错过传输窗口。但无论哪种方式，对于“简单”的实现来说，这都是一个坏主意。
更完整的答案：
我认为这个网站不适合回答这类问题 - 正确的答案是“视情况而定”，以及“你应该自己进行测试”。（此外，也许 Serverfault 会是一个更好的论坛，因为这个论坛更适合业余爱好者）。
话虽如此，我质疑 FTPS 是否是一个好的解决方案，因为它似乎有非常高的开销——在添加额外的加密开销之前，FTP 已经够糟糕了。
至于这在技术上是否可行，在很大程度上取决于你的管道速度、服务器之间的距离以及你同时建立的连接数（多个连接可以在一定程度上缓解高延迟）。
如果您可以将多个文件合并为一个更大的文件，传输它们，然后解压缩它们，您将获得非常大的可观的性能提升，因为：
- 您可以减少延迟问题（以及加密计算开销，但我们忽略这些问题，因为它们相对于其余问题而言并不重要）
- 您可以压缩文件以减少需要传输的数据量。
您尚未指定传输如何进行 - 它是一个上传多个文件的单个 FTPS 会话还是每个文件都有一个单独的 ftps 会话。
后一种解决方案（我怀疑编程起来更容易）将产生巨大的开销，因为每个连接都需要协商，而这种协商相对于小文件来说是昂贵的。（我不是 FTPS 专家，但TLS 通常会给每个请求增加大约 6-7k 的开销而 FTPS 是包装在 TLS 协议中的 FTP 会话）。
假设有效载荷微不足道，则每个请求的延迟将增加约 3 倍。如果站点位于同一网络上，这可能并不重要，但是，例如，如果连接的一端在纽约，另一端在洛杉矶，则延迟时间为 80 毫秒，当您将其乘以文件数量时，您将看到严重的延迟问题，并且您可能会超出传输窗口 - 即使 NAS 可以处理它。
答案2
我将在这里提供一个答案，量化你可能面临的问题。我已经投了赞成票大卫戈的答案，因为它正确地描述了这个问题。
假设三小时内完成 10 万次转账，平均大约每秒 10 次传输。每次传输需要 100 毫秒。
服务器到服务器的延迟必须比这低一个数量级，比如说 10 毫秒，才有可能跟上传输速率。
如果服务器通过 WAN 连接，那么您可以认为这几乎是不可能的。除非您使用多个并发连接，但如果事务本身是连续的，则实际上会抵消并发提供的任何潜在收益。