Will HTML5 permitir que aplicações web para fazer conexões HTTP peer-to-peer?

StackOverflow https://stackoverflow.com/questions/1032006

  •  06-07-2019
  •  | 
  •  

Pergunta

É possível criar uma aplicação web que, com a ajuda de um servidor central, poderia criar conexões diretas com outros usuários do mesmo aplicativo web? Eu estou imaginando um processo semelhante ao UDP perfuração.

Eu li sobre a API novas WebSockets em HTML5, mas parece que você deve iniciar a conexão com um servidor WS-compatível antes que a conexão totalmente duplexada pode começar. Estou pensando moreso sobre um processo para fazer conexões diretas entre clientes, com um servidor se envolver única no aperto de mão inicial.

NOTA: applets Java não contam. Estou interessado apenas em tecnologias de navegador padrão.

Foi útil?

Solução

Em vez de suposições inteligentes, aqui é uma resposta informada:

HTML 5 planos para permitir conexões peer to pares de javascript, mas essas conexões não serão RAW TCP.

A especificação completa pode ser encontrada em http://dev.w3.org/html5/websockets/

JRH

EDIT: com referência específica à peer to conexões de mesmo nível, confira estes links:

É importante notar que as capacidades ainda estão sendo negociados. Vai ser bom para ser capaz de criar "bate-papo locais" aplicativos web:)

JRH

Outras dicas

ATUALIZAÇÃO 2012/10/17: Esta funcionalidade já existe no Chrome Stable v22. Para utilizar esta funcionalidade no Chrome, deve-se permitir que as duas bandeiras em chrome: // flags:

  • Ativar MediaStream
  • Ativar PeerConnection

Em seguida, você pode visitar o AppRTC página de demonstração para experimentar a demo. Veja a WebRTC - Running página Demos Para instruções mais detalhadas sobre como configurar o Chrome para usar a funcionalidade peer to pares e permitindo a captura do dispositivo.

UPDATE: Os engenheiros da Ericcson Labs tem uma prova de conceito em uma compilação de WebKit que faz par HTML5 to peer conversação vídeo .

Eles têm manifestações em seu blogue da tecnologia em ação, bem como diagramas e explicações sobre como a tecnologia vai funcionar.

Eles estão trabalhando para conseguir esta estabilizada e comprometido com o repositório WebKit.

Sim, finalmente.

Como desta escrita (2017), WebRTC é agora uma parte padrão da maioria dos navegadores modernos (cerca de 70% daqueles em uso), e permite o streaming multimídia, peer-to-peer, e de furo.

Docs, código de amostra e exemplos vivos para WebRTC podem ser encontradas em html5rocks.com .

De acordo com a caniuse.com e html5rocks.com , os seguintes navegadores suportam WebRTC:

Suporte completo: Borda 14, o Firefox 22, Firefox Android 55
Suporte parcial: Navegador Android 56, Chrome 20, Chrome Android 29, Borda 12, o Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC Browser Android 11,4
apoio Future (Q3 2017): Chrome para iOS 11, Safari 11 para iOS 11 e OS X 10.11
Sem suporte: IE, IE Mobile, Opera Mini

A taxa de saturação do WebRTC é limitado em aparelhos da Apple, uma vez Safari 11 ainda não foi lançado e requer iOS 11 ou OS X 10.11. Embora projetando a partir de tendências de atualização do passado, WebRTC deve estar disponível em cerca de 75% dos dispositivos iOS em 2018, e 100% em 2020.

Há uma série de razões pelas quais isso seria complicado:

  1. Firewalls (mesmo apenas NAT simples) faria este tipo de conexão difícil em uma camada muito menor do que até mesmo protocol HTTP. Com a minha TI chapéu de segurança, esta parece ser uma maneira maravilhosa de portas arbitrários abertos em uma máquina, apenas visitando um site -. E por isso seria bloqueado de forma agressiva por praticamente todos os sistemas de TI corporativa
  2. HTTP é inerentemente um protocolo cliente-servidor. Embora seja relativamente fácil para simular comunicações duplex usando longa polling (bem como um par de outras técnicas), não é particularmente eficiente.
  3. Isso abriria um grande buraco para ataques XSS.

WebSockets é projetado para resolver a segunda destas questões, mas (deliberadamente, espero) não os outros dois. Quando eles falam sobre peer-to-peer na especificação HTML5, eles estão falando sobre comunicação full duplex entre o servidor eo cliente, não entre um cliente e outro.

No entanto, seria simples de implementar uma pilha de rede apropriada no topo de websockets - com a condição de que toda a comunicação ainda teria que ser feito através do servidor. Eu já vi isso feito usando longa de sondagem (um amigo meu na Uni escreveu uma pilha completa TCP / IP usando longa polling).

Eu segunda harshath.jr: você poderia muito bem ter um servidor agindo como um diretório (expondo "origens" de cada agente conectado; origem sendo esquema + host + porta como em projecto-Abarth origem , com o esquema sendo ou "ws" ou "AAS"). Você poderia, então, iniciar conexões WebSocket peer-to-peer; SOP sendo trabalhado através graças a CORS . Claro, isso significa que cada agente (ou seja browser) teriam que incorporar seu próprio servidor WebSocket (à la Opera Unite).

Nesse meio tempo, faça-o / IRC / etc vias XMPP: nenhuma conexão peer-to-peer, mas WebSocket conexões a um servidor central para passar mensagens para os agentes conectados (eventualmente, usando alguns (ou rede!) WebSocket específico "subprotocol")

EDIT: Note que tudo isso é realmente fora do âmbito do HTML5 (todas essas coisas faziam parte do HTML5, mas foram separados para as suas próprias especificações)

A idéia inteira de Web Sockets foi para resolver os problemas com firewalls e proxies http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top