南极自主仪器卫星数据传输：低开销协议选型及协议开销相关技术问询

嗨，针对你在南极部署自主仪器面临的卫星带宽限制问题，我来结合实际经验梳理下你关心的几个核心点——毕竟这种极致抠带宽的场景，每字节都得精打细算：

一、FTP传输时的元数据开销到底和什么有关？ #

你之前查的文件系统元数据（比如inode、MFT条目）其实和传输带宽没关系，核心要区分这几点：

• 本地/服务器文件系统的元数据：这些是存储层的东西，FTP传输时根本不会碰——你用PUT命令传文件，只会把文件的字节流发出去，本地的创建时间、权限，服务器端生成的inode数据，都不会占用你的卫星带宽。除非你主动用LIST、STAT这类命令去获取元数据，那才会产生少量交互流量。
• FTP协议的元数据交互：比如登录命令（USER/PASS）、传输命令（TYPE I/PUT），每条命令大概几十字节，集中在一次会话里的话，总开销也就几百字节，和你每天130kB的配额比几乎可以忽略。

二、最省带宽的传输协议怎么选？ #

结合你的场景（小批量数据、允许偶尔丢包、每天一次传输），按带宽友好度排序给你列出来：

1. 自定义极简TCP/UDP协议
   这是最省的方案：直接把你的状态/测量数据打包成二进制块，要么用TCP直接发（只带IP+TCP头，每个包固定40字节左右开销），要么用UDP发（IP+UDP头28字节）。你可以自己加个极简的校验（比如16位校验和，2字节），比协议自带的校验开销小太多。
   适合你的原因：完全没有冗余的协议字段，所有字节都是你的有效数据，握手开销只有TCP的3次握手（约60字节），UDP甚至不需要握手。

2. SFTP（关闭元数据同步）
   如果需要简单的加密或身份验证，SFTP比FTP略灵活，但要记得在客户端配置关闭元数据同步（只传文件内容）。单次SSH握手开销大概几百字节，后续传输每个包的额外加密开销大概10-20字节，整体开销可控。

3. FTP（二进制模式）
   用FTP的二进制模式（TYPE I）传输，避免ASCII模式的编码开销。主动模式下数据连接的额外握手开销不大，控制连接的命令总开销也就几百字节。但要注意，有些FTP客户端默认会同步文件时间，记得关掉这个功能，省掉那点元数据流量。

4. HTTP/HTTPS（不推荐）
   HTTP的请求头最少也要几十字节，HTTPS的TLS握手开销更是大得离谱（TLS1.3都要几百字节，老版本更甚），每天只传一次的话，握手开销占比太高，完全不适合你的低带宽场景。

三、块大小对传输开销的影响——必须重视！ #

块大小绝对和传输开销有关，不是只有存储的问题：

• 每个IP+TCP数据包都有固定的头开销（IP20字节+TCP20字节=40字节）。如果你把数据分成100字节的小块，每个包的开销占比是40/(100+40)=28%；如果分成1460字节（以太网MTU对应的TCP有效载荷），开销占比就降到2.67%，差了10倍！
• 建议你把数据打包成接近卫星链路MTU大小的块（比如1400字节左右，留余量避免IP分片），分片会让每个分片都带IP头，额外增加开销。如果不知道卫星链路的MTU，可以先测试从1000字节开始往上试，找到最优值。

四、那些容易被忽略的隐性开销 #

• DNS查询：如果你的服务器用域名，每次连接前的DNS查询会产生几十到几百字节的流量，直接把服务器IP硬编码到设备里，省掉这笔开销。
• TCP Keep-Alive：别开这个！如果连接保持打开，定期发送的Keep-Alive包会浪费流量，传输完就断开连接就行。
• TCP Nagle算法：开启TCP_NODELAY选项，避免小数据包被合并延迟发送，虽然不影响总开销，但能让数据更快发完，减少链路占用时间（卫星链路延迟高，这点很重要）。

总结下来，最适合你的方案就是自定义极简TCP/UDP协议，把当天的数据打包成大的二进制块，用接近MTU的大小发送，完全砍掉不必要的协议冗余。如果需要身份验证，自己加个16字节的固定密钥就行，比用成熟协议省太多。

备注：内容来源于stack exchange，提问作者Blacksad