Bla*_*sad 18 metadata file-transfer filesystems
我正在做一个通过卫星连接互联网的项目，每天只有 130kB（如果我使用更多，那就非常昂贵）。
我希望每天发送尽可能多的“有用”数据，同时保持在 130kB 以下。
我在这里读到（文件名如何存储？）和这里（元数据不占用任何大小吗？）元数据存储在文件系统的专用部分中，但我不清楚它会“花费”多少字节发送它。
例如，如果我使用 FTP，它是否取决于源文件系统？在服务器文件系统上？还是跟FTP协议有关？
说到传输协议，最划算的是什么？我用谷歌搜索了一下，似乎每个协议都消耗位和字节来进行握手、数据完整性检查等，但我没有清楚地找到哪一个是最经济的，以及协议本身的管理需要多少字节。
我还阅读了有关块大小的内容。这个问题与数据传输有关还是仅与数据存储有关（在后一种情况下这不是问题）？
[编辑2023-11-08 11:00]
我已经在从事数据选择、数据压缩、错误处理等工作。我对这些主题比较熟悉，我在这个问题中没有提到它们，因为我暂时不需要帮助，如果是这样的话未来我会问一个单独的问题。
我每天有 130kB，假设协议本身使用了 30kB。我的问题不是如何格式化我的数据，以便我可以在 100kB 内发送尽可能多的值，我的问题是：它真的是 30kB 吗？更多的？较少的？当然这要看情况。但这取决于什么？在我原来的问题上，我列出了一些我添加的想法，我需要你的经验来知道我是否错过了一些东西和/或帮助我将我的研究范围缩小到光解决方案。
上下文元素：
它适用于部署在南极洲的自主仪器。那里不可能有与 Lora 相关的解决方案。
发送的数据是仪器的状态和测量数据。数据存储在本地，每年“物理”检索一次。数据用于查看某些仪器的参数是否需要修改，进行一些预分析并准备年度维护。
如果某一天的数据遗漏或者没有完成，问题不大，第二天应该就不会发送了。
907*_*997 19
从每天 130kB 的数据中获取尽可能多的数据的方法是消除尽可能多的协议层。FTP 提供文件名、权限、目录结构、身份验证等功能。您可能不需要这些功能。问题是，在出现问题之前我们到底可以削减多少？
一个好的起点是用 HTTP 替换 FTP。有一些开销，但非常小。作为一个例子，我刚刚尝试了一个带有curl的HTTP请求，HTTP以标头的形式添加了771字节的开销。如果需要，您可以进一步优化。请注意，除了来自 HTTP 的 771 字节开销之外，还有一些来自 TCP 的开销，因为 HTTP 运行在 TCP 之上。
更好的选择是直接通过 TCP 发送文件。TCP 有一些开销。该来源称其约为 2.74%（包括 IPv4 标头）。如果直接通过 TCP 发送文件，则不会传输有关该文件的元数据。您将不知道原始文件名。不过，这可能没问题。您可以根据收到的时间为其命名。
如果你想节省一点，可以使用UDP。这需要一些工作，但它可以帮助您降低 2.74% 的数字。
如果您想节省更多，可以使用原始 IP 套接字。它们在功能上与 UDP 相同，只是没有端口号或校验和，并且每个数据包的开销减少了 8 个字节。然而，缺少端口号意味着它们无法穿越 NAT。这需要您的远程测量计算机拥有自己的公共 IP 地址，但它可能没有。你也许可以让它工作，但我认为与 UDP 相比，这不值得付出努力。
正如其他人所指出的，您最大的节省潜力来自于从发送文件切换到发送数据。从评论中，你说：
我的仪器原始每日文件有80MB大（1行/秒，95列浮点数）
假设您的意思是 32 位浮点数，该文件应该是
[4 bytes per float]*[95 columns]*[86400 seconds in a day] = 31.31MiB
也许您正在存储 64 位浮点数（您真的需要那种精度级别）吗？
[8 bytes per float]*[95 columns]*[86400 seconds in a day] = 62.62MiB
从你所说的方式来看，我猜测这些值通常不会很快改变。也许您可以为第一行发送高精度值，然后为每个后续行发送较小的增量。如果您愿意发布您的一个数据文件，我有兴趣尝试看看我能得到多小。
小智 10
还不能发表评论，所以这是我的指示：
对于许多基于文件的传输来说，130kb/天可能太有限，但如果您对自己限制更多一点，则可以以其他方式相当有效地使用。关于中间件和低级协议的研究可能比通用文件传输更适合这种情况。存在此类问题的另一个领域是远程物联网设备，您可能会对 LORA（或 LORAWAN）感兴趣。
解决这个问题的另一个角度是依靠共享知识。诸如差分传输（跳过默认条目）和查找可能消息的表之类的事情会将实际带宽减少到最低限度，但需要对通信有很好的理解和编码。Protocol Buffers是此类问题的一种解决方案。
不要忘记计入错误纠正。它将增加原始大小，但可以防止使用不太可靠的传输重新发送的巨大延迟。
\n\n我在这里读到（文件名如何存储？）和这里（元数据不占用任何大小吗？）元数据存储在文件系统的专用部分中，但我不清楚它会“花费”多少字节发送它
\n
文件元数据并不是您从文件系统获取并“发送”的不透明的东西。它是您选择的一组单独参数\xe2\x80\x93 不同的协议发送不同的元数据集，如果您要创建自己的软件来传输文件，您可以决定要发送哪些字段，并且您可以选择要发送的字段。决定何时以及如何发送它们。
\n最大类型的元数据 \xe2\x80\x93 描述文件如何物理存储在磁盘 \xe2\x80\x93 上的布局不仅依赖于文件系统，而且完全是内部的。也就是说，虽然您可以向文件系统询问文件范围列表，但这不是您需要传输（甚至查看）的元数据；您只需从头到尾读取文件，接收者的文件系统就会决定其自己的存储布局。
\n大多数其他字段要么很小（例如时间戳），要么是可选的且不需要传输（例如文件权限，例如 SMB 或 NFS 将传输，但 HTTP 不会 \xe2\x80\x93 并且您当然也不需要）。
\n最后，由于这是多个字段而不仅仅是一个不透明的数据块，因此总大小也很大程度上取决于您选择如何排列这些字段。例如，您是否将修改时间作为文本日期、64 位纳秒字段、十进制秒或 varint 发送，还是根本不发送？
\n也就是说，现阶段要给您一个现成的“哪种协议最好”的答案，即使不是不可能，也是很困难的。你需要花一些时间研究网络协议设计；至少，您应该查看其中一些协议如何工作 \xe2\x80\x93 它们的规范或数据包捕获 \xe2\x80\x93 以大致了解“元数据”如何工作。
\n\n\n例如，如果我使用 FTP，它是否取决于源文件系统？在服务器文件系统上？还是跟FTP协议有关？
\n
使用网络文件传输协议时，源文件系统或目标文件系统通常并不重要，因为整个目的是抽象出底层文件存储的细节并准确定义通过网络发送的内容。
\n当客户端与 FTP 服务器通信时，它对底层文件系统一无所知（它甚至可能不是真正的文件系统；FTP 服务器也可以将 MySQL 表视图呈现为“文件”...），所有它交换的是 FTP 命令 \xe2\x80\x93 并且仅传输 FTP 中定义的元数据字段。
\n\n\n我还阅读了有关块大小的内容。这个问题与数据传输有关还是仅与数据存储有关（在后一种情况下这不是问题）？
\n
两个都。例如，某些传输协议对每个块应用校验和（参见 XMODEM 作为常用示例）；如果一切顺利的话，这会稍微增加数据总量，但同时如果链接质量很差并且需要重新传输某些块（这比重新发送整个文件更便宜），则会大大减少数据量。您可以根据自己的具体需求进行权衡。
\n（在这种情况下，您通常可以假设“块”和“数据包”大致相同。块大小由所使用的传输协议定义，与存储无关。）
\n了解一点关于乐器的知识，但对你的乐器一无所知，在压缩之前几乎总是可以做一些事情。
例如：
对于元数据，有两种类型：文件系统和内置。
文件系统元数据包括创建日期、所属用户等，但通常保留在源文件系统中，并在目标文件系统上重新创建。简而言之，通常不传输，仅传输文件数据。但是，如果您传输存档（例如 Zip），则元数据将包含在存档中。
内置元数据包含在某些文件（例如 Office 文件）中，并且可以包含有关作者、数据等的详细信息。该数据与文档本身一起传输并且是不可分割的。
如果您希望最大限度地使用带宽，协议本身就不那么重要，可以是 FTP、FTPS 或 SFTP 或其他根据需要的协议。减少要传输的数据量更为重要。
您可以通过限制要传输的数据的明显方法来做到这一点，但也可以使用压缩方法来减小数据的大小。Zip 是较旧的压缩方法，但 7Zip 更新且在大多数情况下更高效。
请参阅帖子 使用 7 Zip 压缩文件时最好使用哪些选项？
我在这篇文章中的回答 表明，最佳压缩参数根据所涉及的数据类型而变化。为了找到最有效的参数，我使用了 7-ZIP 微调器。该工具通过简单地使用不同的参数重复压缩来寻找最佳参数，以寻找最佳组合。您可以在您的数据上使用它来找到最佳参数。
请注意，已经压缩的数据无法进一步压缩。压缩 Zip 档案或 Office 文档等文件是没有意义的。
哪种协议最有可能通过卫星发送数据？
由于您提出的问题是绝对的（“大多数”）：
一种自定义协议，以可接受的最小（最不精确）形式传输压缩的原始二进制数据，并省略文件元数据等任何开销。这可能意味着将数据序列化为可变长度数据类型。您可能必须使用大量代表性数据来尝试许多不同的方法。
您也许可以使用 UDP 并推出自己的检查算法来检查丢失、重复或乱序的数据包，但最好从 TCP 开始。
我会包括一个校验和。
显然，对于自定义协议，您必须编写客户端和服务器软件，并对安全性等的影响进行自己的评估。
| 归档时间： |
|
| 查看次数： |
6113 次 |
| 最近记录： |