Ultimate Protocolos de Camada de Aplicação

Prévia do material em texto

UNIVERSIDADE LICUNGO 
 
FACULDADE DE CIÊNCIAS E TECNOLOGIA 
 
LICENCIATURA EM INFORMÁTICA 
 
 
Dário Gildo de Carvalho 
Iquirato Luís Damião 
Mercito Francisco Ordem 
Mildo Álvaro Sortane 
Sanito António Vilichane 
YuranSpriwelGuilherme 
Yuran Mário Maboia 
 
 
Protocolos da Camada de Aplicação 
4º Grupo 
 
 
 
 
 
Quelimane 
2022 
 
Dário Gildo de Carvalho 
Iquirato Luís Damião 
Mercito Francisco Ordem 
Mildo Álvaro Sortane 
Sanito António Vilichane 
YuranSpriwelGuilherme 
Yuran Mário Maboia 
 
 
 
Protocolos da Camada de Aplicação 
4º Grupo 
 
 
Trabalho de Carácter avaliativo a ser 
entregue no Departamento de 
Ciências e Tecnologias na Cadeira de 
Protocolos de Comunicação, 
lecionada pelo: 
Eng. Avelino Victor Eduardo 
 
 
 
Quelimane 
2022 
Índice 
1. INTRODUÇÃO ........................................................................................................................... 4 
2. Objectivos .................................................................................................................................... 5 
2.1. Geral ....................................................................................................................................... 5 
2.2. Objectivos Específicos ............................................................................................................. 5 
3. Metodologia do Projecto ............................................................................................................. 5 
4. CAMADA DE APLICAÇÃO ..................................................................................................... 6 
4.1. PROTOCOLOS DE CAMADA DE APLICAÇÃO ................................................................. 7 
4.1.1. DNS — DOMAIN NAME SYSTEM ................................................................................... 7 
4.1.2. CORREIO ELETRÔNICO.................................................................................................... 8 
4.1.2.1. ARQUITETURA E SERVIÇOS ................................................................................... 9 
4.1.2.2. O AGENTE DO USUÁRIO ............................................................................................. 10 
4.1.2.3. TRANSFERÊNCIA DE MENSAGENS .......................................................................... 10 
4.1.3. SMTP — Simple Mail Transfer Protocol ............................................................................ 10 
4.1.3.1. ENTREGA FINAL ........................................................................................................... 11 
4.1.4. POP3 .................................................................................................................................... 11 
4.1.5. IMAP ................................................................................................................................... 12 
4.1.6. A WORLD WIDE WEB ..................................................................................................... 12 
4.1.7. HTTP — HYPERTEXT TRANSFER PROTOCOL .......................................................... 14 
4.1.7.1. Conexões .......................................................................................................................... 14 
4.1.7.2. Métodos ............................................................................................................................ 15 
4.1.8. APERFEIÇOAMENTOS DE DESEMPENHO .................................................................. 16 
4.1.8.1. A WEB SEM FIOS .......................................................................................................... 16 
4.1.8.2. WAP — Wireless Application Protocol ........................................................................... 16 
4.1.9. FILE TRANSFER PROTOCOL – FTP .............................................................................. 17 
4.1.10. TRIVIAL FILE TRANSFER PROTOCOL – TFTP ......................................................... 17 
4.1.11. TELNET ............................................................................................................................ 18 
4.1.12. SIMPLE NETWORK MANAGEMENT PROTOCOL – SNMP ..................................... 18 
4.1.13. NETWORK FILE SYSTEM – NFS .................................................................................. 19 
4.1.14. ROUTING INFORMATION PROTOCOL – RIP ............................................................ 19 
4.1.15. Real-time Transport Protocol - RTP .................................................................................. 20 
4.1.16. Secure Socket Shell - SSH ................................................................................................ 20 
4.1.17. Session Initiation Protocol - SIP ........................................................................................ 21 
4.1.18. Remote Desktop Protocol - RDP ....................................................................................... 22 
4.1.19. Internet relay chat - IRC .................................................................................................... 22 
5. CONCLUSÃO ........................................................................................................................... 23 
6. REFERENCIA BIBLIOGRAFICA ........................................................................................... 24 
4 
 
 
 
