Definição Das Sete Camadas Do Modelo OSI e Explicação de Suas Funçõe1

Definição das sete camadas do modelo OSI e
explicação de suas funções
Resumo
O modelo OSI (Open Systems Interconnect) tem sete camadas. Este artigo as
descreve e explica, começando pela camada "inferior" na hierarquia (a camada
física) e avançando até a "superior" (a camada de aplicativo). As camadas estão
empilhadas desta forma:

 Aplicativo
 Apresentação
 Sessão
 Transporte
 Rede
 Vínculo de Dados (Enlace)
 Física
CAMADA FÍSICA
A camada física, a camada inferior do modelo OSI, está encarregada da transmissão

e recepção do fluxo de bits brutos não estruturados através de um meio físico. Ela
descreve as interfaces elétricas/ópticas, mecânicas e funcionais com o meio físico e
transporta os sinais para todas as camadas superiores. Ela fornece o seguinte:

 Codificação de dados: modifica o padrão de sinal digital simples (1s e 0s)

usado pelo PC para acomodar melhor as características do meio físico e para
ajudar na sincronização de bits e quadros. Ela determina o seguinte:

 Qual estado de sinal representa um 1 binário
 Como a estação de recepção sabe quando um "tempo de bit"

começa
 Como a estação de recepção delimita um quadro
 Conexão com o meio físico, acomodando várias possibilidades no meio:

 Um transceptor externo (MAU) será usado para conexão com o

meio?
 Quantos pinos têm os conectores e para o quê cada um deles é

usado?
 Técnica de transmissão: determina se os bits codificados serão transmitidos

por sinalização de banda base (digital) ou de banda larga (analógica).
 Transmissão de meio físico: transmite bits como sinais elétricos ou ópticos

apropriados para o meio físico e determina:

 Quais opções de meio físico podem ser usadas
 Quantos volts/db devem ser usados para representar um

determinado estado de sinal, usando um meio físico específico
CAMADA DE VÍNCULO DE DADOS (Enlace)
A camada de vínculo de dados proporciona uma transferência de quadros de

dados sem erros de um nó para outro através da camada física, permitindo que as
camadas acima dela assumam a transmissão praticamente sem erros através do
vínculo. Para fazer isso, a camada de vínculo de dados fornece:

 Estabelecimento e término do vínculo: estabelece e finaliza o vínculo lógico

entre dois nós.
 Controle de tráfego de quadros: instrui o nó de transmissão a se "retirar"

quando não houver buffers de quadros disponíveis.
 Sequenciamento de quadros: transmite/recebe quadros sequencialmente.

 Confirmação de quadros: fornece/espera confirmações de quadros. Faz a
detecção e recuperação de erros que ocorrem na camada física,
retransmitindo quadros não confirmados e lidando com o recebimento de
quadros duplicados.
 Delimitação de quadros: cria e reconhece limites de quadros.
 Verificação de erros de quadro: verifica a integridade dos quadros recebidos.
 Gerenciamento do acesso à mídia: determina quando o nó "tem o direito"

de utilizar o meio físico.
CAMADA DE REDE
A camada de rede controla a operação da sub-rede, decidindo que caminho físico

os dados devem seguir com base nas condições da rede, na prioridade do serviço e
em outros fatores. Ela fornece o seguinte:

 Roteamento: roteia quadros entre redes.
 Controle do tráfego da sub-rede: roteadores (sistemas intermediários da

camada de rede) podem instruir uma estação de envio a "desacelerar" sua
transmissão de quadros quando o buffer do roteador fica cheio.
 Fragmentação de quadros: se ela determinar que o tamanho da unidade

máxima de transmissão (MTU) do roteador downstream é menor que o
tamanho do quadro, um roteador poderá fragmentar um quadro para
transmissão e remontagem na estação de destino.
 Mapeamento de endereços lógicos/físicos: converte endereços lógicos, ou

nomes, em endereços físicos.
 Contabilidade de uso da sub-rede: tem funções de contabilidade para

manter o controle dos quadros encaminhados por sistemas intermediários
da sub-rede, para produzir informações de cobrança.
Sub-rede de Comunicações
O software de camada de rede deve criar cabeçalhos para que o software de

camada de rede residente nos sistemas intermediários da sub-rede possam
reconhecê-los e usá-los para rotear dados ao endereço de destino.
Essa camada dispensa as camadas superiores da necessidade de conhecer
informações sobre as tecnologias de transmissão de dados comutação
intermediária usadas para conectar sistemas. Ela estabelece, mantém e finaliza
conexões nas instalações de comunicações intervenientes (um ou vários sistemas
intermediários na sub-rede de comunicação).
Na camada de rede e nas camadas abaixo dela, existem protocolos de par entre um
nó e seu vizinho imediato, mas o vizinho pode ser um nó através do qual os dados
são roteados, e não a estação de destino. As estações de origem e de destino
podem ser separadas por vários sistemas intermediários.

CAMADA DE TRANSPORTE
A camada de transporte garante que as mensagens sejam entregues sem erros, em

sequência e sem perdas ou duplicações. Ela elimina para os protocolos de camadas
superiores qualquer preocupação a respeito da transferência de dados entre eles e
seus pares.
O tamanho e a complexidade de um protocolo de transporte depende do tipo de

serviço que ele pode obter da camada de rede. Para uma camada de rede confiável
com capacidade de circuito virtual, uma camada de transporte mínima é necessária.
Se a camada de rede não for confiável e/ou apenas tiver suporte para datagramas,
o protocolo de transporte deverá incluir procedimentos externos de detecção e
recuperação de erros.
A camada de transporte fornece o seguinte:

 Segmentação de mensagens: aceita uma mensagem da camada acima dela

(sessão), divide a mensagem em unidades menores (se ela ainda não for
suficientemente pequena) e transmite as unidades menores até a camada de
rede. A camada de transporte na estação de destino remonta a mensagem.
 Confirmação de mensagem: fornece uma entrega completa e confiável de

mensagens com confirmações.
 Controle de tráfego de mensagens: instrui a estação de transmissão a se
"retirar" quando não houver buffers de mensagens disponíveis.
 Multiplexação de sessão: multiplexa vários fluxos de mensagem ou sessões

em um vínculo lógico e controla quais mensagens pertencem a quais
sessões (consulte camada de sessão).
Normalmente, a camada de transporte pode aceitar mensagens relativamente

grandes, mas existem limites rigorosos de tamanho de mensagens impostos pela
camada de rede (ou inferior). Consequentemente, a camada de transporte deve
dividir as mensagens em unidades menores, ou quadros, acrescentando um
cabeçalho ao início de cada quadro.
As informações de cabeçalho da camada de transporte devem então incluir

informações de controle, como sinalizadores de início e fim de mensagem, para
permitir que a camada de transporte na outra extremidade reconheça os limites da
mensagem. Além disso, se as camadas inferiores não mantiverem a sequência, o
cabeçalho de transporte deverá conter informações de sequência para permitir que
a camada de transporte na extremidade receptora junte as partes na ordem certa
antes de entregar a mensagem recebida para a camada acima.

Camadas de ponta a ponta
Ao contrário das camadas inferiores de "sub-rede", cujo protocolo está entre nós
imediatamente adjacentes, a camada de transporte e as camadas acima dela são
verdadeiras camadas de "origem até o destino", ou ponta a ponta, e desconsideram
os detalhes dos recursos de comunicações subjacentes. Os softwares da camada de
transporte (e os softwares acima deles) na estação de origem realizam uma
conversa com softwares semelhantes na estação de destino, usando cabeçalhos de
mensagens e mensagens de controle.

CAMADA DE SESSÃO
A camada de sessão permite o estabelecimento da sessão entre processos em

execução em estações diferentes. Ela fornece o seguinte:

 Estabelecimento, manutenção e término de sessões: permite que dois

processos de aplicativo em máquinas diferentes estabeleçam, usem e
terminem uma conexão, conhecida como sessão.
 Suporte a sessões: realiza as funções que permitem que esses processos se

comuniquem pela rede, realizando tarefas de segurança, reconhecimento de
nomes, registro em log e assim por diante.
CAMADA DE APRESENTAÇÃO
A camada de apresentação formata os dados a serem apresentados na camada de

aplicativo. Ela pode ser considerada o tradutor da rede. Essa camada pode
converter dados de um formato usado pela camada de aplicativo em um formato
comum na estação de envio e, em seguida, converter esse formato comum em um
formato conhecido pela camada de aplicativo na estação de recepção.
A camada de apresentação fornece:

 Conversão de códigos de caractere: por exemplo, ASCII para EBCDIC.
 Conversão de dados: ordem de bits, ponto de CR-CR/LF, flutuante inteiro e

assim por diante.
 Compactação de dados: reduz o número de bits que precisam ser

transmitidos na rede.
 Criptografia de dados: criptografa dados para fins de segurança. Por

exemplo, criptografia de senha.
CAMADA DE APLICATIVO
A camada de aplicativo serve como a janela onde os processos de aplicativos e

usuários podem acessar serviços de rede. Essa camada contém uma variedade de
funções normalmente necessárias:

 Redirecionamento de dispositivo e o compartilhamento de recursos
 Acesso remoto a arquivos
 Acesso de impressora remota
 Comunicação entre processos
 Gerenciamento de rede
 Serviços de diretório
 Mensagens eletrônicas (como email)
 Terminais de rede virtuais

Camada física
Modelo OSI
Camada Protocolo
7.Aplicação HTTP, RTP, SMTP, FTP, SSH, Telnet, SIP, RDP, IRC, SNMP, NNTP, POP3, IMAP, Bi
tTorrent, DNS ...
6.Apresentação XDR, TLS ...
5.Sessão NetBIOS ...
4.Transporte NetBEUI, TCP, UDP, SCTP, DCCP, RIP ...
3.Rede IP (IPv4, IPv6), IPsec, ICMP, ARP, RARP, NAT ...
2.Enlace
 Subca
mada LLC Ethernet, IEEE 802.1Q, HDLC, Token ring, FDDI, PPP, Switch, Frame relay, ATM ...
 Subca
mada
MAC
1.Física Modem, , 802.11 Wi-FiRDIS, RS-232, EIA-422, RS-449, Bluetooth, USB, 10BASE-
T, 100BASE-TX, ISDN, SONET, DSL...
Camada física refere-se, em informática, à consideração dos componentes

de hardware envolvidos em um determinado processo. Em termos de redes, a camada
física diz respeito aos meios de conexão através dos quais irão trafegar os dados, tais
como interfaces seriais, ou cabos coaxiais. É a camada de nível um (físico) dos sete níveis
de camadas do modelo OSI das redes de computadores. Ele fornece:
Codificação de dados: modifica o padrão de sinal digital simples (1s e 0s) usado pelo PC
para melhor acomodar as características do meio físico e para ajudar na sincronização de
bit e quadros. Técnica de transmissão: determina se os bits codificados serão transmitidos
por banda base (digital) ou a sinalização de banda larga (analógica). Transmissão de
mídia física: transmite bits como sinais de ópticos ou elétricos apropriados para o meio
físico e determina: Que opções de mídia físicas podem ser usadas,quantos volts/db deve
ser usado para representar um estado de determinado sinal, usando um determinado meio
físico.
Lista de Protocolos da Camada Física
- IrDA: (Infrared Data Association) é um grupo de interesse da indústria orientada que

foi fundada em 1993 por várias empresas. Fornece um conjunto de especificações do
protocolo sem fio para comunicações via infravermelho.
- USB: Padrão que define os cabos, conectores e protocolos usados para a

transmissão de dados através de cabos em periféricos.
- EIA (Electronic Industries Alliance): Organização que cuida para que as normas

para que equipamentos de marcas diferentes sejam compatíveis e intercambiáveis
funcionem nos EUA.
- Ethernet (IEE 802.3): Tecnologia para a conexão entre hosts de uma rede LAN
baseada no envio de pacotes. Fornece especificações de cabeamento e sinais
elétricos para a camada 1 do modelo OSI.
- SONET / SDH (Synchronous Digital Hierarchy): São padrões para a transferencia de

fluxo de bits sobre fibra óptica através de lasers ou luz altamente coerente LEDs.
DSL: Tecnologias que permitem o acesso a internet através da transmissão digital de

dados em uma rede local de telefonia. Utiliza bandas de frequencia elevadas para os
dados que são separados por filtros. Ataxa de bits do consumidor de serviços DSL
geralmente varia de 256 kbit/s até 40 Mbit/s na direção para o cliente
ISDN: É um conjunto de padrões de comunicação simultânea digital, transmissão de

voz, vídeo, dados e outros serviços de rede através da rede de telefonia pública. Foi
feito para permitir a transmissão digital de voz e dados ao longo de fios de cobre de
telefonia, resultando em qualidade de voz potencialmente melhor do que um
telefone analógico pode oferecer.
T1: É um método de transmissão digital para multiplexar canais de voz ou de dados

em um par de fios. É usado como padrão de interconexão de centrais telefônicas,
nos EUA e Japão. Trabalha em uma largura de banda de 1, 544 Mbps. Pode ser dividio
em 24 subcanais de 64 Kbps. O T1 envia dados em quadros (frames), transmitindo 8
000 quadros por segundo.
E1: É um padrão de linha telefônica digital usado no Brasil e na Europa. Possui taxa
de transferência de 2Mbps e pode ser dividido em 32 canais de 64 Kbps cada.
SONET/SDH: Padrões de multiplexação de protocolos que transferem várias fluxos

digitais de bits sobre fibra ótica usando lasers ou LEDs. Foram desenvolvidos para o
transporte de grandes quantidades de chamadas telefônicas e tráfego de dados
através da mesma fibra, sem problemas de sincronização.
Optical Transport Network: A ITU-T definiu um conjunto de elementos de rede

óptica conectados por links de fibra óptica, capazes de fornecer a funcionalidade do
transporte, multiplexação, comutação, gestão, supervisão e capacidade de
sobrevivência dos canais ópticos que transportam sinais para um cliente.
GSM: Conjunto de padrões desenvolvidos pela European Telecommunications
Standarts
Modelo OSI
Camada 1: Física

A Camada Física define as características mecânicas, elétricas, funcionais e os
procedimentos para ativar, manter e desativar conexões físicas para a transmissão de bits.

As características mecânicas dizem respeito ao tamanho e forma de conectores, pinos,
cabos, etc. que compõem um circuito de transmissão. As características elétricas
especificam os valores dos sinais elétricos (nível de tensão e corrente) usados. As
características funcionais definem o significado dado aos sinais transmitidos na camada
física (por exemplo, transmissão, recepção, terra, etc.).

Os procedimentos especificam as funções e protocolos necessários para a transmissão de
bits. O bit é considerado, na transmissão serial, como a unidade de dados básica da
Camada Física.

Os protocolos da Camada Física devem ser independentes do meio de transmissão de
modo que um dado terminal possa ser utilizado em diversos meios, como pares metálicos,
fibra óptica ou rádio, por exemplo.

A Figura abaixo ilustra a situação de retransmissores com diferentes meios físicos.

Figura 13: Meio Físico com retransmissores

Os padrões de Camada Física que provavelmente se tornaram mais populares são
aqueles correspondentes às interfaces RS232C e RS449 (EIA) e suas adaptações, para
redes de telecomunicações, feita pelo ITU -T (CCITT, na época), a saber as
Recomendações V.24 e X.21.

Estas Recomendações são freqüentemente vistas como especificações da Camada
Física, mas de fato contém elementos das Camadas 1, 2 e 3. Nestas Recomendações, as
descrições dos procedimentos das diversas camadas parecem, por vezes, se misturar. Isto
se deve ao fato que o Modelo OSI não havia sido ainda desenvolvido suficientemente para
permitir uma visão clara das fronteiras entre camadas.

A Recomendação V.24 foi publicada pela primeira vez em 1964 e especifica a operação de
39 circuitos que podem ser usados por um terminal (designado genericamente como Data
Terminal Equipment - DTE ) para controlar um modem (designado genericamente Data
Communication/ Terminating Citcuit Equipment - DCE ) e para permitir que o modem envie
ao terminal informações a respeito do seu estado. O aspecto essencial da V.24 é que os
sinais são transportados como tensões simples referidos a um terra presente no pino 107.
De acordo com o conceito atual de Camada Física apenas alguns circuitos seriam
considerados.

Dynamic Host Configuration Protocol
O DHCP, Dynamic Host Configuration Protocol (protocolo de configuração dinâmica
de host), é um protocolo de serviço TCP/IP que oferece configuração dinâmica de
terminais, com concessão de endereços IP de host, máscara de sub-rede, default
gateway (gateway padrão), número IP de um ou mais servidores DNS, sufixos de
pesquisa do DNS e número IP de um ou mais servidores WINS. Este protocolo é o
sucessor do BOOTP que, embora mais simples, tornou-se limitado para as exigências
atuais. O DHCP surgiu como padrão em outubro de 1993. O RFC 2131 (1997) contém
as especificações mais atuais. O último standard para a especificação do DHCP sobre
IPv6 (DHCPv6) foi publicado como RFC 3315 (2003).
Índice
 1 Funcionamento Básico
 2 Termos Utilizados no DHCP
 3 Critérios de atribuição de IPs
 4 Detalhes técnicos
o 4.1 DHCPDISCOVERY (descoberta)
o 4.2 DHCPOFFER (oferta)
o 4.3 DHCPREQUEST (pedido)
o 4.4 DHCPACK (confirmação)
o 4.5 Informações DHCP
o 4.6 Liberando DHCP
 5 Parâmetros de configuração de cliente no DHCP
 6 Opções do DHCP
 7 Retransmissão DHCP
 8 Confiabilidade
 9 Segurança
 10 Rede sem DHCP - APIPA
 11 Ver também
 12 Referências
Funcionamento Básico
O DHCP usa um modelo cliente-servidor.
Resumidamente, o DHCP opera da seguinte forma:
1. Quando um computador (ou outro dispositivo) conecta-se a uma rede, o host/cliente

DHCP envia um pacote UDP em broadcast (destinado a todas as máquinas) com uma
requisição DHCP (para a porta 67);
2. Qualquer servidor DHCP na rede pode responder a requisição. O servidor DHCP
mantém o gerenciamento centralizado dos endereços IP usados na rede e informações
sobre os parâmetros de configuração dos clientes como gateway padrão, nome do
domínio, servidor de nomes e servidor de horário. Os servidores DHCP que capturarem
este pacote responderão (se o cliente se enquadrar numa série de critérios — ver
abaixo) para a porta 68 do host solicitante com um pacote com configurações onde
constará, pelo menos, um endereço IP e uma máscara de rede, além de dados
opcionais, como o gateway, servidores de DNS, etc.
Termos Utilizados no DHCP
Exemplo de configuração de um servidor DHCP em Microsoft Windows, utilizando a aplicação

Serva.
Servidor DHCP: É um servidor onde foi instalado e configurado o serviço DHCP. Em

Microsoft Windows, após a instalação de um servidor DHCP ele precisa ser autorizado
no Active Directory, antes que possa efetivamente atender pedidos de clientes. O
procedimento de autorização no Active Directory é uma medida de segurança, para
evitar que servidores DHCP sejam introduzidos na rede sem o conhecimento do
administrador da rede. Além do Windows Server, o serviço de DHCP também pode ser
instalado nas distribuições Linux, como o serviço DHCP3 Server, pacote já presente na
maioria das distribuições servidoras de Linux. O servidor DHCP não está disponível
para Windows 2000 Professional, Windows XP Professional ou Windows Vista.
Cliente DHCP: É qualquer dispositivo de rede capaz de obter as configurações do

TCP/IP a partir de um servidor DHCP. Por exemplo, uma estação de trabalho com o
Microsoft Windows 10, uma estação com qualquer distribuição Linux, uma impressora
com placa de rede habilitada ao DHCP, etc.
Escopo: Um escopo é o intervalo consecutivo completo dos endereços IP possíveis para

uma rede (por exemplo, a faixa de 10.10.10.100 a 10.10.10.150, na rede
10.10.10.0/255.255.255.0). Em geral, os escopos definem uma única sub-rede física, na
rede na qual serão oferecidos serviços DHCP. Os escopos também fornecem o método
principal para que o servidor gerencie a distribuição e atribuição de endereços IP e
outros parâmetros de configuração para clientes na rede, tais como o default gateway,
servidor DNS e assim por diante..
Superescopo: Um superescopo é um agrupamento administrativo de escopos que pode

ser usado para oferecer suporte a várias sub-redes IP lógicas na mesma sub-rede física.
Os superescopos contêm somente uma lista de escopos associados ou escopos filhos que
podem ser ativados em conjunto. Os superescopos não são usados para configurar
outros detalhes sobre o uso de escopo. Para configurar a maioria das propriedades
usadas em um superescopo, é necessário configurar propriedades de cada escopo
associado, individualmente. Por exemplo, se todos os computadores devem receber o
mesmo número IP de default gateway, este número tem que ser configurado em cada
escopo, individualmente. Não tem como fazer esta configuração no superescopo e todos
os escopos (que compõem o superescopo), herdarem estas configurações.
Intervalo de exclusão: Um intervalo de exclusão é uma sequência limitada de

endereços IP dentro de um escopo, excluído dos endereços que são fornecidos pelo
DHCP. Os intervalos de exclusão asseguram que quaisquer endereços nesses intervalos
não são oferecidos pelo servidor para clientes DHCP na sua rede. Por exemplo, dentro
da faixa 10.10.10.100 a 10.10.10.150, na rede 10.10.10.0/255.255.255.0 de um
determinado escopo, pode-se criar uma faixa de exclusão de 10.10.10.120 a
10.10.10.130. Os endereços da faixa de exclusão não serão utilizados pelo servidor
DHCP para configurar os clientes DHCP.
Pool de endereços: Após definir um escopo DHCP e aplicar intervalos de exclusão, os

endereços remanescentes formam o pool de endereços disponíveis dentro do escopo.
Endereços em pool são qualificados para atribuição dinâmica pelo servidor para clientes
DHCP na sua rede. No nosso exemplo, onde temos o escopo com a faixa 10.10.10.100 a
10.10.10.150, com uma faixa de exclusão de 10.10.10.120 a 10.10.10.130, o nosso pool
de endereços é formado pelos endereços de 10.10.10.100 a 10.10.10.119, mais os
endereços de 10.10.10.131 a 10.10.10.150.
Concessão: Uma concessão é um período de tempo especificado por um servidor

DHCP durante o qual um computador cliente pode usar um endereço IP que ele recebeu
do servidor DHCP (diz-se atribuído pelo servidor DHCP). Uma concessão está ativa
quando ela está sendo utilizada pelo cliente. Geralmente, o cliente precisa renovar sua
atribuição de concessão de endereço com o servidor antes que ela expire. Uma
concessão torna-se inativa quando ela expira ou é excluída no servidor. A duração de
uma concessão determina quando ela expirará e com que frequência o cliente precisa
renová-la no servidor.
Reserva: Usa-se uma reserva para criar uma concessão de endereço permanente pelo
servidor DHCP. As reservas asseguram que um dispositivo de hardware especificado na
sub-rede sempre pode usar o mesmo endereço IP. A reserva é criada associada ao
endereço de hardware da placa de rede, conhecido como endereço MAC (ou MAC
address). No servidor DHCP cria-se uma reserva, associando um endereço IP com um
endereço MAC. Quando o computador (com o endereço MAC para o qual existe uma
reserva) é inicializado, ele entre em contato com o servidor DHCP. O servidor DHCP
verifica que existe uma reserva para aquele MAC address e configura o computador
com o endereço IP associado ao MAC address. Caso haja algum problema na placa de
rede do computador e a placa tenha que ser substituída, mudará o MAC address e a
reserva anterior terá que ser excluída e uma nova reserva terá que ser criada, utilizando,
agora, o novo MAC address.
Tipos de opção: Tipos de opção são outros parâmetros de configuração do cliente que
um servidor DHCP pode atribuir aos clientes. Por exemplo, algumas opções usadas com
frequência incluem endereços IP para gateways padrão (roteadores), servidores WINS
(Windows Internet Name System) e servidores DNS (Domain Name System).
Geralmente, esses tipos de opção são ativados e configurados para cada escopo. O
console de Administração do serviço DHCP também permite configurar tipos de opção
padrão que são usados por todos os escopos adicionados e configurados no servidor. A
maioria das opções é predefinida através da RFC 2132, mas pode-se usar o console
DHCP para definir e adicionar tipos de opção personalizados, se necessário.
Critérios de atribuição de IPs
O DHCP, dependendo da implementação, pode oferecer três tipos de alocação de

endereços IP:
 Atribuição manual - Onde existe uma tabela de associação entre o endereço MAC do
cliente (que será comparado através do pacote broadcast recebido) e o endereço IP (e
dados restantes) a fornecer. Esta associação é feita manualmente pelo administrador
de rede; por conseguinte, apenas os clientes cujo MAC consta nesta lista poderão
receber configurações desse servidor;
 Atribuição automática - Onde o cliente obtém um endereço de um espaço de
endereços possíveis, especificado pelo administrador. Geralmente não existe vínculo
entre os vários MAC habilitados a esse espaço de endereços;
 Atribuição dinâmica - O único método que dispõe a reutilização dinâmica dos
endereços. O administrador disponibiliza um espaço de endereços possíveis, e cada
cliente terá o software TCP/IP da sua interface de rede configurados para requisitar
um endereço por DHCP assim que a máquina for ligada na rede. A alocação utiliza um
mecanismo de aluguel do endereço, caracterizado por um tempo de vida.
Zerado/expirado esse tempo de vida naturalmente, da próxima vez que o cliente se
conectar, o endereço provavelmente será outro.
Algumas implementações do software servidor de DHCP permitem ainda a atualização

dinâmica dos servidores de DNS para que cada cliente disponha também de um DNS.
Este mecanismo utiliza o protocolo de atualização do DNS especificado no RFC 2136.
Detalhes técnicos
O DHCP (Dynamic Host Configuration Protocol) utiliza o modelo cliente-servidor, no

qual o cliente solicita o endereço e obtém a concessão de um IP, envolvendo quatro
passos, que seguem a seguinte ordem (conforme figura ao lado):
1. discovery (descoberta)
2. offer (oferta)
3. request (pedido)
4. acknowledge (confirmação)
DHCPDISCOVERY (descoberta)
O cliente transmite mensagens na sub-rede física para descobrir os servidores DHCP

disponíveis. Os administradores de rede podem configurar um roteador local para
encaminhar pacotes DHCP a um servidor DHCP de uma sub-rede diferente. Este cliente
cria um pacote UDP (User Datagram Protocol), com o destino de difusão
255.255.255.255 ou o endereço de broadcast de sub-rede específica. Um cliente DHCP
também pode solicitar o seu último endereço IP conhecido (no exemplo abaixo,
192.168.1.100). Se o cliente permanece conectado a uma rede IP para o qual este é
válido, o servidor pode satisfazer o pedido. Caso contrário, ele depende se o servidor
está configurado no modo autoritário ou não. Um servidor no modo autoritário negará o
pedido, fazendo o cliente pedir um novo endereço IP imediatamente. Um servidor no
modo não autoritário simplesmente ignora o pedido, levando a um limite de tempo,
dependente da implementação, para o cliente desistir do pedido e pedir um novo
endereço IP.
DHCPDISCOVERY
UDP Src=0.0.0.0 sPort=68

Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
CIADDR (Client IP Address)
0x00000000
YIADDR (Your IP Address)
0x00000000
SIADDR (Server IP Address)
0x00000000
GIADDR (Gateway IP Address switched by relay)
0x00000000
CHADDR (Client Hardware Address)
0x00053C04
0x8D590000
0x00000000
0x00000000
192 octets of 0s. BOOTP legacy
Magic Cookie
0x63825363
DHCP Options
53: DHCP Discover
1: subnet mask
3: router
54: DHCP server
6: DNS servers
DHCPOFFER (oferta)
Quando um servidor DHCP recebe um pedido de concessão de IP de um cliente, ele

reserva um endereço IP para o cliente (essa reserva é opcional, segundo a RFC 2131 -
3.1.2) e estende uma oferta de concessão IP através do envio de uma mensagem
DHCPOFFER para o cliente. Esta mensagem contém o endereço MAC do cliente, o
endereço IP que o servidor está oferecendo, a máscara de sub-rede, a duração da
concessão, bem como o endereço IP do servidor de DHCP que faz a oferta. O servidor
determina a configuração com base no endereço de hardware do cliente como
especificado no campo CHADDR (endereço de hardware do cliente). Aqui o servidor,
192.168.1.1, especifica o endereço IP no campo YIADDR (seu endereço IP).
DHCPOFFER
UDP Src=192.168.1.1 sPort=67

Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
0x00000000
0xC0A80164 (192.168.1.100)
0xC0A80101 (192.168.1.1)
GIADDR (Gateway IP Address)
0x00000000
0x00053C04
0x8D590000
0x00000000
0x00000000
Magic Cookie
0x63825363
DHCP Options
53: DHCP Offer
1: 255.255.255.0 subnet mask
3: 192.168.1.1 router
51: 86400s (1 day) IP lease time
54: 192.168.1.1 DHCP server
6: DNS servers:
 9.7.10.15,
 9.7.10.16,
 9.7.10.18
DHCPREQUEST (pedido)
Em resposta aos pedidos de oferta do servidor, o cliente responde com um

DHCPREQUEST, ainda em broadcast (para ser visível por todos os DHCP servers),
solicitando o endereço oferecido. Um cliente pode receber ofertas de vários servidores
DHCP, mas vai aceitar apenas uma oferta DHCP. Com base no campo ID da transação
no pedido, os servidores são informados da oferta que o cliente aceitou. Quando outros
servidores DHCP receberem esta mensagem, eles retiram quaisquer ofertas que eles
poderiam ter feito para o cliente e retornam o endereço oferecido ao pool de endereços
disponíveis. Em alguns casos, DHCPMESSAGE é transmitido em broadcast, em vez de
ser unicast para um servidor DHCP particular, porque o cliente DHCP ainda não
recebeu um endereço IP. Além disso, esta mensagem de uma forma pode deixar todos
os outros servidores DHCP saberem que outro servidor fornecerá o endereço IP sem
perder qualquer um dos servidores com uma série de mensagens unicast. A mensagem
DHCPREQUEST também é utilizada pelo cliente DHCP para renovar o período de
concessão do endereço de rede de tempo em tempo (dependente do período de
concessão configurado no servidor DHCP e de implementação do cliente).
DHCPREQUEST
UDP Src=0.0.0.0 sPort=68

Dest=255.255.255.255 dPort=67
OP HTYPE HLEN HOPS

0x01 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
0x00000000
0x00000000
0xC0A80101 (192.168.1.1)
GIADDR (Gateway IP Address)
0x000000080
0x00053C03
0x8D590002
0x00000001
0x00000009
Magic Cookie
0x63825363
DHCP Options
53: DHCP Request
50: 192.168.1.100 requested
54: 192.168.1.1 DHCP server
DHCPACK (confirmação)
Quando o servidor DHCP recebe a mensagem DHCPREQUEST do cliente, o processo

de configuração entra em sua fase final. A fase de reconhecimento envolve o envio de
um pacote DHCPACK para o cliente. Este pacote inclui a duração da concessão e
quaisquer outras informações de configuração que o cliente pode ter solicitado. Neste
ponto, o processo de configuração de IP é concluído. O protocolo prevê que o cliente
DHCP configurará sua interface de rede com os parâmetros negociados.
DHCPACK
UDP Src=192.168.1.1 sPort=67

Dest=255.255.255.255 dPort=68
OP HTYPE HLEN HOPS
0x02 0x01 0x06 0x00
XID
0x3903F326
SECS FLAGS
0x0000 0x0000
0x00000000
0xC0A80164 (192.168.1.100)
0xC0A80101 (192.168.1.1)
GIADDR (Gateway IP Address switched by relay)
0x00000000
0x00053C04
0x8D590000
0x00000000
0x00000000
Magic Cookie
0x63825363
DHCP Options
53: DHCP ACK
1: 255.255.255.0 subnet mask
3: 192.168.1.1 router
51: 86400s (1 day) IP lease time
54: 192.168.1.1 DHCP server
6: DNS servers:
 9.7.10.15,
 9.7.10.16,
 9.7.10.18
Informações DHCP
Um cliente DHCP pode solicitar mais informações do que o servidor enviou com o
DHCPOFFER original. O cliente também pode solicitar dados repetidos para uma
determinada aplicação. Por exemplo, os navegadores usam DHCPINFORM para obter
as configurações de proxy web via WPAD. Estas consultas com o servidor DHCP não
servem para atualizar o tempo de concessão do IP em seu banco de dados (para isso é
enviada a mensagem DHCPREQUEST).
Liberando DHCP
O cliente envia uma solicitação (DHCPRELEASE) ao servidor DHCP para liberar a

configuração de rede e o cliente DHCP desativa seu endereço IP. Como os dispositivos
de lado do cliente geralmente não sabem quando os usuários podem desligá-los da rede,
o protocolo não obriga o envio de DHCPRELEASE.
Parâmetros de configuração de cliente no DHCP
Um servidor DHCP pode fornecer parâmetros de configuração opcionais para o cliente.

RFC 2132 descreve as opções disponíveis DHCP definidas pelo Internet Assigned
Numbers Authority (IANA) - DHCP e PARÂMETROS BOOTP. Um cliente DHCP
pode selecionar, manipular e substituir os parâmetros fornecidos por um servidor
DHCP.
Opções do DHCP
Existe uma opção para identificar o fornecedor e funcionalidade de um cliente DHCP. A

informação é uma sequência de comprimento variável de caracteres ou octetos que tem
um significado especificado pelo fornecedor do cliente DHCP. Um método que um
cliente DHCP pode utilizar para se comunicar com o servidor que está usando um certo
tipo de hardware ou de firmware é definir um valor em seus pedidos de DHCP chamado
de classe de fornecedor Identifier (VCI) (Opção 60). Este método permite a um servidor
DHCP para diferenciar entre os dois tipos de máquinas de cliente e processar os pedidos
provenientes dos dois tipos de modems de forma adequada. Alguns tipos de set-top
boxes também definir a VCI (Opção 60) para informar o servidor DHCP sobre o tipo de
hardware e funcionalidade do dispositivo. O valor que essa opção é definida para dar ao
servidor DHCP uma dica sobre as informações necessárias extra que este cliente precisa
de uma resposta do DHCP.[1]
RFC1497 vendor extensions[2]
Code Name Length Notes
Can be used to pad other options so that they are

0 Pad[3] 1 octet
aligned to the word boundary
Must be sent after the router option (option 3) if

1 Subnet Mask[4] 4 octets
both are included
2 Time Offset[5] 4 octets
multiples of 4 Available routers, should be listed in order of

3 Router
octets preference
multiples of 4 Available time servers to synchronise with, should be

4 Time Server
octets listed in order of preference
multiples of 4 Available IEN116 name servers, should be listed in

5 Name Server
octets order of preference
Domain Name multiples of 4 Available DNS servers, should be listed in order of

6
Server octets preference
multiples of 4 Available log servers, should be listed in order of

7 Log Server
octets preference.
multiples of 4
8 Cookie Server
octets
multiples of 4
9 LPR Server
octets
multiples of 4
10 Impress Server
octets
Resource Location multiples of 4

11
Server octets
minimum of 1
12 Host Name
octet
13 Boot File Size 2 octets Length of the boot image in 4KiB blocks
minimum of 1
14 Merit Dump File Path where crash dumps should be stored
octet
minimum of 1
15 Domain Name
octet
16 Swap Server 4 octets
minimum of 1
17 Root Path
octet
minimum of 1
18 Extensions Path
octet
255 End 0 octets Used to mark the end of the vendor option field
IP Layer Parameters per Host[6]
19 IP Forwarding Enable/Disable 1 octet
20 Non-Local Source Routing Enable/Disable 1 octet
21 Policy Filter multiples of 8 octets
22 Maximum Datagram Reassembly Size 2 octets
23 Default IP Time-to-live 1 octet
24 Path MTU Aging Timeout 4 octets
25 Path MTU Plateau Table multiples of 2 octets
IP Layer Parameters per Interface[7]
26 Interface MTU 2 octets
27 All Subnets are Local 1 octet
28 Broadcast Address 4 octets
29 Perform Mask Discovery 1 octet
30 Mask Supplier 1 octet
31 Perform Router Discovery 1 octet
32 Router Solicitation Address 4 octets
33 Static Route multiples of 8 octets A list of destination/router pairs

Link Layer Parameters per Interface[8]
34 Trailer Encapsulation Option 1 octet
35 ARP Cache Timeout 4 octets
36 Ethernet Encapsulation 1 octet
TCP Parameters[9]
37 TCP Default TTL 1 octet
38 TCP Keepalive Interval 4 octets
39 TCP Keepalive Garbage 1 octet
Application and Service Parameters[10]
40 Network Information Service Domain minimum of 1 octet
41 Network Information Servers multiples of 4 octets
42 Network Time Protocol Servers multiples of 4 octets
43 Vendor Specific Information minimum of 1 octets
44 NetBIOS over TCP/IP Name Server multiples of 4 octets
45 NetBIOS over TCP/IP Datagram Distribution Server multiples of 4 octets
46 NetBIOS over TCP/IP Node Type 1 octet
47 NetBIOS over TCP/IP Scope minimum of 1 octet
48 X Window System Font Server multiples of 4 octets
49 X Window System Display Manager multiples of 4 octets
64 Network Information Service+ Domain minimum of 1 octet
65 Network Information Service+ Servers multiples of 4 octets
68 Mobile IP Home Agent multiples of 4 octets
69 Simple Mail Transport Protocol (SMTP) Server multiples of 4 octets

70 Post Office Protocol (POP3) Server multiples of 4 octets
71 Network News Transport Protocol (NNTP) Server multiples of 4 octets
72 Default World Wide Web (WWW) Server) multiples of 4 octets
73 Default Finger Server multiples of 4 octets
74 Default Internet Relay Chat (IRC) Server multiples of 4 octets
75 StreetTalk Server multiples of 4 octets
76 StreetTalk Directory Assistance (STDA) Server multiples of 4 octets
DHCP Extensions[11]
50 Requested IP Address 4 octets
51 IP Address Lease Time 4 octets
52 Option Overload 1 octet
53 DHCP Message Type 1 octet
54 Server Identifier 4 octets
55 Parameter Request List minimum of 1 octet
56 Message minimum of 1 octet
57 Maximum DHCP Message Size 2 octets
58 Renewal (T1) Time Value 4 octets
59 Rebinding (T2) Time Value 4 octets
60 Vendor class identifier minimum of 1 octet
61 Client-identifier minimum of 2 octets
66 TFTP server name minimum of 1 octet
67 Bootfile name minimum of 1 octet
Retransmissão DHCP
Em redes pequenas, onde apenas uma sub-rede IP está a ser gerido, os clientes DHCP se
comunicar diretamente com os servidores DHCP. No entanto, os servidores DHCP
também pode fornecer endereços IP para várias sub-redes. Neste caso, um cliente
DHCP que ainda não adquiriu um endereço IP não podem se comunicar diretamente
com o servidor DHCP usando o roteamento IP, porque não tem um endereço de IP, nem
ele sabe o endereço IP de um roteador. A fim de permitir que os clientes DHCP em sub-
redes não diretamente servidos por servidores DHCP para se comunicar com servidores
DHCP, os agentes de retransmissão DHCP pode ser instalado nesses sub-redes. As
transmissões do cliente DHCP no link local, o agente de retransmissão recebe a
transmissão e transmite para um ou mais servidores DHCP usando unicast. O agente de
retransmissão armazena seu próprio endereço IP no campo GIADDR do pacote DHCP.
O servidor DHCP usa o GIADDR para determinar a sub-rede na qual o agente de
retransmissão recebeu a transmissão, e atribui um endereço IP na sub-rede. Quando as
respostas do servidor DHCP para o cliente, ele envia a resposta para o endereço
GIADDR, novamente usando unicast. O agente de retransmissão então retransmite a
resposta na rede local.
Confiabilidade
O protocolo DHCP fornece confiabilidade de várias maneiras: renovação periódica,

religação e failover. Clientes DHCP são atribuídos locações que duram por algum
período de tempo. Os clientes começam a tentar renovar suas concessões uma vez
metade do intervalo o arrendamento expirou. Eles fazem isso através do envio de uma
mensagem DHCPREQUEST unicast para o servidor DHCP que concedeu o contrato
original. Se esse servidor for inativo ou inacessível, ele vai deixar de responder ao
DHCPREQUEST. No entanto, o DHCPREQUEST será repetido pelo cliente ao longo
do tempo, [especificar], para quando o servidor DHCP volta-se ou torna-se acessível
novamente, o cliente DHCP vai conseguir entrar em contato com ela, e renovar o seu
contrato. Se o servidor DHCP está inacessível por um período prolongado de tempo,
[especificar] o cliente DHCP tentará religar, transmitindo sua DHCPREQUEST vez de
unicasting-lo. Porque ele é transmitido, a mensagem vai chegar DHCPREQUEST todos
os servidores DHCP disponíveis. Se algum outro servidor DHCP é capaz de renovar a
concessão, ele vai fazê-lo neste momento.
A fim de religação para o trabalho, quando o cliente contatar com êxito um servidor
DHCP de backup, o servidor deve ter informações precisas sobre a ligação do cliente.
Manter informações vinculativas precisa entre dois servidores é um problema
complicado, se os dois servidores são capazes de atualizar o banco de dados mesma
locação, deve haver um mecanismo para evitar conflitos entre as atualizações nos
servidores independentes. Um padrão para implementação de servidores tolerantes a
falhas DHCP foi desenvolvido na Internet Engineering Task Force.
Se religação falhar, o arrendamento acabará por expirar. Quando a concessão expira, o

cliente deve parar de usar o endereço IP concedido a ele em seu contrato. Na época, ele
irá reiniciar o processo de DHCP desde o início, transmitindo uma mensagem
DHCPDISCOVER. Desde o seu contrato de arrendamento expirou, ele vai aceitar
qualquer endereço IP que lhe é oferecido. Uma vez que tem um novo endereço IP,
provavelmente a partir de um servidor DHCP diferente, vai mais uma vez ser capaz de
usar a rede. No entanto, como seu endereço IP mudou, as conexões em curso será
quebrado.
Segurança
A base de protocolo DHCP não inclui nenhum mecanismo de autenticação. Por isso, é
vulnerável a uma variedade de ataques. Estes ataques se dividem em três categorias
principais:
 Fornecimento de informações falsas a clientes por servidores DHCP não autorizados.

 Acesso aos recursos da rede por clientes não autorizados.
 Ataques exaustivos aos recursos da rede advindos de clientes DHCP mal-
intencionados.
Porque o cliente não tem como validar a identidade de um servidor DHCP, servidores
DHCP não autorizados podem ser operados em redes, prestação de informações
incorretas aos clientes DHCP. Isso pode servir tanto como um ataque de negação de
serviço, impedindo o cliente de ter acesso à conectividade de rede. Porque o servidor
DHCP fornece o cliente DHCP com endereços IP do servidor, como o endereço IP de
um ou mais servidores DNS, um atacante pode convencer um cliente DHCP para fazer
pesquisas através de seu DNS seu próprio servidor DNS, e pode, portanto, fornecer suas
próprias respostas a consultas DNS do cliente. Por sua vez, permite que o atacante para
redirecionar o tráfego de rede através de si, permitindo-lhe escutar as conexões entre os
servidores de rede do cliente e ele entra em contato, ou simplesmente para substituir os
servidores de rede com o seu próprio. Porque o servidor DHCP não tem nenhum
mecanismo seguro para autenticar o cliente, os clientes podem obter acesso não
autorizado aos endereços IP de apresentação de credenciais, tais como identificadores
do cliente, que pertencem a outros clientes DHCP. Isso também permite que os clientes
DHCP para esgotar o DHCP armazenamento de servidor de endereços IP, apresentando
novas credenciais cada vez que ele pede um endereço, o cliente pode consumir todos os
endereços IP disponíveis em um link de rede particular, impedindo outros clientes
DHCP da obtenção de serviços. DHCP fornece alguns mecanismos para mitigar esses
problemas.
O Relé de Agente de Informações extensão protocolo Option (RFC 3046) permite que
os operadores de rede para conectar marcas a mensagens DHCP uma vez que estas
mensagens chegam na rede de confiança do operador de rede. Esta tag é então usado
como um token de autorização para controlar o acesso do cliente aos recursos da rede.
Porque o cliente não tem acesso à rede a montante do agente de retransmissão, a falta de
autenticação não impede que o operador do servidor DHCP de confiar no token de
autorização.
Outro ramal, autenticação para DHCP mensagens (RFC 3118), fornece um mecanismo
para autenticação de mensagens DHCP. Infelizmente RFC 3118 não viu a adoção
generalizada por causa dos problemas de gerenciamento de chaves para um grande
número de clientes DHCP.
Rede sem DHCP - APIPA
APIPA é a abreviatura de Automatic Private IP Addressing. Esta é uma nova

funcionalidade que foi introduzida no Microsoft Windows 98, está presente no
Windows 2000, Windows XP, Windows Vista, Windows 7, Longhorn Server e no
Windows Server 2003. Imagine um cliente com o protocolo TCP/IP instalado e
configurado para obter as configurações do protocolo TCP/IP a partir de um servidor
DHCP. O cliente é inicializado, porém não consegue se comunicar com um servidor
DHCP. Nesta situação, o Windows, usa o recurso APIPA, e automaticamente atribui um
endereço IP da rede 169.254.0.0/255.255.0.0. Este é um dos endereços especiais,
reservados para uso em redes internas, ou seja, este não seria um endereço de rede,
válido na Internet. A seguir descrevo mais detalhes sobre a funcionalidade APIPA.
ATENÇÃO: O número de rede usado pelo recurso APIPA é o seguinte:

169.254.0.0/255.255.0.0
Nota: O recurso APIPA é especialmente útil para o caso de uma pequena rede, com 4 ou
5 computadores, onde não existe um servidor disponível. Neste caso pode-se configurar
todos os computadores para usarem o DHCP. Ao inicializar, os clientes não conseguirão
localizar um servidor DHCP (já que não existe nenhum servidor DHCP nesta rede do
nosso exemplo). Neste caso o recurso APIPA atribuirá endereços da rede
169.254.0.0/255.255.0.0 para todos os computadores da rede. O resultado final é que
todos ficam configurados com endereços IP da mesma rede e poderão se comunicar,
compartilhando recursos entre si. É uma boa solução para uma rede doméstica ou de
pequeno escritório.
Ver também
 DHCPv6
 DNS
 Endereço IP
 Redes de computadores
 Protocolo
Referências
1.
 Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor
Extensions». IETF. Section 3: RFC 1497 vendor extensions. Consultado em 26 de julho de 2012
  Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP Vendor
Extensions». IETF. Section 3: RFC 1497 vendor extensions. Consultado em 26 de julho de 2012
Extensions». IETF. Section 3.1: Pad Option. Consultado em 26 de julho de 2012
Extensions». IETF. Section 3.3: Subnet Mask. Consultado em 26 de julho de 2012
Extensions». IETF. Section 3.4: Time Offset. Consultado em 26 de julho de 2012
Extensions». IETF. Section 4: IP Layer Parameters per Host. Consultado em 26 de julho de 2012
Extensions». IETF. Section 5: IP Layer Parameters per Interface. Consultado em 26 de julho de
2012
Extensions». IETF. Section 6: Link Layer Parameters per Interface. Consultado em 26 de julho de
2012
Extensions». IETF. Section 7: TCP Parameters. Consultado em 26 de julho de 2012
Extensions». IETF. Section 8: Application and Service Parameters. Consultado em 26 de julho de
2012
 Alexander, Steve; Droms, Ralph (1997). «RFC 2132: DHCP Options and BOOTP
Vendor Extensions». IETF. Section 9: DHCP Extensions. Consultado em 26 de julho de
2012
Sistema de Nomes de Domínio

O Sistema de Nomes de Domínio,[1][2][3] mais conhecido pela nomenclatura em Inglês
Domain Name System (DNS), é um sistema hierárquico e distribuído de
gerenciamento de nomes para computadores, serviços ou qualquer máquina conectada à
Internet ou a uma rede privada. Faz a associação entre várias informações atribuídas a
nomes de domínios e cada entidade participante. Em sua utilização mais convencional,
associa nomes de domínios mais facilmente memorizáveis a endereços IP numéricos,
necessários à localização e identificação de serviços e dispositivos, processo esse
denominado resolução de nome. Em virtude do banco de dados de DNS ser distribuído,
seu tamanho é ilimitado e o desempenho não se degrada substancialmente quando se
adicionam mais servidores. Por padrão, o DNS usa o protocolo User Datagram Protocol
(UDP) na porta 53 para servir as solicitações e as requisições.[4]
O DNS apresenta uma arquitetura cliente/servidor, podendo envolver vários servidores

DNS na resposta a uma consulta. O servidor DNS resolve nomes para os endereços IP e
de endereços IP para nomes respetivos, permitindo a localização de hosts num domínio
determinado.
Num sistema livre, o serviço é comummente implementado pelo software BIND. Este
serviço geralmente se encontra localizado no servidor DNS primário. O servidor DNS
secundário é uma espécie de cópia de segurança do servidor DNS primário. Assim, ele
se torna parte necessária para quem quer usar a internet de uma forma mais fácil, evita
que hackers roubem os seus dados pessoais.[5]
Existem centenas de servidores-raiz DNS (root servers) no mundo todo, agrupados em
13 zonas DNS raiz,[6] das quais sem elas a Internet não funcionaria. Destes, dez estão
localizados nos Estados Unidos da América, dois na Europa e um na Ásia. Para
aumentar a base instalada destes servidores, foram criadas réplicas localizadas por todo
o mundo, inclusive no Brasil desde 2003.
Índice
 1 História
 2 Visão geral
 3 Hierarquia
o 3.1 Servidores-raiz
o 3.2 Servidores de domínio de topo (top-level domain)
o 3.3 Servidores com autoridade
 4 Métodos de resolução: iterativo e recursivo
 5 Melhorias de performance
o 5.1 Cache
o 5.2 Servidor local
 6 DNS reverso (reverse lookup)
 7 Estrutura
 8 Registro de nome de domínio
 9 Referências
 10 Ver também
 11 Ligações externas
História
A implementação do DNS-Berkeley, foi desenvolvida originalmente para o sistema

operacional BSD UNIX 4.3. A implementação do Servidor de DNS Microsoft se tornou
parte do sistema operacional Windows NT na versão Server 4.0. O DNS passou a ser o
serviço de resolução de nomes padrão a partir do Windows 2000 Server como a maioria
das implementações de DNS teve suas raízes nas RFCs 882 e 883, e foi atualizado nas
RFCs 1034 e 1035.
Visão geral
Um recurso da internet, por exemplo um site da Web, pode ser identificado de duas
maneiras: pelo seu nome de domínio[7], por exemplo, “www.wikipedia.org” ou pelo
endereço de IP[8] dos equipamentos que o hospedam (por exemplo, 208.80.152.130 é o
IP associado ao domínio www.wikipedia.org[9]). Endereços IP são usados pela camada
de rede para determinar a localização física e virtual do equipamento. Nomes de
domínio, porém, são mais mnemônicos para o usuário e empresas. É então necessário
um mecanismo para resolver um nome de domínio em um endereço IP. Esta é a
principal função do DNS.
Ocasionalmente, presume-se que o DNS serve apenas o objetivo de mapear nomes de

hosts da Internet a dados e mapear endereços para nomes de host. Porém, o DNS pode
armazenar uma grande variedade de tipo de dados, para praticamente qualquer
finalidade.[10]
Hierarquia
Devido ao tamanho da Internet, armazenar todos os pares domínio - endereço IP em um

único servidor DNS seria inviável por questões de escalabilidade, que incluem:
 Disponibilidade: se o único servidor de DNS falhasse, o serviço se tornaria indisponível

para o mundo inteiro;
 Volume de tráfego: o servidor deveria tratar os pedidos DNS do planeta inteiro;
 Distância: grande parte dos usuários estaria muito distante do servidor, onde quer que
ele fosse instalado, gerando grandes atrasos para resolver pedidos DNS;
 Manutenção do banco de dados: o banco de dados deveria armazenar uma
quantidade de dados enorme e teria que ser atualizado com uma frequência muito
alta (assim que um novo domínio fosse associado a um endereço IP).
A solução encontrada foi usar uma base de dados distribuída e hierárquica. Os

servidores DNS se dividem nas seguintes categorias:
 Servidores-raiz;
 Servidores de domínio de topo;
 Servidores com autoridade.
Servidores-raiz
Ver artigo principal: Servidor-raiz
No topo da hierarquia estão os 13 servidores raiz. Um servidor-raiz (root name server) é

um servidor de nome para a zona raiz do DNS (Domain Name System). A sua função é
responder diretamente às requisições de registros da zona raiz e responder a outras
requisições retornando uma lista dos servidores de nome designados para o domínio de
topo apropriado. Os servidores raiz são parte crucial da Internet porque são o primeiro
passo em resolver nomes para endereços IP, esses últimos usados para comunicação
entre hosts.
Servidores de domínio de topo (top-level domain)
Cada domínio é formado por nomes separados por pontos. O nome mais à direita é
chamado de domínio de topo. Exemplos de domínios de topo são .com, .org, .net, .edu,
.inf, .gov.
Cada servidor de domínio de topo conhece os endereços dos servidores autoritativos que
pertencem àquele domínio de topo, ou o endereço de algum servidor DNS intermediário
que conhece um servidor autoritativo.
Há também terminações orientadas a países, chamadas de Código de País para

Domínios de Topo/Primeiro Nível (Country Code Top Level Domains). Por exemplo:
.br para o Brasil, .ar para a Argentina, .fr para a França e assim por diante. Há também
combinações, como .com.br e .blog.br.[11]
Servidores com autoridade
O servidor com autoridade de um domínio possui os registros originais que associam

aquele domínio a seu endereço de IP. Toda vez que um domínio adquire um novo
endereço, essas informações devem ser adicionadas a pelo menos dois servidores
autoritativos[12]. Um deles será o servidor autoritativo principal e o outro, o secundário.
Isso é feito para minimizar o risco de, em caso de erros em um servidor DNS, perder
todas as informações originais do endereço daquele domínio.
Métodos de resolução: iterativo e recursivo
Com as três classes de servidores DNS, já é possível resolver qualquer requisição DNS.
Basta fazer uma requisição a um servidor raiz, e esse retornará o endereço do servidor
de topo responsável. Então repete-se a requisição para o servidor de topo, que retornará
o endereço do servidor autoritativo ou algum intermediário. Repete-se a requisição aos
servidores intermediários (se houver) até obter o endereço do servidor autoritativo, que
finalmente retornará o endereço IP do domínio desejado.
Repare que essa solução não resolve um dos problemas de escalabilidade

completamente: os servidores raiz tem que ser acessados uma vez para cada requisição
que for feita em toda a internet. Esses servidores também podem estar muito longe do
cliente que faz a consulta. Além disso, para resolver cada requisição, são precisas várias
consultas, uma para cada servidor na hierarquia entre o raiz e o autoritativo.
Esta forma de resolver consultas é chamada de iterativa ou não-recursiva: cada servidor

retorna ao cliente (ou ao servidor local requisitante, como explicado adiante) o endereço
do próximo servidor no caminho para o autoritativo, e o cliente ou servidor local fica
encarregado de fazer as próximas requisições.
Há também o método recursivo: o servidor pode se responsabilizar por fazer a

requisição ao próximo servidor, que fará a requisição ao próximo, até chegar ao
autoritativo, que retornará o endereço desejado, e esse endereço será retornado para
cada servidor no caminho até chegar ao cliente. Esse método faz com que o cliente
realize apenas uma consulta e receba diretamente o endereço desejado, porém aumenta
a carga dos servidores no caminho. Por isso, servidores podem se recusar a resolver
requisições recursivas.
Melhorias de performance
Dois recursos são usados em conjunto para reduzir a quantidade de requisições que os
servidores raiz devem tratar e a quantidade de requisições feitas para resolver cada
consulta: cache e servidor local.
Cache
Toda vez que um servidor retorna o resultado de uma requisição para a qual ele não é
autoridade (método de resolução recursivo), ele armazena temporariamente aquele
registro. Se, dentro do tempo de vida do registro (TTL, Time to Live), alguma requisição
igual for feita, o servidor DNS pode retornar o resultado sem a necessidade de uma nova
consulta. Note que isso pode provocar inconsistência, já que se um domínio mudar de
endereço durante o tempo de vida do cache, o registro estará desatualizado. Apenas o
servidor autoritativo tem a garantia de ter a informação correta. É possível exigir, na
mensagem de requisição DNS, que a resposta seja dada pelo servidor autoritativo.
Servidor local
Esse tipo de servidor não pertence à hierarquia DNS, mas é fundamental para o seu bom
funcionamento. Em vez de fazer requisições a um servidor raiz, cada cliente faz sua
requisição a um servidor local, que geralmente localiza-se fisicamente muito próximo
do cliente, por exemplo um servidor proxy. Este se encarrega de resolver a requisição.
Com o uso de cache, o servidor local pode ter a resposta pronta, ou ao menos conhecer
algum servidor mais próximo ao autoritativo que o raiz (por exemplo, o servidor de
topo), reduzindo a carga dos servidores raiz.
DNS reverso (reverse lookup)
Normalmente o DNS atua resolvendo o nome do domínio de um host qualquer para seu
endereço IP correspondente. O DNS Reverso resolve o endereço IP, buscando o nome
de domínio associado ao host. Ou seja, quando temos disponível o endereço IP de um
host e não sabemos o endereço do domínio (nome dado à máquina ou outro
equipamento que acesse uma rede), tentamos resolver o endereço IP através do DNS
reverso que procura qual nome de domínio está associado àquele endereço. Os
servidores que utilizam o DNS Reverso conseguem verificar a autenticidade de
endereços, verificando se o endereço IP atual corresponde ao endereço IP informado
pelo servidor DNS. Isto evita que alguém utilize um domínio que não lhe pertence para
enviar spam, por exemplo.
Estrutura
The hierarchical domain name system, organized into zones, each served by a name server
Registro de nome de domínio
A organização responsável por atribuir nomes de domínio e endereços IP em nível

global é a ICANN.
Referências
1.
 «ICANN | Archives | ICANN - Portuguese». archive.icann.org. Consultado em 17 de março de

2018
  jamesmci. «Sistema de nomes de domínio (DNS)». docs.microsoft.com. Consultado em 17
de março de 2018
  «Como funciona a estrutura mundial do Sistema de Nomes de Domínios?».
http://www.registrodedominios.net.br
  RFC 1035, Domain Names - Implementation and Specification, P. Mockapetris, The

Internet Society (November 1987)
  «DNS: Entenda como se proteger com o analista de segurança da PSafe»
  «IANA: Root Servers». Consultado em 29 de junho de 2017
  RFC 1034 (em inglês)
  RFC 781 (em inglês)
  IP da wikipedia (em inglês)
  «rfc2181»
  «O que é DNS (Domain Name System)?». InfoWester. Consultado em 26/-7/2017 Verifique

data em: |acessodata= (ajuda)
 «Name Server Definition». www.techterms.com. Consultado em 1 de agosto de
2012
File Transfer Protocol

FTP ou File Transfer Protocol (em português, Protocolo de Transferência de
Arquivos) é uma forma de transferir arquivos (Portugal: conhecidos como ficheiros).
Pode referir-se tanto ao protocolo quanto ao programa que implementa este protocolo
(Servidor FTP, neste caso, tradicionalmente aparece em letras minúsculas, por
influência do programa de transferência de arquivos do Unix).
A transferência de dados em redes de computadores envolve normalmente transferência

de arquivos e acesso a sistemas de arquivos remotos (com a mesma interface usada nos
arquivos locais). O FTP (RFC 959) é baseado no TCP, mas é anterior à pilha de
protocolos TCP/IP, sendo posteriormente adaptado para o TCP/IP. É o padrão da pilha
TCP/IP para transferir arquivos, é um protocolo genérico independente de hardware.
Índice
 1 Visão geral do protocolo

 2 Como ocorre a transferência de arquivos
 3 Acesso aos servidores FTP
 4 Modos e interfaces
 5 Comandos do cliente FTP
 6 Tradução de nomes de arquivos
 7 Mensagens FTP
 8 Modo cliente-servidor do FTP
 9 Lista de Comandos FTPs
 10 Servidores FTP
 12 Referências
Visão geral do protocolo
O protocolo é especificado na RFC959, resumida logo a seguir.[1]
Um cliente realiza uma conexão TCP para a porta 21 do servidor. Essa conexão,
chamada de conexão de controle, permanece aberta ao longo da sessão enquanto uma
segunda conexão, chamada conexão de dados, é estabelecida na porta 20 do servidor e
em alguma porta do cliente (estabelecida no diálogo entre ambos) como requisitado para
a transferência de arquivo. A conexão de controle é utilizada para administração da
sessão (comandos, identificação, senhas)[2] entre cliente e servidor utilizando um
protocolo semelhante ao Telnet. Por exemplo, "RETR filename" iria transferir o arquivo
especificado de um servidor para um cliente. Devido a essa estrutura de duas portas,
FTP é considerado out-of-band, ao contrário de protocolos in-band, tal como HTTP.[2]
O servidor responde na conexão de controle com três dígitos de código de estado em

ASCII com uma mensagem de texto opcional. Por exemplo, "200" ou "200 OK"
significa que o último comando obteve sucesso. Os números representam o número do
código e o texto opcional representa as explicações ou parâmetros necessários.[3] Uma
transferência de arquivo em progresso, sobre uma conexão de dados, pode ser abortada
utilizando uma mensagem de interrupção enviada sobre a conexão de controle.
FTP pode ser executado em modo ativo ou passivo, os quais determinam como a
conexão de dados é estabelecida. No modo ativo, o cliente envia para o servidor o
endereço IP e o número da porta na qual ele irá ouvir e então o servidor inicia a conexão
TCP. Em situações onde o cliente está atrás de um firewall e inapto para aceitar entradas
de conexões TCP, o modo passivo pode ser utilizado. O cliente envia um comando
PASV para o servidor e recebe um endereço IP e um número de porta como resposta, os
quais o cliente utiliza para abrir a conexão de dados com o servidor.[1] Ambos os modos
foram atualizados em Setembro de 1998 para adicionar suporte ao IPv6 e feitas algumas
mudanças no modo passivo, tornando-o modo passivo estendido.[4]
Durante a transferência de dados sobre a rede, quatro representações de dados podem

ser utilizadas[5]:
 Modo ASCII: usado para texto. Dado é convertido, se necessário, da representação de

caracteres do host remetente para 8-bit em ASCII antes da transmissão, e (novamente,
se necessário) para a representação de caracteres do host destinatário. Como
consequência, esse modo é inapropriado para arquivos que contenham dados
numéricos em binário, ponto flutuante ou forma decima codificada em binário.
 Modo imagem (normalmente chamada de modo binário): a máquina remetente envia
cada arquivo byte a byte e como tal, o destinatário armazena o fluxo de bytes
conforme ele os recebe (o suporte ao modo imagem tem sido recomendado para
todas as implementações de FTP).
 Modo EBCDIC: utilizado para texto simples entre hosts utilizando o conjunto de
caracteres EBCDIC.
 Modo local: permite que dois computadores com configurações idênticas enviem
dados em um formato proprietário sem a necessidade de convertê-los para ASCII.
Para arquivos texto, são fornecidas opções para diferentes controles de formato e
estrutura de registros. Esses recursos foram projetados para suporte à formatação Telnet
ou ASA.
A transferência de dados pode ser feita em qualquer um dos três modos a seguir:[3]
 Modo fluxo: dado é enviado como um fluxo contínuo, liberando FTP de fazer algum
processamento. Ao invés disso, todo processamento é deixado para o TCP. Nenhum
indicador de fim de arquivo é necessário, a menos que o dado esteja dividido dentro
de registros.
 Modo de bloqueio: FTP quebra o dado dentro de vários blocos( bloco de cabeçalho,
contagem de byte e campo de dado) e então passa-o para o TCP. [5]
 Modo comprimido: dado é comprimido utilizando um algoritmo simples.
Como ocorre a transferência de arquivos
A transferência de arquivos dá-se entre um computador chamado "cliente" (aquele que

solicita a conexão para a transferência de dados) e um servidor (aquele que recebe a
solicitação de transferência). O utilizador, através de software específico, pode
selecionar quais arquivos enviar ou receber do servidor. Para existir uma conexão ao
servidor,caso o servidor exija, o utilizador informa um nome de utilizador (ou
username, em inglês) e uma senha password, bem como o nome correto do servidor ou
seu endereço IP. Se os dados foram informados corretamente, a conexão pode ser
estabelecida.
Acesso aos servidores FTP
O acesso a servidores FTP pode ocorrer de dois modos: através de uma interface ou
através da linha de comando, tanto usuários LINUX como usuários Windows podem
acessar através dos dois modos. O modo linha de comando está presente em qualquer
distribuição LINUX-like e Windows, através do telnet.
A partir de qualquer navegador credenciado (Internet Explorer, Firefox, ou mesmo no

Windows Explorer), conforme a norma RFC1738[6] também é possível aceder a um
servidor FTP digitando na barra de endereço:
ftp://[username]:[password]@[servidor]
ou
ftp://[username]:[password]@[servidor]:[porta]
Modos e interfaces
O protocolo subjacente ao FTP pode rodar nos modos interativo ou batch. O cliente
FTP fornece uma interface interativa, enquanto que o MIME e o HTTP usam-no
diretamente. O protocolo permite a gravação e obtenção de arquivos, a listagem da pasta
e a alteração da pasta de trabalho.
Comandos do cliente FTP
Os servidores de FTP raramente mudam, mas novos clientes FTP aparecem com
bastante regularidade. Estes clientes variam no número de comandos que implementam,
a maioria dos clientes FTP comerciais implementam apenas um pequeno subgrupo de
comandos FTP. Mesmo que o FTP seja um protocolo orientado a linha de comandos, a
nova geração dos clientes FTP esconde esta orientação num ambiente gráfico, muitas
vezes, muito desenvolvido.
A interface cliente do FTP do BSD UNIX é um padrão por si mesma, possuindo muitos
comandos arcaicos como tenex ou carriage control, que hoje não têm uso. Os
comandos mais usados são o cd, dir, ls,get e put.
O FTP tem particularidades que são hoje pouco comuns. Depois da ativação do ftp, é
estabelecida uma conexão ao host remoto. Esta conexão envolve o uso da conta do
usuário no host remoto, sendo que alguns servidores FTP disponibilizam anonymous
FTP.
Certos comandos são os que fazem a transferência bidirecional de arquivos, são eles:
 get do servidor FTP para o host local ( mget para mais que um arquivo)
 put para o servidor FTP a partir do host local (mput para mais que um arquivo)
Nota: alguns comandos podem não funcionar com o usuário sendo anonymous, pois tal
conta tem limitações de direitos a nível do sistema operacional.
Tradução de nomes de arquivos
A sintaxe dos nomes dos arquivos pode ser incompatível entre diferentes Sistemas
Operacionais. O UNIX usa 128 caracteres, maiúsculas e minúsculas, enquanto que o
DOS usa 8 + 3 caracteres e apenas maiúsculas. Certos nomes não podem ser usados em
alguns sistemas. Devido a isto tudo o BSD ftp define regras para a tradução de nomes.
Mensagens FTP
O FTP permite dois modos de transferência de mensagens FTP: texto (com traduções
apropriadas) ou binário (sem tradução). Cada mensagem do servidor inclui um
identificador decimal de 3 dígitos (exemplo: 226 Transfer complete). Estas
mensagens podem ser vistas ou não, usando para isso o modo verbose ou quiet,
respectivamente.
Modo cliente-servidor do FTP
O servidor remoto aceita uma conexão de controle do cliente local. O cliente envia
comandos para o servidor e a conexão persiste ao longo de toda a sessão (tratando-se
assim de um protocolo que usa o TCP).
O servidor cria uma conexão de dados para a transferência de dados, sendo criada uma
conexão para cada arquivo transferido. Estes dados são transferidos do servidor para o
cliente e vice e versa.
Os comandos estão separados dos dados e o cliente pode enviar comandos durante a
transferência de dados. O encerramento da conexão indica o fim do arquivo.
Lista de Comandos FTPs
Os comandos abaixo podem ser executados no FTP através da linha de comando. Os

comandos do FTP podem ser abreviados, desde que não formem expressões ambíguas.
Os comandos podem estar abreviados. Seguem os comandos:
 !: Executa o comando na máquina local.

 ?: Semelhante a help.
 append: Adiciona dados a um arquivo existente.
 ascii: Configura o tipo de transferência de arquivos para ASCII.
 bell: Emite um bip quando um comando é executado.
 binary: Configura o tipo de transferência de arquivos para binário.
 bye: Encerra a sessão FTP.
 cd: Seguido de caminho/diretório muda para o diretório informado.
 delete: Apaga um arquivo. Para mais de um arquivo usa-se mdelete.
 debug: Estabelece a modalidade de depuração.
 dir: Mostra o conteúdo do diretório servidor atual.
 disconnect: Semelhante a bye.
 get: Obtêm um arquivo do servidor. Para mais de um arquivo usa-se mget.
 glob: Seleciona a expansão para nomes de arquivo.
 hash: Demonstra cada bloco do arquivo durante a transferência. Cada bloco compõe-
se de 1024 bytes.
 help: Lista sumariamente todos comandos disponíveis.
 literal: Permite enviar comandos arbitrários.
 ls: Mostra uma lista abreviada do conteúdo do diretório servidor.Para mais de uma
pasta usa-se*mls.
 mkdir: Cria um diretório ou subdiretório no servidor.
 prompt: Ativa/desativa o modo interativo.
 put: Envia um arquivo ao servidor. Para enviar mais de um arquivo usa-se mput.
 pwd: Mostra o diretório de trabalho.
 quit: Finaliza a sessão FTP.
 quote: Envia subcomandos do servidor FTP, como se encontram no servidor.
 recv: Similar a get.
 remotehelp: Solicita ajuda do servidor FTP remoto.
 rename: Renomeia um arquivo.
 send: Semelhante a put.
 status: Obtem informações de estado do servidor.
 trace: Demonstra o caminho percorrido pelo arquivo na transferência.
 type: Especifica o tipo de representação.
 user: Iniciar a sessão no servidor.
 verbose: Ativa/desativa a modalidade literal.
Servidores FTP
 Servidor FTP (Lista)

 FileZilla Server (Windows)
 Pure-FTPd (Unix)
 VsFTPd (Unix)
 ProFTPd (Unix)
Ligações externas
 RFC 959 – File Transfer Protocol

 RFC 1579 – Firewall Friendly FTP
 RFC 2228 – FTP Security Extensions
 RFC 2428 – FTP Extensions for IPv6 and NATs
 RFC 2640 – Internationalization of the File Transfer Protocol
Protocolo
 Raw FTP command list

 FTP Sequence Diagram
 FTP Server Test (Online)
Referências
1.
 Postel, J., & Reynolds. J. (October 1985). RFC 959. In The Internet Engineering Task Force.
Retrieved from http://www.ietf.org/rfc/rfc0959.txt
  Kurose, J.F. & Ross, K.W. (2010). Computer Networking. 5th ed. Boston, MA: Pearson
Education, Inc.
  Forouzan, B.A. (2000). TCP/IP: Protocol Suite. 1st ed. New Delhi, India: Tata McGraw-Hill
Publishing Company Limited.
  Allman, M. & Metz, C. & Ostermann, S. (September 1998). RFC 2428. In The Internet
Engineering Task Force. Retrieved from http://www.ietf.org/rfc/rfc2428.txt
  Clark, M.P. (2003). Data Networks IP and the Internet. 1st ed. West Sussex, England: John
Wiley & Sons Ltd.
 «RFC 1738 Uniform Resource Locators (URL)»

Hypertext Transfer Protocol
O Hypertext Transfer Protocol, sigla HTTP (em português Protocolo de
Transferência de Hipertexto) é um protocolo de comunicação (na camada de
aplicação segundo o Modelo OSI) utilizado para sistemas de informação de hipermídia,
distribuídos e colaborativos.[1] Ele é a base para a comunicação de dados da World Wide
Web.
Hipertexto é o texto estruturado que utiliza ligações lógicas (hiperlinks) entre nós
contendo texto. O HTTP é o protocolo para a troca ou transferência de hipertexto.
Coordenado pela World Wide Web Consortium e a Internet Engineering Task Force,
culminou na publicação de uma série de Requests for Comments; mais notavelmente o
RFC 2616, de junho de 1999, que definiu o HTTP/1.1. Em Junho de 2014 foram
publicados 6 RFC's para maior clareza do protocolo HTTP/1.1.[2] Em Março de 2015,
foi divulgado o lançamento do HTTP/2. A atualização deixará o navegador com um
tempo de resposta melhor e mais seguro. Ele também melhorará a navegação em
smartphones. [3]
Para acedermos a outro documento a partir de uma palavra presente no documento

actual ypodemos utilizar hiperligações (ou âncoras). Estes documentos se encontram no
sítio com um endereço de página da Internet – e para acessá-los deve-se digitar o
respectivo endereço, denominado URI (Universal Resource Identifier ou Identificador
Universal de Recurso), que não deve ser confundido com URL (Universal Resource
Locator ou Localizador Universal de Recurso), um tipo de URI que pode ser
directamente localizado.
Índice
 1 Visão técnica geral

 2 História
 3 Sessão HTTP
 4 Cookies
 5 Funcionamento
 6 Mensagem HTTP
o 6.1 Cabeçalho da mensagem
o 6.2 Corpo da mensagem
o 6.3 Requisição
 7 Métodos de solicitação
