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 Pernambucoposgraduacao@cin.ufpe.br

www.cin.ufpe.br/~posgraduacao

RECIFE2016

Igor Nogueira de Oliviera

ANÁLISE DE PERFORMANCE DO PUSH EM CONEXÕES HTTP/2NO 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

RECIFE2016

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 naminha 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 nomeu potencial acadêmico e ingressar no mestrado. Pela compreensão, paciência e apoio contínuonesta e (espero) nas futuras jornadas da minha vida.

A vários amigos como Danilo Lima Dutra, por conseguir minha dispensas do trabalhonos 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 adversidadesclimáticas na várias viagens para as aulas.

Aos meus amigos do grupo de pesquisa GPRT, Wesley Melo, Maria Silvia Ito, CarolinaCani e demais que de alguma forma contribuíram imensamente em vários momentos.

Por fim a minha querida família pelo amor e compreensão durante toda minha vida.

Any sufficiently advanced technology is indistinguishable from magic.

—ARTHUR C. CLARKE

Resumo

Desde sua padronização, o protocolo Hypertext Transfer Protocol (HTTP) tornou-seo estado da arte em protocolos de transporte da internet, sendo utilizado para transmissão dearquivos 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 fatode atender requisições de forma síncrona, o que normalmente atrasa a renderização de páginasWeb podendo vir a afetar a qualidade de experiência dos usuários. Recentemente, o protocoloHTTP foi atualizado para a versão HTTP/2, recebendo diversas modificações, direcionadasprincipalmente 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 servidor Web responda a uma solicitaçãocom mais de um recurso ao mesmo tempo. Este trabalho apresenta uma análise de desempenhodo recurso push no transporte de páginas Web em conexões HTTP/2. Para tanto, foram realizadosexperimentos 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 deanálise e a execução do experimento foi realizada através de requisições de páginas web comdiferentes quantidades e tamanhos de objetos. Através dos resultados obtidos, foi possívelobservar que apesar do protocolo HTTP/2 possuir recursos para a melhoria do carregamentode páginas Web o uso inadequado destes recursos pode causar, em determinadas configurações,degradações no carregamento das páginas.

Palavras-chave: HTTP/2. server push. avaliação de desempenho. TDT. PLT.

Abstract

Since its standardization, the Hypertext Transfer Protocol (HTTP) has been consideredthe state of the art for transmission of hypertext and hypermedia files, such as audio and videoin an interactive way. However, 1.0 and 1.1 versions of HTTP present some weaknesses thatmay be optimized, such as synchronized requests, which typically slow Web pages renderingthus affecting the end user experience. Recently, the protocol was updated to the 2.0 version andreceived several modifications, focused mainly on improvements in the network usage. Amongthese improvements one can cite the addition of push, a feature that allows the server to reply to arequest with more than one resource simultaneously. This work presents a performance analysisof push feature on the transport of web pages on HTTP/2 connections. Therefore, experimentswere conducted on a prototype environment using Total Download Time (TDT) and Page LoadTime (PLT) as metrics, and Web page requests with different amounts and sizes of objects. Fromthe 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.

Keywords: HTTP/2. server push. performance evaluation. TDT. PLT.

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. . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Proxy HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Gateway HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4 Túnel HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5 Efeito HOL Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6 Diagrama de eventos em técnicas de polling HTTP . . . . . . . . . . . . . . . 232.7 Encapsulamento binário. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8 Codificação Huffman em um cabeçalho HTTP/2 . . . . . . . . . . . . . . . . . 252.9 Visão geral de uma sessão Hypertext Transfer Protocol 2.0 (HTTP/2). . . . . . 252.10 Árvore de dependência com pesos. . . . . . . . . . . . . . . . . . . . . . . . . 262.11 Solicitacão e resposta com server push . . . . . . . . . . . . . . . . . . . . . . 272.12 Representação visual do HAR e seus eventos. . . . . . . . . . . . . . . . . . . 31

3.1 Entidades do ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2 Diagrama de sequência das requisições do cliente . . . . . . . . . . . . . . . . 343.3 Frequência de número de objetos do tipo JavaScript por página . . . . . . . . . 383.4 Frequência de Tamanho de objetos do tipo JavaScript por página . . . . . . . . 38

4.1 Comparativo do Tamanho dos Objetos para TDT . . . . . . . . . . . . . . . . 434.2 Comparativo do Número de Objetos em TDT . . . . . . . . . . . . . . . . . . 444.3 Comparativo do Tamanho dos objetos para PLT . . . . . . . . . . . . . . . . . 464.4 Comparativo do Número de Objetos de 2000KB para PLT . . . . . . . . . . . 464.5 Comparativo do Número de Objetos de 100KB para PLT . . . . . . . . . . . . 47

Lista de Tabelas

3.1 Entidades de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2 Componentes de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3 Fatores e Níveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1 Valores P para Tamanho dos Objetos para TDT . . . . . . . . . . . . . . . . . 434.2 Valores P para Número de Objetos em TDT . . . . . . . . . . . . . . . . . . . 44

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

W3C World Wide Web Consortium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Sumário

1 Introdução 141.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.3 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Fundamentação Teórica 172.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.2.1 Principais Modificações . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.2 Push não é Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Complexidade de Páginas Web . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.3.2 Do HTML a Página Web . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.3 HAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Metodologia 333.1 Descrição dos Experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2 Infrastrutura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3 Infraestrutura de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.4 Métricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.5 Fatores e Níveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.6 Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Análise de Desempenho do HTTP/2 424.1 Análise do TDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.1 Impacto do tamanho dos objetos . . . . . . . . . . . . . . . . . . . . . 424.1.2 Impacto do número de objetos . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Análise do PLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.1 Impacto do tamanho dos objetos . . . . . . . . . . . . . . . . . . . . . 454.2.2 Impacto do número de objetos . . . . . . . . . . . . . . . . . . . . . . 45

4.3 Discussões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5 Conclusão e Trabalhos Futuros 485.1 Dificuldades encontradas e limitações do trabalho . . . . . . . . . . . . . . . . 495.2 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Referências 50

Apêndice 52

A Apêndice 53A.1 Script de Coleta dos experimento do PLT . . . . . . . . . . . . . . . . . . . . 53

141414

1Introduçã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 umaampla aceitação. Os motivos foram, além de manter sua funcionalidade original de transmissãode arquivos hipertexto, prover o transporte de mídias mais dinâmicas, hoje denominadas comohipermídias, tais como áudio e vídeo, não apenas em tempo real, como também de forma cadavez mais interativa. Mesmo com a diversidade de funcionalidades e características dos aplicativosweb, 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çãode controle não compactado e em texto plano, sendo este último um fator incremental nacomplexidade computacional para análise de identificadores de quebra de linha (NIELSENet al, 1998). Além disso, segundo os mesmos autores, as restrições tornaram sua documentaçãodesnecessariamente extensa e complexa, dificultando que suas implementações contivessemtodas as funcionalidades definidas pelo padrão. Estes e outro pontos já eram identificados comofalhos 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ãodirecionadas ao melhor aproveitamento da rede. Para isso foram propostos o uso de codificaçãobiná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 dentrode uma mesma conexão. Com isso, espera-se a diminuição do número de conexões ativas econsequentemente menor carga em vários pontos da rede.

Dentre as novas características do HTTP/2, o push permite o envio de recursos peloservidor 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 depipelining e técnicas de polling. Porém, ela ainda dependia da requisição explícita do clienteantes de efetuar o envio do conteúdo do recurso solicitado. Devido a natureza do modelosolicitação/resposta do HTTP, durante a utilização de pipelining, é possível que uma solicitaçãoseja 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 eGoogle2 entre 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 interessedos usuários, o Google aumentou o numero de resultados em sua páginas de busca de 10 para30. Ao contrário do esperado a quantidade de usuários efetuando busca reduziu em 20%, apósuma analise mais criteriosa foi identificado que a modificação inadvertidamente gerou aumentono tempo médio de carregamento da página de 400ms para 900ms. Experimentos similaresforam efetuados na rede de sites da Amazon onde foram inseridos pequenos atrasos, múltiplosde 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 suasespecificaçõ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>3Disponível em: <http://glinden.blogspot.com.br/2006/11/marissa-mayer-at-web-20.html>

1.2. OBJETIVOS 16

web. Dessa forma, o impacto que estes novos recursos causam ainda não foram extensamenteanalisados na prática.

Este trabalho apresenta uma análise de desempenho do recurso push no transporte depáginas web em conexões HTTP/2 através de experimentos. Um servidor que implementa oHTTP/2 foi configurado para responder a solicitações de páginas web de diferentes característicascomo quantidade e tamanho de objetos. Com isso foi possível duplicar a carga de rede gerada nocarregamento de páginas web de diferentes configurações. A partir deste ambiente foi utilizadoum cliente web compatível para acessar e capturar dados de temporização do carregamento depáginas Web em diferentes condições de rede.

1.2 Objetivos

Esta dissertação tem como objetivo principal analisar o impacto do recurso push providopelo 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 consideradosneste estudo. O Capítulo 3 descreve a metodologia utilizada para realizar os experimentos, bemcomo os valores e justificativas das métricas e fatores. O Capítulo 4 apresenta os resultadosdos experimentos e a análise acerca dos dados obtidos. E, por fim, o Capítulo 5 descreve asconclusões e trabalhos futuros.

171717

2Fundamentação Teórica

Este capítulo apresenta os conceitos fundamentais para o entendimento do trabalhoproposto nesta dissertação, referentes ao funcionamento do protocolo HTTP/2 (Seção 2.2), bemcomo 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-WideWeb desde 1990. A primeira versão do HTTP, referida como HTTP/0.9, foi definida como umsimples 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 noformato Multipurpose Internet Mail Extensions (MIME). No entanto, o HTTP/1.0 ainda possuíaalguns pontos fracos por não considerar funcionalidades como:

� Entidades Intermediárias: Necessários para prover tradução de protocolos, análisede 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áriospara 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 gerandooverhead.

Além disso, a proliferação de aplicações implementadas de forma incompleta, quese autodenominaram "HTTP/1.0", resultaram em comunicações inconsistentes por falta deconfirmaçã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 (FIELDINGet al, 1997); revisada na RFC 2616 (FIELDING et al, 1999). Dentre as principais modificaçõespropostas na versão 1.1, pode-se destacar a possibilidade do uso de conexões persistentes para

2.1. HTTP 18

downloads de vários recursos de forma sequencial (pipelining) como a que teve maior impactono 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á-seda seguinte maneira: um cliente HTTP inicia uma solicitação através de uma conexão TCP parauma 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 voltaum código de status, como por exemplo "200 OK", e, opcionalmente, o conteúdo no restantedo corpo da resposta. O corpo desta mensagem é normalmente o recurso solicitado, apesarde 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 ResourceLocators (URL), utilizando os esquemas de Uniform Resource Identifier (URI) http ou httpspara 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çãoem uma determinada solicitação. O HTTP 1.0 definiu 3 métodos, sendo eles: GET, POST eHEAD , utilizados para solicitar conteúdo, enviar conteúdo e solicitar apenas meta informaçõesde 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 permiteque outros métodos sejam definidos por extensões.

Todas as mensagens, sejam de solicitação ou resposta, são definidas utilizando-se amesma 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 realizarsolicitações em nome de um cliente a servidores remotos. Solicitações podem serrespondidas diretamente ou repassadas ao próximo servidor. Um servidor proxy deveinterpretar e, se necessário, modificar mensagens HTTP antes de encaminhá-las. Nor-malmente, servidores proxy são utilizados para prover acesso a clientes localizadosem uma intranet que não possuem acesso a rede externa sem a necessidade de utilizarNetwork Address Translation (NAT). A Figura 2.2 apresenta as interconexões entreentidades 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 seeste fosse de fato o servidor Web remoto, do ponto de vista do cliente. Tambémconhecido como surrogate ou proxy reverso, servidores gateway normalmente seencontram na rede próxima aos servidores de conteúdo atuando como balanceadoresde 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 entrecliente e servidor. Um vez ativo um túnel não é considerado nas mensagens HTTP enão efetua qualquer tipo de tratamento nas mensagens. A Figura 2.4 representa umcenário com utilização de um túnel HTTP.

Um mesmo programa pode implementar todas as funcionalidades dependendo apenas desuas configurações ou localização na rede. O serviço de proxy pode ser o funcionamento padrãopara conexões a servidores remotos, gateway para recursos disponíveis em servidores locais etúnel em conexões onde não é possível analisar as informações das mensagens, como conexõesencriptadas.

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 novarequisição aguarde a conclusão da requisição anterior. Este comportamento força solicitaçõesde 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 naversão 1.1, que permite que várias requisições sejam geradas antes de se receber a respectivaresposta. Apesar das requisições serem geradas de forma serial, não há garantias que as respostassejam recebidas na mesma ordem que foram geradas. Recursos diferentes podem ter tempode processamento distintos no servidor ou ainda podem trafegar por caminhos com latênciasdistintas. 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çõesanteriores; este efeito é denominado HOL Blockings. A Figura 2.5 representa como umasequencia 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 desenvolvidase 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 havendopossíveis restrições pelo navegador. Múltiplas conexões TCP originadas de ummesmo endereço em um curto período de tempo podem ser um indicador de tentativade Denial-of-service (DoS) e causar um possível bloqueio de novas conexões destaorigem. 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ãose aplica a tal restrição. Conexões ativas também consomem recursos de memóriae processamento de forma progressiva e devem ser levadas em consideração comolimitador de desempenho, tanto do servidor como do cliente;

� Image Spriting: O modelo original de requisição e resposta do HTTP pode ser umfator de atraso para o download de conteúdo em páginas Web que possuem grandequantidade de objetos. Este problema é ainda mais notável em redes de alta latência equando os recursos em questão são consideravelmente grandes, por exemplo arquivosde imagens. A técnica de Image Spriting consiste em agrupar várias imagens emapenas um arquivo, reduzindo o número de requisições, que melhora a escalabilidadede largura de banda da conexão. Uma vez feito o download do arquivo de Sprite, sãoutilizadas funções de Cascading Style Sheets (CSS) e/ou JavaScript para exibir asimagens em seus locais esperados, gerando carga de processamento no cliente pararenderização do conteúdo;

