เทคโนโลยีเว็บทดลองใหม่ที่เรียกว่า Compression Dictionary Transport กำลังสร้างการถกเถียงอย่างเข้มข้นในหมู่นักพัฒนา โดยหลายคนตั้งคำถามว่าความซับซ้อนของมันคุ้มค่ากับการประหยัด bandwidth ที่สัญญาไว้หรือไม่ เทคโนโลยีนี้ช่วยให้เว็บไซต์สามารถใช้ compression dictionaries ที่แชร์กันเพื่อลดขนาดของ HTTP response อย่างมาก แต่ข้อเสนอแนะจากชุมชนแสดงให้เห็นว่าประโยชน์ในโลกแห่งความเป็นจริงอาจจะไม่น่าประทับใจเท่าที่โฆษณาไว้
ตัวเลขที่น่าประทับใจซ่อนผลกระทบเล็กน้อยในโลกจริง
แม้ว่าตัวอย่างการโปรโมทจะแสดงการปรับปรุงการบีบอัดอย่างมาก เช่น การลดขนาดไฟล์ JavaScript ลง 98% แต่นักพัฒนาชี้ให้เห็นว่าผลประโยชน์เหล่านี้มักจะแปลเป็นการประหยัดโดยรวมเพียงเล็กน้อย นักวิจารณ์คนหนึ่งวิเคราะห์ตัวอย่าง CNN ที่ไฟล์ JavaScript ขนาด 278KB ถูกบีบอัดจาก 90KB (ด้วย Brotli มาตรฐาน) ลงเหลือเพียง 2KB โดยใช้ dictionary compression แม้ว่านี่จะแสดงถึงการปรับปรุง 98% แต่ bandwidth ที่ประหยัดได้จริงคือเพียง 88KB จากการโหลดหน้าเว็บทั้งหมดของ CNN ที่ 63.7MB ซึ่งน้อยกว่า 0.14% ของข้อมูลทั้งหมดที่ถ่ายโอน
ความแตกต่างระหว่างการปรับปรุงเป็นเปอร์เซ็นต์และประโยชน์ในทางปฏิบัตินี้ได้จุดประกายการอพิปรายว่าเทคโนโลยีนี้แก้ไขปัญหาที่ถูกต้องหรือไม่ แทนที่จะเปิดใช้งานการบีบอัดที่มีประสิทธิภาพมากขึ้น นักพัฒนาบางคนกังวลว่ามันอาจจะเพียงแค่กระตุ้นให้เว็บไซต์ย้ายความ bloat จากการถ่ายโอนเครือข่ายไปยัง hard drive ของผู้ใช้ผ่านการจัดเก็บ dictionary
ตัวอย่างประสิทธิภาพการบีบอัด:
- JavaScript ของ CNN: 278KB → 90KB (Brotli) → 2KB (Dictionary + Brotli) = ปรับปรุงได้ 98%
- แบนด์วิดท์ที่ประหยัดได้จริง: 88KB จากการโหลดหน้าเว็บทั้งหมด 63.7MB (0.14%)
- ขนาด Dictionary ที่กล่าวถึง: สูงสุด 1MB ต่อ dictionary
ความซับซ้อนในการใช้งานทำให้เกิดความกังวล
เทคโนโลยีนี้นำความซับซ้อนมากมายมาสู่ทั้งเซิร์ฟเวอร์และไคลเอนต์ เซิร์ฟเวอร์ต้องจัดการ resource หลายเวอร์ชันที่บีบอัดโดยใช้ dictionary combinations ที่แตกต่างกัน ซึ่งอาจเพิ่มความต้องการพื้นที่จัดเก็บขึ้น 10 เท่าหรือมากกว่า พวกเขาต้อง cache ไม่เพียงแค่ static resource ปัจจุบันเท่านั้น แต่ยังรวมถึงเวอร์ชันในอดีตและ dictionary-compressed combinations ต่างๆ
ดูเหมือนว่าจะมีความซับซ้อนเพิ่มขึ้นมากสำหรับผลประโยชน์ที่จำกัด มีกรณีไหนที่ gzip และ br ในระดับการบีบอัดสูงสุดไม่เพียงพอหรือไม่?
การใช้งานฝั่งไคลเอนต์เกี่ยวข้องกับ HTTP headers ใหม่ การจัดการ dictionary และกฎการแบ่ง cache เบราว์เซอร์ต้องดาวน์โหลดและจัดเก็บ dictionaries ในช่วงเวลาว่าง จากนั้นประสานงานการใช้งานในคำขอในอนาคตในขณะที่เคารพนโยบาย same-origin และข้อจำกัด CORS
วิธีการใช้งาน:
- ใช้ทรัพยากรที่มีอยู่เป็นพจนานุกรม: ใช้ header
Available-Dictionary
พร้อมกับการจับคู่รูปแบบ - พจนานุกรมแยกต่างหาก: ใช้
<link rel="compression-dictionary">
หรือ headerLink:
- ผลกระทบต่อการจัดเก็บข้อมูลของเซิร์ฟเวอร์: อาจเพิ่มขึ้นถึง 10 เท่าในการรวมทรัพยากรที่ถูกแคช
- การรองรับของเบราว์เซอร์: เป็นเทคโนโลยีทดลองที่มีการใช้งานจริงอย่างจำกัดในปัจจุบัน
ผลกระทบด้านความปลอดภัยและความเป็นส่วนตัว
ชุมชนได้ระบุความเสี่ยงที่อาจเกิดขึ้นหลายประการกับเทคโนโลยีใหม่นี้ การบีบอัดแบบ dictionary-based อาจเปิดใช้งาน steganography รูปแบบใหม่ ซึ่งผู้ร้ายอาจซ่อนข้อความที่แตกต่างกันโดยใช้ dictionaries ที่หลากหลายในขณะที่รักษากฎการบีบอัดเดิมไว้ สิ่งนี้เปิดโอกาสสำหรับการแจกจ่าย malware ผ่านไฟล์ dictionary ที่ดูเหมือนไม่มีอันตราย
ความกังวลด้านความเป็นส่วนตัวยังเกิดขึ้นจากศักยภาพการติดตามของเทคโนโลยี เนื่องจาก dictionaries ต้องถูกดาวน์โหลดและ cache พวกเขาอาจทำหน้าที่เป็น fingerprinting vector อีกตัวหนึ่งสำหรับการระบุตัวตนผู้ใช้ ซึ่งเป็นปัญหาโดยเฉพาะเมื่อเปิดใช้งานการป้องกันความเป็นส่วนตัว
ข้อกำหนดทางเทคนิค:
- นโยบาย same-origin: พจนานุกรมต้องมาจากแหล่งที่มาเดียวกันกับทรัพยากร
- ต้องปฏิบัติตาม CORS สำหรับทรัพยากรที่บีบอัดด้วยพจนานุกรมข้ามแหล่งที่มา
- การแบ่งพาร์ติชัน HTTP Cache: พจนานุกรมไม่สามารถแชร์ระหว่างแหล่งที่มาต่างกันได้
- HTTP headers ใหม่:
Available-Dictionary
,Dictionary-ID
,Use-As-Dictionary
- อัลกอริทึมที่รองรับ: Brotli (dbr) และ Zstandard (dzd)
กรณีการใช้งานที่จำกัดแสดงให้เห็นความหวัง
แม้จะมีการวิจารณ์ แต่นักพัฒนาบางคนเห็นคุณค่าในสถานการณ์เฉพาะ แอปพลิเคชันที่มี JavaScript bundles ที่อัปเดตบ่อยครั้งซึ่งเปลี่ยนแปลงทีละน้อยอาจได้รับประโยชน์อย่างมากจาก delta compression โดยใช้เวอร์ชันก่อนหน้าเป็น dictionaries API ที่มีการเชื่อมต่อแบบ chatty และ long-lived อาจเห็นการปรับปรุงที่มีความหมายเช่นกัน
บริการคลาวด์อย่าง Cloudflare ดูเหมือนจะอยู่ในตำแหน่งที่ดีในการใช้งานเทคโนโลยีนี้อย่างโปร่งใส โดยอาจวิเคราะห์การตอบสนองของเว็บไซต์ทั่วไปเพื่อสร้าง site-specific dictionaries ที่ปรับให้เหมาะสมโดยไม่ต้องการการกำหนดค่าด้วยตนเองจากนักพัฒนา
เทคโนโลยีนี้แสดงถึงวิวัฒนาการจากมาตรฐาน SDCH (Shared Dictionary Compression over HTTP) ที่ล้มเหลวซึ่งถูกยกเลิกในปี 2013 แต่ว่ามันจะสามารถเอาชนะข้อจำกัดในทางปฏิบัติที่รบกวนผู้มาก่อนหน้าได้หรือไม่ยังคงต้องรอดู ขณะที่เบราว์เซอร์เริ่มการใช้งานทดลอง การทดสอบในโลกจริงจะเป็นตัวกำหนดว่า Compression Dictionary Transport สามารถให้ประโยชน์ที่มีความหมายซึ่งสมเหตุสมผลกับความซับซ้อนของมันได้หรือไม่
อ้างอิง: Compression Dictionary Transport