ความเข้าใจของฉันเกี่ยวกับ HTTP Polling, Long Polling, HTTP Streaming และ WebSockets

ฉันได้อ่านบทความมากมายใน SO และเว็บเกี่ยวกับคำหลักในหัวข้อคำถามของฉันและได้เรียนรู้มากมายจากพวกเขา คำถามบางคำถามที่ฉันอ่านเกี่ยวข้องกับความท้าทายในการนำไปใช้งานที่เฉพาะเจาะจงในขณะที่คำถามอื่น ๆ มุ่งเน้นไปที่แนวคิดทั่วไป ฉันแค่อยากให้แน่ใจว่าฉันเข้าใจแนวคิดทั้งหมดและเหตุผลว่าทำไมเทคโนโลยี X จึงถูกคิดค้นขึ้นเหนือเทคโนโลยี Y และอื่น ๆ ต่อไปนี้:

Http Polling:โดยทั่วไป AJAX โดยใช้ XmlHttpRequest

Http Long Polling: AJAX แต่เซิร์ฟเวอร์ยังคงตอบสนองต่อไปเว้นแต่เซิร์ฟเวอร์จะมีการอัปเดตทันทีที่เซิร์ฟเวอร์มีการอัปเดตเซิร์ฟเวอร์จะส่งไปจากนั้นไคลเอ็นต์สามารถส่งคำขออื่นได้ ข้อเสียคือข้อมูลส่วนหัวเพิ่มเติมที่ต้องส่งไปมาทำให้เกิดค่าใช้จ่ายเพิ่มเติม

Http Streaming:คล้ายกับการสำรวจความคิดเห็นแบบยาว แต่เซิร์ฟเวอร์ตอบสนองด้วยส่วนหัวด้วย "Transfer Encoding: chunked" ดังนั้นเราจึงไม่จำเป็นต้องเริ่มต้นคำขอใหม่ทุกครั้งที่เซิร์ฟเวอร์ส่งข้อมูลบางส่วน (ดังนั้นจึงบันทึกค่าใช้จ่ายส่วนหัวเพิ่มเติม) ข้อเสียเปรียบตรงนี้คือเราต้อง "เข้าใจ" และคิดโครงสร้างของข้อมูลเพื่อแยกความแตกต่างระหว่างชิ้นส่วนต่างๆที่เซิร์ฟเวอร์ส่งมา

Java Applet, Flash, Silverlight:พวกเขาให้ความสามารถในการเชื่อมต่อกับเซิร์ฟเวอร์ซ็อกเก็ตผ่าน tcp / ip แต่เนื่องจากเป็นปลั๊กอินนักพัฒนาจึงไม่ต้องการพึ่งพาพวกเขา

WebSockets:เป็น API ใหม่ที่พยายามแก้ไขปัญหาสั้น ๆ ของวิธีการข้างต้นในลักษณะต่อไปนี้:

• ข้อได้เปรียบประการเดียวของ WebSockets ที่มีต่อปลั๊กอินเช่น Java Applets, Flash หรือ Silverlight คือ WebSockets ถูกสร้างขึ้นในเบราว์เซอร์และไม่ต้องพึ่งพาปลั๊กอิน
• ข้อดีอย่างเดียวของ WebSockets ผ่านการสตรีม http คือคุณไม่ต้องพยายาม "ทำความเข้าใจ" และแยกวิเคราะห์ข้อมูลที่ได้รับ
• ข้อดีประการเดียวของ WebSockets ใน Long Polling คือการกำจัดขนาดส่วนหัวพิเศษและการเปิดและปิดการเชื่อมต่อซ็อกเก็ตสำหรับการร้องขอ

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

ขอบคุณ!

มีความแตกต่างมากกว่าที่คุณระบุ

เพล็กซ์ / ทิศทาง:

• Uni-directional: แบบสำรวจ HTTP, แบบสำรวจยาว, สตรีมมิง
• Bi-Direcitonal: WebSockets เครือข่ายปลั๊กอิน

ตามลำดับเวลาในการตอบสนองที่เพิ่มขึ้น (โดยประมาณ):

• WebSockets
• เครือข่ายปลั๊กอิน
• สตรีมมิ่ง HTTP
• การสำรวจความคิดเห็นแบบยาว HTTP
• การสำรวจ HTTP