� Concatenação e Minificação: Técnica similar à de Image Spriting, porém utilizada

2.2. HTTP/2 22

em objetos do tipo CSS e JavaScript, que, por serem do tipo texto plano podem sermelhor agrupadas, removendo-se caracteres dispensáveis para sua execução, comoespaços em branco e quebra de linhas ou até mesmo alteração de nome de variáveispara nomes menores.

� Resource Inlining: Definições de estilo e blocos de JavaScript podem ser inseridasdiretamente no objeto raiz da página Web, ou seja, diretamente dentro de tags HTMLatravés de atributos. Isso ajuda a diminuir o numero de objetos de CSS e JavaScript eevita que haja necessidade de aguardar que estes objetos sejam carregados para usode algumas de suas funções;

� Long Polling e Streaming: Diferentes mecanismos foram implementados a fim depermitir comunicação assíncrona entre cliente e servidor sem violar as definiçõesoriginais do HTTP, onde todas as solicitações são iniciadas pelo cliente. Ideal-mente atualizações disponíveis no servidor são enviadas diretamente ao cliente assimque disponíveis. Algumas considerações e boas práticas destes mecanismos foramdocumentados na RFC 6202 (LORETO et al, 2011).

Long Polling: O servidor não responde solicitações de imediato mantendo-acomo pendente do ponto de vista do cliente. A solicitação só é respondida após algumevento no servidor que indique que existem novos dados a serem enviados. Nestemecanismo, o cliente deve sempre manter uma solicitação pendente aguardandonovas 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 respostafoi concluída é emitida. A Figura 2.6 apresenta o diagrama de eventos para as duasestraté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 ladocliente 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 grupode trabalho, o HTTPBis. O grupo seria responsável por inicialmente revisar e atualizar todas asconsideraçõ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 quepoderiam 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 derede do Facebook2, relata quais características consideravam importantes na nova versão paraatender 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 SoftwareFoundation), apenas o SPDY atendia a maioria das características, além de já ser utilizadointernamente na infraestrutura de rede do Facebook e em maior escala pela Google. Neste pontoda 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ópiadireta da especificação do SPDY, até sua padronização oficial pela IETF em maio de 2015 atravésdas RFCs 7540 e 7541. Apesar da existência de diversas implementações e discussões pelacomunidade ativa, o processo foi considerado muito rápido e possivelmente tendencioso até suaformalização (KAMP, 2014).

2.2.1 Principais Modificações

As principais limitações do HTTP 1.1, como HOL Blocking, codificação em textoplano e falta de compressão de informações de controle (cabeçalhos), foram consideradasdurante o processo de padronização da versão 2.0. Outros fatores técnicos de performanceforam 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>2Disponível em: <http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html>

2.2. HTTP/2 24

dos servidores. Além disso, o principal objetivo era implementar o uso de apenas uma conexãoentre 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 designde funcionamento não afeta a semântica de alto nível do protocolo que continuasendo idêntico ao utilizado em sua versão anterior. A Figura 2.7 representa onde oencapsulamento 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 dadospara a camada seguinte, similar a uma camada intermediária.

� Compactação de cabeçalho: Inicialmente, a compactação utilizada seria a mesmado 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 denomes de métodos que se repetem várias vezes durante uma sessão colaboram com aeficiê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 osframes de uma mesma sessão(tabela estática), e possível adição de itens específicos

3Disponível em: <https://http2.github.io>4Disponível em: <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-4929>

2.2. HTTP/2 25

do frame. A compactação é então obtida pois apenas os números referentes as chavessão transmitidos pela rede, no caso de itens específicos do frame são enviados porcompleto 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 mesmaconexão Transmission Control Protocol (TCP), este recurso segmenta o trânsito demensagens HTTP em diferentes streams através do uso de frames. A Figura 2.9representa 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 queestes foram iniciados pelo cliente, enquanto que pares são para streams inciadospelo servidor. Cada frame possui um identificador do stream que pertence alémde informações adicionais de controle de sequência. Desta forma é possível quesejam 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 canalde forma assíncrona, como Server Push.

� Priorização de streams: A sequência em que os frames são enviados na rede nãogarante que os mesmos sejam entregues em ordem por possíveis retransmissões e/ouatrasos do TCP; entretanto, se considerarmos que os pacotes chegam na mesmaordem que são enviados, a sequência dos frames transportados pode ser utilizadapara definir prioridade a determinados recursos. Para permitir o uso de prioridades, aespecificaçã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 paradeclarar dependência exclusiva. Com estas informações, é possível criar uma árvorede dependências baseada em pesos. A Figura 2.10 representa como esta árvore deveser 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 ocupamo 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 e4, e portanto, a quantidade de recursos destinada a cada fluxo pode ser calculadautilizando uma média ponderada. Logo 3/4 dos recursos disponíveis para enviodevem conter dados do stream A e apenas 1/4 do stream B.

Não há uma interpretação clara no quesito recurso que cada uma destas prioridadesdeve utilizar, mas na prática a maioria das implementações utiliza o valor para dividira quantidade de dados a ser enviada por vez com base no tamanho de janela decongestionamento 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 sequenciade 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 demensagens entre o cliente e servidor que são descritos nos seguintes passos:

1. O servidor recebe uma solicitação que pode ter recursos adicionais comoresposta;

2. No mesmo stream utilizado para responder à solicitação, o servidor enviaum frame do tipo PUSH_PROMISE para cada recurso que deseja enviarvia push. O frame PUSH_PROMISE contem um número de stream a serutilizado pelo cliente para identificar futuros frames de dados do push;

3. O servidor considera como criado os streams informados no passo 2 eenvia, 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 peloPUSH_PROMISE ou;

� enviar um frame do tipo RST_STREAM informando que nãoirá aceitar o envio de push.

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çãodo protocolo.

Este trabalho irá estudar mais profundamente este recurso, pois os possíveis efeitoscausados pelo seu uso ainda não foram devidamente analisados. Portanto, a próximasub-seção descreverá em mais detalhes o Push em relação a outras estratégias comfuncionalidade 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 acomunicação entre o cliente e servidor é de fato síncrona e iniciada pelo cliente. As principaislimitaçõ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, ooverhead pode representar uma grande percentagem dos dados transmitidos. Esteefeito é particularmente indesejado em redes tarifadas por volume a exemplo dealgumas redes móveis;

� Latência Máxima: Devido a natureza do modelo de solicitação/resposta do HTTPexigir interações síncronas, cada mensagem enviada deve aguardar confirmação antesde novas mensagens serem geradas. Com isso a latência entre as mensagens pode serde até 3 Round Trip Times (RTTs), caso uma solicitação seja efetuada enquanto outraainda se encontra em trânsito na rede. A utilização de pipelining ajuda a amenizareste efeito. Porém, não é suportado por padrão na maioria dos navegadores (GoogleChrome5 , Mozilla Firefox6);

� Alocação de Recursos: Para evitar desperdício de recursos, os servidores estipulamum tempo limite para conexões sem atividade. Isso pode ser uma restrição muitorígida em relação a frequência de utilização durante o polling, exigindo que novasconexões sejam abertas em curtos intervalos de tempo.

� Entidades intermediárias: Servidores de proxy podem não permitir conexões comgrande duração mesmo quando permitido pelo servidor remoto. A aglomeração demensagens utilizado no streaming pode gerar quadros HTTP segmentados; entidadesintermediárias podem causar atraso ao aguardar que todos os segmentos sejamrecebidos antes de retransmiti-los ao servidor.

5Disponível em: <https://www.chromium.org/developers/design-documents/network-stack/http-pipelining>6Disponível em: <http://kb.mozillazine.org/Network.http.pipelining>

2.3. COMPLEXIDADE DE PÁGINAS WEB 29

Outras considerações mais detalhadas podem ser encontradas na RFC 6202 (LORETOet al, 2011). O recurso push do HTTP/2 não requer complexidade adicional, nem gera carga emcomparaçã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 novosdados, pois estes são enviados assim que disponíveis de forma assíncrona em relação aos demaisstreams.

2.3 Complexidade de Páginas Web

Esta seção descreve a complexidade envolvida no transporte e apresentação de páginasWeb.

2.3.1 HTML

O HyperText Markup Language (HTML) é uma linguagem de marcação utilizada paracriar páginas Web. Em conjunto com CSS e JavaScript, o HTML é utilizado pela maioria dosWeb-sites para criar páginas visualmente ricas, interfaces de aplicativos Web e aplicativos dedispositivos 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 doHTML são mantidas pela World Wide Web Consortium (W3C).

Navegadores Web utilizam arquivos HTML como base para renderizar páginas quepodem conter texto, hyperlinks, imagens, objetos de mídia, como áudio e vídeo inclusive outraspaginas 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 semconteúdo, como o marcador “<img>”. Em ambos os casos, é possível adicionar informações deatributos 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 atributosdos marcadores para criar elementos HTML. Os elementos <html>, <head> e <body> sãodenominados como contêineres estruturais para um documento HTML e contém informaçõesespecíficas:

� HTML: Todos os elementos de um documento HTML devem estar contidos dentrodo elemento <html>, denominado elemento raiz, sendo o único a ter o atributo denome “documentElement” na árvore Document Object Model (DOM).

� HEAD: Contém elementos com informações de metadados do documento e infor-mações de processamento do documento. Elementos dentro deste contêiner não

2.3. COMPLEXIDADE DE PÁGINAS WEB 30

são renderizadas na página Web, porém podem ser utilizados para indicar outrosobjetos que são necessários para o processamento dos demais elementos visuais. Osseguintes elementos podem existir neste contêiner:

� <base>: Especifica qual o prefixo de URL deve ser utilizado nas próximasURLs 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, datade publicação e data de validade. Palavras-chave são comumente descritasatravés dos atributos deste tipo de elemento. Não há um padrão obrigatóriopara definir os possíveis atributos e seus valores.

� <script>: Pode conter blocos de scripts ou referência a outro objeto quecontenha scripts através do atributo src. Quanto utilizado o atributo src oelemento <script> pode conter adicionalmente os atributos mutuamenteexclusivos “async” e “defer” indicando quando o script deve ser executado,sendo definido “async”, o script deve ser executado de forma assíncrona aoutros processos do navegador; quando “defer” o script deve ser executadoapenas após a conclusão da analise do documento. Na ausência destesatributos o script deve ser executado assim que disponível, antes que onavegador prossiga na análise do documento.

� <style>: O conteúdo deste elemento é utilizado para definir estilos dodocumento através de CSS.

� <link>: Define links entre o documento e recursos externos. Não possuiconteúdo e utiliza atributos específicos para informar localização e carac-terísticas do recurso externo. Comumente utilizado para definir objetos dotipo CSS e de ícone na página. O atributo rel deste elemento define o tipode 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 utilizaratributos 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 demaiselementos 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 sequenciados 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. Duranteeste processo, pode ser necessário avaliar modificações causadas por outros objetos ou solicitarobjetos externos. Além disso, o DOM também é utilizado para renderizar todas as informaçõesda página Web.

Wang et al (2013) demonstra como os navegadores efetuam a construção e renderizaçãode 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 eanalisados durante a construção do DOM. Como exemplo, scripts que foram definidos sem oatributo “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 armazenarregistros de interações e eventos durante o carregamento de uma página por um navegadorWeb. O formato é baseado em JavaScript Object Notation (JSON), e contém informações deautoria, detalhes sobre o navegador Web utilizado, informações de cabeçalho e temporização dastransações HTTP e opcionalmente o conteúdo dos objetos transferidos. A Figura 2.12 apresentaum 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 dosobjetos 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ésda inspeção do controlador de rede. Eventos relativos ao carregamento do DOM necessitamde 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 outrasfontes 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 popularesdo 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 comoo TCP efetua o controle de congestionamento, em função de perdas e variância de latência darede (jitter). Tendo em vista que o SPDY, assim como o HTTP/2, utiliza apenas uma conexãoTCP, o impacto causado pelo controle de congestionamento é mais visível do que no HTTP, queutiliza várias conexões.

Ainda sobre o SPDY, Wang et al (2014) apresentou novas métricas e técnicas paracaracterizar o desempenho deste protocolo. Através do isolamento do processo de carregamentode rede em relação aos demais processos envolvidos no carregamento de páginas Web, foiidentificado que o SPDY possui melhor desempenho em relação ao HTTP. Porém, ao seconsiderar os demais fatores computacionais, o desempenho do SPDY é consideravelmenteafetado. Apesar de propor formas de uso para o recurso push, a análise efetuada considerapoucos casos, sendo focados números e tamanhos de objetos observados em um conjunto de 200pá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, perdase 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 asanálises em diferentes ambientes.

Por fim, Han, Hao e Qian (2015) descrevem um framework que combina a utilizaçãodo 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 sebaseiam 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 dorecurso 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, quepodem não representar de forma adequada características da população de Web sites existentes.

333333

3Metodologia

Este capítulo apresenta a descrição dos experimentos realizados para avaliar o recursopush do HTTP/2 considerando um ambiente real. Para tanto, o capítulo está organizado daseguinte 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 ení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 tempono carregamento de páginas Web através de conexões HTTP/2 com e sem a utilização do recursopush. Os resultados devem ser significativos o bastante para indicar quais fatores devem serconsiderados ao se optar por este recurso.

Com o objetivo de recriar ao máximo a utilização de um servidor HTTP/2 em umambiente real, a escolha da configuração do ambiente do experimento foi focada em soluçõesmais próximas possível do padrão dos protocolos envolvidos. Na Figura 3.1, pode-se visualizaras 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 servidorWeb HTTP 1.1 utilizando um proxy reverso HTTP/2. Decidiu-se utilizar esta configuração deambiente porque, durante o desenvolvimento desta dissertação, o software HTTP/2 utilizadoainda não possuía suporte ao backend FastCGI1 e, portanto, dificultaria a criação de conteúdo deforma dinâmica.

Todas as requisições do cliente foram geradas por um navegador Web e possuem omesmo servidor de destino para todos os objetos da página Web. A sequência de passos de umarequisição do experimento realizado são descritos no diagrama de sequência da Figura 3.2.

1Disponível em: <http://www.fastcgi.com/drupal/node/6?q=node/15>

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

Fonte: Autor

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 Lighttpdversão 1.4.37, configurado na porta TCP 80 e com suporte a backend FastCGI habilitado o quepossibilita a utilização de qualquer backend compatível. Além disso, utiliza scripts PHP paragerar conteúdo dinâmico baseado em parâmetros da URL. Desta forma, é possível que umcliente 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 é geradode forma pseudo-aleatória, através da função openssl_random_pseudo_bytes. Esta função nãorequer acesso a disco para gerar conteúdo, o que garante que os dados gerados sejam rapidamentedisponibilizados 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 softwareNghttp2, na versão 1.7.0, configurado na porta TCP 443(https), utilizando o servidor WebLighttpd como backend HTTP. Bibliotecas desenvolvidas neste mesmo software são utilizadosem outras ferramentas popularmente utilizadas como cURL2 e Wireshark3. O servidor oferecesuporte à extensão Application-Layer Protocol Negotiation (ALPN), provido pela camada desegurança Transport Layer Security (TLS). Através desta extensão, é possível informar quais osprotocolos ofertados diretamente no final do handshake de segurança. Por padrão, o servidorsuporta 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 deprotocolos não relacionados aos experimentos, o parâmetro de configuração ’–npn-list=h2’ foiutilizado ao iniciar o serviço.

O cliente utiliza o navegador Web Google Chrome na versão 48.0.2564.82 (64-bit) quefoi escolhido por ofertar suporte nativo ao HTTP/2, além de facilidades para coleta de dados emanipulação interativa através de sua interface de depuração remota. A instalação deste não tevequalquer 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 operacionalFedora versão 22, utilizando o Kernel Linux 4.3.4200.fc22.x86_64.

2Disponível em: <https://curl.haxx.se>3Disponível em: <https://www.wireshark.org>

3.3. INFRAESTRUTURA DE HARDWARE 36

Entidade Configuração do Software

Servidor WebLighttpd versão 1.4.37

TCP 80backend FastCGI habilitado

Servidor ProxyNghttp2 versão 1.7.0

TCP 443Servidor 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-

res de forma eficiente e sem gerar atrasos inesperados que poderiam influenciar na medição dosexperimentos. A Tabela 3.2 resume as configurações de hardware utilizadas.

Componete Processador Memória RedeServidor Dual Xeon L5410 12 GigaBytes Ethernet 100Mb/sCliente 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 estruturafixa de roteamento. Entretanto, durante a execução dos experimentos, foi possível observar umnúmero constante de 13 saltos de rota e latência média entre 80 e 100 milissegundos entre oservidor, 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 utilizadasduas 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 processosde renderização, validação e análise do conteúdo. Por estas restrições, foi possívelutilizar um cliente HTTP/2 em linha de comando fornecido com a suíte de softwaresdo Nghttp2, o nghttp.

2. O intervalo de tempo decorrido entre a solicitação das páginas experimentais eo 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 pelosdiferentes 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 noDOM, que só pode ser alterado a partir deste evento.

Outros eventos gerados durante a construção do DOM foram considerados para se obtero intervalo de tempo utilizado na métrica PLT, porém apenas os eventos DomContentloaded eload são registrados no arquivo HAR. Interações que ocorrem após o PLT, como requisições deobjetos assíncronos, não afetam a definição inicial do DOM e não foram consideradas duranteos experimentos. Na prática, esta métrica considera que todo download e processamento dosobjetos 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 estudoconsidera, em TDT, que este recurso interfere apenas no processo de rede e, em PLT, seuefeito no carregamento de páginas Web em um navegador e seus processos internos. Estes sãodiretamente 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órioHttp Archive4, no intervalo de janeiro de 2013 a dezembro de 2015. O sistema de coleta utilizadopelo Http Archive utiliza arquivos HAR para obter seus dados que não possuem poder descritivopara identificar como os objetos estão apresentados no documento HTML. Dessa forma, elesserão considerados nos experimentos como sendo o pior cenário possível, onde todos os objetosdo 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 comobase os dados apresentados da Figura 3.3, que informa a frequência de números de objetosJavaScript.

Já para definir o tamanho dos objetos do tipo JavaScript, o nível do fator foi baseado naFigura 3.4, que representa a frequência de tamanhos de objetos também minerados do repositórioHttp 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 seencontra abaixo da metade dos intervalos coletados, entretanto , a implementação do experimentopermite que sejam utilizados valores acima dos limites. Esta permeabilidade foi explorada apenaspara os valores de número de objetos a fim de confirmar a continuidade do comportamento mesmoem casos muito acima da média. A Tabela 3.3 apresenta todos os fatores e seus respectivos níveisutilizados nos experimentos para a análise das métricas definidas.

4Disponível em: <http://httparchive.org>

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

Fonte: Autor

3.5. FATORES E NÍVEIS 39

Fator NíveisTamanho 100KB a 2000KB com incremento de 100KB

Número de Objetos 10 a 200 com incremento de 10Tabela 3.3: Fatores e Níveis

Por não existir um modelo descritivo padrão para representar páginas Web, outrosestudos 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 reutilizamdurante os experimentos. Normalmente, os sites são selecionados com base em classificação depopularidade 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 dasessão fornecida pelos servidores originais, um processo complexo e difícil de se implementarcom 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 algumascaracterí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údoaleatório para completar o tamanho do arquivo HTML quando necessário. Com estaconfiguração, é possível determinar de forma mais precisa o tamanho do arquivoantes de ser enviado na rede sem gerar processamento de análise de marcadores nonavegador, 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 desteobjetos 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õesadicionais. Como o foco deste estudo está apenas no HTTP/2, que utiliza umamesma conexão para transferir todos os recursos, os objetos externos são fornecidospelo mesmo servidor.

4. Conteúdo Aleatório: Com exceção dos marcadores e seus atributos, o conteúdo dosobjetos são aleatórios e alterados a cada requisição. A interpretação destes objetospelo 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 decache que poderiam invalidar as medições.

Estas características e restrições contribuem para que cada execução do experimento sejasimilar ao primeiro acesso às páginas. Porém, outras considerações devem ser previstas paraobter 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, quenão possui a complexidade de processos de um navegador Web ou qualquer tipo de mecanismode 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ãocom o servidor é negociada e estabelecida.

2. Download e Análise: O principal recurso fornecido pelo servidor é um documentoHTML que, assim que disponibilizado, é tratado para se obter a lista dos próximosobjetos a serem solicitados

3. Downloads adicionais: os objetos identificados no passo anterior são solicitados aoservidor.

A análise do documento HTML no passo 2 utiliza expressões regulares implementadasem C, capazes de obter as URLs dos objetos externos entre 1 e 5 milissegundos, e interfereminimamente 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çãode DNS.

Para analisar o impacto dos fatores no TDT, os experimentos realizados consideraramvariaçõ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. Destaforma o ambiente foi configurado de 3 formas distintas, sendo elas:

� Tamanho dos Objetos: Foi utilizado um número fixo de objetos sendo 17 o valorobservado 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 a100ms.

� Número de Objetos: O número de objetos influencia diretamente no número destreams concorrentes. Para manter esta concorrência durante o maior tempo possívelfoi considerado o pior caso do tamanho de objetos sendo fixo em 2048KB. A latênciade rede não foi modificada.

Os dados dos experimentos referentes a PLT são obtidos de arquivos HAR geradospelo 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 dodesenvolvedor” 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 ferramentachrome-har-capture5 versão 0.6.0 que usa as funcionalidades providas pela interface de depuraçãoremota do Google Chrome para efetuar ações de limpeza de cache, carregamento de páginas eexportação de arquivos HAR. Como requisito funcional para utilizar a ferramenta, o navegadordeve utilizar os seguintes parâmetros de inicialização: ’–remote-debugging-port=PORT’ que ativaa 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 javascriptutilizados para limpar o cache de DNS e pilha de Sockets interna do navegador. A organizacãodestas opções pode ser melhor observada no script utilizado para coletas no apêndice A.1. Comestas 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, sendodefinidos 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.

5Disponível em: <https://github.com/cyrus-and/chrome-har-capturer>

424242

4Aná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 napercepção do usuário. Para tanto, este Capítulo está estruturado da seguinte forma: a Seção 4.1descreve os resultados referentes a métrica TDT; enquanto que os resultados da métrica PLT sãoapresentados 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 dotamanho dos objetos. O padrão visual dos intervalos de desvio padrão em relação as médias decada grupo de experimentos indicou uma possível igualdade estatística. Para confirmação ourefuta desta hipótese o teste estatístico ANOVA foi executado e os dados obtidos são apresentadosna tabela 4.1.

Sendo o nível de significância considerado em 5%, pares de grupos com valor de Pinferiores ou iguais a 0.05 são ditos como sendo similares. Os tamanhos de 400KB e 1200KBpossuem valores de P relativamente próximos ao limite de significância, o que pode indicarque 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 fatornúmero de objetos.

Os valores apresentam grande dispersão, sendo este efeito mais frequente no uso dorecurso push no intervalo de 17 a 110 objetos. Apesar desta dispersão, o teste estatístico ANOVAapresentado 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 P100 0,0065949320200 0,0000000828300 0,0000000115400 0,0519780950500 0,0000302158600 0,0000001859700 0,0011688200800 0,9232040040900 0,1767195460

1000 0,00000054821100 0,01083350001200 0,05457388501300 0,92275434001400 0,08765669501500 0,00000000011600 0,10016462801700 0,00000000011800 0,00000000011900 0,27567663902000 0,0000000010

Tabela 4.1: Valores P para Tamanho dos Objetos para TDT

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 P10 0,09115639220 0,40563016130 0,00814219640 0,43670940250 0,20480886160 0,09153555070 0,00021656980 0,0000002290 0,139919023

100 0,224896469110 0,016491718120 0,501768027130 0,304275747140 0,091697702150 0,013965674160 0,006070323170 0,007379301180 0,019692227190 0,000241668200 0,060357077

Tabela 4.2: Valores P para Número de Objetos em TDT

4.2. ANÁLISE DO PLT 45

Para o nível de significância em 5%, valores de P inferiores a 0,05 correspondem asimilaridade 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. Apesarde não haver confirmação estatística de igualdade nos streams do tipo push e não push, ambosapresentam comportamento similar nos diferentes cenários. Esta caraterística é esperada devidoo design do protocolo HTTP/2, uma vez que o mesmo utiliza multiplexação, e também indicaque 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 recursopush nos experimentos com maiores números de objetos podem estar relacionados ao grandenúmero de conexões efetuadas entre o servidor proxy e o servidor Web em um curto intervalode 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 aguardeo recebimento do código de status antes de efetuar o envio dos respectivos frames do tipoPUSH_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çãono PLT ao se utilizar o recurso push. Este efeito se inverte a partir de 900KB em diante. Ointervalo 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 fixosde tamanho, sendo o de 100KB representado na Figura 4.4, e o 2048KB, na Figura 4.5. Estaconfiguraçã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çãodo uso do push. No caso onde o tamanho dos objetos é de 100KB, o push demostra temposmaiores em todos os experimentos, com maior evidencia em números menores de objetos. Oefeito oposto é observado no caso de 2000KB onde, no intervalo de 70 a 160, há distinção maisacentuada.

Assim, através destes experimentos, pode-se observar que o tempo de carregamentode 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úmerode 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

Fonte: Autor

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 tipoJavaScript, apresentem degradação no tempo de carregamento.

4.3 Discussões

Estudos propostos por Varvello et al (2016) acompanham o crescimento da adoção doHTTP/2 através da varredura contínua de servidores que hospedam os sites mais popularespelo Alexa. Os dados apresentados na plataforma1 revelam que a maioria das páginas, apesarde divulgarem que estão utilizando HTTP/2, não efetuam, de fato, alterações na estrutura dosobjetos 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 opostoao proposto pelo padrão, ou seja, ao invés de se melhorar o carregamento de páginas, pode-seexperienciar degradação.

1Disponível em: <http://isthewebhttp2yet.com>

484848

5Conclusão e Trabalhos Futuros

Com a padronização do HTTP/2 é esperado um número crescente de servidores ofertandosuporte ao protocolo. Apesar da maioria dos benefícios desta nova versão como multiplexação,compactação de cabeçalhos e encapsulamento binário serem transparentes para os desenvolve-dores de conteúdo Web, outros recursos como priorização de streams e Server Push requeremtratamento especial em sua utilização. Diferentes estratégias de escolha para envio de objetosvia push estão sendo reaproveitadas de implementações similares a exemplo do mod-spdy1 queseleciona objetos baseado no nível dos objetos no HTML.

As análises deste trabalho indicam que a utilização do recurso push pode apresentardegradação no tempo de carregamento de páginas Web em casos específicos. Para efetuar estaanalise inicialmente foi apresentado a complexidade inerente do formato HTML para descriçãode páginas Web, identificando quais os principais objetos a causar maior impacto no tempo decarregamento. As métricas para medir o impacto em diferentes características foram separadasem: TDT , que representa o tempo de download dos objetos; e o PLT que considera o temponecessário pelos demais processos de um navegador para exibir uma página Web.

O ambiente configurado para executar os experimentos permite que sejam geradaspáginas sintéticas com diferentes características, sendo possível controle distinto de fatores comotamanho e número de objetos. A escolha dos níveis dos fatores foram baseados em tendenciasde páginas Web reais obtidos através do repositório Http Arquive, sendo possível inferir queos resultados obtidos possam ocorrer em uma grande população de páginas com as mesmascaracterísticas.

Os dados coletados durante os experimentos indicam que ao efetuar push de objetoscom tamanhos inferiores a 500KB, independente da quantidade de objetos no qual está disperso,há degradação do tempo de carregamento da página Web. Por outro lado não foi encontradoindícios que o número de streams concorrentes causem overhead.

