¿Permitirá HTML5 que las aplicaciones web establezcan conexiones HTTP de igual a igual?

Question

¿Es posible crear una aplicación web que, con la ayuda de un servidor central, pueda crear conexiones directas con otros usuarios de la misma aplicación web? Me estoy imaginando un proceso similar al de perforar UDP.

He leído sobre la nueva API de WebSockets en HTML5, pero parece que debe iniciar la conexión con un servidor compatible con WS antes de que pueda comenzar la conexión dúplex completa. Estoy pensando más acerca de un proceso para hacer conexiones directas entre clientes, con un servidor involucrado solo en el saludo inicial.

NOTA: los applets de Java no cuentan. Estoy interesado solo en las tecnologías de navegador estándar.

Answer 1

En lugar de conjeturas inteligentes, aquí es una respuesta informada:

HTML 5 planes para permitir conexiones par a par de javascript, pero estas conexiones no va a ser TCP RAW.

La especificación completa se puede encontrar en http://dev.w3.org/html5/websockets/

JRH

EDIT: con referencia específica a conexiones par a par, echa un vistazo a estos enlaces:

• En cuanto a conexiones par a par: http://www.w3.org/TR/2008/WD-html5-20080122/#peer-to-peer
• En cuanto a las conexiones de difusión a la red local: http://www.w3.org/TR/2008/WD-html5-20080122/#broadcast
• En cuanto a las conexiones TCP (en el protocolo codificado): http://www.w3.org/TR/2008/WD-html5-20080122/#tcp-connections
• completa de especificaciones propuesta: http://www.w3.org/TR/2008/WD-html5-20080122/#network

Es importante señalar que aún se están negociando las capacidades. Será agradable ser capaz de crear "locales" de chat aplicaciones web :)

JRH

Answer 2

Hay una serie de razones por las que esto sería difícil:

1. Firewalls NAT (incluso apenas aclara) dificultaría este tipo de conexión en una capa de protocolo mucho más baja que incluso HTTP. Con mi sombrero de seguridad de TI, esta parece una forma maravillosa de abrir puertos arbitrarios en una máquina, simplemente visitando un sitio web, por lo que sería virtualmente bloqueado por prácticamente todos los sistemas de TI corporativos.
2. HTTP es intrínsecamente un protocolo de cliente-servidor. Si bien es razonablemente fácil simular comunicaciones dúplex utilizando encuestas largas (así como un par de otras técnicas), no es particularmente eficiente.
3. Esto abriría un agujero grande para los ataques XSS.

WebSockets está diseñado para resolver el segundo de estos problemas, pero (deliberadamente, espero) no los otros dos. Cuando hablan de peer-to-peer en las especificaciones de HTML5, hablan de comunicaciones de dúplex completo entre el servidor y el cliente, no entre un cliente y otro.

Sin embargo, sería sencillo implementar una pila de red adecuada sobre los websockets, con la condición de que toda la comunicación aún tenga que hacerse a través del servidor.He visto esto hecho usando largas encuestas (un amigo mío en Uni escribió una pila completa de TCP/IP usando largas encuestas).

Answer 3

I second harshath.jr: muy bien podría tener un servidor actuando como un directorio (exponiendo los "orígenes" de cada agente conectado; el origen es esquema + host + puerto como en draft-abarth-origin, con el esquema siendo "ws" o "wss"). Luego puede iniciar conexiones WebSocket punto a punto; el SOP se trabajó gracias a CORS. Por supuesto, esto significa que cada agente (es decir, el navegador) debería incrustar su propio servidor WebSocket (à la Opera Unite).

Mientras tanto, hágalo a través de XMPP/IRC/etc.: sin conexión de igual a igual pero con conexiones WebSocket a un servidor central (o red!) Para pasar mensajes a los agentes conectados (utilizando algunos WebSocket específica "subprotocolo")

EDIT: tenga en cuenta que todo esto es en realidad fuera del alcance de HTML5 (todas esas cosas eran una vez parte de HTML5, pero se han dividido lejos en sus propias especificaciones)

Answer 4

el Toda la idea de Web Sockets fue resolver los problemas con Firewalls y proxies http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket

Answer 5

ACTUALIZACIÓN 10/17/2012: Esta funcionalidad ahora existe en Chrome Stable v22. Para utilizar esta funcionalidad en Chrome, se debe permitir que dos banderas en chrome: // flags:

• Habilitar MediaStream
• Habilitar PeerConnection

A continuación, se puede visitar el AppRTC Demo Page de probar el manifestación. Consulte la página WebRTC - Running the Demos para obtener instrucciones más detalladas sobre la configuración de Chrome para usar la funcionalidad punto a punto y habilitar la captura del dispositivo.

---

ACTUALIZACIÓN: Los ingenieros de Ericcson laboratorios tienen una prueba de concepto en una versión de WebKit que hace HTML5 Peer to Peer Conversational Video.

Tienen demostraciones en su blog de la tecnología en acción, así como diagramas y explicaciones sobre cómo funcionará la tecnología.

Están trabajando para conseguir esto estabilizado y comprometido con el repositorio WebKit.

Answer 6

Sí, finalmente.

En el momento de escribir esto (2017), WebRTC ahora es una parte estándar de la mayoría de los navegadores modernos (alrededor del 70% de los que se usan), y permite la transmisión multimedia, peer-to-peer y hole-punching.

Documentos, código de ejemplo y ejemplos en vivo de WebRTC se pueden encontrar en html5rocks.com.

Según caniuse.com y html5rocks.com, los siguientes navegadores son compatibles con WebRTC:

Soporte completo: Edge 14, Firefox 22, Firefox Android 55
apoyo parcial: navegador de Android 56, Chrome 20, Chrome para Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11.4
El apoyo futuro (Q3 2017): Chrome para iOS 11, Safari 11 para iOS 11 y OS X 10.11
No hay soporte: IE, IE Mobile, Opera Mini

La tasa de saturación de WebRTC es limitado en dispositivos Apple, ya que Safari 11 aún no se ha lanzado y requiere iOS 11 u OS X 10.11. Aunque se proyecta a partir de tendencias de actualización pasadas, WebRTC debería estar disponible en alrededor del 75% de los dispositivos iOS para 2018 y 100% para 2020.