A Web e outros servicos da Internet

Heitor Soares Ramos Filho Colaboracao: Bruno Lopes Vieira 3 de dezembro de 2007

Sum rio a
1 Princpios de aplicacoes de rede 1.1 Arquitetura cliente-servidor . . . . . . . . . . . . . . . . 1.2 Arquitetura peer to peer pura . . . . . . . . . . . . . . . 1.3 Arquitetura hbrida (cliente/servidor peer to peer) . . 2 Comunicacao na rede 3 Enderecamento 4 Servicos de transporte 5 Servico de resolucao de nomes DNS 2 2 3 3 4 5 6 8

6 A Web e o protocolo HTTP 10 6.1 O HTML e o protocolo HTTP . . . . . . . . . . . . . . . . . 10 6.2 Os Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3 Servidor Proxy . . . . . . . . . . . . . . . . . . . . . . . . 13 7 O protocolo FTP 8 Servico de correio eletr nico o 16 17

No captulo anterior discutiu-se o que s o redes de computa a dores e como elas funcionam. Entendendo de uma forma geral seu funcionamento, foi apresentada a Internet como uma rede de redes; a grande rede mundial que reune diversas redes em uma so. Faz-se agora necessario compreender a Internet mais a fundo. A partir daqui inicia-se a discuss o sobre os servicos disponveis na a Internet.

1 Princpios de aplicacoes de rede

Daqui por diante discutir-se-a os servicos que circundam a In ternet. As funcionalidades s o diversas: desde servidores de e-mail a a servicos de videoconfer ncia. e E preciso agora compreender melhor como essas aplicacoes fun cionam. No contexto da Internet e necessario que as aplicacoes sejam executadas nos sistemas nais e se comuniquem atrav s de e uma rede. Vale salientar que n o ha aplicacoes desenvolvidas para a o nucleo da rede, ele n o opera na camada de aplicacao. Todas as a aplicacoes da Internet funcionam nos hosts nais. Agora se dara incio ao estudo mais aprofundado da arquitetura dos sistemas da Internet. Dessa forma, espera-se atingir melhor compreens o do funcionamento da rede. a

1.1 Arquitetura cliente-servidor

Conforme visto anteriormente, uma aplicacao que opera na ar quitetura cliente/servidor pura trata de um cliente que efetua alguma solicitacao a um servidor e este a responde. Exemplos desse tipo de situacao s o muito recorrentes no dia-a-dia, como, por exem a plo, os servicos de correio eletr nico (SMTP, POP e IMAP), navegacao o em paginas da Web (HTTP) e transfer ncia de arquivos (FTP). e E importante destacar que, na arquitetura cliente/servidor, um cliente n o podera se comunicar diretamente com outro. Todas as a operacoes s o intermediadas pelo servidor. Isso gera melhor con a trole por parte do servidor, ja que e possvel monitorar todas as transmiss es efetuadas, por m pode gerar trafego desnecessario e o e at mesmo atrasos indesejados. e Basta imaginar uma aplicacao de transmiss o de mensagens a instant neas (chat online), que se estivesse totalmente implemena tada no paradigma cliente/servidor apresentaria diversas caractersticas indesejadas. Todas as mensagens seriam primeiro trans mitidas ao servidor e este as redirecionaria ao(s) destinatario(s). Ou

seja, todo o trafego seria primeiro deslocado a um agente interme diador que seria responsavel por envia-lo ao interlocutor. Em se tratando de mensagens de texto, o atraso n o seria muito grande, a apesar do trafego na rede ser duas vezes o necessario e o servidor pode car sobrecarregado caso haja muito cliente utilizando esse servico. Mas se estivermos utilizando chamadas de voz, al m do e trafego ser muito maior, a possibilidade dos atrasos atrapalharem a comunicacao aumentam muito. Ao se passar para aplicacoes de videoconfer ncia, o atraso seria inevitavel, haja vista que o trafego e para transmiss o de vdeo e extremamente maior. a

1.2 Arquitetura peer to peer pura

Ja foi dito anteriormente que na arquitetura peer to peer ou n o a se utiliza servidores ou eles s o pouco utilizados, em geral apenas a para controle, por exemplo a autenticacao. Uma aplicacao conecta se diretamente com o host que lhe e de interesse. Dessa forma cada host tem acesso direto a qualquer outro. Seu uso e muito difundido nos servicos de compartilhamento de arquivos (como na rede Gnutella). Com esse conceito, os sistemas podem interagir diretamente, sem intermediarios, reduzindo o trafego de dados na rede e evi tando atrasos indesejados. Por m uma rede desse tipo se torna e muito difcil de gerenciar. Como n o ha um servidor central, n o se a a pode ter controle dos hosts conectados. N o ha como controlar a a troca de mensagens e nem sequer ter certeza dos dados da rede.

