没有马上归零可能只是个视觉效果吧, 多线程直接断开TCP连接然后记下位置是可以的, 用不了多少时间, 除非他在buffer填满之后才断开连接, 不过并不是使用了多线程的充分条件. 反而建立连接更花时间. 多线程/断点续传的原理就是在Http请求的Header加个Range, 这样服务器就会在Content给你想要的部分.
Steam的下载当然是多线程的, 单线程的下载工具几乎见不到了.
在不考虑网络的情况下, 最耗时是合并操作, 在每个线程的任务完成之后, 会合并文件, 然后再在剩下的部分分块, 分线程. 当然, 大多数的软件是最后才来合并, 比如IDM.
为什么要合并? 因为每个线程下载的内容会先写到一个字节数组(buffer), buffer满了之后, 就追写到一个临时文件(很多下载器会建立类似part.1之类的文件就是), 总不能放到内存占着. 然后会把一堆临时文件一个一个地读取, 并写入到新的文件(目标文件), 即是你最终得到的文件. 在电脑配置相同时, 越大的下载任务, 所需要的时间自然越长.
steam的合并耗时并不是问题, 因为他们用了不同的机制, 最耗时的还是网络, 推断题主遇到的问题的主要原因, 就是网络原因, 每当一个线程下载完成时, 或者网络不稳定意外断开线程时(多线程下载很常见), 就会与服务器建立请求, 首先是请求负责分配的服务器, 然后分配到具体的节点后再次请求(当然还要经过一路上的各种服务器), 如果你不幸分到了慢的节点, 连接服务器的速度就会更慢, 连接耗时是一个原因.
至于暂停之后变快, 可能是因为统一重新分配了更快下载节点, 也可能是因为突发速率的缘故(一般提供商设置一个远大于带宽的突发速率值, 以提高用户浏览体验)
Steam官方说他们全面使用http协议, 下载区块以1MB为单位, 并且每下载完一个块就解压缩, 因此排除p2p方式(例如bt)的可能.
港区和日本区真是yyds