web udp public
1.0.0
Este repo visa expressar a necessidade pública de uma tecnologia que permita a comunicação servidor-cliente de baixa latência , sem confiabilidade obrigatória e/ou mecânica de entrega ordenada do protocolo de transporte subjacente.
E moldar os requisitos a partir das necessidades existentes e de possíveis aplicações futuras. Para motivar os membros do W3C, a comunidade IETF e os fornecedores de navegadores a iniciar a discussão e propor RFC para impulsionar o desenvolvimento de uma solução.
PRs e discussões em Issues são bem-vindas. Divulguem, RT's são bem-vindos.
A Web evoluiu rapidamente nos últimos anos, melhorando os recursos de rede usando tecnologias como: WebSockets, WebRTC, HTTP/2, eventos enviados por servidor, QUIC .
Essas tecnologias possuem área de aplicação própria e possibilitam que a plataforma web possua:
e muitas outras experiências ricas e poderosas
Nos últimos anos nasceu outro meio: Jogos HTML5 . O Adobe Flash está desaparecendo e a indústria de jogos HTML5 está crescendo continuamente.
O que levou ao nascimento dos IO Games – um dos jogos multijogador mais acessíveis que existe. Alguns exemplos populares: agar.io, slither.io e muitos mais. Todos eles contam atualmente com a única tecnologia viável para comunicação servidor-cliente em tempo real - WebSockets. WebRTC para servidor-cliente é excessivamente complexo (leia mais).
Mas isso limita as capacidades da rede, já que o TCP para jogos tem limites . Vale a pena mencionar que não se trata apenas de jogos - há muitos casos de uso para comunicações servidor-cliente de baixa latência, não confiáveis e não ordenadas.
Latência e congestionamento . O TCP possui entrega de pacotes confiável e ordenada e é um protocolo baseado em conexão. A necessidade do UDP (ou alternativa) sobre o TCP não está em questão, pois é amplamente discutida em muitos artigos sobre os benefícios do UDP (ou alternativa) sobre o TCP em diferentes casos. Aqui estamos tentando apenas resumir. Vale ressaltar que o UDP é a opção de protocolo de transporte mais popular, mas não a única, para esse esforço.
Confiabilidade – isso nem sempre é desejado pela lógica da aplicação, informações desatualizadas podem não ser mais relevantes e podem ser ignoradas. O TCP garantirá a entrega de pacotes, o que leva a congestionamentos que resultam em picos de latência devido à necessidade de reconhecimentos e reentrega de pacotes. O UDP (ou alternativa) não garante confiabilidade imediata, evitando assim problemas de congestionamento que podem ser usados como um benefício para garantir que os dados mais recentes sejam entregues o mais rápido possível.
Entrega ordenada - O TCP usa sequenciamento e confirmações para garantir a leitura ordenada e a reentrega de pacotes. Isso leva ao bloqueio da leitura, o que leva a picos de latência e piora se o ambiente de rede tiver maior perda de pacotes.
Protocolo que não garante confiabilidade e entrega ordenada pronta para uso, permitindo ao desenvolvedor implementar qualquer uma das técnicas, se necessário, ou usar abordagens híbridas. Isso fornece prazos de entrega estáveis e baixa latência em ambientes de rede nada perfeitos. Com controle de congestionamento para mitigar a sobrecarga da infraestrutura da Internet para resolver questões de segurança.
Uma das opções para resolver isso é adicionar uma nova extensão ao protocolo WebSockets existente usando a mecânica de negociação descrita na RFC 6455. O que implementaria funcionalidade extra para estabelecer comunicação de protocolo UDP (ou alternativo). Isso se beneficiaria do modelo de segurança existente de WebSockets baseado na origem e permitiria que os desenvolvedores seguissem uma abordagem progressiva, onde poderiam recorrer à lógica TCP se tal extensão não fosse suportada por nenhum dos lados (servidor ou cliente).
Outra abordagem seria desenvolver uma API completamente nova, muito semelhante aos WebSockets, que abordaria recursos exclusivos da lógica de rede UDP (ou alternativa), bem como potencialmente forneceria recursos extras para o desenvolvedor com opções refinadas de como enviar mensagens.
O estado atual do WebRTC é excessivamente complexo e foi projetado principalmente para comunicação ponto a ponto. Devido a isso não é bem adotado para comunicação servidor-cliente e requer muitos recursos do desenvolvedor. Simplesmente falando, não é amigável para desenvolvedores solo como os WebSockets são hoje. Opção potencial de estender a especificação para modularizar e simplificar os requisitos que permitiriam o uso de algumas partes do WebRTC tornando-o mais acessível para cenários servidor-cliente e API simplificada que o tornaria mais acessível para desenvolvedores web.
Há um rascunho de especificação da API WebTransport que permite que aplicativos da Web estabeleçam conexões de rede interativas, bidirecionais e multiplexadas - com suporte para comunicação confiável e não confiável.
Essa implementação de API e protocolo subjacente deve abordar questões de segurança para torná-la amigável à web:
A API deve abordar essas questões de segurança, sem complicar demais a API para front-end, bem como a implementação para back-end. É por isso que o UDPSocket não é uma opção.
Lista de potenciais protocolos subjacentes que podem ser usados para uma implementação:
