disserta˘c~ao de mestrado jhon franko jorge...
TRANSCRIPT
Universidade Federal do ABC (UFABC)
Centro de Matematica, Computacao e Cognicao (CMCC)Curso de Pos-Graduacao em Ciencia da Computacao
Dissertacao de Mestrado
Jhon Franko Jorge Velarde
APLICACAO DO PROTOCOLO SPDY PARA APLICATIVOS DE
MONITORAMENTO SOBRE REDES DE IP PUBLICO
Santo Andre - SP
2014
Curso de Pos-Graduacao em Ciencia da Computacao
Dissertacao de Mestrado
Jhon Franko Jorge Velarde
APLICACAO DO PROTOCOLO SPDY PARA APLICATIVOS DE
MONITORAMENTO SOBRE REDES DE IP PUBLICO
Trabalho apresentado como requisito parcialpara obtencao do tıtulo de Mestre em Cienciada Computacao, sob orientacao do Prof. Dr.Nunzio Marco Torrisi.
Santo Andre - SP
2014
Centro de Matematica, Computacao e Cognicao (CMCC)
Curso de Pos-Graduacao em Ciencia da Computacao
APLICACAO DO PROTOCOLO SPDY PARA APLICATIVOS DE
MONITORAMENTO SOBRE REDES DE IP PUBLICO
Jhon Franko Jorge VelardeMarco de 2014
BANCA EXAMINADORA:
• Prof. Dr. Nunzio Marco Torrisi (Presidente)(CMCC) Universidade Federal do ABC - UFABC
• Prof. Dr. Rodrigo Palucci PantoniInstituto Federal de Sao Paulo - IFSP
• Prof.a Dr.a Vera Nagamuta(CMCC) Universidade Federal do ABC - UFABC
• Prof. Dr. Ronaldo Cristiano Prati (Suplente)(CMCC) Universidade Federal do ABC - UFABC
Este exemplar foi revisado e alterado em relacao a versao original,de acordo com as observacoes levantadas pela banca no dia da de-fesa, sob responsabilidade unica do autor e com a anuencia de seuorientador.
Santo Andre, 20 de marco de 2014.
Assinatura do autor:
Assinatura do orientador:
Resumo
O objetivo deste trabalho e propor o uso do protocolo SPDY em aplicativos de
monitoramento sobre redes de IP publico, com foco nas melhorias sobre HTTP e
fornecido pelo escalonamento de requests utilizando as oito prioridades no fluxo
SPDY. Para o escalonamento SPDY, sao considerados algoritmos de padroes de
projeto que utilizam mecanismos sıncronos ou assıncronos para o gerenciamento
de requests de multiplos clientes, tais como: os padroes Reactor e Proactor. A
caracterıstica principal, o quantum de tempo, compartilhada nos algoritmos de
escalonamento, tais como: Escalonamento por Prioridade, Escalonamento Round-
Robin, Escalonamento em Filas Multinıvel, Weighted Fair Queuing e Weighted
Round-Robin, permite que os requests com menor prioridade tenham maior opor-
tunidade de ser gerenciados. Um prototipo de servidor SPDY foi desenvolvido
baseado na especificacao do protocolo SPDY e, nas caracterısticas principais
dos padroes de projeto e algoritmos de escalonamento propostos. A avaliacao
deste prototipo foi feita na simulacao de uma situacao real de monitoramento,
o prototipo considerou tres estruturas para gerenciamento de requests no escalo-
nador: oito filas de prioridade, uma fila sem prioridade e oito filas de prioridade
com um quantum de tempo para cada fila. Os resultados obtidos mostram que
os requests com maior prioridade sao processados na media em menor tempo
alem de que sao gerenciados em maior quantidade e, a utilizacao de um quan-
tum de tempo para cada fila de prioridade aumentou a quantidade de requests
gerenciados com menor prioridade.
Palavras-chave: Aplicativos de monitoramento, DNP3, SCADA, HMI, Escalona-
mento, SPDY, HTTP, Padroes de projeto, Filas, Prioridade.
iv
Abstract
The aim of this research project is to propose the use of SPDY protocol for
monitoring applications over public IP networks, with focus on the improve-
ments over HTTP provided by the request scheduling using the eight priorities
in SPDY stream. For the SPDY scheduling, are considered design patterns algo-
rithms which use synchronous or asynchronous mechanisms for handles request
of multiple clients, such as: Reactor and Proactor pattern. The main feature,
the time quantum, shared in scheduling algorithms, such as: Priority Scheduling,
Round-Robin Scheduling, Multilevel Queue Scheduling, Weighted Fair Queuing
and Weighted Round-Robin, allows lower priority requests have higher oppor-
tunity to be managed. A SPDY server prototype was developed based on the
specification of the SPDY protocol, and the main characteristics of the design
patterns and scheduling algorithms proposed. The evaluation of this prototype
was made in the simulation of a real situation monitoring, was considered in the
prototype three structures for managing requests in the scheduler: eight priority
queues, a queue without priority and eight priority queues with a time quantum
for each queue. The results show that higher priority requests are processed on
average in less time beyond that are managed in a larger quantity, and the use
of a time quantum for each priority queue increased the amount of lower priority
managed requests.
v
Agradecimentos
Agradeco a Deus pelas bencaos, pela minha saude e protecao em todos os dias
da minha vida.
Agradeco a minha esposa e amor Alisoli Pretel Jesus por que juntos somos
uma grande equipe, pelo apoio, pela presenca e grande amor, por que todo isso
foi um grande motor para conduzir este mestrado em bom caminho.
Agradeco profundamente a minha amada mae, Dominga e a minha querida
irma, Marıa, pelo amor, pelas oracoes, pela motivacao, compreensao e apoio
incondicional em todo momento.
Agradeco a meu orientador o Prof. Dr. Nunzio Marco Torrisi pela amizade,
pelos ensinamentos, ajuda e colaboracao com o meu trabalho no mestrado.
Aos professores Andre Balan, Joao Paulo Gois e Ronaldo Prati pelas novas
experiencias e pelos conhecimentos adquiridos.
E finalmente, agradeco a meus caros amigos Lıdia, Marcel e Renato por ter
me dado a sua confianca, amizade e por sempre torcer por mim.
vi
Glossario
AJAX Asynchronous Javascript and XML
CyberOPC Cybernetic OPC
DNP3 Distributed Network Protocol, version 3
HMI Human Machine InterfaceHTML5 HyperText Markup Language, version 5HTTP HyperText Transfer ProtocolHTTPS HyperText Transfer Protocol Secure
IETF Internet Engineering Task Force
OLE Object Linking and EmbeddingOPC OLE for Process ControlOPC XML-DA OPC eXtensible Markup Language-Data Ac-
cessOPC-UA OPC-Unified Architecture
RFC Request For Comments
SCADA Supervisory Control And Data AcquisitionSPDY SPeeDY ProtocolSSL Secure Sockets Layer
TCP/IP Transmission Control Protocol/ Internet Pro-tocol
TLS Transport Layer Security
W3C World Wide Web Consortium
vii
Sumario
Glossario vii
1 Introducao 2
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organizacao deste trabalho . . . . . . . . . . . . . . . . . . . . . . 4
2 Revisao Bibliografica 5
2.1 Tecnologias Relacionadas . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Melhoria do Projeto de Aplicativos HTTP . . . . . . . . . 5
2.1.2 Melhorias da Especificacao do Protocolo HTTP . . . . . . 7
2.1.3 Tecnologias Middleware para Otimizacao de uso de HTTP 8
2.2 Estado da arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Protocolo WebSocket . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Protocolo SPDY . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Algoritmos de Escalonamento . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Escalonamento Round-Robin . . . . . . . . . . . . . . . . . 13
2.3.2 Escalonamento por Prioridade . . . . . . . . . . . . . . . . 14
2.3.3 Escalonamento em Filas Multinıvel . . . . . . . . . . . . . 15
2.3.4 Weighted Fair Queuing . . . . . . . . . . . . . . . . . . . . 16
2.3.5 Weighted Round-Robin . . . . . . . . . . . . . . . . . . . . 17
3 Metodologia 18
3.1 Padroes de projeto para transmissao de dados de tipo sıncrono e
assıncrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Metodologia para a avaliacao dos resultados . . . . . . . . . . . . 22
4 Desenvolvimento de um prototipo de servidor SDPY 24
viii
SUMARIO ix
5 Resultados 28
5.1 Testes I: Analise do comportamento dos tempos de processamento
nas oito filas de prioridade . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Testes II: Analise e comparacao do comportamento dos tempos
de processamento em uma fila sem prioridade e nas oito filas de
prioridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Testes III: Analise e comparacao do comportamento dos tempos
de processamento nas oito filas com prioridade e quantum de tempo 43
6 Conclusoes 48
Lista de Figuras
2.1 Diagrama temporal da modalidade HTTP Keep-alive (a) e Pipeli-
ning (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Diagrama de conexoes SPDY. As setas grossas indicam a trans-
ferencia de dados, enquanto as setas finas mostram os tipos de
frames SPDY: PING, SETTINGS, SYN STREAM, SYN REPLY
e DATA FRAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Escalonamento Round-Robin. (a) Fila de frames. (b) Fila de fra-
mes quando FS1 nao termina apos de um quantum. . . . . . . . . 13
2.4 Um algoritmo de escalonamento com quatro classes de prioridade. 15
2.5 Escalonamento em Filas Multinıvel. . . . . . . . . . . . . . . . . . 16
2.6 Weighted Fair Queuing. . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Weighted Round-Robin. . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Diagrama de interacao para o padrao Reactor. . . . . . . . . . . . 19
3.2 Diagrama de interacao para o padrao Proactor. . . . . . . . . . . 21
3.3 Registro de Eventos (a) Reactor. (b) Proactor. . . . . . . . . . . . 21
3.4 Esquema do projeto. . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 Abordagem basica do poll de atualizacao. . . . . . . . . . . . . . . 23
4.1 Visao geral das etapas desenvolvidas no projeto. . . . . . . . . . . 25
4.2 Diagrama de interacao para o enfileiramento de eventos. . . . . . 26
4.3 Dinamica do desenfileiramento de eventos. . . . . . . . . . . . . . 26
4.4 Diagrama de interacao para o despacho de eventos. . . . . . . . . 27
x
LISTA DE FIGURAS xi
5.1 Estrutura dos arquivos de Teste A, F, J e Trafego de Fundo com o
valor da prioridade na primeira coluna e o tempo de inter-arrival
na segunda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 (a) Armazenamento na estrutura de dados. (b) Gerenciamento dos
novos requests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.3 Esquema dos testes 1 e 2. . . . . . . . . . . . . . . . . . . . . . . 32
5.4 Plotting 2D do teste 1 utilizando um cliente SPDY para transmitir
o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.5 Plotting 2D do teste 2 utilizando um cliente SPDY para transmitir
o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.6 Esquema dos testes 3 e 4. . . . . . . . . . . . . . . . . . . . . . . 34
5.7 Plotting 2D do teste 3 utilizando outro cliente SPDY para trans-
mitir o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . 34
5.8 Plotting 2D do teste 4 utilizando outro cliente SPDY para trans-
mitir o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . 35
5.9 Esquema dos testes 5 e 6. . . . . . . . . . . . . . . . . . . . . . . 35
5.10 Plotting 2D do teste 5 utilizando outro cliente SPDY para trans-
mitir o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . 36
5.11 Plotting 2D do teste 6 utilizando outro cliente SPDY para trans-
mitir o trafego de fundo. . . . . . . . . . . . . . . . . . . . . . . . 36
5.12 Vista 1: Plotting 3D do teste 7 utilizando oito filas de prioridade. 38
5.13 Vista 2: Plotting 3D do teste 7 utilizando oito filas de prioridade. 38
5.14 Vista 3: Plotting 3D do teste 7 utilizando oito filas de prioridade. 39
5.15 Vista 1: Plotting 3D do teste 8 utilizando oito filas de prioridade. 40
5.16 Vista 2: Plotting 3D do teste 8 utilizando oito filas de prioridade. 40
5.17 Vista 3: Plotting 3D do teste 8 utilizando oito filas de prioridade. 41
5.18 Vista 1: Plotting 3D do teste 9 utilizando uma fila de prioridade. 42
5.19 Vista 2: Plotting 3D do teste 9 utilizando uma fila de prioridade. 42
5.20 Vista 3: Plotting 3D do teste 9 utilizando uma fila de prioridade. 43
LISTA DE FIGURAS xii
5.21 Nova dinamica de desenfileiramento para o teste. . . . . . . . . . 44
5.22 Vista 1: Plotting 3D do teste 10 utilizando oito filas de prioridade. 45
5.23 Vista 2: Plotting 3D do teste 10 utilizando oito filas de prioridade. 45
5.24 Vista 1: Plotting 3D do teste 11 utilizando um quantum para cada
fila de prioridade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.25 Vista 2: Plotting 3D do teste 11 utilizando um quantum para cada
fila de prioridade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Lista de Tabelas
5.1 Caracterısticas do servidor e das maquinas clientes. . . . . . . . . 28
5.2 Resultados dos Testes 7, 8 e 9. . . . . . . . . . . . . . . . . . . . . 47
5.3 Resultados dos Testes 10 e 11. . . . . . . . . . . . . . . . . . . . . 47
xiii
Lista de Algoritmos
1 Algoritmo de Gerenciamento de Eventos . . . . . . . . . . . . . . 22
1
Capıtulo 1
Introducao
Em 1991, foi especificada a primeira versao do protocolo HTTP por Tim Berners-
Lee e, em 1996, foi padronizado pelo IETF como HTTP 1.0 e documentado no
RFC 1945 [1]. Apenas tres anos depois, pelo aumento da carga na web, foi pa-
dronizado o HTTP 1.1 pelo IETF. O protocolo revisado no RFC 2616 [2] reduziu
o numero necessario de requisicoes de conexao para um terminal atraves da in-
troducao de conexoes keep-alive [3] e, atraves do HTTP pipelining [4] permitiu
multiplos requests em sequencia sem a necessidade de esperar por as correspon-
dentes responses. O HTTP nao mudou muito desde entao, embora o panorama
web tenha mudado fundamentalmente.
Desde a primeira especificacao do protocolo HTTP - RFC 1945, os aplicativos
baseados neste protocolo evoluıram superando a limitacao da especificacao para
trabalhar com streaming e conteudos web interativos. No entanto, muitos dos
gargalos das implementacoes HTTP 1.1 estao relacionadas a gestao de multiplas
conexoes simultaneas, configuracoes de conexao de ida e volta desnecessarias,
controle de congestionamento e um racionamento constante causado pelo cliente
onde ele tenta evitar a abertura de muitas conexoes em um unico servidor [5].
Enquanto a comunidade cientıfica vem desenvolvendo novas ideias para melhorar
o desempenho de aplicativos web sobre HTTP 1.1, a limitacao do domınio de mui-
tos aplicativos de monitoramento de redes IP locais foi estendida para redes de
IP publico usando HTTP como protocolo preferido para aplicativos personaliza-
2
CAPITULO 1. INTRODUCAO 3
dos. Os aplicativos modernos SCADA1 e HMI2 tem acesso em leitura e escritura,
parcial ou totalmente, a suas variaveis de processo atraves de protocolos HTTP,
HTTPS, ModBus [6], DNP [7] e outros, usando gateways como OPC XML-DA
[8], OPC-UA [9], CyberOPC [10] e muitas outras solucoes interessantes.
1.1 Motivacao
Este trabalho foi motivado pela utilizacao das novas caracterısticas de prioridade
introduzidas pelo protocolo SPDY [5], que permita melhorar o desempenho de
qualquer aplicativo de monitoramento que usa o protocolo HTTP. Esta aborda-
gem tenta resolver o problema atraves do protocolo e nao atraves de um mid-
dleware de aplicativos HTTP, por exemplo, o Reverse AJAX [11]. Assim, os
principais resultados esperados sao:
• Uma metodologia otimizada para usar o protocolo SPDY em redes publicas
para monitoramento e controle de processos industriais;
• A contribuicao tecnologica na industria de software para aplicativos de mo-
nitoramento atraves da internet.
1.2 Objetivos
O principal objetivo e pesquisar e desenvolver um prototipo de servidor SPDY
baseado nas especificacoes do protocolo, os estudos de padroes de projeto e nas
caracterısticas dos algoritmos de escalonamento aplicadas na teoria de gerenci-
amento de filas de prioridade do escalonador SPDY. Os algoritmos de gerencia-
mento de filas adotados no projeto do servidor sao justificados pela caracterıstica
de prioridade do protocolo SPDY. Mais especificamente, os objetivos sao:
• Investigar o protocolo SPDY, os padroes de projeto e algoritmos de escalo-
namento, para atingir os requerimentos de gerenciamento de prioridades e
1SCADA ou Supervisory Control and Data Acquisition e um sistema que utiliza softwarepara monitorar e supervisionar as variaveis e dispositivos de sistemas de controle industrial.
2HMI ou Human–machine interface inclui componentes de hardware e software pelo qual osusuarios interagem com as maquinas.
CAPITULO 1. INTRODUCAO 4
modelar a integracao do gerenciador de fluxo de prioridades SPDY;
• Desenvolver um servidor de teste e simular cenarios de aplicativos de mo-
nitoramento no laboratorio;
• Comparar a estrategia de gerenciamento de fluxo sobre redes de IP publico
e avaliar os resultados.
1.3 Organizacao deste trabalho
O primeiro capıtulo e destinado a fornecer o leitor uma visao geral dos assuntos
abordados neste trabalho, assim, neste capıtulo sao apresentadas a introducao,
motivacao e os objetivos.
No capıtulo 2 sao apresentadas as caracterısticas de varias tecnologias relacio-
nadas que visam a melhoria de HTTP. Tambem descrevemos o estado da arte que
abrange os protocolos WebSocket e SPDY, considerados os principais candidatos
para a proxima e esperada especificacao do HTTP 2.0 pelo IETF. Alem disso,
sao abordadas as caracterısticas principais dos algoritmos de escalonamento.
No capıtulo 3 sao descritas as caracterısticas principais dos padroes de pro-
jeto consideradas para o desenvolvimento do escalonador SPDY. Alem disso, e
apresentada a metodologia utilizada para avaliacao dos resultados.
No capıtulo 4 sao abordadas, detalhadamente, as etapas compreendidas no
desenvolvimento de um prototipo de servidor SPDY.
No capıtulo 5 sao apresentados os resultados dos distintos experimentos feitos
sobre o prototipo desenvolvido, alem de descrever a analise de cada um deles. A
avaliacao foi feita na simulacao de uma situacao real de monitoramento conside-
rando tres grupos de testes.
Finalmente, no capıtulo 6 sao apresentadas as conclusoes desta dissertacao.
Capıtulo 2
Revisao Bibliografica
2.1 Tecnologias Relacionadas
2.1.1 Melhoria do Projeto de Aplicativos HTTP
Blocking e Non-Blocking Socket Os termos de Blocking e Non-Blocking
I/O fazem referencia a maneira pela qual os I/O sao processados no sistema
operacional (OS), sıncrona ou assincronamente respectivamente. O problema
da limitacao de conexoes simultaneas esta relacionado tambem a forma como
o servidor foi implementado e como o OS trabalha com os sockets. Querendo
iniciar uma conexao com o servidor e utilizando um socket para qualquer tipo
de operacao, no Blocking I/O, a operacao e iniciada com um thread, a qual fica
imediatamente em espera ate que o pedido esteja completo. No caso de Non-
Blocking I/O, existem duas alternativas, ou um polling, onde o servidor tenta
fazer a operacao cada intervalo de tempo, ou a utilizacao de uma notificacao
assıncrona, no qual o servidor gera um evento indicando que uma operacao esta
pronta para ser processada.
Devido a complexa interacao entre HTTP e o subjacente protocolo da camada
de transporte (TCP), quer isto dizer, apesar da adicao das tecnicas de HTTP
keep-alive e pipelining em HTTP/1.1, um atraso de 500 ms no servidor HTTP
impede a reutilizacao do canal TCP para requests adicionais, do modo que, os
navegadores atuais evitam este problema abrindo multiplas conexoes simultaneas,
em uma media de 6 conexoes. O gerenciamento de multiplas sessoes TCP, para
suportar essas conexoes simultaneas, aumenta a sobrecarga e a latencia. SPDY
5
CAPITULO 2. REVISAO BIBLIOGRAFICA 6
[5] proporciona melhorias significativas de latencia, mas existem outras solucoes
propostas para a latencia web, principalmente no nıvel da camada de transporte
ou sessao.
Stream Control Transmission Protocol (SCTP) E um protocolo da ca-
mada de transporte que trabalha como os populares protocolos TCP e UDP e
oferece algumas de suas caracterısticas de servico. E orientado a mensagem como
UDP e garante a confiabilidade e mensagens em sequencia com o controle de
congestionamento como TCP. Alem disso, a motivacao principal por detras do
SCTP e fornecer um protocolo mais confiavel e robusto do que o TCP e UDP, o
qual pode aproveitar recursos como multihoming 1 [12]. O protocolo foi definido
pelo grupo de trabalho de transporte de sinalizacao SIGTRAN do IETF em 2000,
e e mantido pelo grupo de trabalho da area de transporte (TSVWG) do IETF. O
RFC 4960 define o protocolo e o RFC 3286 fornece uma introducao. Na ausencia
de suporte nativo para SCTP em sistemas operacionais e possıvel o tunel SCTP
sobre UDP, assim como o mapeamento de chamadas da API de TCP para SCTP.
HTTP sobre SCTP E uma proposta para a execucao de HTTP sobre SCTP.
HTTP requer um transporte confiavel para a comunicacao fim-a-fim. Semelhante
ao TCP, o SCTP oferece uma conexao de transporte fim-a-fim confiavel para apli-
cativos web, alem disso, oferece outros servicos inovadores indisponıveis no TCP,
incluindo multi-transmissao, multihoming, fiabilidade parcial e transferencia de
dados orientados a mensagem [13].
Structured Stream Transport (SST) SST e um protocolo de transporte
experimental projetado para atender as necessidades de aplicativos modernos
que precisam trabalhar com muitas atividades de comunicacao assıncrona em
paralelo, tal como baixar diferentes partes de uma pagina web e a reproducao de
audio e multiplos streams de vıdeo de forma simultanea [14].
1 O multihoming faz referencia a um computador ou dispositivo (celular, tablet) conectadoa mais de uma rede.
CAPITULO 2. REVISAO BIBLIOGRAFICA 7
MUX e SMUX Sao protocolos de gerenciamento de sessao que separam o
transporte subjacente dos protocolos de aplicacao de nıvel superior. Fornecem um
canal de comunicacao leve para a camada de aplicacao atraves da multiplexacao
de fluxos de dados, sobre um transporte orientado de fluxo confiavel. Ao suportar
a coexistencia de multiplos protocolos de nıvel de aplicacao (por exemplo, HTTP
e HTTP-NG), eles irao facilitar as transicoes para futuros protocolos web e as
comunicacoes de applets cliente utilizando protocolos privados com os servidores
sobre a mesma conexao TCP como a conversacao HTTP [15].
2.1.2 Melhorias da Especificacao do Protocolo HTTP
Keep-alive Tambem chamado conexao persistente HTTP, permite ao servidor
manter a conexao TCP aberta apos do envio das respostas. As sub-sequentes
requests/responses entre o mesmo cliente e servidor podem ser enviados atraves
da mesma conexao. Depois de um determinado perıodo de tempo (intervalo de
tempo de espera), o servidor HTTP fecha a conexao quando nao e utilizada. E
uma tecnica padrao do HTTP/1.1 e existe em duas versoes: com pipelining e sem
pipelining [3]. A figura 2.1-(a) mostra o esquema do HTTP Keep-alive com os
requests/responses entre o mesmo cliente e servidor atraves da mesma conexao.
HTTP Pipelining E uma tecnica que quebra o modelo rigoroso: “enviar uma
solicitacao e esperar pela resposta”, especificada em HTTP 1.0 [1], e permite
despachar multiplos requests HTTP em paralelo para o servidor em uma unica
conexao TCP, sendo utilizado com muito mais eficacia, mas com o tempo trans-
corrido muito menor, sem esperar pelas respostas correspondentes. Logo que os
pedidos sao todos enviados, o cliente HTTP (navegador) comeca a escutar para
responder. O HTTP Pipelining permite menos pacotes TCP para ser enviados
atraves da rede, desde que no mesmo pacote TCP e possıvel agrupar varios re-
quests HTTP, reduzindo a carga de rede [4]. A figura 2.1-(b) mostra o esquema do
HTTP Pipelining com multiplos requests, em paralelo, sobre a mesma conexao.
CAPITULO 2. REVISAO BIBLIOGRAFICA 8
Cliente Servidor
Abrir
Fechar
Cliente Servidor
Abrir
Fecharte
mp
o
(a) (b)
Figura 2.1: Diagrama temporal da modalidade HTTP Keep-alive (a) e Pipelining(b).
HTTP Server Push Envolve o envio de pacotes de dados periodicamente
desde o servidor HTTP para o cliente HTTP. A conexao HTTP entre o cliente
e o servidor e mantida aberta indefinidamente, de modo que se um evento e
recebido pelo servidor, este pode ser imediatamente enviado para um ou multiplos
clientes, ou caso contrario, os dados teriam que ser enfileirados ate que o proximo
request do cliente seja recebido. Este mecanismo pode ser implementado em
um programa CGI atraves do uso de tipo de MIME multipart/x-mixed-replace.
Tambem e conhecido como HTTP streaming e e suportado apenas pelo Netscape
Navigator (versao 1.1 ou superior) e Internet Explorer [16].
2.1.3 Tecnologias Middleware para Otimizacao de uso deHTTP
Estas tecnologias requerem um software middleware com JavaScript do lado do
cliente e do servidor para a transferencia de dados.
Reverse Ajax Comet [17], conhecido por outros nomes incluindo Reverse Ajax,
e um modelo de aplicacao web que permite aos servidores web enviar dados para
um navegador cliente, sem a necessidade de um request explıcito [17]. Neste
modelo, um request e enviado para o servidor e mantido ativo por um longo
tempo, ate um limite de tempo ou a ocorrencia de um evento do servidor. Quando
CAPITULO 2. REVISAO BIBLIOGRAFICA 9
o request e completado, outro request Ajax de longa duracao e enviado para
esperar por outros eventos do servidor. A maior vantagem do Comet e que cada
cliente sempre tem um link de comunicacao aberto com o servidor, no qual pode
enviar os eventos aos clientes para completar imediatamente as respostas quando
eles chegarem, ou ate mesmo acumular e enviar por rajadas [18].
Bayeux E uma solucao de codigo aberto projetado para proporcionar baixa
latencia atraves de HTTP. Ele trabalha transportando as mensagens assıncronas
e roteando eventos entre clientes e servidores utilizando um modelo publicar/-
subscrever. O objetivo principal de Bayeux e a implementacao de interacoes
de usuarios que respondem a clientes web usando Ajax e a tecnica server-push
chamada de Comet. A ideia principal e facilitar a interoperacao entre as im-
plementacoes para resolver a distribuicao comum de mensagens e problemas de
roteamento, e fornecer mecanismos para melhorias incrementais e de extensoes.
Entre suas operacoes globais encontramos os transportes “Streaming”, que utili-
zam a tecnica de streaming para permitir que multiplas mensagens sejam enviadas
dentro da mesma resposta HTTP, mas que estejam sujeitas a implementacao dos
agentes de usuario e proxies que requerem respostas HTTP incompletas para ser
entregue ao cliente Bayeux [19].
BOSH Ou “Bidirectional-streams Over Synchronous HTTP”, e uma tecnolo-
gia que emula um fluxo bidirecional via HTTP entre cliente e servidor, usando
multiplos requests/responses sıncronos de HTTP. BOSH consegue uma largura
de banda eficiente, para aplicativos que requerem comunicacoes “push” e “pull”,
e baixa latencia, sem requerimento de polling ou segmentacao assıncrona, como
e feito na tecnica conhecida como Comet [20].
CAPITULO 2. REVISAO BIBLIOGRAFICA 10
2.2 Estado da arte
Os requerimentos definidos pelo IETF para o futuro protocolo HTTP incluem um
bom desempenho para os navegadores convencionais e moveis e um amplo grau
de compatibilidade com versoes anteriores. O desenvolvimento das especificacoes
de HTTP 2.0 tem como referencia as caracterısticas de SPDY [21]. WebSocket
e SPDY sao tecnologias que incluem as caracterısticas principais das tecnologias
descritas na secao 2.1 como o Pipelining, reutilizacao da conexao aberta TCP,
multiplexacao de fluxos de dados, o Server Push, etc., e seus drafts de espe-
cificacoes no IETF e W3C sao muito ativos em termos de grupo de interesse.
Ambos sao candidatos para a proxima especificacao de HTTP 2.0.
2.2.1 Protocolo WebSocket
E uma tecnologia web desenvolvida como parte do padrao entrante HTML5 [22],
com suporte para comunicacao bidirecional e full-duplex, ao contrario de tecno-
logias como BOSH ou equivalentes, que requerem apenas uma unica conexao de
socket para que as mensagens sejam enviadas entre o cliente e o servidor. Servi-
dores proxy e firewall com WebSocket sao conscientes que usam o canal HTTP e
que podem operar tambem sobre SSL [23]. O API de WebSocket esta sendo pa-
dronizado pelo W3C, e o protocolo WebSocket foi padronizado pelo IETF como
RFC 6455 [24].
2.2.2 Protocolo SPDY
SPDY [5] e um novo protocolo da camada de aplicacao desenvolvido pela empresa
Google Inc. para transportar mensagens HTTP de forma mais rapida. SPDY foi
projetado para reduzir a latencia e aumentar a seguranca. SPDY e considerado
um substituto para o HTTP e como protocolo de pacotes (frames) tem suporte
para a codificacao de dados binarios e suporte nativo para TLS (SSL). SPDY
adiciona um framing layer ou camada de enquadramento para a multiplexacao
de fluxos de mensagens HTTP simultaneos, atraves de uma unica conexao TCP.
CAPITULO 2. REVISAO BIBLIOGRAFICA 11
O framing layer e otimizado para fluxos request/response do tipo HTTP, tal que
os aplicativos que rodam sobre HTTP atualmente podem trabalhar sobre o SPDY
com pouca ou nenhuma alteracao dependendo do desenvolvimento dos aplicativos
web.
A sessao SPDY permite requests simultaneos HTTP para rodar em uma unica
sessao TCP/IP, e oferece quatro melhorias sobre HTTP:
• Requests multiplexados. Nao existe limite para o numero de requests
que podem ser emitidos simultaneamente em uma unica conexao SPDY.
Como os requests sao intercalados em um unico canal, o protocolo e mais
eficiente sobre TCP.
• Requests priorizados. Os clientes podem solicitar certos recursos para
serem entregues primeiro. Isto evita o problema de congestionar o canal
de rede com os recursos nao crıticos, quando um pedido de alta prioridade
esta pendente.
• Cabecalhos comprimidos. Os clientes atualmente enviam uma quan-
tidade significativa de dados redundantes na forma de cabecalhos HTTP
devido ao fato de que uma unica pagina web pode requerer 50 ou 100 sub-
requests. Comprimir os cabecalhos economiza uma quantidade significativa
de largura de banda alem de reduzir a latencia em relacao ao HTTP, assim
SPDY comprime os cabecalhos dos requests e responses HTTP utilizando
zlib [25], um metodo de compressao baseado em dicionario amplamente
utilizado [26].
• Server pushed streams . Permite aos clientes receber dados de servidores
sem precisar da requisicao deles.
A especificacao tecnica de SPDY esta dividida em duas partes: Framing Layer
e HTTP Layer. O framing layer, no ultimo draft [5] considera seis partes: sessoes,
CAPITULO 2. REVISAO BIBLIOGRAFICA 12
que esta associado as conexoes, framing, fluxos, que entre suas caracterısticas con-
sidera a priorizacao do request, tratamento de erros, fluxo de dados e tipos de fra-
mes de controle. No HTTP Layer, o SPDY tenta preservar a semantica existente
de HTTP embora a sintaxe de transmitir essa semantica tenha mudado. Entre
essas mudancas considera-se o gerenciamento da conexao, o request/response de
HTTP e transacoes enviadas pelo servidor. A figura 2.2 mostra o diagrama para
conexoes SPDY, baseado no tıpico intercambio de pacotes TCP [27], onde varios
parametros de tempo sao necessarios para caraterizar esse intercambio como: O
round-trip time ou tempo de ida/volta que tarda um pacote enviado desde um
emissor, o segment transmission time, como tempo que leva para enviar o maior
numero possıvel de pacotes, o tempo de execucao do algoritmo de controle de
congestionamento slow-start, e finalmente o tempo de processamento do request
no servidor SPDY.
Cliente
SPDY
Servidor
SPDY
Setup
(PING,
SETTINGS)
round-trip
time(RTT)
“tempo de
processamento”
Request inicial
(SYN_STREAM)
Response
(SYN_REPLY,
DATA_FRAME)
segment
transmission
time
slow-start
sustained
transfer...
Figura 2.2: Diagrama de conexoes SPDY. As setas grossas indicam a transferenciade dados, enquanto as setas finas mostram os tipos de frames SPDY: PING,SETTINGS, SYN STREAM, SYN REPLY e DATA FRAME.
CAPITULO 2. REVISAO BIBLIOGRAFICA 13
2.3 Algoritmos de Escalonamento
Para o gerenciador de requests com prioridade, alguns algoritmos de escalona-
mento sao considerados, alguns bem conhecidos de teorias de sistemas operaci-
onais, tais como: Escalonamento Round-Robin, Escalonamento por Prioridade
e Escalonamento em Filas Multinıvel, e tambem algumas propostas tais como:
Weighted Fair Queuing e Weighted Round-Robin.
2.3.1 Escalonamento Round-Robin
Um dos mais antigos, simples, justos algoritmos amplamente utilizado e o escalo-
namento round-robin (ERR). A cada frame SPDY (FS) e atribuıdo um intervalo
de tempo, chamado quantum, o qual e permitido para executar. Se o FS atual
ainda esta em execucao no final do quantum, no escalonador SPDY (ES) ocorre
uma preempcao e cede o lugar a outro FS. Se o FS foi bloqueado ou terminado
antes que tenha decorrido o quantum, um novo FS e escolhido na fila pelo esca-
lonador. O round-robin e facil de implementar. O escalonador tem uma fila de
frames, como e mostrado na figura 2.3-a. Quando o frame FS nao termina apos
um quantum, ele e colocado no final da fila, como e mostrado na figura 2.3-b.
FS1 FS2 FS3 FS4
Atual
Frame
Próximo
Frame
FS2 FS3 FS4 FS1
Atual
Frame
(a) (b)
Figura 2.3: Escalonamento Round-Robin. (a) Fila de frames. (b) Fila de framesquando FS1 nao termina apos de um quantum.
CAPITULO 2. REVISAO BIBLIOGRAFICA 14
O unico problema interessante com o escalonamento round-robin e a duracao
do quantum. Definir um quantum com pouco tempo provocaria muitas co-
mutacoes dos frames e uma baixa na eficiencia do escalonador, mas defini-lo
com muito tempo pode causar uma ma resposta aos requests interativos curtos
[28].
Fair Queuing No fair queuing (FQ), os frames FS sao enviados e armazenados
em filas. O algoritmo de escalonamento round-robin e usado para servir todas as
filas de uma forma justa. A principal vantagem do FQ e que os fluxos em rajadas
nao afetam o desempenho global [29].
2.3.2 Escalonamento por Prioridade
O escalonamento round-robin faz a suposicao implıcita que todos os frames FS sao
igualmente importantes. A necessidade de levar em conta fatores externos, leva
ao escalonamento por prioridade (EP). A ideia basica e simples: A cada frame
FS e atribuıda uma prioridade e o FS com a maior prioridade tem permissao de
execucao.
A fim de prevenir a execucao indefinida dos frames FS com maior prioridade,
o escalonador ES pode diminuir a prioridade dos FS atualmente em execucao
em cada ciclo de relogio (isto e, a cada interrupcao do relogio). Se essa acao
atribui uma prioridade menor para deixar sem execucao ao proximo FS com maior
prioridade, entao um troco de FS ocorre. Alternativamente, a cada FS pode ser
atribuıdo um tempo maximo de quantum que e permitido para executar. Quando
este quantum se esgota, e dada a oportunidade de execucao ao proximo FS com
prioridade mais alta.
E frequentemente conveniente agrupar os frames FS em classes de prioridade
e usar o escalonamento por prioridade entre as classes, mas com o escalonamento
round-robin dentro de cada classe. A figura 2.4 mostra um sistema com quatro
classes de prioridade. O algoritmo de escalonamento e da seguinte maneira: en-
quanto existam frames FS executaveis na classe de prioridade 1, basta executar
CAPITULO 2. REVISAO BIBLIOGRAFICA 15
cada um por um quantum “round-robin por turnos”, sem preocupar-se pelas clas-
ses de menor prioridade, se a classe de prioridade 1 esta vazia entao executamos
os frames FS da classe round-robin 2. Se as classes 1 e 2 sao ambas vazias, em
seguida, executamos a classe round-robin 3, e assim por diante. Se as prioridades
nao sao ajustadas ocasionalmente, todas as classes de menor prioridade podem
morrer por inanicao [28].
Escalonador
Prioridade máxima
Prioridade mínima
Despachador
FS1 FS2 FS3 FS3
FS9
FS8
FS6
FS4
FS5
FS5
FS4
FS6
FS7FS7
FS1
FS8
FS2
FS9
Figura 2.4: Um algoritmo de escalonamento com quatro classes de prioridade.
2.3.3 Escalonamento em Filas Multinıvel
O algoritmo de escalonamento em filas multinıvel, divide a fila pronta em varias fi-
las separadas, como na figura 2.5. Os frames FS sao permanentemente atribuıdos
a uma fila, geralmente baseados em alguma propriedade do FS, seja pela prio-
ridade ou pelo tipo de frame. Cada fila tem seu proprio algoritmo de escalona-
mento. Por exemplo, de duas filas separadas com frames FS, a primeira fila pode
ser escalonada por um algoritmo de escalonamento ERR, enquanto a segunda fila
pode ser escalonada por um algoritmo de escalonamento EP.
Cada fila tem prioridade absoluta sobre as filas de prioridade inferior, tambem
pode ser atribuıdo um intervalo de tempo entre as filas. Assim, cada fila recebe
certa porcao de tempo, o qual pode entao, escalonar entre seus multiplos frames
FS [30].
CAPITULO 2. REVISAO BIBLIOGRAFICA 16
Prioridade Alta
FS9 FS7 FS3 FS1
FS
Tempo
Real
Interativo
preemptado
preemptado
FS0
preemptado
preemptado
Sistema
Lote
Prioridade baixa
FS FS FS
FSFSFSFS
FS FS FS FS
Figura 2.5: Escalonamento em Filas Multinıvel.
2.3.4 Weighted Fair Queuing
O weighted fair queuing (WFQ), e uma tecnica de escalonamento de frame de
dados, que permite diferentes prioridades de escalonamento para os fluxos de
dados multiplexados estatisticamente. A ideia deste algoritmo pode ser facilmente
explicada como uma combinacao dos algoritmos de escalonamento por prioridade
e fair queuing. Tal como no metodo FQ, todas as filas sao servidas de maneira
que nao existe qualquer inanicao de largura de banda, mas algumas filas tem
mais peso no sentido que elas recebem mais servico. Em outras palavras, o peso
e dado a cada fila para atribuir diferentes prioridades as filas. Os frames sao
armazenados na fila apropriada de acordo com sua classificacao.
A figura 2.6 mostra um exemplo do algoritmo WFQ. Os tempos finais sao
atribuıdos somente para um uso qualitativo. Atribuindo um peso alto para uma
fila, ele deve permitir ao escalonador tomar mais de um frame FS dessa fila que
das as outras [29].
CAPITULO 2. REVISAO BIBLIOGRAFICA 17
Fila 1 (50%)
Fila 2 (25%)
Fila 3 (25%)
FS1
Escalonador
Ordem da transmissão de frames
FS9 FS1FS2
FS2 FS3
FS3FS4FS4 FS5FS5 FS6FS6 FS7
FS7
FS8
FS8 FS9
Figura 2.6: Weighted Fair Queuing.
2.3.5 Weighted Round-Robin
O Weighted Round-Robin (WRR) e um algoritmo de escalonamento onde o buf-
fer e dividido em k filas que representam os fluxos ativos, o algoritmo percorre
cada fila e um fator de ponderacao determina quantos bytes de dados do sistema
entrega de cada fila antes de passar para a proxima fila. Um peso e associado a
cada fila proporcionalmente a taxa de bits requerida da fila e, a maneira como as
filas sao servidas e atraves de uma disciplina Round-Robin de acordo com o peso:
cada fila e servido proporcionalmente a seu proprio peso [31].
P=4
P=3
P=2
Escalonador
P=1
Despachador
Alta
Baixa
Filas
FS1 FS2 FS3 FS2
FS3
FS1
FS4
FS4
FS5
FS5
FS6
FS6
FS7FS7
FS8
FS8
FS9
FS9
Figura 2.7: Weighted Round-Robin.
A figura 2.7 mostra um exemplo do algoritmo WRR. O escalonamento WRR
previne que as filas de menor prioridade sejam ignoradas completamente durante
os perıodos de trafego de alta prioridade. Ao utilizar este escalonamento, as filas
de baixa prioridade tem a oportunidade de transmitir frames FS, embora as filas
de alta prioridade nao estejam vazias.
Capıtulo 3
Metodologia
Fluxos e Prioridades em SPDY Apesar de que as caracterısticas atuais do
protocolo HTTP restringem seu otimo desempenho como o envio de um unico
request por conexao, cabecalhos HTTP redundantes, etc., SPDY retem a compati-
bilidade e mantem a estrutura basica de HTTP, tal como a semantica dos requests
e response, ao contrario de WebSocket que requer uma reprogramacao no processo
de encapsulamento de HTTP [24]. Alem disso, oferece a multiplexacao de fluxos,
que proporciona benefıcios adicionais como priorizar os requests, garantindo que
os mais importantes tenham prioridade sobre os menos importantes. Em SPDY,
o iniciador de um fluxo, atribui uma prioridade ao request que e representado por
um numero inteiro de 0 a 7, sendo 0 a maior prioridade e 7 a menor prioridade
[5].
3.1 Padroes de projeto para transmissao de da-dos de tipo sıncrono e assıncrono
Para a implementacao do escalonamento de fluxo e a concorrencia em um servidor
SPDY, serao considerados padroes de projeto de arquitetura de software para o
gerenciamento de eventos em sistemas de rede que usam mecanismos sıncronos e
assıncronos, entre os quais temos os padroes Reactor e Proactor. Comparado aos
mecanismos sıncronos, os mecanismos assıncronos sao atrativos porque oferecem
o benefıcio da concorrencia enquanto aliviam muito a sobrecarga e a complexidade
do multi-threading [32].
18
CAPITULO 3. METODOLOGIA 19
Padrao de projeto Reactor O Reactor e um padrao que simplifica o traba-
lho aos aplicativos orientados a eventos atraves da integracao da demultiplexacao
sıncrona de eventos e o despacho de seus gerenciadores de eventos corresponden-
tes. O padrao Reactor esta constituıdo pelos seguintes participantes: Handles,
que identificam os recursos que sao gerenciados por um sistema operacional; O
demultiplexador sıncrono de eventos, que bloqueia os recursos esperando pela
ocorrencia de eventos em um conjunto de Handles ; A iniciacao do despachador,
que define uma interface para o registro, remocao e envio dos gerenciadores de
eventos; Os gerenciadores de eventos, que especificam uma interface usada pela
iniciacao do despachador chamando de volta aos metodos hook 1 pre-registrados
para processar certos tipos de eventos e finalmente o gerenciador de eventos con-
cretos, que implementa os metodos hook que processam eventos em uma forma
especıfica da aplicacao [33]. A figura 3.1 mostra um diagrama de interacao para
o padrao Reactor.
Initializa
Programa
principal
Callback:
Gerenciador de
eventos concretos :Reactor :Handles
Registrar o
gerenciador
Obter o
gerenciador
Executar no
mesmo laço
Esperar por
eventos
Despachar
gerenciador(es)
Reactor()
registrar_gerenciador(callback)
obter_gerenciador()
gerenciar_eventos()
select()
gerenciar_evento(tipo_evento)
Figura 3.1: Diagrama de interacao para o padrao Reactor.
1Os Metodos hook sao definidos em interfaces ou classes abstratas e devem necessariamenteser implementados por uma aplicacao.
CAPITULO 3. METODOLOGIA 20
Padrao de projeto Proactor O Proactor e um padrao usado para descrever
como iniciar, receber, demultiplexar, despachar e processar eventos. Seu prin-
cipal objetivo e melhorar o desempenho de um aplicativo orientado a eventos
que recebe e processa multiplos eventos de forma assıncrona. O padrao Proac-
tor e desenvolvido da seguinte forma: quando um evento chega, a entidade do
aplicativo, referido a um iniciador, comeca uma operacao assıncrona apropriada,
em seguida, o Proactor registra o evento com um gerenciador e despachador de
eventos associados ao processador de operacoes assıncronas, logo apos, o iniciador
invoca a operacao assıncrona registrada no processador de operacoes assıncronas.
Uma operacao assıncrona e executada sem bloquear o thread de controle do ge-
renciamento de eventos, assim, ele pode realizar outras operacoes. Uma vez
que a operacao e concluıda, o processador de operacoes assıncronas recupera in-
formacoes do gerenciador e despachador de eventos correspondentes, e gera um
evento de conclusao contendo os resultados da operacao assıncrona, logo apos, de-
multiplexa e despacha o evento para o gerenciador de eventos associado a operacao
assıncrona. Posteriormente, o gerenciador de eventos processa os resultados da
operacao assıncrona e chama novamente a aplicacao [32].
O padrao Proactor oferece os seguintes benefıcios: maior portabilidade da
logica da aplicacao, encapsulamento do mecanismo de concorrencia pelo despa-
chador de conclusao, uma polıtica de threading desacoplada da polıtica de con-
correncia, maior separacao de interesses, e maior desempenho e simplificacao da
sincronizacao de aplicativos. No entanto, ele tambem tem os seguintes inconve-
nientes: o escalonamento e controle de operacoes pendentes e a dificuldade de
depuracao [34]. A figura 3.2 mostra um diagrama de interacao para o padrao
Proactor.
CAPITULO 3. METODOLOGIA 21
Operação
assíncrona iniciada
Iniciador do
Proactor
Processador
da Operação
Assíncrona
Operação
Assíncrona
Operação realizada
assincronamente
Operação concluída
Gerenciador de
conclusão notificado
registrar(operação, gerenciador, despachador)
executar()
despachar()
gerenciar_evento()
Despachador
de conclusão
Gerenciador
de conclusão
Figura 3.2: Diagrama de interacao para o padrao Proactor.
Em resumo, tanto o Reactor quanto o Proactor sao padroes de projeto focados
nos aplicativos orientados a eventos e que compartilham principalmente as funcoes
de registro, demultiplexacao e gerenciamento de multiplos eventos.
I1
I2I1
I2
I3
I1 I1
I2
I3
I1
I2I1
I4
Fila 0 Fila 1 Fila 2 Fila 3 Fila 4 Fila 5 Fila 6 Fila 7
I2
I3
I1
Fila
I2
I3
I1
(b)(a)
I5
I6
I4
I1
Figura 3.3: Registro de Eventos (a) Reactor. (b) Proactor.
A figura 3.3 mostra o registro de eventos em ambos padroes, e utilizada uma
fila como estrutura de dados de armazenamento dos eventos para a implementacao
do mecanismo sıncrono do padrao Reactor. A diferenca do Proactor e que utiliza
oito filas chamadas filas de prioridade para implementar o mecanismo assıncrono.
Alem disso, tanto o Reactor quanto o Proactor tambem compartilham a
mesma estrutura do algoritmo 1 de gerenciamento de eventos, mas a diferenca
deles esta na funcao de demultiplexacao dos eventos onde, no Reactor e realizado
atraves do desenfileiramento do evento pronto na unica fila utilizada enquanto
no Proactor e realizado por meio de uma dinamica de desenfileiramento que sera
descrita no capıtulo 4, ambos gerenciam o evento obtido com a mesma logica para
responder a requisicao envolvida no evento.Como se pode deduzir, o Proactor e
CAPITULO 3. METODOLOGIA 22
Algorithm 1 Algoritmo de Gerenciamento de Eventos
1: procedure Handle Events2: loop3: while queue.size > 0 do4: queueItem = Dequeue() . Demultiplexing Events5: response = HandleEvent(queueItem)6: Send response7: end while8: end loop9: end procedure
uma versao do Reactor que, mesmo assim que conceitualmente sejam distintos,
adiciona oito filas de prioridade para melhorar o gerenciamento dos eventos.
3.2 Metodologia para a avaliacao dos resultados
A avaliacao se baseou na comparacao do desempenho entre as diferentes es-
trategias de gestao de fluxo SPDY, testadas durante a execucao do escalonador.
Assim, tendo em conta os parametros de tempo do diagrama de SPDY na fi-
gura 2.2, vamos considerar como parte da avaliacao o tempo de processamento
nas filas de prioridade do escalonador baseado nos algoritmos de padroes de pro-
jeto Reactor e Proactor do servidor SPDY.
Os modelos de trafego adotados para os testes da rede, estarao baseados no
trafego gerado por um grupo de outstations ou estacoes exteriores DNP3 [7], envi-
ando dados de potencia de uma planta de producao de energia, mas adicionando
diferentes prioridades para cada estacao DNP3 e incorporando sua atualizacao
de dados no fluxo SDPY.
Internet RedeCliente SPDY Servidor SPDY
Figura 3.4: Esquema do projeto.
A tecnica basica para o esquema do poll de atualizacao, utilizado no DNP3,
CAPITULO 3. METODOLOGIA 23
permite que o servidor interaja com o cliente retornando imediatamente uma
resposta aos requests periodicos de atualizacao, ou seja, quando ocorrem as al-
teracoes dos dados, enquanto que o cliente mantenha a subscricao. Esta abor-
dagem e descrita na especificacao, mas nao e comum em aplicativos reais devido
ao fato de que nao otimiza o procedimento de notificacao de alteracao de dados
para o cliente. A figura 3.5 mostra a abordagem basica do poll de atualizacao.
Cliente SPDY Servidor SPDY
Request de
Atualização
Cliente SPDY Servidor SPDY
Response do
Servidor
Figura 3.5: Abordagem basica do poll de atualizacao.
Capıtulo 4
Desenvolvimento de umprototipo de servidor SDPY
O desenvolvimento do prototipo de servidor SPDY abrangeu os dois primeiros
objetivos especıficos indicados na secao 1.2. O projeto foi desenvolvido na lingua-
gem de programacao Python e com o uso de bibliotecas externas que dao suporte
ao protocolo SSL, utilizando OpenSSL que adiciona a extensao “Next Protocol
Negotiation” (NPN) [35] para negociar o uso de SPDY sobre uma conexao se-
gura, e tambem para sockets assıncronos, adaptando a biblioteca “asyncore”1
para complementar ao correto funcionamento do escalonador SDPY.
A pesquisa da especificacao do protocolo SPDY e, o estudo dos dois padroes
de projeto e dos cinco algoritmos de escalonamento selecionados, descritos no
capıtulo 3, permitiram atingir o primeiro objetivo especıfico indicado na secao
1.2.
Para o desenvolvimento do prototipo de servidor SPDY, a estrutura do re-
quest/response SPDY esta baseada na especificacao do draft SPDY [5] versao
tres, versao atual suportada por navegadores e servidores que utilizam esta tec-
nologia, e a estrutura do escalonador, nesta primeira versao do prototipo, esta
baseada no padrao de projeto Proactor. A figura 4.1 mostra uma visao geral das
etapas desenvolvidas na primeira versao do servidor SPDY.
1A biblioteca “asyncore” fornece uma infraestrutura basica para desenvolver o gerenciamentode sockets assıncronos, http://docs.python.org/3/library/asyncore.html.
24
CAPITULO 4. DESENVOLVIMENTO DE UM PROTOTIPO DE SERVIDOR SDPY25
Cliente SPDY
Criar o Proactor
como base para
o escalonador de
SPDY
Escalonador - Proactor
Envolver o
frame SPDY
e a prioridade
em um evento
Enfileirar o
evento acordo à
prioridade
atribuida
Despachar o
novo frame
SPDY obtido de
gerenciar o
evento
desenfileirado
<< request SPDY>> << response SPDY>>
<< loop >>
Servidor SPDY
Figura 4.1: Visao geral das etapas desenvolvidas no projeto.
Funcionamento do escalonador SPDY A execucao do servidor SPDY con-
templa inicialmente a criacao da instancia do Proactor. Criada a instancia, dois
metodos serao executados: O registro do gerenciador de eventos, que e preciso
para a analise e processamento dos requests HTTP envolvidos nos frames SPDY,
e o inıcio do thread de gerenciamento de eventos, que fica esperando pelo menos
um elemento disponıvel nas filas de prioridade para ser processado pelo gerenci-
ador de eventos.
O processo no escalonador SPDY, baseado em Proactor, compreende tres
etapas para atingir o gerenciamento de requests SPDY: O envolvimento do frame
SPDY recebido e sua prioridade atribuıda em um evento, respeitando a concepcao
do Proactor descrita na subsecao 3.1; o enfileiramento do evento e por ultimo, o
despacho do frame SPDY resultante do gerenciamento do evento desenfileirado.
Enfileiramento do evento O enfileiramento do evento esta baseado na prio-
ridade atribuıda ao frame SPDY, como item de uma das oito filas de prioridade
criadas segundo a especificacao de SPDY [5]. A figura 4.2 mostra o diagrama de
interacao para o enfileiramento de eventos no escalonador SPDY.
CAPITULO 4. DESENVOLVIMENTO DE UM PROTOTIPO DE SERVIDOR SDPY26
Enfileiramento
iniciado
: Servidor
SPDY : Proactor : QueueItem :PriorityQueue
Estabelecer
parâmetros nos
items da fila
Procurar a fila
baseado na
prioridade
Enfileirar o
evento
Enqueue(handleID, event, priority)
:Queue
setHandle(handleID)
setEvent(event)
Enqueue(queueItem, priority)
Enqueue(queueItem)
FindPriorityQueue(priority)
Figura 4.2: Diagrama de interacao para o enfileiramento de eventos.
Despacho do frame SPDY O processo de despacho de um novo frame SPDY,
inicia com o desenfileiramento do evento pronto para gerenciar. A figura 4.3
mostra a dinamica de desenfileiramento utilizada nas oito filas de prioridade do
escalonador SDPY, onde para desenfileirar um evento e necessario cumprir com
a sequencia de prioridade desde a fila de prioridade mais alta ate a mais baixa.
Portanto, comeca a desenfileirar o evento pronto a partir da fila de mais alta
prioridade. Se essa fila estiver vazia, continua-se com a proxima fila de menor
prioridade e assim por diante.
I2
I3
I1
I2I1
I2
I3
I1 I1
I2
I3
I1
I2I1
I4
Fila 0 Fila 1 Fila 2 Fila 3 Fila 4 Fila 5 Fila 6 Fila 7
<< loop >>
I1
Alta
prioridade
Baixa
prioridade
Figura 4.3: Dinamica do desenfileiramento de eventos.
Com o evento desenfileirado, procedemos a tratar seu pedido com a analise
do frame SPDY envolvido. Essa analise compreende principalmente conhecer
qual e o tipo de frame SPDY para poder atender o requerimento. Assim, de
CAPITULO 4. DESENVOLVIMENTO DE UM PROTOTIPO DE SERVIDOR SDPY27
acordo a especificacao do protocolo SPDY, geramos um novo frame SPDY com
a informacao solicitada. A figura 4.4 mostra o diagrama de interacao para o
despacho de eventos no escalonador SPDY.
Desenfileiramento
iniciado
:Proactor:HTTP
Handler: QueueItem:PriorityQueue
Obter os
parâmetros do
item
Procurar o item
pronto e
desenfileirar
da fila
Gerenciar o
evento a
despachar
:Queue
Dequeue()
queueItem
FindQueueItem()
Dequeue()
queueItem
GetEvent()
event
GetHandle()
handleID
HandleEvent(event)
Figura 4.4: Diagrama de interacao para o despacho de eventos.
Gerenciamento assıncrono de sockets O “asyncore” e uma biblioteca que
trabalha com sockets gerenciados de forma assıncrona, seu desenho e baseado em
eventos e e utilizada para desenvolver servidores de rede com requests concorren-
tes. Estas caraterısticas ajudam muito ao desenvolvimento do escalonador SPDY,
mas essa biblioteca nao tem suporte para sockets envolvidos em SSL, e alem disso,
cada socket entrante e tratado na ordem de chegada e fechado imediatamente,
nao podendo se adequar a um esquema de gerenciamento com prioridade. Devido
a esses inconvenientes na biblioteca, foi adicionado um patch de suporte para soc-
kets envolvidos em SSL e foram implementados metodos para o gerenciamento
de erros e fechamento dos sockets.
Capıtulo 5
Resultados
A fim de abranger a avaliacao do tempo de processamento nas filas de prioridade
do escalonador SPDY, foi definido um ambiente de teste usando quatro maquinas
clientes e um servidor para transmitir requests com diferentes prioridades entre 0
e 7. O servidor e as maquinas clientes possuem as seguintes caracterısticas:
Processador RAM Sistema Operacional
Servidor Intel Core i5 3333M, 4 Nucleos de 3.2 GHz 4 GB Ubuntu 12.04, 32 bits
Maquina 1 Intel Core i5 2430M, 4 Nucleos de 2.4 GHz 4 GB Ubuntu 12.04, 64 bits
Maquina 2 Intel Core i5 3333M, 4 Nucleos de 3.2 GHz 4 GB Ubuntu 12.04, 32 bits
Maquina 3 Intel Core i5 3333M, 4 Nucleos de 3.2 GHz 4 GB Ubuntu 12.04, 64 bits
Maquina 4 Intel Core i5 3333M, 4 Nucleos de 3.2 GHz 4 GB Ubuntu 12.04, 64 bits
Tabela 5.1: Caracterısticas do servidor e das maquinas clientes.
Para determinar as faixas de prioridades e os tempos de envio dos requests
transmitidos por cada cliente para o servidor SDPY, foram utilizados quatro
arquivos de teste configurados com a seguinte estrutura: o valor da prioridade e
tempo de inter-arrival em milissegundos.
Arquivos de Teste Tres dos quatro arquivos de teste contem tempos de inter-
arrival de tres dispositivos DNP3 industriais reais chamados de A, F e J, os quais
enviam dados de uma planta de energia para uma central de controle SCADA,
estes tempos de inter-arrival foram obtidos a partir de medicoes ao longo de uma
semana de funcionamento da planta, alem disso, a cada tempo de inter-arrival foi
atribuıdo um valor de prioridade selecionado aleatoriamente das maiores priorida-
des que estao entre 0 e 2. Os dados destes arquivos tem o objetivo de simular uma
28
CAPITULO 5. RESULTADOS 29
situacao real de monitoramento enviando requests simultaneos por cada cliente.
Os tempos de inter-arrival do quarto arquivo ou arquivo de trafego de fundo,
foram criados utilizando uma funcao de distribuicao normal1 com media de 0.039
segundos e desvio padrao de 1.0 em um intervalo de tempo total de 90 horas.
Alem desta grande quantidade de dados de tempo de inter-arrival foi atribuıdo
aleatoriamente a cada tempo um valor de prioridade menor do que os arquivos
A, F e J que esta entre 3 e 7. Os dados deste ultimo arquivo tem o objetivo
de manter cheias as filas de prioridade gerando um efeito de stress no servidor
SPDY. A figura 5.1 mostra a estrutura e alguns dados dos arquivos de teste.
2 4000
0 6000
1 8000
0 4000
2 262000
.
.
.
A
0 8000
0 78000
2 2000
1 26000
0 2000
.
.
.
F
2 8000
1 22000
1 18000
0 4000
1 18000
.
.
.
J
7 614.094
4 109.847
6 1168.76
6 1083.66
3 703.774
.
.
.
Tráfego de Fundo
Figura 5.1: Estrutura dos arquivos de Teste A, F, J e Trafego de Fundo com ovalor da prioridade na primeira coluna e o tempo de inter-arrival na segunda.
Descricao do Teste Apos da execucao do servidor SPDY, cada cliente envia
o primeiro request e o servidor retorna uma response SPDY contendo texto com
sintaxe HTML e JavaScript aos clientes a fim de que possam anexar o arquivo
de teste a seguir. Assim cada cliente vai continuar um trafego principal com
prioridades entre 0 e 2 ou um trafego de fundo com prioridades entre 3 e 7 por
request. O codigo 5.1 mostra a funcao que e utilizada para gerar o conteudo da
response SPDY, esta funcao contem tres parametros e se o primeiro parametro,
que e boolean, e verdadeiro, entao le o conteudo de um arquivo com sintaxe HTML
e JavaScript de geracao do formulario que permite anexar arquivos.
1A funcao normrnd de Matlab gera numeros aleatorios a partir de uma funcao de distribuicaonormal, http://www.mathworks.com/help/stats/normrnd.html.
CAPITULO 5. RESULTADOS 30
def ge t r e sp proc t ime html (self , f i l e t e s t , t e s t a t t , prev t ime ) :try :
r e sp = ’ ’
if not f i l e t e s t :r e sp = ’<form id =\ ’myform\ ’ method=post> ’ \
’<t a b l e border =\ ’0\ ’> ’ \’<tr><th>Timer:</th> <td><input type =\ ’ t ex t \ ’ ’ \’ id =\ ’ t imer \ ’ va lue=’+t e s t a t t [0 ]+ ’></td></tr> ’\
’<tr><th>Previous Time:</th> <td><input type=’ \’ \ ’ t ex t \ ’ id =\ ’ prev t ime \ ’ va lue=’+prev t ime+’> ’
\’</td></tr> ’ \’<input type =\ ’ hidden \ ’ id =\ ’ curt ime \ ’ va lue=’+\
t e s t a t t [0 ]+ ’> ’ \’<input type =\ ’ hidden \ ’ id =\ ’nrow \ ’ va lue=’+ \t e s t a t t [1 ]+ ’> ’ \’<input type =\ ’ hidden \ ’ id =\ ’ p r i o r i t y \ ’ va lue=’+
\t e s t a t t [2 ]+ ’> ’ \’</tab le> ’ \’</form> ’
else :f = open( ’www/ proct ime a jax . html ’ , ’ rb ’ )re sp = f . read ( ) . decode ( ’UTF−8 ’ )f . c l o s e ( )
return re sp . encode ( ’ ut f−8 ’ )except IOError as e :
raise Exception ( ’ h t tp hand le r − ge t r e sp proc t ime html : ’ \’ I /O e r r o r ({0} ) : {1} ’ .format( e . errno , e . s t r e r r o r ) )
except Exception as e r r :raise Exception ( ’ h t tp hand le r − ge t r e sp proc t ime html : ’ , \e r r )
Codigo 5.1: Geracao do conteudo da response SPDY.
As linhas dos arquivos de teste enviados pelos clientes no proximo grupo
de requests sao armazenados em uma estrutura de dados do servidor a fim de
que possa gerenciar os novos requests ate o final do teste. A response SPDY
para cada request contem texto com sintaxe HTML que inclui tres parametros
preenchidos com o tempo que tem que esperar o cliente SPDY para enviar o
proximo request, a prioridade que vai ter esse request e o ındice do proximo
elemento da estrutura de dados que o servidor tem que obter para atender o
CAPITULO 5. RESULTADOS 31
request enviado. Assim, no codigo 5.1, se o primeiro parametro e falso, entao
geramos a sintaxe HTML de um formulario com campos que sao preenchidos com
os valores dos outros parametros da funcao. A figura 5.2 mostra a representacao
dos ultimos procedimentos anteriormente descritos.
Servidor SPDY
A
Máquina 2J
F
Cliente
Máquina 1
Cliente
Máquina 4
Cliente
(a)
Máquina
Servidor SPDY
(b)
Prioridade,
ÍndiceTempo,
Prioridade,
Índice
Cliente
Estrutura de
dados
Máquina 3
Cliente
Tráfego de
Fundo
Figura 5.2: (a) Armazenamento na estrutura de dados. (b) Gerenciamento dosnovos requests.
A medicao do tempo total de processamento2 nas filas de prioridade do escalo-
nador SPDY abrange as funcoes principais de desenfileiramento e gerenciamento
dos requests. Com a obtencao dos dados de tempo, numero de IP do cliente,
prioridade e numero de request no escalonador SPDY foram realizados dois ex-
perimentos preliminares, o registro em um arquivo de resultados dos tempos de
processamento nas filas de prioridade e a geracao de um grafico3 de Tempo de
inter-arrival vs. Numero de Requests.
2A biblioteca “cProfile” de Python mede o tempo total de execucao de uma porcao de codigo,http://docs.python.org/3.3/library/profile.html.
3A biblioteca “‘matplotlib” de Python realiza o plotting 2D e 3D de dados, http://
matplotlib.org/.
CAPITULO 5. RESULTADOS 32
5.1 Testes I: Analise do comportamento dos tem-pos de processamento nas oito filas de prio-ridade
Para atingir a analise do comportamento dos tempos de processamento nas filas de
prioridade, foram realizados distintos experimentos gerando graficos de Tempo de
processamento vs. Numero de Requests. As figuras abaixo mostram os resultados
dos testes que foram executados no servidor SDPY em um tempo total medio de
20 minutos.
Testes 1 e 2 Os testes 1 e 2 foram executados utilizando um dos clientes
SPDY para transmitir o trafego de fundo e os outros clientes o trafego principal
dos arquivos A, F e J. O esquema de realizacao destes testes esta representado
na figura 5.3.
Servidor SPDY
A
Máquina 2J
F
Cliente
Máquina 1
Cliente
Máquina 4
Cliente
Máquina 3
Cliente
Tráfego de
Fundo
Figura 5.3: Esquema dos testes 1 e 2.
A figura 5.4 mostra que o Teste 1 realizado em um tempo total de 20 minutos
alcanca um numero de requests de 517 e um tempo de processamento maximo de
0.0367 ms.
A figura 5.5 mostra que o Teste 2 realizado em um tempo total de 20 minutos
alcanca um numero de requests de 508 e um tempo de processamento maximo de
0.0392 ms.
CAPITULO 5. RESULTADOS 33
Figura 5.4: Plotting 2D do teste 1 utilizando um cliente SPDY para transmitir otrafego de fundo.
Figura 5.5: Plotting 2D do teste 2 utilizando um cliente SPDY para transmitir otrafego de fundo.
Testes 3 e 4 Os testes 3 e 4 foram executados utilizando um cliente SPDY,
distinto ao usado nos testes 1 e 2, para transmitir o trafego de fundo e os outros
clientes o trafego principal dos arquivos A, F e J. O esquema de realizacao destes
testes esta representado na figura 5.6.
CAPITULO 5. RESULTADOS 34
Servidor SPDY
A
Máquina 2J F
Cliente
Máquina 1
Cliente
Máquina 4
Cliente
Máquina 3
Cliente
Tráfego de
Fundo
Figura 5.6: Esquema dos testes 3 e 4.
Figura 5.7: Plotting 2D do teste 3 utilizando outro cliente SPDY para transmitiro trafego de fundo.
A figura 5.7 mostra que o Teste 3 realizado em um tempo total de 20 minutos
alcanca um numero de requests de 457 e um tempo de processamento maximo de
0.035 ms.
A figura 5.8 mostra que o Teste 4 realizado em um tempo total de 35 mi-
nutos com 46 segundos alcanca um numero de requests de 774 e um tempo de
processamento maximo de 0.038 ms.
Testes 5 e 6 Os testes 5 e 6 foram executados utilizando um cliente SPDY,
distinto ao usado nos anteriores testes, para transmitir o trafego de fundo e os
outros clientes o trafego principal dos arquivos A, F e J. O esquema de realizacao
CAPITULO 5. RESULTADOS 35
Figura 5.8: Plotting 2D do teste 4 utilizando outro cliente SPDY para transmitiro trafego de fundo.
destes testes esta representado na figura 5.9.
Servidor SPDY
AMáquina 2
J
F
Cliente
Máquina 1
Cliente
Máquina 4
Cliente
Máquina 3
Cliente
Tráfego de
Fundo
Figura 5.9: Esquema dos testes 5 e 6.
A figura 5.10 mostra que o Teste 5 realizado em um tempo total de 20 minutos
e 13 segundos alcanca um numero de requests de 461 e um tempo de processa-
mento maximo de 0.039 ms.
CAPITULO 5. RESULTADOS 36
Figura 5.10: Plotting 2D do teste 5 utilizando outro cliente SPDY para transmitiro trafego de fundo.
Figura 5.11: Plotting 2D do teste 6 utilizando outro cliente SPDY para transmitiro trafego de fundo.
A figura 5.11 mostra que o Teste 6 realizado em um tempo total de 20 minutos
alcanca um numero de requests de 436 e um tempo de processamento maximo de
0.04 ms.
CAPITULO 5. RESULTADOS 37
5.2 Testes II: Analise e comparacao do compor-tamento dos tempos de processamento emuma fila sem prioridade e nas oito filas deprioridade
Para ter uma melhor visualizacao do comportamento dos tempos de processa-
mento nas filas de prioridade e assim poder observar em quais filas os requests se
processam em menor tempo e em quais se gerenciam mais, foram gerados distintos
graficos em 3D considerando novamente o tempo de processamento e o numero de
request adicionando como terceiro parametro a prioridade ou o numero de cliente
de acordo com a analise.
Nas figuras abaixo serao mostradas dois tipos de analise com o objetivo de
fazer a comparacao visual entre elas, a primeira considera a proposta deste tra-
balho com a adicao das oito filas de prioridade no gerenciamento dos requests no
escalonador SPDY com graficos de Tempo de Processamento vs. Numero de re-
quests vs. Prioridade. A segunda considera somente uma fila de armazenamento
dos requests atribuindo para cada um deles a mesma prioridade com graficos de
Tempo de Processamento vs. Numero de requests vs. Cliente.
Teste 7 As figuras 5.12, 5.13, 5.14 mostram os graficos do experimento que
utilizou os tres arquivos de tempos reais de teste A, F, J e o arquivo de trafego de
fundo. Como resultado se pode observar que nos 20 minutos de execucao do teste
os 126 requests com prioridades entre 0 e 2 sao processados em um tempo medio
de 0.0012 ms e os 378 requests com prioridades entre 3 e 7 sao processados em
um tempo medio de 0.0019 ms alcancando um tempo de processamento maximo
no teste de 0.025 ms.
CAPITULO 5. RESULTADOS 38
Figura 5.12: Vista 1: Plotting 3D do teste 7 utilizando oito filas de prioridade.
Figura 5.13: Vista 2: Plotting 3D do teste 7 utilizando oito filas de prioridade.
CAPITULO 5. RESULTADOS 39
Figura 5.14: Vista 3: Plotting 3D do teste 7 utilizando oito filas de prioridade.
Teste 8 As figuras 5.15, 5.16, 5.17 mostram os graficos do experimento que
utilizou quatro arquivos de teste que contem os mesmos dados de tempo do
arquivo de trafego do fundo, atribuindo aleatoriamente para tres deles as maiores
prioridades entre 0 e 2. O objetivo deste experimento e a execucao simultanea
com tempos curtos de envio entre requests para alcancar o mais alto nıvel de
stress no servidor. Como resultado se pode observar que nos 20 minutos de
execucao do teste os 1062 requests com prioridades entre 0 e 2 sao processados
em um tempo medio de 0.002408 ms e os 380 requests com prioridades entre 3 e
7 sao processados em um tempo medio de 0.002416 ms alcancando um tempo de
processamento maximo no teste de 0.063 ms. Alem disso, se pode observar que
com esta grande quantidade de transmissao de dados sao gerenciados com maior
prioridade aqueles requests com prioridades entre 0 e 2.
CAPITULO 5. RESULTADOS 40
Figura 5.15: Vista 1: Plotting 3D do teste 8 utilizando oito filas de prioridade.
Figura 5.16: Vista 2: Plotting 3D do teste 8 utilizando oito filas de prioridade.
CAPITULO 5. RESULTADOS 41
Figura 5.17: Vista 3: Plotting 3D do teste 8 utilizando oito filas de prioridade.
Teste 9 As figuras 5.18, 5.19, 5.20 mostram os graficos do experimento que
utilizou novamente nos quatro arquivos de teste os dados de tempo do arquivo de
trafego de fundo com a diferenca que se atribuıram a todos os tempos a mesma
prioridade com valor 0. O objetivo deste experimento e observar o comportamento
dos tempos de processamento em um contexto sıncrono de gerenciamento de
requests e de fazer uma comparacao com a proposta das oito filas de prioridade
no escalonador SPDY. Como resultado se pode observar que nos 20 minutos
de execucao do teste os 1550 requests sao processados em um tempo medio de
0.00246 ms alcancando um tempo de processamento maximo de 0.06 ms.
CAPITULO 5. RESULTADOS 42
Figura 5.18: Vista 1: Plotting 3D do teste 9 utilizando uma fila de prioridade.
Figura 5.19: Vista 2: Plotting 3D do teste 9 utilizando uma fila de prioridade.
CAPITULO 5. RESULTADOS 43
Figura 5.20: Vista 3: Plotting 3D do teste 9 utilizando uma fila de prioridade.
5.3 Testes III: Analise e comparacao do com-portamento dos tempos de processamentonas oito filas com prioridade e quantum detempo
Tomando em consideracao a caracterıstica principal do algoritmo de escalona-
mento Round-Robin, o quantum descrito nas subsecoes 2.3.1 e 2.3.2, foi atribuıdo
a cada fila de prioridade um tempo maximo de execucao ou quantum com a
finalidade que os requests armazenados nas filas com menor prioridade sejam
processados com maior frequencia e assim se possa controlar mais a inanicao.
Empiricamente foi atribuıdo um quantum a cada fila de prioridade com valores
entre 0.8 a 0.1 segundos nessa ordem, assim a dinamica de desenfileiramento,
descrita no capıtulo 4, foi adicionada um novo controle de tempo de execucao
para cada fila de prioridade. Assim, se esse tempo de execucao fosse maior ao
quantum atribuıdo, entao deixa de gerenciar os demais requests da fila atual
que esta atingindo para continuar com os requests da proxima fila de menor
CAPITULO 5. RESULTADOS 44
prioridade, e assim por diante com cada fila de prioridade. A figura 5.21 mostra
a nova dinamica de desenfileiramento para o teste utilizando um quantum de
tempo para cada fila de prioridade.
I2
I3
I1
I2I1
Fila 0 Fila 1 Fila 2 Fila 7
<< loop >>
I1
Alta
prioridade
Baixa
prioridade
q= 0.8 sec q= 0.7 sec q= 0.6 sec q= 0.1 sec
...
Figura 5.21: Nova dinamica de desenfileiramento para o teste.
As figuras abaixo mostram os graficos de dois experimentos realizados com
quatro arquivos de teste que contem os mesmos dados de tempo que do arquivo de
trafego de fundo onde dois deles tem atribuıdos aleatoriamente para cada tempo
as maiores prioridades entre 0 e 2 e os outros dois tem atribuıdos aleatoriamente
prioridades entre 3 e 7, com o objetivo de realizar uma comparacao entre estes
experimentos.
Teste 10 As figuras 5.22, 5.23 mostram os graficos do experimento realizado
com o mesmo gerenciamento sobre as oito filas de prioridade descritos no primeiro
experimento da secao 5.2 em um tempo total de 20 minutos, onde o escalona-
dor SDPY alcanca gerenciar 759 requests nas filas de maior prioridade com um
tempo medio de processamento de 0.002304 ms, 480 requests nas filas de menor
prioridade com um tempo medio de processamento de 0.002388 ms e um maximo
tempo de processamento entre os requests de 0.064 ms.
CAPITULO 5. RESULTADOS 45
Figura 5.22: Vista 1: Plotting 3D do teste 10 utilizando oito filas de prioridade.
Figura 5.23: Vista 2: Plotting 3D do teste 10 utilizando oito filas de prioridade.
CAPITULO 5. RESULTADOS 46
Teste 11 As figuras 5.24, 5.25 mostram os graficos do experimento realizado
com o quantum de tempo para cada fila de prioridade, descrito nesta secao, em
um tempo total de 20 minutos, onde o escalonador SDPY alcanca gerenciar 740
requests nas filas de maior prioridade com um tempo medio de processamento de
0.002836 ms, 541 requests nas filas de menor prioridade com um tempo medio de
processamento de 0.002945 ms e um maximo tempo de processamento entre os
requests de 0.084 ms. Como se pode observar nos dois experimentos realizados
com os mesmos arquivos de teste, a utilizacao de um quantum para cada fila de
prioridade permite gerenciar mais requests das filas de menor prioridade.
Figura 5.24: Vista 1: Plotting 3D do teste 11 utilizando um quantum para cadafila de prioridade.
CAPITULO 5. RESULTADOS 47
Figura 5.25: Vista 2: Plotting 3D do teste 11 utilizando um quantum para cadafila de prioridade.
Em resumo as tabelas 5.2 e 5.3 contem os resultados dos testes descritos nas
secoes 5.2 e 5.3:
Prioridades N. Requests Tempo Medio de Proc. Tempo Max. de Proc.
Teste 7 0 - 2 126 0.0012 ms
3 - 7 378 0.0019 ms 0.025 ms
Teste 8 0 - 2 1062 0.002408 ms
3 - 7 380 0.002416 ms 0.063 ms
Teste 9 1550 0.00246 ms 0.06 ms
Tabela 5.2: Resultados dos Testes 7, 8 e 9.
Prioridades N. Requests Tempo Medio de Proc. Tempo Max. de Proc.
Teste 10 0 - 2 759 0.002304 ms
3 - 7 480 0.002388 ms 0.064 ms
Teste 11 0 - 2 740 0.002836 ms
3 - 7 541 0.002945 ms 0.084 ms
Tabela 5.3: Resultados dos Testes 10 e 11.
Capıtulo 6
Conclusoes
O Proactor, como padrao projetado para aplicativos orientados a evento que
recebem e processam multiplos eventos de forma assıncrona, se adequa as ca-
racterısticas requeridas no escalonador SPDY permitindo a concorrencia e otimo
gerenciamento dos requests transmitidos pelos clientes SDPY.
A inclusao de oito filas de prioridade no escalonador SPDY ajuda a alcancar no
Proactor o conceito de mecanismo assıncrono, alem de que obedece a priorizacao
dos requests como uma das melhorias de SPDY sobre HTTP. Os testes baseados,
em grande parte nesta funcionalidade do escalonador SPDY e descritos na secao
5.2, demonstram que os requests com maior prioridade sao processados na media
em menor tempo alem de que sao gerenciados em maior quantidade, ao contrario
dos requests com menor prioridade que sao gerenciados em menor quantidade
alcancando tempos de processamento maximos em alguns requests e na media
maior tempo de processamento.
A atribuicao de um quantum, como caracterıstica principal do algoritmo de
escalonamento Round-Robin, ou tempo de execucao para cada fila de prioridade,
descrito na secao 5.3, melhorou o gerenciamento dos requests armazenados em
todas as filas de prioridade, prevenindo a execucao indefinida dos requests com
maior prioridade e aumentando a quantidade de requests gerenciados com menor
prioridade.
Este trabalho demonstrou que se alcancamos simular uma situacao real com
o envio de dados gerados por dispositivos industriais de uma planta de energia,
48
CAPITULO 6. CONCLUSOES 49
tomando em consideracao o otimo funcionamento do escalonador SDPY, entao
os aplicativos de monitoramento poderiam adotar as caracterısticas do protocolo
SPDY para melhorar o desempenho atual da tecnica de atualizacao de dados
descrita na secao 3.2.
Referencias Bibliograficas
[1] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext Transfer Protocol –
HTTP/1.0. http://www.ietf.org/rfc/rfc1945.txt, May 1996.
[2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Le-
ach, and T. Berners-Lee. Hypertext Transfer Protocol – HTTP/1.1.
http://www.ietf.org/rfc/rfc2616.txt, June 1999.
[3] J.F. Kurose and K.W. Ross. Computer Networking: A Top-Down Approach.
Addison-Wesley, 2010.
[4] Ilya Grigorik. Optimizing HTTP: Keep-alive and Pipelining.
http://www.igvita.com/2011/10/04/optimizing-http-keep-alive-and-
pipelining, Oct. 2011.
[5] R. Peon M. Belshe. SPDY Protocol. http://tools.ietf.org/html/draft-
mbelshe-httpbis-spdy-00, Feb. 2012.
[6] Modbus Organization. Modbus Application Protocol Specification v1.1b3.
http://www.modbus.org/docs/Modbus Application Protocol V1 1b3.pdf,
April 2012.
[7] IEEE Draft Standard for Electric Power Systems Communications -
Distributed Network Protocol (DNP3). IEEE P1815/D08, January 2012,
pages 1–858, Feb 2012.
[8] OPC Foundation. OPC XML-DA Specification.
http://www.opcfoundation.org/, July 2003.
50
REFERENCIAS BIBLIOGRAFICAS 51
[9] OPC Foundation. OPC Unified Architecture.
http://www.opcfoundation.org/UA.
[10] N.M. Torrisi. Cyberopc. http://www.cyberopc.org.
[11] N.M. Torrisi. Monitoring Services for Industrial. Industrial Electronics Ma-
gazine, IEEE, 5(1):49 –60, March 2011.
[12] Jan Newmarch. Introduction to stream control transmission protocol. Linux
J., (161):7, Sep. 2007.
[13] P. Natarajan, P. Amer, J. Leighton, and F. Baker. SCTP for HTTP.
http://tools.ietf.org/html/draft-natarajan-http-over-sctp-02, July 2009.
[14] Bryan F. Structured Stream Transport. http://pdos.csail.mit.edu/uia/sst,
March 2007.
[15] W3C HTTP-NG project. MUX Overview.
http://www.w3.org/Protocols/MUX, Dec. 2000.
[16] Shishir G. CGI Programming on the World Wide Web.
http://oreilly.com/openbook/cgi/ch06 06.html, March 1996.
[17] P. McCarthy and D. Crane. Comet and Reverse Ajax: The Next-Generation
Ajax 2.0. Apresspod Series. Apress, 2008.
[18] Mathieu Carbou. Reverse Ajax, Part 1: Introduction to Co-
met. http://www.ibm.com/developerworks/web/library/wa-reverseajax1,
July 2011.
[19] Alex R., Greg W., David D., and Mark N. Bayeux Protocol – Bayeux 1.0.0.
http://svn.cometd.com/trunk/bayeux/bayeux.html, 2007.
[20] XMPP Standards Foundation. XMPP Technologies: BOSH.
http://xmpp.org/about-xmpp/technology-overview/bosh.
REFERENCIAS BIBLIOGRAFICAS 52
[21] IETF. Hypertext Transfer Protocol Bis (httpbis).
https://datatracker.ietf.org/wg/httpbis/charter/, 2012.
[22] World Wide Web Consortium. W3C. http://www.w3.org.
[23] Ilya Grigorik. Ruby & Websockets: TCP for the Browser.
http://www.igvita.com/2009/12/22/ruby-websockets-tcp-for-the-browser,
Dec. 2011.
[24] A. Melnikov I. Fette. The Websocket Protocol.
http://tools.ietf.org/html/rfc6455, Dec. 2011.
[25] Mark A. Greg R., Jean-loup G. zlib. http://zlib.net/, July 2012.
[26] Fan Y., Paul A., Jonathan L., and Mike B. A methodology to derive SPDY’s
initial dictionary for zlib compression.
[27] J. Heidemann, K. Obraczka, and J. Touch. Modeling the performance of
HTTP over several transport protocols. Networking, IEEE/ACM Transac-
tions on, 5(5):616–630, 1997.
[28] Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall PTR,
2001.
[29] Chuck Semeria. Supporting Differentiated Service Classes: Queue Scheduling
Disciplines. Juniper Networks, 2001.
[30] Abraham S., Peter B. G., and Greg G. Operating Systems Concepts. JOHN
WILEY & SONS. INC, 2005.
[31] Ioannou, Aggelos, Katevenis, and Manolis G. H. Pipelined heap (priority
queue) management for advanced scheduling in high-speed networks. IEE-
E/ACM Trans. Netw., 15(2):450–461, Apr. 2007.
REFERENCIAS BIBLIOGRAFICAS 53
[32] U. Praphamontripong, S. Gokhale, A. Gokhale, and J. Gray. Performance
Analysis of an Asynchronous Web Server. In Computer SW and App. Conf.,
COMPSAC ’06. 30th Annual Int., volume 2, pages 22–28, Sept. 2006.
[33] Douglas C. S. Reactor – An Object Behavioral Pattern for Concurrent Event
Demultiplexing and event handler dispatching, 1995.
[34] Douglas C. S. James Hu, Irfan P. Applying The Proactor Pattern to High-
Performance Web Servers. In Proceedings of the 10th Int. Conf. on Parallel
and Distributed Computing and Systems, 1998.
[35] A. Langley. Transport Layer Security (TLS) Next Protocol Negotiation Ex-
tension. draft-agl-tls-nextprotoneg-03, April 2012.