SearchHTTP is undeniable: obviously web browsers use HTTP to retrieve website data. HTTP is also a very dominant protocol for server-to-server communication, with HTTP-based APIs as the main driver.
Whereas in the past applications would use a custom protocol, HTTP is now the standard for client-server communication.
We used to say that TCP/IP powered the internet, but for the last decade, people are aiming higher in the network stack, and have made HTTP their protocol of choice.
As the internet changes, and as HTTP is used for a lot of new and challenging applications, HTTP is slowly adapting to these modern-day needs.
From a web performance point of view, HTTP already comes with quite a bit of syntax to control how responses can be cached.
Varnish, as all good caching citizens, will comply with these standards and best practices.
This chapter was all about HTTP, and how it can be leveraged for caching. Not just for the sake of it, but to illustrate how little customization is required in Varnish to gain control over your content delivery flow.
In the next chapter, we’ll talk about the Varnish Configuration Language, and how it can be used to customize the behavior of Varnish. But the most important lesson of this chapter is: the less VCL you have to write, the better. Because a lot of it is covered by HTTP already.
From the Cache-Control header, to cache variations, and even
streaming, compression, and conditional requests: HTTP already offers so
many valuable caching features.
But in most real-world scenarios, HTTP doesn’t have all the answers. And that’s where VCL comes into play. Get ready for chapter 4.