เหตุใดจึงต้องใช้ AJAX เมื่อ WebSockets พร้อมใช้งาน

ฉันใช้ WebSockets มาระยะหนึ่งแล้วฉันได้เลือกที่จะสร้างเครื่องมือการจัดการโครงการ Agile สำหรับโครงการปีสุดท้ายของฉันที่ University โดยใช้เซิร์ฟเวอร์ Node และ WebSockets ฉันพบว่าการใช้ WebSockets มีจำนวนคำขอเพิ่มขึ้น 624% ต่อวินาทีที่แอปพลิเคชันของฉันสามารถดำเนินการได้

อย่างไรก็ตามตั้งแต่เริ่มโครงการฉันได้อ่านช่องโหว่ความปลอดภัยและเบราว์เซอร์บางตัวเลือกที่จะปิดการใช้งาน WebSockets โดยค่าเริ่มต้น ..

นี่ทำให้ฉันมีคำถาม:

เหตุใดจึงต้องใช้ AJAX เมื่อ WebSockets ดูเหมือนว่าจะทำงานที่ยอดเยี่ยมในการลดความหน่วงแฝงและค่าใช้จ่ายทรัพยากรมีอะไรที่ AJAX ทำได้ดีกว่า WebSockets หรือไม่

WebSockets ไม่ได้มีไว้เพื่อแทนที่ AJAX และไม่ได้เป็นเพียงการแทนที่ Comet / แบบสำรวจความคิดเห็นระยะยาว (แม้ว่าจะมีหลายกรณีที่มันสมเหตุสมผล)

จุดประสงค์ของ WebSockets คือการให้การเชื่อมต่อที่มีความหน่วงต่ำทิศทางสองฟูลดูเพล็กซ์และใช้งานยาวนานระหว่างเบราว์เซอร์และเซิร์ฟเวอร์ WebSockets เปิดโดเมนแอปพลิเคชันใหม่ให้กับแอปพลิเคชั่นเบราว์เซอร์ที่ไม่สามารถใช้ HTTP และ AJAX ได้ (เกมแบบโต้ตอบสตรีมสื่อแบบไดนามิกการเชื่อมต่อกับโปรโตคอลเครือข่ายที่มีอยู่ ฯลฯ )

อย่างไรก็ตามมีการทับซ้อนกันระหว่าง WebSockets และ AJAX / Comet อย่างแน่นอน ตัวอย่างเช่นเมื่อเบราว์เซอร์ต้องการได้รับการแจ้งเตือนเกี่ยวกับเหตุการณ์เซิร์ฟเวอร์ (เช่นพุช) ดังนั้นเทคนิคของ Comet และ WebSockets เป็นตัวเลือกที่ทำงานได้อย่างแน่นอน หากแอปพลิเคชันของคุณต้องการกิจกรรมการส่งข้อมูลที่มีความหน่วงแฝงต่ำนี่จะเป็นปัจจัยที่สนับสนุน WebSockets ในทางกลับกันถ้าคุณต้องการอยู่ร่วมกับเฟรมเวิร์กที่มีอยู่และปรับใช้เทคโนโลยี (OAuth, RESTful APIs, พร็อกซี, โหลดบาลานเซอร์) แล้วนี่จะเป็นปัจจัยที่สนับสนุนเทคนิคของ Comet (ตอนนี้)

หากคุณไม่ต้องการสิทธิประโยชน์เฉพาะที่ WebSockets มีให้ก็อาจเป็นความคิดที่ดีกว่าที่จะใช้เทคนิคที่มีอยู่เช่น AJAX และ Comet เพราะจะช่วยให้คุณสามารถนำกลับมาใช้ใหม่และทำงานร่วมกับเครื่องมือเทคโนโลยีและกลไกด้านความปลอดภัย ฐานความรู้ (เช่นผู้คนจำนวนมากใน stackoverflow รู้จัก HTTP / Ajax / Comet มากกว่า WebSockets) ฯลฯ

ในทางกลับกันหากคุณกำลังสร้างแอปพลิเคชันใหม่ที่ทำงานได้ไม่ดีภายในข้อ จำกัด เวลาแฝงและการเชื่อมต่อของ HTTP / Ajax / Comet ให้พิจารณาใช้ WebSockets