CORS (รองรับข้ามแหล่งกำเนิด):

• WebSockets: ใช่
• เครือข่ายปลั๊กอิน: Flash ผ่านคำขอนโยบาย (ไม่แน่ใจเกี่ยวกับผู้อื่น)
• HTTP * (การสนับสนุนล่าสุดบางส่วน)

ข้อมูลไบนารีดั้งเดิม (อาร์เรย์ที่พิมพ์, blobs):

• WebSockets: ใช่
• เครือข่ายปลั๊กอิน: ไม่ใช้ Flash (ต้องใช้การเข้ารหัส URL ผ่าน ExternalInterface)
• HTTP *: ข้อเสนอล่าสุดเพื่อเปิดใช้งานการสนับสนุนประเภทไบนารี

แบนด์วิดท์ในการลดประสิทธิภาพ:

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

การสนับสนุนอุปกรณ์เคลื่อนที่:

• WebSocket: iOS 4.2 ขึ้นไป Android บางรุ่นผ่านการจำลอง Flash หรือใช้Firefox สำหรับ AndroidหรือGoogle Chrome สำหรับ Androidซึ่งทั้งสองให้การสนับสนุน WebSocket ในตัว
• เครือข่ายปลั๊กอิน: Android บางรุ่น ไม่ใช่บน iOS
• HTTP *: ส่วนใหญ่ใช่

ความซับซ้อนในการใช้งาน Javascript (จากง่ายที่สุดไปจนถึงซับซ้อนที่สุด) การวัดความซับซ้อนที่ยอมรับได้นั้นค่อนข้างเป็นเรื่องส่วนตัว

• WebSockets
• แบบสำรวจ HTTP
• เครือข่ายปลั๊กอิน
• แบบสำรวจความยาว HTTP สตรีมมิ่ง

นอกจากนี้ยังทราบว่ามีข้อเสนอ W3C สำหรับมาตรฐาน HTTP สตรีมมิ่งที่เรียกว่าเหตุการณ์เซิร์ฟเวอร์ส่ง ปัจจุบันเป็นวิวัฒนาการที่ค่อนข้างเร็วและได้รับการออกแบบมาเพื่อให้ Javascript API มาตรฐานที่มีความเรียบง่ายเทียบเท่ากับ WebSockets

คำตอบที่ดีบางอย่างจากผู้อื่นซึ่งครอบคลุมพื้นที่มากมาย นี่เป็นข้อมูลเพิ่มเติมเล็กน้อย

ข้อได้เปรียบประการเดียวของ WebSockets ที่มีต่อปลั๊กอินเช่น Java Applets, Flash หรือ Silverlight คือ WebSockets ถูกสร้างขึ้นในเบราว์เซอร์และไม่ต้องพึ่งพาปลั๊กอิน

หากเป็นเช่นนี้คุณหมายความว่าคุณสามารถใช้ Java Applets, Flash หรือ Silverlight เพื่อสร้างการเชื่อมต่อซ็อกเก็ตใช่นั่นเป็นไปได้ อย่างไรก็ตามคุณไม่เห็นว่ามีการใช้งานในโลกแห่งความเป็นจริงบ่อยเกินไปเนื่องจากข้อ จำกัด

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

นอกจากนี้ WebSocket ยังสามารถใช้พอร์ต 80 และ 443 ได้โดยไม่ต้องใช้พอร์ตเฉพาะอีกครั้งด้วยการออกแบบโปรโตคอลให้เข้ากันได้กับโครงสร้างพื้นฐาน HTTP ที่มีอยู่ให้มากที่สุด

ทางเลือกของซ็อกเก็ตเหล่านั้น (Java, Flash และ Silverlight) ยากที่จะใช้อย่างปลอดภัยในสถาปัตยกรรมข้ามแหล่งกำเนิด ดังนั้นผู้คนที่พยายามใช้สิ่งเหล่านี้ข้ามแหล่งกำเนิดมักจะทนต่อความไม่ปลอดภัยมากกว่าที่จะพยายามทำอย่างปลอดภัย

นอกจากนี้ยังสามารถกำหนดให้เปิดพอร์ต "ที่ไม่ได้มาตรฐาน" เพิ่มเติมได้ (สิ่งที่ผู้ดูแลระบบไม่อยากทำ) หรือไฟล์นโยบายที่ต้องจัดการ

