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