[quote]冲锋号响起： 你这个属于正常现象！iis 默认应该只能允许一定的线程数量 10*10=100个线程数全满，线程池被占满，并且其他任务不能执行，造成死堵塞，这个只是我的猜想。 另外给点建议，你既然是测试断点续传 ，关键问题不在于开了多少任务，多少线程，你这个问题的可能性扩大了很多，建议你开一个任务 3个线程 这样测试，是否没问题。 如果这样没问题证明你的断点续传是通过测试的，再研究处理剩下的问题。[/quote] 感谢3楼，经过我进一步设置，就可以响应更多线程下载了，但为何.NET 不自动提升这些数量呢？明明还有好多资源可以用。 C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config <system.web> <!--add--> <httpRuntime minFreeThreads="362" minLocalRequestFreeThreads="304" appRequestQueueLimit="5001"/> <!--add--> <processModel autoConfig="false" maxWorkerThreads="1000" minWorkerThreads="200" maxIoThreads="1000" minIoThreads="200" />

标记学习下

EnableSessionState=”ReadOnly” 试下

同样关注，去年我也用这段代码，本地测试没问题，往服务器上面一放，都不能下载了。

表示关注。。。

你这个属于正常现象！iis 默认应该只能允许一定的线程数量 10*10=100个线程数全满，线程池被占满，并且其他任务不能执行，造成死堵塞，这个只是我的猜想。 另外给点建议，你既然是测试断点续传 ，关键问题不在于开了多少任务，多少线程，你这个问题的可能性扩大了很多，建议你开一个任务 3个线程 这样测试，是否没问题。 如果这样没问题证明你的断点续传是通过测试的，再研究处理剩下的问题。

正在研究这块，有结果第一个告诉你...

能不能断定续传取决于远程服务器，跟客户端用哪种语言没关系。 如果服务器支持，保存断开时刻的文件信息就可以恢复下载。