CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Redes - Parte III PROTOCOLO TCP/IP _______________________________________ 91
1
ENDEREÇO IP _______________________________________________________ 91
1.1 MÁSCARA DE REDE _____________________________________________________ 92
1.2 ENDEREÇO DE BROADCAST._____________________________________________ 93
1.3 ENDEREÇOS DE REDES ESPECIAIS: ______________________________________ 94
1.4 OUTRAS NOTAÇÔES DE ENDEREÇAMENTO ______________________________ 95
2
SUB-REDES E SUPER-REDES _________________________________________ 96
2.1 EXERCÍCIOS ____________________________________________________________ 98
2.2 Exercícios para Laboratório: ________________________________________________ 98
3
PROTOCOLOS ARP E RARP ___________________________________________ 98
3.1 ARP (Address Resolution Protocol)___________________________________________ 99
3.2 RARP (Reverse Address Resolution Protocol) __________________________________ 99
3.3 A FORMA DA MENSAGEM ARP ou RARP _________________________________ 100
3.4 EXERCÍCIOS: __________________________________________________________ 101
4
PROTOCOLO IP _____________________________________________________ 101
4.1 O FORMATO DE UM DATAGRAMA IP ____________________________________ 102
4.2 FRAGMENTAÇÃO E REMONTAGEM DOS DATAGRAMAS _________________ 106
5
ROTEAMENTO IP ___________________________________________________ 107
5.1 ENVIO DIRETO _________________________________________________________ 107
5.2 ENVIO INDIRETO_______________________________________________________ 110
5.3 ROTEAMENTO IP POR TABELAS ________________________________________ 110
5.4 ROTEAMENTO TIPO "NEXT-HOP"_______________________________________ 110
5.5 ROTA PADRÃO _________________________________________________________ 112
5.6 ROTAS ESPECIFICAS DE HOSTS _________________________________________ 112
5.7 ROTEAMENTO ENVOLVENDO SUB-REDES E SUPER-REDES ______________ 113
5.8 ALGORITMO DE ROTEAMENTO_________________________________________ 115
5.9 EXERCÍCIOS ___________________________________________________________ 116
6
PROTOCOLO ICMP __________________________________________________ 116
6.1 FINALIDADE ___________________________________________________________ 116
6.2 FORMATO DA MENSAGEM ICMP________________________________________ 116
89
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
7
PROTOCOLO DE PORTAS ____________________________________________ 118
8
PROTOCOLO UDP ___________________________________________________ 119
8.1 FORMA DAS MENSAGENS UDP __________________________________________ 119
8.2 QUANDO UTILIZAMOS O UDP? __________________________________________ 121
8.3 Exercícios: ______________________________________________________________ 121
9
PROTOCOLO TCP ___________________________________________________ 121
9.1 PROPORCIONANDO A CONFIABILIDADE NO ENVIO E RECEBIMENTO ____ 122
9.2 A IDENTIFICAÇÃO DAS CONEXÕES _____________________________________ 124
9.3 A FORMA DOS SEGMENTOS TCP ________________________________________ 124
9.4 INICIO E TÉRMINO DAS CONEXÕES - "THREE WAY HANDSHAKE" _______ 126
9.5 EXEMPLOS DE SERVIÇOS TCP: _________________________________________ 127
9.6 QUANDO UTILIZAMOS O TCP? __________________________________________ 127
9.7 EXERCÍCIOS: __________________________________________________________ 127
ANEXO: ____________________________________________________________________ 128
TESTE 1:_______________________________________________________________________ 128
TESTE 2:_______________________________________________________________________ 128
TESTE 3:_______________________________________________________________________ 129
TESTE 4:_______________________________________________________________________ 129
TESTE 5:_______________________________________________________________________ 130
TESTE 6:_______________________________________________________________________ 131
TESTE 7:_______________________________________________________________________ 131
TESTE 8:_______________________________________________________________________ 132
CONCLUSÕES DOS TESTES______________________________________________________ 132
90
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Redes - Parte III
PROTOCOLO TCP/IP
Denominamos de TCP/IP um conjunto de protocolos encontrados em todas as camadas do
modelo TCP/IP. Todos, de alguma forma, usam endereços IPs. Mesmo aqueles
encontrados na camada de interface (ARP e RARP) associam o endereço físico ao
endereço IP.
Neste capítulo veremos alguns detalhes do TCP/IP, seus protocolos e respectivos
cabeçalhos e detalhes de funcionamento e configuração de algumas aplicações.
1 ENDEREÇO IP
No protocolo TCP/IP, um nó com ou sem identidade física pode possuir sua identidade
lógica IP. Esta identidade é um Número IP ou endereço IP. Este número tem um tamanho
de 32 bits e é representado, normalmente, na forma decimal de cada byte separado por um
"." (ponto).
Ao receber um datagrama IP o software TCP/IP de um equipamento compara o endereço
de destino existente no cabeçalho do protocolo de rede com seu endereço IP. Se o
resultado desta operação coincidir com seu endereço IP (ou um conjunto deles associado
àquela máquina), então a máquina de destino é ela mesma. Caso o endereço não coincida
então o datagrama é descartado.
Um endereço IP é constituído por uma tripla (bits de identificação da classe, identificação da
rede - netid, identificação do nó lógico daquela rede - hostid). Quando aplicamos a máscara,
tratamos o endereço IP como uma dupla (identificação de rede, que envolve os bits da
classe e o netid, e o hostid). Identificamos as classes de endereçamento como mostra a
figura:
Assim, no formato decimal byte-a-byte, temos as seguintes faixas de endereçamento:
91
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Classe
A
B
C
D
E
Início
0.0.0.0
128.0.0.0
192.0.0.0
224.0.0.0
240.0.0.0
até
até
até
até
até
Final
127.255.255.255
191.255.255.255.
223.255.255.255
239.255.255.255
255.255.255.255
Algumas faixas de endereçamento e endereços individuais são reservadas para
endereçamento específico. É o caso do endereço 0.0.0.0 que, dependendo do objetivo da
implementação TCP/IP (software de roteamento ou usado por uma estação) representa o
endereço de uma máquina gateway ou mesmo um endereço global.
O endereço 255.255.255.255 representa um endereço coringa. Se não fosse pelas
restrições de roteamento, um pacote enviado para este endereço alcançaria TODAS as
máquinas de uma rede, por maior que ela fosse.
Cada rede tem, portanto, um endereço que a identifica, ou endereço de rede, que
representa a identificação da rede; e um endereço coringa ou endereço de broadcast. que
representa todos os nós lógicos daquela rede.
Com as classes de rede, temos um pequeno número de redes lógicas que admitem um
grande número de endereços de nós lógicos (redes da Classe A) e um grande número de
redes lógicas com um pequeno número de nós lógicos (redes da Classe E).
As classes D e E são muito especiais. São representam endereços lógicas de multicast e
experimentais, respectivamente. Reparem que um endereço IP representa, neste caso, uma
"rede" de máquinas.
1.1
MÁSCARA DE REDE
Como se identifica a rede?
Uma vez que o endereçamento IP possui 32 bits isto significa 4Giga-endereços diferentes o
que exigiria uma tabela de igual tamanho para ser tratada caso o roteamento fosse por
endereço absoluto. Separando em redes as tabelas são reduzidas. Para isto, usamos o
endereço de máscara. Operando logicamente (AND) tais máscaras sobre o endereço IP
o resultado fornece a identificação da rede. Um exemplo de máscara válida para uma
rede que contém a maquina de número IP 192.168.45.10 é: máscara = 255.255.255.0 , cuja
representação binária é:
11111111 11111111 11111111 00000000.
Relembrando, a tabela verdade da função lógica E (AND):
92
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
0 AND 0 = 0
0 AND 1 = 0
1 AND 0 = 0
1 AND 1 = 1
Assim, na forma binária, considerando o endereço 192.168.45.10,
11000000 10101000 00101101 00001010
11111111 11111111 11111111 00000000
11000000 10101000 00101101 00000000
(192.168.45.10)
(255.255.255.0)
(192.168.45.0 )
AND
=
número IP de identificação
da rede)
ou, na representação decimal:
192.168.45.10
255.255.255.0
192.168.45.0
(número IP da máquina) AND
(máscara) =
(número IP de identificação da rede)
De forma genérica:
ID da Rede = #IP .AND. #MÁSCARA
1.2
ENDEREÇO DE BROADCAST.
E quanto ao endereço de broadcast?
Como dito anteriormente, o Endereço IP de broadcast é um endereço coringa, ou seja,
todas as máquinas de uma mesma rede IP também se reconhecem por este endereço que
tem os bits do hostid em 1, e pode ser calculado por:
(end. broadcast) = (ID da rede) + (NOT.máscara)
(NOT) é uma operação lógica e apresenta a seguinte tabela:
NOT 1 = 0
NOT 0 = 1
Assim, se a máscara é: 11111111 11111111 11111111 00000000
(NOT)11111111 11111111 11111111 00000000 = 00000000 00000000 00000000 11111111
Somando entre este resultado ao endereço da rede temos o endereço de broadcast.
11000000 10101000 00101101 00000000 . (192.168.45.0) +
00000000 00000000 00000000 11111111 (0.0.0.255) =
11000000 10101000 00101101 11111111 (192.168.45.255) (endereço de broadcast)
Visto a necessidade das máscaras, as classes de rede receberam as máscaras
padronizadas:
93
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Classe
A
B
C
D
E
Máscara Padrão
255.0.0.0
255.255.0.0
255.255.255.0
255.255.255.255
255.255.255.255
Com isto, a classe A possui 256 redes e cada rede (256*256*256) 16777216 endereços.
Tirando o endereço IP da rede e o endereço de broadcast, uma rede classe A permite
16777214 nós válidos (teoricamente). Por que teoricamente? Porque o endereço 0.0.0.0 não
foi desconsiderado. Porque, apesar de válido, a classe A inicia em 0.1.0.0 que também não
foi desconsiderado.
A Classe B permite 65536 redes e cada rede com este mesmo valor de nós Tirando o
endereço de rede e o endereço de broadcast temos 65534 endereços válidos por rede.
A Classe C permite 16777216 redes e cada rede com 256 nós (teóricos). Tirando o
endereço de rede e o endereço de broadcast temos 254 endereços válidos por rede.
As Classe D e E representam redes de um único nó lógico. Estas redes não possuem
endereço de broadcast.
Assim, podemos generalizar para quaisquer redes oriundas das classes A, B e C as regras
de Identificação de Rede e do endereço de broadcast.
1.3
ENDEREÇOS DE REDES ESPECIAIS:
O IANA (Internet Address Number Authority) selecionou alguns espaços de endereçamento
para fins especiais (RFC1597, RFC1700). Estes espaços de endereçamento atendem às
redes públicas, privativas, multicast e redes lógicas puramente virtuais (rede local - interna
ao equipamento).
Os espaços de endereçamento de redes públicas são para aquelas interligadas à Internet.
Os espaços de endereçamento de redes privadas não devem ser conectadas diretamente à
Internet usando tais endereços (elas já existem lá!). As redes lógicas puramente virtuais
fazem parte de todo e qualquer implementação TCP/IP (qualquer equipamento com TCP/IP
ativo). As redes destinadas à multicast (propagação controlada de serviços dedicados),
associam faixas de endereçamento para alguma atividade envolvendo um grupo específico
de máquinas. Exemplo: videoconferência (áudio/vídeo). Todas as máquinas que farão parte
da aplicação de videoconferência também se identificam com algum endereço do espaço IP
224.2.0.0 até 224.2.255.255 (Multimedia Conference Calls).
Os valores das redes privativas são:
94
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
CLASSE
Blocos de Endereços
A
10.0.0.0
B
172.16.0.0 - 172.31.0.0
C
192.168.0 - 192.168.255.0
Faixa de endereçamento
10.0.0.0 -> 10.255.255.255
172.16.0.0 -> 172.16.255.255
172.17.0.0 -> 172.17.255.255,
...
172.31.0.0 -> 172.31.255.255
192.168.0.0 -> 192.168.0.255,
192.168.1.0 -> 192.168.1.255,
...
192.168.255.0 -> 192.168.255.255
Rede Interna
Classe A
127.0.0.0
Redes Públicas
Todas as outras do espaço de endereçamento das Classes A, B e C
Redes de Multicast Compreende os endereços a classe D.
Redes Reservadas Classe E
OBSERVAÇÔES: Estas atribuições de números podem sofrer alterações sem qualquer
aviso prévio do IANA. É altamente recomendável manter atualizado sobre as RFCs. A última
modificação ocorreu em outubro de 1994 (RFC1597 e RFC1700).
1.4
OUTRAS NOTAÇÔES DE ENDEREÇAMENTO
Com o aparecimento de endereçamento genérico (classless addressing [CIDR1, CIDR2]), a
parte do número de identificação da rede pode ter qualquer tamanho, e toda a noção de
classes de endereços torna-se sem importância.
Há casos especiais para o endereçamento IP que podem ser resumidos usando as recentes
notações de endereçamento IP:
Endereço IP ::= { <Número da Rede>, <Número do Nó> }
ou
Endereço IP ::= { <Número da Rede>, <Número da Subnet>,<Número do Nó> }
Também usarmos a notação "-1" para indicar que o campo contém todos os bits em 1
Seguem alguns casos especiais comuns:
(a)
{0, 0}
Este nó da rede. Pode ser usado como um endereço de origem.
95
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
(b)
{0,<Número do Nó>}
Nós especificado na mesma rede. Pode ser usado como um endereço de origem.
(c)
{ -1, -1}
Propagação Limitada (Limited broadcast). Pode ser usado como um endereço de
destino, e um datagrama como este endereço nunca pode ser redirecionado para
rede externas.
(d)
{<Número da Rede>, -1}
Broadcast Direcionado para uma rede (todas as máquinas conectadas àquela rede)
Pode ser usado como um endereço de destino. D
(e)
{<Número da Rede>, <Número da Sub-Rede>, -1}
Ídem ao anterior, porém direcionado para a Sub-Rede especificada.
(f)
{<Número de Rede>, -1, -1}
Broadcast Direcionado a todas as sub-redes naquela rede. Somente pode ser usado
como um endereço de destino.
(g)
{127, <any>}
Endereço de Nó de Loopback Interno. Nunca deve aparecer fora do nó.
Exemplos:
1) Considerando os padrões de classes, identificar as classes e as redes dos endereços
IPs:
a) 120.1.2.3.4
b) 199.5.255.4
c) 160.255.255.8
d) 224.0.0.1
e) 150.163.128.16
2) Escreva os endereços acima considerando a notação de classless.
2 SUB-REDES E SUPER-REDES
Como vimos a máscara aplicada em um endereço IP de um nó, identifica a rede lógica que
aquele nó pertence. Vimos também a existência de máscaras padrões segundo as classes
de rede. O uso de máscaras independe da classe que aquele bloco (ou blocos) pretence(m)
A capacidade de endereçamento IP da Internet pode alcançar seus limites em breve. Isto foi
previsto em 1994, e foi pedido aos integrantes da Internet para adotar técnicas de
segmentação de redes. Com o crescimento da grande rede as tabelas de rotas também se
ampliaram gerando atrasos sensíveis nos sistemas de roteamento. Para contornar estes
problemas adota-se a técnica de segmentação (sub-redes) e fusão de redes contíguas
permitindo as super-redes.
Segmentar logicamente uma rede é dividi-la em novas redes lógicas aplicando máscaras
não convencionais, habilitando bits de menor ordem. Em outras palavras segmentar redes
96
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
significa habilitar bits (estado 1 à direita da máscara padrão) e fundir redes em desabilitar os
bits (estado 0 - zero - à esquerda da máscara padrão).
Exemplo:
1) Segmentar uma rede classe B em 2 sub-redes. Fornecer a nova máscara.
Partindo da máscara padrão para uma rede Classe B:
255.255.0.0
Dividindo a rede em 2 sub-redes, ou "deslocamento à direita de 1 bit"
(máscara padrão)
11111111 11111111 00000000 00000000
(máscara
após 11111111 11111111 10000000 00000000
segmentação)
=255.255.0.0
= 255.255.128.0
2) Qual o valor da máscara para uma super-rede resultante de 2 redes classe B
(contíguas)?
Partindo da máscara padrão para uma rede Classe B:
255.255.0.0
Unir as 2 redes em 1 super-rede ou "deslocar à esquerda o último bit da máscara"
(máscara padrão)
11111111 11111111 00000000 00000000
(máscara
após 11111111 11111110 00000000 00000000
união)
=255.255.0.0
= 255.254.0.0
Cabe lembrar a condição de endereço de identificação da rede e de broadcast não podem
ser esquecidos quando tratamos de redes que correspondem às classes A, B e C. Isto limita
a segmentação de redes até o bit 2 (inclusive) da máscara. Vamos considerar a máscara
padrão para a classe C.
255.255.255.0
Escrevendo o byte com o valor 0 na forma binária:
7
0
6
0
5
0
4
0
3
0
2
0
1
0
0
0
Para dividir em dois segmentos, este último byte apresenta-se:
7
1
6
0
5
0
4
0
3
0
2
0
1
0
0
0
7
1
6
1
5
0
4
0
3
0
2
0
1
0
0
0
Para 4 segmentos
Para 8 segmentos:
97
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
7
1
6
1
5
1
4
0
3
0
2
0
1
0
0
0
Ou seja, o número de segmentos está associado ao número de bits que estamos
preenchendo com valor 1. Assim, é possível deduzir que o número de segmentos (S) e o
número de bits deslocados (N) estão relacionados, por:
S = 2N
Isto é valido até que seja alcançado o bit 2 do último byte. Partindo da máscara padrão de
uma única rede da classe A , N < 23 (4194304 sub-redes com 2 nós); partindo da máscara
padrão de rede classe B, N<15 (16384 sub-redes com 2 nós), e para rede classe C : N<7
(64 sub-redes com 2 nós).
7
1
2.1
6
1
5
1
4
1
3
1
2
1
1
0
0
0
EXERCÍCIOS
3) Fazer o mesmo do exercício 1 para uma rede classe C
4) Idem ao 2 para uma rede classe C.
5) Identificar a máscara para segmentar uma rede classe C em 4 sub-redes
6) Identificar a máscara para criar uma super-rede de 4 redes contíguas da classe C.
7) Identificar os novos endereços de rede e broadcast para cada segmento de sub-rede e
das super-redes.
2.2
Exercícios para Laboratório:
Considere um conjunto de 4 máquinas que fazem parte de uma rede classe C.
1) Teste a conectividade destas máquinas (use o comando ping)
2) Calcule a máscara necessária para dividir a rede em 2 segmentos. Modifique a máscara
de duas das máquinas de modo que cada uma das selecionadas façam parte de uma subrede. Avise ao professor destas mudanças para que ele tome outras providencias de
configuração. Teste a conectividade lógica entre as máquinas de segmentos diferente e
entre uma máquina da rede padrão e a do segmento.
Descreva e explique os fatos ocorridos?
3 PROTOCOLOS ARP E RARP
Para explicar os protocolos ARP e RARP formulando duas perguntas:
98
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
•
•
Se 2 máquinas compartilham da mesma rede física, como é que uma conhecerá o
endereço ethernet da outra se a primeira só conhece o endereço Internet (IP) da
segunda?
Como uma máquina diskless consegue determinar seu endereço IP?
Para resolver estes problemas foram inseridos no TCP/IP dois protocolos de baixo nível.
Estes protocolos estão no limite inferior da camada IP e são conhecidos como ARP e RARP.
3.1
ARP (Address Resolution Protocol)
Uma forma de estabelecer o mapeamento entre endereço IP e endereço físico é o que
denominamos de mapeamento direto. Uma solução é tomar o hostid do endereço IP como
índice de uma tabela contendo o endereço físico da interface correspondente. Esta tabela
estaria armazenada em memória (permanente ou não) e seria carregada em memória em
tempo de boot.
Mas isto tem alguns inconvenientes, pois não é raro a atualização de placas de rede ou
mesmo o transporte de uma máquina para redes físicas diferentes, exigindo uma solução
mais dinâmica. Para resolver este problema os projetistas buscaram uma solução bem
simples, que lembra a capacidade de broadcast das redes Ethernet, e que evita problemas
de centralização de serviços e manutenção das tabelas de mapeamento. O protocolo
projetado denomina-se ARP (Address Resolution Protocol) e está fundamentado na
seguinte idéia:
Quando um Host A quer conhecer o Endereço físico de um Host B cujo endereço Internet
(IP) é conhecido, ele (Host A) envia um frame especial para a rede questionando qual o
endereço físico Fb do Host de endereço IPb. Todos os hostes receberão o pacote, mas
somente o próprio Host de endereço IPb responderá à solicitação com seu endereço
Ethernet. A partir de então, o host A poderá enviar pacotes diretamente para o host B
usando o endereço físico informado.
Desta idéia elementar, surgiram otimizações:
-
-
3.2
Ao enviar um pacote para o host de destino em frames de broadcast, o transmissor já
envia as informações sobre si mesmo, prevendo a continuidade da comunicação,
evitando a solicitação em sentido contrário.
Todas as respostas são armazenadas em memória. Assim, antes de enviar um novo
frame ARP, o host verifica o IP do destinatário em suas tabelas. O pacote com frame de
broadcast só será enviado caso não encontre qualquer referencia ou associação entre
endereço IP e endereço ethernet.
RARP (Reverse Address Resolution Protocol)
99
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
A resposta da segunda pergunta está no uso de máquinas que prestam serviço de RARP. A
idéia é a mesma do ARP, ou seja, por broadcast. Uma estação diskless (sem disco) envia
para o meio físico um frame tipo broadcast solicitando seu IP. Todas as máquinas que
compartilham daquela rede física recebem o frame. Apenas as que prestam serviço RARP
responderão a solicitação. A resposta estará em função do endereço ethernet informado. Há
serviços alternativos ao RARP, conhecidos como BOOTP e DHCP.
3.3
A FORMA DA MENSAGEM ARP ou RARP
Uma mensagem ARP tem a forma apresentada pela figura abaixo. Os números indicam a
ordem do campo no frame e não a identificação do bit do campo.
Onde
HARDWARE TYPE
Especifica o tipo da interface de onde se busca a informação.
Para interface Ethernet o valor é 1.
PROTOCOL TYPE
é o tipo de endereço do protocolo de maior nível. O valor é
080016 para o protocolo IP.
HLEN
é o tamanho do endereço de hardware (físico)
PLEN
É o tamanho do endereço IP. Com estes dois campos HLEN e
PLEN, é possível coletar informações de qualquer tipo de rede.
OPERATION
Define o tipo de operação:
1 - Requisição ARP,
2 - Resposta ARP,
3 - Solicitação RARP,
4- Resposta RARP.
SENDER HA
É o endereço de hardware do solicitante
SENDER IP
É o endereço IP do solicitante
100
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
TARGET HA
É o endereço de hardware da máquina de destino (RARP)
TARGET IP
É o endereço IP da máquina de destino (RARP).
Quando o frame (quadro) chega ao destino, esta máquina lê a informação dos campos
correspondentes ao emissor e retorna o pacote com suas informações.
3.4
EXERCÍCIOS:
1) Ao ligar o seu equipamento, verifique a tabela de endereços físicos através do comando
" arp -a" (sem as aspas).
2) Selecione uma outra máquina da mesma rede física e repita o comando. Agora, de uma
destas máquinas mande um pacote ICMP (PING) para a outra máquina. Verifique as
tabelas de ARP das duas máquinas.
3) Pesquise as RFCs que comentam sobre o ARP e RARP.
4 PROTOCOLO IP
O protocolo IP é um mecanismo utilizado para o envio de datagramas. Este mecanismo
apresenta as seguintes características:
•
•
•
É não confiável (não há garantias de recebimento). Um pacote pode ser
pedido, se atrasar, ser enviado fora de ordem, sem que exista uma forma de
detectar este tipo de condição nesta camada.
É não orientado à conexão, pois cada datagrama é tratado de forma
independente um do outro;
É dito "best-effort delivery" porque o software se esforça no envio do
datagrama, ou seja, somente descartará o datagrama após tentar todos os
recursos possíveis.
O protocolo IP proporciona 3 definições importantes:
•
•
•
A unidade de transferencia de dados, os datagramas, tem uma forma exata.
Realiza a função de roteamento
Informa, de alguma forma, como os nós (hosts e roteadores) devem tratar o
datagrama, quando as mensagens de erro devem ser geradas, e em quais
condições um datagrama deve ser descartado.
101
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
4.1
O FORMATO DE UM DATAGRAMA IP
Considerando a ordem de envio dos bits, o formato do datagrama IP é:
onde:
VER
versão do protocolo IP. Este campo de 4 bits tem o valor
=4 (IPv4)
HLEN
Tamanho do cabeçalho em palavras de 32 bits. O
menor valor é 5 (sem opções IP ou padding)
SERVICE TYPE
Ou TOS (Type of Service), é um campo de 8 bits
composto por:
0
1
2
3
4
5
PREFER
D
T
R
6
7
SEM USO
PREFER - Especifica a preferencia/prioridade do
datagrama sobre outros. Admite os seguintes valores:
111 - Network Control (Controle de rede local)
110 - Controle de Internetwork
101 - CRITIC/ECP (É um datagrama Crítico)
100 - Flash Override (mais rápido apagando o pacote
anterior)
011 - Flash (mais rápido)
010 - Imediato
001 - Alguma Prioridade
000 - Rotina (Normal)
102
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Esta preferencia deve ser tratada adequadamente. O
controle destas preferencias deve ser feito localmente.
D: 0 = Normal , 1 = Reduzir o atraso.
T: 0 = Throughput Normal, 1 = Alto Throughput.
R: 0 = Confiabilidade Normal , 1 = Alta Confiabilidade.
Bit 6-7: Reservado para uso futuro (não informado).
Selecionar os BITS D,R e T não significa melhorar o
desempenho geral daquela rede. Em alguns casos,
selecionar um deles implica na deterioração de outro
recurso.
TOTAL LENGTH
É o tamanho daquele datagrama, incluindo os dados.
(não se trata do tamanho de um datagrama original,
caso tenha sido fragmentado)
IDENTIFICATION
É uma identificação do datagrama. No caso de uma
fragmentação do datagrama, esta ID é COPIADA para
cada fragmento
FLAGS
É um conjunto de flags de fragmentação:
BIT
0
1
2
VALOR
0
DF
MF
O bit 0 é sempre 0. É reservado.
DF = 0, datagrama pode ser fragmentado,
= 1, o datagrama não pode ser fragmentado
MF =0, sinaliza que este datagrama é o último de uma
fragmentação;
=1, sinaliza que há mais fragmentos em relação
ao datagrama original.
FRAGMENT OFFSET
é medido em unidades de 8 octetos (64 bits). O primeiro
fragmento tem offset=0. Representa a posição do
primeiro octeto de dados no pacote de referencia
(original). Exemplo: Tamanho de dados de um
datagrama é 1500 e seja necessário atravessar uma
rede com MTU de 700. Primeiro fragmento contém 700
(OFFSET = zero), o segundo contém os próximos 700
(OFFSET = 700) e o último contém 100 (OFFSET =
1400)
TIME TO LIVE
Este campo indica o tempo máximo de vida do
datagrama tem para permanecer no sistema. Se contém
um valor zero, então o datagrama deve ser destruído e
103
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
deve ser enviado para a origem do datagrama uma
mensagem de erro . Este campo tem seu valor reduzido
de pelo menos 1 unidade todas as vezes que for
processado, mesmo que o tempo de processamento de
roteamento seja inferior a 1 segundo. O TTL é um limite
superior de tempo de vida de um datagrama. O objetivo
é descartar o datagrama no caso dele não conseguir ser
enviado para o destino.
PROTOCOL
Especifica o tipo do protocolo que contém os dados,
conforme os valores definidos em RFC1700 ou mais
atual (Assigned Numbers)
HEADER CHECKSUM
Considerando este valor inicialmente zero, tratando o
cabeçalho como uma seqüência de 16 bits. Ver RFCs
1071, 1624 e 1141
SOURCE IP ADDRESS
Endereço IP de origem
DESTINATION IP ADDRESS
Endereço IP de destino
IP OPTIONS
O campo IP OPTIONS tem um tamanho variável e
depende das opções selecionadas. Algumas opções
tem um tamanho de 1 octeto enquanto outras tem um
tamanho variável. Quando as OPÇÕES IP estão
presentes no datagrama, elas aparecem de forma
contínua, sem qualquer separador entre elas. Cada
opção consiste de um simples octeto que pode ser
seguido por um ou mais octetos de dados daquela
opção. O octeto de código de opções é dividido em 3
campos:
BIT
0
CAMPO
CP
CP
1
2
CLASSE
3
4
5
6
7
NÚMERO OPÇÃO
É um flag que controla como os roteadores
tratarão as opções durante a fragmentação. se
CP =1 então o a opção deve ser copiada em
todos os fragmentos, Se 0 (zero), então a opção
é copiada somente para o primeiro fragmento.
CLASSE
DE
OPÇÃO
104
N.º da
Opção
N.º de
octetos
Descrição
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
0
0
-
0
1
-
0
2
11
0
3
variável
0
7
variável
0
8
4
0
9
variável
2
4
variável
Fim da lista de opções.
Usado se as "opções"
não terminarem no
final do cabeçalho (Ver
PADDING)
Sem operação (usado
para alinhamento dos
octetos numa lista de
opções).
Restrições de
segurança e
tratamento (para
aplicações militares)
Roteamento livre.
Usado para rotear um
datagrama através de
um caminho
específico.
Neste caso, a rota
fornecida deve ser
seguida, mas pode
acontecer de existir
alguns roteadores
intermediários que não
constam na lista.
Registro de rota.
Usado para traçar rota.
(Obsoleto) Era usado
em redes SATNET
como um identificador.
Roteamento forçado.
Usado para rotear um
datagrama através de
um caminho
especificado. Neste
caso, o roteamento
deve seguir a lista de
rotas com rigor.
Internet Timestamp.
Usado para registrar
os tempos dos
roteamentos
Um exemplo de campo de Opções:
ROTEAMENTO
Registro de rota livre - Cada roteador deve inserir seu IP
na lista, após verificar se existe campo livre para isto,
através dos campos de comprimento e do apontador.
105
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Estas e outras opções podem ser encontradas com
detalhes nas RFCs 760 e 791
PADDING
O campo PADDING é preenchido com ZEROS até
completar os 32 bits quando o campo IP OPTIONS
apresentar um tamanho inferior.
DATA
O campo DATA possui o pacote do protocolo de
transporte usado (UDP, TCP, ICMP, etc)
Os campos IP OTIONS e PADDING não são necessários em todos os datagramas IP.
4.2
FRAGMENTAÇÃO E REMONTAGEM DOS DATAGRAMAS
O tamanho de um datagrama depende da tecnologia empregada no meio físico. Uma rede
Ethernet, por exemplo, limita o tamanho dos dados de um frame em 1500 octetos. Quando
usando com um cabeçalho SNAP o padrão é 1492 octetos. Uma rede FDDI permite 4470
octetos de dados por frame. Estes limites são denominamos de MTU (Maximum Transfer
Unit). Ao atravessar redes físicas diferentes com MTUs diferentes, o datagrama deve ser
divido em partes ou fragmentos. O processo de dividir o datagrama é conhecido por
FRAGMENTAÇÂO.
106
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Uma vez que um datagrama foi fragmentado, os fragmentos continuarão isoladamente até o
destino e será remontado lá (só no destino!)
Na fragmentação, cada parte receberá um cabeçalho próprio, podendo conter campos do
cabeçalho original e acrescido de informações que permitirão a sua remontagem. Estas
informações consistem dos campos IDENTIFICATION, FRAGMENT OFFSET, e FLAGS
bem definidos. Caso o flag de "não fragmentar" estiver definido (DF=1) e for necessário uma
fragmentação, o datagrama é descartado e o remetente receberá uma mensagem de erro
(normalmente via ICMP).
5 ROTEAMENTO IP
Denominamos de ROTEAMENTO o mecanismo de escolha de um caminho usado para
enviar pacotes. Roteador é um equipamento com capacidade de realizar esta função. Uma
máquina pode ser um roteador. Encontramos, também roteadores dedicados.
Como vimos, o datagrama IP contém em seu cabeçalho, dentre outras informações, o
endereço IP de destino. Vimos, também, que um endereço IP pode ser desmembrado em
um endereço de rede e endereço do nó naquela rede através da uma operação lógica
envolvendo uma máscara. Vimos, ainda, que o cabeçalho de um frame encontramos os
endereços físicos de um nó.
O Roteamento IP é, portanto, o mecanismo utilizado para transferir datagramas IP entre
interfaces após uma análise dos cabeçalhos destes datagramas selecionando um melhor
caminho (sob algum aspecto). A implementação de roteamento se localiza na camada de
rede.
Sob este ponto de vista, qualquer máquina conectada à rede física estabelece algum tipo de
roteamento. Vejamos o por quê!
5.1
ENVIO DIRETO
Para definir Envio Direto, Comer (1995, Vol.1, página 111) resume:
Transmission of an IP datagram between two machines on a single physical
network does not involve routers. The sender encapsulates the datagram in
a physical frame, binds the destination IP address to a physical hardware
address, and sends the resulting frame directly to the destination.
Ou seja,
A transmissão de um datagrama IP entre 2 máquinas em uma única rede física não envolve
roteadores. A máquina responsável pelo envio, encapsula o datagrama num frame físico,
acopla o endereço IP de destino ao endereço físico do hardware, e envia o frame resultante
diretamente para o destino.
107
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Apesar de não ser um especialista de expressão como o Dr. Comer, que certamente
explicaria esta afirmação de melhor modo que será apresentada aqui, gostaria de tecer
alguns comentários sobre esta afirmação. Isto não é uma crítica! É apenas um ponto de
vista.
A afirmação do Dr. Comer é válida desde que naquela rede física exista apenas uma rede
lógica IP e que o envio use recursos diretos da camada de interface. Vejamos o porquê. A
grande maioria das máquinas com TCP/IP implementam algum algoritmo de roteamento
baseado na rede de destino. O princípio básico do roteamento, neste caso, consiste na
análise do endereço IP de destino (parcela de rede de destino) em relação ao endereço IP
de origem (parcela de rede da origem). Caso estas partes resultem em valores diferentes, o
datagrama IP deve ser enviado para um roteador. Assim, de uma forma genérica (qualquer
tipo de roteamento) não basta só o compartilhamento da mesma rede física. É preciso uma
condição mais ampla e a afirmação deve ser interpretada na forma:
A transmissão de um datagrama IP entre 2 máquinas em uma única rede (física + lógica IP)
não envolve roteadores. A máquina responsável pelo envio, encapsula o datagrama num
frame físico, acopla o endereço IP de destino ao endereço físico do hardware, e envia o
frame resultante diretamente para o destino.
OBS: Uma aplicação que trabalha com acesso direto para envio em baixo nível (frame)
estabelece um "by-pass" da pilha IP. Desta forma, a possibilidade de envio direto
torna-se possível, mesmo em redes lógicas diferentes. As aplicações "normais" não
são capazes disto pois estariam fazendo um by-pass na camada de rede e
transporte.
O protocolo ARP carrega os endereços físicos que pertencem à mesma rede física. A
questão não está na montagem do frame, mas antes da montagem do datagrama IP para o
envio. Assim, dispensar roteadores em redes lógicas diferentes em uma mesma rede física
requer "truques" de máscara na inicialização de um sistema. Este "truque" era possível em
sistemas mais antigos baseados no BSD4.2. O "truque" consiste na modificação da máscara
de rede, em tempo de inicialização do sistema, para um valor tal que as duas redes lógicas
diferentes possam ser consideradas uma única rede lógica, e depois, retornar a máscara
para os valores "nominais" (padrão). Exemplo: Sejam as redes A e B com da classe C,
192.168.254.0 e 192.168.128.0. Em condições normais as máquinas de uma rede não são
capazes de enviar um datagrama IP diretamente para máquinas de outra rede. Porém,
modificando a máscara padrão para 255.255.0.0 temporariamente, isto torna possível, pois
estas duas redes teriam o mesmo IP de identificação de rede (em caso de dúvida rever item
2)
Uma outra forma, bem mais simples, é explorar a capacidade de roteamento encontrado no
TCP/IP, definindo a segunda rede lógica na Tabela de Roteamento. Neste caso todas as
máquinas usam a capacidade de roteamento (tabelas), embora não possam agir como um
roteador.
Foi realizado alguns testes de envio direto. O teste consiste em estabelecer a conexão entre
máquinas de redes lógicas diferentes que compartilham da mesma rede física em uso e
roteadores externos.
108
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Foram usadas máquinas com hardware semelhantes, compatível com o IBM-PC,
executando Windows NT Server 4, Windows NT Workstation 4 (os dois com ServicePack
6a), e Linux (Kernel 2.2.13, distribuição RedHat). Todas as máquinas executavam somente
o protocolo de rede TCP/IP. Um mesmo teste foi repetido para as várias combinações de
Sistemas Operacionais. As condições de configuração para os testes estão resumidas no
anexo deste capítulo.
CONCLUSÕES DOS TESTES
1. O ARP não é usado para decisões de roteamento
2. O "envio direto" está sujeito ao procedimento que implementa algum roteamento
interno.
O envio direto, literalmente, só existe na conexão lógica entre as máquinas quando o
roteamento interno contém informação adequada da tabela de rotas, quer seja por rota
default ou de rede específica.
No envio de um datagrama IP, o roteamento USA a tabela de ARP para a criação do frame,
embora isto só ocorra depois de um roteamento interno. No recebimento, a interface
reconhece o endereço MAC mas não é capaz de entregar o datagrama IP para a camada de
rede.
O envio direto sem roteadores (qualquer tipo) não é aplicável em condições normais (sem
uso de rotas) ou seja, somente considerando a rede física.
O roteamento IP interno existe e é o responsável pelo funcionamento adequado do TCP/IP
no envio e recebimento de datagramas IP. Sem ele, o envio direto é impossível, exceto em
aplicações especiais que pulam o roteamento IP.
Portanto, se EXISTE roteamento interno então existe roteador interno e é usado tanto no
recebimento quanto no envio de um datagrama IP (Os detalhes de como isto é
implementado será discutido em CAP312), ou seja, qualquer máquina com TCP/IP contém
algoritmos de roteamento e agem como um roteador interno.
PROPOSTAS:
1)
Isto é válido para outras implementações do TCP/IP (outros sistemas operacionais),
tipo SunOS, OpenVMS com pilhas TCP/IP UCX e Multinet, AIX, HP-UX?
2)
Uma aplicação para o "envio realmente direto", pulando o roteamento teria sucesso?
109
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
5.2
ENVIO INDIRETO
O envio indireto resume no fato de exigir a identificação de um roteador para onde o
datagrama deverá ser enviado. O roteador, então, redirecionará aquele datagrama para a
rede de destino. Neste caso, como um roteador saberá para onde enviar o datagrama?
5.3
ROTEAMENTO IP POR TABELAS
Também conhecida como Tabela de Roteamento Internet, este tipo de roteamento consiste
na busca da rede de destino em tabelas de rotas, e está presente em hosts e em
computadores "normais". Estas tabelas consistem de um número de rotas de, no mínimo,
equivalente ao número de redes lógicas conectadas ao roteador. A tabela não armazena
"todas as rotas possíveis" (host por host), apenas a parcela de identificação da rede
do endereço IP dos nós daquele segmento lógico e as máscaras correspondentes, ou
seja (rede por rede).
Surge, daí, uma nova questão: Como as tabelas são criadas ou mantidas?
A tabela de rotas é mantida manualmente (rota estática) ou através de protocolos especiais:
RIP (Routing Information Protocol), BGP (Border Gateway Protocol), GGP (Gateway-ToGateway Protocol), EGP (Exterior Gateway Protocol), OSPF (Open Shortest Path First); ou
mesmo através de protocolo mais simples: ICMP (Internet Control Message Protocol). Cada
um desses protocolos são específicos para certas situações. Não vamos entrar em detalhes
de cada um destes protocolos. Estudaremos técnicas que permitirão analisar as
especificações deles e casos de roteamento, cuja solução pode ser o uso de um ou um
conjunto destes protocolos.
No envio direto fizemos uma observação sobre o uso de tabelas quando temos duas (ou
mais) redes lógicas numa mesma rede física. Conforme a afirmação do Dr. Comer, e os
comentários seguintes, o envio direto torna-se possível sem uso de roteadores externos,
mas com o uso da capacidade de roteamento embutida no TCP/IP em cada máquina,
alimentando a tabela de rotas manualmente e usando o endereço IP da interface existente
como gateway. Neste caso não estamos usando "roteadores externos", mas estamos
usando o sistema de roteamento interno. Eis um relatório deste teste.
5.4
ROTEAMENTO TIPO "NEXT-HOP"
A idéia consiste em enviar o datagrama para o roteadores conectados diretamente naquela
rede.
110
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
O roteador R1 trabalha com as seguintes informações:
Para alcançar nós
na rede
192.168.30.0
192.168.50.0
192.168.127.0
192.168.160.0
Enviar o datagrama para
este endereço
Enviar direto
Enviar direto
192.168.30.91
192.168.50.200
Ou seja, decidir caminhos usando somente a identificação da rede reduz o tamanho das
tabelas e traz algumas conseqüências:
1. Todo o tráfego destinado para uma dada rede usa o mesmo caminho. Num caso
onde existe um segundo caminho, eles não podem ser usados concorrentemente,
mesmo que existam atrasos ou diferenças de velocidade do meio físico entre tais
caminhos.
2. Somente o roteador final é capaz de enviar o datagrama diretamente para o host de
destino e verificar se o host está operacional ou não. Neste caso, este roteador deve
possuir mecanismos para avisar a origem do datagrama sobre eventuais problemas
de conexão (se host de destino não existe ou não está operacional). Como veremos,
este mecanismo pode ser estabelecido pelo protocolo ICMP.
3. Na presença de mais de uma rota, e neste caso elas não podem ser concorrentes,
podemos ter caminhos diferentes para um datagrama enviado por um host A para
um B e um datagrama enviado do host B para o host A. Assim, os roteadores devem
garantir a comunicação nos dois sentidos. Olhando para a figura anterior, podemos
questionar: Como fica a tabela dos roteadores R2 e R3? As máquinas das redes
192.168.160.0 e 192.168.127.0 apontam para onde?
111
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
5.5
ROTA PADRÃO
A idéia é ter um software de roteamento que, primeiro, procure a rede de destino na tabela
de rotas. Caso não a encontre, as rotinas de roteamento enviam o datagrama para uma
porta do roteador padrão.
Este roteador agirá da mesma forma. Ele buscará em suas tabelas de rotas a rede de
destino. Caso não encontre o datagrama IP é enviado para o roteador posterior (ou o seu
roteador padrão). Isto vai acontecer até que ou o datagrama alcance o seu destino ou seja
descartado por algum roteador intermediário. Antes de descartar o datagrama este roteador
enviará à origem do datagrama um "recado" dizendo que aquela rede ou nó não foi
alcançado.
Tal rota pode ser aprendida (propagada) através de protocolos tidos como protocolos de
roteamento (RIP, RIP2, OSPF, BGP, etc).
5.6
ROTAS ESPECIFICAS DE HOSTS
O uso de rotas baseando "por nó" dá um maior controle administrativo sobre o uso da rede,
mas aumenta o tamanho das tabelas. Há alguns casos que este tipo de roteamento torna-se
absolutamente necessário. É quando uma máquina (H1) estabelece o roteamento entre a
rede física contínua e uma segunda máquina.
Neste caso, a tabela de R1 será :
112
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Para alcançar hosts na rede
192.168.30.0
192.168.50.0
192.168.127.0
192.168.160.0
192.168.50.21
5.7
Enviar o datagrama para este endereço
Enviar direto (interf. 192.168.30.140)
Enviar direto (interf. 192.168.50.87)
192.168.30.91
192.168.50.200
192.168.50.10
ROTEAMENTO ENVOLVENDO SUB-REDES E SUPER-REDES
Até então, neste estudo de roteamento IP, consideramos as redes seguindo as respectivas
classes (A, B, C). Contudo, ao considerar o roteamento entre sub-redes e super-redes, as
informações constantes da tabela acima não são suficientes. A informação que falta é,
justamente, a máscara da rede. No caso de um roteamento para um Host especifico,
usamos a máscara de host (255.255.255.255).
A tabela de rotas deve ser escrita, na forma:
Para alcançar
hosts na rede
Net-IPd
192.168.30.0
192.168.50.0
192.168.127.0
192.168.160.0
192.168.50.21
192.168.75.0
192.168.75.128
Máscara de Rede
NETMASK
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.255
255.255.255.128
255.255.255.128
113
Enviar o datagrama
para este endereço
(hop)
Enviar direto
Enviar direto
192.168.30.91
192.168.50.200
192.168.50.10
Enviar direto
Enviar direto
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Para o roteamento é OBSERVADO o endereço IP do destino. Vamos entender este
OBSERVADO. Digamos que uma máquina da rede 192.168.50.22 (M-50-22) queira enviar
um datagrama IP para a máquina 192.168.127.10 (M-127-10). Vamos viajar com este
pacote para entendermos como isto "funciona". A tabela acima é propagada de alguma
forma (protocolo RIP, por exemplo) para todas as redes diretamente conectadas à R-1. A
máquina M-50-22 faz parte da rede 192.168.50, que recebe esta informação e armazena em
sua memória. Agora ela quer enviar um pacote para M-127-10. Ao consultar a tabela, ela
reconhece que o datagrama IP deve seguir para o roteador R-1. Imaginemos o seguinte
diálogo de laboratório:
Qual endereço IP de destino ela vai inserir no datagrama IP?
É o endereço de destino do pacote! De M-127-10 (192.168.127.10).
Como ela enviará para o destino se ela não sabe onde isto fica?
Uma das formas, sem ajuda de outros protocolos, é o envio do pacote para a rede
(lembram do ARP?) com endereço de broadcast num frame (que carregará aquele
datagrama). Ou seja TODAS as máquinas vão ler o frame.
Uma oura forma é questionar "quem tem o endereço ethernet de M-127-10?"
Neste caso a resposta não será atendida pois a máquina M-127-10 está muito além dos
roteador R-1. Mas R-1 tem uma interface na mesma rede física de M-50-22. Ele também
recebe o datagrama IP encapsulado num frame com endereço ethernet de destino contendo
um valor de broadcast. Ele, R-1, não sabe interpretar o Ethernet, mas sim o IP. Então, R-1,
leva o pacote para a camada IP e identifica o destino (M-127-10).
Será que ele, R-1, possui informações sobre a rede 192.168.127.0?
Ele consulta sua tabela e lá está ela. No caso no terceiro registro.
Para onde ele deve enviar?
Pela tabela ele obtém o endereço 192.168.30.91.
E R-1 pergunta: " Eu, R-1, tenho a rota para 192.168.30.91?".
O software de roteamento responde: "Para a máquina não, mas para a rede 192.168.30.0
sim! Pela tabela, basta enviar aquele datagrama diretamente para a interface
correspondente à rede 192.168.30.0". Caso ele saiba o endereço Ethernet da máquina
192.168.30.91 então está resolvido! Basta inserir o datagrama IP, que veio de M-50-22, num
frame contendo o endereço ethernet de destino de 192.168.30.91 e enviar para a rede física
(Envio direto).
E se R-1 não sabe?
Ele pergunta: "Quem tem o endereço de ..." e aí ele fica sabendo (via ARP, lembram?
192.168.30.91 está na mesma rede física que uma de suas interfaces). Este frame viaja
114
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
para 192.168.30.91 e lá, em R-2, repete-se o procedimento (perguntas). Só que, agora, R-2
tem uma interface conectada diretamente à rede 192.168.127 e a máquina de destino, cujo
endereço consta no datagrama IP, faz parte de uma das redes físicas onde R-2 está
conectado. Então, numa rede, o ARP de broadcast estará presente enquanto as máquinas
que estabelecem uma comunicação não conhecerem TODOS os endereços (IP e MAC) da
outra.
O que? Isto gera tráfego demais, não?
Sim! Gera! Mas reparem que é só para o primeiro datagrama IP. Até ele chegar ao destino
pela "primeira vez". Quando houver uma resposta daquele datagrama ou seguir uma nova
solicitação nenhuma pergunta será feita, pois são conhecidos os endereços (MAC e IP) dos
roteadores e máquinas vizinhas usadas no envio e recebimento dos datagramas.
Tudo isto pode ser observado quando usamos aplicações tipo TCPDUMP. Então? Gostaram
da viagem? Mais uma perguntinha para não ficar, assim, no "vazio"!!!!
E como é o procedimento de busca das rotas no roteamento?
5.8
ALGORITMO DE ROTEAMENTO
Considerando tudo o que já foi visto até então, o algoritmo de roteamento IP é:
ROTEAMENTOIP(DATAGRAMA, TABELA_DE_ROTAS)
1. EXTRAIR O ENDEREÇO IP DO DESTINATÁRIO, IPD, DO DATAGRAMA.
2. CALCULAR O NETID CORRESPONDENTE, NET-IPD USANDO MÁSCARA PADRÃO.
3. SE NET-IPD É IDENTICO AO ENDEREÇO DE ALGUMA REDE CONECTADA
DIRETAMENTE AO ROTEADOR ENTÃO ENVIAR O DATAGRAMA PARA AQUELA
REDE (ISTO REPRESENTA TRADUZIR O ENDEREÇO IP PARA O ENDEREÇO FÍSICO,
ENCAPSULAR O DATAGRAMA NO FRAME E ENVIAR O FRAME)
4. SE A TABELA CONTÉM UMA ROTA ESPECIFICA PARA IPD ENTÃO ENVIAR O
DATAGRAMA PARA O ENDEREÇO IP ESPECIFICADO NA TABELA
5. PARA CADA ENTRADA NA TABELA DE ROTAS FAÇA:
I. CALCULAR, IPDM,FUNÇÃO LÓGICA AND ENTRE O IPD E A NETMASK
II. SE IPDM É IGUAL AO CAMPO NET-IPD DA TABELA ENTÃO ENVIAR O
DATAGRAMA PARA O IP ESPEFICIADO (OU DIRETAMENTE PARA A REDE)
6. SE NÃO FOR ENCONTRADO NENHUMA ROTA ENVIAR PARA A ROTEADOR PADRÃO
(ROTA DEFAULT)
7. NÃO EXISTINDO ROTA DEFAULT DECLARAR ERRO DE ROTEAMENTO.
Leituras recomendadas: RFC1009, RFC1102, RFC1104, RFC1124 e RFC1716.
115
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
5.9
EXERCÍCIOS
1) Veja as rotas na tabela de seu computador usando o comando "route" (Unix). No
Windows, comande "route print" para ver a tabela de rotas.
2) Faça um teste de roteamento envolvendo duas redes lógicas diferentes compartilhando
uma mesma rede física.
6 PROTOCOLO ICMP
Será que tudo está funcionando bem? Nenhum sistema funciona bem todo o tempo.
Acontecem falhas de processamento, falhas nas linhas de comunicação, tráfego excessivo.
etc.
6.1
FINALIDADE
O ICMP (Internet Control Message Protocol) é um mecanismo de reportagem de erro que
acontece entre uma máquina (nó ou roteador) e o nó de origem que tomará alguma ação
corretiva.
O ICMP não é considerado um protocolo de transporte, embora use o IP para alcançar um
destino (o ICMP está encapsulado no IP), atravessando várias redes físicas. Conforme
veremos, ele não apresenta um protocolo de portas, mas se tratarmos os campos TIPO +
CÓDIGO como uma "espécie de protocolo de porta" (porta de destino) poderíamos
considerá-lo como um protocolo de transporte realizando sua finalidade de suporte ao
protocolo IP. O ICMP é necessário para que o IP funcione corretamente.
6.2
FORMATO DA MENSAGEM ICMP
O cabeçalho ICMP tem um formato específico para cada tipo de mensagem. Contudo, todo
cabeçalho tem os 3 primeiros campos com o mesmo tamanho em bits. Os valores dos dois
primeiros campos definem o objetivo da mensagem ICMP.
116
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
CAMPO TIPO:
Este campo define o objetivo da mensagem e o formato dos campos: "campo 1", "campo 2"
e "campo 3".
As RFCs 1122 (atualização) e 792 descrevem, em detalhes, os campos para cada um dos
tipos citados. Os diagramas e as descrições serão revistas em detalhes no curso de
programação (CAP312).
Caramba! Este protocolo é do tipo "macabro"! Só leva/traz noticias ruins! (:(((
Não! Nem tudo é terror (quando bem usado, evidentemente!). Através do ICMP é possível
atualizar rotas e reconhecer o caminho feito por um datagrama IP até o destino final. Veja a
tabela:
VALOR DO
CAMPO
TIPO
0
3
OBJETIVO DA
MENSAGEM
Replicar Eco
Destino Não Alcançável
VALOR DO CAMPO
CÓDIGO
0
0
1
2
3
4
5
6
7
8
9
10
11
12
4
Source Quench
0 (Ver RFC 896 e 1016)
0
5
8
11
Redirecionamento
(mudança de rota)
Requisitar Eco
Tempo do Datagrama
Excedeu
Rede Não Alcançável
Nó Não Alcançável
Protocolo Não Alcançável
Porta Não Alcançável
É necessário Fragmentação e DF=1
Falha na Rota de origem
Rede de Destino Desconhecida
Nó de Destino Desconhecido
Rota de Origem Isolada
Comunicação com a rede de destino está
proibida administrativamente
Comunicação com o nó de destino está
proibida administrativamente
Rede Não Alcançável para o TOS
informado
Nó Não Alcançável para o TOS informado
1
2
3
0
0
1
117
Redirecionar Datagrama por Rede
(obsoleto)
Redirecionar Datagrama por Nó
Redirecionar Datagrama por TOS e Rede
Redirecionar Datagrama por TOS e Nó
Contador TTL excedido
Tempo de remontagem de fragmento
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
0
12
13
14
15
16
17
18
Problema de Parâmetros
no Datagrama
Requisita Timestamp
Resposta de Timestamp
Requisita Informação
(obsoleto)
Resposta de Informação
(obsoleto)
Requisitar Endereço de
Máscara usada
Resposta da requisição do
endereço de máscara
1
0
0
excedido
O Apontador mostra o problema do
cabeçalho IP
Problema desconhecido com o Cabeçalho
IP
(RFCs: 956, 967 e 1305)
0 ( RFC 950)
0
7 PROTOCOLO DE PORTAS
Quando pressionamos o botão do mouse sobre um ícone numa janela, ou mesmo
acionamos um programa digitando seu nome, é como se estivéssemos estabelecendo um
canal de comunicação entre o computador e o operador. No caso de um ícone, por exemplo,
não é óbvio a identificação do programa (nome do aplicativo) que será executado, mas a
finalidade sim. (O objetivo é este!)
Temos a impressão de que o ícone da aplicação está ali esperando para ser acionado,
como uma porta para aquela aplicação.
Em termos de protocolo de transporte TCP/IP, estamos associando "atividades" às portas de
serviços, ou seja, estamos usando portas para identificar "um conjunto de atividades" num
mesmo protocolo de transporte. Denominamos esta abstração de protocolo de portas.
Da mesma forma que em um sistema "janelado" quando abrimos uma aplicação tipo "linha
de comando" ela fica aguardando a entrada das instruções pelo teclado, as aplicações
TCP/IP, com recursos disponíveis pelo Sistema Operacional, implementam o aceso às
portas de forma síncrona. Ou seja , o S.O. bloqueia a execução daquela aplicação até que
os pacotes cheguem. Normalmente as portas representam filas ou regiões temporárias de
memória (buffers), porém os dados serão perdidos caso cheguem antes que um processo
esteja pronto para recebe-los. Para reter tais pacotes, o software envia aqueles dados para
uma porta específica (associada àquela uma aplicação) até que eles sejam extraídos. De
uma forma mais técnica o protocolo de portas corresponde à filas de execução e cada fila
representa uma atividade, ou uma aplicação, que processará os dados daquela fila. Assim,
podemos ter 2 aplicações diferentes usando uma mesma porta, mas usando protocolos de
transporte diferentes.
118
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Para que seja possível uma resposta, é preciso conhecer a porta de onde partiu aquele
dado, assim como o endereço IP. Assim, para que uma comunicação se estabeleça e a
transferencia de dados ocorra, cada mensagem deve carregar as portas de destino e de
origem. Os endereços de destino e de origem já estão embutidos no datagrama IP enquanto
as portas nos cabeçalhos do protocolo de transporte.
Sob um ponto de vista técnico, os protocolos de transporte UDP e TCP implementam o
conceito de multiplexação e demultiplexação das aplicações baseado nas portas.
Quando o protocolo de transporte (TCP ou UDP) recebe um datagrama, ele verifica se
aquele número de porta está em uso (se existe alguma aplicação correspondente associada
àquela porta). Caso exista ele envia o datagrama para aquela fila. Caso contrário, ele envia
uma mensagem ICMP tipo "porta não alcançável" (port unreachable, ICMP campo=3,
código=3) para o remetente e descarta o datagrama. No caso da fila estar cheia o pacote é,
simplesmente, descartado.
8 PROTOCOLO UDP
O protocolo UDP (User Datagram Protocol) usa o IP para transportar mensagens
implementando, apenas, o recurso de portas. Ou seja, uma aplicação que usa UDP aceita
toda a responsabilidade para manipular e controlar problemas de confiabilidade de envio,
ordenação de pacotes, controle de duplicação, ou perda de conectividade. Normalmente, ao
desenvolvermos alguma aplicação que usa o UDP testamo-la em um ambiente de rede
local. Uma aplicação UDP aplicável para a grande rede (a Internet), deve implementar os
mecanismos de controle e manipulação, caso contrário ela está sujeita à falhas.
8.1
FORMA DAS MENSAGENS UDP
As mensagens UDP são denominadas datagramas de usuário (user datagram). Um
datagrama UDP consiste de 2 partes: cabeçalho UDP e dados UDP. O cabeçalho UDP
contém 4 campos onde são informadas as portas de origem e destino, o tamanho da
mensagem e o checksum UDP, conforme a figura abaixo:
119
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
A porta UDP de origem é opcional. Esta porta é usada para a aplicação de destino retorne
alguma informação para a aplicação da máquina de origem e deve ser zero quando não for
usada. (Pensando nisso é que o protocolo ICMP poderia ser considerado um protocolo de
transporte)
O tamanho da mensagem UDP é medido em número de octetos (número de bytes). A
contagem envolve o cabeçalho UDP e a área de DADOS. Assim, o valor mínimo é 8.
O Checksum é calculado usando um pseudo-cabeçalho. Este é constituído pelos
endereços IP da origem e de destino, o código do tipo de protocolo IP (UDP tem o código
17), e o tamanho do datagrama UDP (não incluir o pseudo-cabeçalho), conforme a figura
abaixo:
Reparem que este pseudo-cabeçalho não está incluso no datagrama UDP. Os endereços
IPs de origem e destino são obtidos do cabeçalho IP. Isto mostra uma forte interação entre o
protocolo UDP e o IP.
Exemplos de serviços UDP:
- TFTP (porta 69),
- NTP (porta 123),
- DOMAIN(DNS) (porta 53, protocolo UDP),
- SYSLOG (porta 514)
Cada um destes serviços tem uma porta padronizada. Outras portas podem ser usadas
desde que não exista um outro serviço (aplicação) usando a mesma porta. As associação
das portas são definidas em arquivo denominado SERVICES na implementação do TCP/IP
de cada sistema operacional. As padronizações são conhecidas como well-known port
assignments e regidas por RFC (até o momento a RFC1700 é quem define estas
associações).
120
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
8.2
QUANDO UTILIZAMOS O UDP?
Usamos o protocolo UDP nas seguintes condições:
8.3
•
A aplicação de serviço transferindo informações "dispensáveis" para uma
aplicação local. Para justificar, tomemos o próprio serviço de tradução de nomes,
o DNS. Há outras formas de implementar ou realizar a tradução de nomes sem o
uso deste serviço.
•
Quando há restrições quanto ao tamanho do código gerado. Na partida de
sistemas (rede local), precisamos de um código pequeno (armazenamento em
memória permanente, vide o TFTP).
•
Aplicação estará restrita à rede local. Caso contrário, o programador deve prever
condições de controle dos datagramas UDP (tempos, ordenação, etc) para evitar
falhas.
Exercícios:
1) Usando um tcpdump para monitorar o trafego de uma rede, verifique o envio de
mensagens UDP de diversos tamanhos (64,128,256,512,1024, 2048, 4096 bytes).
2) Uma conexão UDP é confiável? Explique. Descreva um procedimento de teste que
confirme sua resposta usando o serviço que utilize o UDP.
9 PROTOCOLO TCP
Os protocolos IP e UDP não apresentam recursos para certificar o envio e recebimento de
um datagrama ou mensagem. Para proporcionar esta garantia foi projetado o protocolo TCP
(Transmission Control Protocol). Assim como o UDP, o TCP usa informações do
datagrama IP para seu próprio controle. Melhor ainda, o TCP incorpora recursos de controle
de fluxo, controle envio e recebimento das mensagens, uma forma de prioridade de
mensagens urgentes, enfim, um conjunto de características:
Orientado à Cadeia
(Stream Orientation)
O máquina de destino recebe exatamente a mesma seqüência de
bytes que o remetente enviou.
Conexão em
Circuito Virtual
Antes de enviar a mensagem TCP, as aplicações se certificam se
estão prontas para transferir a mensagem. Uma vez estabelecida a
conexão e autorizada, as aplicações iniciam a transferencia.
Durante a transferencia, as mensagens trocadas são verificadas
quanto ao recebimento. Caso ocorra alguma falha, as duas
máquinas envolvidas detectam a falha e informam às respectivas
aplicações sobre o ocorrido. Dizemos que o TCP implementa um
121
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
circuito virtual pois, sob o ponto de vista da aplicação, tudo se
"parece" como se existisse um circuito de hardware dedicado.
Transferência
Buferizada
O tamanho da mensagem pode ser qualquer. Mesmo que seja um
simples byte. O receptor verá os dados na mesma ordem que a
aplicação (do emissor) enviou. O protocolo de software é livre para
dividir a mensagem em blocos de menor tamanho. Para maximizar
(sob algum aspecto), o tráfego da rede, os dados são mantidos em
buffers até que estes alcancem um nível de preenchimento
suficiente para o envio. Por outro lado, há aplicações que exigem o
envio da informação de forma urgente. Para isto o serviço de envio
disponibiliza um mecanismo push forçando o envio, sem atrasos. O
mecanismo push garante apenas o envio, e não estipula limites de
preenchimento.
Cadeia
não-estruturada
O serviço de envio não honra uma estrutura dos dados. Contudo,
esta estrutura será restaurada na aplicação do receptor. Os dados
são transferidos!
Conexão
Full-Duplex e
Half-Duplex
As conexões proporcionadas pelo TCP permitem transferência nas
duas direções, denominadas Full duplex. Exemplo: FTP (comandos
numa direção e fluxo de dados no sentido oposto). O serviço de
envio também permite que uma aplicação suspenda o fluxo numa
direção enquanto se processa a transferência num sentido oposto
(ou half duplex).
9.1
PROPORCIONANDO A CONFIABILIDADE NO ENVIO E RECEBIMENTO
Embora o protocolo IP não forneça recursos que garantam o envio/recebimento dos
datagramas, o TCP implementa sua confiabilidade baseando-se na técnica de
reconhecimento positivo com retransmissão (positive acknowledgment with retransmission).
A técnica consiste na resposta contendo uma mensagem de ACK para cada mensagem de
dados.
122
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Caso ocorra a perda do pacote (exemplo: ver pacote 2), o que representará o não
recebimento do ACK do pacote, o mecanismo de envio aguarda por um intervalo de tempo
e, findo este prazo, o pacote é retransmitido.
Para otimizar o desempenho do mecanismo de envio, o TCP implementa o conceito de
janelas deslizantes (sliding window). A idéia é deslizar uma janela de tamanho fixo sobre
uma seqüência de pacotes que devem ser enviados. O desempenho depende do tamanho
da janela, ou seja, quantos pacotes serão enviados sem o recebimento dos respectivos
ACKs. O tamanho ideal é aquele que cobrirá o tempo de espera pelo retorno da resposta do
ACK do primeiro pacote, conforme a figura:
123
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
A figura acima mostra uma janela deslizante de 5 pacotes. O pacote 6 será transmitido após
o recebimento do ACK do pacote 1. No caso de falha de algum pacote (ACK não recebido),
somente aquele pacote será retransmitido. O mecanismo de janela deslizante mantém a
rede completamente saturada com pacotes. Obtém-se, com isto, um troughtput mais alto
quando comparamos com o envio isolado de um pacote e a espera da respectiva resposta
de ACK.
Uma janela de tamanho fixo pode não ser adequada assim como gerar problemas como
buffer-overflow. Para evitar isto, o tamanho das janelas pode variar acomodando o envio e
recebimento dos pacotes. Para que o software reconheça este problema, o pacote de ACK
disponibiliza um "anúncio de janela" ajustando o tamanho dos buffers para acomodar o
tamanho das janelas. Procedimento semelhante é aplicável para o controle de fluxo de
dados evitando congestionamentos.
9.2
A IDENTIFICAÇÃO DAS CONEXÕES
As conexões TCP são identificadas através da dupla (Endereço IP, número da porta) tanto
do emissor quanto do receptor. Desta forma podemos ter várias conexões para um mesmo
serviço. Este tipo de controle também é aplicável ao protocolo UDP.
9.3
A FORMA DOS SEGMENTOS TCP
As mensagens TCP são denominadas segmentos. Um segmento TCP consiste de 2 partes:
um cabeçalho e dados. O cabeçalho TCP contém 12 campos onde são informadas as
portas de origem e destino, número de seqüência dos dados, número de ACK, tamanho da
janela, checksum, bits de código, tamanho do cabeçalho, apontadores de urgência, e outras
opções. Estas informações são localizadas no cabeçalho TCP, conforme a figura abaixo:
A porta de origem e porta de destino são fundamentais, pois serão usadas para o envio
de mensagens de controle. No início da comunicação (pelo solicitante) a porta de origem é
selecionada pelo sistema segundo algum algoritmo e a porta de destino corresponde à porta
124
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
da aplicação no sistema remoto. Na resposta, ou na transferencia inversa, as portas são
comutadas.
O número de seqüência identifica a posição do byte da cadeia naquele segmento.
O número de ACK identifica o número do octeto que a origem espera receber no próxima
resposta ack.
HLEN é o tamanho do cabeçalho do segmento TCP, medido em múltiplos de 32-bits (longword). Isto é necessário pois as campo OPÇÕES tem um tamanho variável.
RESERV. é um campo reservado para uso futuro e ocupa 6 bits. O valor é zero.
CÓDIGO define a finalidade do segmento. Apresenta a seguinte estrutura:
10
11
12
13
14
15
URG
ACK
PSH
RST
SYN
FIN
Segmento tipo urgente.
O emissor
O apontador de urgência
Este
Sincroniza alcançou o
é válido. Com este bit
ReSegmento segmento
o número
final da
em 1 e um valor definido
inicializa a
tipo ACK
requer um
de
cadeia
no apontador de
conexão
PUSH
seqüência (mensagem
urgência define-se o
)
OOB (Out-Of-Band)(*)
(*) Os detalhes de como o TCP informa um programa de aplicação sobre dados urgentes
depende do sistema operacional do computador. Há algum tempo este tipo de opção
gerava transtornos em vários sistemas operacionais.
O Checksum é calculado usando um pseudo-cabeçalho. Este é constituído pelos
endereços IP da origem e de destino, o código do tipo de protocolo IP (TCP tem o código 6),
e o tamanho do segmento TCP (não incluir o pseudo-cabeçalho, mas incluir os dados),
conforme a figura abaixo:
Reparem que este pseudo-cabeçalho não está incluso no datagrama TCP. Os endereços
IPs de origem e destino são obtidos do cabeçalho IP.
OBS.: A seqüência de segmentos envolvidos numa conexão TCP pode ser estudada
através de um modelo denominado máquina de estado finito. Este modelo será
estudado em CAP312.
125
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
9.4
INICIO E TÉRMINO DAS CONEXÕES - "THREE WAY HANDSHAKE"
O protocolo TCP é classificado como "orientado à conexão". Isto quer dizer que ele
implementa mecanismos que variam com o estado da conexão. Tal mecanismo segue uma
máquina de estado finita (Finite State Machine). Ou seja, o estado da conexão varia
conforme um "handshake" envolvendo os tipos do segmento TCP (campo CÓDIGO do
cabeçalho TCP).
Vamos admitir que a máquina A quer estabelecer uma conexão com a máquina B para a
troca de dados usando o protocolo TCP. Muito antes de ocorrer a transferencia dos dados
entre as aplicações TCP, elas trocam segmentos específicos. Tais segmentos são
identificados como segmentos de sincronismo (SYN) e segmento de confirmação de
recebimento (ACK). A finalidade do segmento tipo SYN é informar à outra máquina o
"desejo" da conexão. A finalidade do segmento ACK é dizer que foi recebido algum
segmento TCP devidamente identificado.
Assim a Máquina A envia para B um
segmento tipo SYNA, informando que
A quer estabelecer a conexão. No
momento do envio é disparado um
cronometro cujo alarme deve forçar
uma nova transmissão caso a
máquina A não receba uma
confirmação de recebimento. As
retransmissões vão acontecer por um
número de vezes previamente
definido em variáveis do TCP/IP.
Caso a máquina B receber o
segmento SYNA ela responderá para
A com o segmento de confirmação
ACKB.
Se houver recursos para aceitar aquele "convite" de conexão então a máquina B também
enviará um segmento SYNB para a máquina A que, seguindo as mesmas condições,
responderá com um segmento ACKA. Normalmente, os sinais de ACKB e SYNB seguem
num mesmo segmento. Esta troca de sincronismos e confirmações de recebimento,
denominamos de Three-way-handshake.
Somente após este tratamento é que os segmentos de dados serão transferidos, mas
sempre que for enviado algum segmento de dado para a outra máquina, esta responderá
com um segmento ACK correspondente ao segmento recebido.
Isto sucederá até que uma das máquinas sinalize a intenção de término (por intervenção do
usuário ou no término da aplicação). O término da conexão só acontecerá após o
encerramento da aplicação (em condições normais, é claro!).
Para encerrar a conexão são trocados segmentos tipo FIN (substituindo o segmento tipo
SYN) repetindo a mesma sequencia inicial.
126
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
A máquina de estado finita não se resume nestas transições. Ela é muito mais completa e
complexa e será vista em detalhes em CAP-312.
9.5
EXEMPLOS DE SERVIÇOS TCP:
- HTTP (porta 80, protocolo TCP),
- FTP (porta 21, protocolo TCP),
- FTP-DATA (porta 20, protocolo TCP),
- DOMAIN(DNS-XFER) (porta 53, protocolo TCP)
Cada um destes serviços tem uma porta padronizada. Outras portas podem ser usadas
desde que não exista um outro serviço (aplicação) usando a mesma porta naquela máquina.
As associação das portas são definidas em arquivo denominado SERVICES na
implementação do TCP/IP de cada sistema operacional. As padronizações são conhecidas
como well-known port assignments e regidas por RFC
9.6
QUANDO UTILIZAMOS O TCP?
Usamos o protocolo TCP nas seguintes condições:
9.7
•
A informação a ser transferida é fundamental. Queremos certificar do
recebimento e do envio da mensagem.
•
A máquina de destino ultrapassa a rede local.
•
Os atrasos gerados pelo controle e procedimentos do TCP (controle e
notificação), não prejudicam a atividade da aplicação. Aplicações de tempo-real,
por exemplo, devem evitar o uso deste protocolo de transporte.
•
Não há restrições de tamanho de código nem de uso da CPU e memória. Para
garantir alguns recursos o TCP requer uma reservas contínuas de memória.
EXERCÍCIOS:
1) Usando um tcpdump para monitorar o trafego de uma rede, verifique o envio de
segmentos TCP de diversos tamanhos (64,128,256,512,1024, 2048, 4096 bytes).
2) Compare o protocolo TCP com o UDP? Implementar todos os recursos de controle do
TCP no UDP é suficiente para garantir o envio/recebimento de forma confiável através
do UDP?
127
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
ANEXO:
Resultado de testes de roteamento
A pequena rede em topologia em barramento (10Mbps). O teste consiste em enviar 4
pacotes ICMP ECHO_REQUEST (ping) com 32 bytes cada um, da máquina 1 para a
máquina 2, e vice-versa.
Máquina 1: Endereço MAC: 00:40:95:E0:37:D6
Máquina 2: Endereço MAC: 00:C0:DF:42:11:19
TESTE 1:
Máquina 1:
Endereço IP: 192.168.254.1
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.254.0 especificada, gw=192.168.254.1
Tabela ARP inicial: sem entrada
Tabela ARP final: contém endereços MAC e IP da máquina 2
Máquina 2:
Endereço IP: 192.168.254.10
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.254.0 especificada, gw=192.168.254.10
Tabela ARP inicial: sem entrada
Tabela ARP final: contém endereços MAC e IP da máquina 1
Resultado:
Conectividade confirmada. Comprova que a conectividade entre as máquinas tanto
lógica quanto física. Tabela de ARP contém o MAC da máquina remota.
TESTE 2:
Máquina 1:
Endereço IP: 192.168.254.1
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.254.0 especificada, gw=192.168.254.1
Tabela ARP inicial: vazia
Tabela ARP final: permaneceu vazia
128
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Máquina 2:
Endereço IP: 192.168.253.10
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.253.0 especificada, gw=192.168.253.10
Tabela ARP inicial: vazia
Tabela ARP final: permaneceu vazia
Resultado:
Sem conectividade. Resposta ao ECHO_REPLY: Destination host unreachable. Isto
significa que nem o datagrama IP nem o frame ethernet foram enviados ou
recebidos. Este último pelo fato da tabela ARP permanecer vazia
TESTE 3:
Máquina 1:
Endereço IP: 192.168.254.1
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.254.0 especificada, gw=192.168.254.1
Tabela ARP inicial: endereço MAC e IP da máquina 2 (entrada manual)
Tabela ARP final: endereço MAC e IP da máquina 2
Máquina 2:
Endereço IP: 192.168.253.10
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.253.0 especificada, gw=192.168.253.10
Tabela ARP inicial: endereço MAC e IP da máquina 1 (entrada manual)
Tabela ARP final: endereço MAC e IP da máquina 1
Resultado:
Sem conectividade. Resposta ao ECHO_REPLY: Destination host unreachable. Isto
significa que o datagrama IP embutido no frame ethernet não foi enviado e o
endereço ARP não foi utilizado.
TESTE 4:
Máquina 1:
Endereço IP: 192.168.254.1
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
129
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Rota para a rede 192.168.254.0 especificada, gw=192.168.254.1
Rota para a rede 192.168.253.0 especificada, gw=192.168.254.1 (entrada
manual)
Tabela ARP inicial: vazia
Tabela ARP final: contém endereço MAC da máquina 2
Máquina 2:
Endereço IP: 192.168.253.10
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.253.0 especificada, gw=192.168.253.10
Tabela ARP inicial: vazia
Tabela ARP final: contém endereço MAC da máquina 1
Resultado:
Sem conectividade, com resposta de "Request timed out". Significa que o datagrama
IP (consequentemente o frame ethernet) foi enviado, mas para não houve resposta.
O fato da máquina 2 conter o MAC da máquina 1, significa que 2 recebeu o frame
ethernet, mas não conseguiu enviá-lo para a camada IP. Houve o retorno de frame
(máquina 1 contém o endereço MAC da máquina 2), mas, provavelmente, sem
encapsulamento IP.
TESTE 5:
Máquina 1:
Endereço IP: 192.168.254.1
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.254.0 especificada, gw=192.168.254.1
Rota para a rede 192.168.253.0 especificada, gw=192.168.254.1
Tabela ARP inicial: vazia
Tabela ARP final: contém endereço MAC da máquina 2
Máquina 2:
Endereço IP: 192.168.253.10
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão não especificada.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.253.0 especificada, gw=192.168.253.10
Rota para a rede 192.168.254.0 especificada, gw=192.168.253.10
Tabela ARP inicial: vazia
Tabela ARP final: contém endereço MAC da máquina 1
Resultado: Conectividade confirmada. Isto indica que o uso da capacidade de
roteamento embutido no TCP/IP.
130
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
TESTE 6:
Máquina 1:
Endereço IP: 192.168.254.1
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão : 0.0.0.0 especificada, gw=192.168.254.1.
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.254.0 especificada, gw=192.168.254.1
Tabela ARP inicial: vazia
Tabela ARP final: contém endereço MAC da máquina 2
Máquina 2:
Endereço IP: 192.168.253.10
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão: 0.0.0.0 especificada, gw=192.168.253.10
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.253.0 especificada, gw=192.168.253.10
Tabela ARP inicial: vazia
Tabela ARP final: contém endereço MAC da máquina 1
Resultado:
Conectividade confirmada. Isto indica que o uso da capacidade de roteamento
embutido no TCP/IP usando a rota padrão.
TESTE 7:
Máquina 1:
Endereço IP: 192.168.254.1
máscara: 255.255.0.0
Tabela de rotas:
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.0.0 especificada, gw=192.168.254.1
Tabela ARP inicial: vazia
Tabela ARP final: contém endereço MAC da máquina 2
Máquina 2:
Endereço IP: 192.168.253.10
máscara: 255.255.0.0
Tabela de rotas:
Rota padrão: não especificada
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Rota para a rede 192.168.0.0 especificada, gw=192.168.253.10
Tabela ARP inicial: vazia
Tabela ARP final: contém endereço MAC da máquina 2
131
04/05/01
Ulisses Thadeu V Guedes
CAP 258 - REDES E COMUNICAÇÃO DE DADOS
Redes - PROTOCOLO TCP/IP
Resultado:
Conectividade confirmada. Isto indica que a máscara aplicada retrata que as duas
máquinas estão na mesma rede lógica e que há rota para ela. Este teste é
equivalente ao TESTE 1.
TESTE 8:
Máquina 1:
Endereço IP: 192.168.254.1
máscara: 255.255.255.0
Tabela de rotas:
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Tabela ARP inicial: endereço MAC e IP da máquina 2 (entrada manual)
Tabela ARP final: endeereço MAC e IP da máquina 2
Máquina 2:
Endereço IP: 192.168.254.10
máscara: 255.255.255.0
Tabela de rotas:
Rota padrão: não especificada
Rota para a rede 127.0.0.0 especificada, gw=127.0.0.1
Tabela ARP inicial: endereço MAC e IP da máquina 1 (entrada manual)
Tabela ARP final: endereço MAC e IP da máquina 1
Resultado: Sem Conectividade e estamos numa mesma rede lógica e rede física.
CONCLUSÕES DOS TESTES
1. O ARP não é usado para decisões de roteamento IP (teste 3)
2. Dos testes 4, 5, 6 e 7 conclui-se que o "envio direto" está sujeito ao procedimento
que implementa algum roteamento interno.
132
04/05/01
Ulisses Thadeu V Guedes