Os sockets da Web tornam o ajax / CORS obsoleto?

Os sockets da Web quando usados ​​em todos os navegadores da Web tornam o ajax obsoleto?

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

E serão possíveis sockets web em cross-domains ou apenas para a mesma origem?

WebSockets não tornará o AJAX totalmente obsoleto e os WebSockets podem fazer vários domínios.

AJAX

Mecanismos AJAX podem ser usados ​​com servidores da Web simples. Em seu nível mais básico, o AJAX é apenas uma maneira de uma página da Web fazer uma solicitação HTTP. WebSockets é um protocolo de nível muito inferior e requer um servidor WebSockets (seja construído no servidor web, autônomo ou proxied do servidor para um servidor autônomo).

Com WebSockets, o enquadramento e a carga útil são determinados pelo aplicativo. Você poderia enviar HTML / XML / JSON entre o cliente e o servidor, mas não é forçado a isso. AJAX é HTTP . WebSockets tem um handshake amigável HTTP, mas WebSockets não é HTTP . WebSockets é um protocolo bidirecional que está mais próximo de sockets brutos (intencionalmente) do que de HTTP. Os dados de carga útil 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.

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

Domínio cruzado

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

Vou tentar dividir isso em perguntas:

Os sockets da Web quando usados ​​em todos os navegadores da Web tornam o ajax obsoleto?

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

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

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

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

Claro, se esses dados estão mudando . Você pode não ter os dados mudando ou constantemente atualizando. Mais uma vez, esta é uma sobrecarga de código que você deve considerar.

E serão possíveis sockets web em cross-domains ou apenas para a mesma origem?

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

Websockets tem algumas desvantagens em termos de escalabilidade que o ajax evita. Como ajax envia uma solicitação / resposta e fecha a conexão (ou logo após) se alguém permanecer na página da Web, ela não usa resources do servidor quando está inativa. Os Websockets servem para transmitir dados de volta para o navegador e eles conectam os resources do servidor para fazer isso. Os servidores têm um limite em quantas conexões simultâneas podem manter abertas ao mesmo tempo. Para não mencionar, dependendo da tecnologia do lado do servidor, eles podem amarrar um fio para lidar com o soquete. Portanto, os websockets exigem mais resources para ambos os lados por conexão. Você poderia facilmente esgotar todos os seus threads atendendo clientes e, então, nenhum novo cliente poderia entrar se muitos usuários estivessem sentados na página. É aí que o nodejs, o vertx, o netty podem realmente ajudar, mas mesmo aqueles têm limites superiores também.

Também há a questão do estado do socket subjacente, e escrever o código em ambos os lados que continuam a conversa de estado que não é algo que você tem que fazer com o estilo ajax porque é stateless. Websockets requerem que você crie um protocolo de baixo nível que é resolvido para você com ajax. Coisas como bater no coração, fechar conexões ociosas, reconectar erros, etc, são de vital importância agora. Essas são coisas que você não precisou resolver ao usar o AJAX porque ele era sem estado. Estado é muito importante para a estabilidade do seu aplicativo e, mais importante, a saúde do seu servidor. Não é trivial. Pré-HTTP nós construímos muitos protocolos TCP com estado (FTP, telnet, SSH) e, em seguida, HTTP aconteceu. E ninguém mais fez essas coisas porque, mesmo com suas limitações, o HTTP era surpreendentemente mais fácil e robusto. Websockets traz de volta o bom e o mau dos protocolos com estado. Você aprenderá em breve se não receber uma dose da última vez.

Se você precisar de streaming de dados em tempo real, esta sobrecarga extra é justificada, pois o polling do servidor para obter dados em stream é pior, mas se tudo o que você faz é interação do usuário-> request-> response-> update UI, o ajax é mais fácil e usará menos resources porque, uma vez enviada a resposta, a conversa termina e não são utilizados resources adicionais do servidor. Então eu acho que é uma troca e o arquiteto tem que decidir qual ferramenta se encheckbox no seu problema. O AJAX tem o seu lugar e os websockets têm o seu lugar.

Atualizar

Então, a arquitetura do seu servidor é o que importa quando estamos falando de threads. Se você estiver usando um servidor tradicionalmente multiencadeado (ou processos) em que cada conexão de soquete recebe seu próprio segmento para responder a solicitações, os websockets são muito importantes para você. Portanto, para cada conexão, temos um soquete e, eventualmente, o sistema operacional irá cair se você tiver muitos desses, e o mesmo vale para os threads (mais ainda para os processos). Os threads são mais pesados ​​que os sockets (em termos de resources), por isso tentamos e conservamos o número de threads que temos em execução simultaneamente. Isso significa criar um conjunto de encadeamentos, que é apenas um número fixo de encadeamentos compartilhado entre todos os sockets. Mas uma vez que um socket é aberto, o thread é usado durante toda a conversa. A duração dessas conversas determina a rapidez com que você pode adaptar esses segmentos para novos sockets. A duração de sua conversa determina o quanto você pode escalar. No entanto, se você estiver transmitindo, este modelo não funciona bem para escalonamento. Você tem que quebrar o design de thread / socket.

O modelo de solicitação / resposta do HTTP torna muito eficiente em virar os encadeamentos para novos sockets. Se você for usar o request / response, use o HTTP já construído e muito mais fácil do que reimplementar algo assim em websockets.

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

É aí que entram os servidores asynchronouss de thread único. Em Java, muitas vezes chamamos esse NIO de E / S não bloqueado. Isso significa que é uma API diferente para sockets em que o envio e o recebimento de dados não bloqueiam o thread que executa a chamada.

Tão tradicional no bloqueio de sockets quando você chama socket.read () ou socket.write (), eles esperam até que os dados sejam recebidos ou enviados antes de retornar o controle para o 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. concurrencys é o nome do jogo quando falamos de servidores.

Em um servidor NIO, usamos um único thread para manipular todos os clientes e registrar os retornos de chamada para serem notificados 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 function que fornecemos será chamada quando ela chegar. Esse design muda radicalmente como você constrói e arquiteta seu código, porque se ficar preso esperando algo que puder não receba novos clientes. Você tem um único segmento, você não pode realmente fazer duas coisas ao mesmo tempo! Você tem que manter esse segmento em movimento.

IO asynchronous, Programa baseado em events, como é conhecido, é um projeto de sistema muito mais complicado, e eu não sugeriria que você tentasse escrever isso se estivesse começando. Mesmo programadores muito experientes acham muito difícil construir sistemas robustos. Como você é asynchronous, não pode chamar APIs bloqueadas. Assim como a leitura de dados do database ou o envio de mensagens para outros servidores, eles devem ser executados de forma assíncrona. Mesmo a leitura / gravação do sistema de arquivos pode atrasar seu único thread reduzindo sua escalabilidade. Uma vez que você assíncrona é tudo asynchronous o tempo todo, se você quiser manter o único segmento em movimento. É aí que fica desafiador porque, eventualmente, você encontrará uma API, como os DBs, que não é assíncrona e precisa adotar mais threads em algum nível. Portanto, abordagens híbridas são comuns mesmo no mundo asynchronous.

A boa notícia é que existem outras soluções que usam essa API de nível inferior já construída que você pode usar. NodeJS, Vertx, Netty, Apache Mina, Play Framework, Twisted Python, Stackless Python, etc. Pode haver alguma biblioteca obscura para C ++, mas sinceramente eu não me incomodaria. A tecnologia de servidor não requer os idiomas mais rápidos, porque é IO ligado mais do que o limite da CPU. Se você é um louco por performance difícil, use Java. Tem uma enorme comunidade de código para puxar e sua velocidade é muito próxima (e às vezes melhor) do que o C ++. Se você simplesmente odeia, use o Node ou o Python.

Sim, sim. : D

As respostas anteriores não têm imaginação. Não vejo mais motivos para usar o AJAX se websockets estiverem disponíveis para você.