Protocolo WebSockets vs HTTP

Existem muitos blogs e discussões sobre websocket e HTTP, e muitos desenvolvedores e sites defendem fortemente websockets, mas eu ainda não consigo entender o porquê.

por exemplo (argumentos de amantes de websocket):

O HTML5 Web Sockets representa a próxima evolução das comunicações na Web – um canal de comunicação bidirecional full-duplex que opera por meio de um único soquete pela Web. ( http://www.websocket.org/quantum.html )

O HTTP suporta streaming: stream do corpo da solicitação (você está usando enquanto faz o upload de arquivos grandes) e streaming do corpo de 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 quilo bytes do header http quando você faz a pesquisa contínua.

Por que esses 2 bytes não incluem tcp e sob sobrecarga de protocolos tcp?

GET /about.html HTTP/1.1 Host: example.org 

Este é o header http de ~ 48 bytes.

codificação http chunked – http://ru.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 
  • Então, a sobrecarga por cada pedaço não é grande.

Além disso, ambos os protocolos funcionam sobre TCP, portanto, todos os problemas de TCP com conexões de longa duração ainda estão lá.

Questão:

  1. Por que o protocolo websockets é melhor?
  2. Por que foi implementado em vez de atualizar o protocolo http?

1) Por que o protocolo WebSockets é melhor?

WebSockets é melhor para situações que envolvem comunicação de baixa latência, especialmente para baixa latência de mensagens do cliente para o servidor. Para dados de servidor para cliente, você pode obter uma latência relativamente baixa usando conexões de longa duração e transferência em partes. No entanto, isso não ajuda com a latência do cliente para o servidor, o que requer que uma nova conexão seja estabelecida para cada cliente para a mensagem do servidor.

Seu handshake HTTP de 48 bytes não é realístico para conexões de navegador HTTP do mundo real onde geralmente há vários kilobytes de dados enviados como parte da solicitação (em ambas as direções), incluindo muitos headers e dados de cookies. Aqui está um exemplo de uma solicitação / resposta para usar o Chrome:

Exemplo de solicitação (2800 bytes incluindo dados de cookie, 490 bytes sem dados de cookie):

 GET / HTTP/1.1 Host: www.cnn.com Connection: keep-alive Cache-Control: no-cache Pragma: no-cache Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 Cookie: [[[2428 byte of cookie data]]] 

Exemplo de resposta (355 bytes):

 HTTP/1.1 200 OK Server: nginx Date: Wed, 13 Feb 2013 18:56:27 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive Set-Cookie: CG=US:TX:Arlington; path=/ Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT Vary: Accept-Encoding Cache-Control: max-age=60, private Expires: Wed, 13 Feb 2013 18:56:54 GMT Content-Encoding: gzip 

Ambos 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, mensagens pequenas têm apenas 6 bytes de sobrecarga (2 para o header e 4 para o valor da máscara). A sobrecarga de latência não é tanto do tamanho dos headers, mas da lógica para analisar / manipular / armazenar esses headers. Além disso, a latência de 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 para solicitações HTTP normais, mas é provável que WebSockets e / ou 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 que se parece muito com WebSockets de qualquer maneira).

Atualização :

Aqui está uma estrutura para pensar sobre protocolos da web:

  • TCP : camada de transporte de ordem de baixo nível, bidirecional, full-duplex e garantida. Sem suporte ao navegador (exceto via plugin / Flash).
  • HTTP 1.0 : protocolo de transporte request-response em camadas no TCP. O cliente faz um pedido completo, o servidor dá uma resposta completa e, em seguida, a conexão é fechada. Os methods de solicitação (GET, POST, HEAD) têm significado transacional específico para resources no servidor.
  • HTTP 1.1 : mantém a natureza de solicitação-resposta do HTTP 1.0, mas permite que a conexão permaneça aberta para várias solicitações completas / respostas completas (uma resposta por solicitação). Ainda tem headers completos na solicitação e resposta, mas a conexão é reutilizada e não fechada. O HTTP 1.1 também incluiu alguns methods de solicitação adicionais (OPTIONS, PUT, DELETE, TRACE, CONNECT) que também possuem significados transacionais específicos. No entanto, conforme observado na introdução da proposta preliminar do HTTP 2.0, o pipelining HTTP 1.1 não é amplamente implantado, portanto, isso limita muito a utilidade do HTTP 1.1 para resolver a latência entre navegadores e servidores.
  • Long-poll : uma espécie de “hack” para HTTP (1.0 ou 1.1), em que o servidor não responde imediatamente (ou responde apenas parcialmente com headers) à solicitação do cliente. Após uma resposta do servidor, o cliente envia imediatamente uma nova solicitação (usando a mesma conexão se for sobre HTTP 1.1).
  • Fluxo HTTP : uma variedade de técnicas (resposta multipart / chunked) que permitem ao servidor enviar mais de uma resposta para uma única solicitação do cliente. O W3C está padronizando isso como Eventos enviados pelo servidor usando um tipo MIME de text/event-stream . A API do navegador (que é bastante semelhante à API WebSocket) é chamada de API EventSource.
  • Comet / server push : este é um termo genérico que inclui long-poll e HTTP streaming. As bibliotecas de cometas geralmente suportam várias técnicas para tentar maximizar o suporte entre navegadores e entre servidores.
  • WebSockets : uma camada de transporte incorporada ao TCP que usa um handshake de atualização amigável ao HTTP. Ao contrário do TCP, que é um transporte de streaming, o WebSockets é um transporte baseado em mensagens: as mensagens são delimitadas na conexão e são remontadas totalmente antes da entrega no aplicativo. As conexões WebSocket são bidirecionais, full-duplex e de longa duração. Após o pedido / resposta inicial do handshake, não há semântica transacional e há muito pouco por sobrecarga de mensagem. O cliente e o servidor podem enviar mensagens a qualquer momento e devem manipular o recebimento de mensagens de forma assíncrona.
  • SPDY : uma proposta do Google para estender o HTTP usando um protocolo mais eficiente, mas mantendo todas as semânticas HTTP (solicitação / resposta, cookies, codificação). O SPDY introduz um novo formato de enquadramento (com frameworks prefixados por comprimento) e especifica uma maneira de colocar em camadas os pares solicitação / resposta HTTP na nova camada de enquadramento. Cabeçalhos podem ser compactados e novos headers podem ser enviados após a conexão ter sido estabelecida. Existem implementações reais do SPDY em navegadores e servidores.
  • HTTP 2.0 : possui objectives semelhantes ao SPDY: reduz a latência e a sobrecarga de HTTP, preservando a semântica HTTP. O rascunho atual é derivado do SPDY e define um handshake de atualização e um enquadramento de dados muito semelhante ao padrão WebSocket para handshake e enquadramento. Uma proposta alternativa de HTTP 2.0 (httpbis-speed-mobility) usa WebSockets para a camada de transporte e adiciona a multiplexação SPDY e o mapeamento HTTP como uma extensão WebSocket (extensões WebSocket são negociadas durante o handshake).
  • WebRTC / CU-WebRTC : propostas para permitir conectividade peer-to-peer entre navegadores. Isso pode permitir uma comunicação de média e máxima latência, porque o transporte subjacente é SDP / datagrama em vez de TCP. Isso permite a entrega fora de ordem de pacotes / mensagens, o que evita a emissão TCP de picos de latência causados ​​por pacotes descartados que atrasam a entrega de todos os pacotes subseqüentes (para garantir a entrega em ordem).
  • QUIC : é um protocolo experimental que visa reduzir a latência da web em relação ao TCP. Na superfície, o QUIC é muito semelhante ao TCP + TLS + SPDY implementado no UDP. O QUIC fornece controle de multiplexação e stream equivalente a HTTP / 2, segurança equivalente a TLS e semântica de conexão, confiabilidade e controle de congestionamento equivalente a TCP. Como o TCP é implementado nos kernels do sistema operacional e no firmware da middlebox, fazer mudanças significativas no TCP é quase impossível. No entanto, como o QUIC é construído sobre o UDP, ele não sofre dessas limitações. O QUIC é projetado e otimizado para a semântica HTTP / 2.

Referências :

  • HTTP :
    • Página HTTP da Wikipédia
    • W3C Lista de rascunhos / protocolos relacionados ao HTTP
    • Lista de rascunhos IETF HTTP / 1.1 e HTTP / 2.0
  • Evento enviado pelo servidor :
    • Eventos enviados pelo servidor W3C / EventSource Candidate Recommendation
    • Eventos enviados pelo servidor W3C / rascunho da fonte de events
  • WebSockets :
    • Protocolo IETF RFC 6455 WebSockets
    • IETF RFC 6455 WebSocket Errata
  • SPDY :
    • IETF SPDY Draft
  • HTTP 2.0 :
    • IETF HTTP 2.0 httpbis-http2 Rascunho
    • Esboço IETF HTTP 2.0 httpbis-speed-mobility
    • IETF Rascunho httpbis-network-friendly – uma proposta relacionada ao HTTP 2.0 mais antigo
  • WebRTC :
    • Esboço da API do W3C WebRTC
    • Lista de rascunhos do IETF WebRTC
    • Esboço da visão geral do IETF WebRTC
    • IETF WebRTC DataChannel Draft
    • Página inicial da proposta do Microsoft CU-WebRTC
  • QUIC :
    • Projeto QUIC Chrominum
    • IETF QUIC Draft

Você parece assumir que o WebSocket é um substituto para o HTTP. Não é. É uma extensão.

O principal caso de uso de 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 de WebSockets, o único método para aplicativos JavaScript interagirem com um servidor era através do XmlHttpRequest . Mas isso tem uma grande desvantagem: o servidor não pode enviar dados a menos que o cliente tenha solicitado explicitamente.

Mas o novo recurso WebSocket permite que o servidor envie dados sempre que quiser. Isso permite implementar jogos baseados em navegador com uma latência muito menor e sem ter que usar hacks feios como o AJAX long-polling ou os plugins do navegador.

Então, por que não usar o HTTP normal com solicitações e respostas em stream?

Em um comentário para outra resposta, você sugeriu apenas transmitir o pedido do cliente e o corpo da resposta de forma assíncrona.

Na verdade, WebSockets são basicamente isso. Uma tentativa de abrir uma conexão WebSocket do cliente se parece com uma solicitação HTTP no início, mas uma diretiva especial no header (Upgrade: websocket) diz ao servidor para começar a se comunicar neste modo asynchronous. Os primeiros rascunhos do protocolo WebSocket não eram muito mais do que isso e alguns handshaking para garantir que o servidor realmente entendesse que o cliente deseja se comunicar de forma assíncrona. Mas então percebeu-se que os servidores proxy ficariam confusos com isso, porque eles estão acostumados com o modelo usual de solicitação / resposta do HTTP. Um possível cenário de ataque contra servidores proxy foi descoberto. Para evitar isso, era necessário tornar o tráfego do WebSocket diferente de qualquer tráfego HTTP normal. É por isso que as teclas de mascaramento foram introduzidas na versão final do protocolo .

Para o TL; DR, aqui estão 2 centavos e uma versão mais simples para suas perguntas:

  1. WebSockets fornece esses benefícios pelo HTTP:

    • Conexão com estado persistente para a duração da conexão
    • Baixa latência: quase a comunicação em tempo real entre o servidor / cliente devido a nenhuma sobrecarga de restabelecer conexões para cada solicitação, como o HTTP requer.
    • Full duplex: o servidor e o cliente podem enviar / receber simultaneamente
  2. 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 stateless, distribuído usando um modelo de solicitação / resposta. Diferente do compartilhamento de portas por razões legadas (penetração de firewall / proxy), não há muito em comum para combiná-las em um único protocolo.

Por que o protocolo websockets é melhor?

Eu não acho que podemos compará-los lado a lado como quem é melhor. Isso não será uma comparação justa, simplesmente porque eles estão resolvendo dois problemas diferentes . Suas exigências são diferentes. Será como comparar maçãs com laranjas. Eles são diferentes.

HTTP é um protocolo de solicitação-resposta. Cliente (navegador) quer algo, servidor dá. Isso é. Se o cliente de dados desejar for grande, o servidor poderá enviar dados de stream para anular problemas de buffer indesejados. Aqui, o principal requisito ou problema é como fazer a solicitação dos clientes e como responder aos resources (hybertext) que eles solicitam. É aí que o HTTP brilha.

Em HTTP, apenas solicitação do cliente. Servidor só responde.

WebSocket não é um protocolo de solicitação-resposta em que apenas o cliente pode solicitar. É um soquete (muito semelhante ao soquete TCP). Média, uma vez que a conexão está aberta, qualquer um dos lados pode enviar dados até que a conexão TCP esteja fechada. É como um soquete normal. A única diferença com o soquete TCP é que o websocket pode ser usado na web. Na web, temos muita restrição para um socket normal. A maioria dos firewalls bloqueia outras portas que 80 e 433 que o HTTP usou. Proxies e intermediários também serão problemáticos. Assim, para tornar o protocolo mais fácil de implantar nas infraestruturas existentes, use o handshake HTTP para atualizar. Isso significa que, quando a primeira conexão for aberta, o cliente envia uma solicitação HTTP para informar ao servidor que diz “Não é uma solicitação HTTP, atualize para o protocolo websocket”.

 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 

Depois que o servidor entende a solicitação e atualiza para o protocolo websocket, nenhum protocolo HTTP é mais aplicado.

Então, minha resposta é que nem um é melhor que o outro. Eles são completamente diferentes.

Por que foi implementado em vez de atualizar o protocolo http?

Bem, podemos fazer tudo com o nome chamado HTTP também. Mas nós devemos? Se forem duas coisas diferentes, prefiro dois nomes diferentes. O mesmo acontece com Hickson e Michael Carter .

As outras respostas parecem não tocar em um aspecto chave aqui, e isso é que você não faz nenhuma menção de exigir o suporte a um navegador da Web como um cliente. A maioria das limitações do HTTP simples acima está assumindo 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 header apenas no momento do init.

Então, se tudo o que você procura é full-duplex, controle cliente e servidor, e não está interessado em frames / features extras de websockets, então eu diria que o HTTP é uma abordagem mais simples com menor latência / CPU (embora a latência realmente diferiria apenas em microssegundos ou menos para ambos).

Polling HTTP

A sondagem HTTP é o processo de procurar o servidor por cliente em intervalos de tempo predefinidos para buscar informações atualizadas, se disponíveis. Em polling HTTP, o cliente envia uma solicitação para um servidor. Em seguida, o servidor responde com novas mensagens. Se não houver novas mensagens disponíveis, o servidor responderá com um formato vazio ou pré-acordado. Esse stream é repetido pelo intervalo de pesquisa configurado. A sondagem HTTP gera uma sobrecarga de rede significativa no sistema, pois exige a repetição dos headers em cada solicitação.

Portanto, o polling HTTP é executado comparativamente bem, se a frequência de recebimento de atualizações for corrigida. Se a frequência de recebimento da atualização for alta ou o recebimento da atualização for random ou não previsível, a pesquisa de HTTP poderá levar a uma sobrecarga de comunicação. Portanto, a principal desvantagem da pesquisa HTTP é enviar o número de solicitações desnecessárias para o servidor, mesmo que não haja novas atualizações para buscar.

Pesquisa Longa HTTP

A pesquisa longa de HTTP é uma variação da técnica de pesquisa definida para superar as desvantagens mencionadas acima da pesquisa simples. Ele é definido para lidar eficientemente com a transmissão de dados entre o servidor e o cliente. A diferença da pesquisa longa é que ela não envia uma resposta vazia imediatamente, quando não há novas mensagens. Em vez disso, o servidor aguarda uma nova mensagem para responder ou a solicitação é expirada. Isso oferece uma solução mais eficiente para a pesquisa, especialmente quando há menos mensagens novas no sistema, reduzindo o número de solicitações do cliente. Novamente, se os tempos limite de conexão estiverem aparecendo além da resposta, ainda assim a pesquisa longa de HTTP não é muito vantajosa. Portanto, a pesquisa longa de HTTP não resolveu todas as desvantagens exibidas pela pesquisa HTTP.

WebSockets

O protocolo WebSockets foi introduzido como uma extensão, para aprimorar a comunicação cliente-servidor com diversas adições de valor. Na troca de dados em tempo real, o WebSockets funciona bem com menos sobrecarga de comunicação, fornecendo comunicação eficiente e com estado entre o cliente e o servidor. O protocolo WebSockets permite manter conexões de soquete TCP de longo prazo entre clientes e servidores. Mais importante, os conectores Web permitem que as mensagens sejam entregues instantaneamente com uma sobrecarga insignificante para o sistema, em tempo real, de maneira bidirecional e full duplex. WebSockets exibem um recurso exclusivo de atravessar firewall e proxies. Ele pode detectar a presença do servidor proxy e configurar automaticamente um túnel para passar pelo proxy. Especialmente os navegadores da web podem tirar vantagem do modo full duplex para enviar dados em qualquer direção ao mesmo tempo. Além disso, os WebSockets fornecem uma redução significativa do congestionamento da rede e dos custos indiretos do que um sistema duplex comum que mantém duas conexões com polling, ao considerar um soquete único na rede.

Com os resources aprimorados do protocolo WebSockets, geralmente é adequado que as estruturas de aplicativos de rede forneçam mais consistência, permitindo escalabilidade massiva em plataformas em tempo real. Além disso, tem emergido como um protocolo confiável e de alto desempenho, em tempo real, pronto e promissor para a comunicação entre nós, tornando-se uma metodologia confiável para o gerenciamento de cluster.

Referências http://www.devdummy.com/2017/12/http-polling-http-long-polling.html