我正在下载一个大文件(大约100mb)，我时不时地收到SocketException: Read timed out。
我正在考虑提高套接字超时。实际上，我正在考虑将套接字超时设置为0(无限)，因为最终我的应用程序将下载的文件大小甚至可能大于300mb，甚至大于300mb。这是一个好的实践吗?
关于套接字超时，超时倒计时实际何时开始?我的意思是，当套接字超时发生时，这是否意味着连接仍然活跃，文件仍然在不断下载，但只是超时，因为套接字超时配置?或者当它认为连接仍然存在但服务器没有发送数据时开始倒计时;于是倒计时开始并达到了超时?
因为如果是后者，那么我不会选择无限，因为这将是由服务器不发送数据而不是我的应用程序引起的。
我正在下载一个大文件(大约100mb)，我收到SocketException: Read超时每隔一段时间。
所以你的读超时时间太短，或者对端响应不够满足你的需求。
我正在考虑提高套接字超时
从什么?
实际上，我正在考虑将套接字超时设置为0(无限)，因为最终我的应用程序将下载的文件大小甚至可能大于300mb，甚至大于300mb。这是一个好的实践吗?
读取超时与下载大小无关。它与请求的预期服务时间有关。我通常建议将其设置为预期服务时间的两倍。毕竟，读超时的目的是告诉您对等端什么时候没有响应。
关于套接字超时，超时倒计时实际何时开始?
当你进入read方法时。
我的意思是，当套接字超时发生时，是否意味着连接仍然活跃
是的。
文件仍在持续下载
。在超时时间内没有数据到达。
但只是超时，因为套接字超时配置?
读取超时，原因是:(a)您设置了读取超时，(b)超时。别想太多了。
或者当它认为连接仍然存在但服务器没有发送数据时开始倒计时;于是倒计时开始并达到了超时?
见上图。
因为如果是后者，那么我不会选择无限，因为它将由服务器不向我发送数据而不是由我的应用程序引起。
读取超时是由于数据没有在接收应用程序配置的超时时间内到达而导致的。超时时间可能太短，这是应用程序的错误，也可能是因为对等端没有发送任何内容，这是对等端的错误，或者两者兼而有之。不可能先验地决定