13/03/2024
Without shielding
To understand shielding, let’s look at this diagram. My main server is in Roubaix, France. My aim is to lighten the load on this server as much as possible.
Requests come from all over the world, handled by the nearest Fastly POPs. However, these POPs still need to reach my server to refresh the cache, creating inefficiency as every POP accesses my origin.
To improve this, we can place a cache server between the POPs and my origin. This server, acting as a shield, absorbs requests and delivers cached content, reducing the direct load on my origin server and improving efficiency.
With Shielding
The Paris POP acts as an additional caching layer. Since it’s closest to our origin, it will handle all the load from other POPs when they need to access my origin server.
Multiple shields
You can set up multiple shields if you have multiple origins. Just like before, keep your shields close to your origins for better efficiency.
Skipping the shield with PASS on the request
If « PASS » is called on the request, it skips the shields and goes directly to the origin.
Shielding adds another caching layer
Since the shield is essentially an extra POP, you gain benefits from POP features like clustering, which adds another layer of caching.
How to visualize your shield?
Run the following command
curl -I -H "Fastly-Debug: 1" https://www.antoinebrossault.com
Then observe the fastly-debug-path :
For that example I ran the command from a german IP
fastly-debug-path:
(D cache-fra-etou8220158-FRA 1740688295) (F cache-fra-etou8220129-FRA 1740688295)
(D cache-par-lfpb1150066-PAR 1740688295) (F cache-par-lfpb1150066-PAR 1740637340)
We read the values from left to right.
Here the edge pop ( the first one to process our request ) is cache-fra-etou8220158
and the shield is cache-par-lfpb1150066-PAR
Note: fra stands for Frankfurt and par stands for Paris.
We can also see the details of the machines used for the delivery (D) node and the fetching (F) node.
Edge pop (Frankfurt): 🇩🇪
(D cache-fra-etou8220158-FRA 1740688295) (F cache-fra-etou8220129-FRA 1740688295)
And our shield (Paris) : 🇫🇷
(D cache-par-lfpb1150066-PAR 1740688295) (F cache-par-lfpb1150066-PAR 1740637340)
How to interpret x-cache and x-served-by values?
curl -I -H "Fastly-Debug: 1" https://www.antoinebrossault.com
HTTP/2 200
server: Apache/2.4.62 (Debian)
...
x-served-by: cache-par-lfpg1960059-PAR, cache-fra-etou8220027-FRA
x-cache: HIT, HIT
Here we have to read from right to left
edge pop is : cache-fra-etou8220027-FRA ( Frankfurt 🇩🇪 )
shield pop is : cache-par-lfpg1960059-PAR( Paris 🇫🇷 )
How to read x-cache: HIT, HIT
Here, the first HIT (reading from right to left) is the edge POP that had the request in cache in Frankfurt 🇩🇪
and previously (not that request) when it was a MISS on the edge in Frankfurt 🇩🇪, that POP gotput in cache the resource from the shield
You can readme about this in the Fastly doc
An other example with a request in Australia
My site is shielded in Paris, and I decided to connect with a VPN that has an Australian IP address.
So the first time I access the page with my Australian IP the page was not in the cache in Sydney ( WSI ) 🇦🇺 we can see that with the curl command below
curl -I -H "Fastly-Debug: 1" https://www.antoinebrossault.com/blog/
HTTP/2 200
fastly-debug-path: (D cache-wsi-ysbk1060062-WSI 1753723606) (F cache-wsi-ysbk1060037-WSI 1753723606) (D cache-par-lfpg1960038-PAR 1753723606) (F cache-par-lfpg1960038-PAR 1752726591)
fastly-debug-ttl: (M cache-wsi-ysbk1060062-WSI - - 997015) (H cache-par-lfpg1960038-PAR 30538985.291 43200.000 997015)
fastly-debug-digest: faf4bdf346bfe0fe44a8db4ffd1e461422957e17f2a2cd45a8bd247ecc993474
x-served-by: cache-par-lfpg1960038-PAR, cache-wsi-ysbk1060062-WSI
x-cache: HIT, MISS
If we observe the values of x-served-by below, we can see we went to the Sydney POP (WSI) 🇦🇺 first, then to the shield in Paris (PAR) 🇫🇷
x-served-by: cache-par-lfpg1960038-PAR 🇫🇷 , cache-wsi-ysbk1060062-WSI 🇦🇺
Again we read from right to left :
If we observe the values of x-cache below, we can see the resource was not in the cache in the Sydney POP (WSI) 🇦🇺 first, but it was in the cache in the shield in Paris (PAR) 🇫🇷
x-cache: HIT 🇫🇷 , MISS 🇦🇺
Then the second time I access the page with my Australian IP
This time the page was in cache in the cache in Sydney ( WSI ) 🇦🇺 as we have a hit in the x-cache: HIT 🇫🇷, HIT 🇦🇺
curl -I -H "Fastly-Debug: 1" https://www.antoinebrossault.com/blog/
HTTP/2 200
fastly-debug-path: (D cache-wsi-ysbk1060051-WSI 1753723623) (F cache-wsi-ysbk1060037-WSI 1753723606) (D cache-par-lfpg1960038-PAR 1753723606) (F cache-par-lfpg1960038-PAR 1752726591)
fastly-debug-ttl: (H cache-wsi-ysbk1060051-WSI - - 997032) (H cache-par-lfpg1960038-PAR 30538985.291 43200.000 997015)
fastly-debug-digest: faf4bdf346bfe0fe44a8db4ffd1e461422957e17f2a2cd45a8bd247ecc993474
x-served-by: cache-par-lfpg1960038-PAR, cache-wsi-ysbk1060051-WSI
x-cache: HIT, HIT
Takeaways
• The free Shielding feature allows a single POP to act as an additional caching layer
between the user and the origin.
• Each backend configuration can have a different POP selected as it’s Shield POP.
• This allows different Shields to be configured, one per