1.3 Arquitetura hbrida (cliente/servidor peer to peer)

Utilizando-se as caractersticas de cada uma das arquiteturas supracitadas quando mais for conveniente, pode-se resolver os problemas anteriormente citados. No exemplo dado na secao 1.1, o bate-papo online, o problema pode ser facilmente transponvel efe tuando a conex o cliente/servidor para obter os dados dos contatos a e a troca de mensagens ocorrer diretamente dentre os hosts (peer to peer). Dessa forma se minimizara os atrasos e o trafego indesejado sera suprimido. Exemplos desse tipo de aplicacao s o os servicos de a mensagens Jabber e MSN. Neles, para conectar-se o usuario efetua log-in num servidor, o qual retornara a lista de contatos do usuario. Ao se iniciar uma conversa com um outro usuario, a transmiss o a se da diretamente com o outro host. Ja a situacao exposta na secao 1.2, o compartilhamento de ar quivos, pode ser resolvida apenas implantando o controle dos hosts por um servidor. Manter-se-ia a troca de mensagens diretamente 3

host a host. O servidor apenas manteria o controle dos arquivos fornecidos por cada estacao facilitando o sistema de busca (em vez de solicitar a cada host que informe seus arquivos disponveis, cada um o faria ao servidor apos a conex o e a busca seria diretamente a no servidor, que encaminharia o usuario ao host que possui o ar quivo de interesse do solicitante) e a ger ncia efetiva da rede. Isso e pode ser observado nas redes Napster, KaZaA e EDonkey. A escrita de aplicacoes que se comunicam em rede e realizada denindo protocolos em camada de aplicacao ou utilizando as de nicoes ja feitas. Por exemplo, para escrever um navegador Web n o se faz necessario denir novos protocolos de comunicacao dado a que o HTTP ja esta bem denido e documentado. Basta seguir a RFC-2616 e implementar o navegador Web. Caso deseje-se escrever um servico que ainda n o esta especicado, deve-se especicar a um novo protocolo de camada de aplicacao e apenas escolher qual servico e mais apropriado, o servico orientado a conex o ou o servico a n o-orientado a conex o. N o se faz necessario que o desenvolvea a a dor da aplicacao conheca, com detalhes, toda a infra-estrutura da rede, como por exemplo, como os dados ser o roteados entre os a hosts. Essa estrutura e possvel por causa da divis o em camadas a e o acoplamento entre essas camadas. Em qualquer uma dessas arquiteturas apresentadas anteriormente, as aplicacoes precisam se comunicar. Detalhes dessa co municacao esta descrito na proxima secao.

2 Comunicacao na rede
Para que uma aplicacao possa interagir com outras e necessario que estas troquem informacoes. Antes de prosseguir, dena-se um processo como um programa qualquer que esta sendo executado num sistema hospedeiro. Se essa comunicacao for efetuada no mesmo host, a troca de mensagens e estabelecida pelo Sistema Operacional numa comuni cacao interprocessos. No caso dos hosts serem sistemas diferentes, essa comunicacao e efetuada atrav s da troca de mensagens. Assim e sendo, ter-se-a dois tipos de processos: Processo cliente: processo que inicia a comunicacao; Processo servidor: processo que aguarda ser contactado (o processo ca em espera at que receba alguma mensagem). e Observa-se que em sistemas peer to peer ha processos cliente e servidor na mesma aplicacao, ja que hora ela se comporta como cliente, hora como servidor. 4

Essa troca de mensagens ocorre atrav s dos chamados sockets. e Os processos enviam uma mensagem atrav s de seu socket e tamb m e e recebem mensagens atrav s deles. Os Sockets denem e controlam e os m todos de entrada e sada das mensagens. e Um socket pode ser visto como uma porta onde um processo de envio empurra a mensagem para fora da porta e um processo de recebimento a deixa entrar. Os processos de envio e de recebimento conam na infra-estrutura de transporte oferecida pela rede. Diversas linguagens de programacao oferecem bibliotecas para facilitar a implementacao de sockets, ou seja, para facilitar o desenvolvimento de aplicacoes em rede. Os sockets s o identicados na Internet atrav s do enderecamento. a e Na proxima secao o enderecamento utilizado na Internet e discutido com mais detalhes.

3 Enderecamento
Para que um host possa ser localizado na rede, e preciso que ele possua um identicador unico, um endereco. Dessa forma, foi criado o conceito de enderecamento IP. Um conjunto de quatro by tes, ou seja, 32 bits, que identicara cada sistema, gerando numa representacao decimal, um bloco de quatro numeros de 0 a 255 (ex: 201.4.93.96). E importante frisar que essa estrutura de enderecamento e de nida pelo protocolo IPv4 (ver Information Sciences Institute University of Southern California, 1981), sendo que ja esta em fase de estudo (a transicao entre essas vers es ocorrera de forma muito o lenta) o IPv6 (ver Deering & Hinden, 1998). Entretanto sabe-se bem que e muito comum usar varias aplica coes num mesmo sistema (ex: navegar em paginas da Web enquanto se utiliza algum mensageiro instant neo e ouvir musica por uma a radio na Internet). Dessa forma apenas o endereco do host n o sera a suciente para efetuar a troca de mensagens, as aplicacoes dentro de um host tamb m devem ser identicadas de forma unica. Anal, e ao chegar uma mensagem, como o sistema podera encaminha-la a aplicacao correspondente se todas possuem o mesmo endereco, sem ter de envia-la a todas? Para resolver essa quest o utiliza a se o conceito de portas. Cada mensagem e encaminhada a um endereco associada a uma porta, havendo convencoes de portas comuns, conforme pode ser visto na tabela 1. Dessa forma, um socket e unicamente identicado na Inter net atrav s da tupxla IPorigem:Portaorigem IPdestino:Portadestino , e como ilustrado na Figura 1. Na gura, temos que o host A esta 5

Tabela 1: Tabela de convencao de algumas portas Porta Aplicacao 21 Servicos FTP 23 Acesso remoto Telnet 25 Envio de e-mail SMTP 80 Servico de navegacao Web rodando uma aplicacao que e identicada como processo 1. No host B tamb m esta rodando uma aplicacao e ela tamb m e idene e ticada como processo 1. Note que a identicacao das aplicacoes deve ser unica dentro de um mesmo host mas as aplicacoes po dem ter a mesma identicacao desde que estejam executando em hosts diferentes. O sistema operacional de cada host ira controlar a identicacao dessas aplicacoes. Dado que essas duas aplicacoes queiram se comunicar, um socket e estabelecido entre elas. Esse socket pode utilizar o servico orientado a conex o ou o servico n o a a orientado a conex o oferecidos pela camada de transporte. a

Figura 1: Elementos de um Socket Na proxima secao s o discutidos, com mais detalhes, os servicos a oferecidos pela camada de transporte.

4 Servicos de transporte
Ha varios servicos de transporte disponveis numa rede de com putadores. Antes de se discutir esses servicos, apresenta-se um breve resumo das necessidades de controle no transporte de mensagens. Aplicacoes de transfer ncia de arquivos (como FTP) e acesso re e moto a sistemas (Telnet) n o admitem perda de dados. Se um ara 6

quivo n o for transmitido por completo, o mesmo em geral n o pode a a ser utilizado, assim como o acesso remoto com perda de dados pode trazer varios problemas ao sistema. Entretanto aplicacoes de strea ming multimdia como transmiss o de audio online podem admitir a a perda de uma certa quantidade de dados, n o havendo perdas a consideraveis. Essa ultima tamb m exige um limite mnimo de banda para e transfer ncia (velocidade de transmiss o), assim como as de tee a leconfer ncia. Ha ainda aplicacoes que n o admitem atrasos na e a transmiss o de dados, como as de telefonia IP e jogos online. a A partir da, denem-se os servicos de transporte disponibiliza dos pelos dois principais protocolos de controle de transmiss o de a dados. Na Internet temos: TCP: apresenta a transmiss o de dados orientada a conex o (rea ` a quer conex o entre processos cliente e servidor), com transa porte conavel (caso algum pacote n o chegue ao destino o a mesmo sera retransmitido), controle de uxo (evita que o re ceptor seja sobrecarregado) e controle de congestionamento (evita que o canal de comunicacao que sobrecarregado); por m e n o oferece garantia de tempo de transmiss o e controle de a a banda passante. UDP: oferece transmiss o de dados n o-conavel sem nenhuma gaa a rantia de como dar-se-a o processo de transmiss o (uxo, con a gestionamento, temporizacao e banda). Dado o supracitado, surge a quest o: que protocolo de transa fer ncia utilizar? Em se tratando de aplicacoes que requerem cone abilidade, o TCP oferece todo o aparato necessario para esse con trole. Por m todos esses recursos exigem tempo de processamento. e Al m do que, n o interessa a uma streaming multimdia online a ree a transmiss o de um pacote perdido, visto que o tempo de execucao a desse ja passou. Para esse tipo de aplicacao, que requer velocidade na transmiss o, o UDP apresenta-se como uma melhor alternativa. a Vale salientar que pode-se utilizar o UDP com conabilidade, desde que seja implementado o servico de conabilidade diretamente na aplicacao. Esta opcao raramente e utilizada pois, como ja foi dito anteriormente, o desenvolvedor, em geral, deve escolher o servico que melhor se adeque a sua aplicacao. No caso de uma aplicacao ` que n o se adeque nem ao TCP e nem ao UDP, essa opcao pode ser a util mas o seu desenvolvimento sera, certamente, mais complexo. O UDP tamb m n o oferece garantias de tempo de entrega e nem e a de taxa de transmiss o. Esses servicos ainda est o sendo desenvola a vidos na Internet. Atualmente, as aplicacoes que necessitam tem 7

pos de resposta mais baixo e n o necessitam de conabilidade, opa tam por UDP pois os controles de uxo e congestionamento presentes no TCP podem diminuir a taxa de transmiss o de uma conex o. a a Nas proximas secoes ser o discutidos alguns protocolos de aplicacao a frequentemente encontrados na Internet.

5 Servico de resolucao de nomes DNS

Para acessar um sistema remoto, e necessario que se saiba o endereco do servidor. Ou seja, e necessario que o endereco IP seja conhecido. Entretanto torna-se muito difcil a memorizacao de enderecos de computadores em sua forma num rica. Na tentativa de facilitar a e utilizacao de enderecos, criou-se o servico de resolucao de nomes, o DNS (Domain Name System), onde um servidor e responsavel por tra duzir um endereco alfanum rico num endereco IP. Assim sendo, ao e inv s do usuario acessar um stio atrav s de um endereco IP como e e 200.17.114.42, utiliza-se www.ufal.br. O servico DNS e realizado atrav s de um banco de dados distribudos de nomes. Isso signie ca que n o ha um unico servidor que contenha todas as traducoes a de nomes para enderecos IPs. Essa informacao esta espalhada em diversos servidores onde cada entidade mant m os seus regise tros para o seu domnio e algumas entidades mant m os registros e raiz. Por exemplo, existem os servidores responsaveis pelo incio da hierarquia do DNS, ou seja, o domnio .. A partir da esses servido res apontam para os servidores responsaveis pelos domnios abaixo desse domnio, por exemplo, o domnio .com., .br., .ar., .net. e .tv.. Assim, sucessivamente, outros servidores s o responsaveis pelos a domnios em nveis abaixo desses como por exemplo os domnios .com.br., .net.br. e assim por diante. O nome DNS completo contempla o . no nal mas este e suprimido pelas aplicacoes. Cada pas elegeu uma instituicao para ser responsavel pela dis tribuicao de nomes, por exemplo, no Brasil, uma instituicao ca responsavel por todos os domnios abaixo do .br. Caso uma ins tituicao deseje ter um nome abaixo da hierarquia do Brasil, basta realizar uma solicitacao atrav s do stio http://registro.br, que e o seu nome seja includo nesses servidores e aponte o seu domnio para o seu proprio servidor. Por exemplo, a UFAL tem no regis tro.br um cadastro que aponta o domnio da UFAL para os seus proprios servidores DNS, de forma que o cadastro dos computado res da UFAL ca nos servidores de DNS da propria UFAL. Para o registro.br basta apenas saber quem e o servidor de DNS da UFAL. Dessa maneira, a UFAL administra quem e o servidor que responde 8

pelo nome ftp.ufal.br e www.ufal.br, por exemplo, e tamb m a e todos os domnios abaixo de ufal.br. Por exemplo temos o domnio tci.ufal.br do Instituto de Computacao da UFAL. Por sua vez, re cursivamente, os servidores que respondem por www.tci.ufal.br, ftp.tci.ufal.br, por exemplo, cam nos servidores DNS do TCI que est o cadastrados no servidor de DNS da UFAL. a Inicialmente o controle do DNS dos registros brasileiros cou com a Fapesp (Fundacao de Amparo a Pesquisa do Estado de S o Paulo), ` a mas, recentemente, esse controle passou para o comit gestor da e Internet brasileira (CGI BR). No site http://registro.br pode-se inclusive vericar quem s o os proprietarios de determinado domnio e/ou efetuar o registro a de um domnio que esteja disponvel. A quest o agora e: como funciona a resolucao de nomes? Pria meiro e importante saber que a resolucao de nomes e feita da di reita para a esquerda, separando-se por pontos (.) as subredes. Ou seja, o endereco www.ufal.br e resolvido da seguinte forma: br: acessam-se os servidores raiz (treze servidores espalhados pelo planeta que respondem pelas primeiras chamadas da resolucao de nomes) identicando-se ao servidor de qual pas sera redirecionado para o restante do processo, no caso br indica que deve ser redirecionado ao servidor do Brasil. ufal: no servidor do Brasil, identica-se quem e responsavel pela traducao do domnio ufal: kharma.ufal.br 200.17.114.40. www: acessando o servidor DNS do domnio ufal, verica-se que www corresponde a 200.17.114.38, retornando ao host que o solicitou para que o acesso desejado possa ser efetuado. Com a utilizacao do DNS, deni-se uma forma universal para acessar objetos na Internet, a URL (Uniform Resource Locator). A URL e utilizada para acesso a qualquer objeto depositado na Internet atrav s de qualquer servico. A URL tem o seguinte formato: e protocol://server-name.domain-name.top-level-domain: port/directory/filename ex: http://www.healthyway.com:8080/exercise/mtbike.html ftp://ftp.company.com/freeware/progra.exe

6 A Web e o protocolo HTTP

A Web pode ser denida como um conjunto de hipermdias (hi pertextos, imagens, vdeos etc.) disponveis para acesso atrav s da e Internet. Para que que mais claro, dene-se hipertexto de uma forma simplista como textos que possuem ligacoes com outros ele mentos. Assim, torna-se possvel navegar entre paginas da Internet atrav s dos hiperlinks (ligacoes de refer ncia a um outro texto e e sendo esse texto uma outra pagina ou at mesmo recursos mul e timdia como vdeos e animacoes). Para que se possa ter melhor id ia da import ncia da Web, basta e a imaginar como seria a Internet sem esse recurso. N o havendo a a disponibilidade dessas paginas n o ha como acessar sites, nem a blogs, nem qualquer outro tipo de sistema que use essas id ias, e como redes de relacionamento ou portais de notcias. Era assim que tudo funcionava at 1990, quando Tim Berners-Lee concebeu a e Web. Em 1 de agosto de 1991 ele disponibilizou a primeira pagina Web da Internet, que explicava como a Web seria e suas vantagens, como criar um navegador etc. Foi a partir da que houve a grande explos o de uso da Internet, que a partir de 1992 comecou a se poa pularizar, passando a ser largamente utilizada. No Brasil, a Internet iniciou sua operacao comercial em 1994 mas ja estava operando nas universidades. Para que a id ia de hipertexto funcionasse, houve a necessidade e de criacao de uma linguagem capaz de transcrever as ligacoes de hipertexto. Para suprir essa necessidade, surgiu o HTML, uma linguagem de hipertextos (ver World Wide Web Consortium, 1999).

6.1 O HTML e o protocolo HTTP

So que ainda seria necessario uma maneira pratica de transferir as paginas HTML, um meio de acesso rapido e pratico. Foi com essa id ia que se desenvolveram os servidores Web. Como ja foi e visto anteriormente, para que duas aplicacoes possam conversar na Internet (servidor Web e navegador Web) e necessario um meio formal de comunicacao dentre elas. Esse meio seria o protocolo HTTP (ver Fielding et al., 1999). O protocolo HTTP funciona originalmente de maneira muito simples, apenas com tr s m todos: e e GET: solicita um objeto (pagina HTML, imagem etc.) ao servidor Web. POST: envia informacoes ao servidor.

10

HEAD: solicita ao servidor que algum elemento seja ignorado a res` posta. Um exemplo de utilizacao do protocolo HTTP esta ilustrado na gura 2. Nesta gura, um cliente abre uma conex o com o servidor a Web da UFAL (em geral na porta 80) e solicita a pagina index.html. O servidor responde com um codigo informando que a pagina existe e transfere a pagina para o cliente. O protocolo HTTP e conhecido por ser stateless, ou seja, n o a mant m as conex es. A cada pedido por um objeto, o servidor o e o transfere e encerra a conex o. Com isso, cada vez que uma ligacao a leva a um servidor Web e aberta uma nova conex o com o este ser a vidor. Essa caracterstica e utilizada no servico Web pois, em geral, baixamos uma pagina, lemos o que nos interessa, e depois nave gamos por paginas no mesmo servidor ou em outros servidores, dependendo de para onde a ligacao (link) nos leva. O fato de n o a manter a conex o faz com que os servidores possam manter mais a clientes pois a manutencao de conex o por tempos longos gera uma a sobrecarga no servidor. Perceba que para manter uma conex o o a servidor deve ter o registro de todos os clientes ativos. Se essa conex o demorasse, a memoria do servidor poderia car cheia caso a varios clientes conectassem simultaneamente. N o manter a co a nex o diminui as chances de muitos clientes estarem conectados a simultaneamente nos servidores e os sobrecarregarem.

GET www.ufal.br/index.html Navegador 200 <index.html> Servidor Web

Figura 2: Exemplo de acesso HTTP Com sua evolucao, surgiu o HTTP 1.1 (vers o atualmente em uso), a que acrescenta os seguintes comandos: PUT: envia um arquivo ao servidor Web. DELETE: apaga um arquivo no servidor Web. Al m disto, o HTTP 1.1 melhora o desempenho, modicando a e forma como as conex es s o realizadas. Por exemplo, a transo a fer ncia de uma pagina com 10 guras necessitaria a abertura de e 11 conex es do cliente com o servidor ao utilizar o HTTP 1.0. Uma o 11

conex o para trazer a pagina e mais dez conex es para trazer cada a o uma das imagens. Utilizando HTTP 1.1 seria necessario apenas uma conex es para trazer a pagina e as outras dez imagens. Esse fato o aumenta o desempenho do protocolo HTTP al m de alivar a sobree carga para a abertura dessas conex es no servidor. Essa caraco terstica e conhecida como persist ncia, pois a conex o persiste at e a e que todos os arquivos sejam transferidos. O HTTP continua stateless por m, com o uso da persist ncia, apresenta melhor desempenho e e no caso de paginas com varios objetos (muito comum nas paginas atuais onde encontramos varias imagens, animacoes e aplicacoes embutidas). Observe-se ainda na gura 2 que junto com o arquivo de res posta, o servidor envia anteriormente um codigo. E atrav s desse e codigo que o navegador identica o tipo de resposta enviada. Na tabela 2 ha alguns dos principais codigos de resposta HTTP. Tabela 2: Codigos de resposta HTTP Signicado Requisicao efetuada com sucesso; arquivo anexo. Objeto movido permanentemente para <destino>. Servidor n o entende a mensagem enviada. a Objeto n o encontrado. a Vers o do HTTP n o suportada pelo servidor. a a

Codigo 200 301 400 404 505

Note-se que os codigos iniciados em 2 signicam que o processo correu normalmente, em 3 uma modicacao no servidor, em 4 um erro na solicitacao e em 5 erro no servidor. Sendo ainda que os iniciados em 1 s o apenas mensagens informativas. a

6.2 Os Cookies
Uma outra quest o interessante e: como personalizar paginas a para um usuario? Em outras palavras, como os sites, por exem plo, mecanismos de sempre identicar o ultimo usuario a efetuar login, ja que a resposta do HTTP seria sempre o mesmo site, sem ser necessario que ele efetue login novamente? O fato do HTTP ser statless faz com que seja mais difcil identi car o usuario. Por exemplo, no FTP, a conex o e mantida at que a e o usuario desista dela. Esse fato facilita a identicacao do usuario pois a secao e mantida. Como ja foi explicado, o HTTP n o mant m a e essa conex o e para cada requisicao nova o HTTP entende como se a fosse um novo cliente. Para isso se usam os chamados cookies, que s o pequenos ara 12

quivos de texto que guardam informacoes para personalizacao de paginas. Atrav s deles, via HTML a pagina l seus conteudos e e e redene-se para prover maior interatividade e customizacao. Al m e disso, os cookies podem ser utilizados para manter informacoes de estado em varios processos, como, por exemplo, um carrinho de compras de uma loja virtual. Supondo que no meio de uma selecao para compras falte energia, caso sejam implementados cookies o usuario, ao retornar ao site tera sua selecao de acordo com o ultimo estado. Ainda outras funcionalidades s o atribudas aos cookies, como a obtencao de informacoes para tentar melhorar mecanismos de bus cas.

6.3 Servidor Proxy

Com o desenvolvimento da Web, as paginas foram cando cada vez mais cheias de objetos como imagens, animacoes e aplicacoes embutidas e o carregamento dessas paginas foi se tornando lento. Antes do surgimento da banda larga, era inviavel fazer determi nadas paginas pois seria muito lento para carregar na casa dos usuarios. Para minimizar esse efeito, foi criado um servico que evitasse que se caso de mais de um usuario da mesma rede de sejasse visualizar uma pagina cada um iniciasse uma conex o com a o servidor e efetuasse o download do mesmo arquivo. Ou seja, paginas comumente acessadas podem gerar trafego desnecessario, podendo at mesmo congestionar o canal de comunicacao. Como e essa pagina ja passou por um canal de comunicacao, se ela fosse armazenada localmente, os proximos clientes que desejassem visu alizar a mesma pagina poderiam baixar essa pagina de um servidor local, evitando o congestionamento. Esse servico e conhecido como proxy com cache. Um servidor proxy tem por funcao responder por acessos a Web, ` em vez dos usuario conectarem-se diretamente. Ou seja, se um usuario deseja acessar um determinado site, ele o solicita ao proxy que fara a solicitacao ao servidor Web, retornando ao proxy que por sua vez respondera ao cliente solicitante (ver gura 3). Assim, pode-se implementar polticas de acesso, determinando qual o li mite de banda a cada usuario, que stios n o devem ser acessados a e reduzir o tempo de resposta a uma requisicao. Um servidor proxy ` serve como um ponto de gerenciamento das conex es web de uma o rede. Para isto, basta exigir que todos os clientes dessa rede sempre naveguem utilizando o servidor proxy. O cache e um repositorio local, onde antes de acessar a Internet ` o servidor vericara se ja n o possui o objeto solicitado. Com isto a 13

GET www.ufal.br/index.html Navegador 200 <index.html> Proxy

GET www.ufal.br/index.html

200 <index.html>

Servidor Web

Figura 3: Acesso a Internet atrav s de um proxy ` e ele consegue economizar a quantidade de dados que ser o baixados a no caso de varias requisicoes iguais feitas pelos clientes de uma rede. Por exemplo se dois usuarios acessam a pagina da UFAL, o servidor proxy so precisa traz -la uma unica vez e entregar aos dois e usuarios. Caso o proxy n o contenha o objeto solicitado no seu cache, ele a acessara o servidor Web externo. Para evitar problemas caso o objeto seja atualizado (evitar que o usuario n o consiga acesso a objetos mais recentes), o servidor a proxy sempre verica se a data de atualizacao do objeto requisitado esta mais nova do que a data do objeto que ele tem armazenado. Caso isto ocorra, ele ignora o objeto que esta armazenado no repo sitorio local e baixa o objeto mais atualizado, substituindo o objeto obsoleto. O servidor proxy consegue identicar quando o objeto esta obsoleto pois ele realiza o m todo conhecido por GET condicional, e ou seja, baixa o arquivo apenas se a data de atualizacao daquele arquivo for mais recente do que uma data especicada (a data de atualizacao do arquivo armazenado no repositorio local) e n o baixa a caso a data do arquivo localizado no servidor externo seja menor ou igual a do repositorio local. 14

Dessa forma a gura 4 ilustra o acesso atrav s de um proxy com e cache onde este possui o objeto solicitado (cache-hit) e a gura 5 o caso similar, so que o servidor n o possui o objeto e tera de efetuar a a solicitacao ao servidor Web (cache-miss).

GET www.ufal.br/index.html Navegador 200 <index.html> Proxy

Cache

Figura 4: Cache-hit

GET www.ufal.br/index.html Navegador 200 <index.html> Proxy Cache GET www.ufal.br/index.html

200 <index.html>

Servidor Web

Figura 5: Cache-miss

15

7 O protocolo FTP
Como forma de melhorar a troca de arquivos numa rede de computadores, criou-se um protocolo destinado exclusivamente a ` transfer ncia de arquivos, o FTP (File Transfer Protocol). Ele pere mite o download e upload de arquivos utilizando comando textuais simples e intuitivos. Por se tratar da transfer ncia de arquivos, e necessario que a e transfer ncia seja conavel. Em outras palavras, e necessario que e haja garantia de que o arquivo recebido n o esteja corrompido e que a este n o seja acessado por usuarios indevidos. Por isso o protocolo a FTP e utilizado sobre o TCP. A porta padr o do protocolo FTP e a a 21. A partir da conex o ao servidor, o usuario informa seu nome de a usuario e senha e que arquivo deseja efetuar download ou upload, iniciando-se uma conex o para transfer ncia de dados na porta 20. a e Com isto o FTP e tido como um protocolo onde o controle e fora da banda, ou seja, os comandos s o realizados em uma conex o TCP a a diferente da conex o que transfere os arquivos. a Um exemplo de conex o FTP, onde o comando get solicita um a arquivo e o comando put envia um arquivo ao servidor, seria: open ftp.ufal.br 220 ProFTPD 1.3.0 Server (UFAL) [192.168.0.4] Name (ftp.ufal.br:heitor): foo 331 Password required for foo. Password: 230 User foo logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> get meu_arquivo.txt 200 PORT command successful 150 Opening BINARY mode data connection for meu_arquivo.txt (79 bytes) 226 Transfer complete. 79 bytes received in 0.42 secs (0.2 kB/s) ftp> put outro_arquivo.txt local: outro_arquivo.txt remote: outro_arquivo.txt 200 PORT command successful 150 Opening BINARY mode data connection for outro_arquivo.txt 226 Transfer complete. 79 bytes sent in 0.00 secs (2204.2 kB/s) ftp> bye 16

221 Goodbye.

8 Servico de correio eletr nico o

Uma das formas mais populares de utilizar a Internet e a partir do servico de correio eletr nico (e-mail). Ele consiste basicamente o na transfer ncia de mensagens de texto dentre usuarios especicae dos. Para prover este servico e utilizado o protocolo SMTP (Simple Mail Transfer Protocol porta 25), que e responsavel pela transfer ncia e dessas mensagens do usuario ao servidor. Ou seja, um usuario envia uma mensagem de correio eletr nico atrav s de um programa o e local em seu computador ou de um Webmail (interface de acesso ao a caixa de correio eletr nico atrav s de uma pagina Web) e esta e ` o e encaminhada ao servidor de correio eletr nico do usuario. Este, por o sua vez, transmite a mensagem ao servidor do usuario de destino, estando ent o disponvel para consulta pelo usuario (ver gura 6). a

Remetente

SMTP: foo@ufal.br

Servidor de Correio

SMTP: foo@ufal.br

Destinatario

POP: foo@ufal.br

Servidor de Correio

Figura 6: Transfer ncia de mensagem de correio eletr nico dentre e o um usuario remetente a um destinatario O detalhe e que o protocolo SMTP n o e utilizado para receber as a mensagens de correio eletr nico, apenas para transmit-las. Ent o, o a 17

como um usuario pode ter acesso a suas mensagens? Observe-se ainda na gura 6 que o destinatario usa o protocolo POP (Post Ofce Protocol porta 110) para receber suas mensagens. Ou seja, para transmitir mensagens de correio eletr nico, e utilizado o protocolo o SMTP. Para solicita-las ao servidor, utiliza-se o protocolo POP. Vale ressaltar que ha outros protocolo de recebimento de mensagens de correio eletr nico, o IMAP (Internet Message Access Protocol porta o 465 ). O IMAP oferece mais recursos ao usuario como a possibili dade de manutencao de pastas dentro do servidor. O protocolo POP e mais simples e mais leve para o servidor enquanto que o proto colo IMAP tem mais recursos sendo que consome mais recursos do servidor.

Refer ncias e
Deering, S. & Hinden, R. (1998), Internet protocol: Darpa internet program. URL http://www.ietf.org/rfc/rfc0791.txt, RFC 2460, ultima consulta em novembro de 2007. Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. & Berners-Lee, T. (1999), Hypertext transfer protocol http/1.1. URL http://www.ietf.org/rfc/rfc0791.txt, RFC 2616, ultima consulta em novembro de 2007. Information Sciences Institute University of Southern California (1981), Internet protocol: Darpa internet program. URL http:// www.ietf.org/rfc/rfc0791.txt, RFC 791, ultima consulta em novembro de 2007. World Wide Web Consortium (1999), HTML 4.01 specication. URL http://www.w3.org/TR/REC-html40/, ultima consulta em no vembro de 2007.

18