Compression Dictionary Transport เผชิญความสงสัยจากนักพัฒนาเกี่ยวกับความซับซ้อนและประโยชน์จริงที่จำกัด

เทคโนโลยีเว็บทดลองใหม่ที่เรียกว่า 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

วิธีการใช้งาน:

1. ใช้ทรัพยากรที่มีอยู่เป็นพจนานุกรม: ใช้ header Available-Dictionary พร้อมกับการจับคู่รูปแบบ
2. พจนานุกรมแยกต่างหาก: ใช้ <link rel="compression-dictionary"> หรือ header Link:
3. ผลกระทบต่อการจัดเก็บข้อมูลของเซิร์ฟเวอร์: อาจเพิ่มขึ้นถึง 10 เท่าในการรวมทรัพยากรที่ถูกแคช
4. การรองรับของเบราว์เซอร์: เป็นเทคโนโลยีทดลองที่มีการใช้งานจริงอย่างจำกัดในปัจจุบัน

ผลกระทบด้านความปลอดภัยและความเป็นส่วนตัว

ชุมชนได้ระบุความเสี่ยงที่อาจเกิดขึ้นหลายประการกับเทคโนโลยีใหม่นี้ การบีบอัดแบบ 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