Web Cache หรือ HTTP Caching Headers คืออะไร

หงุดหงิด! เว็บช้า? เมื่อผู้ใช้รู้สึกหงุดหงิดเมื่อเว็บไซต์ทำงานช้า และนี่ก็เป็นจุดกำหนดนิยามคำว่า Caching เพื่อเพิ่มประสิทธิภาพให้กับเว็บเซิร์ฟเวอร์ มาทำความเข้าใจเรื่องของ Caching กันครับ

โพสนี้ว่าด้วยเรื่อง…เวทมนตร์ Web Cache หรือ HTTP Caching Headers

ไม่พล่ามทำเพลง ไม่สาทะยาย บอกข้อดีเลยล่ะกันครับ 55++

  • Performance / Reduced latency – เพิ่มประสิทธิภาพ, ตอบสนองเร็ว หล้าย ๆ กับทัก inbox แล้ว reply กลับทันทีด้วย AI bot
  • Cust down the bandwidth – แบนด์วิดท์เหลือ ๆ เพราะไม่ได้ใช้แบนด์วิดท์เซิร์ฟเวอร์
  • Reduced load on the serer – ลดการไปโหลดเซิร์ฟเวอร์ ปล่อยให้เซิร์ฟเวอร์ว่างรับงานใหม่ ๆ มาทำ
image credit: hostarmada

การแคช (Caching) คืออะไร?

วิธีการใดวิธีการหนึ่งที่ว่าด้วยเรื่อง “ปรับจูนประสิทธิภาพ” ด้วยวิธีการแคชระดับเซิร์ฟเวอร์ หรือระดับแอปพลิเคชัน เช่น ใช้ Redis หรือ Memcached และฝั่งไคลเอ็นต์ เพื่อเพิ่มประสิทธิภาพให้กับเว็บ

การแคช (Caching) คอนเทนต์มันเก็บที่ไหนบ้าง?

  • Browser Cache แคชส่วนตัวของผู้ใช้ที่เก็บบนเบราว์เซอร์
  • Proxy Cache พร็อกซี่แคช เช่น ISP Proxy Server, หรือขยับมาใกล้ตัวเราหน่อยก็ Squid Proxy Server ในองค์กร (เวลาเข้าถึงอินเทอร์เน็ตทราฟฟิกต้องวิ่งผ่านเครื่องนี้ก่อนส่งต่อไปยัง Gateway)
  • Reverse Proxy ระบบแคชที่กั้นอยู่ข้างหน้าเซิร์ฟเวอร์ แอปพลิเคชันที่ได้รับความนิยมก็เช่น NGINX
    หรืออาจจะเป็นแคชแบบสาธารณะ เช่น Public DNS / Public Proxy หรือ Cloudflare ฯลฯ

ดังนั้นภาพรวมที่ได้ก็เป็นประมาณนี้

Brower -> Proxy Server -> Reverse Proxy Server -> Server

image credit: twitter.com/kamranahmedse

แล้ว Caching ทำงานยังไง?

ระบบ Caching ตัวกลางที่อยู่ระหว่าง Client (เบราว์เซอร์) -> Caching -> Server
เมื่อมี request คำร้องขอทรัพยากร (ไฟล์คอนเทนต์) จากไคล์เอ็นต์มันจะถูกตรวจสอบในแคชเซิร์ฟเวอร์ก่อน หากไม่พบคอนเทนต์ที่ต้องการในแคช (Caching) คำร้องขอ (requests) จะถูกส่งไปยังเว็บเซิร์ฟเวอร์ การตอบกลับจากเซิร์ฟเวอร์จะถูกส่งมาเก็บที่แคชก่อน แล้วส่งทรัพยากรหรือไฟล์คอนเทนต์นั้นกลับไปให้ไคล์เอ็นต์ (HTTP Headers)

และครั้งถัดไปเมื่อมีไคล์เอ็นต์อื่นๆ request ขอทรัพยากรเดียวกันนี้ เซิร์ฟเวอร์แคชจะตอบกลับส่งข้อมูลให้ทันที (Reduced latency) โดยที่ไม่ต้องส่งคำขอไปยังเว็บเซิร์ฟเวอร์ครับ ยังทำให้ประหยัดแบนด์วิดท์เว็บเซิร์ฟเวอร์และลดภาระงาน เนื่องจาก requests ทั้งหมดไม่ได้ถูกส่งไปยังเซิร์ฟเวอร์ครับ

