Universidade Federal do ABC (UFABC)
Centro de Matemática, Computação e Cognição (CMCC)
Curso de Pós-Graduação em Ciência da Computação
Dissertação de Mestrado
Jhon Franko Jorge Velarde
APLICAÇÃO DO PROTOCOLO SPDY PARA APLICATIVOS DE
MONITORAMENTO SOBRE REDES DE IP PÚBLICO
Santo André - SP
2014
Curso de Pós-Graduação em Ciência da Computação
Dissertação de Mestrado
Jhon Franko Jorge Velarde
APLICAÇÃO DO PROTOCOLO SPDY PARA APLICATIVOS DE
MONITORAMENTO SOBRE REDES DE IP PÚBLICO
Trabalho apresentado como requisito parcial
para obtenção do tı́tulo de Mestre em Ciência
da Computação, sob orientação do Prof. Dr.
Nunzio Marco Torrisi.
Santo André - SP
2014
Centro de Matemática, Computação e Cognição (CMCC)
Curso de Pós-Graduação em Ciência da Computação
APLICAÇÃO DO PROTOCOLO SPDY PARA APLICATIVOS DE
MONITORAMENTO SOBRE REDES DE IP PÚBLICO
Jhon Franko Jorge Velarde
Março de 2014
BANCA EXAMINADORA:
• Prof. Dr. Nunzio Marco Torrisi (Presidente)
(CMCC) Universidade Federal do ABC - UFABC
• Prof. Dr. Rodrigo Palucci Pantoni
Instituto Federal de São 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 relação à versão original,
de acordo com as observações levantadas pela banca no dia da defesa, sob responsabilidade única do autor e com a anuência de seu
orientador.
Santo André, 20 de março de 2014.
Assinatura do autor:
Assinatura do orientador:
Resumo
O objetivo deste trabalho é propor o uso do protocolo SPDY em aplicativos de
monitoramento sobre redes de IP público, com foco nas melhorias sobre HTTP e
fornecido pelo escalonamento de requests utilizando as oito prioridades no fluxo
SPDY. Para o escalonamento SPDY, são considerados algoritmos de padrões de
projeto que utilizam mecanismos sı́ncronos ou assı́ncronos para o gerenciamento
de requests de múltiplos clientes, tais como: os padrões Reactor e Proactor. A
caracterı́stica principal, o quantum de tempo, compartilhada nos algoritmos de
escalonamento, tais como: Escalonamento por Prioridade, Escalonamento RoundRobin, Escalonamento em Filas Multinı́vel, Weighted Fair Queuing e Weighted
Round-Robin, permite que os requests com menor prioridade tenham maior oportunidade de ser gerenciados. Um protótipo de servidor SPDY foi desenvolvido
baseado na especificação do protocolo SPDY e, nas caracterı́sticas principais
dos padrões de projeto e algoritmos de escalonamento propostos. A avaliação
deste protótipo foi feita na simulação de uma situação real de monitoramento,
o protótipo considerou três estruturas para gerenciamento de requests no escalonador: 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 são processados na média em menor tempo
além de que são gerenciados em maior quantidade e, a utilização de um quantum 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, Padrões 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 improvements over HTTP provided by the request scheduling using the eight priorities
in SPDY stream. For the SPDY scheduling, are considered design patterns algorithms 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 opportunity 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
Agradeço a Deus pelas bênçãos, pela minha saúde e proteção em todos os dias
da minha vida.
Agradeço a minha esposa e amor Alisoli Pretel Jesus por que juntos somos
uma grande equipe, pelo apoio, pela presença e grande amor, por que todo isso
foi um grande motor para conduzir este mestrado em bom caminho.
Agradeço profundamente a minha amada mãe, Dominga e a minha querida
irmã, Marı́a, pelo amor, pelas orações, pela motivação, compreensão e apoio
incondicional em todo momento.
Agradeço a meu orientador o Prof. Dr. Nunzio Marco Torrisi pela amizade,
pelos ensinamentos, ajuda e colaboração com o meu trabalho no mestrado.
Aos professores André Balan, João Paulo Gois e Ronaldo Prati pelas novas
experiências e pelos conhecimentos adquiridos.
E finalmente, agradeço a meus caros amigos Lı́dia, Marcel e Renato por ter
me dado a sua confiança, amizade e por sempre torcer por mim.
vi
Glossário
AJAX
Asynchronous Javascript and XML
CyberOPC
Cybernetic OPC
DNP3
Distributed Network Protocol, version 3
HMI
HTML5
HTTP
HTTPS
Human Machine Interface
HyperText Markup Language, version 5
HyperText Transfer Protocol
HyperText Transfer Protocol Secure
IETF
Internet Engineering Task Force
OLE
Object Linking and Embedding
OPC
OLE for Process Control
OPC XML-DA OPC eXtensible Markup Language-Data Access
OPC-UA
OPC-Unified Architecture
RFC
Request For Comments
SCADA
SPDY
SSL
Supervisory Control And Data Acquisition
SPeeDY Protocol
Secure Sockets Layer
TCP/IP
TLS
Transmission Control Protocol/ Internet Protocol
Transport Layer Security
W3C
World Wide Web Consortium
vii
Sumário
Glossário
vii
1 Introdução
2
1.1
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Organização deste trabalho . . . . . . . . . . . . . . . . . . . . . .
4
2 Revisão Bibliográfica
2.1
2.2
2.3
5
Tecnologias Relacionadas . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
Melhoria do Projeto de Aplicativos HTTP . . . . . . . . .
5
2.1.2
Melhorias da Especificação do Protocolo HTTP . . . . . .
7
2.1.3
Tecnologias Middleware para Otimização de uso de HTTP
8
Estado da arte
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2.1
Protocolo WebSocket . . . . . . . . . . . . . . . . . . . . .
10
2.2.2
Protocolo SPDY . . . . . . . . . . . . . . . . . . . . . . .
10
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
3.1
3.2
18
Padrões de projeto para transmissão de dados de tipo sı́ncrono e
assı́ncrono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
Metodologia para a avaliação dos resultados . . . . . . . . . . . .
22
4 Desenvolvimento de um protótipo de servidor SDPY
viii
24
SUMÁRIO
5 Resultados
5.1
28
Testes I: Análise do comportamento dos tempos de processamento
nas oito filas de prioridade . . . . . . . . . . . . . . . . . . . . . .
5.2
ix
32
Testes II: Análise e comparação do comportamento dos tempos
de processamento em uma fila sem prioridade e nas oito filas de
prioridade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3
37
Testes III: Análise e comparação do comportamento dos tempos
de processamento nas oito filas com prioridade e quantum de tempo 43
6 Conclusões
48
Lista de Figuras
2.1
Diagrama temporal da modalidade HTTP Keep-alive (a) e Pipelining (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
8
Diagrama de conexões SPDY. As setas grossas indicam a transferência de dados, enquanto as setas finas mostram os tipos de
frames SPDY: PING, SETTINGS, SYN STREAM, SYN REPLY
e DATA FRAME. . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
12
Escalonamento Round-Robin. (a) Fila de frames. (b) Fila de frames quando F S1 não termina após 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 interação para o padrão Reactor. . . . . . . . . . . .
19
3.2
Diagrama de interação para o padrão Proactor. . . . . . . . . . .
21
3.3
Registro de Eventos (a) Reactor. (b) Proactor. . . . . . . . . . . .
21
3.4
Esquema do projeto. . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.5
Abordagem básica do poll de atualização. . . . . . . . . . . . . . .
23
4.1
Visão geral das etapas desenvolvidas no projeto. . . . . . . . . . .
25
4.2
Diagrama de interação para o enfileiramento de eventos. . . . . .
26
4.3
Dinâmica do desenfileiramento de eventos. . . . . . . . . . . . . .
26
4.4
Diagrama de interação para o despacho de eventos. . . . . . . . .
27
x
LISTA DE FIGURAS
5.1
xi
Estrutura dos arquivos de Teste A, F, J e Tráfego de Fundo com o
valor da prioridade na primeira coluna e o tempo de inter-arrival
na segunda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2
29
(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 tráfego de fundo. . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5
33
Plotting 2D do teste 2 utilizando um cliente SPDY para transmitir
o tráfego de fundo. . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.6
Esquema dos testes 3 e 4. . . . . . . . . . . . . . . . . . . . . . .
34
5.7
Plotting 2D do teste 3 utilizando outro cliente SPDY para transmitir o tráfego de fundo. . . . . . . . . . . . . . . . . . . . . . . .
5.8
5.9
34
Plotting 2D do teste 4 utilizando outro cliente SPDY para transmitir o tráfego de fundo. . . . . . . . . . . . . . . . . . . . . . . .
35
Esquema dos testes 5 e 6. . . . . . . . . . . . . . . . . . . . . . .
35
5.10 Plotting 2D do teste 5 utilizando outro cliente SPDY para transmitir o tráfego de fundo. . . . . . . . . . . . . . . . . . . . . . . .
36
5.11 Plotting 2D do teste 6 utilizando outro cliente SPDY para transmitir o tráfego 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 dinâmica 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 máquinas 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 . . . . . . . . . . . . . .
1
22
Capı́tulo 1
Introdução
Em 1991, foi especificada a primeira versão do protocolo HTTP por Tim BernersLee e, em 1996, foi padronizado pelo IETF como HTTP 1.0 e documentado no
RFC 1945 [1]. Apenas três anos depois, pelo aumento da carga na web, foi padronizado o HTTP 1.1 pelo IETF. O protocolo revisado no RFC 2616 [2] reduziu
o número necessário de requisições de conexão para um terminal através da introdução de conexões keep-alive [3] e, através do HTTP pipelining [4] permitiu
múltiplos requests em sequência sem a necessidade de esperar por as correspondentes responses. O HTTP não mudou muito desde então, embora o panorama
web tenha mudado fundamentalmente.
Desde a primeira especificação do protocolo HTTP - RFC 1945, os aplicativos
baseados neste protocolo evoluı́ram superando a limitação da especificação para
trabalhar com streaming e conteúdos web interativos. No entanto, muitos dos
gargalos das implementações HTTP 1.1 estão relacionadas à gestão de múltiplas
conexões simultâneas, configurações de conexão de ida e volta desnecessárias,
controle de congestionamento e um racionamento constante causado pelo cliente
onde ele tenta evitar a abertura de muitas conexões em um único servidor [5].
Enquanto a comunidade cientı́fica vem desenvolvendo novas ideias para melhorar
o desempenho de aplicativos web sobre HTTP 1.1, a limitação do domı́nio de muitos aplicativos de monitoramento de redes IP locais foi estendida para redes de
IP público usando HTTP como protocolo preferido para aplicativos personaliza-
2
CAPÍTULO 1. INTRODUÇÃO
3
dos. Os aplicativos modernos SCADA1 e HMI2 têm acesso em leitura e escritura,
parcial ou totalmente, a suas variáveis de processo através 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 soluções interessantes.
1.1
Motivação
Este trabalho foi motivado pela utilização 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 abordagem tenta resolver o problema através do protocolo e não através de um middleware de aplicativos HTTP, por exemplo, o Reverse AJAX [11]. Assim, os
principais resultados esperados são:
• Uma metodologia otimizada para usar o protocolo SPDY em redes públicas
para monitoramento e controle de processos industriais;
• A contribuição tecnológica na indústria de software para aplicativos de monitoramento através da internet.
1.2
Objetivos
O principal objetivo é pesquisar e desenvolver um protótipo de servidor SPDY
baseado nas especificações do protocolo, os estudos de padrões de projeto e nas
caracterı́sticas dos algoritmos de escalonamento aplicadas na teoria de gerenciamento de filas de prioridade do escalonador SPDY. Os algoritmos de gerenciamento de filas adotados no projeto do servidor são justificados pela caracterı́stica
de prioridade do protocolo SPDY. Mais especificamente, os objetivos são:
• Investigar o protocolo SPDY, os padrões de projeto e algoritmos de escalonamento, para atingir os requerimentos de gerenciamento de prioridades e
1
SCADA ou Supervisory Control and Data Acquisition é um sistema que utiliza software
para monitorar e supervisionar as variáveis e dispositivos de sistemas de controle industrial.
2
HMI ou Human–machine interface inclui componentes de hardware e software pelo qual os
usuários interagem com as máquinas.
CAPÍTULO 1. INTRODUÇÃO
4
modelar a integração do gerenciador de fluxo de prioridades SPDY;
• Desenvolver um servidor de teste e simular cenários de aplicativos de monitoramento no laboratório;
• Comparar a estratégia de gerenciamento de fluxo sobre redes de IP público
e avaliar os resultados.
1.3
Organização deste trabalho
O primeiro capı́tulo é destinado a fornecer o leitor uma visão geral dos assuntos
abordados neste trabalho, assim, neste capı́tulo são apresentadas a introdução,
motivação e os objetivos.
No capı́tulo 2 são apresentadas as caracterı́sticas de varias tecnologias relacionadas que visam à melhoria de HTTP. Também descrevemos o estado da arte que
abrange os protocolos WebSocket e SPDY, considerados os principais candidatos
para a próxima e esperada especificação do HTTP 2.0 pelo IETF. Além disso,
são abordadas as caracterı́sticas principais dos algoritmos de escalonamento.
No capı́tulo 3 são descritas as caracterı́sticas principais dos padrões de projeto consideradas para o desenvolvimento do escalonador SPDY. Além disso, é
apresentada a metodologia utilizada para avaliação dos resultados.
No capı́tulo 4 são abordadas, detalhadamente, as etapas compreendidas no
desenvolvimento de um protótipo de servidor SPDY.
No capı́tulo 5 são apresentados os resultados dos distintos experimentos feitos
sobre o protótipo desenvolvido, além de descrever a análise de cada um deles. A
avaliação foi feita na simulação de uma situação real de monitoramento considerando três grupos de testes.
Finalmente, no capı́tulo 6 são apresentadas as conclusões desta dissertação.
Capı́tulo 2
Revisão Bibliográfica
2.1
2.1.1
Tecnologias Relacionadas
Melhoria do Projeto de Aplicativos HTTP
Blocking e Non-Blocking Socket
Os termos de Blocking e Non-Blocking
I/O fazem referência à maneira pela qual os I/O são processados no sistema
operacional (OS), sı́ncrona ou assincronamente respectivamente. O problema
da limitação de conexões simultâneas está relacionado também à forma como
o servidor foi implementado e como o OS trabalha com os sockets. Querendo
iniciar uma conexão com o servidor e utilizando um socket para qualquer tipo
de operação, no Blocking I/O, a operação é iniciada com um thread, a qual fica
imediatamente em espera até que o pedido esteja completo. No caso de NonBlocking I/O, existem duas alternativas, ou um polling, onde o servidor tenta
fazer a operação cada intervalo de tempo, ou a utilização de uma notificação
assı́ncrona, no qual o servidor gera um evento indicando que uma operação está
pronta para ser processada.
Devido à complexa interação entre HTTP e o subjacente protocolo da camada
de transporte (TCP), quer isto dizer, apesar da adição das técnicas de HTTP
keep-alive e pipelining em HTTP/1.1, um atraso de 500 ms no servidor HTTP
impede a reutilização do canal TCP para requests adicionais, do modo que, os
navegadores atuais evitam este problema abrindo múltiplas conexões simultâneas,
em uma média de 6 conexões. O gerenciamento de múltiplas sessões TCP, para
suportar essas conexões simultâneas, aumenta a sobrecarga e a latência. SPDY
5
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
6
[5] proporciona melhorias significativas de latência, mas existem outras soluções
propostas para a latência web, principalmente no nı́vel da camada de transporte
ou sessão.
Stream Control Transmission Protocol (SCTP) É um protocolo da camada de transporte que trabalha como os populares protocolos TCP e UDP e
oferece algumas de suas caracterı́sticas de serviço. É orientado a mensagem como
UDP e garante a confiabilidade e mensagens em sequência com o controle de
congestionamento como TCP. Além disso, a motivação principal por detrás do
SCTP é fornecer um protocolo mais confiável 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 sinalização SIGTRAN do IETF em 2000,
e é mantido pelo grupo de trabalho da área de transporte (TSVWG) do IETF. O
RFC 4960 define o protocolo e o RFC 3286 fornece uma introdução. Na ausência
de suporte nativo para SCTP em sistemas operacionais é possı́vel o túnel SCTP
sobre UDP, assim como o mapeamento de chamadas da API de TCP para SCTP.
HTTP sobre SCTP É uma proposta para a execução de HTTP sobre SCTP.
HTTP requer um transporte confiável para a comunicação fim-a-fim. Semelhante
ao TCP, o SCTP oferece uma conexão de transporte fim-a-fim confiável para aplicativos web, além disso, oferece outros serviços inovadores indisponı́veis no TCP,
incluindo multi-transmissão, multihoming, fiabilidade parcial e transferência de
dados orientados a mensagem [13].
Structured Stream Transport (SST) SST é um protocolo de transporte
experimental projetado para atender às necessidades de aplicativos modernos
que precisam trabalhar com muitas atividades de comunicação assı́ncrona em
paralelo, tal como baixar diferentes partes de uma página web e a reprodução de
áudio e múltiplos streams de vı́deo de forma simultânea [14].
1
O multihoming faz referência a um computador ou dispositivo (celular, tablet) conectado
a mais de uma rede.
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
7
MUX e SMUX São protocolos de gerenciamento de sessão que separam o
transporte subjacente dos protocolos de aplicação de nı́vel superior. Fornecem um
canal de comunicação leve para a camada de aplicação através da multiplexação
de fluxos de dados, sobre um transporte orientado de fluxo confiável. Ao suportar
a coexistência de múltiplos protocolos de nı́vel de aplicação (por exemplo, HTTP
e HTTP-NG), eles irão facilitar as transições para futuros protocolos web e as
comunicações de applets cliente utilizando protocolos privados com os servidores
sobre a mesma conexão TCP como a conversação HTTP [15].
2.1.2
Melhorias da Especificação do Protocolo HTTP
Keep-alive
Também chamado conexão persistente HTTP, permite ao servidor
manter a conexão TCP aberta após do envio das respostas. As sub-sequentes
requests/responses entre o mesmo cliente e servidor podem ser enviados através
da mesma conexão. Depois de um determinado perı́odo de tempo (intervalo de
tempo de espera), o servidor HTTP fecha a conexão quando não é utilizada. É
uma técnica padrão do HTTP/1.1 e existe em duas versões: 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 através da mesma conexão.
HTTP Pipelining
É uma técnica que quebra o modelo rigoroso: “enviar uma
solicitação e esperar pela resposta”, especificada em HTTP 1.0 [1], e permite
despachar múltiplos requests HTTP em paralelo para o servidor em uma única
conexão TCP, sendo utilizado com muito mais eficácia, mas com o tempo transcorrido muito menor, sem esperar pelas respostas correspondentes. Logo que os
pedidos são todos enviados, o cliente HTTP (navegador) começa a escutar para
responder. O HTTP Pipelining permite menos pacotes TCP para ser enviados
através da rede, desde que no mesmo pacote TCP é possı́vel agrupar vários requests HTTP, reduzindo a carga de rede [4]. A figura 2.1-(b) mostra o esquema do
HTTP Pipelining com múltiplos requests, em paralelo, sobre a mesma conexão.
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
Cliente
Servidor
Abrir
8
Cliente
Servidor
Abrir
tempo
Fechar
Fechar
(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 conexão HTTP entre o cliente
e o servidor é mantida aberta indefinidamente, de modo que se um evento é
recebido pelo servidor, este pode ser imediatamente enviado para um ou múltiplos
clientes, ou caso contrário, os dados teriam que ser enfileirados até que o próximo
request do cliente seja recebido. Este mecanismo pode ser implementado em
um programa CGI através do uso de tipo de MIME multipart/x-mixed-replace.
Também é conhecido como HTTP streaming e é suportado apenas pelo Netscape
Navigator (versão 1.1 ou superior) e Internet Explorer [16].
2.1.3
Tecnologias Middleware para Otimização de uso de
HTTP
Estas tecnologias requerem um software middleware com JavaScript do lado do
cliente e do servidor para a transferência de dados.
Reverse Ajax Comet [17], conhecido por outros nomes incluindo Reverse Ajax,
é um modelo de aplicação 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 é enviado para o servidor e mantido ativo por um longo
tempo, até um limite de tempo ou a ocorrência de um evento do servidor. Quando
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
9
o request é completado, outro request Ajax de longa duração é enviado para
esperar por outros eventos do servidor. A maior vantagem do Comet é que cada
cliente sempre tem um link de comunicação aberto com o servidor, no qual pode
enviar os eventos aos clientes para completar imediatamente as respostas quando
eles chegarem, ou até mesmo acumular e enviar por rajadas [18].
Bayeux É uma solução de código aberto projetado para proporcionar baixa
latência através 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 é a implementação de interações
de usuários que respondem a clientes web usando Ajax e a técnica server-push
chamada de Comet. A ideia principal é facilitar a interoperação entre as implementações para resolver a distribuição comum de mensagens e problemas de
roteamento, e fornecer mecanismos para melhorias incrementais e de extensões.
Entre suas operações globais encontramos os transportes “Streaming”, que utilizam a técnica de streaming para permitir que múltiplas mensagens sejam enviadas
dentro da mesma resposta HTTP, mas que estejam sujeitas à implementação dos
agentes de usuário e proxies que requerem respostas HTTP incompletas para ser
entregue ao cliente Bayeux [19].
BOSH Ou “Bidirectional-streams Over Synchronous HTTP”, é uma tecnologia que emula um fluxo bidirecional via HTTP entre cliente e servidor, usando
múltiplos requests/responses sı́ncronos de HTTP. BOSH consegue uma largura
de banda eficiente, para aplicativos que requerem comunicações “push” e “pull ”,
e baixa latência, sem requerimento de polling ou segmentação assı́ncrona, como
é feito na técnica conhecida como Comet [20].
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
2.2
10
Estado da arte
Os requerimentos definidos pelo IETF para o futuro protocolo HTTP incluem um
bom desempenho para os navegadores convencionais e móveis e um amplo grau
de compatibilidade com versões anteriores. O desenvolvimento das especificações
de HTTP 2.0 tem como referência as caracterı́sticas de SPDY [21]. WebSocket
e SPDY são tecnologias que incluem as caracterı́sticas principais das tecnologias
descritas na seção 2.1 como o Pipelining, reutilização da conexão aberta TCP,
multiplexação de fluxos de dados, o Server Push, etc., e seus drafts de especificações no IETF e W3C são muito ativos em termos de grupo de interesse.
Ambos são candidatos para a próxima especificação de HTTP 2.0.
2.2.1
Protocolo WebSocket
É uma tecnologia web desenvolvida como parte do padrão entrante HTML5 [22],
com suporte para comunicação bidirecional e full-duplex, ao contrário de tecnologias como BOSH ou equivalentes, que requerem apenas uma única conexão de
socket para que as mensagens sejam enviadas entre o cliente e o servidor. Servidores proxy e firewall com WebSocket são conscientes que usam o canal HTTP e
que podem operar também sobre SSL [23]. O API de WebSocket está sendo padronizado pelo W3C, e o protocolo WebSocket foi padronizado pelo IETF como
RFC 6455 [24].
2.2.2
Protocolo SPDY
SPDY [5] é um novo protocolo da camada de aplicação desenvolvido pela empresa
Google Inc. para transportar mensagens HTTP de forma mais rápida. SPDY foi
projetado para reduzir a latência e aumentar a segurança. SPDY é considerado
um substituto para o HTTP e como protocolo de pacotes (frames) tem suporte
para a codificação de dados binários e suporte nativo para TLS (SSL). SPDY
adiciona um framing layer ou camada de enquadramento para a multiplexação
de fluxos de mensagens HTTP simultâneos, através de uma única conexão TCP.
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
11
O framing layer é 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 alteração dependendo do desenvolvimento dos aplicativos
web.
A sessão SPDY permite requests simultâneos HTTP para rodar em uma única
sessão TCP/IP, e oferece quatro melhorias sobre HTTP:
• Requests multiplexados. Não existe limite para o número de requests
que podem ser emitidos simultaneamente em uma única conexão SPDY.
Como os requests são intercalados em um único canal, o protocolo é 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 não crı́ticos, quando um pedido de alta prioridade
está pendente.
• Cabeçalhos comprimidos. Os clientes atualmente enviam uma quantidade significativa de dados redundantes na forma de cabeçalhos HTTP
devido ao fato de que uma única página web pode requerer 50 ou 100 subrequests. Comprimir os cabeçalhos economiza uma quantidade significativa
de largura de banda além de reduzir a latência em relação ao HTTP, assim
SPDY comprime os cabeçalhos dos requests e responses HTTP utilizando
zlib [25], um método de compressão baseado em dicionário amplamente
utilizado [26].
• Server pushed streams. Permite aos clientes receber dados de servidores
sem precisar da requisição deles.
A especificação técnica de SPDY está dividida em duas partes: Framing Layer
e HTTP Layer. O framing layer, no último draft [5] considera seis partes: sessões,
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
12
que está associado às conexões, framing, fluxos, que entre suas caracterı́sticas considera a priorização do request, tratamento de erros, fluxo de dados e tipos de frames de controle. No HTTP Layer, o SPDY tenta preservar a semântica existente
de HTTP embora a sintaxe de transmitir essa semântica tenha mudado. Entre
essas mudanças considera-se o gerenciamento da conexão, o request/response de
HTTP e transações enviadas pelo servidor. A figura 2.2 mostra o diagrama para
conexões SPDY, baseado no tı́pico intercâmbio de pacotes TCP [27], onde vários
parâmetros de tempo são necessários para caraterizar esse intercâmbio 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
número possı́vel de pacotes, o tempo de execução 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)
Request inicial
(SYN_STREAM)
“tempo de
processamento”
Response
(SYN_REPLY,
DATA_FRAME)
segment
transmission
time
slow-start
sustained
transfer
...
Figura 2.2: Diagrama de conexões SPDY. As setas grossas indicam a transferência
de dados, enquanto as setas finas mostram os tipos de frames SPDY: PING,
SETTINGS, SYN STREAM, SYN REPLY e DATA FRAME.
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
2.3
13
Algoritmos de Escalonamento
Para o gerenciador de requests com prioridade, alguns algoritmos de escalonamento são considerados, alguns bem conhecidos de teorias de sistemas operacionais, tais como: Escalonamento Round-Robin, Escalonamento por Prioridade
e Escalonamento em Filas Multinı́vel, e também 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 é o escalonamento round-robin (ERR). A cada frame SPDY (FS) é atribuı́do um intervalo
de tempo, chamado quantum, o qual é permitido para executar. Se o FS atual
ainda está em execução no final do quantum, no escalonador SPDY (ES) ocorre
uma preempção e cede o lugar a outro FS. Se o FS foi bloqueado ou terminado
antes que tenha decorrido o quantum, um novo FS é escolhido na fila pelo escalonador. O round-robin é fácil de implementar. O escalonador tem uma fila de
frames, como é mostrado na figura 2.3-a. Quando o frame FS não termina após
um quantum, ele é colocado no final da fila, como é mostrado na figura 2.3-b.
Atual
Frame
FS1
Próximo
Frame
Atual
Frame
FS3
FS2
(a)
FS4
FS2
FS4
FS3
FS1
(b)
Figura 2.3: Escalonamento Round-Robin. (a) Fila de frames. (b) Fila de frames
quando F S1 não termina após de um quantum.
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
14
O único problema interessante com o escalonamento round-robin é a duração
do quantum.
Definir um quantum com pouco tempo provocaria muitas co-
mutações dos frames e uma baixa na eficiência do escalonador, mas defini-lo
com muito tempo pode causar uma má resposta aos requests interativos curtos
[28].
Fair Queuing
No fair queuing (FQ), os frames FS são enviados e armazenados
em filas. O algoritmo de escalonamento round-robin é usado para servir todas as
filas de uma forma justa. A principal vantagem do FQ é que os fluxos em rajadas
não afetam o desempenho global [29].
2.3.2
Escalonamento por Prioridade
O escalonamento round-robin faz a suposição implı́cita que todos os frames FS são
igualmente importantes. A necessidade de levar em conta fatores externos, leva
ao escalonamento por prioridade (EP). A ideia básica é simples: A cada frame
FS é atribuı́da uma prioridade e o FS com a maior prioridade tem permissão de
execução.
A fim de prevenir a execução indefinida dos frames FS com maior prioridade,
o escalonador ES pode diminuir a prioridade dos FS atualmente em execução
em cada ciclo de relógio (isto é, a cada interrupção do relógio). Se essa ação
atribui uma prioridade menor para deixar sem execução ao próximo FS com maior
prioridade, então um troco de FS ocorre. Alternativamente, a cada FS pode ser
atribuı́do um tempo máximo de quantum que é permitido para executar. Quando
este quantum se esgota, é dada a oportunidade de execução ao próximo FS com
prioridade mais alta.
É 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 é da seguinte maneira: enquanto existam frames FS executáveis na classe de prioridade 1, basta executar
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
15
cada um por um quantum “round-robin por turnos”, sem preocupar-se pelas classes de menor prioridade, se a classe de prioridade 1 está vazia então executamos
os frames FS da classe round-robin 2. Se as classes 1 e 2 são ambas vazias, em
seguida, executamos a classe round-robin 3, e assim por diante. Se as prioridades
não são ajustadas ocasionalmente, todas as classes de menor prioridade podem
morrer por inanição [28].
Prioridade máxima
FS1
FS2
FS3
FS8
FS4
FS7
FS5
FS8
FS6
FS9
FS3
FS5
FS4
FS1
Despachador
Escalonador
FS2
FS6
FS7
FS9
Prioridade mínima
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 várias filas separadas, como na figura 2.5. Os frames FS são permanentemente atribuı́dos
a uma fila, geralmente baseados em alguma propriedade do FS, seja pela prioridade ou pelo tipo de frame. Cada fila tem seu próprio algoritmo de escalonamento. 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, também
pode ser atribuı́do um intervalo de tempo entre as filas. Assim, cada fila recebe
certa porção de tempo, o qual pode então, escalonar entre seus múltiplos frames
FS [30].
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
16
Prioridade Alta
Tempo
Real
FS9
FS7
FS3
FS1
preemptado
Sistema
FS
FS
FS
FS
FS0
preemptado
Interativo
FS
FS
FS
FS
preemptado
Lote
FS
FS
Prioridade baixa
FS
FS
preemptado
Figura 2.5: Escalonamento em Filas Multinı́vel.
2.3.4
Weighted Fair Queuing
O weighted fair queuing (WFQ), é uma técnica 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 combinação dos algoritmos de escalonamento por prioridade
e fair queuing. Tal como no método FQ, todas as filas são servidas de maneira
que não existe qualquer inanição de largura de banda, mas algumas filas têm
mais peso no sentido que elas recebem mais serviço. Em outras palavras, o peso
é dado a cada fila para atribuir diferentes prioridades às filas. Os frames são
armazenados na fila apropriada de acordo com sua classificação.
A figura 2.6 mostra um exemplo do algoritmo WFQ. Os tempos finais são
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].
CAPÍTULO 2. REVISÃO BIBLIOGRÁFICA
17
Fila 1 (50%)
FS1
FS2
FS3
Ordem da transmissão de frames
Fila 2 (25%)
FS4
FS5
FS6
FS8
FS9
Escalonador
FS9
FS7
FS8
FS5
FS6
FS4
FS2
FS3
FS1
Fila 3 (25%)
FS7
Figura 2.6: Weighted Fair Queuing.
2.3.5
Weighted Round-Robin
O Weighted Round-Robin (WRR) é um algoritmo de escalonamento onde o buffer é dividido em k filas que representam os fluxos ativos, o algoritmo percorre
cada fila e um fator de ponderação determina quantos bytes de dados do sistema
entrega de cada fila antes de passar para a próxima fila. Um peso é associado a
cada fila proporcionalmente à taxa de bits requerida da fila e, a maneira como as
filas são servidas é através de uma disciplina Round-Robin de acordo com o peso:
cada fila é servido proporcionalmente a seu próprio peso [31].
Alta
Filas
FS1
FS2
FS3
FS1
FS4
FS7
FS5
FS8
FS6
FS2
FS5
P=4
FS6
FS8
P=3
Despachador
FS9
Escalonador
FS9
FS4
P=2
FS7
FS3
P=1
Baixa
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 tráfego de alta prioridade. Ao utilizar este escalonamento, as filas
de baixa prioridade têm a oportunidade de transmitir frames FS, embora as filas
de alta prioridade não estejam vazias.
Capı́tulo 3
Metodologia
Fluxos e Prioridades em SPDY Apesar de que as caracterı́sticas atuais do
protocolo HTTP restringem seu ótimo desempenho como o envio de um único
request por conexão, cabeçalhos HTTP redundantes, etc., SPDY retém a compatibilidade e mantém a estrutura básica de HTTP, tal como a semântica dos requests
e response, ao contrário de WebSocket que requer uma reprogramação no processo
de encapsulamento de HTTP [24]. Além disso, oferece a multiplexação 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 é representado por
um número inteiro de 0 a 7, sendo 0 a maior prioridade e 7 a menor prioridade
[5].
3.1
Padrões de projeto para transmissão de dados de tipo sı́ncrono e assı́ncrono
Para a implementação do escalonamento de fluxo e a concorrência em um servidor
SPDY, serão considerados padrões 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 padrões Reactor e Proactor. Comparado aos
mecanismos sı́ncronos, os mecanismos assı́ncronos são atrativos porque oferecem
o benefı́cio da concorrência enquanto aliviam muito a sobrecarga e a complexidade
do multi-threading [32].
18
CAPÍTULO 3. METODOLOGIA
19
Padrão de projeto Reactor O Reactor é um padrão que simplifica o trabalho aos aplicativos orientados a eventos através da integração da demultiplexação
sı́ncrona de eventos e o despacho de seus gerenciadores de eventos correspondentes. O padrão Reactor está constituı́do pelos seguintes participantes: Handles,
que identificam os recursos que são gerenciados por um sistema operacional; O
demultiplexador sı́ncrono de eventos, que bloqueia os recursos esperando pela
ocorrência de eventos em um conjunto de Handles; A iniciação do despachador,
que define uma interface para o registro, remoção e envio dos gerenciadores de
eventos; Os gerenciadores de eventos, que especificam uma interface usada pela
iniciação do despachador chamando de volta aos métodos hook 1 pré-registrados
para processar certos tipos de eventos e finalmente o gerenciador de eventos concretos, que implementa os métodos hook que processam eventos em uma forma
especı́fica da aplicação [33]. A figura 3.1 mostra um diagrama de interação para
o padrão Reactor.
Callback:
Programa Gerenciador de
principal eventos concretos
Initializa
Registrar o
gerenciador
:Reactor
Reactor()
registrar_gerenciador(callback)
Obter o
gerenciador
obter_gerenciador()
Executar no
mesmo laço
gerenciar_eventos()
Esperar por
eventos
Despachar
gerenciador(es)
:Handles
select()
gerenciar_evento(tipo_evento)
Figura 3.1: Diagrama de interação para o padrão Reactor.
1
Os Métodos hook são definidos em interfaces ou classes abstratas e devem necessariamente
ser implementados por uma aplicação.
CAPÍTULO 3. METODOLOGIA
20
Padrão de projeto Proactor O Proactor é um padrão usado para descrever
como iniciar, receber, demultiplexar, despachar e processar eventos. Seu principal objetivo é melhorar o desempenho de um aplicativo orientado a eventos
que recebe e processa múltiplos eventos de forma assı́ncrona. O padrão Proactor é desenvolvido da seguinte forma: quando um evento chega, a entidade do
aplicativo, referido a um iniciador, começa uma operação assı́ncrona apropriada,
em seguida, o Proactor registra o evento com um gerenciador e despachador de
eventos associados ao processador de operações assı́ncronas, logo após, o iniciador
invoca a operação assı́ncrona registrada no processador de operações assı́ncronas.
Uma operação assı́ncrona é executada sem bloquear o thread de controle do gerenciamento de eventos, assim, ele pode realizar outras operações. Uma vez
que a operação é concluı́da, o processador de operações assı́ncronas recupera informações do gerenciador e despachador de eventos correspondentes, e gera um
evento de conclusão contendo os resultados da operação assı́ncrona, logo após, demultiplexa e despacha o evento para o gerenciador de eventos associado à operação
assı́ncrona. Posteriormente, o gerenciador de eventos processa os resultados da
operação assı́ncrona e chama novamente a aplicação [32].
O padrão Proactor oferece os seguintes benefı́cios: maior portabilidade da
lógica da aplicação, encapsulamento do mecanismo de concorrência pelo despachador de conclusão, uma polı́tica de threading desacoplada da polı́tica de concorrência, maior separação de interesses, e maior desempenho e simplificação da
sincronização de aplicativos. No entanto, ele também tem os seguintes inconvenientes: o escalonamento e controle de operações pendentes e a dificuldade de
depuração [34]. A figura 3.2 mostra um diagrama de interação para o padrão
Proactor.
CAPÍTULO 3. METODOLOGIA
Iniciador do
Proactor
Operação
assíncrona iniciada
21
Processador
da Operação
Assíncrona
Operação
Assíncrona
Despachador
de conclusão
Gerenciador
de conclusão
registrar(operação, gerenciador, despachador)
executar()
Operação realizada
assincronamente
despachar()
Operação concluída
gerenciar_evento()
Gerenciador de
conclusão notificado
Figura 3.2: Diagrama de interação para o padrão Proactor.
Em resumo, tanto o Reactor quanto o Proactor são padrões de projeto focados
nos aplicativos orientados a eventos e que compartilham principalmente as funções
de registro, demultiplexação e gerenciamento de múltiplos eventos.
I6
I5
I4
I3
I2
I1
Fila
(a)
I3
I2
I1
Fila 0
I1
Fila 1
I2
I1
Fila 2
I4
I3
I2
I1
Fila 3
I1
Fila 4
I3
I2
I1
Fila 5
I2
I1
Fila 6
I1
Fila 7
(b)
Figura 3.3: Registro de Eventos (a) Reactor. (b) Proactor.
A figura 3.3 mostra o registro de eventos em ambos padrões, é utilizada uma
fila como estrutura de dados de armazenamento dos eventos para a implementação
do mecanismo sı́ncrono do padrão Reactor. A diferença do Proactor é que utiliza
oito filas chamadas filas de prioridade para implementar o mecanismo assı́ncrono.
Além disso, tanto o Reactor quanto o Proactor também compartilham a
mesma estrutura do algoritmo 1 de gerenciamento de eventos, mas a diferença
deles está na função de demultiplexação dos eventos onde, no Reactor é realizado
através do desenfileiramento do evento pronto na única fila utilizada enquanto
no Proactor é realizado por meio de uma dinâmica de desenfileiramento que será
descrita no capı́tulo 4, ambos gerenciam o evento obtido com a mesma lógica para
responder à requisição envolvida no evento.Como se pode deduzir, o Proactor é
CAPÍTULO 3. METODOLOGIA
22
Algorithm 1 Algoritmo de Gerenciamento de Eventos
1: procedure Handle Events
2:
loop
3:
while queue.size > 0 do
4:
queueItem = Dequeue()
. Demultiplexing Events
5:
response = HandleEvent(queueItem)
6:
Send response
7:
end while
8:
end loop
9: end procedure
uma versão 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 avaliação dos resultados
A avaliação se baseou na comparação do desempenho entre as diferentes estratégias de gestão de fluxo SPDY, testadas durante a execução do escalonador.
Assim, tendo em conta os parâmetros de tempo do diagrama de SPDY na figura 2.2, vamos considerar como parte da avaliação o tempo de processamento
nas filas de prioridade do escalonador baseado nos algoritmos de padrões de projeto Reactor e Proactor do servidor SPDY.
Os modelos de tráfego adotados para os testes da rede, estarão baseados no
tráfego gerado por um grupo de outstations ou estações exteriores DNP3 [7], enviando dados de potência de uma planta de produção de energia, mas adicionando
diferentes prioridades para cada estação DNP3 e incorporando sua atualização
de dados no fluxo SDPY.
Cliente SPDY
Internet
Servidor SPDY
Rede
Figura 3.4: Esquema do projeto.
A técnica básica para o esquema do poll de atualização, utilizado no DNP3,
CAPÍTULO 3. METODOLOGIA
23
permite que o servidor interaja com o cliente retornando imediatamente uma
resposta aos requests periódicos de atualização, ou seja, quando ocorrem as alterações dos dados, enquanto que o cliente mantenha a subscrição. Esta abordagem é descrita na especificação, mas não é comum em aplicativos reais devido
ao fato de que não otimiza o procedimento de notificação de alteração de dados
para o cliente. A figura 3.5 mostra a abordagem básica do poll de atualização.
Request de
Atualização
Cliente SPDY
Servidor SPDY
Response do
Servidor
Cliente SPDY
Servidor SPDY
Figura 3.5: Abordagem básica do poll de atualização.
Capı́tulo 4
Desenvolvimento de um
protótipo de servidor SDPY
O desenvolvimento do protótipo de servidor SPDY abrangeu os dois primeiros
objetivos especı́ficos indicados na seção 1.2. O projeto foi desenvolvido na linguagem de programação Python e com o uso de bibliotecas externas que dão suporte
ao protocolo SSL, utilizando OpenSSL que adiciona a extensão “Next Protocol
Negotiation” (NPN) [35] para negociar o uso de SPDY sobre uma conexão segura, e também para sockets assı́ncronos, adaptando a biblioteca “asyncore”1
para complementar ao correto funcionamento do escalonador SDPY.
A pesquisa da especificação do protocolo SPDY e, o estudo dos dois padrões
de projeto e dos cinco algoritmos de escalonamento selecionados, descritos no
capı́tulo 3, permitiram atingir o primeiro objetivo especı́fico indicado na seção
1.2.
Para o desenvolvimento do protótipo de servidor SPDY, a estrutura do request/response SPDY está baseada na especificação do draft SPDY [5] versão
três, versão atual suportada por navegadores e servidores que utilizam esta tecnologia, e a estrutura do escalonador, nesta primeira versão do protótipo, está
baseada no padrão de projeto Proactor. A figura 4.1 mostra uma visão geral das
etapas desenvolvidas na primeira versão do servidor SPDY.
1
A biblioteca “asyncore” fornece uma infraestrutura básica para desenvolver o gerenciamento
de sockets assı́ncronos, http://docs.python.org/3/library/asyncore.html.
24
CAPÍTULO 4. DESENVOLVIMENTO DE UM PROTÓTIPO DE SERVIDOR SDPY25
<< loop >>
Servidor SPDY
Escalonador - Proactor
Criar o Proactor
como base para
o escalonador de
SPDY
Envolver o
frame SPDY
e a prioridade
em um evento
Enfileirar o
evento acordo à
prioridade
atribuida
<< request SPDY>>
Despachar o
novo frame
SPDY obtido de
gerenciar o
evento
desenfileirado
<< response SPDY>>
Cliente SPDY
Figura 4.1: Visão geral das etapas desenvolvidas no projeto.
Funcionamento do escalonador SPDY A execução do servidor SPDY contempla inicialmente a criação da instância do Proactor. Criada a instância, dois
métodos serão executados: O registro do gerenciador de eventos, que é preciso
para a análise 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 gerenciador de eventos.
O processo no escalonador SPDY, baseado em Proactor, compreende três
etapas para atingir o gerenciamento de requests SPDY: O envolvimento do frame
SPDY recebido e sua prioridade atribuı́da em um evento, respeitando a concepção
do Proactor descrita na subseção 3.1; o enfileiramento do evento e por último, o
despacho do frame SPDY resultante do gerenciamento do evento desenfileirado.
Enfileiramento do evento O enfileiramento do evento está baseado na prioridade atribuı́da ao frame SPDY, como item de uma das oito filas de prioridade
criadas segundo a especificação de SPDY [5]. A figura 4.2 mostra o diagrama de
interação para o enfileiramento de eventos no escalonador SPDY.
CAPÍTULO 4. DESENVOLVIMENTO DE UM PROTÓTIPO DE SERVIDOR SDPY26
: Servidor
SPDY
Enfileiramento
iniciado
: QueueItem :PriorityQueue :Queue
: Proactor
Enqueue(handleID, event, priority)
setHandle(handleID)
Estabelecer
parâmetros nos
items da fila
setEvent(event)
Enqueue(queueItem, priority)
Procurar a fila
baseado na
prioridade
FindPriorityQueue(priority)
Enqueue(queueItem)
Enfileirar o
evento
Figura 4.2: Diagrama de interação 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 dinâmica de desenfileiramento utilizada nas oito filas de prioridade do
escalonador SDPY, onde para desenfileirar um evento é necessário cumprir com
a sequência de prioridade desde a fila de prioridade mais alta até a mais baixa.
Portanto, começa a desenfileirar o evento pronto a partir da fila de mais alta
prioridade. Se essa fila estiver vazia, continua-se com a próxima fila de menor
prioridade e assim por diante.
<< loop >>
Alta
prioridade
Fila 0
I3
I2
I1
Fila 1
I2
I1
Fila 2
I4
I3
I2
I1
Fila 3
I1
Fila 4
Baixa
prioridade
I3
I2
I1
Fila 5
I2
I1
Fila 6
I1
Fila 7
Figura 4.3: Dinâmica do desenfileiramento de eventos.
Com o evento desenfileirado, procedemos a tratar seu pedido com a análise
do frame SPDY envolvido. Essa análise compreende principalmente conhecer
qual é o tipo de frame SPDY para poder atender o requerimento. Assim, de
CAPÍTULO 4. DESENVOLVIMENTO DE UM PROTÓTIPO DE SERVIDOR SDPY27
acordo à especificação do protocolo SPDY, geramos um novo frame SPDY com
a informação solicitada. A figura 4.4 mostra o diagrama de interação para o
despacho de eventos no escalonador SPDY.
:Proactor
Desenfileiramento
iniciado
:PriorityQueue
:Queue
: QueueItem
:HTTP
Handler
Dequeue()
FindQueueItem()
Procurar o item
pronto e
desenfileirar
da fila
Dequeue()
queueItem
queueItem
GetEvent()
Obter os
parâmetros do
item
Gerenciar o
evento a
despachar
event
GetHandle()
handleID
HandleEvent(event)
Figura 4.4: Diagrama de interação para o despacho de eventos.
Gerenciamento assı́ncrono de sockets
O “asyncore” é uma biblioteca que
trabalha com sockets gerenciados de forma assı́ncrona, seu desenho é baseado em
eventos e é utilizada para desenvolver servidores de rede com requests concorrentes. Estas caraterı́sticas ajudam muito ao desenvolvimento do escalonador SPDY,
mas essa biblioteca não tem suporte para sockets envolvidos em SSL, e além disso,
cada socket entrante é tratado na ordem de chegada e fechado imediatamente,
não podendo se adequar a um esquema de gerenciamento com prioridade. Devido
a esses inconvenientes na biblioteca, foi adicionado um patch de suporte para sockets envolvidos em SSL e foram implementados métodos para o gerenciamento
de erros e fechamento dos sockets.
Capı́tulo 5
Resultados
A fim de abranger a avaliação do tempo de processamento nas filas de prioridade
do escalonador SPDY, foi definido um ambiente de teste usando quatro máquinas
clientes e um servidor para transmitir requests com diferentes prioridades entre 0
e 7. O servidor e as máquinas clientes possuem as seguintes caracterı́sticas:
Servidor
Máquina 1
Máquina 2
Máquina 3
Máquina 4
Intel
Intel
Intel
Intel
Intel
Core
Core
Core
Core
Core
i5
i5
i5
i5
i5
Processador
3333M, 4 Núcleos
2430M, 4 Núcleos
3333M, 4 Núcleos
3333M, 4 Núcleos
3333M, 4 Núcleos
de
de
de
de
de
3.2
2.4
3.2
3.2
3.2
GHz
GHz
GHz
GHz
GHz
RAM
4 GB
4 GB
4 GB
4 GB
4 GB
Sistema Operacional
Ubuntu 12.04, 32 bits
Ubuntu 12.04, 64 bits
Ubuntu 12.04, 32 bits
Ubuntu 12.04, 64 bits
Ubuntu 12.04, 64 bits
Tabela 5.1: Caracterı́sticas do servidor e das máquinas 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 Três dos quatro arquivos de teste contêm tempos de interarrival de três 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 medições ao longo de uma
semana de funcionamento da planta, além disso, a cada tempo de inter-arrival foi
atribuı́do um valor de prioridade selecionado aleatoriamente das maiores prioridades que estão entre 0 e 2. Os dados destes arquivos têm o objetivo de simular uma
28
CAPÍTULO 5. RESULTADOS
29
situação real de monitoramento enviando requests simultâneos por cada cliente.
Os tempos de inter-arrival do quarto arquivo ou arquivo de tráfego de fundo,
foram criados utilizando uma função de distribuição normal1 com média de 0.039
segundos e desvio padrão de 1.0 em um intervalo de tempo total de 90 horas.
Além 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 está entre 3 e 7. Os dados deste último arquivo têm 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.
A
2
0
1
0
2
.
.
.
F
4000
6000
8000
4000
262000
0
0
2
1
0
.
.
.
J
8000
78000
2000
26000
2000
2
1
1
0
1
.
.
.
Tráfego de Fundo
8000
22000
18000
4000
18000
7
4
6
6
3
.
.
.
614.094
109.847
1168.76
1083.66
703.774
Figura 5.1: Estrutura dos arquivos de Teste A, F, J e Tráfego de Fundo com o
valor da prioridade na primeira coluna e o tempo de inter-arrival na segunda.
Descrição do Teste Após da execução 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 tráfego principal com
prioridades entre 0 e 2 ou um tráfego de fundo com prioridades entre 3 e 7 por
request. O código 5.1 mostra a função que é utilizada para gerar o conteúdo da
response SPDY, esta função contêm três parâmetros e se o primeiro parâmetro,
que é boolean, é verdadeiro, então lê o conteúdo de um arquivo com sintaxe HTML
e JavaScript de geração do formulário que permite anexar arquivos.
1
A função normrnd de Matlab gera números aleatórios a partir de uma função de distribuição
normal, http://www.mathworks.com/help/stats/normrnd.html.
CAPÍTULO 5. RESULTADOS
30
def g e t r e s p p r o c t i m e h t m l ( self , f i l e t e s t , t e s t a t t , p r e v t i m e ) :
try :
resp = ’ ’
if not f i l e t e s t :
r e s p = ’<form i d =\’myform \ ’ method=post> ’ \
’<t a b l e b o r d e r =\ ’0\ ’ > ’ \
’<t r ><th>Timer :</ th> <td><i n p u t type =\’ t e x t \ ’ ’ \
’ i d =\’ t i m e r \ ’ v a l u e= ’+t e s t a t t [ 0 ] + ’></td></t r > ’
\
’<t r ><th>P r e v i o u s Time:</ th> <td><i n p u t type= ’ \
’ \ ’ t e x t \ ’ i d =\’ p r e v t i m e \ ’ v a l u e= ’+p r e v t i m e+ ’> ’
\
’</td></t r > ’ \
’<i n p u t type =\’ hidden \ ’ i d =\’ c u r t i m e \ ’ v a l u e= ’+
\
t e s t a t t [ 0 ] + ’> ’ \
’<i n p u t type =\’ hidden \ ’ i d =\’nrow \ ’ v a l u e= ’+ \
t e s t a t t [ 1 ] + ’> ’ \
’<i n p u t type =\’ hidden \ ’ i d =\’ p r i o r i t y \ ’ v a l u e= ’+
\
t e s t a t t [ 2 ] + ’> ’ \
’</ t a b l e > ’ \
’</form> ’
else :
f = open ( ’www/ p r o c t i m e a j a x . html ’ , ’ rb ’ )
r e s p = f . r e a d ( ) . decode ( ’UTF−8 ’ )
f . close ()
return r e s p . encode ( ’ u t f −8 ’ )
except IOError a s e :
raise E x c e p t i o n ( ’ h t t p h a n d l e r − g e t r e s p p r o c t i m e h t m l : ’ \
’ I /O e r r o r ( { 0 } ) : {1} ’ . format ( e . e r r n o , e . s t r e r r o r ) )
except E x c e p t i o n a s e r r :
raise E x c e p t i o n ( ’ h t t p h a n d l e r − g e t r e s p p r o c t i m e h t m l : ’ , \
err )
Código 5.1: Geração do conteúdo da response SPDY.
As linhas dos arquivos de teste enviados pelos clientes no próximo grupo
de requests são armazenados em uma estrutura de dados do servidor a fim de
que possa gerenciar os novos requests até o final do teste. A response SPDY
para cada request contem texto com sintaxe HTML que inclui três parâmetros
preenchidos com o tempo que tem que esperar o cliente SPDY para enviar o
próximo request, a prioridade que vai ter esse request e o ı́ndice do próximo
elemento da estrutura de dados que o servidor tem que obter para atender o
CAPÍTULO 5. RESULTADOS
31
request enviado. Assim, no código 5.1, se o primeiro parâmetro é falso, então
geramos a sintaxe HTML de um formulário com campos que são preenchidos com
os valores dos outros parâmetros da função. A figura 5.2 mostra a representação
dos últimos procedimentos anteriormente descritos.
Cliente
Cliente
Cliente
Máquina 1
Máquina 4
Máquina
F
A
Cliente
Cliente
Máquina 3
Tráfego de
Fundo
J
Prioridade,
Índice
Tempo,
Prioridade,
Índice
Máquina 2
Servidor SPDY
Estrutura de
dados
Servidor SPDY
(a)
(b)
Figura 5.2: (a) Armazenamento na estrutura de dados. (b) Gerenciamento dos
novos requests.
A medição do tempo total de processamento2 nas filas de prioridade do escalonador SPDY abrange as funções principais de desenfileiramento e gerenciamento
dos requests. Com a obtenção dos dados de tempo, número de IP do cliente,
prioridade e número de request no escalonador SPDY foram realizados dois experimentos preliminares, o registro em um arquivo de resultados dos tempos de
processamento nas filas de prioridade e a geração de um gráfico3 de Tempo de
inter-arrival vs. Número de Requests.
2
A biblioteca “cProfile” de Python mede o tempo total de execução de uma porção de código,
http://docs.python.org/3.3/library/profile.html.
3
A biblioteca “‘matplotlib” de Python realiza o plotting 2D e 3D de dados, http://
matplotlib.org/.
CAPÍTULO 5. RESULTADOS
5.1
32
Testes I: Análise do comportamento dos tempos de processamento nas oito filas de prioridade
Para atingir a análise do comportamento dos tempos de processamento nas filas de
prioridade, foram realizados distintos experimentos gerando gráficos de Tempo de
processamento vs. Número de Requests. As figuras abaixo mostram os resultados
dos testes que foram executados no servidor SDPY em um tempo total médio de
20 minutos.
Testes 1 e 2 Os testes 1 e 2 foram executados utilizando um dos clientes
SPDY para transmitir o tráfego de fundo e os outros clientes o tráfego principal
dos arquivos A, F e J. O esquema de realização destes testes está representado
na figura 5.3.
Cliente
Cliente
Máquina 1
Máquina 4
A
F
Cliente
Cliente
Máquina 3
Tráfego de
Fundo
J
Máquina 2
Servidor SPDY
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
alcança um número de requests de 517 e um tempo de processamento máximo de
0.0367 ms.
A figura 5.5 mostra que o Teste 2 realizado em um tempo total de 20 minutos
alcança um número de requests de 508 e um tempo de processamento máximo de
0.0392 ms.
CAPÍTULO 5. RESULTADOS
33
Figura 5.4: Plotting 2D do teste 1 utilizando um cliente SPDY para transmitir o
tráfego de fundo.
Figura 5.5: Plotting 2D do teste 2 utilizando um cliente SPDY para transmitir o
tráfego 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 tráfego de fundo e os outros
clientes o tráfego principal dos arquivos A, F e J. O esquema de realização destes
testes está representado na figura 5.6.
CAPÍTULO 5. RESULTADOS
34
Cliente
Cliente
Máquina 4
Tráfego de
Fundo
Máquina 1
A
Cliente
Cliente
Máquina 3
J
F
Máquina 2
Servidor SPDY
Figura 5.6: Esquema dos testes 3 e 4.
Figura 5.7: Plotting 2D do teste 3 utilizando outro cliente SPDY para transmitir
o tráfego de fundo.
A figura 5.7 mostra que o Teste 3 realizado em um tempo total de 20 minutos
alcança um número de requests de 457 e um tempo de processamento máximo de
0.035 ms.
A figura 5.8 mostra que o Teste 4 realizado em um tempo total de 35 minutos com 46 segundos alcança um número de requests de 774 e um tempo de
processamento máximo 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 tráfego de fundo e os
outros clientes o tráfego principal dos arquivos A, F e J. O esquema de realização
CAPÍTULO 5. RESULTADOS
35
Figura 5.8: Plotting 2D do teste 4 utilizando outro cliente SPDY para transmitir
o tráfego de fundo.
destes testes está representado na figura 5.9.
Cliente
Cliente
Máquina 4
Tráfego de
Fundo
J
Cliente
Cliente
Máquina 3
Máquina 1
A
F
Máquina 2
Servidor SPDY
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 alcança um número de requests de 461 e um tempo de processamento máximo de 0.039 ms.
CAPÍTULO 5. RESULTADOS
36
Figura 5.10: Plotting 2D do teste 5 utilizando outro cliente SPDY para transmitir
o tráfego de fundo.
Figura 5.11: Plotting 2D do teste 6 utilizando outro cliente SPDY para transmitir
o tráfego de fundo.
A figura 5.11 mostra que o Teste 6 realizado em um tempo total de 20 minutos
alcança um número de requests de 436 e um tempo de processamento máximo de
0.04 ms.
CAPÍTULO 5. RESULTADOS
5.2
37
Testes II: Análise e comparação do comportamento dos tempos de processamento em
uma fila sem prioridade e nas oito filas de
prioridade
Para ter uma melhor visualização do comportamento dos tempos de processamento 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
gráficos em 3D considerando novamente o tempo de processamento e o número de
request adicionando como terceiro parâmetro a prioridade ou o número de cliente
de acordo com a análise.
Nas figuras abaixo serão mostradas dois tipos de análise com o objetivo de
fazer a comparação visual entre elas, a primeira considera a proposta deste trabalho com a adição das oito filas de prioridade no gerenciamento dos requests no
escalonador SPDY com gráficos de Tempo de Processamento vs. Número de requests vs. Prioridade. A segunda considera somente uma fila de armazenamento
dos requests atribuindo para cada um deles a mesma prioridade com gráficos de
Tempo de Processamento vs. Número de requests vs. Cliente.
Teste 7 As figuras 5.12, 5.13, 5.14 mostram os gráficos do experimento que
utilizou os três arquivos de tempos reais de teste A, F, J e o arquivo de tráfego de
fundo. Como resultado se pode observar que nos 20 minutos de execução do teste
os 126 requests com prioridades entre 0 e 2 são processados em um tempo médio
de 0.0012 ms e os 378 requests com prioridades entre 3 e 7 são processados em
um tempo médio de 0.0019 ms alcançando um tempo de processamento máximo
no teste de 0.025 ms.
CAPÍTULO 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.
CAPÍTULO 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 gráficos do experimento que
utilizou quatro arquivos de teste que contêm os mesmos dados de tempo do
arquivo de tráfego do fundo, atribuindo aleatoriamente para três deles as maiores
prioridades entre 0 e 2. O objetivo deste experimento é a execução simultânea
com tempos curtos de envio entre requests para alcançar o mais alto nı́vel de
stress no servidor. Como resultado se pode observar que nos 20 minutos de
execução do teste os 1062 requests com prioridades entre 0 e 2 são processados
em um tempo médio de 0.002408 ms e os 380 requests com prioridades entre 3 e
7 são processados em um tempo médio de 0.002416 ms alcançando um tempo de
processamento máximo no teste de 0.063 ms. Além disso, se pode observar que
com esta grande quantidade de transmissão de dados são gerenciados com maior
prioridade aqueles requests com prioridades entre 0 e 2.
CAPÍTULO 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.
CAPÍTULO 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 gráficos do experimento que
utilizou novamente nos quatro arquivos de teste os dados de tempo do arquivo de
tráfego de fundo com a diferença que se atribuı́ram a todos os tempos a mesma
prioridade com valor 0. O objetivo deste experimento é observar o comportamento
dos tempos de processamento em um contexto sı́ncrono de gerenciamento de
requests e de fazer uma comparação com a proposta das oito filas de prioridade
no escalonador SPDY. Como resultado se pode observar que nos 20 minutos
de execução do teste os 1550 requests são processados em um tempo médio de
0.00246 ms alcançando um tempo de processamento máximo de 0.06 ms.
CAPÍTULO 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.
CAPÍTULO 5. RESULTADOS
43
Figura 5.20: Vista 3: Plotting 3D do teste 9 utilizando uma fila de prioridade.
5.3
Testes III: Análise e comparação do comportamento dos tempos de processamento
nas oito filas com prioridade e quantum de
tempo
Tomando em consideração a caracterı́stica principal do algoritmo de escalonamento Round-Robin, o quantum descrito nas subseções 2.3.1 e 2.3.2, foi atribuı́do
a cada fila de prioridade um tempo máximo de execução ou quantum com a
finalidade que os requests armazenados nas filas com menor prioridade sejam
processados com maior frequência e assim se possa controlar mais a inanição.
Empiricamente foi atribuı́do um quantum a cada fila de prioridade com valores
entre 0.8 a 0.1 segundos nessa ordem, assim à dinâmica de desenfileiramento,
descrita no capı́tulo 4, foi adicionada um novo controle de tempo de execução
para cada fila de prioridade. Assim, se esse tempo de execução fosse maior ao
quantum atribuı́do, então deixa de gerenciar os demais requests da fila atual
que está atingindo para continuar com os requests da próxima fila de menor
CAPÍTULO 5. RESULTADOS
44
prioridade, e assim por diante com cada fila de prioridade. A figura 5.21 mostra
a nova dinâmica de desenfileiramento para o teste utilizando um quantum de
tempo para cada fila de prioridade.
<< loop >>
Alta
prioridade
Baixa
prioridade
...
Fila 0
I3
I2
I1
Fila 1
I2
I1
Fila 2
q= 0.8 sec
q= 0.7 sec
q= 0.6 sec
I1
Fila 7
q= 0.1 sec
Figura 5.21: Nova dinâmica de desenfileiramento para o teste.
As figuras abaixo mostram os gráficos de dois experimentos realizados com
quatro arquivos de teste que contêm os mesmos dados de tempo que do arquivo de
tráfego de fundo onde dois deles têm atribuı́dos aleatoriamente para cada tempo
as maiores prioridades entre 0 e 2 e os outros dois têm atribuı́dos aleatoriamente
prioridades entre 3 e 7, com o objetivo de realizar uma comparação entre estes
experimentos.
Teste 10 As figuras 5.22, 5.23 mostram os gráficos do experimento realizado
com o mesmo gerenciamento sobre as oito filas de prioridade descritos no primeiro
experimento da seção 5.2 em um tempo total de 20 minutos, onde o escalonador SDPY alcança gerenciar 759 requests nas filas de maior prioridade com um
tempo médio de processamento de 0.002304 ms, 480 requests nas filas de menor
prioridade com um tempo médio de processamento de 0.002388 ms e um máximo
tempo de processamento entre os requests de 0.064 ms.
CAPÍTULO 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.
CAPÍTULO 5. RESULTADOS
46
Teste 11 As figuras 5.24, 5.25 mostram os gráficos do experimento realizado
com o quantum de tempo para cada fila de prioridade, descrito nesta seção, em
um tempo total de 20 minutos, onde o escalonador SDPY alcança gerenciar 740
requests nas filas de maior prioridade com um tempo médio de processamento de
0.002836 ms, 541 requests nas filas de menor prioridade com um tempo médio de
processamento de 0.002945 ms e um máximo 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 utilização 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 cada
fila de prioridade.
CAPÍTULO 5. RESULTADOS
47
Figura 5.25: Vista 2: Plotting 3D do teste 11 utilizando um quantum para cada
fila de prioridade.
Em resumo as tabelas 5.2 e 5.3 contêm os resultados dos testes descritos nas
seções 5.2 e 5.3:
Teste 7
Teste 8
Prioridades
0-2
3-7
0-2
3-7
Teste 9
N. Requests
126
378
1062
380
1550
Tempo Médio de Proc.
0.0012 ms
0.0019 ms
0.002408 ms
0.002416 ms
0.00246 ms
Tempo Max. de Proc.
0.025 ms
0.063 ms
0.06 ms
Tabela 5.2: Resultados dos Testes 7, 8 e 9.
Teste 10
Teste 11
Prioridades
0-2
3-7
0-2
3-7
N. Requests
759
480
740
541
Tempo Médio de Proc.
0.002304 ms
0.002388 ms
0.002836 ms
0.002945 ms
Tempo Max. de Proc.
Tabela 5.3: Resultados dos Testes 10 e 11.
0.064 ms
0.084 ms
Capı́tulo 6
Conclusões
O Proactor, como padrão projetado para aplicativos orientados a evento que
recebem e processam múltiplos eventos de forma assı́ncrona, se adéqua às caracterı́sticas requeridas no escalonador SPDY permitindo a concorrência e ótimo
gerenciamento dos requests transmitidos pelos clientes SDPY.
A inclusão de oito filas de prioridade no escalonador SPDY ajuda a alcançar no
Proactor o conceito de mecanismo assı́ncrono, além de que obedece à priorização
dos requests como uma das melhorias de SPDY sobre HTTP. Os testes baseados,
em grande parte nesta funcionalidade do escalonador SPDY e descritos na seção
5.2, demonstram que os requests com maior prioridade são processados na média
em menor tempo além de que são gerenciados em maior quantidade, ao contrário
dos requests com menor prioridade que são gerenciados em menor quantidade
alcançando tempos de processamento máximos em alguns requests e na média
maior tempo de processamento.
A atribuição de um quantum, como caracterı́stica principal do algoritmo de
escalonamento Round-Robin, ou tempo de execução para cada fila de prioridade,
descrito na seção 5.3, melhorou o gerenciamento dos requests armazenados em
todas as filas de prioridade, prevenindo a execução indefinida dos requests com
maior prioridade e aumentando a quantidade de requests gerenciados com menor
prioridade.
Este trabalho demonstrou que se alcançamos simular uma situação real com
o envio de dados gerados por dispositivos industriais de uma planta de energia,
48
CAPÍTULO 6. CONCLUSÕES
49
tomando em consideração o ótimo funcionamento do escalonador SDPY, então
os aplicativos de monitoramento poderiam adotar as caracterı́sticas do protocolo
SPDY para melhorar o desempenho atual da técnica de atualização de dados
descrita na seção 3.2.
Referências Bibliográficas
[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. Leach, 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-andpipelining, 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
http://www.opcfoundation.org/, July 2003.
50
XML-DA
Specification.
REFERÊNCIAS BIBLIOGRÁFICAS
[9] OPC
Foundation.
51
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 Magazine, 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.
met.
Reverse Ajax,
Part 1:
Introduction to Co-
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:
http://xmpp.org/about-xmpp/technology-overview/bosh.
BOSH.
REFERÊNCIAS BIBLIOGRÁFICAS
[21] IETF.
Hypertext
52
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 Transactions 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. IEEE/ACM Trans. Netw., 15(2):450–461, Apr. 2007.
REFERÊNCIAS BIBLIOGRÁFICAS
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 HighPerformance 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 Extension. draft-agl-tls-nextprotoneg-03, April 2012.