BT

O futuro do HTTP e a controvérsia sobre o SPDY

por Abel Avram , traduzido por Robison Tesini em 23 Out 2012 |

O IETF HTTPBIS Working Group se reuniu em Vancouver (Canadá), este mês, para discutir o futuro do HTTP/1.1 e do HTTP/2.0. A reunião se focou na proposta de uma nova carta de intenções, que estabelece ações futuras sobre as duas versões do protocolo.

Para o HTTP/1.1, a RFC2616, o documento da IETF que define o protocolo será atualizada para esclarecer itens mal-entendidos e para remover ambiguidades que têm impacto negativo sobre a interoperabilidade. Serão também removidas funcionalidades e marcadas como obsoletas características pouco utilizadas. Outra melhoria será a documentação de características de segurança, incluindo autenticação, cookies e TLS. Por fim, não existirá um HTTP/1.2; as mudanças serão parte da HTTP/1.1 como esclarecimentos.

Algumas das decisões importantes foram estabelecidas para o no HTTP/2.0. A nova versão do protocolo HTTP manterá a semântica do HTTP/1.1, para possibilitar a conversão entre chamadas HTTP/2.0 em HTTP/1.1 e vice-versa. Também será adotada uma sintaxe nova ainda não definida, usando o SPDY Draft como ponto de partida. E o HTTP 2.0 poderá utilizar outros protocolos de transporte diferentes do TCP, ficando assim muito mais rápido que o HTTP/1.1. Além disso, a nova versão deverá consumir menos recursos de rede, como sockets.

O grupo de trabalho irá propor um esboço do padrão HTTP/2.0 em setembro deste ano. A conclusão do padrão está planejada para novembro de 2014.

Quanto ao SPDY, Mark Nottingham, presidente do grupo de trabalho HTTPBIS, escreveu:

É importante compreender que o protocolo SPDY não está sendo adotado como o HTTP/2.0. Ele será o ponto de partida da nossa discussão. Evitará começar do zero.

Adalberto Foresti, editor da HTTP Speed+Mobility na Microsoft, escreveu:

O grupo concordou que sete áreas fundamentais precisam de discussões mais profundas e embasadas, como parte do processo de especificação do HTTP 2.0. Além disso, o padrão resultante não terá compatibilidade retroativa com propostas existentes (SPDY, HTTP Speed+Mobility ou o comando Upgrade do HTTP).

Perguntamos a Mark Nottingham o que acontecerá com instalações do SPDY, se o HTTP/2.0 não for compatível com o padrão. A resposta:

Acho que todos esperam que essas instalações do SPDY desapareçam; todos que defendem o SPDY deixaram bem claro que se trata de um protocolo experimental.

Com relação ao destino das instalações atuais do SPDY, Mike Belshe, inventor do SPDY e editor do SPDY protocol, disse ao InfoQ:

Presumindo que HTTP/2.0 seja tão ou mais rápido que o SPDY, o Chrome e o Firefox deixarão de suportar o protocolo depois de algum tempo. Muitos sites ainda estão implementando HTTP/1.1, portanto continuarão a funcionar mesmo que o SPDY desapareça. Depois, caso o site deseje sua velocidade de volta, deverá fazer um upgrade para HTTP/2.0. De qualquer modo, não haverá interrupção de serviços para os usuários. Mas haverá um período de transição para os sites.

Adalberto Foresti também minimizou a importância do SPDY, dizendo que nos seus testes o protocolo apresentou a mesma performance que o HTTP/1.1, com todas as otimizações ativadas:

Para comparar a performance do SPDY com o HTTP/1.1, rodamos testes que comparam o tempo de download de vários sites públicos utilizando um estudo de testes controlado. Os testes usam softwares disponíveis publicamente, rodando na maior parte com configurações default e todas as otimizações disponíveis do HTTP/1.1 ativadas. Veja um relatório preliminar aqui. Os resultados se assemelham a outros que indicam divergências quanto ao desempenho do SPDY.

Nossos resultados indicam que a performance é quase igual entre SPDY e HTTP/1.1, quando são aplicadas todas as otimizações conhecidas a este último. As melhorias de performance do SPDY não são consistentes ou significativas. Continuaremos nossos testes, e convidamos outros grupos a publicar seus resultados para que a equipe responsável pelo HTTP/2.0 possa escolher as melhores mudanças e atingir a o máximo de desempenho e escalabilidade possível.

Pedimos a Mike Belshe que comentasse sobre as afirmações de Foresti:

Os resultados dos testes da Microsoft confirmam a vantagem do SPDY. Fico feliz em saber que a Microsoft está testando ativamente os protocolos. A equipe da Microsoft queria verificar se o SPDY era melhor que pipelining e minificação. No final, concluiu que o "uso inteligente de otimizações existentes e bem entendidas, como pipelining e minificação podem aproximar a performance do HTTP à do SPDY". Basicamente concordo com isso - mas deixaram de mencionar que a "solução" proposta por eles não é utilizável na internet de hoje.

O grande problema é que os testes comparam o SPDY com pipelining, que foi padronizado como parte do protocolo HTTP/1.1 há mais de 12 anos, mas nunca foi implementado por um grande browser. Por que não? Porque a técnica simplesmente não funciona - não pode ser implantada sem sujeitar usuários a travamentos e perda de performance. No final do ano passado, o time do Firefox tentou deixar o pipelining operacional, mas desistiu e passou a trabalhar no SPDY.

Além disso, a maneira com que os testes foram construídos não leva em conta a multiplexação. Uma vantagem significativa da multiplexação sobre o pipelining é que este último "bloqueia" durante o tempo de processamento do servidor para cada chamada. A multiplexação não bloqueia. Mas, nos testes, foi utilizado um cache de arquivos, criando um tempo de processamento do servidor com zero de latência, sem bloqueios.

Esse tipo de teste se aplica em vários casos, mas não para comparar SPDY e pipelining. Se não houvesse tempo de processamento de servidor, perda de pacotes ou atrasos devido a enfileiramentos, a necessidade de multiplexação seria muito menor. Na verdade, nas condições do teste da Microsoft, eu esperava que uma boa implementação de pipelining fosse mais rápida que o SPDY.

Em suma, os resultados da Microsoft são acadêmicos: têm pouca relevância no mundo real. O artigo confirma que SPDY é mais rápido que o HTTP, e também confirma que SSL é custoso. Mas o pipelining é uma proposta sem méritos. Se fosse implementável estaria rodando no Chrome, Firefox e IE há muito tempo.

O Firefox implementa o pipelining mas a funcionalidade fica desligada por padrão. Essa qyestão vem sendo discutida desde pelo menos 2004, como mostra este bug da Mozilla. De acordo com comentários no registro do bug, algumas pessoas rodam o Firefox com pipelining ligado há muito tempo, sem problemas; já outras tiveram sérios problemas com alguns sites. É por isso que o pipelining não está ligado por default ainda. Os sites Mozillazine e Network.http.pipelining possuem mais detalhes sobre o problema.

Houve algumas tentativas de testar o pipelining no Chrome, com 10% do canal de desenvolvimento (Dev Channel) ligado por default, como mostra esse item do Chromium. Mas o item está fechado agora. O pipelining ainda permanece desligado por default na versão oficial do Chrome 21.

Embora o HTTP/2.0 deva partir do SPDY, não se sabe como será a versão final do protocolo. Atualmente as instalações do SPDY possuem performance superior ao HTTP/1.1 sem pipelining, mas esses servidores deverão migrar para HTTP/2.0 quando o padrão estiver estável para se beneficiarem das novas funcionalidades definidas no HTTP/2.0.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT