I think download rates may depend on these 3 factors: the Network Infrastructure (router, VPN, network card, towers), the RAM or cache, the Final Storage (HDD or SDD or whatnot).

So we take this as an example: I have a very slow HDD Drive and very slow RAM but a very fast network adapter & router.

When downloading, for example, a Linux Live ISO, the adapter will download it fast but yet all content that is downloaded is not written to disk immediately.

So my plausible solutions would be:

  1. The Internet Stack (TCP/IP or whatever) allow clients to defer receiving network packets. So that a client could say to aserver directly: Yo, I'm still struggling with the data I received, would you mind sending me the next data after (when I tell you to do so).
  2. A software library pauses receiving data when struggling.
  3. Data is stored somewhere else (other than cache or RAM) (maybe on the router?)

Is there a one real answer or it depends?

4 Answers 4


tl;dr Network-agents can interact according to certain protocols that specify how they're expected to behave. Protocols like TCP try to ensure reliable-messaging, so they require senders to await acknowledgement before sending more. By contrast, protocols like UDP simply don't guarantee that all messages will be delivered.

Depends on the protocol.

With TCP:

  1. Connections are established with formal agreements. A network card struggling with too many connections should refuse to take on additional connections.

  2. Each connection is allocated a set amount of memory (buffer) for storing messages.

  3. The protocol ensures that the buffer isn't overloaded by expecting the sender to await acknowledgement of prior messages being processed before sending more.

With UDP:

  1. There aren't formal connections specified by the protocol. Messages are just thrown together in the same piles, according to the port-number they're received on.

  2. There aren't many guarantees as to how much can be stored. If too many messages are received, the extra are just lost. Or maybe the old ones are lost. Or maybe the network-controller will just get frustrated, say "Screw it!", and lose both the old-messages and new-messages. UDP is explicitly unreliable (though it is expected to make a best-effort attempt).

  • 1
    this explains why UDP is used for streaming, as the order of the data received is not important
    – vixalien
    Feb 28, 2021 at 19:10
  • 2
    @vixalien more like because latency is important. TCP hides unreliability by adding latency - if you'd rather have unreliability instead of latency, use UDP Mar 1, 2021 at 11:36

There would have to be quite a discrepancy in the age of the respective components, for a network adapter (and connected infrastructure) to exceed the performance of system RAM, so the premises of this scenario are somewhat contrived.

Nevertheless, under TCP the receiver requests data in chunks, the completion of which must be acknowledged before the sender attempts to send more. The size of the chunks are determined by the receiver. If the receiving machine bogs down for any reason, the acknowledgement back to the sender will be delayed, which will delay the transmission of any further data. So it is not so much that the receiver goes "Yo, I'm struggling", it simply doesn't say "Yo, I'm ready for more", until it is in fact ready for more.

So you can see that the need to store appreciable amounts of data, other than in the "final storage", does not arise. The transmission is simply conducted at the overall pace of the final storage (or whatever other element is the slowest in the system).


"Networks" and "Disks" ("mass storage") have zero relation to each other. If you are, say, "downloading [an ISO ...]," then there is a program that is actually doing the work. This program is using a network-connection as the source of its data, and it is actively communicating with the remote host so that, between the two of them, they are successfully transferring blocks of data. The local program is then writing successive blocks of the received data to a growing disk file.

This is program-to-program communication, using the network stack as an interface. As the local program proceeds through its communication with its remote counterpart, it periodically writes data to a disk file which it has opened.


This happens at the application layer in the OSI stack so It’s stored wherever the application decides to store it. Typically system memory.

Sure your network card has a receive buffer but that’s tiny (think kilobytes) compared to what the app may buffer before writing to disk. Disks are slow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.