我正在进行一个通过卫星连接互联网的项目，速度只有 130kB/天（如果我使用更多的话，费用就非常昂贵）。
我希望每天发送尽可能多的“有用”数据，同时保持在 130kB 以下。
我读这里（文件名是如何存储的？）和这里（元数据不占用任何大小吗？）元数据存储在文件系统的专用部分，但我不清楚发送它需要“花费”多少字节。
例如，如果我使用 FTP，它是否依赖于源文件系统？依赖于服务器文件系统？或者它与 FTP 协议有关？
说到传输协议，哪种协议最具成本效益？我在 Google 上搜索了一下，似乎每种协议都会消耗比特和字节来进行握手、数据完整性检查等，但我没有清楚地找到哪种协议最经济，以及协议本身的管理需要多少字节。
我还阅读了有关块大小的内容。这个问题与数据传输有关吗？还是仅与数据存储有关（在后一种情况下这不是问题）？
[编辑 2023-11-08 11:00]
我已经在进行数据选择、数据压缩、错误处理等工作。我对这些主题比较熟悉，我没有在这个问题中提到它们，因为我暂时不需要帮助，如果将来有需要的话，我会提出一个单独的问题。
我每天有 130kB，假设协议本身使用了 30kB。我的问题不是如何格式化我的数据，以便我可以在 100kB 内发送尽可能多的值，我的问题是：它真的是 30kB 吗？更多？更少？当然这取决于情况。但这取决于什么？在我最初的问题中，我列出了一些我添加的想法，我需要您的经验来了解我是否遗漏了什么和/或帮助我将研究范围缩小到轻量级解决方案。
背景要素：
它适用于部署在南极洲的自主仪器。那里没有与 Lora 相关的解决方案。
要发送的数据是仪器的状态和测量数据。数据本地存储，每年“物理”检索一次。数据用于查看是否应修改某些仪器的参数、进行一些预分析以及准备年度维护。
如果有一天的数据漏发或者没有发完整，问题也不大，应该不会是第二天再发。
答案1
要想从每天 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
从你说话的方式来看，我猜这些值通常不会快速变化。也许你可以为第一行发送高精度值，然后为后续的每一行发送较小的增量。如果你愿意发布你的一个数据文件，我很想尝试看看我能得到多小的值。
答案2
还不能发表评论，因此以下是我的建议：
对于许多基于文件的传输来说，130kb/天可能太有限了，但如果你再限制一下自己，就可以在其他方面相当有效地使用它。与通用文件传输相比，有关中间件和低级协议的研究可能与这种情况更相关。另一个存在此类问题的领域是远程物联网设备，LORA（或 LORAWAN）可能会引起你的兴趣。
解决这个问题的另一个角度是依靠共享知识。差分传输（跳过默认条目）和查找可能的消息表等方法可以将实际带宽降至最低，但需要对通信有很好的理解和编码。协议缓冲区是解决此类问题的一种方法。
不要忘记计算错误修正。它会增加原始大小，但可以防止使用不太可靠的传输方式重新发送时出现巨大的延迟。
答案3
我在这里（文件名是如何存储的？）和这里（元数据不占用任何大小？）读到元数据存储在文件系统的专用部分，但我不清楚发送它需要“花费”多少字节
文件元数据并不是你从文件系统中获取并“发送”的模糊东西。它是一组你挑选的单独参数——不同的协议发送不同的元数据集，如果你要创建自己的文件传输软件，你可以决定使用哪些字段想发送，并由您决定何时以及如何发送。
最大的元数据类型——描述文件在磁盘上的物理存储方式的布局——不仅依赖于文件系统，而且完全是内部的。也就是说，虽然你能向文件系统询问文件扩展名列表，这不是你需要的元数据是否需要转机（甚至查看）；您只需从头到尾读取文件，接收方的文件系统将决定其自己的存储布局。
大多数其他字段要么很小（例如时间戳），要么是可选的，不需要传输（例如文件权限，例如 SMB 或 NFS 将传输但 HTTP 不会 - 当然您也不需要）。
最后，由于这是多个字段，而不仅仅是一个不透明的数据块，因此总大小也高度依赖于你选择如何排列这些字段。例如，您是将修改时间作为文本日期、64 位纳秒字段、十进制秒或 varint 发送，还是根本不发送？
也就是说，在这个阶段很难甚至不可能给你一个现成的“哪种协议最好”的答案。你需要花一些时间研究网络协议设计；至少，你应该看着其中一些协议的工作原理（它们的规范或数据包捕获），以大致了解“元数据”的工作原理。
例如，如果我使用 FTP，它是否依赖于源文件系统？依赖于服务器文件系统？或者它与 FTP 协议有关？
使用网络文件传输协议时，源文件系统或目标文件系统通常无关紧要，因为全部目的此类协议的目的是抽象出底层文件存储的细节，并准确定义通过网络发送的内容。
当客户端与 FTP 服务器通信时，它对底层文件系统一无所知（它甚至可能不是一个真正的文件系统；FTP 服务器也可以将 MySQL 表视图显示为“文件”...），它交换的只是 FTP 命令——并且它只传输在 FTP 中定义的元数据字段。
我还阅读了有关块大小的内容。这个问题与数据传输有关吗？还是仅与数据存储有关（在后一种情况下这不是问题）？
两者都有。例如，某些传输协议会将校验和应用于每个块（例如，参见常用示例 XMODEM）；如果一切顺利，这将略微增加总数据量，但同时，如果链接质量较差且需要重新传输某些块（这比重新发送整个文件更便宜），则会大大减少数据量。这是根据您的特定需求进行调整的权衡。
（在这种情况下，您通常可以假设“块”和“数据包”大致相同。块大小由使用的传输协议定义，与存储无关。）
答案4
对于元数据，有两种类型：文件系统和内置。
文件系统元数据包括创建日期、所有者用户等，但通常这些元数据保留在源文件系统中，并在目标文件系统上重新创建。简而言之，它通常不会被转移，只会转移文件数据。但是，如果您转移的是存档，例如 Zip，则元数据会包含在存档中。
内置元数据包含在某些文件（例如 Office 文件）中，其中可能包含有关作者、数据等的详细信息。这些数据随文档本身一起传输，不可分割。
如果你想最大限度地利用带宽，协议本身就不那么重要了，可以是 FTP、FTPS、SFTP 或其他协议，根据需要。减少要传输的数据量更为重要。
您可以通过限制要传输的数据这一显而易见的方法来实现这一点，但也可以使用压缩方法来减少数据的大小。Zip 是较旧的压缩方法，但 7Zip 在大多数情况下是较新且更高效的。
我的回答 本文展示了最佳压缩参数随所涉及的数据类型而变化。为了找到最有效的参数，我使用了 7-ZIP 微调器。此工具通过简单地重复压缩不同的参数来寻找最佳组合，从而寻找最佳参数。您可以在数据上使用它来找到最佳参数。
请注意，已压缩的数据无法进一步压缩。压缩 Zip 档案或 Office 文档等文件毫无意义。