As principais contribuições da dissertação foram externamente publicadas nos seguintesshort papers:

� Analise dos resultados para métrica TDT (OLIVEIRA et al, 2016a) a ser publicado1Disponível em: <https://developers.google.com/speed/spdy/mod_spdy/>

5.1. DIFICULDADES ENCONTRADAS E LIMITAÇÕES DO TRABALHO 49

pela CSBC 2016.

� Analise da métrica PLT (OLIVEIRA et al, 2016b) submetido e aceito porem ainda nãopublicado pela “ACM SIGCOMM Workshop on Fostering Latin-American Researchin Data Communication Networks (LANCOMM)”.

5.1 Dificuldades encontradas e limitações do trabalho

A utilização da Internet no ambiente introduz variações pontuais nos resultados, conside-rados outliers. Fatores não analisados no experimento, como jitter e perdas de pacotes, podemafetar diretamente o controle de congestionamento, sendo o HTTP/2 transportado em conexõesTCP únicas, o impacto destas modificações influenciam diretamente a temporização dos streams

transportados.

5.2 Trabalhos futuros

As limitações e resultados observados neste estudo revelam a possibilidade de continua-ção desta mesma análise considerando outros fatores a exemplo de diferentes caracteristicas derede, diferentes navegadores e plataformas. O ambiente utiliza um servidor proxy que, devido anatureza do recurso push, o servidor Web pode sofrer sobrecarga ao receber grande volume derequisições em um curto período. Este efeito deve ser ainda mais crítico pois a conexão entreo servidor Web e proxy não possui latência ou perdas, sendo as conexões iniciadas de fato emsimultâneo.

A variação de fatores da rede como latência e perdas devem ser analisadas, especialmenteem ambientes reais a exemplo de redes móveis.

Visto que a utilização de Content Delivery Networks (CDNs) continua a ser o métodomais adotado para difusão de conteúdo de páginas Web, a existência de múltiplos servidorescomo origem de conteúdos de uma mesma página deve ser analisado.

505050

Referências

BELSHE, M.; PEON, R.; THOMSON, M. Hypertext Transfer Protocol Version 2 (HTTP/2).[S.l.]: RFC Editor, 2015. RFC, Disponível em:<http://www.rfc-editor.org/rfc/rfc7540.txt>. (7540).

BERNERS-LEE, T.; FIELDING, R. T.; NIELSEN, H. F. Hypertext Transfer Protocol –HTTP/1.0. [S.l.]: RFC Editor, 1996. RFC, Disponível em:<http://www.rfc-editor.org/rfc/rfc1945.txt>. (1945).

BUTKIEWICZ, M.; MADHYASTHA, H. V.; SEKAR, V. Understanding Website Complexity:measurements, metrics, and implications. In: ACM SIGCOMM CONFERENCE ONINTERNET MEASUREMENT CONFERENCE, 2011., New York, NY, USA. Proceedings. . .ACM, 2011. p.313–328. (IMC ’11).

ERMAN, J. et al. Towards a SPDY’Ier Mobile Web? In: NINTH ACM CONFERENCE ONEMERGING NETWORKING EXPERIMENTS AND TECHNOLOGIES, New York, NY, USA.Proceedings. . . ACM, 2013. p.303–314. (CoNEXT ’13).

FIELDING, R. et al. Hypertext Transfer Protocol – HTTP/1.1. [S.l.]: RFC Editor, 1997.RFC. (2068).

FIELDING, R. T. et al. Hypertext Transfer Protocol – HTTP/1.1. [S.l.]: RFC Editor, 1999.RFC, Disponível em: <http://www.rfc-editor.org/rfc/rfc2616.txt>. (2616).

GRIGORIK, I. High Performance Browser Networking: what every web developer shouldknow about networking and web performance. 1.ed. [S.l.]: O’Reilly Media, 2013.

HAN, B.; HAO, S.; QIAN, F. MetaPush: cellular-friendly server push for http/2. In:WORKSHOP ON ALL THINGS CELLULAR: OPERATIONS, APPLICATIONS ANDCHALLENGES, 5., New York, NY, USA. Proceedings. . . ACM, 2015. p.57–62.(AllThingsCellular ’15).

HOCK-CHUAN, C. In Introduction to HTTP Basics. [accessed: 2015-01-20], Disponível em:<https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html>.

KAMP, P.-H. HTTP/2.0 - The IETF is Phoning It In. Queue, New York, NY, USA, v.13, n.1,p.10:10–10:12, Dec. 2014.

LORETO, S. et al. Known Issues and Best Practices for the Use of Long Polling andStreaming in Bidirectional HTTP. [S.l.]: RFC Editor, 2011. RFC, Disponível em:<http://www.rfc-editor.org/rfc/rfc6202.txt>. (6202).

NIELSEN, H. F. et al. HTTP-NG Overview - Problem Statement, Requirements, andSolution Outline. Disponível em:<https://tools.ietf.org/html/draft-frystyk-httpng-overview-00>,Internet draft.

OLIVEIRA, I. et al. Análise de Performance do PUSH em Conexões HTTP/2 no Carregamentode Páginas Web. In: CSBC WPIETFIRTF 2016 (). Anais. . . [S.l.: s.n.], 2016.

REFERÊNCIAS 51

OLIVEIRA, I. et al. Should I Wait or Should I Push? A Performance Analysis of Push Featurein HTTP/2 Connections. In: SIGCOMM WORKSHOP ON FOSTERING LATIN-AMERICANRESEARCH IN DATA COMMUNICATION NETWORKS (LANCOMM), 2016.Proceedings. . . ACM, 2016.

PADHYE, J.; NIELSEN, H. F. A comparison of SPDY and HTTP performance. Microsoft Res,[S.l.], 2012.

PEON, R.; RUELLAN, H. HPACK: header compression for http/2. [S.l.]: RFC Editor, 2015.RFC. (7541).

PODJARNY, G. Not as SPDY as you thought. 2012.

SAXCE, H. de; OPRESCU, I.; CHEN, Y. Is HTTP/2 really faster than HTTP/1.1? In:COMPUTER COMMUNICATIONS WORKSHOPS (INFOCOM WKSHPS), 2015 IEEECONFERENCE ON. Anais. . . [S.l.: s.n.], 2015. p.293–299.

SIVAKUMAR, A. et al. PARCEL: proxy assisted browsing in cellular networks for energy andlatency reduction. In: ACM INTERNATIONAL ON CONFERENCE ON EMERGINGNETWORKING EXPERIMENTS AND TECHNOLOGIES, 10., New York, NY, USA.Proceedings. . . ACM, 2014. p.325–336. (CoNEXT ’14).

VARVELLO, M. et al. Is The Web HTTP/2 Yet? In: PASSIVE AND ACTIVEMEASUREMENT CONFERENCE. Anais. . . [S.l.: s.n.], 2016.

Wang, X. S. et al. Demystifying Page Load Performance with WProf. In: USENIXCONFERENCE ON NETWORKED SYSTEMS DESIGN AND IMPLEMENTATION, 10.,Berkeley, CA, USA. Proceedings. . . USENIX Association, 2013. p.473–486. (nsdi’13).

