การวิเคราะห์โดยละเอียดของ JavaScript ของคำขอเครือข่ายและทรัพยากรระยะไกล

1. การกำเนิดของ Ajax

ในปี 2548 Jesse James Garrett เขียนบทความเรื่อง "Ajax - แนวทางใหม่สู่แอปพลิเคชันเว็บ" ซึ่งบรรยายถึงแอปพลิเคชันที่เรียกว่า Ajax (เทคโนโลยี JavaScript แบบอะซิงโครนัส+XML) เทคนิคนี้เกี่ยวข้องกับการส่งคำขอข้อมูลเพิ่มเติมไปยังเซิร์ฟเวอร์โดยไม่ต้องรีเฟรชเพจ ส่งผลให้ผู้ใช้ได้รับประสบการณ์ที่ดีขึ้น Garrett อธิบายว่าเทคโนโลยีนี้เปลี่ยนแปลงรูปแบบการคลิกและรอแบบเดิมๆ ที่คงอยู่มาตั้งแต่กำเนิดของเว็บได้อย่างไร
เทคโนโลยีหลักที่ผลักดัน Ajax สู่เวทีประวัติศาสตร์คืออ็อบเจ็กต์ XMLHttpRequest (XHR) ก่อนการถือกำเนิดของ XHR การสื่อสารสไตล์อาแจ็กซ์จะต้องสำเร็จผ่านเทคโนโลยีสีดำบางอย่าง โดยส่วนใหญ่ใช้บานหน้าต่างที่ซ่อนอยู่หรือบานหน้าต่างอินไลน์ XHR มีอินเทอร์เฟซที่เหมาะสมสำหรับการส่งคำขอเซิร์ฟเวอร์และรับการตอบกลับ อินเทอร์เฟซนี้สามารถรับข้อมูลเพิ่มเติมจากเซิร์ฟเวอร์แบบอะซิงโครนัส ซึ่งหมายความว่าผู้ใช้สามารถรับข้อมูลได้โดยไม่ต้องรีเฟรชเพจ หลังจากได้รับข้อมูลผ่านวัตถุ XHR คุณสามารถใช้วิธี DOM เพื่อแทรกข้อมูลลงในเว็บเพจได้
โดยทั่วไปแล้ว XHR object API นั้นถือว่าใช้งานยาก และ Fetch API ก็กลายเป็นมาตรฐานทางเลือกที่ทันสมัยกว่าสำหรับ XHR อย่างรวดเร็วหลังจากการกำเนิดอัตโนมัติ Fetch API รองรับสัญญาตามกำหนดเวลาและเธรดบริการ (พนักงานบริการ) และกลายเป็นเว็บที่ทรงพลังอย่างยิ่ง เครื่องมือพัฒนา

2. การแบ่งปันทรัพยากรข้ามแหล่งกำเนิด

ข้อจำกัดที่สำคัญของการสื่อสาร Ajax ผ่าน XHR คือนโยบายความปลอดภัยข้ามแหล่งกำเนิด ตามค่าเริ่มต้น XHR สามารถเข้าถึงทรัพยากรในโดเมนเดียวกันกับเพจที่เริ่มต้นคำขอเท่านั้น ข้อจำกัดด้านความปลอดภัยนี้ป้องกันพฤติกรรมที่เป็นอันตรายบางอย่าง อย่างไรก็ตาม เบราว์เซอร์ยังต้องรองรับการเข้าถึงแบบข้ามแหล่งที่มาตามกฎหมายอีกด้วย
การแบ่งปันทรัพยากรข้ามแหล่งกำเนิด (CORS) กำหนดวิธีที่เบราว์เซอร์และเซิร์ฟเวอร์ใช้การสื่อสารข้ามแหล่งกำเนิด แนวคิดพื้นฐานเบื้องหลัง CORS คือการใช้ส่วนหัว HTTP ที่กำหนดเองเพื่อให้เบราว์เซอร์และเซิร์ฟเวอร์เข้าใจซึ่งกันและกันเพื่อพิจารณาว่าคำขอหรือการตอบกลับควรสำเร็จหรือล้มเหลว
สำหรับคำขอทั่วไป เช่น คำขอ GET หรือ POST จะไม่มีส่วนหัวที่กำหนดเอง และเนื้อหาคำขอจะเป็นแบบข้อความ/ธรรมดา เมื่อส่งคำขอดังกล่าวจะมีส่วนหัวเพิ่มเติมที่เรียกว่า Origin ส่วนหัว Origin มีแหล่งที่มา (โปรโตคอล ชื่อโดเมน พอร์ต) ของหน้าที่ส่งคำขอ เพื่อให้เซิร์ฟเวอร์สามารถระบุได้ว่าจะให้การตอบกลับหรือไม่
เบราว์เซอร์สมัยใหม่รองรับ CORS ผ่านทางออบเจ็กต์ XMLHttpRequst ซึ่งจะถูกทริกเกอร์โดยอัตโนมัติเมื่อพยายามเข้าถึงทรัพยากรจากแหล่งกำเนิดที่แตกต่างกัน หากต้องการส่งคำขอไปยังต้นทางในโดเมนอื่น คุณสามารถใช้อ็อบเจ็กต์ XHR มาตรฐานและส่ง URL แบบเต็มไปยังเมธอด open() ได้ เช่น:

