tcp 是可靠连接,为什么有时候网络上下载的压缩文件会无法解压

2018-08-16 09:07:02 +08:00
 zmxnv123
2792 次点击
所在节点    问与答
16 条回复
znood
2018-08-16 09:11:37 +08:00
下载文件又不是一个 tcp 请求,可能是服务端或者下载工具的问题
hahasong
2018-08-16 09:12:48 +08:00
下载工具的校验和填充逻辑 bug
kurtrossel
2018-08-16 09:18:20 +08:00
不知道从什么版本开始,新版 WinRAR 做出来的压缩包用旧版解压会报错

升级 WinRAR 到最新版可解

我猜你可能遇到的是这问题

并非污染或者劫持所致,我也困惑了很久......
x7395759
2018-08-16 09:19:00 +08:00
多看书,计算机网络。
DevNet
2018-08-16 10:03:10 +08:00
这么说吧,四层的 TCP 是有可靠的重传机制,但是 7 层的应用是有超时时间的,不可能一直等待 TCP 重传。毕竟三层的 IP 层面实现的是尽力而为的转发,链路质量差的时候谁也没办法。
yksoft1
2018-08-16 11:06:36 +08:00
你换个内存条看看
nfroot
2018-08-16 11:25:33 +08:00
@kurtrossel Winrar5.5 开始默认设置就是 rar5 格式了。所以我给大家都装 5.4 然后禁止升级,哈哈哈
night98
2018-08-16 11:27:16 +08:00
劫持,校验出错,非 http 下载,等等等等
stephenyin
2018-08-16 11:38:03 +08:00
大多数下载其实并不用 tcp, 用 tcp 的下载不会太快.
kokutou
2018-08-16 11:40:23 +08:00
因为百度网盘客户端做的太垃圾了。

再就是上面说的 WinRAR5 的问题。
zpf124
2018-08-16 11:43:16 +08:00
最简单能想到的容易出错的情况是 多线程下载和 p2p 传输。

当年迅雷 百度云 下载出错了一点都不奇怪。
首先 多线程的情况下,每个线程的 tcp 连接都是对的,但网络不稳定没准某个线程的链接就断开了,而它对应的线程数据还不一定都写到硬盘里了,没准写一半时间太长这个没有网络的线程就被 kill 了。

p2p 就更容易, 万一 这么多个源里,有一个人那他自己的文件本身就是错的, 你收到的了之后 tcp 只能验证和他一样,但一样那也是错的。
paparika
2018-08-16 12:00:43 +08:00
难道不是数据源头(存储器)的问题?
lychnis
2018-08-16 12:01:06 +08:00
这根 tcp 啥关系...
mrzx
2018-08-16 14:37:58 +08:00
楼上有个人说对了。
可能只是 RAR 换压缩算法了。

最新的 winrar 默认用 v5 版本的新压缩方法,老式 winrar 版本老的根本无法顺利解压,直接报错。
Hk4Fun
2018-08-16 14:41:35 +08:00
上次用 idm 下载百度云一个 4.3G 的压缩文件就是这样
flynaj
2018-08-17 09:55:31 +08:00
可能源数据就是错的,迅雷下载的经常这样

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/480241

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX