Os soquetes da Web tornam o ajax/CORS obsoleto?

Question

Os web sockets, quando usados ​​em todos os navegadores, tornarão o ajax obsoleto?

Porque se eu pudesse usar web sockets para buscar dados e atualizá-los em tempo real, por que precisaria de ajax?Mesmo se eu usar o ajax para buscar dados apenas uma vez quando o aplicativo for iniciado, ainda posso querer ver se esses dados foram alterados depois de um tempo.

E os web sockets serão possíveis em domínios cruzados ou apenas na mesma origem?

Answer 1

WebSockets não tornarão o AJAX totalmente obsoleto e os WebSockets podem fazer cross-domain.

AJAX

Os mecanismos AJAX podem ser usados ​​com servidores web simples.Em seu nível mais básico, AJAX é apenas uma forma de uma página da web fazer uma solicitação HTTP.WebSockets é um protocolo de nível muito inferior e requer um servidor WebSockets (construído no servidor web, independente ou proxy do servidor web para um servidor independente).

Com WebSockets, o enquadramento e a carga útil são determinados pelo aplicativo.Você pode enviar HTML/XML/JSON entre cliente e servidor, mas não é forçado a isso. AJAX é HTTP.WebSockets tem um handshake HTTP amigável, mas WebSockets não é HTTP.WebSockets é um protocolo bidirecional que está mais próximo dos soquetes brutos (intencionalmente) do que do HTTP.Os dados de carga útil do WebSockets são codificados em UTF-8 na versão atual do padrão, mas é provável que isso seja alterado/estendido em versões futuras.

Portanto, provavelmente sempre haverá lugar para solicitações do tipo AJAX, mesmo em um mundo onde todos os clientes oferecem suporte nativo a WebSockets.O WebSockets está tentando resolver situações em que o AJAX não é capaz ou é marginalmente capaz (porque o WebSockets é bidirecional e tem uma sobrecarga muito menor).Mas o WebSockets não substitui tudo o que o AJAX é usado.

Domínio cruzado

Sim, WebSockets oferece suporte a vários domínios.O handshake inicial para configurar a conexão comunica informações sobre a política de origem.A página da Wikipedia mostra um exemplo de aperto de mão típico: http://en.wikipedia.org/wiki/WebSockets

Answer 2

Vou tentar dividir isso em perguntas:

Os web sockets, quando usados ​​em todos os navegadores, tornarão o ajax obsoleto?

Absolutamente não.WebSockets são conexões de soquete brutas com o servidor.Isso vem com são as próprias preocupações de segurança.As chamadas AJAX são simplesmente assíncronas.Solicitações HTTP que podem seguir os mesmos procedimentos de validação do restante das páginas.

Porque se eu pudesse usar web sockets para buscar dados e atualizá-los em tempo real, por que precisaria de ajax?

Você usaria AJAX para tarefas mais simples e gerenciáveis.Nem todo mundo quer ter a sobrecarga de proteger uma conexão de soquete para simplesmente permitir solicitações assíncronas.Isso pode ser resolvido de maneira bastante simples.

Mesmo se eu usar o ajax para buscar dados apenas uma vez quando o aplicativo for iniciado, ainda posso querer ver se esses dados foram alterados depois de um tempo.

Claro, se esses dados estão mudando.Talvez você não tenha os dados alterados ou atualizados constantemente.Novamente, isso é sobrecarga de código que você tem que prestar contas.

E os web sockets serão possíveis em domínios cruzados ou apenas na mesma origem?

Você pode ter WebSockets entre domínios, mas precisa codificar seu servidor WS para aceitá-los.Você tem acesso ao cabeçalho do domínio (host) que pode usar para aceitar/negar solicitações.Isto pode, no entanto, ser falsificado por algo tão simples como nc.Para realmente proteger a conexão, você precisará autenticá-la por outros meios.

Answer 3

Websockets têm algumas grandes desvantagens em termos de escalabilidade que o ajax evita.Como o ajax envia uma solicitação/resposta e fecha a conexão (..ou logo depois) se alguém permanecer na página da web, ele não usa recursos do servidor quando está ocioso.Os Websockets destinam-se a transmitir dados de volta ao navegador e vinculam recursos do servidor para isso.Os servidores têm um limite de quantas conexões simultâneas podem manter abertas ao mesmo tempo.Sem mencionar que dependendo da tecnologia do lado do servidor, eles podem amarrar um thread para lidar com o soquete.Portanto, os websockets têm requisitos mais intensivos de recursos para ambos os lados por conexão.Você poderia facilmente esgotar todos os seus threads atendendo clientes e nenhum novo cliente poderia entrar se muitos usuários estivessem apenas sentados na página.É aqui que nodejs, vertx e netty podem realmente ajudar, mas mesmo esses também têm limites superiores.

Também há a questão do estado do soquete subjacente e da escrita do código em ambos os lados que conduz a conversa com estado, o que não é algo que você precisa fazer com o estilo ajax porque é sem estado.Websockets exigem que você crie um protocolo de baixo nível que é resolvido para você com ajax.Coisas como batimentos cardíacos, fechamento de conexões ociosas, reconexão em caso de erros, etc. são de vital importância agora.Essas são coisas que você não precisava resolver ao usar AJAX porque ele não tinha estado.O estado é muito importante para a estabilidade do seu aplicativo e, mais importante, para a integridade do seu servidor.Não é trivial.Antes do HTTP, construímos vários protocolos TCP com estado (FTP, telnet, SSH) e então o HTTP aconteceu.E ninguém mais fazia isso porque, mesmo com suas limitações, o HTTP era surpreendentemente mais fácil e robusto.Websockets trazem de volta o que há de bom e de ruim nos protocolos com estado.Você aprenderá em breve se não tiver tomado uma dose daquela última tentativa.