นอกจากนี้คำตอบบางข้อบ่งชี้ว่าข้อเสียข้อใดข้อหนึ่งของ WebSockets คือการสนับสนุนเซิร์ฟเวอร์ จำกัด / แบบผสมและเบราว์เซอร์ ขอผมกระจายมันหน่อย ในขณะที่ iOS (iPhone, iPad) ยังคงรองรับโปรโตคอลเก่า (Hixie) เซิร์ฟเวอร์ WebSockets ส่วนใหญ่รองรับทั้ง Hixie และ HyBi / IETF 6455รุ่น แพลตฟอร์มอื่น ๆ ส่วนใหญ่ (หากยังไม่มีการสนับสนุนในตัว) สามารถรับการสนับสนุน WebSockets ผ่านweb-socket-js (โพลีฟิลที่ใช้ Flash) สิ่งนี้ครอบคลุมผู้ใช้เว็บส่วนใหญ่ นอกจากนี้หากคุณกำลังใช้โหนดสำหรับแบ็กเอนด์เซิร์ฟเวอร์ให้พิจารณาใช้Socket.IOซึ่งรวมถึงเว็บซ็อกเก็ต-jsเป็นทางเลือกและหากไม่สามารถใช้งานได้ (หรือปิดการใช้งาน) ก็จะถอยกลับไปใช้เทคนิคดาวหาง สามารถใช้ได้สำหรับเบราว์เซอร์ที่กำหนด

อัปเดต : iOS 6 รองรับมาตรฐาน HyBi / IETF 6455 ปัจจุบัน

กรอไปข้างหน้าจนถึงเดือนธันวาคม 2017 เว็บซ็อกเก็ตได้รับการสนับสนุนโดย (ในทางปฏิบัติ) ทุกเบราว์เซอร์และการใช้งานเป็นเรื่องธรรมดามาก

อย่างไรก็ตามนี่ไม่ได้หมายความว่า Websockets มีการจัดการเพื่อแทนที่ AJAX อย่างน้อยก็ไม่สมบูรณ์โดยเฉพาะอย่างยิ่งเมื่อมีการปรับ HTTP / 2 ขึ้นเรื่อย ๆ

คำตอบสั้น ๆ ก็คือ AJAX ยังคงยอดเยี่ยมสำหรับแอปพลิเคชัน REST ส่วนใหญ่แม้ว่าจะใช้ Websockets ก็ตาม แต่พระเจ้าอยู่ในรายละเอียดดังนั้น ... :

AJAX สำหรับการสำรวจ?

การใช้ AJAX สำหรับการสำรวจ (หรือการสำรวจแบบยาว) กำลังจะตาย (และควรจะเป็น) แต่ก็ยังคงมีการใช้งานด้วยเหตุผลสองประการที่ดี (ส่วนใหญ่สำหรับเว็บแอปขนาดเล็ก):

1. สำหรับนักพัฒนาหลายคน AJAX นั้นง่ายต่อการเขียนโค้ดโดยเฉพาะอย่างยิ่งเมื่อมันมาถึงการเขียนโค้ดและออกแบบแบ็กเอนด์

2. ด้วย HTTP / 2 ค่าใช้จ่ายสูงสุดที่เกี่ยวข้องกับ AJAX (การสร้างการเชื่อมต่อใหม่) จะถูกตัดออกไปทำให้การโทร AJAX นั้นมีประสิทธิภาพมากโดยเฉพาะอย่างยิ่งสำหรับการโพสต์และอัปโหลดข้อมูล

อย่างไรก็ตามการกดปุ่ม Websocket นั้นเหนือกว่า AJAX (ไม่จำเป็นต้องรับรองความถูกต้องอีกครั้งหรือส่งส่วนหัวอีกต่อไปไม่ต้องใช้การปัดเศษ "ไม่มีข้อมูล" ฯลฯ ) เรื่องนี้ถูกกล่าวถึงหลายครั้ง

AJAX สำหรับ REST หรือไม่

การใช้ AJAX ที่ดีกว่าคือการเรียกใช้ REST API การใช้งานนี้ช่วยลดความยุ่งยากของฐานรหัสและป้องกันไม่ให้การเชื่อมต่อ Websocket ปิดกั้น (โดยเฉพาะการอัปโหลดข้อมูลขนาดกลาง)

มีหลายเหตุผลที่น่าสนใจที่จะชอบการโทร AJAX สำหรับ REST APIและการอัปโหลดข้อมูล:

1. AJAX API ได้รับการออกแบบในทางปฏิบัติสำหรับการโทร REST API และเป็นแบบที่เหมาะสม

2. ส่วนที่เหลือการโทรและการอัปโหลดโดยใช้ AJAX นั้นง่ายกว่าในการเขียนโค้ดทั้งบนไคลเอนต์และแบ็กเอนด์

3. เมื่อปริมาณข้อมูลเพิ่มขึ้นการเชื่อมต่อ Websocket อาจถูกบล็อกเว้นแต่ว่าการกระจายตัวของข้อความ / ตรรกะมัลติเพล็กซ์จะถูกเข้ารหัส

   หากทำการอัพโหลดในการsendโทรWebsocket ครั้งเดียวมันสามารถปิดกั้นการสตรีม Websocket ได้จนกว่าการอัปโหลดจะเสร็จสิ้น สิ่งนี้จะลดประสิทธิภาพโดยเฉพาะกับลูกค้าที่ช้าลง

การออกแบบทั่วไปใช้ข้อความ bidi ขนาดเล็กที่ถ่ายโอนผ่าน Websockets ในขณะที่ REST และการอัปโหลดข้อมูล (ไคลเอนต์ไปยังเซิร์ฟเวอร์) ใช้ประโยชน์จาก AJAX ที่ใช้งานง่ายเพื่อป้องกัน Websocket ไม่ให้ถูกบล็อก

อย่างไรก็ตามสำหรับโครงการขนาดใหญ่ความยืดหยุ่นที่ได้รับจาก Websockets และความสมดุลระหว่างความซับซ้อนของรหัสและการจัดการทรัพยากรจะทำให้ยอดเงินคงเหลืออยู่ในความโปรดปรานของ Websockets

ตัวอย่างเช่นการอัปโหลดจาก Websocket สามารถเสนอความสามารถในการอัปโหลดขนาดใหญ่ต่อหลังจากการเชื่อมต่อถูกยกเลิกและสร้างใหม่อีกครั้ง (โปรดจำไว้ว่าภาพยนตร์ 5GB ที่คุณต้องการอัปโหลด?)

ด้วยการเข้ารหัสโค้ดการกระจายตัวของการอัพโหลดทำให้ง่ายต่อการอัปโหลดขัดจังหวะต่อ (ส่วนที่ยากคือการเขียนโค้ด)

HTTP / 2 push เป็นอย่างไร

ฉันควรจะเพิ่มว่าคุณสมบัติการกด HTTP / 2 ไม่ได้ (และอาจเป็นไปไม่ได้) แทนที่ Websockets

เรื่องนี้เคยพูดถึงที่นี่มาก่อน แต่พอจะพูดถึงว่าการเชื่อมต่อ HTTP / 2 เดียวให้บริการเบราว์เซอร์ทั้งหมด (แท็บ / หน้าต่างทั้งหมด) ดังนั้นข้อมูลที่ถูกผลักโดย HTTP / 2 ไม่ทราบว่าเป็นแท็บ / หน้าต่างใด กำจัดความสามารถในการแทนที่ความสามารถของ Websocket ในการส่งข้อมูลโดยตรงไปยังแท็บ / หน้าต่างเบราว์เซอร์ที่ต้องการ

ในขณะที่ Websockets นั้นยอดเยี่ยมสำหรับการสื่อสารข้อมูลแบบสองทิศทางขนาดเล็ก AJAX ยังคงมีข้อดีหลายประการโดยเฉพาะอย่างยิ่งเมื่อพิจารณา payloads ที่มีขนาดใหญ่ขึ้น (อัพโหลดเป็นต้น)

และความปลอดภัย?

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

AJAX ตามธรรมชาติแล้วจะมีความได้เปรียบเพราะความปลอดภัยมันถูกสร้างไว้ในโค้ดของเบราว์เซอร์ (ซึ่งบางครั้งก็เป็นที่น่าสงสัย แต่ก็ยังมีอยู่)

ในทางกลับกันการโทร AJAX มีความอ่อนไหวต่อการโจมตี "คนที่อยู่ตรงกลาง" มากกว่าในขณะที่ปัญหาด้านความปลอดภัยของ Websockets มักจะเป็นข้อบกพร่องในรหัสแอปพลิเคชันที่แนะนำข้อบกพร่องด้านความปลอดภัย

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

ความเห็นต่ำต้อยของฉัน

IMHO ฉันจะใช้ Websockets สำหรับทุกสิ่งยกเว้นการโทร REST API อัปโหลดข้อมูลขนาดใหญ่ฉันจะแยกส่วนและส่งผ่าน Websockets เมื่อเป็นไปได้

การสำรวจความคิดเห็น IMHO ควรผิดกฎหมายค่าใช้จ่ายในการรับส่งข้อมูลเครือข่ายน่ากลัวและการผลักดัน Websocket นั้นง่ายพอที่จะจัดการแม้กระทั่งสำหรับนักพัฒนาใหม่

