Por que usar o AJAX quando o WebSockets está disponível?

Estou usando o WebSockets há algum tempo, decidi criar uma ferramenta de gerenciamento de projetos Agile para o meu projeto final do ano na Universidade, utilizando o servidor Node e o WebSockets. Descobri que o uso do WebSockets proporcionava um aumento de 624% no número de solicitações por segundo que meu aplicativo podia processar.

No entanto, desde o início do projeto, li sobre brechas de segurança e alguns navegadores optando por desativar o WebSockets por padrão.

Isso me leva à pergunta:

Por que usar o AJAX quando o WebSockets parece fazer um excelente trabalho de reduzir a latência e a sobrecarga de recursos; existe algo que o AJAX faz melhor que o WebSockets?

O WebSockets não se destina a substituir o AJAX e nem é estritamente um substituto para o Comet / pesquisa longa (embora existam muitos casos em que isso faz sentido).

O objetivo do WebSockets é fornecer uma conexão de baixa latência, bidirecional, full-duplex e de longa duração entre um navegador e um servidor. O WebSockets abre novos domínios de aplicativos para aplicativos de navegador que não eram realmente possíveis usando HTTP e AJAX (jogos interativos, fluxos de mídia dinâmicos, ponte para protocolos de rede existentes etc.).

No entanto, há certamente uma sobreposição de propósito entre WebSockets e AJAX / Comet. Por exemplo, quando o navegador deseja ser notificado sobre eventos do servidor (por exemplo, push), as técnicas Comet e WebSockets certamente são as duas opções viáveis. Se seu aplicativo precisar de eventos push de baixa latência, isso seria um fator a favor dos WebSockets. Por outro lado, se você precisar coexistir com estruturas existentes e tecnologias implantadas (OAuth, APIs RESTful, proxies, balanceadores de carga), isso seria um fator a favor das técnicas de Cometa (por enquanto).

Se você não precisar dos benefícios específicos que o WebSockets oferece, provavelmente será uma boa idéia seguir as técnicas existentes, como AJAX e Comet, pois isso permite que você reutilize e se integre a um enorme ecossistema de ferramentas, tecnologias e mecanismos de segurança. , bases de conhecimento (ou seja, muito mais pessoas no stackoverflow conhecem HTTP / Ajax / Comet que WebSockets) etc.

Por outro lado, se você estiver criando um novo aplicativo que simplesmente não funcione bem dentro das restrições de latência e conexão do HTTP / Ajax / Comet, considere usar o WebSockets.

Além disso, algumas respostas indicam que uma das desvantagens do WebSockets é o suporte limitado / misto ao servidor e ao navegador. Deixe-me difundir um pouco isso. Enquanto o iOS (iPhone, iPad) ainda suporta o protocolo mais antigo (Hixie), a maioria dos servidores WebSockets suporta as versões Hixie e HyBi / IETF 6455 . A maioria das outras plataformas (se elas ainda não possuem suporte interno) podem obter suporte para WebSockets via web-socket-js (polyfill baseado em Flash). Isso cobre a grande maioria dos usuários da web. Além disso, se você estiver usando o Nó para back-end do servidor, considere usar o Socket.IO, que inclui web-socket-js como fallback e, mesmo que isso não esteja disponível (ou desativado), ele voltará a usar qualquer técnica do Comet disponível para o navegador fornecido.

Atualização : o iOS 6 agora suporta o atual padrão HyBi / IETF 6455.

Em dezembro de 2017, os Websockets são suportados por (praticamente) todos os navegadores e seu uso é muito comum.

No entanto, isso não significa que os Websockets conseguiram substituir o AJAX, pelo menos não completamente, especialmente porque a adaptação HTTP / 2 está em ascensão.

A resposta curta é que o AJAX ainda é ótimo para a maioria dos aplicativos REST, mesmo ao usar Websockets. Mas deus está nos detalhes, então ...:

AJAX para pesquisa?

O uso do AJAX para pesquisas (ou pesquisas longas) está acabando (e deveria ser), mas ainda permanece em uso por duas boas razões (principalmente para aplicativos da Web menores):

1. Para muitos desenvolvedores, o AJAX é mais fácil de codificar, especialmente quando se trata de codificar e projetar o back-end.

2. Com o HTTP / 2, o custo mais alto relacionado ao AJAX (o estabelecimento de uma nova conexão) foi eliminado, permitindo que as chamadas AJAX tivessem um bom desempenho, especialmente para postar e fazer upload de dados.

No entanto, o push do Websocket é muito superior ao AJAX (sem necessidade de autenticar novamente ou reenviar cabeçalhos, sem necessidade de ida e volta "sem dados", etc '). Isso foi discutido várias vezes.

AJAX para REST?

Um uso melhor para o AJAX são as chamadas à API REST. Esse uso simplifica a base de código e impede o bloqueio da conexão Websocket (especialmente em uploads de dados de tamanho médio).

Há vários motivos convincentes para preferir chamadas à API do AJAX for REST e upload de dados:

1. A API AJAX foi praticamente projetada para chamadas à API REST e é uma ótima opção.

2. Chamadas e uploads REST usando AJAX são significativamente mais fáceis de codificar, tanto no cliente quanto no back-end.

3. À medida que a carga útil dos dados aumenta, as conexões do Websocket podem ser bloqueadas, a menos que a lógica de fragmentação / multiplexação de mensagens seja codificada.

   Se um upload for realizado em uma única sendchamada do Websocket , ele poderá bloquear um fluxo do Websocket até que o upload seja concluído. Isso reduzirá o desempenho, especialmente em clientes mais lentos.

Um design comum usa pequenas mensagens bidimensionais transferidas pelos Websockets enquanto o REST e os uploads de dados (cliente para servidor) aproveitam a facilidade de uso do AJAX para impedir o bloqueio do Websocket.

No entanto, em projetos maiores, a flexibilidade oferecida pelos Websockets e o equilíbrio entre a complexidade do código e o gerenciamento de recursos derrubarão o equilíbrio em favor dos Websockets.

Por exemplo, os uploads baseados no Websocket podem oferecer a capacidade de retomar envios grandes depois que uma conexão é interrompida e restabelecida (lembre-se do filme de 5 GB que você deseja enviar?).

Ao codificar a lógica de fragmentação de upload, é fácil retomar um upload interrompido (a parte mais difícil foi codificar a coisa).

E quanto ao push HTTP / 2?

Provavelmente devo acrescentar que o recurso de envio HTTP / 2 não substitui (e provavelmente não pode) substituir Websockets.

Isso já foi discutido aqui antes, mas basta mencionar que uma única conexão HTTP / 2 atende a todo o navegador (todas as guias / janelas); portanto, os dados enviados por HTTP / 2 não sabem a qual guia / janela pertence, eliminando sua capacidade de substituir a capacidade do Websocket de enviar dados diretamente para uma guia / janela específica do navegador.

Embora os Websockets sejam ótimos para pequenas comunicações bidirecionais de dados, o AJAX ainda traz várias vantagens - especialmente ao considerar cargas úteis maiores (uploads etc.).

E segurança?

Bem, geralmente, quanto mais confiança e controle são oferecidos a um programador, mais poderosa é a ferramenta ... e mais preocupações de segurança surgem.

O AJAX por natureza teria uma vantagem, já que sua segurança está embutida no código do navegador (que às vezes é questionável, mas ainda está lá).

Por outro lado, as chamadas AJAX são mais suscetíveis a ataques "man in the middle", enquanto os problemas de segurança dos Websockets geralmente são bugs no código do aplicativo que introduziu uma falha de segurança (geralmente a lógica de autenticação de back-end é onde você os encontra).

Pessoalmente, não acho que isso seja tão grande diferença, se alguma coisa que eu acho que os Websockets são um pouco melhor, especialmente quando você sabe o que está fazendo.

Minha humilde opinião

IMHO, eu usaria Websockets para tudo, menos chamadas à API REST. Uploads de Big Data Eu fragmentaria e enviaria Websockets quando possível.

As pesquisas, IMHO, devem ser proibidas, o custo no tráfego de rede é horrível e o Websocket Push é fácil o suficiente para gerenciar, mesmo para novos desenvolvedores.

Além de problemas com navegadores mais antigos (incluindo o IE9, como o WebSockets será suportado a partir do IE10), ainda existem grandes problemas com os intermediários de rede que ainda não oferecem suporte ao WebSockets, incluindo proxies transparentes, proxies reversos e balanceadores de carga. Existem algumas operadoras de celular que bloqueiam completamente o tráfego do WebSocket (ou seja, após o comando HTTP UPGRADE).

Com o passar dos anos, o WebSockets será cada vez mais suportado, mas, enquanto isso, você sempre deve ter um método de fallback baseado em HTTP para enviar dados para os navegadores.

A maior parte das reclamações que li sobre websockets e segurança é de fornecedores de segurança de ferramentas de segurança de navegador e firewall. O problema é que eles não sabem como fazer a análise de segurança do tráfego dos websockets, porque depois de fazer a atualização do HTTP para o protocolo binário do websocket, o conteúdo do pacote e seu significado são específicos do aplicativo (com base no que você programa). Obviamente, esse é um pesadelo logístico para essas empresas cujo meio de vida se baseia na análise e classificação de todo o tráfego da Internet. :)

Os WebSockets não funcionam em navegadores mais antigos, e os que o suportam geralmente têm implementações diferentes. Essa é praticamente a única boa razão pela qual eles não são usados ​​o tempo todo no lugar do AJAX.

Acho que não podemos fazer uma comparação clara entre Websockets e HTTP, pois eles não são rivais nem resolvem os mesmos problemas.

Os Websockets são uma ótima opção para lidar com o fluxo bidirecional de longa duração de maneira quase em tempo real, enquanto o REST é ótimo para comunicações ocasionais. Usar websockets é um investimento considerável, portanto, é um exagero para conexões ocasionais.

Você pode achar que os Websockets se saem melhor quando há altas cargas; o HTTP é um pouco mais rápido em alguns casos, porque pode utilizar o cache. Comparar REST com Websockets é como comparar maçãs com laranjas.

Deveríamos verificar qual deles fornece a melhor solução para nosso aplicativo, qual se encaixa melhor em nosso caso de uso vence.

Um exemplo das diferenças entre HTTP e Websockets na forma de uma lib de tamanho de cliente que pode manipular pontos de extremidade Websocket como APIs REST e pontos de extremidade RESTful como Websockets no cliente. https://github.com/mikedeshazer/sockrest Além disso, para aqueles que estão tentando consumir uma API do websocket no cliente ou vice-versa da maneira como estão acostumados. O libs / sockrest.js praticamente deixa claro as diferenças (ou melhor, deveria).