2009-06-23 33 views
94

Có thể tạo một ứng dụng web, với sự giúp đỡ của một máy chủ trung tâm, có thể tạo kết nối trực tiếp với những người dùng khác của cùng một ứng dụng web không? Tôi đang tưởng tượng một quá trình tương tự như đấm lỗ UDP.HTML5 có cho phép ứng dụng web tạo kết nối HTTP ngang hàng không?

Tôi đã đọc về API WebSockets mới trong HTML5, nhưng có vẻ như bạn phải khởi tạo kết nối với máy chủ tương thích với WS trước khi kết nối song công có thể bắt đầu. Tôi đang nghĩ về moreso về quy trình tạo kết nối trực tiếp giữa khách hàng, với máy chủ chỉ tham gia chỉ trong lần bắt tay đầu tiên.

LƯU Ý: Java applet không được tính. Tôi chỉ quan tâm đến các công nghệ trình duyệt chuẩn.

+0

có thể liên quan: [Làm cách nào để nhận dữ liệu với kết nối ngang hàng ngang hàng?] (Http : //stackoverflow.com/questions/20166067/how-can-i-receive-data-with-a-peerjs-peer-to-peer-connection) –

Trả lời

104

Thay vì suy đoán thông minh, đây là một câu trả lời thông báo:

HTML 5 kế hoạch để cho phép ngang ngang nhau để kết nối từ javascript, nhưng những kết nối này SẼ KHÔNG RAW TCP.

Các spec đầy đủ có thể được tìm thấy tại http://dev.w3.org/html5/websockets/

jrh

EDIT: với tài liệu tham khảo cụ thể để ngang ngang nhau để kết nối, hãy kiểm tra các liên kết:

của nó quan trọng cần lưu ý rằng khả năng vẫn đang được đàm phán. Nó sẽ được tốt đẹp để có thể tạo ra "trò chuyện địa phương" các ứng dụng web :)

jrh

+43

+1 => "Thay vì đoán thông minh, đây là thông báo answer " –

+2

WebSocket có cho phép kết nối với BẤT K host máy chủ nào không? Tôi tin rằng spec nói chỉ máy chủ. – hegemon

+4

Ổ cắm web không còn là một phần của HTML5 nữa mà là một đặc điểm độc lập. –

3

Có một số lý do tại sao điều này sẽ được khôn lanh:

  1. Tường lửa (thậm chí chỉ đơn giản NAT) sẽ làm cho loại kết nối này gặp khó khăn ở lớp protocal thấp hơn nhiều so với cả HTTP. Với mũ bảo mật CNTT của tôi, điều này có vẻ giống như một cách tuyệt vời để mở các cổng tùy ý trên máy tính, chỉ bằng cách truy cập một trang web - và vì vậy nó sẽ bị chặn bởi hầu hết các hệ thống CNTT của công ty.
  2. HTTP vốn đã là giao thức máy khách-máy chủ. Mặc dù rất dễ dàng để mô phỏng các giao tiếp song công bằng cách sử dụng phép bỏ phiếu dài (cũng như một vài kỹ thuật khác), nhưng nó không đặc biệt hiệu quả.
  3. Điều này sẽ mở một lỗ hổng lớn cho các cuộc tấn công XSS.

WebSockets được thiết kế để giải quyết vấn đề thứ hai của những vấn đề này, nhưng (cố ý, tôi mong đợi) chứ không phải hai vấn đề còn lại. Khi họ nói về peer-to-peer trong spec HTML5, họ đang nói về truyền thông song công đầy đủ giữa máy chủ và máy khách, không phải giữa một máy khách và máy khách khác.

Tuy nhiên, việc triển khai một ngăn xếp mạng thích hợp trên đầu trang của websockets sẽ đơn giản - với điều kiện là tất cả các giao tiếp sẽ vẫn phải được thực hiện thông qua máy chủ.Tôi đã thấy điều này được thực hiện bằng cách sử dụng bỏ phiếu dài (một người bạn của tôi tại Uni đã viết một ngăn xếp TCP/IP đầy đủ bằng cách sử dụng phiếu thăm dò ý kiến ​​dài).

+0

P2P không phải là máy khách-máy chủ; di chuyển trước đây lưu lượng truy cập giữa các đồng nghiệp, sau đó di chuyển nó thông qua máy chủ đến một hoặc nhiều khách hàng. Lợi ích chính của P2P là một máy chủ có thể hoạt động như một người mai mối trong khi lưu lượng truy cập lớn giữa các khách hàng (đó là một lợi ích cho sự riêng tư và băng thông). – Beejor

0

Tôi thứ hai harshath.jr: bạn có thể có một máy chủ hoạt động như một thư mục (hiển thị "nguồn gốc" của mỗi tác nhân được kết nối; nguồn gốc là sơ đồ + máy chủ + cổng như trong draft-abarth-origin, với lược đồ là "ws" hoặc "wss"). Sau đó bạn có thể khởi tạo các kết nối WebSocket ngang hàng; các SOP được làm việc thông qua nhờ CORS. Tất nhiên, điều này có nghĩa là mỗi tác nhân (tức là trình duyệt) sẽ phải nhúng máy chủ WebSocket của riêng mình (à la Opera Unite).

Đồng thời, thực hiện theo cách XMPP/IRC/vv: không có kết nối ngang hàng nhưng kết nối WebSocket với máy chủ trung tâm (hoặc mạng!) Để truyền tin nhắn tới các tác nhân được kết nối (cuối cùng sử dụng một số WebSocket cụ thể "subprotocol")

EDIT: lưu ý rằng tất cả điều này là thực sự nằm ngoài phạm vi của HTML5 (tất cả những điều đó đã từng là một phần của HTML5 nhưng đã được tách ra đi vào thông số kỹ thuật của riêng mình)

28

CẬP NHẬT 10/17/2012: Chức năng này hiện có trong Chrome Stable v22. Để sử dụng chức năng này trong Chrome, người ta phải cho phép hai cờ trong chrome: // flags:

  • Bật MediaStream
  • Enable PeerConnection

Sau đó, bạn có thể ghé thăm AppRTC Demo Page để thử bản giới thiệu. Xem trang WebRTC - Running the Demos để biết thêm hướng dẫn chi tiết về cách thiết lập Chrome để sử dụng chức năng ngang hàng ngang hàng và cho phép chụp thiết bị.


UPDATE: Các kỹ sư tại Ericcson Labs có một bằng chứng của khái niệm trong một build WebKit mà không HTML5 Peer to Peer Conversational Video.

Họ có các cuộc biểu tình trong blog của họ về công nghệ đang hoạt động, cũng như sơ đồ và giải thích về cách công nghệ sẽ hoạt động.

Họ đang nỗ lực để ổn định và cam kết với kho lưu trữ WebKit.

+0

Bạn ước tính được bao lâu trước khi nó ở trong WebKit? – Alistair

+0

Tôi không biết. Tôi đề nghị kiểm tra với Ericcson. Liên kết nằm trong câu trả lời của tôi. Diễn đàn của họ có thể có thông tin về thời điểm đó. – jmort253

+0

Yêu cầu cài đặt cấu hình/gắn cờ cho mỗi trình duyệt đặc biệt không giống như một phần của thông số chuẩn web đang hoạt động. Nếu nó không có trong HTML5, WebSockets, hoặc WebRTC out-of-the-box, thì bạn không thể làm peer-to-peer mà không có hack. May mắn thay có vẻ như WebRTC đang đi đúng hướng. – Beejor

4

Có, cuối cùng.

Theo văn bản này (2017), WebRTC hiện là một phần tiêu chuẩn của hầu hết các trình duyệt hiện đại (khoảng 70% số người dùng) và cho phép truyền trực tuyến đa phương tiện, ngang hàng và đục lỗ.

Tài liệu, mã mẫu và ví dụ trực tiếp cho WebRTC có thể được tìm thấy tại html5rocks.com.

Theo caniuse.comhtml5rocks.com, các trình duyệt sau hỗ trợ WebRTC:

Hỗ trợ đầy đủ: Edge 14, Firefox 22, Firefox Android 55
hỗ trợ từng phần: Trình duyệt Android 56, Chrome 20, Chrome Android 29, Cạnh 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11.4
hỗ trợ trong tương lai (Q3 2017): Chrome dành cho iOS 11, Safari 11 dành cho iOS 11 và OS X 10.11
Không hỗ trợ: IE, IE di động, Opera Mini

Tỷ lệ bão hòa của WebRTC được là giới hạn trên các thiết bị của Apple, vì Safari 11 chưa được phát hành và yêu cầu iOS 11 hoặc OS X 10.11. Mặc dù chiếu từ xu hướng nâng cấp trong quá khứ, WebRTC sẽ khả dụng trên khoảng 75% thiết bị iOS vào năm 2018 và 100% vào năm 2020.

Các vấn đề liên quan