HTML5 permettra-t-il aux applications Web d'établir des connexions HTTP peer-to-peer?

100

Est-il possible de créer une application Web qui, avec l'aide d'un serveur central, pourrait créer des connexions directes avec d'autres utilisateurs de la même application Web? J'imagine un processus similaire à la perforation UDP.

J'ai lu sur la nouvelle API WebSockets en HTML5, mais il semble que vous deviez initier la connexion avec un serveur compatible WS avant que la connexion en duplex intégral puisse commencer. Je pense plus à un processus pour établir des connexions directes entre les clients, avec un serveur n'intervenant que dans la poignée de main initiale.

REMARQUE: les applets Java ne comptent pas. Je ne suis intéressé que par les technologies de navigateur standard.

javascript ajax html Peter O.
la source
éventuellement lié: Comment puis-je recevoir des données avec une connexion peerJS peer to peer?
David Cary

Réponses:

109

Au lieu de suppositions intelligentes, voici une réponse éclairée:

HTML 5 prévoit d'autoriser les connexions peer-to-peer à partir de javascript, mais ces connexions NE SERONT PAS RAW TCP.

La spécification complète peut être trouvée à http://dev.w3.org/html5/websockets/

jrh

EDIT: avec une référence spécifique aux connexions peer to peer, consultez ces liens:

Il est important de noter que les capacités sont toujours en cours de négociation. Ce sera bien de pouvoir créer des applications Web de "chat local" :)

jrh

jrharshath
la source
45
+1 => "Au lieu de suppositions intelligentes, voici une réponse éclairée"
Ionuț G. Stan
2
WebSocket permet-il de se connecter à N'IMPORTE QUEL hôte? Je crois que les spécifications indiquent uniquement le serveur.
hegemon
4
Web Sockets ne fait plus partie de HTML5, mais une spécification autonome.
Sergey Ilinsky
8
Les WebSockets ne sont pas d'égal à égal - ils sont toujours client à serveur et les navigateurs n'implémentent pas la moitié du serveur.
Alnitak
4
webSockets ne fait pas d'égal à égal, mais une spécification plus récente, WebRTC, est conçue pour cela.
Eric Mill
29

MISE À JOUR 17/10/2012: cette fonctionnalité existe désormais dans Chrome Stable v22. Pour utiliser cette fonctionnalité dans Chrome, il faut activer deux indicateurs dans chrome: // flags:

  • Activer MediaStream
  • Activer PeerConnection

Ensuite, vous pouvez visiter la page de démonstration AppRTC pour essayer la démo. Consultez la page WebRTC - Exécution de la démonstration pour obtenir des instructions plus détaillées sur la configuration de Chrome pour utiliser la fonctionnalité peer to peer et l'activation de la capture d'appareil.

MISE À JOUR: Les ingénieurs d'Ericcson Labs ont une preuve de concept dans une version WebKit qui fait de la vidéo conversationnelle HTML5 Peer to Peer .

Ils ont des démonstrations sur leur blog de la technologie en action, ainsi que des diagrammes et des explications sur le fonctionnement de la technologie.

Ils travaillent à la stabilisation et à la validation de cela dans le référentiel WebKit.

jmort253
la source
Combien de temps estimez-vous qu'il faudra avant que ce soit dans WebKit?
Alistair
Je ne sais pas. Je suggère de vérifier avec Ericcson. Le lien est dans ma réponse. Leurs forums peuvent avoir des informations sur le moment.
jmort253
Exiger des paramètres de configuration / d'indicateur spéciaux par navigateur n'est pas la même chose que de faire partie d'une spécification standard Web opérationnelle. Si ce n'est pas dans HTML5, WebSockets ou WebRTC prêt à l'emploi, vous ne pouvez pas faire de peer-to-peer sans hacks. Heureusement, il semble que WebRTC va dans la bonne direction.
Beejor
11

Oui enfin.

Au moment de la rédaction de cet article (2017), WebRTC fait désormais partie intégrante de la plupart des navigateurs modernes (environ 70% de ceux utilisés) et permet le streaming multimédia, le peer-to-peer et la perforation.

Des documents, des exemples de code et des exemples en direct pour WebRTC sont disponibles sur html5rocks.com .

Selon caniuse.com et html5rocks.com , les navigateurs suivants prennent en charge WebRTC:

Prise en charge complète: Edge 14, Firefox 22, Firefox Android 55
Prise en charge partielle: Navigateur Android 56, Chrome 20, Chrome Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11.4
Prise en charge future ( Q3 2017): Chrome pour iOS 11, Safari 11 pour iOS 11 et OS X 10.11
Pas de support: IE, IE Mobile, Opera Mini

Le taux de saturation de WebRTC est limité sur les appareils Apple, car Safari 11 n'est pas encore sorti et nécessite iOS 11 ou OS X 10.11. Bien que projetant à partir des tendances de mise à niveau passées, WebRTC devrait être disponible sur environ 75% des appareils iOS d'ici 2018 et 100% d'ici 2020.

Beejor
la source
4

Il y a un certain nombre de raisons pour lesquelles cela serait délicat:

  1. Les pare-feu (même les NAT simples) rendraient ce type de connexion difficile à une couche de protocole beaucoup plus basse que même HTTP. Avec mon chapeau de sécurité informatique, cela semble être un moyen formidable d'ouvrir des ports arbitraires sur une machine, simplement en visitant un site Web - et ainsi il serait bloqué de manière agressive par pratiquement tous les systèmes informatiques d'entreprise.
  2. HTTP est intrinsèquement un protocole client-serveur. Bien qu'il soit raisonnablement facile de simuler des communications duplex en utilisant une longue interrogation (ainsi que quelques autres techniques), ce n'est pas particulièrement efficace.
  3. Cela ouvrirait un grand trou pour les attaques XSS.

WebSockets est conçu pour résoudre le deuxième de ces problèmes, mais (délibérément, je suppose) pas les deux autres. Lorsqu'ils parlent d'égal à égal dans la spécification HTML5, ils parlent de communications en duplex intégral entre le serveur et le client, et non entre un client et un autre.

Cependant, il serait simple d'implémenter une pile de réseau appropriée au-dessus des Websockets - à condition que toutes les communications doivent toujours être effectuées via le serveur. J'ai vu cela faire en utilisant une longue interrogation (un de mes amis à Uni a écrit une pile TCP / IP complète en utilisant une longue interrogation).

jwoolard
la source
P2P n'est pas client-serveur; le premier déplace le trafic entre pairs, le second le déplace via le serveur vers un ou plusieurs clients. Le principal avantage du P2P est qu'un serveur peut agir comme un entremetteur tandis qu'un trafic important passe entre les clients (ce qui est une aubaine pour la confidentialité et la bande passante).
Beejor
0

Je seconde harshath.jr: vous pourriez très bien avoir un serveur agissant comme un répertoire (exposant les "origines" de chaque agent connecté; l'origine étant schéma + hôte + port comme dans draft-abarth-origin , le schéma étant soit "ws" ou "wss"). Vous pouvez alors lancer des connexions WebSocket peer-to-peer; la SOP en cours d' élaboration grâce à CORS . Bien sûr, cela signifie que chaque agent (c'est-à-dire le navigateur) devrait intégrer son propre serveur WebSocket (à la Opera Unite).

En attendant, faites-le de la manière XMPP / IRC / etc.: pas de connexion peer-to-peer mais des connexions WebSocket à un serveur central (ou réseau!) Pour passer des messages aux agents connectés (éventuellement en utilisant un WebSocket spécifique " sous-protocole ")

EDIT: notez que tout cela sort du cadre de HTML5 (toutes ces choses faisaient autrefois partie de HTML5 mais ont été divisées en leurs propres spécifications)

Thomas Broyer
la source