下载文件消耗的流量比实际文件大很多是什么原因

试一下单线程下载看看

非相关领域，讲一些自己的理解，不一定对。

1. 下载过程中，如果某些数据有问题，就要丢掉，然后重新下。

2. 下载过程中，有可能丢包，需要重传。

3. 不知道你下载东西用的什么协议，如果是 http 协议，传输过程中 header 之类的会有额外的流量开销。

下载文件时的消耗的网络流量，受网络协议、压缩协议、文件大小等多方面因素影响。

接 2 楼

1. TCP/IP 包头 ：这部分消耗的大约占比 2-3%左右。
2. TCP 重传： 这个有可能会丢包，这个要看链路环境了。不知道这种重传应用层能不能统计到。有数据说这部分可能在 3%-7%左右。

如果这样算的话，比实际文件大是正常的，但是具体大多少，就不好说了。

贴一段华为云 CDN 的描述：

服务概览和统计分析页面展示的是加速域名日志中记录的流量数据，是应用层日志统计出的流量，但是实际产生的网络流量由于 TCP/IP 包头消耗和 TCP 重传消耗要比应用层统计到的流量高出 7%~15%。因此按照业界标准，应用于账单的计费数据会在控制台监控数据的基础上上浮 10%。

@ylls 自己写程序单线程下载没问题

@Junzhou 问题是我直接用浏览器下载的，传输过程可能丢失部分数据或者重复的头部信息，但是不应该高出太多的

@Junzhou 如果上浮 10% 是可以接受的，但是这相差 30% -70% 了.。。。，他们给我的解释是客户端的问题，不是他们统计的问题。。。通过分析日志看到浏览器同时发出了 200 和 206 的请求

@KevinTsui 那你就要问问七牛云，这个流量统计是实际的，还是根据实际流量按照业界标准上浮了。

@KevinTsui 如果是 206 请求，你可以看下这个请求的 content-length ，这个应该是实际的文件大小，计算下这些 206 请求的 content-length 的大小和，是不是 26MB 。 如果大于 26MB ，可能这里做了冗余。 比如一个文件 10MB ，切成 10 个 1MB 的，实际可能会每个分片，是 1.1MB, 有 0.1MB 的冗余。

@KevinTsui 如果是浏览器下载的，结合你说的有 206 状态，我觉得这里可能是断点续传导致的流量消耗更多，不过你可以找七牛的技术确认下这方面的影响。

@Junzhou 好的，我跟他们确认下，谢谢了

浏览器下载会发送多条请求，但是浏览器调试又看不出来。

拉原始日志直接一条命令算一下
统计流量在原始文件的 105%左右是正常的
但计费平台可能直接再×1.1 把 TCP 开销算上

查下 http header 的 content-type ，有可能不是按照 binary 模式来下载的，而是经过某种编码。比如编码成 base64 ，大小就会增加 1/3

@Junzhou 话是按你说的没错，但是 gzip 不是能压缩么？用于减少传输的文件的大小

加解密，压缩