la xhr = new XMLHttpRequest();xhr.onreadystatechange = function(){
	ถ้า(xhr.readyState == 4){
		if((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304){
			การแจ้งเตือน (xhr.reaponseText);
		}อื่น{
			alert("คำขอไม่สำเร็จ:"+xhr.status);
		-
	}};xhr.open("get","http://www.nezha.con/page/",true);xhr.send(null);

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

• คุณไม่สามารถใช้ setRequestHeader() เพื่อตั้งค่าส่วนหัวที่กำหนดเอง

• คุณไม่สามารถส่งและรับคุกกี้ได้

• เมธอด getAllResponseHeaders() จะส่งคืนสตริงว่างเสมอ

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

3. คำขอ Preflight

CORS ใช้กลไกการตรวจสอบเซิร์ฟเวอร์ที่เรียกว่าคำขอ Preflight ซึ่งอนุญาตให้ใช้ส่วนหัวที่กำหนดเอง วิธีการอื่นที่ไม่ใช่ GET และ POST และประเภทเนื้อหาคำขอที่แตกต่างกัน เมื่อส่งคำขอที่เกี่ยวข้องกับตัวเลือกขั้นสูงข้อใดข้อหนึ่งข้างต้น คำขอก่อนการบินจะถูกส่งไปยังเซิร์ฟเวอร์ก่อน คำขอนี้ถูกส่งโดยใช้วิธี OPTIONS และมีส่วนหัวต่อไปนี้:

• Origin: เหมือนกับคำขอแบบง่าย

• Access-Control-Request-Method: วิธีที่คุณต้องการใช้

• Access-Control-Request-Headers: (เป็นทางเลือก) -ค่าที่แยกออกมาเพื่อใช้รายการส่วนหัวที่กำหนดเอง

4. Fetch API

Fetch API สามารถทำงานทั้งหมดของออบเจ็กต์ XMLHttpRequest ได้ แต่ใช้งานง่ายกว่า อินเทอร์เฟซทันสมัยกว่า และสามารถใช้ในเครื่องมือเว็บ เช่น เธรดผู้ปฏิบัติงานเว็บ XMLHttpRequest สามารถเลือกเป็นแบบอะซิงโครนัสได้ ในขณะที่ Fetch API จะต้องเป็นแบบอะซิงโครนัส
เมธอด fetch() ถูกเปิดเผยในขอบเขตส่วนกลาง รวมถึงเธรดการดำเนินการหน้าหลัก โมดูล และเธรดของผู้ปฏิบัติงาน การเรียกวิธีนี้ทำให้เบราว์เซอร์ส่งคำขอไปยัง URL ที่กำหนด
1. คำขอจัดส่ง
fetch() มีอินพุตพารามิเตอร์ที่จำเป็นเพียงอันเดียวเท่านั้น ในกรณีส่วนใหญ่ พารามิเตอร์นี้คือ URL เพื่อรับทรัพยากร และเมธอดนี้จะส่งคืนสัญญา:

ให้ r = fetch('/bar');console.log(r);//Promise<pending>

รูปแบบ URL (เส้นทางสัมพันธ์ , เส้นทางสัมบูรณ์ ฯลฯ) จะถูกตีความเหมือนกับอ็อบเจ็กต์ XHR
เมื่อคำขอเสร็จสมบูรณ์และมีทรัพยากรเพียงพอ ออบเจ็กต์การตอบสนองจะถูกประมวลผล ออบเจ็กต์นี้คือการห่อหุ้ม API ซึ่งสามารถรับทรัพยากรที่เกี่ยวข้องได้ ใช้คุณสมบัติและวิธีการของออบเจ็กต์นี้เพื่อรับทรัพยากร ทำความเข้าใจการตอบสนอง และแปลงการทำโหลดบาลานซ์ให้เป็นรูปแบบที่มีประโยชน์
2. อ่านคำตอบ วิธีที่ง่ายที่สุดในการอ่านเนื้อหาตอบกลับคือการรับเนื้อหาในรูปแบบข้อความธรรมดา เพียงใช้เมธอด text() เมธอดนี้ส่งคืนสัญญา ซึ่งแก้ไขเพื่อดึงเนื้อหาทั้งหมดของทรัพยากร
3. การจัดการรหัสสถานะและคำขอล้มเหลว
Fetch API รองรับการตรวจสอบสถานะการตอบสนองผ่านคุณสมบัติสถานะและสถานะข้อความของการตอบกลับ คำขอที่ได้รับการตอบกลับสำเร็จมักจะสร้างรหัสสถานะที่มีค่า 200
4. โหมดคำขอ Fetch ทั่วไป:

• ส่งข้อมูล JSON,

• ส่งพารามิเตอร์ในส่วนเนื้อหาคำขอ,

• ส่งไฟล์

• , โหลดไฟล์ Blob

• , ส่งคำขอข้ามโดเมน,

• คำขอขัดจังหวะ

5.

ซ็อกเก็ต Websocket เป้าหมายของ websocket คือการบรรลุ full-duplex และ two- วิธีสื่อสารกับเซิร์ฟเวอร์ผ่านการเชื่อมต่อระยะยาว เมื่อสร้าง websocket ใน JavaScript คำขอ HTTP จะถูกส่งไปยังเซิร์ฟเวอร์เพื่อเริ่มต้นการเชื่อมต่อ หลังจากที่เซิร์ฟเวอร์ตอบสนอง การเชื่อมต่อจะสลับจากโปรโตคอล HTTP ไปเป็นโปรโตคอล websocket โดยใช้ส่วนหัวการอัพเกรดใน HTTP ซึ่งหมายความว่า websocket ไม่สามารถใช้งานได้ผ่านเซิร์ฟเวอร์ HTTP มาตรฐาน แต่ต้องใช้เซิร์ฟเวอร์ที่เป็นกรรมสิทธิ์ซึ่งรองรับโปรโตคอลนี้
เนื่องจาก websocket ใช้โปรโตคอลที่กำหนดเอง รูปแบบ URL จึงมีการเปลี่ยนแปลงเล็กน้อย http:// หรือ https:// ไม่สามารถใช้ได้อีกต่อไป แต่ต้องใช้ ws:// และ wss:// แบบแรกคือการเชื่อมต่อที่ไม่ปลอดภัย และแบบหลังคือการเชื่อมต่อที่ปลอดภัย เมื่อดำเนินการ URL ของ websocket จะต้องรวมรูปแบบ URL ไว้ด้วย เนื่องจากเป็นไปได้ว่าอาจรองรับรูปแบบเพิ่มเติมในอนาคต
ข้อดีของการใช้โปรโตคอลแบบกำหนดเองแทนโปรโตคอล HTTP คือไคลเอ็นต์และเซิร์ฟเวอร์สามารถส่งข้อมูลได้น้อยมากโดยไม่ก่อให้เกิดภาระใดๆ บน HTTP การใช้แพ็กเก็ตข้อมูลขนาดเล็กทำให้เว็บซ็อกเก็ตเหมาะสำหรับแอปพลิเคชันมือถือที่ปัญหาแบนด์วิดท์และเวลาแฝงมีความสำคัญ ข้อเสียของการใช้โปรโตคอลแบบกำหนดเองคือการกำหนดโปรโตคอลใช้เวลานานกว่าการกำหนด JavaScript API Websocket ได้รับการสนับสนุนโดยเบราว์เซอร์หลักทั้งหมด

6. แผนที่ความคิดจาวาสคริปต์