重复下载

[jiangyanlily]

每次下载的时候都会先发起range为 0- 的请求，然后再分段下载，但是这一个 0- 的请求，就已经下载了整个文件了，为什么不发起一个range为0-0的请求，然后解析response中的content-range来获取总长再进行分段？我自己改了一版代码，发现这样也是完全可以下载的，可以解决掉重复下载的问题，但不明白为什么作者不这样用呢？其他的使用者好像也没反馈类似问题

[Jacksgong]

赞，这块这边抓包确实是存在相关问题（实际测验完整的分块下载45M左右的文件，首次连接虽然只用于获取请求头，抓包发现请求头只有1kb大小，但是却拉取了2M左右的body），初步怀疑底层库可能有做相关的网络i/o的缓存。

---

但是如果直接将首次连接请求改为0-0，一些需要使用首次连接输入流的case会受到影响，因此这块会综合探究之后，将这个问题在1.7.0中修复。

[Jacksgong]

@jiangyanlily 感谢你细心的点出了这个bug，目前这个bug已经修复，将会在1.7.0带上，该问题的根本原因我在这里做了探究，感兴趣也可以看一看。

[Heycz]

1.7.2版本还是有重复下载

[Jacksgong]

@Heycz 你这是分块下载时建立的多条连接吧？原问题是TCP层的窗口缓存机制，某一条连接多下载了数据。

[Heycz]

但是我看实际的流量消耗确实是翻了倍

[Jacksgong]

@Heycz TCP层窗口这块已经验证了没有问题，并且我在多个任务上验证不再存在多余的数据下载。

如果是流量翻倍，那应该在你那边是非常明显的问题，可否具体你那边跟踪下这个翻倍的流量是哪里产生的？

[Heycz]

我在AS上看好像确实正常,也就是我用chrome拦截的时候,第一个探测的时候显示的Size不是实际下载量吧

[Jacksgong]

@Heycz ok，如果有进一步的验证说明存在问题，欢迎随时讨论。

[Heycz]

@Jacksgong 为啥我用TrafficStats查看流量是X2了,包括手机自带的流量统计也是,是不是系统会把第一次探测的也算进去?

[Jacksgong]

@Heycz 探测采用的是Range是0-0，如下左图:

实际Response只有1字节，并且读取完响应头释放了，该响应也不会提供任何多余1字节的的输入流供使用（如果有，也是该请求的BUG，因为我们请求的Range是0-0理论只包含开头的1字节的数据），并不存在任何多余的数据。

如果说TrafficStats或者是系统自带统计是通过响应头中指示的数据大小（Content-Range）来统计流量，那这个错误也太低级了。

你可以通过Charles来跟踪下流量，Charles是我确定比较靠谱的。

[Heycz]

@Jacksgong 终于查到啥问题了,我初始化的时候传入的OkhttpBuilder的时候加入了HttpLoggingInterceptor这个拦截器导致的,我在你的demo上验证过,也是一样变了双倍

[Heycz]

我设置了HttpLoggingInterceptor的日志打印到body,然后探测的时候,HttpLoggingInterceptor会把body都down下来打印了.非常感谢 @Jacksgong 热心解答.还有就是我看到你是不是在重构这个库,改为okdownloader? em,值得期待

[Jacksgong]

@Heycz 嗯，是啊，之前FileDownloader有很多诟病，所以索性重写了okdownload。欢迎PR啊