o 7.1 GET
o 7.2 HEAD
o 7.3 POST
o 7.4 PUT
o 7.5 DELETE
o 7.6 TRACE
o 7.7 OPTIONS
o 7.8 CONNECT
 8 Códigos de estado
 9 Conexões persistentes
 10 Estado de sessão HTTP
 11 Resposta
o 11.1 Códigos de retorno
o 11.2 Conexões
o 11.3 Outros protocolos
 12 Esquema de comunicação
 13 Ver também
 14 Referências
 15 Bibliografia
Visão técnica geral
O HTTP funciona como um protocolo de requisição-resposta no modelo computacional

cliente-servidor. Um navegador web, por exemplo, pode ser o cliente e uma aplicação
em um computador que hospeda um sítio da web pode ser o servidor. O cliente submete
uma mensagem de requisição HTTP para o servidor. O servidor, que fornece os
recursos, como arquivos HTML e outros conteúdos, ou realiza outras funções de
interesse do cliente, retorna uma mensagem resposta para o cliente. A resposta contém
informações de estado completas sobre a requisição e pode também conter o conteúdo
solicitado no corpo de sua mensagem.
Um navegador web é um exemplo de agente de usuário (AU). Outros tipos de agentes

de usuário incluem o software de indexação usado por provedores de consulta (web
crawler), navegadores vocais, aplicações móveis e outros software que acessam,
consomem ou exibem conteúdo web.
O HTTP é projetado para permitir intermediações de elementos de rede para melhorar

ou habilitar comunicações entre clientes e servidores. Sites web de alto tráfego
geralmente se beneficiam dos servidores de cache web que entregam conteúdo em nome
de servidores de upstream para melhorar o tempo de resposta. Navegadores web
armazenam os recursos web acessados anteriormente e reutilizam-nos quando possível
para reduzir o tráfego de rede. Servidores proxy HTTP nas fronteiras de redes privadas
podem facilitar a comunicação para o cliente sem um endereço globalmente roteável,
transmitindo mensagens com servidores externos.
História
O HyperText Transfer Protocol é um protocolo de aplicação responsável pelo

tratamento de pedidos e respostas entre cliente e servidor na World Wide Web. Ele
surgiu da necessidade de distribuir informações pela Internet e para que essa
distribuição fosse possível foi necessário criar uma forma padronizada de comunicação
entre os clientes e os servidores da Web e entendida por todos os computadores ligados
à Internet. Com isso, o protocolo HTTP passou a ser utilizado para a comunicação entre
computadores na Internet e a especificar como seriam realizadas as transacções entre
clientes e servidores, através do uso de regras básicas.
Este protocolo tem sido usado pela WWW desde 1990. A primeira versão de HTTP,
chamada HTTP/0.9, era um protocolo simples para a transferência de dados no formato
de texto ASCII pela Internet, através de um único método de requisição, chamado GET.
A versão HTTP/1.0 foi desenvolvida entre 1992 e 1996 para suprir a necessidade de
transferir não apenas texto. Com essa versão, o protocolo passou a transferir mensagens
do tipo MIME44 (Multipurpose Internet Mail Extension) e foram implementados novos
métodos de requisição, chamados POST e HEAD.
No HTTP/1.1, versão actual do protocolo descrito na RFC 2616,[4] foi desenvolvido um

conjunto de implementações adicionais ao HTTP/1.0, como por exemplo: o uso de
conexões persistentes; o uso de servidores proxy que permitem uma melhor organização
da cache; novos métodos de requisições; entre outros. Afirma-se que o HTTP também é
usado como um protocolo genérico para comunicação entre os agentes de utilizadores e
proxies/gateways com outros protocolos, como o SMTP, NNTP, FTP, Gopher, e WAIS,
permitindo o acesso a recursos disponíveis em aplicações diversas.[4]
Sessão HTTP
Uma sessão HTTP é uma sequência de transações de rede de requisição-resposta. Um

cliente HTTP inicia uma requisição estabelecendo uma conexão Transmission Control
Protocol (TCP) para uma porta particular de um servidor (normalmente a porta 80. Veja
Lista de portas dos protocolos TCP e UDP). Um servidor HTTP ouvindo naquela porta
espera por uma mensagem de requisição de cliente. Recebendo a requisição, o servidor
retorna uma linha de estado, como "HTTP/1.1 200 OK", e uma mensagem particular
própria. O corpo desta mensagem normalmente é o recurso solicitado, apesar de uma
mensagem de erro ou outra informação também poder ser retornada.
Cookies
Ver artigo principal: Cookie HTTP
O termo cookie é derivado do inglês que significa biscoito. Recebeu esse nome de uma
antiga gíria usada pelos programadores que consistia em um programa chamava um
procedimento e recebia de volta algo que seria necessário apresentar novamente mais
tarde para realizar algum trabalho. Foi criado pela Netscape para solucionar o problema
do envio e solicitação de arquivos, que era esquecido pelo servidor e que poderia ser
usado por outros computadores com o mesmo IP conforme (TANEMBAUM, 2003), o
que causava problemas, pois não se sabia na realidade se era ou não aquele usuário
mesmo. Os cookies são arquivos ou strings e não são programas executáveis. Eles são
tratados como dados pelo navegador, não existe nenhuma maneira dele ser usado como
vírus, apesar de que podem ser explorados bugs no servidor e causar a ativação de um
cookie como vírus, por um hacker. Basicamente ele é um grupo de dados trocados entre
o servidor de páginas e o navegador colocado em um ficheiro criado no computador do
usuário. Serve para manter a persistência das sessões HTTP. Ele funciona da seguinte
forma: Um usuário solicita uma página da Web, nisso o servidor pode fornecer
informações adicionais acompanhando a página solicitada. Essas informações podem
incluir um cookie, um pequeno arquivo ou string (com quatro KB no máximo). Este
cookie pode ter até 5 campos (figura abaixo): Domain, Path, Content, Expires, Secure.
Domain informa de onde veio o cookie. O navegador confirma que os servidores estão
enviando dados fieis a respeito de seu domínio. Cada domínio pode armazenar no
máximo 20 cookies por cliente. O campo Path é um caminho na estrutura de diretórios
do servidor que identifica as partes da árvore de arquivos do servidor que podem usar o
cookie. Frequentemente, ele obtém o símbolo / (barra), que representa a árvore inteira.
O campo Content utiliza a forma nome = valor, podendo o servidor definir da maneira
que quiser tanto o valor quanto o nome, e é nele que fica armazenado o conteúdo do
cookie. Expires é o campo que faz o cookie persistir, nele contém a data e o horário, e
se ele estiver ausente o navegador descartara automaticamente após o termino da sessão.
O último campo define se ele é seguro ou não.
Domain Path Content Expires Secure
15 de outubro de 2002
toms-casino.com / CustomerlD=497793521 Yes
17:00
11 de outubro de 2002
joes-store.com / Cart=1-00501;1-07031;2-13721 No
14:22
Prefs=Stk:SUNW+ORCL;Spt:Jet 31 de dezembro de 2010
aportal.com / No
s 23:59
12-12
sneaky.com 31- / UserID=3627239101 No
23:59
Figura x: Alguns exemplos de cookie.↵Fonte: (TANEMBAUM, 2003).
O cookie é usado para identificar um usuário que configurou uma página web, para que
na próxima vez que ele entrar ela esteja configurada do modo em que ele deixou. Pode
ser usado também quando se faz a solicitação de armazenamento de senha, na vez
posterior em que entrar no site, a sua senha será lembrada. É usado também em sites de
compra, como e-commerce, armazenando os produtos que o cliente colocou no carrinho
para que no final da compra não necessite fazer todo o processo novamente.
Funcionamento
Um sistema de comunicação em rede possui diversos protocolos que trabalham em

conjunto para o fornecimento de serviços. Para que o protocolo HTTP consiga transferir
seus dados pela Web, é necessário que os protocolos TCP e IP (Internet Protocol,
Protocolo de Internet) tornem possível a conexão entre clientes e servidores através de
sockets TCP/IP.
De acordo com Fielding,[5] o HTTP utiliza o modelo cliente-servidor, como a maioria

dos protocolos de rede, baseando-se no paradigma de requisição e resposta. Um
programa requisitante (cliente) estabelece uma conexão com um outro programa
receptor (servidor) e envia-lhe uma requisição, contendo a URI, a versão do protocolo,
uma mensagem MIME (padrão utilizado para codificar dados em formato de textos
ASCII para serem transmitidos pela Internet) contendo os modificadores da requisição,
informações sobre o cliente e, possivelmente, o conteúdo no corpo da mensagem.
O servidor responde com uma linha de status (status line) incluindo sua versão de
protocolo e com os códigos de erro informando se a operação foi bem sucedida ou
fracasso, seguido pelas informações do servidor, metainformações da entidade e
possível conteúdo no corpo da mensagem. Após o envio da resposta pelo servidor,
encerra-se a conexão estabelecida.
Mensagem HTTP
O protocolo HTTP faz a comunicação entre o cliente e o servidor por meio de

mensagens. O cliente envia uma mensagem de requisição de um recurso e o servidor
envia uma mensagem de resposta ao cliente com a solicitação. Segundo Foscarini,[6] os
dois tipos de mensagens existentes no protocolo utilizam um formato genérico, definido
na RFC 822, para a transferência de entidades.
Uma mensagem, tanto de requisição quanto de resposta, é composta, conforme definido

na RFC 2616,[7] por uma linha inicial, nenhuma ou mais linhas de cabeçalhos, uma linha
em branco obrigatória finalizando o cabeçalho e por fim o corpo da mensagem, opcional
em determinados casos. Nessa sessão serão apresentados os campos que compõem uma
mensagem mais detalhadamente; ou seja, o HTTP apresenta o sítio ou local onde está a
página da Internet.
Cabeçalho da mensagem
O cabeçalho da mensagem (header) é utilizado para transmitir informações adicionais

entre o cliente e o servidor. Ele é especificado imediatamente após a linha inicial da
transação (método), tanto para a requisição do cliente quanto para a resposta do
servidor, seguido de dois pontos (:) e um valor. Existem quatro tipos de cabeçalhos que
poderão ser incluídos na mensagem os quais são: general-header, request-header,
response-header e entity-header.[8]
Esses cabeçalhos são utilizados para enviar informações adicionais sobre a mensagem
transmitida (general-header), a requisição e os clientes (request-header) que
comunicam suas configurações e os formatos de documentos desejados como resposta.
[9]
Além disso, são utilizados pelo servidor ao retornar o recurso no qual foi requisitado
pelo cliente, para transmitir informações que descrevem as configurações do servidor e
do recurso identificado pelo URI de requisição, e que não pertence à linha de status
(response-header). Na RFC 2616,[10] estão descritos todos os campos que pertencem a
esses cabeçalhos.
Alguns tipos MIME[11]
Exemplo Descrição
text/plain Arquivo no formato texto (ASCII)
text/html Arquivo no formato HTML, utilizado

como padrão para documentos Web
Image/gif Imagem com o formato GIF
Image/jpeg Imagem com o formato JPEG
application/zip Arquivo compactado
application/json Arquivo no formato JSON
application/xml (ou text/xml) Arquivo no formato XML
Corpo da mensagem
Uma mensagem HTTP pode conter um corpo de dados que são enviados abaixo das
linhas de cabeçalho. Em uma mensagem de resposta, o corpo da mensagem é o recurso
que foi requisitado pelo cliente, ou ainda uma mensagem de erro, caso este recurso não
seja possível. Já em uma mensagem de requisição, o corpo pode conter dados que serão
enviados diretamente pelo usuário ou um arquivo que será enviado para o servidor.
Quando uma mensagem HTTP tiver um corpo, poderão ser incluídos cabeçalhos de
entidades que descrevem suas características, como por exemplo, o Content-Type que
informa o tipo MIME dos dados no corpo da mensagem e o Content-Length que
informa a quantidade de bytes que o corpo da mensagem contém. A tabela ao lado
apresenta alguns tipos MIME.
Requisição
De acordo com Fielding,[12] uma mensagem de requisição do cliente é composta pelos

seguintes campos: uma linha inicial (Request-Line); linhas de cabeçalhos (Request-
header); uma linha em branco obrigatória e um corpo de mensagem opcional. A linha
inicial de uma requisição é composta por três partes separadas por espaços: o método
(Method), a identificação do URI (Request-URI) e a versão do HTTP (HTTP-Version)
utilizado.
Segundo Bastos & Ladeira,[13] Request-URI é um identificador uniforme de recurso

(Uniform Resource Identifier) que identifica sobre qual recurso será aplicada a
requisição. No protocolo HTTP, o tipo de URI utilizado é chamado de URL (Uniform
Resource Locator), composto pela identificação do protocolo, pelo endereço do
computador servidor e pelo documento requisitado.[14]
Métodos de solicitação
O protocolo HTTP define oito métodos (GET, HEAD, POST, PUT, DELETE, TRACE,
OPTIONS e CONNECT) que indicam a ação a ser realizada no recurso especificado.
Conforme Bastos e Ladeiras,[15] o método determina o que o servidor deve fazer com o
URL fornecido no momento da requisição de um recurso. Um servidor HTTP deve
implementar ao menos os métodos GET e HEAD.
Uma solicitação HTTP, ou HTTP Request é uma maneira do navegador mostrar uma
página da internet utilizando um dos oito métodos de solicitação do protocolo HTTP.[16]
Além de solicitar um determinado arquivo, envia várias informação para o servidor,

sendo elas: o seu IP, a versão do navegador que está usando, que página utilizou para
pedir a HTTP Request e a idioma que você usa, entre outros.[16]
GET
O método GET requisita uma representação do recurso especificado. Requisições

usando GET devem apenas recuperar dados e não devem ter qualquer outro efeito. (Isto
também é verdade para alguns outros métodos HTTP.) O W3C publicou princípios de
orientações sobre esta distinção, "O projeto de aplicações web devem ser informados
pelos princípios acima, mas também por limitações relevantes."
Abaixo segue um exemplo de uma comunicação entre um cliente e um servidor HTTP.

O servidor possui a URL www.exemplo.com, porta 80.
O pedido do cliente (seguido por uma linha em branco, de maneira que o pedido termina
com um newline duplo, cada um composto por um carriage return seguido de um Line
Feed):
GET /index.html HTTP/1.1

Host: www.exemplo.com
O cabeçalho Host reconhece vários diferentes nomes DNS que tenham o mesmo IP.
A resposta do servidor (seguida por uma linha em branco e o texto da página

solicitada):
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8
HEAD
Variação do GET em que o recurso não é retornado. É usado para obter metainformações
por meio do cabeçalho da resposta, sem ter que recuperar todo o conteúdo.
POST
Ver artigo principal: POST (HTTP)
Envia dados para serem processados (por exemplo, dados de um formulário HTML)
para o recurso especificado. Os dados são incluídos no corpo do comando. Sua
utilização em uma requisição ocorre quando é necessário enviar dados ao servidor para
serem processados, geralmente por um programa script identificado no Request-URI.
Uma requisição por meio desse método sempre requer que as informações submetidas
sejam incluídas no corpo da mensagem e formatadas como uma query string, além de
conter cabeçalhos adicionais especificando seu tamanho (Content-Length) e seu
formato (Content-Type). Por isso, esse método oferece uma maior segurança em
relação aos dados transferidos, ao contrário do método GET que os dados são anexados a
URL, ficando visíveis ao usuário.[17] Por exemplo:
POST /index.html HTTP/1.0

Accept: text/html
If-modified-since: Sat, 29 Oct 1999 19:43:31 GMT
Content-Type: application/x-www-form-urlencoded
Content-Length: 41
Nome=NomePessoa&Idade=99&Curso=Computacao
PUT
Edita as informações de um determinado recurso.
DELETE
Exclui o recurso.
TRACE
Ecoa o pedido, de maneira que o cliente possa saber o que os servidores intermediários
estão mudando em seu pedido.
OPTIONS
Recupera os métodos HTTP que o servidor aceita.
CONNECT
Serve para uso com um proxy que possa se tornar um túnel SSL (um túnel pode ser
usado, por exemplo, para criar uma conexão segura).
Códigos de estado
Ver também: Anexo:Lista de códigos de status HTTP
Do HTTP/1.0 em diante, a primeira linha da resposta HTTP é chamada linha de estado

e inclui um código de estado numérico (como "404") e uma frase de razão textual
(como "Not Found" - Não Encontrado). A maneira que o agente de usuário manipula a
resposta depende primeiramente do código e secundariamente nos cabeçalhos de
resposta. Códigos de estado personalizados podem ser usados, uma vez que, se o agente
de usuário encontrar um código que ele não reconheça, ele pode usar o primeiro dígito
do código para determinar a classe geral da resposta.
Da mesma forma, as frases de razão padrões são apenas recomendações e podem ser
substituídas com "equivalentes locais" a critério do desenvolvedor web. Se o código de
estado indicou um problema, o agente de usuário pode mostrar a frase de razão para o
usuário, para que sejam fornecidas informações adicionais sobre a natureza do
problema. O padrão também permite que o agente de usuário tente interpretar a frase de
razão, apesar disto poder ser imprudente uma vez que o padrão especifica
explicitamente que os códigos de estado são legíveis por máquina e as frases de razão
são legíveis por homens.
Conexões persistentes
Ver artigo principal: Conexão persistente HTTP
No HTTP/0.9 e 1.0, a conexão é fechada após um único par de requisição/resposta. No

HTTP/1.1 um mecanismo de persistência de vida (keep-alive) foi introduzido, onde uma
conexão pode ser reutilizada para mais de uma requisição. Tais conexões persistentes
reduzem a latência de requisição perceptível, pois o cliente não precisa renegociar a
conexão TCP após a primeira requisição ter sido enviada. Outro efeito colateral positivo
é que em geral a conexão se torna mais rápida com o tempo devido ao mecanismo de
início-lento do TCP.
A versão 1.1 do protocolo também faz melhoras na otimização de comprimento de

banda para o HTTP/1.0. Por exemplo, o HTTP/1.1 introduziu a codificação de
transferência em partes para permitir que o conteúdo em conexões persistentes sejam
transmitidos em vez de armazenados temporariamente para posterior transmissão. O
pipelining HTTP reduz ainda mais o tempo de atraso, permitindo que os clientes enviem
várias requisições antes de esperar por cada resposta. Outra melhoria para o protocolo
foi o byte serving, onde um servidor transmite apenas a porção de um recurso solicitado
explicitamente por um cliente.
Estado de sessão HTTP
O HTTP é um protocolo sem estado. Um protocolo sem estado não exige que o servidor
HTTP retenha informações ou estado sobre cada usuário para a duração de várias
solicitações. Entretanto, algumas aplicações web implementam estado ou sessões do
lado servidor usando um ou mais de um dos métodos a seguir:
 Variáveis ocultas dentro de formulários web

 Cookies HTTP
 Parâmetros de query string, por exemplo, /index.php?
session_id=algum_código_único_de_sessão
Resposta
Para Fielding,[18] uma mensagem de resposta do servidor é composta pelos seguintes

campos: uma linha inicial (Status-Line); linhas de cabeçalhos (Responseheader); uma
linha em branco obrigatória e um corpo de mensagem opcional. A linha inicial de uma
resposta, chamada de linha de status, possui por sua vez três partes separadas por
espaços: a versão do protocolo HTTP (HTTP-Version), um código de status (Status-
Code) da resposta, que fornece o resultado da requisição, e uma frase de justificativa
(Reason-Phrase) que descreve o código do status.
Códigos de retorno
A linha inicial de uma resposta HTTP indica ao cliente se sua requisição foi bem
sucedida ou não.[19] Essa situação é fornecida através de um código de retorno (Status-
Code) e uma frase explicativa (Reason-Phrase). De acordo com Fielding,[20] o código de
status é formado por três dígitos e o primeiro dígito representa a classe que pertence
classificada em cinco tipos:
 1xx: Informational (Informação) – utilizada para enviar informações para o cliente de

que sua requisição foi recebida e está sendo processada;
 2xx: Success (Sucesso) – indica que a requisição do cliente foi bem sucedida;
 3xx: Redirection (Redirecionamento) – informa a ação adicional que deve ser tomada
para completar a requisição;
 4xx: Client Error (Erro no cliente) – avisa que o cliente fez uma requisição que não pode
ser atendida;
 5xx: Server Error (Erro no servidor) – ocorreu um erro no servidor ao cumprir uma
requisição válida.
O protocolo HTTP define somente alguns códigos em cada classe descritos na RFC
2616, mas cada servidor pode definir seus próprios códigos.
Conexões
Segundo Hirata,[21] o HTTP/1.0 é um protocolo sem estado. Isto significa que as

conexões entre um cliente e um servidor são encerradas após o envio de cada requisição
ou resposta. Cada vez que uma conexão é estabelecida ou encerrada, é consumida uma
grande quantidade de tempo da CPU, de largura de banda e de memória.
Na maioria das vezes, para se obter o resultado esperado, é necessário realizar mais de
uma solicitação de recursos através de várias conexões. Por exemplo, no caso de uma
página Web, que consiste de diversos arquivos (.html, .gif, .css, etc) é preciso que sejam
feitas várias requisições para compor a página, uma conexão não-persistente. O ideal
seria que apenas uma conexão fosse utilizada para os pedidos e as respostas HTTP,
diminuindo, assim, a sobrecarga ocasionada pelas conexões, uma conexão persistente.
A conexão persistente, implementada como conexão padrão no protocolo HTTP/1.1,

possibilita que uma conexão seja estabelecida para enviar várias requisições em
seqüência sem a necessidade de esperar por cada resposta, no qual serão recebidas na
mesma ordem em que as solicitações foram enviadas, um processo chamado de
pipelining.[22] Pode também dar-se o caso de ser estabelecida uma conexão sem
pipelining, em que o cliente só faz nova requisição quando o servidor lhe envia a
resposta, ou seja, o servidor fica inactivo até o objecto (.html, .gif, .css, etc) atingir o seu
destino no cliente.
Se uma requisição incluir o cabeçalho Connection: close, a conexão será encerrada

após o envio da resposta correspondente. Utiliza-se este cabeçalho quando não há
suporte a conexões persistentes, quando for a última requisição a ser enviada nesta
conexão, ou ainda, sempre que quiser encerrar a conexão mesmo que nem todas as
requisições tenham sido completadas. Além disso, o servidor pode fechar uma conexão
se estiver ociosa por um determinado período de tempo.
Outros protocolos
Existem outros tipos de protocolos como o FTP (File Transfer Protocol, ou Protocolo de
Transferência de Arquivos), usado para envio de arquivos do computador para um
servidor na Web, o SMTP (Simple Mail Transfer Protocol, ou Protocolo de
Transferência de Correio Simples), protocolo usado para correio eletrônico, entre outros
protocolos.
Esquema de comunicação
Pedido básico de HTTP cliente-servidor:
GET <ficheiro> HTTP/1.1

Host: <ip>
User-Agent: <Agente>
Connection: <tipo>
O agente é quem faz a ligação ao servidor, normalmente um navegador. O tipo indica

como o servidor deve proceder com a conexão. É comumente utilizado para requisições
persistentes.
Uma requisição completa pode exigir muitas informações. A requisição abaixo -

utilizando o método POST - fora retirada do Mozilla Firefox v3.6b5 (pt-BR, para
Windows):
POST /diretorio/arquivo.html HTTP/1.1

Host: www.exemplo.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; pt-BR;
rv:1.9.2b5) Gecko/20091204 Firefox/3.6b5
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-alive: 115
Cookie: nome=valor; nome2=valor2
Connection: keep-alive
Content-Length: 28
usuario=exemplo&senha=123456
Ver também
 Hyper Text Transfer Protocol Secure (HTTPS)

 Representational State Transfer (REST)
 SPDY – An HTTP enhancement proposed by Google
 Web cache
 WebSockets
 HTTP referrer
 World Wide Web (WWW)
 Lista de códigos de status HTTP
Referências
1.
 T. Berners-Lee et all, 1996

  Mark Nottingham (7 de Junho de 2014). «RFC2016 está morto» (em inglês). Mark
Nottingham. Consultado em 13 de junho de 2015
  «HTTP/2: Internet mais rápida»
  Fielding et al 1999, p. 7
  Fielding et al (1999, p. 10)
  Foscarini (2001, p. 13)
  Fielding et al, 1999, p. 21
  cf. Fielding et al, 1999, p. 21
  cf. Bastos & Ladeira, 2001
  cf. Fielding et al, 1999
  Fielding et al, 1999
  Fielding (1999, p. 24)
  Bastos & Ladeira
  cf. Embratel, 2002
  Bastos & Ladeiras (2001)
  «O que é um 'HTTP request'?». www.portais.ws. Consultado em 15 de março de 2011
  Herrmann, 1997
  cf. Herrman, 1997, p. 53
  Hirata, 1999
22.  cf. Fielding et al, 1999, p. 30

Bibliografia
 T. Berners-Lee, R. Fielding, H. Frystyk (maio de 1996). «Hypertext Transfer Protocol --

HTTP/1.0» (em inglês). Internet Engineering Task Force. Consultado em 21 de junho de
2009
 BASTOS, Leonara de Oliveira; LADEIRA, Adriane Cristina. Protocolo HTTP.
 cf. 46 HERRMANN, Eric. Aprenda em 1 semana programação CGI em Perl 5. Rio de
Janeiro: Campus, 1997
Internet Message Access Protocol

IMAP (Internet Message Access Protocol. Traduzido do inglês, significa "Protocolo de
acesso a mensagem da internet") é um protocolo de gerenciamento de correio
eletrônico.
Utiliza, por padrão, as portas TCP 143 ou 993 (conexão criptografada via SSL)[1]. O
mais interessante é que as mensagens ficam armazenadas no servidor e o utilizador pode
ter acesso a suas pastas e mensagens em qualquer computador, tanto por webmail como
por cliente de correio eletrônico (como o Mozilla Thunderbird, Outlook Express ou o
Evolution). Outra vantagem deste protocolo é o compartilhamento de caixas postais
entre usuários membros de um grupo de trabalho. Além disso, é possível efetuar
pesquisas por mensagens diretamente no servidor, utilizando palavras-chave.
Índice
 1 Detalhes
 2 Referências
 3 Ver também
Detalhes
O protocolo é superior em recursos ao POP3 - protocolo que a maioria dos provedores

oferece aos seus assinantes.[2] Por outro lado, apresenta algumas limitações:
 O número de mensagens possível de se armazenar depende do espaço limite que nos

é atribuído para a caixa de correio;
 Caso o servidor IMAP esteja numa localização remota, pela Internet, e não numa rede
local LAN, é necessário estar ligado à Internet todo o tempo que quisermos consultar
ou enviar mensagens, podendo não ser adequado a quem utiliza a Internet através de
ligação telefônica dial-up, devido aos custos associados. No entanto, a maioria dos
clientes de e-mail (e.g. Outlook Express, Thunderbird, Novell Evolution etc.) oferecem
a possibilidade de criar uma cópia local (offline) das mensagens contidas em uma ou
várias pastas (e.g. Inbox (Recebidas), Sent (Enviadas), etc.). Sendo assim, toda vez que
você dispuser de uma conexão (estiver online) sua cópia local será sincronizada com o
servidor de e-mail.
Em relação ao POP3, permite ativar e desativar "flags" (marcações que indicam

características de uma mensagem), que podem, inclusive, ser definidas pelo usuário.
Com o POP3, estas marcações são registradas pelo cliente, de forma que, se a
mensagem for aberta por um segundo cliente, as mesmas podem não ter seu "status"
indicado corretamente. O IMAP permite a gravação das "flags" junto às caixas-postais,
assegurando que, independente de qual cliente se acesse, as mensagens terão as mesmas
corretamente atribuídas.
Possui ainda a capacidade de reconhecer os padrões de mensagens eletrônicas [RFC

822] e MIME-IMB [RFC 2045] em mensagens eletrônicas, de modo que os clientes de
e-mail não o necessitem fazer. O servidor IMAP cumpre a tarefa de interpretar estes
padrões, tornando os clientes mais fáceis de implementar e o acesso mais "universal",
bem como pesquisa de texto em mensagens de forma remota. Este modo de trabalho é
feito localmente às caixas-postais e a seleção para recebimento dos atributos de uma
mensagem, ou seu texto ou anexos e outras partes ("attachments") podem ser feitos de
forma independente. Então, o usuário pode pedir para receber de uma mensagem com
um grande "attachment", apenas a parte do texto que lhe interessa, o que é vantajoso no
caso de um acesso discado de baixa qualidade e a redução do tráfego em geral.
Referências
1.
 «Service Name and Transport Protocol Port Number Registry». www.iana.org. Consultado
em 8 de maio de 2017
 «Internet Providers Should Find Their Way to IMAP (washingtonpost.com)».

www.washingtonpost.com. Consultado em 23 de abril de 2012
LDAP
Lightweight Directory Access Protocol, ou LDAP, é um protocolo de aplicação
aberto, livre de fornecedor e padrão de indústria para acessar e manter serviços de
informação de diretório distribuído sobre uma rede de Protocolo da Internet (IP).
Serviços de diretório desempenham um papel importante no desenvolvimento de
aplicações intranet e Internet permitindo o compartilhamento de informações sobre
usuários, sistemas, redes, serviços e aplicações através da rede. Como exemplos,
serviços de diretório podem fornecer qualquer conjunto de registros organizado,
geralmente com uma estrutura hierárquica, como um diretório de e-mail corporativo. Da
mesma forma, uma lista telefônica (diretório de telefones) é uma lista de assinantes com
um endereço e um número de telefone. Um diretório LDAP geralmente segue o modelo
X.500, que é uma árvore de nós, cada um consistindo de um conjunto de atributos com
seus respectivos valores. O LDAP foi criado como uma alternativa ao Directory Access
Protocol (DAP).
O LDAP é especificado em uma série de publicações de Sequência de Padronização do

Internet Engineering Task Force (IETF) chamadas Request for Comments (RFCs),
usando a linguagem de descrição ASN.1. A última especificação é a Versão 3,
publicada como RFC 4511. Por exemplo, aqui está uma pesquisa LDAP traduzida em
Português puro: "Procure no diretório de e-mails da companhia por todas as pessoas
localizadas em Belém cujos nomes contêm "João" que possuem um endereço de e-mail.
Por favor, retorne seus nomes completos, e-mail, título e descrição."
Uma utilização comum do LDAP é fornecer um "logon único" onde uma senha para um
usuário é compartilhada entre muitos serviços, como a aplicação de um código de login
da companhia para páginas web (de forma que a equipe loga apenas uma vez aos
computadores da companhia e então são automaticamente logadas na intranet da
companhia).
O LDAP é baseado em um subconjunto mais simples dos padrões contidos dentro do

padrão X.500. Devido a este relacionamento, o LDAP é às vezes chamado X.500-lite.
Índice
 1 História
 2 Visão geral
 3 Estrutura de diretório
 4 Veja também
 5 Livros
História
Um diretório LDAP tende a refletir vários limites políticos, geográficos e/ou

organizacionais, dependendo do modelo adotado. A utilização do LDAP hoje em dia
tende a se basear nos nomes já existentes do sistema Domain Name System (DNS), na
estruturação dos níveis mais básicos de hierarquia. Mais profundamente, podem
aparecer estruturas representando pessoas, unidades organizacionais, impressoras,
documentos, grupos de pessoas ou qualquer outra coisa que represente um nó.
A versão atual é LDAPv3, especificado em uma série de RFC como mostra o RFC
4510.
Os autores deste protocolo foram Tim Howes da Universidade de Michigan, Steve Kille
da ISODE (ISO Development Environment) e Wengyik Yeong da Performance
Systems International.
LDAP influenciou protocolos de Internet subsequentes, incluindo versões posteriores do

X.500, Directory Services Markup Language(DSML), Service Provisioning Markup
Language (SPML) e o Service Location Protocol.
Visão geral
Um cliente começa uma sessão de LDAP ligando-se a um servidor LDAP, normalmente

pela porta padrão: 389, TCP. Este envia requisições para o servidor, o qual devolve
respostas. As operações básicas são:
 Bind – autentica e especifica a versão do protocolo LDAP;
 Search – procura por e/ou recupera entradas dos diretórios;
 Compare – testa se uma entrada tem determinado valor como atributo;
 ADD – adiciona uma nova entrada;
 Delete – apaga uma entrada;
 Modify – modifica uma entrada;
 Modify DN – move ou renomeia uma entrada;
 StartTLS[1] – protege a conexão com a Transport Layer Security (TLS);
 Abandon – aborta uma requisição prévia;
 Extended Operation – operação genérica para definir outras operações;
 Unbind – fecha a conexão, não o inverso de Bind.
Em contrapartida o servidor pode mandar "Unsolicited Notifications” (Notificações não

solicitadas) que são respostas a nenhuma requisição, ex. antes deste terminar uma
conexão. Com algumas exceções o cliente não precisa esperar uma resposta antes de
enviar a próxima requisição, e o servidor pode enviar a resposta em qualquer ordem.
LDAP é definido nos termos da ASN.1, e as mensagens de protocolos são codificadas

no formato binário BER.
O LDAP é uma definição de protocolo para acesso a bancos de dados especializados

chamados diretórios. É similar ao SQL no sentido que é uma linguagem para interagir
com bancos de dados sem especificar um banco de dados particular. De fato, o banco de
dados de suporte ao LDAP é quase sempre um sistema RDBMS geral, como o LDBM
ou o Oracle.
Nas diversas tecnologias que empresas de médio e grande porte utilizam hoje em dia,
uma área para autenticação é exigida por praticamente todos os sistemas, o que pode
muitas vezes ocasionar uma variada quantidade de cadastro de utilizadores replicados
entre os sistemas. Como exemplo daquele utilizador que tem muitos "logins" e "senhas"
para acesso aos sistemas da empresa e toda semana precisa lembrar ou alterar alguma
informação de seu cadastro. Ex: login e senha para acesso a máquina, a rede, ao e-mail,
ao sistema de gestão, sistema de documentos, etc. Desta forma o usuário fica confuso e
a equipe de TI simplesmente perde tempo com o serviço repetitivo e de suporte. Um
servidor de diretórios como o Open LDAP ou MS Active Directory recebe esta
autenticação dos muitos sistemas; o protocolo LDAP serve justamente para outras
aplicações quaisquer da empresa se conectarem e consultarem um servidor de diretórios.
Estrutura de diretório
O protocolo fornece uma interface com diretórios que segue a edição de 1993 do
modelo X.500:
 Uma entrada consiste de um conjunto de atributos

 Um atributo possui um nome (um tipo de atributo ou descrição de atributo) e um ou
mais valores. Os atributos são definidos em um esquema (ver abaixo).
 Cada entrada possui um identificador único: seu Distinguished Name (DN), em
português Nome Distinto. Ele consiste de seu Relative Distinguished Name (RDN), em
português Nome Distinto de Parente, construído de algum(ns) atributo(s) na entrada,
seguido pelo DN da entrada pai. Pense no DN como o caminho completo de um
arquivo e o RDN como seu nome de arquivo relativo em sua pasta pai (por exemplo, se
/foo/bar/meuarquivo.txt fosse o DN, então meuarquivo.txt seria o RDN).
Um DN pode ser alterado durante o tempo de vida da entrada, por exemplo, quando
entradas são movidas dentro de uma árvore. Para identificar entradas com segurança e
sem ambiguidade, um UUID pode ser fornecido no conjunto de atributos operacionais
da entrada.
Uma entrada pode parecer com isto quando representada no LDAP Data Interchange
Format (LDIF) (o LDAP propriamente dito é um protocolo binário):
dn: cn=John Doe,dc=exemplo,dc=com

cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john@example.com
manager: cn=Barbara Doe,dc=exemplo,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
"dn" é o nome distinto da entrada. Ele não é um atributo nem uma parte da entrada.
"cn=John Doe" é o RDN da entrada (Relative Distinguished Name) e
"dc=exemplo,dc=com" é o DN da entrada pai, onde "dc" significa 'Domain
Component'. As outras linhas mostram os atributos na entrada. Nomes de atributos são
normalmente cadeias de caractere mnemônicas, como "cn" para common name (nome
comum), "dc" para domain component (componente de domínio), "mail" para endereço
de e-mail e "sn" para sobrenome.
Veja também
 OpenLDAP
 Serviço de diretório
 Active Directory
Livros
Autenticaçao Centralizada com Openldap - Sungaila, Marcos - Novatec, 2007

Apresenta a implementação do servidor OpenLDAP como meio de autenticação para
vários serviços como: email, web, proxy e ftp além da autenticação de usuários para
redes heterogêneas (com Linux e Windows). Aborda, ainda, a parte de troubleshooting e
criptografia. Parte deste livro pode ser consultado on-line em books.google.com.
Ligações externas
 A RFC sobre o LDAP

 LDAPSearch no Código Livre LDAPSearch é um pequeno aplicativo desenvolvido em
PHP que faz uma busca num Sistema de Serviço de Diretórios (MS Active Directory,
OpenLDAP) pelo nome do usuário, retornando informações pessoais do mesmo.
 Documento que demonstra os campos no AD que fazem referência ao LDAP.
MGCP
MGCP é um acrónimo para a expressão inglesa Media Gateway Control Protocol, um
protocolo proposto pelo grupo de trabalho IETF (Internet Engineer Task Force) para
integração da arquitetura SS#7 em redes VOIP. Embora o SS#7 se encontre presente na
telefonia tradicional, o MGCP especifica com redes IP, Frame Relay e ATM.
O sistema é composto por um Call Agent, pelo menos um media gateway (MG),
responsável pela conversão dos sinais entre circuitos e pacotes, e pelo menos um
signaling gateway (SG), quando conectado a um PSTN.
Durante a evolução do MGCP, o trabalho cooperativo de grupos do ITU-T e do IETF

resultou na recomendação H.248, definida também com o protocolo Megaco (IETF),
através do RFC 3015.
RFCs
Nesta lista podem-se encontrar os RFCs relacionados com o MGCP:
 RFC 3435 - Media Gateway Control Protocol (MGCP) Versão 1.0 (sobrepõe-se ao RFC
2705)
 RFC 3660 - Basic Media Gateway Control Protocol (MGCP) Packages (informativol)
 RFC 3661 - Media Gateway Control Protocol (MGCP) Return Code Usage
 RFC 3064 - MGCP CAS Packages
 RFC 3149 - MGCP Business Phone Packages
 RFC 3515 - Session Initiation Protocol (SIP) Refer Method
 RFC 3991 - Media Gateway Control Protocol (MGCP) Redirect and Reset Package
 RFC 3992 - Media Gateway Control Protocol (MGCP) Lockstep State Reporting
Mechanism
Network News Transfer Protocol

Origem: Wikipédia, a enciclopédia livre.
(Redirecionado de NNTP)
Network News Transfer Protocol (NNTP) é um protocolo da Internet para grupos de

discussão da chamada Usenet. Foi definido inicialmente pela RFC 977; 20 anos depois,
em Outubro de 2006 a RFC 3977 substituiu e tornou obsoleta a RFC original.
Especifica o modo de distribuição, busca, recuperação e postagem de artigos usando um

sistema de transmissão confiável. Para clientes de leitura de noticias, o NNTP habilita a
recuperação de artigos armazenados em um banco de dados centralizado, permitindo
aos assinantes a opção de selecionar somente os artigos nos quais estão interessados.
Ligações externas
 RFC 3977 Network News Transfer Protocol Specification (em inglês)

 Lista de servidores NNTP de acesso público
Network Time Protocol

O NTP é um protocolo para sincronização dos relógios dos computadores baseado no
protocolo UDP sob a porta 123, para sincronização do relógio de um conjunto de
computadores em redes de dados com latência variável. O NTP permite manter o
relógio de um computador com a hora sempre certa e com grande exatidão.
Originalmente idealizado por David L. Mills da Universidade do Delaware e ainda hoje
mantido por si e por uma equipe de voluntários, o NTP foi utilizado pela primeira vez
antes de 1985, sendo ainda hoje muito popular e um dos mais antigos protocolos da
internet.
Índice
 1 Importância do NTP
 2 Os relógios de computador
 3 Algumas propriedades importantes dos relógios
 4 Funcionamento do NTP
o 4.1 A topologia do NTP
o 4.2 Os tipos de associação possíveis
o 4.3 A Troca de Mensagens e o cálculo do Deslocamento
o 4.4 O Algoritmo de Filtro de Relógio
o 4.5 O Algoritmo de Seleção dos Relógios
o 4.6 O Algoritmo de Agrupamento
o 4.7 O Algoritmo de Combinação de Relógios
o 4.8 Disciplina do Relógio Local
o 4.9 Segurança no NTP
 5 Servidores de NTP públicos
Importância do NTP
Uma característica básica e ao mesmo tempo importante do tempo é que ele sempre
avança. O tempo não para e não volta atrás. Vários programas de computador fazem uso
dessa característica e podem ter seu funcionamento comprometido se o relógio do
computador inesperadamente passar a indicar um horário errado, especialmente se for
um horário no passado. Isso se complica ainda mais na Internet, com vários
computadores trocando informações entre si!
Infelizmente os relógios dos computadores são imprecisos e se adiantam ou se atrasam
com o passar do tempo. É muito fácil também trocar seu horário para o passado ou para
o futuro, mesmo acidentalmente.
Diferentes softwares e aplicações podem ser sensíveis a problemas relativos à

sincronização do tempo de formas diversas. Como exemplos de aplicações afetadas pelo
tempo pode-se citar: Sistemas de distribuição de conteúdo (www, usenet news, etc);
Sistemas de arquivos (filesystems); Agendadores de eventos como o cron e o at dos
sistemas unix; Criptografia; Protocolos de comunicação e aplicações de tempo real;
Sistemas transacionais e bancos de dados distribuidos.
É importante também do ponto de vista de segurança de redes que os relógios dos

computadores estejam sincronizados. Investigações relacionadas a incidentes de
segurança tornam-se impossíveis caso os servidores envolvidos e os diversos arquivos
de log discordem entre si em relação às estampas de tempo dos eventos.
Para algumas aplicações exatidão da ordem de segundos pode ser suficiente. Para
outras, é necessário manter os relógios com diferenças na ordem dos milisegundos entre
si e em relação à hora certa.
O NTP, se corretamente utilizado, é capaz de garantir as propriedades necessárias ao

relógio do computador para o bom funcionamento das aplicações. Num primeiro
momento isso pode parecer algo muito simples: "consultar o tempo em um servidor" e
"ajustar o relógio local" de tempos em tempos. Mas na verdade o NTP faz muito mais
do que isso. Diversos componentes do sistema colaboram para:
 Obter, a partir de diversas amostras, informações de tempo de um determinado

servidor, como o deslocamento, dispersão e variação.
 Discernir, dentre um conjunto de servidores, quais fornecem o tempo correto e quais
estão mentindo.
 Escolher, dentre os servidores que fornecem o tempo correto, qual é a melhor
referência.
 Disciplinar o relógio local, descobrindo seus principais parâmetros de funcionamento,
como precisão, estabilidade e escorregamento e ajustando-o de forma contínua e
gradual, mesmo na ausência temporária de referências de tempo confiáveis, para que
tenha e melhor exatidão possível.
 Garantir a monotonicidade do tempo.
 Identificar, a partir de métodos criptográficos, servidores de tempo conhecidos e
confiáveis, evitando possíveis ataques.
 Formar, em conjunto com outros servidores NTP, uma topologia simples, confiável,
robusta e escalável para a sincronização de tempo.
Os relógios de computador
Os relógios de computadores, como quaisquer outros relógios, são baseados em 3

dispositivos:
 um oscilador;
 um contador;
 e um dispositivo de leitura ou visualização.
O oscilador é um dispositivo que gera eventos cíclicos a uma taxa constante, chamada
de freqüência. Normalmente os osciladores dos computadores são baseados em cristais
de quartzo. O contador acumula os ciclos gerados pelo oscilador, geralmente utilizando-
se de interrupções de hardware, convertendo-os em unidades de medida conhecidas,
como segundos, minutos, horas. Cada valor do contador é chamado de estampa de
tempo. A "visualização" ou leitura é feita através de rotinas de software.
Algumas propriedades importantes dos relógios
 Exatidão: (Accuracy) É quanto o relógio está próximo à referência. Ou seja, indica se o

relógio está "certo" ou "errado" ou melhor: quanto o relógio está "certo" ou "errado".
 Precisão (Precision), Resolução (Resolution) e Granularidade (granularity): Por

resolução, se entende o valor do menor incremento possível do contador do relógio. A
resolução de um relógio de computador é determinada pela freqüência das
interrupções de hardware que fazem funcionar o contador. Os valores normalmente
variam entre 100Hz e 1Khz, o que resulta em resoluções de 10ms a 1ms.
Em alguns casos é possível utilizar outras fontes de freqüência (maiores), como por
exemplo o relógio da CPU, para interpolar os valores obtidos pelo relógio do sistema,
conseguindo assim uma resolução melhor. Isso geralmente é chamado de
granularidade do relógio. Com isso, resoluções de aproximadamente 1µs são possíveis.
Por precisão, entende-se geralmente o menor incremento de tempo que pode ser lido
pelo computador. Pode ser um valor maior do que a resolução, já que ler o relógio é
uma tarefa realizada por software e há um certo tempo e incerteza envolvidos nela.
Ou pode ser menor, quando o software consegue ler o relógio mais rápido do que esse
pode contar.
No contexto do NTP, precisão é o maior desses valores. Ou seja, precisão, no NTP,

engloba os conceitos de precisão, resolução e granularidade vistos acima. É o menor
incremento de relógio que se pode conseguir na prática em um determinado
equipamento.
 Dispersão: (Dispersion) É o desvio ou erro estimado nas leituras do relógio. Pode ser
causado por flutuações de curta duração na freqüência do oscilador, por erros de
medida ocasionados por excesso de utilização do processador, latência causada por
interrupções, latência na rede, etc. No NTP a dispersão (dispersion) é estimada
localmente e informada pelo servidor ao cliente na troca de mensagens.
 Variação: (Jitter) É o desvio ou erro nas leituras de relógio. Pode ser causado por
flutuações de curta duração na freqüência do oscilador, por erros de medida
ocasionados por excesso de utilização do processador, latência causada por
interrupções, latência na rede, etc. No NTP a variação (jitter) é estimada pelo cliente, a
partir das diversas medidas de deslocamento (offset) para um determinado servidor. O
NTP também calcula uma variação (jitter) para o sistema como um todo, com base na
variação dos servidores utilizados.
 Deslocamento: (Offset ou time offset) É a diferença de tempo entre dois relógios. No
NTP, o deslocamento representa o quanto o relógio local deve ser alterado para estar
com o valor igual ao da referência de tempo.
 Escorregamento: (Drift) É a instabilidade na freqüência do oscilador. Ou seja, quanto a

freqüência do relógio varia com o tempo. Essa instabilidade pode ser causada por
fatores externos, como variações na radiação, pressão, temperatura ou umidade e
pelo envelhecimento (ageing).
 Monotonicidade: (Monotonicity) Cada leitura sucessiva do relógio deve apresentar um

tempo mais no futuro do que a leitura anterior. Ou seja, o tempo sempre avança.
 Sincronização: (Synchronization) É o processo de ajustar a fase de dois osciladores,

relógios, ou fluxos de dados de forma que a diferença entre eles seja nula. A palavra
pode ser usada também para indicar a propriedade de haver ou não diferenças de
deslocamento entre dois relógios. Ao sincronizar dois relógios não se garante que a
diferença entre eles permanecerá nula ao longo do tempo.
 Sintonização: (Syntonization) É o processo de ajustar dois osciladores para que

forneçam a mesma freqüência. Esse processo não garante que a fase seja a mesma. Ao
sintonizar os osciladores de dois relógios, se as freqüências permanecerem constantes
dali em diante, as diferenças de deslocamento também permanecerão.
Funcionamento do NTP
A topologia do NTP
As setas amarelas indicam uma conexão direta, por um sinal de IRIG, por exemplo; setas
vermelhas indicam uma conexão de rede.
Os servidores NTP formam uma topologia hierárquica, dividida em camadas ou estratos

(em inglês: strata) numerados de 0 (zero) a 16 (dezesseis). O estrato 0 (stratum 0) na
verdade não faz parte da rede de servidores NTP, mas representa a referência primária
de tempo, que é geralmente um receptor do Sistema de Posicionamento Global (GPS)
ou um relógio atômico. O estrato 16 indica que um determinado servidor está
inoperante.
O estrato 0, ou relógio de referência, fornece o tempo correto para o estrato 1, que por
sua vez fornece o tempo para o estrato 2 e assim por diante. O NTP é então,
simultaneamente, servidor (fornece o tempo) e cliente (consulta o tempo), formando
uma topologia em árvore.
Os tipos de associação possíveis
As relações entre os diferentes dispositivos NTP são normalmente chamadas de

Associações. Elas podem ser:
 Permanentes: são criadas por uma configuração ou comando e mantidas sempre.

 Priorizáveis (preemptables): são específicas da versão 4 do NTP e criadas por uma
configuração ou comando, podem ser desfeitas no caso de haver um servidor melhor,
ou depois de um certo tempo.
 Efêmeras ou transitórias: são criadas por solicitação de outro dispositivo NTP e podem
ser desfeitas em caso de erro ou depois de um certo tempo.
São possíveis as seguintes Associações:
 Cliente - Servidor: (client - server) É uma associação permanente e a forma mais

comum de configuração. Um dispositivo faz o papel de cliente, solicitando informações
sobre o tempo a um servidor. O cliente tem conhecimento das associações com os
servidores e do estado da troca de pacotes. Outro dispositivo faz o papel de servidor,
respondendo à solicitação do cliente com informações sobre o tempo. O servidor não
armazena informações sobre o diálogo com o cliente ou sobre sua associação com o
mesmo.
 Modo simétrico: (symmetric mode) Dois ou mais dispositivos NTP podem ser
configurados como pares (peers), de forma que possam tanto buscar o tempo, quanto
fornecê-lo, garantindo redundância mútua. Essa configuração faz sentido para
dispositivos no mesmo estrato, configurados também como clientes de um ou mais
servidores. Caso um dos pares perca a referência de seus servidores, os demais pares
podem funcionar como referência de tempo. O modo simétrico pode ser:
o Ativo: O dispositivo A configura o dispositivo B como seu par (criando dessa
forma uma associação permanente). Por sua vez, o dispositivo B também
configura o dispositivo A como seu par (também cria uma associação
permanente).
o Passivo: O dispositivo A configura o dispositivo B como seu par (modo
simétrico ativo). Mas o dispositivo B não tem o dispositivo A na sua lista de
servidores ou pares. Ainda assim, ao receber um pacote de A, o dispositivo B
cria uma associação transitória, de forma a poder fornecer ou receber o tempo
de A.
 Broadcast ou Multicast: O NTP pode fazer uso de pacotes do tipo broadcast ou

multicast para enviar ou receber informações de tempo. Esse tipo de configuração
pode ser vantajosa no caso de redes locais com poucos servidores alimentando uma
grande quantidade de clientes.
A Troca de Mensagens e o cálculo do Deslocamento
As mensagens do NTP são baseadas no protocolo UDP. A troca de mensagens entre

cliente e servidor permite que o cliente descubra qual seu deslocamento (offset) em
relação ao servidor, ou seja, o quanto seu relógio local difere do relógio do servidor.
Consideremos servidor e cliente com relógios não sincronizados. A troca de mensagens

dá-se da seguinte forma:
1. O Cliente lê seu relógio, que fornece o tempo a.

2. O Cliente envia a Mensagem 1 com a informação de tempo a para o servidor.
3. O Servidor recebe a Mensagem 1 e nesse instante lê seu relógio, que fornece o
instante x. O Servidor mantém a e x em variáveis.
4. O Servidor após algum tempo lê novamente seu relógio, que fornece o instante y.
5. O Servidor envia a Mensagem 2 com a, x e y para o cliente.
6. O Cliente recebe a Mensagem 2 e nesse instante lê seu relógio, que fornece o instante
b.
Ao receber a Mensagem 2, o Cliente passa a conhecer os instantes a, x, y e b. Mas a e b

estão numa escala de tempo, enquanto x e y em outra. O valor do incremento dessas
escalas é o mesmo, mas os relógios não estão sincronizados.
Não é possível, então, calcular o tempo que a Mensagem 1 levou para ser transmitida
(T-ida), nem o tempo que a Mensagem 2 gastou na rede (T-volta). Contudo, o tempo
total de ida e volta, ou atraso (também conhecido por Round Trip Time ou RTT) que é a
soma T-ida + T-volta pode ser calculado como:
 atraso (delay) = (b-a)-(y-x).
Considerando-se que o tempo de ida é igual ao tempo de volta, pode-se calcular o

deslocamento entre o servidor e o relógio local como:
 deslocamento (offset) = x - (a + atraso/2) =

 deslocamento (offset) = (x-a+y-b)/2.
O Algoritmo de Filtro de Relógio
Através da troca de mensagens, o NTP consegue as informações de atraso e

deslocamento de um servidor. Essa troca de mensagens não é realizada uma única vez.
Ela se repete periodicamente, com o período dinamicamente controlado pelo NTP.
É importante notar então, que não há apenas um valor de atraso e um de deslocamento

para cada servidor, mas um conjunto deles, provenientes das diversas trocas de
mensagem! A partir dessa lista de valores, o Algoritmo de Filtro de Relógio calcula
então um valor de atraso (delay), de deslocamento (offset) e de variação (jitter).
Na verdade, cada amostra é composta de 4 valores: atraso, deslocamento, dispersão e

estampa de tempo. A estampa de tempo indica quando a amostra chegou. A dispersão é
o erro estimado do relógio de servidor remoto, informada pelo servidor na mensagem
NTP.
A lista com os valores é ordenada em função do atraso. Considera-se que as amostras
com menor atraso são melhores porque provavelmente não se sujeitaram a filas nos
switches e roteadores, de forma que parte das variações estocásticas de tempo no envio
e recebimento das mensagens é evitada com essa escolha.
Os valores mais antigos são descartados, porque o valor de deslocamento pode não mais
corresponder à realidade, já que a exatidão do relógio local varia ao longo do tempo.
Após descartar as amostras antigas, resta uma lista com as amostras mais recentes e
ordenadas em função do atraso. Da primeira entrada dessa lista são retiradas as variáveis
atraso e deslocamento para o par cliente servidor (note-se que para cada par cliente -
servidor há uma variável de cada tipo).
A dispersão e a variação são calculadas levando em conta todos os valores da lista.
O Algoritmo de Seleção dos Relógios
Uma vez que o Algoritmo de Filtro de Relógios tenha calculado os principais

parâmetros referentes a cada servidor, faz-se importante descobrir quais deles são
confiáveis e quais não. Os servidores que têm algum erro no tempo fornecido são
chamados de relógios falsos (falsetickers, na literatura em inglês, a tradução é
aproximada). Os servidores que fornecem a hora corretamente são chamados de relógios
verdadeiros (truechimmers, em inglês, uma tradução mais literal seria algo como
"badaladores verdadeiros").
Para a seleção dos relógios, o NTP considera como verdadeiro o deslocamento que se
encontra dentro de um determinado intervalo de confiança. Esse intervalo é calculado,
para cada associação com um servidor, como:
 intervalo de confiança = (deslocamento/2) + dispersão.
A Seleção de relógios busca um intervalo de intersecção para os valores de

deslocamento de cada servidor, considerados os intervalos de confiança. Os servidores
cujos deslocamentos ficam fora da intersecção são relógios falsos.
O Algoritmo de Agrupamento
O algoritmo de Agrupamento trabalha com os servidores que são relógios verdadeiros,

utilizando técnicas estatísticas, com o objetivo de selecionar os melhores dentre eles. Os
critérios de seleção utilizados são:
 estrato (stratum)
 distância para a raiz
 variação (jitter)
No processo alguns servidores são descartados, sendo chamados de relógios afastados

(outlyers). Os que permanecem são chamados de relógios sobreviventes (survivors),
algumas vezes na literatura em inglês utiliza-se candidatos (candidates) no mesmo
sentido que sobreviventes, por conta do algoritmo utilizado onde, à princípio, todos os
relógios verdadeiros são candidatos, mas apenas alguns sobrevivem.
O melhor dos relógios sobreviventes é considerado como par do sistema (system peer).
O Algoritmo de Combinação de Relógios
Se o algoritmo de Agrupamento encontrar apenas um sobrevivente, ele será o par do

sistema e será utilizado como referência para ajustar o relógio local. Se um servidor for
configurado como tendo preferência sobre os demais e estiver dentre os sobreviventes,
ele será considerado como par do sistema e, mesmo que existam outros sobreviventes,
estes serão ignorados. Nesses casos, o algoritmo de Combinação de Relógios não é
utilizado.
Para os demais casos, quando há mais do que um sobrevivente e nenhum deles foi
configurado com a palavra chave prefer, o algoritmo de Combinação de Relógios
calcula uma média ponderada dos deslocamentos dos relógios, com o objetivo de
aumentar a exatidão.
Disciplina do Relógio Local
O processo de disciplina do Relógio Local controla a fase e a freqüência do relógio do

sistema. Ele é baseado na combinação de duas filosofias de controle bastante diferentes
entre si: Phase Locked Loop (PLL) e Frequency Locked Loop (FLL) (traduções desses
termos são incomuns, mas poderiam ser Laço Controlado por Fase e Laço Controlado
por Freqüência). Ambas as filosofias implementam controles onde há realimentação, ou
seja, onde a informação de saída é usada novamente na entrada.
O NTP disciplina o relógio local de forma contínua, mesmo em períodos onde não é
possível consultar servidores de tempo. As características do relógio local são medidas e
se tornam conhecidas do NTP, o que torna possível que ele funcione dessa forma. O
arquivo indicado pela chave driftfile (geralmente /var/lib/ntp/ntp.drift) na configuração
armazena o erro esperado de freqüência para o relógio.
Algumas características importantes desse algoritmo:
 Saltos no tempo são evitados sempre que possível. O tempo é ajustado para mais ou
para menos gradualmente, variando-se a freqüência do relógio local.
 Se uma diferença maior do que 128ms for detectada o NTP considera que o tempo
está muito errado, e que é necessário um salto para frente ou para trás para corrigi-lo.
Contudo isso só é feito se essa diferença maior que 128ms persistir por um período
maior que 900s (15min), para evitar que condições de congestionamento grave mas
temporário na rede, que podem levar a medições erradas de tempo, causem
inadvertidamente esse tipo de salto.
 Se uma diferença maior que 1000s (~16,7min) for detectada o algoritmo aborta a
execução, considerando que algo muito errado aconteceu. Se houver diferenças dessa
ordem ou maiores elas devem ser corrigidas manualmente antes de se executar o
daemon NTP.
Segurança no NTP
Por segurança no contexto da Tecnologia da Informação entende-se basicamente

garantir quatro propriedades da informação: integridade, disponibilidade, autenticidade
e confidencialidade.
Os algoritmos vistos anteriormente, aliados à correta configuração do sistema, com um

número suficiente de fontes de tempo com referências primárias independentes,
garantem de forma satisfatória a integridade e disponibilidade do serviço de tempo.
Os algoritmos de criptografia do NTP visam garantir a autenticidade da informação. Ou

seja, têm o objetivo de assegurar ao cliente que o servidor é quem ele diz ser.
A confidencialidade não é considerada um problema no contexto do NTP. Ou seja, a

informação de tempo sempre trafega na rede de forma aberta, sem criptografia, mesmo
quando uma assinatura cifrada é utilizada para garantir a autenticidade da informação.
Isso é dessa forma porque o tempo é uma informação pública, não há razão para
esconder essa informação e trabalhar com a informação de tempo cifrada demandaria
tempo tanto do servidor quando do cliente e degradaria o desempenho do sistema,
fazendo-o menos exato.
Existem basicamente dois métodos no NTP para realizar a autenticação, chave simétrica
(symmetric key) e chave pública (autokey).
Servidores de NTP públicos
Servidores públicos de NTP podem ser encontrados em:
 http://support.ntp.org/bin/view/Servers/WebHome : Lista de servidores NTP Públicos.

 http://www.pool.ntp.org: Projeto que mantém um DNS pool com servidores públicos
de NTP.
 http://www.ntp.br: Serviço NTP do NIC.br. Mantém servidores sincronizados com a
Hora Legal Brasileira, fornecida pelo Observatório Nacional.
Ligações externas
Serviço NTP e informações (em português)
 http://www.ntp.br: Serviço NTP do NIC.br. Neste site pode ser encontrada

documentação sobre o NTP e sobre o serviço prestado pelo NIC.br.
 http://www.rnp.br/ntp: Serviço NTP da RNP (Rede Nacional de Ensino e Pesquisa).
Neste site pode ser encontrada documentação sobre o NTP e sobre o serviço NTP
prestado pela RNP.
 http://www.nara.org.br/servicos/ntp : O Núcleo de Apoio a Rede Acadêmica (NARA)
disponibiliza informações sobre a configuração de clientes e servidores NTP.
 http://www.oal.ul.pt/index.php?link=acerto: Página do Observatório Astronómico de
Lisboa com informações sobre a configuração de clientes NTP para acerto da hora
Portuguesa.
Hora Legal Brasileira

 http://www.on.br: Página do Observatório Nacional. O ON tem como atribuição legal a
geração, conservação e disseminação da Hora Legal Brasileira. Rastreado ao Bureau
International des Poids et Mesures (BIPM), na França, participa do Tempo Universal
Coordenado (UTC), juntamente com os órgãos disseminadores de tempo e frequência
dos demais países.
 http://pcdsh01.on.br: Divisão do Serviço da Hora do Observatório Nacional. O ON
possui um serviço de NTP público.
Hora Legal Portuguesa
 http://www.oal.ul.pt: Página do Observatório Astronómico de Lisboa. Uma das tarefas

do OAL é a de manter e fornecer a Hora Legal de Portugal, dirigindo a Comissão
Permanente da Hora.
Pesquisa sobre o uso do NTP na Internet (em português)
 http://www.ntpsurvey.arauc.br: Página sobre a pesquisa realizada em 2005, por Pedro

R. Torres Júnior, da UFPR, analisando a rede de servidores NTP da Internet. O trabalho
resultou, entre outras coisas, em sua dissertação de mestrado, que pode ser baixada
do site.
Projeto NTP (em inglês)
 http://www.ntp.org: Página oficial do projeto NTP.

 http://www.eecis.udel.edu/~mills/ntp.html : Página do projeto NTP mantida por David
Mills.
 http://www.eecis.udel.edu/~mills/ntp/html/index.html : Documentação da
implementação de referência oficial do NTP, mantida por David Mills.
 http://www.ntp.org/ntpfaq: FAQ e HOWTO do NTP.
 http://support.ntp.org:NTP Public Services Project, é um site wiki com documentação
construída pela comunidade: http://support.ntp.org/bin/view/Support/WebHome. A
página também lista servidores ntp públicos:
http://support.ntp.org/bin/view/Servers/WebHome
 http://www.isc.org: Página do Internet Systems Consortium. O ISC mantém o NTP
Public Services Project.
 http://www.pool.ntp.org: Projeto que mantém um DNS pool com servidores públicos
de NTP.
 http://www.ijs.si/time: Página do Jožef Stefan Institute, na Eslovênia, sobre NTP.
Documentação de ótima qualidade.
 http://www.meinberg.de/english/sw/ntp.htm: Instalador do NTP (implementação de
referência) para Windows.
Projeto NTP - normas (inglês)
 ftp://ftp.registro.br/rfc/rfc1305: Especificação do protocolo NTP versão 3. Não existe

uma especificação da versão 4 do protocolo.
 ftp://ftp.registro.br/rfc/rfc4330: Especificação do protocolo SNTP versão 4.
 http://www.ietf.org/html.charters/ntp-charter.html : Esta página com o link para a
versão mais recente do draft do protocolo NTP versão 4.
 http://support.ntp.org/bin/view/IETF/WebHome : Grupo de trabalho do IETF para a
criação da especificação do NTP versão 4.
Pesquisas sobre o NTP (inglês)
 http://alumni.media.mit.edu/~nelson/research/ntp-survey99 : Artigo, escrito por

Nelson Minar do MIT, em 1999, levantando características da rede de servidores NTP
na Internet.
 http://www.terena.nl/activities/tf-ngn/tf-ngn11/20030508_LS_ntp_ipv6.pdf :
Comparativo do uso de NTP com IPv4 e IPv6. Apresentação de 2003, feita por Laura
Serrano, da RedIRIS.
Informações sobre padrões de tempo (inglês)
 http://www.bipm.org: Bureau International des Poids et Mesures (BIPM). O BIPM é a

entidade responsável por garantir a uniformidade dos padrões de medida em âmbito
mundial, o que inclui a geração do Tempo Universal Coordenado (UTC).
 http://tf.nist.gov/timefreq: National Institute of Standards and Technology (NIST) -
Time & Frequency Division. É uma das instituições responsáveis por manter os padrões
de tempo e freqüência nos Estados Unidos .
 http://tycho.usno.navy.mil/: US Naval Observatory - Time Service Department. É uma
das instituições responsáveis por manter os padrões de tempo e freqüência nos
Estados Unidos.
Outros (inglês)
 http://www.schlitt.net/scripts/ntp: Scripts de monitoração utilizados por um dos

membros do Pool de servidores NTP públicos.
 http://saturn.dennishilberg.com/gathering_data.php : Scripts de monitoração
utilizados por um dos membros do Pool de servidores NTP públicos.
 Meinberg NTP Server
 Windows NTP Server
 Elproma Time Server NTP Division
 Oscilloquartz SA - NTP servers
 NTP Server Test Online
Post Office Protocol

O Post Office Protocol (termo em inglês que, traduzido, significa "Protocolo dos
correios"), ou POP3, é um protocolo utilizado no acesso remoto a uma caixa de correio
eletrônico.[1] Ele está definido no RFC 1939 e permite que todas as mensagens contidas
numa caixa de correio eletrônico possam ser transferidas sequencialmente para um
computador local. Dessa maneira, o utilizador pode ler as mensagens recebidas, apagá-
las, responder-lhes, armazená-las etc.
Este protocolo utiliza as portas TCP 110 (porta padrão) ou TCP 995 (conexão
criptografada via SSL). A porta TCP 109 foi utilizada na versão anterior do protocolo
(POP2).[2][3]
O funcionamento do protocolo POP3 diz-se off-line, uma vez que o processo suportado
se baseia nas seguintes etapas:
 É estabelecida uma ligação TCP entre a aplicação cliente de e-mail (User Agent - UA) e
o servidor onde está a caixa de correio (Message Transfer Agent - MTA)
 O utilizador autentica-se;
 Todas as mensagens existentes na caixa de correio são transferidas sequencialmente
para o computador local;
 As mensagens são apagadas da caixa de correio (opcionalmente, o protocolo pode ser
configurado para que as mensagens não sejam apagadas da caixa de correio; se esta
opção não for utilizada, deve-se utilizar sempre o mesmo computador para ler o
correio eletrônico, para poder manter um arquivo das mensagens);
 A ligação com o servidor é terminada;
 O utilizador pode agora ler e processar as suas mensagens (off-line).
A característica off-line do protocolo POP3 é particularmente útil para utilizadores que

se ligam à Internet através de redes públicas comutadas, em que o custo da ligação é
proporcional ao tempo de ligação (exemplo: a rede telefônica convencional ou a rede
RDIS). Com o POP3, a ligação apenas precisa de estar ativa durante a transferência das
mensagens, e a leitura e processamento das mensagens pode depois ser efetuada com a
ligação inativa.
Referências
1.
 «Network+ Guide to Networks - Tamara Dean - Google Books». books.google.com.br.

Consultado em 23 de abril de 2012
  «Service Name and Transport Protocol Port Number Registry». www.iana.org. Consultado
em 8 de maio de 2017
3.  «Service Name and Transport Protocol Port Number Registry». www.iana.org.

Consultado em 8 de maio de 2017
Ver também
 Internet Message Access Protocol

 Simple Mail Transfer Protocol
Ligações externas
 RFC 1939 "Post Office Protocol - Version 3" (em inglês)

 RFC 2449 "POP3 Extension Mechanism" (em inglês)
 RFC 1734 "POP3 AUTHentication command" (em inglês)
 RFC 2222 "Simple Authentication and Security Layer (SASL)" (em inglês)
 RFC 3206 "The SYS and AUTH POP Response Codes" (em inglês)
Open Network Computing Remote Procedure Call
O Open Network Computing Remote Procedure Call (frequentemente abreviado
para ONC RPC; ou ainda, Sun ONC e Sun RPC) é um sistema de chamada de
procedimento remoto, desenvolvido originalmente pela Sun Microsystems como parte
do projeto Network File System.
O sistema é baseado nas convenções de chamada usadas em Unix e em C. Ele serializa

os dados usando a linguagem de descrição de interface XDR, que também é usado para
codificar e decodificar dados em arquivos que são acessados em mais de uma
plataforma. A transmissão do XDR é feita através de UDP ou TCP. O acesso aos
serviços de uma máquina é feito através de um mapeador de portas que aguarda
requisições em portas conhecidas.
Existem implementações do ONC RPC na maioria dos sistemas Unix-like. Já a

Microsoft fornece uma implementação para Windows como parte do Microsoft
Windows Services for UNIX; mas também diversas implementações externas para
Windows doutros fornecedores.
O ONC RPC é descrito no RFC 1831, e os mecanismos de autenticação usados pelo

sistema são descritos em RFC 2695, RFC 2203 e RFC 2623.
Referências
 «ONC RPC: Invocação de Procedimentos Remotos» (PDF). Faculdade de Ciências e Tecnologia

da Universidade Nova de Lisboa. Consultado em 13 de julho de 2008
Real-time Transport Protocol

Em ciência da computação, RTP (do inglês Real-time Transport Protocol) é um
protocolo de redes utilizado em aplicações de tempo real como, por exemplo, entrega de
dados áudio ponto-a-ponto, como Voz sobre IP. Ele funciona como uma sub-camada na
camada de transporte, camada 4 do Modelo OSI, e define como deve ser feita a
fragmentação do fluxo de dados de áudio, adicionando a cada fragmento informação de
sequência e de tempo de entrega, sendo o controle é realizado pelo RTCP - Real Time
Control Protocol. Ambos utilizam o UDP como real protocolo de transporte, o qual não
oferece qualquer garantia que os pacotes serão entregues num determinado intervalo.
O RTP permite que seja atribuída a cada fonte (i.e, câmeras ou microfones) sua própria
corrente independente de pacotes RTP. Por exemplo, para uma videoconferência entre
dois participantes, quatro correntes RTP podem ser abertas — duas correntes para
transmitir o áudio (uma em cada direção) e duas para transmitir o vídeo (uma em cada
direção).
Os protocolos RTP/RTCP são definidos pela RFC 3550 do IETF (Internet Engineering
Task Force).
Bibliografia
 Perkins, Colin (2003), RTP, ISBN 978-0-672-32249-5, Addison-Wesley

 Peterson, Larry L.; Viktoriya Limonova (2007), Computer Networks, ISBN 978-0-12-
374013-7 4 ed. , Morgan Kaufmann
 «RTP». Network Protocols Handbook. [S.l.]: Javvin Technologies. 2005. ISBN 978-0-
9740945-2-6
 «RTP». Broadband Networks. [S.l.]: Ministry of Human resources, India. 2008
Ligações externas
 oRTP, RTP library from Linphone written in C (em inglês)

 Henning Schulzrinne's RTP page(including FAQ)
 GNU ccRTP
 JRTPLIB, a C++ RTP library
 RTPMobile.NET, an open source.NET RTP library
 LScube project, providing a full streaming suite including experimental SCTP support
RTSP
O Real Time Streaming Protocol (RTSP) é um protocolo a nível de aplicação
desenvolvido pela IETF em 1998 com a RFC 2326 para controle na transferência de
dados com propriedades de tempo real. RTSP torna possível a transferência, sob
demanda, de dados em tempo real como áudio e vídeo. Ele serve para estabelecer e
controlar um único ou vários streams sincronizados de mídias contínuas pertencentes a
uma apresentação.Utiliza os protocolos TCP e UDP na porta 554.
O conjunto de streams a ser controlado é definido por uma descrição de apresentação,

normalmente um arquivo, que pode ser obtido por um cliente usando HTTP ou outro
meio como e-mail; e, pode não necessariamente estar armazenado em um servidor de
mídia. Uma descrição de apresentação contém informações sobre um ou mais streams
que compõe a apresentação, como endereços de rede e informações sobre o conteúdo
da apresentação, além de parâmetros que tornam possível ao cliente escolher a
combinação mais apropriada das mídias.
Routing Information Protocol

O RIP (Routing Information Protocol) é um padrão para troca de informações entre
os gateways e hosts de roteamento. Atualmente existem muitos protocolos de
roteamento utilizados para toda a rede. A rede mundial de computadores é organizada
como um conjunto de "sistemas autônomos". Cada sistema autônomo tem a sua
própria tecnologia de roteamento, o que pode bem ser diferente para diferentes sistemas
autônomos. O protocolo de roteamento usado entre roteadores de um mesmo sistema
autônomo é referido como um IGP (Interior Gateway Protocol). Um protocolo separado
é usado para fazer a interface entre os sistemas autônomos. O mais antigo, e ainda
usado na internet é o EGP (Exterior Gateway Protocol). Esses
protocolos são agora geralmente referidos como protocolos inter-AS de roteamento. O
RIP é projetado para redes com tamanho moderado, que utilizam uma
tecnologia razoavelmente homogênea. Não é destinado a uso em ambientes mais
complexos, devido à suscetibilidade a falhas. O RIP2, é uma evolução do RIP,
e destina-se a expandir a quantidade de informação útil carregada nos pacotes e também
adicionar uma medida de segurança. RIP2 é um protocolo que utiliza UDP para
transporte. Cada host que usa RIP2 tem um processo de roteamento que envia e recebe
datagramas em UDP, na porta 520. RIP e RIP2 são para redes IPv4, enquanto o RIPng é
projetado para a rede IPv6.
Índice
 1 Atualizações do roteamento
o 1.1 Operação
 2 Métrica de roteamento
 3 Características da estabilidade do RIP
 4 Temporizadores do RIP
 5 Formato do pacote do RIP
 6 Formato do pacote do RIP 2
 7 Tópicos relacionados
Atualizações do roteamento
O RIP emite mensagens de atualização das suas rotas (Tabelas de Roteamento) em

intervalos regulares (a cada 30 segundos) e quando a topologia da rede mudar. Quando
um roteador recebe uma atualização do roteamento que inclua mudanças a uma entrada,
atualiza sua tabela de roteamento para refletir a rota nova. O valor métrico (salto) para o
trajeto é aumentado por 1 e o remetente é indicado como o hop seguinte. Os roteadores
do RIP mantêm somente a melhor rota (a rota com o valor métrico mais baixo) à um
destino. Após ter atualizado sua tabela de roteamento, o roteador começa imediatamente
a transmitir atualizações do roteamento para informar aos outros roteadores da rede
sobre a mudança. Estas atualizações são emitidas independentemente das atualizações
regulares programadas.
Operação
RIP define 2 tipos de mensagens.
1. Requisição (Request Message)

2. Resposta (Response Message).
Quando um roteador RIP fica online, envia uma mensagem de requisição (Request
Message) em broadcast para todas as interfaces RIP. Todos os roteadores vizinhos que
receberem essa mensagem a respondem de volta (Response Message) contendo suas
tabelas de roteamento. A mensagem de resposta é também gratuitamente enviada
quando o temporizador de atualização expira.
Assim que o roteador recebe a tabela de roteamento, processa cada entrada da tabela de
roteamento seguindo as regras:
1. Se não existem entradas de rotas que correspondem à recebida, então a entrada de

rota é automaticamente adicionada à tabela de roteamento, juntamente com as
informações sobre o roteador do qual recebeu a tabela de roteamento.
2. Se existirem entradas correspondentes, mas a contagem de hop é menor da que está
em sua tabela de roteamento, então a tabela de roteamento é atualizada com a nova
rota.
3. Se existirem entradas correspondentes, mas a contagem de hop é maior da que está
em sua tabela de roteamento, então a tabela de roteamento é atualizada com
contagem de hop de 16 (hop infinito). Os pacotes ainda são encaminhados à antiga
rota. Um temporizador hold-down é disparado e todas as atualizações daquela rota
vindas de outros roteadores são ignoradas/descartadas. Se após o término do
temporizador o roteador ainda está alertando sobre a contagem maior de hop, então
o valor é atualizado dentro de sua tabela de roteamento. Somente após o fim do
temporizador, as atualizações dos outros roteadores são aceitas para aquela rota.
Métrica de roteamento
O RIP usa um único roteamento métrico (contagem do hop) para medir a distância entre
a origem e o destino. Cada hop em um trajeto da fonte ao destino é atribuído um valor
de contagem, tipicamente 1. Quando um roteador recebe um atualização do roteamento
que contenha uma entrada nova ou mudada da rede de destino, o roteador adiciona 1 ao
valor métrico indicado na atualização e incorpora a rede à tabela de roteamento. O
endereço IP do remetente é usado como o hop seguinte.
Características da estabilidade do RIP
O RIP impede que os enlaces do roteamento continuem transmitindo infinitamente, a

fim de evitar loops na rede. Para tal, o protocolo possui um limite no número dos hops
permitidos em um trajeto da fonte ao destino. O número máximo dos hops em um
trajeto é 15. Se um roteador receber uma atualização do roteamento que contenha uma
entrada nova ou mudada, e se aumentar o valor métrico por 1 pode resultar em loop, o
destino da rede será então considerado inalcançável. O ponto fraco desta característica
da estabilidade é que limita o número de saltos máximos de uma rede RIP para 16 hops.
O RIP inclui inúmeras outras características de estabilidade que são comuns a muitos
protocolos do roteamento. Estas características são projetadas a fim de fornecer
estabilidade, mesmo com mudanças rápidas e constantes na topologia de uma rede. O
RIP executa os mecanismos SPLIT HORIZON e HOLD DOWN para impedir que a
informação de roteamento incorreta seja propagada.
Temporizadores do RIP
O RIP usa vários temporizadores para regular seu desempenho. Estes incluem:
 temporizador de atualização do roteamento;

 temporizador do intervalo de distribuição;
 temporizador para o nível de distribuição.
O temporizador da atualização de roteamento cronometra o intervalo entre atualizações
periódicas das tabelas de roteamento. Geralmente, é ajustado a 30 segundos, com uma
quantidade pequena de tempo aleatório adicionado sempre que o temporizador é
restaurado. Isto é feito para ajudar impedir o congestionamento, que poderia ocorrer
caso todos os roteadores que tentem simultaneamente atualizar suas tabelas. Cada
entrada da tabela de roteamento tem um temporizador de intervalo de distribuição
associada a ela. Quando o temporizador de intervalo de parada expira, a rota é marcada
como inválida, mas será retida na tabela de roteamento por um certo número de
atualizações, após isso, ela será excluída.
Formato do pacote do RIP
As seguintes descrições resumem os campos do formato do datagrama RIP:
 Comando: Indica se o pacote que é um pedido ou uma resposta. O pedido pergunta

que um roteador emite o toda ou uma parte de sua tabela de roteamento. A resposta
pode ser uma atualização regular não solicitada do roteamento ou uma resposta a um
pedido. As respostas contêm entradas da tabela de roteamento.
 Número de versão: Especifica a versão do RIP usada. Este campo serve para sinalizar
versões potencialmente diferentes e/ou incompatíveis.
 O campo zero: Este não é usado realmente pelo RIP de RFC 1058; adicionou-se
unicamente para fornecer a compatibilidade inversa com as variedades pré-
padronizadas do RIP. Seu nome vem de seu valor optado: zero.
 Identificador do Endereço da família (AFI): Especifica a família do endereço usada. O
RIP é projetado para carregar a informação de roteamento para diversos protocolos
diferentes. Cada entrada tem um identificador do endereço-família para indicar o tipo
de endereço que está sendo especificado.
 Endereço: Especifica o endereço IP endereço para a entrada.
 Métrica: Indica quantos hops da rede interna (roteadores) foram atravessados da
chegada ao destino. Este valor está entre 1 e 15 para uma rota válida, ou 16 para uma
rota inalcançável.
Até 25 AFIs, endereços, e métricos são permitidos em um único pacote RIP. (até 25
destinos podem ser alistados em um único pacote do RIP).
Formato do pacote do RIP 2
A especificação do RIP 2 (descrita em RFC 1723) permite que mais informação seja
incluída em pacotes do RIP e fornece um mecanismo simples do autenticação que não
seja suportado pelo RIP.
 Comando: Indica se o pacote é um pedido ou uma resposta. O pedido pergunta se um

roteador emite toda ou uma parte sua tabela de roteamento. A resposta pode ser uma
atualização regular não solicitada do roteamento ou uma resposta a um pedido. As
respostas contêm entradas da tabela de roteamento. Os pacotes múltiplos do RIP são
usados fazer saber à informação das tabelas de roteamento grandes.
 Versão: Especifica a versão do RIP usada. Em um pacote do RIP que executa alguns dos
campos do RIP 2 ou que usa o autenticação, este valor é ajustado a 2.
 Identificador de endereçamento da família (AFI): Especifica a família do endereço
usada. Funções do campo da AFI do RIP 2 são idênticas ao campo de AFI do RIP do RFC
1058, com uma exceção: Se o AFI para a primeira entrada na mensagem for 0xFFFF, o
restante da entrada contém a informação da autenticação. Atualmente, o único tipo
de autenticação é senha simples.
 Distribution Tag: Provê um método para distinguir entre as rotas internas (aprendidas
pelo RIP) e as rotas externas (aprendidas de outros protocolos).
 Endereço IP: Especifica o endereço IP para a entrada.
 Máscara da Sub-rede: Contém a máscara da sub-rede para a entrada. Se este campo
for zero, nenhuma máscara da subrede foi especificada para a entrada.
 Hop seguinte: Indica o endereço IP do hop seguinte a que os pacotes devem ser
enviados.
 Métrica: Indica quantos hops da rede interna (roteadores) foram atravessados no
desengate ao destino. Este valor está entre 1 e 15 para uma rota válida ou 16 para
uma rota inalcançável.
Em resumo, o RIP (Routing Information Protocol) foi o primeiro protocolo de

roteamento padrão desenvolvido para ambientes TCP/IP. O RIP é um protocolo de
encaminhamento dinâmico, que implementa o algoritmo vetor-distância (erroneamente
vetor de distância) e caracteriza-se pela simplicidade e facilidade de solução de
problemas. Seus pacotes são enviados em UDP. Normalmente, os roteadores usam RIP
em modo ativo e as estações (hosts) em modo passivo. O RIP transmite a sua tabela de
encaminhamento a cada 30 segundos. O RIP permite 15 rotas por pacote; assim, em
redes grandes, são exigidos vários pacotes para enviar a tabela de encaminhamento
inteira. A distância ao destino é medido pelos roteadores que se passam até chegar ao
destino, permitindo passar por até 15 roteadores, tendo depois de ser reencaminhado de
novo.
Tópicos relacionados
 BGP
 OSPF
 Traceroute
 Ping
 WHOIS
Protocolo de Iniciação de Sessão

O Protocolo de Iniciação de Sessão (Session Initiation Protocol - SIP) é um
protocolo de código aberto de aplicação, que utiliza o modelo “requisição-resposta”,
similar ao HTTP, para iniciar sessões de comunicação interativa entre utilizadores. É
um padrão da Internet Engineering Task Force (IETF) (RFC 2543, 1999.).[1]
SIP é um protocolo de sinal para estabelecer chamadas e conferências através de redes

via Protocolo IP, um exemplo típico seria o VoIP. O estabelecimento, mudança ou
término da sessão é independente do tipo de mídia ou aplicação que será usada na
chamada; uma chamada pode utilizar diferentes tipos de dados, incluindo áudio e vídeo.
SIP teve origem em meados da década de 1990 (naquele tempo o H.323 estava a
começar a ser finalizado como um padrão) para que fosse possível adicionar ou remover
participantes dinamicamente numa sessão multicast. O desenvolvimento do SIP
concentrou-se em ter um impacto tão significativo quanto o protocolo HTTP, a
tecnologia por trás das páginas da web que permitem que uma página com links
clicáveis conecte com textos, áudio, vídeo e outras páginas da web. Enquanto o HTTP
efetua essa integração através de uma página web, o SIP integra diversos conteúdos a
sessões de administração. O SIP recebeu uma adoção rápida como padrão para
comunicações integradas e aplicações que usam presença. (Presença significa a
aplicação estar consciente da sua localização e disponibilidade).
SIP foi moldado, inspirado em outros protocolos de Internet baseados em texto como o
SMTP (email) e o HTTP (páginas da web) e foi desenvolvido para estabelecer, mudar e
terminar chamadas num ou mais utilizadores numa rede IP de uma maneira totalmente
independente do conteúdo de dados da chamada. Como o HTTP, o SIP leva os controles
da aplicação para o terminal, eliminando a necessidade de uma central de comutação.
O protocolo SIP possui as seguintes características:
 Simplicidade e possui apenas seis métodos.

 Independência do protocolo de transporte.
 Baseado em texto.
Índice
 1 Arquitetura do SIP
o 1.1 Agente do Utilizador
o 1.2 Servidor Proxy
 1.2.1 Servidor Proxy SIP
 1.2.2 Servidor de Redirecionamento SIP
o 1.3 Registrador
 2 A Arquitectura SIP Suporta Novos Tipos de Serviços
 3 O SIP no mercado atual
 4 A relação do SIP e do H.323
 5 Interoperabilidade com o H.323
 6 Ver também
Arquitetura do SIP
Os principais componentes da arquitetura do SIP são:
Agente do Utilizador
O Agente do Utilizador é o terminal SIP ou o software de estação final. O Agente do

Utilizador funciona como um cliente no pedido de inicialização de sessão e também age
como um servidor quando responde a um pedido de sessão. Dessa forma, a arquitectura
básica é cliente/servidor.
O Agente do Utilizador é “inteligente”, com isso ele armazena e gerencia situações de

chamada. O Agente do Utilizador faz chamadas com um endereço parecido com o de e-
mail ou número de telefone (E.164).
Como por exemplo: SIP:user@proxy.university.edu
Isso faz URLs SIP fáceis de associar com o endereço de e-mail do usuário. O Agente do
Utilizador pode aceitar e receber chamadas de outro Agente do Utilizador sem requerer
nenhum componente adicional do SIP. Os componentes restantes fornecem
gerenciamento e funcionalidades adicionais.
Servidor Proxy
Servidor Proxy SIP
Um tipo de servidor intermediário do SIP é um Servidor Proxy SIP. O Servidor Proxy

SIP encaminha pedidos antes do Agente do utilizador para o próximo servidor SIP
retendo também informações com a finalidade de poderem ser usadas para fins
contabilísticos ou de facturação. Além disso, o servidor proxy SIP pode operar com
comunicação stateful (por exemplo, como um circuito, TCP) ou stateless (por exemplo
como um UDP). O servidor SIP stateful pode “dividir” chamadas por ordem de chegada
para que várias extensões que estejam a tocar todos ao mesmo tempo sendo que a
primeira a atender ficará com a chamada. Essa capacidade significa que se pode
especificar que um telefone de desktop SIP, um telefone celular SIP e aplicações de
videoconferência de casa SIP possam sinalizar simultanemente quando estiver a receber
uma chamada. Ao atender um dos dispositivos e iniciada a conversação, os restantes
param de sinalizar. O servidor proxy SIP pode utilizar múltiplos métodos para tentar
resolver o pedido de endereço de host, incluindo busca de DNS, busca em base de dados
ou retransmitir o pedido para o “próximo” servidor proxy.
Servidor de Redirecionamento SIP
Um outro tipo de servidor intermediário do SIP é o Servidor de Redirecionamento SIP.

A função do servidor de redirecionamento SIP é fornecer a resolução de nome e
localização do usuário. O servidor de redirecionamento SIP responde ao pedido do
Agente do Usuário fornecendo informações sobre o endereço do servidor para que o
cliente possa contactar o endereço diretamente.
Registrador
O Registrador SIP fornece um serviço de informação de localidades; ele recebe

informações do Agente do Usuário e armazena essa informação de registro.
A arquitectura do SIP faz uso do SDP (Session Description Protocol). O SDP foi uma
ferramenta de conferência multicast via IP desenvolvida para descrever sessões de
áudio, vídeo e multimídia. Na realidade, qualquer tipo de MIME (Multipurpose Internet
Mail Extension) pode ser descrita, similar à habilidade do e-mail de suportar todos os
tipos de anexos em mensagens. A descrição da sessão pode ser usada para negociar uma
aceitação de um conjunto de tipos de mídias compatíveis.
Como resultado dessa arquitectura, o endereço do usuário SIP remoto é sempre o

mesmo (por exemplo sip:user@proxy.univ.edu), mas ao invés de estar amarrado a um
endereço estático, ele comporta-se como um endereço dinâmico que reflecte a
localização actual do destinatário. A combinação de Proxy e Servidor Redirecionador dá
ao SIP grande flexibilidade de arquitectura; o usuário pode empregar vários esquemas
simultaneamente para usuários localizados e é o que faz a arquitetura do SIP ser bem
adaptada para suportar mobilidades. Mesmo quando o usuário remoto é móvel, o Proxy
e o redireccionador podem ser usados para passar adiante o pedido de conexão para o
usuário da locação actual. As sessões podem envolver múltiplos participantes, de forma
similar a uma chamada multiponto H.323. Comunicações dentro de uma sessão em
grupo podem ser via multicast ou via uma rede de chamadas unicast, ou até mesmo uma
combinação dos dois. Um outro resultado da arquitectura do SIP é a sua adequação
natural como um ambiente de colaboração devido às suas habilidades de apresentar
múltiplos tipos de dados, aplicações, multimídia, etc. com uma ou mais pessoas.
A Arquitectura SIP Suporta Novos Tipos de Serviços
Um tipo de “transmissão de chamadas” permite aos usuários especificar onde eles estão
para que as chamadas possam ser passadas para lá ou escolher para passar as chamadas
para o “e-mail de voz” ou para qualquer outro serviço de atendimento automático.
Participantes de chamada podem gerenciar a chamada; isso permite que os participantes
decidam introduzir uma nova chamada participante ou cancelar uma conexão na
chamada. A habilidade de responder a uma chamada com um tipo diferente de mídia;
isso permite, por exemplo, que um stream de voz que está a chegar seja respondido por
uma página da web. Informação de “presença” – o Agente do Usuário pode ser usado
para indicar se o usuário está presente (disponível para atender a todas as chamadas
chamada) ou ausente (não disponível para atender a chamada).
O SIP no mercado atual
Há um certo número de produtos comerciais e de fonte aberta do SIP disponíveis

actualmente e desenvolvimento comercial tem se mostrado com foco nos Agentes do
Usuário como o telefone SIP e os softwares de Agentes do Usuário. Exemplos notáveis
incluem o “Messenger” da Microsoft. Uma linha mais desenvolvida de produtos com a
arquitectura SIP está disponível pela Siemens, Cisco, Avaya, Nortel Networks, PingTel,
3COM (US Robotics), e outros. Um produto desse domínio está disponível pela Wave3
Software, inclui software tanto para plataforma Windows como para Macintosh.
A Microsoft anunciou que não desenvolverá mais o H.323 (NetMeeting e Exchange

Conferencing Server) e passará exclusivamente a desenvolver produtos dentro do SIP.
O Windows Messenger provê ao usuário um software de telefone (um dispositivo de
voz sobre IP) com as ferramentas adicionais de vídeo, Chat e compartilhamento de
dados. Os componentes do servidor SIP estão em desenvolvimento e devem aparecer no
mercado em breve. Esta é a fronteira para se ter um tremendo impacto no mercado pela
adoção do SIP.
O Network World Fusion conduziu um teste de interoperabilidade no Windows

Messenger em Janeiro de 2002, registrando o cliente Microsoft com um Synamicsoft
SIP Proxy Server e passando as chamadas por um telefone IP Pingtel xpressa. As
chamadas não foram feitas somente com sucesso, mas também com uma qualidade de
voz relatada como “qualidade comercial”.
A relação do SIP e do H.323
O SIP e o H.323 são padrões para rota de chamada, sinal de chamada, troca de
capacidade, controle de mídia e serviços adicionais. A força do H.323 tem sido a sua
interoperabilidade com a rede telefónica pública comutada(PSTN) e disponibilidade de
sistemas/aplicações desktop e salas de videoconferência de preço acessível e confiável.
O SIP é um protocolo desenvolvido especificamente para Internet e promete grande
escalabilidade e flexibilidade. É provável que o H.323 fique como a tecnologia de
conferência para gerenciar serviços de conferência/colaboração pelos próximos 2 ou 3
anos, com o SIP se tornando mais usado quando o MCU SIP, gateways e servidores
passarem além do beta. O RADVISION, por exemplo, tem demonstrado um gateway
H.323/SIP em algumas exposições profissionais, mas ainda não é um produto.
Interoperabilidade com o H.323
As organizações de padrões já estão trabalhando com uma interoperabilidade SIP-

H.323, prometendo a possibilidade de um período de transição razoável entre as
tecnologias H.323 e SIP. Duas organizações que estão especialmente interessadas esse
tópico são a IMTC (International Multimedia Telecommunications Consortium), uma
corporação sem fins lucrativos, com mais de 100 organizações pelo mundo, e também a
ETSI (European Telecommunications Standards Institute). A Open H.323 Organization
já lançou um gateway de trabalho H.323 para SIP.
Ver também
 H.323
 IAX-2
 VoIP
Simple Mail Transfer Protocol

Simple Mail Transfer Protocol (abreviado SMTP. Traduzido do inglês, significa
"Protocolo de transferência de correio simples") é o protocolo padrão para envio de e-
mails através da Internet, definido na RFC 821.
É um protocolo relativamente simples, em texto plano, onde um ou vários destinatários

de uma mensagem são especificados (e, na maioria dos casos, validados) sendo, depois,
a mensagem transferida. Esse protocolo usa por padrão a porta TCP 25 (ou 465 para
conexão criptografada via SSL). No Brasil, porém, desde 2013, provedores e operadoras
de internet passaram a utilizar a porta 587, como medida de segurança para diminuir o
número de spams.[1]
O SMTP é um protocolo de envio apenas, o que significa que ele não permite que um
usuário descarregue as mensagens de um servidor. Para isso, é necessário um cliente de
e-mail com suporte ao protocolo POP3 ou IMAP, o que é o caso da maioria dos clientes
atuais.
A resolução DNS de um servidor SMTP de um dado domínio é possibilitada por sua
entrada MX (Mail eXchange).
Índice
 1 História
 2 Exemplo de uma sessão SMTP
 3 Segurança e spamming
 4 Ver também
História
A utilização em massa do SMTP remonta aos anos 1980. Na altura, era um

complemento ao UUCP, que era mais adequado para transferências de correio
eletrônico entre máquinas sem ligação permanente. Por outro lado, o desempenho do
SMTP aumenta se as máquinas envolvidas, emissor e receptor, se encontrarem ligadas
permanentemente.
O Sendmail foi um dos primeiros (se não o primeiro) agente de transporte de email a
implementar SMTP. Em 2001, havia, pelo menos, cerca de 50 programas que
implementavam SMTP como cliente (emissor) ou servidor (receptor). Outros servidores
SMTP muito conhecidos são: exim, Postfix, Qmail, Microsoft Exchange Server e o
Mail da Apple, disponível apenas para usuários do Mac OS ou do iOS para dispositivos
móveis da Apple.
Dada a especificação inicial, que contemplava apenas texto ASCII, este protocolo não é
ideal para a transferência de arquivos (também chamados de ficheiros). Alguns
standards foram desenvolvidos para permitir a transferência de ficheiros em formato
binário através de texto simples, como o caso do MIME. Hoje em dia, quase todos os
servidores SMTP suportam a extensão 8BITMIME.
Para testar um servidor SMTP, com relativa facilidade, pode-se utilizar o protocolo
Telnet.
Exemplo de uma sessão SMTP
Após o estabelecimento de uma conexão entre emissor (cliente) e receptor (servidor), o

exemplo seguinte ilustra uma sessão SMTP. Na conversação seguinte, "C:" designa as
mensagens do cliente, e "S:" as mensagens do servidor. Na maioria dos computadores,
uma conexão pode ser estabelecida usando o comando telnet no emissor, por exemplo:
C: MAIL FROM:<Smith@Alpha.ARPA>
S: 250 OK
C: RCPT TO:<Jones@Beta.ARPA>
S: 250 OK
C: RCPT TO:<Green@Beta.ARPA>
S: 550 No such user here
C: RCPT TO:<Brown@Beta.ARPA>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: <CRLF>.<CRLF>
S: 250 OK
Embora opcional, praticamente todos os clientes questionam o servidor sobre quais as

extensões SMTP que este suporta, utilizando o comando EHLO (em oposição ao HELO
ilustrado acima), e o corpo da mensagem (depois de DATA) segue tipicamente em
formato MIME.
Segurança e spamming
Uma das limitações da especificação SMTP inicial é que não existe método de
autenticação dos emissores. Como tal, foi-lhe adicionada a extensão SMTP-AUTH.
Apesar disso, o spamming continuava a ser um problema. Alterar o SMTP

extensivamente ou substituí-lo completamente não se torna prático, devido à forte
utilização do SMTP e aos efeitos que daí podiam advir. O Internet Mail 2000 é uma
proposta nesse sentido.
É por essa razão que existem várias propostas para protocolos alternativos que iriam
assistir a operação SMTP. O Grupo de Pesquisa Anti-Spam do Internet Research Task
Force encontra-se a estudar várias propostas para se suportar a autenticação do emissor
de uma forma flexível, leve e escalável. A proposta aparentemente mais sólida parece
ser o protocolo Sender Policy Framework.
Ver também
 Post Office Protocol

 Internet Message Access Protocol
Ligações externas
 RFC 2821 - The Simple Mail Transfer Protocol, que tornou obsoleto o RFC 821
 RFC 2822 - Internet (i.e. e-mail) Message Format, que tornou obsoleto o RFC 821
 RFC 1869 - Extensões do SMTP, originando o Extended SMTP
 RFC 1891 - Extensão ao SMTP para suportar Delivery Status Notification (DSN)
NIC.br. «CGI.br - Comitê Gestor da Internet no Brasil». CGI.br - Comitê Gestor da Internet no
Brasil. Consultado em 30 de agosto de 2015
Simple Network Management Protocol

Simple Network Management Protocol (SNMP), em português Protocolo Simples
de Gerência de Rede, é um "protocolo padrão da Internet para gerenciamento de
dispositivos em redes IP". Dispositivos que normalmente suportam SNMP incluem
roteadores, comutadores, servidores, estações de trabalho, impressoras, racks modernos
e etc. SNMP é usado na maioria das vezes em sistemas de gerenciamento de rede para
monitorar dispositivos ligados a rede para condições que garantem atenção
administrativa. SNMP é um componente do conjunto de protocolos da Internet como
definido pela Internet Engineering Task Force (IETF). Ele consiste de um conjunto de
padrões de gerenciamento de rede, incluindo um protocolo da camada de aplicação, um
esquema de banco de dados, e um conjunto de objetos de dados.
O software de gerência de redes não segue o modelo cliente-servidor convencional, pois

para as operações GET e SET, a estação de gerenciamento se comporta como cliente e o
dispositivo de rede a ser analisado ou monitorado se comporta como servidor, enquanto
que na operação TRAP ocorre o oposto, pois no envio de alarmes é o dispositivo
gerenciado que toma iniciativa da comunicação. Por conta disso, os sistemas de
gerência de redes evitam os termos 'cliente' e 'servidor' e optam por usar "gerente" para
a aplicação que roda na estação de gerenciamento e "agente" para a aplicação que roda
no dispositivo de rede.
Índice
 1 Gerência de redes
 2 Componentes Básicos do SNMP
 3 Arquitetura
o 3.1 Master Agent
o 3.2 Subagent
o 3.3 Management Station
 4 O SNMP e o ASN.1
 5 Comandos do SNMP
 6 Nomes de objetos e MIB
 7 Aspectos de segurança
 8 SNMPv2 e SNMPv3
Gerência de redes
O programa gerente da rede é a entidade responsável pelo monitoramento e controle dos

sistemas de hardware e software que compõem a rede, e o seu trabalho consiste em
detectar e corrigir problemas que causem ineficiência (ou impossibilidade) na
comunicação e eliminar as condições que poderão levar a que o problema volte a surgir.
A gerência de uma rede pode não ser simples, dada sua heterogeneidade em termos de
hardware e software, e de componentes da rede, por vezes incompatíveis. As falhas
intermitentes, se não forem detectadas, podem afetar o desempenho da rede. Um
software de gerência de redes permite ao gestor monitorar e controlar os componentes
da sua rede.
Componentes Básicos do SNMP
Uma rede gerida pelo protocolo SNMP é formada por três componentes chaves:
1. Dispositivos Geridos
2. Agentes
3. Sistema de Gerenciamento de Redes (NMS - Network-Management Systems)
Um Dispositivo Gerido é um nó de rede que possui um agente SNMP instalado e se

encontra numa rede gerida. Estes dispositivos coletam e armazenam informações de
gestão e mantém estas informações disponíveis para sistemas NMS através do protocolo
SNMP. Dispositivos geridos, também às vezes denominados de dispositivos de rede,
podem ser routers, servidores de acesso, impressoras, computadores, servidores de rede,
switches, dispositivos de armazenamento, dentre outros.
Um Agente é um módulo de software de gestão de rede que fica armazenado num

Dispositivo Gerido. Um agente tem o conhecimento das informações de gestão locais e
traduz estas informações para um formato compatível com o protocolo SNMP.
Um sistema NMS é responsável pelas aplicações que monitoram e controlam os

Dispositivos Geridos. Normalmente é instalado num (ou mais que um) servidor de rede
dedicado a estas operações de gestão, que recebe informações (pacotes SNMP) de todos
os dispositivos geridos daquela rede.
O protocolo SNMP opera na porta 161 por padrão. A porta 162 é denominada
SNMPTRAP. Um trap SNMP é usado para reportar uma notificação ou para outros
eventos assíncronos sobre o subsistema gerido.
Arquitetura
O framework SNMP consiste de: Agentes Mestres (Master Agents), Sub-agentes

(Subagents) e Estações de Gerenciamento (Management Stations).
Master Agent
O Master Agent em uma rede gerenciada é, na verdade, um software sendo executado

em um dispositivo com suporte a SNMP, por exemplo, um roteador, que interage com
uma estação de gerenciamento. É o equivalente a um servidor, na comunicação
cliente/servidor, ou a um daemon, sob o ponto de vista de sistemas operacionais. Os
subagentes são os responsáveis por passarem informações específicas para o Masters
Agent.
Subagent
Os subagentes ou subagents são pequenos programas em execução no dispositivo com

suporte a SNMP, responsáveis pelo monitoramento de recursos específicos naquele
dispositivo, como por exemplo, o status de um link ethernet em um roteador, ou a
quantidade de espaço livre em um disco de um servidor. Algumas características dos
softwares subagentes são:
 Coletar informações de objetos gerenciados

 Configurar parâmetros destes objetos gerenciados
 Responder a solicitações do software de gerência da rede
 Gerar alarmes ou traps em determinadas situações
Management Station
O Gerente da Rede ou Estação de Gerenciamento ou ainda Management Station é o

componente final da arquitetura de uma solução SNMP. Funciona como um cliente em
uma comunicação cliente/servidor. Realiza requisições de informações aos dispositivos
gerenciados, que podem ser temporárias ou através de comandos a qualquer tempo. E
ainda é o responsável por receber alarmes gerados pelos agentes e gerar saídas para
estes alarmes, tais como, alterar (SET) o valor de um determinado parâmetro gerenciado
no equipamento, enviar mensagem para o celular do administrador da rede, dentre
outras.
O SNMP e o ASN.1
O SNMP é um protocolo padrão usado para gerência de redes, que define os formatos
dos pedidos que o Gerente envia para o Agente e os formatos das respostas que o agente
retorna, assim como o significado exato de cada pedido e resposta. Uma mensagem
SNMP é codificada com um padrão designado de ASN.1 (do inglês: Abstract Syntax
Notation.1).
Para permitir a transferência de grandes pacotes, sem desperdiçar espaço em cada

transferência, o ASN.1 usa uma combinação de tamanho e valor para cada objeto a ser
transferido.
Comandos do SNMP
O SNMP não define um grande número de comandos, no lugar disso define duas
operações básicas:
 GET, para obter um valor de um dispositivo
 SET, para colocar um valor num dispositivo
O comando que especifica uma operação de GET ou SET deve especificar o nome do
objeto, que é único.
Podemos definir objetos. No caso de um contador de erros de CRC e uma vez que o
SNMP não inclui comandos específicos para fazer reset do contador, uma forma
simples é colocar zero no contador. Neste caso, o Gerente faz o GET (leitura) do
parâmetro desejado para determinar o estado do dispositivo. As operações que
controlam o dispositivo são definidas como efeitos secundários de SET (alterar/gravar
valores) em objetos.
Especifica (na versão 1) quatro pacotes de unidades de dados (PDU):
1. GET, usado para retirar um pedaço de informação de gerenciamento.

2. GETNEXT, usado interativamente para retirar sequências de informação de
gerenciamento.
3. GETBULK, usado para retirar informações de um grupo de objetos.
4. SET, usado para fazer uma mudança no subsistema gerido.
5. TRAP, usado para reportar uma notificação ou para outros eventos assíncronos sobre
o subsistema gerido.
Nomes de objetos e MIB
Todos os objetos acedidos pelo SNMP devem ter nomes únicos definidos e atribuídos.
Além disso, o Gerente e o Agente devem acordar os nomes e significados das operações
GET e SET. O conjunto de todos os objetos SNMP é coletivamente conhecido como
MIB (do inglês: Management Information Base). O standard SNMP não define o MIB,
mas apenas o formato e o tipo de codificação das mensagens. A especificação das
variáveis MIB, assim como o significado das operações GET e SET em cada variável,
são especificados por um padrão próprio.
A definição dos objetos do MIB é feita com o esquema de nomes do ASN.1, o qual
atribui a cada objeto um prefixo longo que garante a unicidade do nome, a cada nome é
atribuído um número inteiro. Também, o SNMP não especifica um conjunto de
variáveis, e como a definição de objetos é independente do protocolo de comunicação,
permite criar novos conjuntos de variáveis MIB, definidos como standards, para novos
dispositivos ou novos protocolos. Por isso, foram criados muitos conjuntos de variáveis
MIB que correspondem a protocolos como UDP, IP, ARP, assim como variáveis MIB
para hardware de rede como Ethernet ou FDDI, ou para dispositivos tais como bridges,
switches ou impressoras.
Aspectos de segurança
O SNMP, até a sua versão 2, não suportava qualquer tipo de autenticação, o que o
tornava vulnerável a uma série de ameaças de segurança. Tais ameaças incluíam o
acesso e modificação não autorizados de dados nas MIBs dos dispositivos gerenciados.
Essa vulnerabilidade do protocolo fez com que diversos fabricantes não
implementassem a operação Set, reduzindo o SNMP a uma ferramenta de monitoração
apenas.
SNMPv2 e SNMPv3
A versão 2 do SNMP é uma evolução do protocolo inicial. O SNMPv2 oferece uma boa
quantidade de melhoramentos em relação ao SNMPv1, incluindo operações adicionais
do protocolo, melhoria na performance, segurança, confidencialidade e comunicações
Gerente-para-Gerente. A SNMPV3 inclui implementação na segurança ao protocolo
como privacidade, autenticação e controle de acesso.
Na prática, as implementações do SNMP oferecem suporte para as múltiplas versões

(RFC 3584), tipicamente SNMPv1, SNMPv2c e SNMPv3.
Ligações externas
 Gerenciamento de Equipamentos Usando o Protocolo SNMP
Secure Shell

Secure Shell (SSH) é um protocolo de rede criptográfico para operação de serviços de

rede de forma segura sobre uma rede insegura.[1] A melhor aplicação de exemplo
conhecida é para login remoto a sistemas de computadores pelos usuários.
O SSH fornece um canal seguro sobre uma rede insegura em uma arquitetura cliente-
servidor, conectando uma aplicação cliente SSH com um servidor SSH.[2] Aplicações
comuns incluem login em linha de comando remoto e execução remota de comandos,
mas qualquer serviço de rede pode ser protegido com SSH. A especificação do
protocolo distingue entre duas versões maiores, referidas como SSH-1 e SSH-2.
A aplicação mais visível do protocolo é para acesso a contas shell em sistemas

operacionais do tipo Unix, mas também verifica-se algum uso limitado no Windows.
Em 2015, a Microsoft anunciou que incluiriam suporte nativo para SSH em uma
liberação futura.[3]
O SSH foi projetado como um substituto para o Telnet e para protocolos de shell
remotos inseguros como os protocolos Berkeley rlogin, rsh e rexec. Estes protocolos
enviam informações, notavelmente senhas, em texto puro, tornando-os suscetíveis à
interceptação e divulgação usando análise de pacotes.[4] A criptografia usada pelo SSH
objetiva fornecer confidencialidade e integridade de dados sobre uma rede insegura,
como a Internet, apesar dos arquivos vazados por Edward Snowden indicarem que a
Agência de Segurança Nacional pode algumas vezes descriptografar o SSH, permitindo-
os ler o conteúdo de sessões SSH.[5]
Índice
 1 Definição
 2 Gerenciamento de chaves
 3 Uso
 4 Referências
 5 Ver também
Definição
O SSH usa criptografia de chave pública para autenticar o computador remoto e e

permiti-lo autenticar o usuário, se necessário.[2] Há várias maneiras de usar o SSH, uma
é usar pares de chave pública-privada geradas automaticamente para simplesmente
encriptar uma conexão de rede e então usar autenticação por senha para logar.
Outra maneira é usar um par de chaves pública-privada geradas manualmente para

realizar a autenticação, permitindo que usuários ou programas loguem sem ter que
especificar uma senha. Neste cenário, qualquer um pode produzir um par
correspondente de chaves diferentes (pública e privada). A chave pública é colocada em
todos os computadores que devem permitir o acesso ao proprietário da chave privada
correspondente (o proprietário mantem o segredo da chave privada). Uma vez que a
autenticação é baseada na chave privada, a chave em si nunca é transferida por meio da
rede durante a autenticação. O SSH apenas verifica se a mesma pessoa que oferece a
chave pública também possui a chave privada correspondente. Em todas as versões do
SSH é importante verificar chaves públicas desconhecidas, isto é, associar as chaves
públicas com as identidades, antes de aceitá-las como válidas. Aceitar a chave pública
de um atacante sem validação autorizará o atacante como um usuário válido.
Gerenciamento de chaves
Em sistemas do tipo Unix, a lista de chaves públicas autorizadas é normalmente

armazenada no diretório home do usuário que está permitido logar remotamente, no
arquivo ~/.ssh/authorized_keys.[6] Este arquivo é considerado pelo SSH apenas se
ele não puder ser alterado por nada além do proprietário e do root. Quando a chave
pública está presente no terminal remoto e a chave privada correspondente está presente
no terminal local, a digitação da senha não é mais necessária (alguns softwares como a
pilha Message Passing Interface (MPI) pode precisar deste acesso sem senha para rodar
adequadamente). Entretanto, para segurança adicional a chave privada em si pode ser
bloqueada com uma senha.
A chave privada também pode ser procurada em locais padrões e seu caminho completo
pode ser especificado como uma definição de linha de comando (a opção -i para ssh). O
utilitário ssh-keygen produz as chaves pública e privada, sempre em pares.
O SSH também suporta autenticação baseada em senha que é criptografada por chaves
geradas automaticamente. Neste caso o atacante pode imitar o lado servidor legítimo,
solicitar a senha e obtê-la (ataque homem-no-meio). Entretanto, isto é possível apenas
se os dois lado nunca tiverem se autenticado antes, uma vez que o SSH lembra a chave
que o lado servidor usou anteriormente. O cliente SSH lança um aviso antes de aceitar a
chave de um novo servidor desconhecido previamente. A autenticação por senha pode
ser desabilitada.
Uso
O SSH é normalmente usado para login em uma máquina remota e execução de

comandos, mas também suporta tunelamento, redirecionamento de portas TCP e
conexões X11. Ele pode transferir arquivos usando os protocolos SSH file transfer
(SFTP) ou secure copy (SCP).[2] O SSH utiliza o modelo cliente-servidor.
A porta TCP padrão 22 tem sido usada para contatar servidores SSH.[7]
Referências
1.
 Network Working Group of the IETF, January 2006, RFC 4251, The Secure Shell (SSH)
Protocol Architecture
  Network Working Group of the IETF, January 2006, RFC 4252, The Secure Shell (SSH)
Authentication Protocol
  Peter Bright (June 2, 2015). «Microsoft bringing SSH to Windows and PowerShell». Ars
Technica Verifique data em: |data= (ajuda)
  SSH Hardens the Secure Shell, Serverwatch.com
  «Prying Eyes: Inside the NSA's War on Internet Security». Spiegel Online. December 28,
2014 Verifique data em: |data= (ajuda)
  SSH setup manual
7.  «Service Name and Transport Protocol Port Number Registry». iana.org
Ver também
 OpenSSH
Ligações externas
 OpenSSH (em inglês)

 SSH (em inglês)
 PUTTY (em inglês) Cliente SSH para Windows.
 WinSCP Cliente SFTP para Windows. (em inglês)
 Fugu SSH (em inglês) Cliente SSH para OSX.
 Web Cliente SSH para Internet. (em inglês)
Telnet
Telnet é um protocolo de rede utilizado na Internet ou redes locais para proporcionar
uma facilidade de comunicação baseada em texto interativo bidirecional usando uma
conexão de terminal virtual. Os dados do usuário são intercalados em banda com
informações de controle Telnet em um byte de conexão 8-bit de dados orientado sobre o
Transmission Control Protocol (TCP).
O Telnet foi desenvolvido em 1969 com a chegada do RFC 15, prorrogado no RFC 854,
e padronizado como Internet Engineering Task Force (IETF) Internet STD Padrão 8,
um dos primeiros padrões da Internet.
Índice
 1 Definição
 2 Conceitos fundamentais
o 2.1 Terminal virtual
o 2.2 Opções negociadas
o 2.3 Regras de negociação
 3 Especificações
Definição
O protocolo Telnet é um protocolo standard de Internet que permite a interface de

terminais e de aplicações através da Internet. Este protocolo fornece as regras básicas
para permitir ligar um cliente (sistema composto de uma afixação e um teclado) a um
intérprete de comando (do lado do servidor).
O Telnet existe há mais de 40 anos, muito antes de aparecer a Internet. Este sistema de
transmissão de dados foi inventado pelas Forças Armadas Americanas para transmissão
de dados entre bases militares. Foi disponibilizado ao público em 1977, tendo sido os
radioamadores os primeiros a aproveitá-lo.
Portanto, pode-se dizer que a Internet trabalha por cima do Telnet, servindo-se do seu
sistema para funcionar. A transmissão de dados pelo Telnet utiliza software específico
que os codifica, permitindo utilizar centenas de portas por nós definidas e reencaminha-
las, para o PC que pretendemos. Se tivermos uma rede interna com vários pc's
instalados, utilizando um router, abrimos uma porta para cada PC e, com o mesmo IP,
os dados fluem direccionados e reencaminhados simultaneamente, sem qualquer
problema. O utilizador que recebe dados combina com o seu correspondente a porta de
passagem para o sistema funcionar. A máquina que envia os dados fá-lo em pacotes.
Informa o correspondente que tem dados. Este, por sua vez, dá o OK para a transmissão.
O pacote é enviado com a informação do número de bits que este tem. Só depois do
correspondente ter informado que recebeu os bits todos, é que pede o segundo pacote.
Se por qualquer motivo informa que os bits não chegaram todos, o envio do pacote é
repetido. Muita coisa fica ainda por dizer sobre este sistema. O protocolo baseia-se
numa conexão TCP para enviar dados em formato ASCII codificado em 8 bits entre os
quais se intercalam sequências de controle para o Telnet. Fornece assim um sistema
orientado para a comunicação, bidireccional (half-duplex), codificado em 8 bits fácil de
aplicar. Com essa conexão é possível o acesso remoto para qualquer máquina ou
equipamento que esteja sendo executado em modo servidor.
Conceitos fundamentais
O protocolo Telnet assenta em três conceitos fundamentais que serão explicados a

seguir:
O paradigma do terminal rede virtual (NVT, Network Virtual Terminal); O princípio de

opções negociadas; As regras de negociação.
Terminal virtual
O Telnet consiste em criar abstrações no terminal, fazendo com que qualquer cliente ou
servidor se comunique com outro host sem conhecer as suas características.
A comunicação de NVT, comumente chamada de Terminal Rede Virtual, fornece uma

base padrão de:
 Caracteres de 7 bits ASCII

 Três caracteres de controle
 Cinco caracteres de controle opcionais
 Um jogo de sinais de controle básico
Opções negociadas
As opções negociadas permitem que alguns terminais proponham serviços adicionais

que não são definidos nas especificações básicas. Esses serviços adicionais permitem a
utilização de funções avançadas em forma de opções, fazendo iniciar os pedidos para
solicitar a autorização ao sistema distante a ativação desse serviço ou não. Qualquer um
dos lados da rede pode emitir o sinal e logo em seguida a outra deve responder se aceita
ou não a liberação da opção requerida. Caso o pedido seja para desativar a opção, quem
recebe a mensagem não deve recusar a mensagem, para ser compatível com o modelo
NVT.
Regras de negociação
As regras de negociação de opções podem evitar um caso de bloqueio do pedido, pois

os pedidos só devem ser emitidos quando acontece a mudança de um modo. Caso exista
um envio para mudança esse deve ser inserido no fluxo de dados apenas no lugar onde
tem efeito, o receptor da mensagem só deve adotá-lo quando não se encontrar no
mesmo modo pedido.
Especificações
Este protocolo é um protocolo básico, no qual se apoiam outros protocolos da sequência

TCP/IP (FTP, SMTP, POP3,…). As especificações de Telnet não mencionam
autenticação porque o Telnet está totalmente separado das aplicações que o utilizam (o
protocolo FTP define uma sequência de autenticação acima do Telnet). Além disso, o
protocolo Telnet é um protocolo de transferência de dados não seguro, o que quer dizer
que os dados que veicula circulam às claras na rede (de maneira não codificada).
Quando o protocolo Telnet é utilizado para ligar um hóspede distante à máquina na qual
é aplicado como servidor, este protocolo é atribuído à porta 23.
Se fizermos uma exceção às opções e às regras de negociação associadas, as

especificações do protocolo Telnet são básicas. A transmissão de dados através de
Telnet consiste unicamente em transmitir bytes no fluxo TCP (o protocolo Telnet
precisa que os dados devem, por default - isto é, se nenhuma opção precisar o contrário
- ser agrupados num tampão antes de serem enviados. Mais concretamente, isto
significa que por default os dados são enviados linha por linha). Quando o byte 255 é
transmitido, o próximo deve ser interpretado como um comando. O byte 255 é assim
nomeado IAC (Interpret As Command, traduza-se "interpretar como um comando"). Os
comandos são descritos posteriormente.
As especificações básicas do protocolo Telnet estão disponíveis no RFC 854, enquanto

as numerosas opções são descritas nos RFC 855 a 861.
Ligações externas
 Lista de servidores telnet
 RFCs relacionadas:
RFC 854
TELNET protocol specification
RFC 855
TELNET option specifications
RFC 856
TELNET binary transmission
RFC 857
TELNET echo option
RFC 858
TELNET suppress Go Ahead option
RFC 859
TELNET status option
RFC 860
TELNET timing mark option
RFC 861
TELNET extended options - list option
RFC 885
Telnet end of record option
RFC 1041
Telnet 3270 regime option
RFC 1073
Telnet Window Size Option
RFC 1079
Telnet terminal speed option
RFC 1091
Telnet terminal-type option
RFC 1096
Telnet X display location option
RFC 1097
Telnet subliminal-message option
RFC 1116
Telnet linemode option
RFC 1205
5250 Telnet interface
RFC 1372
Telnet remote flow control option
RFC 2217
Telnet Com Port Control Option

RFC 2941
Telnet Authentication Option
RFC 2942
Telnet Authentication: Kerberos Version 5
RFC 2943
TELNET Authentication Using DSA
RFC 2944
Telnet Authentication: SRP
RFC 2946
Telnet Data Encryption Option
RFC 4248
The telnet URI Scheme
RFC 4777
IBM's iSeries Telnet Enhancements
Transport Layer Security

O Transport Layer Security (TLS),[nota 1] assim como o seu antecessor Secure Sockets
Layer (SSL),[nota 2] é um protocolo de segurança — desenvolvido por Tim Dierks e Eric
Rescorla do IETF TLS Working Group — que protege as telecomunicações via internet
para serviços como e-mail (SMTP), navegação por páginas (HTTPS) e outros tipos de
transferência de dados. Em 2017 Tim Dierks trabalhava na Google , e Eric Rescorla na
Mozilla [1] e RTFM.Inc [2]
Existem algumas pequenas diferenças entre o SSL 3.0 e o TLS 1.0, mas o protocolo
permanece substancialmente o mesmo. O termo "SSL" aqui usado aplica-se a ambos os
protocolos, exceto se disposto em contrário. O protocolo SSL 3.0 também é conhecido
como SSL3 e o TLS 1.0 como TLS1 ou ainda SSL3.1.
Índice
 1 Descrição
 2 Funcionamento
 3 História e desenvolvimento
 4 Notas
 5 Ver também
 6 Referências
Descrição
O protocolo SSL provê a privacidade e a integridade de dados entre duas aplicações que
comuniquem pela internet. Isso ocorre por intermédio da autenticação das partes
envolvidas e da cifragem dos dados transmitidos entre as partes. Ainda, esse protocolo
ajuda a prevenir que intermediários entre as duas extremidades das comunicações
obtenham acesso indevido ou falsifiquem os dados que estão sendo transmitidos.
Protocolo TLS
Funcionamento
O servidor do site que está sendo acessado envia uma chave pública ao browser, usada
por este para enviar uma chamada secreta, criada aleatoriamente. Desta forma, fica
estabelecida a troca de dados criptografados entre dois computadores.
Baseia-se no protocolo TCP da suíte TCP/IP e utiliza-se do conceito introduzido por

Diffie-Hellman nos anos 70 (criptografia de chave pública) e Phil Zimmermann (criador
do conceito PGP).
História e desenvolvimento
A primeira versão foi desenvolvida pela Netscape em 1994. O SSL versão 3.0 foi
lançado em 1996, e serviu posteriormente de base para o desenvolvimento do TLS
versão 1.0, um protocolo padronizado da IETF originalmente definido pelo RFC 2246.
Grandes instituições financeiras como Visa, MasterCard, American Express, dentre
outras, aprovaram o SSL para comércio eletrônico seguro na Internet.
O SSL opera de forma modular, possui design extensível e apresenta compatibilidade

entre pares com versões diferentes do mesmo.
O SSL executa a autenticação das 2 partes envolvidas nas comunicações (cliente e

servidor) baseando-se em certificados digitais.
Notas
1.
 Em português: Segurança da Camada de Transporte.

2.  Em português: Protocolo de Camada Segura de Soquetes.
Ver também
 PGP
 OpenPGP
 GnuPG
 Certificado EV SSL
Referências
1.
 «Mozzila page of Eric Rescorla»
2.  «RTFM inc»
Ligações externas
 The TLS Protocol, Version 1.0 (em inglês). RFC 2246 (descrição do protocolo TLS 1.0).
Visitado em 15 de outubro de 2014.
 TLS The Transport Layer Security (TLS) Protocol Version 1.2 (RFC)
 The Transport Layer Security (TLS) Protocol Version 1.1 (RFC)
 Especificação Original
 Biblioteca aberta que implementa SSL
 Transport Layer Security (TLS) e Secure Sockets Layer (SSL)
Extensible Messaging and Presence Protocol

Extensible Messaging and Presence Protocol (XMPP) (conhecido anteriormente
como Jabber[1]) é um protocolo aberto, extensível, baseado em XML, para sistemas de
mensagens instantâneas, desenvolvido originalmente para mensagens instantâneas e
informação de presença formalizado pelo IETF. Softwares com base XMPP são
distribuídos em milhares de servidores através da internet, e usados por cerca de dez
milhões de pessoas em todo mundo, de acordo com a XMPP Standards Foundation[2].
Índice
 1 Introdução
 2 Clientes XMPP
o 2.1 XMPP apenas
o 2.2 Multi-protocolo, com suporte XMPP
o 2.3 Servidor Multi-protocolo, com suporte XMPP
 3 Exemplo de comunicação cliente-servidor usando o protocolo XMPP
 4 Referências
Introdução
Jeremie Miller iniciou o projecto Jabber em 1998; a principal versão pública ocorreu em
Maio de 2000. O produto principal do projecto é o jabberd, um servidor em que os
clientes XMPP se ligam para comunicar. Este servidor pode criar uma rede privada
XMPP (por detrás de um firewall, por exemplo) ou pode se juntar à rede XMPP global e
pública. o XMPP surgiu como alternativa aos protocolos fechados de comunicação
predominantemente utilizados em aplicações com ICQ, MSN Messenger, etc. Por ser
um protocolo aberto, o desenvolvimento de aplicações que fazem uso do mesmo pode
ser feito sem a necessidade de permissões especiais ou pagamento de royalties.
Um conceito chave do sistema XMPP são os transportes, também conhecido como

gateways, que permite aos utilizadores acederem a redes usando outros protocolos - tais
como o AIM, o ICQ (usando o OSCAR), MSN Messenger e Windows Messenger
(usando o .NET Messenger Service), SMS ou E-mail. Ao contrário dos clientes de
multiprotocolo, como o Trillian ou Pidgin, XMPP fornece este acesso no nível de
servidor comunicando via serviços especiais de gateway em um computador remoto.
Qualquer utilizador XMPP pode se registrar com uma destas gateways fornecendo a
informação necessária para aceder a essa rede, e pode então comunicar-se com os
utilizadores dessa rede como se fossem utilizadores de XMPP. Isto significa que
qualquer cliente que suportar inteiramente o protocolo XMPP pode ser usado para
aceder a qualquer rede em que exista uma gateway, sem necessitar de código extra no
cliente.
Por ser um padrão aberto, o XMPP favorece a interoperabilidade. Usuários podem

escolher a aplicação que mais lhe convém desde que ela compreenda o protocolo.
Existem diversas aplicações que usam XMPP como Pidgin, Miranda, Kopete, Adium,
etc.
Jabber, agora administrado pela XMPP Standards Foundation (conhecido anteriormente

como Jabber Software Foundation), foram aceitas pela IETF como padrão sob o nome
XMPP, com RFC número 3920. É frequentemente considerado como estando na
competição com o SIMPLE, baseado no protocolo do SIP, como protocolo padrão da
notificação de presença e de instant messaging; no entanto, o design do XMPP tem por
finalidade fornecer uma plataforma de interface mais geral entre aplicações.
Em agosto de 2005, a empresa Google lançou o Google Talk, baseado em XMPP, o que
ajudou a popularizar o protocolo, em função da grande quantidade de usuários deste
produto. Mais tarde o protocolo continuou sendo usado nos outros serviços de
comunicação da empresa, mais precisamente, os serviços de comunicação instantânea
embutidos no Gmail e Orkut.
Clientes XMPP
XMPP apenas
Nome Plataforma Licença
Akeni Jabber Client Multi-plataforma Proprietária, gratuito para uso não-comercial
Coccinella Multi-plataforma GPL

Exodus Windows GPL
Gabber Linux/Unix, Gnome GPL
Google Talk Windows Proprietária, gratuito
Gossip Linux/Unix, Gnome GPL
Jabbear Web and desktop Messenger Windows, Web Proprietária
Jabber Instant Messenger Windows Proprietária
JabberFox Mac OS X BSD
Jabbin Linux/Windows GPL
JAJC Windows Proprietária
JBother Java GPL
Jeti Java GPL
Nitro Mac OS X GPL
Pandion Windows GPL
Psi Multi-plataforma GPL
Tkabber Multi-plataforma GPL
Gajim Multi-plataforma GPL
Multi-protocolo, com suporte XMPP

Adium Mac OS X GPL
Bitlbee via IRC Multi-plataforma Freeware
Centericq Multi-plataforma GPL
Empathy Linux/Unix, Gnome GPL
Fire Mac OS X GPL
Jitsi Multi-plataforma Windows, Mac OSX, Linux e outros) LGPL
Pidgin Multi-plataforma GPL
Gush ? Creative Commons

