โดยทั่วไปแล้ว การแคชจะปรับปรุงประสิทธิภาพได้ด้วยการจัดเก็บข้อมูล ซึ่งจะทำให้ระบบแสดงคำขอข้อมูลเดียวกันในอนาคตได้เร็วขึ้น ตัวอย่างเช่น ทรัพยากรที่แคชไว้จากเครือข่ายจะหลีกเลี่ยงการเดินทางไปที่เซิร์ฟเวอร์ได้ ผลการคำนวณที่แคชไว้ทำให้ ไม่ต้องเสียเวลาในการคำนวณแบบเดียวกัน
ใน Chrome มีการใช้กลไกแคชในหลากหลายรูปแบบ และตัวอย่างแคช HTTP ก็เช่นกัน
วิธีการทำงานของแคช HTTP ของ Chrome ในปัจจุบัน
ตั้งแต่เวอร์ชัน 85 เป็นต้นไป Chrome จะแคชทรัพยากรที่ดึงมาจากเครือข่าย โดยใช้ URL ของทรัพยากรที่เกี่ยวข้องเป็นคีย์แคช (คีย์แคชใช้เพื่อระบุทรัพยากรที่แคชไว้)
ตัวอย่างต่อไปนี้แสดงให้เห็นวิธีที่ระบบแคชและดำเนินการกับรูปภาพเดียวในบริบทที่แตกต่างกัน 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
และเกิด Hit แคช (โปรดทราบว่าเมื่อเว็บไซต์ระดับบนสุดและ 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
) จึงเกิด Hit แคช
คำถามที่พบบ่อย
เปิดใช้ใน 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: วางแผนจะใช้งานด้วยโดเมนระดับบนสุด คือ://eTLD+1 และพิจารณาเพิ่มคีย์ที่ 2 เช่น Chrome
ระบบจะจัดการกับการดึงข้อมูลจากผู้ปฏิบัติงานอย่างไร
ผู้ปฏิบัติงานเฉพาะใช้คีย์เดียวกันกับเฟรมปัจจุบัน โปรแกรมทำงานของบริการและโปรแกรมทำงานที่ใช้ร่วมกันมีความซับซ้อนยิ่งขึ้น เนื่องจากอาจมีการแชร์กับไซต์ระดับบนสุดหลายไซต์ วิธีแก้ไขปัญหาสำหรับตัวแทนอยู่ระหว่างการหารือ