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

ฉันได้อ่านเกี่ยวกับ WebSockets API ใหม่ใน HTML5 แต่ดูเหมือนว่าคุณต้องเริ่มการเชื่อมต่อกับเซิร์ฟเวอร์ที่เข้ากันได้กับ WS ก่อนที่จะเริ่มการเชื่อมต่อแบบ full-duplexed ได้ ฉันคิด moreso เกี่ยวกับกระบวนการที่จะทำให้การเชื่อมต่อโดยตรงระหว่างลูกค้ากับเซิร์ฟเวอร์การมีส่วนร่วมเพียงในการจับมือกันครั้งแรก

หมายเหตุ: แอพเพล็ต Java ไม่นับ ฉันสนใจเฉพาะเทคโนโลยีเบราว์เซอร์มาตรฐาน

แทนที่จะเดาอย่างชาญฉลาดนี่คือคำตอบที่มีข้อมูล:

HTML 5 วางแผนที่จะอนุญาตการเชื่อมต่อแบบเพียร์ทูเพียร์จากจาวาสคริปต์ แต่การเชื่อมต่อเหล่านี้จะไม่เป็น RAW TCP

สามารถดูข้อมูลจำเพาะทั้งหมดได้ที่http://dev.w3.org/html5/websockets/

jrh

แก้ไข: ด้วยการอ้างอิงเฉพาะสำหรับการเชื่อมต่อแบบเพียร์ทูเพียร์โปรดดูลิงก์เหล่านี้:

• เกี่ยวกับการเชื่อมต่อแบบเพียร์ทูเพียร์: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
• เกี่ยวกับการเชื่อมต่อการออกอากาศไปยังเครือข่ายท้องถิ่น: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
• เกี่ยวกับการเชื่อมต่อ TCP (ในโปรโตคอลที่เข้ารหัส): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
• ข้อมูลจำเพาะที่เสนอให้ครบถ้วน: http://www.w3.org/TR/2008/WD-html5-20080122/#network

สิ่งสำคัญที่ควรทราบคือความสามารถยังอยู่ในระหว่างการเจรจา จะเป็นการดีที่สามารถสร้างเว็บแอป "แชทท้องถิ่น" ได้ :)

jrh

อัปเดต 10/17/2012:ขณะนี้ฟังก์ชันนี้มีอยู่ใน Chrome Stable v22 แล้ว ในการใช้ฟังก์ชันนี้ใน Chrome หนึ่งต้องเปิดใช้งานแฟล็กสองรายการใน chrome: // flags:

• เปิดใช้งาน MediaStream
• เปิดใช้งาน PeerConnection

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

UPDATE:วิศวกรที่ Ericcson Labs มีหลักฐานของแนวคิดในการสร้าง WebKit ที่ไม่HTML5 Peer เพื่อ Peer สนทนาวิดีโอ

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

พวกเขากำลังดำเนินการเพื่อทำให้สิ่งนี้เสถียรและมุ่งมั่นกับที่เก็บ WebKit

ใช่ในที่สุด

จากการเขียนนี้ (2017) ปัจจุบัน WebRTC เป็นส่วนมาตรฐานของเบราว์เซอร์สมัยใหม่ส่วนใหญ่ (ประมาณ 70% ของเบราว์เซอร์ที่ใช้งานอยู่) และอนุญาตให้สตรีมมัลติมีเดียแบบเพียร์ทูเพียร์และการเจาะรู

เอกสาร, รหัสตัวอย่างและตัวอย่างชีวิตสำหรับ WebRTC สามารถพบได้ที่html5rocks.com

ตามcaniuse.comและhtml5rocks.comเบราว์เซอร์ต่อไปนี้รองรับ WebRTC:

การสนับสนุนเต็มรูปแบบ: Edge 14, Firefox 22, Firefox Android 55
การสนับสนุนบางส่วน: Android Browser 56, Chrome 20, Chrome Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11.4
การสนับสนุนในอนาคต ( Q3 2017): Chrome สำหรับ iOS 11, Safari 11 สำหรับ iOS 11 และ OS X 10.11
ไม่รองรับ: IE, IE Mobile, Opera Mini

