Igor Nogueira de Oliviera
ANÁLISE DE PERFORMANCE DO PUSH EM CONEXÕES HTTP/2
NO CARREGAMENTO DE PÁGINAS WEB
Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2016
Igor Nogueira de Oliviera
ANÁLISE DE PERFORMANCE DO PUSH EM CONEXÕES HTTP/2
NO CARREGAMENTO DE PÁGINAS WEB
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Djamel Fawzi Hadj Sadok Co-Orientador: Patricia Takako Endo
RECIFE 2016
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
O48a Oliveira, Igor Nogueira de
Análise de performance do PUSH em conexão HTTP/2 no carregamento de páginas web / Igor Nogueira de Oliveira. – 2016.
56 f.: il., fig., tab.
Orientador: Djamel Fawzi Hadj Sadok.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2016.
Inclui referências e apêndice.
1. Redes de computadores. 2. Avaliação de desempenho I. Sadok, Djamel Fawzi Hadj (orientador). II. Título.
004.6 CDD (23. ed.) UFPE- MEI 2016-135
Dedico esta dissertação a minha amada noiva Sarita Bora, pelo incentivo em me tornar alguém melhor, sempre.
Agradecimentos
Agradeço primeiramente ao meu orientador, professor Djamel Sadok por confiar na minha capacidade e persistência durante todo o mestrado. A professora Patrícia Endo, co-orientadora, pelo apoio e ajuda para organizar este trabalho.
Agradecimento em especial a minha noiva, Sarita Bora, por me incentivar a investir no meu potencial acadêmico e ingressar no mestrado. Pela compreensão, paciência e apoio contínuo nesta e (espero) nas futuras jornadas da minha vida.
A vários amigos como Danilo Lima Dutra, por conseguir minha dispensas do trabalho nos dias de aula; Seu irmão Manoel Dutra pelas incontáveis manutenções da minha moto.
A Sr. Gildo Lemos Júnior, pela jaqueta de couro que me protegeu das adversidades climáticas na várias viagens para as aulas.
Aos meus amigos do grupo de pesquisa GPRT, Wesley Melo, Maria Silvia Ito, Carolina Cani e demais que de alguma forma contribuíram imensamente em vários momentos.
Any sufficiently advanced technology is indistinguishable from magic. —ARTHUR C. CLARKE
Resumo
Desde sua padronização, o protocolo Hypertext Transfer Protocol (HTTP) tornou-se o estado da arte em protocolos de transporte da internet, sendo utilizado para transmissão de arquivos hipertexto e hipermídias, como áudio e vídeo de forma cada vez mais interativa. Porém, o HTTP em suas versões 1.0 e 1.1 apresenta pontos que podem ser otimizados, como o fato de atender requisições de forma síncrona, o que normalmente atrasa a renderização de páginas Web podendo vir a afetar a qualidade de experiência dos usuários. Recentemente, o protocolo HTTP foi atualizado para a versão HTTP/2, recebendo diversas modificações, direcionadas principalmente a melhorias no tocante ao uso dos recursos de rede. Dentre estas melhorias, pode-se citar a adição do recurso push, que permite que o pode-servidor Web responda a uma solicitação com mais de um recurso ao mesmo tempo. Este trabalho apresenta uma análise de desempenho do recurso push no transporte de páginas Web em conexões HTTP/2. Para tanto, foram realizados experimentos em um ambiente simulado, replicando características de rede presentes na internet. Foram adotados o Total Download Time (TDT) e o Page Load Time (PLT) como métricas de análise e a execução do experimento foi realizada através de requisições de páginas web com diferentes quantidades e tamanhos de objetos. Através dos resultados obtidos, foi possível observar que apesar do protocolo HTTP/2 possuir recursos para a melhoria do carregamento de páginas Web o uso inadequado destes recursos pode causar, em determinadas configurações, degradações no carregamento das páginas.
Abstract
Since its standardization, the Hypertext Transfer Protocol (HTTP) has been considered the state of the art for transmission of hypertext and hypermedia files, such as audio and video in an interactive way. However, 1.0 and 1.1 versions of HTTP present some weaknesses that may be optimized, such as synchronized requests, which typically slow Web pages rendering thus affecting the end user experience. Recently, the protocol was updated to the 2.0 version and received several modifications, focused mainly on improvements in the network usage. Among these improvements one can cite the addition of push, a feature that allows the server to reply to a request with more than one resource simultaneously. This work presents a performance analysis of push feature on the transport of web pages on HTTP/2 connections. Therefore, experiments were conducted on a prototype environment using Total Download Time (TDT) and Page Load Time (PLT) as metrics, and Web page requests with different amounts and sizes of objects. From the results, one can observe that despite presenting features to improve Web page load time, improper use of these HTTP/2 resources may lead, on certain conditions, to the opposite effect.
Lista de Figuras
1.1 Perda de interesse na página por tempo de carregamento . . . 15
2.1 Visão geral de uma sessão HTTP. . . 18
2.2 Proxy HTTP . . . 19
2.3 Gateway HTTP . . . 20
2.4 Túnel HTTP . . . 20
2.5 Efeito HOL Blocking . . . 21
2.6 Diagrama de eventos em técnicas de polling HTTP . . . 23
2.7 Encapsulamento binário. . . 24
2.8 Codificação Huffman em um cabeçalho HTTP/2 . . . 25
2.9 Visão geral de uma sessão Hypertext Transfer Protocol 2.0 (HTTP/2). . . 25
2.10 Árvore de dependência com pesos. . . 26
2.11 Solicitacão e resposta com server push . . . 27
2.12 Representação visual do HAR e seus eventos. . . 31
3.1 Entidades do ambiente . . . 34
3.2 Diagrama de sequência das requisições do cliente . . . 34
3.3 Frequência de número de objetos do tipo JavaScript por página . . . 38
3.4 Frequência de Tamanho de objetos do tipo JavaScript por página . . . 38
4.1 Comparativo do Tamanho dos Objetos para TDT . . . 43
4.2 Comparativo do Número de Objetos em TDT . . . 44
4.3 Comparativo do Tamanho dos objetos para PLT . . . 46
4.4 Comparativo do Número de Objetos de 2000KB para PLT . . . 46
Lista de Tabelas
3.1 Entidades de Software . . . 36
3.2 Componentes de Hardware . . . 36
3.3 Fatores e Níveis . . . 39
4.1 Valores P para Tamanho dos Objetos para TDT . . . 43
Lista de Acrônimos
ALPN Application-Layer Protocol Negotiation . . . 35
CDN Content Delivery Network . . . 49
CSS Cascading Style Sheets . . . 21
DOM Document Object Model . . . 29
DoS Denial-of-service . . . 21
HAR HTTP Archive format . . . 31
HOL Blocking Head-Of-Line Blocking . . . 15
HTML HyperText Markup Language . . . 29
HTTP/2 Hypertext Transfer Protocol 2.0 . . . 14
HTTP Hypertext Transfer Protocol . . . 14
IANA Internet Assigned Numbers Authority . . . 18
IETF Internet Engineering Task Force . . . 14
JSON JavaScript Object Notation . . . 31
MIME Multipurpose Internet Mail Extensions . . . 17
NAT Network Address Translation . . . 19
PLT Page Load Time . . . 37
QUIC Quick UDP Internet Connections . . . 15
RFC Request For Comments RTT Round Trip Time . . . 28
SPDY SPDY . . . 15
TCP Transmission Control Protocol . . . 25
TDT Total Download Time . . . 36
TLS Transport Layer Security . . . 35
URI Uniform Resource Identifier . . . 18
URL Uniform Resource Locators . . . 18
Sumário
1 Introdução 14 1.1 Motivação . . . 15 1.2 Objetivos . . . 16 1.3 Estrutura da dissertação . . . 16 2 Fundamentação Teórica 17 2.1 HTTP . . . 17 2.1.1 Funcionamento básico . . . 182.1.2 Limitacões e Técnicas de Mitigacão . . . 20
2.2 HTTP/2 . . . 22
2.2.1 Principais Modificações . . . 23
2.2.2 Pushnão é Polling . . . 28
2.3 Complexidade de Páginas Web . . . 29
2.3.1 HTML . . . 29
2.3.2 Do HTML a Página Web . . . 31
2.3.3 HAR . . . 31
2.4 Trabalhos Relacionados . . . 32
3 Metodologia 33 3.1 Descrição dos Experimentos . . . 33
3.2 Infrastrutura de Software . . . 35 3.3 Infraestrutura de Hardware . . . 36 3.4 Métricas . . . 36 3.5 Fatores e Níveis . . . 37 3.6 Coleta de Dados . . . 40 4 Análise de Desempenho do HTTP/2 42 4.1 Análise do TDT . . . 42
4.1.1 Impacto do tamanho dos objetos . . . 42
4.1.2 Impacto do número de objetos . . . 42
4.2 Análise do PLT . . . 45
4.2.1 Impacto do tamanho dos objetos . . . 45
4.2.2 Impacto do número de objetos . . . 45
5 Conclusão e Trabalhos Futuros 48
5.1 Dificuldades encontradas e limitações do trabalho . . . 49
5.2 Trabalhos futuros . . . 49
Referências 50
Apêndice 52
A Apêndice 53
14 14 14
1
Introdução
Desde sua padronização definida em 1997 pela Internet Engineering Task Force (IETF) na RFC 2068 (FIELDING et al, 1997), o protocolo Hypertext Transfer Protocol (HTTP) teve uma ampla aceitação. Os motivos foram, além de manter sua funcionalidade original de transmissão de arquivos hipertexto, prover o transporte de mídias mais dinâmicas, hoje denominadas como hipermídias, tais como áudio e vídeo, não apenas em tempo real, como também de forma cada vez mais interativa. Mesmo com a diversidade de funcionalidades e características dos aplicativos web, o HTTP ainda continua a ser a escolha padrão para transporte de dados.
O HTTP 1.1 não proporciona a melhor utilização da rede possível por utilizar codificação de controle não compactado e em texto plano, sendo este último um fator incremental na complexidade computacional para análise de identificadores de quebra de linha (NIELSEN et al, 1998). Além disso, segundo os mesmos autores, as restrições tornaram sua documentação desnecessariamente extensa e complexa, dificultando que suas implementações contivessem todas as funcionalidades definidas pelo padrão. Estes e outro pontos já eram identificados como falhos e que demandariam grandes alterações no protocolo.
Recentemente, uma nova proposta do HTTP foi definida (BELSHE; PEON; THOMSON, 2015). As principais melhorias propostas no Hypertext Transfer Protocol 2.0 (HTTP/2) são direcionadas ao melhor aproveitamento da rede. Para isso foram propostos o uso de codificação binária e uma estratégia específica de compactação para os dados de controle (PEON; RUELLAN, 2015). Adicionalmente, a nova versão define multiplexação de requisições e respostas dentro de uma mesma conexão. Com isso, espera-se a diminuição do número de conexões ativas e consequentemente menor carga em vários pontos da rede.
Dentre as novas características do HTTP/2, o push permite o envio de recursos pelo servidor sem que haja necessidade de uma requisição explícita do cliente, de forma assíncrona. Esta funcionalidade já era, de certa forma, possível na versão 1.1 através da utilização de
pipelininge técnicas de polling. Porém, ela ainda dependia da requisição explícita do cliente
antes de efetuar o envio do conteúdo do recurso solicitado. Devido a natureza do modelo solicitação/resposta do HTTP, durante a utilização de pipelining, é possível que uma solicitação seja bloqueada por outra em casos de perda de dados ou variações na latência da rede. Este
1.1. MOTIVAÇÃO 15 fenômeno é conhecido como Head-Of-Line Blocking (HOL Blocking).
1.1
Motivação
A facilidade de utilização e acesso a internet através de páginas web permite o
cres-cimento constante da industria de comercio eletrônico. Grandes empresas como Amazon1 e
Google2entre outras destacaram que o tempo para carregamento de suas páginas afeta
direta-mente o satisfação do usuário em utilizar seu serviços. Em 2006, após uma pesquisa de interesse dos usuários, o Google aumentou o numero de resultados em sua páginas de busca de 10 para 30. Ao contrário do esperado a quantidade de usuários efetuando busca reduziu em 20%, após uma analise mais criteriosa foi identificado que a modificação inadvertidamente gerou aumento no tempo médio de carregamento da página de 400ms para 900ms. Experimentos similares foram efetuados na rede de sites da Amazon onde foram inseridos pequenos atrasos, múltiplos
de 100ms3. Os resultados encontrados são apresentados na Figura 1.1.
Figura 1.1: Perda de interesse na página por tempo de carregamento
Fonte: Adaptado de http://www.peer1.com/knowledgebase/ how-slow-website-impacts-your-visitors-and-sales
Tendo em vista a consequência direta do tempo de carregamento de suas páginas é imprescindível que novas tecnologias, como HTTP/2, sejam adotadas para diminuir este tempo.
Alguns dos protocolos utilizados como base para a definição do HTTP/2, como o SPDY (SPDY) e o Quick UDP Internet Connections (QUIC), já utilizam o recurso push em suas especificações. Contudo, como o HTTP/2 ainda é bastante recente, lançado em maio de 2015, alguns dos recursos definidos nesta versão ainda não são amplamente utilizados por servidores
1Disponível em: <https://www.amazon.com>
2Disponível em: <https://www.google.com>
1.2. OBJETIVOS 16 web. Dessa forma, o impacto que estes novos recursos causam ainda não foram extensamente analisados na prática.
Este trabalho apresenta uma análise de desempenho do recurso push no transporte de páginas web em conexões HTTP/2 através de experimentos. Um servidor que implementa o HTTP/2 foi configurado para responder a solicitações de páginas web de diferentes características como quantidade e tamanho de objetos. Com isso foi possível duplicar a carga de rede gerada no carregamento de páginas web de diferentes configurações. A partir deste ambiente foi utilizado um cliente web compatível para acessar e capturar dados de temporização do carregamento de páginas Web em diferentes condições de rede.
1.2
Objetivos
Esta dissertação tem como objetivo principal analisar o impacto do recurso push provido pelo HTTP/2 no carregamento de páginas Web. Como objetivos específicos, pode-se citar:
Compreender a complexidade do carregamento de páginas Web;
Definir métricas e fatores que influenciam o push;
Manipular os fatores em um ambiente experimental;
Analisar os resultados obtidos nos experimentos.
1.3
Estrutura da dissertação
Esta dissertação está estruturada da seguinte forma: o Capítulo 2 apresenta a funda-mentação teórica, onde são descritos os formatos de documentos e protocolos considerados neste estudo. O Capítulo 3 descreve a metodologia utilizada para realizar os experimentos, bem como os valores e justificativas das métricas e fatores. O Capítulo 4 apresenta os resultados dos experimentos e a análise acerca dos dados obtidos. E, por fim, o Capítulo 5 descreve as conclusões e trabalhos futuros.
17 17 17
2
Fundamentação Teórica
Este capítulo apresenta os conceitos fundamentais para o entendimento do trabalho proposto nesta dissertação, referentes ao funcionamento do protocolo HTTP/2 (Seção 2.2), bem como trabalhos relacionados ao tema (Seção 2.4).
2.1
HTTP
O HTTP é um protocolo da camada de aplicação que tem sido usado pela World-Wide Web desde 1990. A primeira versão do HTTP, referida como HTTP/0.9, foi definida como um simples protocolo de transferência de dados brutos pela Internet.
Já o HTTP/1.0, definido pela RFC 1945 (BERNERS-LEE; FIELDING; NIELSEN, 1996), melhorou a versão anterior, permitindo a padronização da codificação das mensagens no formato Multipurpose Internet Mail Extensions (MIME). No entanto, o HTTP/1.0 ainda possuía alguns pontos fracos por não considerar funcionalidades como:
Entidades Intermediárias: Necessários para prover tradução de protocolos, análise
de tráfego e possíveis funcionalidades de cache pela rede.
Funções de cache: Não haviam métodos ou informações de controle necessários
para prover esta funcionalidade.
Hosts virtuais: Apenas um hostname era configurado por servidor.
Conexões persistentes: Uma nova conexão era efetuada a cada solicitação gerando
overhead.
Além disso, a proliferação de aplicações implementadas de forma incompleta, que se autodenominaram "HTTP/1.0", resultaram em comunicações inconsistentes por falta de confirmação de funcionalidades implementadas em ambas as partes (FIELDING et al, 1997).
Com isto, o protocolo HTTP foi atualizado para a versão 1.1 na RFC 2068 (FIELDING et al, 1997); revisada na RFC 2616 (FIELDING et al, 1999). Dentre as principais modificações propostas na versão 1.1, pode-se destacar a possibilidade do uso de conexões persistentes para
2.1. HTTP 18
downloadsde vários recursos de forma sequencial (pipelining) como a que teve maior impacto
no tempo de transmissão e, consequentemente, no tempo de carregamentos de páginas Web.
2.1.1
Funcionamento básico
De forma simplificada, o funcionamento do HTTP, independentemente da versão, dá-se da seguinte maneira: um cliente HTTP inicia uma solicitação através de uma conexão TCP para uma porta específica em um servidor HTTP (por padrão, porta 80 para HTTP, e 443 para HTTPS [Internet Assigned Numbers Authority (IANA)]). O servidor, ao receber o pedido, envia de volta um código de status, como por exemplo "200 OK", e, opcionalmente, o conteúdo no restante do corpo da resposta. O corpo desta mensagem é normalmente o recurso solicitado, apesar de uma mensagem de erro ou outras informações também poderem ser enviadas no cabeçalho. Os recursos HTTP são identificados e localizados na rede através de uma Uniform Resource Locators (URL), utilizando os esquemas de Uniform Resource Identifier (URI) http ou https para indicar o uso de conexões inseguras ou seguras, respectivamente.
A Figura 2.1 descreve um cenário simplificado de operação de uma sessão HTTP.
Figura 2.1: Visão geral de uma sessão HTTP.
Fonte: Adaptado de Hock-Chuan (2009).
Métodos, como o GET exibido na Figura 2.1, são utilizados para indicar o tipo de ação em uma determinada solicitação. O HTTP 1.0 definiu 3 métodos, sendo eles: GET, POST e HEAD , utilizados para solicitar conteúdo, enviar conteúdo e solicitar apenas meta informações de um recurso, respectivamente. A versão 1.1 adicionou mais 5 métodos sendo eles: OPTIONS, PUT, DELETE, TRACE e CONNECT. A semântica utilizada para definir estes métodos permite que outros métodos sejam definidos por extensões.
Todas as mensagens, sejam de solicitação ou resposta, são definidas utilizando-se a mesma semântica. Todas as solicitações são geradas pelo cliente e devem possuir uma resposta
2.1. HTTP 19 correspondente, gerada pelo servidor.
O protocolo HTTP permite a existência de entidades intermediárias entre o cliente e o servidor, caracterizadas de acordo com sua funcionalidade (BERNERS-LEE; FIELDING; NIELSEN, 1996):
Proxy: é uma entidade intermediária que atua como servidor e cliente para realizar
solicitações em nome de um cliente a servidores remotos. Solicitações podem ser respondidas diretamente ou repassadas ao próximo servidor. Um servidor proxy deve interpretar e, se necessário, modificar mensagens HTTP antes de encaminhá-las. Nor-malmente, servidores proxy são utilizados para prover acesso a clientes localizados em uma intranet que não possuem acesso a rede externa sem a necessidade de utilizar Network Address Translation (NAT). A Figura 2.2 apresenta as interconexões entre entidades para funcionalidade de proxy.
Figura 2.2: Proxy HTTP Fonte: Autor
Gateway: é uma entidade que atua como intermediária a outros servidores, porém,
diferentemente de um proxy, as requisições são respondidas diretamente como se este fosse de fato o servidor Web remoto, do ponto de vista do cliente. Também conhecido como surrogate ou proxy reverso, servidores gateway normalmente se encontram na rede próxima aos servidores de conteúdo atuando como balanceadores de carga, tradutores para outros protocolos não HTTP e/ou front-end de criptografia. A Figura 2.3 demostra as interconexões entre entidades em um cenário proxy reverso.
Túnel: é uma entidade que retransmite sem qualquer interpretação conexões entre
cliente e servidor. Um vez ativo um túnel não é considerado nas mensagens HTTP e não efetua qualquer tipo de tratamento nas mensagens. A Figura 2.4 representa um cenário com utilização de um túnel HTTP.
Um mesmo programa pode implementar todas as funcionalidades dependendo apenas de suas configurações ou localização na rede. O serviço de proxy pode ser o funcionamento padrão para conexões a servidores remotos, gateway para recursos disponíveis em servidores locais e túnel em conexões onde não é possível analisar as informações das mensagens, como conexões encriptadas.
2.1. HTTP 20
Figura 2.3: Gateway HTTP
Fonte: Autor Figura 2.4: Túnel HTTP
Fonte: Autor
2.1.2
Limitacões e Técnicas de Mitigacão
O modelo de solicitação/resposta do HTTP, apesar de ter baixa complexidade de im-plementação, não permite o envio de requisições simultâneas, ou seja, requer que cada nova requisição aguarde a conclusão da requisição anterior. Este comportamento força solicitações de forma síncrona, o que normalmente atrasa a renderização de páginas Web.
Parte desta limitação foi amenizada com a funcionalidade de pipelining introduzida na versão 1.1, que permite que várias requisições sejam geradas antes de se receber a respectiva resposta. Apesar das requisições serem geradas de forma serial, não há garantias que as respostas sejam recebidas na mesma ordem que foram geradas. Recursos diferentes podem ter tempo de processamento distintos no servidor ou ainda podem trafegar por caminhos com latências distintas. Como o envio das respostas deve ser efetuado na mesma sequência das solicitações, é possível que respostas que já estejam prontas para envio sejam atrasadas por requisições anteriores; este efeito é denominado HOL Blockings. A Figura 2.5 representa como uma sequencia de requisições pode causar HOL Blocking em uma sessão HTTP utilizando pipeline.
Mesmo com as melhorias propostas na versão 1.1, algumas técnicas foram desenvolvidas e adotadas como melhores práticas no desenvolvimento de conteúdo Web, sendo elas:
2.1. HTTP 21
Figura 2.5: Efeito HOL Blocking
Fonte: Autor
Hostname Sharding: A técnica de Hostname Sharding consiste em utilizar
múlti-plos domínios (ou subdomínios) para hospedar dados de uma mesma página Web, permitindo que múltiplas conexões sejam efetuadas em paralelo mesmo havendo possíveis restrições pelo navegador. Múltiplas conexões TCP originadas de um mesmo endereço em um curto período de tempo podem ser um indicador de tentativa de Denial-of-service (DoS) e causar um possível bloqueio de novas conexões desta origem. Para evitar esta problema, navegadores Web limitam a quantidade de cone-xões abertas a um mesmo hostname. Neste caso, o uso de Hostname Sharding não se aplica a tal restrição. Conexões ativas também consomem recursos de memória e processamento de forma progressiva e devem ser levadas em consideração como limitador de desempenho, tanto do servidor como do cliente;
Image Spriting: O modelo original de requisição e resposta do HTTP pode ser um
fator de atraso para o download de conteúdo em páginas Web que possuem grande quantidade de objetos. Este problema é ainda mais notável em redes de alta latência e quando os recursos em questão são consideravelmente grandes, por exemplo arquivos de imagens. A técnica de Image Spriting consiste em agrupar várias imagens em apenas um arquivo, reduzindo o número de requisições, que melhora a escalabilidade de largura de banda da conexão. Uma vez feito o download do arquivo de Sprite, são utilizadas funções de Cascading Style Sheets (CSS) e/ou JavaScript para exibir as imagens em seus locais esperados, gerando carga de processamento no cliente para renderização do conteúdo;
2.2. HTTP/2 22 em objetos do tipo CSS e JavaScript, que, por serem do tipo texto plano podem ser melhor agrupadas, removendo-se caracteres dispensáveis para sua execução, como espaços em branco e quebra de linhas ou até mesmo alteração de nome de variáveis para nomes menores.
Resource Inlining: Definições de estilo e blocos de JavaScript podem ser inseridas
diretamente no objeto raiz da página Web, ou seja, diretamente dentro de tags HTML através de atributos. Isso ajuda a diminuir o numero de objetos de CSS e JavaScript e evita que haja necessidade de aguardar que estes objetos sejam carregados para uso de algumas de suas funções;
Long Polling e Streaming: Diferentes mecanismos foram implementados a fim de
permitir comunicação assíncrona entre cliente e servidor sem violar as definições originais do HTTP, onde todas as solicitações são iniciadas pelo cliente. Ideal-mente atualizações disponíveis no servidor são enviadas diretaIdeal-mente ao cliente assim que disponíveis. Algumas considerações e boas práticas destes mecanismos foram documentados na RFC 6202 (LORETO et al, 2011).
Long Polling: O servidor não responde solicitações de imediato mantendo-a como pendente do ponto de vista do cliente. A solicitação só é respondida após algum evento no servidor que indique que existem novos dados a serem enviados. Neste mecanismo, o cliente deve sempre manter uma solicitação pendente aguardando novas atualizações.
Streaming: O servidor mantém a solicitação no estado aberto indefinidamente, ou seja, mesmo após o envio de informações nenhuma indicação de que resposta foi concluída é emitida. A Figura 2.6 apresenta o diagrama de eventos para as duas estratégias de polling.
Todas as mitigações citadas ajudam a aproveitar melhor a transmissão de páginas Web, porém adicionam complexidade e overhead ao se gerar, no lado do servidor, ou acessar, no lado cliente o conteúdo.
2.2
HTTP/2
Apesar de ser um protocolo considerado antigo, não houve grandes esforços no desenvol-vimento de uma nova versão do HTTP. Apenas em 2007 foi formado pela IETF um novo grupo de trabalho, o HTTPBis. O grupo seria responsável por inicialmente revisar e atualizar todas as considerações definitivas do HTTP 1.1, o que resultou nas RFCs 7230 à 7235.
De 2007 até 2012, foram analisados pelo HTTPBis alguns possíveis protocolos que poderiam ser utilizados como base para a versão 2.0. Em julho de 2012, um dos feedbacks
2.2. HTTP/2 23
Figura 2.6: Diagrama de eventos em técnicas de polling HTTP
Fonte: Autor
ao Call for Expressions of Interest in HTTP/21, fornecido pela equipe de infraestrutura de
rede do Facebook2, relata quais características consideravam importantes na nova versão para
atender as demandas em sua estrutura e quais protocolos já existentes estavam analisando. Dentre os possíveis protocolos a serem utilizados, como SPDY (formalmente FLIP, Google), HTTP Speed+Mobility (Microsoft) e WAKA (Roy Thomas Fielding, Adobe e Apache Software Foundation), apenas o SPDY atendia a maioria das características, além de já ser utilizado internamente na infraestrutura de rede do Facebook e em maior escala pela Google. Neste ponto da história, apenas o SPDY era suportado por dois do três navegadores Web mais populares, Google Chrome e Mozilla Firefox.
Em novembro de 2012, o primeiro draft do HTTP/2 foi publicado, sendo uma cópia direta da especificação do SPDY, até sua padronização oficial pela IETF em maio de 2015 através das RFCs 7540 e 7541. Apesar da existência de diversas implementações e discussões pela comunidade ativa, o processo foi considerado muito rápido e possivelmente tendencioso até sua formalização (KAMP, 2014).
2.2.1
Principais Modificações
As principais limitações do HTTP 1.1, como HOL Blocking, codificação em texto plano e falta de compressão de informações de controle (cabeçalhos), foram consideradas durante o processo de padronização da versão 2.0. Outros fatores técnicos de performance foram identificados como foco pelo HTTPBis para guiar o desenvolvimento do novo procolo, especificamente, latência observada pelo usuário final, utilização de recursos de rede e recursos
1Disponível em: <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI>
2.2. HTTP/2 24 dos servidores. Além disso, o principal objetivo era implementar o uso de apenas uma conexão entre o navegador e o servidor Web3.
As principais características e recursos do HTTP/2 são descritas a seguir.
Encapsulamento binário: Conexões HTTP/2 utilizam codificação binária para
trans-missão de dados. Apesar desta codificação não ser legível, ela é mais compacta, computacionalmente simples de implementar e menos susceptível a erros. O design de funcionamento não afeta a semântica de alto nível do protocolo que continua sendo idêntico ao utilizado em sua versão anterior. A Figura 2.7 representa onde o encapsulamento binário ocorre em relação as camadas da rede.
Figura 2.7: Encapsulamento binário.
Fonte: Adaptado de Grigorik (2013).
Na prática, a codificação ocorre imediatamente antes do envio/recebimento dos dados para a camada seguinte, similar a uma camada intermediária.
Compactação de cabeçalho: Inicialmente, a compactação utilizada seria a mesma
do SPDY, o GZIP. Porém, durante os testes de implementação iniciais foram
identifi-cadas falhas consideráveis de segurança ao se utilizar este método de compactação4.
O HTTP/2 utiliza uma estratégia exclusiva de compactação, o HPACK (PEON; RUELLAN, 2015), que é baseado no algoritmo de codificação Huffman. A im-plementação binária e o fato de haver uma quantidade relativamente pequena de nomes de métodos que se repetem várias vezes durante uma sessão colaboram com a eficiência deste algorítimo. A Figura 2.8 demostra como a codificação Huffman é efetuada através da atribuição de chaves para itens de cabeçalho comuns em todos os frames de uma mesma sessão(tabela estática), e possível adição de itens específicos
3Disponível em: <https://http2.github.io>
2.2. HTTP/2 25 do frame. A compactação é então obtida pois apenas os números referentes as chaves são transmitidos pela rede, no caso de itens específicos do frame são enviados por completo apenas uma vez por sessão.
Figura 2.8: Codificação Huffman em um cabeçalho HTTP/2
Fonte: Autor
Multiplexação: Para permitir interações bilaterais e simultâneas em uma mesma
conexão Transmission Control Protocol (TCP), este recurso segmenta o trânsito de mensagens HTTP em diferentes streams através do uso de frames. A Figura 2.9 representa como as informações são organizadas na conexão.
Figura 2.9: Visão geral de uma sessão HTTP/2.
Fonte: Adaptado de Grigorik (2013).
A fim de evitar colisão em identificadores de streams, números ímpares indicam que estes foram iniciados pelo cliente, enquanto que pares são para streams inciados pelo servidor. Cada frame possui um identificador do stream que pertence além de informações adicionais de controle de sequência. Desta forma é possível que sejam enviados e recebidos em qualquer ordem. Esta estratégia elimina o efeito
2.2. HTTP/2 26 HOL Blocking da camada de aplicação e permite outras estratégias de uso do canal de forma assíncrona, como Server Push.
Priorização de streams: A sequência em que os frames são enviados na rede não
garante que os mesmos sejam entregues em ordem por possíveis retransmissões e/ou atrasos do TCP; entretanto, se considerarmos que os pacotes chegam na mesma ordem que são enviados, a sequência dos frames transportados pode ser utilizada para definir prioridade a determinados recursos. Para permitir o uso de prioridades, a especificação do HTTP/2 define três campos opcionais em frames do tipo HEADERS; um para identificar o stream dependente, outro para indicar o peso e um bit para declarar dependência exclusiva. Com estas informações, é possível criar uma árvore de dependências baseada em pesos. A Figura 2.10 representa como esta árvore deve ser definida em relação aos pesos e exclusividade de streams.
Figura 2.10: Árvore de dependência com pesos.
Fonte: Adaptado de Grigorik (2013).
O peso de cada stream é definido por um valor de 1 a 256. Streams que ocupam o mesmo nível de hierarquia são ponderados em função dos pesos que possuem. Na figura 2.10, por exemplo, os fluxos A e B possuem respectivamente pesos 12 e 4, e portanto, a quantidade de recursos destinada a cada fluxo pode ser calculada
utilizando uma média ponderada. Logo 3/4 dos recursos disponíveis para envio
devem conter dados do stream A e apenas1/4do stream B.
Não há uma interpretação clara no quesito recurso que cada uma destas prioridades deve utilizar, mas na prática a maioria das implementações utiliza o valor para dividir a quantidade de dados a ser enviada por vez com base no tamanho de janela de congestionamento disponível no momento do envio.
2.2. HTTP/2 27
Server Push: Através deste recurso é possível que o servidor responda a uma
solicita-ção com mais de um recurso ao mesmo tempo. A Figura 2.11 representa a sequencia de solicitação e respostas utilizando este recurso.
Figura 2.11: Solicitacão e resposta com server push
Fonte: Autor
Na prática implementação deste recurso possui detalhes específicos de troca de mensagens entre o cliente e servidor que são descritos nos seguintes passos:
1. O servidor recebe uma solicitação que pode ter recursos adicionais como resposta;
2. No mesmo stream utilizado para responder à solicitação, o servidor envia um frame do tipo PUSH_PROMISE para cada recurso que deseja enviar via push. O frame PUSH_PROMISE contem um número de stream a ser utilizado pelo cliente para identificar futuros frames de dados do push; 3. O servidor considera como criado os streams informados no passo 2 e
envia, assim que possível, frames de dados dos recursos adicionais; 4. O cliente, para cada PUSH_PROMISE recebido, deve optar por:
reservar um stream com o identificador sugerido pelo
PUSH_PROMISE ou;
enviar um frame do tipo RST_STREAM informando que não
2.2. HTTP/2 28 Por padrão, streams do tipo push são dependentes do stream que foram gerados. Con-tudo, elas podem receber diferentes pesos a depender da escolha da implementação do protocolo.
Este trabalho irá estudar mais profundamente este recurso, pois os possíveis efeitos causados pelo seu uso ainda não foram devidamente analisados. Portanto, a próxima sub-seção descreverá em mais detalhes o Push em relação a outras estratégias com funcionalidade similar.
2.2.2
Push não é Polling
As técnicas de Long Polling e Streaming omitem, do ponto de vista do usuário, que a comunicação entre o cliente e servidor é de fato síncrona e iniciada pelo cliente. As principais limitações em tais técnicas são:
Overhead: No Long Polling, as mensagens de solicitação e resposta contém
cabeça-lho completo. Para transmissões de mensagens pequenas e em baixa frequência, o
overheadpode representar uma grande percentagem dos dados transmitidos. Este
efeito é particularmente indesejado em redes tarifadas por volume a exemplo de algumas redes móveis;
Latência Máxima: Devido a natureza do modelo de solicitação/resposta do HTTP
exigir interações síncronas, cada mensagem enviada deve aguardar confirmação antes de novas mensagens serem geradas. Com isso a latência entre as mensagens pode ser de até 3 Round Trip Times (RTTs), caso uma solicitação seja efetuada enquanto outra ainda se encontra em trânsito na rede. A utilização de pipelining ajuda a amenizar este efeito. Porém, não é suportado por padrão na maioria dos navegadores (Google Chrome5, Mozilla Firefox6);
Alocação de Recursos: Para evitar desperdício de recursos, os servidores estipulam
um tempo limite para conexões sem atividade. Isso pode ser uma restrição muito rígida em relação a frequência de utilização durante o polling, exigindo que novas conexões sejam abertas em curtos intervalos de tempo.
Entidades intermediárias: Servidores de proxy podem não permitir conexões com
grande duração mesmo quando permitido pelo servidor remoto. A aglomeração de mensagens utilizado no streaming pode gerar quadros HTTP segmentados; entidades intermediárias podem causar atraso ao aguardar que todos os segmentos sejam recebidos antes de retransmiti-los ao servidor.
5Disponível em: <https://www.chromium.org/developers/design-documents/network-stack/http-pipelining>
2.3. COMPLEXIDADE DE PÁGINAS WEB 29 Outras considerações mais detalhadas podem ser encontradas na RFC 6202 (LORETO et al, 2011). O recurso push do HTTP/2 não requer complexidade adicional, nem gera carga em comparação com as técnicas equivalentes, pois utiliza a mesma conexão TCP existente. Não é necessário que sejam enviadas solicitações periódicas ao servidor para consulta sobre novos dados, pois estes são enviados assim que disponíveis de forma assíncrona em relação aos demais streams.
2.3
Complexidade de Páginas Web
Esta seção descreve a complexidade envolvida no transporte e apresentação de páginas Web.
2.3.1
HTML
O HyperText Markup Language (HTML) é uma linguagem de marcação utilizada para criar páginas Web. Em conjunto com CSS e JavaScript, o HTML é utilizado pela maioria dos Web-sites para criar páginas visualmente ricas, interfaces de aplicativos Web e aplicativos de dispositivos móveis. Inicialmente proposto por Tim Berners-Lee no final da década de 80, posteriormente padronizado pela IETF até que, a partir de 1996 as definições de padrões do HTML são mantidas pela World Wide Web Consortium (W3C).
Navegadores Web utilizam arquivos HTML como base para renderizar páginas que podem conter texto, hyperlinks, imagens, objetos de mídia, como áudio e vídeo inclusive outras paginas Web com uso de frames HTML.
A sintaxe do HTML é definida através de marcadores, ou tags, entre os caracteres “<” e “>”, como por exemplo “<html>”. Estes marcadores, em sua maioria, são em pares como “<body>” e “</body>”, sendo utilizados para iniciar e finalizar um bloco, respectivamente.
Alguns marcadores não são apresentados em pares e são utilizados para descrever elementos sem conteúdo, como o marcador “<img>”. Em ambos os casos, é possível adicionar informações de atributos dentro dos marcadores de inicio de bloco ou diretamente no marcador caso seja único.
Após obter um documento HTML, o navegador Web analisa o conteúdo e atributos dos marcadores para criar elementos HTML. Os elementos <html>, <head> e <body> são denominados como contêineres estruturais para um documento HTML e contém informações específicas:
HTML: Todos os elementos de um documento HTML devem estar contidos dentro
do elemento <html>, denominado elemento raiz, sendo o único a ter o atributo de nome “documentElement” na árvore Document Object Model (DOM).
HEAD: Contém elementos com informações de metadados do documento e
2.3. COMPLEXIDADE DE PÁGINAS WEB 30 são renderizadas na página Web, porém podem ser utilizados para indicar outros objetos que são necessários para o processamento dos demais elementos visuais. Os seguintes elementos podem existir neste contêiner:
<base>: Especifica qual o prefixo de URL deve ser utilizado nas próximas
URLs relativas. Apenas uma definição base deve existir no documento.
<meta> É utilizado para informar meta informações adicionais ao
docu-mento que não possuem outro local a serem informadas, como autor, data de publicação e data de validade. Palavras-chave são comumente descritas através dos atributos deste tipo de elemento. Não há um padrão obrigatório para definir os possíveis atributos e seus valores.
<script>: Pode conter blocos de scripts ou referência a outro objeto que
contenha scripts através do atributo src. Quanto utilizado o atributo src o elemento <script> pode conter adicionalmente os atributos mutuamente exclusivos “async” e “defer” indicando quando o script deve ser executado, sendo definido “async”, o script deve ser executado de forma assíncrona a outros processos do navegador; quando “defer” o script deve ser executado apenas após a conclusão da analise do documento. Na ausência destes atributos o script deve ser executado assim que disponível, antes que o navegador prossiga na análise do documento.
<style>: O conteúdo deste elemento é utilizado para definir estilos do
documento através de CSS.
<link>: Define links entre o documento e recursos externos. Não possui
conteúdo e utiliza atributos específicos para informar localização e carac-terísticas do recurso externo. Comumente utilizado para definir objetos do tipo CSS e de ícone na página. O atributo rel deste elemento define o tipo de relacionamento que o documento tem com o recurso externo.
<title>: Define o título do documento HTML em seu conteúdo.
BODY: Contém elementos do conteúdo visível do documento que podem utilizar
atributos para definições inline de estilos entre outras definições arbitrárias. Elemen-tos do tipo <script> podem ser utilizados dentro do elemento <body>. Os demais elementos possíveis não são considerados relevantes no restante deste trabalho. A especificação do HTML não possui qualquer tipo de restrição em relação a sequencia dos blocos, exceto dos elementos estruturais.
2.3. COMPLEXIDADE DE PÁGINAS WEB 31
2.3.2
Do HTML a Página Web
Após obter o documento HTML inicial, o navegador inicia a construção da página Web. Os marcadores do documento são utilizados para definir elementos em um DOM. Durante este processo, pode ser necessário avaliar modificações causadas por outros objetos ou solicitar objetos externos. Além disso, o DOM também é utilizado para renderizar todas as informações da página Web.
Wang et al (2013) demonstra como os navegadores efetuam a construção e renderização de páginas Web e quais dependências existem entre os processos relacionados nesta atividade. Algumas destas dependências são impostas por padrões Web, a exemplo da execução Javascript: quando definidos diretamente entre tags <script> devem ser executados assim que identificados. Outras dependências são causadas ao se identificar objetos externos que devem ser obtidos e analisados durante a construção do DOM. Como exemplo, scripts que foram definidos sem o atributo “async” ou “defer” devem ser analisados assim que disponíveis.
2.3.3
HAR
O HTTP Archive format (HAR) é um formato de arquivo utilizado para armazenar registros de interações e eventos durante o carregamento de uma página por um navegador Web. O formato é baseado em JavaScript Object Notation (JSON), e contém informações de autoria, detalhes sobre o navegador Web utilizado, informações de cabeçalho e temporização das transações HTTP e opcionalmente o conteúdo dos objetos transferidos. A Figura 2.12 apresenta um trecho de arquivo har e sua representação visual em cascata.
Figura 2.12: Representação visual do HAR e seus eventos.
Fonte: Google Chrome
Os valores apresentados indicam precisamente o início e fim das transações de rede dos objetos da página. Detalhes da rede como tempo de negociação da conexão, negociação do TLS, atraso até o primeiro byte do objeto e tempo de Download podem ser obtidos diretamente através da inspeção do controlador de rede. Eventos relativos ao carregamento do DOM necessitam de informações coletadas pelos demais processos de um navegador. O entendimento sobre tal
2.4. TRABALHOS RELACIONADOS 32 formato é relevante por ser utilizado durante a coleta de resultados dos experimentos e em outras fontes utilizadas neste estudo.
2.4
Trabalhos Relacionados
Estudos anteriores tais como Padhye, Nielsen e Podjarny (2012) e Podjarny (2012) anali-sam performance com uso do SPDY em relação ao HTTP e indicam resultados contraditórios, convergindo apenas no possível baixo desempenho do SPDY em redes móveis.
Em Erman et al (2013), os autores efetuam medições ao acessar os 20 sites mais populares do mundo, de acordo com o Alexa, utilizando SPDY e servidores proxy HTTP/1 em redes 3G. Eles atestam que o baixo desempenho do SPDY em redes móveis esta relacionado à forma como o TCP efetua o controle de congestionamento, em função de perdas e variância de latência da rede (jitter). Tendo em vista que o SPDY, assim como o HTTP/2, utiliza apenas uma conexão TCP, o impacto causado pelo controle de congestionamento é mais visível do que no HTTP, que utiliza várias conexões.
Ainda sobre o SPDY, Wang et al (2014) apresentou novas métricas e técnicas para caracterizar o desempenho deste protocolo. Através do isolamento do processo de carregamento de rede em relação aos demais processos envolvidos no carregamento de páginas Web, foi identificado que o SPDY possui melhor desempenho em relação ao HTTP. Porém, ao se considerar os demais fatores computacionais, o desempenho do SPDY é consideravelmente afetado. Apesar de propor formas de uso para o recurso push, a análise efetuada considera poucos casos, sendo focados números e tamanhos de objetos observados em um conjunto de 200 páginas.
Avançando para o HTTP, o trabalho apresentado por Saxce, Oprescu e Chen (2015) relata análises utilizando HTTP/2 em relação a diferentes fatores de rede como latência, perdas e largura de banda. Os resultados comprovam ganho de performance no uso do recurso push em um cenário simples de múltiplos objetos e tamanho fixo. Porém, os autores não estendem as análises em diferentes ambientes.
Por fim, Han, Hao e Qian (2015) descrevem um framework que combina a utilização do push em conjunto com Server Hint para evitar uso duplicado na transmissão de objetos já armazenados em cache pelos clientes. Os comparativos de resultados do uso deste framework se baseiam apenas em configurações simples do uso do push.
Embora todos os trabalhos relacionado aqui descritos apresentem contribuições significa-tivas, até onde sabemos, não foi encontrada uma análise específica sobre o impacto do uso do recurso push em relação aos fatores de tamanho e número de objetos em streams concorrentes. Os estudos efetuados consideram cópias de uma pequena fracão de páginas Web reais, que podem não representar de forma adequada características da população de Web sites existentes.
33 33 33
3
Metodologia
Este capítulo apresenta a descrição dos experimentos realizados para avaliar o recurso
pushdo HTTP/2 considerando um ambiente real. Para tanto, o capítulo está organizado da
seguinte forma: a seção 3.1 descreve os objetivos e o cenário utilizado para realizar os experimen-tos; as seções 3.2 e 3.3 apresentam as configurações de software e hardware, respectivamente, do ambiente; a seção 3.4 define as métricas dos experimentos; a seção 3.5 apresenta os fatores e níveis para cada métrica analisada; e a seção 3.6 descreve o processo de coleta de dados.
3.1
Descrição dos Experimentos
Os experimentos tem como objetivo comparar o comportamento das variações no tempo no carregamento de páginas Web através de conexões HTTP/2 com e sem a utilização do recurso push. Os resultados devem ser significativos o bastante para indicar quais fatores devem ser considerados ao se optar por este recurso.
Com o objetivo de recriar ao máximo a utilização de um servidor HTTP/2 em um ambiente real, a escolha da configuração do ambiente do experimento foi focada em soluções mais próximas possível do padrão dos protocolos envolvidos. Na Figura 3.1, pode-se visualizar as principais entidades envolvidas nos experimentos e como as mesmas estão interligadas.
O ambiente apresentado na Figura 3.1 descreve um cenário de acesso a um servidor Web HTTP 1.1 utilizando um proxy reverso HTTP/2. Decidiu-se utilizar esta configuração de ambiente porque, durante o desenvolvimento desta dissertação, o software HTTP/2 utilizado ainda não possuía suporte ao backend FastCGI1e, portanto, dificultaria a criação de conteúdo de forma dinâmica.
Todas as requisições do cliente foram geradas por um navegador Web e possuem o mesmo servidor de destino para todos os objetos da página Web. A sequência de passos de uma requisição do experimento realizado são descritos no diagrama de sequência da Figura 3.2.
3.1. DESCRIÇÃO DOS EXPERIMENTOS 34
Figura 3.1: Entidades do ambiente
Fonte: Autor
Figura 3.2: Diagrama de sequência das requisições do cliente
3.2. INFRASTRUTURA DE SOFTWARE 35
3.2
Infrastrutura de Software
O backend de conteúdo do servidor Web HTTP 1.1 utiliza servidor Web Lighttpd versão 1.4.37, configurado na porta TCP 80 e com suporte a backend FastCGI habilitado o que possibilita a utilização de qualquer backend compatível. Além disso, utiliza scripts PHP para gerar conteúdo dinâmico baseado em parâmetros da URL. Desta forma, é possível que um cliente solicite um recurso com tamanho de dados específico.
Para garantir que solicitações a um mesmo objeto não gerem armazenamento em cache pelo navegador Web, além de omitir cabeçalhos de controle de cache, o conteúdo é gerado de forma pseudo-aleatória, através da função openssl_random_pseudo_bytes. Esta função não requer acesso a disco para gerar conteúdo, o que garante que os dados gerados sejam rapidamente disponibilizados ao servidor Web.
O servidor proxy HTTP/2 atua como gateway na conexão entre servidor Web e navega-dor Web do cliente. Este serviço implementa suporte ao protocolo HTTP/2 através do software Nghttp2, na versão 1.7.0, configurado na porta TCP 443(https), utilizando o servidor Web Lighttpd como backend HTTP. Bibliotecas desenvolvidas neste mesmo software são utilizados
em outras ferramentas popularmente utilizadas como cURL2e Wireshark3. O servidor oferece
suporte à extensão Application-Layer Protocol Negotiation (ALPN), provido pela camada de segurança Transport Layer Security (TLS). Através desta extensão, é possível informar quais os protocolos ofertados diretamente no final do handshake de segurança. Por padrão, o servidor suporta conexões em diferentes protocolos como HTTP/1.1, SPDY/3.1 e versões de desenvol-vimento do HTTP/2 como h2-16 e h2-14 além da versão final h2. Para restringir o anuncio de protocolos não relacionados aos experimentos, o parâmetro de configuração ’–npn-list=h2’ foi utilizado ao iniciar o serviço.
O cliente utiliza o navegador Web Google Chrome na versão 48.0.2564.82 (64-bit) que foi escolhido por ofertar suporte nativo ao HTTP/2, além de facilidades para coleta de dados e manipulação interativa através de sua interface de depuração remota. A instalação deste não teve qualquer tipo de configuração adicional e não foram utilizados plugins ou modificações internas. A Tabela 3.1 resume as versões e configurações dos softwares do ambiente.
As entidades em execução no servidor (servidor Web, servidor proxy e scripts PHP) foram compilados com base no sistema operacional Centos 7.0.1406 com o Kernel Linux 3.10.0-123.el7.x86_64. A entidade no cliente, o Google Chrome, é executada no sistema operacional
Fedora versão 22, utilizando o Kernel Linux 4.3.4200.fc22.x86_64.
2Disponível em: <https://curl.haxx.se>
3.3. INFRAESTRUTURA DE HARDWARE 36
Entidade Configuração do Software
Servidor Web
Lighttpd versão 1.4.37 TCP 80
backendFastCGI habilitado
Servidor Proxy
Nghttp2 versão 1.7.0 TCP 443
Servidor Web Lighttpd como backend
Cliente Google Chrome versão 48.0.2564.82 (64-bit)
Tabela 3.1: Entidades de Software
3.3
Infraestrutura de Hardware
A estrutura de hardware do ambiente possui componentes capazes de executar os
softwa-resde forma eficiente e sem gerar atrasos inesperados que poderiam influenciar na medição dos
experimentos. A Tabela 3.2 resume as configurações de hardware utilizadas.
Componete Processador Memória Rede
Servidor Dual Xeon L5410 12 GigaBytes Ethernet 100Mb/s
Cliente Quad core Intel i7 16 Gigabytes Ethernet 100Mb/s
Tabela 3.2: Componentes de Hardware
A interconexão entre os componentes é feita através da Internet, que não possui estrutura fixa de roteamento. Entretanto, durante a execução dos experimentos, foi possível observar um número constante de 13 saltos de rota e latência média entre 80 e 100 milissegundos entre o servidor, localizado em um data-center em Orlando, Flórida e o cliente na UFPE em Recife, Pernambuco.
3.4
Métricas
Para analisar quais os efeitos causados pelo uso do push em páginas Web, foram utilizadas duas métricas:
1. O intervalo de tempo para conclusão do download de todos os objetos das pági-nas Web. Para esta métrica foi definido o acrônimo Total Download Time (TDT). Esta considera apenas fatores relacionados a transações de rede, excluindo processos de renderização, validação e análise do conteúdo. Por estas restrições, foi possível utilizar um cliente HTTP/2 em linha de comando fornecido com a suíte de softwares do Nghttp2, o nghttp.
2. O intervalo de tempo decorrido entre a solicitação das páginas experimentais e o evento de conclusão de carregamento do DOM. Para esta métrica foi definido o
3.5. FATORES E NÍVEIS 37 acrônimo Page Load Time (PLT). Esta métrica considera o tempo utilizado pelos diferentes processos em um navegador Web até a ocorrência do evento DomConten-tloaded[2.3.2]. Este evento não indica a conclusão do carregamento da página, mas é utilizado por scripts Javascript para iniciar processos que efetuam modificações no DOM, que só pode ser alterado a partir deste evento.
Outros eventos gerados durante a construção do DOM foram considerados para se obter o intervalo de tempo utilizado na métrica PLT, porém apenas os eventos DomContentloaded e
loadsão registrados no arquivo HAR. Interações que ocorrem após o PLT, como requisições de
objetos assíncronos, não afetam a definição inicial do DOM e não foram consideradas durante os experimentos. Na prática, esta métrica considera que todo download e processamento dos objetos necessários para se iniciar a exibição da página foram concluídos.
Sendo o push um recurso interno do protocolo de aplicação, a análise neste estudo considera, em TDT, que este recurso interfere apenas no processo de rede e, em PLT, seu efeito no carregamento de páginas Web em um navegador e seus processos internos. Estes são diretamente dependentes das características de tamanho e quantidade dos objetos transferidos, além de depender de fatores de rede, como largura de banda e latência.
3.5
Fatores e Níveis
Alguns valores de níveis foram baseados em médias mineradas a partir do repositório Http Archive4, no intervalo de janeiro de 2013 a dezembro de 2015. O sistema de coleta utilizado pelo Http Archive utiliza arquivos HAR para obter seus dados que não possuem poder descritivo para identificar como os objetos estão apresentados no documento HTML. Dessa forma, eles serão considerados nos experimentos como sendo o pior cenário possível, onde todos os objetos do tipo JavaScript são externos e causam bloqueio no processamento do DOM.
Para definir o número de objetos do tipo JavaScript nos experimentos, utilizou-se como base os dados apresentados da Figura 3.3, que informa a frequência de números de objetos JavaScript.
Já para definir o tamanho dos objetos do tipo JavaScript, o nível do fator foi baseado na Figura 3.4, que representa a frequência de tamanhos de objetos também minerados do repositório Http Archive, coletados de janeiro de 2013 a dezembro de 2015.
É possível observar que em ambos os casos a maior concentração das frequências se encontra abaixo da metade dos intervalos coletados, entretanto , a implementação do experimento permite que sejam utilizados valores acima dos limites. Esta permeabilidade foi explorada apenas para os valores de número de objetos a fim de confirmar a continuidade do comportamento mesmo em casos muito acima da média. A Tabela 3.3 apresenta todos os fatores e seus respectivos níveis utilizados nos experimentos para a análise das métricas definidas.
3.5. FATORES E NÍVEIS 38
Figura 3.3: Frequência de número de objetos do tipo JavaScript por página
Fonte: Autor
Figura 3.4: Frequência de Tamanho de objetos do tipo JavaScript por página
3.5. FATORES E NÍVEIS 39
Fator Níveis
Tamanho 100KB a 2000KB com incremento de 100KB
Número de Objetos 10 a 200 com incremento de 10
Tabela 3.3: Fatores e Níveis
Por não existir um modelo descritivo padrão para representar páginas Web, outros estudos como [BUTKIEWICZ; MADHYASTHA; SEKAR (2011) e SIVAKUMAR et al (2014)] utilizam cópias de conteúdo de sites reais em um determinado período do tempo e os reutilizam durante os experimentos. Normalmente, os sites são selecionados com base em classificação de popularidade e tendem a representar o comportamento de uma população maior de sites.
Além da cópia do conteúdo das páginas, é necessário duplicar todo o comportamento da sessão fornecida pelos servidores originais, um processo complexo e difícil de se implementar com precisão. Por estes motivos, optou-se pela criação de páginas Web sintéticas que represen-tem a mesma carga de páginas com características similares. Esta estratégia possui algumas características e restrições a serem destacadas:
1. Descrição Mínima: O documento HTML não contém informações além das necessá-rias para descrever os objetos. Apenas o elemento BODY, é preenchido com conteúdo aleatório para completar o tamanho do arquivo HTML quando necessário. Com esta configuração, é possível determinar de forma mais precisa o tamanho do arquivo antes de ser enviado na rede sem gerar processamento de análise de marcadores no navegador, o que poderia alterar o PLT.
2. Objetos externos: Objetos do tipo JavaScript são definidos por URLs no atributo “src” sem o uso de atributos “async” ou “defer”, o que força a interpretação deste
objetos assim que disponíveis no navegador Web.
3. Mesma Origem: Objetos externos em páginas reais podem ser fornecidas por ser-vidores distintos com diferentes características de rede além de gerar conexões adicionais. Como o foco deste estudo está apenas no HTTP/2, que utiliza uma mesma conexão para transferir todos os recursos, os objetos externos são fornecidos pelo mesmo servidor.
4. Conteúdo Aleatório: Com exceção dos marcadores e seus atributos, o conteúdo dos objetos são aleatórios e alterados a cada requisição. A interpretação destes objetos pelo navegador Web não será possível, influenciando apenas no tempo de download destes objetos. Devido a natureza aleatória, não há interferência de mecanismos de
cacheque poderiam invalidar as medições.
Estas características e restrições contribuem para que cada execução do experimento seja similar ao primeiro acesso às páginas. Porém, outras considerações devem ser previstas para obter este comportamento.
3.6. COLETA DE DADOS 40
3.6
Coleta de Dados
Para coletas referentes a TDT, foi utilizado o cliente de linha de comando nghttp, que não possui a complexidade de processos de um navegador Web ou qualquer tipo de mecanismo de cache. O funcionamento desta ferramenta ocorre nas seguintes etapas:
1. Conexão: Após identificar o protocolo e servidor através da URL provida, a conexão com o servidor é negociada e estabelecida.
2. Download e Análise: O principal recurso fornecido pelo servidor é um documento HTML que, assim que disponibilizado, é tratado para se obter a lista dos próximos objetos a serem solicitados
3. Downloads adicionais: os objetos identificados no passo anterior são solicitados ao servidor.
A análise do documento HTML no passo 2 utiliza expressões regulares implementadas em C, capazes de obter as URLs dos objetos externos entre 1 e 5 milissegundos, e interfere minimamente na precisão da medição. Os resultados fornecidos pela ferramenta cliente nghttp já desconsideram o tempo de carregamento do programa, tratamento da URL e possível resolução de DNS.
Para analisar o impacto dos fatores no TDT, os experimentos realizados consideraram variações de apenas um dos fatores por vez, mantendo-se fixo os demais. Em todos os experi-mentos foram efetuadas 100 repetições em cada ponto de verificação do fator analisado. Desta forma o ambiente foi configurado de 3 formas distintas, sendo elas:
Tamanho dos Objetos: Foi utilizado um número fixo de objetos sendo 17 o valor
observado na média de número de objetos de acordo com o repositório Http Archive. O fator latência de rede não foi modificado sendo o valor médio observado inferior a 100ms.
Número de Objetos: O número de objetos influencia diretamente no número de
streamsconcorrentes. Para manter esta concorrência durante o maior tempo possível
foi considerado o pior caso do tamanho de objetos sendo fixo em 2048KB. A latência de rede não foi modificada.
Os dados dos experimentos referentes a PLT são obtidos de arquivos HAR gerados pelo navegador Web Google Chrome durante o acesso as páginas genéricas de diferentes ca-racterísticas. O arquivo de registro HAR é gerado manualmente pela opção “ferramentas do desenvolvedor” e contém, além de detalhes de transferências na rede, o registro dos eventos load e DomContentLoaded.
3.6. COLETA DE DADOS 41 Para serializar a coleta de dados gerados pelo navegador foi utilizado a ferramenta chrome-har-capture5versão 0.6.0 que usa as funcionalidades providas pela interface de depuração remota do Google Chrome para efetuar ações de limpeza de cache, carregamento de páginas e exportação de arquivos HAR. Como requisito funcional para utilizar a ferramenta, o navegador deve utilizar os seguintes parâmetros de inicialização: ’–remote-debugging-port=PORT’ que ativa a interface de depuração remota na porta especificada, ’–enable-benchmarking’ e ’–enable-net-benchmarking’ que habilitam funcionalidades adicionais de depuração por funções de javascript utilizados para limpar o cache de DNS e pilha de Sockets interna do navegador. A organizacão destas opções pode ser melhor observada no script utilizado para coletas no apêndice A.1. Com estas configurações cada execução do experimento não influencia nos resultados dos seguintes, garantindo a validade das medições realizadas.
As configurações do ambiente foram definidas pela variação de um fator por vez, sendo definidos os seguintes cenários:
Tamanho dos Objetos: O valor médio de 17 objetos foi utilizado neste cenário.
Número de Objetos: Para considerar os casos mais extremos foram duas
configura-ções de tamanho, sendo uma de 100KB e ou de 2048KB.
42 42 42
4
Análise de Desempenho do HTTP/2
Este Capítulo apresenta os resultados dos experimentos descritos no Capítulo 3, ana-lisando duas importantes métricas, TDT e PLT, e discutindo o impacto do recurso push na percepção do usuário. Para tanto, este Capítulo está estruturado da seguinte forma: a Seção 4.1 descreve os resultados referentes a métrica TDT; enquanto que os resultados da métrica PLT são apresentados na Seção 4.2; Por fim os resultados são discutidos na Seção 4.3
4.1
Análise do TDT
4.1.1
Impacto do tamanho dos objetos
Os valores obtidos nos experimentos pela variação do tamanho de objetos são apresen-tados na Figura 4.1. Os grupos de experimentos apresentam incremento linear em função do tamanho dos objetos. O padrão visual dos intervalos de desvio padrão em relação as médias de cada grupo de experimentos indicou uma possível igualdade estatística. Para confirmação ou refuta desta hipótese o teste estatístico ANOVA foi executado e os dados obtidos são apresentados na tabela 4.1.
Sendo o nível de significância considerado em 5%, pares de grupos com valor de P inferiores ou iguais a 0.05 são ditos como sendo similares. Os tamanhos de 400KB e 1200KB possuem valores de P relativamente próximos ao limite de significância, o que pode indicar que em um número maior de amostras deste grupo deve gerar um valor de P inferior a 0.05. Considerando o nível de significância em 6%, 70% dos experimentos apresentam similaridade.
4.1.2
Impacto do número de objetos
A Figura 4.2 apresenta os dados coletados nos experimentos com variação do fator número de objetos.
Os valores apresentam grande dispersão, sendo este efeito mais frequente no uso do recurso push no intervalo de 17 a 110 objetos. Apesar desta dispersão, o teste estatístico ANOVA apresentado na Tabela 4.2 indica quais grupos possuem similaridades estatísticas.
4.1. ANÁLISE DO TDT 43
Figura 4.1: Comparativo do Tamanho dos Objetos para TDT
Fonte: Autor
Tamanho do Objetos (KB) Valor de P
100 0,0065949320 200 0,0000000828 300 0,0000000115 400 0,0519780950 500 0,0000302158 600 0,0000001859 700 0,0011688200 800 0,9232040040 900 0,1767195460 1000 0,0000005482 1100 0,0108335000 1200 0,0545738850 1300 0,9227543400 1400 0,0876566950 1500 0,0000000001 1600 0,1001646280 1700 0,0000000001 1800 0,0000000001 1900 0,2756766390 2000 0,0000000010
4.1. ANÁLISE DO TDT 44
Figura 4.2: Comparativo do Número de Objetos em TDT
Fonte: Autor
Número de Objetos Valor de P
10 0,091156392 20 0,405630161 30 0,008142196 40 0,436709402 50 0,204808861 60 0,091535550 70 0,000216569 80 0,00000022 90 0,139919023 100 0,224896469 110 0,016491718 120 0,501768027 130 0,304275747 140 0,091697702 150 0,013965674 160 0,006070323 170 0,007379301 180 0,019692227 190 0,000241668 200 0,060357077
4.2. ANÁLISE DO PLT 45 Para o nível de significância em 5%, valores de P inferiores a 0,05 correspondem a similaridade entre os experimentos; neste caso, apenas 9 dos 20 experimentos são similares.
Os resultados obtidos pela métrica TDT indicam que a quantidade de streams concorren-tes, independentes do tipo, não afetam de forma crítica o tempo no processo de rede. Apesar de não haver confirmação estatística de igualdade nos streams do tipo push e não push, ambos apresentam comportamento similar nos diferentes cenários. Esta caraterística é esperada devido o design do protocolo HTTP/2, uma vez que o mesmo utiliza multiplexação, e também indica que a compactação de cabeçalhos não causa overhead.
Os níveis de dispersão apresentados com maior evidência durante o uso do recurso
pushnos experimentos com maiores números de objetos podem estar relacionados ao grande
número de conexões efetuadas entre o servidor proxy e o servidor Web em um curto intervalo de tempo. Este evento ocorre pois para cada objeto a ser enviado através do recurso push, uma nova solicitação é gerada ao servidor Web, sendo necessário que o servidor proxy aguarde o recebimento do código de status antes de efetuar o envio dos respectivos frames do tipo PUSH_PROMISE.
4.2
Análise do PLT
4.2.1
Impacto do tamanho dos objetos
A Figura 4.3 apresenta o comparativo do tamanho dos objetivos para a métrica de PLT. Como pode-se observar, os grupos de experimento entre 100KB e 500KB apresentam degradação no PLT ao se utilizar o recurso push. Este efeito se inverte a partir de 900KB em diante. O intervalo entre 600KB e 800KB não indica diferenças no PLT no uso ou não do recurso.
4.2.2
Impacto do número de objetos
Para a análise do impacto do número de objetos, foram considerados dois valores fixos de tamanho, sendo o de 100KB representado na Figura 4.4, e o 2048KB, na Figura 4.5. Esta configuração considera os tamanhos limites observados na análise anterior de tamanho.
Os valores observados em ambos os gráficos confirmam a distinção no PLT em função do uso do push. No caso onde o tamanho dos objetos é de 100KB, o push demostra tempos maiores em todos os experimentos, com maior evidencia em números menores de objetos. O efeito oposto é observado no caso de 2000KB onde, no intervalo de 70 a 160, há distinção mais acentuada.
Assim, através destes experimentos, pode-se observar que o tempo de carregamento de páginas Web pode ser negativamente afetado em função do tamanho dos objetos trans-feridos, principalmente em tamanhos inferiores a 500 KiloBytes. Por outro lado, o número de objetos não causa o mesmo impacto. Seguindo este mesmo comportamento é possível que
4.2. ANÁLISE DO PLT 46
Figura 4.3: Comparativo do Tamanho dos objetos para PLT
Fonte: Autor
Figura 4.4: Comparativo do Número de Objetos de 2000KB para PLT
4.3. DISCUSSÕES 47
Figura 4.5: Comparativo do Número de Objetos de 100KB para PLT
Fonte: Autor
páginas com tais características, ao utilizar técnicas de push para transmissão de objetos do tipo JavaScript, apresentem degradação no tempo de carregamento.
4.3
Discussões
Estudos propostos por Varvello et al (2016) acompanham o crescimento da adoção do HTTP/2 através da varredura contínua de servidores que hospedam os sites mais populares
pelo Alexa. Os dados apresentados na plataforma1revelam que a maioria das páginas, apesar
de divulgarem que estão utilizando HTTP/2, não efetuam, de fato, alterações na estrutura dos objetos servidos através do novo protocolo.
De acordo com os resultados obtidos neste trabalho, pode-se reconfirmar esta necessidade, ressaltando inclusive que caso estas alterações não sejam realizadas, pode-se obter efeito oposto ao proposto pelo padrão, ou seja, ao invés de se melhorar o carregamento de páginas, pode-se experienciar degradação.
