Existem muitos blogs e discussões sobre websocket e HTTP, e muitos desenvolvedores e sites defendem fortemente os websockets, mas ainda não consigo entender o porquê.
por exemplo (argumentos de amantes de websocket):
Os soquetes da Web em HTML5 representam a próxima evolução das comunicações na Web - um canal de comunicação bidirecional full-duplex que opera através de um único soquete na Web. ( http://www.websocket.org/quantum.html )
O HTTP oferece suporte ao streaming: solicite o streaming do corpo (você o está usando durante o upload de arquivos grandes) e o streaming do corpo da resposta.
Durante a conexão com o WebSocket, o cliente e o servidor trocam dados por quadro, com 2 bytes cada, em comparação com 8 kg de bytes do cabeçalho http quando você faz pesquisa contínua.
Por que esses 2 bytes não incluem os protocolos TCP e TCP?
GET /about.html HTTP/1.1
Host: example.orgEste é o cabeçalho http de ~ 48 bytes.
codificação em pedaços http - https://en.wikipedia.org/wiki/Chunked_transfer_encoding :
23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0- Portanto, a sobrecarga por cada pedaço não é grande.
Os dois protocolos também funcionam com TCP, portanto todos os problemas de TCP com conexões de longa duração ainda estão lá.
Questões:
- Por que o protocolo websockets é melhor?
- Por que foi implementado em vez de atualizar o protocolo http?
Respostas:
1) Por que o protocolo WebSockets é melhor?
O WebSockets é melhor para situações que envolvem comunicação de baixa latência, especialmente para baixa latência para mensagens de cliente para servidor. Para dados de servidor para cliente, é possível obter uma latência bastante baixa usando conexões de longa data e transferência em blocos. No entanto, isso não ajuda na latência do cliente para o servidor, o que requer que uma nova conexão seja estabelecida para cada mensagem de cliente para servidor.
Seu handshake HTTP de 48 bytes não é realista para conexões do navegador HTTP do mundo real, onde geralmente existem vários kilobytes de dados enviados como parte da solicitação (em ambas as direções), incluindo muitos dados de cabeçalhos e cookies. Aqui está um exemplo de uma solicitação / resposta para usar o Chrome:
Solicitação de exemplo (2800 bytes, incluindo dados do cookie, 490 bytes sem dados do cookie):
Resposta de exemplo (355 bytes):
HTTP e WebSockets têm handshakes de conexão inicial de tamanho equivalente, mas com uma conexão WebSocket o handshake inicial é executado uma vez e, em seguida, pequenas mensagens possuem apenas 6 bytes de sobrecarga (2 para o cabeçalho e 4 para o valor da máscara). A sobrecarga de latência não é muito do tamanho dos cabeçalhos, mas da lógica para analisar / manipular / armazenar esses cabeçalhos. Além disso, a latência da configuração da conexão TCP provavelmente é um fator maior que o tamanho ou o tempo de processamento de cada solicitação.
2) Por que foi implementado em vez de atualizar o protocolo HTTP?
Há esforços para reprojetar o protocolo HTTP para obter melhor desempenho e menor latência, como SPDY , HTTP 2.0 e QUIC . Isso melhorará a situação das solicitações HTTP normais, mas é provável que o WebSockets e / ou o WebRTC DataChannel ainda tenham menor latência para transferência de dados de cliente para servidor do que o protocolo HTTP (ou será usado em um modo semelhante ao WebSockets enfim).
Atualização :
Aqui está uma estrutura para pensar em protocolos da web:
text/event-streamtipo MIME. A API do navegador (que é bastante semelhante à API WebSocket) é chamada de API EventSource.Referências :
fonte
Você parece assumir que o WebSocket é um substituto para o HTTP. Não é. É uma extensão.
O principal caso de uso do WebSockets são aplicativos Javascript que são executados no navegador da Web e recebem dados em tempo real de um servidor. Jogos são um bom exemplo.
Antes do WebSockets, era o único método para os aplicativos Javascript interagirem com um servidor
XmlHttpRequest. Mas elas têm uma grande desvantagem: o servidor não pode enviar dados a menos que o cliente solicite explicitamente.Mas o novo recurso WebSocket permite que o servidor envie dados sempre que desejar. Isso permite implementar jogos baseados em navegador com uma latência muito menor e sem a necessidade de usar hacks feios, como pesquisas longas do AJAX ou plugins de navegador.
Então, por que não usar HTTP normal com solicitações e respostas transmitidas
Em um comentário para outra resposta, você sugeriu apenas transmitir a solicitação do cliente e o corpo da resposta de forma assíncrona.
De fato, os WebSockets são basicamente isso. Uma tentativa de abrir uma conexão WebSocket a partir do cliente parece uma solicitação HTTP no início, mas uma diretiva especial no cabeçalho (Upgrade: websocket) informa ao servidor para começar a se comunicar nesse modo assíncrono. Os primeiros rascunhos do protocolo WebSocket não foram muito mais do que isso e alguns handshakes para garantir que o servidor realmente entenda que o cliente deseja se comunicar de forma assíncrona. Porém, percebeu-se que os servidores proxy ficariam confusos com isso, porque estão acostumados ao modelo usual de solicitação / resposta do HTTP. Um cenário de ataque em potencial contra servidores proxy foi descoberto. Para evitar isso, era necessário fazer o tráfego do WebSocket parecer diferente de qualquer tráfego HTTP normal. É por isso que as chaves de máscara foram introduzidas noa versão final do protocolo .
fonte
Uma API REST regular usa o HTTP como protocolo subjacente para a comunicação, que segue o paradigma de solicitação e resposta, significando que a comunicação envolve o cliente solicitando alguns dados ou recursos de um servidor e o servidor respondendo de volta a esse cliente. No entanto, o HTTP é um protocolo sem estado, portanto, todo ciclo de solicitação-resposta terá que repetir as informações de cabeçalho e metadados. Isso gera latência adicional no caso de ciclos de solicitação-resposta repetidos frequentemente.
Com o WebSockets, embora a comunicação ainda inicie como um handshake HTTP inicial, são necessárias outras atualizações para seguir o protocolo WebSockets (ou seja, se o servidor e o cliente estiverem em conformidade com o protocolo, pois nem todas as entidades suportam o protocolo WebSockets).
Agora, com o WebSockets, é possível estabelecer uma conexão full duplex e persistente entre o cliente e um servidor. Isso significa que, diferentemente de uma solicitação e uma resposta, a conexão permanece aberta enquanto o aplicativo estiver em execução (por exemplo, é persistente) e, como é full duplex, é possível a comunicação simultânea bidirecional, ou seja, agora o servidor é capaz de iniciar uma comunicação e 'envia' alguns dados ao cliente quando novos dados (nos quais o cliente está interessado) se tornam disponíveis.
O protocolo WebSockets é estável e permite implementar o padrão de mensagens Publish-Subscribe (ou Pub / Sub), que é o conceito principal usado nas tecnologias em tempo real, nas quais você pode obter novas atualizações na forma de push do servidor sem o cliente que precisa solicitar (atualizar a página) repetidamente. Exemplos desses aplicativos são o rastreamento de localização do carro Uber, notificações push, atualização dos preços da bolsa em tempo real, bate-papo, jogos com vários jogadores, ferramentas de colaboração on-line ao vivo etc.
Você pode conferir um artigo detalhado sobre Websockets, que explica a história deste protocolo, como surgiu, para que é usado e como você pode implementá-lo.
Aqui está um vídeo de uma apresentação que fiz sobre WebSockets e como eles são diferentes do que usar as APIs REST regulares: Padronização e alavancagem do aumento exponencial no fluxo de dados
fonte
Para o TL; DR, aqui estão 2 centavos e uma versão mais simples para suas perguntas:
O WebSockets fornece esses benefícios sobre HTTP:
O WebSocket e o protocolo HTTP foram projetados para resolver problemas diferentes, o IE WebSocket foi projetado para melhorar a comunicação bidirecional, enquanto o HTTP foi projetado para ser sem estado, distribuído usando um modelo de solicitação / resposta. Além do compartilhamento das portas por motivos herdados (penetração de firewall / proxy), não há muito em comum para combiná-las em um único protocolo.
fonte
Por que o protocolo websockets é melhor?
Não acho que possamos compará-los lado a lado como quem é melhor. Não será uma comparação justa simplesmente porque eles estão resolvendo dois problemas diferentes . Seus requisitos são diferentes. Será como comparar maçãs com laranjas. Eles são diferentes.
HTTP é um protocolo de solicitação-resposta. Cliente (navegador) quer alguma coisa, servidor dá. Isso é. Se o cliente de dados desejar for grande, o servidor poderá enviar dados de streaming para anular problemas indesejados do buffer. Aqui, o principal requisito ou problema é como fazer a solicitação dos clientes e como responder aos recursos (texto em hipertexto) que eles solicitam. É aí que o HTTP brilha.
O WebSocket não é um protocolo de solicitação-resposta em que apenas o cliente possa solicitar. É um soquete (muito semelhante ao soquete TCP). Quando a conexão é aberta, ambos os lados podem enviar dados até que a conexão TCP sublinhada seja fechada. É como um soquete normal. A única diferença com o soquete TCP é que o websocket pode ser usado na web. Na web, temos muitas restrições para um soquete normal. A maioria dos firewalls bloqueia outras portas além das 80 e 433 usadas pelo HTTP. Proxies e intermediários também serão problemáticos. Portanto, para tornar o protocolo mais fácil de implantar no soquete da infraestrutura existente, use o handshake HTTP para atualizar. Isso significa que, quando a conexão for aberta pela primeira vez, o cliente enviou uma solicitação HTTP para informar ao servidor dizendo "Isso não é uma solicitação HTTP, atualize para o protocolo websocket".
Depois que o servidor entende a solicitação e atualiza-o para o protocolo websocket, ele não é mais aplicado.
Então, minha resposta é: Nenhum dos dois é melhor que o outro. Eles são completamente diferentes.
Por que foi implementado em vez de atualizar o protocolo http?
Bem, podemos fazer tudo sob o nome chamado HTTP também. Mas vamos? Se são duas coisas diferentes, vou preferir dois nomes diferentes. O mesmo acontece com Hickson e Michael Carter .
fonte
As outras respostas não parecem abordar um aspecto-chave aqui, e você não menciona a necessidade de oferecer suporte a um navegador da Web como cliente. A maioria das limitações do HTTP simples acima pressupõe que você estaria trabalhando com implementações de navegador / JS.
O protocolo HTTP é totalmente capaz de comunicação full-duplex; é legal que um cliente execute um POST com transferência de codificação em partes e um servidor para retornar uma resposta com um corpo de codificação em partes. Isso removeria a sobrecarga do cabeçalho apenas no momento do init.
Portanto, se tudo o que você procura é full-duplex, controla o cliente e o servidor e não está interessado em recursos / estruturas extras dos websockets, então eu argumentaria que o HTTP é uma abordagem mais simples com menor latência / CPU (embora a latência realmente diferiria em microssegundos ou menos em ambos).
fonte