อัตราความอิ่มตัวของ WebRTC ถูก จำกัด บนอุปกรณ์ Apple เนื่องจาก Safari 11 ยังไม่เปิดตัวและต้องใช้ iOS 11 หรือ OS X 10.11 แม้ว่าจะคาดการณ์แนวโน้มการอัปเกรดที่ผ่านมา แต่ WebRTC ควรพร้อมใช้งานบนอุปกรณ์ iOS ประมาณ 75% ภายในปี 2018 และ 100% ภายในปี 2020

มีสาเหตุหลายประการที่ทำให้สิ่งนี้ยุ่งยาก:

1. ไฟร์วอลล์ (แม้แต่ NAT ธรรมดา) จะทำให้การเชื่อมต่อประเภทนี้ทำได้ยากที่ชั้นโปรโตคอลที่ต่ำกว่า HTTP เมื่อเปิดหมวกรักษาความปลอดภัยด้านไอทีของฉันดูเหมือนจะเป็นวิธีที่ยอดเยี่ยมในการเปิดพอร์ตตามอำเภอใจบนเครื่องเพียงแค่เข้าไปที่เว็บไซต์และระบบไอทีขององค์กรแทบทั้งหมดจะถูกบล็อกอย่างเข้มงวด
2. HTTP เป็นโปรโตคอลไคลเอนต์เซิร์ฟเวอร์โดยธรรมชาติ แม้ว่าจะง่ายพอสมควรในการจำลองการสื่อสารแบบดูเพล็กซ์โดยใช้การสำรวจความคิดเห็นแบบยาว (รวมถึงเทคนิคอื่น ๆ อีกสองสามอย่าง) แต่ก็ไม่มีประสิทธิภาพโดยเฉพาะ
3. สิ่งนี้จะเปิดช่องโหว่ขนาดใหญ่สำหรับการโจมตี XSS

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

อย่างไรก็ตามมันเป็นเรื่องง่ายที่จะติดตั้งสแต็กเครือข่ายที่เหมาะสมที่ด้านบนของ websockets โดยมีเงื่อนไขว่าการสื่อสารทั้งหมดยังคงต้องทำผ่านเซิร์ฟเวอร์ ฉันได้เห็นสิ่งนี้ทำได้โดยใช้การสำรวจความคิดเห็นแบบยาว (เพื่อนของฉันที่ Uni เขียนสแต็ก TCP / IP แบบเต็มโดยใช้การสำรวจแบบยาว)

ฉันที่สอง harshath.jr: คุณสามารถมีเซิร์ฟเวอร์ที่ทำหน้าที่เป็นไดเร็กทอรีได้เป็นอย่างดี (เปิดเผย "ต้นกำเนิด" ของแต่ละเอเจนต์ที่เชื่อมต่อจุดเริ่มต้นเป็นโครงร่าง + โฮสต์ + พอร์ตเช่นเดียวกับร่าง - ต้นกำเนิดโดยมีแบบแผนเป็น "ws" หรือ "wss") จากนั้นคุณสามารถเริ่มต้นการเชื่อมต่อ WebSocket แบบเพียร์ทูเพียร์ SOPการทำงานผ่านขอบคุณที่ล ธ แน่นอนว่านี่หมายความว่าแต่ละตัวแทน (เช่นเบราว์เซอร์) จะต้องฝังเซิร์ฟเวอร์ WebSocket ของตัวเอง (à la Opera Unite)

ในระหว่างนั้นให้ทำ XMPP / IRC / etc. -way: ไม่มีการเชื่อมต่อแบบเพียร์ทูเพียร์ แต่เชื่อมต่อ WebSocket ไปยังเซิร์ฟเวอร์ส่วนกลาง (หรือเครือข่าย!) เพื่อส่งข้อความไปยังเอเจนต์ที่เชื่อมต่อ (ในที่สุดก็ใช้ WebSocket เฉพาะบางส่วน " โปรโตคอลย่อย ")

แก้ไข: โปรดทราบว่าจริงๆแล้วทั้งหมดนี้อยู่นอกขอบเขตของ HTML5 (สิ่งเหล่านี้ทั้งหมดเคยเป็นส่วนหนึ่งของ HTML5 แต่ถูกแยกออกเป็นข้อกำหนดของตัวเอง)

แนวคิดทั้งหมดของ Web Sockets คือการแก้ปัญหาเกี่ยวกับไฟร์วอลล์และพร็อกซีhttp://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket