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

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

Eiji Kitamura

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

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

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

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

ตัวอย่างต่อไปนี้แสดงวิธีแคชและจัดการรูปภาพ 1 รูปในบริบทที่แตกต่างกัน 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) ในกรณีนี้ ระบบจะขอรูปภาพจากเครือข่ายและแคชโดยใช้ 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 และผู้ปฏิบัติงานที่แชร์จะมีความซับซ้อนมากกว่า เนื่องจากอาจมีการแชร์ระหว่างเว็บไซต์ระดับบนสุดหลายเว็บไซต์ โซลูชันสำหรับลูกค้าอยู่ระหว่างการหารือ