1. INTRODUÇÃO 
Nos anos 60, o principal sector estratégico americano, Departmentof Defense – DoD se 
interessou em um protocolo que estava sendo desenvolvido/utilizado pelas universidades para 
interligação dos seus sistemas computacionais e que utilizava a tecnologia de chave de pacotes. O 
interesse do DoD estava no desejo de manter a comunicação entre os diversos sistemas espalhados 
pelo mundo, no caso de um desastre nuclear. O problema maior estava na compatibilidade entre os 
sistemas computacionais de diferentes fabricantes que possuíam diferentes sistemas operacionais, 
topologias e protocolos. 
A integração e compartilhamento dos dados passou a ser um problema de difícil resolução. 
Foi atribuído assim à Advanced Research ProjectsAgency – ARPA a tarefa de encontrar uma 
solução para este problema de tratar com diferentes equipamentos e diferentes características 
computacionais. Foi feita então uma aliança entre universidades e fabricantes para o 
desenvolvimento de padrões de comunicação. Esta aliança especificou e construiu uma rede de 
teste de quatro nós, chamada ARPANET, e que acabou sendo a origem da Internet hoje. 
No final dos anos 70, esta rede inicial evoluiu, teve seu protocolo principal desenvolvido e 
transformado na base para o TCP/IP (Transmition Control Protocol / Internet Protocol). A 
aceitação mundial do conjunto de protocolos TCP/IP deveu-se principalmente a versão UNIX de 
Berkeley que além de incluir estes protocolos, colocava-os em uma situação de domínio público, 
onde qualquer organização, através de sua equipe técnica poderia modificá-los e assim garantir seu 
desenvolvimento. 
Dentre as várias organizações e comités que participaram deste desenvolvimento e 
divulgação, podemos destacar Internet EngineeringTask Force – IETF (http://www.ietf.org) cuja 
principal função actual é a manutenção e apoio aos padrões da Internet e TCP/IP principalmente 
através da série de documentos Request for Comments - RFC. Estes documentos descrevem as 
diversas tecnologias envolvidas e servem de base para as novas tecnologias que deverão manter a 
compatibilidade com as anteriores dentro do possível. O maior trunfo do TCP/IP é o fato destes 
protocolos apresentarem a interoperabilidade de comunicação entre todos os tipos de hardware e 
todos os tipos de sistemas operacionais. Sendo assim, o impacto positivo da comunicação 
computacional aumenta com o número de tipos computadores que participam da grande rede 
Internet. E no trabalho iremosfalar acerca dos protocolos da camada de aplicação entre os vários 
protocolos iremos abordar apenas os protocolos nomeadamente: DNS, RIP, http, NFS, SMTP, 
SNMP, TELNET, TFTP, FTP, POP3, IMAP. 
5 
 
 
 
2. Objectivos 
2.1. Geral 
 Compreender a camada de aplicação. 
2.2. Objectivos Específicos 
 Debruçar sobre os principais conceitos da camada de aplicação; 
 Distinguir os protocolos da camada de aplicação; 
 Apontar a forma de funcionamento de cada protocolo de comunicação. 
 
3. Metodologia do Projecto 
Metodologia é o caminho do pensamento e a prática exercida na abordagem da realidade 
(MINAYO, 1996:16), ou seja, disciplina que se ocupa de estudar e ordenar (no possível) e em 
conformidade com COHN, (1992), realça que a metodologia é o caminho pelo qual fazemos algo, 
de maneira a atingir um objectivo; é a base mental para o exercício de uma actividade que se 
deseja eficaz; exige a organização do conhecimento e experiências prévias 
Para esta elaboração deste trabalho foi usado o método de revisão bibliográfica que 
consistiu na leitura, análise e interpretação de informações contidas em várias literaturas que 
abordam o tema em epígrafe. Neste processo de revisões bibliográficas, foi feita uma procura de 
diferentes ferramentas para protocolos da camada de aplicação tendo-se procedido à comparação 
entre elas. 
Em seguida foram realizadas revisões de site com a finalidade de adquirir conhecimentos 
básicos e específicos sobre a metodologia de desenvolvimento de projectos de web site. 
 
 
6 
 
 
 
4. CAMADA DE APLICAÇÃO 
A camada de aplicação é utilizada em redes de computadores para designar uma camada 
de abstração que engloba protocolos que realizam a comunicação fim-a-fim entre aplicações. E é 
responsável por gerenciar e deixar disponível ao usuário, todos os sistemas e ferramentas a ele 
destinados. 
É a camada mais próxima do usuário, na qual é a encarregada quando o cliente acessa o e-
mail, páginas WEB, mensagens instantâneas, Login remoto, vídeo-clipes, videoconferência. 
A arquitectura de aplicação permite que o utilizador acesse essas funções. Existem três 
tipos de arquitectura: Arquitectura cliente-servidor; Arquitectura P2P e Arquitectura híbrida de 
cliente-servidor e P2P. 
Arquitectura cliente-servidor 
A arquitectura cliente servidor é uma arquitectura de aplicação distribuída, ou seja, na rede 
existem os fornecedores de recursos ou serviços a rede, que são chamados de servidores, e existem 
os requerentes dos recursos ou serviços, denominados clientes. 
O cliente não compartilha nenhum de seus recursos com o servidor, mas no entanto, ele 
solicita alguma função do servidor, sendo ele, o cliente, responsável por iniciar a comunicação 
com o servidor, enquanto o mesmo aguarda requisições de entrada. 
Arquitectura P2P 
Arquitectura P2P (peer-to-peer) é uma arquitectura de redes em que cada par, ou nó, coopera entre 
si para prover serviços um ao outro, sem a necessidade a priori de um servidor central. Todos os 
pares são clientes e servidores. 
As redes Par-a-Par, do ingês, Peer-to-peer (sigla P2P), surgem como uma proposta de 
descentralização do monopólio de processamento funcional. Fazendo com que sistemas sirvam a 
outros sistemas, dando a cada estação as mesmas responsabilidades e capacidades dentro da rede. 
Dave Winer da UserLand Software sugere que os sistemas P2P envolvam as seguintes 
características. 
1. Interface de troca de arquivos seja fora do navegador de Internet. 
2. Computadores podem servir tanto como servidores como clientes 
3. Sistemas fáceis de usar e bem integrados. 
4. O sistema deve incluir ferramentas que ajudam usuários que queiram criar ou adicionar 
alguma funcionalidade. 
7 
 
 
 
5. Sistemas que promovam conexão entre usuários 
6. Sistemas que façam algo novo ou excitante 
7. Sistemas que atendam a protocolos "cross-network" como SOAP ou XML-RPC 
Arquitectura híbrida de cliente-servidor e P2P 
A arquitectura híbrida agrega características das duas arquitecturas anteriores. Nessa 
arquitectura, as instruções não são directas ao processador, porém também não estão sobre a 
camada do sistema operacional do hardware hospedeiro. 
 
4.1. PROTOCOLOS DE CAMADA DE APLICAÇÃO 
Os protocolos da camada de aplicação actuam junto com os protocolos da camada de 
transporte (TCP/IP e UDP). Eles definem como os processos de uma aplicação trocam mensagens 
entre si. De seguida vamos debruçar dos protocolos da camada de aplicação. 
4.1.1. DNS — DOMAIN NAME SYSTEM 
Embora os programas teoricamente possam se referir a hosts, caixas de correio e outros 
recursos utilizando seus endereços binários de rede (por exemplo, endereços IP), esses endereços 
são difíceis de memorizar. Além disso, enviar correio electrónico para tana@128.111.24.41 
significa que, se o ISP ou a organização de Tana muar o servidor de correio para uma máquina 
diferente com outro endereço IP, seu endereço de correio electrónico terá de mudar. 
Consequentemente, foram introduzidos nomes em ASCII para desacoplar os nomes das máquinas 
dos endereços dessas máquinas. Desse modo, o endereço de Tana poderia ser algo como 
tana@art.uscb.edu. Todavia, a rede em si só reconhecer endereços numéricos; portanto, é 
necessário algum tipo de mecanismo para converter os strings ASCII em endereços de rede. Nas 
sessões a seguir, estudaremos como esse mapeamento é feito na Internet. Na ARPANET, havia 
simplesmente um arquivo, hosts.txt, que listava todos os hosts e seus endereços IP. Toda noite, 
esse arquivo era acessado por todos os hosts no local em que era mantido. Para uma rede de 
algumas centenas de grandes máquinas de tempo compartilhado, essa estratégia funcionava 
razoavelmente bem. 
No entanto, quando milhares de mini computadores e PCs foram conectadas à rede, todos 
perceberam que essa estratégia não poderia continuar a ser utilizada para sempre. Por um lado, o 
arquivo acabaria por se tornar grande demais. No entanto, a razão mais importante é que poderia 
haver conflitos de nomes de hosts constantemente, a menos que os nomes fossem gerenciados de 
8 
 
 
 
uma forma centralizada, algo totalmente fora de cogitação em uma enorme rede internacional, 
devido à carga e à latência. Para resolver esses problemas, foi criado o DNS (Domain Name 
System — sistema de nomes de domínios). 
A essência do DNS é a criação de um esquema hierárquico de atribuição de nomes baseado 
no domínio e de um sistema de bancos de dados distribuídos para implementar esse esquema de 
nomenclatura. Ele é usado principalmente para mapear nomes de hosts e destinos de mensagens de 
correio electrónico em endereços IP, mas também pode ser usado para outros objectivos. O DNS é 
definido nas RFCs 1034 e 1035. 
Em resumo, o DNS é utilizado da forma descrita a seguir. Para mapear um nome em um 
endereço IP, um programa aplicativo chama um procedimento de biblioteca denominado 
resolvedor e repassa a ele o nome como um parâmetro. Vimos um exemplo de resolvedor, 
gethostby name. O resolvedor envia um pacote UDP a um servidor DNS local, que procura o nome 
e retorna o endereço IP ao resolvedor. Em seguida, o resolvedor retorna o endereço IP ao programa 
aplicativo que fez a chamada. Munido do endereço IP, o programa pode então estabelecer uma 
conexão TCP com o destino ou enviar pacotes UDP até ele. 
4.1.2. CORREIO ELETRÔNICO 
O correio electrónico — ou e-mail, como é chamado por muitos de seus fãs — já existe há 
mais de duas décadas. Antes de 1990, ele era empregado principalmente nos meios académicos. 
Durante os anos 90, ficou conhecido para o público em geral e seu uso cresceu exponencialmente, 
até alcançar um número de mensagens de correio electrónico enviadas por dia imensamente maior 
que o número de cartas remetidas pelo correio convencional (isto é, cartas escritas em papel). 
Como a maioria das outras formas de comunicação, o correio electrónico tem suas próprias 
convenções e estilos. Em particular,é muito informal e tem baixo limiar de uso. Pessoas que nunca 
sonhariam telefonar ou mesmo escrever uma carta para uma pessoa muito importante não hesitam 
nem um segundo em enviar uma mensagem de correio electrónico escrita às pressas e sem 
cuidado. 
O correio electrónico está repleto de elementos de jargão, como AP (A Propósito), RCTR 
(Rolando no Chão de Tanto Rir) e EMHO (Em Minha Humilde Opinião). Muitas pessoas também 
empregam pequenos símbolos ASCII chamados smileys ou emoticons em suas mensagens de 
correio electrónico. 
9 
 
 
 
4.1.2.1.ARQUITETURA E SERVIÇOS 
Em geral, eles consistem em dois subsistemas: os agentes do usuário, que permitem que as 
pessoas leiam e enviem mensagens, e os agentes de transferência de mensagens, que deslocam as 
mensagens da origem até o destino. Os agentes do usuário são programas locais que oferecem um 
método baseado em comandos, baseado em menus ou gráfico para interagir com o sistema de 
correio electrónico. Normalmente, os agentes de transferência de mensagens são daemons do 
sistema, ou seja, processos executados no segundo plano. Sua tarefa é mover as mensagens de 
correio electrónico pelo sistema. 
Em geral, os sistemas de correio electrónico admitem cinco funções básicas. Vamos 
examiná-las. A composição se refere ao processo de criar mensagens e respostas. Apesar de 
qualquer editor de textos poder ser usado para o corpo da mensagem, o sistema em si pode auxiliá-
lo com o endereçamento e com os inúmeros campos de cabeçalho associados a cada mensagem. 
Por exemplo, quando responde a uma mensagem, o sistema de correio electrónico pode extrair o 
endereço do remetente da mensagem recebida e incluí-lo automaticamente no lugar adequado da 
resposta. 
A transferência se refere ao deslocamento de uma mensagem entre o remetente e o 
destinatário. Em geral, isso exige o estabelecimento de uma conexão com o destino ou com alguma 
máquina intermediária, a transmissão de uma mensagem e o encerramento da conexão. O sistema 
de correio electrónico pode fazer isso automaticamente, sem perturbar o usuário. 
A geração de relatórios está relacionada ao fato de informar o remetente sobre o que 
aconteceu com a mensagem. Ela foi entregue? Foi rejeitada? Perdeu-se? Existem inúmeras 
aplicações em que a confirmação da entrega da mensagem é importante e pode ter até mesmo 
significação legal ("Bem, Excelência, meu sistema de correio electrónico não é confiável. Acho 
que a intimação electrónica que me enviaram se perdeu em algum lugar"). 
A exibição das mensagens recebidas é necessária para que as pessoas possam ler suas 
mensagens de correio electrónico. Às vezes, é preciso fazer a conversão ou invocar um 
visualizador especial, como acontece quando a mensagem é um arquivo PostScript ou de voz 
digitalizada. Algumas vezes, também há tentativas de conversões e formatações simples. 
10 
 
 
 
A disposição é a última etapa e se refere ao que o destinatário faz com a mensagem depois 
de recebê-la. Dentre as possibilidades estão: jogá-la fora, gravá-la etc. Também deveria ser 
possível recuperar e reler as mensagens gravadas, encaminhá-las ou processá-las de outras formas. 
4.1.2.2. O AGENTE DO USUÁRIO 
Os sistemas de correio electrónico tê m duas partes básicas, como vimos anteriormente: os 
agentes do usuário e os agentes de transferência de mensagens. Nesta sessão, estudaremos os 
agentes do usuário. Em geral, um agente do usuário é um programa (às vezes, chamado de leitor de 
correio electrónico) que aceita uma variedade de comandos para composição (ou redação), 
recebimento e resposta a mensagens, bem como para manipular caixas de correio. Alguns agentes 
do usuário têm uma sofisticada interface baseada em menus ou ícones que exige um mouse, 
enquanto outros esperam receber comandos de 1 carácter do teclado. Porém, em termos funcionais, 
essas interfaces são iguais. Alguns sistemas são comandados por meio de ícones ou menus, mas 
também têm atalhos pelo teclado. 
4.1.2.3. TRANSFERÊNCIA DE MENSAGENS 
4.1.3. SMTP — Simple Mail TransferProtocol 
Dentro da Internet, as mensagens de correio electrónico são entregues quando a máquina de 
origem estabelece uma conexão TCP com a porta 25 da máquina de destino. Um daemon de 
correio electrónico, que se comunica em SMTP (Simple Mail TransferProtocol) permanece na 
escuta nessa porta. Esse daemon aceita as conexões recebidas e copia as mensagens que elas 
contêm para as caixas de correio apropriadas. Se uma mensagem não puder ser entregue, um 
relatório de erros contendo a primeira parte da mensagem não entregue será retornado ao 
remetente. 
O SMTP é um protocolo ASCII muito simples. Após estabelecer a conexão TCP com a 
porta 25, a máquina de transmissão, operando como cliente, espera que a máquina de recepção, 
operando como servidor, comunique-se primeiro. O servidor começa enviando uma linha de texto 
que fornece sua identidade e informa que está preparado para receber mensagens. Caso não esteja, 
o cliente encerrará a conexão e tentará outra vez mais tarde. Se o servidor estiver disposto a 
receber mensagens, o cliente anunciará de quem veio a mensagem e para quem ela está indo. Se 
esse receptor existir no local de destino, o servidor dará ao cliente o sinal para enviar a mensagem. 
Em seguida, o cliente enviará a mensagem e o servidor a confirmará. Não são necessários totais de 
verificação, porque o TCP fornece um fluxo de bytes confiável. Se houver mais mensagens, elas 
11 
 
 
 
serão enviadas. Quando todas as mensagens tiverem sido trocadas em ambos os sentidos, a 
conexão será encerrada. 
4.1.3.1. ENTREGA FINAL 
Até agora, supomos que todos os usuários têm máquinas capazes de enviar e receber 
mensagens de correio electrónico. Como vimos, o correio electrónico é entregue fazendo-se o 
remetente estabelecer uma conexão TCP para o destinatário, e depois transmitir a mensagem por 
ela. Esse modelo funcionou bem durante décadas, quando todos os hosts da ARPANET (e mais 
tarde da Internet) estavam de fato on-line o tempo todo para aceitar conexões TCP. Entretanto, 
com o advento de pessoas que acessam a Internet chamando seu ISP por modem, o modelo falha. 
O problema é este: o que acontece quando Elinor quer enviar a Carolyn uma mensagem de correio 
electrónico e Carolyn não está on-line no momento? Elinor não pode estabelecer uma conexão 
TCP para Carolyn e, desse modo, não pode executar o protocolo SMTP. Uma solução é fazer um 
agente de transferência de mensagens em uma máquina do ISP aceitar correio electrónico para seus 
clientes e armazená-lo nas respectivas caixas de correio, na máquina do ISP. Tendo em vista que 
esse agente pode estar on-line o tempo todo, as mensagens de correio electrónico podem ser 
enviadas para ele 24 horas por dia. 
4.1.4. POP3 
Infelizmente, essa solução cria outro problema: como o usuário conseguirá o correio 
electrónico do agente de transferência de mensagens do ISP? A solução para esse problema é criar 
outro protocolo que permita aos agentes de transferência do usuário (em PCs clientes) entrar em 
contacto com o agente de transferência de mensagens (na máquina do ISP) e permitir que as 
mensagens de correio electrónico sejam copiadas do ISP para o usuário. Um protocolo desse tipo é 
o POP3 (Post Office Protocol Version 3), descrito na RFC 1939. 
O POP3 começa quando o usuário inicia o leitor de correio. O leitor de correio chama o ISP 
(a menos que já exista uma conexão) e estabelece uma conexão TCP com o agente de transferência 
de mensagens na porta 110. Depois que a conexão é estabelecida, o protocolo POP3 passa por três 
estados em sequência: Autorização, Transação e Actualização. 
O estado de autorização lida com o login do usuário. O estado de transação lida com a 
colecta de mensagens de correio electrónico do usuário e com a marcação das mensagens para 
12 
 
 
 
exclusão da caixa de correio. Na realidade, o estado de actualização faz a mensagens de correioelectrónico serem excluídas. 
4.1.5. IMAP 
Para um usuário uma conta de correio electrónico em um ISP que é sempre acessado a 
partir de um único PC, o POP3 funciona muito bem e é amplamente usado devido à sua 
simplicidade e robustez. Porém, é um clichê da indústria de informática que, tão logo algo 
funciona bem, alguém começa a exigir mais recursos (e a receber mais bugs). Isso também 
aconteceu com o correio electrónico. Por exemplo, muitas pessoas têm uma única conta de correio 
electrónico no trabalho ou na escola e querem acessá-la no trabalho, em seu PC de casa, no laptop 
quando estão viajando a negócios e em cybercafés quando estão em férias. Embora o POP3 torne 
isso possível, pois normalmente ele baixa todas as mensagens armazenadas em cada contacto, o 
resultado é que o correio electrónico do usuário logo fica espalhado por várias máquinas, mais ou 
menos ao acaso, e algumas delas nem mesmo pertencem ao usuário. 
Essa desvantagem deu origem a um protocolo alternativo de entrega final, o IMAP 
(Internet Message Access Protocol), definido na RFC 2060. Diferente do POP3, que basicamente 
supõe que o usuário limpará a caixa de correio em cada contacto e trabalhará off-line depois disso, 
o IMAP pressupõe que todas as mensagens de correio electrónico permanecerão no servidor 
indefinidamente, em várias caixas de correio. O IMAP fornece mecanismos extensos para leitura 
de mensagens ou mesmo partes de mensagens, um recurso útil quando se utiliza um modem lento 
para ler a parte de texto de uma mensagem de várias partes com grandes anexos de áudio e vídeo. 
Tendo em vista que a suposição funcional é que as mensagens não serão transferidas para o 
computador do usuário com a finalidade de armazenamento permanente, o IMAP fornece 
mecanismos para criar, destruir e manipular várias caixas de correio no servidor. Desse modo, um 
usuário pode manter uma caixa de correio para cada correspondente e mover as mensagens da 
caixa de entrada para essas caixas depois que elas forem lidas. 
4.1.6. A WORLD WIDE WEB 
A WorldWide Web é uma estrutura arquitectónica que permite o acesso a documentos 
vinculados espalhados por milhões de máquinas na Internet. Em dez anos, ela deixou de ser um 
meio de distribuição de dados sobre física de alta energia para se tornar a aplicação que milhões de 
pessoas consideram ser "A Internet". Sua enorme popularidade se de ve à sua interface gráfica 
13 
 
 
 
colorida, de fácil utilização para principiantes. Além disso, ela oferece uma imensa variedade de 
informações sobre quase todos os assuntos imagináveis, desde aborígenes até zoologia. 
A World Wide Web é uma estrutura arquitectónica que permite o acesso a documentos vinculados 
espalhados por milhões de máquinas na Internet. Em dez anos, ela deixou de ser um meio de 
distribuição de dados sobre física de alta energia para se tornar a aplicação que milhões de pessoas 
consideram ser "A Internet". Sua enorme popularidade se deve à sua interface gráfica colorida, de 
fácil utilização para principiantes. Além disso, ela oferece uma imensa variedade de informações 
sobre quase todos os assuntos imagináveis, desde aborígenes até zoologia. 
A proposta inicial para uma teia de documentos vinculados veio de um físico do CERN, 
Tim BernersLee, em Março de 1989. O primeiro protótipo (no modo texto) já era operacional um 
ano e meio depois. Em Dezembro de 1991, foi realizada uma demonstração pública na conferência 
Hypertext ‘91, em San António, no Texas. 
Essa demonstração e a publicidade resultante atraíram a atenção de outros pesquisadores, o 
que levou Marc Andreessen, da Universityof Illinois, a iniciar o desenvolvimento do primeiro 
navegador gráfico, o Mosaic, lançado em Fevereiro de 1993. O Mosaic se tornou tão popular que, 
um ano mais tarde, Andreessen fundou sua própria empresa, a Netscape Communications Corp., 
cujo objectivo era desenvolver clientes, servidores e outros produtos de software para a Web. 
Quando a Netscape abriu seu capital ao público em 1995, os investidores, aparentemente 
pensando que ela seria a sucessora da Microsoft, pagaram 1,5 bilhão de dólares por suas acções. 
Esse recorde foi ainda mais surpreendente porque a empresa tinha apenas um produto, operava no 
vermelho e já havia anunciado que não previa a possibilidade de lucros para um futuro próximo. 
Nos três anos seguintes, o Netscape Navigator e o Internet Explorer da Microsoft se engajaram em 
uma "guerra de navegadores", cada um procurando incluir mais recursos (e, portanto, mais bugs) 
qu e o outro. Em 1998, o América Online comprou a Netscape Communications Corp. por 4,2 
bilhões de dólares, encerrando assim a breve vida da Netscape como empresa independente. 
Em 1994, o CERN e o MIT assinaram um acordo criando o World Wide Web Consortium 
(às vezes abreviado como W3C), uma organização voltada para o desenvolvimento da Web, a 
padronização de protocolos e para o incentivo à interoperabilidade entre os sites. Berner s-Lee 
tornou-se o director do consórcio. Desde então, centenas de universidades e empresas juntaram-se 
ao consórcio. Embora existam agora mais livros sobre a Web do que se pode imaginar, o melhor 
14 
 
 
 
lugar para obter informações actualizadas sobre a Web é (naturalmente) a própria Web. A 
homepage do consórcio está no endereço www.w3.org. Os leitores interessados são levados por 
links a páginas que englobam todos os numerosos documentos e actividades de consórcio. 
4.1.7. HTTP — HYPERTEXT TRANSFER PROTOCOL 
O protocolo de transferência utilizado em toda a World Wide Web é o HTTP (Hyper Text 
Transfer Protocol). Ele especifica as mensagens que os clientes podem enviar aos servidores e que 
respostas eles receberão. Cada interacção consiste em uma solicitação ASCII, seguida por uma 
resposta RFC 822 semelhante ao MIME. Todos os clientes e todos os servidores devem obedecer a 
esse protocolo. Ele é definido na RFC 2616. Nesta sessão, estudaremos algumas de suas 
propriedades mais importantes. 
4.1.7.1. Conexões 
O modo habitual de um navegador entrar em contacto com um servidor é estabelecer uma 
conexão TCP para a porta 80 da máquina servidora, embora esse procedimento não seja exigido 
formalmente. O vantagem de se usar o TCP é que nem os navegadores nem os servidores têm de se 
preocupar com mensagens perdidas, mensagens duplicadas, mensagens longas ou confirmações. 
Todos esses assuntos são tratados pela implementação do TCP. 
No HTTP 1.0, depois que a conexão era estabelecida, uma única solicitação era enviada e 
uma única resposta era devolvida. Então, a conexão TCP era encerrada. Em um mundo no qual as 
páginas da Web típicas consistiam inteiramente em texto HTML, esse método era adequado. Após 
alguns anos, a página da Web média continha grandes números de ícones, imagens e outros 
atractivos visuais, e assim o estabelecimento de uma conexão TCP para transportar um único ícone 
se tornou um modo de operação muito dispendioso. 
Essa observação levou ao lançamento do HTTP 1.1, que admite conexões persistentes. 
Com elas, é possível estabelecer uma conexão TCP, enviar uma solicitação e obter uma resposta, e 
depois enviar solicitações adicionais e receber respostas adicionais. Amortizando o custo da 
instalação e da liberação do TCP por várias solicitações, o over head relativo devido ao TCP é 
muito menor por solicitação. Também é possível transportar as solicitações por pipeline, ou seja, 
enviar a solicitação 2 antes de chegar a resposta à solicitação 1. 
15 
 
 
 
4.1.7.2. Métodos 
Embora o HTTP tenha sido projectado para utilização na Web, ele foi criado de modo mais 
geral que o necessário, visando às futuras aplicações orientadas a objectos. Por essa razão, são 
aceitas operações chamadas métodos, diferentes da simples solicitação de uma página da Web. 
Essa generalidade permitiu que o SOAP viesse a existir. Cada solicitação consiste em uma ou mais 
linhas de texto ASCII, sendo a primeira palavra daprimeira linha o nome do método solicitado. Os 
métodos internos estão listados na Figura 7.41. Para acessar objectos gerais, também podem estar 
disponíveis métodos adicionais específicos de objectos. Os nomes diferenciam letras maiúsculas de 
minúsculas; portanto, GET é um método válido, mas get não é. 
O método GET solicita ao servidor que envie a página (ou objecto, no caso mais genérico; 
na prática, apenas um arquivo). A página é codificada em MIME de forma adequada. A grande 
maioria das solicitações a servidores da Web tem a forma de métodos GET. 
O método HEAD solicita apenas o cabeçalho da mensagem, sem a página propriamente 
dita. Esse método pode ser usado para se obter a data da última modificação feita na página, para 
reunir informações destinadas à indexação, ou apenas para testar a validade de um URL. 
O método PUT é o inverso de GET: em vez de ler, ele grava a página. Esse método 
possibilita a criação de um conjunto de páginas da Web em um servidor remoto. O corpo da 
solicitação contém a página. Ela pode ser codificada com o uso de MIME. Nesse caso, as linhas 
após PUT podem incluir Content-Type e cabeçalho de autenticação, para demonstrar que o 
chamador de fato tem permissão para executar a operação solicitada. 
Um pouco semelhante a PUT é o método POST, que também transporta um URL. No 
entanto, em vez de substituir os dados existentes, os novos dados são "anexados" a ele, em um 
sentido mais genérico. Enviar uma mensagem a um newsgroup ou incluir um arquivo em um BBS 
são dois exemplos de anexação nesse contexto. Na prática, nem PUT nem POST são muito 
utilizados hoje. 
DELETE faz exactamente isso: exclui a página. A exemplo de PUT, a permissão e a 
autenticação têm papel fundamental. Não há garantia de que DELETE tenha sido bem-sucedido 
pois, mesmo que o servidor HTTP remoto esteja pronto para excluir a página, o arquivo subjacente 
pode ter um modo que impeça o servidor HTTP de modificá-lo ou excluí-lo. 
16 
 
 
 
O método TRACE serve para depuração. Ele instrui o servidor a enviar de volta a 
solicitação. Esse método é útil quando as solicitações não estão sendo processadas correctamente e 
o cliente deseja saber qual solicitação o servidor recebeu de fato. 
O método CONNECT não é usado actualmente. Ele é reservado para uso futuro. 
O método OPTIONS fornece um meio para que o cliente consulte o servidor sobre suas 
propriedades ou sobre as de um arquivo específico. 
4.1.8. APERFEIÇOAMENTOS DE DESEMPENHO 
4.1.8.1. A WEB SEM FIOS 
Há um interesse considerável em pequenos dispositivos portáteis capazes de acessar a Web 
por meio de um link sem fio. De fato, as primeiras tentativas nesse sentido já foram feitas. Sem 
dúvida haverá uma grande mudança nessa área nos próximos anos, mas ainda vale a pena examinar 
algumas ideias actuais relacionadas à Web sem fio, para ver onde estamos agora e para onde 
podemos seguir. Vamos nos concentrar nos dois primeiros sistemas geograficamente distribuídos 
da Web sem fio que chegaram ao mercado: WAP e i-mode. 
4.1.8.2. WAP — Wireless Application Protocol 
Depois que a Internet e os telefones celulares se tornaram comuns, não demorou muito para 
que alguém tivesse a ideia de combiná-los em um telefone móvel com uma tela embutida para 
acesso sem fio ao correio electrónico e à Web. Nesse caso, "alguém" foi um consórcio liderado 
inicialmente pelas empresas Nokia, Ericsson, Motorola e phone.com (antes denominada Unwired 
Planet) e que tem agora centenas de membros. O sistema é chamado WAP (Wireless Application 
Protocol). 
Um dispositivo WAP pode ser um telefone móvel aperfeiçoado, um PDA ou um notebook 
sem qualquer recurso de voz. A especificação permite tudo isso e muito mais. A ideia básica é usar 
a infra-estrutura sem fio digital existente. Os usuários podem literalmente chamar um gateway 
WAP pelo link sem fio e enviar solicitações de página da Web. Em seguida, o gateway verifica se 
seu cache tem a página solicitada. Se estiver presente, ela será enviada; caso contrário, o gateway 
irá buscá-la na Internet fisicamente conectada. Em essência, isso significa que o WAP 1.0 é um 
sistema de comutação de circuitos com uma tarifa de conexão por minuto bastante alta. Para 
encurtar a história, as pessoas não gostaram de acessar a Internet usando uma tela minúscula e 
pagando por minuto; assim, o WAP se tornou um fiasco (embora também houvesse outros 
17 
 
 
 
problemas). Porém, o WAP e seu concorrente, o i-mode (descrito a seguir) parecem estar 
convergindo para uma tecnologia semelhante e, desse modo, o WAP 2.0 ainda poderá ser um 
grande sucesso. Tendo em vista que o WAP 1.0 foi a primeira tentativa de utilização da Internet 
sem fio, vale a pena descrevê-lo, pelo menos brevemente. 
Em essência, o WAP é uma pilha de protocolos para acesso à Web, embora optimizada 
para conexões de baixa largura de banda, usando dispositivos sem fios com uma CPU lenta, pouca 
memória e uma tela pequena. Esses requisitos são evidentemente distintos das exigências que os 
PCs de desktop padrão devem manter, o que resulta em algumas diferenças nos protocolos. 
4.1.9. FILE TRANSFER PROTOCOL – FTP 
A aplicação FTP foi uma das primeiras aplicações na hoje chamada Internet. A base é o 
protocolo FTP que tem como principal função a transferência de arquivos entre dispositivos nos 
formatos ASCII e Binário. É uma aplicação do tipo cliente/servidor e em uma situação típica a 
aplicação cliente FTP utiliza o protocolo TCP para estabelecer uma conexão com o servidor 
remoto. Os servidores podem disponibilizar áreas só de leitura para download de arquivos 
compartilháveis ou leitura/escrita para áreas públicas sem restrição. 
Normalmente estes servidores permitem conexão autenticada, login/senha, com usuários 
cadastrados para acesso em áreas do servidor restritas ou ainda usuário anonymous ou mesmo ftp, 
com senha livre, normalmente o e-mail, para posterior contacto. É importante observar que neste 
processo de autenticação o login/senha trafegam pela rede sem criptografia facilitando assim 
eventuais infortúnios como a utilização de analisadores de tráfego. Normalmente nos casos onde a 
autenticação é necessária se emprega servidores de FTP criptografados, sendo o Security Shell - 
SSH um dos mais populares. 
Quando um cliente começa a negociar uma conexão com um servidor FTP, uma porta é 
escolhida e enviada para posterior conexão. O servidor, por sua vez, recebe a requisição pela porta 
padrão 20. A resposta do servidor é enviada pela porta 21 endereçada pela porta escolhida pelo 
cliente. A utilização do conceito de portas permite desta forma, que um mesmo servidor receba 
várias requisições pois a resposta é endereçada à diferentes portas escolhidas por cada cliente. 
4.1.10. TRIVIAL FILE TRANSFER PROTOCOL – TFTP 
Este protocolo é utilizado principalmente para transferir arquivos de configuração ou 
mesmo do sistema operacional entre um computador e um equipamento, roteadores, comutadores, 
18 
 
 
 
bridges, impressoras, etc. A aplicação também é do tipo cliente/servidor sendo normalmente o 
equipamento o cliente e o computador o servidor. 
Ao invés de TCP, este protocolo utiliza UDP pois apresenta a possibilidade de acesso, 
normalmente para configuração, à equipamentos importantes em situações críticas como por 
exemplo quando um roteador fica inacessível por não suportar mais conexões TCP no caso de um 
ataque externo. 
Servidores de TFTP não possuem autenticação sendo normalmente utilizados através de 
uma conexão directa na porta serial ou auxiliar do equipamento para garantir confiabilidade e 
segurança na transferência dos arquivos. Existem várias aplicações TFTP disponibilizadas de 
maneira compartilhada na Internet. 
4.1.11. TELNET 
Esta aplicação também do tipo cliente/servidor utiliza o protocolo TCP. É utilizada para 
conexão remota em computadores para execução de aplicações específicas muitas das vezes 
desenvolvidas pelo própriousuário. Também usada para configuração e monitoramento remoto de 
equipamentos, como roteadores por exemplo. Como não transfere arquivos, é comum a utilização 
de aplicações FTP ou TFTP em conjunto. Da mesma forma que o FTP, existe a necessidade de 
autenticação e portanto todos os problemas relativos a segurança também estão presentes. Da 
mesma forma, existem aplicações Telnet criptografadas compartilhadas na Internet. 
4.1.12. SIMPLE NETWORK MANAGEMENT PROTOCOL – SNMP 
Este protocolo utiliza UDP para fazer gerência de equipamentos, sendo o protocolo base de 
todas as principais plataformas de gerenciamento, CiscoWorks - CISCO, HP Open View - HP, Sun 
Net Manager - SUN, Transcend – 3COM, SCOTTY – TU Braunschweig, MRTG, dentre outras. 
Sua primeira versão possuía muitas falhas relativas a segurança e portanto era alvo certo dos 
hackers para invasão às redes. Apesar disto, sua utilização cresceu a ponto de se tornar o protocolo 
padrão das principais plataformas. 
O funcionamento das aplicações está vinculado ao envio/recebimento periódico de 
mensagens, equipamentos/computadores respectivamente, que contém valores de parâmetros 
relevantes para monitoramento, análise e posterior configuração por parte dos equipamentos. Estas 
informações são armazenadas em forma de base de dados chamada Management Information Base 
– MIB. 
19 
 
 
 
É possível configurar as aplicações para que enviem avisos através de e-mails, de sinais 
visuais e sonoros, Tc, aos gerentes de rede quando situações críticas ocorrerem, como por exemplo 
a mudança de estado de uma porta de um roteador, nível de tráfego fora dos limites, percentagem 
de processamento perto do limite, dentre outras. 
4.1.13. NETWORK FILE SYSTEM – NFS 
O Network File System (NFS) é um protocolo de rede para compartilhamento distribuído 
de arquivos . Um sistema de arquivos define um sistema de dados em formato de arquivos 
armazenados e recuperados de maneira de armazenamento, como unidades de disco rígido, 
unidades de estado sólido e unidades de fita. O NFS é um protocolo de compartilhamento de 
arquivos de rede que define como os arquivos são armazenados e recuperados de dispositivos de 
armazenamento nas redes. 
O protocolo de arquivos de rede NFS foi desenvolvido para um protocolo de 
compartilhamento local de arquivos NFS desenvolvido para um protocolo de compartilhamento 
local de sistemas Unix e lançado pela Sun Microsystems 84. A especificação NFS foi publicada 
pela Internet EngineeringTask Force (IEIE) como um protocolo de Internet RFC 1094 em 1989. A 
versão actual do protocolo NFS está documentada na RFC 7530 , que documenta o protocolo NFS 
versão 4 (NFSv4). 
Clientes com autorização para acessar sistemas de arquivos compartilhados podem montar 
arquivos compartilhados FS, também conhecidos como sistemas de arquivos compartilhados. O 
NFS usa procedimentos remotos ( RPCs ) para chamadas rotear entre clientes e servidores. 
O NFS é um protocolo de camada de aplicação , o que significa que pode operar em 
qualquer pilha de protocolos de transporte ou rede. No entanto, na maioria dos casos, o NFS é 
implementado em sistemas que executam o conjunto de protocolos TCP/IP . A intenção original do 
NFS era criar um protocolo simples e sem estado para compartilhamento de sistemas de sistemas 
distribuídos. 
4.1.14. ROUTING INFORMATION PROTOCOL – RIP 
O RoutingInformationProtocol (RIP) é um protocolo de roteamento de vector de 
distância. Os roteadores que executam o protocolo de vector de distância enviam todas ou parte de 
suas tabelas de roteamento em mensagens de atualização de roteamento para seus vizinhos. 
https://www-techtarget-com.translate.goog/searchnetworking/definition/protocol?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
https://www-techtarget-com.translate.goog/searchmobilecomputing/definition/file-sharing?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
https://www-techtarget-com.translate.goog/searchstorage/definition/file-system?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
https://www-techtarget-com.translate.goog/searchdatacenter/definition/Unix?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
https://translate.google.com/website?sl=en&tl=pt&hl=pt-PT&prev=search&u=https://www.rfc-editor.org/rfc/rfc7530
https://www-techtarget-com.translate.goog/searchsoftwarequality/definition/authorization?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
https://www-techtarget-com.translate.goog/searchapparchitecture/definition/Remote-Procedure-Call-RPC?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
https://www-techtarget-com.translate.goog/searchnetworking/definition/Application-layer?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
https://www-techtarget-com.translate.goog/searchnetworking/definition/TCP-IP?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
https://www-techtarget-com.translate.goog/whatis/definition/stateless?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-PT&_x_tr_pto=sc
20 
 
 
 
O RIP é um protocolo de roteamento intra-domínio usado em um sistema autónomo. Aqui, 
intra-domínio significa rotear os pacotes em um domínio definido, por exemplo, navegação na web 
dentro de uma área institucional. Para entender o protocolo RIP, nosso foco principal é conhecer a 
estrutura do pacote, quantos campos ele contém e como esses campos determinam a tabela de 
roteamento. 
4.1.15. Real-time TransportProtocol - RTP 
O Real-time TransportProtocol mantém um fluxo fixo e controlado de dados entre servidor 
e cliente, apesar de condições variadas de congestionamento da Rede Mundial ou atrasos na 
transmissão. Os pacotes de dados deste protocolo possuem datação. A transmissão é monitorada 
por um outro protocolo relacionado, o RTCP (Real Time Control Protocol). 
O Real-time TransportProtocol ( RTP ) é um protocolo de rede para entrega de áudio e 
vídeo em redes IP . O RTP é usado em sistemas de comunicação e entretenimento que 
envolvem mídia de streaming , como telefonia , aplicativos de teleconferência de vídeo , 
incluindo WebRTC , serviços de televisão e recursos push-to-talk baseados na web. 
O RTP normalmente é executado no protocolo UDP ( User Datagram Protocol ). O RTP é 
usado em conjunto com o protocolo de controle RTP (RTCP). Enquanto o RTP carrega os fluxos 
de mídia (por exemplo, áudio e vídeo), o RTCP é usado para monitorar as estatísticas de 
transmissão e a qualidade do serviço (QoS) e auxilia na sincronização de vários fluxos. O RTP é 
uma das bases técnicas da Voz sobre IP e, neste contexto, é frequentemente usado em conjunto 
com um protocolo de sinalização , como o Protocolo de Iniciação de Sessão (SIP), que estabelece 
conexões através da rede. 
O RTP foi desenvolvido pelo Grupo de Trabalho de Transporte de Áudio e Vídeo da Força-
Tarefa de Engenharia da Internet (IETF) e publicado pela primeira vez em 1996 
como RFC 1889, que foi substituído pelo RFC 3550 em 2003. 
4.1.16. Secure Socket Shell - SSH 
SSH é a sigla para Secure Socket Shell, sendo um dos protocolos específicos de segurança 
de troca de arquivos entre cliente e servidor de internet, usando criptografia. 
O objectivo do SSH é permitir que desenvolvedores ou outros usuários realizem alterações 
em sites e servidores utilizando uma conexão simples e segura. 
https://vies.wiki/wiki/pt/Network_protocol
https://vies.wiki/wiki/pt/IP_networks
https://vies.wiki/wiki/pt/Streaming_media
https://vies.wiki/wiki/pt/Telephony
https://vies.wiki/wiki/pt/Video_teleconference
https://vies.wiki/wiki/pt/WebRTC
https://vies.wiki/wiki/pt/IPTV
https://vies.wiki/wiki/pt/Push-to-talk
https://vies.wiki/wiki/pt/User_Datagram_Protocol
https://vies.wiki/wiki/pt/User_Datagram_Protocol
https://vies.wiki/wiki/pt/RTP_Control_Protocol
https://vies.wiki/wiki/pt/Quality_of_service
https://vies.wiki/wiki/pt/Synchronization
https://vies.wiki/wiki/pt/Voice_over_IP
https://vies.wiki/wiki/pt/Signaling_protocol
https://vies.wiki/wiki/pt/Session_Initiation_Protocol
https://vies.wiki/wiki/pt/Internet_Engineering_Task_Forcehttps://vies.wiki/wiki/pt/Internet_Engineering_Task_Force
https://vies.wiki/wiki/pt/Internet_Engineering_Task_Force
https://vies.wiki/wiki/pt/RFC_(identifier)
https://vies.wiki/wiki/pt/Real-time_Transport_Protocol
https://vies.wiki/wiki/pt/RFC_(identifier)
https://vies.wiki/wiki/pt/RFC_(identifier)
21 
 
 
 
Secure Socket Shell é um protocolo de rede para o usuário internet acessar, administrar e 
modificar remotamente seus servidores. Isso inclui gerenciamento de contas de hospedagem que 
usam. 
O objectivo do SSH é permitir que desenvolvedores ou outros usuários realizem alterações 
em sites e servidores utilizando uma conexão simples e segura. 
Ex de ferramentas que se usam no protocolo SSH: 
1. Open SSH; 2. SmarTTY; 3. PuTTy; 4. FileZiler; 5. ZOC e 6. XShell 
O funcionamento do SIP será tratado com detalhes nas seções 3 e 4 deste texto, mas é 
possível citar algumas actividades básicas de antemão, como a localização e sinalização dos 
participantes, classificação da natureza da comunicação a ser utilizada na sessão e transmissão da 
informação utilizando um protocolo apropriado. 
4.1.17. Session Initiation Protocol - SIP 
O SIP (Session Initiation Protocol, ou Protocolo de Início de Sessão) opera na camada de 
aplicação executando operações de controle relacionadas ao estabelecimento, manipulação e 
finalização de sessões multimídia. Estas definidas, neste contexto, como sendo trocas de dados 
entre seus participantes (humanos, ou componentes automatizados, por exemplo, um servidor 
de voicemail). 
Session Initiation Protocol (Protocolo de Iniciação de Sessão) é um tecnologia que permite 
a comunicação entre usuários por meio de uma rede VoIP. 
Uma característica importante deste protocolo é que ele não foi desenvolvido para prover 
serviços, mas sim primitivas para implementá-los. O objectivo é explorar ao máximo a 
interoperabilidade e recurso de protocolos já existentes e, ao seguir uma filosofia modular, permite 
a fácil adaptação a tecnologias que serão desenvolvidas futuramente. O SIP, é um protocolo 
limitado ao ser usado de maneira isolada, porém torna-se uma ferramenta muito útil na 
manutenção de sessões multimídia ao ser utilizado em conjunto com outros protocolos 
Ela possui código aberto, o que significa que qualquer pessoa pode utilizá-la, modificá-la e 
distribuí-la. 
A principal função da tecnologia SIP é facilitar a comunicação por vídeo ou áudio em 
diversos tipos de mídia, em qualquer aplicativo. Dentre elas, podemos citar o compartilhamento de 
dados, áudio, texto e vídeo, os serviços de char e outras funcionalidades. 
22 
 
 
 
4.1.18. Remote Desktop Protocol - RDP 
 O Protocolo de Área de Trabalho Remota da Microsoft (RDP) fornece recursos de exibição 
remota e entrada em conexões de rede para aplicativos baseados em Windows em execução em um 
servidor. O RDP foi projectado para dar suporte a diferentes tipos de topologias de rede e vários 
protocolos LAN. 
Remote Desktop Protocol é um protocolo multi-canal que permite que um usuário se 
conecte a um computador rodando o Microsoft Terminal Services. 
Existem clientes para a maioria das versões do Windows, e outros sistemas operacionais 
como o Linux. 
O servidor escuta por padrão a porta TCP 3389. Permite a conexão a um PC rodando na 
mesma Rede Local (LAN). 
4.1.19. Internet relay chat - IRC 
O Internet relaychat (IRC) é um sistema de bate-papo baseado em texto que permite 
discussões entre qualquer número de participantes nos chamados canais de conversação, bem 
como discussões entre apenas dois parceiros (em diálogos de perguntas e respostas, por exemplo). 
O Internet Relay Chat ou IRC como é mais conhecido, é um serviço da Internet utilizado 
para teleconferência em modo texto. Ele é constituído de servidores e clientes, de maneira que 
cada servidor contém informações sobre todo o sistema (clientes, usuários, outros servidores, etc.). 
O cliente é implementado em sockets e normalmente utiliza as portas 6666, 6667 ou 6668 
para comunicar-se com o servidor. Esta comunicação ocorre sobre TCP/IP, utilizando o protocolo 
TCP na camada de rede. 
O protocolo do Internet Relay Chat é baseado em texto (caracteres ASCII) e está descrito 
no RFC 1459. 
Qualquer participante pode abrir um novo canal de conversa e, um único usuário de 
computador pode, participar de vários canais simultâneos. 
 
 
23 
 
 
 
5. CONCLUSÃO 
TCP/IP não é um protocolo único, é uma colecção de protocolos com arquitectura 
distribuída em 4 camadas que se distribuem sobre as camadas do modelo OSI: aplicação, host-host, 
rede e física. A camada física não é descrita na arquitectura TCP/IP apesar de ser a base para a 
comunicação entre a aplicação e a rede. 
O protocolo IP é a base da arquitectura pois atribui endereços lógicos aos dispositivos e às 
redes e assim consegue definir o caminho para levar os pacotes da origem ao destino. TCP e UDP 
são protocolos da camada de transporte e tem como função principal a entrega de dados 
(segmentos) aos dispositivos destinos. O TCP é um protocolo orientado à conexão e assim garante 
que os dados cheguem na ordem certa ao seu destino. O UDP ao contrário, é não orientado a 
conexão e não garante a chegada dos dados ao destino. 
Existem vários outros protocolos e aplicações que utilizam conexões TCP/IP e UDP/IP, e 
que não foram abordados aqui por simplicidade apenas. A importância do conjunto de protocolos 
TCP/IP está totalmente ligada ao sucesso da Internet. Estes protocolos, apesar de suas limitações 
em termos de roteamento, cada vez mais, estão se tornando a base de aplicações que são 
disponibilizadas e necessárias à Internet. 
 
24 
 
 
 
6. REFERENCIA BIBLIOGRAFICA 
TACKETT. J, GUNTER. D e BROWN. L;Using Linux – The Most Complete Reference”; 
QUE Corporation, ISBN: 0-7897-01000-6, 1995. 
HUNT. C,“TCP/IP Network Administration”, O’Reilly Associates, ISBN: 1- 56592-322-7, 
second edition, December 1997. 
CCNA Certification – Routing Basics for CISCO Certified Network Associates Exam 640-
407”, R. N. Myhre, Prentice-Hall, ISBN: 0-13-086185-5, 1999. 
 TANENBAUM, A. S. Redes de computadores. 4. ed. Rio de Janeiro: Campus, 1997.