WebRTC กับ Websockets: ถ้า WebRTC สามารถทำวิดีโอเสียงและข้อมูลได้ทำไมฉันต้องใช้ Websockets? [ปิด]

ดังนั้นฉันจึงต้องการสร้างแอปแชทที่จะอนุญาตให้ใช้วิดีโอเสียงและข้อความ ฉันใช้เวลาค้นคว้าใน Websockets และ WebRTC เพื่อตัดสินใจว่าจะใช้อะไร เนื่องจากมีแอพวิดีโอและเสียงมากมายที่มี WebRTC นี่เป็นตัวเลือกที่สมเหตุสมผล แต่มีสิ่งอื่น ๆ ที่ฉันควรพิจารณาหรือไม่ แบ่งปันความคิดของคุณ

สิ่งที่ชอบ:

• เนื่องจาก WebRTC ใหม่นั้นมีเฉพาะในบางเบราว์เซอร์ในขณะที่ WebSockets ดูเหมือนจะมีเบราว์เซอร์เพิ่มขึ้น

• Scalability - Websockets ใช้เซิร์ฟเวอร์สำหรับเซสชันและ WebRTC น่าจะเป็น p2p

• มัลติเพล็กซ์ / ห้องแชทหลายห้อง - ใช้ใน Google+ แฮงเอาท์และฉันยังคงดูแอปตัวอย่างเกี่ยวกับวิธีการนำไปใช้

• เซิร์ฟเวอร์ - Websockets ต้องการ RedisSessionStore หรือ RabbitMQ เพื่อขยายข้ามเครื่องหลายเครื่อง

WebRTC ถูกออกแบบมาสำหรับการสื่อสารที่มีประสิทธิภาพสูงคุณภาพของวิดีโอเสียงและข้อมูลโดยพลการ กล่าวอีกนัยหนึ่งสำหรับแอพเหมือนกับที่คุณอธิบาย

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

ในทางกลับกัน WebSocket ถูกออกแบบมาสำหรับการสื่อสารสองทางระหว่างไคลเอนต์และเซิร์ฟเวอร์ เป็นไปได้ที่จะสตรีมเสียงและวิดีโอผ่าน WebSocket (ดูตัวอย่างที่นี่ ) แต่เทคโนโลยีและ API ไม่ได้รับการออกแบบมาเพื่อการสตรีมที่มีประสิทธิภาพและมีประสิทธิภาพในแบบที่ WebRTC เป็น

ดังที่คำตอบอื่น ๆ ได้กล่าวไว้ WebSocket สามารถใช้สำหรับการส่งสัญญาณได้

ฉันเก็บรักษารายการทรัพยากรของWebRTC : ขอแนะนำให้คุณเริ่มต้นโดยดูที่งานนำเสนอ Google I / O 2013 เกี่ยวกับ WebRTC

WebSockets:

• ให้สัตยาบันมาตรฐาน IETF (6455) พร้อมรองรับเบราว์เซอร์ที่ทันสมัยและแม้แต่เบราว์เซอร์รุ่นเก่าที่ใช้โพลีฟิลของ web-socket-js

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

• API เบราว์เซอร์ที่ง่ายกว่ามาก โดยพื้นฐานหนึ่งคอนสตรัคที่มีการเรียกกลับสองสาม

• ไคลเอ็นต์ / เบราว์เซอร์ไปยังเซิร์ฟเวอร์เท่านั้น

• รองรับการขนส่งตามคำสั่งที่เชื่อถือได้เท่านั้นเพราะสร้างขึ้นบน TCP ซึ่งหมายความว่าการส่งแพ็กเก็ตสามารถหน่วงเวลาแพ็กเก็ตถัดไป

WebRTC:

• เพิ่งเริ่มได้รับการสนับสนุนจาก Chrome และ Firefox MS ได้เสนอตัวแปรที่เข้ากันไม่ได้ องค์ประกอบ DataChannel ยังไม่สามารถใช้งานได้ระหว่าง Firefox และ Chrome

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

