Você está na página 1de 75

Redes de computadores

PDF gerado usando o pacote de ferramentas em código aberto mwlib. Veja http://code.pediapress.com/ para mais informações.
PDF generated at: Fri, 18 Jul 2014 02:40:46 UTC
Conteúdo
Páginas
Introdução 1
Arquitetura de redes de computadores 3
Protocolos e serviços de rede 5
Meios físicos de transmissão 8
Comutação de circuitos e de pacotes 11
Pilha de protocolos da Internet 16
História da Internet 20
ATM 22
Camada de rede 23
Protocolo IP 23
Camada de transporte 26
Multiplexação e demultiplexação 28
Protocolo UDP 32
Transmissão de dados confiável 36
Protocolo TCP 40
Controle de congestionamento 47
Camada de aplicação 49
HTTP 54
FTP 57
Correio eletrônico 58
DNS 63
Programação com sockets 67

Referências
Fontes e Editores da Página 71
Fontes, Licenças e Editores da Imagem 72

Licenças das páginas


Licença 73
Introdução 1

Introdução
O que é uma Rede de Computadores?
A última coisa que devemos entender ao começar a estudar redes é entender o que é uma rede. Quando falamos em
redes de computadores, a maioria das pessoas pensa em uma série de computadores ligados entre si por meio de
cabos para trocarem dados ou então pensa em grandes redes como a internet. A disciplina de Redes de
Computadores de fato estuda estas coisas, mas ela também estuda muito mais coisas, pois o assunto de redes de
computadores é algo bastante amplo e possui uma quantidade enorme de aplicações.
Uma boa definição de Rede de Computadores é: Uma rede de computadores é um conjunto de dois ou mais
dispositivos (também chamados de nós) que usam um conjunto de regras (protocolo) em comum para compartilhar
recursos (hardware, troca de mensagens) entre si, através de uma rede.
Perceba que qualquer tipo de dispositivo capaz de enviar ou receber dados pode ajudar a compor uma rede, não
apenas um computador. Por essa razão, quando falamos em componentes de rede, nos referimos à eles como nós, e
não computadores. Como exemplo de Redes, podemos citar:
• A Internet
• Uma rede local de uma empresa
• Uma rede de telefonia
Como exemplo de nós que vemos com frequência conectados à uma rede, podemos citar:
• Terminais de computadores
• Impressoras
• Computadores
• Repetidores
• Pontes
• Roteadores
• Chaves
Abaixo veremos alguns termos e expressões que são essenciais para que possamos estudar redes de computadores:
• Endereçamento: Isso significa alocar um endereço para cada nó conectado a uma rede. Um exemplo é o usado
pelas redes de telefonia, onde cada aparelho de telefone possui o seu próprio número.
• Meio: O ambiente físico usado para conectar os nós de uma rede. O meio de uma rede pode ser algum tipo de
cabo ou através de ondas de rádio ou outro tipo de radiação eletromagnética.
• Protocolo: Um protocolo são algumas regras que os nós devem obedecer para se comunicarem uns com os
outros. O que eles fazem é criar uma linguagem comum entre diferentes máquinas. De forma geral, ele é um
conjunto de regras, especificações e procedimentos que devem governar entidades que se comunicam entre si. Por
exemplo, quando conversamos com alguém, devemos sempre esperar a pessoa terminar de falar para que
possamos dizer algo também. Não é permitido começar a falar ao mesmo tempo que outra pessoa. Isso é um
exemplo de protocolo usado por humanos para que eles possam conversar. Da mesma forma, também somos
obrigados a seguir protocolos diferentes em festas, ocasiões formais ou reuniões executivas. Como exemplos de
protocolos que regem a comunicação entre computadores, podemos citar o TCP/IP (Transmission Control
Protocol/ Internet Protocol') - um protocolo para controle de transmissão e para a internet, o FTP (File Transfer
Protocol) - um protocolo para a transmissão de arquivos entre computadores, HTTP (HyperText Transfer
Protocol) - protocolo de transmissão de hiper-textos e o protocolo Google Talk - conjunto de protocolos de rede
usado pelo Google. Protocolos são tão importantes que às vezes é comum chamarmos uma rede pelo nome de seu
protocolo.
Introdução 2

• Roteamento: Rotear significa determinar qual o caminho que um pacote de dados deve tomar ao viajar entre os
nós de origem e destino. Em redes em laço completo no qual todas as máquinas estão conectadas entre si, isto é
uma tarefa fácil. Mas no caso de redes mistas, por exemplo, esta pode ser uma tarefa complicada. Para fazer este
serviço, costuma-se usar unidades de hardware dedicadas chamadas roteadores.

Tipos Básicos de rede

Classificação de redes pela Área Ocupada


Com relação à área que ocupa, uma rede pode ser classificada em:
• Rede Local: (LAN - Local Area Network) Qualquer rede com um raio de 10 Km ou menos. Elas são bastante
usadas para conectar computadores em uma sala, prédio ou campus universitário.
• Rede Metropolitana: (MAN - Metropolitana Area Network) Uma rede que conecta máquinas ao longo de uma
área metropolitana. Por exemplo, considere uma empresa com sedes em vários pontos ao longo de uma metrópole
cujos computadores estejam em rede.
• Rede de Longa Distância: (WAN - Wide Area Network) Qualquer rede que seja maior do que uma Rede Local
descrita acima. Muitas delas são usadas para conectar máquinas entre diferentes cidades, estados ou países. Além
destas duas classificações principais, existem outras:
• Rede Pessoal: (PAN - Personal Area Network) Uma rede doméstica que liga recursos diversos ao longo de uma
residência. Através da tecnologia Bluetooth obtém-se uma rede PAN.
• Rede Global: (GAN - Global Area Network) Coleções de redes de longa distância ao longo do globo
• Rede de Armazenamento de Dados (SAN - Storage Area Network) Redes destinadas exclusivamente a
armazenar dados.

Classificação de redes pela Topologia


Outra forma muito usada de se classificar redes é pela
sua topologia. Ou seja, a forma pela qual os
computadores se conectam entre si. De acordo com a
topologia, elas podem ser classificadas em:
• Rede Ponto-a-Ponto: Neste tipo de rede, cada
máquina só tem a capacidade de se comunicar com
máquinas adjacentes entre si. Por exemplo, suponha
que existem os nós A, B e C. A só pode se
Diversas topologias de rede.
comunicar com B, B pode se comunicar com A e C
enquanto C só pode se comunicar com B. Nessa
rede, se o nó A deseja se comunicar com C, a sua mensagem deve obrigatoriamente passar por B. Esta é uma rede
ponto-a-ponto. No desenho mostrado ao lado, todas as redes são ponto-a-ponto, com exceção da última. Existem
alguns tipos especiais de redes deste tipo:

• Rede em Estrela: Neste tipo de rede, existe um nó central que é adjacente à todos os outros. Já os outros nós,
não possuem adjacência entre si, somente com o nó central. O dispositivo que costuma ser usado como nó
central deste tipo de rede é o Hub. A terceira rede mostrada no desenho ao lado é uma rede deste tipo.
• Rede em Laço: São semelhantes às Redes Estrela, mas nelas não existe um nó central. Ele é substituído por
um cabeamento dedicado. Um tipo de Rede em Laço é a Rede em Anel. Nela, todas as máquinas ligam-se à
outras duas formando um circuito fechado. As informações podem ser passadas tanto em sentido horário, como
anti-horário. Com isso, a rede não é destruída mesmo que um cabo seja destruído. Outro tipo de Rede em Laço
é o Laço Completo. Nela, todas as máquinas ligam-se entre si. Ela é um tipo de rede cara, mas é bastante
confiável Mesmo que um punhado de cabos sejam destruídos, ela pode continuar funcionando. A Quarta rede
Introdução 3

mostrada no desenho acima é uma Rede em Laço Completo.


• Rede em Árvore: É uma rede na qual os nós estão dispostos de forma hierárquica. Existe um nó-raiz que se
conecta com nós de segundo nível. Estes, por sua vez, conectam-se à nós de terceiro nível e assim por diante.
Um exemplo é a rede do meio da linha de baixo mostrada no desenho acima.
• Redes de Difusão: Neste tipo de rede, sempre que uma máquina envia uma mensagem, esta se propaga ao longo
da rede de forma que todos os nós escutem a mensagem. Uma vantagem deste tipo de rede é que podemos
classificar as suas mensagens em três diferentes tipos: mensagens únicas destinadas á um único nó, múltipla para
um certo número de nós e ampla para todos os nós da rede. Como exemplos deste tipo de rede podemos citar:
• Redes em Barramento: Nesta rede, existe um barramento por onde toda a informação passa e toda vez que
alguém coloca uma informação no barramento, as máquinas conectadas à ele recebem a mensagem. Um
exemplo é a última rede mostrada no desenho acima.
• Redes via Satélite: Neste tipo de rede, existe um satélite capaz de transmitir dados em órbita ao redor da terra.
Em uma determinada região geográfica, todas as máquinas sintonizadas à ele são capazes de receber os dados.

Arquitetura de redes de computadores


O termo redes de computadores está cada vez mais em desuso com as novas tecnologias e dispositivos que estão
sendo interconectados na internet pública. Estes dispositivos conhecidos como sistemas finais não são unicamente
compostos de computadores de mesa mas também de uma grande variedade de equipamentos que incluem telefones
celulares, sistemas de automação residencial ou industrial, computadores portáteis e aparelhos eletrônicos diversos.
Estes sistemas finais são interconectados e percorrem uma rota ou caminho que passa por enlaces de comunicação
(cabos, ondas, fibras ópticas etc) e também por comutadores de pacotes (switches, hubs, roteadores etc). O primeiro
é o meio físico responsável pela transmissão em si enquanto o segundo faz o encaminhamento dos pacotes aos seus
destinos.
Os sistemas finais acessam a internet por meio de ISPs (provedores de serviço de internet) de nível baixo que são
interconectados por ISPs de nível alto, compostos por roteadores e sistemas de fibra óptica de altíssima velocidade,
obedecendo certas convenções de nomeação e endereço a fim de padronizar o acesso à rede.
Os protocolos controlam o envio e recebimento das informações e envolvem todos os dispositivos que compõem a
internet, sendo o mais famoso deles o conjunto de protocolos conhecido como TCP/IP. Este protocolo, cujo nome
vem dos protocolos mais importantes de pilha, TCP e IP, foi desenvolvido originalmente pela Universidade da
Califórnia para o Departamento de Defesa dos EUA (DoD). Atualmente o TCP/IP é o protocolo padrão para redes
locais e remotas.

Topologia
A topologia da rede define o modo como diversos dispositivos computacionais (nós) estão ligados um ao outro. A
topologia de rede mais simples é a que representa dois nós interligados. Esta é a topologia Ponto a Ponto, que pode
ser utilizada também na conexão entre mais de dois nós. Além da ligação Ponto a Ponto há outros exemplos de
topologias, como:
• Topologia em barramento;
• Topologia Anel;
• Topologia em estrela.
Arquitetura de redes de computadores 4

Tipos de cabo
Existem 4 tipos de cabo de rede: Cabo de par trançado não blindado (UTP - Unshielded Twisted Pair), cabo de par
trançado blindado(STP - Shielded Twisted Pair), cabo de fibra óptica e cabo coaxial, que é usado em redes antigas.

Camadas da pilha de protocolos


O TCP/IP foi implementado em uma arquitetura de pilhas, onde cada camada interage com a camada imediatamente
superior ou inferior a ela. A divisão superficial em camadas e alguns protocolos são mostrados abaixo:

Camada Protocolo

4. Aplicação FTP, TORRENT, SMTP, POP3, HTTP

3. Transporte TCP, UDP, DCCP

2. Rede ARP, RARP, IPv4, IPv6

1. Física BLUETOOTH, WIFI, USB, ETHERNET

Descrição do serviço
Através da internet os sistemas finais executam aplicações distribuídas (navegação na web, compartilhamento de
arquivos, jogos em rede, troca de mensagens, aúdio, vídeo etc) que podem se comunicar entre si e dois serviços são
oferecidos a essas aplicações: serviço confiável orientado a conexão TCP (Transmission Control Protocol) e, serviço
não confiável não orientado a conexão UDP (User Datagram Protocol). O primeiro é geralmente mais lento que o
segundo, mas oferece garantia de entrega e integridade dos pacotes a serem transmitidos.
Um dos problemas que a internet enfrenta é que não há garantia de tempo que os pacotes levarão para ser
transmitidos. O usuário pode apenas aumentar a velocidade de tráfego entre sua rede e seu provedor de acesso,
geralmente pagando mais ao seu provedor.

Referência
• Redes de Computadores e a Internet, JAMES F. KUROSE - KEITH W. ROSS
Protocolos e serviços de rede 5

Protocolos e serviços de rede


Podemos pensar em rede de computadores como diversas máquinas interligadas fisicamente entre si onde os seus
utilizadores promovem a troca de informação de seu interesse. Entretanto, uma rede não pode ser bem estabelecida
considerando apenas o hardware como preocupação principal como nas primeiras redes, atualmente o software é
considerado uma das partes mais importantes na concepção de novas tecnologias de redes de computadores.
Protocolo é o conjunto de regras sobre o modo como se dará a comunicação entre as partes envolvidas.
Protocolo é a "língua" dos computadores, ou seja, uma espécie de idioma que segue normas e padrões determinados.
É através dos protocolos que é possível a comunicação entre um ou mais computadores. Os protocolos de rede
nasceram da necessidade de conectar equipamentos de fornecedores distintos, executando sistemas distintos, sem ter
que escrever a cada caso programas específicos. Ambos os computadores devem estar configurados com os mesmos
parâmetros e obedecer aos mesmos padrões para que a comunicação possa ser realizada sem erros. Existem diversos
tipos de protocolos de rede, variando de acordo com o serviço a ser utilizado. De maneira geral há dois tipos de
protocolos: Abertos e Proprietários ou Específicos. Os protocolos Abertos são os protocolos padrões da internet. Este
podem comunicar com outros protocolos que utilizam o mesmo padrão de protocolo. Um exemplo seria o TCP/IP,
pois ele pode comunicar com várias plataformas como Windows, Linux, Mac e outros. Já os protocolos Proprietários
são feitos para ambiente específicos (daí o seu nome), pois ele apenas pode comunicar com uma plataforma padrão.
Exemplos desse tipo de protocolo: IPX/SPX, NETBIOS e outros. São exemplos de protocolos de rede: IP (Internet
Protocol), DHCP (Dynamic Host Configuration Protocol), TCP (Transmission Control Protocol), HTTP (Hypertext
Transfer Protocol), FTP (File Transfer Protocol), Telnet (Telnet Remote Protocol), SSH (SSH Remote Protocol),
POP3 (Post Office Protocol 3), SMTP (Simple Mail Transfer Protocol), IMAP (Internet Message Access Protocol).

Funções dos Protocolos


Uma das funções dos protocolos é pegar os dados que serão transmitidos pela rede, dividir em pequenos pedaços
chamados pacotes, na qual dentro de cada pacote há informações de endereçamento que informam a origem e o
destino do pacote. É através do protocolo que as fases de estabelecimento, controle, tráfego e encerramento,
componentes da troca de informações são sistematizadas. O protocolo desempenha as seguintes funções:
• Endereçamento: especificação clara do ponto de destino da mensagem
• Numeração e sequencia: individualização de cada mensagem, através de número sequencial
• Estabelecimento da conexão: estabelecimento de um canal lógico fechado entre fonte e destino
• Confirmação de recepção: confirmação do destinatário, com ou sem erro, após cada segmento de mensagem
• Controle de erro: detecção e correção de erros
• Retransmissão: repetição da mensagem a cada recepção de mensagem
• Conversão de código: adequação do código às características do destinatário
• Controle de fluxo: manutenção de fluxos compatíveis com os recursos disponíveis

Hierarquia
Como já foi visto um protocolo é um conjunto de regras sobre o modo como se dará a comunicação entre as partes
envolvidas. Com o intuito de reduzir a complexidade do projeto, a maioria das redes foi organizada como uma série
de níveis ou camadas, que são colocadas uma sobre a outra. O número, o nome, o conteúdo e a função de cada
camada difere de uma rede para outra. Em todas as redes, no entanto, o objetivo de cada camada é oferecer
determinados serviços para as camadas superiores. A camada n de uma máquina comunica-se com a camada n de
outra máquina. Para isso acontecer, ela baseia-se num conjunto de convenções e regras que vão permitir gerenciar
esta comunicação na qual foi nomeada de protocolo da camada n, ou, simplesmente, protocolo n.
Protocolos e serviços de rede 6

As entidades que ocupam as mesmas camadas em diferentes máquinas são chamadas de PARES. São os pares que se
comunicam utilizando o protocolo. Os dados não são transferidos diretamente entre os pares, pois não existe meio
físico entre eles. Então cada camada transfere os dados para a camada inferior a ela, até alcançar a última camada.
Após a última camada está o meio físico (meio de transmissão) através do qual se dá a comunicação.
Em cada par de camadas adjacentes, há uma INTERFACE (Define as operações e serviços que a camada inferior
tem a oferecer para a camada superior a ela). Ao conjunto das camadas compondo uma rede dá-se o nome de
arquitetura da rede. As especificações da arquitetura devem conter informações suficientes para permitir o correto
desenvolvimento da rede, tanto do ponto de vista do software quanto do hardware. Por outro lado, os detalhes de
implementação dos mecanismos em cada camada, assim como as especificações detalhadas das interfaces não fazem
parte da definição da arquitetura da rede.
Resumindo, o protocolo é um conjunto de regras que controlam o formato e o significado das informações trocadas
pelas entidades pares contidas numa camada, sendo que as entidades utilizam protocolos com a finalidade de
implementar as suas definições de serviços e as entidades têm a liberdade de trocarem os seus protocolos, desde que
não alterem o serviço visível para os seus utilizadores.

Serviços de Rede
Um serviço de rede é um conjunto de operações implementado por um protocolo através de uma interface, e é
oferecido à camada imediatamente superior. Ele define o que uma camada é capaz de executar sem se preocupar com
a maneira pela qual as operações serão executadas.
Cada serviço é utilizado por aplicações diferentes, podendo uma aplicação utilizar vários serviços, como, por
exemplo, um browser como o Mozilla Firefox. Este utiliza, por exemplo, HTTP, SHTTP, DNS.
Os serviços podem ser orientados a conexão ou não. Serviços relacionados à família TCP são orientados a conexão,
enquanto serviços relacionados ao protocolo UDP são sem conexão.
Protocolos e serviços de rede 7

Classificação de serviços
• Serviços orientados a conexão: é o serviço TCP. Antes do envio de dados, um processo conhecido como
handshaking cria uma conexão fraca entre os hosts. Basicamente, esse processo prepara o receptor para a
recepção de pacotes. Esta conexão prévia possibilita verificar se todos os pacotes irão chegar corretamente ao
destino, e em caso negativo, solicitar o reenvio dos mesmos (quando o receptor recebe um pacote, ele envia uma
mensagem de confirmação ao transmissor. Se a confirmação não chegar, o pacote é reenviado), gerando uma
transferência de dados confiável. Também pode fazer-se um controlo de fluxo e congestionamento, para casos em
que o receptor não suporta a velocidade de envio dos pacotes, ou quando algum roteador na rede está
congestionado (é enviada uma mensagem ao transmissor, reduzindo ou interrompendo a velocidade de envio de
pacotes). Como exemplo de serviços orientados a conexão, TCP, temos: HTTP, FTP, Telnet.
• Serviços sem conexão: é o serviço UDP (Protocolo de Datagrama de Usuário). Não há o processo de handshaking.
Assim, uma aplicação apenas envia dados para um host, e com isso não há como saber se todos os pacotes
chegaram. É mais rápido, mesmo por não haver a etapa da handshaking, mas é menos confiável, além de não
possuir a possibilidade de controle de fluxo e congestionamento presentes no TCP. Algumas aplicações que usam
o UDP: conferência de vídeo e telefone por internet.

Existem outros tipos de serviços, como o DHCP, que automaticamente determina um endereço IP válido a cada host
conectado à Internet e o DNS, que possibilita que o utilizador use strings, ao invés de endereços IP para se conectar a
outros servidores. O DNS mantém um banco de dados que relaciona cada string a um endereço IP.
Meios físicos de transmissão 8

Meios físicos de transmissão


Para definir os meios físicos é necessário entender o comportamento dos bits. Um bit viaja partir de um sistema
através de uma série de links e roteadores até atingir o sistema de destino. Nesse caminho, o bit é transmitido
diversas vezes. O sistema de origem transmite o bit, o primeiro roteador recebe o bit e o transmite e assim por diante.
Enquanto viaja da origem para o destino, o bit passa por uma série de transmissores e receptores. Cada bit é enviado
pela propagação de ondas eletromagnéticas ou pulsos ópticos através de um meio físico. Os meios físicos podem ter
formas distintas e não precisam ser do mesmo tipo em todo o caminho. Exemplos de meios físicos incluem
par-trançado, cabo coaxial, cabo de fibra-óptica, espectro de rádio terrestre, e, espectro de rádio por satélite. Os
meios físicos dividem-se em duas categorias: meios encapsulados e não encapsulados. Nos meios encapsulados, as
ondas percorrem um material sólido. Os exemplos desse tipo de meio são: cabo de fibra-óptica, par-trançado e cabo
coaxial. Nos meios não encapsulados, as ondas propagam-se na atmosfera e no espaço. Exemplos: LAN wireless e
canal digital de satélite. O custo do link físico é relativamente baixo comparado a outros custos da rede. O custo de
instalação do link físico pode ser muito superior ao custo do material. Por essa razão, muitos construtores instalam
tipos variados de cabos em todas as salas de um edifício. Mesmo que, inicialmente, só um meio seja usado, existe
uma boa chance de outro meio ser usado no futuro. Dessa forma, economiza-se dinheiro evitando a colocação de fios
no futuro.

Meios Magnéticos
Uma forma muito barata de se transportar dados de um lugar para o outro é através de fitas magnéticas ou discos
flexíveis. Apesar de simples é muito confiável e, dependendo da maneira como é feita, pode ser mais eficaz que
muitos meios de transmissão guiados. Por exemplo, vamos supor que um usuário queira fazer um back-up de seu HD
em outro computador localizado algumas quadras de distância. Um HD de 80 GB portátil leva algumas horas para
ser completamente preenchido em um computador e levando para outro. No entanto, transmitir 80GB em uma
Internet ADSL comum levaria muito mais tempo.

Cabo Coaxial
O cabo coaxial é formado por dois condutores separados e envoltos por um material isolante. O primeiro condutor,
normalmente o cobre, é mais rígido e está envolto pelo segundo condutor, este em forma de malha e normalmente de
alumínio. Este segundo condutor, além de ajudar na transmissão é também responsável por proteger o primeiro
condutor contra interferências magnéticas. O cabo coaxial pode ser classificado de duas formas dependendo do
material do condutor em malha.
Quando este material é o alumínio o cabo é dito Cabo Coaxial Grosso (Resistência de 75 ohms, transmissão numa
velocidade de até 10 mbps a uma freqüência de 10 Ghz). Quando esse material é cobre o cabo é dito Cabo Coaxial
Fino (Resistência de 50 ohms, transmissão numa velocidade de até 10 mbps a uma freqüência de 2 Ghz).
Meios físicos de transmissão 9

Fibra óptica
Os cabos de fibra óptica são filamentos de vidro ou de materiais poliméricos com capacidade de transmitir sinais
digitais sob a forma de sinais luminosos. Tal filamento pode apresentar diâmetros variáveis, dependendo da
aplicação, indo desde diâmetros ínfimos, da ordem de micrômetros (mais finos que um fio de cabelo) até vários
milímetros. Graças a essa característica, são cabos que conseguem ter uma velocidade ilimitada, se comparados com
cabos elétricos.
Também torna seu uso desejável quando existe a necessidade de transmitir dados a grandes distâncias. Outra
característica interessante destes tipos de cabos é que eles não sofrem interferência de campos eletromagnéticos.
São cabos com custo mais alto, e com certa dificuldade de manuseio. Entretanto, seu uso vem se disseminando cada
vez mais, com a necessidade cada vez maior de velocidades mais altas. Seu custo também diminui dia após dia, e a
matéria-prima para a construção do cabo é abundante.
Os cabos de fibra óptica são compostos por dois fios(um para a recepção e outro para a transmisssão) formados por
minúsculos cilindros de vidro. Possui duas camadas: Núcleo (vítreo) e Revestimento (Silicone).

Tipos

Multimodo Degrau
Primeiro tipo de fibra óptica que surgiu, é também o mais simples dos três. Aqui, o núcleo e o revestimento estão
claramente definidos. O núcleo é formado por um único tipo de material, tendo então índice de refração constante, e
diâmetro variável. Os raios de luz refletem no revestimento em vários ângulos, resultando em comprimentos de
caminhos diferentes para o sinal. Isto causa o espalhamento do sinal ao longo do cabo e limita a largura de banda do
cabo. Este fenômeno é chamado de dispersão modal. A atenuação é alta, fazendo com que essas fibras sejam
utilizadas em transmissão de dados em curtas distâncias e iluminação.
Banda: até 35 Mhz.km
Núcleo: entre 50 e 400 mm
Atenuação: maior que 5 dB/km

Multimodo Refração Gradual


Neste tipo de fibra óptica, a interface entre o núcleo e o revestimento é alterada para propiciar índices de refração
diferentes dentro do núcleo e do revestimento. Os sinais luminosos viajam no eixo do cabo encontrando uma grande
refração, tendo uma velocidade de transmissão baixa. Os raios que viajam na mesma direção do cabo tem um índice
de refração menor e são propagados mais rapidamente. Com isso, todos os modos do sinal poderão viajar a uma
mesma velocidade efetiva no cabo, de maneira a reduzir a dispersão modal. É normalmente empregada nas
telecomunicações.
Banda: até 500 Mhz.km
Núcleo:entre 125 e 50 mm
Atenuação: 3 dB/km
Meios físicos de transmissão 10

Monomodo
Com um diâmetro de núcleo diminuto, o índice núcleo/revestimento permite que apenas um modo seja propagado
através da fibra, o que diminui a dispersão do pulso luminoso. A emissão de sinais em fibras do tipo monomodo só é
possível com a utilização de laser. Contudo, o equipamento como um todo é mais caro que o dos sistemas
multimodo. Esse tipo de fibra possui grande emprego em sistemas telefônicos.
Banda: até 100 GHz.km
Núcleo: 8 micrometros (µm)
Atenuação: entre 0,2 dB/km e 0,7 dB/km

Transmissão via rádio


Neste tipo de transmissão utilizamos varias características físicas que as ondas de rádio podem oferecer. Elas são
fáceis de serem geradas, atravessam paredes, contornam objetos, são refletidas pela atmosfera e percorrem longas
distancias. É muito útil quando se quer construir uma rede em regiões onde esticar cabos é coisa complicada, como
em uma cidade cheia de prédios, ou dentro de um prédio ou em regiões montanhosas.
A desvantagem é que é preciso uma visada perfeita (sem obstáculos) para uma boa qualidade de trafego, embora
fatores como chuva, neblina, serração não influenciam a via rádio

Ondas infravermelhas
As ondas infravermelhas são largamente utilizadas em controles remotos, por exemplo. Uma característica
importante desta onda é que ela não pode atravessar objetos sólidos. Assim pode-se construir LAN's mais seguras
contra espionagem eletrônica. Contudo, essas transmissões estão limitadas a cerca de 30 metros, e possui largura de
banda de até cerca de 30Mbps.

Outros meios
As redes também podem ser construídas por outros meios, que agora estão conquistando mercado. Entre eles:

Bluetooth
As redes bluetooth (chamadas de rede PicoNet) tem suas vantagens e desvantagens não estão aqui. Dentre suas
vantagens, está o preço bem acessível dos adaptadores bluetooth, baixo consumo de energia, e a possiblidade de usar
esses mesmos adaptadores para fazer a conexão com diversos gadgtes do dia-a-dia. Como desvantagem, a velocidade
da conexão bluetooth raramente passa de 700kb/s, o alcance é do no máximo 10 metros, e só podem ser ligados 8
acessos simultâneos.

PLC (Power Line Communications)


Pensando na enorme rede elétrica que já existe em todo o mundo, foi desenvolvida essa tecnologia para a
transferência de dados e voz pela rede elétrica. Outra vantagem é a fácil instalação desse tipo de rede. Agora, como
desvantagens, temos a quantidade de interferência que ainda existe nesse meio, e o imenso compartilhamento dele.

USB (Cabo de rede USB)


As portas Universal Serial Bus mais conhecidas como USB, estão presentes em todos os computadores atuais, além
de ser a interface mais utilizada pelos outros periféricos. Para montar uma rede via USB, é necessário um cabo
especial, que possui um hardware controlador de rede, que será o responsável pela criação de uma rede virtual entre
os computadores. Apesar de ter uma alta taxa de transferência, as redes USB são limitadas a conectar apenas duas
máquinas.
Comutação de circuitos e de pacotes 11

Comutação de circuitos e de pacotes


Comutação segundo o dicionário Michaelis [1] significa permutação, substituição. Em computação, a Comutação
de circuitos e pacotes é utilizada, por exemplo, em sistemas de comunicação onde o tráfego é constante.
Uma imagem sobre comutação pode ser encontrada neste link [2].
Autor: David Sudjiman [3]
Website: davidsudjiman.info [4].

Histórico
Inicialmente as redes comutadas surgiram por uma necessidade da área de telecomunicações. Com o surgimento e
ampliação das redes telefônicas, houve a necessidade de interligar os pontos. A princípio eram interligadas uma a
uma, mas esta opção gradativamente tornou-se inviável devido à grande quantidade de fios exigida.
Iniciou-se então a comutação manual onde cada telefone era interligado a uma central com um telefonista e este era
encarregado de transferir a ligação. Porém, era também inconveniente pois além de ter a demora natural do operador,
ainda perdia-se a privacidade, uma vez que o operador poderia ouvir toda a conversa.
Observando a necessidade de um mecanismo mais eficiente, em 1891 foi criada a primeira central telefônica
automaticamente comutada. Para seu funcionamento, foi necessária a adaptação da aparelhagem. Os telefones
passaram a ter o sinal decádico, que representavam os números de 0 a 9. A interpretação dos sinais pelos
comutadores gerava uma cascata interligada destes até o estabelecimento da ligação.
Entre 1970 e 1980 houve o desenvolvimento e implantação de centrais telefônicas eletrônicas, ou seja, os
comutadores operados eletromecanicamente foram substituídos por sistemas digitais operados computacionalmente,
tudo graças às tecnologias de digitalização da voz [5].
A expansão dos conceitos para transmissão de dados foi quase imediata, gerando os paradigmas de comunicação
comutada existentes.
Tambem se divide em sub-etapas:
1. Estabelecimento do circuito
2. Conversação
3. Desconexão do circuito

Comutação por Circuitos


A comutação por circuitos exige que as estações comunicantes possuam um caminho dedicado exclusivo, que pode
ser estabelecido de quatro maneiras:
1. Circuito físico
2. Frequency Division Multiplexing (FDM - multiplexação por canais de frequência)
3. Time Division Multiplexing (TDM - multiplexação por canais de tempo)
4. Statistical Time Division Multiplexing (STDM - multiplexação estatística por canais de tempo)
Este paradigma de comunicação é executado em três passos distintos e específicos:
• Estabelecimento do circuito
• Troca de informações
• Desconexão ponto a ponto
Caso uma destas etapas tenha problemas, há quebra da conexão. Um exemplo claro é uma ligação telefônica, onde
há a necessidade de um canal dedicado em ambos terminais. Outro exemplo é a internet discada.
Comutação de circuitos e de pacotes 12

Circuitos físicos
As vantagens dos circuitos físicos são a exclusividade do canal que agiliza a velocidade de troca de informações e
consequentemente o tempo. A contrapartida é um método oneroso, que exige manutenção individual constante, com
uso excessivo de fiação. É interessante seu uso somente para pequenas aplicações em distâncias curtas, pois sua
expansão é trabalhosa.

FDM - Frequency Division Multiplexing


Imagem de FDM disponível no Flickr [6].
A divisão em canais de frequencia cria circuitos virtuais com banda mais estreita que o canal do comutador com a
rede, de forma que a soma de todos circuitos é igual ou menor à banda do comutador.
A grande vantagem é o uso de menos fiação para promoção do serviço, porém o problema é a rápida saturação dos
canais. Conforme a figura [6] ilustra, os canais necessitam uma banda de comunicação e uma faixa de segurança.
Outro problema está na expansão do sistema: será necessário reconfigurar todos os terminais para as novas larguras
de banda.
Em geral, utiliza-se FDM em sinais analógicos.

TDM - Time Division Multiplexing


Imagem de TDM disponível no Flickr [7].
A divisão de canais no tempo gera circuitos virtuais entre os terminais e o roteador. Este possui um ciclo de tempo
em que deve se comunicar com todas estações. Para tanto, o tempo é alocado igualmente para cada terminal
comunicar-se.
Este método exclui parcialmente o problema da expansibilidade, já que não exige reconfiguração, apenas
disponibilidade de recursos. A disputa ocorre somente no momento da conexão, após estabelecida não há problemas.
O grande problema no entanto é que, conforme a rede aumenta, os recursos são alocados e o tempo de resposta
aumenta aritmeticamente.
Em geral, utiliza-se TDM em sinais digitais.

STDM - Statistical Time Division Multiplexing


Imagem de STDM disponível no Flickr [8].
O método STDM[9] funciona identicamente o método TDM, porém soluciona parcialmente o problema do tempo de
resposta. Ele utiliza métodos estatísticos e diferencia as estações ativas das ociosas. O segundo passo é alocar
recursos somente às estações ativas, e escutar as ociosas, de forma que não seja perdida a conexão com as mesmas.
No entanto, quando todas as estações estão ativas o tempo de resposta se mantém igual ao TDM.
Este procedimento foi denominado Fast Connect Circuit Switching. Um problema do STDM é a perda de conexão.
Caso uma estação ociosa fique ativa e o roteador não possua recursos livres, a conexão é perdida.

Comutação por Pacotes


A comutação por pacotes não exige o estabelecimento de um circuito dedicado para a comunicação, o que implica
menores custos com meios físicos. Este paradigma utiliza a ideia da segmentação de dados em partes discretas,
compostas de cabeçalho (com bits de verificação de integridade), corpo e rodapé (onde é realizada a verificação
cíclica de redundância), que são denominados pacotes [10](ou outros nomes, como quadro, bloco, célula, segmento,
dependendo do contexto).
Neste tipo de comutação é usada a multiplexação estatística (STDM). Diferentemente do paradigma rival (por
circuitos), neste o tempo é alocado para os terminais mais ativos prioritariamente, porém sem o risco da quebra da
Comutação de circuitos e de pacotes 13

conexão.
Um exemplo são as conexões Ethernet, que comutam por pacotes e não perdem conexão.
Os comutadores de pacotes utilizam uma das três técnicas seguintes:
1. Cut-through [11](corte de caminho)
2. Store-and-forward [12](armazena e passa adiante)
3. Fragment-free [13](livre de fragmentos)

Cut-through
Este comutador recebe e armazena apenas parte do cabeçalho (6 primeiros bytes), para saber qual receptor do pacote,
e já encaminha os dados diretamente. A princípio, há um enorme ganho em velocidade. No entanto, por não haver
nenhuma verificação de erros (neste caso a verificação ocorre nos terminais), frequentemente é necessário o reenvio
do pacote. Na prática é muito pouco utilizado sozinho.

Store-and-forward
O comutador recebe e armazena os dados até possuir completamente o pacote em um buffer de entrada. Após, efetua
verificação por erros cíclicos e outros, passa o pacote para o buffer de saída e retransmite o pacote para o outro
comutador ou o terminal. Caso ele encontre algum erro, descarta o pacote.
Este tipo de comutador é mais robusto e eficiente, porém devido ao grande número de requisições geralmente
ocorrem muitos choques de pacotes a atrasos. A implementação mista do store-and-forward e do cut-through é a
configuração mais utilizada.

Fragment-free
O funcionamento deste comutador é muito semelhante ao cut-through, porém ele armazena os 64 primeiros bytes
antes de enviar. Esta implementação é baseada em observações estatísticas: a grande maioria dos erros, bem como
todos os choques de pacotes, ocorrem nos primeiros 64 bytes.

O deslocamento dos pacotes é nó a nó (e não fim a fim como na por circuito), sendo que cada passagem para o
próximo nó é denominada hop. A cada hop o terminal ou comutador transmite apenas um pacote e aguarda para
transmitir o restante.
Há basicamente duas implementações: circuitos virtuais e datagramas.

Circuitos Virtuais [14]


Cada roteador grava em uma tabela seus circuitos virtuais (VCs) e os identifica unicamente (para este comutador,
dois roteadores podem referenciar um terceiro por identificadores diferentes). As tabelas são montadas por ordem
hierárquica, ou seja, dos mais abrangentes para os menos.
Após a identificação e montagem das tabelas, é necessário primeiramente o comutador estabelecer um circuito para
então iniciar a transferência de dados. O circuito implica que todos os pacotes seguirão o mesmo caminho durante a
conexão. Há uma grande desvantagem neste método, pois ele é vulnerável a pontos cegos. Caso um comutador saia
do ar e este faça parte do circuito virtual há uma perda da conexão.
O funcionamento assemelha-se ao sistema de uma transportadora, onde são definidas rotas para a entrega de
mercadorias.
Comutação de circuitos e de pacotes 14

SVC Switched Virtual Circuit[15]


O circuito é estabelecido dinamicamente, sob demanda, e encerrado assim que finda a transmissão. Seu
estabelecimento segue os mesmos passos de uma comutação por circuitos.
A alocação temporária de banda permite a disponibilidade quase constante de recursos, uma vez que assim que
concluída a comunicação é encerrada a conexão. No entanto, há um alto consumo de banda no estabelecimento e no
encerramento dos circuitos, pois é necessário percorrer todos os nós.

PVC Permanent Virtual Circuit[16]


Nesta implementação,permanentemente, ficando dedicado à transferência de dados. Os circuitos virtuais
permanentes (PVC) são bastante utilizados por fornecedores de serviços públicos ATM para criar e estabelecer uma
complexa infra-estrutura baseada em ATM para as respectivas redes internas. Em muitos casos, a infra-estrutura
interna ATM da rede é construída utilizando PVCs com ligações ponto a ponto que ocorrem em circuitos virtuais
comutados (SVC, switched virtual circuit).
Há também um menor consumo de banda no estabelecimento e encerramento da conexão, no entanto a alocação
permanente satura a rede por garantir banda e tráfego constantes.
E é muito utilizada em aplicações que exigem fluxo constante de informações.

Datagramas
A implementação por datagramas permite aos pacotes serem enviados por caminhos diferentes. A cada pacote é
determinada uma rota individual, com base na tabela de roteamento presente em cada comutador e no endereço de
destino. Não é garantida a chegada dos pacotes em ordem, sendo necessário a reorganização após a chegada.
A transmissão dos dados inicia-se imediatamente após hop, e devido ao fato de cada pacote possuir um caminho
distinto os roteadores [17](comutadores) ficam menos sobrecarregados, além de prevenir a perda de conexão.
O funcionamento é semelhante a uma viagem, sabendo o destino e partindo do mesmo local muitos carros podem
fazer diversas rotas e chegarem, sem garantias de ordem de chegada.

Vantagens
• Melhor uso do meio de transmissão
• Melhor eficiência de linha
• Melhora a confiabilidade da transmissão de dados
• Pode não haver tempos de estabelecimento e desconexão de circuito(datagramas)
• Baixo tempo de transmissão desde a origem ao destino
• Os erros não precisam chegar no terminal para serem recuperados
• Possibilidade de armazenar pacotes (transmissão e recepção assíncronos)
• Alteração de encaminhamento em caso de congestionamento
• Possibilidade de aceitar pacotes em situações de trafego intenso, com posterior envio
Comutação de circuitos e de pacotes 15

Desvantagens
• Disputa por banda nó a nó
• Congestionamento excessivo (choque de pacotes e atraso)
• Sem garantia de banda
• Tempos de atraso entre origem e destino variáveis no tempo
• Possibilidade de chegada de pacotes ao destino por ordem diferente da de emissão (datagramas)

Comutação de circuitos vs. Comutação de pacotes [18]


A comutação de circuitos e a comutação de pacotes diferem em diversos aspectos. Nesta seção, faremos uma
comparação entre estas duas técnicas, no que diz respeito a configuração de chamada, forma de envio de
dados/pacotes, suscetibilidade a falhas, congestionamento, transparência e tarifação.
Na comutação de circuitos, é necessário estabelecer, previamente, um caminho fim-a-fim, para que os dados possam
ser enviados. Isso garante que, após a conexão ter sido efetuada, não haverá congestionamento e os dados serão
enviados de forma ordenada. Entretanto, configurar um caminho com antecedência provoca reserva e provável
desperdício de largura de banda. Esse tipo de comutação não é muito tolerante a falhas, sendo que na inatividade de
um switch, os circuitos que o utilizam serão encerrados. Os bits fluem continuamente pelo fio e a tranmissão de
dados é feita de forma transparente, ou seja, o transmissor e o receptor determinam a taxa de bits, formato ou método
de enquadramento, sem interferência da concessionária de comunicações, o que proporciona, por exemplo , a
coexistência de voz, dados e mensagens de fax no sistema telefônico.
Já na comutação de pacotes, não é necessário estabelecer uma comunicação previamente. Assim sendo, diferentes
pacotes poderão seguir caminhos distintos, dependendo das condiçoes da rede no momento em que forem enviados,
não chegando, necessariamente, ao receptor de forma ordenada. Existe, entretanto, a possibilidade de
atraso/congestionamento em todos os pacotes, uma vez que não é reservada, antecipadamente, largura de banda para
a transmissão. Esta técnica é mais tolerante a defeitos e, em caso de inatividade de um switch, os pacotes são
roteados de modo a contornar os inativos. É utilizada a transmissão store-and-forward, na qual os pacotes são
reservados na memória de um roteador, e depois de inspecionados em busca de erros, são enviados ao roteador
seguinte. Por fim, essa transmissão não se dá de forma transparente sendo que os parâmetros básicos, tais como taxa
de bits, formato e método de enquadramento, são determinados pela concessionária de comunicações. No sistema
como um todo, a comutação de pacotes é mais eficiente que a comutação de circuitos.
Após estas comparações, podemos chegar a seguinte conclusão: de uma lado temos um serviço garantido, porém
com desperdício de recursos (comutação de circuitos); de outro, temos serviço não garantido, porém com velocidade
maior e sem desperdício de recursos (comutação de pacotes).

Referências
[1] http:/ / michaelis. uol. com. br/ moderno/ portugues/ index. php?lingua=portugues-portugues& palavra=comuta%E7%E3o
[2] http:/ / www. flickr. com/ photos/ davidsudjiman/ 169238847/
[3] http:/ / www. davidsudjiman. info/ about/
[4] http:/ / www. davidsudjiman. info
[5] http:/ / www. projetoderedes. com. br/ tutoriais/ tutorial_rede_telefonica_comutada_01. php
[6] http:/ / www. flickr. com/ photos/ davidsudjiman/ 169233552/
[7] http:/ / www. flickr. com/ photos/ davidsudjiman/ 169237353/
[8] http:/ / www. flickr. com/ photos/ davidsudjiman/ 169237351/
[9] http:/ / www. davidsudjiman. info/ 2006/ 02/ 06/ fdm-tdm-and-stdm/
[10] http:/ / hsw. uol. com. br/ questao525. htm
[11] http:/ / informatica. hsw. uol. com. br/ lan-switch8. htm
[12] http:/ / informatica. hsw. uol. com. br/ lan-switch8. htm
[13] http:/ / informatica. hsw. uol. com. br/ lan-switch8. htm
[14] KUROSE,J. F.; ROSS,K. W. Redes de Computadores e a Internet - Uma abordagem top-down, 3ª Edição
Comutação de circuitos e de pacotes 16

[15] http:/ / fatosdigitais. wordpress. com/ 2007/ 07/ 24/ redes-wan-basico/


[16] http:/ / fatosdigitais. wordpress. com/ 2007/ 07/ 24/ redes-wan-basico/
[17] http:/ / pt. wikipedia. org/ wiki/ Roteador
[18] TANENBAUM, A. S. Redes de Computadores; 4ª edição

Pilha de protocolos da Internet


Segundo Kurose, "a Internet é um sistema extremamente complicado e que possui muitos componentes."[1]. Para que
um sistema tão complexo possa permitir a comunicação de usuários, independente da plataforma de Software
utilizada, ou meio físico de transmissão, ou mesmo de hardware usado, foi necessário criar padrões e regras. Com
isso, surgiram os protocolos de rede. Segundo definição da CISCO, "um protocolo é uma descrição formal de um
conjunto de regras e convenções que governam a maneira de comunicação entre os dispositivos em uma rede."[2]

Camada de Enlace (CE)


Para que duas máquinas se comuniquem, é necessário haver um certo grau de cooperação. "Em vez de implementar a
lógica para isso como um único módulo, a tarefa é dividida em subtarefas, cada qual implementada
separadamente."[3]. Então desenvolveu-se a arquitetura da Internet em camadas. A modularização facilita o
entendimento das funções e também a detecção de erros. Cada camada tem características próprias.
Assim, surgiu a pilha de protocolos da Internet (ou pilha TCP/IP), que é formada pelos protocolos que regem a
comunicação na Internet. Nessa arquitetura em forma de pilha, as camadas inferiores fornecem serviços às camadas
superiores, de forma que estas não precisem saber o funcionamento de uma camada inferior, apenas conhecer os seus
serviços. Na pilha TCP/IP, o TCP é o principal protocolo da camada de transporte, enquanto que o IP é o responsável
pela camada de redes.
Um exemplo típico da relação entre esses protocolos é a comunicação entre duas pessoas. Uma pessoa pensa em algo
para falar e "processa" o que quer dizer. O cerébro ordena a movimentação das cordas vocais, e depois da boca. O ar
é o responsável por enviar a mensagem até os ouvidos de outra pessoa. A mensagem é então levada ao cérebro,
processada, e essa segunda pessoa é capaz de compreender o que foi dito pela primeira. Para o outro responder, é
feito o mesmo processo realizado pela primeira pessoa.
As regras para redes, ou protocolos, são criadas e mantidas por diferentes organizações e comitês, como: Institute of
Electrical and Electronic Engineers (IEEE), American National Standards Institute (ANSI), Telecommunications
Industry Association (TIA), Electronic Industries Alliance (EIA) e International Telecommunications Union (ITU),
anteriormente conhecida como Comité Consultatif International Téléphonique et Télégraphique (CCITT).

Modelos OSI e TCP/IP


Quando a Internet surgiu, não existia ainda um modelo padrão para suas aplicações, ela simplesmente "funcionava".
Então, criaram o modelo OSI (Open Systems Interconnection - Interconexão de Sistemas Abertos), que descreve
toda a comunicação em 7 camadas: Aplicação, Apresentação, Sessão, Transporte, Rede, Enlace de Dados e Física.
Esse modelo descreve e separa cada parte da comunicação, porém, trata-se de um modelo complexo, que não é
realmente implementado pela Internet. Surgiu então o modelo para descrevê-la, o modelo TCP/IP, baseado em seus
dois principais protocolos (o TCP e o IP). O modelo TCP/IP em si não é muito utilizado, mas é mais próximo à
realidade da comunicação na grande rede mundial.
Será explicado aqui as camadas do modelo TCP/IP, com algumas adições, fornando o modelo Híbrido, pois este une
a didática de um lado, e a utilização prática da internet do outro.
Pilha de protocolos da Internet 17

TCP/IP
A pilha TCP/IP é formada por quatro camadas. Este modelo apresenta uma solução prática ao modelo OSI que nunca
chegou a ser implementado. As camadas que formam o TCP/IP são:

Aplicação
Na camada superior, a Aplicação, funcionam os serviços que são diretamente fornecidos ao usuário da Internet.
Nesta camada funcionam protocolos como HTTP, DNS, DHCP, MSN Messenger e outros. É implementada
simplesmente por software. Sua principal funcionalidade é padronizar a forma com que os programas consigam
conversar entre si, definindo regras que devem ser obedecidas por todos os softwares que implementem tal serviço.

Transporte
A camada seguinte é responsável por criar uma comunicação fim-a-fim, ou seja, ela faz uma conexão virtual entre a
origem e o destino. Os principais protocolos dessa camada são o TCP (Transmission Control Protocol - Protocolo de
Controle de Transmissão) e o UDP (User Datagram Protocol - protocolo de datagramas do usuário).
O TCP (descrito na RFC 793) provê uma transmissão confiável, garantindo que o que foi mandado chegue ao
destino, como o uso de pacotes ACK(confirmação) e janelamento. O TCP garante que os dados são entregues livres
de erro, em sequência e sem perdas ou duplicação. O lema do TCP é "transmitir com segurança". Portanto, esse
protocolo é mais usado em aplicações em que é necessária a garantia de entrega dos pacotes de forma ordenada e
sem erros, como acessos a páginas WEB, por exemplo.
O UDP (descrito na RFC 768) corresponde a um protocolo não orientado a conexão, sem confiabilidade, já que não
há garantia de recebimento de pacotes, quer dizer, o UDP não implementa nenhum mecanismo de controle de
congestionamento, de fluxo ou de erros. Geralmente é utilizado por aplicações que necessitam de velocidade (o UDP
é um protocolo bastante leve) e dispensam a confirmação de que as informações foram recebidas (como
videoconferências).
Essa camada trabalha com endereçamento baseado em portas. Cada serviço fornecido pela camada de aplicação
possui um endereço de porta, e a camada de transporte faz a conexão entre porta de origem e porta de destino.
Segundo Tanenbaum: "A Camada de Transporte não é simplesmente outra camada. Ela é o núcleo de toda hierarquia
de protocolos...Sem a camada de transporte, todo o conceito de protocolos em camada faria pouco sentido."(Andrew
Pilha de protocolos da Internet 18

S. Tanenbaum, Redes de Computadores). Nessa camada, os dados vindos da camada de Aplicação são agrupados em
segmentos.
A figura TCP Header [4] mostra as partes do cabeçalho TCP. Esta exibição é apenas uma representação esquemática.
Na analogia com a realidade, deve-se considerar uma disposição horizontal, com a segunda linha após a primeira e,
assim sucessivamente, até a última.
• Source port / Destination port: parte que identifica as portas das camadas de aplicação da origem e do destino.
• Sequence number: normalmente especifica o número assinalado para o primeiro byte de dados na mensagem
corrente. Na fase de estabelecimento de uma conexão, pode ser usado como uma identificação da transmissão.
• Acknowledgment number: contém o número sequencial do próximo byte de dados que o dispositivo de origem
espera receber.
• Data offset: o número de palavras de 32 bits do cabeçalho TCP.
• Reserved: reservado para uso futuro.
• Flags: usado para uma variedade de informações de controle, como SYN e ACK para estabelecer conexão e FIN
para terminar.
• Window: especifica o tamanho da parte de memória (buffer) disponível para os dados a receber.
• Checksum: verificação da integridade do cabeçalho.
• Urgent pointer: aponta para o primeiro byte urgente de dados no pacote.
• Options: especifica várias opções do TCP.
• Data: contém cabeçalho e dados da camada superior, isto é, a de aplicação. O seu comprimento é variável,
podendo ser bem mais que os 32 bits indicados na tabela.

Inter-Redes
A camada de Redes está relacionada com o transporte dos pacotes da origem até o destino. Quando se fala nisso, se
fala em roteadores, que são os responsáveis por esse trabalho. Eles não devem conhecer a localização de cada
endereço na rede de ip em redes de comunicação curta. Os protocolos tcp/ip dessa camada não podem garantir que
pacotes possam ser roteados pela rede, ou seja, protocolos que contenham endereçamento de origem e destino (IP,
IPX/SPX, etc.) e protocolos que conheçam a rede e os respectivos endereços nela (RIP, OSPF, EIGRP, IS-IS, etc.),
além de utilizarem algoritmos de roteamento para determinar o caminho de menor custo. O principal protocolo dessa
camada é o IP (Internet Protocol). Nessa camada, os segmentos da camada superior (transporte) são agrupados em
datagramas.

Host/Rede
O modelo de referência TCP/IP não define muito bem essa camada, somente deve ser garantido que os pacotes IP
trafeguem de algum modo, independentemente do protocolo e do meio físico, até o destino.
Por isso, para explicar essa parte, costuma-se usar o modelo híbrido de referência, que é composto pelas camadas:
Aplicação, Transporte, Rede, Enlace de Dados e Física.

Enlace de Dados
A camada de Enlace é responsável por dar acesso ao meio físico de comunicação. Como é uma camada bem próxima
à transferência de bits, ela também fornece correção de erros, através da Checagem Cíclica de Redunância (CRC -
Cyclic Redundancy Checksum). Também é responsável por fazer o controle do fluxo de bits, de forma que o
receptor possa receber os dados a uma velocidade que possa processar. Essa camada trata as topologias de rede e
engloba dispositivos como Switch, placas de rede, interfaces, etc. Os pacotes de dados, nessa camada, são
denominados quadros. Exemplos de protocolos da camada de enlace são o Ethernet e o PPP, e é nessa camada onde
são adicionados cabeçalhos e trailers MAC. Isso permite que seja feita a análise do MAC Address em um dado
aplicativo. Uma breve descrição a respeito do MAC Address é feita abaixo.
Pilha de protocolos da Internet 19

Endereço MAC (MAC Address)


O endereço MAC (Media Access Control) é o endereço físico único de uma interface de rede. Todos os dispositivos
que estão conectados à rede local Ethernet, possuem interfaces endereçadas: estações de trabalho, impressoras,
roteadores e switches, etc. O IEEE controla o espaço de endereçamento Ethernet e distribui faixas de endereços aos
fabricantes. Cada faixa consiste de um identificador de 24 bits (3 primeiros dos 6 bytes - pares hexadecimais),
chamado “Organizationally Unique Identifier” (OUI). Cada fabricante adquire um ou mais OUIs e produz interfaces
de rede cujos endereços são compostos do seu OUI concatenado com um número de 24 bits ( 3 últimos bytes) que
identifica a interface. Apesar de ser único, praticamente todo hardware hoje permite a alteração do endereço MAC.
Isso acontece devido ao fato de as interfaces de rede terem o MAC gravado em memória ROM, a qual é depois
copiada para a RAM, com a inicialização da placa de rede, o que abre brechas para sua modificação. Tal modificação
é conhecida como MAC spoofing, uma técnica em que se altera o endereço MAC, muitas vezes para fins maliciosos
ilegais.

Física
Em uma rede, uma informação é controlada, manipulada e processada por um agente específico, e sinais são a
materialização dessas informações. O meio onde esses sinais se propagam pode ser descrito pela camada Física.
Resumidamente, essa camada inclui o elemento condutor e os parâmentos que definem a transmissão. Muitas vezes
chamada de PHY, essa é a camada que conecta um dispositivo de link ao meio de transmissão, onde os dados
realmente trafegam. A camada física trata da distância máxima dos cabos (por exemplo, no caso do UTP onde são
100m), de conectores físicos (tipo BNC do coaxial ou RJ45 do UTP), dos pulsos elétricos (no caso de cabo metálico)
ou pulsos de luz (no caso da fibra ótica). Na transmição de qualquer tipo de sinal, pode-se usar cabos par-trançado,
cabos coaxiais, fibras-ópticas ou até mesmo o ar (wireless). O papel dessa camada, portanto, é apenas permitir que os
dados saiam do transmissor e cheguem ao receptor, não provendo nenhum serviço de segurança, nem integridade.

Referências
[1] James F. Kurose e Keith W. Ross, Redes de Computadores e a Internet - Uma abordagem Top-Down
[2] Currículo online CISCO CCNA 3.0
[3] Willian Stallings, Redes e Sistemas de Comunicação de Dados
[4] http:/ / www. mspc. eng. br/ info/ im01/ net108. gif
História da Internet 20

História da Internet
A abordagem histórica é sempre válida, mesmo quando se trata de tecnologia, que nos termos atuais, se moderniza e
evolui em ritmo frenético. Devemos recorrer à história para resgatar as motivações, o contexto histórico e a evolução
por trás de cada invenção. Portanto, não podemos ignorar a história daquilo que se tornou um componente central da
infra-estrutura mundial de telecomunicações [1], a Internet.
É interessante notar que uma série de pesquisas e motivações nasciam na década de 60, e que tinham em comum a
idealização de uma grande rede de comunicação: a necessidade da descentralização geográfica da informação
durante a Guerra Fria, as primeiras pesquisas sobre comutação de pacotes e a idealização de estudiosos (J.C.R.
Licklider, do MIT) de construir uma grande rede de onde qualquer pessoa pudesse acessar arquivos e programas, são
exemplos das motivações que surguiram naquela década.
Foram nos anos 60 que surgiram os primeiros estudos sobre comutação de pacotes, com a intenção de criar uma
forma de comunicação mais eficiente e robusta que a comutação de circuitos. Neste período temos 3 institutos que se
destacam em suas contribuições (pesquisas realizadas em paralelo, sem conhecimento mútuo). Seriam estes o MIT,
Rand Institute e o National Physical Laboratory. Muito do que foi pesquisado teve o propósito de atender a
necessidades militares, pois o contexto político do mundo era a Guerra Fria. Mas pesquisadores, como J.C.R.
Licklider do MIT, em 1962, já discutia o conceito de Rede Galática (Galactic Network), e já idealizava um conceito
de redes de computadores que é basicamente o modelo de internet que temos hoje.
O primeiro livro sobre a teoria da comutação de pacotes foi lançando em 1964, por Leonard Kleinrock. Em 1965,
depois que Lawrence G. Roberts, trabalhando com Thomas Merril, colocaram em funcionamento a primeira
(pequena) rede WAN usando a rede telefônica, concluiu-se que a comutação por circuito era ineficiente para este
propósito, confirmando definitivamente, que a solução estava na comutação por pacotes.
Em 1968 é criado o primeiro comutador de pacotes, chamado Interface Message Processors (IMP’s), para compor a
arquitetura da ARPANet. Em 1969, três IMPs são instalados na universidade de Stanford, Santa Bárbara e Utah,
configurando assim, uma rede com 4 nós. Em 1972 a ARPANet já contava com 15 nós. Neste mesmo ano o primeiro
protocolo tipo host-to-host foi criado, e a primeira aplicação de e-mail foi apresentada.
A década seguinte, 70, foi a responsável pelo desenvolvimento do TCP, inicialmente especificado por Vint Cerf, em
1974. O objetivo era obter um protocolo que transmitisse de forma eficiente e confiável ,pacotes em redes de longa
distância. Posteriormente, Robert Kahn definiu algumas regras que norteariam o desenvolvimento do novo
protocolo, como por exemplo: retransmissão dos pacotes em caso de perda, cada rede distinta se conecta à internet
sem depender da sua arquitetura, caixas-pretas (posteriormente chamados de gateways e roteadores) fariam a
conexão entre as redes sem reter informação sobre os pacotes e não haveria um controle global no nível de operação.
Os anos 80 marcam a proliferação das redes conectadas à Internet e finalmente, com a criação da Web , e dos
browsers com interface gráfica na década de 90, temos a inclusão do usuário doméstico na rede, e o início do
fenômeno comercial e cultural que se tornou a Internet.

A Proliferação de Redes 1980-1990


Ao final da década de 1970, aproximadamente 200 máquinas estavam conectadas à ARPAnet, ao final da década de
1980, o número de máquinas ligadas a internet pública, uma confederação de redes muito parecida com a internet de
hoje, alcançaria 100 mil. A década de 1980 seria uma época de formidável crescimento.
Grande parte daquele crescimento foi consequência de vários esforços distintos para criar redes de computadores
para interligar universidades. A BITNET processava e-mails e fazia transferência de arquivos entre diversas
universidades do nordeste dos Estados Unidos. A CSNET (computer science network – rede da ciência de
computadores) foi formada para interligar pesquisadores de universidades que não tinham acesso a ARPAnet. Em
1986, foi criada a NSFNET para prover acesso a centros de super-computação patrocinados pela NFS. Partindo de
História da Internet 21

uma velocidade inicial de 56 kbps, ao final da década o backbone da NSFNET estaria funcionando a 1.5 Mbps e
servindo como backbone primário para interligação de redes regionais.
Na comunidade da ARPAnet, já estavam sendo encaixados muitos dos componentes finais da arquitetura da internet
de hoje. No dia 1º de janeiro de 1983, o TCP/IP foi adotado oficialmente como o novo padrão de protocolo de
maquinas para a ARPAnet (em substituição ao protocolo NCP). Devido a importância do evento, o dia da transição
do NCP para o TCP/IP foi marcado com antecedência – a partir daquele dia toda as maquinas tiveram de adotar o
TCP/IP. No final da década de 1980, foram agregadas importante extensões ao TCP para implementação do controle
de congestionamento baseado em hospedeiros. Também foi desenvolvido o sistema de nomes de domínios (DNS)
utilizado para mapear nomes da internet fáceis de entender para endereços IP de 32 bits. Paralelamente ao
desenvolvimento da ARPAnet (que em sua maior parte deve-se aos Estados Unidos), no inicio da década de 1980 os
franceses lançaram o projeto Minitel, um plano ambicioso para levar as redes de dados para todos os lares.
Patrocinado pelo governo francês, o sistema Minitel consistia em uma rede publica de comutação de pacotes
(baseada no conjunto de protocolos X.25, que usava circuitos virtuais), servidores Minitel e terminais baratos com
modens de baixa velocidade embutidos. O Minitel transformou-se em um enorme sucesso em 1984, quando o
governo francês forneceu, gratuitamente, um terminal para toda residência francesa que quisesse. O sistema Minitel
incluía sites de livre acesso – como o da lista telefônica – e também sites particulares, que cobravam uma taxa de
cada usuário baseada no tempo de utilização. No seu auge, em meados de 1990, o Minitel oferecia mais de 20 mil
serviços, que iam desde home banking ate bancos de dados especializados para pesquisa. Era usado por mais de 20%
da população da França, gerava receita de mais de um bilhão de dólares por ano e criou dez mil empregos. Estava
presente em grande parte dos lares franceses dez anos antes de a maioria dos norte-americanos ouvir falar em
internet.

Referências
[1] Kurose, 2006
ATM 22

ATM
Asynchronous Transfer Mode, é um modo de transferência de troca de pacotes onde toda a informação é organizada
em células. ATM é um método de formatação, multiplexagem, transporte e troca de informação num tamanho fixo
de 53 bytes de informação, 5 bytes presentes no cabeçalho da célula e 48 bytes na zona do corpo (Payload) da célula.
O tempo de Informação contida poderá ser voz, data ou vídeo.
ATM, é uma conexão orientada à ligação. Por norma, a informação e a sinalização são transportados em camadas
(layers) diferentes.

Vantagens
A escolha na utilização de pequenas células, representa ao compromisso entre a necessidade de troca dados com um
overhead e um delay mais reduzido tendo assim uma excelente eficácia na utilização da largura de banda disponível.
Este tipo de rede funciona com uma largura de banda relativamente alta. Um exemplo de utilização, é onde existem
pacotes de voz e vídeo a circular numa rede e onde se quer um delay muito baixo.
As vantagens de utilizar células de tamanho fixo passam por:
• Uma variação do delay muito baixa ou nula.
• Uma sincronização de células mais eficiente.
• Excelente para a utilização pelo mecanismo de routing.
A utilização de células de 53 bytes passa por um acordo existente entre:
• Europeus queriam células de 32 bytes com header.
• Americanos desejavam células de 64 bytes com header.
• Então o compromisso ficou por exemplo, 48 bytes com 5 bytes de header: i.e., (32bytes + 64bytes) / 2 = 48 bytes
mais 5 bytes de header.

Layers
O funcionamento do modelo ATM, ocorre de duas formas, uma para o user-to-network interface (UNI), outra para
network-to-node interface (NNI) e estão divididos em 3 layers.
1. ATM Adaptation Layer (AAL)
2. ATM Layer
3. Physical Layer
1. O Interface AAL, é o layer responsável por fazer repassar "células" vindas de layers superiores para layers
inferiores. Quando isto ocorre o AAL segmenta os dados em "células" ATM e quando faz o processo contrário,
quando recebe dados de layers inferiores, então o Layer ATM volta a re-assembelar os dados num formato que os
layers superiores consigam compreender. Este processo é chamado de SAR, segmentation and reassembly.
2. O ATM layer é responsável por repassar "células" para o Physical Layer para fazer transmissão e vice versa.
Determina para onde é que as ligações recebidas deverão ser encaminhadas, faz reset dos identificadores de
ligação e reencaminha os dados para o link seguinte. Controla também diversos funções de gestão de tráfego,
como por exemplo, marcação de células de baixa prioridade, indicadores de congestionamento, controles
genéricos de fluxos de dados. Controla igualmente a velocidade de transmissão de dados.
Camada de rede 23

Camada de rede
A camada de rede é o núcleo de toda a hierarquia de protocolos e integra toda a arquitetura da rede. Sua função é
permitir transferência de dados da máquina de origem e à máquina de destino, independente das redes físicas em uso
no momento. O destino pode ser outra rede e muitas vezes, para chegar ao destino, pode exigir vários hops (saltos)
em roteadores intermediários ao longo do percurso.
Para atingir seus objetivos, a camada de rede deve conhecer a topologia da sub-rede de comunicações (ou seja, o
conjunto de todos os roteadores) e escolher os caminhos mais apropriados através dela. A camada de rede também
deve ter o cuidado de escolher rotas que evitem sobrecarregar algumas das linhas de comunicação e roteadores
enquanto deixam outras ociosas. Por fim, quando a origem e o destino estão em redes diferentes, ocorrem novos
problemas, e cabe à camada de rede lidar com eles
Protocolos da camada de rede: IP (Internet Protocol ), ICMP (Internet Control Message Protocol), ARP (Address
Resolution Protocol) e RARP (Reverse Address Resolution Protocol). Um papel essencial do protocolo IP é receber
os dados enviados pela camada de transporte e enviá-los para a camada de enlace, o protocolo ARP é responsável
por fazer a conversão entre os endereços IPs e os endereços MAC da rede, e o protocolo RARP faz o processo
reverso do ARP.

Protocolo IP
Os endereços físicos ( MAC) das placas de rede podem ser utilizados para comunicar-se com outras máquinas na
própria rede, mas não além desta, pois o protocolo utilizado na camada física as limita. Para que distintas redes
locais com tecnologias diferentes possam se comunicar é que foi criado o protocolo IP. Ou seja, este protocolo serve
para abstrair os protocolos das camadas superiores (transporte e aplicação) da rede em que se encontram, tratando
várias redes interconectadas como apenas uma.
Para conectar somente duas redes locais, normalmente um computador com duas placas de rede já basta. Este
computador é comumente chamado de bridge[1], pois faz uma "ponte" entre as duas redes locais. Porém quando se
deseja interligar várias LANs, o equipamento mais usado é um computador dedicado chamado roteador, cuja função
principal é receber pacotes endereçados a redes diferentes da que estão e colocá-los na rede que esteja mais próxima
de seu destino.

O endereço IP
O endereço IP é um número de 32 bits[2], comumente exibido como octetos na base decimal (veja Conversão de base
numérica) separados por pontos, dividido em um prefixo que identifica a rede onde está conectada a máquina e um
sufixo que identifica cada máquina individualmente em sua rede. O endereço IP completo (prefixo da rede + sufixo
da máquina) tem de ser único em todas as sub-redes que componham a rede maior.
Para melhorar o controle e o gerenciamento, os gestores dividiram os endereços IP na Internet em diversas classes[3]
com diferentes fronteiras entre o endereço da rede e o da máquina. Assim, cada rede, dependendo do número de
máquinas que possuir, recebe um prefixo para as classes A, B ou C e gerencia o sufixo de forma que os endereços
não se repitam, podendo também subdividir um sufixo em um novo endereço de sub-rede, caso esta passe a existir.
Protocolo IP 24

Classe 8 16 24 31

A Prefixo Sufixo

B Prefixo Sufixo

C Prefixo Sufixo

D Multicast

E Reservado para experimentação

Portanto o espaço de endereçamento na internet é dividido da seguinte forma:

Classe Faixa de valores Número de Número de


(primeiro octeto) endereços máquinas
de rede em cada rede

A 0 ~ 127 128 16.777.216

B 128 ~ 191 [4] 65.536


16.384

C 192 ~ 223 2.097.152 256

D 224 ~ 239 - -

E 240 ~ 255 ? ?

Este sistema de classes facilita o roteamento, pois dependendo da faixa em que se encontrar o primeiro octeto do
endereço, se sabe quantos bits dele se referem a rede e quantos a máquina. Porém tira versatilidade do sistema.
Fica-se limitado a 3 tamanhos de redes: grande (classe C), muito grande (classe B) ou exagerada (classe A).
Conforme a internet crescia, se fez necessária a subdivisão dos espaços de endereçamento, para poder acomodar
mais redes de menor tamanho. Então foi criado o CIDR (Classeless Interdomain Routing), que possibilita a
utilização de qualquer número de bits para rede, devendo este número ser informado em um netmask.

Máscaras de rede (endereçamento sem classe)


Netmask é a forma de se informar ao sistema operacional qual parte do endereço é referente à rede e qual é referente
à máquina. Ele é formado com 1 na porção da rede do endereço e 0 na porção da máquina[5]. Geralmente o netmask
é escrito com o mesmo formato de um endereço IP (bits separados em octetos escritos na base decimal), mesmo não
sendo o endereço.
Por exemplo, um netmask para uma rede de classe C é 255.255.255.0, já que apenas o último octeto dos endereços
classe C são referentes à rede, os demais estão totalmente preenchidos por 1 pois (255)10=(11111111)2.
Os administradores frequentemente precisam subdividir o espaço de endereçamento recebido para a internet. Por
exemplo: Suponha ter recebido um endereço de classe C 200.131.56 e precise separar o espaço para 4 sub-redes.
Assim sendo, deve-se separar mais dois bits do último octeto para identificar as redes (00, 01, 10 e 11) e o netmask
teria (11000000)2 no último octeto; assim o netmask seria 255.255.255.192. Todos os endereços se iniciariam por
200.131.56, e teriam para o último octeto o seguinte:
Protocolo IP 25

Sub-rede De Até

1ª (00000000)2 = (0)10 (00111111)2 = (63)10

2ª 01000000)2 = (64)10 (01111111)2 = (127)10

3ª (10000000)2 = (128)10 (10111111)2 = (191)10

4ª (11000000)2 = (192)10 (11111111)2 = (255)10

O netmask, assim, é ideal para a extração do endereço de rede de um endereço IP. Basta um simples e (and) bit a bit
entre o netmask e o endereço para a tarefa ser completada. Por esta tarefa ser realizada nos roteadores a cada pacote,
para se decidir qual será a porta de destino, a eficiência é importante.
Entretanto, alguns sistemas usam uma grafia distinta desta, indicando o número de bits componentes do endereço de
rede, por exemplo 200.131.56.207/24, onde o 24 após o endereço IP serve para indicar que os 16 primeiros bits do
endereço referem-se a rede e, portanto, que os 8 restantes são referentes ao endereço da máquina.

Entre a rede local e a de longa distância


A camada física possui um tipo próprio de endereçamento, portanto se faz necessária uma conversão do endereço IP
para o protocolo utilizado nesta camada.

Referências
[1] LSM (http:/ / lsm. dei. uc. pt/ ib/ comunicacoes/ redes/ bridge. html), Acessado em 9/8/10.
[2] Devmedia (http:/ / www. devmedia. com. br/ post-17494-Como-funciona-o-protocolo-IP. html), Acessado em 9/8/10.
[3] [mesonpi.cat.cbpf.br/naj/tcpipf.pdf Mesonpi], página 8. Acessado em 9/8/10.
[4] Vas-y (http:/ / www. vas-y. com/ dicas/ navegar/ internet/ 03. html), Acessado em 9/8/10.
[5] [mesonpi.cat.cbpf.br/naj/tcpipf.pdf Mesonpi], página 9. Acessado em 9/8/10.
Camada de transporte 26

Camada de transporte
Introdução à Camada de Transporte
A camada de transporte, dentro do modelo OSI, localiza-se abaixo da camada de aplicação e acima da camada de
rede (Internet). A principal finalidade dessa camada é manter a comunicação entre dois hosts, ou seja, ela é
responsável pela transferência fim-a-fim, de maneira eficiente, confiável e econômica de dados entre uma máquina
de origem e uma máquina de destino. A camada de transporte prevê dois protocolos, o primeiro deles é o TCP
(Transmission Control Protocol — protocolo de controle de transmissão), que é um protocolo orientado a conexões
confiáveis, ou seja, ele permite a entrega sem erros de dados de uma determinada máquina a outra máquina da rede.
O outro protocolo, o UDP (User Datagram Protocol - protocolo de datagramas do utilizador) corresponde a um
protocolo não orientado a conexão, ou seja, sem confiabilidade, já que não há garantia de envio/recebimento de
pacotes.
O serviço de transporte mantém um relacionamento muito próximo com o destinatário do serviço. Portanto, deve ser
fácil de usar. Podemos relacionar algumas primitivas que os provedores deste tipo de serviço devem adotar, de modo
a oferecer um serviço orientado a conexão com um mínimo de funcionalidade (em geral, basta permitir requisições
de estabelecimento, uso e encerramento de uma conexão). Primitivas: LISTEN, CONNECT, SEND DATA,
RECEIVE e DISCONNECT.
[1]
Uma ilustração do serviço provido pela camada de trasporte . Observe a implementação de um serviço de
transporte confiável de dados sobre uma camada não confiável.

Multiplexação e Demultiplexação
Enquanto que a camada de rede provê uma comunicação host a host, a camada de transporte provê uma comunicação
processo a processo. Para realizar essa ampliação do serviço provido pela camada de redes, a camada de transporte
utiliza o conceito de portas, que é, na verdade, um número que identifica qual processo deverá se encarregar da
informação trazida por aquele pacote. Na prática, o aplicativo informa ao sistema operacional que estará escutando
uma determinada porta e então todos os pacotes daquele protocolo (UDP ou TCP) serão repassados àquele processo.
O método de receber os dados do processo utilizando uma determinada porta, colocar um cabeçalho e enviar a um
determinado processo de outro host é chamado de multiplexação.
O método de receber um pacote vindo de outro host e repassar as informações ao processo correto é chamado de
demultiplexação.
Abaixo segue uma ilustração do funcionamento da Multiplexação/Demultiplexação, na qual dois clientes usam o
mesmo números de porta destino (80) para se comunicar com a mesma aplicação do servidor web.

Protocolo UDP
O protocolo UDP é um dos protocolos utilizados pela camada de transporte. A idéia central do protocolo é receber os
dados de um processo e entregar ao processo de destino. Não leva em consideração o congestionamento da rede, ou
uma entrega confiável dos dados, apenas a multiplexação e demultiplexação.
A grande vantagem do UDP em relação ao TCP (outro protocolo da camada de transporte) está na velocidade de
transmissão, relevando a confiabilidade na entrega dos pacotes. Nas aplicações onde velocidade é mais importante
do que a ordem em que os pacotes são recebidos, como jogos, vídeos e músicas, o UDP é preferível.
Observe o Cabeçalho UDP [2], podemos notar a tamanha simplicidade deste protocolo, bem como uma ilustração da
idéia do UDP, que é a de transmitir (busca pelo tempo real, velocidade), independentemente da chegada ou não dos
pacotes no destinatário (sem garantia de envio/ recebimento).
Camada de transporte 27

Protocolo TCP
O protocolo TCP é outro protocolo utilizado pela camada de transporte. A idéia central deste protocolo é prover
confiabilidade no transporte dos dados, não deixando de lado o tráfego na rede (controle de congestionamento) e a
multiplexação e demultiplexação.
A grande vantagem do TCP em relação ao UDP está na confiabilidade em que os dados são entregues ao remetente.
Este protocolo provê mecanismos que garantem que todos os dados repassados a camada de aplicação não estão
corrompidos. Desta forma um host A pode enviar um arquivo ao host B tendo a certeza de que o arquivo, caso seja
entregue á camada de aplicação do host B, está íntegro.
O Tcp é orientado a conexão, isto é, um host estabelece uma conexão com outro host, de forma que um pode enviar
dados para o outro em modo full duplex.
O TCP, portanto, provê transferência confiável de dados entre processos rodando em sistemas finais. A comunicação
entre os dois aplicativos se dá como se eles estivessem fisicamente interligados por um cabo, embora ambos possam
estar a milhares de quilômetro de distância um do outro.
Observe uma representação do cabeçalho TCP [3], uma simples demonstração do propósito do TCP. Percebe-se a
complexidade de um pacote TCP, o que reflete toda a confiabilidade e garantia oferecidos por este protocolo. O TCP
não está preocupado em apenas enviar os pacotes (velocidade, tempo real), mas sim dar a garantia ao destinatário de
que o pacote enviado pelo remetente tenha sido entregue.

Referências
1. James F. Kurose e Keith W. Ross, Redes de Computadores e a Internet - Uma abordagem Top-Down
2. Andrew S. Tanenbaum, Redes de Computadores

Referências
[1] http:/ / gridra. files. wordpress. com/ 2008/ 10/ transporte1. jpg
[2] http:/ / www. ccuec. unicamp. br/ treinamento_int2004/ tcpip/ udp-packet. gif
[3] http:/ / www. ralphmcs. eti. br/ midia/ 19990910_arquivos/ image019. gif
Multiplexação e demultiplexação 28

Multiplexação e demultiplexação
Situada entre as camadas de aplicação e de rede, a camada de transporte provê uma comunicação processo a
processo. Para tal, a camada de transporte utiliza o conceito de portas, que é, na verdade, um número que identifica
qual processo deverá se encarregar da informação trazida por aquele pacote. Na prática, o aplicativo informa ao
sistema operacional que estará escutando uma determinada porta e então todos os pacotes daquele protocolo (UDP
ou TCP) serão repassados àquele processo. A Demultiplexação é a entrega dos dados de um segmento da camada de
transporte à porta correta. "O trabalho de reunir, no hospedeiro de origem, porções de dados provenientes de
diferentes portas, encapsular cada porção de dados com infomações do cabeçalho (que mais tarde serão usadas na
demultiplexação) para criar segmentos, e passar esses segmentos para a camada de rede é denominado
multiplexação".(KUROSE; ROSS, 2006, p. 148).

Multiplexação e Demultiplexação na camada de transporte


Sabe-se que o serviço de multiplexação e o de demultiplexação é de extrema importância para todas as redes de
computadores. No entanto, aqui será enfatizado seu uso na camada de transporte.
A camada de transporte, em um hospedeiro de destino, recebe segmentos da camada de rede que fica abaixo dela
(isso acontece, analisando uma abordagem top-down), a qual tem o dever de entregar todos os dados desses
segmentos ao processo da camada de aplicação, que também roda nesse hospedeiro. Porém, o que acontece na
realidade é que a camada de transporte não entrega os segmentos a um processo, mas sim em um socket (porta)
intermediário. Onde cada socket tem um identificador exclusivo, que depende de o socket ser TCP ou UDP.
O direcionamento a uma porta correta de um segmento, é feito a partir da análise de um conjunto de campos que se
localiza no segmento. Nesse campo encontra-se a porta destinatária, a qual o segmento será direcionado pela camada
de transporte. Esse direcionamento a porta correta é denominado de demultiplexação.
Define-se multiplexação como sendo a tarefa de reunir pedaços de dados, vindos de diferentes portas (no hospedeiro
de origem), encapsulando esses pedaços com o conjunto de campos para criar segmentos e entregá-los a camada de
rede. A transferência de dados pode ser feita por: UDP (não orientada para conexão) ou TCP (orientada para
conexão). Caso seja feita por UDP, o socket UDP é identificado por uma tupla com dois elementos: endereços IP de
destino e um número de porta de destino; por outro lado seja feita por TCP, o socket TCP é identificado por uma
tupla com quatro elementos: endereço IP de origem, número da porta de origem, endereço IP de destino e número da
porta de destino.

Multiplexação/demultiplexação não orientada para conexão


A porta UDP pode ser criada a partir de uma implementação, na qual pode se designar um número de porta
específico ou mesmo deixar que seja designado um número de porta ao socket pela camada de transporte.
Logicamente isso, dependerá da escolha do implementador. Em geral, o lado servidor de uma aplicação designa um
número de porta específico, enquanto o lado cliente da aplicação deixa essa escolha livre e transparente para a
camada de transporte.
Com isso, entende-se que mesmo que dois ou mais segmentos tenham endereços IP ou número de porta fonte
diferentes eles poderão ser direcionados ao mesmo processo de destino, caso tenham o mesmo número IP e mesmo
número de porta de destino pela mesma porta de destino.
Multiplexação e demultiplexação 29

Transporte Orientado Para Conexao: TCP


O protocolo TCP é, sem dúvidas, um dos mais importantes protocolos utilizados atualmente. Esse protocolo fornece
um serviço de entrega de pacotes confiável e orientado para conexão, ou seja, todos os aplicativos que utilizam o
TCP como protocolo de transporte estabelecem uma conexão antes de começar a trocar dados, além de contar com
serviços como detecção de erros, retransmissões, reconhecimento cumulativo, temporizadores e campos de
cabeçalho para números de seqüência e de reconhecimento.
Ao contrario do UDP para mandar dados através do TCP é necessário a abertura de uma conexão fim-a-fim, ou seja
o TCP suporta comunicação apenas entre dois hosts por vez. Uma sessão TCP é inicializada através de um processo
conhecido como 'three-way handshake', que consiste em três pacotes de estabelecimento de conexão, sendo um
pacote SYN enviado pelo cliente que consiste em um segmento TCP especial que não contem nenhum dado da
camada de aplicação mas com o flag SYN ativado. Além disso o cliente escolhe aleatoriamente um numero de
seqüência inicial e coloca esse número no campo de numero de seqüência do segmento SYN inicial. Quando o
servidor recebe o segmento SYN ele aloca buffers e variáveis TCP necessárias a conexão e envia um segmente de
aceitação de conexão ao TCP cliente. Esse segmento é chamado SYNACK. Ao receber o segmento SYNACK o
cliente também reserva buffers e variáveis para a conexão. O cliente então envia ao servidor mais um segmento que
reconhece o segmento de confirmação da conexão do servidor, o bit SYN é ajustado para 0 e a conexão já esta
estabelecida. Esse processo sincroniza os números de seqüência e oferece informações de controle necessárias para
estabelecer uma conexão virtual entre os dois hosts. Depois de concluído o 'tree-way handshake' inicial, os
segmentos são enviados e confirmados de forma seqüencial entre os hosts remetente e destinatário. Um processo de
handshake semelhante é usado pelo TCP antes de fechar a conexão para verificar se os dois hosts acabaram de enviar
e receber todos os dados.
O TCP recebe os dados de aplicação e processa esses dados como um conjunto de bytes, os mesmos são agrupados
em segmentos que o TCP numera em seqüência para a entrega. Apos receber os dados de aplicação o TCP direciona
esses dados para um buffer de envio da conexão (reservado durante o estabelecimento da conexão) e vai criando
segmentos e enviando para a rede. A quantidade máxima retirada do buffer e colocada em um segmento é limitada
pelo MMS (tamanho máximo do segmento).
O TCP utiliza o conceito de portas, que permite que vários programas estejam em funcionamento, ao mesmo tempo,
no mesmo computador, trocando informações com um ou mais serviços/servidores.
Algumas das principais características do TCP e que faz com que ele seja tao utilizado são citadas a seguir:
• Garante a entrega de datagramas IP: Esta talvez seja a principal função do TCP, ou seja, garantir que os pacotes
sejam entregues sem alterações, sem terem sido corrompidos e na ordem correta. O TCP tem uma série de
mecanismos para garantir esta entrega.
• Garante o seqüenciamento adequado e entrega ordenada de dados segmentados: Esta característica refere-se a
função de dividir grandes arquivos em pacotes menores e transmitir cada pacote separadamente. Os pacotes
podem ser enviados por caminhos diferentes e chegar fora de ordem. O TCP tem mecanismos para garantir que,
no destino, os pacotes sejam ordenados corretamente, antes de serem entregues ao programa de destino.
• Verifica a integridade dos dados transmitidos: Usando cálculos de soma de verificaçao o TCP faz verificações
para garantir que os dados não foram alterados ou corrompidos durante o transporte entre a origem e o destino.
• Envia mensagens positivas dependendo do recebimento bem-sucedido dos dados. No destino, o TCP recebe os
pacotes, verifica se estão OK e, em caso afirmativo, envia uma mensagem para a origem, confirmando cada
pacote que foi recebido corretamente. Caso um pacote não tenha sido recebido ou tenha sido recebido com
problemas, o TCP envia uma mensagem ao computador de origem, solicitando uma retransmissão do pacote.
Com esse mecanismo, apenas pacotes com problemas terão que ser reenviados, o que reduz o tráfego na rede e
agiliza o envio dos pacotes.
• Oferece um método preferencial de transporte de programas que devem usar transmissão confiável de dados
baseada em sessões: Ou seja, o TCP é muito mais confiável do que o UDP e é indicado para programas e serviços
Multiplexação e demultiplexação 30

que dependam de uma entrega confiável de dados.

Transporte Não Orientado Para Conexao: UDP


O UDP é um protocolo usado para o transporte rápido de dados entre hosts TCP/IP. Porém o UDP não fornece
garantia de entrega e nem verificação de dados. De uma maneira simples, podemos dizer que o protocolo UDP
manda os dados para o destino sem a necessidade de apresentação entre as unidades remetentes e destinatária antes
de enviar o segmento, porem se vai chegar, e sem erros, é impossível saber (o UDP fornece verificação de erro
porém nada faz para corrigir o erro, apenas informa a aplicação que determinado pacote é corrupto). O UDP não
garante a entrega ou verifica o seqüenciamento para qualquer pacote. Uma outra solução bastante utilizada
ultimamente é a inserção da confiabilidade na própria aplicação (adicionando mecanismos de reconhecimento e de
transmissão embutidos na aplicação) permitindo assim que ela tire proveito de ambas as alternativas, ou seja, os
processos de aplicação se comunicam de maneira confiável sem ter que se sujeitar as limitações da taxa de
transmissão impostas pelo mecanismo de controle de congestionamento impostas pelo TCP.
Alguns dos principais motivos pelo qual o UDP pode ser preferível são:
• Melhor controle no nível de aplicação sobre quais dados são enviados e quando: como ele não possui controle de
congestionamento (como ocorre no TCP), não ocorre atraso no envio do pacote. Não possui o serviço de
confirmação de recebimento que pode atrasar a transmissão se alguns pacotes forem perdidos, e é compatível com
aplicações de tempo real onde a velocidade é mais importante que a confiabilidade na entrega.
• Não há estabelecimento de conexão: O UDP apenas envia os dados sem perder tempo tentando abrir conexões
(como ocorre no TCP) esse é um dos motivos pelo qual DNS roda sobre UDP.
• Não há estados de conexão: Usado pelo TCP para garantir a entrega confiável de dados (esses estados inclui
buffers de envio e recebimento, parâmetros de controle de congestionamento e etc), por isso um servidor com
uma aplicação especifica pode suportar um numero muito maior de clientes ativos quando a aplicação roda sobre
UDP ao invés de TCP.
• Pequena Sobrecarga de Cabeçalho de Pacote: O TCP possui 20 bytes de sobrecarga de cabeçalho enquanto o
UDP so possui 8 bytes.
Algumas das aplicações mais importantes que utilizam o UDP são:
• Atualização de tabelas de roteamento com protocolo RIP.
• Transferir dados de gerenciamento de rede, que normalmente funcionam quando a rede esta sobrecarregada e é
difícil conseguir transferência confiável devido ao controle de congestionamento.
• O DNS também roda sobre o UDP.
• É bastante utilizado em aplicações multimídia como telefone por internet, vídeo conferência em tempo real e
recepção de áudio e vídeo armazenados.

Mecanismos de Controle de Congestionamento


Podemos distinguir mecanismos de controle de congestionamento conforme a camada de rede ofereça ou não
assistência explícita à camada de transporte, com finalidade de controle de congestionamento. Sabendo que 'Janela
de Congestionamento' é um parâmetro que impõe uma limitação a taxa a qual o remetente pode enviar tráfego para
dentro da rede, (especificamente a quantidade de dados não reconhecidos em um hospedeiro não pode exceder o
mínimo da janela de congestionamento) podemos dividir o controle de congestionamento em dois modos:
• Controle de congestionamento fim-a-fim: Nesse método a camada de rede não fornece nenhum suporte explícito à
camada de trasporte, e o congestionamento da rede é intuída pelos sistemas finais com base na observação do
comportamento da rede (perda de pacotes). Esse é o metodo utilizado pelo protocolo TCP.
• Controle de congestionamento assistido pela rede: com esse método os roteadores fornecem realimentação de
informações ao remetente a respeito do congestionamento da rede. O controle de congestionamento assistido pela
Multiplexação e demultiplexação 31

rede tem dois modos de operação. São eles:


• Realimentação Direta: Pacote enviados de um roteador da rede a um remetente (como se fosse um pacote de
congestionamento dizendo: “estou congestionado”)
• Realimentação Indireta: Ocorre quando um roteador marca/atualiza um campo em um pacote que esta indo do
remetente ao destinatário para indicar o congestionamento e com isso o destinatário informa ao remetente
sobre o congestionamento. Esse método possui a desvantagem de perder, no mínimo, o tempo de ida e volta de
um pacote, para avisar ao remetente sobre o congestionamento.

Servidores Web e o TCP


Este é um cenário bastante interessante para se entender os princípios da multiplexação e demultiplexação no TCP.
Observe uma ilustração [1] de uma situação típica, onde vários clientes se conectam a um servidor WEB através da
porta 80.
Em virtude de o TCP ser identificado por uma tupla de 4 (quatro) elementos, todas as conexões serão corretamente
multiplexadas/demultiplexadas.
Os pacotes que saem dos hospedeiros clientes possuem sempre o IP de destino B e porta de destino 80. Isto é
exatamente o esperado em se tratando de servidores WEB.
Consideremos primeiramente o processo cliente (navegador) rodando no hospedeiro A. Apesar de este processo ter
escolhido a mesma porta de origem do processo rodando em C (porta origem x), os pacotes de A e C serão
corretamente demultiplexados, pois o servidor WEB ainda pode diferenciar os pacotes devido ao campo IP de
origem. Analogamente, também não haverá problema na identificação de pacotes de duas aplicações rodando no
mesmo hospedeiro cliente (como ocorre em C). Os pacotes serão diferenciados através do número da porta de
origem, que deve ser diferente para cada um dos processos(neste exemplo, temos x e y). Uma breve conclusão é que
o servidor identifica os pacotes pelo campo 'IP de origem', e duas aplicações no mesmo cliente se diferenciam pela
campo 'porta de origem'.
O servidor WEB, por sua vez, tem duas abordagens para gerenciar estas conexões. Ele pode, a cada nova requisição,
criar um novo thread (inserido em um único grande processo), ou criar um novo processo. Threads são mais
eficientes, uma vez que exigem/alocam menos recursos de hardware para serem executados. Observe que nas duas
abordagens, o servidor designará um socket único a cada thread/processo, que na prática, designa a porta pela qual os
dados passam da aplicação à camada de transporte.

Algoritimo de Controle de Congestionamento


O principal objetivo do controle de congestionamento é reduzir a taxa em que um remetente envia pacotes na rede.
Normalmente isso é conseguido diminuindo o tamanho da janela de congestionamento de todos os remetentes
quando a rede esta congestionada (ocorre perdas de pacotes).
Alguns dos principais algoritimos usados no controle de congestinamento são:
• Diminuição Multiplicativa: Nessa abordagem o TCP diminui a janela de congestionamento pela metade toda vez
que houver uma nova perda de pacotes. O valor da janela de congestionamento pode atingir um valor mínimo
igual a 1 MSS.
• Aumento Aditivo: Esse método é utilizado toda vez que não há congestionamento, o principio desse método é que
se nenhum congestionamento for detectado, provavelmente há largura de banda disponível e que pode ser usada
adicionalmente pelo TCP. Nessas circunstancias o TCP aumenta sua janela de congestionamento lentamente para
verificar se há largura de banda adicional disponível no caminho fim-a-fim. Isso é conseguido incrementando a
janela de congestionamento cada vez que um novo reconhecimento é recebido tendo como meta aumentar a
mesma de 1 MSS a cada tempo de viagem de ida e volta.
Multiplexação e demultiplexação 32

• Partida Lenta: No inicio de uma conexão o TCP inicia o valor da janela de congestionamento em 1 MSS. Nesse
caso a taxa de aumento da mesma aumenta exponencialmente, duplicando seu valor de janela de
congestionamento a cada RTT (Round Trip Time). Esse aumento exponencial continua até ocorrer o primeiro
evento de perda.

Referências
[1] http:/ / www. decom. ufop. br/ prof/ tiago/ disciplinas/ 2006/ sistDist/ trabalhos/ httpXtcp_arquivos/ Image1. gif

KUROSE; ROSS. Redes de Computadores e a Internet: Uma abordagem top-down. São Paulo: Pearson Addison
Wesley, 2006

Protocolo UDP
Introdução
O protocolo de transporte UDP foi referenciado pela RFC 768 em 28 de agosto de 1980. O UDP, ao contrário do que
muitos crêem, não é um protocolo anterior ao TCP. Inicialmente, não havia uma separação entre a camada de rede e
de transporte. Os protocolos TCP e IP eram referenciados como um único protocolo. Entretanto, à medida que se
percebia as limitações do protocolo para certas aplicações, as especificações foram mudando. Na versão 3(1978) do
TCP/IP já haviam indícios de separação entre os protocolos, e na versão 4(1980), há a separação total entre eles. Por
isso o protocolo IP começa na versão 4.
O UDP nasce então para servir como uma interface entre o IP e a camada de aplicação. Sua RFC possue apenas três
páginas e sua meta é ser um protocolo simples e rápido. Nela também, é definido que o UDP assume que está
rodando sobre o protocolo IP.
Em relação ao IP, adere poucos serviços, entre eles a verificação de erros(Checksum), suporte à multiplexação e
demultiplexação e suporte a broadcast e multicast. Demais serviços, como entrega confiável de dados e controle de
congestionamento podem ser implementados pela camada de aplicação, se o programador achar necessário.

Comparação entre TCP/IP e UDP

Melhor controle no nível da aplicação


Quando um processo passa dados, o UDP empacota e repassa para a camada de rede. No caso do TCP, o remetente é
limitado pelo controle de congestionamento. Além disso, o TCP reenvia os segmentos até a recepção ser conhecida.

Não há estabelecimento de conexão


O TCP usa a apresentação de três vias antes de transferir dados. O UDP simplesmente os envia, garantindo maior
velocidade. Por esse motivo o DNS roda sobre UDP. Já no caso do HTTP, para maior precisão na apresentação de
páginas de texto, por exemplo, é usado o TCP.
Protocolo UDP 33

Não há estados de conexão


O TCP mantém o estado da conexão: buffers de envio e recebimento, parâmetros de controle de congestionamento,
parâmetros numéricos de seqüência e de reconhecimento. O UDP não mantém estado, dessa forma, suporta mais
clientes ativos.

Pequena sobrecarga de cabeçalho


Além dos dados de cada segmento, apresentam as seguintes sobrecargas de cabeçalho de pacote: TCP = 20 bytes,
UDP = 8 bytes.

Estrutura do Segmento UDP


O segmento UDP contém quatro campos de cabeçalho com 16bts cada, como mostrado no figura abaixo. A porta da
fonte é um campo opcional que permite ao destinatário identificar o processo no remetente (demultiplexação) e a
porta de destino identifica o processo de destino do segmento UDP. O campo da mensagem contém os dados da
aplicação que está usando o segmento. Vamos observar mais detalhadamente o campo Checksum.

+ Bits 0 - 7 8 - 15 16 - 23 24 - 31

0 Source address

32 Destination address

64 Zeros Protocol UDP length

96 Source Port Destination Port

128 Length Checksum

160 Data
Protocolo UDP 34

Checksum
Checksum é um campo de 16bts
utilizado na detecção de erros
fim-a-fim em UDP. Embora o UDP
forneça verificação de erros, ele não
recupera esse erro. Algumas
implementações de UDP simplesmente
descartam o segmento danificado,
outras passam o segmento errado à
aplicação acompanhado de algum
aviso.
O principio de funcionamento do
Checksum é muito simples. Do lado de
remetente os dados são organizados em
pequenos blocos de 16bits. Realiza-se
a soma desses blocos e sobre o
resultado é feito o complemento de um
que é então armazenado no campo do
Checksum do segmento UDP. No lado
do destinatário o refaz-se o calculo
feito no remetente e o resultado é então
Effect of a typical checksum function (the Unix cksum utility).
somado ao Checksum. Se o resultado
for zero então considera-se que não
houve erros no segmento
Vale lembrar que o Checksum é um campo opcional. Sendo assim, entende-se do lado do destinatário que se o
Checksum estiver em zero, significa que a verificação não ocorrerá. Contudo, é possível no lado do remetente que o
resultado do complemento de um da soma dos bits enviados pode ser zero. Neste caso, se a aplicação estiver usando
Checksum então todos os 16bts serão marcados em um.

Checksums Simples
Os algorítmos mais simples de checksum quebram os dados em "palavras" com um número fixo de bits, e depois
conta o bit do "exclusive or" de todas essas palavras. O resultado muda quando um único bit dos dados está ao
contrário, e também quando dois ou mais bits em posições diferentes da palavra, estão trocados. Porém, esse
algorítimo de checksum não é muito sensível a erros comuns como:
• Mudar a ordem das palavras de dados;
• Inserir ou deletar palavras com todos os bits zerados;
• Trocar um número ímpar de bits na mesma posição da palavra.
Protocolo UDP 35

Checksums Avançados
Alguns algorítmos mais sofisticados com verificação reduntante, incluindo os algorítimos como:Fletcher's checksum,
Adler-32, and cyclic redundancy checks (CRCs), e eles são construídos para endereçar essas fraquezas através da
consideração nao só o valor de cada byte, mas também a sua posição. O custo dessa habilidade de detectar mais tipos
de erros é uma maior complexidade computacional ao fazer a verificação redundante de valores.
O Objetivo dos algorítimos de checksum é detectar modifiações acidentais como corrompimento de dados gravados
ou erros de comunicação de canais Eles não são construídos para detectar corrompimentos intencionais por agentes
maliciosos. Por isso, muitos algorítimos de checksum pode ser facilmente invertidos, no sentido de que alguém pode
facilmente modificar os dados para preservar o seu checksum. Para se proteger de modificações maliciosas, pode-se
usar um hash de criptografia.

Um exemplo de Algorítimos de Checksum


Um exemplo de Checksum Simples:
• Dados 4 bytes de dados: 0x25, 0x62, 0x3F, 0x52 (qualquer outra quantidade de bytes também é válida).
• Passo 1: Adicionando-se todos os bytes juntos temos 0x118.
• Passo 2: Retira-se o carry nibble para obter 0x18.
• Passo 3: Calcule o complemento de doisde 0x18 e teremos 0xE8. Esse é o byte de checksum.
• Passo 4: Para testar o byte checksum simplesmente o adicione ao grupo original de bytes. O resultado deverá ser
0x100.
• Passo 5: Retire o carry nibble novamente resultando em 0x00. O resultado 0x00 (0 em decimal), indica que não
houve erro (todavia um erro indetectável pode ter ocorrido).

Quando Utilizar o Protocolo UDP


• Fluxo de dados em tempo real:
• Multicasting:
• Broadcasting;
• E no geral, serviços que admitem certa perda de dados.

Exemplos de Serviços que usam UDP


• Youtube, e outros serviços de streaming, tanto de áudio, quando de vídeo;
• P2P;
• Skype, e inúmeros serviços de VOIP.
Transmissão de dados confiável 36

Transmissão de dados confiável


Transferência confiável de dados
Dentre todos os problemas que existem para a implementação de redes de computadores, podemos dizer que a
tranferência confiável de dados é um dos principais. Essa tarefa ainda é mais complexa, pois a implementação do
Protocolo de tranferência confiável de dados é feita em um canal confiável, porém possui a camada de rede logo
abaixo: um canal não confiável. Por exemplo: o TCP é um protocolo de tranferência de dados confiável
implementado sobre uma camada de rede fim-a-fim não confiável (IP).
Tranferência Confiável de dados [1] (Fonte: Rede de Computadores e a Internet, 3ª Edição, James F. Kurose)
A figura do link acima ilustra como é implementado o serviço de tranferência confiável de dados. Os pacotes são
enviados do remetente ao destinatário vindo das camadas superiores até as inferiores. O protocolo de tranferência
confiável de dados é implementado na camada de transporte. rdt é a sigla para Reliable Data Transfer que significa
transferência confiável de dados. Na figura, rdt_send() é chamada vinda da camada superior, (ex., pela aplicação).
Passa dados para entregar à camada superior receptora. udt_send()é chamada pela entidade de transporte, para
transferir pacotes para o receptor através do canal não confiável. rdt_rcv()é chamada pela entidade da camada
inferior quando o pacote chega ao lado receptor do canal e deliver_data()é chamada pela entidade de transporte para
entregar dados para camada superior.
Consideraremos apenas o caso de transferência unidirecional de dados, ou seja, do lado do remetente ppara o lado do
destinatário. Os diagramas utilizados para a exemplificação dos protocolos utilizam máquinas de estados finitos
(FSM) para especificar o protocolo transmissor e o receptor. É definido que estado é quando neste “estado” o
próximo estado fica unicamente determinado pelo próximo evento.
FSM [2]
A figura acima ilustra a abordagem FSM.

rdt1.0: Transferência confiável de dados sobre canais perfeitamente confiáveis


Primeiro é considerado um caso mais simples, na qual nao há erro de bits na transmissão e também não há perdas de
pacotes. As FSMs são separadas para transmissor e receptor na qual transmissor envia dados para o canal subjacente
receptor lê os dados do canal subjacente. Como não a erro de bits ou perdas de pacotes o papel do remetente é
simplesmente aguardar o pedido de envio da camada superior e enviar o pacote, voltando ao seu estado de espera de
nova solicitação. O lado do destinatário fica em estado de espera de chegada de pacotes da camada inferior, recebe
os dados, extrai e os envia para a camada superior.
RDT1.0 [3]
A figura acima ilustra a especificação da FSM do protocolo em questão.

rdt2.0: Canal com erros de bit


Já o rdt2.0 prevê envio de dados que podem chegar com erros ou comrrompidos. Para solucionar tal problema, é
implementado o conceito de resposta pelo destinatário ao remetente. Dessa forma o protocolo usa como resposta
reconhecimento positivo (ACK) e reconhecimento negativo (NAK). Nos reconhecimentos (ACKs)o destinatário
avisa explicitamente ao remetente que o pacote foi recebido corretamente e nos reconhecimentos negativos (NAKs)o
destinatário avisa explicitamente ao remetente que o pacote tem erros. Quando o remetente recebe um NAK ele faz o
reenvio do pacote.
RDT2.0 [4]
A figura acima ilustra a especificação da FSM do protocolo em questão.
Transmissão de dados confiável 37

rdt2.1: Solução para ACKs/NAKs perdidos


O rdt2.1 é uma versão que soluciona um problema que pode acontecer no rdt2.0 e na qual este nao soluciona.
Trata-se do sequenciamento dos pacotes e dos reconhecimentos positivos e negativos emitidos pelo destinatário.
Dessa forma é evitado a tranferência desnecessária de arquivos (duplicidade) e confusões em determinar para qual
pacote foi enviado o reconhecimento.
RDT2.1 REMETENTE [5]
RDT2.1 DESTINATÁRIO [6]
As figuras acima ilustram a especificação da FSM do protocolo em questão. Notamos que agora o remetente e o
destinatário possui duas vezes a mais o número de estados.

rdt2.2: Uso somente de ACKs


O rdt2.2 possui a mesma funcionalidade do rdt2.1, porém usando somente ACKs. Ao invés de enviar NAK, o
destinatário envia um ACK para o último pacote recebido sem erro incluindo explicitamente o número de seqüência
do pacote sendo reconhecido. O recebimento de ACKs duplicados no remetente resulta na mesma ação do NAK, ou
seja, a retransmissão do pacote corrente. Dessa forma nota-se uma maior simplicidade no FSM com relação ao rdt2.1

Protocolo rdt3.0
O que vimos até agora foi:
• Rdt1.0: um protocolo sobre um canal perfeitamente confiável;
• Rdt2.2: um protocolo mais real, onde há erro de bits.
Porém, há uma outra situação que normalmente ocorre em uma transferência de arquivos e que precisa ser tratada: a
perda de pacotes. Implementaremos então um mecanismo para detectar um pacote perdido e retransmiti-lo. Tal
mecanismo consiste da utilização de um temporizador de contagem regressiva que será acionado ao enviar cada
pacote do remetente ao destinatário.
Uma ilustração do mecanismo apresentado é a seguinte:
• um pacote pkt0 é enviado ao remetente, e o temporizador relativo à esse pacote é acionado.
• pkt0 chega ao destinatário e este envia o ACK0.
• se ACK0 chegar ao remetente, o temporizador de pkt0 é parado e será enviado o pkt1. Porém, caso o
temporizador chegue a 0 antes do ACK0 ser recebido, pkt0 é reenviado, e os passos anteriores são novamente
repetidos.
Utilizando o temporizador, nem o remetente nem o destinatário conseguem identificar o que houve com o pacote
enviado. Ele pode ter sido perdido, a resposta ACK pode ter sido perdida, ou simplesmente houve lentidão na rede, o
que fez com que o temporizador zerasse antes do recebimento do pacote ou do ACK. A última situação resulta em
pacotes duplicados, porém o protocolo rdt2.2 já corrige tal problema.

Transferência confiável de dados utilizando paralelismo


Com a utilização do protocolo rdt3.0 já são corrigidos os principais problemas que ocorrem em uma transferência de
dados. Resta-nos agora melhorarmos seu desempenho.
Por ser do tipo pare-e-espere o protocolo rdt3.0 envia apenas um pacote por vez, e só envia o próximo quando
receber a confirmação de recebimento do mesmo. Introduziremos então o conceito de paralelismo. Serão enviados
vários pacotes sequencialmente(apesar do nome indicar, os pacotes não são enviados ao mesmo tempo), mesmo sem
a recepção dos pacotes anteriores. Isso implica em maiores números de seqüência e na utilização de buffers do lado
remetente, e também do lado destinatário no caso da repetição seletiva, para mais de um pacote.
Transmissão de dados confiável 38

Serão apresentados dois protocolos que utilizam a idéia de paralelismo,Go-Back-N e Repetição Seletiva.

Protocolo Go-Back-N
Para solucionar os problemas causados pelo comportamento pare e espere dos protocolos anteriores, foi
desenvolvido o protocolo Go-Back-N. Este permite o envio de um determinado número de pacotes sem que os
anteriores tenham sido reconhecidos. Para um melhor entendimento vamos analisar a seguinte figura:
É definido um número de pacotes que podem ser enviados sem que seja necessário aguardar pelo reconhecimento de
cada um deles. Esta quantidade de pacotes pode ser vista como uma "janela". Na figura, os pacotes pretos são
pacotes que foram corretamente enviados e já receberam reconhecimento (receberam o ACK do destinatário). Os
pacotes azuis são pacotes que já foram enviados, mas ainda não foram reconhecidos, e os pacotes verdes são os
próximos pacotes a serem enviados, já que ainda estão dentro dos limites da janela. Os pacotes vermelhos estão fora
do limite da janela, logo não podem ser enviados ainda.
Nextseqnum é o número de sequência do próximo pacote a ser enviado. O pacote base é o pacote não reconhecido
com número de sequência mais antigo. Quando este pacote for reconhecido, a janela irá se deslocar para a direita no
espaço de números de sequência dos pacotes, permitindo o envio de outros pacotes. A janela "desliza", e com isso o
protocolo Go-Back-N é também denominado protocolo de janela deslizante.
O lado remetente deve ser capaz de responder a 3 situações:
• Dados recebidos da camada de cima
Antes de criar e enviar um pacote, o protocolo deve verificar se há espaço na janela. Se não houver, os dados serão
devolvidos, podendo ser enviados apenas quando um espaço for liberado;
• Recebimento de um ACK
Receber um ACK com número de sequência n indica ao remetente que todos os pacotes com número de sequência
até n (inclusive) foram recebidos corretamente pelo destinatário, e assim a janela desliza. O pacote com número de
sequência n+1 se torna a base;
• Esgotamento de temporização
É usado um temporizador para o pacote base. Se um ACK chegar antes do temporizador se esgotar, ele é reiniciado
para o pacote seguinte. Se ele se esgotar, todos os pacotes que foram enviados mas que ainda não foram
reconhecidos são reenviados.
O lado destinatário, ao receber um pacote com número de sequência n, que está na ordem esperada, envia um ACK
correspondente e entrega os dados à camada superior. Caso o pacote recebido não esteja na ordem, ele será
descartado e será reenviado um ACK para o último pacote recebido corretamente.
Esta característica garante que os pacotes sejam recebidos em ordem, mas descarta pacotes recebidos corretamente.
Se por um lado isto gera um prejuízo na necessidade de retransmissão de dados (que ainda podem ser perdidos,
gerando mais retransmissões), existe uma vantagem importante nesta opção: a simplicidade nos buffers do
destinatário. Não será preciso armazenar pacotes fora de ordem, mas apenas o número de sequência esperado para o
próximo pacote.
As figuras a seguir, retiradas do livro Computer Networking: A Top-Down Approach Featuring the Internet, de
James F. Kurose e Keith W. Ross, 3ª edição, mostram as FSM do lado remetente e do destinatário, e a operação
geral do protocolo, respectivamente.
Transmissão de dados confiável 39

Repetição Seletiva
O protocolo o Go-Back-N ou (GBN) resolveu um problema de vital importância para a transferência de dados, que é
a questão do aproveitamento e da utilização do canal. Com o GBN há envio de mais de um pacote sem a
obrigatoriedade de confirmação de recebimento do pacote anterior, ou seja, ele enche o canal com pacotes, N pacotes
(um numero finito), tendo assim um melhor aproveitamento do canal, da largura de faixa do canal. Porém a forma
como foi feito o GBN existem ainda algumas questões que prejudicam a transferência eficiente de dados. Estas
questões são: o tamanho da janela grande e/ou o produto entre atraso e largura de faixa também grande. Pensemos
sobre a janela, que é o mesmo conceito de janela do GBN. Vamos supor uma janela de tamanho para 100 pacotes. Se
houver qualquer erro, pode ser perda do pacote enviado ou perda do ACK enviado pelo destinatário, terá que ser
reenviado o pacote. O problema surge do fato que todos os pacotes posteriores ao que foi perdido terão de ser
também reenviados. Se houver erro no 10º pacote, todos os 90 restantes juntamente com o 10º terão de ser
reenviados, ou seja, haverá muitos reenvios desnecessários, tendo desta forma uma utilização também ineficiente,
apesar de já ter melhorado. Imagine agora uma janela com 1000 pacotes! Quanto maior a janela, mais o problema se
agrava. Se, também, o canal contiver uma taxa de erros alta, implica em maiores repetições. Como sabemos, os
canais reais não transmitem sem erros. Por mais que o canal seja confiável e com baixa taxa de erros, esses erros
existirão!
A repetição seletiva veio justamente melhorar esta questão. Agora, como o próprio nome sugere, não haverão
reenvios desnecessários. Apenas será retransmitido o pacote que tiver algum problema. Com isto há um bom ganho
de tempo nas transferências de dados. Analisemos agora a visão que tanto o remetente quanto o destinatário têm da
janela, primeiramente para o remetente:
Em verde podemos ver os pacotes que foram enviados e seus ACK’s já foram recebidos. Em amarelo são os que
foram enviados, mas ainda não chegou a resposta (recebimento do ACK). Em azul são os pacotes que foram
autorizados a serem enviados, mas ainda não foram. Em branco são os pacotes que ainda não foram autorizados ao
envio. Veja que alguns pacotes já tiveram confirmação de recebimento mesmo que pacotes anteriores ainda não
tenham sido confirmados. Isto é uma grande diferença da janela do GBN, e é justamente a isso que veio a Repetição
Seletiva, permitir que o destinatário reconheça pacotes fora de ordem, possibilitando assim retransmissões somente
dos arquivos com algum problema.
Como no GBN, os pacotes à medida que são recebidos da camada superior recebem um número de sequência. Se
este número estiver dentro da janela, então este pacote pode ser enviado, que são justamente os pacotes em azul. Ao
ser enviado sua classificação muda para amarelo, e finalmente ao receber confirmação de recebimento por parte do
destinatário o pacote passa a ser classificado como verde. Ao receber o ACK do pacote, se o pacote estiver no início
da janela, então a janela pula uma ou mais posições à frente conforme os pacotes posteriores forem verdes ou não.
Outra questão é quanto ao problema da perca de pacotes. Para isto é usado temporização, só que na repetição
seletiva, cada pacote tem de ter sua própria temporização, uma vez que só será retransmitido o pacote perdido.
Agora analisemos o destinatário. Os pacotes em lilás já foram recebidos, veja que eles estão fora de ordem, uma vez
que existem pacotes anteriores ainda não recebidos. Esta é mais uma diferença, e uma causa da repetição seletiva.
Esses pacotes ficarão em buffer no destinatário. Em cinza temos os pacotes que são aguardados, mas ainda não
recebidos. Em azul são pacotes aceitáveis, que também são aguardados por estarem dentro da janela. Em branco são
os pacotes não utilizados por estarem fora da janela. Como já dito, os pacotes já recebidos mas fora de ordem ficam
armazenados em buffer. Ao receber um pacote e este pacote sendo o primeiro da janela, ele será enviado à camada
superior juntamente com aqueles que já foram recebidos anteriormente e estão em sequência com este primeiro.
Então a janela desliza à direita por um numero de pacotes igual á quantidade de pacotes que foram à camada
superior. Em caso de o destinatário receber um pacote com número de sequência anterior ao número de inicio da
janela (rcv_base), ou seja, pacote já recebido, mesmo assim será necessário o envio de um ACK para que o
remetente possa movimentar sua janela à frente. Este fato pode ocorrer devido à perca do ACK, pois desta forma o
remetente nunca receberá confirmação e então reenviará o pacote, mas o pacote já foi recebido pelo destinatário,
Transmissão de dados confiável 40

porém o remetente não sabe disso, e por isso ele deve reenviar o ACK.
Na figura acima temos um exemplo de transmissão com a repetição seletiva. São enviados 4 pacotes (pkt0, pkt1,
pkt2, pkt3). Porém o pacote pkt2 é perdido e só chegam ao destinatário os pacotes pkt0, pkt1 e pkt3. O destinatário
recebe normalmente os três pacotes que chegaram, os armazena em buffer e envia seus respectivos ACK’s. O
remetente recebe confirmação para os pacotes pkt0 e pkt1 e envia então os pacotes pkt4 e pkt5. Nesse ponto o tempo
de vida do pacote pkt2 se esgota e então ele é reenviado. Os pacotes pkt4 e pkt5 são recebidos, armazenados em
buffer e o destinatário envia seus ACK’s. Só então o pacote pkt2 é recebido. Agora então, como pkt2 está no inicio
da janela ele é enviado para a camada superior juntamente com pkt3, pkt4 e pkt5 que estavam em buffer e na
sequência de pkt2. É então enviado o ACK respectivo a pkt2 (ACK2).

Referências
[1] http:/ / www. uploadimagens. com/ upload/ ebdbcfcb1e2ed83918d48c7a430c83fc. jpg
[2] http:/ / www. uploadimagens. com/ upload/ 10f4e26f1ace9be4ae779ce6451a84af. jpg
[3] http:/ / www. uploadimagens. com/ upload/ 2aa14739f2bf3f3602403d7074bcae7d. jpg
[4] http:/ / www. uploadimagens. com/ upload/ 5c91dbdcd59c6e9fc32a31ca87fd49eb. jpg
[5] http:/ / www. uploadimagens. com/ upload/ 05eb6c61f0eaf56efabbfd76bda5f2de. jpg
[6] http:/ / www. uploadimagens. com/ upload/ 6fa4767cf39f23f7d642c89a3406fa99. jpg

Protocolo TCP
Transporte orientado para conexão: TCP, protocolo de transporte confiável da camada de transporte, orientado
para conexão, da Internet.[1]
O TCP (Transmission Control Protocol - Protocolo de Controle de Transmissão) é um dos protocolos[2], sob os quais
assenta o núcleo da Internet nos dias de hoje. A versatilidade e robustez deste protocolo tornou-o adequado para
redes globais, já que este verifica se os dados são enviados de forma correta, na sequência apropriada e sem erros,
pela rede.
Protocolo TCP 41

A conexão TCP
TCP(Transmission Control Protocol) é um protocolo da camada de transporte, orientado a conexão. Ele é
responsável pela divisão da mensagem em datagramas, reagrupamento e retransmissão no caso de datagramas
perdidos.
Dentre suas principais vantagens, podemos destacar a segurança quanto à reposição de pacotes perdidos e ordenação
desses pacotes.

Estrutura do segmento TCP [3]


O segmento TCP é dividido em partes. Didaticamente é representado pelo bloco abaixo ilustrado, porém na prática é
enviado sequencialmente. Cada linha da tabela é um bloco de 32 bits, sendo que o bit inicial é de número 0.
O protocolo TCP permite que seu cabeçalho tenha tamanho variável, conforme as necessidades das estações
comunicantes e especifidades do enlace. A estrutura básica possui valores bem definidos, como as portas de origem
(16 bits) e de destino (16 bits).
Partes importantes no TCP são o número de seqüência (32 bits) e o número de reconhecimento (32 bits), pois estes
campos garantem a confiabilidade da transferência.Há também outros campos, como comprimento do cabeçalho (4
bits), que indica qual tamanho do cabeçalho em palavras de 32 bit, as flags (6 bits), que podem ser de 6 tipos:
• URG – urgência
• ACK – número ack válido
• PSH – push (envio imediato de dados)
• RST – reset (reinício da conexão)
• SYN – sync (estabelecimento de conexão)
• FIN – finalizar conexão
Protocolo TCP 42

Há também a janela de recepção (16 bits) que indica o tamanho da janela para controle de fluxo (figura acima), o
checksum (16 bits) que verifica a integridade dos dados de todo o pacote, como um hash; o ponteiro para dados
urgentes (16 bits) que indica que determinado dado deve ser entregue no mesmo instante, as opções (quantidade
variável de bits), que podem alocar mais banda do enlace para a transmissão dentre outras possibilidades, e os dados,
cuja quantidade é definida no MSS.
Protocolo TCP 43

A conexão TCP, por ser confiável, exige o estabelecimento de uma conexão, embora não seja necessário alocar
exclusividade de enlace (circuito dedicado[4]). É necessário existir um cliente e um servidor, porém como é um
protocolo full-duplex, um terminal pode ser simultaneamente servidor e cliente.
A confiabilidade da transmissão se deve ao número de seqüência e ao número de reconhecimento. O primeiro indica
qual é o primeiro byte do segmento de daos, e o segundo indica o primeiro byte do próximo segmento de dados. Isso
permite que os dados sejam agrupados corretamente, mesmo que pacotes tenham sofrido atrasos na transmissão.
O número de sequência é escolhido aleatoriamente no servidor e no cliente, e são independentes entre si, ou seja, não
é exigência que o número de sequência do servidor seja o mesmo do cliente. Mas então como é feita a comunicação?
Para isto é utilizada a flag ACK. Esta flag faz a sincronização dos números de sequência, como mostrado na figura a
seguir.

[5]

Estimativa do tempo de viagem de ida e volta e de esgotamento de


temporização
O TCP utiliza um mecanismo de controle de temporização/retransmissão para recuperar segmentos perdidos. Em um
protocolo real como o TCP, surgem problemas de implementação de um mecanismo de controle de
temporização/retransmissão como por exemplo, estimar o tempo de viagem de ida e volta da conexão - RTT (a
duração dos intervalos de controle deve ser maior do que o RTT, evitando o envio de retransmissões desnecessárias).

Estimativa do tempo de viagem de ida e volta - RTT [6]


O RTT para um segmento, denominado RTTamostra, é a quantidade de tempo transcorrido entre o momento em
que o segmento é enviado (isto é, passado ao IP) e o momento em que é recebido um reconhecimento para o
segmento. Ao invés de medir um RTTamostra para cada segmento transmitido, a maioria das implementações de
TCP executa apenas uma medição de RTTamostra por vez. Isto é, em qualquer instante, o RTTamostra estará
Protocolo TCP 44

sendo estimado para apenas um dos segmentos transmitidos mas ainda não reconhecidos, o que resulta em um novo
valor de RTTamostra para aproximadamente cada RTT. E mais, o TCP nunca computa um RTTamostra para um
segmento que foi retransmitido; apenas mede-o para segmentos que foram transmitidos uma vez.
Os valores de RTTamostra sofrerão variação de segmento para segmento devido a congestionamento nos roteadores
e a variações de carga nos sistemas finais. Por causa dessa variação, qualquer dado valor de RTTamostra pode ser
atípico. Portanto, para estimar um RTT típico, é natural tomar alguma espécie de média dos valores de
RTTamostra. O TCP mantém uma média, denominada RTTestimado, dos valores de RTTamostra. Ao obter um
novo RTTamostra, o TCP atualiza RTTestimado de acordo com a seguinte fórmula:
RTTestimado = (1 - a) * RTTestimado + a * RTTamostra
Esta fórmula está escrita sob a forma de um comando de linguagem de programação. O valor recomendado de a é a
= 0,125 (isto é, 1/8) [RFC 2988], caso em que essa fórmula de torna:
RTTestimado = 0,875 * RTTestimado + 0,125 * RTTamostra
Onde RTTestimado é uma média ponderada dos valores de RTTamostra. Essa média ponderada atribui um peso
maior às amostras recentes do que às amostras antigas.
Observação: O valor de "a" determina o peso das amostras mais recentes no cálculo da média, por exemplo, se "a"
vale 0,125, a última amostra analisada terá peso de 12,5% no valor de RTTestimado.
Além de ter uma estimativa do RTT, também é valioso ter uma medida de sua variabilidade. O [RFC 2988] define a
variação do RTT, RTTdesvio, como uma estimativa do desvio típico entre RTTamostra e RTTestimado:
RTTdesvio = (1 - b) * RTTdesvio + b * | RTTamostra - RTTestimado |
Onde RTTdesvio é uma MMEP (Média Móvel Exponencial Pura) da diferença entre RTTamostra e RTTestimado.
Se os valores de RTTamostra apresentarem pouca variação, então RTTdesvio será pequeno; por outro lado, se
houver muita variação, RTTdesvio será grande. O valor recomendado para b é 0,25.

Estabelecimento e gerenciamento da temporização de retransmissão


Considerando-se dispor dos valores RTTestimado, RTTamostra e RTTdesvio, pode-se estabelecer um valor para a
temporização de retransmissão do TCP (IntervaloTimeOut). Este valor deve ser maior ou igual a RTTestimado,
caso contrário seriam enviadas retransmissões desnecessárias, porém não deve ser muito maior pois se houver perda
de algum segmento, o TCP não o retransmitiria rapidamente, o que resultaria em grandes atrasos de transferência de
dados. Dessa forma, é desejável que o valor estabelecido para a temporização seja igual a RTTestimado mais uma
certa margem, que deverá ser grande quando houver muita variação nos valores de RTTamostra e pequena quando
houver pouca variação. Assim, o valor de RTTdesvio deve ser considerado:
IntervaloTimeOut = RTTestimado + (4 * RTTdesvio)

Transferência confiável de dados


Usa reconhecimentos positivos, temporizadores,números de seqüência e paralelismo

Recuperação de perdas de segmentos


Retransmissão rápida

Ignora os ACKs duplicados


Ignora controle de fluxo e de congestionamento
RFC 2581: Três ACKs duplicados ® retransmite o segmento que Falta
Reconhecimento cumulativo evita a retransmissão do primeiro segmento
Protocolo TCP 45

Gerenciamento da conexão TCP


A maior parte dos ataques à Web, atualmente, exploram vulnerabilidades apresentadas no gerenciamento das
conexões TCP. Além disso, importante observar, que o estabelecimento da conexão TCP interfere,
significativamente, nos atrasos percebidos em nossa navegação. Portanto, saber como as conexões TCP são
estabelecidas e finalizadas, possibilitando gerenciá-las, é bastante importante para garantia da confiabilidade inerente
ao protocolo TCP.
Para envio de pacotes entre hospedeiros, via TCP, é necessário, previamente, o estabelecimento de uma conexão
entre cliente e servidor. Para tanto, são necessárias três etapas, comumente chamada de apresentação de 3 vias (3
way handshake), conforme detalhado abaixo.

Etapa 1: o lado cliente do TCP encapsula e envia ao


servidor, em um datagrama IP, um segmento contendo um bit de flag
SYN ativado em 1 (requisição de estabelecimento de conexão) e um
número de sequência inicial escolhido aleatoriamente pelo próprio
cliente. Esse segmento é chamado TCP SYN.

Etapa 2: o servidor, por sua vez, ao receber datagrama IP,


extrai o segmento TCP SYN, aloca buffers e variáveis para conexão
TCP e envia um segmento de aceitação de conexão,
chamado SYNACK, contendo um bit de flag SYN ainda ativado em
1 e um ACK de reconhecimento do número de sequência inicial do
cliente, juntamente com a informação de sequência inicial do
servidor.

Etapa 3: por fim, o cliente recebe o SYNACK, reserva


buffers e variáveis para a conexão TCP, enviando um segmento
contendo um ACK de reconhecimento do número de sequência inicial
do servidor, o próximo número de sequência do cliente e um bit de
flag SYN ajustado em zero (conexão já estabelecida).

Pode acontecer, entretanto, situações em que o segmento TCP SYN recebido pelo hospedeiro apresenta número de
porta e/ou IP incompatíveis com as portas nele existentes. Neste caso, não há o reconhecimento do segmento TCP
SYN e, então, o hospedeiro (servidor) retorna ao cliente um segmento contendo um bit de sinalização RST, ativado
em 1, para reenvio/reinicialização da conexão.
Se essas três etapas forem bem sucedidas, os dados podem ser enviados entre um cliente e um servidor em
hospedeiros diferentes. Quando não se deseja continuar enviando pacotes, a conexão TCP pode ser finalizada pelo
cliente ou pelo servidor.
O encerramento acontece em 4 passos. Em suma, inicialmente o cliente envia, ao servidor, um segmento TCP FIN,
com um bit de flag FIN ajustado em 1, requisitando a finalização da conexão. O servidor recebe e envia, ao cliente,
um ACK de reconhecimento (etapa 2). Posteriormente, o servidor envia um segmento FIN, também ativado em 1, ao
cliente. Quando o cliente o recebe, responde com um ACK de reconhecimento e, então, a conexão é encerrada e os
recursos (buffers e variáveis) alocados para a conexão TCP são liberados.
Protocolo TCP 46

Encerramento da conexão TCP

Referências
[1] KUROSE,J. F.; ROSS,K. W. Redes de Computadores e a Internet - Uma abordagem top-down, 3ª Edição
[2] http:/ / pt. wikiversity. org/ wiki/ Introdução_às_Redes_de_Computadores/ Protocolos_e_serviços_de_rede
[3] TANENBAUM, A. S. Redes de Computadores; 4ª edição
[4] http:/ / pt. wikiversity. org/ wiki/ Introdução_às_Redes_de_Computadores/ Comutação_de_circuitos_e_de_pacotes
[5] KUROSE,J. F.; ROSS,K. W. Redes de Computadores e a Internet - Uma abordagem top-down, 3ª Edição
[6] KUROSE,J. F.; ROSS,K. W. Redes de Computadores e a Internet - Uma abordagem top-down, 3ª Edição
Controle de congestionamento 47

Controle de congestionamento
As causas e custos do congestionamento
Antes de conhecer os principais mecanismos de controle de congestionamento devemos entender por que o
congestionamento acontece e as consequências do mesmo, analizando três possíveis cenários.
Cenário 1: dois remetentes, um roteador com buffers infinitos
Supondo que tenhamos dois hospedeiros A e B que estejam enviando dados para os hospedeiros C e D. Não há
retransmissão de dados perdidos, controle de fluxo e nem controle de congestionamento e o roteador tem capacidade
de armazenamento infinita.
A vazão no destinatário (número de bytes por segundo) será igual à velocidade do envio do remetente até um certo
ponto em que não importa o quão rápido se envie os pacotes a vazão será limitada pelo enlace de comunicação
compartilhado entre os dois hospedeiros remetentes A e B, e quanto mais a velocidade de envio se aproxima desse
limite maior será o atraso médio, tendendo a infinito.
Analizando esse cenário vemos um custo do congestionamento que são os atrasos quando a velocidade de envio se
aproxima da capacidade do enlace.
Cenário 2: dois remetentes, um roteador com buffers finitos
Neste caso supomos que a capacidade de armazenamento do roteador seja finita, o que acarretará em descarte dos
pacotes que chegam a um buffer que já está cheio e depois a retransmissão do mesmo.
O desempenho ideal ocorreria se o remetente soubesse sempre quando o roteador está livre pois não haveria perda
alguma, porém sabemos que isso é impossível na realidade.
Na prática, há sempre a necessidade de se retransmitir pacotes que foram perdidos durante a comunicação, e embora
possamos usar de temporizadores para determinar se um pacote foi reconhecido ou não, pode ser que estes pacotes
estejam perdidos e levem um tempo a mais para chegar ao destinatário, levando o remetente a fazer retransmissões
desnecessárias.
Cenário 3: quatro remetentes, roteadores com buffers finitos e trajetos com múltiplos roteadores
Muitos roteadores implica em trajeto maior na transmissão de pacotes. O que pode ocorrer é que a conexão
estabelecida entre dois hospedeiros entre em competição com outra conexão estabelecida entre outros dois
hospedeiros e à medida que a transmissão de pacotes dentro de uma conexão fique maior, a outra conexão
estabelecida tenderá a cair no limite do tráfego pesado.
Outro custo também do congestionamento ocorreria caso um pacote seja descartado no meio do caminho (no repasse
de um roteador por exemplo), desperdiçando toda a transmissão feita até o momento em que o mesmo foi
descartado.

Mecanismos de controle de congestionamento


Dizemos que o controle é fim-a-fim quando a camada de rede (roteadores) não oferece suporte à camada de
transporte no controle de congestionamento. O controle será feito pelos sistemas finais observando o comportamento
da rede através de informações como perda de pacotes ou atraso. O protocolo TCP adota esse tipo de controle de
congestionamento.
O controle de congestionamento assistido pela rede conta com ajuda dos roteadores da camada de rede para fornecer
informações a respeito de congestionamento. O roteador poderá passar essa informação de congestionamento direto
para o remetente ou marcando um pacote para que o destinatário perceba o congestionamento e sinalize para o
remetente. O principal controle deste tipo que temos é o controle ATM ABR, usado na arquitetura ATM de
comunicação de dados.
Controle de congestionamento 48

Controle de congestionamento ATM ABR


A arquitetura ATM é baseada no conceito de circuito virtual de comutação de pacotes (células, na terminologia
ATM). O comutador (roteador) está sempre monitorando o comportamento de remetentes individuais e interferindo
na conexão afim de se controlar congestionamentos.
Nesta arquitetura, temos a presença de células de dados e das células de gerenciamento de recursos (células RM)
durante a transmissão, sendo estas últimas as que contêm informações sobre congestionamento entre hospedeiros e
comutadores.
As células de dados contém um bit EFCI (explicit forward congestion indication) que será sempre modificado para o
valor 1 quando um comutador detecta congestionamento. Ao receber esta informação o destinatário poderá modificar
para 1 o valor do bit CI (congestion indication) da célula RM quando a situação do congestionamento for grave ou
do bit NI (no increase) também da célula RM quando for mais leve.
Além dos bits CI e NI, a célula RM também possui um campo ER (explicit rate) de dois bytes, que estabelecerá uma
taxa mínima suportável por todos os comutadores à medida que o congestionamento aumente.

Controle de congestionamento TCP


O TCP usa controle de congestionamento fim-a-fim. Isto significa que o remetente limita ou aumenta a taxa de
entrega de dados para conexão em função do congestionamento percebido por ele, por isso dizemos que o TCP é
auto-regulado.
A conexão TCP é composta de um buffer de recepção, um buffer de envio e de diversas variáveis. Dentre essas
variáveis temos a CongWin (janela de congestionamento), que limitará a taxa de envio de pacotes de um remetente
TCP.
Ao início de cada RTT (tempo de ida e volta) o remetente enviará seus pacotes de acordo com o tamanho da
CongWin estabelecido, e ao final recebe reconhecimento para os dados, um sinal de que todos os pacotes foram
enviados corretamente.
Quando ocorre um evento de perda ou de três ACKs duplicados (ocasionando desperdício de pacotes) o remetente
reduzirá sua CongWin utilizando a chamada diminuição multiplicativa, reduzindo o valor da CongWin à metade.
Porém existe um limite mínimo do tamanho dessa janela, que é de 1 MSS (maximum segment size).
O TCP reconhece que não há congestionamento na rede quando recebe ACKs (reconhecimento de pacotes), então
aumentará a CongWin lentamente a cada tempo de ida e volta (aumento aditivo).
Esse comportamento do TCP de estar sempre aumentando a janela de congestionamento lentamente e depois
reduzindo à metade bruscamente gera um comportamento parecido com dentes de serra, se visualizado graficamente.
Durante o início de uma conexão TCP temos a fase de partida lenta, quando o remetente transmite a uma taxa lenta
(normalmente 1 MSS) e depois aumenta sua taxa exponencialmente, duplicando o valor de CongWin a cada tempo
de ida e volta até acontecer um evento de perda. O remetente TCP também pode entrar em fase de partida lenta após
um evento de esgotamento de temporização, ajustando a janela de congestionamento para 1 MSS e aumentando
exponencialmente até que a CongWin alcance metade do valor que tinha antes do evento (Threshold, em português,
patamar).

Referências
• Redes de Computadores e a Internet, JAMES F. KUROSE - KEITH W. ROSS
Camada de aplicação 49

Camada de aplicação
Em um modelo de comunicação, como o TCP/IP, as camadas mais inferiores têm a função de transmitir os dados
enviados pela camada de aplicação de maneira confiável, mas não fornecem serviços diretos aos usuários. Já a
camada de aplicação, fornece diretamente estes serviços, sendo assim, a camada de aplicação é “a razão de ser de
uma rede de computadores”[1]. No modelo TCP/IP não há as camadas de seção e apresentação, que na maioria das
aplicações são pouco usadas. Essas duas camadas estão incluidas na camada de aplicação.

Arquiteturas de aplicação
Uma Arquitetura de Aplicação define a estrutura de comunicação entre os utilizadores da aplicação. Existem
basicamente três tipos de arquitetura: Cliente-Servidor, Peer-to-Peer e uma arquitetura híbrida, que é uma mescla das
outros duas. Ao contrario de uma arquitetura de rede, que é fixa, ou seja, provê um conjunto específico de serviços
as aplicaçõoes, a arquitetura de aplicação deve ser escolhida pelo desenvolvedor da aplicação, determinando o modo
que a aplicação vai se comportar nos sistemas finais em uma rede.
Com essa classificação segundo a arquitetura (cliente-servidor, P2P ou híbrida) pode-se entender melhor como se
comportam as aplicações em uma rede. Em qualquer uma dessas arquiteturas, uma aplicação se comunica através de
pares de processos, onde um é rotulado cliente e outro servidor. Mesmo em uma aplicação do tipo P2P, o par que
solicita um arquivo de outra máquina, é denominado cliente, e o outro que fornece é o servidor.

Cliente e Servidor
Este modelo praticamente ocupava a única possibilidade e acabava assumindo como unanimidade o posto de
arquitetura de aplicação, isso ocorria devido a computadores poderosos, com muita memória, serem muito caros.
Com isso, a tendência era que existissem computadores potentes que centralizassem esses efeitos, por isso
MainFrames eram utilizados para armazenar dados de clientes para fazer operações remotas.
Na atualidade, apesar do avanço da tecnologia, trazendo computadores pessoais com maior possibilidade de
processamento e de memória, com custo baixo, esse modelo ainda se apresenta com muita força e aparentemente terá
forças para continuar por muito tempo ainda.
No modelo de arquitetura Cliente-Servidor, existem dois processos envolvidos, um no host cliente e um outro no
host servidor. A comunicação acontece quando um cliente envia uma solicitação pela rede ao processo servidor, e
então o processo servidor recebe a mensagem, e executa o trabalho solicitado ou procura pelos dados requisitados e
envia uma resposta de volta ao cliente, que estava aguardando. Nesta arquitetura o servidor tem uma aplicação que
fornece um determinado serviço e os clientes tem aplicações que utilizam este serviço. Uma característica desta
arquitetura, é que um cliente não se comunica com outro cliente, e o servidor, que tem um endereço fixo, esta sempre
em funcionamento. Quase sempre um único servidor é incapaz de suportar as requisições de todos os clientes, devido
a isso, na maioria dos casos são utilizados vários servidores que constituem um servidor virtual (server farm).
Um exemplo claro de aplicação Cliente-Sevidor é a comunicação entre um browser, que é usado para visualizar
páginas da internet, em um servidor web. Neste tipo de aplicação o cliente (browser) e o servidor (servidor web)
comunicam-se trocando mensagens através do protocolo HTTP.
Camada de aplicação 50

Peer-to-Peer
A arquitetura P2P (Peer-to-Peer) consiste em uma comunicação direta entre os clientes, não existe nenhuma divisão
fixa entre cliente e servidor. Cada par (peer) ativo requisita e fornece dados a rede, desta forma não existe a
dependência do servidor, isso aumenta significativamente a largura de banda e a redução de recursos. Esse tipo de
arquitetura é utilizado principalmente por aplicações de compartilhamento de conteúdo, como arquivos contendo
áudio, vídeo, dados ou qualquer coisa em formato digital. Outras aplicações orientadas a comunicações de dados,
como a telefonia digital, videotelefonia e rádio pela internet também utilizam esta arquitetura. Como exemplo
podemos citar o protocolo BitTorrent que utiliza a arquitetura peer-to-peer para compartilhamento de grandes
quantidades de dados. Neste exemplo um cliente é capaz de preparar e transmitir qualquer tipo de ficheiro de dados
através de uma rede, utilizando o protocolo BitTorrent.
Um peer (par) é qualquer computador que esteja executando uma instância de um cliente. Para compartilhar um
arquivo ou grupo de arquivos, um nó primeiro cria um pequeno arquivo chamado "torrent" (por exemplo,
Meuarquivo.torrent). Este arquivo contém metadados sobre os arquivos a serem compartilhados e sobre o tracker,
que é o computador que coordena a distribuição dos arquivos. As pessoas que querem fazer o download do arquivo
devem primeiro obter o arquivo torrent, e depois se conectar ao tracker, que lhes diz a partir de quais outros pares
que se pode baixar os pedaços do arquivo.
Camada de aplicação 51

Híbrida
Com uma pesquisa realizada pela empresa Xerox, foi detectado que pelo menos 70% dos usuários de P2P não
compartilhavam arquivo, enquanto apenas 1% compartilhavam 50% destes, ou seja, a teoria que se tinha de “divisão
de trabalho” pelos clientes, não valia na prática. Para isso então, buscou-se uma solução, e esta solução, representou
a utilização da arquitetura do tipo híbrida.
Uma híbrida, mescla das outras duas: cliente-servidor/P2P. Esta arquitetura utiliza, por exemplo, para transferência
de arquivos o P2P e a arquitetura cliente/servidor para pesquisar quais peers contêm o arquivo desejado. Uma
aplicação muito utilizada neste tipo de arquitetura é a de mensagem instantânea. O Windows Live Messenger e o
aMSN são bons exemplos, onde usuários podem bater papo online instantaneamente em tempo real. A comunicação
desta aplicação é tipicamente P2P, no entanto, para iniciar uma comunicação, um usuário registra-se em um servidor,
e verifica quem da sua lista de contatos também está registrado, para a partir de então começar uma comunicação.
Essas aplicações também disponibilizam transferência de arquivos, suporte a grupos, emoticons, histórico de chat,
suporte a conferência, suporte a Proxy, e outras ferramentas.
Camada de aplicação 52

A Comunicação entre os Processos


Na Internet, as aplicações devem "conversar" entre si, ou seja, o que o usuário deseja deve ser entendido pela outra
máquina e respondido. Essa comunicação é feita entre os processos, através da troca de mensagens. O remetente cria
mensagens com seus pedidos ao destinatário, que recebe e gera as suas mensagens para responder (ou não) a
solicitação.
Por exemplo, numa comunicação Web, o cliente solicita uma página da Internet, através de um determinado tipo de
mensagem (no caso, uma requisição HTTP). O servidor recebe a requisição, e envia uma mensagem com a página
para o cliente (através de uma resposta HTTP). Porém, se ocorre um erro, o servidor envia mensagens dizendo ao
cliente que ouve algum erro.
Geralmente, a comunicação consiste em pares de processos, onde um processo em cada lado envia mensagens para o
outro. Isso ocorre na rede através dos sockets, que são os "porta-vozes" de cada host para uma determinada
aplicação.
Para que haja essa comunicação, é necessário que os hosts se identifiquem. Para isso, usam o endereço IP. Porém, é
necessário também identificar qual processo naquela máquina irá levar as mensagens à aplicação, e essa
identificação é chamada de número (ou endereço) de porta.

Protocolos de Camada de Aplicação


Para que dois processos se comuniquem, eles devem trocar mensagens. Porém, é necessário haver regras que
padronizem como serão trocadas e tratadas essas mensagens. Por isso, existem os protocolos da camada de
aplicação. Como em Tanenbaum[2], "mesmo na camada de aplicação existe a necessidade de protocolos de suporte, a
fim de permitir que as aplicações funcionem."
É necessário definir os tipos de mensagens a serem trocadas, a sintaxe dos vários tipos de mensagens, a semântica
dos campos que compõem as mensagens e as regras que determinam quando e como um processo envia e responde
as mensagens. No entanto, como explica Kurose, é importante não confundir os protocolos de camada de aplicação
com as aplicações. São conceitos diferentes, apesar de os protocolos serem uma parcela significativa de uma
aplicação. Uma aplicação é a interface com o usuário, ou seja, aquilo que é realmente acessado. Os protocolos se
Camada de aplicação 53

responsabilizam por definir como os processos irão se comunicar e como irão tratar as mensagens, para expor o que
foi solicitado pelo usuário em sua aplicação. Por exemplo, para acessar uma página Web, um usuário executa um
programa Browser e solicita uma página. O Browser usa o protocolo HTTP para enviar o pedido da página, assim
como o servidor usa o mesmo protocolo para aceitar a requisição e devolver a página solicitada. O Browser
interpreta a mensagem vinda do servidor e apresenta a página.
Dentre os protocolos de aplicação, pode-se citar: HTTP (HyperText Transfer Protocol), HTTPS (HyperText Transfer
Protocol over Secure Socket Layer), FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), Telnet,
POP3 (Post Office Protocol version 3), e muitos outros.

O protocolo de Transporte para uma Aplicação


Uma aplicação necessita escolher um tipo de protocolo da camada de transporte, para que as mensagens sejam
entregues a aplicação de destino. Uma vez feito essa escolha, a camada de transporte tem a responsabilidade de levar
as mensagens pela rede. A internet oferece dois protocolos para a camada de transporte, o TCP (Transmission
Control Protocol) e o UDP (User Datagram Protocol). Para efetuar uma boa escolha, o desenvolvedor da aplicação
deve fazer uma escolha atentando-se a necessidade de sua aplicação. Com relação ao transporte, podemos citar, por
exemplo, a necessidade de transporte sem perdas, a necessidade de largura de banda na comunicação, a
temporização, no que se refere a aplicações interativas em tempo real, a necessidade de mecanismos de controle de
congestionamento e controle de fluxo (ou seja, compatibilidade de velocidades do remetente e do receptor), entre
outras.
O protocolo TCP oferece um serviço confiável de transferência de dados, ou seja, ele garante a entrega do dados do
socket emissor ao socket receptor, na ordem e sem perdas, ou seja, ao iniciar a comunicação entre dois hosts com
esse protocolo, é feito uma "conexão virtual" entre as portas dos hosts. O TCP utiliza o three-way-handshake para
iniciar a comunicação. Portanto, aplicações que envolvem transferência de arquivos, como correio eletrônico,
aplicações financeiras, visualizador de páginas da Web (browsers) e ate mesmo conexões remotas a computadores e
mensagens instantâneas, que necessitam de confiabilidade na entrega dos dados, ou seja, que não haja perdas,
utilizam o protocolo TCP. O TCP também oferece um serviço orientado para conexão, ou seja, ele faz com que o
cliente e o servidor troquem mensagens sobre informações de controle da camada de transporte, antes da
transferência de dados propriamente dita, e isso garante uma transferência orientada para conexão.
O protocolo UDP oferece um transporte simples e menos confiável, pois não é orientado para conexão, ou seja, não
existem procedimentos de verificação de envio e recebimento de dados. No entanto, pode haver checagem de
integridade e se algum pacote não for recebido, a aplicação do host de destino pode não fazer uma nova solicitação.
Essa característica de "bombear" os dados para o destino à velocidade que quiser, faz do protocolo UDP mais rápido
e ideal para certos tipos de aplicações. Existem aplicações que é preferível entregar os dados o mais rapidamente
possível, mesmo que algumas informações se percam no caminho. É o caso, por exemplo, das transmissões de vídeo
pela internet, onde a perda de um pacote de dados não interromperá a transmissão. Por outro lado, se os pacotes não
chegarem ou demorarem a chegar, haverá congelamentos na imagem, causando irritação ao usuário. O mesmo
acontece com aplicações de videoconferência, jogos em redes e telefonia pela internet.
Nem o TCP, nem o UDP oferecem garantia quanto a atrasos, ou seja, o TCP pode até garantir que os dados
cheguem, porém não garante um tempo mínimo para que isso ocorra. O UDP também: os dados podem ser aceitos
mais rápido que TCP, porém atrasos na rede podem tornar o serviço inútil.
Camada de aplicação 54

Referências
[1] James F. Kurose e Keith W. Ross, Redes de Computadores e a Internet - Uma abordagem Top-Down
[2] Andrew S. Tanenbaum, Redes de Computadores

HTTP
Protocolo HTTP
O protocolo HTTP, Hypertext Transfer Protocol ou Protocolo de Transferência de Hipertexto, é um protocolo da
camada de aplicação do TCP/IP cuja função é de proporcionar a transferência de hipertexto. Este protocolo é usado
desde 1990, atualmente está na versão 1.1.

Características do Protocolo HTTP


• É um protocolo de camada de aplicação da WEB
• É implementado em dois programas: Cliente e Servidor
• O HTTP é quem define a estrutura da mensagem que o cliente vai trocar com o servidor e utiliza TCP como seu
protocolo de transporte
• Protocolo sem estado. O que significa que ele não mantém memória sobre suas ações. Ou seja se um cliente fizer
uma requisição idêntica a uma anterior a qualquer momento, o HTTP não sabe informar sobre esse histórico.

Passos para uma comunicação HTTP


1. É estabelecida uma conexão TCP entre o programa cliente e o servidor.
2. O cliente envia uma requisição HTTP para sua interface socket.
3. O TCP leva essa mensagem para a interface socket do servidor.
4. O servidor envia uma resposta HTTP para sua interface socket.
5. O TCP leva essa resposta para a interface socket do cliente.

Conexões Persistentes e Não Persistentes


A versão HTTP/1.0 utiliza conexões TCP não persistentes na comunicação cliente-servidor. Já a versão 1.1 deste
protocolo utiliza conexões persistentes.

Conexões Não Persistentes


Neste tipo de conexão, cada objeto requisitado pelo cliente ao servidor é transportado por uma conexão TCP, que se
encerra imediatamente após a confirmação do recebimento do objeto. Desta forma, se um documento HTML, por
exemplo, referenciar outros objetos, como arquivos JPEG, GIF, entre outros, novas conexões TCP deverão ser
estabelecidas para transferência destes arquivos, além da conexão para obtenção do próprio arquivo HTML.
Os browsers podem ter interpretações diferentes, pois o HTTP define apenas o protocolo de comunicação entre o
cliente e o servidor. Podem ser configuradas conexões paralelas reduzindo o tempo de resposta. Por padrão, os
browsers utilizam entre 5 e 10 conexões paralelas.
HTTP 55

Conexões Persistentes
As conexões do tipo persistente são caracterizadas pelo fato da conexão TCP permanecer aberta após o envio da
resposta, ou seja, a conexão persiste durante o recebimento de todos os objetos referenciados. A requisição e a
resposta utilizam-se da mesma conexão, esta só será encerrada ou fechada quando não for usada por um tempo que
pode ser configurável. Desta forma, apenas uma conexão TCP é necessária para o recebimento completo de uma
página Web. Além disso, outras páginas Web que estejam no mesmo servidor podem ser completamente recebidas
pelo cliente através desta mesma conexão TCP.
Existem duas versões de conexões persistentes: sem paralelismo e com paralelismo. Na primeira, uma nova
requisição só é feita após a resposta da anterior, portanto, requer um RTT para cada objeto e pode permanecer ociosa
aguardando outra requisição. Naquelas com paralelismo, o cliente emite requisições assim que encontra referências,
ou seja, não aguarda respostas das requisições anteriores. Nesse caso, necessita apenas um RTT para todos os objetos
e fica ociosa uma fração menor de tempo.

Formato da Mensagem HTTP


Existem dois tipos de mensagem HTTP: requisição e resposta.

Requisição
Uma mensagem de requisição é formada por uma linha de requisição, as linhas de cabeçalho e o corpo da
mensagem.
A linha de requisição é formada pelo método, a URL e a versão http, todos separados por um espaço. O método é o
tipo de ação que a mensagem requer. Exemplos de métodos que são muito usados em mensagens http são GET,
POST e HEAD. A URL é o objeto sobre o qual a mensagem quer realizar a ação(método) requisitada. E a versão
http se refere à versão requisitada pela mensagem.
As linhas de cabeçalho devem conter detalhes sobre a requisição para o servidor. Podemos encaixar o cabeçalho das
mensagens de requisição em três tipos.
• Gerais: contêm informações referentes principalmente à própria mensagem, e são usadas para controlar seu
processamento e prover o receptor com informações extras.
• Requisição: fornecem para o servidor mais informações sobre a natureza da requisição do cliente, e dão ao cliente
mais controle sobre como a requisição é gerenciada. Podem também contar quais formatos ou códigos o cliente
consegue processar.
• Entidade: descrevem a entidade contida no corpo da mensagem, se existir alguma.
Normalmente a mensagem de requisição não irá possuir cabeçalhos de entidade, pois dificilmente uma mensagem de
requisição trará consigo um corpo de mensagem.
No corpo de mensagem, quando o mesmo existir numa mensagem de requisição, haverá uma entidade, que pode ser
um arquivo de música, uma imagem, uma página html, etc.

Resposta
Uma mensagem de resposta é formada por uma linha de estado, as linhas de cabeçalho e o corpo da mensagem.
Na linha de estado, teremos a versão http, o código da resposta, e uma mensagem associada ao código. A versão http
se refere à versão da mensagem de resposta. O código da resposta e a mensagem associada a ele trarão a informação
sobre os resultados do processamento da requisição do cliente. O código de resposta é um número de três dígitos que
indica o resultado formal que o servidor está comunicando ao cliente. Já a mensagem associada é opcional, e é um
texto descritivo que pode ser mostrado para o usuário humano do cliente http, que poderá então saber o que o
servidor respondeu.
HTTP 56

Exemplos de Códigos de estado:


• 200 OK: Requisição bem sucedida.
• 301 Moved Permanently: o objeto requisitado foi movido, e a resposta retornará uma nova URL, com a
localização do objeto.
• 400 Bad Request: o servidor não entendeu a requisição do cliente.
• 404 HTTP Not Found: O servidor não encontrou o objeto requisitado.
• 505 HTTP Version Not Supported: o servidor não suporta a versão http requisitada.
As linhas de cabeçalho devem trazer informações extras sobre a mensagem de resposta. Podemos encaixar o
cabeçalho das mensagens de resposta em três tipos.
• Gerais: assim como nas mensagens de requisição, deverão conter informações referentes principalmente à própria
mensagem, não tazendo informações sobre o corpo da mensagem.
• Resposta: provêem informação complementar visando ampliar as informações da linha de estado. O servidor
poderá também retornar informações extras no corpo da mensagem, principalmente se ocorrerem erros.
• Entidade: descrevem a entidade contida no corpo da mensagem, se existir alguma. São mais frequentes nas
mensagems de resposta.
No corpo de mensagem, quando o mesmo existir numa mensagem de requisição, haverá uma entidade, que pode ser
um arquivo de música, uma imagem, uma página html, etc.

Cache WEB ou Servidores Proxy


Nos últimos anos o número de usuários da Internet aumentou de maneira significativa e esse número cresce a cada
ano. Com isso, sem nenhum mecanismo de controle de banda ou constante aumento dessa banda, o tempo de
resposta em uma requisição de um cliente a um servidor pode demorar muito.
Para amenizar o impacto desses usuários na rede um mecanismo barato que tem sido largamente implementado é o
cache web. A ideia do cache web ou servidor proxy é muito simples: o cliente web se conecta ao cache web para
obter determinado conteúdo. Se o cache web não tiver o conteúdo solicitado armazenado, ele faz requisição ao
servidor web de destino. O conteúdo é então repassado primeiro ao cache web, que o armazena e só então é
repassado ao cliente web de destino. Pode-se dizer então que o proxy é tanto um servidor quanto um cliente.
Nesse processo tem-se um notável ganho de desempenho quando uma mesma página é requisitada várias vezes por
clientes web, pois o conteúdo solicitado está armazenado numa maquina local. Outro benefício é que tanto o servidor
web quanto a rede externa também são desafogados, já que a requisição do cliente não chegará até eles. De uma
forma mais global, os servidores proxy também melhoram o desempenho da Internet como um todo.

Cookies

Principais objetivos
Os cookies são pequenos arquivos gravados nos computadores clientes, com determinadas informações sobre
sessões do navegador. A principal função desses arquivos é a da persistência das sessões HTTP. Outras funções do
cookie é a restrição de acesso a determinados serviços e a identificação de usuários.

Funcionamento dos Cookies


A comunicação do cookie acontece basicamente em três etapas:
1. O Navegador solicita uma página
2. O Servidor responde com a página + o cookie
3. O Navegador pede outra página já utilizando o cookie
HTTP 57

Parâmetros dos Cookies


Todo arquivo de cookie, tem alguns paramêtros básicos. Dentre eles:
1. Nome
2. Valor
3. Tempo de Vida
4. Domínio

Utilização dos Cookies


Como exemplo de serviços que utilizam os cookies em larga escala, temos:
1. Comércio Eletrônico
2. Google Accounts
3. Redes Sociais
4. Bancos On-Line
5. Blogs
6. Fóruns

FTP
História
O primeiro protocolo a definir mecanismos para transferência de arquivos foi proposto em 1971, desenvolvido para
ser implementado em hosts do M.I.T. Em 1972, com a especificação RFC 354, o File Transfer Protocol – FTP é
então usado como o protocolo de transferência de arquivos da rede ARPAnet. Seu objetivo era transferir dados
confiavelmente e eficientemente, além de permitir o uso de armazenamento remoto de arquivos.
A partir de então, foram feitas algumas correções de erros, aprimorados pontos que demandavam mais ênfase e
adicionadas funcionalidades. Em 1973, como RFC 454, foi publicado o documento oficial do FTP, permanecendo a
estrutura original já concebida, mas incluindo mudanças importantes.Nos anos que se seguiram, vários comentários,
discussões e pequenas revisões foram publicados.
Em 1980, motivado pela transição do protocolo NCP para o TCP da rede ARPAnet, o FTP foi então especificado
para ser usado com o protocolo TCP. O último documento de especificação deste protocolo é o RFC 959.

FTP
Os objetivos do FTP são: promover o compartilhamento de arquivos, programas de computadores e/ou dados;
promover o acesso a computadores remotos; blindar o usuário da variação dos tipos de sistema de armazenamento de
arquivos entre os diversos hosts e finalmente, transferir dados de forma confiável e eficiente. Apesar do FTP poder
ser usado diretamente pelo usuário em um terminal, ele foi projetado para ser usado por programas principalmente.
É um dos protocolos mais usados para se transferir arquivos na Internet. Envolve tanto transferência de arquivos
quanto acesso a sistemas de arquivos remotos. Independe do hardware ou do sistema operacional e utiliza conexão
TCP para estabelecimento da conexão entre cliente e servidor. Faz uso de duas conexões paralelas para transferir um
arquivo: uma conexão de controle (informações de usuário e senha, comandos como GET ou PUT etc.) e uma
conexão de dados (usada para enviar, efetivamente, o arquivo). Devido a essa característica, dizemos que este
protocolo possui controle fora da Banda. A conexão de controle é dita persistente, ou seja, uma vez estabelecida a
sessão, ela permanece ativa durante toda a conexão. Já a conexão de dados é dita não persistente, ou seja, a cada
nova transferência, estabelece-se uma conexão, que é fechada após o término da tarefa.
FTP 58

Comandos FTP
No RFC 959 são definidos 33 comandos, que podem ser utilizados por um usuário em um terminal, embora seja
mais comum que as aplicações tenham interfaces que blindem o usuário destas linhas de comando. As instruções são
no formato ASCII, de 7 bits, em caracaters maiúsculos, com ou sem argumentos. Alguns dos comandos mais comuns
são USER username, PASS password, RETR filename etc. Os nomes são auto-explicativos. USER é usado para o
usuário especificado no argumento se conectar ao servidor FTP. RETR é usado para recuperar um arquivo,
especificado pelo argumento filename, e assim sucessivamente. Outros comandos são mostrados na tabela abaixo:

Comando Descrição

ascii Transfere arquivos no modo ASCII. Neste modo, há conversão de formatos, caso os sistemas operacionais envolvidos sejam
diferentes.

BIN Transfere arquivos no modo binário, não alterando nenhum bit do arquivo

LR ou DIR Listam o conteúdo do diretório atual

CD Permite mudar o diretório remoto

GET Transfere um arquivo da máquina remota para a local. Para transferir mais de um arquivo usa-se mget

HASH Imprime "#" a cada 1024 bytes transferidos. É importante para a visualização do progresso de transferencia de arquivos

PUT Transfere um arquivo da máquina local para a remota. Para transferir mais de um arquivo usa-se mput

QUIT ou Levam ao encerramento da conexão de controle levando ao término da conexão do FTP


BYE

Correio eletrônico
Introdução
O correio eletrônico, comumente chamado de email, foi utilizado inicialmente no meio acadêmico nos anos 80. Em
duas décadas, tornou-se bastante popular e sua utilização cresceu exponencialmente.
Os primeiros sistemas de correio eletrônico consistiam apenas em protocolos de transferência de
arquivos(mensagens). Ficou convencionado que a 1ª linha de cada mensagem devia conter o endereço do
destinatário. Essa técnica, aos poucos, se mostrou bastante deficitária e limitada, inviabilizando sua utilização no
envio de mensagens a um grupo de pessoas, por exemplo. Além disso, várias foram as críticas a esses sistemas,
dentre as quais destacamos:[1]
• as mensagens não apresentavam uma estrutura interna
• não havia garantia de entrega da mensagem
• a interface não era integrada ao sistema de transmissão, ou seja, usuário editava a mensagem, saía do editor e
“rodava” um software para transferência da mensagem.
• impossível enviar mensagem integrando texto, desenhos, voz, etc.
Após isso, foram propostos sistemas de correio eletrônico mais elaborados e completos. Em 1982, um grupo de
estudantes propôs o sistema de correio eletrônico da ARPANET, cujas propostas foram publicadas nas RFC821 e
RFC822, as quais tratavam de protocolos de transmissão e formatos de mensagens, respectivamente.
Correio eletrônico 59

Arquitetura e serviços [2]


Os sistemas de correio eletrônico são organizados em dois subsistemas: agentes de usuário, responsáveis pela leitura
e envio das mensagens e agentes de trasnferência/transporte de mensagem. Os agentes de usuário são programas
locais, cujos métodos podem ser baseados tanto em comandos como em menus/gráficos, o que permite interação
com o sistema de correio eletrônico. Os agentes de transferência, por sua vez, são responsáveis por executar tarefa
em 2º plano, ou seja, pela movimentação das mensagens por todo o sistema.
Um sistema típico de correio eletrônico apresenta 5 funções básicas, quais sejam:
• Composição: processo de criar mensagens e respostas
• Trasnferência: deslocamento de mensagens entre remetente e destinatário, de forma transparente para o usuário.
• Geração de relatórios: confirmação de entrega de mensagens
• Exibição: necessária para leitura das mensagens recebidas
• Disposição: Refere-se às possibilidades existentes para o destinatário após receber uma mensagem. Ex: apagar,
mover, etc

Definições
Para melhor entendimento, é necessário saber o significado de algumas siglas.
E-mail: Eletronic Mail, sinônimo de correio eletrônico. É também o nome dado à mensagem eletrônica enviada
através do correio eletrônico.
• MUA [3]: Mail User Agent, é o software utilizado pelo cliente para gerenciar seus e-mails. É responsável por
receber da caixa de entrada e repassar ao MTA para envio.
• MTA [4]: Mail Transfer Agent, realiza a transferência das mensagens. Recebe elas do MUA ou de outro MTA, e
com base no cabeçalho define a forma que entregará a mensagem ao MDA.
• MDA [5]: Mail Delivery Agent, promove a entrega das mensagens. As recebe do MTA e realiza a entrega na caixa
de mensagens do destinatário.
Além disso, os e-mails são compostos de basicamente duas partes: cabeçalho (ou header, definido pela RFC 822) e
corpo (ou body), onde o cabeçalho contém as informações do protocolo utilizado, do remetente, data, hora, assunto,
domínios, e diversas outras informações, enquanto o corpo contém a mensagem propriamente dita.
Received: by intranet.sender.com (Postfix, from userid 33)
id 65BDC5B7CF; Thu, 28 Aug 2008 12:35:02 -0300 (BRT)
To: fulano@recipient.com
Subject: Um teste
Date: Thu, 28 Aug 2008 12:35:02 -0300
From: Ciclano <ciclano@sender.com>
A grande maioria dos webmails e dos MUAs ocultam o cabeçalho completo, exibindo apenas informações básicas,
como remetente, destinatários, data e hora e assunto. Cada campo received indica um servidor SMTP que foi
visitado no trajeto da mensagem.
Cada conta de e-mail é uma caixa postal, onde seu proprietário pode criar novas mensagens, ler antigas, apagar,
classificar, dentre outros recursos, dependendo do servidor de e-mail.
Correio eletrônico 60

Protocolos de envio
Geralmente são utilizados pelos MTAs para envio de mensagens, e executam as transferencias de dados.

UUCP [6][7]
O primeiro protocolo de transferencia desenvolvido foi o UUCP (Unix to Unix CoPy), sob regência do RFC 976.
Surgiu e foi bastante difundido por volta dos anos 80.
Inicialmente foi utilizado na ARPANET, para troca de mensagens entre Universidades. Como funcionava sobre
redes comutadas por circuitos (e portanto a tarifação era por tempo de conexão), e ainda por ser necessário uma
conexão entre cada cliente, que muitas vezes estavam em outros países, era comum implantar um sistema
concentrador de atividades.
Este concentrador sincronizava-se com os clientes e armazenava as funções pedidas, como envio de e-mails e
transferencia de arquivos, e em determinada hora conectava-se e realizava as funções da fila. Após concluído,
desconectava-se e voltava a armazenar as funções.
Este comportamento conferia uma certa desvantagem por não sem em tempo real, com atrasos de várias horas, mas
com certeza havia grande vantagem sobre os correios convencionais, que demoravam dias ou meses. Os e-mails
conforme esta tecnologia eram formados pelo nome da máquina seguido de exclamação e do nome do usuário
(Exemplo: dominio.com.br!nome.de.usuario. Neste tipo de protocolo, era extremamente comum o uso de servidores
intermediários, o que barateava a comunicação. Em geral, um servidor só possuía acesso aos seus adjacentes. Se eu
fosse mandar um e-mail para a China por exemplo, deveria utilizar o endereço de destinatário
ServidorBrasil!ServidorEuropa!ServidorLesteEuropa!ServidorChina!usuário. Esta prática aumentava ainda mais o
atraso com que as mensagens chegavam.
Como esta definição de rotas estáticas era bastante trabalhosa, começaram a ser implantados na rede hops, que eram
máquinas capazes de interpretar as rotas e reescrever outras mais rápidas e menos congestionadas, o que melhorou a
velocidade da comunicação e reduziu custos.
Atualmente este protocolo ainda é utilizado em redes corporativas e alguns sistemas devido ao baixo custo,
gerenciamento não-persistente de filas, porém com adaptações para uso sobre o protocolo TCP/IP. Gradativamente,
no entanto, ela vem sido substituída por técnicas mais modernas.
A tecnologia utilizada pela NASA para comunicação com suas sondas e satélites é similar à UUCP.

SMTP [8][9]
SMTP, ou simple mail transfer protocol, conforme define o RFC 2821, é o protocolo mais utilizado atualmente para
transmissão de mensagens de correio eletrônico.
O protocolo é utilizado pelo MTA para transferir a mensagem, e ele serve justamente para definir padrões de como
entregar, e como interpretar os ados enviados. O padrão exige a codificação de binário em ASCII, e decodificação
ASCII para binário na passagem ao MDA.
Em geral, uma transferencia SMTP é direta entre o servidor de origem e o de destino, não passando por nenhum
intermediário. Os servidores armazenam as mensagens caso não possam ser entregues de imediato, por qualquer
falha ou impedimento. A conexão é feita na porta TCP 25.
A comunicação entre servidores SMTP é estabelecida sobre o protocolo TCP/IP, com a identificação dos
conectantes. Após estabelecida a conexão, há a troca de comandos entre o cliente e o servidor, iniciando-se com a
identificação do remetente, após do destinatário, e por fim a mensagem.
Por se tratar de uma conexão persistente, podem ser enviadas diversas mensagens sequencialmente, bastando apenas
especificar o remetente, destinatário e mensagem dos demais emails antes do comando de encerrar a conexão (quit).
S: 220 www.example.com ESMTP Postfix
Correio eletrônico 61

C: HELO mydomain.com
S: 250 Hello mydomain.com
C: MAIL FROM: sender@mydomain.com
S: 250 Ok
C: RCPT TO: friend@example.com
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: test message
C: From: sender@mydomain.com
C: To: friend@example.com
C:
C: Hello,
C: This is a test.
C: Goodbye.
C: .
S: 250 Ok: queued as 12345
C: quit
S: 221 Bye
Exemplo de transmissão SMTP

MIME [10]
MIME não é um protocolo de transmissão de e-mails. É um formato de codificação dos caracteres utilizados na
escrita do e-mail, ele serve para que letras em outros padrões de codificação diferentes do ASCII não sejam
truncadas, e para transmissão de dados multimídia. Significa Multipurpose Internet Mail Extensions, e é regido pelas
RFC 2045 e RFC 2046.
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="b1_ad752a574aae1a24143bb0f4add1f60d"
--b1_ad752a574aae1a24143bb0f4add1f60d
Content-Type: text/plain; charset = "iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Exemplo de cabeçalho MIME
O cabeçalho MIME utiliza-se basicamente de dois elementos fundamentais: content-type e
content-transfer-encoding.
O content-transfer-encoding indica qual codificação foi utilizada para transformar o conteúdo da mensagem em
ASCII para o envio por SMTP. Sem este dado a mensagem fica truncada, pois não se sabe como decodificar a
mesma. Há diversos tipos de codificação, sendo uma das mais comuns a quoted-printable.
O content-type define que tipo de conteúdo possui a mensagem, e indica ao MUA como tratar o determinado
conteúdo. Podem ser desde conteúdos multimídia até textos simples.
Correio eletrônico 62

Protocolos de recebimento
Os protocolos de recebimento permitem ao usuário pegar arquivos e mensagens de sua caixa postal para seu
computador local. Os protocolos utilizados para este fim são basicamente três: HTTP, IMAP E POP3.

POP3 [11][12]
Protocolo de acesso extremamente simples, definido pelo RFC 1939. Seu nome vem da abreviação de Post Office
Protocol versão 3.
Há basicamente três passos que devem ser executados: autenticação, transação e atualização. Na autenticação, após
estabelecida a conexão, o cliente fornece um nome de usuário e uma senha, sem nenhuma obfuscação. Após, há duas
opções para a transação: ler-e-apagar, e ler-e-guardar, o que influencia nos comandos que devem ser passados ao
servidor. Na fase de atualização, que ocorre após o término da conexão, o servidor apaga ou marca como lida as
mensagens, conforme definido na fase de transação.
Embora seja a 3ª versão deste protocolo, ele é muito simples. Utiliza-se basicamente de 6 comandos: user, pass, list,
retr, dele e quit. Responde basicamente de duas formas: err quando um comando está incorreto, e ok quando o
comando foi compreendido. A conexão é feita na porta TCP 110. Embora simples, é o mais indicado para pessoas
que acessam e-mail de apenas um local.

IMAP [13]
O protocolo IMAP (Internet Message Access Protocol) é mais robusto que o POP, e está em sua quarta versão,
primeira revisão., definido na RFC 3501. Seu poder aumentou sua complexidade relativamente ao POP.
O IMAP é ideal para usuário nômades, que acessam de diversos pontos, pois permite a gerência remota de ações,
inclusive entre sessões. Não entendeu? Você organiza sua mensagens na pasta local e elas são organizadas
similarmente na sua caixa postal, com comandos do usuário. Há também a vantagem de poder receber somente
determinada parte de uma mensagem, nos casos de uma conexão lenta, estreita, ou muito cara (como celular por
exemplo). Neste caso o usuário pode filtrar para receber parte da mensagem, escolher quais conteúdos baixar, ou
seomente mensagens pequenas.
O poder que este protocolo confere é imenso. Vale a pena ler a RFC 3501.

Protocolos híbridos

Webmail
O webmail ou e-mail sobre HTTP é uma funcionalidade excelente para usuários em trânsito. A transmissão das
mensagens para o servidor e da caixa de entrada ao usuário são feitas através do protocolo HTTP, que permite o
acesso através de qualquer browser.
Isto confere maior agilidade e portabilidade ao uso do e-mail. É importante lembrar que as trocas entre servidores de
webmail continuam sendo feitas através de SMTP.
O webmail pode ser considerada a modalidade de acesso a e-mails mais utilizada atualmente. Muitos webmails
utilizam scripts que conferem funcionalidades IMAP ao usuário.
Correio eletrônico 63

Referências
[1] TANENBAUM, A. S. Redes de Computadores; 4ª edição
[2] KUROSE,J. F.; ROSS,K. W. Redes de Computadores e a Internet - Uma abordagem top-down, 3ª Edição
[3] http:/ / www. feep. net/ sendmail/ tutorial/ intro/ MUA-MTA-MDA. html
[4] http:/ / www. feep. net/ sendmail/ tutorial/ intro/ MUA-MTA-MDA. html
[5] http:/ / www. feep. net/ sendmail/ tutorial/ intro/ MUA-MTA-MDA. html
[6] http:/ / www. uucp. org/
[7] http:/ / pt. wikipedia. org/ wiki/ UUCP
[8] http:/ / www. ietf. org/ rfc/ rfc2821. txt
[9] http:/ / en. wikipedia. org/ wiki/ Simple_Mail_Transfer_Protocol
[10] http:/ / pt. wikipedia. org/ wiki/ MIME
[11] http:/ / www. faqs. org/ rfcs/ rfc1939. html
[12] http:/ / www2. rad. com/ networks/ 1998/ pop/ index. htm
[13] http:/ / www. imap. org/

DNS
Domain Name System - DNS
Na internet as páginas web são geralmente conhecidas pelo seu apelidos ou nome de hospedeiro (hostname).
Embora sejam quase que exclusivamente conhecidas por esse nome, todos os hospedeiros são identificados também
pelo seu endereço IP. O endereço IP é formado por 4 octetos que constituiem 32 bits e possui uma estrutura
hierárquica rígida, de forma que quando examinamos este endereço da esquerda pra direita vamos obtendo cada vez
mais informações sobre sua localização na internet, coisa que não é possível examinando apenas seu nome de
hospedeiro.
Enquanto as pessoas preferem identificar esses hospedeiros pelo seu nome por serem mais fáceis de serem
lembrados, os roteadores preferem identificá-los pelo seu endereço IP, mais fáceis de serem processados por não
possuirem caracteres alfanuméricos de tamanhos variáveis.

História do DNS [1]


O DNS foi criado a partir da necessidade existente de traduzir os complicados números IP para um tipo de mais alto
nível, que poderia ser relembrado com facilidade por pessoas comuns. Com certeza foi um ponto de apoio para o
crescimento exponencial que a rede sofreu. Sua criação data do ano de 1983 pelo americano Paul Mockapetris, que
fez o trabalho a pedido de Jonathan Postel, um grande personagem que esteve presente na criação da ARPANET e
foi editor dos RFCs. Paul descreveu o sistema de nomes nas RFCs 882 e 883, posteriormente o protocolo foi
reformulado nas RFCs 1034 e 1035. A primeira implementação do DNS foi criada por um grupo de quatro
estudantes da Universidade da Califórnia Berkeley. Essa implementação foi melhorada no ano seguinte, dando vida
ao software que até hoje é mais conhecido servidor de domínios, o BIND (Berkeley Internet Name Domain).
DNS 64

Serviços fornecidos pelo DNS [2]


A tarefa de traduzir um nome de hospedeiro para endereço IP é feita pelo DNS (domain name system - sistema de
nomes de domínio), que é basicamente um conjunto de servidores distribuidos de forma hierárquica que recebe o
nome de hospedeiro que o usuário deseja e devolve o endereço IP correspondente. O protocolo DNS utiliza o
protocolo UDP e a porta 53 para comunicação.
Além de ser identificado pelo seu nome de hospedeiro, um hospedeiro pode também ser identificado por um ou mais
apelidos que simplificam um nome de hospedeiro complicado ou muito grande. O DNS pode ser chamado neste caso
para obter o nome de hospedeiro (também conhecido como nome canônico) e o endereço IP correspondente ao
apelido fornecido, assim como para certos servidores de correio que possuem apelido para simplificar o seu nome
canônico.
O DNS também pode ser usado para fazer distribuição de carga entre servidores web ou de e-mail replicados,
principalmente para sites movimentados que rodam em vários servidores e possuem endereços IP diferentes.

Modo de funcionamento do DNS [3]


Os servidores DNS são distribuídos de forma hierárquica entre vários servidores por todo o mundo, de forma que
não concentre todo o processo em um único servidor, o que sobrecarregaria o mesmo, tornaria o processo mais lento
e mais sujeito a falhas. Os servidores DNS dividem-se em três classes:
• Servidores de nomes raiz: há 13 servidores de nomes raiz no mundo, responsáveis por passar uma lista de
servidores TLD correspondentes ao endereço IP desejado;
• Servidores TLD (nomes de domínio de alto nível): são responsáveis por domínios de alto nível como com, org,
net ,edu, gov, uk, fr, jp, br e outros;
• Servidores de nomes com autoridade: são a parte final do processo, geralmente as próprias organizações,
responsáveis por passar o endereço IP em si correspondente ao nome de hospedeiro informado.
Também há o servidor DNS local contido em cada ISP (internet service provider - provedor de serviços de internet).
Este não integra a hierarquia de servidores DNS, apenas faz o repasse do nome de hospedeiro e recebe o endereço IP
correspondente dos servidores que integram a hierarquia.
Para que um host acesse uma URL qualquer ("www.amazon.com", por exemplo) na internet, primeiramente ele
envia uma mensagem de requisição para o servidor de nomes local. O servidor local envia uma consulta ao DNS
raiz, o qual percebe o sufixo 'com' e responde uma lista de endereços IP para o DNS local contendo servidores TLD
que são reponsáveis por 'com'. Em seguida, o DNS local faz requisição para um desses servidores TLD, o qual
percebe o sufixo 'amazon.com' e envia ao DNS local o endereço IP do servidor DNS com autoridade para a Amazon.
Finalmente, o DNS local consulta o servidor com autoridade e esse responde com o endereço do hospedeiro
'www.amazon.com'. Assim, o DNS local responde ao hospedeiro o IP do nome solicitado.
A partir do processo relatado acima, vemos que há consultas recursivas e iterativas. Entre o hospedeiro e o DNS
local, a consulta é recursiva, uma vez que o hospedeiro pede que o DNS local obtenha o mapeamento em seu nome.
Enquanto que as outras três consultas (DNS local com DNS raiz, TLD e autoridade) são iterativas, já que as
respostas são retornadas diretamente ao DNS local. Em teoria, qualquer consulta DNS pode ser iterativa ou
recursiva, porém, na prática, as consultas geralmente são feitas conforme o padrão exposto acima. A figura abaixo
ilustra o caminho de uma consulta DNS para resolver o endereço IP de determinado nome, similarmente ao que foi
apresentado acima:
Os servidores DNS, sejam eles de qualquer tipo, podem fazer uso de cache de DNS para agilizar o processo. Quando
é feito uma requisição ao servidor, este armazena em sua memória a resposta correspondente, de forma que quando a
mesma requisição é feita novamente ele dará a resposta imediatamente, não necessitando fazer toda a procura
novamente. Essa informação fica armazenada por um certo período de tempo, geralmente 2 dias, até ser atualizada
DNS 65

novamente em uma outra requisição.

Registros e Mensagens DNS


As informações sobre o DNS são armazenadas em zonas. Em uma zona pode haver informações sobre um ou mais
domínios. As informações são adicionadas em uma zona do DNS, através da criação de registros de recursos (RR).
Um RR corresponde a uma tupla composta basicamente de quatro elementos (nome, valor, tipo e TTL-Tempo de
vida útil do RR) e ele fornece mapeamentos de hospedeiros para endereços IP. Cada mensagem de resposta DNS
carrega um ou mais registros de recursos. Abaixo segue uma descrição dos principais tipos de RRs:
A: É o tipo mais utilizado, faz o mapeamento de um nome DNS para um endereço IP versão 4, de 32 bits.
Exemplo:
host1.example.microsoft.com. IN A 127.0.0.1
AAAA: Faz o mapeamento de um nome DNS para um endereço IP versão 6, de 128 bits.
Exemplo:
ipv6_host1.example.microsoft.com. IN AAAA 4321:0:1:2:3:4:567:89ab
CNAME: (Canonical Name)- Mapeia um alias (apelido) ou nome DNS alternativo. Por exemplo, suponha que o site
da empresa esteja no servidor srv01.abc.com.br. Porém na internet, os usuários irão utilizar o nome
www.abc.com.br. Neste caso basta criar um alias www que faz referência ao nome srv01.abc.com.br. Pronto, quando
os usuários digitarem www.abc.com.br estarão acessando, na verdade, o endereço srv01.abc.com.br. Porém para o
usuário, tudo ocorre transparentemente, como se o nome fosse realmente www.abc.com.br.
Exemplo:
www.abc.com.br. CNAME srv01.abc.com.br.
NS: É utilizado para relacionar um nome DNS com o seu dono, ou seja, o servidor que é a autoridade para o nome
DNS. Ou em outras palavras, o servidor DNS onde está a zona primária associada ao nome.
Exemplo:
example.microsoft.com. IN NS nameserver1.example.microsoft.com
MX: Fornece informações utilizadas pelos servidores de e-mail, para o roteamento de mensagens. Cada host
definido em um registro MX deve ter um correspondente registro do tipo A em uma zona válida, no servidor DNS.
Exemplo:
example.microsoft.com. MX 10 mailserver1.example.microsoft.com
Nota : O número de dois dígitos após o MX, é um indicativo da ordem de preferência quando mais de um registro
MX é configurado na mesma zona.
PTR: É utilizado em zonas reversas, para fazer o mapeamento reverso, ou seja, o mapeamento de um número IP
para um nome. Ao criar um registro do tipo A, em uma zona direta, você pode criar, automaticamente, o registro
PTR associado, se já houver uma zona reversa configurada.
Exemplo:
10.20.20.10.in-addr.arpa. PTR host.example.microsoft.com.
HINFO: Utilizado para armazenar informações sobre o hardware do servidor DNS, tais como tipo de CPU, tipo e
versão do sistema operacional e assim por diante. Estas informações podem ser utilizadas por protocolos como por
exemplo o ftp, o qual utiliza procedimentos diferentes, para diferentes sistemas operacionais
Exemplo:
my-computer-name.example.microsoft.com. HINFO INTEL-386 WIN32
DNS 66

As duas únicas espécies de mensagens DNS existentes são a de consulta e resposta DNS. Esses dois tipos de
mensagens possuem o mesmo formato e são compostas da seguinte maneira:
• O cabeçalho é formado por 12 bytes, dos quais 16 bits são designados a identificar a consulta. Esse identificador é
copiado para a mensagem de retorno à consulta da qual ele foi originado. Assim, a partir da propagação desse
identificador, vemos que é possível que o cliente combine respostas recebidas com consultas enviadas. O
cabeçalho é ainda composto basicamente por mais cinco campos. São eles: Flags, que indica se uma mensagem é
de consulta ou resposta e também se o servidor de nomes indicado na mensagem de resposta se trata de um
servidor com autoridade ou não, dentre outras funções; e quatro campos "números de" (Perguntas, Respostas,
Autoridade e Informação adicional).
• A seção de pergunta contém informações a respeito de uma consulta que está sendo feita e inclui um campo para
nome de quem está sendo consultado e outro que indica o tipo de pergunta que está sendo feita sobre o nome.
• Uma outra seção, chamada seção de resposta, possui os registros de recursos para os nomes referentes às
consultas. Como é possível que um mesmo hospedeiro tenha diversos endereços IP (como em servidores WEB
replicados), uma resposta pode retornar vários RRs.
• A seção de autoridade é aquela que, como o próprio nome induz, contém registros de servidores com autoridade.
• Já a seção adicional contém outros registros úteis, como por exemplo, conter o registro do tipo A que fornece o
endereço IP para o nome canônico do servidor de correio.
Listagem completa de RR's:

Referências
[1] en.wikipedia.org
[2] KUROSE,J. F.; ROSS,K. W. Redes de Computadores e a Internet - Uma abordagem top-down, 3ª Edição
[3] KUROSE,J. F.; ROSS,K. W. Redes de Computadores e a Internet - Uma abordagem top-down, 3ª Edição
Programação com sockets 67

Programação com sockets


Inicialmente é preciso conceituar o que é socket. A comunicação entre processos de software tornou-se indispensável
nos sistemas atuais.
O elo entre os processos do servidor e do cliente é o socket. Ele é a “porta” na qual os processos enviam e recebem
mensagens. De acordo com JAMES F KUROSE: “socket é a interface entre a camada de aplicação e a de transporte
dentro de uma máquina”.
Então foram desenvolvidas diversas aplicações cliente/servidor onde cliente(s) e servidor poderiam estar em
máquinas diferentes, distantes umas das outras. Os aplicativos do cliente e do servidor utilizam protocolos de
transporte para se comunicarem. Quando um aplicativo interage com o software de protocolo, ele deve especificar
detalhes, como por exemplo se é um servidor ou um cliente. Além disso, os aplicativos que se comunicam devem
especificar detalhes adicionais (por exemplo, o remetente deve especificar os dados a serem enviados, e o receptor
deve especificar onde os dados recebidos devem ser colocados).
Analisando o esquema acima percebemos que tudo acima da interface do socket, na camada de aplicação, é
controlado pelo criador da aplicação. O controle da camada de transporte é feito pelo Sistema Operacional.
Temos dois tipos de serviços de transporte via socket: o confiável orientado a cadeia de bytes (byte steam) e os
datagramas não confiáveis. O protocolo na qual é implementado o primeiro é o TCP, já o segundo é implementado
no protocolo UDP.

Histórico
Na década de 1980 nos Estados Unidos a ARPA (Advanced Research Projects Agency of the Department of
Defense) deu à Berkeley, Universidade da California a responsabilidade de construir um sistema operacional que
pudesse ser utilizado no suporte à ARPAnet, que é o antecessor da internet atual.
Neste sentido, foi desenvolvida uma interface e adicionada ao sistema operacional, Unix BSD (Berkeley Software
Distribution). Tal interface tinha justamente a função de suporte a comunicação em rede. Esta interface ficou então
conhecida como Berkeley Sockets Interface, e é a base para a maioria das interfaces entre protocolos de internet
TCP/IP existente.
Existe uma nomenclatura específica para se referir a cada “lado” da comunicação. Temos o servidor, que fica
esperando por conexões de entrada e que fornece certos tipos de serviços à outra parte. Já o Cliente vem a ser quem
solicita a conexão ao servidor para fazer alguma requisição, algum pedido. É importante dizer que não é o
computador que distingue quem é servidor e quem é cliente, mas sim a forma como certo programa usa os sockets.
Às vezes também se faz confusão no fato de se pensar que um servidor precisa ser um mainframe. Desktops como os
que usamos em casa funcionam tanto como cliente quanto como servidor, e é o que ocorre freqüentemente.
Cada socket tem um endereço único na internet. Este endereço é formado por um número IP e por um número de
porta. Devido às grandes dimensões da internet, não há como uma pessoa, ou mesmo uma máquina, saber o endereço
de todas as outras. Para resolver este problema foi criado protocolo DNS (Domain Name Service). Este protocolo
tem a função de traduzir os nomes ou endereços de alto nível das máquinas para o seu respectivo número IP. Assim,
ao se passar o endereço de um socket de um servidor, não se passa diretamente seu número IP, mas sim um nome
mais fácil de recordar e então o DNS traduz para o endereço real, ou endereço IP.
Os sockets podem ser usados para comunicação via qualquer um dos protocolos UDP ou TCP. Assim, é possível
termos tanto comunicação orientada a conexão (via TCP), quanta não orientada a conexão (via UDP). O socket
abstrai esse conceito, permitindo assim a utilização de qualquer um dos meios.
Programação com sockets 68

Programação de aplicações TCP


Inicialmente o cliente deve contactar o servidor. Para isso, o processo servidor já deve estar executando o programa
antes de ser contactado além de já ter criado o socket (porta) que aceita o contato do cliente. O cliente contacta o
servidor criando um socket TCP local e especifica o endereço IP e o número da porta do processo servidor. Quando
o servidor é contactado o servidor cria um novo socket para se comunicar com o cliente, permitindo assim a
liberação do socket de “boas-vindas” para que possa ser contactado por outros clientes.
Do ponto de vista da aplicação, a conexão TCP é um fluxo cotínuo de dados, a mensagem é fragmentada em pacotes,
não há duplicação, ele garante a entrega e a ordem dos pacotes. A conexão é ponto-a-ponto: um remetente e um
destinátario conectado por sockets.
Este texto não tem como objetivo o aprendizado da linguagem Java, portanto só serão demonstradas e explicadas as
linhas de códigos referentes às instruções que são utilizadas no programa exemplificado pela ilustração acima.
Começando com a aplicação que será hospedada no Servidor.
No início do programa, deverá ser inserida essas linhas que importam a biblioteca que contém as classes que são
utilizadas em uma aplicação com Socket(java.net.*) e as classes de recepção de informação do teclado ou Socket do
cliente ou servidor(java.io.*).

import java.io.*;
import java.net.*;

Aqui criamos um objeto welcomeSocket é o socket do lado do servidor, numero_da_porta deverá ser substituido
pelo número da porta pela qual a aplicação cliente usará para conectar com o servidor. Este socket esperará a
requisição de conexão de um cliente.

ServerSocket welcomeSocket = new ServerSocket(numero_da_porta);

Como o programa servidor normalmente fica funcionando por tempo indefinido, coloca-se o restante das instruções
dentro de um loop infinito, como segue:

while(true) {
...
}

A próxima instrução cria um objeto connectionSocket do tipo Socket quando um cliente conectar ao servidor. O TCP
encarregará de criar uma conexão virtual direta entre esse socket e o socket do cliente de forma que todos os bytes
serão enviados ao servidor na ordem certa.

Socket connectionSocket = welcomeSocket.accept();

No caso do envio de um objeto do tipo String do cliente para o servidor, utilizamos as seguintes instruções para
receber os dados do cliente.
BufferedReader infoDoCliente = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream());

String mensagemDoCliente = infoDoCliente.readLine();

Depois de processar a informação enviada pelo cliente, queremos enviar um outro objeto(mensagem_para_cliente)
do tipo String de volta para o cliente, como um mensagem de dado recebido ou algo do tipo.
DataOutputStream infoParaCliente = new DataOutputStream(connectionSocket.getOutputStream());
infoParaCliente.writeBytes(mensagem_para_cliente);

Com isso termina-se o programa do lado do Servidor. Agora analisaremos o programa cliente.
Programação com sockets 69

Como no caso do programa servidor, o código inicia com a importação das bibliotecas que contém as classes de
sockets e de envio de informações.

import java.io.*;
import java.net.*;

Primeiramente, criamos o socket que conectará com o servidor. O primeiro parâmetro passado ao construtor é o
nome do servidor, por exemplo, 127.0.0.1 se a aplicação servidor estiver rodando no mesmo computador que a
aplicação cliente. O segundo parâmetro é o número da porta que é informado ao socket servidor.

Socket clientSocket = new Socket("nome_do_servidor", numero_da_porta);

Após a criação do socket cliente, temos que criar os objetos de cadeia que serão ligados ao socket. O objeto
infoParaServidor será a cadeia que enviará informações para o servidor e o objeto infoDoServidor será a cadeia que
receberá informações do servidor.
DataOutputStream infoParaServidor = new DataOutputStream(clientSocket.getOutputStream());

BufferedReader infoDoServidor = new BufferedReader(new InputStreamReader(client.getInputStream()));

Utilizaremos o mesmo caso do servidor, e enviaremos(mensagem_do_cliente) e


receberemos(mensagem_para_cliente) dois objetos do tipo String para exemplificar.

infoParaServidor.writeBytes(mensagem_do_cliente);
String mensagem_para_cliente = infoDoServidor.readLine();

Agora já podemos fechar o socket, e também a conexão TCP entre cliente e servidor.

clientSocket.close();

Sockets UDP são mais rápidos que sockets TCP; São mais simples, porém menos confiável; Em UDP não é
necessário abrir conexão, deste modo a comunicação ocorre apenas com o envio da mensagem; Um mensagem é um
datagrama, que é composto de um remetente (sender) e um receptor (receiver) e a mensagem (content).

Programação de sockets com UDP


A comunicação entre processos também é possível por UDP. Entretanto, UDP é um serviço sem conexão. Com isso,
não há o three-way handshaking (ou apresentação de três vias)inicial, e assim não há um canal pré-estabelecido entre
os processos. Para que a comunicação entre os processos seja possível, deve-se incorporar ao conjunto de bytes
enviados tanto o endereço IP do destino quanto a porta do processo de destino. Este conjunto (bytes + endereço IP +
porta) recebe o nome de pacote.
Com o pacote criado, ele é colocado na rede através do socket. O processo receptor deverá abrir o pacote para retirar
as informações pertinentes. Sendo o UDP um serviço sem conexão, não há garantias de que o pacote realmente
chegará ao seu destino.
Na comunicação por TCP, não é necessário que todas as cadeias de bytes recebam endereço IP e número de porta, já
que existe uma tubulação virtual, pela qual as cadeias fluem, que possui estas informações adicionais. Já na
comunicação por UDP, não havendo esta tubulação virtual, torna-se necessário que as cadeias de bytes sejam
organizados em pacotes, todos com endereço IP e número de porta.
Abaixo segue uma exemplo de programação em socket com UDP. Assim como dito anteriormente, o objetivo aqui
não é ensinar java, mas sim exemplificar programação com sockets. Comecemos pela parte do servidor.

DatagramSocket serverSocket = new DatagramSocket(9876);


Programação com sockets 70

Diferentemente do TCP, aqui criamos um objeto do tipo DatagramSocket e não ServerSocket. Os dados que serão
enviados e recebidos pelo servidor passarão todos através deste socket do tipo DatagramSocket. Não se faz
necessário a criação de um objeto DatagramSocket para cada nova conexão. Todas as conexões dos clientes passarão
por esse único socket serverSocket. Isto não é um problema porque cada vez que recebe um pacote, o servidor
responde e fica livre novamente, pois inexiste conexão entre ambos. O socket escuta na porta 9876.

while (true) { ... }

Loop infinito, onde o servidor fica esperando o recebimento de pacotes.

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);


serverSocket.receive(receivePacket);

O objeto receivePacket aloca memória onde serão salvos os dados de entrada, recebidos pelo servidor. O método
receive fica esperando o recebimento e armazena o pacote em receivePacket.

String sentence = new String(receivePacket.getData());


InetAddress IPAdress = receivePacket.getAddress();
int port = receivePacket.getPort();

Estas linhas desmontam o pacote, retirando informações necessárias à retransmissão. O objeto sentence recebe os
dados. IPAdress é o número de IP do cliente, que é necessário para mandar a resposta assim como o número de porta
port. Todos estes dados foram enviados pelo cliente. Após o processamento a resposta é enviada para o respectivo
endereço IP e número de porta.
Do lado do cliente temos a criação do socket pelo qual será enviado um pacote da seguinte forma:

DatagramSocket clientSocket = new DatagramSocket();

Note que a única diferença entre o socket cliente e o servidor é de que para o servidor foi necessário especificar um
número de porta, e para o cliente não. Este comando não cria conexão alguma e nem contata o servidor, e é
justamente por isso que não se faz necessário especificar nome do servidor nem seu numero de porta.

InetAddress IPAddress = InetAddress.getByName(“hostname”);

Aqui criamos um objeto para armazenar o número de IP do Server. Hostname é o nome (apelido) do servidor. O
método getByName() faz uma consulta ao servidor DNS para saber qual o número IP do server.

byte[] sendData new byte[1024];


byte[] receiveData = new byte[1024];

Estes dois vetores armazenarão os dados enviados e recebidos respectivamente.


DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAdress, 9876);

Esta linha cria o pacote que será enviado ao Server. Nele estão gravados os dados em si, sendData, o tamanho dos
dados, sendData.length, o numero de IP do Server, IPAdress, e o numero da porta onde o Server espera, 9876.

clientSocket.send(sendPacket);

Depois de pronto, enviamos o pacote através do método send do socket clientSocket. Enviado o pacote o cliente fica
esperando uma resposta.

clientSocket.receive(receivePacket);

Quando ocorre o recebimento do pacote, ele é armazenado em receivePacket.


Fontes e Editores da Página 71

Fontes e Editores da Página


Introdução  Fonte: http://pt.wikibooks.org/w/index.php?oldid=271272  Contribuidores: Abacaxi, Defender, 1 edições anónimas

Arquitetura de redes de computadores  Fonte: http://pt.wikibooks.org/w/index.php?oldid=270857  Contribuidores: Abacaxi, Alguém, 1 edições anónimas

Protocolos e serviços de rede  Fonte: http://pt.wikibooks.org/w/index.php?oldid=266767  Contribuidores: Abacaxi, Guiwp, 1 edições anónimas

Meios físicos de transmissão  Fonte: http://pt.wikibooks.org/w/index.php?oldid=270066  Contribuidores: Abacaxi, Defender, 1 edições anónimas

Comutação de circuitos e de pacotes  Fonte: http://pt.wikibooks.org/w/index.php?oldid=247355  Contribuidores: Abacaxi

Pilha de protocolos da Internet  Fonte: http://pt.wikibooks.org/w/index.php?oldid=265357  Contribuidores: Abacaxi, Stryn, 3 edições anónimas

História da Internet  Fonte: http://pt.wikibooks.org/w/index.php?oldid=271441  Contribuidores: Abacaxi, Marcos Antônio Nunes de Moura, 4 edições anónimas

ATM  Fonte: http://pt.wikibooks.org/w/index.php?oldid=267251  Contribuidores: Abacaxi

Camada de rede  Fonte: http://pt.wikibooks.org/w/index.php?oldid=251995  Contribuidores: Abacaxi

Protocolo IP  Fonte: http://pt.wikibooks.org/w/index.php?oldid=247335  Contribuidores: Abacaxi

Camada de transporte  Fonte: http://pt.wikibooks.org/w/index.php?oldid=251994  Contribuidores: Abacaxi

Multiplexação e demultiplexação  Fonte: http://pt.wikibooks.org/w/index.php?oldid=270383  Contribuidores: Abacaxi, 2 edições anónimas

Protocolo UDP  Fonte: http://pt.wikibooks.org/w/index.php?oldid=269946  Contribuidores: Abacaxi, 3 edições anónimas

Transmissão de dados confiável  Fonte: http://pt.wikibooks.org/w/index.php?oldid=247341  Contribuidores: Abacaxi

Protocolo TCP  Fonte: http://pt.wikibooks.org/w/index.php?oldid=247338  Contribuidores: Abacaxi

Controle de congestionamento  Fonte: http://pt.wikibooks.org/w/index.php?oldid=247342  Contribuidores: Abacaxi

Camada de aplicação  Fonte: http://pt.wikibooks.org/w/index.php?oldid=269975  Contribuidores: Abacaxi, Marcos Antônio Nunes de Moura, 2 edições anónimas

HTTP  Fonte: http://pt.wikibooks.org/w/index.php?oldid=247350  Contribuidores: Abacaxi

FTP  Fonte: http://pt.wikibooks.org/w/index.php?oldid=253150  Contribuidores: Abacaxi, Alguém

Correio eletrônico  Fonte: http://pt.wikibooks.org/w/index.php?oldid=247347  Contribuidores: Abacaxi

DNS  Fonte: http://pt.wikibooks.org/w/index.php?oldid=266107  Contribuidores: Abacaxi, 1 edições anónimas

Programação com sockets  Fonte: http://pt.wikibooks.org/w/index.php?oldid=247348  Contribuidores: Abacaxi


Fontes, Licenças e Editores da Imagem 72

Fontes, Licenças e Editores da Imagem


Image:NetworkTopologies.png  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:NetworkTopologies.png  Licença: Public Domain  Contribuidores: Bensin, Fastily, Grafite,
Kilom691, Maksim, Malyszkz, Waldir, YMS, 16 edições anónimas
Imagem:Camadas.jpg  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Camadas.jpg  Licença: Public Domain  Contribuidores: Leofaragao
Imagem:Servicos.jpg  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Servicos.jpg  Licença: Public Domain  Contribuidores: Leofaragao
Imagem:Modelos(cortado1).png  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Modelos(cortado1).png  Licença: Creative Commons Attribution-Share Alike  Contribuidores:
Alancaio
Image:Checksum.svg  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Checksum.svg  Licença: Public Domain  Contribuidores: Original by Helix84, adapted by Jorge Stolfi
Image:Versiones_de_TCP_en_BSD.svg  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Versiones_de_TCP_en_BSD.svg  Licença: Public Domain  Contribuidores: Adam majewski,
Berthgmn, Clemente, Mdd, Popolon, Pyfisch, Skim, WikipediaMaster, 1 edições anónimas
Image:TCP_windowing.png  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:TCP_windowing.png  Licença: GNU Free Documentation License  Contribuidores: User:Nuno Tavares
Image:Estrutura_TCP.png  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Estrutura_TCP.png  Licença: Attribution  Contribuidores: Lauro Ramon Gomides
Image:Comunicação_TCP_cliente_servidor.png  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Comunicação_TCP_cliente_servidor.png  Licença: GNU Free Documentation
License  Contribuidores: Diego.takashi
Imagem:TCP termination.png  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:TCP_termination.png  Licença: GNU Free Documentation License  Contribuidores: User:Nuno
Tavares
Imagem:Cliente-servidor.jpeg  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Cliente-servidor.jpeg  Licença: Creative Commons Attribution-Share Alike  Contribuidores: Alancaio
Imagem:ProjetoP2P.jpeg  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:ProjetoP2P.jpeg  Licença: Creative Commons Attribution-Share Alike  Contribuidores: Alancaio
Imagem:Híbrido.jpeg  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Híbrido.jpeg  Licença: Creative Commons Attribution-Share Alike  Contribuidores: Alancaio
Ficheiro:DNS_RR.jpg  Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:DNS_RR.jpg  Licença: Creative Commons Zero  Contribuidores: 1freemind4u
Licença 73

Licença
Creative Commons Attribution-Share Alike 3.0
//creativecommons.org/licenses/by-sa/3.0/