Not really sure of your exact situation, if your network is really flaky you really need to fix that.... and if your trying to do streaming over a WAN, you might be better off doing log shipping instead.
But what we do here with one live and one hot-standby via streaming is
synchronous_commit = off
(Alongside of the synchronous_standby_names = '*', In addition to log_shipping
What this does is allow the client to get a success before transaction is flushed to disk, and flushed to the standby server.
This does not create a case where in a crash you have corrupted data, but you may miss the last few transactions on a restore. But, at least, local recovery can be 'set right... from the docs:
"However, the special value local is available for transactions that wish to wait for local flush to disk, but not synchronous replication."
That means Postgres will flush to disk before returning to the client, but the streaming replication will be async.
Check out synchronous_commit in:
