หน้านี้ได้รับการแปลโดย Cloud Translation API

เพิ่มความปลอดภัยและความเป็นส่วนตัวด้วยการแบ่งพาร์ติชันแคช

Eiji Kitamura

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

ใน Chrome มีการใช้กลไกแคชในหลายวิธี และแคช HTTP ก็เป็นตัวอย่างหนึ่ง

วิธีการทํางานของแคช HTTP ของ Chrome ปัจจุบัน

ตั้งแต่เวอร์ชัน 85 เป็นต้นไป Chrome จะแคชทรัพยากรที่ดึงมาจากเครือข่ายโดยใช้ URL ของทรัพยากรที่เกี่ยวข้องเป็นคีย์แคช (คีย์แคชใช้เพื่อระบุทรัพยากรที่แคชไว้)

ตัวอย่างต่อไปนี้แสดงวิธีแคชและจัดการรูปภาพเดียวในบริบทที่แตกต่างกัน 3 รูปแบบ

คีย์แคช: https://x.example/doge.png — **คีย์แคช**: { `https://x.example/doge.png` }

ผู้ใช้เข้าชมหน้าเว็บ (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://a.example, https://x.example/doge.png} — **คีย์แคช**: { `https://a.example`, `https://a.example`, `https://x.example/doge.png` }

ผู้ใช้เข้าชมหน้าเว็บ (https://a.example) ซึ่งขอรูปภาพ (https://x.example/doge.png) ในกรณีนี้ ระบบจะขอรูปภาพจากเครือข่ายและแคชโดยใช้ทูเปิลที่มี https://a.example (เว็บไซต์ระดับบนสุด) https://a.example (เว็บไซต์เฟรมปัจจุบัน) และ https://x.example/doge.png (URL ของทรัพยากร) เป็นคีย์ (โปรดทราบว่าเมื่อคําขอทรัพยากรมาจากเฟรมระดับบนสุด เว็บไซต์ระดับบนสุดและเว็บไซต์เฟรมปัจจุบันในคีย์การแยกเครือข่ายจะเหมือนกัน)

ผู้ใช้รายเดียวกันเข้าชมหน้าอื่น (https://b.example) ซึ่งขอรูปภาพเดียวกัน (https://x.example/doge.png) แม้ว่าระบบจะโหลดรูปภาพเดียวกันในตัวอย่างก่อนหน้า แต่จะไม่ถือว่ามีการตีข้อมูลแคชเนื่องจากคีย์ไม่ตรงกัน

ระบบจะขอรูปภาพจากเครือข่ายและแคชโดยใช้ทูเปิลที่มี https://b.example, https://b.example และ https://x.example/doge.png เป็นคีย์

ตอนนี้ผู้ใช้กลับมาที่ https://a.example แต่ครั้งนี้รูปภาพ (https://x.example/doge.png) ฝังอยู่ใน iframe ในกรณีนี้ ตัวแปรคือทูเปิลที่มี 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" ระบบจะไม่สนใจโดเมนย่อยและหมายเลขพอร์ต จึงเกิด Hit แคช

จะเกิดอะไรขึ้นหากฝัง 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_[****] ต่อท้าย แสดงว่า Chrome เปิดใช้การแบ่งพาร์ติชันแคช HTTP อยู่ หากมี Control_[****] หรือ Default_[****] ตามหลัง แสดงว่าไม่ได้เปิดใช้

ฉันจะทดสอบการแบ่งพาร์ติชันแคช HTTP ใน Chrome ได้อย่างไร

หากต้องการทดสอบการแบ่งพาร์ติชันแคช HTTP ใน Chrome คุณต้องเปิด Chrome ด้วย Flag บรรทัดคำสั่ง --enable-features=SplitCacheByNetworkIsolationKey ทำตามวิธีการที่หัวข้อเรียกใช้ Chromium ด้วย Flag เพื่อดูวิธีเปิด Chrome ด้วย Flag บรรทัดคำสั่งในแพลตฟอร์มของคุณ

ในฐานะนักพัฒนาเว็บ ฉันควรดำเนินการใดๆ เพื่อตอบสนองต่อการเปลี่ยนแปลงนี้หรือไม่

การเปลี่ยนแปลงนี้ไม่ใช่การเปลี่ยนแปลงที่ส่งผลเสีย แต่อาจต้องพิจารณาประสิทธิภาพสำหรับเว็บเซอร์วิสบางรายการ

เช่น เว็บไซต์ที่ให้บริการทรัพยากรจำนวนมากซึ่งแคชได้สูงในเว็บไซต์ต่างๆ (เช่น แบบอักษรและสคริปต์ยอดนิยม) อาจมีการเข้าชมเพิ่มขึ้น นอกจากนี้ ผู้ใช้บริการดังกล่าวอาจพึ่งพาบริการดังกล่าวมากขึ้น

(มีแนวคิดที่จะเปิดใช้คลังที่ใช้ร่วมกันในลักษณะที่รักษาความเป็นส่วนตัว ซึ่งเรียกว่าคลังที่ใช้ร่วมกันบนเว็บ (วิดีโอนำเสนอ) แต่แนวคิดนี้ยังอยู่ระหว่างการพิจารณา)

การเปลี่ยนแปลงพฤติกรรมนี้ส่งผลต่ออะไรบ้าง

อัตราการไม่พบแคชโดยรวมเพิ่มขึ้นประมาณ 3.6% การเปลี่ยนแปลง FCP (First Contentful Paint) นั้นน้อยมาก (~0.3%) และเศษส่วนของไบต์โดยรวมที่โหลดจากเครือข่ายเพิ่มขึ้นประมาณ 4% ดูข้อมูลเพิ่มเติมเกี่ยวกับผลกระทบต่อประสิทธิภาพได้ในคำอธิบายการแบ่งพาร์ติชันแคช HTTP

ข้อมูลนี้เป็นไปตามมาตรฐานไหม เบราว์เซอร์อื่นๆ ทำงานต่างออกไปไหม

"พาร์ติชันแคช HTTP" ได้รับการกำหนดมาตรฐานไว้ในข้อกำหนดการดึงข้อมูล แม้ว่าเบราว์เซอร์จะทำงานแตกต่างกันไป

Chrome: ใช้รูปแบบระดับบนสุด://eTLD+1 และรูปแบบเฟรม://eTLD+1
Safari: ใช้ eTLD+1 ระดับบนสุด
Firefox: วางแผนที่จะติดตั้งใช้งานด้วยรูปแบบระดับบนสุด://eTLD+1 และพิจารณารวมคีย์ที่ 2 ไว้ด้วย เช่น Chrome

ระบบจะจัดการการดึงข้อมูลจากอุปกรณ์ทำงานอย่างไร

ผู้ปฏิบัติงานเฉพาะจะใช้คีย์เดียวกับเฟรมปัจจุบัน Service Worker และ Worker ที่แชร์มีความซับซ้อนกว่าเนื่องจากอาจแชร์กันระหว่างเว็บไซต์ระดับบนสุดหลายแห่ง ขณะนี้เรากำลังหาวิธีแก้ปัญหาอยู่