|  |      1ylls      2022-09-16 16:55:51 +08:00 试一下单线程下载看看 | 
|  |      2Junzhou      2022-09-16 17:00:08 +08:00  1 非相关领域,讲一些自己的理解,不一定对。 1. 下载过程中,如果某些数据有问题,就要丢掉,然后重新下。 2. 下载过程中,有可能丢包,需要重传。 3. 不知道你下载东西用的什么协议,如果是 http 协议,传输过程中 header 之类的会有额外的流量开销。 | 
|      3nothingistrue      2022-09-16 17:06:08 +08:00 下载文件时的消耗的网络流量,受网络协议、压缩协议、文件大小等多方面因素影响。 | 
|  |      4Junzhou      2022-09-16 17:07:22 +08:00 接 2 楼 1. TCP/IP 包头 :这部分消耗的大约占比 2-3%左右。 2. TCP 重传: 这个有可能会丢包,这个要看链路环境了。不知道这种重传应用层能不能统计到。有数据说这部分可能在 3%-7%左右。 如果这样算的话,比实际文件大是正常的,但是具体大多少,就不好说了。 | 
|  |      5Junzhou      2022-09-16 17:09:39 +08:00 贴一段华为云 CDN 的描述:  服务概览和统计分析页面展示的是加速域名日志中记录的流量数据,是应用层日志统计出的流量,但是实际产生的网络流量由于 TCP/IP 包头消耗和 TCP 重传消耗要比应用层统计到的流量高出 7%~15%。因此按照业界标准,应用于账单的计费数据会在控制台监控数据的基础上上浮 10%。 | 
|      8KevinTsui OP @Junzhou 如果上浮 10% 是可以接受的,但是这相差 30% -70% 了.。。。,他们给我的解释是客户端的问题,不是他们统计的问题。。。通过分析日志看到浏览器同时发出了 200 和 206 的请求 | 
|  |      10Junzhou      2022-09-16 17:33:35 +08:00 @KevinTsui 如果是 206 请求,你可以看下这个请求的 content-length ,这个应该是实际的文件大小,计算下这些 206 请求的 content-length 的大小和,是不是 26MB 。 如果大于 26MB ,可能这里做了冗余。 比如一个文件 10MB ,切成 10 个 1MB 的,实际可能会每个分片,是 1.1MB, 有 0.1MB 的冗余。 | 
|  |      11Junzhou      2022-09-16 17:41:39 +08:00 @KevinTsui 如果是浏览器下载的,结合你说的有 206 状态,我觉得这里可能是断点续传导致的流量消耗更多,不过你可以找七牛的技术确认下这方面的影响。 | 
|  |      13zungmou      2022-09-16 18:28:39 +08:00 浏览器下载会发送多条请求,但是浏览器调试又看不出来。 | 
|      14ngv2      2022-09-16 20:03:44 +08:00 via Android 拉原始日志直接一条命令算一下 统计流量在原始文件的 105%左右是正常的 但计费平台可能直接再×1.1 把 TCP 开销算上 | 
|      15weyou      2022-09-16 20:14:56 +08:00 via Android 查下 http header 的 content-type ,有可能不是按照 binary 模式来下载的,而是经过某种编码。比如编码成 base64 ,大小就会增加 1/3 | 
|  |      17wanguorui123      2022-09-17 22:26:36 +08:00 加解密,压缩 |