นอกเหนือจากปัญหาเกี่ยวกับเบราว์เซอร์รุ่นเก่า (รวมถึง IE9 เนื่องจาก WebSockets จะได้รับการสนับสนุนเริ่มต้นจาก IE10) ยังมีปัญหาใหญ่เกี่ยวกับตัวกลางเครือข่ายที่ยังไม่สนับสนุน WebSockets รวมถึงพร็อกซีแบบโปร่งใสพร็อกซี่ย้อนกลับ มีผู้ให้บริการมือถือบางรายที่ปิดกั้นการรับส่งข้อมูล WebSocket (นั่นคือหลังจากคำสั่ง HTTP UPGRADE)

เมื่อเวลาผ่านไปหลายปี WebSockets จะได้รับการสนับสนุนมากขึ้นเรื่อย ๆ แต่ในเวลาเดียวกันคุณควรมีวิธีการถอยกลับที่ใช้ HTTP สำหรับการส่งข้อมูลไปยังเบราว์เซอร์

สิ่งที่ฉันได้อ่านเกี่ยวกับเว็บซ็อกเก็ตและความปลอดภัยส่วนใหญ่มาจากผู้ขายระบบรักษาความปลอดภัยของเว็บเบราว์เซอร์และเครื่องมือรักษาความปลอดภัยไฟร์วอลล์ ปัญหาคือพวกเขาไม่รู้วิธีทำการวิเคราะห์ความปลอดภัยของทราฟฟิกของ websockets เพราะเมื่อทำการอัพเกรดจาก HTTP ไปเป็นโปรโตคอลไบนารี่ websocket เนื้อหาของแพ็คเก็ตและความหมายของมันก็คือโปรแกรมเฉพาะ เห็นได้ชัดว่านี่เป็นฝันร้ายด้านโลจิสติกส์ของ บริษัท เหล่านี้ซึ่งการทำมาหากินขึ้นอยู่กับการวิเคราะห์และจำแนกการรับส่งข้อมูลอินเทอร์เน็ตทั้งหมดของคุณ :)

WebSockets ไม่ทำงานในเว็บเบราว์เซอร์รุ่นเก่าและรุ่นที่รองรับมักจะมีการใช้งานที่แตกต่างกัน นั่นเป็นเหตุผลที่ดีเพียงข้อเดียวที่ว่าทำไมพวกเขาจึงไม่ใช้ AJAX ตลอดเวลา

ฉันไม่คิดว่าเราสามารถทำการเปรียบเทียบ Websockets และ HTTP ได้อย่างชัดเจนเนื่องจากพวกเขาไม่มีคู่แข่งหรือแก้ปัญหาเดียวกัน

เว็บซ็อคเก็ตเป็นตัวเลือกที่ยอดเยี่ยมสำหรับการจัดการข้อมูลสตรีมแบบสองทิศทางในระยะยาวแบบเรียลไทม์ในขณะที่ REST เหมาะสำหรับการสื่อสารเป็นครั้งคราว การใช้เว็บซ็อกเก็ตเป็นการลงทุนจำนวนมากดังนั้นจึงเป็นการ overkill สำหรับการเชื่อมต่อเป็นครั้งคราว

คุณอาจพบว่า Websockets ทำได้ดีกว่าเมื่อมีการโหลดสูง HTTP ในบางกรณีอาจเร็วกว่านี้เล็กน้อยเนื่องจากสามารถใช้การแคชได้ การเปรียบเทียบ REST กับ Websockets เปรียบเสมือนการเปรียบเทียบแอปเปิ้ลกับส้ม

เราควรตรวจสอบว่าโซลูชันใดให้โซลูชันที่ดีกว่าสำหรับแอปพลิเคชันของเรา

ตัวอย่างของความแตกต่างระหว่าง HTTP และ Websockets ในรูปแบบของ lib- ขนาดไคลเอนต์ที่สามารถจัดการกับจุดสิ้นสุด Websocket เช่น REST APIs และปลายทาง RESTful เช่น Websockets บนไคลเอนต์ https://github.com/mikedeshazer/sockrest นอกจากนี้สำหรับผู้ที่พยายามใช้ websocket API บนไคลเอนต์หรือในทางกลับกันในแบบที่พวกเขาคุ้นเคย libs / sockrest.js สวยมากทำให้ชัดเจนความแตกต่าง (หรือค่อนข้างควรจะ)