Consider a customer service desk:
A customer phones the customer service desk with a query. The customer service agent has no idea what the answer is and puts the customer on hold and phones the product support desk to ask a product specialist. The product specialist has no idea what the answer is and puts the customer service agent on hold and phones the technical support desk to ask a technician. The technician has no idea what the answer is and puts the product specialist on hold and gets the manual out.
The manual provides the answer to the technician in complex technical terms. The technician understands the complex technical terms and reconnects to the product support desk and tells the product specialist the answer in technical jargon. The product specialist understands the technical jargon and reconnects to the support desk and tells customer service agent the answer in product jargon. The customer service agent understands the product jargon and reconnects to the customer and tells the customer the answer in plain English. The customer is happy with the answer but not with the time it took waiting on the phone.
If each person in the chain started to keep notes (a cache of information) on the different requests and their answers, they would not always have to phone through or check the manual to get the answer. This speeds things up considerably. However, if the product development team changes the product, the answers that have been noted down might now be out of date.
And so it is with data caching. At each level the answer to a request can be stored to speed things up when the same request is made; but, there needs to be a mechanism to handle changes. When visiting, or working on, a WordPress site, data is cached at a number of levels to reduce the amount of data being sent across the network and to reduce repeated processing.
The cache that most of us are aware of is the browser cache on our own computer or laptop.
The browser cache is a temporary store of the pages that were downloaded by the browser to display websites we have visited. When you revisit the same page of a website, the browser sends a request to the web server. This request includes details of the relevant page it already has in its cache. The server uses this request to determine what if a new or changed page needs to be downloaded to the browser for it to display the requested website page.
The next level of caching is handled by the server infrastructure where the website is hosted. (There can be additional intermediate caching, for example, implemented on servers within an Internet Service Provider.)
The web server receives the request from the browser and determines what pages need to be downloaded. WordPress pages are always PHP files and the web server sends these to the PHP interpreter which will run any PHP scripts and return the requested web page. When you consider that PHP will often be running the same scripts to produce the same web pages, this is clearly not efficient.
So, between the web server and PHP is the HTTP cache. The HTTP cache is either a WordPress page caching plugin or a server component. The server cache can be either a HTTP cache module of the web server itself or an additional dedicated HTTP cache server like Varnish.
Generally speaking, the caching facility will check its cache to see if it has already responded to the request and if so return the appropriate page. If the request response has not been cached, the request is made to PHP and the response cached as well as returned to the web server. The difference between using a plugin and a dedicated cache server, is that the plugin uses PHP to check the cache whereas the dedicated cache server can return cached request responses without using PHP at all.
WordPress stores its data in a database and its PHP scripts make database queries to retrieve the data to process the request. To reduce the overhead of repeating database queries, WordPress stores the query result in its inbuilt object cache, an object that is created by WordPress. So when WordPress identifies the same query, it can get the result from the object cache without reference to the database.
There are some aspects of the WordPress object cache that need to be borne in mind. Core WordPress PHP makes use of the object cache by design whereas for plugins and themes to benefit they need to have be designed and developed to make use of the object cache through its API. Another aspect is that cached data is held in memory only for the current request and will not be stored persistently across page loads unless you install a persistent caching plugin.