O HTTP / 2 torna os websockets obsoletos?

Estou aprendendo sobre o protocolo HTTP / 2. É um protocolo binário com pequenos quadros de mensagens. Permite a multiplexação de fluxo em uma única conexão TCP. Conceitualmente, parece muito semelhante ao WebSockets.

Existem planos para obsoletos websockets e substituí-los por algum tipo de solicitação HTTP / 2 sem cabeçalho e mensagens push iniciadas pelo servidor? Ou o WebSockets complementará o HTTP / 2?

Pelo que entendi, o HTTP / 2 não substitui o websocket, mas visa padronizar o protocolo SPDY.

No HTTP / 2, o push do servidor é usado nos bastidores para melhorar o carregamento de recursos pelo cliente a partir do navegador. Como desenvolvedor, você realmente não se importa com isso durante o seu desenvolvimento. No entanto, com o Websocket, o desenvolvedor pode usar a API capaz de consumir e enviar mensagens com uma conexão full-duplex exclusiva.

Essas não são as mesmas coisas e devem se complementar.

Depois de terminar de ler a especificação HTTP / 2 , acho que o HTTP / 2 faz websockets obsoletos na maioria dos casos de uso, mas talvez não todos.

PUSH_PROMISE(conhecido coloquialmente como push do servidor) não é o problema aqui. Isso é apenas uma otimização de desempenho.

O principal caso de uso para Websockets em um navegador é ativar o fluxo bidirecional de dados. Portanto, acho que a pergunta do OP passa a ser se o HTTP / 2 faz um trabalho melhor ao ativar o fluxo bidirecional no navegador, e acho que sim.

Primeiro de tudo, é bi-di. Basta ler a introdução à seção de fluxos :

Um "fluxo" é uma sequência bidirecional independente de quadros trocados entre o cliente e o servidor em uma conexão HTTP / 2. Os fluxos têm várias características importantes:

Uma única conexão HTTP / 2 pode conter vários fluxos abertos simultaneamente, com os quadros de intercalação de terminais de vários fluxos.

Os fluxos podem ser estabelecidos e usados ​​unilateralmente ou compartilhados pelo cliente ou servidor.

Os fluxos podem ser fechados por qualquer um dos pontos de extremidade.

Artigos como este (vinculados em outra resposta) estão errados sobre esse aspecto do HTTP / 2. Eles dizem que não é bidi. Olha, há uma coisa que não pode acontecer com o HTTP / 2: depois que a conexão é aberta, o servidor não pode iniciar um fluxo regular, apenas um fluxo push. Mas quando o cliente abre um fluxo enviando uma solicitação, os dois lados podem enviar quadros DATA através de um soquete persistente a qualquer momento - bidi completo.

Isso não é muito diferente dos websockets: o cliente precisa iniciar uma solicitação de atualização do websocket antes que o servidor também possa enviar dados.

A maior diferença é que, diferentemente dos websockets, o HTTP / 2 define sua própria semântica de multiplexação: como os fluxos obtêm identificadores e como os quadros carregam o ID do fluxo em que estão. O HTTP / 2 também define a semântica de controle de fluxo para priorizar fluxos. Isso é importante na maioria das aplicações do mundo real de bidi.

(Esse artigo errado também diz que o padrão Websocket tem multiplexação. Não, não tem. Não é realmente difícil descobrir isso, basta abrir o Websocket RFC 6455 e pressionar ⌘-F e digite "multiplex". Depois de ler

O protocolo pretende ser extensível; versões futuras provavelmente introduzirão conceitos adicionais, como multiplexação.

Você descobrirá que há uma extensão de rascunho de 2013 para a multiplexação do Websocket. Mas não sei quais navegadores, se houver, suportam isso. Eu não tentaria criar meu webapp SPA na parte de trás dessa extensão, especialmente com o HTTP / 2 chegando, o suporte pode nunca chegar).

A multiplexação é exatamente o tipo de coisa que você normalmente deve fazer sempre que abre um soquete da Web para bidi, por exemplo, para ativar um aplicativo de página única com atualização reativa. Estou feliz que esteja na especificação HTTP / 2, resolvida de uma vez por todas.

Se você quiser saber o que o HTTP / 2 pode fazer, consulte o gRPC. O gRPC é implementado no HTTP / 2. Veja especificamente as opções de streaming half e full duplex que o gRPC oferece. (Observe que o gRPC atualmente não funciona em navegadores, mas isso ocorre porque os navegadores (1) não expõem o quadro HTTP / 2 ao javascript do cliente e (2) geralmente não oferecem suporte a Trailers, que são usados ​​em a especificação gRPC.)

Onde os websockets ainda podem ter um lugar? O grande problema é servidor-> navegador empurrado dados binários. O HTTP / 2 permite dados binários enviados pelo servidor-> pelo navegador, mas não é exposto no JS do navegador. Para aplicativos como enviar quadros de áudio e vídeo, esse é um motivo para usar websockets.

Edição: 17/01 2020

Com o tempo, essa resposta subiu gradualmente até o topo (o que é bom, porque esta resposta é mais ou menos correta). No entanto, ainda existem comentários ocasionais dizendo que isso não está correto por vários motivos, geralmente relacionados a alguma confusão PUSH_PROMISEou como realmente consumir servidor orientado a mensagens -> envio de cliente em um aplicativo de página única. E há um caso de uso para websockets em um navegador, que são dados binários enviados por servidor. Para dados textuais, incluindo JSON, não use websockets, use SSE.

Para recapitular: o protocolo HTTP / 2 é bi-di completo. No entanto, os navegadores modernos não expõem o protocolo HTTP / 2 orientado a quadros ao JavaScript . No entanto, se você fizer várias solicitações para a mesma origem em uma conexão HTTP / 2, todo esse tráfego ficará multiplexado em uma conexão (e é com isso que nos preocupamos!).

Portanto, se você precisa criar um aplicativo de bate-papo em tempo real, digamos, onde você precisa transmitir novas mensagens de bate-papo para todos os clientes na sala de bate-papo que possuem conexões abertas, você pode (e provavelmente deve) fazer isso sem os websockets.

Você usaria eventos enviados pelo servidor para enviar mensagens para baixo e a API de busca para enviar solicitações. Eventos enviados pelo servidor (SSE) é uma API pouco conhecida, mas bem suportada, que expõe um fluxo de servidor para cliente orientado a mensagens. Embora não pareça com o JavaScript do cliente, seu navegador (se ele suporta HTTP / 2) reutilizará uma única conexão TCP para multiplexar todas essas mensagens. Não há perda de eficiência e, de fato, é um ganho em relação aos websockets. Precisa de vários fluxos? Abra várias fontes de eventos! Eles serão automaticamente multiplexados para você.

Além de serem mais eficientes em termos de recursos e com menos latência inicial do que um handshake de websocket, os Eventos Enviados pelo Servidor têm a propriedade agradável de que eles retornam automaticamente e trabalham com HTTP / 1.1. Mas quando você tem uma conexão HTTP / 2, eles funcionam incrivelmente bem.

Aqui está um bom artigo com um exemplo do mundo real de como realizar o SPA de atualização reativa.

Eu digo Não ( Websockets não são obsoletos ).

O primeiro e mais frequentemente ignorado problema é que o envio HTTP / 2 não é aplicável e pode ser ignorado por proxies, roteadores, outros intermediários ou até pelo navegador.

ou seja (do rascunho HTTP2):

Um intermediário pode receber notificações do servidor e optar por não encaminhá-las para o cliente . Em outras palavras, como usar as informações enviadas depende desse intermediário. Da mesma forma, o intermediário pode optar por enviar push adicionais ao cliente, sem nenhuma ação do servidor.

Portanto, o HTTP / 2 Push não pode substituir WebSockets.

Além disso, as conexões HTTP / 2 fecham após um tempo.

É verdade que o padrão afirma que:

As conexões HTTP / 2 são persistentes. Para obter o melhor desempenho, espera-se que os clientes não fechem as conexões até que seja determinado que nenhuma comunicação adicional é necessária (por exemplo, quando um usuário navega para fora de uma página da web específica) ou até que o servidor feche a conexão.

Mas...

Os servidores são incentivados a manter as conexões abertas pelo maior tempo possível, mas podem terminar as conexões inativas, se necessário. Quando um dos terminais escolhe fechar a conexão TCP da camada de transporte, o terminal final DEVE enviar primeiro um quadro GOAWAY (Seção 6.8), para que ambos os terminais possam determinar com segurança se os quadros enviados anteriormente foram processados ​​e concluam ou finalizam graciosamente as tarefas restantes necessárias.

Mesmo que a mesma conexão permita enviar conteúdo enquanto está aberto e mesmo que o HTTP / 2 resolva alguns dos problemas de desempenho introduzidos pelo 'keep-alive' do HTTP / 1.1 ... as conexões HTTP / 2 não são mantidas abertas indefinidamente .

Uma página da Web também não pode reiniciar uma conexão HTTP / 2 depois de fechada (a menos que voltemos a puxar muito, isso é).

EDIT (2017, dois anos depois)

As implementações do HTTP / 2 mostram que várias guias / janelas do navegador compartilham uma única conexão HTTP / 2, o que significa que pushnunca saberá a qual guia / janela pertence, eliminando o uso pushcomo substituto dos Websockets.

EDIT (2020)

Não sei por que as pessoas começaram a votar de forma negativa. De qualquer forma, os anos desde que a resposta foi postada inicialmente provaram que o HTTP / 2 não pode substituir o WebSockets e não foi projetado para isso.

Concedido, o HTTP / 2 pode ser usado para encapsular conexões WebSocket, mas essas conexões encapsuladas ainda exigirão o protocolo WebSocket e afetarão a maneira como o contêiner HTTP / 2 se comporta.

A resposta é não. O objetivo entre os dois é muito diferente. Existe até uma RFC para WebSocket sobre HTTP / 2 que permite fazer várias conexões WebSocket através de um único canal HTTP / 2 TCP.

O WS sobre HTTP / 2 será uma peça de conservação de recursos, diminuindo o tempo para abrir novas conexões e permitindo mais canais de comunicação sem a despesa adicional de mais soquetes, IRQs flexíveis e buffers.

https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01

Bem, para citar este artigo da InfoQ :

Bem, a resposta é claramente não, por uma razão simples: Como vimos acima, o HTTP / 2 apresenta o Server Push, que permite ao servidor enviar proativamente recursos para o cache do cliente. No entanto, ele não permite enviar dados para o próprio aplicativo cliente. Os envios de servidor são processados ​​apenas pelo navegador e não são exibidos no código do aplicativo, o que significa que não há API para o aplicativo receber notificações para esses eventos.

E, portanto, o envio de HTTP2 é realmente algo entre o navegador e o servidor, enquanto os Websockets realmente expõem as APIs que podem ser usadas pelo cliente (javascript, se estiver sendo executado no navegador) e pelo código do aplicativo (executado no servidor) para transferir dados em tempo real.

A troca de mensagens e o streaming simples (não o áudio, o streaming de vídeo) podem ser feitos via multiplexação Http / 2 e WebSockets. Portanto, há alguma sobreposição, mas os WebSockets têm protocolo bem estabelecido, muitas estruturas / APIs e menos sobrecarga de cabeçalhos. Aqui está um bom artigo sobre o tópico .

Haverá implementação do WebSocket no HTTP / 2. https://tools.ietf.org/html/rfc8441

Por enquanto, em abril de 2020, o HTTP / 2 não está tornando obsoletos os WebSockets. A maior vantagem do WebSockets sobre HTTP2 é que

HTTP/2 works only on Browser Level not Application Level

Significa que o HTTP / 2 não oferece nenhuma API JS como WebSockets para permitir a comunicação e transferir algum tipo de JSON ou outros dados para o servidor diretamente do Aplicativo (por exemplo, Site). Então, até onde eu acredito, o HTTP / 2 só tornará obsoletos os WebSockets se começar a oferecer API como WebSockets para conversar com o servidor. Até que seja apenas uma versão atualizada e mais rápida do HTTP 1.1.

A partir de hoje, não.

O HTTP / 2, comparado ao HTTP, permite manter uma conexão com um servidor. A partir daí, você pode ter vários fluxos de dados ao mesmo tempo. A intenção é que você possa enviar várias coisas ao mesmo tempo, mesmo sem o cliente solicitando. Por exemplo, quando um navegador solicita a index.html, o servidor também pode pressionar index.csse index.js. O navegador não solicitou, mas o servidor pode fornecê-lo sem ser solicitado, pois pode presumir que você desejará em alguns segundos.

Isso é mais rápido do que o HTTP / 1 alternativa de obter index.html, analisá-lo, descobrindo que ele precisa index.jse index.csse , em seguida, a construção de 2 outras solicitações para esses arquivos. O HTTP / 2 permite que o servidor envie dados que o cliente nem solicitou.

Nesse contexto, é semelhante ao WebSocket, mas não por design. O WebSocket deve permitir uma comunicação bidirecional semelhante a uma conexão TCP ou serial. É um soquete onde os dois se comunicam. Além disso, a principal diferença é que você pode enviar pacotes de dados arbitrários em bytes brutos, não encapsulados no protocolo HTTP. Os conceitos de cabeçalhos, caminhos, cadeias de consulta só acontecem durante o handshake, mas o WebSocket abre um fluxo de dados.

A outra diferença é que você obtém muito mais acesso otimizado ao WebSocket em Javascript, enquanto que com o HTTP, ele é tratado pelo navegador. Tudo o que você obtém com HTTP é o que você pode caber no XHR/ fetch(). Isso também significa que o navegador irá começar a interceptar e modificar cabeçalhos HTTP sem você ser capaz de controlá-lo (por exemplo: Origin, Cookies, etc). Além disso, o que o HTTP / 2 é capaz de enviar por push é enviado ao navegador. Isso significa que o JS nem sempre (se é que sabe) sabe que as coisas estão sendo empurradas. Novamente, faz sentido index.csse index.jsporque o navegador o armazenará em cache, mas não muito para pacotes de dados.

É realmente tudo em nome. HTTP significa HyperText Transfer Protocol. Estamos voltados para o conceito de transferência de ativos. O WebSocket trata da construção de uma conexão de soquete na qual dados binários são transmitidos bidirecionalmente.

O que realmente não estamos discutindo é o SSE (Eventos Enviados pelo Servidor). Enviar dados para o aplicativo (JS) não é a intenção do HTTP / 2, mas é para o SSE. O SSE fica realmente fortalecido com o HTTP / 2. Mas não é um substituto real para o WebSockets quando o importante é os dados em si, não os pontos finais variáveis ​​atingidos. Para cada terminal no WebSocket, um novo fluxo de dados é criado, mas com o SSE é compartilhado entre a sessão HTTP / 2 já existente.

Resumidos aqui, estão os objetivos de cada um:

• HTTP - responda a uma solicitação com um ativo
• HTTP / 2 - responda a uma solicitação com vários ativos
• SSE - Responda com um fluxo de eventos de texto unidirecional (UTF-8)
• WebSocket - Crie um fluxo de dados binários bidirecionais