Kopete Linux/Unix GPL
Miranda IM Windows GPL
Trillian ? Proprietária
SIM Multi-plataforma GPL
Spark Multi-plataforma GPL
Servidor Multi-protocolo, com suporte XMPP

DJabberd Multi-plataforma GPL
ejabberd Multi-plataforma GPL
iChat Server Mac OS X GPL
jabberd14 Multi-plataforma GPL
jabberd2 Multi-plataforma GPL
Openfire Multi-plataforma Apache License
Prosody Multi-plataforma MIT
psyced Multi-plataforma GPL
Tigase Multi-plataforma GPL
Exemplo de comunicação cliente-servidor usando o protocolo XMPP
Um cliente (kuusipuu) se liga a um servidor XMPP (amessage.de porta 5222/tcp), envia

uma mensagem (Assunto: "teste 1449" e Corpo: "teste 1449") a um outro cliente (tero) e
se desliga.
kuusipuu:
<?xml version="1.0"?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams"
xmlns="jabber:client" to="amessage.de">
amessage.de:
<stream:stream xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' from='amessage.de'
id='1461777714'>
kuusipuu:
<iq type="set" id="auth_2" to="amessage.de" >

<query xmlns="jabber:iq:auth">
<username>kuusipuu</username>
<password>mypassword</password>
<resource>Work</resource>
</query>
</iq>
amessage.de:
<iq from="amessage.de" id='auth_2' type='result'/>
kuusipuu:
<message to="tero@exemplo.com" >

<subject>teste 1449</subject>
<body>teste 1449</body>
</message>
<presence type="unavailable" >
<status>Logged out</status>
</presence>
</stream:stream>
amessage.de:
</stream:stream>
Referências
1.
 Jabber Inc. - About Us
2.  Fast-Growing Open Network Overtakes IM Originator
Ligações externas
 XMPP Standards Foundation (inglês)

 Lista de servidores XMPP públicos (inglês)
[Esconder]
v • e
Mensageiros instantâneos
Protocolos Abertos  IMPP
 IRC
 MTProto
 RetroShare
 SIP
o MSRP
o SIMPLE
 TextSecure
 Tox
 XMPP
o Jingle
o WFP
 Zephyr
 MSNP
 OSCAR
Fechados o TOC_(protocolo)
 Skype
 YMSG
Serviços  AOL Instant Messenger

 BAND
 BlackBerry Messenger
 Facebook Messenger
 Google Hangouts
 Google Talk
 GroupMe
 Hike Messenger
 ICQ
 iMessage
 indoona
 IRC Networks
 KakaoTalk
 Kik
 Libon
 Line
 Microsoft Messenger service
 MyPush
 Nimbuzz
 ooVoo
 Palringo
 Signal
 Skype
 Skype Qik
 Snapchat
 Tango
 Telegram
 QQ
 TextSecure
 Threema
 Tox
 Upptalk
 Viber
 WeChat
 WhatsApp
 Windows Messenger service
 Yahoo! Messenger
Clientes  AIM
 Baidu Hi
 BlackBerry Messenger
 CSipSimple
 Facebook Messenger
 FaceTime
 Fetion
 Gadu-Gadu
 GroupMe
 IBM Sametime
 ICQ
 IMVU
 indoona
Protocolo  Linphone
único  MyPush
 Palringo
 Qnext
 RetroShare
 SFLphone
 Signal
 Skype
 Telegram
 QQ
 TextSecure
 Tox
 WeChat
 WhatsApp
 Yahoo! Messenger
Multi-  Adium
protocolo  Ayttm
 BitlBee
 Centericq
 eBuddy
 Empathy
 Fire
 Gizmo5
 Instantbird
 Jitsi
 Kopete
 Messages/iChat
 Microsoft Lync
 Miranda IM
 Nimbuzz
 Pidgin
 QIP 2010
 Trillian
 UOL Messenger
 Upptalk
 Xfire
 Bombus
 Facebook Chat
XMPP  Gajim
(Jabber)  Google Talk
 Psi
 Tkabber
 aMSN
 emesene
 Windows Messenger
MSNP
 Microsoft Messenger
 MSN Messenger
 Windows Live Messenger
 Backchannel
 Buddy profile
 Chat log
 Chatterbot
 Contact list
 Emoticon
 Compartilhamento de arquivos
 IM bot
 Instant message service center
 LAN messenger
Ver também  Mobile instant messaging
 Presence information
 Shoutbox
 SMS language
 Status message
 Videoconferência
 Videofone
 Voz sobre IP (VOIP)
 Webcam
 Web chat
Camada de transporte
Transmission Control Protocol
O TCP (acrônimo para o inglês Transmission Control Protocol, que significa
"Protocolo de Controle de Transmissão") é um dos protocolos sob os quais assenta a
Internet. Ele é complementado pelo Protocolo da Internet, sendo normalmente chamado
de TCP/IP. A versatilidade e robustez do TCP tornou-o adequado a redes globais, já que
este verifica se os dados são enviados de forma correta, na sequência apropriada e sem
erros, pela rede.
O TCP é um protocolo de nível da camada de transporte (camada 4) do Modelo [1]OSI e

é sobre o qual que se assentam a maioria das aplicações cibernéticas, como o SSH, FTP,
HTTP — portanto, a World Wide Web[2]. O Protocolo de controle de transmissão provê
confiabilidade, entrega na sequência correta e verificação de erros dos pacotes de dados,
entre os diferentes nós da rede, para a camada de aplicação.
Aplicações que não requerem um serviço de confiabilidade de entrega de pacotes

podem se utilizar de protocolos mais simples como o User Datagram Protocol (UDP),
que provê um serviço que enfatiza a redução de latência da conexão.
Índice
 1 Origem histórica
 2 Características técnicas
 3 Funcionamento do protocolo
o 3.1 Estabelecimento da conexão
o 3.2 Transferência de dados (sessão)
o 3.3 Adequação de parâmetros
o 3.4 Término da ligação
 4 Portas ou serviços
 5 Utilização do IP para entrega de dados
 6 Referências
 7 Ver também
Origem histórica
Em maio de 1974, o Instituto de Engenheiros Eletricistas e Eletrônicos publicou um

artigo intitulado "A Protocol for Packet Network Interconnection."[2] Os autores do
artigo, Vinton G. Cerf e Robert Kahn descreveram um protocolo de interconexão para
compartilhamento de recursos usando comutação de pacotes ao longo dos nós. Um
componente central de controle deste modelo foi o Transmission Control Program, que
incorporou os elos e serviços orientados para datagrama entre hosts. O programa de
controle de transmissão monolítico foi dividido depois dentro de uma arquitetura
modular formada de um Protocolo de controle de transmissão na camada orientada a
conexão e o Protocolo de internet na camada de interconexão. O modelo se torna
informalmente conhecido como TCP/IP, embora formalmente tenha sido chamado de
Internet Protocol Suite.
Características técnicas
Cabeçalho de uma trama TCP
+ Bits 0 - 3 4-9 10 - 15 16 - 31
0 Porta na origem Porta no destino
32 Número de sequência
64 Número de confirmação (ACK)
Reservado Janela
96 Offset Flags
s Window
128 Checksum Ponteiro de urgência
160 Opções (opcional)
Padding (até 32)

224 Dados

Detalhe do campo Flags
+ 10 11 12 13 14 15
96 UrgPt AC Pus RST SYN FIN

r K h
As características fundamentais do TCP são:
 Orientado à conexão - A aplicação envia um pedido de conexão para o destino e usa a

"conexão" para transferir dados. Portanto, se faz necessário o estabelecimento de
uma conexão, por meio de uma sequência de passos definida no protocolo para que os
dois pontos da conexão possam interagir entre si.
 Handshake - Mecanismo de estabelecimento e finalização de conexão a três e quatro
tempos, respectivamente, o que permite a autenticação e encerramento de uma
sessão completa. O TCP garante que, no final da conexão, todos os pacotes foram bem
recebidos.
 Ponto a ponto - uma conexão TCP é estabelecida entre dois pontos. A princípio,
pacotes de broadcasting parecem violar esse princípio, mas o que ocorre é que é
enviado um pacote com um endereço especial em seu cabeçalho que qualquer
computador em sua rede pode responder a esse pacote, mesmo que não esteja
explicitamente endereçado pra ele.
 Confiabilidade - O TCP usa várias técnicas para proporcionar uma entrega confiável dos
pacotes de dados que, dependendo da aplicação, gera uma grande vantagem que tem
em relação ao UDP. Aliado a outros fatores, o protocolo se mantém bastante
difundido nas redes de computadores. O TCP permite a recuperação de pacotes
perdidos, a eliminação de pacotes duplicados, a recuperação de dados corrompidos e
pode recuperar a ligação em caso de problemas no sistema e na rede.
 Full duplex - É possível a transferência simultânea em ambas direções (cliente-servidor)
durante toda a sessão. Apesar disso, em alguns momentos, o protocolo necessita que
algum pacotes de dados cheguem para que se dê o envio de outros, o que limita as
transmissões.
 Entrega ordenada - A aplicação faz a entrega ao TCP de blocos de dados com um
tamanho arbitrário num fluxo (ou stream) de dados, tipicamente em octetos. O TCP
parte estes dados em segmentos de tamanho especificado pelo valor MTU. Porém, a
circulação dos pacotes ao longo da rede (utilizando um protocolo de
encaminhamento, na camada inferior, como o IP) pode fazer com que os pacotes não
cheguem ordenados. O TCP garante a reconstrução do stream no destinatário
mediante os números de sequência.
 Controle de fluxo - O TCP usa o campo janela ou window para controlar o fluxo. O
receptor, à medida que recebe os dados, envia mensagens ACK (=Acknowledgement),
confirmando a recepção de um segmento; como funcionalidade extra, estas
mensagens podem especificar o tamanho máximo do buffer no campo (janela) do
segmento TCP, determinando a quantidade máxima de bytes aceita pelo receptor. O
transmissor pode transmitir segmentos com um número de bytes que deverá estar
confinado ao tamanho da janela permitido: o menor valor entre sua capacidade de
envio e a capacidade informada pelo receptor.
 Controle de congestionamento - Baseado no número de mensagens de
reconhecimentos ACK (=Acknowledgement) recebidos pelo remetente por unidade de
tempo calculada com os dados do tempo de ida e de volta, ou em inglês RTT (Round
Trip Travel), o protocolo prediz o quanto a rede está congestionada e diminui sua taxa
de transmissão de modo que o núcleo da rede não se sobrecarregue. Esse tipo de
comportamento, a princípio ineficiente, se baseia fortemente na teoria dos jogos -
especificamente em jogos simétricos que, dentre várias coisas, difunde a ideia de que
se ninguém recua um pouco, para dar passagem aos demais, todos perdem.
Funcionamento do protocolo
Fig. 1 - Neste exemplo considera-se o backlog preenchido para forçar o timeout no cliente para
que o pacote SYN seja reenviado. No entanto, o primeiro pacote podia ter-se perdido devido a
erros na rede.
O protocolo TCP especifica três fases durante uma conexão: estabelecimento da ligação,
transferência e término de ligação. O estabelecimento da ligação é feito em três passos,
enquanto que o término é feito em quatro. Durante a inicialização são inicializados
alguns parâmetros, como o Sequence Number (número de sequência) para garantir a
entrega ordenada e robustez durante a transferência.
Estabelecimento da conexão
Para estabelecer uma conexão, o TCP usa um handshake (aperto de mão) de três vias.
Antes que o cliente tente se conectar com o servidor, o servidor deve primeiro ligar e
escutar a sua própria porta, para só depois abri-la para conexões: isto é chamado de
abertura passiva. Uma vez que a abertura passiva esteja estabelecida, um cliente pode
iniciar uma abertura ativa. Para estabelecer uma conexão, o aperto de mão de três vias
(ou 3 etapas) é realizado:
1. SYN: A abertura ativa é realizada por meio do envio de um SYN pelo cliente ao
servidor. O cliente define o número de sequência de segmento como um valor
aleatório A.
2. SYN-ACK: Em resposta, o servidor responde com um SYN-ACK. O número de
reconhecimento (acknowledgment) é definido como sendo um a mais que o número
de sequência recebido, i.e. A+1, e o número de sequência que o servidor escolhe para
o pacote é outro número aleatório B.
3. ACK: Finalmente, o cliente envia um ACK de volta ao servidor. O número de sequência
é definido ao valor de reconhecimento recebido, i.e. A+1, e o número de
reconhecimento é definido como um a mais que o número de sequência recebido, i.e
B+1.
Neste ponto, o cliente e o servidor receberam um reconhecimento de conexão. As etapas
1 e 2 estabelecem o parâmetro (número de sequência) de conexão para uma direção e
ele é reconhecido. As etapas 2 e 3 estabelecem o parâmetro de conexão (número de
sequência) para a outra direção e ele é reconhecido. Com isto, uma comunicação full-
duplex é estabelecida.
Tipicamente, numa ligação TCP existe aquele designado de servidor (que abre um
socket e espera passivamente por ligações) num extremo, e o cliente no outro. O cliente
inicia a ligação enviando um pacote TCP com a flag SYN activa e espera-se que o
servidor aceite a ligação enviando um pacote SYN+ACK. Se, durante um determinado
espaço de tempo, esse pacote não for recebido ocorre um timeout e o pacote SYN é
reenviado. O estabelecimento da ligação é concluído por parte do cliente, confirmando a
aceitação do servidor respondendo-lhe com um pacote ACK.
Durante estas trocas, são trocados números de sequência iniciais (ISN) entre os
interlocutores que irão servir para identificar os dados ao longo do fluxo, bem como
servir de contador de bytes transmitidos durante a fase de transferência de dados
(sessão).
No final desta fase, o servidor inscreve o cliente como uma ligação estabelecida numa
tabela própria que contém um limite de conexões, o backlog. No caso do backlog ficar
completamente preenchido a ligação é rejeitada ignorando (silenciosamente) todos os
subsequentes pacotes SYN.
Transferência de dados (sessão)
Durante a fase de transferência o TCP está equipado com vários mecanismos que
asseguram a confiabilidade e robustez: números de sequência que garantem a entrega
ordenada, código detector de erros (checksum) para detecção de falhas em segmentos
específicos, confirmação de recepção e temporizadores que permitem o ajuste e
contorno de eventuais atrasos e perdas de segmentos.
Como se pode observar pelo cabeçalho TCP, existem permanentemente um par de

números de sequência, doravante referidos como número de sequência e número de
confirmação (ACKnowledgement). O emissor determina o seu próprio número de
sequência e o receptor confirma o segmento usando como número ACK o número de
sequência do emissor. Para manter a confiabilidade, o receptor confirma os segmentos
indicando que recebeu um determinado número de bytes contíguos. Uma das melhorias
introduzidas no TCP foi a possibilidade do receptor confirmar blocos fora da ordem
esperada. Esta característica designa-se por selective ACK, ou apenas SACK.
A remontagem ordenada dos segmentos é feita usando os números de sequência, de 32

bit, que reiniciam a zero quando ultrapassam o valor máximo, 231-1, tomando o valor da
diferença. Assim, a escolha do ISN torna-se vital para a robustez deste protocolo.
O campo checksum permite assegurar a integridade do segmento. Este campo é

expresso em complemento para um consistindo na soma dos valores (em complemento
para um) da trama. A escolha da operação de soma em complemento para um deve-se
ao fato de esta poder ser calculada da mesma forma para múltiplos desse comprimento -
16 bit, 32 bit, 64 bit, etc - e o resultado, quando encapsulado, será o mesmo. A
verificação deste campo por parte do receptor é feita com a recomputação da soma em
complemento para um que dará -0 caso o pacote tenha sido recebido intacto.
Esta técnica (checksum), embora muito inferior a outros métodos detectores, como o
CRC, é parcialmente compensada com a aplicação do CRC ou outros testes de
integridade melhores ao nível da camada 2, logo abaixo do TCP, como no caso do PPP
e Ethernet. Contudo, isto não torna este campo redundante: com efeito, estudos de
tráfego revelam que a introdução de erro é bastante frequente entre hops protegidos por
CRC e que este campo detecta a maioria desses erros.
As confirmações de recepção (ACK) servem também ao emissor para determinar as

condições da rede. Dotados de temporizadores, tanto os emissores como receptores
podem alterar o fluxo dos dados, contornar eventuais problemas de congestão e, em
alguns casos, prevenir o congestionamento da rede. O protocolo está dotado de
mecanismos para obter o máximo de performance da rede sem a congestionar — o
envio de tramas por um emissor mais rápido que qualquer um dos intermediários (hops)
ou mesmo do receptor pode inutilizar a rede. São exemplo a janela deslizante, o
algoritmo de início-lento
Adequação de parâmetros
Neste simples exemplo só está a ser considerada a janela do servidor. O cliente tem a
percepção do estado da janela do servidor a cada ACK recebido.
O cabeçalho TCP possui um parâmetro que permite indicar o espaço livre atual do
receptor (emissor quando envia a indicação): a janela (ou window). Assim, o emissor
fica a saber que só poderá ter em trânsito aquela quantidade de informação até esperar
pela confirmação (ACK) de um dos pacotes - que por sua vez trará, com certeza, uma
atualização da janela. Curiosamente, a pilha TCP no Windows foi concebida para se
auto-ajustar na maioria dos ambientes e, nas versões atuais, o valor padrão é superior
em comparação com versões mais antigas.
Porém, devido ao tamanho do campo, que não pode ser expandido, os limites aparentes
da janela variam entre 2 e 65535, o que é bastante pouco em redes de alto débito e
hardware de alta performance. Para contornar essa limitação é usado uma Opção
especial que permite obter múltiplos do valor da janela, chamado de escala da janela,
ou TCP window scale; este valor indica quantas vezes o valor da janela, de 16 bit, deve
ser operado por deslocamento de bits (para a esquerda) para obter os múltiplos, podendo
variar entre 0 e 14. Assim, torna-se possível obter janelas de 1 gigabyte. O parâmetro de
escala é definido unicamente durante o estabelecimento da ligação.
Término da ligação
Término de conexão.
A fase de encerramento da sessão TCP é um processo de quatro fases, em que cada