ในระยะสั้นการใช้ Java, Flash หรือ Silverlight สำหรับการเชื่อมต่อซ็อกเก็ตนั้นมีปัญหามากพอที่คุณจะไม่เห็นว่ามีการใช้งานในสถาปัตยกรรมที่จริงจังบ่อยเกินไป Flash และ Java มีความสามารถนี้มาแล้วอย่างน้อย 10 ปี แต่ยังไม่แพร่หลาย

มาตรฐาน WebSocket สามารถเริ่มต้นด้วยแนวทางใหม่โดยคำนึงถึงข้อ จำกัด เหล่านั้นและหวังว่าจะได้เรียนรู้บทเรียนจากพวกเขา

การใช้งาน WebSocket บางอย่างใช้ Flash (หรืออาจเป็น Silverlight และ / หรือ Java) เป็นทางเลือกเมื่อไม่สามารถสร้างการเชื่อมต่อ WebSocket ได้ (เช่นเมื่อทำงานในเบราว์เซอร์เก่าหรือเมื่อตัวกลางรบกวน)

แม้ว่ากลยุทธ์ทางเลือกบางประเภทสำหรับสถานการณ์เหล่านั้นจะฉลาด แต่ก็จำเป็น แต่ส่วนใหญ่ที่ใช้ Flash และคณะจะประสบกับข้อเสียที่อธิบายไว้ข้างต้น ไม่จำเป็นต้องเป็นอย่างนั้น - มีวิธีแก้ปัญหาเพื่อให้ได้การเชื่อมต่อข้ามแหล่งที่มาที่ปลอดภัยโดยใช้ Flash, Silverlight เป็นต้น แต่การใช้งานส่วนใหญ่จะไม่ทำเช่นนั้นเพราะไม่ใช่เรื่องง่าย

ตัวอย่างเช่นหากคุณใช้ WebSocket สำหรับการเชื่อมต่อข้ามแหล่งที่มาก็จะทำงานได้ดี แต่ถ้าคุณเรียกใช้ในเบราว์เซอร์รุ่นเก่าหรือไฟร์วอลล์ / พร็อกซีรบกวนและพึ่งพา Flash กล่าวว่าในฐานะทางเลือกของคุณคุณจะพบว่าการเชื่อมต่อข้ามแหล่งกำเนิดเดียวกันนั้นทำได้ยาก เว้นแต่คุณจะไม่สนใจเรื่องความปลอดภัยแน่นอน

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

ข้อดีอย่างเดียวของ WebSockets ผ่านการสตรีม http คือคุณไม่ต้องพยายาม "ทำความเข้าใจ" และแยกวิเคราะห์ข้อมูลที่ได้รับ

ไม่ง่ายเหมือนการเปิดสตรีม HTTP และนั่งสำรองขณะที่ข้อมูลของคุณไหลเป็นนาทีชั่วโมงหรือนานกว่านั้น ลูกค้าที่แตกต่างกันมีพฤติกรรมที่แตกต่างกันและคุณต้องจัดการสิ่งนั้น ตัวอย่างเช่นไคลเอนต์บางรายจะทำการบัฟเฟอร์ข้อมูลและไม่ปล่อยข้อมูลไปยังแอปพลิเคชันจนกว่าจะมีคุณสมบัติตรงตามเกณฑ์ ที่แย่กว่านั้นคือบางส่วนจะไม่ส่งข้อมูลไปยังแอปพลิเคชันจนกว่าจะปิดการเชื่อมต่อ

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

แม้ว่าการสตรีม HTTP อาจเป็นทางเลือกที่ดีเมื่อไม่มี WebSocket แต่ก็ไม่ใช่ยาครอบจักรวาล จำเป็นต้องมีความเข้าใจที่ดีในการทำงานอย่างมีประสิทธิภาพในพื้นที่เลวร้ายของเว็บในสภาพโลกแห่งความเป็นจริง

มีความแตกต่างที่สำคัญอื่น ๆ ที่ฉันขาดหายไปหรือไม่?

ยังมีอีกสิ่งหนึ่งที่ยังไม่มีใครพูดถึงฉันจะนำมากล่าว

โปรโตคอล WebSocket ได้รับการออกแบบให้เป็นเลเยอร์การขนส่งสำหรับโปรโตคอลระดับสูง แม้ว่าคุณจะสามารถส่งข้อความ JSON หรือสิ่งที่ไม่ได้โดยตรงผ่านการเชื่อมต่อ WebSocket แต่ก็ยังสามารถใช้โปรโตคอลมาตรฐานหรือแบบกำหนดเองได้

ตัวอย่างเช่นคุณสามารถทำ AMQP หรือ XMPP ผ่าน WebSocket ได้ตามที่ผู้คนเคยทำมาแล้ว ดังนั้นลูกค้าสามารถรับข้อความจากนายหน้า AMQP ราวกับว่ามันเชื่อมต่อโดยตรงกับนายหน้าเอง (และในบางกรณีก็เป็นเช่นนั้น)

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

(โดยปกติแล้วคุณต้องการที่จะทำทุกอย่างได้อย่างปลอดภัยดังนั้นโปรดตรวจสอบกับผู้ขายหรือผู้ให้บริการ WebSocket)

บางคนเรียก WebSocket ว่า TCP สำหรับเว็บ เนื่องจากเช่นเดียวกับ TCP ขนส่งโปรโตคอลระดับสูงขึ้น WebSocket ก็เช่นกัน แต่เป็นวิธีที่เข้ากันได้กับโครงสร้างพื้นฐานของเว็บ

ดังนั้นในขณะที่ส่งข้อความ JSON (หรืออะไรก็ได้) โดยตรงผ่าน WebSocket จึงเป็นไปได้เสมอเราควรพิจารณาโปรโตคอลที่มีอยู่ด้วย เพราะสำหรับหลาย ๆ สิ่งที่คุณต้องการทำอาจมีโปรโตคอลที่คิดไว้แล้วว่าจะทำ

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

นี่เป็นคำถามที่ดีมากและคำตอบทั้งหมดให้ข้อมูลมาก!

หากฉันอาจถามสิ่งอื่นเพิ่มเติม: ฉันเจอในบทความบางแห่งที่บอกว่าการสตรีม http อาจถูกแคชโดยพร็อกซีในขณะที่ websockets ไม่ได้ นั่นหมายความว่าอย่างไร?

(StackOverflow จำกัด ขนาดของการตอบกลับความคิดเห็นดังนั้นฉันจึงต้องตอบที่นี่แทนที่จะตอบแบบอินไลน์)

นั่นเป็นจุดที่ดี เพื่อให้เข้าใจสิ่งนี้ลองนึกถึงสถานการณ์ HTTP แบบเดิม ... ลองนึกภาพว่าเบราว์เซอร์เปิดหน้าเว็บดังนั้นจึงขอhttp://example.comกล่าว เซิร์ฟเวอร์ตอบสนองด้วย HTTP ที่มี HTML สำหรับเพจ จากนั้นเบราว์เซอร์จะเห็นว่ามีทรัพยากรในหน้าเว็บจึงเริ่มขอไฟล์ CSS ไฟล์ JavaScript และรูปภาพ ไฟล์เหล่านี้เป็นไฟล์แบบคงที่ซึ่งจะเหมือนกันสำหรับไคลเอนต์ทั้งหมดที่ร้องขอ

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

ดังนั้นลูกค้า # 1 จึงขอhttp://example.com/images/logo.gifพูด คำขอนั้นจะส่งผ่านพร็อกซีไปจนถึงเว็บเซิร์ฟเวอร์กลางซึ่งทำหน้าที่ขึ้น logo.gif ในฐานะที่เป็น logo.gif ผ่านพร็อกซี่พร็อกซี่จะบันทึกภาพที่และเชื่อมโยงกับที่อยู่http://example.com/images/logo.gif

เมื่อไคลเอนต์ # 2 มาพร้อมและขอhttp://example.com/images/logo.gifพร็อกซีจะส่งคืนรูปภาพและไม่จำเป็นต้องสื่อสารกลับไปยังเว็บเซิร์ฟเวอร์ที่อยู่ตรงกลาง สิ่งนี้ให้การตอบสนองที่เร็วกว่าสำหรับผู้ใช้ปลายทางซึ่งเป็นสิ่งที่ดีเสมอ แต่ก็หมายความว่ามีภาระน้อยลง นั่นสามารถแปลเป็นต้นทุนฮาร์ดแวร์ที่ลดลงต้นทุนเครือข่ายที่ลดลง ฯลฯ ดังนั้นจึงเป็นเรื่องที่ดี

