The Internet does not use only one protocol. It doesn't even use only one protocol at time: it actually uses several at once, which stack up on top of each other to do all sorts of different things. If we oversimplify things a little, you could say that it uses four.
- Link Layer: A protocol that lets you push a signal down a wire (or radio waves, or flashes of light, or whatever) to another machine on the other end. Examples include PPP, WiFi, and Ethernet.
- Network Layer: A protocol that lets you push a signal through a chain of machines, so that you can get data between machines that aren't directly connected. This is where IP and IPv6 live.
- Transport Layer: A protocol that lets you make some basic sense out of that signal. Some, like TCP, establish "virtual connections" between two machines, as though there were a wire straight between them. Others, like UDP, just blast bits of data out from one machine to another. Different protocols have different strengths and weaknesses, which is part of why there are so many.
- Application Layer: These are what we typically think of as "protocols". They're specialized for certain types of data, meant for specific purposes. Some examples include FTP, HTTP, and BitTorrent, which all transfer files.
Those file transfer protocols I mentioned are typically stacked on top of TCP (which is itself stacked on top of IP), which is where we get to your particular question. TCP tries, as best it can, to work like a wire straight between the machines would: when the server sends a packet, it can be sure the client got it, and it can be sure the client got its packets in the same order that the server sent them. Part of the way it does this is that every packet the server sends has to be acknowledged by the client: it sends a small signal back saying "OK, I got that packet you sent; I'm ready for the next one." If the server doesn't get that acknowledgment, it keeps sending packets until it does (or decides that this is never going to work and gives up).
This is the key to answering your question. The server can't send Packet 2 until it knows that Packet 1 got through, which can't happen until Packet 1 gets acknowledged, and that can't happen until Packet 1 is really finished. The servers in the middle of the chain don't have to cache any data (no more than one packet at a time, anyway) because by the time a machine even sees Packet 2, it knows that it doesn't need Packet 1 anymore.
One last point: technically, this only means that the Internet doesn't have to cache data the way you're talking about. If someone really wanted to cache all of this data, they could; there's nothing in the protocols to really stop it from happening. But the Internet doesn't need these caches in order to work.
2What you describe does not happen. The client makes a direct connection to the file server and downloads at 1 mbps. – Ramhound – 2014-02-06T19:55:39.333
@Ramhound How does this work? Do you have any external articles on it? How can the server know that it should output packets at 1 mbps? What happens if it doesn't limit to that speed? – Friend of Kim – 2014-02-06T19:57:44.853
Explaining how a web server works is outside the scope of your question. You asked if what you described is how it works, its not, the client's ISP never caches the file. What do you mean by "What happens if it doesn't limit to that speed?" what is it exactly? – Ramhound – 2014-02-06T19:59:34.997
@Ramhound What happens if the server doesn't limit the output to the network to 1 mbps? – Friend of Kim – 2014-02-06T20:02:01.670
If a file is split up into 1 billion packets, and each packet has got a destination IP, wouldn't that allow the server to send away all packets at 1 gbps to to its access point? – Friend of Kim – 2014-02-06T20:04:02.523
1
See http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Flow_control
– jjlin – 2014-02-06T20:06:20.357So the data is actually cached. Each node on the internet specifies how much it is willing to cache, and tells the server. – Friend of Kim – 2014-02-06T20:09:25.880
4No, the sender has to wait for the receiver to read data before it can send more data. There is a little buffering, but no caching (which is saving for later re-use). The sender will probably not even read most of the 100 GB from disk at any greater rate than the receiver consumes it. – mgkrebbs – 2014-02-06T20:36:51.013
The nodes as somebody points out and I said originally does not cache your content. Your request data and it's sent when your done with that content more sat is sent. – Ramhound – 2014-02-06T22:07:59.567
Read this: http://www.amazon.com/TCP-Illustrated-Volume-Addison-Wesley-Professional/dp/0321336313
– joeqwerty – 2014-02-07T02:31:17.280If a server uses a custom protocol that doesn't wait for a response. Would the ISP just discard the packages as they build up because of the slow connection to the client? – Friend of Kim – 2014-02-07T15:27:17.757