WANG, X. S. et al. How Speedy is SPDY? In: USENIX CONFERENCE ON NETWORKEDSYSTEMS DESIGN AND IMPLEMENTATION, 11., Berkeley, CA, USA. Proceedings. . .USENIX Association, 2014. p.387–399. (NSDI’14).

Apêndice

535353

AApêndice

A.1 Script de Coleta dos experimento do PLT

# ! / b i n / bash

# numero de e x e c u c o e s

r u n _ c o u n t =100;# tamanho t o t a l dos o b j e t o s

b a s e _ s i z e =2048000;

# f un ca o de a juda

f u n c t i o n usage ( ) {echo −e " \ n \ tUsage : "echo −e " \ t \ t $ 0 BASE_URL \ n "e x i t ;

}

i f [ −z $1 ] ; thenecho −en " \ t M i s s i n g BASE_URL" ;usage ;

e l s eu r l =$1

f i

# f un ca o de l o g

f u n c t i o n l o g ( ) {l o c a l type =$1l o c a l run =$2l o c a l d a t a =$3l o c a l f i l e =" ${ t y p e } . d a t "

A.1. SCRIPT DE COLETA DOS EXPERIMENTO DO PLT 54

case $run in0) echo −n ’ ’ > $ f i l e

; ;n e x t ) echo −e " \ n " >> $ f i l e

; ;

* ) echo −e " $run $ d a t a " >> $ f i l e; ;e sac

}

# a j u s t a c o n f i g u r a c o e s i n i c i a s : l i m p a r l o g s e i n i c i a r go og l e

chrome

f u n c t i o n s t a r t u p ( ) {> o u t . d a tl o g push 0l o g nopush 0i f ps aux | g r ep chrome | g r ep remote−debugging−p o r t > / dev /

n u l l ; thenps aux | g r ep chrome | g r ep remote−debugging−p o r t | awk ’{

p r i n t $2 } ’ | x a r g s k i l l −9f i/ u s r / b i n / google−chrome −−browser−t e s t −−bwsi −−d i s a b l e −cache

−−remote−debugging−p o r t =6666 −−enab l e−benchmark ing −−enab l e−ne t−benchmark ing 2>&1 > / dev / n u l l &

s l e e p 3}

s t a r t u p ;# loop e x t e r n o de execucoes , um por grupo

f o r p o t in { 1 . . 5 } ; dopush_mean =0p u s h _ s t d =0nopush_mean =0n o p u s h _ s t d =0

base = ‘ echo " 10 * $po t " | bc ‘o b j _ c o u n t = $base ;s i z e = $ b a s e _ s i z eeach = ‘ echo " $ s i z e / $ o b j _ c o u n t " | bc ‘

A.1. SCRIPT DE COLETA DOS EXPERIMENTO DO PLT 55

echo −e " \ nRuns : ${ r u n _ c o u n t } \ t S i z e : \ t $ s i z e \ t O b j e c t s : \t $ o b j _ c o u n t ( $each each ) "

l o g " push " n e x tl o g " nopush " n e x t# loop i n t e r n o de execucao , $ r u n _ c o u n t por grupo

f o r ( ( i =1 ; i <= $ r u n _ c o u n t ; i ++ ) ) ; doecho −en " $ i " ;push [ $ i ] = 0 ;f o r t ime in ‘ chrome−har−c a p t u r e r −p 6666 " ${ u r l

}& j s =$each , $ o b j _ c o u n t " 2 >&1| g rep onLoad |sed s / ’ . * : \ ’ / / ‘ ; do

i f echo $ t ime | g r ep " [0−9] s " >/ dev /n u l l ; then

t ime = ‘ echo $ t ime | sed s / ’ \ + \ | s’ / / g ‘ ;

t ime = ‘ echo " $ t ime * 1000 " | bc ‘ ;e l s e

t ime = ‘ echo $ t ime | sed s / ’ \ + \ |ms ’ / / g ‘

f ii f [ ‘ echo " $ t ime > ${ push [ $ i ] } " | bc ‘ ]

; thenpush [ $ i ]= $ t ime ;

f idone

l o g " push " $base ${ push [ $ i ] } ;push_mean = ‘ echo " ${ push [ $ i ] } + $push_mean " | bc ‘nopush [ $ i ] = 0 ;f o r t ime in ‘ chrome−har−c a p t u r e r −p 6666 " ${ u r l

}& j s =$each , $ o b j _ c o u n t&no_push " 2 >&1| g reponLoad | sed s / ’ . * : \ ’ / / ‘ ; do

i f echo $ t ime | g r ep " [0−9] s " >/ dev /n u l l ; then

t ime = ‘ echo $ t ime | sed s / ’ \ + \ | s’ / / g ‘ ;

t ime = ‘ echo " $ t ime * 1000 " | bc ‘ ;e l s e

t ime = ‘ echo $ t ime | sed s / ’ \ + \ |

A.1. SCRIPT DE COLETA DOS EXPERIMENTO DO PLT 56

ms ’ / / g ‘f ii f [ ‘ echo " $ t ime > ${ nopush [ $ i ] } " | bc ‘

] ; thennopush [ $ i ]= $ t ime ;

f idone

l o g " nopush " $base ${ nopush [ $ i ] } ;nopush_mean = ‘ echo " ${ nopush [ $ i ] } + $nopush_mean

" | bc ‘echo −e " ( ${ push [ $ i ] } , ${ nopush [ $ i ] } ) " ;g n u p l o t b o x p l o t . p l

done# c a l c u l o i n c r e m e n t a l de media e d e s v i o padrao

push_mean = ‘ echo " $push_mean / ${# push [@] } " | bc ‘nopush_mean = ‘ echo " $nopush_mean / ${# nopush [@] } " | bc ‘f o r ( ( i =1 ; i <= $ r u n _ c o u n t ; i ++ ) ) ; do

p u s h _ s t d = ‘ echo " $ p u s h _ s t d + ( $push_mean − ${push [ $ i ] } ) ^2 " | bc ‘

n o p u s h _ s t d = ‘ echo " $ n o p u s h _ s t d + ( $nopush_mean −${ nopush [ $ i ] } ) ^2 " | bc ‘

donep u s h _ s t d = ‘ echo " s q r t ( ( $ p u s h _ s t d / ${# push [@] } ) ) " |

bc ‘n o p u s h _ s t d = ‘ echo " s q r t ( ( $ n o p u s h _ s t d / ${# nopush [@] }

) ) " | bc ‘# imprime dados para acompanhamento

echo −e " \ npush_mean : \ t$push_mean \ t p u s h _ s t d : \ t $ p u s h _ s t d"

echo −e " nopush_mean : \ t$nopush_mean \ t n o p u s h _ s t d : \t $ n o p u s h _ s t d "

echo −e " $base , $push_mean , $push_s td , $nopush_mean , $ n o p u s h _ s t d ">> o u t . d a t

done# gera g r a f i c o a p a r t i r dos a r q u i v o s de l o g

g n u p l o t p l o t . p l