Serviços Web HTTP

Prévia do material em texto

Serviços de Rede em Sistemas Windows e Linux
Aula 08: Serviços Web – HTTP
Apresentação
Você seria capaz de imaginar o atual cenário operacional sem as inúmeras vantagens e os diversos benefícios do uso dos
aplicativos Web? Hoje somos capazes de resolver quase todas as nossas necessidades cotidianas pelo acesso à internet
e aos sistemas disponíveis na Web. Nesta aula, trataremos do princípio dos serviços Web, os chamados HTTP Servers.
Objetivos
Explicar o serviço Web HTTP e sua relação com o Serviço de Nome de Domínio – DNS;
Aplicar a instalação e con�guração do serviço em sistema operacional Windows e do sistema operacional Linux;
Descrever o princípio do Proxy Reverso e o Serviço HTTP.
Você sabe o que é Web?
Provavelmente, quando você pensou em Web, deve ter-se lembrado de sites comerciais, divulgação de marcas etc. Mas vamos
entender primeiro como surgiu a Web.
 Fonte: pixabay
Surgimento da Web
A Web (World Wide Web) nasceu por volta dos anos de 1989. Foi desenvolvida pela Organização Europeia para Pesquisa
Nuclear, com objetivo de melhorar ou facilitar a comunicação de pesquisadores nucleares, o que trouxe grande repercussão,
considerando o baixo custo e a facilidade de uso.
Por volta de 1993, houve um grande salto para o uso desse
serviço, quando a National Center for Supercomputing
Applications (NCSA) lançou e distribuiu o Mosaic. Para
época, um avanço e uma interessante forma de ver o novo
mundo pela Web.
Veja, a seguir, a ilustração do Mosaic:
 Figura 1. Fonte: History Computer.
O que é serviço Web?
Para muitos, o serviço WWW ou Web é a parte multimídia da internet. Até o momento de sua popularização, textos eram
comuns, porém o apelo visual de imagens veio com a popularização desse serviço, o que mudou a perspectiva sobre a internet.
Observando os aspectos operacionais, o serviço Web é formado por um conjunto de servidores, dispostos em domínios e
subdomínios organizacionais, que proveem o serviço Web.
Comentário
javascript:void(0);
Como estamos falando de domínio e subdomínio, vale lembrar que essa estrutura é ordenada e controlada pelo Serviço de
Nomes de Domínios – DNS. Considere a integração desses serviços como parte importante para o funcionamento do WWW.
Dessa forma, o funcionamento do protocolo HTTP está fundamentado no conceito cliente servidor, em que o cliente faz a
requisição e o servidor responde a esta requisição, conforme exempli�cado abaixo:
 Figura 2. Fonte: NTU.
Você pode se questionar: Como o protocolo trata as requisições e como se estabelece o serviço?
O protocolo é stateless, ou seja, cada solicitação é tratada de forma individual. Não há registro do status das requisições
anteriores.
Comentário
O protocolo funciona como se fosse bate e volta; ou seja, perguntou, você responde e encerra-se. Caso precise de nova
informação, você responderá à próxima pergunta.
O HTTP também faz abstração o que nos dá a possibilidade de criarmos aplicações independentemente dos dados que serão
usados para transmissão com o cliente.
Por �m, para termos uma visão mais ampla do protocolo, podemos dizer que o HTTP é um protocolo sem estado de conexão
(stateless), genérico e extremamente �exível, portanto, usado para diversas �nalidades.
Por essas razões, o protocolo é bastante utilizado no desenvolvimento de diversos sistemas.
Exemplo
javascript:void(0);
É possível desenvolver:
Uma página, na qual será transmitida texto, imagem, áudio e vídeos;
Sistemas mais complexos comerciais desenvolvidos em linguagens como PHP, Python, Java e outros.
Atenção
Lembre-se de que a integração dessas linguagens ao serviço HTTP ocorre por meio da instalação dos webservers responsáveis
pela interpretação ou criação de ambiente para cada uma das linguagens.
Assim, caso você queira desenvolver sistemas em PHP, você deverá instalar um servidor HTTP e o container PHP para
possibilitar a integração. Essa mesma visão deverá ser seguida para as demais linguagens.
 Mas qual o servidor Web devemos usar?
 Clique no botão acima.
