โดยทั่วไปแล้ว การแคชช่วยปรับปรุงประสิทธิภาพได้โดยการจัดเก็บข้อมูลเพื่อให้แสดงคำขอข้อมูลเดียวกันในอนาคตได้เร็วขึ้น ตัวอย่างเช่น ทรัพยากรที่แคชไว้จากเครือข่าย สามารถหลีกเลี่ยงการรับส่งข้อมูลไปยังเซิร์ฟเวอร์ได้ ผลลัพธ์การคำนวณที่แคชไว้ อาจข้ามเวลาที่ใช้ในการคำนวณแบบเดิมได้
ใน Chrome มีการใช้กลไกแคชในหลายรูปแบบและเซิร์ฟเวอร์แคช HTTP ก็เป็นตัวอย่างหนึ่ง
วิธีการทำงานของแคช HTTP ของ Chrome ในปัจจุบัน
ตั้งแต่เวอร์ชัน 85 เป็นต้นไป Chrome จะแคชทรัพยากรที่ดึงจากเครือข่าย โดยใช้ URL ทรัพยากรที่เกี่ยวข้องเป็นคีย์แคช (คีย์แคชใช้เพื่อระบุทรัพยากรที่แคชไว้)
ตัวอย่างต่อไปนี้แสดงวิธีแคชและจัดการรูปภาพ 1 รูปในบริบทที่แตกต่างกัน 3 แบบ
ผู้ใช้เข้าชมหน้าเว็บ (https://a.example
) ที่ขอรูปภาพ (https://x.example/doge.png
) เครือข่ายขอรูปภาพและแคชโดยใช้ https://x.example/doge.png
เป็นคีย์
ผู้ใช้คนเดียวกันนี้เข้าชมหน้าอื่น (https://b.example
) ซึ่งส่งคำขอรูปภาพเดียวกัน (https://x.example/doge.png
)
เบราว์เซอร์จะตรวจสอบแคช HTTP ของเบราว์เซอร์ว่าได้แคชแหล่งข้อมูลนี้อยู่แล้วหรือไม่ โดยใช้ URL รูปภาพเป็นคีย์ เบราว์เซอร์พบข้อมูลที่ตรงกันในแคช ดังนั้นจึงใช้ทรัพยากรเวอร์ชันที่แคชไว้
และไม่สำคัญว่ารูปภาพจะโหลดจากใน iframe หรือไม่ หากผู้ใช้เข้าชมเว็บไซต์อื่น (https://c.example
) ด้วย iframe
(https://d.example
) และ iframe ขอรูปภาพเดียวกัน
(https://x.example/doge.png
) เบราว์เซอร์จะยังคงโหลดรูปภาพจากแคชได้เนื่องจากคีย์แคชเหมือนกันในทุกหน้า
กลไกนี้ทำงานได้ดีในแง่ของประสิทธิภาพมาเป็นเวลานาน อย่างไรก็ตาม เวลาที่เว็บไซต์ใช้ในการตอบสนองต่อคำขอ HTTP สามารถเปิดเผยว่าเบราว์เซอร์ได้เข้าถึงทรัพยากรเดียวกันในอดีต ซึ่งเปิดเบราว์เซอร์เพื่อโจมตีความปลอดภัยและความเป็นส่วนตัว ดังตัวอย่างต่อไปนี้
- ตรวจหาว่าผู้ใช้ได้เข้าชมเว็บไซต์หนึ่งๆ หรือไม่: ฝ่ายตรงข้ามสามารถตรวจหาประวัติการท่องเว็บของผู้ใช้ได้โดยตรวจสอบว่าแคชมีทรัพยากรซึ่งอาจเจาะจงสำหรับเว็บไซต์ใดเว็บไซต์หนึ่งหรือกลุ่มประชากรตามรุ่นของเว็บไซต์หนึ่งๆ หรือไม่
- การโจมตีการค้นหาข้ามเว็บไซต์: ฝ่ายตรงข้ามจะตรวจจับได้ว่ามีสตริงที่กําหนดเองแสดงในผลการค้นหาของผู้ใช้หรือไม่ โดยตรวจสอบว่ารูปภาพ "ไม่มีผลการค้นหา" ที่ใช้โดยเว็บไซต์ใดเว็บไซต์หนึ่งอยู่ในแคชของเบราว์เซอร์หรือไม่
- การติดตามข้ามเว็บไซต์: แคชสามารถใช้เพื่อจัดเก็บตัวระบุที่เหมือนคุกกี้เป็นกลไกการติดตามข้ามเว็บไซต์
Chrome จะแบ่งพาร์ติชันแคช HTTP โดยเริ่มตั้งแต่ Chrome 86 เป็นต้นไปเพื่อลดความเสี่ยงเหล่านี้
การแบ่งพาร์ติชันแคชจะส่งผลต่อแคช HTTP ของ Chrome อย่างไร
เมื่อใช้การแบ่งพาร์ติชันแคช ระบบจะคีย์ทรัพยากรที่แคชไว้โดยใช้ "คีย์การแยกเครือข่าย" ใหม่นอกเหนือจาก URL ทรัพยากร คีย์การแยกเครือข่ายประกอบด้วยเว็บไซต์ระดับบนสุดและเว็บไซต์เฟรมปัจจุบัน
ดูตัวอย่างก่อนหน้านี้อีกครั้งเพื่อดูว่าการแบ่งพาร์ติชันแคชทำงานอย่างไรในบริบทต่างๆ
ผู้ใช้เข้าชมหน้าเว็บ (https://a.example
) ที่ขอรูปภาพ (https://x.example/doge.png
) ในกรณีนี้ ระบบจะขอรูปภาพจากเครือข่ายและแคชโดยใช้ Tuple ที่ประกอบด้วย https://a.example
(เว็บไซต์ระดับบนสุด), https://a.example
(เว็บไซต์เฟรมปัจจุบัน) และ https://x.example/doge.png
(URL ทรัพยากร) เป็นคีย์ (โปรดทราบว่าเมื่อคำขอทรัพยากรมาจากเฟรมระดับบนสุด เว็บไซต์ระดับบนสุดและเว็บไซต์เฟรมปัจจุบันในคีย์การแยกเครือข่ายจะเหมือนกัน)
ผู้ใช้รายเดียวกันเข้าชมหน้าอื่น (https://b.example
) ซึ่งขอรูปภาพเดียวกัน (https://x.example/doge.png
) แม้ว่าในตัวอย่างก่อนหน้านี้จะโหลดรูปภาพเดียวกัน เนื่องจากคีย์ไม่ตรงกันจึงไม่ใช่การพบแคช
มีการขออิมเมจจากเครือข่ายและแคชโดยใช้ Tuple ที่ประกอบด้วย https://b.example
, https://b.example
และ https://x.example/doge.png
เป็นคีย์
ตอนนี้ผู้ใช้กลับมาที่ https://a.example
แต่คราวนี้รูปภาพ
(https://x.example/doge.png
) ฝังอยู่ใน iframe ในกรณีนี้ คีย์คือ Tuple ที่มี https://a.example
, https://a.example
และ https://x.example/doge.png
และเกิดการพบแคช (โปรดทราบว่าเมื่อเว็บไซต์ระดับบนสุดและ iframe เป็นเว็บไซต์เดียวกัน คุณจะใช้ทรัพยากรที่แคชกับเฟรมระดับบนสุดได้
ผู้ใช้กลับมาที่ https://a.example
แต่คราวนี้รูปภาพโฮสต์อยู่ใน iframe จาก https://c.example
ในกรณีนี้ ระบบจะดาวน์โหลดรูปภาพจากเครือข่ายเนื่องจากไม่มีทรัพยากรในแคชที่ตรงกับคีย์ที่ประกอบด้วย https://a.example
, https://c.example
และ https://x.example/doge.png
จะเกิดอะไรขึ้นหากโดเมนมีโดเมนย่อยหรือหมายเลขพอร์ต ผู้ใช้เข้าชม https://subdomain.a.example
ที่ฝัง iframe (https://c.example:8080
) ที่ขอรูปภาพ
เนื่องจากคีย์สร้างขึ้นโดยอิงตาม "scheme://eTLD+1" ระบบจึงไม่สนใจโดเมนย่อยและหมายเลขพอร์ต ดังนั้นจึงเกิดการพบแคช
จะเกิดอะไรขึ้นหาก iframe ซ้อนกันหลายครั้ง ผู้ใช้เข้าชม https://a.example
ซึ่งมี iframe (https://b.example
) ที่ฝัง iframe ไว้อีก (https://c.example
) ซึ่งส่งคำขอรูปภาพไปในที่สุด
เนื่องจากคีย์ดึงมาจากเฟรมบนสุด (https://a.example
) และเฟรมทันทีซึ่งโหลดทรัพยากร (https://c.example
) เกิดการพบแคช
คำถามที่พบบ่อย
มีการเปิดใช้งานใน Chrome ของฉันอยู่แล้วหรือไม่ ฉันจะตรวจสอบได้อย่างไร
ฟีเจอร์นี้จะเปิดตัวในช่วงปลายปี 2020 วิธีตรวจสอบว่าอินสแตนซ์ของ Chrome รองรับอยู่แล้วหรือไม่
- เปิด
chrome://net-export/
แล้วกดเริ่มต้นการบันทึกลงดิสก์ - ระบุตำแหน่งที่จะบันทึกไฟล์บันทึกในคอมพิวเตอร์ของคุณ
- ท่องเว็บใน Chrome เป็นเวลา 1 นาที
- กลับไปที่
chrome://net-export/
แล้วกดหยุดการบันทึก - ไปที่
https://netlog-viewer.appspot.com/#import
- กดเลือกไฟล์และส่งไฟล์บันทึกที่บันทึกไว้
คุณจะเห็นเอาต์พุตของไฟล์บันทึก
หา SplitCacheByNetworkIsolationKey
ในหน้าเดียวกัน หากตามด้วย Experiment_[****]
แสดงว่ามีการเปิดใช้การแบ่งพาร์ติชันแคช HTTP ใน Chrome หากเป็นไปตาม Control_[****]
หรือ Default_[****]
แสดงว่าไม่ได้เปิดใช้
ฉันจะทดสอบการแบ่งพาร์ติชันแคช HTTP ใน Chrome ได้อย่างไร
หากต้องการทดสอบการแบ่งพาร์ติชันแคช HTTP ใน Chrome คุณต้องเปิด Chrome ด้วยการแฟล็กบรรทัดคำสั่ง: --enable-features=SplitCacheByNetworkIsolationKey
ทำตามวิธีการเรียกใช้ Chromium ด้วยแฟล็กเพื่อดูวิธีเปิด Chrome ด้วยแฟล็กบรรทัดคำสั่งในแพลตฟอร์ม
ในฐานะนักพัฒนาเว็บ ฉันควรดำเนินการใดเพื่อตอบสนองต่อการเปลี่ยนแปลงนี้ไหม
การเปลี่ยนแปลงนี้ไม่ใช่การเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ แต่อาจมีการพิจารณาประสิทธิภาพสำหรับบริการเว็บบางรายการ
ตัวอย่างเช่น เว็บไซต์ที่ให้บริการทรัพยากรจำนวนมากที่สร้างแคชได้ในเว็บไซต์จำนวนมาก (เช่น แบบอักษรและสคริปต์ยอดนิยม) อาจมีจำนวนการเข้าชมเพิ่มขึ้น นอกจากนี้ ผู้ที่ใช้บริการดังกล่าวอาจมีความเชื่อถือมากขึ้น
(มีการเสนอให้เปิดใช้ไลบรารีที่แชร์ในลักษณะที่รักษาความเป็นส่วนตัวซึ่งเรียกว่าไลบรารีที่ใช้ร่วมกันบนเว็บ (วิดีโองานนำเสนอ) แต่ยังอยู่ระหว่างการพิจารณา)
การเปลี่ยนแปลงทางพฤติกรรมนี้มีผลอย่างไร
อัตราการพลาดแคชโดยรวมเพิ่มขึ้นประมาณ 3.6% การเปลี่ยนแปลง FCP (First Contentful Paint) นั้นเล็กน้อย (ประมาณ 0.3%) และสัดส่วนโดยรวมของไบต์ที่โหลดจากเครือข่ายเพิ่มขึ้นประมาณ 4% ดูข้อมูลเพิ่มเติมเกี่ยวกับผลกระทบต่อประสิทธิภาพได้ในคำอธิบายการแบ่งพาร์ติชันแคช HTTP
การทำเช่นนี้เป็นมาตรฐานหรือไม่ เบราว์เซอร์อื่นๆ ทำงานต่างกันหรือไม่
"พาร์ติชันแคช HTTP" เป็นไปตามมาตรฐานในข้อกำหนดการดึงข้อมูล แต่เบราว์เซอร์จะทำงานต่างออกไป ดังนี้
- Chrome: ใช้รูปแบบระดับบนสุด://eTLD+1 และรูปแบบเฟรม://eTLD+1
- Safari: ใช้ eTLD+1 ระดับบนสุด
- Firefox: การวางแผนใช้งานด้วย Scheme ระดับบนสุด: Scheme://eTLD+1 และพิจารณารวมคีย์ที่ 2 เช่น Chrome
มีการดำเนินการกับการดึงข้อมูลจากผู้ปฏิบัติงานอย่างไร
ผู้ปฏิบัติงานโดยเฉพาะใช้คีย์เดียวกันกับเฟรมปัจจุบัน Service Worker และผู้ปฏิบัติงานที่แชร์จะมีความซับซ้อนมากกว่า เนื่องจากอาจมีการแชร์ระหว่างเว็บไซต์ระดับบนสุดหลายเว็บไซต์ โซลูชันสำหรับลูกค้าอยู่ระหว่างการหารือ