A timeout means that your client is not reading fast enough.
JMeter does not read response data fast enough, so the connection is idle long enough to be idle and disconnected.
We regularly test files of 800 MB and 2 GB in size.
When using the HTTP / 1.0, HTTP / 1.1 and HTTP / 2 protocols.
Use of regular (unencrypted) connections and secure TLS connections.
With answers transmitted with as many transfer code encodings and Content-Encodings as we can think (compressed, gzip, chunked, ranged, etc.).
We conduct all these tests using our own test infrastructure, we often deploy many Amazon EC2 nodes to perform a load test, which can sufficiently verify server requirements (a typical test is 20 client nodes per 1 node server).
When testing large responses, you need to know the protocol (HTTP / 1.x vs HTTP / 2) and how the persistence behavior of this protocol can change the request / response delay. In the real world, you will not have many large requests after each other on the same persistent connection via HTTP / 1 (via HTTP / 2, several requests will be parallel and will be sent simultaneously).
Make sure you configure JMeter to use HTTP / 1.1 and not use persistent connections. (see the JMeter documentation for help on this)
Also remember your bandwidth for your testing, it is very common to blame the server (any server) for not working fast enough when the test itself is sloppy and has expectations that far exceed the bandwidth of the network itself.
Next, do not test on the same computer, for this load test you will need several machines (1 for the server and 4+ for the client).
Finally, during load testing, you will want to know in detail about your network configurations on your server (and, to a lesser extent, client test machines) to maximize network configuration for high load. OS default configurations are rarely sufficient for proper load testing.