interlocutor responsabiliza-se pelo encerramento do seu lado da ligação. Quando um
deles pretende finalizar a sessão, envia um pacote com a flag FIN ativa, ao qual deverá
receber uma resposta ACK. Por sua vez, o outro interlocutor irá proceder da mesma
forma, enviando um FIN ao qual deverá ser respondido um ACK.
Pode ocorrer, no entanto, que um dos lados não encerre a sessão. Chama-se a este tipo
de evento de conexão semi-aberta. O lado que não encerrou a sessão poderá continuar a
enviar informação pela conexão, mas o outro lado não.
Portas ou serviços
O TCP introduz o conceito de porta tipicamente associado a um serviço (camada

aplicação)/ligação específica. Assim, cada um dos intervenientes na conexão dispõe de
uma porta associada (um valor de 16 bit) que dificilmente será o mesmo do interlocutor.
Alguns serviços (que fazem uso de protocolos específicos) são tipicamente acessíveis
em portas fixas, conhecidas como portas bem conhecidas, que são aqueles numerados
do 1 ao 1023. Além destas, existem ainda duas gamas de portas, registradas e privadas
ou dinâmicas. As portas bem conhecidas são atribuídas pela Internet Assigned Numbers
Authority (IANA) e são tipicamente utilizados por processos com direitos de sistema ou
super-utilizador. Nestas portas encontram-se em escuta passiva os serviços triviais,
como HTTP, SSH, FTP, etc. Todos os protocolos da suite IP se encontram registrados
dentro desta gama.
A gama de portas privadas segue regras de atribuição específicas do sistema operativo e

serve para abrir ligações a outras máquinas, como surfar na rede, por exemplo.
Utilização do IP para entrega de dados

Ver artigo principal: TCP/IP
O TCP, tal como o UDP, usa o IP para a entrega dos datagramas à rede, e os pontos de
acesso à aplicação são identificados por portas acessadas por multiplexação, tal como
acontece com o UDP, o que permite múltiplas ligações em cada host. As portas podem
ser associadas com uma aplicação (Processo).
O IP trata o pacote TCP como dados e não interpreta qualquer conteúdo da mensagem
do TCP, sendo que os dados TCP viajam pela rede em datagramas IP. Os roteadores que
interligam as redes apenas verificam o cabeçalho IP, quando fazem o envio dos
datagramas. O TCP no destino interpreta as mensagem do protocolo TCP.
Referências
1.
 Citação vazia (ajuda)
2.  Vinton G. Cerf, Robert E. Kahn, A Protocol for Packet Network Intercommunication,

IEEE Transactions on Communications, Vol. 22, No. 5, May 1974 pp. 637-648
Ver também
 bic-tcp
 Lista de protocolos de redes
 SCTP
User Datagram Protocol

O User Datagram Protocol (UDP) é um protocolo simples da camada de transporte.
Ele é descrito na RFC 768 e permite que a aplicação envie um datagrama encapsulado
num pacote IPv4 ou IPv6 a um destino, porém sem qualquer tipo de garantia que o
pacote chegue corretamente (ou de qualquer modo).[1]
O protocolo UDP não é confiável. Caso garantias sejam necessárias, é preciso

implementar uma série de estruturas de controle, tais como timeouts, retransmissões,
acknowledgements, controle de fluxo, etc. Cada datagrama UDP tem um tamanho e
pode ser considerado como um registro indivisível, diferentemente do TCP, que é um
protocolo orientado a fluxos de bytes sem início e sem fim.[1]Também dizemos que o
UDP é um serviço sem conexão, pois não há necessidade de manter um relacionamento
longo entre cliente e o servidor. Assim, um cliente UDP pode criar um socket, enviar
um datagrama para um servidor e imediatamente enviar outro datagrama com o mesmo
socket para um servidor diferente. Da mesma forma, um servidor poderia ler
datagramas vindos de diversos clientes, usando um único socket.
O UDP também fornece os serviços de broadcast e multicast, permitindo que um único

cliente envie pacotes para vários outros na rede.
Índice
 1 História
 2 Funcionamento
 3 Cabeçalho UDP
 4 Seleção do número de portas no UDP
 5 Vantagens do uso do UDP
 6 Notas e Referências
História
O trabalho original de Vint Cerf e Bob Kahn sobre a Internet descreveu o protocolo
TCP, que provia todo o transporte e serviços de encaminhamento na Internet. Kahn
queria que o protocolo suportasse uma série de serviços de transporte, desde a entrega
sequenciada de dados totalmente confiável (modelo de circuito virtual) até o serviço de
datagrama, onde a aplicação fazia uso direto do serviço básico de rede, o que poderia
implicar em pacotes ocasionalmente perdidos, corrompidos ou reordenados.
Entretanto, o esforço inicial para implementar TCP resultou numa versão que somente
permitiu circuitos virtuais. O modelo funcionou bem para transferência de arquivos e
aplicações de logins remotos, mas alguns dos trabalhos em aplicações avançadas como
pacotes de voz mostraram que, em alguns casos, a perda de pacotes deveria ser corrigida
pela aplicação e não pelo protocolo TCP. Isso levou a uma reorganização do TCP
original em dois protocolos: o simples IP que provia apenas o endereçamento e o
roteamento dos pacotes individuais e o TCP em separado, que se preocupava com o
controle do fluxo e a recuperação de pacotes perdidos.
Para as aplicações que não queriam os serviços de TCP, uma alternativa chamada UDP
(User Datagram Protocol) foi adicionada para prover acesso direto ao serviço básico de
IP.
Funcionamento
O UDP, dá às aplicações acesso direto ao serviço de entrega de datagramas, como o

serviço de entrega que o IP dá. O UDP é pouco confiável, sendo um protocolo não
orientado para conexão. Não existem técnicas no protocolo para confirmar que os dados
chegaram ao destino corretamente. O UDP usa número de porta de origem e de destino
de 16 bits.
O UDP é um acrônimo do termo inglês User Datagram Protocol que significa

protocolo de datagramas de utilizador (ou usuário). O UDP faz a entrega de mensagens
independentes, designadas por datagramas, entre aplicações ou processos, em sistemas
host. A entrega pode ser feita fora de ordem e datagramas podem ser perdidos. A
integridade dos dados pode ser conferida por um "checksum" (um campo no cabeçalho
de checagem por soma) baseado em complemento de um, de 16 bits.
Os pontos de acesso do UDP são geralmente designados por "Portas de protocolo" ou

"portas" ou até "portos", em que cada unidade de transmissão de dados UDP identifica o
endereço IP e o número de porta do destino e da fonte da mensagem, os números
podendo ser diferentes em ambos os casos.
A diferença básica entre o UDP e o TCP é o fato de que o TCP é um protocolo
orientado à conexão e, portanto, inclui vários mecanismos para iniciar, manter e
encerrar a comunicação, negociar tamanhos de pacotes, detectar e corrigir erros, evitar
congestionamento do fluxo e permitir a retransmissão de pacotes corrompidos,
independente da qualidade do meio físicos.
O UDP, por sua vez, é feito para transmitir dados pouco sensíveis, como fluxos de
áudio e vídeo, ou para comunicação sem conexão como é o caso da negociação DHCP
ou tradução de endereços por DNS. Os dados são transmitidos apenas uma vez,
incluindo apenas um frágil, e opcional, sistema de CRC de 16 bits. Os pacotes que
chegam corrompidos são simplesmente descartados, sem que o emissor sequer saiba do
problema. Por outro lado, a ausência de estruturas de controle complexas garante ao
UDP alta eficiência, já que cada pacote é composto praticamente somente por dados.
Cabeçalho UDP
O cabeçalho UDP é extremamente simples, contendo apenas os números de porta,

comprimento da mensagem e o checksum. O cabeçalho dos datagramas UDP é
colocado a seguir ao cabeçalho IP.
Porta Porta Comprimento da Checksu

origem destino mensagem m
Os campos em laranja são opcionais. A porta de origem geralmente especifica a porta

desejada de resposta, mas pode ser omitida. Isso tipicamente ocorre em comunicações
broadcast ou mensagens de pânico, que notificam sobre a queda de um equipamento.
Seleção do número de portas no UDP
Os computadores que pretendem estabelecer uma comunicação devem definir um

número de porta. Para o servidor (Processo), e aguarda pela chegada de mensagens,
datagramas, o cliente seleciona uma porta local, para recebimento de datagramas e envia
datagramas para a porta selecionada para o processo do servidor. Muitos serviços
conhecidos usam números de portas reservados, por exemplo: 161 para o Protocolo
SNMP.
Vantagens do uso do UDP
 O UDP é uma escolha adequada para fluxos de dados em tempo real, especialmente
aqueles que admitem perda ou corrompimento de parte de seu conteúdo, tais como
vídeos ou voz (VoIP). Aplicações sensíveis a atrasos na rede, mas poucos sensíveis a
perdas de pacotes, como jogos de computadores, também podem se utilizar do UDP.
As garantias de TCP envolvem retransmissão e espera de dados, como consequência,
intensificam os efeitos de uma alta latência de rede.
 O UDP também suporta broadcasting e multicasting. Caso esses recursos sejam
necessários, o UDP deverá necessariamente ser utilizado. Algum tratamento de erro
pode ser adicionado, mas geralmente aplicações multicast também admitem perda de
parte dos pacotes ou fazem retransmissões constantes (tal como o ocorre no
protocolo DHCP).
 O UDP não perde tempo com criação ou destruição de conexões. Durante uma
conexão, o UDP troca apenas 2 pacotes, enquanto no TCP esse número é superior a
10. Por isso, aplicações que encaixam num modelo de pergunta-resposta também são
fortes candidatas a usar UDP. Entretanto, pode ser necessário implementar algoritmos
de timeouts, acks e, no mínimo, retransmissão. Nesse caso, vale lembrar que se a troca
de mensagens for muito intensa, o protocolo TCP pode voltar a ser vantajoso, já que
seu custo de conexão será amortizado.
Embora o processamento dos pacotes UDP seja realmente mais rápido, quando as
garantias de confiabilidade e ordenação são necessárias, é pouco provável que uma
implementação em UDP obterá resultados melhores do que o uso direto do TCP. Em
primeiro lugar, corre-se o risco de que uma implementação ingênua feita em UDP seja
menos eficiente do que os algoritmos já testados e otimizados presentes no TCP. Em
segundo lugar, boa parte do protocolo TCP, nos principais sistemas operacionais, opera
em modo núcleo, tendo portanto uma execução mais privilegiada do que um protocolo
de aplicação teria. Finalmente, é válido lembrar que muitas placas de rede já possuem o
TCP programado em seu firmware o que permite, por exemplo, o cálculo de checksum
por hardware. Por isso, o protocolo UDP não deveria ser utilizado para fluxos de bytes
confiáveis, tais como a transferência de arquivos. Como exemplo, podemos citar o
protocolo TFTP, exceção a essa regra, que foi feito para redes locais, de alta
confiabilidade. Na internet, seu desempenho é muito inferior ao sua versão confiável, o
protocolo FTP.
Notas e Referências
1.
E. Ferreira, Rubem. «23». In: Novatec. Linux:guia do adminitrador do sistema. Janeiro de 2013
2ª edição ed. São Paulo: [s.n.] ISBN 9788575221778
Datagram Congestion Control Protocol

Datagram Congestion Control Protocol (DCCP), ou Protocolo de Controle de
Congestionamento de Datagramas, é um protocolo de redes de computadores da camada
de transporte que se encontra em desenvolvimento pelo IETF. DCCP é um novo
protocolo da camada de transporte que implementa conexões bidirecionais unicast,
controle de congestionamento nao-confiavel de datagramas.
Recursos
- Orientado a conexão;
- Transporte não confiável;
-Preserva limite de mensagem;

- Entrega não ordenada;
- Dados checksum;
- Checksum tamanho 16 bits;
- Parcial checksum;
- Path MTU;
- Controle de Congestionamento.
Características
- Mecanismos de comunicação ECN que avisam a perda de pacotes e informações;
- Mecanismos que verificam com alta confiabilidade o envio de pacotes de dados, até
chegar ao receptor, e se esses pacotes foram
marcados com ECN, corrompidos, ou caiu no buffer de recepção;
- Mecanismos que permitem que os servidores evitem a tentativa de conexões nao