โพสต์นี้ไม่ลงลึกถึงวิธีการควบคุมแคชนะครับ (HTTP Headers) เช่น กำหนดค่าวันหมดอายุของคอนเทนต์ที่เก็บบน Cache และกาตรวจสอบคอนเทนต์เก่า/ใหม่ ของเนื้อหาที่ยังคงใช้งานได้ (Cache Validation) และ Cache Invalidation หรือการเคลียรแคชบน Caching (การลบเนื้อหาที่ไม่มีการอัปเดต)

ตัวอย่าง HTTP Headers ส่วนหัวที่ส่งไปในไฟล์

จากรูปข้างบนอธิบายเพิ่มเติมเกี่ยวกับการควบคุมแคช
expires: คือวันหนดอายุของเนื้อหานี้บนแคช
etag: ค่าที่ถูกกำหนดเอาไว้ตรวจสอบความถูกต้องของเนื้อหากับเซิร์ฟเวอร์
age: ค่าอายุของเนื้อหานี้ที่เก็บบนแคช
cache-control: ค่าที่ถูกระบุสำหรับควบคุมพฤติกรรมการแคชเนื้อหาไฟล์นี้
max-age=3600 (หน่วยเป็นวินาที)
no-cache คือไม่มีแคช
public สาธารณะ
(ส่วนนี้จะมีออปชันเช่น private หมายความว่าสามารถเก็บแคชเนื้อหาได้แค่ browser ของไคลเอ็นต์เท่านั้น, public คือเก็บแคชไว้ได้ที่สาธารณะทุกแห่ง เช่น Proxy cache, Reverse Proxy และ no-cache)

cache-control: max-age=3600, no-cache, public

คือเนื้อหานี้ไคลเอ็นต์จะเก็บแคชเอาไว้ได้สูงสุด 60 นาที และเนื้อหานี้ถูกเก็บเป็นแบบสาธารณะ เช่น ระบบเซิร์ฟเวอร์บน Cloudflare เป็นต้น และเมื่อ cache expired เนื้อหาหมดอายุ เนื้อหาใหม่จากเซิร์ฟเวอร์ (Origin Server) จะถูกโหลดมาเก็บที่ Caching แทนของเก่า.

etag: abcxyz

คือเมื่อครบเวลา 60 นาที ไคล์เอ็นต์จะส่ง request ไปถามเซิร์ฟเวอร์เพื่อตรวจสอบเนื้อหาว่ายังใช้งานได้ไหม (หรือเนื้อหานี้ถูกลบไปแล้วบนเซิร์ฟเวอร์ เป็นต้น) ซึ่งหากค่า etag ไม่ตรงกับเซิร์ฟเวอร์
เซิร์ฟเวอร์จะตอบกลับค่าใหม่ etag และเนื้อหาใหม่กลับไปยังไคล์เอ็นต์

หากยกตัวอย่าง etag ให้เห็นภาพก็ เช่น ไฟล์รูปภาพ ที่มีการอัปเดตใหม่บนเซิร์ฟเวอร์ ค่า etag ก็จะเปลี่ยนไปครับ

การกำหนดค่าแคชที่ดีควรเป็นอย่างไร?

คำตอบคือ อาจไม่มีคำตอบสำหรับเรื่องนี้ครับ
เพราะว่ามันขึ้นอยู่กับลักษณะและการทำงานของแอปพลิเคชันของคุณครับ ตัวอย่าง เช่น การแคช ไฟล์ html, CSS, JavaScript และ images

การทำ Caching ซึ่งเป็นแนวทางปฏิบัติสำหรับปรับจูนประสิทธิภาพให้กับเว็บ/แอปพลิเคชันนั้นเองครับ

source: Redis และ Memcached มันดียังไง?
[1] RFC on HTTP Caching: https://tools.ietf.org/html/rfc7234
[2] RFC on HTTP Conditional Requests: https://tools.ietf.org/html/rfc7232


Scroll to top