The theory of client-side caching
When we say client-side caching, this isn't strictly referring to client as in web browser, but can also refer to a proxy anywhere in the transmission chain.
Anyway, without the cache-control headers, a page that is requested from a site run with TYPO3 is always transmitted in full. The caching of TYPO3 suppresses only the full rendering of the requested page by TYPO3 (saving a lot of database queries), but the content read from the cache is still sent to the client all the time.
If we enable caching by sending the needed cache-control headers, any proxy or the browser itself may cache the page locally. So when a page is requested and an existing cached copy is still valid (i.e. not too old), it is not transmitted from the server to the client at all. Obviously this will reduce network usage as well as the load on the server.
Cache-Control headers
To provide control over the caching of web pages, the HTTP/1.1 protocol defines a set of headers that can be sent back and forth between server and client. Those allow you to prohibit caching completely (as is needed for any page that is truly dynamic, such as search results or pages depending on your login).
Forcing revalidation
Since in some situations a client may need to actively circumvent a cache and fetch a fresh copy from the original server, HTTP/1.1 defines ways to do so. If a client sends specific headers (usually after reloading with Shift or Control pressed), any cache involved must not use a cached copy but check for a new one first.