Con�ra, a seguir, um grá�co extraído do NetCraft em que são apresentados os sistemas mais usados:
Como foi possível observar, dentre os servidores mais utilizados, estão o Apache, o Nginx e o IIS da Microsoft. Para
nossa aula, ressaltamos que:
Não abordaremos a integração do servidor Web com container de linguagem, trataremos aqui das con�gurações
fundamentais do serviço;
Usaremos o Internet Information Services (IIS) da Microsoft e o Nginx no Linux para con�guração.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Como con�gurar no sistema Windows?
Agora vamos entender as con�gurações do Servidor Web no ambiente Windows. Para a instalação do IIS, você deve seguir o
mesmo padrão já adotado em outras aulas.
 Con�gurações do Servidor Web no ambiente Windows
 Clique no botão acima.
Abra o Server Manager. Em seguida, clique em Add roles and features. Observe as telas abaixo:
Na próxima tela, clique em próximo (Next) para seguir adiante na instalação:
Selecione o tipo de instalação. Como faremos a instalação de uma função no próprio servidor, usaremos a opção
sugerida Role-based or feature-based installation.
Em seguida, manteremos o servidor onde será instalado. Deve aparecer o hostname de sua máquina, conforme
demonstrado nas seguintes imagens:
Agora chegou o momento de selecionar o pacote, como demonstrado nesta imagem:
Será apresentada uma tela com o resumo da seleção e, em seguida, uma tela de questionamento de possíveis funções
que você deseje instalar. Em ambos os casos, clique em próximo e prossiga com a instalação. Veja os exemplos:
Na sequência, faça a seleção das funções do servidor IIS que deseje instalar. Nessa seleção, considere os aspectos
funcionais do servidor como registros de logs, segurança, redirecionamentos e a�ns. Observe o modelo abaixo:
Agora, sim, con�rmaremos a instalação do serviço. Nessa etapa, você deve clicar em Install. Será apresentada uma
tela de progressão da instalação. Depois de concluída, basta fechar o console de instalação e testar se tudo foi feito
corretamente, pelo acesso via browser. Veja as telas:
Comentário
Agora, sim, con�rmaremos a instalação do serviço. Nessa etapa, você deve clicar em Install. Será apresentada uma
tela de progressão da instalação. Depois de concluída, basta fechar o console de instalação e testar se tudo foi feito
corretamente, pelo acesso via browser. Veja as telas:
Vamos colocar o site no ar?
Para isso, clique na opção Sites e, na sequência, siga as con�gurações. Veja abaixo.
Para iniciar, escolha um nome para o site.
Observe que o teste foi feito com uma solicitação via endereço IP no browser. Você pode se perguntar:
Será que quem realizou o teste estava com preguiça de escrever o nome e preferiu colocar o IP para facilitar?
Lembre-se de que sempre é o Serviço de Nome de Domínio que faz a tradução de nome para IP. Sendo assim, não é de
responsabilidade do IIS ou de qualquer outro Servidor Web tratar desse aspecto.
Em seguida, de�na um local de armazenamento para o site. Podemos fazer isso por diretório local ou local remoto. No
exemplo a seguir, é demonstrado como con�gurar um diretório local. Caso o local de armazenamento seja remoto,
clique em Connect para de�nir as informações do local de armazenamento.
Agora de�na o protocolo que será usado. Podemos de�nir o HTTP ou HTTPS. Será necessário ainda con�gurar o
endereço pelo qual você deseja que seu serviço seja respondido. Caso você tenha mais de uma interface de redes e
deseja ou necessita de�nir um endereço de acesso, descreva-o nesse momento e caso tenha apenas uma interface,
você poderá usar o padrão All Unassigned.
Na opção port, de�na a porta que será usada para conexão do seu site.
Dica
De�na um nome que seja representativo para todos que venham a gerenciar o ambiente em sua organização, isso ajudará
bastante no dia a dia.
Atenção
Um ponto importante aqui é conhecer as de�nições de portas e serviços contidos no site da IANA (https://www.iana.org/).
Assim, você nãocorrerá o risco de usar uma porta estabelecida e provavelmente usada por outro serviço, o que causará con�itos
e indisponibilidade de serviços. Lembre-se de que você poderá usar qualquer porta, desde que respeite esses princípios. Em caso
de sites distintos, usamos portas distintas para diferenciá-los e darmos acessos adequados aos mesmos.
javascript:void(0);
Para �nalizar, de�na um Host Name, de forma opcional e clique em ok. O resultado será o apresentado abaixo:
Observe que foram criados, o siteteste e um Application Pools correspondente ao site criado.
Como con�gurar no sistema Linux?
Feita a con�guração no Windows, partiremos para a con�guração no sistema Linux. Usaremos o Nginx Server como servidor
Web para o sistema operacional Linux.
O Nginx é multiplataforma, então, o que veremos aqui poderá ser usado no Windows, ou seja, é mais um serviço que poderá ser
aproveitado em um ambiente híbrido.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
 Con�gurações do Servidor Web no Sistema Web
 Clique no botão acima.
Após a instalação, devemos acessar o arquivo base de con�guração, localizado no caminho absoluto
/etc/nginx/nginx.conf. Dessa forma, use o seu editor preferido para editar o arquivo em questão.
O próximo passo abrange as diretivas universais para sistema, determinando a forma como o tráfego da web HTTP
será tratado. A primeira parte do bloco de HTTP é mostrado a seguir:
Ainda há o parâmetro ssl_protocols; que cria compatibilidade aos formatos criptográ�cos ssl TLS versão 1, 1.1, 1.2,
inibindo o formato SLLv3 por este não ser su�cientemente maduro, o que o torna inseguro.
Existem também os controles de Logs que são tratados com os parâmetros access_log e error_log.
user www-data;
worker_processes 4;
pid /run/nginx.pid;
events {
worker_connections 768;
# multi_accept on;
}
1
2
3
4
5
http {
##
# Basic Settings##
send�le on ;
tcp_nopush on ;
tcp_nodelay on ;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off ;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off ;
include /etc/nginx/mime.types ;
default_type application/octet-stream ;
##
# Logging Settings##
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
6
7
8
9
10
11
12
13
14
15
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
https://estacio.webaula.com.br/cursos/go0191/aula8.html
Por padrão os arquivos, serão salvaguardados em /var/log/nginx nos em arquivos que correspondem aos nomes dos
parâmetros (access.log e error.log) e são de muita importância para a gestão do servidor e aos processos de auditoria.
Ainda podemos con�gurar as opções de acesso e tratativa de arquivos compactados como gzip. Isso pode ser feito
pelo parâmetro gzip_disable "msie6" e, como no exemplo, está desabilitando a compatibilidade com o Internet
Explorer 6 para evitar problemas.
A estrutura gzip ajuda ao servidor a limitar a quantidade de largura de banda utilizada e acelerar algumas
transferências e as con�gurações podem ser feitas no arquivo /etc/nginx/nginx.conf. Vamos entender o contexto da
con�guração com o exemplo abaixo:
O gzip_vary fará com que seja habilitado ou desabilitado o armazenamento de recursos compactados e
descompactados quando um cliente não possui suporte ao uso desses recursos e o proxy público envia,
apresentando-o ao cliente. Já o parâmetro gzip_proxied habilitará ou desabilitará o uso da compactação em respostas
a solicitações feitas por proxy, sendo a solicitação via proxy identi�cada pelo VIA no cabeçalho de solicitação. Dessa
forma, podemos de�nir o gzip_proxied da seguinte forma:
off: Desativa a compactação para as solicitações de proxy;
expired: Habilita a compactação caso o proxy inclua um valor para desativar o armazenamento em cache;
no-cache: Ativa a compactação se houver, no cabeçalho de resposta, o campo cache-control associado ao no-
cache;
no-store: Se comporta da mesma forma que o no-cache, porém o cache-control deve estar associado ao no-
store;
private: Segue o mesmo princípio dos anteriores, porém é necessário que o cache-control esteja associado ao
private;
no-etag: Caso o cabeçalho de resposta não possua o campo ETag, a compactação será ativada;
auth: Caso exista o campo Authorization no cabeçalho de respostas, a compactação será ativada;
any: Para toda e qualquer solicitação de proxy, será habilitada a compactação.
No exemplo demonstrado, colocamos o any para justamente compactar todas as requisições originárias de um proxy.
O bloco de HTTP do arquivo nginx.conf contém uma declaração de inclusão feita com o parâmetro include (include
/etc/nginx/sites-enabled/*;), permitindo que con�gurações sejam carregadas a partir de arquivos separados, conforme
os especi�cados no subdiretório sites-enabled. Esses arquivos normalmente são links simbólicos, dando a você a
capacidade de ativar ou desativar um servidor virtual rapidamente, preservando seu arquivo de con�guração.
#gzip_vary on;
#gzip_proxied any;
#gzip_comp_level 6;
#gzip_buffers 16 8k;
#gzip_http_version 1.1;
#gzip_types text/plain text/css application/json application/x-
javascripttext/xml application/xml application/xml+rss text/javascript;
Existe um arquivo padrão que pode (e deve) ser usado como modelo para você criar as con�gurações dos sites que
serão dispostos pelo Nginx. Então, apenas copie o /etc/nginx/sites-available/default para /etc/nginx/sites-
available/example.com. Feito a cópia com o devido nome do site que será disposto, vamos para as con�gurações
pertinentes.
A diretiva listen, de�ne o nome do host/IP e aporta TCP onde ele deve ouvir as conexões HTTP. Por padrão, as
conexões HTTP estão relacionadas na porta 80.
Como exemplo vamos analisar a con�guração feita abaixo:
Um servidor ouvirá os pedidos no endereço IP 192.168.3.105, em duas portas distintas. A primeira linha de�ne a porta
80, e a segunda, na porta 8080. Uma outra forma de representarmos as portas é usando as seguintes notações:
Essas notações são equivalentes na aplicação prática. Outra possibilidade é a de�nição de endereços distintos. Assim,
podemos de�nir:
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
root /usr/share/nginx/html;
index index.html index.htm;
# Make site accessible from //localhost/
server_name localhost;
location / {
# First attempt to serve request as �le, then
# as directory, then fall back to displaying a 404.
try_�les $uri $uri/ /index.html;
# Uncomment to enable naxsi on this location
# include /etc/nginx/naxsi.rules
}
}
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
listen     192.168.3.105:80;
listen     192.168.3.105:8080;
listen 80;
listen *:80;
listen 8080;
listen *:8080;
Agora que entendemos como de�nir portas e interfaces, vamos passar para o server_name, responsável por processar
os pedidos dos nomes de domínios do servidor.
Abaixo será apresentado uma referência onde qualquer pedido para exemplo.com será tratado, independentemente de
ser ftp.exemplo.com, www.exemplo.com, exemplo.com ou qualquernome.exemplo.com.
Outra forma é de�nir qualquer variação de exemplo. Dessa forma, teríamos server_name exemplo.*;ou poderíamos
de�nir vários server_names distintos como no exemplo server_name example.com linode.com icann.org;
Por �m, se você de�nir o server_name   ""; irá processar todas as solicitações que não tenha um nome de hosts ou que
têm um nome de host não especi�cado, tais como pedidos para o próprio endereço IP.
Você pode fazer tratativas de registro de log de acesso e de erros. Com o parâmetro access_log off, há a possibilidade
de desativar o acesso. O access_log pode ser de�nido no arquivo nginx.conf ou no bloco de con�guração para um
domínio especí�co. Ele de�ne o local do log de acesso e, ao de�nir o log de acesso, você poderá de�nir um caminho
para cada bloco de con�guração. Um access_log de�nido no HTTP pode ser usado para registrar todo o acesso em
um único arquivo ou um padrão para todos os registros de acesso às máquinas virtuais que não de�nem os seus
próprios arquivos de log /etc/nginx/nginx.conf.
Como sugestão, indicamos o uso de caminho absoluto no lugar de caminhos relativos para os arquivos. Isso ajudará
no controle de erros de acesso aos arquivos de registro.
Vamos tratar das diretivas de localização dos arquivos. Vamos focar a de�nição dos caminhos base e trataremos as
especi�cidades do que se passa dentro de um bloco de localização em seguida.
A localização con�guração permite con�gurar como Nginx irá responder aos pedidos de recursos dentro do servidor.
Assim como o server_name de�nirá como processar pedidos de domínio, a localização abrange os pedidos de
arquivos e pastas especí�cos, como //example.com/blog/.
Assim, é necessário que seja con�gurado dentro do arquivo do site (/etc/nginx/sites-available/example.com) os
parâmetros:
listen 12.34.56.77:80;
listen 12.34.56.78:80;
listen 12.34.56.79:80;
server_name *.exemplo.com;
server_name .exemplo.com;
access_log logs/example.access.log;
location / { }
location /images/ { }
location /blog/ { }
location /planet/ { }
location /planet/blog/ { }
Esses cinco primeiros exemplos são de uma cadeia de partida literal, o que corresponde a qualquer parte de uma
solicitação HTTP que vem após o segmento de acolhimento.
Assim, se houver um pedido ou uma solicitação //example.com/ para o retorno (assumindo que exista um
server_name de entrada para example.com), a diretiva de localização irá determinar o que acontece com esse pedido.
O Nginx sempre cumpre solicitação, usando a correspondência mais especí�ca. Sendo assim, sempre que houver um
pedido como //example.com/planet/blog/ ou //example.com/planet/blog/about/, o sistema fará a tratativa da
solicitação pela con�guração de localização/planeta/blog/ porque é a de�nição mais especí�ca, embora localização
/planeta/ também coincide com esse pedido. Resumindo: ele fará o atendimento pela maior exatidão.
Dessa forma, encerramos as con�gurações, agora basta subir o serviço e iniciar as operações.
Atenção! Aqui existe uma videoaula, acesso pelo conteúdo online
Atividade
1) O Nginx pode ser con�gurado nos sistemas operacionais Linux e Windows?
2) O IIS, em sua con�guração, possibilita a de�nição de um endereço IP especí�co para respostas de requisições de acesso?
3) É possível usarmos portas distintas para sites distintos nos IIS e no Nginx?
4) Qual(is) porta(s) podemos usar para acesso aos serviços providos por um servidor web?
5) Qual é o usuário interno do Nginx?
Notas
user1
De�ne que usuário do sistema Linux é responsável por gerir o servidor Nginx. A maioria das distribuições baseadas no Debian
usam www-data, mas isso pode ser diferente em outras distribuições.
worker_process2
Determina como muitos segmentos ou instâncias simultâneas podem ser executadas, ou seja, demonstra ao sistema que
temos diversos processadores para usar.
pid3
De�ne onde Nginx vai escrever seu processo mestre ID ou PID. O PID é usado pelo sistema operacional para acompanhar e
enviar sinais para o processo Nginx.
events4
Diretivas que afetam o processamento de conexão.
worker_connections5
O parâmetro worker_connections de�ne o número máximo de conexões simultâneas permitidas por um processo de trabalho
(768 por padrão). Caso você queira múltiplas conexões ao mesmo tempo, você deve retirar o comentário do parâmetro
multi_accept on.
send�le on6
Quando habilitado, informa ao sistema que os dados não estão em memória e precisam ser liberada a saída e entrada do
disco.
tcp_nopush on7
É responsável por enviar o cabeçalho de resposta de pacotes para o sistema operacional e deve ser usada quando o send�le
estiver habilitado (on).
tcp_nodelay on8
Pode estar ativa apenas quando um há transferência para o estado keep-alive.
keepalive_timeout9
Determina o tempo limite que uma conexão de um cliente estará ativa no servidor.
types_hash_max_size10
Estabelece o tamanho máximo das hash tables e tem por padrão 2048.
server_tokens off11
Emite mensagens de erro ao servidor e é usada para depurar falhas no sistema. Por padrão, vem desabilitada e, para habilitá-la,
basta retirar o # do início da linha.
server_names_hash_bucket_size12
Aqui será de�nido o tamanho para as tabelas de nome de hash. Esse tamanho está relacionado com o tamanho de cache do
processador. Esse é mais um parâmetro que vem comentado por padrão e pode ser habilitado com a retirada do # do início da
linha.
server_name_in_redirect off13
Ativa ou desativa o uso do nome determinado pelo server_name.
include /etc/nginx/mime.types14
De�ne o mapeamento das extensões de nome de arquivo que podem ser de�nidas com a diretiva types. Tais arquivos
correspondem a uma lista de formados e extensões permitidas no sistema.
default_type application/octet-stream15
Declaração direta de MIME TYPE não declarado dentro do arquivo mime.types. Isso fará com que seja ativado a aplicação de
stream de vídeo octet-stream.
Referências
FOX, Pamela. HyperText Transfer Protocol (HTTP). Khan Academy, [S.l.], [2019?]. Disponível em:
htt // kh d / ti / t i i i l /th i t t/htt ht l/ /h t t t f
javascript:void(0);
https://www.khanacademy.org/computing/ap-computer-science-principles/the-internet/http-html/a/hypertext-transfer-
protocol-http. Acesso em: 22 jun. 2019.
PAVAN. Podila. HTTP: The Protocol Every Web Developer Must Know – Part 1. 2013. Envato Tuts+, Nova Iorque, 8 abr. 2013.
Disponível em: https://code.tutsplus.com/tutorials/http-the-protocol-every-web-developer-must-know-part-1--net-31177. Acesso
em: 22 jun. 2019.
REDE NACIONAL DE PESQUISA. Instituto Tamis. Popularização da Internet: introdução ao uso de correio eletrônico e web. [S.l.],
out. 1997. Disponível em: https://memoria.rnp.br/_arquivo/documentos/ref0186.pdf. Acesso em: 23 jun. 2019.
TEMPLIN, Reagan. Introduction to IIS Architectures. [S.l.], 15 nov. 2007. Disponível em: https://docs.microsoft.com/pt-
br/iis/get-started/introduction-to-iis/introduction-to-iis-architecture#http-administration-and-con�guration. Acesso em: 22 jun.
2019.
Próxima aula
Serviço de comunicação - e-mail server.
Explore mais
Assista aos vídeos:
Criando um Servidor Web #05 - Con�gurando o Nginx;
Como con�gurar NGINX en CentOS 7 - parte 1.
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);
javascript:void(0);