• Transport layer สามารถกำหนดค่าได้ด้วยแอปพลิเคชันที่สามารถเลือกได้หากการเชื่อมต่อเป็นไปตามลำดับและ / หรือเชื่อถือได้

• API เบราว์เซอร์ที่ซับซ้อนและหลายชั้น มี JS libs เพื่อให้ง่ายขึ้น API แต่สิ่งเหล่านี้ยังใหม่และเปลี่ยนแปลงได้อย่างรวดเร็ว (เช่นเดียวกับ WebRTC เอง)

Websockets ใช้โปรโตคอล TCP

WebRTC เป็น UDP ส่วนใหญ่

ดังนั้นเหตุผลหลักในการใช้ WebRTC แทน Websocket คือความล่าช้า ด้วยการสตรีมแบบ websocket คุณจะมีเวลาหน่วงสูงหรือการเล่นที่ขาด ๆ หาย ๆ โดยมีเวลาหน่วงต่ำ ด้วย WebRTC คุณอาจประสบความล่าช้าในการเล่นและการเล่นที่ราบรื่นซึ่งเป็นสิ่งสำคัญสำหรับการสื่อสาร VoIP

เพียงลองทดสอบเทคโนโลยีเหล่านี้ด้วยการสูญเสียเครือข่ายเช่น 2% คุณจะเห็นความล่าช้าสูงในสตรีม Websocket

webRTC หรือ websockets? ทำไมไม่ใช้ทั้งสองอย่าง

เมื่อสร้างวิดีโอแชท / เสียง / ข้อความแชท webRTC เป็นตัวเลือกที่ดีเนื่องจากใช้เทคโนโลยีเพียร์ทูเพียร์และเมื่อการเชื่อมต่อเริ่มต้นและทำงานคุณไม่จำเป็นต้องผ่านการสื่อสารผ่านเซิร์ฟเวอร์ (เว้นแต่ใช้ TURN)

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

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

ความปลอดภัยเป็นสิ่งที่คุณพลาดไม่ได้

ด้วย Websockets ข้อมูลจะต้องผ่านเว็บเซิร์ฟเวอร์ส่วนกลางซึ่งโดยทั่วไปจะเห็นการรับส่งข้อมูลทั้งหมดและสามารถเข้าถึงได้

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

ขึ้นอยู่กับแอปพลิเคชันของคุณซึ่งอาจจะมีหรือไม่มีก็ได้

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

การเปรียบเทียบ websocket กับ webrtc นั้นไม่ยุติธรรม

Websocket ขึ้นอยู่กับ TCP ขอบเขตของแพ็คเก็ตสามารถตรวจพบได้จากข้อมูลส่วนหัวของแพ็กเก็ต websocket ซึ่งแตกต่างจาก tcp

โดยทั่วไป webrtc ใช้ประโยชน์จาก websocket การส่งสัญญาณสำหรับ webrtc นั้นไม่ได้กำหนดไว้มันขึ้นอยู่กับผู้ให้บริการว่าเขาต้องการใช้การส่งสัญญาณประเภทใด อาจเป็น SIP, HTTP, JSON หรือข้อความ / ไบนารีข้อความใด ๆ

ข้อความการส่งสัญญาณสามารถส่ง / รับโดยใช้ websocket

Webrtc เป็นส่วนหนึ่งของการเชื่อมต่อแบบเพียร์ทูเพียร์ เราทุกคนรู้ว่าก่อนที่จะสร้างการเชื่อมต่อแบบเพียร์ทูเพียร์มันต้องใช้กระบวนการจับมือกันเพื่อสร้างการเชื่อมต่อแบบเพียร์ทูเพียร์ และเว็บซ็อคเก็ตมีบทบาทในกระบวนการจับมือกัน

Websocket และ WebRTC สามารถใช้ร่วมกัน Websocket เป็นช่องสัญญาณของ WebRTC และ webrtc เป็นช่องสัญญาณภาพ / เสียง / ข้อความนอกจากนี้ WebRTC สามารถเป็น UDP ได้ในรีเลย์ TURN รีเลย์ TURN สนับสนุน TCP HTTP และ HTTPS หลายโครงการใช้ Websocket และ WebRTC ร่วมกัน