วิธีเริ่มต้นใช้งาน VUE3.0 อย่างรวดเร็ว: เข้าสู่การเรียนรู้
เมื่อหลายบริบทเข้าถึง SharedArrayBuffer หากดำเนินการกับบัฟเฟอร์ในเวลาเดียวกัน ปัญหาการช่วงชิงทรัพยากรอาจเกิดขึ้นได้ Atomics API ช่วยให้หลายบริบทสามารถอ่านและเขียน SharedArrayBuffer ได้อย่างปลอดภัย โดยบังคับให้ดำเนินการได้ครั้งละหนึ่งการดำเนินการบนบัฟเฟอร์เท่านั้น
ธรรมชาติของการดำเนินการปรมาณูขัดขวางการปรับให้เหมาะสม (เช่น การจัดลำดับคำสั่งใหม่) ที่ระบบปฏิบัติการหรือฮาร์ดแวร์คอมพิวเตอร์โดยปกติจะดำเนินการโดยอัตโนมัติ การดำเนินการแบบอะตอมมิกยังทำให้ไม่สามารถเข้าถึงหน่วยความจำพร้อมกันได้ หากใช้ไม่ถูกต้อง อาจทำให้การทำงานของโปรแกรมช้าลง ด้วยเหตุนี้ ความตั้งใจในการออกแบบดั้งเดิมของ Atomics API คือการสร้างโปรแกรม JavaScript แบบมัลติเธรดที่ซับซ้อนโดยอาศัยพื้นฐานที่น้อยที่สุดแต่มีความเสถียร พฤติกรรมของอะตอม
Atomics API จัดเตรียมชุดวิธีการง่ายๆ สำหรับการดำเนินการแก้ไขแบบแทนที่ ในข้อกำหนด ECMA วิธีการเหล่านี้ถูกกำหนดเป็นการดำเนินการ AtomicReadModifyWrite ภายใต้ประทุน วิธีการเหล่านี้อ่านค่าจากตำแหน่งใน SharedArrayBuffer ดำเนินการทางคณิตศาสตร์และการดำเนินการระดับบิต และสุดท้ายก็เขียนผลลัพธ์ไปยังตำแหน่งเดียวกัน ลักษณะอะตอมมิกของการดำเนินการเหล่านี้หมายความว่าการดำเนินการอ่าน แก้ไข และเขียนกลับที่อธิบายไว้ข้างต้นจะถูกดำเนินการตามลำดับ และจะไม่ถูกขัดจังหวะโดยเธรดอื่น
//สร้างบัฟเฟอร์ขนาด 1 ให้ sharedArrayBuffer = new SharedArrayBuffer(1); //สร้าง Unit8Arraylet ตามบัฟเฟอร์ typedArray = new Unit8Array(sharedArrayBuffer); //ArrayBuffers ทั้งหมดถูกเตรียมใช้งานเป็น 0console.log(typedArray); //Unit8Array[0] // ทำการบวกอะตอมมิก 10 เข้ากับค่าที่ดัชนี 0Atomics.add(typedArray,0,10); //Unit8Array[10] //ดำเนินการลบอะตอมมิก 10 กับค่าที่ดัชนี 0Atomics.sub(typedArray,0,10); //Unit8Array[0]
คอมไพเลอร์ JavaScript ของเบราว์เซอร์และสถาปัตยกรรม CPU เองมีอำนาจในการจัดเรียงคำสั่งใหม่เพื่อปรับปรุงประสิทธิภาพการทำงานของโปรแกรม ภายใต้สถานการณ์ปกติ สภาพแวดล้อมแบบเธรดเดียวของ JavaScript สามารถดำเนินการเพิ่มประสิทธิภาพนี้ได้ตลอดเวลา แต่การจัดเรียงคำสั่งใหม่ในหลายเธรดอาจนำไปสู่การแย่งชิงทรัพยากรและเป็นเรื่องยากมากในการแก้ไขปัญหา
Atomics API แก้ปัญหานี้ด้วยสองวิธีหลัก:
ลำดับของคำสั่งอะตอมมิกทั้งหมดที่สัมพันธ์กันจะไม่มีการจัดเรียงใหม่
การใช้การอ่านหรือเขียนแบบอะตอมมิกช่วยรับประกันว่าคำสั่งทั้งหมดจะไม่เรียงลำดับใหม่โดยสัมพันธ์กับการอ่านและเขียนแบบอะตอมมิก
นอกเหนือจากการอ่านและเขียนค่าบัฟเฟอร์แล้ว Atomics.load() และ Atomics.store() ยังสามารถสร้าง "code fences" ได้อีกด้วย เอ็นจิ้น JavaScript ช่วยให้มั่นใจได้ว่าคำสั่งที่ไม่ใช่อะตอมมิกสามารถจัดเรียงใหม่ในเครื่องโดยสัมพันธ์กับ load() และ store() แต่การจัดเรียงใหม่นี้จะไม่ละเมิดขอบเขตของการอ่านและเขียนอะตอมมิก
const sharedArrayBuffer = SharedArrayBuffer ใหม่ (4); มุมมอง const = Unit32Array ใหม่ (sharedArrayBuffer); //แสดงมุมมองการเขียนที่ไม่ใช่อะตอมมิก[0] = 1; //รับประกันว่าการเขียนที่ไม่ใช่อะตอมมิกจะเสร็จสิ้นก่อนการดำเนินการอ่านนี้ ดังนั้น 1console.log(Atomics.load(view,0)); จะถูกอ่านที่นี่อย่างแน่นอน //1 //ดำเนินการเขียนอะตอมมิก Atomics.store(view,0,2); //รับประกันว่าการอ่านแบบไม่ใช่อะตอมมิกจะเกิดขึ้นหลังจากการเขียนแบบอะตอมมิกเสร็จสิ้น และ 2console.log(view[0]); จะถูกอ่านที่นี่อย่างแน่นอน //2
เพื่อให้มั่นใจว่าการอ่านต่อเนื่องและไม่สะดุดก่อนแล้วจึงเขียน Atomics API มีสองวิธี: การแลกเปลี่ยน() และการเปรียบเทียบการแลกเปลี่ยน() Atomics.exchange() ทำการแลกเปลี่ยนอย่างง่าย ๆ ซึ่งรับประกันว่าเธรดอื่นจะไม่รบกวนการแลกเปลี่ยน
const sharedArrayBuffer = SharedArrayBuffer ใหม่ (4); มุมมอง const = Unit32Array ใหม่ (sharedArrayBuffer); //เขียน 10Atomics.store(view,0,10) ที่ดัชนี 0; //อ่านค่าจากดัชนี 0 และเขียน 5 ที่ดัชนี 0console.log(Atomics.exchange(view,0,5)); //10 //อ่านค่าจากดัชนี 0 console.log(Atomics.load(view,0)); //5
ในโปรแกรมแบบมัลติเธรด เธรดอาจต้องการเขียนไปยังบัฟเฟอร์ที่ใช้ร่วมกันเท่านั้น หากไม่มีเธรดอื่นแก้ไขค่าตั้งแต่ครั้งล่าสุดที่อ่าน หากค่าไม่ได้รับการแก้ไข เธรดนี้สามารถเขียนค่าที่อัปเดตได้อย่างปลอดภัย: หากค่าได้รับการแก้ไข การดำเนินการเขียนจะทำลายค่าที่คำนวณโดยเธรดอื่น สำหรับงานประเภทนี้ Atomics API จัดเตรียมเมธอด comparison-Exchange() เมธอดนี้ดำเนินการเขียนหากค่าที่ดัชนีเป้าหมายตรงกับค่าที่คาดไว้เท่านั้น
หากไม่มีกลไกการล็อคบางประเภท โปรแกรมแบบมัลติเธรดไม่สามารถรองรับข้อกำหนดที่ซับซ้อนได้ ด้วยเหตุนี้ Atomics API จึงจัดเตรียมวิธีการที่เลียนแบบ Linux Futex (mutex พื้นที่ผู้ใช้ที่รวดเร็ว) วิธีการเหล่านี้แม้จะเรียบง่ายในตัวเอง แต่ก็สามารถใช้เป็นองค์ประกอบพื้นฐานสำหรับกลไกการล็อคที่ซับซ้อนมากขึ้นได้
การดำเนินการ Atomic Futex ทั้งหมดสามารถใช้ได้บนมุมมอง Int32Array เท่านั้น และยิ่งไปกว่านั้น เฉพาะภายในเธรดผู้ปฏิบัติงานเท่านั้น
การส่งข้อความข้ามเอกสาร บางครั้งเรียกว่า XDM (การส่งข้อความข้ามเอกสาร) คือความสามารถในการถ่ายโอนข้อมูลระหว่างบริบทการดำเนินการที่แตกต่างกัน (เช่น เธรดของผู้ปฏิบัติงานหรือเพจจากแหล่งที่ต่างกัน)
Encoding API ส่วนใหญ่จะใช้เพื่อแปลงระหว่างสตริงและอาร์เรย์แบบตายตัว
File API ยังคงยึดตามฟิลด์อินพุตไฟล์ในแบบฟอร์ม แต่เพิ่มความสามารถในการเข้าถึงข้อมูลไฟล์โดยตรง HTML5 เพิ่มคอลเลกชันไฟล์ให้กับ DOM สำหรับองค์ประกอบอินพุตไฟล์ เมื่อผู้ใช้เลือกไฟล์ตั้งแต่หนึ่งไฟล์ขึ้นไปในฟิลด์ไฟล์ คอลเลกชันไฟล์จะมีชุดของออบเจ็กต์ไฟล์ที่แสดงถึงไฟล์ที่เลือก แต่ละออบเจ็กต์จะมีคุณลักษณะแบบอ่านอย่างเดียว
ประเภท FileReader แสดงถึงกลไกการอ่านไฟล์แบบอะซิงโครนัส คุณสามารถคิดว่า FileReader คล้ายกับ XMLHttpRequest ยกเว้นว่าใช้เพื่ออ่านไฟล์จากระบบไฟล์แทนการอ่านข้อมูลจากเซิร์ฟเวอร์ ประเภท FileReader มีหลายวิธีในการอ่านข้อมูลไฟล์
readAsText(file,encoding);//อ่านเนื้อหาข้อความธรรมดาจากไฟล์และบันทึกลงในแอตทริบิวต์ผลลัพธ์
readAsDataURL(file);//อ่านไฟล์และบันทึก URI ข้อมูลของเนื้อหาในแอตทริบิวต์ผลลัพธ์
readAsBinaryString(file); / /อ่านไฟล์และบันทึกข้อมูลไบนารีของอักขระแต่ละตัวในแอตทริบิวต์ผลลัพธ์
readAsArrayBuffer(file); //อ่านไฟล์และบันทึกเนื้อหาไฟล์ในแอตทริบิวต์ผลลัพธ์ในรูปแบบของ ArrayBuffer
เวอร์ชันซิงโครนัสของ ประเภทไฟล์รีดเดอร์
ในบางกรณี คุณอาจต้องอ่านบางส่วนของไฟล์แทนการอ่านทั้งไฟล์ เพื่อจุดประสงค์นี้ ออบเจ็กต์ File จึงมีเมธอดที่เรียกว่า Slice() วิธีการ Slice() ได้รับพารามิเตอร์สองตัว: ไบต์เริ่มต้นและจำนวนไบต์ในพื้นที่ Yaodu เมธอดนี้ส่งคืนอินสแตนซ์ของ Blob ซึ่งจริงๆ แล้วเป็นซูเปอร์คลาสของ File
Blob แสดงถึงวัตถุไบนารีขนาดใหญ่ ซึ่งเป็นประเภทการห่อหุ้มของ JavaScript สำหรับข้อมูลไบนารีที่ไม่สามารถแก้ไขได้ อาร์เรย์ที่ประกอบด้วยสตริง, ArrayBuffers, ArrayBufferViews และแม้แต่ Blob อื่นๆ ก็สามารถใช้สร้าง Blob ได้ ตัวสร้าง Blob สามารถรับพารามิเตอร์ตัวเลือกและระบุประเภท MIME ในนั้น
Streams API ถือกำเนิดขึ้นเพื่อแก้ไขปัญหาที่เรียบง่ายแต่เป็นพื้นฐาน: เว็บแอปพลิเคชันใช้บล็อกข้อมูลขนาดเล็กที่เรียงลำดับแทนบล็อกข้อมูลขนาดใหญ่อย่างไร มีสองสถานการณ์การใช้งานหลักสำหรับความสามารถนี้
Streams API กำหนดสตรีมสามรายการ:
สตรีมที่อ่านได้: สตรีมที่สามารถอ่านบล็อกข้อมูลผ่านอินเทอร์เฟซสาธารณะ ข้อมูลเข้าสู่สตรีมภายในจากแหล่งที่มาที่สำคัญ จากนั้นผู้บริโภคจะประมวลผล
สตรีมที่เขียนได้: สตรีมที่สามารถเขียนบล็อกข้อมูลผ่านอินเทอร์เฟซสาธารณะบางส่วนได้ ผู้ผลิต (ผู้บริโภค) เขียนข้อมูลลงในสตรีม และข้อมูลจะถูกถ่ายโอนภายในไปยังช่องข้อมูลพื้นฐาน (ซิงค์)
สตรีม Conversion: ประกอบด้วยสองสตรีม สตรีมที่เขียนได้จะใช้เพื่อรับข้อมูล และสตรีมที่อ่านได้จะใช้เพื่อส่งออกข้อมูล การตรวจสอบคุณภาพสตรีมทั้งสองนี้เป็นหม้อแปลงไฟฟ้าที่สามารถตรวจสอบและแก้ไขเนื้อหาสตรีมได้ตามต้องการ
Web Cryptography API อธิบายชุดเครื่องมือการเข้ารหัสที่สร้างมาตรฐานวิธีที่ JavaScript ใช้การเข้ารหัสในลักษณะที่ปลอดภัยและธรรมดา เครื่องมือเหล่านี้รวมถึงการสร้าง การใช้ และการใช้คู่คีย์เข้ารหัส การเข้ารหัสและถอดรหัสข้อมูล และการสร้างตัวเลขสุ่มที่เชื่อถือได้
หลายๆ คนใช้ Math.random() เมื่อต้องการสร้างตัวเลขสุ่ม วิธีการนี้ถูกนำมาใช้ในเบราว์เซอร์เป็นตัวสร้างตัวเลขสุ่มหลอก (PRNG, ตัวสร้างตัวเลขหลอกเทียม) สิ่งที่เรียกว่าหลอกหมายถึงกระบวนการสร้างค่าที่ไม่สุ่มอย่างแท้จริง ค่าที่สร้างโดย PRNG จะจำลองลักษณะเฉพาะแบบสุ่มเท่านั้น PRNG ของเบราว์เซอร์ไม่ได้ใช้แหล่งที่มาสุ่มที่แท้จริง แต่ใช้อัลกอริธึมคงที่กับสถานะภายในเท่านั้น แต่ละครั้งที่มีการเรียก Math.random() สถานะภายในนี้จะถูกแก้ไขโดยอัลกอริทึม และผลลัพธ์จะถูกแปลงเป็นตัวเลขสุ่มใหม่ ตัวอย่างเช่น เครื่องยนต์ V8 ใช้อัลกอริธึมที่เรียกว่า xorshift128+ เพื่อทำการปรับเปลี่ยนนี้
เนื่องจากตัวอัลกอริธึมได้รับการแก้ไขแล้ว และอินพุตของอัลกอริธึมเป็นเพียงสถานะก่อนหน้าเท่านั้น ลำดับหมายเลขสุ่มจึงถูกกำหนดด้วย xorshift128+ ใช้สถานะภายใน 128 บิต และอัลกอริทึมได้รับการออกแบบเพื่อให้สถานะเริ่มต้นใด ๆ สร้างค่าสุ่มหลอก 2 128 -1 ก่อนที่จะทำซ้ำตัวเอง การวนซ้ำประเภทนี้เรียกว่าการวนซ้ำการเรียงสับเปลี่ยน และความยาวของการวนซ้ำนี้เรียกว่าระยะเวลา เห็นได้ชัดว่าหากผู้โจมตีทราบสถานะภายในของ PRNG เขาสามารถทำนายค่าสุ่มหลอกที่สร้างขึ้นในภายหลังได้ หากนักพัฒนาใช้ PRNG เพื่อสร้างคีย์ส่วนตัวสำหรับการเข้ารหัสโดยไม่ได้ตั้งใจ ผู้โจมตีสามารถใช้คุณลักษณะนี้ของ PRNG เพื่อคำนวณคีย์ส่วนตัวได้
ตัวสร้างตัวเลขสุ่มหลอกส่วนใหญ่จะใช้เพื่อคำนวณตัวเลขสุ่มที่ดูเหมือนสุ่มอย่างรวดเร็ว แต่ไม่เหมาะสำหรับอัลกอริธึมการเข้ารหัส เพื่อแก้ปัญหานี้ ตัวสร้างตัวเลขสุ่มหลอกที่ปลอดภัยด้วยการเข้ารหัส (CSPRNG, ตัวสร้างตัวเลขสุ่มเทียมที่ปลอดภัยแบบเข้ารหัส) เพิ่มเติมด้วยการเพิ่มเอนโทรปีเป็น อินพุต เช่น การทดสอบเวลาของฮาร์ดแวร์หรือคุณลักษณะอื่นๆ ของระบบที่มีพฤติกรรมที่ไม่สามารถคาดเดาได้ แม้ว่าจะไม่เร็วเท่ากับ PRNG แต่ค่าที่สร้างขึ้นนั้นยากต่อการคาดเดาและสามารถใช้สำหรับการเข้ารหัสได้
Web Cryptography API แนะนำ CSPRNG ซึ่งสามารถเข้าถึงได้บนออบเจ็กต์ Crypto ส่วนกลางผ่าน crypto.getRandomValues() ต่างจาก Math.random() ที่ส่งคืนตัวเลขทศนิยมระหว่าง 0 ถึง 1 getRandomValues() เขียนค่าสุ่มลงในอาร์เรย์แบบตายตัวที่ส่งผ่านไปเป็นพารามิเตอร์ คลาสของอาร์เรย์แบบตายตัวไม่สำคัญเนื่องจากบัฟเฟอร์พื้นฐานจะเต็มไปด้วยบิตสุ่ม