reconhecidas e conexões ja terminadas;
- Incorpora o controle de congestionamento o ECN (Explicit Congestion Notification

[RFC3168] e o ECN Nonce [RFC3540].
- Handshakes para conexões segura, configuração e desmontagem.
O DCCP é destinado para aplicações que usam grandes transferência de dados.O DCCP
também e destinado para aplicações que usam Streaming de Audio que podem se
beneficiar do controle sobre as tensões entre o atraso e a ordem de entrega.Já o TCP,
não é adequado para estas aplicações, no TCP a entrega e o controle de
congestionamento pode causar longos atrasos. Já o UDP evita atrasos, mas quem usam
UDP deve fazer o controle de congestionamento por conta própria. O DCCP fornece um
controle de congestionamento por conta própria. O DCCP fornece um controle de
congestionamento, ECN, incluindo suporte para fluxos nao confiável de datagramas, e
evita atrasos que acontecem no TCP. Ele também implementa a configuração da
conexão confiável, subdivisão, e apresenta handshakes.
Segurança
O DCCP prevê qualquer proteção contra ataques que possa bisbilhotar uma conexão em
andamento, ou quem pode adivinhar sequências de números válidos de outras maneiras.
Aplicações que desejarem segurança mais forte ainda devem usar o IP sec [RFC2401].
Stream Control Transmission Protocol
O protocolo SCTP (Stream Control Transmission Protocol) é um protocolo de
transporte confiável que opera sobre um serviço de pacotes não confiável e sem
conexão, como é o caso do IP. O SCTP oferece a transferência de datagramas
(mensagens) livre de erros e de duplicações através do reconhecimento de transmissões
(ACKs). A detecção de corrupção, perda e duplicação de dados é obtida através de
mecanismos de checksum e números sequenciais. Um mecanismo de retransmissão
seletiva é usado para corrigir a perda ou a corrupção de dados.
O SCTP é um protocolo de transporte definido em 2000 pelo IETF Signaling Transport

(SIGTRAN). O protocolo é definido pela RFC 2960, um texto introdutório é fornecido
pela RFC 3286.
Como é um protocolo do transporte, o SCTP é equiparável ao TCP ou ao UDP.

Certamente, fornece alguns serviços similares ao TCP, assegurando confiança,
transporte em seqüência das mensagens com controle do congestionamento, etc.
Este artigo sobre Internet é um esboço relacionado ao Projeto Internet. Você pode ajudar
a Wikipédia expandindo-o.
RSVP
Índice
 1 Expressão
 2 Protocolo de comunicação digital
o 2.1 Tipos de serviço
 3 Domínio
Expressão
RSVP é a abreviatura de Répondez S'il Vous Plaît, expressão francesa que significa
"Responda por favor".
O RSVP é utilizado pela pessoa que deseja confirmar quem irá no evento que ela vai
realizar, desta maneira pede a confirmação para ter um melhor planejamento do evento
em geral.
Protocolo de comunicação digital
O RSVP, ou Protocolo RSVP (Resource reSerVation Protocol), é um protocolo para a

arquitetura de serviços integrado, empregue para fazer reservas. Com este protocolo
vários transmissores enviam dados para vários grupos.
O RSVP permite que os receptores individuais mudem livremente de canal e otimiza o

uso da largura de banda ao mesmo tempo que elimina o congestionamento.
É um protocolo de QoS e de habilitação de negócios.
Provedores comerciais devem ser capazes de:
 promover suporte nativo de QoS por meio de aplicações IP;

 organizar acordos para suportar QoS entre entidades diferentes;
 garantir QoS quando necessário;
 cobrar pelo serviço.
Os provedores precisam:
 fornecer às aplicações um modo uniforme de pedir um certo nível de QoS;

 encontrar um modo de garantir um nível de QoS;
 fornecer autenticação do serviço.
Tipos de serviço
O RSVP oferece dois tipos de serviço:
1. Serviço de garantia controlada: uma aplicação que necessite de um serviço de

garantia controlada espera que a rede se comporte como se ela estivesse com pouca
carga (baixo fluxo de dados); a taxa de perda de pacotes deve ser muito baixa ou nula;
o atraso não é especificado, mas as flutuações devem ser as mais baixas possível.
2. Serviço garantido: este tipo de serviço não só pede uma largura de banda específica,
mas também um atraso de tráfego máximo; em sua forma mais simples, o protocolo
utiliza roteamento por multidifusão com árvores de amplitude; cada grupo recebe um
endereço de grupo. Para transmitir dados a um grupo, um transmissor coloca o
endereço desse grupo em seus pacotes; em seguida, o algoritmo de roteamento por
multidifusão padrão constrói uma árvore de amplitude que cobre todos os membros.
Domínio
Novo dominio .RSVP

Camada de rede
Open Shortest Path First
O OSPF - Open Shortest Path First - é um protocolo de roteamento para redes que
operam com protocolo IP; desenvolvido pelo grupo de trabalho da IGPs (Interior
Gateway Protocol) da IETF (Internet Engineering Task Force) e descrito inicialmente
em 1989 pela RFC 1131. Baseado no algoritmo SPF - Shortest Path First (menor rota
primeiro), o OSPF foi criado para substituir o protocolo RIP empregado no final da
década de 1980 na então Arpanet (atual Internet) e que apresentava diversos problemas
e limitações para operar satisfatoriamente em uma rede de grande porte.
Atualmente o OSPF é um dos protocolos de roteamento mais empregados, sendo

suportado pela maioria dos roteadores, assim como por servidores que implementem os
sistemas operacionais Linux e Unix. Versátil, o OSPF pode ser empregado tanto a redes
de pequeno quanto em redes de grande porte.
Índice
 1 Princípio de funcionamento
 2 Principais características
 3 Pacote OSPF
o 3.1 Cabeçalho do pacote OSPF
 4 Tópicos relacionados
Princípio de funcionamento
Embora possua inúmeros detalhes de implementação e configuração, o princípio de

roteamento do OSPF é relativamente simples. Ao invés de manter uma tabela com todas
as rotas possíveis (como faz o protocolo RIP), cada nó (roteador) OSPF contêm dados
sobre todos os links da rede. Cada entrada da tabela de roteamento OSPF contém um
identificador de interface, um número do link e uma distância ou custo (esse último
pode ser atribuído pelo administrador da rede). Com todas essas informações, cada nó
possui uma visão da topologia da rede e pode, dessa forma, descobrir sozinho qual é a
melhor rota para um dado destino.
Caso ocorra uma alteração num dos links de rede, os nós adjacentes avisam seus
vizinhos. Esses por sua vez, verificam o número da mensagem ou a hora no cabeçalho
do pacote OSPF para saberem se este aviso é novo ou velho. Se o aviso for novo, é feita
a verificação da existência da entrada. Caso ela não exista, é adicionada à tabela de
roteamento. Se a entrada já existir, são comparados os números da mensagem recebida
com a entrada existente na tabela de roteamento. Se o número da mensagem recebida
for maior que a entrada existente, a entrada é substituída, caso contrário, a entrada da
tabela é transmitida como uma nova mensagem. Se os números forem iguais, o nó não
executa nenhuma ação.
Principais características
Há duas características principais no OSPF. A primeira, é que se trata de um protocolo

aberto, o que significa que suas especificações são de domínio público; suas
especificações podem ser encontradas na RFC (Request For Comments) número 1247.
A segunda, é que ele se baseia no algoritmo SPF, também chamado de algoritmo de
Dijkstra, nome de seu criador.
OSPF é um protocolo de roteamento do tipo link-state, que envia avisos sobre o estado
da conexão (link-state advertisements, LSA) a todos os outros roteadores em uma
mesma área hierárquica. Informações sobre interfaces ligadas, métrica usada e outras
variáveis são incluídas nas LSAs. Ao mesmo tempo em que o roteador OSPF acumula
informações sobre o estado do link, ele usa o algoritmo SPF para calcular a melhor rota
para cada nó.
Por ser um protocolo do tipo link-state, o OSPF difere-se do RIP e do IGRP, que são
protocolos de roteamento baseados em vetores de distância. Os roteadores que
trabalham com algoritmos de vetor de distância, a cada atualização, enviam toda ou
parte de suas tabelas de roteamento para seus vizinhos.
Pacote OSPF
Há cinco tipos distintos de pacotes OSPF. Cada um dos cinco tipos iniciam com um
cabeçalho padrão de 24 bytes. E são eles:
1. Pacote de aviso. (Hello packet)

2. Pacote de informações do Banco de Dados (Database Description packet)
3. Requisição de estado de link (Link State Request packet)
4. Atualização de estado de link (Link State Update packet)
5. Recebimento de informações de link (Link State Acknowledgment packet)
Cabeçalho do pacote OSPF
Todo pacote OSPF inicia com um cabeçalho de 24 bytes. Esse cabeçalho contem todas
as informações necessárias para determinar se o pacote deve ser aceito para futuras
operações. O pacote tem a seguinte estrutura:
0 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+
| Version # | Type | Packet length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+
| Router ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+
| Area ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+
| Checksum | AuType
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+
| Authentication
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+
| Authentication
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+
 Version - O número da versão do protocolo OSPF.

 Type - O tipo do pacote OSPF.
Tipo Descrição
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
 Packet length - O tamanho do pacote em bytes. O tamanho inclui também o

cabeçalho.
 Router ID - O identificador do roteador que enviou o pacote.
 Area ID - Um número de 32 bits que indica a área a qual o pacote pertence. Todo
pacote é associado a uma única área.
 Checksum - O checksum do pacote completo, incluindo o cabeçalho, mas excluindo os
64 bits de autenticação.
 AuType - Indica o esquema de autenticação a ser usado no pacote.
 Authentication - Um campo de 64 bits usado para informar o esquema de autenticação
a ser utilizado.
Tópicos relacionados
 BGP
 Intermediate System to Intermediate System
 IEEE 802.1aq - Shortest Path Bridging (SPB)
 Ping2
 RIP
 WHOIS
 Traceroute
Protocolo de Internet
Protocolo de Internet (em inglês: Internet Protocol, ou o acrónimo IP) é um protocolo
de comunicação usado entre todas as máquinas em rede para encaminhamento dos
dados. Tanto no Modelo TCP/IP, quanto no Modelo OSI, o importante protocolo da
internet IP está na camada intitulada camada de rede.
Índice
 1 Funcionamento
 2 Formato do Cabeçalho do IPv4
 3 Endereçamento IPv4 e encaminhamento
 4 Ver também
 5 Bibliografia
 6 Referências
Funcionamento
Os dados numa rede IP que são enviados em blocos referidos como ficheiros (os termos
são basicamente sinónimos no IP, sendo usados para os dados em diferentes locais nas
camadas IP). Em particular, no IP nenhuma definição é necessária antes do nó tentar
enviar ficheiros para um nó com o qual não comunicou previamente.
O IP oferece um serviço de datagramas não confiável (também chamado de melhor

esforço); ou seja, o pacote vem quase sem garantias. O pacote pode chegar desordenado
(comparado com outros pacotes enviados entre os mesmos nós), também podem chegar
duplicados, ou podem ser perdidos por inteiro. Se a aplicação requer maior
confiabilidade, esta é adicionada na camada de transporte.
Os roteadores são usados para reencaminhar datagramas IP através das redes

interconectadas na segunda camada. A falta de qualquer garantia de entrega significa
que o desenho da troca de pacotes é feito de forma mais simplificada. (Note que se a
rede cai, reordena ou de outra forma danifica um grande número de pacotes, o
desempenho observado pelo utilizador será pobre, logo a maioria dos elementos de rede
tentam arduamente não fazer este tipo de coisas - melhor esforço. Contudo, um erro
ocasional não irá produzir nenhum efeito notável.)
O IP é o elemento comum encontrado na Internet pública dos dias de hoje. É descrito no

RFC 791 da IETF, que foi pela primeira vez publicado em Setembro de 1981. Este
documento descreve o protocolo da camada de rede mais popular e atualmente em uso.
Esta versão do protocolo é designada de versão 4, ou IPv4. O IPv6 tem endereçamento
de origem e destino de 128 bits, oferecendo mais endereçamentos que os 32 bits do
IPv4.
Formato do Cabeçalho do IPv4
+ 0-3 4-7 8 - 15 16 - 18 19 - 31
Tamanho do Tipo de Serviço (ToS) Comprimento
0 Versão
cabeçalho (agora DiffServ e ECN) (pacote)
32 Identificador Flags Offset
64 Tempo de Vida (TTL) Protocolo Checksum
96 Endereço origem
12
Endereço destino
8
16
Opções
0

19
Dados
2

 Versão - o primeiro campo do cabeçalho de um datagrama IPv4 é o campo de versão,

com quatro bits.[1]
 Tamanho do cabeçalho (IHL) - o segundo campo, de quatro bits, é o IHL (acrónimo
para Internet Header Length, ou seja, Comprimento do Cabeçalho da Internet) em
número de palavras de 32 bits (4 bytes) do cabeçalho IPv4. [1] Como o cabeçalho IPv4
prevê o campo OPÇÕES que pode ser utilizado para estender o cabeçalho IP, [2] o
campo IHL essencialmente especifica onde exatamente termina o cabeçalho e onde
iniciam os dados do datagrama IPv4.[2] Um cabeçalho IPv4 mínimo tem vinte bytes de
comprimento, logo o valor mínimo em decimal no campo IHL seria cinco, conforme [1]:
 Tipo de serviço (ToS) - no RFC 791, os oito bits seguintes são alocados para um campo
tipo de serviço (ToS), agora DiffServ e ECN. A intenção original era para um nó
especificar uma preferência para como os datagramas poderiam ser manuseados
assim que circulariam pela rede. Por exemplo, um nó pode definir o campo de valores
do seu ToS dos datagramas IPv4 para preferir pequeno desfasamento de tempo,
enquanto que outros podem preferir alta confiabilidade. Na prática, o campo ToS não
foi largamente implementado. Contudo, trabalho experimental, de pesquisa e
desenvolvimento se focou em como fazer uso destes oito bits. Estes bits têm sido
redefinidos e mais recentemente através do grupo de trabalho do DiffServ na IETF e
pelos pontos de código do Explicit Congestion Notification (ECN) (RFC 3168.)
 Comprimento (pacote) - o campo de dezesseis bits seguinte do IPv4 define todo o
tamanho do datagrama, incluindo cabeçalho e dados, em bytes de oito bits. O
datagrama de tamanho mínimo é de vinte bytes e o máximo é 64 Kb. O tamanho
máximo do datagrama que qualquer nó requer para estar apto para manusear são 576
bytes, mas os nós mais modernos manuseiam pacotes bem maiores. Por vezes, as
subredes impõem restrições no tamanho, em cada caso os datagramas têm que ser
"fragmentados". A fragmentação é manuseada quer no nó quer no comutador de
pacotes no IPv4, e apenas no nó no caso do IPv6.
 Identificador - o campo seguinte de dezesseis bits é um campo de identificação. Este
campo é usado principalmente para identificar fragmentos identificativos do
datagrama IP original. Alguns trabalhos experimentais sugerem usar o campo IP para
outros propósitos, tais como adicionar pacotes para levar a informação para
datagrama, de forma a que ajude a pesquisar datagramas para trás com endereços
fonte falsificados.
 Flags - o campo de três bits que segue é usado para controlar ou identificar
fragmentos.
 Offset - o campo offset do fragmento tem treze bits, e permite que um receptor
determine o local de um fragmento em particular no datagrama IP original.
 Tempo de vida (TTL) - um campo de oito bits, o TTL (time to live, ou seja, tempo para
viver) ajuda a prevenir que os datagramas persistam (ex. andando aos círculos) numa
rede. Historicamente, o campo TTL limita a vida de um datagrama em segundos, mas
tornou-se num campo de contagem de nós caminhados. Cada comutador de pacotes
que um datagrama atravessa decrementa o campo TTL em um valor. Quando o campo
TTL chega a zero, o pacote não é seguido por um comutador de pacotes e é
descartado.
 Protocolo - um campo de protocolo de oito bits segue-se, definindo o protocolo
seguinte usado numa porção de dados de um datagrama IP. A Internet Assigned
Numbers Authority mantém uma lista de números de protocolos. Os protocolos
comuns e os seus valores decimais incluem o ICMP (1), o TCP (6).
 Checksum - o campo seguinte é um campo de verificação para o cabeçalho do
datagrama IPv4. Um pacote em trânsito é alterado por cada comutador que atravesse.
Um desses comutadores pode comprometer o pacote, e a verificação é uma forma
simples de detectar a consistência do cabeçalho. Este valor é ajustado ao longo do
caminho e verificado a cada novo nó. Envolve apenas verificação do cabeçalho (não
dos dados).
Encapsulamento IP: O endereço de origem no cabeçalho IP indicará a quem deverá ser enviada
a resposta do protocolo encapsulado, neste caso o TCP.
 Endereço de origem/Endereço de destino - a seguir ao campo de verificação, seguem-

se os endereço de origem e de destino, de 32 bits cada um. Note que os endereços
IPv6 de origem e destino são de 128 bits cada.
 Opções - Campos do cabeçalho adicionais podem seguir o campo do endereço de
destino, mas estes não são normalmente usados. Os campos de opção podem ser
seguidos de um campo de caminho que assegura que os dados do utilizador são
alinhados numa fronteira de palavras de 32 bits. (No IPv6, as opções movem-se fora do
cabeçalho padrão e são especificados pelo campo Next Protocol, semelhante à função
do campo "Protocolo" no IPv4).
A seguir, três exemplos de opções que são implementadas e aceitas na maioria dos
roteadores:
 Security (especifica o nível de segurança do datagrama (usado em aplicações

militares));
 Timestamp (Faz com que cada roteador anexe seu endereço e sua marca temporal (32
bits), que serve para depuração de algoritmos de roteamento); e
 Record route (faz com que cada roteador anexe seu endereço).
Endereçamento IPv4 e encaminhamento
Talvez os aspectos mais complexos do IP sejam o endereçamento e o encaminhamento.

O endereçamento define como os endereços IP dos nós finais são atribuídos e como as
subredes dos endereços de IP dos nós são divididos e agrupados. O encaminhamento IP
é feito por todos os nós, mas mais comumente por roteadores de rede, que tipicamente
usam os protocolos IGP ou EGP para ajudar na leitura de datagramas IP que
reencaminhem decisões através de IPs em redes ligadas.
Na internet, e nas redes particulares que vemos hoje nas empresas ou mesmo nas
residências, o protocolo de comunicação usado pelos computadores chama-se IP - sigla
para Internet Protocol. Criado no fim dos anos 70, o protocolo IP tem como "missão"
não só fazer dois computadores "conversarem", mas também possibilitar a interligação
de duas ou mais redes separadas. Com raríssimas exceções, praticamente todas as redes
do mundo acabaram, de uma forma ou de outra, sendo conectadas entre si e foi essa
comunhão de redes que acabou formando o que conhecemos hoje por internet (nome
que, em português, pode ser traduzido por "inter-redes" ou "redes interligadas").
O protocolo IP possui um esquema de endereçamento parecido com os números de

telefone. Assim como qualquer telefone, no mundo todo, é único (considerando o DDD
e o código de país), cada computador ligado na internet possui um número único, que é
chamado de endereço IP ou número IP. Esse número serve para identificar o
computador na internet. Se você precisar conversar com alguém pela internet, basta
mandar mensagens endereçadas ao endereço IP do computador da pessoa.
Para que um email da Alice saia de seu computador e chegue ao computador do Beto,
por exemplo, é preciso que os dados (no caso, o texto do email) sejam divididos em
pacotinhos pequenos (chamados de pacotes IP) que possuem marcados dentro de si o
endereço IP de origem (ou seja, o número único do computador da Alice) e o IP de
destino (o número único do computador do Beto). A internet "se vira" para encontrar o
caminho entre Alice e Beto, sem que nenhum dos dois precise se preocupar com isso.
No entanto, o protocolo IP em sua versão atual (a versão quatro, rotulada como IPv4) já
é bastante antiga e tem muitos problemas.[carece de fontes] Os mais graves são falhas de
segurança, que periodicamente são descobertas e não têm solução. [carece de fontes] A maioria
dos ataques contra computadores hoje na internet só é possível devido a falhas no
protocolo IP. [carece de fontes] A nova geração do protocolo IP, o IPv6, resolve grande parte
dos problemas de segurança da internet hoje, herdados justamente do projeto antiquado
do IPv4.[carece de fontes]
Mas o IPv4 tem um problema ainda mais premente do que sua inerente insegurança: já
esgotou sua capacidade de expansão. Cada computador ligado à internet - seja um
computador pessoal, uma estação de trabalho ou um servidor que hospeda um site -
precisa de um endereço único que o identifique na rede. O IPv4 define, entre outras
coisas importantes para a comunicação entre computadores, que o número IP tem uma
extensão de 32 bits. Com 32 bits, o IPv4 tem disponíveis em teoria cerca de quatro
bilhões de endereços IP mas, na prática, o que está realmente disponível é menos da
metade disso. Se contarmos que o planeta tem seis bilhões de habitantes e que cada
dispositivo ligado na internet (o que inclui smartphones, PCs, notebooks e afins) precisa
de um número só dele, é fácil perceber que a conta não fecha. Esse número, sendo
finito, um dia acaba.
Em cima disso, os endereços IP são "travados" geograficamente. Dois endereços

próximos estão necessariamente na mesma cidade ou região. Se considerarmos que
cerca de três quartos dos endereços IP disponíveis para a internet estão localizados nos
Estados Unidos (mesmo que nunca usados), sobram apenas pouco mais de um bilhão de
endereços para o resto do mundo - aumentando ainda mais o problema de escassez.
A entrada dos smartphones e outros dispositivos móveis (que são baratos e

extremamente populares) na internet contribuiu para que o número de endereços IP
disponíveis seja ainda mais escasso. De fato, algumas previsões pessimistas davam
conta de que os endereços IP iriam acabar por completo em 2012, transformando a
internet num verdadeiro caos.
O advento do IPv6, com 128 bits, resolveria todos esses problemas. Primeiro, porque dá
fim a praticamente todos os buracos de segurança conhecidos do IPv4, tornando as
comunicações muitíssimo mais seguras. O IPv6 provavelmente será uma dor de cabeça
sem tamanho para os hackers criminosos.
Em segundo lugar, o IPv6 define 128 bits para endereçamento, e portanto conta com
cerca de 3,4 × 10^38 endereços disponíveis (ou 340 seguido de 36 zeros). Para quem
não quiser fazer a conta, basta saber que são muitos bilhões de quatrilhões de endereços
disponíveis, garantindo que não vai faltar números IP para os humanos por milênios.
Pelo "draft" inicial de um documento proposto pelo IETF - Internet Engineering Task
Force, órgão responsável pelo desenvolvimento tecnológico da internet, a migração de
IPv4 para IPv6 deveria ter começado em algum momento entre 2009 e 2010, com
migração total até o fim de 2011. O cronograma ainda está atrasado devido aos vários
problemas da completa conversão. Google, Yahoo! e Facebook já começam a adotar o
IPv6.
Na Campus Party Brasil de 2011, em sua quarta edição brasileira, realizada em São
Paulo, a Telefônica ofereceu aos campuseiros a oportunidade de se conectar à internet
com IPv6. A companhia vem testando a tecnologia há dois anos e espera poder oferecê-
la aos seus clientes ainda em 2011.[3]
Ver também
 Protocolo (ciência da computação)

 Comutador
 Endereço IP
 IANA
 Lista padrão de serviços e portas associadas
Bibliografia
 RFC 791 - Internet Protocol (em inglês)

 RFC 3168 - Explicit congestion notification (em inglês)
 RFC 1883 - Internet Protocol, Version 6 (em inglês)
Referências
1.
 Forouzan, Behrouz (2008). Comunicação de Dados e Redes de Computadores 4ª ed. São

Paulo: McGraw-Hill. pp. 582–596
  Kurose, James F.; Ross, Keith W. (2013). Redes de computadores e a internet: uma
abordagem top-down 6ª ed. São Paulo: Pearson Education do Brasil. pp. 245–247
 Entenda o protocolo IP e a diferença entre IPv4 e IPv6
IPv6
IPv6 é a versão mais atual do Protocolo de Internet. Originalmente oficializada em 6 de
junho de 2012, é fruto do esforço do IETF para criar a "nova geração do IP" (IPng:
Internet Protocol next generation), cujas linhas mestras foram descritas por Scott
Bradner e Allison Marken, em 1994, na RFC 1752.[1] Sua principal especificação
encontra-se na RFC 2460.[2]
O protocolo está sendo implantado gradativamente na Internet e deve funcionar lado a

lado com o IPv4, numa situação tecnicamente chamada de "pilha dupla" ou "dual
stack", por algum tempo. A longo prazo, o IPv6 tem como objetivo substituir o IPv4,
que suporta somente cerca de 4 bilhões(escala curta)/mil milhões(escala longa) (4x109) de
endereços IP, contra cerca de 340 undecilhões(escala curta)/sextiliões(escala longa) (3,4x1038) de
endereços do novo protocolo[3].
O assunto é tão relevante que alguns governos têm apoiado essa implantação. O
governo dos Estados Unidos, por exemplo, em 2005, determinou que todas as suas
agências federais deveriam provar ser capazes de operar com o protocolo IPv6 até junho
de 2008. Em julho de 2008, foi liberada uma nova revisão[4] das recomendações para
adoção do IPv6 nas agências federais, estabelecendo a data de julho de 2010 para
garantia do suporte ao IPv6. O governo brasileiro recomenda a adoção do protocolo no
documento e-PING, dos Padrões de Interoperabilidade de Governo Eletrônico.
Índice
 1 Motivações para a implantação do IPv6

o 1.1 O esgotamento do IPv4 e a necessidade de mais endereços na Internet
o 1.2 Outros fatores motivantes
 2 Novidades nas especificações do IPv6
 3 Formato do datagrama IPv6
 4 Fragmentação e determinação do percurso
 5 Múltiplos cabeçalhos
 6 Endereçamento
 7 Estruturas de endereços de transição
 8 Outras estruturas de endereços IPv6
 9 Referências
Motivações para a implantação do IPv6

O esgotamento do IPv4 e a necessidade de mais endereços na Internet
O principal motivo para a implantação do IPv6 na Internet é a necessidade de mais

endereços, porque a disponibilidade de endereços livres IPv4 terminou.
Para entender as razões desse esgotamento, é importante considerar que a Internet não
havia sido projetada para uso comercial. No início da década de 1980, ela era
considerada uma rede predominantemente acadêmica, com poucas centenas de
computadores interligados. Apesar disso, pode-se dizer que o espaço de endereçamento
do IP versão 4, de 32 bits, não é pequeno: 4 294 967 296 de endereços.
Ainda assim, já no início de sua utilização comercial, em 1993, acreditava-se que o

espaço de endereçamento da Internet poderia se esgotar num prazo de 2 ou 3 anos. Mas,
não por causa da limitada quantidade de endereços, e sim por conta da política de
alocação inicial, que não era favorável a uma utilização racional desses recursos.
Dividiu-se esse espaço em três classes principais (embora atualmente existam, a rigor,
cinco classes), a saber:
 Classe A: com 128 segmentos/redes, que poderiam ser atribuídos individualmente às

entidades que deles necessitassem, com aproximadamente 16 milhões de endereços
cada. Essa classe era classificada como /8, pois os primeiros 8 bits representavam a
rede, ou segmento, enquanto os demais poderiam ser usados livremente. Ela utilizava
o espaço compreendido entre os endereços 00000000.*.*.* (0.*.*.*) e 01111111.*.*.*
(127.*.*.*).
 Classe B: com aproximadamente 16 mil segmentos de 64 mil endereços cada. Essa
classe era classificada como /16. Ela utilizava o espaço compreendido entre os
endereços 10000000.0000000.*.* (128.0.*.*) e 10111111.11111111.*.* (191.255.*.*).
 Classe C: com aproximadamente 2 milhões de segmentos de 256 endereços cada. Essa
classe era classificada como /24. Ela utilizava o espaço compreendido entre os
endereços 11000000.0000000.00000000.* (192.0.0.*) e
11011111.11111111.11111111.* (213.255.255.*).
Os 32 blocos /8 restantes foram reservados para Multicast e para a IANA (Internet

Assigned Numbers Authority), entidade que controla a atribuição global dos números na
Internet.
O espaço reservado para a classe A atenderia a apenas 128 entidades, no entanto,

ocupava metade dos endereços disponíveis. Não obstante, empresas e entidades como
HP, GE, DEC, MIT, DISA, Apple, AT&T, IBM, USPS, dentre outras, receberam
alocações desse tipo.
As previsões iniciais, no entanto, de esgotamento quase imediato dos recursos, não se

concretizaram devido ao desenvolvimento de uma série de tecnologias, que
funcionaram como uma solução paliativa para o problema trazido com o crescimento
acelerado:
 O CIDR (Classless Inter Domain Routing), ou roteamento sem uso de classes, que é
descrito pela RFC 1519. Com o CIDR foi abolido o esquema de classes, permitindo
atribuir blocos de endereços com tamanho arbitrário, conforme a necessidade,
trazendo um uso mais racional para o espaço.
 O uso do NAT (Network Address Translation) e da RFC 1918, que especifica os
endereços privados, não válidos na Internet, nas redes corporativas. O NAT permite
que, com um endereço válido apenas, toda uma rede baseada em endereços privados,
tenha conexão, embora limitada, com a Internet.
 O DHCP (Dynamic Host Configuration Protocol), descrito pela RFC 2131. Esse protocolo
trouxe a possibilidade aos provedores de reutilizarem endereços Internet fornecidos a
seus clientes para conexões não permanentes.
O conjunto dessas tecnologias reduziu a demanda por novos números IP, de forma que
o esgotamento previsto para a década de 1990, foi postergado para a década de 2010.
Porém, a adoção mundial do IPv6 é lenta: 2% em 2014, 5% em 2015, 8% em 2016,
14% em 2017 e 20% em 2018.[5]
Outros fatores motivantes
O principal fator que impulsiona a implantação do IPv6 é sua necessidade na

infraestrutura da Internet. É uma questão de continuidade de negócios, para provedores
e uma série de outras empresas e instituições.
Contudo, há outros fatores que motivam sua implantação:
 Internet das Coisas: Imagina-se que, em um futuro onde a computação seja ubíqua, a
tecnologia estará presente em vários dispositivos atualmente ainda não inteligentes,
que serão capazes de interagir autonomamente entre si - computadores invisíveis
interligados à Internet, embutidos nos objetos usados no dia a dia - tornando a vida
ainda mais líquida. Pode-se imaginar eletrodomésticos conectados, automóveis,
edifícios inteligentes, equipamentos de monitoramento médico, etc. Dezenas, talvez
mesmo centenas ou milhares de equipamentos estarão conectados em cada
residência e escritório. O IPv6, com endereços abundantes, fixos, válidos, é necessário
para fazer desse futuro uma realidade.
 Expansão das redes: Vários fatores motivam uma expansão cada vez mais acelerada da
Internet: a inclusão digital, as redes móveis (3G, 4G, 5G), etc. São necessários mais IPs.
 Qualidade de serviço: A convergência das redes de telecomunicações futuras para a
camada de rede comum, o IPv6, favorecerá o amadurecimento de serviços hoje
incipientes, como VoIP, streaming de vídeo em tempo real, etc, e fará aparecerem
outros, novos. O IPv6 tem um suporte melhorado a classes de serviço diferenciadas,
em função das exigências e prioridades do serviço em causa.
 Mobilidade: A mobilidade é um fator muito importante na sociedade de hoje em dia.
O IPv6 suporta a mobilidade dos utilizadores, estes poderão ser contactados em
qualquer rede através do seu endereço IPv6 de origem.
Novidades nas especificações do IPv6
 Espaço de Endereçamento. Os endereços IPv6 têm um tamanho de 128 bits.

 Autoconfiguração de endereço. Suporte para atribuição automática de endereços
numa rede IPv6, podendo ser omitido o servidor de DHCP a que estamos habituados
no IPv4.
 Endereçamento hierárquico. Simplifica as tabelas de encaminhamento dos roteadores
da rede, diminuindo assim a carga de processamento dos mesmos.
 Formato do cabeçalho. Totalmente remodelados em relação ao IPv4: mais simplificado
e eficiente.
 Cabeçalhos de extensão. Opção para guardar informação adicional.
 Suporte à qualidade diferenciada. Aplicações de áudio e vídeo passam a estabelecer
conexões apropriadas tendo em conta as suas exigências em termos de qualidade de
serviço (QoS).
 Capacidade de extensão. Permite adicionar novas especificações de forma simples.
 Encriptação. Diversas extensões no IPv6 permitem, à partida, o suporte para opções
de segurança como autenticação, integridade e confidencialidade dos dados.
Formato do datagrama IPv6
Um datagrama IPv6 é constituído por um cabeçalho base, ilustrado na figura que se

segue, seguido de zero ou mais cabeçalhos de extensão, seguidos depois pelo bloco de
dados.
Formato do cabeçalho base do datagrama IPv6:

 Possui menos informação que o cabeçalho do IPv4. Por exemplo, o checksum foi
removido do cabeçalho, já que esta versão considera que o controle de erros das
camadas inferiores é confiável.
 O campo Traffic Class é usado para assinalar a classe de serviço a que o pacote
pertence, permitindo assim dar diferentes tratamentos a pacotes provenientes de
aplicações com exigências distintas. Este campo serve de base para o funcionamento
do mecanismo de qualidade de serviço (QoS) na rede.
 O campo Flow Label é usado com novas aplicações que necessitem de bom
desempenho. Permite associar datagramas que fazem parte da comunicação entre
duas aplicações. Usados para enviar datagramas ao longo de um caminho pré-
definido.
 O campo Payload Length representa, como o nome indica, o volume de dados em
bytes que pacote transporta.
 O campo Next Header aponta para o primeiro header de extensão. Usado para
especificar o tipo de informação que está a seguir ao cabeçalho corrente.
 O campo Hop Limit tem o número de hops transmitidos antes de descartar o
datagrama, ou seja, este campo indica o número máximo de saltos (passagem por
roteadores) do datagrama antes de ser descartado. Esse campo substitui o TTL do
IPv4.
Fragmentação e determinação do percurso
No IPv6 o responsável pela fragmentação é o host que envia o datagrama, e não os

roteadores intermédios como no caso do IPv4. No IPv6, os roteadores intermédios
descartam os datagramas maiores que o MTU da rede. O MTU será o MTU máximo
suportado pelas diferentes redes entre a origem e o destino. Para isso o host envia
pacotes ICMP de vários tamanhos; quando um pacote chega ao host destino, todos os
dados a serem transmitidos são fragmentados no tamanho deste pacote que alcançou o
destino.
O processo de descoberta do MTU tem que ser dinâmico, porque o percurso pode ser
alterado durante a transmissão dos datagramas.
No IPv6, um prefixo não fragmentável do datagrama original é copiado para cada

fragmento. A informação de fragmentação é guardada num cabeçalho de extensão
separado. Cada fragmento é iniciado por uma componente não fragmentável seguida de
um cabeçalho do fragmento.
Múltiplos cabeçalhos
Uma das novidades do IPv6 é a possibilidade de utilização de múltiplos cabeçalhos

encadeados. Estes cabeçalhos extra permitem uma maior eficiência, pois o tamanho do
cabeçalho pode ser ajustado segundo as necessidades, e uma maior flexibilidade, porque
podem ser sempre adicionados novos cabeçalhos para satisfazer novas especificações.
As especificações atuais recomendam a seguinte ordem:
1. IPv6
2. Hop-By-Hop Options Header
3. Destination Option Header
4. Routing Header
5. Fragment Header
6. Authentication Security Payload Header
7. Destination Options Header
8. Upper-Layer Header
Endereçamento
O endereçamento no IPv6 é de 128 bits (o quádruplo do IPv4), e inclui prefixo de rede e

sufixo de host. No entanto, não existem classes de endereços, como acontece no IPv4.
Assim, a fronteira do prefixo e do sufixo pode ser em qualquer posição do endereço.
Um endereço padrão IPv6 deve ser formado por um campo provider ID, subscribe ID,
subnet ID e node ID. O node ID (ou identificador de interface) deve ter 64 bits, e pode
ser formado a partir do endereço físico (MAC) no formato EUI 64.
Os endereços IPv6 são normalmente escritos como oito grupos de 4 dígitos

hexadecimais. Por exemplo,
2001:0db8:85a3:08d3:1319:8a2e:0370:7344
Se um grupo de vários dígitos seguidos for 0000, pode ser omitido. Por exemplo,
2001:0db8:85a3:0000:0000:0000:0000:7344
é o mesmo endereço IPv6 que o exemplo anterior:
2001:0db8:85a3::7344
Existem no IPv6 tipos especiais de endereços:
 unicast - cada endereço corresponde a uma interface (dispositivo).

 multicast - cada endereço corresponde a múltiplas interfaces. É enviada uma cópia
para cada interface.
 anycast - corresponde a múltiplas interfaces que partilham um prefixo comum. Um
datagrama é enviado para um dos dispositivos, por exemplo, o mais próximo.
Com o IPv6 todas as redes locais devem ter prefixos /64. Isso é necessário para o
funcionamento da autoconfiguração e outras funcionalidades.
Usuários de qualquer tipo receberão de seus provedores redes /48, ou seja, terão a seu
dispor uma quantidade suficiente de IPs para configurar aproximadamente 65 mil redes,
cada uma com endereços (18 quintilhões). É preciso notar, no entanto, que alguns
provedores cogitam entregar aos usuários domésticos redes com tamanho /56,
permitindo sua divisão em apenas 256 redes /64.
Estruturas de endereços de transição
Os endereços IPv6 podem ser mapeados para IPv4 e são concebidos para roteadores que
suportem os dois protocolos, permitindo que nos IPv4 façam um "túnel" através de uma
estrutura IPv6. Estes endereços são automaticamente construídos pelos roteadores que
suportam ambos os protocolos.
Para tal, os 128 bits do IPv6 ficam assim divididos:
 campo de 80 bits colocado a '0' (zero), 0000:0000:0000:0000:0000 ...

 campo de 16 bits colocado a '1' (um), ... FFFF ...
 endereço IPv4 de 32 bits
Endereços IPv6 mapeados para IPv4:
::FFFF:<endereço IPv4>
Outras estruturas de endereços IPv6
Existem outras estruturas de endereços IPv6:
 Endereços de ISP - formato projetado para permitir a conexão à Internet por

utilizadores individuais de um ISP.
 Endereços de Site - para utilização numa Rede Local.
Referências
1.
 «Request for Comments: 1752» (em inglês). Internet Engineering Task Force. Janeiro de
1995. Consultado em 18 de outubro de 2009
  «Request for Comments: 2460» (em inglês). Internet Engineering Task Force. Dezembro de
1998. Consultado em 18 de outubro de 2009
  VENTURA, Felipe (19 dde janeiro de 2012). «Novo sistema que permite 340 undecilhões de
endereços IP estreia em junho». Gizmodo. Consultado em 21 de julho de 2015 Verifique data
em: |data= (ajuda)
  «NIST Special Publication 500-267 - A Profile for IPv6 in the U.S.Government – Version 1.0»
(PDF) (em inglês)
5.  https://www.google.com/intl/en/ipv6/statistics.html
Ligações externas
 Curso e-learning Introdução ao IPv6, do CGI.br / NIC.br

 Sítio sobre IPv6 do Comitê Gestor da Internet brasileiro
 Task Force IPv6 Portuguesa
 IPv6 na RCTS
 Sítio Internet sobre o IPv6 do LACNIC
 Projeto português da Escola Superior de Tecnologia e Gestão de Leiria
 Capítulo online sobre IPv6 do livro "Redes, Guia Prático"
 Estatísticas sobre a exaustão do IPv4
 Diferenças entre IPv4 e IPv6
Internet Control Message Protocol

ICMP, sigla para o inglês Internet Control Message Protocol, é um protocolo
integrante do Protocolo IP, definido pelo RFC 792, é utilizado para fornecer relatórios
de erros à fonte original. Qualquer computador que utilize IP precisa aceitar as
mensagens ICMP e alterar o seu comportamento de acordo com o erro relatado. Os
gateways devem estar programados para enviar mensagens ICMP quando receberem
datagramas que provoquem algum erro.
As mensagens ICMP geralmente são enviadas automaticamente em uma das seguintes

situações:
 Um pacote IP não consegue chegar ao seu destino (i.e. Tempo de vida do pacote
expirado)
 O Gateway não consegue retransmitir os pacotes na frequência adequada (i.e.
Gateway congestionado)
 O Roteador ou Encaminhador indica uma rota melhor para a máquina a enviar
pacotes.
Ferramentas comumente usadas em Windows baseadas nesse protocolo são: Ping e

Traceroute.
Alguns firewalls, geralmente instalados em servidores Windows ou Unix, bloqueiam as

respostas (ICMP Reply), dificultando o Ping e o Traceroute (tracert). Isso por diversas
razões. Uma delas é para bloquear os ataques de hackers, que consiste na sobrecarga da
memória, enviando dados (em ping) até o sistema não ter a capacidade de administrar
suas próprias funções. Esse ataque é significativo, principalmente contra usuários do
Microsoft Windows 95.
Frames ICMP (1)
 Echo Request / Reply

Mensagens para funções de teste e controle da rede, caso a maquina esteja ligada ira
responder com um reply e se estiver inalcançavel request;
Usadas pelo comando PING
 Destination Unreachable
Enviado por um router que deixa fora um Datagrama;
Tipo de mensagem que é obtida quando não se consegue localizar o equipamento alvo;
(nem todos os datagramas perdidos são detectados)
 CODE - Indica a razão da perda do datagrama

 Timestamp Request / Reply
Mensagens para sincronização dos relógios das máquinas
ICMPv6
Internet Control Message Protocol Version 6 (ICMPv6) ou ICMP para IPv6 é a
nova versão do ICMP. ICMPv6 é definido pela RFC 4443. O ICMPv6 é parte integral
da arquitetura IPv6 que precisa ser suportada completamente por todas as
implementações IPv6.
Ligações externas
 IANA: Parametros do ICMPv6
Este artigo sobre Informática é um esboço. Você pode ajudar a Wikipédia expandindo-o.
Camada de link de dados

Neighbor Discovery Protocol
O Neighbor Discovery Protocol (representado por NDP, ou ND), ou Protocolo para a
descoberta de vizinhos, [1] é um protocolo do TCP/IP usado com o IPv6. Ele opera na
camada de rede do modelo Internet (RFC 1122), e é responsável pela autoconfiguração
de endereço dos nós, descoberta de outros nós na rede local, determinação de endereços
de outros nós, detecção de endereços duplicados, localização de roteadores e de
servidores DNS disponíveis, descoberta de prefixos de endereços, e pela manutenção da
informação sobre os outros nós vizinhos que estejam ativos [2]
O protocolo define cinco tipos diferentes de pacotes ICMPv6 para realizar funções para
IPv6 similares para aos protocolos do IPv4 Address Resolution Protocol (ARP) e dos
recursos Router Discovery e Router Redirect de seu Internet Control Message Protocol,
ou ICMP. Além disso, ele oferece muitas outras melhorias em relação a seus similares
do IPv4, como se vê na seção 3.1 da RFC 4861. Por exemplo, ele inclui Neighbor
Unreachability Detection (NUD), ou detecção de vizinhos inalcançáveis. Por isso,
melhora a robustez da entrega de pacotes na presença de problemas em roteadores ou
links, ou de nós móveis.
A extensão do protocolo Inverse Neighbor Discovery (IND), ou "descoberta inversa de

vizinhos" (RFC 3122), permite que os nós determinem e anunciem um endereço IPv6
correspondente a um dado endereço da camada de enlace de dados, de modo similar ao
Reverse ARP para IPv4.O SEND, ou protocolo seguro para descoberta de vizinhos, uma
extensão do NDP, usa CGA (ou endereços gerados criptograficamente) e RPKI (ou
recursos de criptografia de chave pública) para trazer segurança ao NPD com um
método criptográfico que é independente do IPSec. O ND Proxy (Neighbor Discovery
Proxy) oferece um serviço similar ao Proxy ARP do IPv4, e permite fazer bridges ou
pontes de rede, de múltiplos segmentos de rede em um único prefixo de sub-rede,
quando não é possível estabelecer pontes na camada de enlace.
Referências
1.
 Network Working Group; Thomas Narten; Erik Nordmark; William Allen Simpson; Hesham
Soliman (1 de março de 2005). «Protocol Overview». ietf.org. The Internet Engineering Task
Force (IETF). p. 3. Consultado em 7 de junho de 2016. Cópia arquivada em 2 de setembro de
2007
2.  RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten et al. (September
2007)
Address Resolution Protocol

Address Resolution Protocol (ARP), em português Protocolo de Resolução de
Endereços, é um protocolo de telecomunicações usado para resolução de endereços da
camada de Internet em endereços da camada de enlace, uma função crítica em redes de
múltiplos acessos. O ARP foi definido pela RFC 826 em 1982,[1] é o Padrão Internet
STD 37, e também é o nome do programa para manipulação desses endereços na
maioria dos sistemas operacionais.
O ARP é usado para mapear um endereço de rede (por exemplo, um endereço IPv4)
para um endereço físico como um endereço Ethernet (também chamado de endereço
MAC). ARP foi implementado com muitas combinações de tecnologias da camada de
rede e de enlace de dados, como IPv4, Chaosnet, DECnet e Xerox PARC Universal
Packet (PUP) usando padrões IEEE 802, FDDI, X.25, Frame Relay e Asynchronous
Transfer Mode (ATM). IPv4 sobre IEEE 802.3 e IEEE 802.11 é o caso mais comum.
Em redes Internet Protocol Version 6 (IPv6), a funcionalidade do ARP é fornecida pelo

Neighbor Discovery Protocol (NDP).
Índice
 1 Escopo de operação
 2 Proxy ARP
 3 Ver também
 5 Notas e Referências
Escopo de operação
O Address Resolution Protocol é um protocolo de requisição e resposta que é executado

encapsulado pelo protocolo da linha. Ele é comunicado dentro dos limites de uma única
rede, nunca roteado entre nós de redes. Esta propriedade coloca o ARP na camada de
enlace do conjunto de protocolos da Internet, enquanto que no modelo Open Systems
Interconnection (OSI), ele é frequentemente descrito como residindo na Camada 3,
sendo encapsulado pelos protocolos da Camada 2. Entretanto, o ARP não foi
desenvolvido no framework OSI.
Proxy ARP
O Proxy ARP é uma variação do ARP. Ele possibilita que uma organização possua
somente um endereço IP para suas diversas redes.
Nesse caso, todas as redes estão conectadas a um router. Quando um host quiser se
comunicar com um host de outra rede (sem saber seu endereço MAC), ele irá despejar
um pacote com o número IP do host destino. Mas nesse caso o pacote é interceptado
primeiramente pelo router, que retorna ao host destino seu próprio endereço MAC. A
informação subseqüente será então orientada para o router, que a redirecionará para o
host destino, de acordo com a sua própria tabela de endereços.
Ver também
 Routing
 Redes de computadores
 Protocolo
 MAC
Ligações externas
 RFC 826
 DHCP
Notas e Referências
1.
1. David C. Plummer (novembro de 1982). «RFC 826, An Ethernet Address Resolution

Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for
Transmission on Ethernet Hardware». Internet Engineering Task Force, Network
Working Group
Este artigo sobre redes de computadores é um esboço. Você pode ajudar a Wikipédia
expandindo-o.
Protocolo de tunelamento
Redes de computadores utilizam um protocolo de tunelamento quando um protocolo
de rede (o protocolo de entrega) encapsula um protocolo de carga diferente. Por meio
da utilização de tunelamento pode-se, por exemplo, transportar uma carga (dados) sobre
uma rede de entrega incompatível, ou fornecer um caminho seguro através de uma rede
não confiável. Lembra a ideia de um túnel entre uma origem e um destino.
Tunelamento normalmente contrasta com um modelo de protocolo em camadas como

aqueles do modelo OSI ou TCP/IP. Geralmente, o protocolo de entrega opera em um
nível igual ou maior no modelo em que o protocolo de carga opera.
Em se tratando de um ramo do protocolo TCP/IP, o SSH e o Telnet, pode-se criar uma

conexão entre dois computadores, intermediada por um servidor remoto, fornecendo a
capacidade de redirecionar pacotes de dados. Por exemplo, se alguém se encontra dentro
de uma instituição cuja conexão à Internet é protegida por um firewall que bloqueia
determinadas portas de conexão, não será possível, por exemplo, acessar e-mails via
POP3, o qual utiliza a porta 110, nem enviá-los via SMTP, pela porta 25.
As duas portas essenciais são a 80, para HTTP e a 443, para HTTPS, as quais garantem
uma navegação em páginas da Web sem restrições. Para evitar conexões indesejadas ou
que comprometam a segurança da instituição as demais portas não são abertas pelo
administrador de rede. Contudo, isso compromete a dinamicidade de aplicações na
Internet. Um funcionário ou aluno que queira acessar painéis de controle de sites,
arquivos via FTP ou amigos via Instant Messengers, por exemplo, não terá a capacidade
de fazê-lo, uma vez que as respectivas portas para seus funcionamentos estão
bloqueadas.
Para quebrar essa imposição rígida, porém necessária, o SSH oferece o recurso do
Túnel. O processo se caracteriza por duas máquinas ligadas ao mesmo servidor SSH,
que faz apenas o redirecionamento das requisições do computador que está sob firewall.
O usuário envia para o servidor um pedido de acesso ao servidor pop.xxxxxxxx.com
pela porta 443 (HTTPS), por exemplo. Então, o servidor acessa o computador remoto e
requisita a ele o acesso ao protocolo, retornando um conjunto de pacotes referentes à
aquisição. O servidor codifica a informação e a retorna ao usuário via porta 443. Sendo
assim, o usuário tem acesso a toda a informação que necessita.
É importante salientar que a prática do Tunnelling não é ilegal caso o fluxo de conteúdo
esteja de acordo com as normas da instituição.
Índice
 1 IP tunneling
 2 Proxy tunnel
o 2.1 Recursos
IP tunneling
Um IP Tunnel é um termo técnico para designar o encapsulamento de um pacote IP

dentro de outro com o propósito de simular uma conexão física entre duas redes remotas
através de uma outra rede.
Este processo é frequentemente usado com o protocolo IPsec para criar um meio de
conectar duas redes usando uma VPN. O meio para que essas duas redes se vejam é,
tipicamente, a Internet. Dessa forma o fator limitador que é a distância é praticamente
eliminado, permitindo a utilizadores de uma rede dispôr dos recursos de outra rede
remota como se fossem locais.
Proxy tunnel
Um proxy tunnel é uma conexão SSH criada por meio de um proxy até um host com um
servidor SSH. Através desse túnel podem ser trafegadas quaisquer informações sem
possibilidade de bloqueio do proxy por filtro de conteúdo, uma vez que todos os dados
estão criptografados.
O túnel proxy pode ser criado em cima de qualquer tipo de socket proxy ou http proxy
que permita conexões SSL (https).
Recursos
A conexão SSH permite a associação de portas em cada ponta, assim abrindo um novo
gateway TCP em uma porta específica e ainda permite o uso de portas dinâmicas em
uma das pontas, ou seja, através de uma porta estática pode-se sair em qualquer porta
solicitada na outra ponta.
Claro como parece, toda rede com um proxy com suporte a SSL é passível de bypass
em seu firewall.
Obviamente com uma conexão fechada de ponta a ponta o acesso também pode ser feito
de fora para dentro, e um serviço interno de rede pode ser exposto para fora da rede com
túnel proxy reverso.
A única forma de filtrar esse tipo de acesso é negar por padrão qualquer conexão SSL
via proxy e liberar sites com SSL sob demanda.
Ligações externas
 Artigo sobre proxy túnel

 Como configurar proxy tunel usando o PuTTY(Animação em flash)
Layer 2 Tunneling Protocol

Em rede de computadores, Layer 2 Tunnelling Protocol (L2TP), em português
Protocolo de Tunelamento de Camada 2, é um protocolo de tunelamento usado para
suportar redes virtuais privadas (VPNs) ou como parte da entrega de serviços pelos
provedores de serviços de internet (ISPs). Ele não fornece qualquer encriptação ou
confidencialidade por si mesmo, em vez disso, ele conta com um protocolo de
encriptação que passa dentro do túnel para fornecer privacidade.[1]
História
Publicado em 1999 quando foi proposto o padrão RFC 2661, o L2TP tem sua origem
primeiramente em dois protocolos de tunelamento antigos para comunicação ponto a
ponto: Layer 2 Forwarding Protocol (L2F) da Cisco e o Point-to-Point Tunnelling
Protocol (PPTP) da Microsoft. Uma nova versão deste protocolo, o L2TPv3 surgiu
quando foi proposto o padrão RFC 3931 em 2005. O L2TPv3 fornece recursos de
segurança adicionais, encapsulamento melhorado e a capacidade de conduzir outros
enlaces de dados além do Protocolo Ponto a Ponto (PPP) sobre uma rede IP (por
exemplo: Frame Relay, Ethernet, ATM, etc.).
Referências
1.
1. IETF (1999), RFC 2661, Layer Two Tunnelling Protocol "L2TP"
[Esconder]
v • e
Rede privada virtual

 SSTP
 IPsec
 L2TP
 L2TPv3
 PPTP
Protocolos de comunicação
 Split tunneling
 SSL/TLS
 (Oportunístico:
tcpcrypt)
 Cloudvpn
 FreeS/WAN
 Libreswan
 n2n
 OpenConnect
 OpenIKED
 Openswan
Software Livre  OpenVPN
 Social VPN
 SoftEther VPN
 strongSwan
 tcpcrypt
 tinc
 VTun
 Layer 2 Forwarding
Protocol
Protocolos implementados por fabricantes
 DirectAccess
 Avast SecureLine
 Check Point VPN-1
 Cisco Systems VPN
Client
Software Proprietário  Hamachi
 Microsoft
Forefront Unified
Access Gateway
Vetores de Risco  Filtro de conteúdo

 Inspeção profunda
de conteúdo
 Inspeção profunda
de pacotes
 Bloqueio de
endereço IP
 Enumeração de
redes
 Stateful firewall
 TCP Reset
 Bloqueio de VPN
expandindo-o.
Point-to-Point Protocol
Em redes de computadores, o Point-to-Point Protocol (PPP), em português Protocolo
ponto-a-ponto é um protocolo de enlace de dados (camada 2) usado para estabelecer
uma conexão direta entre dois nós. Ele pode fornecer autenticação de conexão,
criptografia de transmissão (usando ECP, RFC 1968) e compressão.
O PPP é usado sobre muitos tipos de redes físicas incluindo cabo serial, linha telefônica,
linha tronco, telefone celular, enlaces de rádio especializados e enlaces de fibra ótica
como SONET. O PPP também é usado sobre conexões de acesso à Internet. Provedores
de serviços de Internet têm usado o PPP para acesso discado à Internet pelos clientes,
uma vez que pacotes IP não podem ser transmitidos sobre uma linha de modem por si
próprios, sem algum protocolo de enlace de dados.
Dois derivados do PPP; o Point-to-Point Protocol over Ethernet (PPPoE), em português

protocolo ponto a ponto sobre Ethernet, e Point-to-Point Protocol over ATM
(PPPoA), em português Protocolo ponto a ponto sobre ATM, são usados mais
comumente por Provedores de Serviços de Internet para estabelecer uma conexão de
serviços de Internet de Linha Digital de Assinante (ou DSL) com seus clientes.
A MIB para o PPP, identificada pela OID [1.3.6.1.2.1.10.23], é constituida de diversos

grupos definidos em RFC's distintas. Os mais comumente conhecidos são:
 PPP Link Group: composto por uma tabela de status da conexão (Link Status Table) e
por uma tabela de configuração com parâmetros sugeridos (Link Configuration Table).
 PPP Link Quality Report Group: composto por uma tabela de parâmetros e estatística
(número de: pacotes enviados e recebidos, pacotes com erros e descartados, e
pacotes válidos) e por uma tabela de configuração, que contém informações acerca da
qualidade da conexão.
 PPP Security Table: composta por variáveis de configuração e controle relacionadas
com as funcionalidades de segurança do PPP.
 PPP IP Group: composta por variáveis de configuração, status e controle relacionadas
com uso do protocolo IP sobre o PPP.
 PPP Bridge Group: composta por variáveis de configuração, status e controle
relacionadas com uso de funcionalidade de Bridge sobre o PPP.
NCP – Network Control Protocol
O NCP é composto por uma família de protocolos de rede. Ele estabelece e configura os
diferentes protocolos na camada de rede que serão utilizados pelo PPP.
Links ponto-a-ponto tendem a agravar alguns problemas comuns a diversas famílias de

protocolos de rede. Por exemplo, atribuição e gerenciamento de endereços IP é
especialmente difícil sobre circuitos comutados com links ponto-a-ponto. Estes
problemas são tratados pela família de Network Control Protocols (NCPs), onde é
necessário um gerenciamento específico para cada problema.
Métodos de autenticação do PPP

PAP
O PAP (Password Authentication Protocol) usa um método simples de senha que é

enviado em texto puro pelo host remoto.
CHAP
O CHAP (Challenge Handshake Authentication Protocol) usa um método de senha

criptografada, onde o host local envia um "challenge" para o host remoto, que responde
enviando o login e senha.
Este artigo sobre Informática é um esboço. Você pode ajudar a Wikipédia expandindo-o.
Media Access Control

Media Access Control ou MAC (Português: Controle de Acesso ao Meio) é um termo
utilizado em redes de computadores para designar parte da camada de enlace, camada
número 2 segundo o modelo OSI. É provedora de acesso a um canal de comunicação e
o endereçamento neste canal possibilitando a conexão de diversos computadores numa
rede.
O endereçamento é realizado pelo endereço MAC ou também chamado endereço físico

que consiste em um número único a cada dispositivo de rede possibilitando o envio de
pacotes para um destino especificado mesmo que esteja em outra subrede. Atua como
interface entre a LLC e a camada física provendo uma emulação de comunicação full
duplex.
expandindo-o.

Definição Das Sete Camadas Do Modelo OSI e Explicação de Suas Funçõe1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Definição Das Sete Camadas Do Modelo OSI e Explicação de Suas Funçõe1

Enviado por

Direitos autorais:

Formatos disponíveis

Definição das sete camadas do modelo OSI e

explicação de suas funções

 Vínculo de Dados (Enlace)

A camada física, a camada inferior do modelo OSI, está encarregada da transmissão

 Codificação de dados: modifica o padrão de sinal digital simples (1s e 0s)

 Como a estação de recepção sabe quando um "tempo de bit"

 Como a estação de recepção delimita um quadro

 Conexão com o meio físico, acomodando várias possibilidades no meio:

 Um transceptor externo (MAU) será usado para conexão com o

 Quantos pinos têm os conectores e para o quê cada um deles é

 Técnica de transmissão: determina se os bits codificados serão transmitidos

 Transmissão de meio físico: transmite bits como sinais elétricos ou ópticos

 Quais opções de meio físico podem ser usadas

 Quantos volts/db devem ser usados para representar um

CAMADA DE VÍNCULO DE DADOS (Enlace)

A camada de vínculo de dados proporciona uma transferência de quadros de

 Estabelecimento e término do vínculo: estabelece e finaliza o vínculo lógico

 Controle de tráfego de quadros: instrui o nó de transmissão a se "retirar"

 Sequenciamento de quadros: transmite/recebe quadros sequencialmente.

 Delimitação de quadros: cria e reconhece limites de quadros.

 Verificação de erros de quadro: verifica a integridade dos quadros recebidos.

 Gerenciamento do acesso à mídia: determina quando o nó "tem o direito"

A camada de rede controla a operação da sub-rede, decidindo que caminho físico

 Roteamento: roteia quadros entre redes.

 Controle do tráfego da sub-rede: roteadores (sistemas intermediários da

 Fragmentação de quadros: se ela determinar que o tamanho da unidade

 Mapeamento de endereços lógicos/físicos: converte endereços lógicos, ou

 Contabilidade de uso da sub-rede: tem funções de contabilidade para

O software de camada de rede deve criar cabeçalhos para que o software de

A camada de transporte garante que as mensagens sejam entregues sem erros, em

O tamanho e a complexidade de um protocolo de transporte depende do tipo de

A camada de transporte fornece o seguinte:

 Segmentação de mensagens: aceita uma mensagem da camada acima dela

 Confirmação de mensagem: fornece uma entrega completa e confiável de

 Multiplexação de sessão: multiplexa vários fluxos de mensagem ou sessões

Normalmente, a camada de transporte pode aceitar mensagens relativamente

As informações de cabeçalho da camada de transporte devem então incluir

Camadas de ponta a ponta

A camada de sessão permite o estabelecimento da sessão entre processos em

 Estabelecimento, manutenção e término de sessões: permite que dois

 Suporte a sessões: realiza as funções que permitem que esses processos se

A camada de apresentação formata os dados a serem apresentados na camada de

A camada de apresentação fornece:

 Conversão de códigos de caractere: por exemplo, ASCII para EBCDIC.

 Conversão de dados: ordem de bits, ponto de CR-CR/LF, flutuante inteiro e

 Compactação de dados: reduz o número de bits que precisam ser

 Criptografia de dados: criptografa dados para fins de segurança. Por

A camada de aplicativo serve como a janela onde os processos de aplicativos e

 Redirecionamento de dispositivo e o compartilhamento de recursos

 Acesso remoto a arquivos

 Acesso de impressora remota

 Comunicação entre processos

 Mensagens eletrônicas (como email)

 Terminais de rede virtuais

Camada física refere-se, em informática, à consideração dos componentes

- IrDA: (Infrared Data Association) é um grupo de interesse da indústria orientada que

- USB: Padrão que define os cabos, conectores e protocolos usados para a

- EIA (Electronic Industries Alliance): Organização que cuida para que as normas

- SONET / SDH (Synchronous Digital Hierarchy): São padrões para a transferencia de

DSL: Tecnologias que permitem o acesso a internet através da transmissão digital de

ISDN: É um conjunto de padrões de comunicação simultânea digital, transmissão de

T1: É um método de transmissão digital para multiplexar canais de voz ou de dados

SONET/SDH: Padrões de multiplexação de protocolos que transferem várias fluxos