这是一个创建于 2673 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 znood 2018-08-16 09:11:37 +08:00 via iPhone  1 下载文件又不是一个 tcp 请求，可能是服务端或者下载工具的问题 |
 | 2 hahasong 2018-08-16 09:12:48 +08:00 via iPhone 1 下载工具的校验和填充逻辑 bug |
 | 3 kurtrossel 2018-08-16 09:18:20 +08:00 不知道从什么版本开始，新版 WinRAR 做出来的压缩包用旧版解压会报错 升级 WinRAR 到最新版可解 我猜你可能遇到的是这问题 并非污染或者劫持所致，我也困惑了很久...... |
 | 4 quickma 2018-08-16 09:19:00 +08:00 多看书，计算机网络。 |
 | 5 DevNet 2018-08-16 10:03:10 +08:00 1 这么说吧，四层的 TCP 是有可靠的重传机制，但是 7 层的应用是有超时时间的，不可能一直等待 TCP 重传。毕竟三层的 IP 层面实现的是尽力而为的转发，链路质量差的时候谁也没办法。 |
 | 6 yksoft1 2018-08-16 11:06:36 +08:00 1 你换个内存条看看 |
 | 1 @kurtrossel Winrar5.5 开始默认设置就是 rar5 格式了。所以我给大家都装 5.4 然后禁止升级，哈哈哈 |
 | 8 night98 2018-08-16 11:27:16 +08:00 via Android 劫持，校验出错，非 http 下载，等等等等 |
 | 9 stephenyin 2018-08-16 11:38:03 +08:00 大多数下载其实并不用 tcp, 用 tcp 的下载不会太快. |
 | 10 kokutou 2018-08-16 11:40:23 +08:00 via Android 因为百度网盘客户端做的太垃圾了。 再就是上面说的 WinRAR5 的问题。 |
 | 11 zpf124 2018-08-16 11:43:16 +08:00 1 最简单能想到的容易出错的情况是 多线程下载和 p2p 传输。 当年迅雷 百度云 下载出错了一点都不奇怪。 首先 多线程的情况下，每个线程的 tcp 连接都是对的，但网络不稳定没准某个线程的链接就断开了，而它对应的线程数据还不一定都写到硬盘里了，没准写一半时间太长这个没有网络的线程就被 kill 了。 p2p 就更容易， 万一 这么多个源里，有一个人那他自己的文件本身就是错的， 你收到的了之后 tcp 只能验证和他一样，但一样那也是错的。 |
 | 12 paparika 2018-08-16 12:00:43 +08:00 难道不是数据源头（存储器）的问题？ |
 | 13 lychnis 2018-08-16 12:01:06 +08:00 这根 tcp 啥关系... |
 | 14 mrzx 2018-08-16 14:37:58 +08:00  1 楼上有个人说对了。 可能只是 RAR 换压缩算法了。 最新的 winrar 默认用 v5 版本的新压缩方法，老式 winrar 版本老的根本无法顺利解压，直接报错。 |
 | 15 Hk4Fun 2018-08-16 14:41:35 +08:00 via Android 上次用 idm 下载百度云一个 4.3G 的压缩文件就是这样 |
 | 16 flynaj 2018-08-17 09:55:31 +08:00 via Android 可能源数据就是错的，迅雷下载的经常这样 |
Select Language