ปัญหาเกิดขึ้นเมื่ออัปเดต logo.gif บนเว็บเซิร์ฟเวอร์ พร็อกซีจะให้บริการรูปภาพเก่าต่อไปโดยที่ไม่รู้ว่ามีรูปภาพใหม่ สิ่งนี้นำไปสู่การหมดอายุทั้งหมดดังนั้นพร็อกซีจะแคชรูปภาพในช่วงเวลาสั้น ๆ เท่านั้นก่อนที่จะ "หมดอายุ" และคำขอถัดไปจะส่งผ่านพร็อกซีไปยังเว็บเซิร์ฟเวอร์ซึ่งจะรีเฟรชแคชของพร็อกซี นอกจากนี้ยังมีโซลูชันขั้นสูงเพิ่มเติมที่เซิร์ฟเวอร์กลางสามารถผลักดันไปยังแคชที่รู้จักและอื่น ๆ และสิ่งต่างๆก็ค่อนข้างซับซ้อน

สิ่งนี้เกี่ยวข้องกับคำถามของคุณอย่างไร?

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

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

ดังนั้นหากลูกค้าของคุณส่งคำขอราคาหุ้นพูดและได้รับคำตอบจากนั้นลูกค้ารายต่อไปอาจส่งคำขอเดียวกันและรับข้อมูลแคช อาจไม่ใช่สิ่งที่คุณต้องการ! หากคุณขอราคาหุ้นคุณต้องการข้อมูลล่าสุดใช่ไหม?

มันจึงเป็นปัญหา

มีเทคนิคและวิธีแก้ปัญหาในการจัดการปัญหาเช่นนั้นเป็นเรื่องจริง เห็นได้ชัดว่าคุณสามารถใช้งานการสตรีม HTTP ได้เนื่องจากมีการใช้งานอยู่ในปัจจุบัน ผู้ใช้ปลายทางทุกคนมีความโปร่งใส แต่ผู้ที่พัฒนาและดูแลสถาปัตยกรรมเหล่านั้นต้องกระโดดข้ามห่วงและจ่ายราคา ส่งผลให้สถาปัตยกรรมมีความซับซ้อนมากเกินไปซึ่งหมายถึงการบำรุงรักษาที่มากขึ้นฮาร์ดแวร์มากขึ้นความซับซ้อนมากขึ้นค่าใช้จ่ายที่มากขึ้น นอกจากนี้ยังหมายความว่านักพัฒนามักจะต้องใส่ใจเกี่ยวกับสิ่งที่ไม่ควรมีเมื่อพวกเขาควรจะมุ่งเน้นไปที่แอปพลิเคชัน GUI และตรรกะทางธุรกิจ - พวกเขาไม่ควรต้องกังวลเกี่ยวกับการสื่อสารพื้นฐาน

HTTP จำกัด จำนวนการเชื่อมต่อที่ไคลเอนต์สามารถมีกับเซิร์ฟเวอร์ไว้ที่ 2 (แม้ว่าจะสามารถลดขนาดได้โดยใช้โดเมนย่อย) และ IE เป็นที่ทราบกันดีว่าบังคับใช้สิ่งนี้อย่างกระตือรือร้น Firefox และ Chrome อนุญาตให้มากขึ้น (แม้ว่าฉันจะจำไม่ได้ว่ามีกี่ตัวก็ตาม) สิ่งนี้อาจดูเหมือนไม่ใช่ปัญหาใหญ่ แต่หากคุณใช้การเชื่อมต่อ 1 รายการอย่างต่อเนื่องสำหรับการอัปเดตแบบเรียลไทม์คำขออื่น ๆ ทั้งหมดจะต้องคอขวดผ่านการเชื่อมต่อ HTTP อื่น ๆ และมีเรื่องของการมีการเชื่อมต่อที่เปิดมากขึ้นจากไคลเอนต์ทำให้เซิร์ฟเวอร์มีภาระมากขึ้น

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