3. Resultater: inkluderte studier
3.3 Effekt av musikk og musikkterapi med spedbarn på sykehus
As cargas nos servidores não foram consideradas nos experimentos simulados. Em um ambiente real, o balanceamento de carga é um aspecto que não pode ser ignorado, uma vez que ele está diretamente relacionado ao desempenho dos servidores.
5.4. Detalhes de Implementação 71
algoritmo de busca foi modificado. O resolvedor, ao consultar o RTT de um servidor, também lê sua carga. O valor de carga de um nó é obtido por meio do comando Linux uptime. Esse comando mostra a média de carga do sistema no decorrer do último minuto. A média de carga do sistema é a o número médio de processos que estão no estado “executando” ou “não-interrompível”. Um processo no estado “executando” está utilizando a CPU ou aguardando para utilizá-la. Um processo no estado “não-interrompível” está esperando por um acesso de entrada/saída (GREENFIELD; JOHNSON,1993a). Tipicamente, para uma máquina com uma CPU, esse valor varia entre 0 e 1. Nos experimentos, todos os nós possuem 1 núcleo.
No processo de busca, o algoritmo mantém uma lista dos servidores selecionados em cada iteração. Ao terminar a busca, essa lista contém os servidores e seus respectivos RTTs e valores de carga, ordenados por RTT. Então, o algoritmo, de forma iterativa, procura pelo servidor mais próximo tal qual a carga não ultrapasse um limiar estabelecido como uma variável do ambiente. Se nenhum servidor satisfaz essa restrição, um elemento da lista é selecionado de forma aleatória.
Portanto, nenhum servidor sobrecarregado será selecionado para atender à requisição de um cliente, aumentando a capacidade do servidor de atender clientes e oferecer uma melhor qualidade de serviço. Isso é verdade a não ser que todos os servidores estejam sobrecarregados. Esse cenário ocorre quando o sistema como um todo não é capaz de atender à demanda dos clientes. Nessa situação, novos servidores devem ser adicionados ao sistema.
5.4
Detalhes de Implementação
Preza-se pela transparência do sistema aos clientes. Portanto, foram feitas o mínimo de modificações no lado do cliente. O cliente executa uma distribuição Linux Ubuntu e invoca os serviços por meio da linha de comando. A única mudança necessária é a adição do endereço IP do resolvedor GALA no arquivo “/etc/resolv/conf”, o que fará com que as perguntas de nome de domínio sejam enviadas ao resolvedor anycast. Para buscar nomes anycast, basta adicionar “.any” no final de um nome de domínio.
O resolvedor consiste de um daemon, implementado utilizando C++, que recebe pacotes de consulta DNS de acordo com o RFC 1035 (P. Mockapetris, 1987), identifica nomes de domínio, repassa resoluções que não são nomes anycast e responde perguntas com formato anycast. É importante ressaltar que o processo de busca é centralizado no resolvedor, para manter a transparência no cliente. Por esse motivo, cada cliente possui um resolvedor correspondente em sua região. Assim, o processo de busca terá o resultado muito próximo de uma busca realizada no próprio cliente.
O publicador é um nó executando o software BIND. BIND é uma implementação dos protocolos de sistema de domínio BIND (Internet Systems Consortium,2014).
72 Capítulo 5. Protótipo do Sistema
O servidor oferece páginas HTML como serviço. Ele executa o software Nginx (Nginx,
2014). Para os experimentos, uma única página HTML foi utilizada. O servidor também executa um daemon GALA, implementado em C++, o qual é responsável por registrar o servidor no DNS, atualizar e podar a vizinhança e responder à consultas dos resolvedores. Toda comunicação entre servidores e resolvedores é feita por meio de UDP.
5.5
Detalhes do Ambiente
Para implantar o sistema de anycast, o serviço de nuvem DigitalOcean1 foi utilizado. Esse serviço oferece servidores privados virtuais (VPS) ao seus clientes. Todos os VPS utilizados possuem 512MB de RAM, 1 núcleo, 20GB SSD de disco rígido e executam o sistema operacional Ubuntu 14.04 LTS.
Foram lançados 21 nós em 5 regiões geográficas distintas. São elas Nova Iorque, São Francisco, Londres, Amsterdã e Singapura. Cada região possui dois servidores, um cliente e um resolvedor. Adicionalmente, um nó DNS foi implantado em Nova Iorque.
Tabela 9 – Mapeamento dos servidores
Endereço IP Mapeamento Geográfico Mapeamento Estático X,Y 178.62.***.*** Rússia Grã Bretanha 3,5 178.62.***.*** Rússia Grã Bretanha 3,5 178.62.***.*** Rússia Grã Bretanha 3,5 178.62.***.*** Rússia Grã Bretanha 3,5 104.131.***.*** X Estados Unidos 2,5 104.131.***.*** X Estados Unidos 2,5 104.131.***.*** X Estados Unidos 2,5 104.131.***.*** X Estados Unidos 2,5 107.170.***.*** X Estados Unidos 2,5 107.170.***.*** X Estados Unidos 2,5 162.243.***.*** X Estados Unidos 2,5 104.131.***.*** X Estados Unidos 2,5 178.62.***.*** Rússia Holanda 4,5 178.62.***.*** Rússia Holanda 4,5 178.62.***.*** Rússia Holanda 4,5 178.62.***.*** Rússia Holanda 4,5 128.199.***.*** Grã Bretanha Singapura 6,4 128.199.***.*** Grã Bretanha Singapura 6,4 128.199.***.*** Grã Bretanha Singapura 6,4 128.199.***.*** Grã Bretanha Singapura 6,4
Na Tabela9, os resultados de mapeamento estão expostos, considerando os nós implan- tados. Foram utilizadas 64 regiões geográficas e o banco de dados de geolocalização MaxMind de 2013. Pelo fato do banco de dados não fornecer resultados corretos para os endereços IP
5.6. Avaliação de Desempenho 73
utilizados, eles foram mapeados de forma estática. A primeira coluna indica o endereço IP de um servidor do sistema. A segunda coluna corresponde ao mapeamento do banco de dados MaxMind. “X” significa que não havia um intervalo de endereços IP que o endereço em questão se encaixava. A terceira coluna mostra o mapeamento correto, utilizado pelo sistema. A quarta coluna indica qual o nome de domínio que o endereço correspondente foi mapeado pelo sistema.
5.6
Avaliação de Desempenho
Para validar o sistema implantado, experimentos foram feitos utilizando o ambiente descrito a seguir. Na Tabela10, os fatores e níveis considerados estão expostos. O fator requisi- ções por cliente representa o número de requisições por cliente a cada segundo. O tempo total do experimento é de um minuto. O fator de consciência de carga é utilizado para analisar o desempenho do sistema considerando a métrica de carga ou ignorando-a.
Adicionalmente, duas variáveis de resposta foram analisadas: os tempos de busca e serviço. O tempo de busca é o tempo entre o cliente realizar a pergunta anycast e o resolvedor GALA encontrar um servidor adequado para atender à requisição do cliente. O tempo de serviço envolve a invocação do serviço no servidor. Considerando os passos mostrados na Figura40, o tempo de busca compreende os quatro primeiros passos, enquanto que o tempo de serviço compreende os dois últimos.
Para coletar essas variáveis de resposta, nos clientes, há um script que chama a ferra- menta dig (CONSORTIUM,2000). Depois, com o resultado obtido, o comando wget (NIKSIC,
1996) é invocado. Para ambos comandos, o programa de medidas de tempo do sistema, time (MACKENZIE,19XX), é utilizado.
Tabela 10 – Configurações de experimento.
Fator Níveis
Algoritmo GAA, GALA Consciência de Carga Sim, Não Requisições por Cliente (por segundo) 30, 50
Na Tabela11, os parâmetros de ambiente para os experimentos estão expostos. Em cada região geográfica, há um cliente, dois servidores e um resolvedor GALA. Também, há um único servidor DNS em Nova Iorque. Os outros parâmetros são variáveis do sistema e são as mesmas utilizadas nas simulações. Adicionalmente, as execuções do experimento foram replicadas 6 vezes, uma vez que esse número de replicações foi suficiente para obter resultados satisfatórios.
Na Figura41, os resultados para o experimento real estão ilustrados. O eixo x representa as combinações de fatores do experimento e o eixo y representa as médias dos tempos de serviço e busca em milissegundos.
74 Capítulo 5. Protótipo do Sistema
Tabela 11 – Parâmetros do experimento.
Parâmetro Valor Clientes 5 Servidores 10 Resolvedores 5 Servidores DNS 1 Nós por anel (k) 8 Nós secundários (l) 2 Anéis (R) 11 a 10 b 0.5 s 2 Regiões geográficas 64 Replicações 6
Figura 41 – Resultados para os tempos de busca e serviço, adaptada deAdami et al.(2015b).
Para os tempos de busca, é possível notar que a busca do algoritmo GALA é mais rápida que o algoritmo GAA. Esse comportamento condiz com o observado nas simulações. Como afirmado anteriormente, GALA converge mais rápido para um servidor adequado, uma vez que ele começa sua busca em um servidor próximo do cliente. Adicionalmente, os tempos de busca aumentaram com o aumento de carga, como esperado. Ainda, a consciência de carga não afetou a busca de forma significativa.
5.7. Considerações Finais 75
tarefas em menos tempo, se comparado com o GAA. Isso ocorre porque o sistema demora mais para selecionar servidores no segundo algoritmo, fazendo com que as requisições acumulem e os servidores fiquem mais carregados executando mais trabalho concorrentemente. Também, é importante notar que o aumento da carga também aumentou os tempos de serviço, um com- portamento esperado. Considerando a consciência de carga, sua presença teve uma influência negativa para a carga menor. Por outro lado, para a carga maior, ela teve um influencia positiva. O resultado negativo é explicado pelo fato de que a sobrecarga causada pela leitura de carga do sistema é maior que o ganho com a consciência da carga para esse caso. Em um trabalho futuro, é possível tornar o sistema adaptável e escolher utilizar a carga de forma automática em casos onde isso seja vantajoso.
5.7
Considerações Finais
Os resultados apresentados nesta Seção foram coletados por meio da execução de experimentos em um sistema real, descrito em detalhes, e gráficos foram criados por meio do softwareMinitab. Os resultados mostraram que o algoritmo GALA obteve melhores resultados que o algoritmo GAA, assim como observado anteriormente nas simulações. Esses resultados fortalecem a afirmação de que o sistema GALA supera o sistema GAA como um sistema de anycastna camada de aplicação.
77
CAPÍTULO
6
PUBLICAÇÕES
6.1
Considerações Iniciais
Com os resultados obtidos deste trabalho de mestrado, artigos foram produzidos, sub- metidos e publicados. Eles podem ser divididos em duas categorias: artigos que descrevem os resultados das simulações e artigos que descrevem os resultados das execuções do ambiente real.
6.2
Trabalhos Publicados
Com os resultados obtidos por meio de simulação, foram publicados dois artigos. Ambos são destacados a seguir:
Adami, J. L.; Estrella, C. J.; de Oliveira, M. E.; Reiff-Marganiec S.; Providing Quality of Ser- vice on Services Selection using Anycast Techniques. In: 11th IEEE International Conference on Services Computing, 2014, DOI: 10.1109/SCC.2014.46, Qualis B1.
Adami, J. L.; Estrella, C. J.; Libardi, R.; Reiff-Marganiec S.; Quality of Service on Services Selection using Anycast Techniques: a Convergence Analysis. In: 14th IFIP/IEEE Sympo- sium on Integrated Network and Service Management, 2015, DOI: 10.1109/INM.2015.7140381, Qualis A2.
6.3
Trabalhos Submetidos
Com os resultados obtidos com a implantação do sistema real, foi submetido um novo artigo para a Revista PLOS One.
78 Capítulo 6. Publicações
Adami, J. L.; Estrella, C. J.; Libardi, R.; de Oliveira, M. E.; Reiff-Marganiec S.; GALA: An Application Anycast System for Distributed Environments. In: PLOS One Journal, 2015, submetido, Qualis A1.
Essa revista é uma mídia internacional que é meio de publicação para tópicos multidisci- plinares, incluindo a área de redes de computadores.
6.4
Considerações Finais
Ao todo, foram submetidos três artigos. Dois deles descrevem as simulações realizadas enquanto que o terceiro descreve os resultados obtidos do ambiente real. Os dois primeiros foram publicados enquanto que o terceiro artigo está em fase de análise.
79
CAPÍTULO
7
CONCLUSÕES
7.1
Considerações Iniciais
As etapas do projeto de pesquisa foram desenvolvidas e o cronograma previsto foi respeitado, seguindo conforme o planejado inicialmente. As próximas seções descrevem os resultados finais obtidos e as contribuições deste trabalho.
7.2
Conclusões
O experimentos realizados no Capítulo4tiveram como objetivo mostrar os ganhos do algoritmo GALA, se comparado com seu antecessor, GAA. Nas simulações, foram analisados os tempos de busca, número de saltos e eficiência da seleção. Ainda, foi analisado como a granularidade das regiões geográficas afetam o desempenho do sistema. Também, foi mostrado a convergência do algoritmo GALA comparando-o com o algoritmo GAA.
Uma vez que as simulações indicavam um ganho no algoritmo anycast, o sistema real foi implantado e os experimentos do Capítulo5foram realizados para estudar o comportamento do sistema de anycast na camada de aplicação, fortalecendo a validação do sistema modelado e simulado. Adicionalmente, foram discutidos aspectos não observados na simulação do sistema de anycast na camada de aplicação, como a influência da carga nos nós.
Analisando os resultados apresentados no Capítulo4e5, pode-se concluir que o algoritmo GALA obteve um desempenho geral melhor que o algoritmo GAA. A geolocalização diminuiu o número de passos para encontrar o melhor servidor e, consequentemente, diminuiu o tempo das requisições. Além disso, outro fato que contribuiu para a diminuição da latência das requisições é o algoritmo GALA sempre iniciar sua busca em uma região próxima do cliente, ondes os RTTs das requisições são pequenos. No algoritmo GAA, isso pode não ocorrer. Há a possibilidade do nó inicial estar muito distante do cliente. Nesse caso, a consulta em um servidor distante resulta
80 Capítulo 7. Conclusões
em tempos elevados. Ainda, os resultados mostraram eficiências menores quando aplicado o algoritmo GALA, em comparação ao GAA. Porém, deve-se levar em consideração que a entrada é o principal fator que influencia nessa variável de resposta e os valores obtidos não foram tão menores assim. Portanto, é possível afirmar que o algoritmo proposto avaliado traz um ganho significativo ao sistema.
Concluindo, a principal contribuição científica deste trabalho é a proposta, modelagem, simulação e implantação de um sistema anycast na camada de aplicação. Ainda, incluem a análise de sua acurácia, velocidade de seleção de servidores e convergência. Finalmente, soma-se a validação dos resultados simulados, mostrando o ganho em relação ao sistema existente.
7.3
Trabalhos Futuros
Vale a pena ressaltar que, com o desenvolvimento deste trabalho, novas oportunidades de pesquisa foram criadas e estão descritas na listagem abaixo. Adicionalmente, um trabalho derivado deste projeto já está sendo desenvolvido: uma ferramenta web que auxilia na elaboração de experimentos simulados. Sua interface permite visualizar os resultados em forma de gráficos e tabelas. Assim, a configuração e execução de experimentos se torna mais fácil, rápida e flexível. Esse trabalho está sendo desenvolvido pelo aluno de iniciação científica Henrique Pizzol Grando, cujo processo FAPESP é 2014/11080-8.
• A geolocalização utilizada não foi acurada o suficiente a fim de fornecer bons resultados à seleção de servidores. Novas formas de geolocalização e mapeamento dos nós podem ser exploradas, aumentando a confiabilidade do sistema.
• O sistema real implantado limitou-se a uma quantidade pequena de máquinas e regiões geográficas. Muitos cenários ainda podem ser explorados em ambientes maiores.
• Considera-se a adição de novas métricas ao sistema, como classes de cliente. Este item inclui a adição automática de métricas conforme características específicas do ambiente.
• Todos os experimentos realizados foram feitos de forma manual. Uma automação desse processo é possível e interessante de ser explorada, assim como foi feito para os experi- mentos simulados em um trabalho de iniciação científica.
7.4
Etapas Cumpridas
A seguir, as principais atividades previstas para o programa de mestrado são descritas. Na Tabela12, a organização desses itens durante o tempo está ilustrada e os itens devidamente destacados.
7.4. Etapas Cumpridas 81
Tabela 12 – Organização das atividades realizadas.
Fases
Período (por bimestres)
2013 2014 2015 2 3 4 5 6 1 2 3 4 5 6 1 2 3 1 X X X X X 2 X 3 X X X X X X X X X X 4 X X X X X 5 X X X X X X X X X 6 X X X X X X X X X 7 X X X 8 X X X X X X
1. Cumprimento de créditos referente às disciplinas do mestrado: Para realizar a defesa da dissertação foi necessário cumprir um total de 48 créditos durante os dois semestres de 2013;
2. Preparação para o exame de proficiência em inglês: Essa etapa compreende o período de preparação para obter o certificado de proficiência em língua inglesa;
3. Análise crítica dos trabalhos relacionados: As atividades iniciais foram focadas na análise crítica dos trabalhos relacionados à arquiteturas que utilizam anycast na camada de aplicação, planejamento de experimentos e avaliação de desempenho. A continuidade da análise bibliográfica foi de suma importância durante todo o período de trabalho, de maneira que se agreguem novas metodologias ao projeto de pesquisa;
4. Preparação para o exame de qualificação: Essa fase inclui a preparação para o exame de qualificação que deve foi realizado no início do primeiro semestre de 2014;
5. Desenvolvimento da proposta: Essa fase envolveu o desenvolvimento de todos os com- ponentes do sistema. Decisões de projeto mais específicas foram tomadas nessa etapa. Essas decisões envolvem desde questões de linguagem até a estrutura da comunicação entre os servidores na rede;
6. Elaboração de artigos científicos: Preparação de artigos que promovam a divulgação dos resultados alcançados e a apresentação das contribuições científicas;
7. BEPE: Permanência do candidato em um estágio de pesquisa no exterior (BEPE) com período de 4 meses e meio;
8. Redação da dissertação: Fase da escrita da dissertação de mestrado, que deve ser entregue para defesa até o final de agosto de 2015.
82 Capítulo 7. Conclusões
7.5
Considerações Finais
Este Capítulo apresentou o cronograma e as etapas desenvolvidas do trabalho. Todo o projeto seguiu o cronograma calculado e este foi executado com êxito. Adicionalmente, as conclusões, principais contribuições e trabalhos futuros foram apresentados.
83
REFERÊNCIAS
ADAMI, L. J.; ESTRELLA, J. C.; LIBARDI, R. M. de O.; REIFF-MARGANIEC, S. Quality of Service on Services Selection using Anycast Techniques: a Convergence Analysis. In: IEEE IM, 2015. 14th IFIP/IEEE Symposium on Integrated Network and Service Management. [S.l.: s.n.], 2015. Citado 5 vezes nas páginas11,12,38,64e65.
ADAMI, L. J.; ESTRELLA, J. C.; OLIVEIRA, E. M. de; REIFF-MARGANIEC, S. Providing Quality of Service on Services Selection using Anycast Techniques. In: IEEE SCC, 2014. 11th IEEE International Conference on Services Computing. [S.l.: s.n.], 2014. Citado 8 vezes nas páginas11,12,51,55,56,57,58e60.
ADAMI, L. J.; ESTRELLA, J. C.; OLIVEIRA, E. M. de; REIFF-MARGANIEC, S.; LIBARDI, R. M. de O.; OLIVEIRA, E. M. de. GALA: An Application Anycast System for Distributed Environments. In: PLOS One. [S.l.: s.n.], 2015b. Citado 9 vezes nas páginas11,12,34,52,53,
54,63,70e74.
BHATTACHARJEE, S.; AMMAR, M.; ZEGURA, E.; SHAH, V.; FEI, Z. Application-layer anycasting. In: INFOCOM ’97. Sixteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Driving the Information Revolution., Proceedings IEEE. [S.l.: s.n.], 1997. v. 3, p. 1388–1396. Citado na página17.
CHELLOUCHE, S.; NEGRU, D.; BORCOCI, E.; LEBARS, E. Anycast-based context-aware server selection strategy for VoD services. In: GLOBECOM Workshops (GC Wkshps), 2010 IEEE. [S.l.: s.n.], 2010. p. 1513–1517. Citado na página17.
. Context-aware distributed multimedia provisioning based on anycast model towards Future Media Internet. In: Consumer Communications and Networking Conference (CCNC), 2011 IEEE. [S.l.: s.n.], 2011. p. 880–885. Citado 3 vezes nas páginas11,19e20.
CHEN, Y.; XIONG, Y.; SHI, X.; ZHU, J.; DENG, B.; LI, X. Pharos: accurate and decentralised network coordinate system. Communications, IET, v. 3, n. 4, p. 539–548, 2009. Citado na página27.
CIA. CIA World Factbook. 2013. Https://www.cia.gov/library/publications/the-world- factbook/. Acessado em 08/08/2013. Citado na página38.
CONSORTIUM, I. S. Linux User’s Manual - dig. 2000. Citado na página73.
Donald E. Eastlake 3rd. Secure Domain Name System Dynamic Update. 1997. RFC 2137. Citado na página40.
ESTRELLA, J. C.; SANTANA, R. H. C.; SANTANA, M. J. WSARCH: An Architecture for Web Services Provisioning with QoS Support - Performance Challenges. [S.l.]: Saarbrücken : VDM Verlag Dr. Müller GmbH & Co, 2011. Http://www.amazon.com/WSARCH-Architecture- Provisioning-Performance-Challenges/dp/3639378245. Citado 2 vezes nas páginas23e24.
84 Referências
FEI, Z.; BHATTACHARJEE, S.; ZEGURA, E.; AMMAR, M. A novel server selection technique for improving the response time of a replicated service. In: INFOCOM ’98. Seventeenth An- nual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE. [S.l.: s.n.], 1998. v. 2, p. 783–791. Citado na página17.
FREEDMAN, M. J.; LAKSHMINARAYANAN, K.; MAZIèRES, D. OASIS: anycast for any service. In: Proceedings of the 3rd conference on Networked Systems Design & Implemen- tation - Volume 3. Berkeley, CA, USA: USENIX Association, 2006. (NSDI’06), p. 10–10. Citado 3 vezes nas páginas11,26e36.
GREENFIELD, L.; JOHNSON, M. K. Linux uptime command. 1993. Linux manual. Citado na página71.
. Linux User’s Manual - uptime. 1993. Citado na página23.
HUFFAKER, B.; FOMENKOV, M.; CLAFFY, K. Geocompare: a comparison of public and commercial geolocation databases. May 2011. Citado 2 vezes nas páginas36e50.
Internet Systems Consortium. BIND. 2014. Accessed in 11/12/2014. Citado na página71. ISO 3166. ISO 3166 Codes (Countries). 2013. "http://www.iso.org/iso/country_codes/iso_ 3166_code_lists/country_names_and_code_elements.htm". Acessado em 08/08/2013. Citado 2 vezes nas páginas37e38.
JIN, C. Z. M. An anycast routing algorithm based on genetic algorithm. In: WSEAS TRAN- SACTIONS on COMPUTERS. [S.l.: s.n.], 2009. Citado na página24.
JONES, B. The World. 1998. "http://cse.ssl.berkeley.edu/segwayed/lessons/search_
ice_snow/ski.2b1BigMap.html". Acessado em 02/10/2013. Citado 2 vezes nas páginas11e40. LATIF L; MYKONIATI, E. L. R. C. R. G. D. R. M. Multi recipient anycast routing. In: Univer- sity College London. [S.l.: s.n.], 2008. Citado na página25.
MA, Z.-Y.; ZHOU, J.; ZHANG, L. A Scalable Framework for Global Application Anycast. In: Information and Computing Science, 2009. ICIC ’09. Second International Conference on. [S.l.: s.n.], 2009. v. 1, p. 250–253. Citado 7 vezes nas páginas11,19,28,29,30,44e50. MACKENZIE, D. Linux User’s Manual - time. 19XX. Citado na página73.
Marc Wick. GeoNames. 2013. Http://download.geonames.org/export/dump/. Acessado em 13/11/2013. Citado na página51.
Minitab Inc. Software for Statistics, Process Improvement, Six Sigma, Quality - Minitab. 2013. "http://www.minitab.com". Acessado em 06/12/2013. Citado 2 vezes nas páginas47e69. MYKONIATI, E.; LATIF, L.; LANDA, R.; YANG, B.; CLEGG, R.; GRIFFIN, D.; RIO, M. Distributed overlay anycast tables using space filling curves. In: INFOCOM Workshops 2009, IEEE. [S.l.: s.n.], 2009. p. 1–6. Citado 5 vezes nas páginas11,18,27,28e39.
Nginx. Nginx Website. 2014. Accessed in 11/12/2014. Citado na página72. NIKSIC, H. Linux User’s Manual - wget. 1996. Citado na página73.
P. Mockapetris. Domain Names - Implementation and Specification. 1987. RFC 1035. Citado