Se você precisar de streaming de dados em tempo real, essa sobrecarga extra é garantida porque pesquisar o servidor para obter dados transmitidos é pior, mas se tudo o que você está fazendo é interação do usuário-> solicitação-> resposta-> atualização da interface do usuário, então o ajax é mais fácil e usará menos recursos porque, uma vez enviada a resposta, a conversa termina e nenhum recurso adicional do servidor é usado.Então eu acho que é uma troca e o arquiteto tem que decidir qual ferramenta se adapta ao seu problema.AJAX tem seu lugar e websockets têm seu lugar.

Atualizar

Portanto a arquitetura do seu servidor é o que importa quando falamos de threads.Se você estiver usando um servidor (ou processos) tradicionalmente multithread, onde cada conexão de soquete obtém seu próprio thread para responder às solicitações, os websockets são muito importantes para você.Portanto, para cada conexão temos um soquete e, eventualmente, o sistema operacional irá falhar se você tiver muitos deles, e o mesmo vale para threads (mais ainda para processos).Threads são mais pesados ​​que soquetes (em termos de recursos), então tentamos conservar quantos threads temos executando simultaneamente.Isso significa criar um pool de threads que é apenas um número fixo de threads compartilhados entre todos os soquetes.Mas uma vez que um soquete é aberto, o thread é usado para toda a conversa.A duração dessas conversas determina a rapidez com que você pode redirecionar esses threads para novos soquetes que chegam.A duração da sua conversa determina o quanto você pode escalar.No entanto, se você estiver transmitindo, esse modelo não funciona bem para dimensionamento.Você tem que quebrar o design de rosca/soquete.

O modelo de solicitação/resposta do HTTP o torna muito eficiente na troca de threads para novos soquetes.Se você for usar apenas solicitação/resposta, use HTTP, ele já está construído e é muito mais fácil do que reimplementar algo assim em websockets.

Como os websockets não precisam ser de solicitação/resposta como HTTP e podem transmitir dados se o seu servidor tiver um número fixo de threads em seu pool de threads e você tiver o mesmo número de websockets amarrando todos os seus threads com conversas ativas, você pode não atendemos novos clientes chegando!Você atingiu sua capacidade máxima.É aí que o design do protocolo também é importante com websockets e threads.Seu protocolo pode permitir que você afrouxe o thread por soquete por modelo de conversa, de forma que as pessoas sentadas lá não usem um thread em seu servidor.

É aí que entram os servidores assíncronos de thread único.Em Java, costumamos chamar isso de NIO para IO sem bloqueio.Isso significa que é uma API diferente para soquetes onde o envio e o recebimento de dados não bloqueiam o thread que executa a chamada.

Tão tradicional no bloqueio de soquetes quando você chama socket.read() ou socket.write() eles esperam até que os dados sejam recebidos ou enviados antes de retornar o controle ao seu programa.Isso significa que seu programa está parado esperando que os dados do soquete entrem ou saiam até que você possa fazer qualquer outra coisa.É por isso que temos threads para que possamos trabalhar simultaneamente (ao mesmo tempo).Envie esses dados para o cliente X enquanto aguardo os dados do cliente Y.Simultaneidades é o nome do jogo quando falamos de servidores.

Em um servidor NIO usamos um único thread para lidar com todos os clientes e registrar retornos de chamada para ser notificado quando os dados chegarem.Por exemplo

socket.read( function( data ) {
   // data is here! Now you can process it very quickly without waiting!
});

A chamada socket.read() retornará imediatamente sem ler nenhum dado, mas nossa função que fornecemos será chamada quando chegar.Esse design muda radicalmente a forma como você constrói e arquiteta seu código, porque se você ficar esperando por algo, não poderá receber novos clientes.Você tem um único tópico e não pode fazer duas coisas ao mesmo tempo!Você tem que manter esse fio em movimento.

NIO, IO assíncrono, programa baseado em eventos, como é conhecido, é um design de sistema muito mais complicado, e eu não sugeriria que você tentasse escrever isso se estiver começando.Mesmo os programadores mais experientes acham muito difícil construir sistemas robustos.Como você é assíncrono, não pode chamar APIs desse bloco.Assim como a leitura de dados do banco de dados ou o envio de mensagens para outros servidores devem ser realizados de forma assíncrona.Até mesmo a leitura/gravação do sistema de arquivos pode retardar seu thread único, diminuindo sua escalabilidade.Depois que você se torna assíncrono, tudo fica assíncrono o tempo todo, se você quiser manter o thread único em movimento.É aí que fica desafiador porque eventualmente você encontrará uma API, como bancos de dados, que não é assíncrona e terá que adotar mais threads em algum nível.Portanto, abordagens híbridas são comuns mesmo no mundo assíncrono.

A boa notícia é que existem outras soluções que usam essa API de nível inferior já construída e que você pode usar.NodeJS, Vertx, Netty, Apache Mina, Play Framework, Twisted Python, Stackless Python, etc.Pode haver alguma biblioteca obscura para C++, mas honestamente eu não me incomodaria.A tecnologia de servidor não requer as linguagens mais rápidas porque está mais vinculada à E/S do que à CPU.Se você é um fanático por desempenho, use Java.Ele tem uma enorme comunidade de código para extrair e sua velocidade é muito próxima (e às vezes melhor) do que C++.Se você simplesmente odeia, escolha Node ou Python.

Answer 4

Sim, sim, é verdade.:D

As respostas anteriores carecem de imaginação.Não vejo mais razão para usar AJAX se websockets estiverem disponíveis para você.