Pré-visualização parcial do texto
Baixe Camada de Aplicação e outras Notas de estudo em PDF para Redes de Computadores, somente na Docsity!
Capitalo Camada de Aplicação plicações de rede são a razão de ser de uma rede de computadores, Se não fosse possível inventar aplicações úteis, não haveria necessidade de projetar protocolos de rede para suportá-las. Nos últi- os 35 anos, foram criadas numerosas aplicações de rede engenhosas e maravilhosas. Entre elas estão as aplicações clássicas de texto, que se tornaram populares na década de 1980: correio eletrônico, aces- so a computadores remotos, transferência de arquivo, grupos de discussão e bate-papo e também uma apli- cação que alcançou estrondoso sucesso em meados da década de 1990: a Web. Há ainda muitas aplicações multimídia, como vídeo em tempo real, rádio e telefonia por Internet e videoconferência. Duas aplicações de enorme sucesso também surgiram no final do milênio — mensagem instantânea e compartilhamento não hierárquico de arquivos (peer-to-peer — P2P). Neste capítulo estudamos os aspectos conceituais e de implementação de aplicações de rede. Começamos definindo conceitos fundamentais de camada de aplicação, incluindo protocolos, clientes e ser- vidores, processos, sockets e interfaces de camada de transporte. Então examinamos detalhadamente várias aplicações de rede, entre elas a Web, e-mail, DNS e compartilhamento de arquivos P2P. Em seguida, abordamos desenvolvimento de aplicação de rede por TCP e também por UDP. Em parti- cular, estudamos o API socket e examinamos algumas aplicações cliente-servidor simples em Java. Por exemplo, exploramos como é possível criar um servidor Web simples em Java. Apresentamos também vários exercícios divertidos e interessantes de programação de aplicações no final do capítulo. A camada de aplicação é um lugar particularmente bom para iniciarmos o estudo de protocolos. É ter- reno familiar, pois conhecemos muitas das aplicações que dependem dos protocolos que estudaremos. Ela nos dará uma boa idéia do que são protocolos e nos apresentará muitos assuntos que encontraremos nova- mente quando estudarmos protocolos de camadas de transporte, de rede e de enlace. 2.1 Princípios de aplicações de rede Vamos começar relacionando exemplos de aplicações de rede populares: Correio eletrônico AWeb 57 ENA Transferência de arquivos entre duas contas em dois computadores, como FTP (File Transport Protocol -— Protocolo de Transferência de Arquivos) MBM Jogos multiusuários em rede E Videoclipes armazenados AEMBRE Telefonia por Internet Fani videoconferência em rempo real Neste livro discutiremos muitas dessas aplicações com níveis variáveis de detalhamento. Por exemplo, neste capítulo abordaremos e-mail, a Web e compartilhamento de arquivos PZP No Capítulo 7, que trata de redes multimídia, estudaremos vídeo em tempo real e telefonia por Internet. aplicação será, Agora, suponha que você tenha wma grande idéia para wma nova aplicação de rede. talvez, um grande serviço para a humanidade, ou agradará a seu professor, ou fará de você um homem (ou mulher) rico(a), ou simplesmente será divertido desenvolve-la. Seja qual for sua motivação, vamos exami- nar agora como transformar a idéia em uma aplicação do mundo real. O cerne do desenvolvimento de aplicação de rede é escrever programas que radem em sistemas finais diferentes e se comuniquem entre si pela rede. Por exemplo, na aplicação Web há dois programas distintos que se comunicam um com e outro: o programa do browser, que roda na máquina do usuário (computador de mesa, laptop, PDA, telefone celular e assim por diante); e o programa do servidor Web. que roda na máquina do servidor Web. Um outro exemplo é um sistema de compartilhamento de arquivos P2P no qual hã um programa em cada máguina que participa da comunidade de compartilhamento de arquivos, Nesse caso, os programas de cada máquina podem ser semelhantes ou idênticos. Portanto, ao desenvolver sua nova aplicação, você precisara escrever um soltware que rode em várias máquinas. É importante dizer que você não precisará escrever um software que rode em equipamentos de núcleo de rede, como roteadores ou comutadores Ethernet. E, mesmo que você quisesse escrever software de aplicação para esses equipamentos, não poderia. Como aprendemos no Capítuto 1 e mostramos na Figura 1.18, equipamentos de núcleo de rede não funcionam na camada de aplicação, mas em camadas mais baixas, especificamente na de tede e abaixo dela. Esse projeto básico — a saber, confinar o software de apli- vação nos sistemas finais, como mostra a Figura 2.1, facilitou o desenvolvimento e a proliferação rápidos de uma vasta gama de aplicações de Inemet 2.1.1 Arquiteturos de aplicação de rede Ao construir uma nova aplicação de rede, você primeiramente precisará escolher a arquitetura da apli- cação. Realmente, antes de mergulhar na codificação do soltware, você deverá elaborar um plano geral para a arquitetura da sua aplicação. Tenha sempre em mente que a arquitetura de uma aplicação é distintamen- te diferente da arquitetura de rede (por exemplo, a arquitetura em cinço camadas da Internet que discuti- mos no Capítulo 1). Do ponto de vista do profissional que desenvolve a aplicação, a arquitetura de rede é fixa é prové um conjunto específico de serviços às aplicações. Por outro lado, a arquitetura da aplicação é projetada pelo desenvolvedor « determina como a aplicação é organizada nos vários sistemas finais, Ao escolher a arquitenta da aplicação, o desenvolvedor provavelmente aproveitará uma das três arquiteturas mais utilizadas em aplicações modernas de rede: a arquitetura cliente-servidor, a arquitetura P2P e uma arquitetura híbrida chiente-servidor/P2P. a. Aplicação cliente-servidor h. Aplicação P2P Figuro 2.2 (g) Arquitetura ciente-servidor, (h) arquitetora PSP Em uma arquitetura P2P pura, não há um servidor sempre funcionando no centro da aplicação. Em vez disso, pares arbitrários de hospedeiros, denominados peers, comunicam-se diretamente entre si Como os pares se comunicam sem passar por nenhum servidor especial, a arquiteinra é denominada par-a-par (peer- to-peer — P2P). Nesse tipo de arquitetura, nenhuma das máquinas participantes precisa estar sempre em fun- cionamento; além disso, um hospedeiro participante pode mudar seu endereço IP cada vez que for ligado. Um bom exemplo de aplicação que tem arquitetura P2P pura é a Gnutella [Gnutella, 2004], uma aplicação P2P de compartilhamento de arquivos de código-fonte aberto. Na Gnutella, qualquer hospedeiro pode requi- sitar e enviar arquivos, consultar a localização de um arquivo e responder e transmitir consultas. Exami- -naremos a Gntella mais detalhadamente na Seção 2.6. A arquitetura P2P é ilustrada na Figura 2.2(b). Uma das características mais fortes da arquitetura P2P é sua escalabilidade. Por exemplo, em uma aph- cação P2P de compartilhamento de arquivos, milhões de pares podem participar da comunidade de com- partilhamento de arquivos, sendo que cada um deles funciona como um servidor e contribui com recursos para a comunidade. Desse modo, conquanto cada par gere carga de trabalho requisitando arquivos, também agrega capacidade de serviço ao sistema respondendo requisições de outros pares, Assim, em princípio, o compartilhamento de arquivos P2P é intrinsecamente escalável -— cada par adicional não apenas aumenta a demanda, mas também aumenta a capacidade de serviço. Na Internet de hoje, o tráfego de compartilha- mento de arquivos P2P é responsável por uma grande parcela de todo o tráfego [Saroiu, 20021. Por outra lado, devido à sua natureza altamente distribuída e descentralizada, pode ser difícil gerenciar aplicações P2P Por exemplo, um par pode ter a única cópia de um arquivo importante e sair da comunida- de a qualquer momento. Continua em aberto a questão da possibilidade de criar soluções P2P de grande porte para aplicações empresariais [Adya, 2004. Às duas arquiteturas, cliente-servidor e P2P são comuns em aplicações de rede. Contudo, muitas aphi- cações são organizadas segundo arquiteruras bibridas cliente-servidor/P2P Um exemplo disso é a já extin- ta Napster, a primeira das populares aplicações de compartilhamento de arquivos MP3. A arquitetura da Napster exa P2P no sentido de que arquivos MP3 eram trocados diretamente entre pares, sem passar por ser- vidores dedicados, sempre em funcionamento; mas também era cliente-servidor, já que um par consukava um servidor central para determinar quais pares que estavam em funcionamento tinham um arquivo MP3 desejado. (A arquitetura da Napster é estudada mais detalhadamente na Seção 2.6.) Outra aplicação que uti- Capítulo 2 Camada do splicação tim ma arquitetura híbrida é a mensagem instantânea. Nela, a conversa entre dois usuários é tipicamente = B3E isto é, o texto enviado entre dois usuários não passa por um servidor intermediário, sempre em fum- é stonamento. Entretanto, quando Alice, uma usuária, lança sua aplicação de mensagem instantânea, ela se é wegistra em tm servidor central; e quando Bob, um outro usuário, quer conversar com alguém inscrito na sua lista de amigos, seu cliente de mensagem instantânea contata o servidor central para descobrir uuais - Qusses seus amigos estão correntemente on-line e disponíveis. $.1,2 Comunicação entre processos Antes de construir sua aplicação de rede, você também precisará ter um entendimento básico de como programas que rodam em vários sistemas finais comunicam-se entre si. No jargão de sistemas operacionais, «a verdade não são programas que se comunicam, mas processos. Um processo pode ser imaginado como tm programa que está rodando dentro de um sistema final. Quando os processos comunicantes estão todan- do no mesmo sistema final, eles comrunicam-se entre si usando comunicação mterprocessos, cujas regras ais determinadas pelo sistema operacional do sistema [imal. Porém, neste livro, não estamos interessados sin como se comunicam processos que estão no mesmo hospedeiro, mas em como se comunicam proces- was que rodam em sistemas finais diferentes (com sistemas operacionais potencialmente diferentes). Eles se comunicam pela troca de mensagens por meio da rede de computadores. Um processo origina- ist cria e envia mensagens para a rede; um processo destinatário recebe-as e possivelmente responde, devol- “mudo outras. A Figura 2.1 mostra que processes se comunicam usando a camada de aplicação da pilha de sínco camadas da arquitetura, Processos clientes e processos servidores Uma aplicação de rede consiste em páres de processos que enviam mensagens uns para os outros por aúeia de uma rede. Por exemplo, na aplicação Web, o processo cliente de um browser troca mensagens cont * processo de um servidor Web. Em um sistema de compartilhamento de arquivos P2R um arquivo é trans- ferido de um processo que está em um par para outro que está em outro par. Para cada par de processos aestunicantes normalmente rotulamos um dos dois processos de cliente e o outro, de servidor. Na Web, um browser é um processo cliente e um servidor Web é um processo servidor. No compartilhamento de arqui- vog P2P o par que está descarregando o arquivo é rotulado de cliente é o que está recebendo, de servidor. Talvez você já tenha observado que, em algumas aplicações, tal como compartilhamento de arquivos FAR um processo pode ser ambos. cliente e servidor, Reahmente, tm processo em um sistema de comparti- Thamento de arquivos P2P pode carregar e descarregar arquivos. Mesmo assim, no contexto de qualquer «tada sessão entre um par de processos, ainda podemos rotular um processo de cliente e o outro de servi- glur, Definimos os processos cliente e servidor como segue: No contexto de uma sessão de comunicação entre um par de process cação (isto €. o primeiro a contatar o outro no início da sessão) é rotulado de cliente. O proc espera ser contatado para iniciar a sessão é o servidor. 8, € processo que inicia « comuni- O que Na Web, um processo do browser inicia o contato com um processo do servidor Web: por conseguinte, « processo do browser é a cliente £ o processo do servidor Web é o servidor. No compartilhamento de arqui- es P2P quando o Par A solicita ao Par Bo envio de um arquivo específico, o Par À é o cliente enquanto o Bgr B é o servidor no contexto dessa sessão específica de comunicação. Quando não houver possibilidade de confusão, às vezes usaremos também a terminologia “lado cliente e lado servidor de uma aplicação”. No final deste capítulo examinaremos passo a passo um código simples para ambos os lados de aplicações de sede: o lado cliente e o lado servidor. Hã um ponto em nossa terminologia que talvez precise ser mais bem esclarecido. Na Seção 2.1.1, clas- aificamos aplicações segundo suas arquiteturas, a saber, cliente-servidor, P2P ou híbrida. Essa classificação Capítulo 2 Comada da aplicação SS ti ads ds Endereçamento de processos Para que um processo em um hospedeiro envie uma mensagem aum processo em quiro, à processo áriginador tem de identificar o processo destinatário, Para isso, é preciso especificar duas tafermaç q & nome ou o endereço da máquina hospedeira e (2) um identificador que especifique o processo destinatá- ri no hospedeiro de destino. Primeiro, vamos considerar endereços de hospedeiros. Em aplicações da Interner, o hospedeiro de des- tino é identificado por seu endereço IP, Discutiremos endereços IP em deralhes no Capítulo + Por enquan- te, basta saber que o endereço tP é uma quantidade de 32 bits que identifica exclusivamente O sistema Hiral isendo mais precisos, idenúfica exclusivamente a interface de rede que liga aquele hospedeiro à internet) Visto que q endereço TP de qualquer sistema final conectado à Internet pública deve ser globalmente exclu- siva, a atribuição desses endereços deve ser gerenciada com. cuidado, como será discutido no Capítulo 4. Além de saber o endereço do sistema final ao qual a mensagem se destina, o hospedeiro originador tam- bém deve identificar o processo que está rodando no outro hospedeiro. Essa informação é necessária porque, sm geral, um hospedeiro poderia estar executando muitas aplicações de rede. Um número de porta de destino atende a essa finalidade. Aplicações populares receberam números de porta específicos. Por exem- pla, um servidor Web é identificado pelo número de porta 80. Um processo servidor de correio (que usa o paotocoto SMTP) é identificado pelo número de porta 25. Uma lista de números bem conhecidos de portas pata todos os protocolos padronizados da Internet pode ser encontrada no site hitp;/Awyiana org. Quando um desenvolvedor cria uma nova aplicação de rede, ela deve receber um novo número de porta. fxaminaremos números de porta detalhadamente no Capítulo 3. 2,1.3. Protocolos de comada de aplicação Acabamos de aprender que processos de rede comunicam-se entre si enviando mensagens para dentro de sockets. Mas, como essas mensagens são estruturadas? O que significam os vários campos nas mensa- gens? Quando os processos enviam as mensagens? Essas perguntas nos transportam para O mundo dos pro- 1ocolos de camada de aplicação. Um protocolo de camada de aplicação define como processos de ama agticação, que funcionam em sistemas finais diferentes, passam mensagens entre si. Em particular, Wn pro- tovolo de camada de aplicação define: os tipas de mensagens trocadas, por exemplo, de requisição e de resposta; a sintaxe dos vários tipos de mensagens, tais camo os campos da mensagem e como os campos são delineados; a semântica dos campos, isto é, O significado da informação nos campos; SEM regras para determinar quando e como tm processo envia mensagens e responde a mensagens. Alguns protocolos de camada de aplicação estão especificados em RFCs e, portanto, são de domínio guúblico, Por exemplo, o protocolo de camada de aplicação da Web. HTTP (Hypertext Transfer Protocol [ERC 2616]), está à disposição como um RFC. Se um desenvolvedor de browser seguir as 1 3 do REC. do HTTP seu browser estará habilitado a extrair páginas de qualquer servidor Web que também tenha segui- da as regras do RFC do HTTE Muitos outros protocolos de camada de apticação são proprietários e, inten- «tomalmente, não estão disponíveis ao público. Por exemplo, muitos dos sistemas de compartilhamento de emquivos P2P existentes usam protocolos de camada de aplicação proprietários É importante distinguir aplicações de rede de protocolos de camada de aplicação. Um protocolo de ssitnada de aplicação é apenas um pedaço (embora grande) de aplicação de rede. Examinemos alguns exem- tias. À Web é uma aplicação cliente-servidor que permite aos usuários obter documentos de servidores Web pur demanda. A aplicação Web consiste em. muitos componentes, entre eles um padrão para formato de «focumentos (isio é, FITML), browsers Web (por exemplo, Netscape Navigator e Mictosoit Internet Explorer), servidores Web (por exemplo, servidores Apache, Microsoft e Netscape) e um protocolo de Redes do compuiadores e o Internet camada de aplicação. O protocolo de camada de aplicação da Web, HTTP, define o formato e a segiência das mensagens que são passadas entre o browser e o servidor Web. Assim, ele é apenas um pedaço da apli- cação Web, Como outro exemplo, considere a aplicação correio eletrônico da Intemet. O correio eletrôni- co da Imemet também tem muitos componentes, entre eles servidores de correio que armazenam caixas postais de usuários, leitores de correio que permitem aos usuários ler é criar mensagens, um padrão que define como mensagens são passadas entre servidores e entre servidores € feitores de correio « como o con- teúdo de certas partes da mensagem de correio (por exemplo, um cabeçalho) deve ser interpretado. O prin- cipal protocolo de camada de aplicação para o correio eletrônico é o SMTP — Simple Mail Protocol [RFC 28211. Assim, o SMTP é apenas um pedaço (embora grande) da aplicação correio eletrônico. 2.1.4 De gue serviços uma aplicação necessita? Lembre-se de que um socket é a interface entre o processo da aplicação e o protocolo de camada de transporte, À aplicação do lado remetente envia mensagens através da porta. Do outro lado da porta, o pro- tocolo de camada de transporte tem a responsabilidade de levar as mensagens pela rede até a porta do pro- cesso destinatário. Muitas redes, inclusive a Internet, oferecem mais de um protocolo de camada de trans- porte. Ao desenvolver uma aplicação, você deve escolher um dos protocolos de camada de transporte disponíveis. Como fazer essa escolha? O mais provável é que você avalie os serviços providos pelos proto- colos de camada de transporte disponíveis e escolha o protocolo que melhor atenda às necessidades de sua aplicação. A situação é semelhante a escolher trem ou avião como meio de transporie entre duas cidades. Você 1em de escolher um ou outro, e cada modalidade de transporte oferece serviços diferentes. Por exem- plo, o trem olerece a facilidade da partida e da chegada no ceuiro da cidade, ao passo que o avião oferece menor tempo de viagem. Quais são os serviços que uma aplicação necessitaria de um protocolo de transporte? Podemos classi- ficar, de maneira geral, as necessidades de serviço de uma aplicação segundo três dimensões: perda de dados, largura de banda e temporização. Transferência confiável de dados Algumas aplicações, como correio eletrônico, mensagem instantânea, transferência de arquivos, acesso a hospedeiros remotos, transferência de documentos Web e aplicações financeiras, exigem transferência de dados totalmente confiável, isto é. não pode haver perda de dados. Em particular, a perda de dados de arqui- vo ou de uma transação financeira pode ter consequências devastadoras (no último caso, tanto para o banco quanto para o cliente), Outras aplicações tolerantes a perda, mais notavelmente aplicações de multimídia, como áudio/vídeo em tempo real ou áudivívideo armazenados, podem tolerar uma certa perda de dados. Nessas últimas aplicações, dados perdidos podem resultar em uma pequena falha durante a execução do dudio/vídeo — o que não é um prejuízo crucial. Os efeitos dessa perda sobre a qualidade da aplicação e a quan- tidade real tolerável de perda de pacotes dependerão muito da aplicação e do esquema de codificação usado. Largura de bando“ Algumas aplicações têm de transmitir dados a uma certa velocidade para serem efetivas. Por exemplo, se uma aplicação de telefonia por Internet codifica voz a 32 kbps, então também deve poder enviar dados para a tede e fazer com que sejam entregues na aplicação receptora a essa mesma taxa, Se essa largura de banca não estiver disponível, a aplicação precisará codificar a uma taxa diferente (e receber largura de banda suficiente para sustentar essa taxa de codificação diferente) ou então desistir, já que receber metade da largura de banda de que precisa de nada adianta para ta! aplicação sensível à largura de banda, Muíias aplicações de multimídia existentes são sensíveis à largura de banda, mas as futuras poderão usar técnicas adaptativas de codi- Apesar de este não ser o terimo mais preciso para definir o conceito apresentado, optou-se por respeitar à esculha de antor (Dandwidih). (N. do RTS Redes de computadores e à Internet RS SO a ec EEMS Serviço orientado para conexão: « TCP faz com que o cliente e o servidor troquem informações de controle de camada de transporte antes que as mensagens de camada de apiicação comecem a fluir. Esse procedimento de apresentação, por assim dizer, alerta o cliente e o servidor, permitindo que eles se preparem para wma enxurrada de pacotes. Após a fase de apresentação, dizemos que existe uma conexão TCP entre as portas dos dois processos. A conexão é full-duplex (simmulta- nea), visto que os dois processos podem enviar mensagens um ao outro pela conexão ao mesmo tempo. Quando termina de enviar mensagens, a aplicação deve interromper a conexão. Esse sex- viço é chamado de serviço “orientado para conexão”, e não serviço “de conexão”, porque os dois processos estão conectados de um modo muito solto. No Capítulo 3, discutiremos detalhadamente serviço orientado para conexão e examinaremos como ele é implementado. BEAR Serviço confiável de transporte: os processos comunicantes podem confiar no TCP para a entrega de todos os dados enviados sem erro e nia ordem correta. Quando um lado da aplicação passa uma cadeia de bytes para dentro de um socket, pode contar com o TCP para entregar a mesma cadeia de dadas ao socket receptor, sem falta de bytes nem bytes duplicados. O TCP também. inclui um mecanismo de controle de congestionamento, um serviço voltado ao bem- estar geral da Internet e não ao benefício direto dos processos comunicantes. O mecanismo de controle de congestionamento do TCP limita a capacidade de transmissão de um processo (cliente ou servidor) quando a rede está congestionada entre cliente e servidor. Em particular, como veremos no Capítulo 3, o controle de congestionamento do TCP tenta limitar cada conexão do TCP à sua justa porção de largura de banda de rede. A limitação da velocidade de transmissão pode ter um eleito muito prejudicial sobre aplicações de áudio e vídeo em tempo real que imponham uma limitação de largura de banda mínima. Além disso, apli- cações em tempo reaí são tolerantes à perda e não necessitam de um serviço de transporte totalmente con- fiável. Por essas razões, desenvolvedores de aplicações em tempo real usualmente executam suas aplicações em UDP, e não em TCP Delineados os serviços providos pelo TCP, vamos falar um pouco dos serviços que o TCP não oferece. Em primeiro lugar, o TCP não garante uma taxa de transmissão mínima. Em particular, não é permitido a um processo originador transmitir com a taxa que hem entender; em vez disso, ela € regulada pelo controle de congestionamento do YCP, que pode forçar o remetente a enviar dados a uma taxa média baixa. Em segundo lugar, o TCP não oferece nenhuma garantia quanto a atrasos. Em particular, quando um processo originador p dados para dentro de um socket, os dados cedo ou tarde chegarão ao processo receptor, mas o TCP não garante absolutamente nenhum limite de tempo para que eles cheguem lá. Como já acon- teceu com muitos de nós, no caso da “espera mundial”, às vezes licamos esperando por dezenas de segundos ou até minttos para que o TCP entregue uma mensagem (contendo, por exemplo, um arquivo HTML) do servidor ao cliente Web. Em resumo, o TCP garante a entrega de todos os dados, mas não dá nenhuma garantia quanto à velocidade de entrega ou aos atrasos experimentados. Serviços do EDP O UDP é um protocolo de iransporte simplificado, leve, com um modelo de serviço minimalista. É um serviço não orientado para conexão: portanto, não há apresentação antes que os dois processos comecem a se comunicar. O UDP provê um serviço não confiável de transferência de dados — isto é, quando um pro- cesso envia uma mensagem para dentro de um socket UDP o protocolo não oferece nenhuma garantia de que a mensagem chegará ao processo receptor. Além do mais, mensagens que reahmente chegam ao processo receptor podem chegar tora de ordem. O UDP não inclui um mecanismo de controle de congestionamento: portanto, um processo originador pode bombear dados para dentro de um socket UDP a taxa que quiser (embora nem todos os dados consi- gam alcançar o socket receptor). Como aplicações em tempo rcal usualmente podem tolerar uma certa perda de dados, mas exigem uma taxa mínima, desenvolvedores desse tipo de aplicações frequentemente preferem executá-las por UDP, evitando, assim, o controle de congestionamento e os cabeçalhos de pacetes do TCP Similarmente ao TCP 9 UDP não oferece nenhuma garantia quanto a atras Capítulo 2 Camada de uplicação NÓS DT Sr nas Aplicações Protocola de comudo de uplicação Protocolo de transporte . subjucente Correio eletrônico SMTP (RFC 2821) TCP Acesso a terminal remoto Telnet (RFC 854) Te web HTTP (RFC 2616) , TCP Transferência de arquivos FTP (RFC 959) o TCR Servidor remoto de arquivos NES (McKusik, 1996) UDP qu TCP Multimídia em tempo real Quase sempre proprietária (por exemplo, Real Networks) UDP ou TCP - - Telefonia por Internet Quase sempre proprietária (por exemplo, Net2phone) o Tipicamente UDP o Figura 2.5 Aplicações populares da Interne?, seus protocolos de comado de eplicação e seus protocolos de transporte subjucentes A Figura 2.5 mostra os protocolos de transporte usados por algumas aplicações populares da Internet. Vemos que e-mail, a Web, acesso a terminais remotos e 1ransferência de arquivos usam o TCP. Essas aplica- ções escolheram o TCP primordialmente porque ele oferece um serviço confiável de transferência de dados, garantindo que todos eles mais cedo ou mais tarde cheguem a seu destino. Vemos também que a aplicação de telefonia por Internei normalmente funciona em UDP Cada lado de uma aplicação de telefone por Internet precisa enviar dados pela rede a uma taxa minima (veja a Figura 2.4). o que é mais provavelmente possível com UDP do que com TCP E, também, aplicações de telefone por Internet são tolerantes às perdas, de modo que não necessitam do serviço confiável de transferência de dados provido pelo TCP. Como já observamos anteriormente, nem o TCP nem o UDP oferecem garantia de temporização. Isso significa que aplicações sensíveis a atrasos não podem ser executadas na internet de hoje? A resposta é cla- ramente “sim, elas podem” — a Internet abriga aplicações desse tipo há muitos anos. Essas aplicações em geral funcionam razoavelmente bem porque foram projetadas para enfrentar, até onde for possível, essa fatia de garantia. Examinaremos diversos desses truques de projeto no Capítulo 7. Porém, mesmo o projeto inte- ligente tem suas limitações quando o atraso é excessivo, como frequentemente é o caso da Internet pública. Em resumo, hoje, a Inemet pode prover serviço satisfatório a aplicações sensíveis ao atraso, mas não pode oferecer nenhuma garantia de temporização ou de largura de banda, No Capítulo 7, discutiremos também modelos emergentes de servicos de Internet que oferecem novos serviços, inclusive serviço de garantia con- tra atrasos para aplicações em tempo real. 2.1.6 Aplicações de rede abordadas neste livro Novas aplicações de Interner de domínio público e proprietárias são desenvolvidas todos os dias. Em vez de tratamos de um grande número dessas aplicações de maneira enciclopédica, preferimos focalizar um pequeno número de aplicações ao mesmo tempo importantes e populares. Neste capítulo, discutiremos cinco aplicações populares: a Weh, a transferência de arquivos, o correio eletrônico, o serviço de diretório e o com- partilhamento de arquivos PZP Discutiremos primeiramente a Web não somente porque ela é uma aplicação imensamente popular, mas também porque seu protocolo de camada de aplicação, HTTP, é direto e Jaci! de emtender. Após examinarmos a Web, examinaremos brevemente o FTP porque este protocolo olerece um ótimo contraste com o HITE Em seguida, discutiremos o correio eletrônico, a primeira aplicação de enorme sucesso da Internet. O correio eletrônico é mais complexo do que a Web, no sentido de que usa não somen- te um, mas vários protocolos de camada de aplicação. Após o e-mail, estudaremos o DNS, que prove um ser- viço de diretório para a Internet. À maioria dos usuários não interage diretamente com o DNS; em vez disso, eles q chamam indivetamente por meio de ouiras aplicações (nclusive a Web, a transferência de anquivos e o correio eletrônico). O DNS ilustra primorosamente como um componente de funcionalidade ee múcle de rede (tradução de nome de rede para endereço de rede) pode ser implementado na camada de aplicação da Internet, Finalmente, discutiremos o compartilhamento de arquivos P2P que, segundo algumas med (por exemplo, tráfego de rede), é a classe de aplicações mais popular da Internet de hoje. 
