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