If all your ISP does is to drop your Internet connection, your downloads will be slightly delayed but not interrupted. This resilience is built into the TCP protocol. However, there's a chance that your ISP is doing more. If it is being naughty and sending RST packets on your behalf, or if it forces you to go through a transparent HTTP proxy, or if the disconnection causes your IP address to change, then your downloads will be aborted and there's nothing you can do about that.
You can resume an HTTP(S) download where it left off, but this requires support from the server. Some do, some don't; the only way to see is to try.
The two basic command line tools for downloading files (often preinstalled, but if not available in your distribution's package repository) support resuming downloads:
With wget, add the -c (--continue) option. This has no effect if there is no local file yet; if there is a local file, wget assumes that it's a partial download and attempts to resume where it left off.
You may want to use the --content-disposition option to use the server-specified name for the file. You may also want to specify a different user agent string to avoid ill-advised “protections” on the server.
wget --user-agent=Mozilla --content-disposition -c http://download.example.com/foo.zip
With curl, add -C - (--continue-at -) to the command line get the same effect as wget's -c option.
curl --user-agent=Mozilla --remote-header-name -C - http://download.example.com/foo.zip
Both wget and curl can retry downloads if they get interrupted. Whether this is effective depends on how long you remain disconnected. See --tries and --waitretry options for wget, and the --retry and --retry-delay options for curl.
Some GUI download managers support resuming downloads; I think the major browsers don't.
If the server doesn't support resuming, you're stuck without an external relay.
