การประมวลผลไฟล์ในเครื่องผ่านเบราว์เซอร์ทำงานอย่างไร
ถ้าไม่มีการอัปโหลดอะไรเลย แล้วอะไรเป็นตัวทำงาน และทำที่ไหน
คำว่า "ในเครื่อง" ในที่นี้หมายถึงอะไร
ตัวแปลงไฟล์ออนไลน์แบบเดิมคือเว็บไซต์ที่มีปลายทางสำหรับรับไฟล์อัปโหลด ไฟล์ของคุณถูกส่งไปยังเครื่องที่คุณควบคุมไม่ได้ ประมวลผลที่นั่น เก็บไว้ระยะหนึ่ง แล้วส่งกลับมาให้ดาวน์โหลด การประมวลผลในเครื่องตัดส่วนกลางของประโยคนั้นทิ้ง โค้ดที่อ่านไฟล์ของคุณทำงานอยู่ในแท็บเบราว์เซอร์ที่คุณเปิดอยู่แล้ว บนหน่วยประมวลผลของคุณเอง และผลลัพธ์ถูกเขียนกลับลงดิสก์ของคุณเอง
ตัวเว็บไซต์ยังคงถูกดึงผ่านเครือข่ายอยู่ ทั้ง HTML สไตล์ชีต สคริปต์ และโมดูล WebAssembly ล้วนมาจากเซิร์ฟเวอร์เหมือนหน้าเว็บทั่วไป ความต่างอยู่ที่ทิศทาง โค้ดของโปรแกรมวิ่งลงมา แต่ไฟล์ของคุณไม่ได้วิ่งขึ้นไป
เบราว์เซอร์มีชิ้นส่วนเหล่านี้อยู่แล้ว
| ความสามารถ | ให้อะไร |
|---|---|
| File และ Blob API | อ่านไบต์ของไฟล์ที่ผู้ใช้เลือกหรือลากมาวาง โดยไม่ต้องส่งฟอร์ม |
| Web Workers | รันงานหนักบนเธรดเบื้องหลัง เพื่อให้ส่วนติดต่อผู้ใช้ยังตอบสนองอยู่ |
| WebAssembly | รันไลบรารีโคเดกที่คอมไพล์จาก C, C++ หรือ Rust ด้วยความเร็วใกล้เคียงโค้ดเนทีฟ |
| Canvas และ OffscreenCanvas | ถอดรหัส วาด ย่อขยาย และเข้ารหัสภาพใหม่ |
| WebCodecs | เข้าถึงตัวเข้ารหัสและถอดรหัสวิดีโอที่เร่งความเร็วด้วยฮาร์ดแวร์ของเบราว์เซอร์เอง |
| WebGPU | รันการอนุมานของโมเดลและงานพิกเซลแบบขนานบนหน่วยประมวลผลกราฟิก |
| File System Access | เขียนผลลัพธ์ลงตำแหน่งที่ผู้ใช้เลือกโดยตรง ในที่ที่รองรับ |
ไม่มีอะไรในนี้แปลกประหลาด มันคือแพลตฟอร์มเดียวกับที่รันสเปรดชีต เครื่องมือออกแบบ และเกมในแท็บ สิ่งเดียวที่ผิดจากปกติคือการตัดสินใจไม่เพิ่มเซิร์ฟเวอร์เข้าไปด้วย
เส้นทางที่ไฟล์เดินผ่าน
- คุณเลือกไฟล์ เบราว์เซอร์ส่งตัวชี้ไปยังไฟล์นั้นให้หน้าเว็บ ไม่ใช่สำเนา แต่เป็นการอ้างอิง
- หน้าเว็บอ่านไบต์แรก ๆ เพื่อระบุชนิดไฟล์ที่แท้จริงจากลายเซ็นของมัน แทนที่จะเชื่อนามสกุลไฟล์
- มันประเมินว่างานนี้ต้องใช้หน่วยความจำเท่าไร แล้วปฏิเสธหรือเข้าคิวงานไว้หากเกินกว่าที่อุปกรณ์จะให้ได้อย่างปลอดภัย
- ไบต์ถูกโอนเข้าไปใน Web Worker การโอน ArrayBuffer เป็นการย้ายความเป็นเจ้าของ ไม่ใช่การคัดลอก ไฟล์ขนาดใหญ่จึงไม่ถูกเก็บซ้ำสองชุดในหน่วยความจำ
- ภายในเวิร์กเกอร์ โคเดกที่เป็น WebAssembly หรือ API ของแพลตฟอร์มจะทำการถอดรหัสและเข้ารหัสจริง
- ผลลัพธ์กลับมาเป็นไบต์ ถูกห่อไว้ใน Blob แล้วส่งให้คุณดาวน์โหลดหรือเขียนลงตำแหน่งที่คุณเลือก
- URL ชั่วคราวของ Blob นั้นถูกเพิกถอน และบัฟเฟอร์ต่าง ๆ ถูกคืนหน่วยความจำ
ทำไม WebAssembly ถึงเป็นตัวที่เปลี่ยนเกม
โคเดกภาพและวิดีโอคือโค้ดภาษา C ที่ถูกปรับแต่งอย่างพิถีพิถันมาหลายทศวรรษ การเขียนมันใหม่ด้วย JavaScript ไม่เคยเป็นเรื่องที่เป็นไปได้จริง WebAssembly คือรูปแบบคำสั่งไบนารีแบบพกพาที่เบราว์เซอร์รันในแซนด์บ็อกซ์ด้วยความเร็วใกล้เคียงโค้ดเนทีฟ ซึ่งหมายความว่าไลบรารีที่มีอยู่แล้วเหล่านั้นถูกคอมไพล์และส่งมายังเบราว์เซอร์ได้ตามที่มันเป็น
แซนด์บ็อกซ์สำคัญพอ ๆ กับความเร็ว โมดูล WebAssembly ไม่มีสิทธิ์เข้าถึงระบบไฟล์ เครือข่าย หรือแท็บอื่น ๆ ของคุณโดยปริยาย มันเห็นเฉพาะหน่วยความจำที่หน้าเว็บส่งให้เท่านั้นและไม่เห็นอย่างอื่นเลย โคเดกที่มุ่งร้ายหรือแค่มีบั๊กจึงไม่อาจเตร็ดเตร่ไปอ่านสิ่งที่ไม่ได้ถูกมอบให้
อะไรที่ยังแตะเครือข่าย และทำไมมันไม่ใช่ไฟล์ของคุณ
มีสามอย่างที่มาทางเครือข่าย คือตัวหน้าเว็บเอง เอนจินของเครื่องมือที่คุณเปิด และในกรณีของการลบพื้นหลังคือค่าน้ำหนักของโมเดล ทั้งสามอย่างเป็นแอสเซตแบบสแตติกของ FileSlimmer เอง ที่ถูกดึงมาจากออริจินของ FileSlimmer เองก่อนที่ไบต์ใด ๆ ของคุณจะถูกอ่าน ทั้งหมดเป็นการดาวน์โหลด เก็บแคชได้ และหลังการใช้งานครั้งแรกก็เสิร์ฟจากแคชของเบราว์เซอร์เองได้โดยไม่ต้องใช้เครือข่ายเลย
ทุกอย่างหลังจากจุดนั้นเกิดขึ้นในเครื่อง เอนจินได้รับไบต์ของไฟล์ผ่าน postMessage จากหน้าเว็บเท่านั้น มันไม่เคยถูกมอบ URL ให้ส่งอะไรออกไป และนโยบายความปลอดภัยของเนื้อหายังจำกัดว่าหน้าเว็บจะเชื่อมต่อไปที่ไหนได้บ้าง แม้จะมีโค้ดบางส่วนพยายามก็ตาม
ข้อแลกเปลี่ยน กล่าวอย่างตรงไปตรงมา
| ประเด็นพิจารณา | ในเบราว์เซอร์ของคุณ | บนเซิร์ฟเวอร์ |
|---|---|---|
| ไฟล์ของคุณไปไหน | ไม่ไปไหน | ไปยังเครื่องที่คุณควบคุมไม่ได้ |
| ความเร็ว | เท่าที่อุปกรณ์ของคุณทำได้ | เท่าที่ผู้ให้บริการจ่ายเงินซื้อมา |
| ไฟล์ขนาดใหญ่มาก | ถูกจำกัดด้วยหน่วยความจำของเบราว์เซอร์ | ถูกจำกัดด้วยข้อกำหนดของผู้ให้บริการ |
| ทำงานแบบออฟไลน์ | ได้ เมื่อเอนจินถูกแคชไว้แล้ว | ไม่ได้ |
| ฟอร์แมตที่พบไม่บ่อย | ได้เฉพาะสิ่งที่คอมไพล์เป็น WebAssembly ได้ | ได้ทุกอย่างที่ผู้ให้บริการติดตั้งไว้ |
| งานชุดละพันไฟล์ | ถูกจำกัดด้วยตัวอุปกรณ์ | โดยทั่วไปเหมาะกว่า |
การประมวลผลในเครื่องไม่ได้ดีกว่าในทุกกรณี มันดีกว่าเมื่อไฟล์เป็นเรื่องส่วนตัว เมื่ออุปกรณ์มีกำลังพอ และเมื่องานนั้นพอดีกับหน่วยความจำ ส่วนเซิร์ฟเวอร์ดีกว่าเมื่อคุณต้องประมวลผลมากเกินกว่าที่เครื่องเดียวจะรับไหว การรู้ชัดว่าคุณอยู่ในสถานการณ์ไหนมีประโยชน์กว่าการยืนกรานว่าแนวทางใดแนวทางหนึ่งชนะทุกสนาม
สิ่งที่หน้านี้ไม่ได้อ้าง
นี่คือคำอธิบายว่าแอปพลิเคชันนี้ทำอะไร ไม่ใช่ข้ออ้างเกี่ยวกับส่วนขยายในเบราว์เซอร์ของคุณ ซึ่งอ่านเนื้อหาของหน้าเว็บใดก็ได้ที่คุณเปิด ไม่ใช่ข้ออ้างเกี่ยวกับระบบปฏิบัติการของคุณ ซึ่งตรวจสอบไฟล์ใดก็ได้ที่คุณแตะ และไม่ใช่ข้ออ้างเกี่ยวกับผู้ให้บริการเครือข่ายของคุณ ซึ่งเห็นได้ว่าคุณเข้าเว็บไซต์ใด สิ่งเหล่านั้นอยู่นอกเหนือเอื้อมของเว็บไซต์ใด ๆ และเครื่องมือที่บอกคุณเป็นอย่างอื่นกำลังกล่าวเกินจริง
ข้ออ้างในที่นี้แคบและตรวจสอบได้ คือไฟล์ที่คุณเลือกถูกประมวลผลในเครื่องภายในเบราว์เซอร์นี้ และไม่ถูกอัปโหลดโดย FileSlimmer คู่มือถัดไปอธิบายวิธีตรวจสอบด้วยตัวเองแทนที่จะเชื่อไปตามคำบอก
เครื่องมือสำหรับเรื่องนี้
แหล่งอ้างอิง
- W3C — File API
- W3C — WebAssembly Core Specification
- WHATWG — HTML Standard, Web Workers
- W3C — WebCodecs