Apostila (Versão 2.10)

Transcrição

Apostila de Fundamentos de
Redes de Computadores
Versão 2.10
Apostila de Fundamentos de Redes de Computadores
Prof: Ricardo Quintão
Índice Analítico
Índice Analítico ....................................................................................................2
Índice de Figuras dos Capítulos ........................................................................ 10
Índice de Figuras dos Apêndices ....................................................................... 14
Índice de Equações ............................................................................................ 15
Índice de Tabelas dos Capítulos ........................................................................ 16
Capítulo 1 Comunicação de Dados ................................................................. 17
1.1
Conceitos básicos de Transmissão de dados ............................................................................. 17
1.1.1 Sinais .................................................................................................................................... 17
1.1.1.1 Sinais Analógicos e Digitais ......................................................................................... 17
1.1.1.1.1
1.1.1.1.2
Sinais Analógicos .............................................................................................................. 17
Sinais Digitais ................................................................................................................... 17
1.1.2 Formas de Onda ................................................................................................................... 18
1.1.2.1 Amplitude ..................................................................................................................... 18
1.1.2.2 Frequência .................................................................................................................... 18
1.1.2.3 Fase .............................................................................................................................. 19
1.1.3 Taxa de Transmissão Máxima de um Canal ......................................................................... 21
1.1.3.1 Teorema de Nyquist...................................................................................................... 21
1.1.4 Fontes de Distorção de Sinais em Transmissão .................................................................... 22
1.1.4.1 Ruídos .......................................................................................................................... 22
1.1.4.1.1
1.1.4.1.2
1.1.4.1.3
1.1.4.1.4
1.1.4.1.5
Ruído Térmico .................................................................................................................. 22
Ruído de Intermodulação ................................................................................................... 22
Ruído de Crosstalk (Linha Cruzada) .................................................................................. 22
Ruído Impulsivo ................................................................................................................ 23
Lei de Shannon .................................................................................................................. 23
1.1.4.2 Atenuações ................................................................................................................... 23
1.1.4.3 Ecos .............................................................................................................................. 23
1.1.5 Técnicas de Modulação ........................................................................................................ 24
1.1.5.1 Modulação Analógica ................................................................................................... 24
1.1.5.1.1
1.1.5.1.2
1.1.5.1.3
Modulação por Amplitude (AM) ....................................................................................... 24
Modulação por Frequência (FM) ....................................................................................... 25
Modulação por Fase (PM) ................................................................................................. 25
1.1.5.2 Modulação Digital ........................................................................................................ 25
1.1.5.2.1
1.1.5.2.2
1.1.5.2.3
Modulação por Deslocamento de Amplitude (ASK) .......................................................... 25
Modulação por Deslocamento de Frequência (FSK) .......................................................... 26
Modulação por Deslocamento de Fase (PSK) .................................................................... 26
1.1.6 Comutação ........................................................................................................................... 26
1.1.6.1 Circuitos ....................................................................................................................... 26
1.1.6.2 Mensagens .................................................................................................................... 28
1.1.6.3 Pacotes .......................................................................................................................... 28
1.1.6.3.1
1.1.6.3.2
Comutação de Pacotes – Circuito Virtual ........................................................................... 29
Comutação de Pacotes – Datagrama ................................................................................. 29
1.1.6.4 Células .......................................................................................................................... 30
2
1.1.7 Forma de Comunicação ........................................................................................................ 30
1.1.8 Multiplexação ....................................................................................................................... 30
1.1.8.1 Multiplexação na Frequência ........................................................................................ 31
1.1.8.2 Multiplexação no Tempo .............................................................................................. 33
1.1.8.2.1
1.1.8.2.2
TDM Síncrono .................................................................................................................. 33
TDM Assíncrono ............................................................................................................... 34
1.1.8.3 Características do FDM e do TDM ............................................................................... 35
1.1.8.4 Sistemas em Banda Larga e em Banda Básica .............................................................. 35
1.1.8.4.1
1.1.8.4.2
Sinalização em Banda Básica ............................................................................................ 36
Sinalização em Banda Larga .............................................................................................. 36
1.1.9 Digitalização de um Sinal pela Técnica PCM ...................................................................... 36
1.1.10 Codificação e Transmissão de Sinais Digitais em Banda Básica .......................................... 37
1.1.10.1 Transmissão Assíncrona ............................................................................................. 38
1.1.10.2 Transmissão Síncrona ................................................................................................. 40
1.1.10.2.1
1.1.10.2.2
Codificação Manchester .................................................................................................. 41
Codificação Manchester Diferencial ................................................................................ 43
1.1.11 Técnicas de Detecção de Erros ............................................................................................. 44
1.1.11.1 Paridade ...................................................................................................................... 45
1.1.11.2 CRC ............................................................................................................................ 45
Capítulo 2 Meios de Transmissão e Topologia de Redes ............................... 48
2.1
Meios de Transmissão ............................................................................................................... 48
2.1.1 Fios de cobre ........................................................................................................................ 48
2.1.1.1 Cabo de Par Trançado ................................................................................................... 48
2.1.1.2 Cabo Coaxial ................................................................................................................ 49
2.1.2 Fibras de Vidro ..................................................................................................................... 50
2.1.3 Rádio .................................................................................................................................... 50
2.1.4 Satélites ................................................................................................................................ 50
2.1.4.1 Satélites Geossíncronos ou Geoestacionários ............................................................... 51
2.1.4.2 Satélites de Baixa Órbita da Terra ................................................................................ 51
2.1.4.3 Arrays de Satélites de Baixa Órbita da Terra ................................................................ 52
2.1.5 Microondas........................................................................................................................... 52
2.1.6 Infravermelho ....................................................................................................................... 53
2.1.7 Luz de Laser......................................................................................................................... 53
2.2
Classificação de Redes .............................................................................................................. 53
2.3
Topologia de Redes Locais (LAN) ........................................................................................... 54
2.3.1 Estrela .................................................................................................................................. 54
2.3.2 Anel ...................................................................................................................................... 54
2.3.3 Barramento ........................................................................................................................... 55
Capítulo 3 Modelo OSI .................................................................................... 56
3.1
Tipos de Serviços OSI............................................................................................................... 58
3.1.1 Serviço Orientado a Conexão ............................................................................................... 58
3.1.2 Serviço não Orientado a Conexão ........................................................................................ 59
3.2
OSI Hoje ................................................................................................................................... 59
Capítulo 4 Dispositivos de Conectividade....................................................... 61
4.1
Placas de Rede (NIC – Network Interface Card) ...................................................................... 61
4.2
Modems ..................................................................................................................................... 61
4.3
Repetidores ............................................................................................................................... 61
3
4.4
Hubs (Concentradores) ............................................................................................................. 61
4.5
Bridges (Pontes) ........................................................................................................................ 62
4.6
Switches (Comutadores) ............................................................................................................ 63
4.7
Gateways................................................................................................................................... 64
4.8
Roteadores ................................................................................................................................ 65
4.9
Access Point (Ponto de Acesso – AP) ....................................................................................... 65
Capítulo 5 Método de Acesso ao Meio ............................................................ 66
5.1
Método de Acesso ao Meio ....................................................................................................... 66
5.1.1 CSMA .................................................................................................................................. 66
5.1.1.1 CSMA/CD .................................................................................................................... 66
5.1.1.2 CSMA/CA .................................................................................................................... 68
5.1.2 Token Passing (Passagem de Token) .................................................................................... 70
5.2
Arquitetura ................................................................................................................................ 72
5.2.1 Ethernet ................................................................................................................................ 72
5.2.1.1 O Algoritmo de Recuo Binário Exponencial ................................................................ 74
5.2.2 Token Ring ........................................................................................................................... 74
5.2.3 Wireless (Redes sem Fio) ..................................................................................................... 75
Capítulo 6 Tecnologias para conexão digital de longa distância ................... 79
6.1
X.25 .......................................................................................................................................... 79
6.2
Frame Relay (FR) ..................................................................................................................... 79
6.3
ATM ......................................................................................................................................... 79
6.3.1 Circuitos Virtuais do ATM ................................................................................................... 80
6.4
ISDN ......................................................................................................................................... 80
6.5
xDSL......................................................................................................................................... 81
6.5.1 Outras Tecnologias de DSL .................................................................................................. 83
6.6
Cable Modem............................................................................................................................ 84
Capítulo 7 Arquitetura TCP/IP ...................................................................... 86
7.1
A Motivação para Ligação Inter-redes ...................................................................................... 86
7.2
O Conceito de Serviço Universal .............................................................................................. 86
7.3
Serviço Universal em um Mundo Heterogêneo ......................................................................... 86
7.4
Ligação Inter-redes ................................................................................................................... 87
7.5
Conexão de Rede Física com Roteadores.................................................................................. 87
7.6
Arquitetura de Inter-rede ........................................................................................................... 87
7.7
Obtendo Serviço Universal ....................................................................................................... 88
7.8
Uma Rede Virtual ..................................................................................................................... 88
7.9
Protocolos para Ligação Inter-redes .......................................................................................... 89
7.10
Arquitetura TCP/IP ................................................................................................................... 89
7.11
Divisão em Camadas do Protocolo TCP/IP ............................................................................... 90
4
7.12 Endereços para a Inter-rede Virtual ........................................................................................... 91
7.12.1 O Esquema de Endereços IP ................................................................................................. 92
7.12.2 A Hierarquia de Endereços IP .............................................................................................. 92
7.12.3 Classes de Endereços IP ....................................................................................................... 92
7.12.4 Computando a Classe de um Endereço................................................................................. 93
7.12.5 Notação Decimal Pontilhada ................................................................................................ 94
7.12.6 Classes e Notação Decimal Pontilhada ................................................................................. 94
7.12.7 Autoridade para Endereços................................................................................................... 95
7.12.8 Um Exemplo de Endereçamento IP ...................................................................................... 95
7.12.9 Endereços IP Especiais ......................................................................................................... 96
7.12.9.1 Endereço de Rede ....................................................................................................... 96
7.12.9.2 Endereço de Broadcast Direcionado........................................................................... 96
7.12.9.3 Endereço de Broadcast Limitado................................................................................ 97
7.12.9.4 Endereço deste Computador ....................................................................................... 97
7.12.9.5 Endereço de Loopback................................................................................................ 97
7.12.9.6 Resumo de Endereços IP Especiais ............................................................................ 98
7.12.10 Divisão do Espaço de Endereçamento ............................................................................. 98
7.12.11 Roteadores e o Princípio de Endereçamento IP................................................................ 98
7.12.12 Host Multi-Homed ........................................................................................................... 99
7.12.13 Sub-redes ......................................................................................................................... 99
7.13 Técnicas para Resolução de Endereços ................................................................................... 102
7.13.1 O Problema da Tradução de Endereço ............................................................................... 102
7.13.2 Dois Tipos de Endereços Físicos ........................................................................................ 102
7.13.3 Tradução por Mapeamento Direto ...................................................................................... 102
7.13.4 Tradução por Vínculo Dinâmico ........................................................................................ 103
7.13.5 O Cache de Tradução de Endereço .................................................................................... 104
7.13.6 Timeout de Cache ARP ...................................................................................................... 104
7.13.7 Funcionamento do ARP ..................................................................................................... 105
7.13.7.1 Envio de um Datagrama dentro da mesma rede ....................................................... 105
7.13.7.2 Envio de um Datagrama para um nó que está fora da rede ...................................... 106
7.13.8 Refinamentos do ARP ........................................................................................................ 108
7.13.9 Relacionamento do ARP com outros Protocolos ................................................................ 108
7.13.10 Implementação do ARP ................................................................................................. 108
7.13.11 Encapsulamento e Identificação do ARP ....................................................................... 109
7.13.12 Formato do Protocolo ARP ............................................................................................ 110
7.13.13 Revalidação Automática de Cache ARP ........................................................................ 111
7.13.14 Reverse Address Resolution (RARP) ............................................................................. 111
7.14 Entrega de Datagramas Sem Conexão.................................................................................... 112
7.14.1 Sistema de Entrega sem Conexão ....................................................................................... 112
7.14.2 Finalidade do Internet Protocol (IP) ................................................................................... 112
7.14.3 O Datagrama IPv4 ............................................................................................................. 112
7.14.4 Formato do Datagrama ...................................................................................................... 113
7.14.5 Encapsulamento de Datagramas IP.................................................................................... 113
7.14.6 Tamanho do Datagrama, MTU da rede e Fragmentação ................................................... 114
7.14.7 Remontagem de Fragmentos .............................................................................................. 116
7.14.8 Controle de Fragmentação .................................................................................................. 116
7.14.9 Time to Live (TTL) ............................................................................................................. 117
7.15 Encaminhamento de Datagramas ........................................................................................... 118
7.15.1 Encaminhamento em uma Inter-rede .................................................................................. 118
7.15.2 Entrega Direta e Indireta .................................................................................................... 119
7.15.3 Entrega de Datagrama por uma Única Rede ...................................................................... 120
7.15.4 Entrega Indireta .................................................................................................................. 120
7.15.5 Encaminhamento IP controlado por Tabela ........................................................................ 120
5
7.15.6 Encaminhamento do Próximo Salto ................................................................................... 121
7.15.7 Rotas Default...................................................................................................................... 122
7.15.8 Rotas Específicas do Host .................................................................................................. 123
7.15.9 O Algoritmo de Encaminhamento IP ................................................................................. 123
7.15.10 Encaminhamento com Endereços IP .............................................................................. 123
7.15.11 Tratando de Datagramas que Chegam ........................................................................... 125
7.16 IPv6 ......................................................................................................................................... 126
7.16.1 Por que Mudar? .................................................................................................................. 126
7.16.2 Além do IPv4 ..................................................................................................................... 126
7.16.3 A Estrada para uma Nova Versão do IP ............................................................................. 127
7.16.4 O Nome do Próximo IP ...................................................................................................... 127
7.16.5 Características do IPv6 ....................................................................................................... 127
7.16.6 Forma Geral de um Datagrama IPv6 ................................................................................. 128
7.16.6.1 Formato de Cabeçalho Básico do IPv6 ..................................................................... 128
7.16.6.2 Cabeçalhos de Extensão do IPv6 .............................................................................. 130
7.16.7 Analisando um Datagrama IPv6 ........................................................................................ 130
7.16.8 Fragmentação e Remontagem do IPv6 ............................................................................... 130
7.16.9 A Conseqüência da Fragmentação de fim-a-fim................................................................. 131
7.16.10 Roteamento de Origem IPv6 .......................................................................................... 131
7.16.11 Opções do IPv6 .............................................................................................................. 132
7.16.12 Tamanho do Espaço de Endereços do IPv6 ................................................................... 133
7.16.13 Notação Hexadecimal de dois pontos do IPv6 ............................................................... 133
7.16.14 Endereços IPv4 Embutidos e Transição ......................................................................... 134
7.16.15 Endereços Não-Especificados e de Loopback ................................................................ 135
7.16.16 Estrutura de Endereço Unicast ....................................................................................... 135
7.17 ICMP ...................................................................................................................................... 135
7.17.1 O Internet Control Message Protocol ................................................................................ 136
7.17.2 Relato de erro versus correção de erro................................................................................ 136
7.17.3 Entrega de mensagem ICMP .............................................................................................. 137
7.17.4 Formato de mensagem ICMP ............................................................................................. 138
7.17.5 Teste de alcance e status do destino (ping) ......................................................................... 139
7.17.6 Requisição de eco e formato de mensagem de resposta ...................................................... 140
7.17.7 Relatos de destinos inalcançáveis ....................................................................................... 140
7.17.8 Controle de congestionamento e fluxo de datagramas ........................................................ 141
7.17.9 Formato de extinção de origem .......................................................................................... 142
7.17.10 Requisições de mudança de rota dos roteadores............................................................. 142
7.17.11 Detectando rotas circulares ou excessivamente longas .................................................. 144
7.17.12 Relatando outros problemas ........................................................................................... 144
7.17.13 Sincronismo de clock e estimativa de tempo de trânsito ................................................ 145
7.17.14 Mensagens ICMP mais antigas e não mais necessárias .................................................. 146
7.18 UDP ........................................................................................................................................ 146
7.18.1 Identificando o destino final ............................................................................................... 147
7.18.2 O User Datagram Protocol ................................................................................................ 147
7.18.3 Formato de mensagens UDP .............................................................................................. 148
7.18.4 Pseudocabeçalho UDP ....................................................................................................... 149
7.18.5 Encapsulamento e camadas de protocolos UDP ................................................................. 149
7.18.6 Camadas e o cálculo de checksum do UDP ........................................................................ 151
7.18.7 Multiplexação, demultiplexação e portas UDP................................................................... 151
7.18.8 Números de porta UDP reservados e disponíveis ............................................................... 152
7.19 TCP ......................................................................................................................................... 153
7.19.1 A necessidade de entrega de fluxo...................................................................................... 153
7.19.2 Propriedades do serviço de entrega confiável ..................................................................... 154
7.19.3 Fornecendo confiabilidade ................................................................................................. 155
6
7.19.4 A idéia por trás das janelas deslizantes ............................................................................... 157
7.19.5 O Transmission Control Protocol ...................................................................................... 158
7.19.6 Portas, conexões e extremidades ........................................................................................ 159
7.19.7 Aberturas passivas e ativas ................................................................................................. 160
7.19.8 Segmentos, fluxos e números de sequência ........................................................................ 161
7.19.9 Tamanho de janela variável e controle de fluxo ................................................................. 162
7.19.10 Formato do segmento TCP ............................................................................................ 162
7.19.11 Dados fora de faixa ........................................................................................................ 164
7.19.12 Opções do TCP .............................................................................................................. 164
7.19.12.1 Opção de tamanho máximo do segmento ............................................................... 164
7.19.12.2 Opção de janela móvel ............................................................................................ 165
7.19.12.3 Opção de estampa de tempo ................................................................................... 166
7.19.13 Cálculo do checksum TCP ............................................................................................. 166
7.19.14 Estabelecendo uma conexão TCP .................................................................................. 167
7.19.15 Números de sequência iniciais ....................................................................................... 167
7.19.16 Fechando uma conexão TCP .......................................................................................... 168
7.19.17 Reinício da conexão TCP ............................................................................................... 169
7.19.18 Números de porta TCP reservados ................................................................................. 169
7.19.19 Desempenho do TCP ..................................................................................................... 170
Capítulo 8 Serviços e Tecnologias Web ........................................................ 172
8.1
Atribuição Dinâmica de Endereços ......................................................................................... 172
8.1.1 BOOTP .............................................................................................................................. 172
8.1.2 DHCP ................................................................................................................................. 172
8.1.2.1 Usando IP para determinar um endereço IP ................................................................ 173
8.1.2.2 A política de retransmissão do DHCP ........................................................................ 174
8.1.2.3 O formato de mensagem DHCP ................................................................................. 174
8.1.2.4 A necessidade da configuração dinâmica ................................................................... 176
8.1.2.5 Conceito de aluguel do DHCP .................................................................................... 177
8.2
NAT ........................................................................................................................................ 177
8.2.1 Criação da tabela de tradução NAT .................................................................................... 177
8.2.2 NAT multiendereço ............................................................................................................ 178
8.2.3 NAT mapeado em porta ..................................................................................................... 179
8.2.4 Interação entre NAT e ICMP.............................................................................................. 180
8.2.5 Interação entre NAT e aplicações ....................................................................................... 180
8.2.6 NAT na presença de fragmentação ..................................................................................... 181
8.2.7 Domínios de endereço conceituais ..................................................................................... 181
8.2.8 Slirp e Iptables.................................................................................................................... 181
8.3
DNS ........................................................................................................................................ 182
8.3.1 Nomes para máquinas ........................................................................................................ 182
8.3.2 Espaço de nomes plano ...................................................................................................... 183
8.3.3 Nomes hierárquicos ............................................................................................................ 183
8.3.4 Delegação de autoridade para nomes.................................................................................. 184
8.3.5 Autoridade de subconjunto ................................................................................................. 184
8.3.6 Internet Domain Names ...................................................................................................... 185
8.3.7 Domínios de nível superior ................................................................................................ 186
8.3.8 Sintaxe e tipo de nome ....................................................................................................... 187
8.3.9 Mapeando nomes de domínio para endereços .................................................................... 188
8.3.10 Tradução de nome de domínio ........................................................................................... 190
8.3.11 Tradução eficiente .............................................................................................................. 190
8.3.12 Caching: a chave para a eficiência...................................................................................... 191
8.4
Correio Eletrônico ................................................................................................................... 192
7
8.4.1 Nomes e aliases da caixa de correio ................................................................................... 193
8.4.2 Expansão de alias e encaminhamento de correio ................................................................ 193
8.4.3 Padrões do TCP/IP para serviço de correio eletrônico ........................................................ 194
8.4.4 Simple Mail Transfer Protocol (SMTP) ............................................................................. 195
8.4.5 Recuperação de correio e protocolos de manipulação de caixa de correio ......................... 196
8.4.5.1 Post Office Protocol.................................................................................................... 197
8.4.5.2 Internet Message Access Protocol .............................................................................. 197
8.5
FTP ......................................................................................................................................... 198
8.5.1 Recursos do FTP ................................................................................................................ 198
8.5.2 Modelo de processo do FTP ............................................................................................... 198
8.5.3 Números de porta TCP e conexões de dados ...................................................................... 199
8.5.4 A visão do usuário do FTP ................................................................................................. 200
8.5.5 FTP anônimo ...................................................................................................................... 200
8.6
World Wide Web – HTTP ...................................................................................................... 200
8.6.1 Descrição Geral do HTTP. ................................................................................................. 201
8.6.2 Conexões não persistentes e conexões persistentes ............................................................ 203
8.6.2.1 Conexões não persistentes .......................................................................................... 203
8.6.2.2 Conexões Persistentes ................................................................................................. 204
8.6.3 Formato da mensagem HTTP ............................................................................................. 205
8.6.3.1 Mensagem de requisição HTTP .................................................................................. 205
8.6.3.2 Mensagem de resposta HTTP ..................................................................................... 207
8.6.4 Interação usuário/servidor: autenticação e cookies ............................................................. 209
8.6.4.1 Autenticação ............................................................................................................... 209
8.6.4.2 Cookies ....................................................................................................................... 210
8.6.5 O GET condicional............................................................................................................. 210
8.6.6 Web Caches ........................................................................................................................ 212
Capítulo 9 Segurança em Redes .................................................................... 216
9.1
O que é segurança na rede? ..................................................................................................... 216
9.1.1 Comunicação Segura .......................................................................................................... 216
9.1.2 Considerações sobre segurança de rede na Internet ............................................................ 217
9.2
Princípios da criptografia ........................................................................................................ 219
9.2.1 Criptografia de chaves simétricas ....................................................................................... 220
9.2.2 Criptografia de chaves públicas .......................................................................................... 222
9.3
Autenticação: quem é você? .................................................................................................... 224
9.3.1 Protocolo de autenticação PA 1.0 ....................................................................................... 224
9.4
Integridade .............................................................................................................................. 229
9.4.1 Geração de assinaturas digitais ........................................................................................... 230
9.4.2 Resumo de mensagem ........................................................................................................ 231
9.4.3 Algoritmos de função de hash ............................................................................................ 233
9.5
Distribuição de chaves e certificação ...................................................................................... 234
9.5.1 KDC (central de distribuição de chaves) ............................................................................ 235
9.5.2 Kerberos ............................................................................................................................. 236
9.5.3 Certificação de chaves públicas .......................................................................................... 237
9.6
E-mail seguro .......................................................................................................................... 240
8
9.6.1 Princípios de segurança para e-mail ................................................................................... 240
9.6.2 PGP (privacidade razoável) ................................................................................................ 243
9.7
Comércio pela Internet ............................................................................................................ 244
9.7.1 Comércio pela Internet usando SSL ................................................................................... 245
9.7.1.1 Como a SSL funciona ................................................................................................. 246
9.7.1.2 A SSL em ação ........................................................................................................... 248
9.7.1.3 As limitações no comércio pela internet ..................................................................... 248
9.7.2 Comércio pela Internet usando SET ................................................................................... 249
9.7.2.1 Estágios de uma compra ............................................................................................. 250
9.8
Segurança na camada de rede: o IPsec .................................................................................... 251
9.8.1 AH (protocolo de autenticação de cabeçalho) .................................................................... 252
9.8.2 ESP (protocolo de segurança de encapsulamento da carga útil) ......................................... 254
9.8.3 O AS e a administração de chaves ...................................................................................... 254
Apêndice A Série de Fourier ......................................................................... 255
A.1 Exemplo 1: Cálculo dos Coeficientes de Fourier de um Sinal NRZ ........................................ 257
A.1.1 Cálculo do a 0 .................................................................................................................... 257
A.1.2 Cálculo do a n .................................................................................................................... 258
A.1.3 Cálculo do bn ..................................................................................................................... 259
A.1.4 Gráficos do Exemplo 1 ....................................................................................................... 260
A.2 Exemplo 2: Cálculo dos Coeficientes de Fourier de um Sinal Manchester ............................. 268
A.2.1 Cálculo do a 0 .................................................................................................................... 269
A.2.2 Cálculo do a n .................................................................................................................... 269
A.2.3 Cálculo do bn ..................................................................................................................... 271
A.2.4 Gráficos do Exemplo 2 ....................................................................................................... 272
A.3
Como Integrar Funções Seno e Cosseno ................................................................................. 281
Apêndice B Cálculo relacionado à Órbita de Satélites ................................ 282
Apêndice C Técnicas de Criptografia ........................................................... 285
C.1
DES (padrão para criptografia de dados) ................................................................................ 285
C.2 RSA ........................................................................................................................................ 286
C.2.1 Porque o RSA funciona? .................................................................................................... 288
Bibliografia ....................................................................................................... 291
9
Índice de Figuras dos Capítulos
Figura 1.1 – Sinal Analógico. ....................................................................................................... 17
Figura 1.2 – Sinal Digital. ............................................................................................................ 18
Figura 1.3 – Visualização de Duas Ondas de Frequências Diferentes. ........................................ 19
Figura 1.4 – Representação do Seno e Cosseno no Círculo Trigonométrico. .............................. 19
Figura 1.5 – Senoide em Função do Tempo. ................................................................................ 20
Figura 1.6 – Cossenoide em Função do Tempo. .......................................................................... 20
Figura 1.7 – Senoide em Função da Fase. .................................................................................... 21
Figura 1.8 – Cossenoide em Função da Fase. .............................................................................. 21
Figura 1.9 – Exemplo de Modulação Analógica. ......................................................................... 24
Figura 1.10 – Exemplo de Modulação Digital. ............................................................................ 25
Figura 1.11 – Comutação de Circuito........................................................................................... 26
Figura 1.12 – Comutação por Circuito ao Longo do Tempo. ...................................................... 27
Figura 1.13 – Comutação por Mensagem ao Longo do Tempo. .................................................. 28
Figura 1.14 – Comutação por Pacote. .......................................................................................... 29
Figura 1.15 – Comutação por Pacote ao Longo do Tempo. ......................................................... 30
Figura 1.16 – Desperdício de Banda Passante do Meio Físico. ................................................... 31
Figura 1.17 – Multiplexação na Frequência (FDM). .................................................................... 31
Figura 1.18 – Exemplo de Multiplexação na Frequência de três Sinais de Voz. ......................... 32
Figura 1.19 – Transmissão em uma Linha Multiplexada na Frequência. .................................... 32
Figura 1.20 – TDM Síncrono. ...................................................................................................... 33
Figura 1.21 – Desperdício de Capacidade com TDM Síncrono. .................................................. 34
Figura 1.22 – TDM Assíncrono.................................................................................................... 35
Figura 1.23 – Digitalização de um Sinal (PCM). ......................................................................... 37
Figura 1.24 – Codificação NRZ. .................................................................................................. 38
Figura 1.25 – Recuperação de um Sinal NRZ. ............................................................................. 38
Figura 1.26 – Exemplo de Transmissão Assíncrona. ................................................................... 39
Figura 1.27 – Exemplo de Transmissão e Recepção Assíncrona. ................................................ 40
Figura 1.28 – Codificação Manchester......................................................................................... 41
Figura 1.29 – Exemplo de Codificação Manchester. ................................................................... 42
Figura 1.30 – Recuperação do Período do Clock Através do Preâmbulo. ................................... 42
Figura 1.31 – Exemplo de Transmissão Manchester. .................................................................. 43
Figura 1.32 – Exemplo de Codificação Manchester Diferencial. ................................................ 43
Figura 1.33 – Criação do FCS usando a Técnica CRC no Transmissor....................................... 46
Figura 1.34 – Verificação dos Dados Usando a Técnica CRC feita no Receptor. ....................... 47
Figura 2.1 – Par Trançado. ........................................................................................................... 49
Figura 2.2 – Cabo Coaxial. ........................................................................................................... 49
Figura 2.3 – Comunicação Via Satélite. ....................................................................................... 51
Figura 2.4 – Array de Satélites. .................................................................................................... 52
Figura 2.5 – Topologia em Estrela. .............................................................................................. 54
Figura 2.6 – Topologia em Anel................................................................................................... 55
Figura 2.7 – Topologia de Barramento......................................................................................... 55
Figura 3.1 – Modelo OSI em Camadas. ....................................................................................... 58
Figura 4.1 – Conexão de dois segmentos por uma Bridge. .......................................................... 62
Figura 4.2 – Montagem da Tabela de Mapeamento de uma Bridge. ........................................... 63
Figura 4.3 – Esquema Lógico de um Switch. ............................................................................... 64
Figura 5.1 – Funcionamento do CSMA/CD. ................................................................................ 67
10
Figura 5.2 – Exemplo de Comunicação Sem Fio. ........................................................................ 68
Figura 5.3 – Transmissão de A para B. ........................................................................................ 68
Figura 5.4 – Colisão entre A e C. ................................................................................................. 69
Figura 5.5 – Sinal de Controle para B. ......................................................................................... 69
Figura 5.6 – Resposta de B ao Sinal de Controle de A. ............................................................... 70
Figura 5.7 – Região Reservada para a Comunicação de A com B. .............................................. 70
Figura 5.8 – Funcionamento do Token Passing. .......................................................................... 71
Figura 5.9 – Formato de Quadros DIX. ........................................................................................ 72
Figura 5.10 – Rede Sem Fio com uma Estação-Base (AP). ......................................................... 76
Figura 5.11 – Rede Sem Fio Ad Hoc. .......................................................................................... 76
Figura 5.12 – Uma Rede 802.11 de Várias Células. .................................................................... 77
Figura 7.1 – Duas redes físicas conectadas por um roteador. ...................................................... 87
Figura 7.2 – Uma inter-rede formada usando três roteadores. ..................................................... 87
Figura 7.3 – O conceito de inter-rede. .......................................................................................... 89
Figura 7.4 – As camadas do modelo de referência TCP/IP. ......................................................... 90
Figura 7.5 – Divisão em Classes do endereçamento IP................................................................ 93
Figura 7.6 – Uma inter-rede de exemplo privado com endereços IP atribuídos aos hosts........... 96
Figura 7.7 – Um exemplo de endereços IP atribuídos a dois roteadores. .................................... 99
Figura 7.8 – Uma rede de campus consistindo em LANs para vários departamentos. .............. 100
Figura 7.9 – Uma rede da classe B dividida em 64 sub-redes. ................................................... 101
Figura 7.10 – O protocolo ARP. ................................................................................................. 104
Figura 7.11 – Cada nó em uma LAN tem um endereço IP e um endereço MAC. ..................... 106
Figura 7.12 – Duas LANs interconectadas por um roteador. ..................................................... 107
Figura 7.13 – Uma mensagem ARP encapsulada em um frame de rede física. ......................... 110
Figura 7.14 – Formato de uma Mensagem ARP/RARP para o padrão Ethernet. ...................... 110
Figura 7.15 – Formato Geral de um Datagrama IP. .................................................................. 113
Figura 7.16 – Formato de um Datagrama IP. ............................................................................ 113
Figura 7.17 – O encapsulamento de um datagrama IP em um frame. ........................................ 114
Figura 7.18 – Um exemplo de necessidade de fragmentação. ................................................... 115
Figura 7.19 – Exemplo de Fragmentação de um Datagrama. ................................................... 116
Figura 7.20 – Um exemplo de um host singly-homed que precisa encaminhar datagramas. .... 119
Figura 7.21 – Uma internet de exemplo com 4 redes e 3 roteadores. ........................................ 122
Figura 7.22 – O IP e a tabela de roteamento residem acima do limite de endereço. .................. 124
Figura 7.23 – Formato Geral de um Datagrama IPv6. .............................................................. 128
Figura 7.24 – O Formato do Cabeçalho Básico do IPv6 de 40 octetos. ..................................... 129
Figura 7.25 – Três Datagramas IPv6. ........................................................................................ 130
Figura 7.26 – O Formato de um Cabeçalho de Extensão de Fragmento. ................................... 131
Figura 7.27 – O Formato de um Cabeçalho de Roteamento IPv6. ............................................. 132
Figura 7.28 – O Formato de um Cabeçalho de Extensão de Opção IPv6. ................................. 132
Figura 7.29 – A Codificação de uma Opção Individual em um Cabeçalho de Extensão IPv6. . 132
Figura 7.30 – Codificação de um Endereço IPv4 em um Endereço IPv6. ................................. 134
Figura 7.31 – A Divisão de um Endereço de Unicast IPv6 em Três Partes. .............................. 135
Figura 7.32 – Dois níveis de encapsulamento ICMP. ................................................................ 137
Figura 7.33 – Formato de uma mensagem de requisição ou resposta de eco do ICMP. ............ 140
Figura 7.34 – Formato da mensagem de destino inalcançável do ICMP. .................................. 140
Figura 7.35 – Formato da mensagem de extinção de origem ICMP. ......................................... 142
Figura 7.36 – Mensagens de redirecionamento ICMP. .............................................................. 143
Figura 7.37 – Formato da mensagem de redirecionamento ICMP. ............................................ 143
Figura 7.38 – Formato da mensagem de tempo excedido do ICMP. ......................................... 144
Figura 7.39 – Formato da mensagem de problema de parâmetro do ICMP............................... 145
11
Figura 7.40 – Formato da mensagem de requisição ou resp. de estampa de tempo do ICMP. .. 145
Figura 7.41 – O formato dos campos em um datagrama UDP. .................................................. 148
Figura 7.42 – Os 12 octetos do pseudocabeçalho para o cálculo do checksum. ........................ 149
Figura 7.43 – As camadas conceituais do UDP entre programas aplicativos e o IP. ................. 150
Figura 7.44 – Um datagrama UDP encapsulado em um datagrama IP. ..................................... 150
Figura 7.45 – Exemplo de demultiplexação de uma camada acima do IP. ................................ 152
Figura 7.46 – Um protocolo usando confirmação positiva com retransmissão. ........................ 156
Figura 7.47 – Timeout e retransmissão que ocorre quando um pacote é perdido. ..................... 156
Figura 7.48 – Um protocolo de janela deslizante com oito pacotes na janela............................ 157
Figura 7.49 – Um exemplo de três pacotes transmitidos usando a janela deslizante. ................ 158
Figura 7.50 – A disposição conceitual em camadas do UDP e TCP acima do IP...................... 159
Figura 7.51 – Um exemplo da janela deslizante do TCP. .......................................................... 161
Figura 7.52 – O formato de um segmento TCP com um cabeçalho TCP seguido por dados. ... 163
Figura 7.53 – O formato do pseudo cabeçalho usado pelo TCP. ............................................... 166
Figura 7.54 – A sequência de mensagens em um handshake de três vias. ................................. 167
Figura 7.55 – O handshake de três vias modificado usado para fechar conexões...................... 169
Figura 8.1 – Formato de uma mensagem DHCP. ....................................................................... 175
Figura 8.2 – Formato do campo FLAGs de 16 bits do DHCP. .................................................. 175
Figura 8.3 – O uso de um NAT por um pequeno ISP. ............................................................... 178
Figura 8.4 – Uma pequena parte da hierarquia de nome de domínio da Internet. ..................... 187
Figura 8.5 – A organização conceitual dos servidores de nome de domínio. ............................ 189
Figura 8.6 – Uma organização realista de servidores para a Hierarquia de nomes. ................... 189
Figura 8.7 – Componentes conceituais de uma sistema de correio eletrônico. .......................... 192
Figura 8.8 – Uma extensão do sistema de correio da Figura 8.7................................................ 193
Figura 8.9 – Exemplo de transferência SMTP de Alpha.edu para Beta.gov. ............................. 196
Figura 8.10 – Um cliente e um servidor FTP com conexões TCP entre eles. ............................ 199
Figura 8.11 – Comportamento de requisição-resposta do HTTP. .............................................. 202
Figura 8.12 – Formato geral de uma mensagem de requisição. ................................................. 206
Figura 8.13 – Formato geral de uma mensagem de resposta. .................................................... 208
Figura 8.14 – Clientes requisitando objetos por meio de um Web Cache. ................................ 213
Figura 8.15 – Gargalo entre uma rede institucional e a Internet. ............................................... 214
Figura 8.16 – Adição de um cache à rede institucional. ............................................................. 215
Figura 9.1 – Remetente, destinatário e intruso (Alice, Bob e Trudy). ....................................... 217
Figura 9.2 – Analisador de Pacotes. ........................................................................................... 218
Figura 9.3 – Componentes Criptográficos.................................................................................. 219
Figura 9.4 – Uma cifra monoalfabética. ..................................................................................... 221
Figura 9.5 – Uma cifra de Vigenere usando duas cifras de César. ............................................. 222
Figura 9.6 – Criptografia de chaves públicas. ............................................................................ 223
Figura 9.7 – Protocolo PA 1.0 e um cenário de falha. ............................................................... 224
Figura 9.10 – Protocolo PA 4.0 e um cenário de falha............................................................... 227
Figura 9.11 – Protocolo PA 5.0 trabalhando corretamente. ....................................................... 228
Figura 9.12 – Falha de segurança no protocolo PA 5.0.............................................................. 228
Figura 9.13 – Um ataque do homem do meio. ........................................................................... 229
Figura 9.14 – Criação de uma assinatura digital para um documento........................................ 230
Figura 9.15 – Funções de hash são usadas para criar resumos de mensagem. ........................... 232
Figura 9.16 – Envio de uma mensagem assinada digitalmente. ................................................. 232
Figura 9.17 – Verificação da integridade de uma mensagem assinada. ..................................... 233
Figura 9.18 – Mensagem inicial e mensagem fraudulenta têm a mesma soma de verificação. . 234
12
Figura 9.19 – Estabelecimento de uma chave de sessão única usando uma KDC. .................... 235
Figura 9.20 – Trudy se passa por Bob usando a criptografia de chaves públicas. ..................... 238
Figura 9.21 – Bob obtém um certificado de uma CA................................................................. 239
Figura 9.22 – Alice usa uma chave de sessão simétrica KS. ...................................................... 242
Figura 9.23 – Uso de funções de hash e assinaturas digitais...................................................... 242
Figura 9.24 – Alice usa várias técnicas para enviar uma mensagem. ........................................ 243
Figura 9.25 – Mensagem PGP assinada. .................................................................................... 244
Figura 9.26 – Mensagem PGP secreta. ....................................................................................... 244
Figura 9.27 – Visão de alto nível da fase de mútua apresentação SSL. ..................................... 247
Figura 9.28 – Posição do cabeçalho AH no datagrama IP. ........................................................ 253
Figura 9.29 – Campos ESP no datagrama IP. ............................................................................ 254
13
Índice de Figuras dos Apêndices
Figura A-1 – Exemplo 1: Sinal NRZ. ......................................................................................... 257
Figura A-2 – Sinal Original. ....................................................................................................... 261
Figura A-3 – 10 Harmônicos de Fourier. ................................................................................... 261
Figura A-4 – Primeiro Harmônico de Fourier. ........................................................................... 262
Figura A-5 – Somatório dos 2 primeiros Harmônico de Fourier. .............................................. 262
Figura A-10 – Somatório dos 7 primeiros Harmônico de Fourier. ............................................ 265
Figura A-13 – Somatório dos 10 primeiros Harmônico de Fourier. .......................................... 266
Figura A-14 – Amplitude de Média Quadrática de cada Harmônico de Fourier. ...................... 267
Figura A-15 – Exemplo 2: Sinal Manchester. ............................................................................ 268
Figura A-16 – Sinal Original. ..................................................................................................... 273
Figura A-17 – 13 Harmônicos de Fourier. ................................................................................. 273
Figura A-18 – Primeiro Harmônico de Fourier. ......................................................................... 274
Figura A-31 – Amplitude de Média Quadrática de cada Harmônico de Fourier. ...................... 280
Figura B-1 – Órbita de um Satélite............................................................................................. 282
Figura C-1 – Operação básica do DES. ...................................................................................... 286
Figura C-2 – Criptografia de chaves públicas. ........................................................................... 287
14
Índice de Equações
Equação A-1 – Forma Geral da Série de Fourier. ...................................................................... 256
Equação A-2 – Coeficientes da Série de Fourier........................................................................ 256
Equação A-3 – Amplitude de Média Quadrática de cada Harmônico de Fourier. ..................... 256
Equação A-4 – Função Representante do Sinal NRZ. ............................................................... 257
Equação A-5 – Coeficiente a0 do Sinal NRZ. ............................................................................ 258
Equação A-6 – Coeficiente an do Sinal NRZ. ............................................................................ 259
Equação A-7 – Coeficiente bn do Sinal NRZ. ............................................................................ 259
Equação A-8 – Série de Fourier Completa para o Sinal NRZ. ................................................... 260
Equação A-9 – Função Representante do Sinal Manchester. ..................................................... 268
Equação A-10 – Coeficiente a0 do Sinal Manchester................................................................. 269
Equação A-11 – Coeficiente an do Sinal Manchester................................................................. 270
Equação A-12 – Coeficiente bn do Sinal Manchester. ............................................................... 272
Equação A-13 – Série de Fourier Completa para o Sinal Manchester. ...................................... 272
Equação B-1 – Velocidade Angular do Satélite. ........................................................................ 283
Equação B-2 – Raio do Satélite. ................................................................................................. 283
Equação B-3 – Velocidade Linear do Satélite............................................................................ 283
Equação B-4 – Altura do Satélite em Relação à Superfície da Terra. ........................................ 283
Equação B-5 – Condição Necessária para Órbitas Geoestacionárias. ........................................ 283
Equação B-6 – Velocidade Angular da Terra............................................................................. 284
Equação B-7 – Velocidade Angular do Satélite para Órbitas Geoestacionárias. ....................... 284
Equação B-8 – Massa da Terra................................................................................................... 284
Equação B-9 – Raio da Terra. .................................................................................................... 284
Equação B-10 – Constante Gravitacional Universal (G). .......................................................... 284
Equação B-11 – Altura do Satélite para uma Órbita Geoestacionária. ...................................... 284
15
Índice de Tabelas dos Capítulos
Tabela 3.1 – Funcionalidades das Camadas do Modelo OSI. ...................................................... 57
Tabela 7.1 – Relação dos primeiros 4 bits com a classe de um endereço IP. ............................... 94
Tabela 7.2 – Exemplos de Endereços IP em Binário e Notação Decimal Pontilhada.................. 94
Tabela 7.3 – Faixa de Valores do Primeiro Octeto para as Classes IP. ........................................ 95
Tabela 7.4 – Resumo das formas de endereços IP especiais. ....................................................... 98
Tabela 7.5 – Total de Redes e Hosts em cada Classe Primária. ................................................... 98
Tabela 7.6 – Significado do Campo TIPO. ................................................................................ 133
Tabela 7.7 – Valores do campo TYPE de uma mensagem ICMP.............................................. 139
Tabela 7.8 – Valores possíveis para o campo CÓDIGO. ........................................................... 141
Tabela 7.9 – Valor do campo CÓDIGO para uma mensagem de redirecionamento. ................ 144
Tabela 7.10 – Valor do campo CÓDIGO para um tempo excedido. ......................................... 144
Tabela 7.11 – Exemplos de portas UDP atualmente atribuídas. ................................................ 153
Tabela 7.12 – Bits do campo BITS DE CÓDIGO no cabeçalho TCP. ...................................... 163
Tabela 7.13 – Exemplos de números de porta TCP. .................................................................. 171
Tabela 8.1 – Um exemplo de uma tabela de tradução usada pelo NAPT. ................................. 179
Tabela 8.2 – Os domínios de Internet de nível superior e seus significados.............................. 186
Tabela 9.1 – Campos selecionados de um certificado de chave pública X.509 e RFC 1422..... 239
16
Comunicação de Dados
1.1
Conceitos básicos de Transmissão de dados
1.1.1
Sinais
Sinais são ondas que se propagam através de meios físicos diversos ou até mesmo pelo
ar. O uso de ondas para transmitir sinais remonta a eras bastante antigas. Em 1863, James
Maxwell, um professor de física da Universidade de Cambridge, demonstrou teoricamente a
existência de ondas eletromagnéticas. Em 1887, Henrich Hertz descobriu as ondas de rádio
e sua origem eletromagnética. Daí para a transmissão dos sinais foi rápido, pois em 1895
Giuglielmo Marconi inventou o rádio, transmitindo sinais através de ondas.
1.1.1.1
Sinais Analógicos e Digitais
A natureza é intrinsecamente analógica. Imagens e sons apenas podem ser
entendidos e produzidos pelo ser humano em forma analógica, uma vez que os aparelhos
auditivo e vocal produzem sinais contínuos no tempo. A vantagem dos sinais digitais
consiste na possibilidade da introdução de códigos redundantes (adicionais) para
controle de erros e também a possibilidade de compactação sem perda da qualidade do
sinal, capacidades impossíveis em sinais analógicos. Vamos entender a diferença entre
um sinal analógico e um sinal digital.
1.1.1.1.1 Sinais Analógicos
Possuem variação contínua no tempo, ou seja, seu universo de valores é
infinito, por poder ser dimensionado através de um número de casas decimais maior
ou menor de acordo com o equipamento utilizado.
Observe na Figura 1.1. Qualquer instante de tempo que deseje amostrar
possuirá um valor diferente do instante de tempo anterior e do posterior. Outro
detalhe é que este valor poderá ser medido como 1 Hz, 1,01 Hz, 1,0100001 Hz ou
qualquer número de casas decimais, conferindo a sua característica “contínua”.
Figura 1.1 – Sinal Analógico.
1.1.1.1.2 Sinais Digitais
A Figura 1.2 mostra um sinal digital. Possuem um conjunto finito de valores,
que pode variar de acordo com o número de bits que se use para codificar cada
17
amostra, mas ainda assim sempre será finito. No princípio da transmissão de dados,
a cada instante de tempo se transmitia apenas um bit, e a taxa de transmissão dos
modens era medida em bauds. Os modens atuais possuem a capacidade de codificar
mais de um bit por intervalo de tempo (dibit, tribit, etc), então usamos atualmente
para caracterizar a taxa de transmissão simplesmente bps (bits por segundo) e seus
múltiplos (Kbps, Mbps, Gbps, Tbps, Pbps, ...).
Figura 1.2 – Sinal Digital.
1.1.2
Formas de Onda
Um sinal normalmente é representado por uma forma de onda. Como as ondas são
oscilatórias, elas possuem três características básicas: amplitude, frequência e fase.
1.1.2.1
Amplitude
A amplitude representa a altura da onda desde o eixo representativo do zero até o
seu ponto mais alto. Dependendo da origem do sinal, ela pode estar associada a diversas
características, por exemplo: no caso de sinais sonoros, a amplitude está relacionada com
o volume do som; no caso de sinais luminosos, ela está associada a intensidade com que
a luz é transmitida; etc.
1.1.2.2
Frequência
Devido a natureza oscilatória das ondas, ela acaba possuindo ciclos. Um ciclo é
toda variação feita pela onda a partir de um determinado ponto até ela retornar ao mesmo
ponto de forma que a sequência seguinte seja uma repetição da anterior. A medida de
frequência é justamente a quantidade de ciclos que a onda realiza em um determinado
período de tempo, exemplo: 10 ciclos a cada minuto, 50 ciclos por hora, etc. Quando a
unidade de tempo representada para medir a quantidade de ciclos for o segundo (ciclos
por segundo), utiliza-se uma unidade especial denominada Hertz (Hz), logo, se a
frequência for por exemplo 500 Hz, significa que a onda realiza 500 ciclos a cada
segundo. Quando a frequência se torna muito grande, é comum utilizar seus múltiplos,
como por exemplo: KHz, MHz, GHz, THz, etc. A Figura 1.3 mostra um exemplo de
duas ondas com frequências diferentes.
18
Figura 1.3 – Visualização de Duas Ondas de Frequências Diferentes.
1.1.2.3
Fase
O círculo trigonométrico possui alguns eixos especiais onde dois destes eixos são
muito utilizados para a geração de ondas. São os eixos horizontal e vertical que
representam os valores do cosseno e do seno respectivamente.
Trabalhando com este círculo trigonométrico, que por definição possui raio de
valor 1, ao se representar um vetor radial de tamanho unitário cujo ângulo com o eixo
horizontal é , poderemos fazer duas projeções: uma no eixo horizontal (eixo x) e neste
caso o valor da projeção é chamado de cosseno de , e a projeção no eixo vertical (eixo
y) onde neste caso o seu valor é chamado de seno de .
Como o raio do círculo tem valor unitário, os valores destas projeções
(independente se for feita no eixo horizontal ou vertical) terá valores variando entre 1
(maior valor) e -1 (menor valor).
A Figura 1.4 ilustra um exemplo de seno e cosseno de um ângulo  no valor de
30º. Repare que a diferença entre o seno e o cosseno é que o seno começa do valor 0 e
o cosseno começa do valor 1.
Figura 1.4 – Representação do Seno e Cosseno no Círculo Trigonométrico.
Se variarmos continuamente este ângulo no tempo e fizermos um gráfico
representando os valores do seno ou do cosseno deste ângulo, teremos a representação
de uma onda denominada senoidal (no caso do seno) e cossenoidal (no caso do cosseno).
A Figura 1.5 representa uma onda senoidal variando em função do tempo. A frequência
19
utilizada no exemplo é de 1 Hz ou seja, 1 ciclo a cada segundo. A Figura 1.6 representa
uma cossenoide em função do tempo também com frequência de 1 Hz.
Figura 1.5 – Senoide em Função do Tempo.
Figura 1.6 – Cossenoide em Função do Tempo.
Neste tipo de onda, temos um ciclo de repetição que ocorre a cada 360º ou 2π
radianos. Sendo que neste caso a amplitude máxima é de 1, já que o valor do raio é
unitário, e a frequência é a quantidade de voltas completas que este vetor realiza no
círculo por unidade de tempo. Se for necessário representar uma amplitude maior do
que 1, é só multiplicar a função seno ou cosseno pela amplitude desejada, como por
exemplo: f ( )  A.sen( ) ou f ( )  A. cos( ) , onde A representa a amplitude
desejada. A Figura 1.7 representa o gráfico da função seno e a Figura 1.8 o gráfico da
função cosseno em relação ao ângulo .
O ângulo que o vetor faz em relação ao eixo horizontal é chamado de fase. Sendo
assim, quando representarmos a onda em função da fase, teremos os valores do seno e
do cosseno em relação a este ângulo.
Resumindo, a fase é o valor do ângulo formado por este vetor. Se o vetor se
movimenta continuamente no tempo, teremos a fase variando continuamente também.
20
Figura 1.7 – Senoide em Função da Fase.
Figura 1.8 – Cossenoide em Função da Fase.
1.1.3
Taxa de Transmissão Máxima de um Canal
Em 1928, H. Nyquist formulou uma equação que define a taxa de transmissão máxima
para um canal de banda passante limitada e imune a ruídos. Como veremos mais adiante,
distorções podem ocorrer durante a transmissão de um sinal por um meio físico devido a
fatores como atenuação, ruídos, etc. Alguns anos mais tarde, em 1948, Claude Shannon
estendeu os resultados de Nyquist para o caso de um canal sujeito a ruído térmico.
1.1.3.1
Teorema de Nyquist
Nyquist provou que, se um sinal arbitrário é transmitido através de um canal de
largura de banda B Hz, o sinal resultante da filtragem pode ser completamente
reconstruído pelo receptor através da amostragem do sinal transmitido, a uma frequência
igual a no mínimo 2B vezes por segundo. Nyquist demonstrou que esta é a frequência
mínima de amostragem necessária e, ao mesmo tempo, amostrar esse sinal a uma
frequência maior que 2B é inútil, já que as frequências componentes que seriam
recuperadas por tal amostragem já não existem no sinal devido à filtragem do canal.
Para sinais digitais, isso corresponde a dizer que o número de transições de um nível de
amplitude para outro no sinal original não pode ser maior do que 2B vezes por segundo.
A quantidade de transições de amplitudes é chamada de baud. Em outras palavras,
através de um canal de largura de banda igual a B Hz, pode-se transmitir um sinal digital
de no máximo 2B bauds. Como 1 baud  log2 L bps (onde L é o número de níveis
21
utilizados na codificação), então a capacidade D do canal na ausência de ruído é dada
por:
D  2B log2 L bps
Essa é a fórmula obtida por Nyquist para a capacidade máxima de um canal dada
a sua banda passante, na ausência de ruído.
1.1.4
Fontes de Distorção de Sinais em Transmissão
Além dos efeitos de distorção dos sinais transmitidos oriundos da banda passante
limitada do meio físico, outros fatores causarão distorções nos sinais durante a transmissão.
Entre eles encontramos: os ruídos presentes durante a transmissão, a atenuação e os ecos.
Passemos a analisar cada um desses fatores, seus principais efeitos e a forma de contornálos.
1.1.4.1
Ruídos
Em qualquer transmissão, o sinal recebido consiste no sinal transmitido
modificado por várias distorções inseridas durante a transmissão devido à interferência
de sinais indesejáveis denominados ruídos. O ruído é um dos maiores limitantes do
desempenho de sistemas de comunicação.
A quantidade de ruído presente numa transmissão é medida em termos da razão
entre a potência do sinal e a potência do ruído, denominado relação sinal-ruído. Se
representarmos a potência do sinal por S e a potência do ruído por N, a relação sinalruído é dada por S/N. É muito comum utilizar-se, ao invés desta razão diretamente, o
valor 10 log10 (S/N) . O resultado obtido é uma medida da relação sinal-ruído em uma
unidade denominada decibel (dB). Uma relação de 10 corresponde a 10 dB; uma relação
de 100 corresponde a 20 dB; uma relação de 1.000 corresponde a 30 dB e assim por
diante.
Ruídos podem ser classificados em quatro tipos: ruído térmico, ruído de
intermodulação, crosstalk (linha cruzada) e ruído impulsivo.
1.1.4.1.1 Ruído Térmico
O ruído térmico é uniformemente distribuído em todas as frequências do
espectro (sendo por isso frequentemente citado como ruído branco) e sua
quantidade é função da temperatura.
1.1.4.1.2 Ruído de Intermodulação
Quando sinais de diferentes frequências compartilham um mesmo meio
físico, pode-se obter um ruído denominado de ruído de intermodulação. A
intermodulação pode causar a produção de sinais em uma faixa de frequências, que
poderão perturbar a transmissão de outro sinal naquela mesma faixa. Este mau
funcionamento acontece devido a defeitos em componentes do sistema ou devido a
sinais com potência muito alta.
1.1.4.1.3 Ruído de Crosstalk (Linha Cruzada)
Crosstalk é um ruído bastante comum em sistemas telefônicos. Quem de nós
ainda não teve a experiência de ser perturbado, durante uma conversação telefônica,
por uma conversação travada por terceiros? É o fenômeno que comumente
chamamos de “linha cruzada”. Este efeito é provocado por uma interferência
indesejável entre condutores próximos que induzem sinais entre si.
22
1.1.4.1.4 Ruído Impulsivo
Os tipos de ruído descritos até aqui tem magnitudes e características
previsíveis de forma que é possível projetar sistemas de comunicação que se
ajustem a essas características. O ruído impulsivo, porém, é não contínuo e consiste
em pulsos irregulares e com grandes amplitudes, sendo de prevenção difícil. Tais
ruídos podem ser provocados por diversas fontes, incluindo distúrbios elétricos
externos, falhas nos equipamentos etc.
O ruído impulsivo é, em geral, pouco danoso em uma transmissão analógica.
Em transmissões de voz, por exemplo, pequenos intervalos onde o sinal é
corrompido não chegam a prejudicar a inteligibilidade dos interlocutores. Na
transmissão digital, o ruído impulsivo é a maior causa de erros de comunicação.
1.1.4.1.5 Lei de Shannon
Vinte anos depois de Nyquist, Shannon provou, também matematicamente,
que um canal tem uma capacidade máxima limitada. A parte mais interessante de
seu trabalho discute canais na presença de ruído térmico.
O principal resultado de Shannon (conhecido como a Lei de Shannon) afirma
que a capacidade máxima Dmax de um canal em bits por segundo (bps) cuja largura
de banda é B Hz, e cuja relação sinal-ruído é S/N, é dada por:
D max  B log2 1  S/N 
Um canal de 3.000 Hz (3 KHz), por exemplo, com uma relação sinal-ruído
de 30 dB (parâmetros típicos de uma linha telefônica) não poderá, em hipótese
alguma, transmitir a uma taxa maior do que 30.000 bps (30 Kbps), não importando
quantos níveis de sinal se utilizem ou qual a frequência de sinalização. É importante
notar que este é um limite máximo teórico, e que, na prática, é difícil até mesmo se
aproximar deste valor. Muito embora vários esquemas tenham sido propostos, a lei
de Shannon constitui-se um limite máximo intransponível.
1.1.4.2
Atenuações
A potência de um sinal cai com a distância, em qualquer meio físico. Essa
atenuação é, em geral, logarítmica e por isso é geralmente expressa em um número
constante em decibéis por unidade de comprimento. A atenuação se dá devido a perdas
de energia por calor e por irradiação. Em ambos os casos, quanto maiores as frequências
transmitidas, maiores as perdas. A distorção por atenuação é um problema facilmente
contornado em transmissão digital através da colocação de repetidores que podem
regenerar totalmente o sinal original, desde que a atenuação não ultrapasse um
determinado valor máximo. Para tanto, o espaçamento dos repetidores não deve exceder
um determinado limite, que varia de acordo com a característica de atenuação do meio
físico utilizado.
1.1.4.3
Ecos
Ecos em linhas de transmissão causam efeitos similares ao ruído. Toda vez que
há uma mudança de impedância (resistência oferecida aos sinais oscilatórios) numa
linha, sinais serão refletidos e voltarão por esta linha, podendo corromper os sinais que
estão sendo transmitidos.
Precauções para que a impedância de uma linha de transmissão não seja alterada
podem ser tomadas para evitar a reflexão dos sinais. A utilização de terminadores e
transceptores de alta impedância é um exemplo para evitar o eco em redes em barra.
23
Em sistemas telefônicos, os ecos podem ser bastante desagradáveis quando
percebidos em intervalos maiores que dezenas de milissegundos. Nesses sistemas é
comum a utilização de canceladores de eco nos pontos onde é inevitável a alteração da
impedância.
1.1.5
Técnicas de Modulação
Todas as técnicas de modulação envolvem o deslocamento do sinal original, doravante
denominado sinal modulador ou modulante, de sua faixa de frequências original para uma
outra faixa. O valor desse deslocamento corresponde à frequência de uma onda denominada
portadora. Toda onda possui três características básicas explicadas anteriormente:
amplitude, frequência e fase. Quando se modula uma portadora, uma destas características
será modificada em função do sinal para que o destinatário possa, através da verificação da
característica usada na modulação, recuperar o sinal original.
O sinal modulador pode ser do tipo Analógico ou Digital levando a duas categorias de
modulação: a modulação analógica e a modulação digital.
1.1.5.1
Modulação Analógica
A modulação é chamada de analógica quando o sinal modulador for do tipo
analógico. Existem três técnicas básicas de modulação analógica, como mostra a
Figura 1.9.

Modulação por Amplitude (Amplitude Modulation – AM);

Modulação por Frequência (Frequency Modulation – FM);

Modulação por Fase (Phase Modulation – PM).
Figura 1.9 – Exemplo de Modulação Analógica.
1.1.5.1.1 Modulação por Amplitude (AM)
Na modulação por amplitude, a portadora terá a sua amplitude sendo
modificada em função do sinal modulador. Neste caso, quando o sinal modulador
aumenta em amplitude, a portadora também aumentará e quando o sinal modulador
diminuir de amplitude, a amplitude da portadora também será diminuída. Um
cuidado importante a ser tomado é quanto a amplitude mínima da portadora. Se ela
ficar inferior a capacidade do receptor em identificá-la, o sinal será perdido.
24
1.1.5.1.2 Modulação por Frequência (FM)
Na modulação por frequência, a portadora terá a sua frequência variando em
função do sinal modulador. Quando o sinal modulador aumenta em amplitude, a
frequência da portadora será aumentada e quando o sinal diminuir de amplitude a
frequência da portadora será diminuída. A aparência da portadora modulada fica
semelhante a um efeito de sanfona. Tal como no caso anterior, o aparelho receptor
analisará a variação na frequência da portadora e assim reproduzirá o sinal original.
1.1.5.1.3 Modulação por Fase (PM)
Na modulação por fase, a portadora terá a variação da sua fase modificada em
função do sinal modulador. Conforme o sinal vai aumentando de amplitude, a
velocidade com que a fase varia também aumenta, enquanto que quando o sinal
diminui em amplitude, a velocidade com que a fase varia também é reduzida. Neste
caso a portadora modulada também possui a aparência do efeito sanfona, mas a
forma como este efeito é aplicado torna a onda modulada por fase diferente da onda
modulada por frequência. O aparelho receptor, verificando a variação na
velocidade com que a fase varia, ele é capaz de recuperar o sinal original.
1.1.5.2
Modulação Digital
No caso específico do sinal modulador ser um sinal digital, utilizam-se as mesmas
técnicas apresentadas anteriormente, só que neste caso mudam-se as denominações.

Modulação por Deslocamento de Amplitude (Amplitude Shift Keying –
ASK);

Modulação por Deslocamento de Frequência (Frequency Shift Keying –
FSK);

Modulação por Deslocamento de Fase (Phase Shift Keying – PSK).
A Figura 1.10 mostra um exemplo de modulação digital.
Figura 1.10 – Exemplo de Modulação Digital.
1.1.5.2.1 Modulação por Deslocamento de Amplitude (ASK)
Na técnica ASK, a amplitude do sinal resultante da modulação varia de
acordo com a amplitude do sinal que se quer modular, mantendo-se a frequência da
onda portadora constante. Diferente da modulação analógica, só existirão duas
25
amplitudes. Uma referente à modulação do valor um e outra referente ao valor zero.
No caso do valor zero, a amplitude é reduzida a ponto de não haver mais a
portadora, sendo visto como silêncio na transmissão.
1.1.5.2.2 Modulação por Deslocamento de Frequência (FSK)
Na técnica FSK, mantém-se a amplitude da portadora constante. O que varia
é a frequência de acordo com o sinal transmitido. Semelhante a técnica anterior, só
existirão duas frequências diferentes. Um referente à modulação do valor um e
outra referente à modulação do valor zero.
1.1.5.2.3 Modulação por Deslocamento de Fase (PSK)
Na técnica PSK, a transmissão do sinal é identificada por modificações na
fase da onda transmitida. A amplitude e a frequência da onda portadora são
mantidas constantes. No exemplo da Figura 1.10, quando existe a alternância entre
o bit 0 e o bit 1, a fase da portadora é deslocada de 180º.
1.1.6
Comutação
Comutação é a tradução literal de switching, que em português significa “chavear”.
Esse chaveamento é a decisão sobre que caminho despachar a unidade de informação. Essa
função pode ser realizada por comutadores (switches), como os Ethernet e ATM, ou, num
nível mais alto, por roteadores. Esses últimos, na verdade, são chamados de roteadores
porque executam uma estratégia qualquer para a escolha da rota a ser usada para despachar
o pacote, para em seguida comutá-lo através da rede. A função de comutação em uma rede
também se refere à alocação de recursos para a transmissão pelos diversos dispositivos
conectados. A seguir, serão apresentadas as técnicas de comutação existentes.
1.1.6.1
Circuitos
A comunicação via comutação de circuitos pressupõe a existência de um caminho
dedicado entre as estações comunicantes. É usada nas comunicações telefônicas, por
exemplo. A Figura 1.11 ilustra uma comunicação via circuitos chaveados (comutados).
No estabelecimento da conexão, um circuito é destinado para existir durante toda a
comunicação, esteja ela usando o meio ou não. Esse circuito só é desfeito após o
procedimento de desconexão.
Figura 1.11 – Comutação de Circuito.
A Figura 1.12 ilustra a progressão da comunicação entre duas estações. No
estabelecimento da conexão, uma mensagem de controle é enviada ao destino.
Conforme ela vai sendo roteada, um caminho vai sendo alocado. Quando ela atinge seu
destino, uma mensagem de controle de confirmação é enviada pelo destino, já usando o
canal alocado, sem processamento nos nós intermediários. A comunicação entre as
26
estações então é possível, até que uma delas encerre a conexão. A mensagem de
desconexão vai provocando a liberação do circuito nos nós intermediários.
Figura 1.12 – Comutação por Circuito ao Longo do Tempo.
Problemas: como o caminho fica dedicado às estações, mesmo que o tráfego não
seja constante e contínuo, há grande desperdício da capacidade de transmissão do meio.
Isso é visível quando usamos a linha telefônica com modens dial-up para acessar
Internet. Pagamos um valor de acordo com o tempo de utilização, e não pelos bytes
transmitidos e recebidos, porque o circuito estabelecido estará à nossa disposição
durante toda a conexão, independentemente de o usarmos ou não.
Obs.: o caminho entre origem e destino pode ser:

Um caminho físico, com enlaces físicos;

Uma sucessão de canais de frequência alocados em cada enlace (FDM);

Uma sucessão de canais de tempo alocados em cada enlace (TDM Síncrono),
ou seja, a técnica de comutação não implica diretamente em uma ou outra
técnica de multiplexação.
A comutação de circuitos é bastante utilizada em sistemas telefônicos com certas
vantagens, porque o tráfego de voz é tipicamente constante e contínuo. Os PBXs usam
esse sistema.
Nos primeiros sistemas o chaveamento era manual; depois, com os relés, passou a
ser automática; posteriormente, passaram a ser multiplexadas na frequência, e mais
recentemente, com a introdução das centrais digitais, multiplexados no tempo. Mais
adiante veremos estas técnicas de multiplexação.
Como conclusões, temos que o retardo é determinístico, pois o meio não é
compartilhado, facilitando a recuperação do sinal. Mas o uso inadequado do meio pode
provocar indisponibilidade de recursos para o estabelecimento dos circuitos. É mais
adequado para tráfego contínuo, como voz, mas péssimo para o tráfego de dados
27
(rajadas), porque não há como exceder o limite do canal para a transmissão de um pico
de transmissão, havendo o desperdício durante os períodos de silêncio.
1.1.6.2
Mensagens
Em função das características inadequadas da comutação de circuitos para o
tráfego de dados, surgiu a comutação de mensagens, ilustrado na Figura 1.13. Na
comutação de mensagens, não é necessário o estabelecimento de um caminho dedicado,
mas passa a ser necessário um esquema de endereçamento, para que a mensagem possa
ser roteada. Este é o sistema store-and-forward (primeiro armazenar para depois
encaminhar). Somente após o completo armazenamento local da mensagem é que a
mesma será despachada para o próximo nó de comutação.
Obs.: esse caminho pode se encontrar ocupado recebendo outras mensagens, e
ainda outras mensagens podem estar aguardando para serem transmitidas, sendo
necessário o estabelecimento de uma fila, tipicamente FIFO (first IN, first OUT).
O aproveitamento das linhas é maior, já que os canais podem ser plenamente
compartilhados por várias mensagens ao longo do tempo. As mensagens são sempre
transmitidas sob demanda.
Quando o tráfego se torna muito intenso, diferentemente de uma rede de
comutação por circuitos, onde a conexão é recusada, na comutação por mensagens a
mesma é sempre aceita e colocada em uma fila para retransmissão ao próximo nó.
Observe que há um gap (intervalo) entre as mensagens. Isso simboliza o retardo
provocado pela inserção da mensagem em uma fila, mais o tempo de processamento, ou
seja, de escolha de rota.
O ganho a considerar aqui é a economia de meios com os possíveis atrasos na
entrega das mensagens, em relação à comutação por circuitos.
Figura 1.13 – Comutação por Mensagem ao Longo do Tempo.
1.1.6.3
Pacotes
Para otimizar o esquema da comutação de mensagens, criou-se a comutação de
pacotes, cuja diferença básica é que as mensagens são divididas em pedaços de tamanho
ainda variável (como nas mensagens), porém com um limite máximo definido (pacotes).
28
A Figura 1.14 mostra um exemplo de comutação por pacote enquanto que a Figura 1.15
mostra como acontece ao longo do tempo. Pacotes de uma mesma mensagem podem
estar simultaneamente trafegando numa rede, e ainda por cima possivelmente por
caminhos diferentes (na modalidade datagrama), sendo muito comum a recepção dos
mesmos desordenados. Isso reduz sobremaneira o atraso da rede de comutação de
mensagens, além de exigir menor capacidade de armazenamento (memória) dos nós
intermediários. Também facilita a recuperação de erros pela retransmissão apenas do
pacote danificado, ao invés de toda a mensagem. Pode ser do tipo circuito virtual ou
datagrama, em função do estabelecimento ou não de uma determinada rota para
transmissão dos pacotes.
Figura 1.14 – Comutação por Pacote.
1.1.6.3.1 Comutação de Pacotes – Circuito Virtual
A modalidade de Comutação por Pacotes através de circuitos virtuais é
parecida com a Comutação por Circuitos comum, com a diferença fundamental de
que o meio pode (e normalmente é) compartilhado. O que não muda é a rota. Os
pacotes, neste caso, sempre chegam na sequência em que foram enviados. Nesse
caso, há o overhead (sobrecarga) das mensagens de controle para estabelecimento
da rota e seu desestabelecimento posterior. A vantagem é o compartilhamento do
meio, com alocação de recursos em cada nó de comutação.
1.1.6.3.2 Comutação de Pacotes – Datagrama
Na modalidade datagrama, há a grande vantagem de reduzir o overhead para
estabelecer rotas prévias, além de possibilitar um maior volume de dados de uma
mesma transmissão simultaneamente, pois permite a presença de vários pacotes no
meio de transmissão, já que os pacotes podem trafegar por caminhos diferentes.
Devido a isso, são necessárias informações de controle no cabeçalho para o
roteamento particularizado de cada datagrama nos vários nós de comutação, além
de um mecanismo de reordenação de pacotes no destino, já que devido a
possibilidade dos datagramas percorrerem caminhos diferentes, eles poderão
chegar fora de ordem.
29
Figura 1.15 – Comutação por Pacote ao Longo do Tempo.
1.1.6.4
Células
A comutação de células é um caso particular da comutação de pacotes, modalidade
circuitos, onde todos os pacotes possuem tamanhos fixos (53 bytes). Seu tamanho
diminuto permite grande velocidade na comutação, e o fato de ser fixo permite que as
verificações de erro sejam feitas por hardware, com velocidades muito superiores ao
convencional. A tecnologia ATM, que será vista adiante, implementa a comutação de
células. Backbones de alta velocidade vem implementando essa técnica, capaz de
oferecer taxas de 155 Mbps a 10 Gbps, sem a necessidade de grandes alterações de
arquitetura, como ocorre no padrão Ethernet, por exemplo.
1.1.7
Forma de Comunicação
A comunicação por um determinado meio pode acontecer de três formas diferente:
simplex, half-duplex e full-duplex.
1.1.8

Simplex: neste tipo de comunicação, o meio permite a veiculação da
informação em apenas um único sentido como por exemplo, as
transmissões de TV, Rádio e alguns pagers.

Half-Duplex: neste tipo de comunicação, o meio permite a
veiculação da informação nos dois sentidos, porém, elas não
podem ocorrer simultaneamente. Exemplo: Walktalk.

Full-Duplex: neste tipo de comunicação, o meio permite a
veiculação da informação nos dois sentidos simultaneamente,
como por exemplo, ligações telefônicas.
Multiplexação
Sempre que a banda passante de um meio físico for maior ou igual à banda passante
necessária para um sinal, podemos utilizar este meio para a transmissão do sinal. Na prática,
a banda passante necessária para um sinal é, em geral, bem menor do que a banda passante
dos meios físicos disponíveis, como mostra a Figura 1.16.
30
Figura 1.16 – Desperdício de Banda Passante do Meio Físico.
A pergunta natural a se fazer neste momento é: não seria possível aproveitar a banda
extra disponível para a transmissão de outros sinais? Vamos supor a existência de três sinais
(C0, C1 e C2) com a banda passante necessária indicada na Figura 1.17, não seria possível
transmiti-los simultaneamente através de um mesmo meio físico como mostrado nesta
mesma figura? A resposta a essa pergunta é sim, e a técnica que permite a transmissão de
mais de um sinal em um mesmo meio físico é denominada multiplexação. Existem duas
formas básicas de multiplexação:

Multiplexação na Frequência (Frequency Division Multiplexing – FDM);

Multiplexação no Tempo (Time Division Multiplexing – TDM).
Figura 1.17 – Multiplexação na Frequência (FDM).
1.1.8.1
Multiplexação na Frequência
Em primeiro lugar, se passarmos um filtro em cada um dos sinais da Figura 1.17
de forma a preservar somente a faixa relativa à banda passante necessária de cada um
deles, teremos dado o primeiro passo para alojar esses três sinais na forma desejada, sem
que um sinal interfira no outro. O passo seguinte é deslocar a faixa de frequências
original do segundo e do terceiro sinal de forma que eles passem a ocupar as três faixas
disjuntas, sem sobreposição. Como vimos anteriormente, a técnica de modulação
permite esse deslocamento de frequência. Dessa forma, os três sinais podem ser
transmitidos no meio físico, cada um deles ocupando uma banda ou canal distinto com
tamanho necessário para a sua transmissão. Como os sinais foram previamente filtrados
de acordo com a sua banda passante necessária, a informação de cada um deles está
preservada e contida naquela faixa de frequência na qual está sendo transmitido e em
nenhuma outra.
Considere o exemplo ilustrado na Figura 1.18. Nessa figura, estão representados
três sinais de voz através de seus espectros. Um dos sinais foi modulado para a
frequência de 4 KHz à 8 KHz e um outro foi modulado para a frequência de 8 KHz à
12 KHz. Os sinais são passados por filtros de forma a impedir que existam componentes
em outras frequências que não a faixa a eles reservadas, faixas estas de tamanho igual a
31
4 KHz. Note que mencionamos anteriormente que a banda passante necessária para um
sinal de voz tem uma largura de 3 KHz, portanto, 4 KHz é mais do que suficiente para
a transmissão desses sinais. Após terem sido filtrados, esses sinais podem trafegar
simultaneamente pelo meio físico.
Figura 1.18 – Exemplo de Multiplexação na Frequência de três Sinais de Voz.
Um receptor que deseje recuperar um dos sinais transmitidos numa linha
multiplexada na frequência, deverá conhecer a faixa de frequências que está sendo
utilizada para a sua transmissão. Dessa forma, ele poderá deslocar o sinal recebido de
forma a fazer o sinal desejado ocupar novamente a sua faixa original (de 0 a n Hz). O
sinal demodulado pode a seguir ser filtrado para conter somente o sinal original. A
Figura 1.19 ilustra o processo de transmissão em uma linha multiplexada na frequência.
Equipamentos capazes de realizar modulações e demodulações de sinais são
denominados MODEMs (MOduladores/DEModuladores).
Figura 1.19 – Transmissão em uma Linha Multiplexada na Frequência.
32
1.1.8.2
Multiplexação no Tempo
A Multiplexação por divisão do tempo se beneficia do fato de que a capacidade
(em bits por segundo) do meio de transmissão, em muitos casos, excede a taxa média de
geração de bits das estações conectadas ao meio físico. Quando isso ocorre, vários sinais
podem ser transportados por um único caminho físico, intercalando-se porções de cada
sinal no tempo. A multiplexação no tempo pode ser classificada em síncrona ou
assíncrona.
1.1.8.2.1 TDM Síncrono
No TDM síncrono (ou simplesmente TDM), o domínio do tempo é dividido
em intervalos de tamanho fixo T chamados frames; cada frame é subdividido em N
subintervalos {t1, t2, ..., tn} denominados slots ou segmentos que formam uma
partição dos frames que, por sua vez, formam uma partição do tempo infinito, como
mostra a Figura 1.20.
Figura 1.20 – TDM Síncrono.
Denomina-se canal, ao conjunto de todos os slots, um em cada frame,
identificados por uma determinada posição fixa dentro desses frames. Por exemplo,
o canal 3 é forma pelo terceiro slot de cada frame. Canais podem ser alocados a
estações que desejem transmitir. Cada estação deverá esperar o slot correspondente
dentro de cada frame, quando então poderá transmitir durante o tempo daquele slot,
utilizando a taxa de transmissão máxima suportada pelo meio físico.
Da mesma forma que alocamos canais de frequências em redes utilizando
FDM, em redes que utilizam TDM, os canais devem ser alocados às diferentes
fontes de transmissão ou estações. Se a alocação de um determinado canal é fixa
durante todo o tempo e preestabelecida antes do funcionamento da rede, então temse um canal dedicado.
Canais também podem ser alocados e desalocados dinamicamente durante o
funcionamento da rede. Nesse caso, esses canais são denominados canais
chaveados, de forma análoga à nossa definição para redes em banda larga. Uma
estação, ao alocar um canal chaveado, pode transmitir neste canal pelo tempo que
desejar. Quando não desejar mais o monopólio do canal, a estação o devolve à
controladora do sistema, que agora pode alocá-lo a outras estações. Este esquema
de alocação é sempre utilizado quer o canal seja ponto a ponto ou multiponto.
No TDM síncrono com canais chaveados, quando um canal é alocado,
estabelece-se uma conexão que permanece dedicada à estação transmissora até o
momento em que ela resolva desfazê-la. Essa forma de chaveamento é denominada
chaveamento de circuitos, como foi visto na Seção 1.1.6.1. Note que quando uma
estação que alocou um canal não estiver transmitindo (ou a taxa de transmissão for
33
menor do que a taxa assegurada pelo canal), tem-se um desperdício de capacidade
do meio físico, já que o canal alocado não pode ser utilizado por qualquer outra
estação até o momento da desconexão como mostra a Figura 1.21.
Figura 1.21 – Desperdício de Capacidade com TDM Síncrono.
1.1.8.2.2 TDM Assíncrono
Uma alternativa ao TDM síncrono que procura eliminar o desperdício da
capacidade existente nesse esquema é o TDM assíncrono (também conhecido por
TDM estatístico ou STDM – Statistical TDM). Nesse esquema, não há alocação
de canal nem estabelecimento de conexão. Parcelas de tempo são alocadas
dinamicamente de acordo com a demanda das estações. Nenhuma capacidade é
desperdiçada, pois o tempo não utilizado está sempre disponível caso alguma
estação gere tráfego e deseje utilizar o canal de transmissão. Em compensação, no
TDM assíncrono, cada unidade de informação transmitida deve sempre conter um
cabeçalho com os endereços de origem e de destino como mostra a Figura 1.22. No
TDM síncrono, cada canal já identifica o transmissor. Em canais ponto a ponto
com TDM síncrono, esse cabeçalho é totalmente desnecessário já que o receptor
também é identificado pela conexão.
34
Figura 1.22 – TDM Assíncrono.
Não havendo a noção de conexão dedicada, o canal é sempre compartilhado
no tempo por todas as estações a ele conectadas, sendo o acesso definido como
assíncrono.
1.1.8.3
Características do FDM e do TDM
Como vimos na Multiplexação por Divisão de Frequência (FDM), a utilização da
modulação é necessária para deslocar os sinais originais para outra faixa de frequência.
A filtragem dos sinais permite o compartilhamento do mesmo meio físico sem que um
sinal interfira nas faixas de frequências adjacentes que carregam outros sinais. Os
resultados da modulação de sinais foram apresentados na Figura 1.9 e na Figura 1.10.
Nota-se que os sinais digitais são transformados em sinais analógicos e, por esse motivo,
é comum associarmos os sistemas de banda larga à transmissão analógica.
Já em esquemas que utilizam Multiplexação por Divisão do Tempo (TDM), os
sinais são transmitidos em banda básica, sendo portanto, sinais digitais. Assim, associase TDM à transmissão digital.
Como já havíamos mencionado, a transmissão digital oferece vantagens sobre a
analógica principalmente no que diz respeito à recuperação dos sinais na presença de
ruídos. Sinais, em transmissão digital podem ser regenerados através de repetidores que
não propagam ruídos. Além disso, é possível implementar esquemas de detecção e
correção de erros que estudaremos mais adiante.
1.1.8.4
Sistemas em Banda Larga e em Banda Básica
As técnicas de transmissão estão diretamente relacionadas com as técnicas de
multiplexação. Duas técnicas de transmissão são as mais empregadas: a sinalização em
banda básica e a sinalização em banda larga.
35
1.1.8.4.1 Sinalização em Banda Básica
Na sinalização em banda básica, o sinal é simplesmente colocado na rede sem
se usar qualquer tipo de modulação, aparecendo diretamente na rede e não como
deslocamento de frequência, fase ou amplitude de uma portadora de alta frequência.
A sinalização em banda básica vem sendo adotada nos projetos de redes por
não necessitar de modems e por possibilitar a transmissão em alta velocidade, sendo
utilizada a técnica de multiplexação TDM. Para transmissões a longas distâncias,
certas precauções devem ser tomadas. A técnica também não é adequada a circuitos
que estão sujeitos a ruídos, interferências e erros aleatórios. No ambiente restrito
das redes locais, contudo, a sinalização em banda básica, em geral, é adequada.
1.1.8.4.2 Sinalização em Banda Larga
Ao contrário da sinalização em banda básica, na qual toda a banda de
frequência do meio é utilizada para produzir o sinal, a sinalização em banda larga
realiza a multiplexação em frequência (FDM). Com essa multiplexação, o espectro
de frequências do meio é dividido em vários canais, cada um podendo suportar
diferentes tráfegos.
A sinalização em banda larga é geralmente utilizada em redes locais em barra.
Sua utilização numa topologia em anel é problemática, pois exigiria que cada
repetidor fosse capaz de receber e retransmitir dados nos múltiplos canais. O custo
de dispositivos para a realização desta tarefa tornaria a rede inviável.
1.1.9
Digitalização de um Sinal pela Técnica PCM
Nas seções anteriores, examinamos a codificação de informações digitais por sinais
analógicos através de processos que denominamos de modulação. Essa técnica é necessária
quando desejamos empregar multiplexação na frequência (FDM) em redes em banda larga,
ou quando necessitamos ajustar a faixa de frequências do sinal para transmissão em um canal
específico com características próprias (como é o caso da transmissão de dados via linhas
telefônicas).
Fora os casos citados anteriormente, a transmissão digital é, em geral, mais vantajosa
do que a analógica devido, principalmente, à possibilidade de restaurarmos o sinal original
mesmo na presença de falhas ou ruídos no sistema. A transmissão digital vem substituindo
a analógica sempre que possível, inclusive na própria rede telefônica, com a instalação de
novas centrais e cabos de fibra óptica.
A informação de voz é originalmente analógica. Para utilizarmos as vantagens da
transmissão digital, devemos codificá-la em um sinal digital antes da transmissão. Os
dispositivos capazes de codificar informações analógicas em sinais digitais são denominados
CODECs (CODer/DECoder). Nesta seção examinaremos a principal técnica utilizada por
CODECs, denominada PCM (Pulse Code Modulation – Modulação por Código de Pulso).
A técnica PCM é baseada no teorema de Nyquist (ou teorema da amostragem)
apresentado na Seção 1.1.3.1. O teorema assegura que uma taxa de amostragem duas vezes
superior que a largura de banda do sinal (B) é suficiente para recuperar este sinal. Utilizando
uma taxa de amostragem maior ou igual a 2B, o sinal original deve ser amostrado e, a cada
amostra, deve-se associar um valor proporcional à amplitude do sinal naquele ponto. Este
processo é conhecido como PAM (Pulse Amplitude Modulation – Modulação por Amplitude
de Pulso).
36
A partir dos pulsos PAM, podemos produzir os pulsos PCM através de um processo
conhecido como quantização, onde cada amostra PAM é aproximada a um inteiro de n bits.
No exemplo da Figura 1.23, escolhemos n  3 , dando origem a oito níveis (23). A saída
PCM corresponde ao resultado dessa quantização.
Podemos calcular, a partir desse processo, a taxa gerada pela transmissão de
informações analógicas através de sinais digitais. Considere o caso de sinais de voz, por
exemplo. Se assumirmos que a banda passante necessária desses sinais tem largura igual a
4.000 Hz (4 KHz), a taxa de amostragem de Nyquist é, neste caso, igual a 8.000 amostras por
segundo. Se escolhermos essa taxa e codificarmos cada amostra com oito bits, a taxa gerada
será 8.000  8  64 Kbps .
Figura 1.23 – Digitalização de um Sinal (PCM).
1.1.10 Codificação e Transmissão de Sinais Digitais em Banda Básica
A codificação de sinais em banda básica mais conhecida é denominada codificação
NRZ (Non Return to Zero), onde há a presença de dois níveis de tensão ou corrente, cada
qual representando um dos dois símbolos digitais (0 ou 1). Temos utilizado até agora, em
nossos exemplos, esse tipo de codificação, por se tratar do mais simples. Já observamos que,
37
neste esquema, definimos um intervalo de sinalização, durante o qual o sinal permanece
inalterado de forma a caracterizar o bit transmitido, como mostra a Figura 1.24. O receptor
deve procurar amostrar o sinal recebido no meio deste intervalo, onde o sinal já se encontra
estável, de forma a reconhecer o nível de tensão ou corrente correto, e recuperar a informação,
como mostra a Figura 1.25.
Figura 1.24 – Codificação NRZ.
Para uma amostragem correta, receptor e transmissor precisam ter seus clocks
(relógios) sincronizados em frequência e fase. As diferenças de fase e frequência entre os
clocks do transmissor e do receptor são, em geral, difíceis de resolver. O problema da
frequência envolve a utilização de osciladores com frequências idênticas que, na prática, são
difíceis de conseguir.
Figura 1.25 – Recuperação de um Sinal NRZ.
A diferença de fase envolve outros fatores ainda mais incontroláveis, como por
exemplo, o instante em que são disparados os circuitos osciladores de transmissão e recepção.
Podem-se adotar duas estratégias básicas para lidar com esse problema de sincronismo dos
clocks, que determinam as duas formas básicas de transmissão: a transmissão assíncrona e a
transmissão síncrona.
1.1.10.1 Transmissão Assíncrona
Na transmissão assíncrona, admite-se que a referência de tempo de transmissor e
receptor não é única, apenas próxima, e tenta-se lidar com essas diferenças. A técnica
de codificação de dados utilizada nesta solução é usualmente a NRZ e para que haja o
sincronismo nas fases do clock do transmissor e do receptor, no início de uma
transmissão de dados é enviado um sinal de início (start bit) e logo em seguida enviado
o sinal com os dados. Como existe a diferença na frequência, o sincronismo não poderá
ser mantido por muito tempo, levando a uma limitação no tamanho dos dados enviados
que variam de 5 a 8 bits. Ao final desta sequência, é enviado um sinal de parada (stop
bit) para indicar ao receptor que pare o seu clock e aguarde uma nova transmissão através
de um start bit como mostra a Figura 1.26.
38
Figura 1.26 – Exemplo de Transmissão Assíncrona.
Detalhando um pouco mais o funcionamento da transmissão assíncrona, no
receptor utiliza-se um oscilador com uma frequência múltipla, digamos n vezes maior
que a frequência do oscilador do transmissor. Sendo fr e ft as frequências dos clocks de
recepção e transmissão, e Tr e Tt os respectivos períodos de cada clock, podemos
escrever:
f r  nf t
Como temos a relação entre frequência e período dada por: T 
1
, podemos
F
escrever que:
Tr 
1
fr
Tr 
1
nf t
Como f t 
Tr 
1
1
n
Tt
Tr 
Tt
n
1
temos que:
Tt
Detectado o início de uma recepção, a amostragem se fará depois de passados n 2
pulsos de clock do receptor. Admitindo que a frequência de oscilação do receptor tenha
um erro de precisão, esta não será maior do que uma fração de um período, ou seja, a
defasagem que pode ser introduzida não ultrapassa o intervalo Tt n , podendo essa
defasagem ser, teoricamente, reduzida o quanto se queira, bastando para isso
aumentarmos o valor de n.
Note, porém, que mesmo pequenas defasagens, após um intervalo grande de
transmissão, irão se acumular provocando o afastamento do instante de amostragem do
centro do intervalo de sinalização, se fr não for exatamente igual a nft. Por esse motivo,
a transmissão assíncrona é orientada à transmissão de caracteres que são pequenas
unidades de dados que variam, em geral, entre 5 e 8 bits, como foi comentado
anteriormente, de forma a não permitir longas sequências de bits.
39
Para o funcionamento correto da recepção, precisamos de um mecanismo que
permita a detecção precisa do início da recepção de um caracter, uma vez que não
queremos aí introduzir um erro de fase. De posse desse mecanismo, a cada caracter
teremos anulado toda a defasagem que por ventura tenha se acumulado no caracter
anterior, pois começamos a marcar novamente o meio dos bits, a partir do início do
primeiro bit do caracter corrente. Por esse motivo, a transmissão assíncrona será
caracterizada pela transmissão de caracteres delimitados por bits especiais denominados
start bit e stop bit, conforme mostra a Figura 1.26.
O start bit marca o início da transmissão de um caracter. O start bit deve sempre
apresentar uma transição inicial de 1 para 0 de forma a marcar bem a sua presença e
permitir o disparo da contagem no oscilador de recepção, que deve contar n 2 pulsos
para chegar ao instante de amostragem. Após o start bit, segue-se o caracter, e mais um
bit opcional de paridade utilizado em determinados esquemas de detecção de erros que
será apresentado na Seção 1.1.11.1. Por fim, um stop bit é colocado para marcar o fim
do caracter, permitindo que o receptor tenha um intervalo de tempo para ter acesso ao
seu registro de recepção, e também para garantir a transição no início do próximo start
bit do caracter seguinte, caso este seja transmitido logo a seguir. A Figura 1.27 ilustra
todo este funcionamento considerando um n  2 .
Figura 1.27 – Exemplo de Transmissão e Recepção Assíncrona.
Podemos notar que, como o início de um caracter é bem delimitado, caracteres
podem ser transmitidos espaçados entre si de forma aleatória. Não há a necessidade de
transmitir um após o outro, já que a detecção correta do início de um caracter é o
suficiente para garantir o funcionamento correto dos osciladores durante a transmissão
e recepção desse caracter.
1.1.10.2 Transmissão Síncrona
Na transmissão síncrona, procura-se garantir a existência de uma referência
“única” de tempo para o transmissor e receptor durante cada transmissão. Existem dois
modos de realizarmos essa tarefa.
O primeiro, o mais simples, consiste em enviar em um canal separado dos dados,
o clock do circuito transmissor. Se cuidados forem tomados de forma que os dados
transmitidos sofram exatamente os mesmos retardos que o clock do circuito transmissor,
esse clock poderá ser usado pelo circuito receptor como a base para a amostragem correta
40
dos dados recebidos. A técnica de codificação de dados utilizada nesta solução é, em
geral, a NRZ.
A solução apresentada no parágrafo anterior, embora teoricamente simples,
apresenta alguns problemas práticos. O primeiro deles é a necessidade de dois canais
de transmissão (um para os dados e outro para o clock), com toda a duplicação dos
circuitos de transmissão correspondentes, aumentando em muito o custo de transmissão.
Outro problema é a exigência dos circuitos apresentarem os mesmos retardos de
transmissão. De forma análoga, os meios de transmissão utilizados devem ser
perfeitamente idênticos de forma a apresentar o mesmo retardo de propagação. Uma
pequena variação no comprimento do meio poderia impossibilitar qualquer
comunicação. Enfim, qualquer variação de retardos poderia ocasionar a amostragem
incorreta de dados no receptor. Esse problema será tanto mais crítico quanto maiores
forem as velocidades de transmissão empregadas e as distâncias envolvidas.
O segundo modo de se realizar uma transmissão síncrona consiste em enviar dados
e informações de sincronismo que permitam recuperar o clock, juntos em um mesmo
canal, utilizando alguma técnica de codificação. Ao receptor cabe separar esses dois
sinais e, a partir do clock recuperado, realizar a amostragem dos dados. Essa alternativa
evita o problema contido na primeira solução, ou seja, a necessidade de dois canais, com
os problemas que daí advêm.
São várias as técnicas de codificação usuais em redes de computadores para a
transmissão conjunta de dados e informações de sincronismo em um mesmo canal.
Todas elas baseiam-se no fato de garantirmos a existência de transições em qualquer que
seja o padrão de bits transmitidos. Também em todas as técnicas há a necessidade do
envio de informações de sincronismo antes do início da transmissão. A seguir vamos
exemplificar duas dessas técnicas, utilizadas nos padrões IEEE 802: a codificação
Manchester e a codificação Manchester Diferencial.
1.1.10.2.1 Codificação Manchester
A codificação Manchester, é nada mais nada menos que a modulação em fase
dos dados e clock. Essa técnica tem todas as vantagens da utilização de apenas um
canal de transmissão. Conforme podemos ver na Figura 1.28, na codificação
Manchester uma transição positiva representa o bit 1 e uma transição negativa
representa o bit 0. Como cada bit possui uma transição, o sinal carrega seu próprio
pulso de clock. A Figura 1.29 mostra um exemplo de transmissão utilizando a
codificação Manchester.
Figura 1.28 – Codificação Manchester.
41
Figura 1.29 – Exemplo de Codificação Manchester.
Na codificação Manchester, toda transmissão de bits 0 e 1 implica em
transições no sinal, mas nem toda transição representa um bit. Note, por exemplo,
na Figura 1.29, a transição que aparece ao final do bit 0 quando o bit seguinte
também é 0. O fato de que nem toda transição representa um bit dificulta a
separação dos dados e o sincronismo no sinal transmitido. Se, no entanto,
transmitirmos antes de cada pacote de dados um preâmbulo de 0s e 1s se alternando,
todas as transições desse preâmbulo serão significativas e a partir delas será
possível recuperar o clock, que daí em diante será simplesmente ajustado em fase
com as próximas transições existentes no meio de cada bit transmitido. Recuperado
o clock, a recuperação dos dados é trivial, pois agora sabemos quais transições
carregam informações e quais não carregam. A Figura 1.30 mostra como é possível
descobrir o período do clock original (T) a partir do preâmbulo.
Figura 1.30 – Recuperação do Período do Clock Através do Preâmbulo.
A Figura 1.31 mostra a separação dos dados e clock no sinal recebido. A
lógica é simples. A partir de cada transição válida, esperamos 3 4 do período de
sinalização e amostramos o sinal recebido. A amostragem ocorrerá na descida do
ciclo do clock recuperado. O preâmbulo garante que o algoritmo começa sempre
de uma transição válida. O sinal amostrado é exatamente o inverso do sinal
transmitido. Note na Figura 1.31 que os bits do sinal recuperado são o inverso do
valor do sinal amostrado na descida do clock recuperado. No sinal recuperado está
faltando um bit no começo (bit 0), porque não consideramos a existência do
preâmbulo neste exemplo. Em uma transmissão real, o preâmbulo não só levaria a
recuperação do período do clock original (T) como também evitaria a perda do
primeiro bit de dados da transmissão.
42
Figura 1.31 – Exemplo de Transmissão Manchester.
1.1.10.2.2 Codificação Manchester Diferencial
A codificação Manchester Diferencial é derivada da codificação Manchester.
Conforme podemos ver na Figura 1.32, como na codificação Manchester, cada bit
é representado por duas metades, tendo a segunda metade a polaridade inversa da
primeira, isto é, existe sempre uma transição no meio do bit. Um bit 0 é
representado por uma transição no começo (mudança de polaridade) da sua
transmissão, enquanto que o bit 1 é representado por nenhuma transição (mesma
polaridade) no começo da sua transmissão.
Figura 1.32 – Exemplo de Codificação Manchester Diferencial.
A separação dos sinais (dados e sincronismos) é realizada de modo similar à
codificação Manchester apresentada na Seção 1.1.10.2.1.
43
Além das vantagens provenientes da utilização de um só cabo, as codificações
Manchester, diferencial ou não, trazem intrinsecamente o seu próprio esquema de
detecção de erro. Cada bit Manchester válido tem uma transição no meio. Se um
ruído causar a inversão de alguma metade deste bit, a ausência de transição vai
representar um dado Manchester inválido. Apenas o evento improvável da inversão
das duas metades da célula criaria um erro não detectável, mas a probabilidade deste
fenômeno ocorrer são ínfimas.
É interessante notarmos que, na codificação Manchester, diferencial ou não,
os bits são representados por mudança de polaridade do sinal. Sinais que não
mudam de polaridade também existem, embora não sejam utilizados para
representação de informação propriamente dita, mas sim para funções especiais.
Um símbolo carregado por um período de sinalização que não muda de polaridade
mantendo o nível baixo é denominado bit J. O símbolo que não muda de
polaridade, porém mantém o nível alto é denominado bit K. Os bits J e K nunca
aparecem nos dados transmitidos, mas podem ser utilizados para funções de
delimitação de pacotes.
O preâmbulo, como vimos, serve para ajudar a separação dos dados e clock
na codificação Manchester. Ele tem, contudo, outras funções além desta, utilizadas
em todas as técnicas de codificação apresentadas. Nas redes locais que não usam
Multiplexação em Frequência, a ausência de transmissão é indicada pela ausência
de sinal no meio. Se um dispositivo fosse iniciar a transmissão com o começo de
seus dados, provavelmente os dispositivos receptores perderiam os primeiros bits,
pois precisam de um tempo finito para ajustarem os seus clocks internos à
frequência e/ou fase do transmissor. Esta é mais uma razão para a existência do
preâmbulo. Se o receptor perder um pedaço do preâmbulo, ele ainda será capaz de
reconhecer o seu final pelo aparecimento de alguma sequência particular, e a partir
daí, receber os dados corretamente. Notemos que em sistemas onde há transmissões
ininterruptas de pacote de dados, a necessidade de preâmbulo verifica-se apenas
para a iniciação do sistema. Uma vez iniciado, não há mais necessidade de envio
de preâmbulo, a não ser para uma nova iniciação.
Uma outra característica a ser explorada na codificação Manchester é que a
ausência de transmissão pode ser detectada pela simples ausência de transições no
meio.
1.1.11 Técnicas de Detecção de Erros
Apresentamos na Seção 1.1.4, vários fenômenos que podem causar erros de
transmissão, como os ruídos. Na impossibilidade de eliminar totalmente esses fenômenos,
sistemas de comunicação devem ser projetados de forma a possibilitar a recuperação da
informação perdida. O primeiro passo para qualquer esquema de tratamento de erros é a sua
detecção. Reconhecer que um quadro foi recebido com erro irá permitir que se tomem as
providências necessárias, que poderão variar de acordo com as necessidades das aplicações
e com as características dos dados transmitidos. Nesta seção abordaremos apenas as técnicas
para a sua detecção.
Todos os métodos de detecção de erros são baseados na inserção de bits extras na
informação transmitida. Esses bits consistem em informações redundantes, isto é, que podem
ser obtidas a partir da informação original. Esses bits são computados pelo transmissor
através de algum algoritmo que tem como entrada os bits originais a serem transmitidos.
Após computar esses bits, o transmissor os acrescenta aos bits de informação propriamente
dita, para então prosseguir com a transmissão do quadro. Quando o quadro é recebido, o
44
receptor, conhecendo o algoritmo utilizado pelo transmissor, pode recomputar os bits de
redundância e compará-los com os respectivos bits recebidos no quadro. Se eles forem
diferentes, detectou-se a presença de um erro.
Vários algoritmos para geração de bits de redundância já foram propostos e podem ser
encontrados nas literaturas. Iremos apresentar resumidamente duas das principais técnicas
conhecidas pelos nomes de Paridade e CRC (Cyclic Redundancy Checks – Checagem de
Redundância Cíclica).
1.1.11.1 Paridade
A forma mais simples de redundância para detecção de erros já foi mencionada
anteriormente quando apresentamos a transmissão assíncrona na Seção 1.1.10.1,
consistindo na inserção de um bit de paridade ao final de cada caracter de um quadro.
O valor desse bit é escolhido de forma a deixar todos os caracteres com um número par
de bits 1 (paridade par) ou com um número ímpar de bits 1 (paridade ímpar).
Tipicamente, em transmissões assíncronas, costuma-se utilizar a paridade par. Se o
transmissor desejar, por exemplo, transmitir o caracter “1110001”, utilizando paridade
ímpar, ele acrescentará um bit 1 ao final do caracter, de forma que a sequência resultante
terá um número ímpar de bits 1 (no caso, 5 bits 1), ficando “11100011”. O receptor,
examinando o caracter recebido, deverá sempre encontrar um número de bits 1 ímpar,
caso em que assumirá que a transmissão foi efetuada com sucesso. Caso contrário,
houve algum erro durante a transmissão que ocasionou a inversão de um ou mais bits.
Se a paridade fosse par, teria sido acrescentado o bit 0, de forma que continuaria
existindo um total par de bits 1 (no caso, 4 bits 1).
Note que, caso um número par de bits tenha sido invertido, o receptor não será
capaz de perceber a existência de erro, pois a paridade ainda estará correta.
1.1.11.2 CRC
Como vimos anteriormente, o esquema de paridade é muito restrito, sendo pouco
eficiente na detecção de erros. Esquemas de melhor eficiência já foram propostos,
dentre eles o CRC.
Nesse esquema, um quadro de k bits, é representado por um polinômio D(X).
Como exemplo, o quadro “1101011011” onde k  10 é representado pelo polinômio
D( X )  X 9  X 8  X 6  X 4  X 3  X  1 . A ordem do polinômio D(X) será k  1 .
No transmissor é gerado um polinômio temporário L(X), formado pela
concatenação dos dados com uma quantidade n de zeros, onde n representa a ordem do
polinômio gerador G(X). Em seguida, o polinômio temporário L(X) é dividido em
módulo 2 pelo polinômio gerador G(X). Após esta divisão, obteremos um resto r(X),
cuja ordem será inferior à ordem do polinômio gerador G(X) representado aqui por n.
Por último, o polinômio temporário L(X), será subtraído do resto da divisão r(X) criando
o polinômio que será transmitido T(X). Este polinômio a ser transmitido é formado pelo
dado concatenado ao resto, onde os n bits extras acrescentados à direita dos dados são
chamados de FCS (Frame Check Sequence – Sequência de checagem de Quadro). Na
Figura 1.33 temos um exemplo da geração de uma transmissão usando como técnica de
detecção de erro o CRC.
45
Quadro  1101011011  D( X )  X 9  X 8  X 6  X 4  X 3  X  1
Polinômio Gerador  10011  G ( X )  X 4  X  1 (ordem 4  n  4 )
L(X) = 11010110110000
Realizando a divisão em módulo 2 de L(X) por G(X).
Realizando a subtração em módulo 2 de L(X) por r(X) resultando no T(X).
Figura 1.33 – Criação do FCS usando a Técnica CRC no Transmissor.
Sempre que é subtraído do dividendo o resto obtido pela divisão, o resultado é,
obrigatoriamente, um múltiplo do divisor. Sendo assim, após a subtração do polinômio
L(X) por r(X), gerando o polinômio T(X), este polinômio será divisível por G(X).
Todos os equipamentos que receberem o polinômio T(X) poderão realizar a sua
verificação realizando a sua divisão por G(X) e verificando se o resto é igual a zero,
como mostra a Figura 1.34. Se for, considera-se que não houve alteração na transmissão
e então pode-se dar continuidade ao seu processamento. No caso de nós intermediários,
realizar a retransmissão. No caso do destinatário, realizar a retirada do FCS e então
encaminhar o dado para as camadas superiores da hierarquia de transporte.
46
Figura 1.34 – Verificação dos Dados Usando a Técnica CRC feita no Receptor.
Alguns polinômios geradores são largamente utilizados e padronizados. Como
exemplo, temos os seguintes:
CRC  12  X 12  X 11  X 3  X 2  X  1
CRC  16  X 16  X 15  X 2  1
CRC  CCITT  X 16  X 12  X 5  1
CRC  32  X 32  X 26  X 23  X 22  X 16  X 12  X 11  X 10  X 8  X 7  X 5  X 4  X 2  X  1
O esquema baseado em CRC-12 é utilizado em sequências de caracteres de seis
bits gerando FCS de 12 bits. Tanto o CRC-16 quanto o CRC-CCITT são populares para
sequências de caracteres de oito bits, na Europa e EUA, respectivamente, ambos
resultam em FCS de 16 bits. O CRC-32 foi o escolhido pelo comitê IEEE-802 para ser
utilizado em redes locais, gerando FCS de 32 bits.
47
Meios de Transmissão e Topologia de Redes
No nível mais baixo, toda a comunicação entre computadores envolve codificar dados em uma
forma de energia e enviar essa energia através de um meio de transmissão. Por exemplo, a corrente
elétrica pode ser usada para transferir dados através de um fio, ou as ondas de rádio podem ser usadas
para carregar dados através do ar. Uma vez que os dispositivos de hardware conectados a um
computador executam a codificação e a decodificação dos dados, os programadores e os usuários não
precisam conhecer os detalhes da transmissão de dados. Entretanto, já que um papel principal do
software de comunicação é tratar os erros e as falhas que surgem no hardware subjacente, compreender
tal software requer o conhecimento de alguns conceitos básicos sobre transmissão de dados.
Nesta seção abordaremos os principais meios de transmissão de dados e as topologias de redes,
isto é, a forma como os equipamentos serão conectados uns aos outros.
2.1
Meios de Transmissão
2.1.1
Fios de cobre
As redes de computadores convencionais usam fios como o meio primário para
conectar computadores porque o fio é barato e fácil de instalar. Embora os fios possam ser
feitos de vários tipos de metais, muitas redes usam o cobre porque sua baixa resistência à
corrente elétrica significa que os sinais podem viajar mais longe. Assim, os profissionais de
rede usam às vezes o termo cobre como sinônimo de fio.
O tipo de fiação usado em redes de computadores é escolhido para minimizar a
interferência. A interferência surge porque um sinal elétrico que viaja através de um fio age
como uma estação de rádio em miniatura. O fio emite um pouco de energia eletromagnética,
que pode viajar através do ar. Além disso, sempre que encontra um outro fio, uma onda
eletromagnética gera uma corrente elétrica pequena no fio. A quantidade de corrente gerada
depende da força da onda eletromagnética e da posição física do fio. Geralmente, os fios não
chegam perto o suficiente para fazer da interferência um problema. Por exemplo, se dois fios
estão dispostos próximos um do outro em um ângulo reto e um sinal passa através de um dos
fios, a corrente gerada no outro é quase indetectável. Entretanto, quando dois fios são
colocados juntos em paralelo, um sinal forte enviado em um fio gerará um sinal similar no
outro. Já que os computadores não podem distinguir entre sinais gerados acidentalmente e
as transmissões normais, a corrente gerada pode ser forte o bastante para transtornar ou
impedir um comunicação normal. Infelizmente, o problema da interferência é sério porque
os fios que compreendem uma rede de dados são freqüentemente colocados em paralelo com
muitos outros fios. Por exemplo, os fios de um computador podem encontrar-se ao lado dos
fios de outros computadores ou dos fios para outras redes.
Para minimizar a interferência, as redes usam um de dois tipos básicos de fiação: Par
Trançado ou Cabo Coaxial.
2.1.1.1
Cabo de Par Trançado
A fiação trançada do par é usada também por sistemas de telefonia. O termo se
deve ao fato de que cada fio é revestido com um material isolador, e então um par dos
fios é torcido, tal como mostra a Figura 2.1.
48
Figura 2.1 – Par Trançado.
As torções simples mudam as propriedades elétricas do fio e ajudam o mesmo a
se tornar apropriado para o uso em uma rede. Em primeiro lugar, uma vez que limitam
a energia eletromagnética que o fio emite, as torções ajudam a impedir que as correntes
elétricas no fio irradiem energia que interfere com os outros fios. Em segundo, já que
fazem o par dos fios menos suscetível à energia eletromagnética, as torções ajudam a
impedir que os sinais em outros fios interfiram com o par.
2.1.1.2
Cabo Coaxial
O segundo tipo de fiação de cobre usado nas redes é o cabo coaxial, o mesmo tipo
de fiação usado para a TV a cabo. O coaxial fornece ainda maior proteção contra
interferência do que o par trançado. Em vez de trançar fios um ao redor do outro para
limitar a interferência, um cabo coaxial consiste em um único fio cercado por um
protetor de metal mais pesado tal como ilustrado na Figura 2.2.
Figura 2.2 – Cabo Coaxial.
O protetor de metal pesado em um cabo coaxial forma um cilindro flexível em
torno do fio interno que fornece uma barreira à irradiação eletromagnética. A barreira
isola o fio interno de duas maneiras: protege o fio da energia eletromagnética entrante
que poderia causar a interferência e evita que sinais no fio interno irradiem energia
eletromagnética que poderia afetar outros fios. Uma vez que cerca o centro do fio
uniformemente em todos os lados, o protetor em um cabo coaxial é especialmente eficaz.
O cabo pode ser colocado em paralelo com outros cabos ou dobrado e torcido em torno
dos cantos. O protetor permanece sempre no lugar.
A idéia de usar um protetor para proteger os fios foi aplicada também ao par
trançado. Um cabo par trançado protegido consiste em um par de fios cercado por um
protetor de metal. Cada fio é revestido com um material isolante, de forma que o metal
em um fio não toque o metal em outro. O protetor forma meramente uma barreira que
49
impede que a irradiação eletromagnética entre ou escape. A proteção adicional
fornecida pelo cabeamento com cabo coaxial ou par trançado protegido é
freqüentemente usada quando os fios de uma rede passam perto de equipamentos que
geram campos elétricos ou magnéticos fortes (por exemplo: um ar condicionado de
grande porte).
2.1.2
Fibras de Vidro
As redes de computadores usam também fibras de vidro flexíveis para transmitir dados.
Conhecido como fibra óptica, o meio usa a luz para transportar dados. A fibra de vidro em
miniatura é revestida de plástico que permite que a fibra se dobre sem quebrar. Um
transmissor em uma extremidade de uma fibra usa um diodo emissor de luz (light emitting
diode, LED) ou um laser para enviar pulsos de luz pela fibra. Um receptor no extremo oposto
usa um transistor sensível à luz para detectar os pulsos.
As fibras ópticas têm quatro vantagens principais sobre fios. Em primeiro lugar, como
usam luz, as fibras ópticas não causam interferência elétrica em outros cabos nem são
suscetíveis à interferência elétrica. Em segundo lugar, como as fibras de vidro podem ser
fabricadas para refletir a maioria da luz interna, uma fibra pode carregar um pulso de luz
muito mais longe do que um fio de cobre pode carregar um sinal. Em terceiro lugar, já que
a luz pode codificar mais informação do que sinais elétricos, uma fibra óptica pode carregar
mais informação do que um fio. Em quarto lugar, ao contrário da eletricidade, que requer
sempre um par de fios conectado em um circuito completo, a luz pode viajar de um
computador a outro sobre uma única fibra.
Apesar de suas vantagens, as fibras ópticas têm algumas desvantagens. Primeiramente,
a instalação de uma fibra requer um equipamento especial que faça o polimento das
extremidades para permitir que a luz passe completamente. Em segundo lugar, se uma fibra
quebrar dentro do revestimento plástico, encontrar onde ocorreu o problema é difícil. Em
terceiro lugar, reparar uma fibra quebrada é difícil porque um equipamento especial é
necessário para juntar duas fibras de modo que a luz possa passar através da junção.
2.1.3
Rádio
Além de seus usos para transmissão pública dos programas de rádio e de televisão e
para uma comunicação privada com dispositivos como telefones portáteis, podem ser usadas
radiações eletromagnéticas para transmitir dados de computador. Informalmente, diz-se que
uma rede que usa ondas de rádio eletromagnéticas opera na frequência de rádio, e as
transmissões são chamadas de transmissões RF. Ao contrário das redes que usam fios ou
fibras ópticas, as redes que usam transmissão de RF não requerem uma conexão física direta
entre computadores. Em vez disso, cada computador participante está conectado a uma
antena, que pode tanto transmitir como receber RF.
2.1.4
Satélites
Embora as transmissões de rádio não se curvem de acordo com a superfície da terra, a
tecnologia RF pode ser combinada com satélites para fornecer comunicação através de
distâncias mais longas. Por exemplo, a Figura 2.3 ilustra como um satélite de comunicações
na órbita em torno da terra pode fornecer uma conexão de rede através de um oceano. O
satélite contem um transponder que consiste em um receptor de rádio e um transmissor. O
transponder aceita uma transmissão de rádio entrante, amplifica-a e transmite o sinal
amplificado para a terra em um ângulo ligeiramente diferente do que chegou. Uma estação
terrestre em um lado do oceano transmite um sinal ao satélite, que o envia então a uma estação
no outro lado. Devido ao fato de ser caro colocar um satélite de comunicações em órbita, um
único satélite contém geralmente os múltiplos transponders que operam independentemente
50
(tipicamente seis a doze). Cada transponder usa uma frequência de rádio diferente (isto é,
canal), possibilitando que comunicações múltiplas prossigam simultaneamente. Além disso,
como um único canal do satélite pode ser compartilhado, ele pode servir a muitos clientes.
Figura 2.3 – Comunicação Via Satélite.
2.1.4.1
Satélites Geossíncronos ou Geoestacionários
Os satélites de comunicação podem ser agrupados em categorias de acordo com a
altura em que orbitam. O tipo mais fácil de entender é conhecido como satélites
geossíncronos ou geoestacionários. O nome se deve ao fato de que um satélite
geossíncrono é colocado em uma órbita que seja sincronizada exatamente com a rotação
da terra. Tal órbita é classificada como uma órbita geoestacionária da terra
(Geostacionary Earth Orbit – GEO) porque, quando visto da terra, o satélite parece
permanecer exatamente no mesmo ponto no céu o tempo todo. Por exemplo, um satélite
geoestacionário em órbita circular acima do equador, sobre o Oceano Atlântico, pode
ser usado para repassar transmissões entre Europa e América do Norte a qualquer hora,
porque permanece acima do mesmo ponto sobre o oceano.
As leis da física determinam a distância exata da terra na qual um satélite deve
orbitar para permanecer sincronizado com a rotação da terra. A distância necessária para
a órbita geossíncrona é aproximadamente 35.800 quilômetros. Os engenheiros às vezes
se referem à distância como a órbita elevada da terra. No Apêndice B é mostrado o
cálculo da órbita de um satélite.
É interessante perceber que há uma quantidade limitada de “espaço” disponível na
órbita geossíncrona acima do equador, porque os satélites de comunicação que usam
uma mesma frequência devem ser separados um do outro para evitar a interferência. A
separação mínima depende do poder dos transmissores, mas requer geralmente uma
separação angular entre 4º e 8º. Assim, o círculo inteiro de 360º acima do equador pode
acomodar somente 45 a 90 satélites.
2.1.4.2
Satélites de Baixa Órbita da Terra
Uma segunda categoria de satélites de comunicação opera no que é chamada de
Órbita Baixa da Terra (Low Earth Orbit, LEO), o que significa que orbitam algumas
centenas de quilômetros acima da terra (normalmente 320 a 645 quilômetros). A
principal desvantagem de uma órbita de baixa altitude se encontra na velocidade em que
um satélite deve viajar. Como seus períodos de rotação são mais rápidos do que a
rotação da terra, os satélites em órbitas mais baixas não permanecem estacionários acima
de um único ponto na superfície da terra. Em vez disso, um observador que esteja na
terra e que olhe para cima através de um telescópio vê tais satélites moverem-se através
51
do céu. De fato, um único satélite pode completar uma órbita inteira em
aproximadamente 1,5 horas.
Do ponto de vista de um provedor de comunicações, ter um satélite que não
aparenta permanecer estacionário causa problemas. Em primeiro lugar, o satélite pode
ser usado somente durante o tempo em que sua órbita passa entre duas estações
terrestres. Em segundo lugar, a utilização máxima requer sistemas complexos de
controle que se movam continuamente de forma que as estações terrestres apontem
diretamente para o satélite.
2.1.4.3
Arrays de Satélites de Baixa Órbita da Terra
Foi inventado um esquema interessante que permite uma comunicação contínua
através de satélites em órbita baixa. Em vez de focalizar em um satélite, o esquema
requer que uma companhia de comunicação lance um conjunto de satélites em órbitas
baixas da terra como mostra a Figura 2.4. Embora um dado satélite orbite rapidamente,
o conjunto de órbitas é escolhido de modo que em cada ponto na terra exista ao menos
um satélite acima a qualquer momento (são necessários sessenta e seis satélites para
fornecer serviço sobre a superfície inteira da terra). Do ponto de vista de um observador
na terra, parece que um satélite emerge de um ponto no horizonte, voa em cima, e então
desaparece em um pondo do horizonte oposto. A chave do esquema se encontra no
conjunto de órbitas que garante que ao menos um satélite esteja disponível em qualquer
momento.
Figura 2.4 – Array de Satélites.
Além dos transponders usados para comunicação com as estações da terra, um
array de satélites de órbita baixa contém equipamento de rádio usado para comunicarse com outros satélites no array. Enquanto se movem através de suas órbitas, os satélites
se comunicam um com o outro e concordam no encaminhamento de dados. Por
exemplo, suponha que, em um dado momento, um satélite viajando sobre a Europa
receba uma transmissão de uma estação terrestre na Alemanha, destinada para um local
dos Estados Unidos. O satélite receptor poderia repassar uma transmissão a um outro
satélite, que a repassaria a um terceiro que pode alcançar uma estação terrestre nos
Estados Unidos próxima ao destino. Com o passar do tempo, os satélites vão adiante e
os novos satélites tomam seu lugar, significam que uma transmissão mais tarde da
Alemanha para os Estados Unidos poderia ter que atravessar três outros satélites no
array.
2.1.5
Microondas
A radiação eletromagnética além da faixa de frequência usada por rádio e televisão
pode ser usada também para transportar informações. Em particular, muitas empresas de
52
telefonia interurbana usam transmissões de microonda para carregar conversas telefônicas.
Umas poucas empresas de grande porte instalaram também sistemas de comunicação de
microonda como parte do sistema de rede da empresa.
Embora as microondas sejam meramente uma versão das ondas de rádio com
frequência mais elevada, elas se comportam de maneira diferente. Em vez de transmitir em
todas as direções, uma transmissão de microonda pode ser apontada em uma única direção,
impedindo que outros interceptem o sinal. Além disso, a transmissão de microondas pode
carregar mais informações do que transmissões de RF de frequência mais baixa. Entretanto,
já que as microondas não podem penetrar em estruturas de metal, a transmissão de
microondas trabalha melhor quando há um trajeto desobstruído entre o transmissor e o
receptor. Como consequência, a maioria das instalações baseadas em microondas consiste
em duas torres que são mais altas do que os edifícios e a vegetação circundantes, cada uma
com um transmissor de microondas apontado diretamente para um receptor de microondas
no outro.
2.1.6
Infravermelho
Os controles remotos sem-fio usados com dispositivos tais como televisões e aparelhos
de som comunicam-se através de transmissões em infravermelho. O infravermelho é
limitado a uma área pequena (por exemplo, uma única sala) e exige geralmente que o
transmissor esteja apontando para o receptor. O hardware infravermelho é barato se
comparado a outros mecanismos, não requer uma antena.
As redes de computadores podem usar a tecnologia infravermelha para a transmissão
de dados. Por exemplo, é possível equipar uma sala grande com uma única conexão
infravermelha que forneça acesso à rede a todos os computadores na sala. Os computadores
podem permanecer em contato com a rede enquanto são movidos dentro da sala. As redes
de infravermelho são especialmente convenientes para computadores pequenos e portáteis
porque o infravermelho oferece as vantagens de comunicação sem-fio sem necessitar do uso
de antenas. Assim, um computador portátil que use infravermelho pode ter todo o hardware
de comunicação embutido.
2.1.7
Luz de Laser
Já mencionamos que a luz pode ser usada para comunicação através de fibras ópticas.
Um feixe de luz pode também ser usado para carregar dados através do ar. Como um sistema
de comunicação de microondas, uma comunicação que use luz consiste em dois locais, um
que possua um transmissor e um outro que possua um receptor. O equipamento de
comunicação é montado em uma posição fixa, frequentemente em uma torre, e alinhado de
forma que o transmissor em uma posição envie seu feixe de luz diretamente ao receptor na
outra. O transmissor usa um laser para gerar o feixe de luz porque um feixe de laser coerente
permanecerá focalizado sobre uma longa distância.
Como uma transmissão de microondas, a luz de um laser deve viajar em uma linha reta
e não deve ser obstruída. Infelizmente, um feixe de laser não pode penetrar na vegetação ou
em condições climáticas como neve e névoa. Assim, a transmissão via laser tem uso
limitado.
2.2
Classificação de Redes
Como foi visto, dependendo do volume de tráfego e do alcance que se necessita realizar
uma comunicação, precisa-se escolher o meio adequado para realizar esta transferência. Não
pode-se esquecer também dos fatores que podem interferir no sinal durante a comunicação.
Devido a isso, as redes são classificadas de acordo com a sua abrangência, como vemos abaixo:
53
2.3

LAN: abreviatura de Local Area Network, que significa Rede de Área Local É uma
rede que tem como característica principal o alcance do porte de uma
empresa. Limitando-se a uma distância da ordem de poucos quilômetros (2,5
Km para redes Ethernet)

MAN: abreviatura de Metropolitan Area Network, que significa Rede de Área
Metropolitana. Esta rede tem como característica básica o alcance em uma
área do porte de uma cidade.

WAN: abreviatura de Wide Area Network, que significa Rede Geograficamente
distribuída. Possui como característica a interligação de longas distâncias,
como estados, países e continentes.
Topologia de Redes Locais (LAN)
Já que muitas tecnologias de LAN têm sido inventadas, é importante conhecer como as
tecnologias específicas são semelhantes e como elas diferem. Para ajudar a entender as
semelhanças, cada rede é classificada em uma categoria de acordo com a sua topologia ou forma
geral. Esta seção descreve as três topologias usadas mais frequentemente com LANs.
2.3.1
Estrela
Uma rede usa uma topologia de estrela se todos os computadores se prendem a um
ponto central. A Figura 2.5 ilustra o conceito.
Figura 2.5 – Topologia em Estrela.
Uma vez que uma rede em forma de estrela se assemelha a uma roda, o centro de uma
rede em estrela é chamado de centralizador. Um centralizador típico consiste em um
dispositivo eletrônico que aceita dados de um computador remetente e os encaminha para o
computador de destino. No Capítulo 4 descreveremos alguns equipamentos que podem
realizar o trabalho de centralizador.
A Figura 2.5 mostra uma rede de estrela idealizada. Na prática, as redes em estrela têm
raramente uma forma simétrica em que o centralizador esteja localizado a uma distância igual
de todos os computadores. Em vez disso, frequentemente um centralizador reside em uma
localização separada dos computadores acoplados a ele. Por exemplo, os computadores
podem residir em escritórios individuais, enquanto o centralizador reside em uma localização
acessível para o pessoal responsável pela administração da rede.
2.3.2
Anel
Na topologia em anel, os computadores são organizados de forma que sejam
conectados em um loop fechado. Um cabo conecta o primeiro computador a um segundo
computador, outro cabo conecta o segundo computador a um terceiro, e assim por diante, até
que um cabo conecte o computador final de volta ao primeiro. O nome anel surge porque
54
alguém pode imaginar os computadores e os cabos que os conectam organizados em um
círculo tal como mostra a Figura 2.6.
Figura 2.6 – Topologia em Anel.
É importante entender que o anel, assim como a topologia em estrela, refere-se a
conexões lógicas entre computadores, não orientação física. Os computadores e as conexões
em uma rede em anel não precisam ser organizados em um círculo. Em vez disso, o cabo
entre um par de computadores em uma rede em anel pode seguir um corredor ou subir
verticalmente de um andar de um edifício para outro. Além disso, se um computador está
longe de outros do anel, os dois cabos que conectam o computador distante podem seguir o
mesmo caminho físico.
2.3.3
Barramento
Uma rede que usa uma topologia de barramento normalmente consiste em um único
cabo longo ao qual computadores se acoplam. Qualquer computador acoplado a um
barramento pode enviar um sinal através do cabo, e todos os computadores receberão o sinal.
A Figura 2.7 ilustra a topologia. Como todos os computadores ligados pelo cabo podem
detectar um sinal elétrico, qualquer computador pode enviar dados a qualquer outro
computador. Naturalmente, os computadores acoplados a uma rede de barramento devem se
coordenar para assegurar que somente um computador envia um sinal a cada momento para
evitar o caos.
Figura 2.7 – Topologia de Barramento.
55
Modelo OSI
Quando as redes começaram a ser desenvolvidas, questões de interoperabilidade e projeto
começaram a surgir. Visando a essas questões e visando também acomodar a interconexão de redes
proprietárias e heterogêneas, a ISO desenvolveu em 1974 uma arquitetura e modelo de referência para
servir como base para atividades futuras de padronização de redes. O modelo resultante foi chamado
formalmente de modelo de referencia OSI (Open Systems Interconnect – Interconexões de Sistemas
Abertos). O modelo OSI apresenta um conjunto detalhado de padrões para descrever uma rede. Ele
forma um arcabouço conceitual para o desenvolvimento de padrões para protocolos de redes.
Uma das características mais interessantes do modelo OSI é a definição e codificação formal do
conceito de arquitetura de rede em camadas. São utilizadas camadas descritivas operacionalmente bemdefinidas que descrevem o que acontece em cada estágio no processamento de dados a serem
transmitidos. Esse conceito de camadas é extremamente importante, uma vez que as redes são sistemas
não-triviais. Em função da natureza complexa de uma rede, é extremamente difícil projetar uma
arquitetura que:

Tenha alto grau de conectividade;

Seja confiável;

Seja fácil de implementar, usar e modificar.
As camadas ajudam a reduzir esta complexidade. Organizando as funções de uma rede em uma
série de camadas hierárquicas, o projeto de uma rede é bastante simplificado. Por exemplo, uma
abordagem baseada em camadas possibilita que as funções e serviços de uma camada sejam
completamente independentes e isolados das outras camadas.
Com isso, podemos alterar os recursos de uma camada sem mudar significativamente a arquitetura
como um todo. À medida que novas tecnologias vão surgindo para uma nova camada, elas podem ser
implementadas sem afetar as demais camadas. Teoricamente, uma camada pode ser completamente
removida, alterada e reinserida sem afetar as outras camadas acima ou abaixo dela. As camadas em
redes são similares à programação modular. Assim como os programas grandes de computador são
quebrados em módulos de programa independentes e separados, as camadas subdividem uma
arquitetura de rede em componentes independentes e separados. Cada uma delas é responsável por um
conjunto específico de funções e serviços. Protocolos específicos definem os serviços e a maneira como
esses serviços são disponibilizados.
As camadas do modelo OSI são (de cima para baixo, iniciando pela camada 7 (a mais alta) e indo
até a camada 1 (a mais baixa): aplicação, apresentação, sessão, transporte, rede, enlace de dados e física.
Cada camada é composta de duas partes: definição de serviços, que define o tipo de serviços oferecidos
pela camada, e especificação de protocolo, que detalha as regras que governam a implementação de um
serviço específico em particular. As camadas mais baixas oferecem serviços para as camadas mais
altas. Geralmente, essas camadas definem os recursos de comunicação necessários para que ocorra a
comunicação entre dois dispositivos quaisquer. A Figura 3.1 apresenta o modelo OSI e a Tabela 3.1
mostra a finalidade de cada camada.
56
Funcionalidades das Camadas do Modelo OSI
Camadas
Funcionalidades


Aplicação (7)


Apresentação (6)










Sessão (5)






Transporte (4)
Rede (3)
Enlace (2)
Física (1)


















Consiste de protocolos que definem as aplicações específicas orientadas para usuários, como correio
eletrônico, transferência de arquivos e terminal virtual.
Alguns exemplos são: FTAM (File Transfer, Access and Management) para manipular arquivos
remotamente; X.400 (para correio eletrônico) e CMIP (Common Management Information Protocol)
para gerenciamento de rede.
Acrescenta um cabeçalho durante a transmissão dos dados para que a camada de aplicação da
máquina de destino saiba o que fazer.
Retira o cabeçalho durante uma recepção colocada pela máquina de origem para transmitir os dados
ao aplicativo.
Trata de formatos de dados, traduções e conversões de código.
Cuida da sintaxe e semântica dos dados transmitidos.
Codifica mensagens em formatos adequados para transmissão eletrônica.
Compressão e criptografia dos dados efetuados nessa camada.
Recebe mensagens da camada de aplicação, formata essas mensagens e as transmite para a camada
de sessão.
Na prática essa camada é frequentemente incorporada na camada de aplicação.
Acrescenta um cabeçalho durante a transmissão dos dados para que a camada de apresentação da
Retira o cabeçalho durante uma recepção colocada pela máquina de origem para transmitir.
Trata da coordenação entre processos de comunicação entre os nós.
Responsável pelas regras de diálogo (por exemplo, verificar se uma conexão permite comunicação
em half duplex ou full duplex), pela sincronização do fluxo de dados e pelo restabelecimento da
conexão em caso de falha.
Alguns exemplos são o AppleTalk Data Stream Protocol para transferência confiável de dados entre
dois nós, o NetBEUI (uma extensão do NetBIOS) e o Printer Access Protocol para acessar uma
impressora PostScript em uma rede AppleTalk.
Usa a camada de apresentação acima dela e a camada de transporte abaixo dela.
Acrescenta um cabeçalho durante a transmissão dos dados para que a camada de sessão da máquina
de destino saiba o que fazer.
Trata da entrega de dados sem erros.
Aceita dados da camada de sessão, quebra os dados em pacotes menores, se necessário, passa os
pacotes para a camada de rede e garante que eles cheguem ao destino completos e corretos.
Acrescenta um cabeçalho durante a transmissão dos dados para que a camada de transporte da
Responsável pela rota entre redes para que os dados sejam entregues na rede de destino.
Resolve todos os problemas inerentes à transmissão de dados entre redes heterogêneas.
As mensagens formatadas são denominadas pacotes.
Acrescenta um cabeçalho e um fecho durante a transmissão dos dados para que a camada de rede da
Retira o cabeçalho e o fecho durante uma recepção colocada pela máquina de origem para transmitir.
Responsável pela transferência de dados entre pontos de uma mesma rede.
Trata de detecção de erros, “enquadramento” e controle de fluxo.
Resolve problemas relativos a quadros danificados, perdidos ou duplicados.
As mensagens formatadas são denominadas quadros em vez de pacotes.
Acrescenta um cabeçalho e um fecho durante a transmissão dos dados para que a camada de enlace
da máquina de destino saiba o que fazer.
Responsável por transmitir bits através de uma ligação; transporta energia.
Aceita quadros da camada de enlace de dados e traduz os bits em sinais do meio físico abaixo dela.
Cuida de questões como o tipo de cabo em uso, o tipo de conector (ou seja, a interface) que liga um
dispositivo a um meio e o esquema de sinalização.
Acrescenta um cabeçalho e um fecho durante a transmissão dos dados para que a camada de física
da máquina de destino saiba o que fazer.
Tabela 3.1 – Funcionalidades das Camadas do Modelo OSI.
57
Figura 3.1 – Modelo OSI em Camadas.
3.1
Tipos de Serviços OSI
Há dois tipos diferentes de serviços oferecidos pelas camadas OSI:

Orientados a conexão.

Não orientados a conexão.
Algumas camadas também incluem multiplexação como um serviço adicional, mas isso não
necessariamente cruza todas as camadas da arquitetura. Os serviços ficam disponíveis nos
SAPs (Service Access Points – Pontos de Acesso a Serviços), tendo cada SAP um endereço
correspondente.
3.1.1
Serviço Orientado a Conexão
Esse tipo de serviço sugere que antes da transferência de dados uma ligação física (ou
virtual) se estabeleça entre nós de emissão e recepção. Essa ligação permanece efetiva
durante toda a sessão. Quando a sessão se completa, a ligação é removida. As características
de um serviço orientado a conexão incluem:

Desperdício de largura de banda, uma vez que a ligação permanece mesmo
durante intervalos da transmissão;

Alto risco potencial de “prender” a rede, pois há sempre a possibilidade de uma
ligação não ser concluída;

Garantia de chegada sequencial dos pacotes ao nó de destino (aspecto positivo).
O sistema telefônico é um exemplo de serviço orientado a conexão. Você estabelece
uma conexão (disca uma número) e, uma vez feita a conexão, transfere dados pelo circuito
(começa a falar). A comunicação ocorre na sequência apropriada (as palavras e sentenças
são recebidas na ordem correta). No final da transferência a conexão é liberada (o telefone é
desligado liberando o circuito). Observe as questões de desperdício de largura de banda e de
“prender” a rede. Se uma conexão telefônica é efetuada, mas ninguém fala, a largura de
banda é desperdiçada porque o circuito fica estabelecido sem que ninguém o utilize. Alguém
58
tentando contatar esse aparelho durante esse período de silêncio ouviria um sinal de ocupado
– uma conexão “presa”.
3.1.2
Serviço não Orientado a Conexão
Esse tipo de serviço é diferente do serviço orientado por conexão, pois nenhuma ligação
física se estabelece entre os nós emissor e receptor antes da transmissão dos dados. Em vez
disso, uma mensagem é quebrada em pacotes e encaminhada pela rede. Cada pacote é
independente dos outros pacotes, que carregam partes da mensagem e, portanto, precisam
carregar um endereço de destino.
Os pacotes podem chegar fora de ordem. Imagine uma agencia de correios como um
provedor de serviços não orientado a conexão. Se você envia a alguém cinco cartas separadas
e enumeradas de 1 a 5, precisa colocar o endereço de recebimento em cada uma delas. Uma
vez remetidas, as cartas não seguirão necessariamente a mesma rota de entrega, e é possível
que sejam recebidas fora de sequência (por exemplo, a carta 3 é recebida antes da carta 2).
Um serviço não orientado a conexão pode ser confiável ou não-confiável. Um serviço nãoconfiável não requer aviso do recebimento dos dados provenientes do receptor para o
emissor. Isso se chama serviço de datagramas como foi visto na Seção 1.1.6.3.2. Um serviço
confiável requer uma confirmação de recebimento. Isso equivale a comparar um serviço de
remessa “regular” com uma remessa registrada com aviso de recebimento.
Um dos melhores e mais práticos exemplos desses serviços é a Internet. Vamos ilustrar
os dois serviços enviando uma mensagem pela Internet. Antes de fazer isso, entretanto,
precisamos de um pouco de metodologia de endereçamento.
Para enviar uma mensagem de um nó a outro pela Internet, três endereços diferentes
são necessários. O primeiro é o endereço de hardware, que identifica de forma única cada
nó. Endereços de hardware são fornecidos pela camada de enlace de dados. O segundo é o
endereço de rede, que identifica a rede à qual o nó está conectado. No TCP/IP, esse é
chamado de endereço de internet ou endereço IP (Internet Protocol). Endereços de rede
operam na camada de rede. Cada nó da rede que faz parte da Internet tem um endereço IP
único. O terceiro endereço é o endereço da porta, que identifica de forma única uma
aplicação específica de usuário, como correio eletrônico. Todas as aplicações de rede têm
identificadores correspondentes denominados número de porta.
Para enviar uma mensagem de um nó a outro, uma mensagem é primeiramente criada
na camada de aplicação. Ela passa pelos formatos necessários enquanto desce pelas camadas.
Quando a mensagem atinge a camada de rede, um endereço de rede é alocado para ela. Esse
endereço de rede identifica a rede específica onde está conectado o nó de destino. A camada
de rede determina o caminho que a mensagem deve seguir para atingir o nó de destino. Ela
também encapsula os pacotes como datagramas IP e os passa à camada de enlace de dados.
Na camada de enlace de dados, o endereço de hardware do nó de destino é adicionado a cada
pacote. Esse endereço identifica de forma única a localização do nó de destino na rede atual.
A camada de enlace de dados, dentre outras tarefas, coloca o pacote na forma de quadros,
que são semelhantes aos pacotes, mas existem em níveis mais baixos, e verifica a integridade
de cada quadro. Os quadros são então passados para a camada física, que os coloca no meio
de transmissão.
3.2
OSI Hoje
Do início até meados dos anos 90, a literatura sobre redes estava repleta de artigos
apresentando as vantagens e virtudes do modelo OSI. Muitos administradores de redes
desenvolveram estratégias para migrar suas redes para o modelo OSI, e alguns chegaram a
professar que todas as redes deveriam dar suporte a um único protocolo: OSI. Até mesmo o
59
governo dos Estados Unidos adotou o OSI ao estabelecer o perfil GOSIP (Government OSI
Profile), determinando que todas as organizações governamentais deveriam adquirir produtos
compatíveis com OSI a partir de 1992. apesar de tudo isso, o OSI nunca emergiu como “o”
protocolo de redes, em particular nos Estados Unidos. Aparentemente o modelo OSI foi
atropelado pelo TCP/IP, que serve como suíte de protocolos da Internet. Em 1995, o GOSIP foi
modificado para incluir o TCP/IP como uma suíte de protocolos aceitável para GOSIP, e hoje,
embora os protocolos OSI estejam em uso, sua presença é pálida se comparada com a do TCP/IP.
Hoje, os usos mais notáveis do OSI como implementação de suíte de protocolos estão na Rede de
Transportes Aéreos mundial e em redes de interoperação entre companhias de fornecimento de
energia elétrica. Diversas razões (naturalmente que especulativas) pelas quais o modelo OSI
nunca se materializou como “o” protocolo de redes são apresentadas a seguir.

Desenvolvimento de Padrões: TCP/IP e OSI são diferentes quanto à forma como
seus padrões são desenvolvidos e testados. Sendo uma organização formal para
padrões internacionais, a ISO possui uma inércia1 considerável, e o processo de
desenvolver padrões é difícil. Desde seu desenvolvimento inicial, o OSI foi
projetado para fazer tudo e segundo uma estratégia de cima para baixo.
Contrastando com essa abordagem, o TCP/IP dá suporte a um processo aberto de
participação dos usuários para preparar seus padrões. O desenvolvimento ou
modificação de protocolos TCP/IP são feitos quando necessário. Além disso,
pesquisas, desenvolvimento e testes dos protocolos podem ser efetuados em uma
rede em produção; o procedimento ocorre através de documentos de requisição de
comentários (RFC) e a distribuição dos padrões TCP/IP é gratuita. Em contraste, os
protocolos OSI têm direitos autorais e taxas de aquisição.

Esnobismo: A política do TCP/IP foi dirigida para equipamentos conectados nos
Estados Unidos – especificamente organizações acadêmicas, de pesquisas,
governamentais e militares. O modelo OSI, por outro lado, foi produto de um corpo
internacional de padronizações (ISO). Consequentemente, muitos usuários na
Europa encaravam o TCP/IP como um padrão específico dos Estados Unidos e
queriam adotar o OSI. Nos Estados Unidos, entretanto, os usuários não queriam
algo “diferente” e ficaram com o TCP/IP.

Versatilidade e Robustez: Comparado ao modelo OSI, o TCP/IP é simples, tem uma
longa história (mais de 25 anos), é não-proprietário, foi desenvolvido com base em
uma abordagem pragmática e vai ao encontro das necessidades de uma população
diversificada que incluía pesquisadores, educadores e pessoas de negócios.
Algumas pessoas, como por exemplo, Vint Cerf, considerado um dos pais da
Internet e que professa que se tenha “IP sobre tudo”, considera o TCP/IP a
linguagem universal das redes.

A Internet: O TCP/IP está totalmente vinculado à Internet.
Não obstante, o modelo OSI teve um impacto amplo nas redes, inclusive no TCP/IP.
Embora sua aceitabilidade tenha diminuído consideravelmente durante a segunda metade dos anos
90, o modelo OSI continua a fornecer um padrão detalhado para descrever uma rede. É com essa
perspectiva que a comunidade de projeto de redes continua a considerar o modelo OSI como
estrutura conceitual teórica para o desenvolvimento de redes e suas arquiteturas.
1
Termo da física que indica a dificuldade de um objeto entrar em movimento. Neste caso se relaciona com a demora em
realizar um determinado serviço.
60
Dispositivos de Conectividade
Ao montar uma rede, alguns dispositivos são necessários para realizar a transferência dos dados
da máquina de origem com a máquina de destino. Abaixo seguem os dispositivos de conectividade
mais comuns para permitir a comunicação entre máquinas.
4.1
Placas de Rede (NIC – Network Interface Card)
As placas de redes são os dispositivos que conectam o computador ao meio físico
responsável pela transferência dos dados. Ela possui uma identificação que será utilizada para
reconhecer se os dados que estão trafegando pelo meio são para ela ou não. Este endereço é
normalmente composto por 48 bits, sendo que os 24 bits mais significativos são escolhidos por
um órgão internacional de forma que não existam endereços repetidos. Já os 24 bits menos
significativos serão atribuídos pelo fabricante do equipamento. Cabe a este fabricante não utilizar
números repetidos. Esta identificação é conhecida como endereço MAC (Media Access Control
– Acesso de Controle ao Meio). Este equipamento trabalha na camada de enlace do modelo OSI.
4.2
Modems
Os Modems possuem uma finalidade semelhante a da placa de rede, sendo que neste caso,
ele irá conectar o computador ao sistema telefônico. Para isso, ele utiliza uma portadora de
frequência audível, pois o sistema de telefonia foi feito para a transmissão de voz. Em função dos
dados a serem transmitidos, a portadora é modulada, garantindo que os dados não serão “barrados”
pelo sistema de telefonia. Esta é a função moduladora.
Quando os dados chegam ao modem, ele efetua o processo inverso, retirando os bits da
portadora modulada que está chegando. Esta é a função demoduladora. Este mecanismo já foi
comentado na Seção 1.1.8.1. Este equipamento trabalha na camada física do modelo OSI.
4.3
Repetidores
Os repetidores, que nos sistemas digitais também possuem a capacidade de regenerar o sinal,
tem como finalidade inserir mais energia no sinal de um determinado meio para que ele possa
percorrer distâncias maiores. Por exemplo: vamos supor que um determinado cabo de rede possui
um grau de atenuação do sinal permitindo que ele seja transmitido com a certeza de ser
interpretado corretamente apenas por uma distância de 500 metros. Se precisarmos colocar um
equipamento em uma distância superior a essa, será necessária a inserção de um repetidor para
que o sinal seja realimentado e então consiga chegar até o seu destino. Não existe um limite na
quantidade de repetidores que podem ser colocados, logo o alcance de uma rede pode ser qualquer
um, porém, dependendo do método utilizado para o acesso ao meio, determinados limites podem
ser estabelecidos, como será visto no CSMA/CD na Seção 5.1.1.1. Este equipamento trabalha na
camada física do modelo OSI.
4.4
Hubs (Concentradores)
Os hubs possuem a finalidade de interligar diversas máquinas. Ele tem a capacidade de
regenerar o sinal antes de enviar aos equipamentos. A característica mais importante do hub diz
respeito a forma como o sinal é distribuído. Ele funciona como um unificador de equipamentos,
tendo um comportamento semelhante ao de uma rede de barramento. Todo sinal enviado em uma
de suas portas é replicado em todas as outras portas, inclusive na porta que foi feito o envio, para
61
que o protocolo CSMA/CD que será visto na Seção 5.1.1.1 possa ser capaz de escutar e verificar
se houve ou não uma colisão. Este dispositivo trabalha na camada física do modelo OSI.
4.5
Bridges (Pontes)
Como um repetidor, uma bridge é um dispositivo eletrônico que conecta dois segmentos de
LAN. Diferentemente de um repetidor, porém, uma bridge manipula quadros completos e usa a
mesma interface de rede que um computador convencional. A bridge escuta o tráfego em cada
segmento usando o modo promíscuo. Quando a bridge recebe um quadro de um segmento, ela
verifica se o quadro chegou intacto, por exemplo, se não houve nenhuma interferência elétrica na
LAN durante a transmissão, e então encaminha uma cópia do quadro para o outro segmento se
necessário. Deste modo, dois segmentos de LAN conectados por uma bridge se comportam como
uma LAN única. Um computador conectado a qualquer um dos segmentos pode enviar um quadro
para qualquer outro computador conectado a um dos dois segmentos. Como cada segmento
suporta conexões de rede padrão e usa o formato de quadro padrão, os computadores não sabem
se eles estão conectados a uma LAN ou a uma LAN com bridge. A Figura 4.1 ilustra o conceito.
Figura 4.1 – Conexão de dois segmentos por uma Bridge.
As bridges se tornaram mais populares que os repetidores porque ajudam a isolar problemas.
Se dois segmentos são conectados por um repetidor e um raio causa uma interferência elétrica em
um deles, o repetidor propagará a interferência para o outro segmento. Em contraste, se a
interferência acontecer em um de dois segmentos conectados por uma bridge, a bridge recebe um
quadro incorretamente formado, que é simplesmente descartado pela bridge, do mesmo modo que
um computador convencional descartaria um quadro com erro. Semelhantemente, uma bridge
não encaminha uma colisão de um segmento para outro. Deste modo, a bridge evita que eventuais
problemas em um segmento afetem o outro.
A maioria das bridges faz mais do que encaminhar uma cópia de cada quadro de uma LAN
para outra. De fato, uma bridge típica consiste em um computador convencional com uma CPU,
memória e duas interfaces de rede. Uma bridge é dedicada a uma única tarefa e não executa
software aplicativo. Em vez disso, a CPU executa um programa contido na sua ROM. A função
mais valiosa que uma bridge executa é a filtragem de quadros. Uma bridge não encaminha um
quadro a menos que seja necessário. Em particular, se um computador acoplado a um segmento
envia um quadro para um computador no mesmo segmento, a bridge não precisa encaminhar uma
cópia do quadro para o outro segmento. Claro, se a LAN suportar broadcast ou multicast, a bridge
deve encaminhar uma cópia de cada quadro broadcast ou multicast para fazer a LAN estendida
operar como uma grande LAN única.
Para determinar se um quadro deve ser encaminhado, uma bridge usa o endereço físico
(MAC address) encontrado no cabeçalho do quadro. A bridge sabe a localização de cada
computador acoplado às LANs que ela conecta. Quando um quadro chega em um segmento, ela
extrai e verifica o endereço de destino. Se o computador de destino está acoplado ao segmento
através do qual o quadro chegou, então o destino e a bridge receberam a mesma transmissão e
esta descarta o quadro sem encaminhar uma cópia. Se o destino não se situa no mesmo segmento
através do qual o quadro chegou, a bridge envia uma cópia do quadro ao outro segmento.
62
Como uma bridge pode saber quais computadores estão acoplados a quais segmentos? A
maioria das bridges é chamada de adaptativa ou bridges que aprendem (learning bridges) porque
elas aprendem as localizações de computadores automaticamente. Para fazer isso, a bridge escuta
em modo promíscuo os segmentos ligados por ela e forma uma lista de computadores acoplados
a cada segmento. Quando um quadro chega, a bridge executa duas computações. Primeiro, a
bridge extrai o endereço físico de origem do cabeçalho do quadro e acrescenta o endereço à sua
lista de computadores acoplados ao segmento. Segundo, ela extrai o endereço físico de destino
do quadro e usa o endereço para determinar se o quadro deve ser encaminhado. Deste modo,
todas as bridges acopladas a um segmento aprendem que um computador está presente assim que
o computador transmite um quadro. A Figura 4.2 mostra como a bridge da Figura 4.1 pode
aprender as localizações dos computadores.
Evento
Bridge inicializada
U envia para V
V envia para U
Z faz broadcast
Y envia para V
Y envia para X
X envia para W
W envia para Z
Lista do Segmento 1
-------------------------U
U, V
U, V
U, V
U, V
U, V
U, V, W
Lista do Segmento 2
---------------------------------------------------------------------------Z
Z, Y
Z, Y
Z, Y, X
Z, Y, X
Figura 4.2 – Montagem da Tabela de Mapeamento de uma Bridge.
Após cada computador acoplado a um segmento de uma LAN unida por bridges ter enviado
um quadro, as bridges que conectam os segmentos aprendem a localização dos computadores e
usam as informações para filtrarem quadros. Como resultado, o comportamento de uma rede
unida por bridges ligadas por um longo tempo restringe quadros para os mínimos segmentos
necessários.
Obviamente, no momento que a bridge é inicializada, ela não sabe quais computadores estão
acoplados a cada segmento de LAN. Deste modo, uma bridge encaminha quadros destinados a
um computador até que ela determine a localização do computador. De fato, se um computador
não enviasse quaisquer quadros, uma bridge não poderia detectar sua localização e encaminharia
quadros desnecessariamente. Felizmente, os computadores normalmente não permanecem
silenciosos. Um sistema de computador que inclui software de rede normalmente emite pelo
menos um quadro quando o sistema é inicializado. Além disso, a comunicação entre
computadores é normalmente bidirecional, um computador que recebe um quadro normalmente
envia uma resposta. Portanto, as bridges normalmente aprendem as localizações rapidamente.
Como as bridges necessitam analisar o endereço físico de destino, ela trabalha na camada
de enlace do modelo OSI.
4.6
Switches (Comutadores)
O conceito de ligação por bridges ajuda a explicar um mecanismo que está ganhando
popularidade, comutação (switching). Em geral, uma tecnologia de rede é chamada comutada
(switched) se o hardware inclui um dispositivo eletrônico que conecta um ou mais computadores
e permite que eles enviem e recebam dados. Mais especificamente, uma LAN comutada consiste
em um único dispositivo eletrônico que transfere quadros entre muitos computadores.
Fisicamente, um switch se assemelha a um hub. O hub consiste em uma única caixa com
múltiplas portas, cada uma ligada a um único computador. A diferença entre um hub e um switch
surge do modo como os dispositivos operam: um hub simula um meio compartilhado único,
63
enquanto que um switch simula uma LAN unida através de bridges com um computador por
segmento. A Figura 4.3 mostra as conexões conceituais dentro de um switch1.
Figura 4.3 – Esquema Lógico de um Switch.
Não é de se surpreender que a vantagem principal de se usar uma LAN comutada em vez
de um hub é a mesma de se usar uma LAN unida por bridges em vez de um segmento único:
paralelismo. Como um hub simula um segmento único compartilhado por todos os computadores,
no máximo dois computadores podem se comunicar através de um hub em um determinado
tempo. Deste modo, a máxima largura de banda possível de um sistema de hub é T, a taxa em
que um único computador pode enviar dados através de um segmento de LAN. Em uma LAN
comutada, entretanto, cada computador tem um segmento de LAN simulado para si próprio. O
segmento está ocupado apenas quando um quadro estiver sendo transferido de/para o computador.
Como resultado, até metade dos computadores conectados a um switch pode estar enviando dados
ao mesmo tempo, desde que cada um deles esteja enviando para um dos computadores que não
está ocupado enviando dados. Deste modo, a largura de banda máxima possível de um switch é
T n
, onde T é a taxa em que um determinado computador pode transmitir dados e n é o número
2
total de computadores conectados ao switch.
Tal como as bridges, os switches necessitam analisar o endereço físico de destino, tendo
então que trabalhar na camada de enlace do modelo OSI.
4.7
Gateways
Um Gateway, ou porta de ligação, é uma máquina intermediária geralmente destinada a
interligar redes, separar domínios de colisão, ou mesmo traduzir protocolos. Cabe ao gateway
traduzir e adaptar os pacotes originários da rede local para que estes possam atingir o destinatário,
mas também traduzir as respostas e devolvê-las ao par local da comunicação. Assim, é freqüente
1
Na prática, um switch não é construído por bridges independentes. Em vez disso, um switch contém processadores e uma
interconexão central (por exemplo, um cross-bar eletrônico). Um processador examina o endereço de um quadro recebido
e então usa a interconexão central para transferir o quadro para a porta de saída correta.
64
a utilização de protocolos de tradução de endereços, como o NAT — que é das implementações
de gateway mais simples.
Quando um pacote precisa ser enviado, ele é analisado pela camada de redes da origem.
Esta camada se encarrega de verificar se o endereço de destino pertence a mesma rede da máquina
de origem ou a uma rede diferente. No caso de pertencer a mesma rede, o pacote é transferido
para a camada de enlace que se encarrega de identificar a máquina de destino. Caso o destino
pertença a outra rede, este pacote será entregue a camada de enlace com ordens para encaminhálo ao gateway, que se encarregará de transmiti-lo e adequá-lo a rede destino.
Devido a possibilidade de adequação de protocolos em geral, o gateway pode trabalhar em
qualquer camada a partir da camada de redes inclusive.
4.8
Roteadores
Roteador ou router ou encaminhador é um equipamento usado para fazer a comunicação
entre diferentes redes de computadores, tal como um gateway. Este equipamento provê a
comunicação entre computadores distantes entre si e até mesmo com protocolos de comunicação
diferentes.
Roteadores são dispositivos que operam na camada de redes do modelo OSI. A principal
característica dos roteadores é selecionar a porta mais apropriada para repassar os pacotes
recebidos. Ou seja, encaminhar os pacotes para a melhor rota disponível para um determinado
destino.
Os roteadores inicializam e fazem a manutenção de tabelas de rotas executando processos
e protocolos de atualização de rotas, especificando os endereços e domínios de roteamento,
atribuindo e controlando métricas de roteamento. O administrador pode fazer a configuração
estática das rotas para a propagação dos pacotes ou através de processos dinâmicos executando
nas redes. Os roteadores passam adiante os pacotes baseando-se nas informações contidas na
tabela de roteamento. O problema da configuração das rotas estáticas é que, toda vez que houver
alteração na rede que possa vir a afetar essa rota, o administrador deve refazer a configuração
manualmente. Já o conhecimento de rotas dinâmicas é diferente. Depois que o administrador
fizer a configuração através de comandos para iniciar o roteamento dinâmico, o conhecimento das
rotas será automaticamente atualizado sempre que novas informações forem recebidas através da
rede. Essa atualização é feita através da troca de conhecimento entre os roteadores da rede.
4.9
Access Point (Ponto de Acesso – AP)
O Ponto de Acesso – AP é um equipamento que disponibiliza um sinal eletromagnético para
que diversos aparelhos possam acessá-lo sem a necessidade de uma ligação física entre eles. Ele
cria uma bolha de alcance possibilitando a comunicação sem fio (wireless).
Este equipamento pode trabalhar até a camada de redes, oferecendo o recurso de roteamento.
Caso existam diversos APs trabalhando no mesmo local, ou, parte da bolha de um AP está
interferindo na bolha de outro AP, é necessário configurar os APs para trabalharem em canais
diferentes, isto é, freqüências diferentes, para que não haja a destruição dos seus sinais. Para que
um equipamento acesse um AP, ele precisa, antes de mais nada, ter uma placa wireless e em
seguida configurá-la para trabalhar no mesmo canal do AP que se queira contactar. Os diversos
dispositivos que estão utilizando o mesmo AP, e com isso o mesmo canal, terão as suas
transmissões multiplexadas no tempo para que todos tenham condições de utilizar o meio.
65
Método de Acesso ao Meio
Quando possuímos diversos equipamentos ligados através de um meio de comunicação e
desejamos que estes equipamentos se comuniquem entre si, deve-se utilizar algum método para acessar
este meio de comunicação de forma que todos consigam, talvez não ao mesmo tempo, transferir as suas
informações sem que uma máquina destrua a informação da outra.
Neste Capítulo comentaremos alguns métodos utilizados para o acesso ao meio e as arquiteturas
que implementam tais métodos.
5.1
Método de Acesso ao Meio
5.1.1
CSMA
Considerando uma rede local, onde as máquinas podem escutar se existe alguma
portadora no meio de transmissão, isto é, se alguma outra máquina está fazendo uso do meio
para transmitir dados, é possível estruturar um método onde, antes de uma máquina realizar
a sua transmissão, ela verifica se existe alguma outra transmitindo, analisando o meio para
saber se existe alguma portadora. Este protocolo é conhecido por CSMA (Carrier Sense
Multiple Access – Acesso Múltiplo por Detecção de Portadora). Existem algumas variações
deste método, porém nos restringiremos ao CSMA/CD e ao CSMA/CA.
5.1.1.1
CSMA/CD
O protocolo CSMA puro, embora ele verifique se o meio está livre antes de realizar
a transferência dos dados, devido ao retardo oferecido pela propagação do sinal no meio,
existe a possibilidade de uma outra máquina, que também pretende transmitir, ao
verificar o mesmo meio descobrir que ele se encontra livre. Esta segunda máquina pode
ter detectado o meio livre porque o sinal transmitido pela primeira ainda não havia
chegado até ela. Neste caso, esta segunda máquina começará a realizar a transferência
dos seus dados. Em determinado momento, o sinal da primeira máquina se misturará ao
sinal da segunda, levando à perda das duas informações. A este fenômeno dá-se o nome
de colisão.
O protocolo CSMA/CD utiliza uma técnica para detectar a ocorrência de colisão.
A sigla CSMA/CD significa: Carrier Sense Multiple Access with Collision Detection –
Acesso Múltiplo por Detecção de Portadora com Detecção de Colisão. O método
utilizado implica em, durante a transmissão, a máquina transmissora capta o sinal do
meio e verifica se está igual ao que ela está transmitindo. Caso haja alguma mudança,
seja pela incidência de algum ruído, ou a tentativa de uma outra máquina em transmitir
durante a transmissão atual, ocorrerá uma colisão, danificando as informações sendo
transmitidas, sendo necessária a paralisação de ambas as transmissões e então tentar
retransmiti-las.
No caso da colisão, temos que considerar o tempo que o sinal leva para percorrer
o cabo inteiro (t). O pior caso será quando a máquina de uma extremidade começa uma
transmissão e quando o sinal está quase chegando na máquina da extremidade oposta,
esta começa a transmitir, gerando uma colisão logo a seguir. Esta última máquina
detecta quase que instantaneamente a colisão, porém a primeira máquina a iniciar a
transmissão só perceberá que houve colisão quando o sinal adulterado chegar até ela,
isto é, percorrer todo o cabo consumindo o tempo t. Sendo assim, para que tenhamos a
66
garantia de que qualquer máquina seja capaz de detectar uma colisão, ela precisa
permanecer transmitindo, e com isso escutando o meio, por um período de tempo de 2t,
que é o tempo do sinal chegar até a máquina da extremidade oposta mais o tempo da
colisão chegar até a máquina de origem. A Figura 5.1 ilustra este procedimento.
Figura 5.1 – Funcionamento do CSMA/CD.
Considerando que durante a transmissão o equipamento precisa ficar escutando o
meio para detectar a colisão, esta transmissão deverá ser do tipo half-duplex, já que o
equipamento está ocupado transmitindo e escutando o próprio sinal. Com a evolução
das redes, existe uma tendência da implementação do modelo full-duplex, que neste
caso, encerraria a existência de colisões.
67
5.1.1.2
CSMA/CA
Existe um conjunto de tecnologias de rede sem-fio que usam uma forma
modificada de CSMA/CD. Em vez de transmitir sinais através de um cabo, o hardware
de rede sem-fio usa antenas para transmitir sinais de RF através do ar, que outros
computadores recebem. Os dispositivos usam freqüências de 900 MHz para permitir
que sejam enviados dados a 2 Mbps. Como outras tecnologias de rede, as redes sem-fio
usam compartilhamento. Isto é, todos os computadores que participam em uma
determinada rede sem-fio são configurados para usar uma mesma freqüência de rádio.
Deste modo, eles devem se alternar no envio de pacotes.
Uma diferença entre o modo como redes cabeadas e sem-fio administram
compartilhamento surge por causa da forma com que as transmissões sem-fio se
propagam. Embora a energia eletromagnética se irradie em todas as direções, os
transmissores de rede sem-fio usam pouca energia, o que significa que uma transmissão
tem energia suficiente somente para viajar uma distância pequena. Além disso,
obstruções metálicas podem bloquear o sinal. Deste modo, as unidades sem-fio
localizadas em pontos bem distantes ou atrás de obstruções não receberão as
transmissões de outro.
A falta de comunicação completa significa que as redes sem-fio não podem usar o
mesmo mecanismo de CSMA/CD. Para entender por quê, considere três computadores
com hardware de rede sem-fio posicionados longe um do outro como mostra a
Figura 5.2.
Figura 5.2 – Exemplo de Comunicação Sem Fio.
Na figura, os dois computadores de fora (A e C) estão muito longe um do outro
para receberem suas transmissões. Em tais situações, escuta de portadora e detecção de
colisões não bastam. Por exemplo, suponha que o computador A esteja enviando um
pacote para o computador B como mostra a Figura 5.3. Já que o computador C não pode
receber a transmissão, ele poderia realizar uma transmissão, resultando em uma colisão
como mostra a Figura 5.4. Semelhantemente, se ambos os computadores A e C
transmitissem um quadro ao mesmo tempo, somente o computador B poderá detectar
uma colisão.
Figura 5.3 – Transmissão de A para B.
68
Figura 5.4 – Colisão entre A e C.
Para assegurar que eles compartilham os meios de transmissão corretamente, as
redes sem-fio usam um esquema modificado conhecido como CSMA/CA (Carrier
Sense Multiple Access with Collision Avoidance – Acesso Múltiplo por Detecção de
Portadora com Prevenção de Colisão). Em vez de depender de todos os outros
computadores para receberem todas as transmissões, o CSMA/CA usado com redes
sem-fio ativa uma breve transmissão para o receptor pretendido antes de transmitir um
pacote. Por exemplo, suponha que o computador A da Figura 5.2 precisa enviar um
quadro para o computador B. Antes de enviar o quadro, o computador A primeiro
transmite uma breve mensagem de controle indicando a intenção de transmitir um
quadro como mostra a Figura 5.5.
Figura 5.5 – Sinal de Controle para B.
Quando o computador B recebe a mensagem de controle, ele responde enviando
outra mensagem de controle para indicar que está pronto para receber uma transmissão.
Quando o computador A receber a resposta de seu receptor pretendido, ele começa a
transmissão do quadro.
A vantagem de esperar por uma resposta do recipiente se torna clara se for
lembrada daquela transmissão assimétrica. A Figura 5.6, mostra que embora o
computador C não receba a transmissão do computador A, ele recebe a transmissão do
computador B. Deste modo, uma vez que o computador B envia uma resposta, todos os
computadores dentro do alcance de sua antena esperarão pela transmissão de um pacote
(ainda que não possam receber a transmissão).
69
Figura 5.6 – Resposta de B ao Sinal de Controle de A.
Com a transmissão destes dois sinais de controle, cria-se uma região do espaço
onde apenas as máquinas A e B podem transmitir, garantindo que não haverá colisão na
transmissão dos quadros de dados. A Figura 5.7 mostra a região reservada.
Figura 5.7 – Região Reservada para a Comunicação de A com B.
Colisões de mensagens de controle podem acontecer quando se estiver usando
CSMA/CA, mas elas podem ser tratadas facilmente. Na Figura 5.2, por exemplo, se
ambos os computadores A e C geram um pacote para o computador B exatamente ao
mesmo tempo, cada um deles envia uma mensagem de controle. As mensagens de
controle chegarão ao computador B simultaneamente, causando uma colisão. Quando
tais colisões acontecerem, as estações remetentes aplicam o backoff exponencial
aleatório antes de reenviar as mensagens de controle. Como as mensagens de controle
são muito menores que os quadros de dados, a probabilidade de uma segunda colisão é
muito mais baixa do que com o CSMA/CD. Mais cedo ou mais tarde, uma das duas
mensagens de controle chegará intacta, e o computador B transmitirá uma resposta.
5.1.2
Token Passing (Passagem de Token)
Foi dito que uma rede usando uma topologia em anel conecta computadores em um
loop. A maioria das redes que empregam a topologia em anel usa também um mecanismo
de acesso ao meio conhecido como Token Ring (Passagem de Token), e as redes resultantes
são conhecidas como Redes em Anel de Passagem de Token (Token Passing Ring Networks),
abreviadas como Token Ring. Uma rede Token Ring opera como um meio único,
70
compartilhado. Quando um computador precisa enviar dados, o computador deve esperar
uma permissão antes de poder acessar a rede. Uma vez que ele obtém permissão, o
computador remetente tem completo controle do anel, logo, nenhuma outra transmissão
acontece simultaneamente. Quando o computador remetente transmite um quadro, os bits
passam do remetente para o próximo computador, então para o próximo e assim por diante,
até que os bits passem completamente em torno do anel e voltem ao remetente. A Figura 5.8
ilustra o conceito onde o computador A é o remetente, logo ele retém o Token e então
transmite um pacote de dados cujo destinatário é o computador E.
Figura 5.8 – Funcionamento do Token Passing.
Como mostra a Figura 5.8, todas as estações exceto o remetente encaminham adiante
bits em torno do anel. Deste modo, para verificar que nenhum erro de transmissão ocorreu,
um remetente pode comparar os dados sendo recebidos com os dados sendo enviados. Outras
estações monitoram todas as transmissões. Se um quadro é destinado a um dado computador,
aquele computador faz uma cópia do quadro à medida que os bits passam pelo anel.
71
5.2
Arquitetura
5.2.1
Ethernet
A estrutura original de quadros DIX (DEC, Intel, Xerox) é mostrada na Figura 5.9.
Cada quadro começa com um Preâmbulo de 8 bytes, cada um contendo o padrão de bits
10101010. A codificação Manchester desse padrão produz uma onda quadrada de 10 MHz
durante 6,4 µs, a fim de permitir a sincronização entre o clock do receptor e o clock do
transmissor, como foi explicado na Seção 1.1.10.2.1 na Figura 1.30. Eles devem permanecer
sincronizados durante todo o restante do quadro, usando a codificação Manchester para
controlar os limites de bits.
Figura 5.9 – Formato de Quadros DIX.
O quadro contém dois endereços, um para o destino e um para a origem. O padrão
permite endereços de 2 e de 6 bytes, mas os parâmetros definidos para o padrão de banda
básica de 10 Mbps usam somente os endereços de 6 bytes. O bit de alta ordem do endereço
de destino é 0 para endereços comuns e 1 para endereços de grupo. Os endereços de grupos
permitem que diversas estações escutem um único endereço. Quando um quadro é enviado
para um endereço de grupo, todas as estações do grupo recebem. A transmissão para um
grupo de estações é chamada de multidifusão (multicast). O endereço que consiste em todos
os bits 1 é reservado para difusão (broadcast). Um quadro contendo todos os bits 1 no campo
destino é aceito por todas as estações da rede. A diferença entre multicast e broadcast é
importante o bastante para ser repetida. Um quadro de multicast é transmitido para um grupo
selecionado de estações na Ethernet. O multicast é mais seletivo, mas envolve o
gerenciamento de grupos. O broadcast é menos seletivo, fazendo com que todas as máquinas
da rede recebam o quadro e com isso, não requer qualquer gerenciamento de grupos.
Outra característica interessante do endereçamento é o uso do bit 46 (adjacente ao bit
de mais alta ordem) para distinguir endereços locais de endereços globais. Os endereços
locais são atribuídos pelo administrador da rede e não têm significado fora da rede local. Os
endereços globais, ao contrário, são atribuídos pelo IEEE para assegurar que duas estações
de qualquer lugar do mundo nunca tenham o mesmo endereço global. Com os 46 bits
restantes disponíveis, pode-se gerar 2 46 endereços globais, isto é, 70.368.744.177.664 (cerca
de 70 trilhões) endereços globais. A idéia é que qualquer estação possa endereçar
exclusivamente qualquer outra estação, fornecendo apenas o número de 48 bits correto. Cabe
à camada da rede descobrir como localizar o destino.
Em seguida, vem o campo Tipo, que informa ao receptor o que fazer com o quadro.
Vários protocolos da camada de rede podem estar em uso ao mesmo tempo na mesma
máquina, assim, ao chegar um quadro Ethernet, o kernel tem de saber a qual deles deve
entregar o quadro.
Depois, vêm os dados, com até 1.500 bytes. Esse limite foi escolhido de forma um
tanto arbitrária na época em que o padrão DIX foi esculpido em pedra, principalmente com
base no fato de que um transceiver precisa ter memória RAM suficiente para guardar um
quadro inteiro e, em 1978, a RAM tinha um custo muito alto. Um limite superior significaria
mais RAM e, conseqüentemente, um transceiver mais caro.
Além de haver um comprimento máximo de quadro, também existe um comprimento
mínimo. Embora um campo de dados de 0 byte às vezes seja útil, ele causa um problema.
Como o padrão Ethernet utiliza o CSMA/CD como método de acesso ao meio, quando se
72
detecta uma colisão, um transceiver trunca o quadro atual, o que significa que bits perdidos
e fragmentados de quadros aparecem a todo instante no cabo. Para tornar mais fácil a
distinção entre quadros válidos e lixo, o padrão Ethernet exige que os quadros válidos tenham
pelo menos 64 bytes de extensão, do endereço de destino até o campo de CRC, incluindo
ambos. Se a parte de dados de um quadro for menor que 46 bytes, o campo Preenchimento
será usado para preencher o quadro até o tamanho mínimo.
Outro (e mais importante) motivo para a existência de um quadro de comprimento
mínimo é impedir que uma estação conclua a transmissão de um quadro curto antes que tenha
passado o tempo mínimo necessário para detectar a ocorrência de uma colisão. Este tempo
é definido como duas vezes o tempo de propagação do sinal da máquina de um extremo do
cabo até a máquina do extremo oposto, como foi visto na Seção 5.1.1.1, quando falamos do
CSMA/CD.
Para que o sistema de detecção de colisão funcione, deve-se estabelecer um limite de
comprimento da rede de forma que o tempo máximo de propagação do sinal de uma
extremidade a outra seja estabelecido. De acordo com o padrão 802.3, o barramento deveria
ter um comprimento máximo de 2.500 metros, contendo 5 seções de cabo coaxial grosso do
tipo 10 base 5 conectados por 4 repetidores. Ao medir o tempo de propagação do sinal de
uma extremidade a outra obteve-se 25 µs, logo o tempo de ida e volta será de 50 µs.
Utilizando uma taxa de transmissão de 10 Mbps, o tamanho do quadro pode ser calculado
através da seguinte fórmula:. Quadro  Taxa  Tempo , sendo assim, obteremos como
tamanho
mínimo
para
um
quadro
Ethernet
o
valor
de
6
6
Quadro  10  10  50  10  500 bits , onde foi arredondado para 512 bits, ou seja
64 bytes. Foi daí que surgiu a limitação comentada anteriormente de que o quadro Ethernet
não poderia ter menos do que 64 bytes entre o endereço de destino e o CRC.
Com o melhoramento das tecnologias e aumentando o tráfego na rede, houve a
necessidade de investir no aumento na taxa de transmissão. Uma primeira evolução foi
passar a taxa de 10 Mbps para 100 Mbps que foi denominada de Fast Ethernet. Ao
multiplicarmos a taxa por 10, o tamanho mínimo do quadro passara para 640 bytes. Isso
causaria problemas de compatibilidade com a Ethernet original de 10 Mbps. Como nesta
época o uso de barramento era reduzido e começou-se a utilizar a topologia de tipo estrela
onde os computadores eram ligados a um equipamento central através de cabos de par
trançado, uma alternativa para manter a compatibilidade era manter o tamanho do quadro em
64 bytes, porém diminuindo o tamanho da rede em 10 vezes, levando a uma distância máxima
entre os equipamentos de 250 metros. Em se tratando de uma rede local, este tamanho
resolvia a maioria dos casos.
Algum tempo depois veio a rede Ethernet com 1 Gbps conhecida como Gigabit
Ethernet. Neste caso, para manter a padronização inicial de quadros com 64 bytes o tamanho
máximo entre as máquinas deve ser de 25 metros. Esta restrição se vê necessária para que o
mecanismo de detecção de colisão funcione corretamente, porém, se usarmos uma forma de
conexão entre máquinas que não ofereça o risco de colisão, pode-se aumentar o tamanho do
cabo, pois mesmo passando a não ser capaz de detectar colisões, esta detecção não seria
necessária. Uma forma de tornar desnecessária a detecção da colisão é fazer a ligação direta
de um equipamento a outro, não havendo o compartilhamento do meio que os conecte. Desta
forma, sem compartilhamento, não haverá como uma terceira máquina provocar uma colisão
e ainda possibilita a comunicação full-duplex. Com o barateamento e a popularização dos
switches, que são equipamentos de interconexão que possibilitam a ligação direta de dois
equipamentos, a rede Gigabit Ethernet pode ser implementada utilizando-se cabos superiores
73
a 25 metros entre as máquinas e mantendo o padrão de 64 bytes para o tamanho mínimo dos
quadros.
5.2.1.1
O Algoritmo de Recuo Binário Exponencial
Vejamos agora como é feita a randomização quando ocorre uma colisão. Depois
de uma colisão ser detectada, o tempo é dividido em slots discretos, cuja duração é igual
ao pior tempo de propagação do sinal de ida e volta no meio. No caso do padrão
Ethernet, o tempo de duração do slot foi definido como sendo de 51,2 µs, já que o quadro
foi arredondado para um tamanho mínimo de 512 bits (64 bytes), como foi mencionado
na seção anterior.
Depois da primeira colisão, cada estação espera 0 ou 1 tempo de slot antes de
tentar novamente. Se duas estações colidirem e selecionarem o mesmo número
aleatório, elas colidirão novamente. Depois da segunda colisão, cada uma seleciona ao
acaso 0, 1, 2 ou 3 e aguarda esse número de tempos de slot. Se ocorrer uma terceira
colisão, cuja probabilidade é de 25%, na próxima vez o número de slots que a estação
deverá esperar será escolhido ao acaso no intervalo de 0 a 2 3  1 .
Em geral, depois de i colisões, é escolhido um número aleatório entre 0 e 2 i  1 ,
e esse número de slots será ignorado. Entretanto, após terem sido alcançadas 10
colisões, o intervalo de randomização será congelado em um máximo de 1.023 slots.
Depois de 16 colisões, o controlador desiste e informa o erro ao computador. Qualquer
recuperação adicional caberá às camadas superiores.
Esse algoritmo, chamado de recuo binário exponencial, foi escolhido para se
adaptar dinamicamente ao número de estações que estão tentando transmitir. Se o
intervalo de escolha do número aleatório para todas as colisões fosse 1.023, a chance de
duas estações colidirem uma segunda vez seria desprezível, mas o tempo de espera
médio depois de uma colisão seria de centenas de períodos de slot, introduzindo um
retardo significativo. Por outro lado, se cada estação sempre esperasse durante 0 ou 1
slot, e se 100 estações tentassem transmitir ao mesmo tempo, elas colidiriam repetidas
vezes até que 99 delas escolhessem 1 e a estação restante escolhesse 0. Isso poderia
levar anos. Aumentando-se exponencialmente o intervalo de randomização à medida
que ocorre um número cada vez maior de colisões consecutivas, o algoritmo assegura
um baixo retardo quando apenas algumas estações colidem, mas também garante que a
colisão será resolvida em um intervalo de tempo razoável quando muitas estações
colidirem. A restrição do recuo a 1.023 impede que o limite cresça demais.
Como descrevemos até agora, o CSMA/CD não fornece nenhuma confirmação.
Como a simples ausência de colisões não garante que os bits não foram adulterados por
picos de ruído no cabo, para obter uma comunicação confiável, o destino deve conferir
o CRC e, se ele estiver correto, deve transmitir um quadro de confirmação para a origem.
Normalmente, essa confirmação seria apenas outro quadro no que se refere ao protocolo,
e teria de disputar o tempo do canal, assim como qualquer outro quadro de dados.
Contudo, uma simples modificação no algoritmo de disputa permitiria uma confirmação
mais rápida da recepção do quadro. Seria necessário apenas reservar o primeiro slot de
disputa após cada transmissão bem sucedida para a estação de destino. Infelizmente, o
padrão não oferece essa possibilidade.
5.2.2
Token Ring
Como um remetente obtém permissão para transmitir em um Token Ring?
Diferentemente da Ethernet, uma transmissão de Token Ring não conta com CSMA/CD. Em
74
vez disso, o hardware de Token Ring coordena entre todos os computadores conectados para
assegurar que a permissão seja passada a cada computador um de cada vez. A coordenação
usa uma mensagem especial reservada chamada Token. O Token é um padrão de bits que
difere de quadros de dados normais. Para assegurar que dados normais não possam ser
interpretados como um Token, algumas tecnologias de Token Ring usam bit stuffing1 para
mudar temporariamente ocorrências do Token em dados para transmissão no anel. Mais
importante, o hardware de Token assegura que existe exatamente um Token em uma rede de
Token Ring.
Essencialmente, um Token dá uma permissão ao computador para enviar um quadro.
Desse modo, antes de poder enviar um quadro, um computador deve esperar pelo Token
chegar. Quando um Token chegar, o computador remove temporariamente o Token do anel
e usa o anel para transmitir dados. Embora possa ter mais de um quadro esperando para ser
enviado, o computador envia apenas um quadro e então transmite o Token. Diferentemente
de quadros de dados, que giram completamente em torno do anel enquanto estão sendo
enviados, o Token viaja de um computador diretamente para outro adjacente, que pode então
usar a rede para enviar um quadro.
Se todos os computadores em uma rede de Token Ring têm dados para enviar, o
esquema de Token Ring garante que eles irão se alternar, com cada computador enviando um
quadro antes de passar o Token. Note que o esquema garante acesso justo: com a passagem
do Token pelo anel, cada computador tem uma oportunidade para usar a rede. Se um
determinado computador não tem dados para enviar quando ele recebe o Token, o hardware
de interface meramente passa o Token adiante sem atraso. No caso extremo em que nenhuma
estação tem dados para transmitir, o Token circula continuamente, com cada estação
recebendo o Token e então passando o mesmo imediatamente para o próximo computador.
O tempo exigido para um Token fazer uma viagem completa ao redor de um anel de
computadores ociosos é extremamente breve (por exemplo, um milissegundo). Este tempo
breve é possível por duas razões. Primeiro, porque o Token é pequeno e pode ser transmitido
rapidamente através de um único fio. Segundo, o Token é manipulado pelo hardware em
anel, o que significa que a velocidade não depende da CPU do computador.
5.2.3
Wireless (Redes sem Fio)
Quase na mesma época em que surgiram os notebooks, muitas pessoas sonhavam com
o dia em que entrariam em um escritório e magicamente seu notebook se conectaria à
Internet. Em conseqüência disso, diversos grupos começaram a trabalhar para descobrir
maneiras de alcançar esse objetivo. A abordagem mais prática é equipar o escritório e os
notebooks com transmissores e receptores de rádio de ondas curtas para permitir a
comunicação entre eles. Esse trabalho levou rapidamente à comercialização de redes semfio por várias empresas.
O problema era encontrar duas delas que fossem compatíveis. Essa proliferação de
padrões significa que um computador equipado com um rádio da marca X não funcionaria
em uma sala equipada com uma estação-base da marca Y. Finalmente, a indústria decidiu
que um padrão de rede sem-fio poderia ser uma boa idéia, e assim o comitê do IEEE que
padronizou as redes com fio recebeu a tarefa de elaborar um padrão de redes sem-fio. O
padrão recebeu o nome 802.11. Um apelido comum para ele é WiFi. Trata-se de um padrão
importante e que merece respeito, e assim vamos chamá-lo por seu nome correto, 802.11.
1
Técnica utilizada para camuflar seqüências de bits especiais de forma que não sejam interpretados erroneamente pelo
sistema de transmissão.
75
O padrão proposto tinha de funcionar em dois modos:

Na presença de uma estação base;

Na ausência de uma estação base.
No primeiro caso, toda a comunicação deveria passar pela estação-base, chamada de
access point – AP (ponto de acesso) na terminologia do 802.11. Este padrão está ilustrado
na Figura 5.10. No outro caso, os computadores simplesmente transmitiriam diretamente uns
para os outros. Agora, esse modo costuma ser chamado interligação de redes ad hoc. Um
exemplo típico é de duas ou mais pessoas juntas em uma sala não equipada com uma rede
sem-fio, fazendo seus computadores se comunicarem diretamente. Este padrão está ilustrado
na Figura 5.11.
Figura 5.10 – Rede Sem Fio com uma Estação-Base (AP).
Figura 5.11 – Rede Sem Fio Ad Hoc.
A primeira decisão foi a mais fácil: como denominá-lo. Todos os outros padrões de
redes tinham números como 802.1, 802.2, 802.3, até 802.10; assim, o padrão de redes sem
fio recebeu a denominação 802.11. O resto era mais difícil.
Em particular, alguns dos muitos desafios que tinham de ser enfrentados eram:

Descobrir uma banda de freqüências adequada que estivesse disponível, de
preferência em todo o mundo;

Lidar com o fato de que os sinais de rádio têm um alcance finito;

Assegurar que a privacidade dos usuários seria mantida;

Levar em conta a duração limitada da bateria;

Considerar a segurança humana (as ondas de rádio causam câncer);

Compreender as implicações da mobilidade dos computadores;
76

Construir um sistema com largura de banda suficiente para ser economicamente
viável
Na época em que o processo de padronização começou (meados da década de 1990), a
Ethernet já havia dominado o mercado de redes locais, e assim o comitê decidiu tornar o
802.11 compatível com a Ethernet acima da camada de enlace. Em particular, deve ser
possível enviar um pacote IP pela rede sem-fio, do mesmo modo que um computador
conectado envia um pacote IP pela Ethernet. Apesar disso, existem várias diferenças
inerentes em relação à Ethernet na camada física e na camada de enlace de dados, e essas
diferenças tinham de ser tratadas pelo padrão.
Em primeiro lugar, um computador na Ethernet sempre escuta o meio antes de
transmitir. Somente se o meio estiver ocioso o computador inicia a transmissão. No caso
das redes sem-fio, essa idéia não funciona muito bem, como foi visto na Seção 5.1.1.2.
O segundo problema que tinha de ser resolvido era a possibilidade de objetos sólidos
refletirem o sinal de rádio, de forma que o sinal pudesse ser recebido várias vezes (ao longo
de diversos caminhos). Essa interferência resulta naquilo que se denomina atenuação
multiponto.
O terceiro problema é que grande parte do software não está ciente da mobilidade. Por
exemplo, muitos processadores de testos tem uma lista de impressoras que os usuários podem
escolher para imprimir um arquivo. Quando o computador no qual o processador de textos
funciona é levado para um novo ambiente, a lista de impressoras se torna inválida.
O quarto problema é que, se um notebook for afastado da estação-base (AP) que ele
está utilizando e entrar na faixa de alcance de uma estação base diferente, será necessário
alguma forma de transferência. Embora ocorra com telefones celulares, esse problema não
acontece com a Ethernet e precisa ser resolvido. Tipicamente, a rede prevista consiste em
várias células, cada uma com sua própria estação-base, e com as estações-base conectadas
pela Ethernet, como mostra a Figura 5.12. Visto do exterior, o sistema inteiro deve ser
semelhante a uma única Ethernet. A conexão entre o sistema 802.11 e o mundo exterior é
chamado portal.
Figura 5.12 – Uma Rede 802.11 de Várias Células.
Após algum trabalho, o comitê apresentou um padrão em 1997 que tratou dessas e de
outras questões. A rede sem-fio que ele descreveu funcionava a 1 Mbps ou 2 Mbps. Quase
imediatamente, as pessoas reclamaram que ela era muito lenta, e assim começou o trabalho
em padrões mais rápidos. Uma divisão se desenvolveu dentro do comitê, resultando em dois
novos padrões publicados em 1999. O padrão 802.11a utiliza uma faixa de freqüência mais
77
larga e funciona em velocidades de 54 Mbps. O padrão 802.11b utiliza a mesma faixa de
freqüências que o 802.11, mas emprega uma técnica de modulação diferente para alcançar
11 Mbps. Algumas pessoas vêem esse fato como algo psicologicamente importante, tendo
em vista que 11 Mbps é mais rápido que a Ethernet fisicamente conectada original. É
provável que o padrão original de 1 Mbps, o 802.11, desapareça rapidamente, mas ainda não
está claro qual dos novos padrões ocupará seu lugar.
Para tornar a questão ainda mais complicada do que já era, o comitê 802 apresentou
ainda outra variante, o 802.11g, que utiliza a técnica de modulação do 802.11a, mas emprega
a faixa de freqüências do 802.11b.
Não há dúvida que o 802.11 causará uma revolução na computação e no acesso à
Internet. Aeroportos, estações de trem, hotéis, centros comerciais e universidades estão
instalando rapidamente essas redes. Até mesmo as lojas de cibercafés estão instalando o
802.11, para que os yuppies reunidos possam navegar pela Web enquanto apreciam sua
bebida. É provável que o 802.11 faça pela Internet o que os notebooks fizeram pela
computação: torná-la móvel.
78
Tecnologias para conexão digital de longa distância
6.1
X.25
A rede X.25 foi a primeira rede pública de dados. Ela foi desenvolvida na década de 1970,
em uma época na qual o serviço de telefonia era um monopólio em todos os lugares, e a empresa
de telefonia em cada país esperava que houvesse uma única rede de dados por país, a dela. Para
usar a X.25, primeiro um computador estabelecia uma conexão com o computador remoto, isto é,
fazia uma chamada telefônica. Essa conexão recebia um número de conexão que seria usado em
pacotes de transferência de dados (porque várias conexões poderiam estar abertas ao mesmo
tempo). Os pacotes de dados eram muito simples, consistindo em um cabeçalho de 3 bytes e até
128 bytes de dados. O cabeçalho tinha um número de conexão de 12 bits, um número de sequência
de pacote, um número de confirmação e alguns bits variados. As redes X.25 operaram por cerca
de uma década com relativo sucesso.
6.2
Frame Relay (FR)
Na década de 1980, as redes X.25 foram substituídas em grande parte por um novo tipo de
rede chamado frame relay. A essência do frame relay é o fato de ser uma rede orientada a conexão
sem controle de erros e nenhum controle de fluxo. Por se tratar de uma rede orientada a conexões,
os pacotes eram entregues em ordem (quando eram entregues). Nas propriedades de entrega em
ordem, nenhum controle de erros e nenhum controle de fluxo tornavam o frame relay semelhante
a uma LAN de área extensa. Sua aplicação mais importante é a interconexão de LANs instaladas
em vários escritórios de uma empresa. O frame relay pode trabalhar com PVCs (Permanent
Virtual Circuits – Circuitos Virtuais Permanentes) ou SVCs (Switched Virtual Circuits – Circuitos
Virtuais Chaveados).
6.3
ATM
Outra rede orientada a conexões, e muito mais importante, é o ATM (Asynchronous
Transfer Mode – Modo de Transferência Assíncrona). O nome um pouco estranho é explicado
pelo fato de, no sistema de telefonia, a maioria das transmissões ser síncrona, mas não o ATM.
O ATM foi projetado no início da década de 1990 e lançado em meio a uma agitação
verdadeiramente incrível. O ATM prometia resolver todos os problemas de redes e
telecomunicações do mundo, mesclando voz, dados, televisão a cabo, telex e todos os outros
meios de comunicação em um único sistema integrado que poderia fazer tudo para todos. Isso
não aconteceu. Em grande parte, os problemas eram semelhantes aos que descrevemos antes em
relação ao OSI, isto é, momento, tecnologia, implementação e política ruins. Tendo simplesmente
derrubado as empresas de telefonia no primeiro round, muitas pessoas na comunidade da Internet
viram no ATM a sequência da luta da Internet contra as empresas de telecomunicações. Porém,
isso não era verdade e, desse momento em diante, até mesmo os fanáticos por datagramas
concluíram que a qualidade de serviço da Internet deixava muito a desejar. Para encurtar a
história, o ATM teve muito mais sucesso que o OSI, e agora, é amplamente utilizado dentro do
sistema de telefonia para mover pacotes IP. Por ser utilizada principalmente pelas operadoras
para transporte interno, muitas vezes os usuários não percebem sua existência, mas, sem dúvida,
ele estará vivo e muito bem.
79
6.3.1
Circuitos Virtuais do ATM
Tendo em vista que as redes ATM são orientadas a conexões, o envio de dados exige
primeiro o envio de um pacote para reconfigurar a conexão. À medida que o pacote de
configuração passa pela sub-rede, todos os roteadores no caminho inserem uma entrada em
suas tabelas internas registrando a existência da conexão e reservando os recursos necessários
para ela. Com freqüência, as conexões são chamadas de circuitos virtuais, em uma analogia
com os circuitos físicos utilizados no sistema telefonia. A maioria das redes ATM também
admite circuitos virtuais permanentes, que são conexões permanentes entre duas máquinas
(distantes). Eles são semelhantes a linhas dedicadas no universo da telefonia. Cada conexão,
temporária ou permanente, tem um identificador de conexão exclusivo.
Uma vez estabelecida uma conexão, um ou outro lado pode iniciar a transmissão de
dados. A idéia básica por trás do ATM é transmitir todas as informações em pequenos
pacotes de tamanho fixo chamados células. As células têm 53 bytes, dos quais 5 bytes
formam o cabeçalho e 48 bytes são a carga útil. Uma parte do cabeçalho é o identificador da
conexão, e assim, as máquinas transmissoras e receptoras e todos os roteadores
intermediários podem saber quais células pertencem a cada conexão. Essa informação
permite que cada roteador saiba como rotear cada célula de entrada. O roteamento de células
é feito em hardware, em alta velocidade. De fato, o principal argumento para se ter células
de tamanho fixo é a facilidade para construir roteadores de hardware capazes de tratar células
curtas de comprimento fixo. Pacotes IP de comprimento variável têm de ser roteados por
software, um processo mais lento. Outra vantagem do ATM é a possibilidade de configurar
o hardware para copiar uma célula de entrada em várias linhas de saída, uma propriedade
necessária para manipular um programa de televisão que esteja sendo transmitido por difusão
a muitos receptores. Por fim, células pequenas não bloqueiam nenhuma linha por muito
tempo, o que torna mais fácil garantir a qualidade de serviço.
Todas as células seguem a mesma rota até o destino. A entrega de células não é
garantida, mas sua ordem sim. Se as células 1 e 2 forem enviadas nessa ordem, se ambas
chegarem, elas chegarão nessa ordem, nunca 2 antes de 1. Porém, uma delas ou ambas podem
se perder no caminho. Cabe aos níveis de protocolos mais altos recuperar células perdidas.
Observe que, embora essa garantia não seja perfeita, é melhor que a garantia oferecida pela
Internet. Lá, os pacotes não só podem se perder, mas também podem ser entregues fora de
ordem. Em contraste, o ATM garante nunca entregar células fora de ordem.
As redes ATM são organizadas como WANs tradicionais, com linhas e roteadores. As
velocidades mais comuns para redes ATM são 155 Mbps e 622 Mbps, embora sejam
admitidas velocidades mais altas. A velocidade de 155 Mbps foi escolhida por possibilitar a
transmissão de imagens de televisão de alta definição. A escolha de exatamente 155,52 Mbps
se deu por uma questão de compatibilidade com o sistema de transmissão SONET da AT&T.
A velocidade de 622 Mbps foi escolhida para permitir que quatro canais de 155 Mbps
pudessem ser enviados através dela.
6.4
ISDN
Um dos primeiros esforços para se fornecer serviços digitais de larga escala para os
assinantes foi lançado pelas companhias telefônicas sob o nome de ISDN (Integrated Services
Digital Network – Rede Digital de Serviços Integrados). O ISDN fornece voz e dados
digitalizados para assinantes através do cabeamento de loop local convencional. Isto é, o ISDN
usa o mesmo tipo de cabeamento de cobre de par trançado que o sistema telefônico analógico.
Do ponto de vista de um assinante, o ISDN oferece três canais digitais separados,
designados B, B e D (normalmente escritos 2B+D). Os dois canais B, que operam cada um em
80
uma velocidade de 64 Kbps, são para o transporte de voz digitalizada, dados ou vídeo
comprimido; o canal D, que opera a 16 Kbps, serve como um canal de controle1. Em geral, um
assinante usa o canal D para solicitar serviços que são então providos através dos canais B, por
exemplo, fazer um telefonema que usa voz digital. O assinante também usa o canal D para
administrar uma sessão que está em andamento ou para terminar uma sessão. Finalmente, os dois
canais B podem ser combinados ou unidos para se produzir um único canal com uma taxa de
dados efetiva de 128 Kbps.
Os canais 2B+D são conhecidos como ISDN Basic Rate Interface (BRI). De fato, o ISDN
usa uma forma de multiplexação por divisão de tempo para fornecer a ilusão de múltiplos canais
de dados viajando através de um único par de fios.
Quando as companhias telefônicas definiram primeiramente o ISDN muitos anos atrás,
64 Kbps parecia rápido se comparado a modems dial-up, que operavam a menos que 10 Kbps.
As companhias telefônicas esperavam que os clientes usassem o ISDN para as comunicações
digitais locais e de longa distancia de forma análoga ao modo que eles usam o sistema telefônico
de voz. Com o passar dos anos, porém, os modems dial-up melhoraram, e foram inventadas
tecnologias alternativas que forneceram taxas de dados altas através do loop local com custo
baixo. Consequentemente, o ISDN agora é uma alternativa cara que oferece pequena largura de
banda.
6.5
xDSL
Um dos tipos mais impressionantes da nova tecnologia para fornecimento de serviços
digitais através de loop local é conhecido como DSL (Digital Subscriber Line – Linha Digital de
Assinante). De fato, existem diversas variantes. Como os nomes diferem pela primeira palavra,
o conjunto é coletivamente chamado através da sigla xDSL.
A tecnologia de xDSL que talvez seja a mais interessante é conhecida com ADSL
(Asymmetric Digital Subscriber Line – Linha Digital de Assinante Assimétrica). Do ponto de
vista de um assinante, o ADSL fornece a habilidade de se enviar e receber informações digitais
em alta velocidade. Como o nome indica, entretanto, o serviço é assimétrico. No caso do ADSL,
a assimetria deriva da taxa de transferência. A largura de banda disponível é dividida para se
tornar a taxa de transferência em uma direção muito mais alta do que na outra.
Para entender a motivação para a assimetria, pense sobre como uma pessoa média usa a
Internet. A maioria do tráfego é gerada quando a pessoa navega pela Web ou faz download de
arquivos. Em ambos os casos, o tráfego que o indivíduo envia para a Internet consiste em
pequenas solicitações, por exemplo, alguns bytes de dados. Porém, o tráfego que flui de volta da
Internet para o usuário pode conter milhões de bytes de dados, por exemplo, imagens
digitalizadas. Para distinguir as duas direções, os profissionais usam o termo downstream para se
referir a dados fluindo para o usuário, e upstream para se referir a dados fluindo a partir do usuário.
O loop do assinante pode ser otimizado para tráfego assimétrico se estiver alocando a largura de
banda de maneira a fornecer uma taxa de transferência mais alta para downstream.
Do ponto de vista do usuário, a otimização oferece a vantagem de permitir que as páginas
da Web sejam mostradas mais depressa do que uma solução simétrica permitiria. Claro, a
assimetria torna o ADSL impróprio para conexões que enviam mais dados do que recebem. Por
exemplo, um negócio que tem um catálogo on-line disponível para clientes não se beneficiaria do
ADSL porque o negócio tenderia a enviar mais dados do que recebe.
1
Embora o usuário tenha um total de 144 Kbps disponível, o sistema subjacente opera a 160 Kbps; os 16 Kbps restantes são
consumidos por sincronização e enquadramento.
81
Quão rápido o ADSL pode operar? A taxa máxima de downstream atinge um valor
espantoso de 6,144 Mbps, e a taxa máxima upstream atinge 640 Kbps.
Embora as taxas de dados sejam surpreendentemente altas, o aspecto mais surpreendente do
ADSL advém do cabeamento físico através do qual ele alcança tais taxas de dados e o modo que
ele usa esse cabeamento. O ADSL não exige quaisquer mudanças no cabeamento de loop local
porque é projetado para correr sobre o mesmo cabeamento de par trançado que foi originalmente
instalado para o serviço telefônico analógico. Além disso, o ADSL não interrompe o loop local,
ele pode executar simultaneamente através dos mesmos fios que o serviço telefônico padrão.
Desse modo, o ADSL tem uma vantagem econômica óbvia: as companhias telefônicas podem
usá-lo para prover serviço digital de alta velocidade sem recabear o loop local.
Como o ADSL alcança taxas altas de dados sobre par trançado? Os pesquisadores primeiro
observaram que um esquema como o ADSL poderia ser possível porque muitos loops locais
acomodam sinais em frequências mais altas do que aquelas usadas pelo sistema telefônico. A
solução ADSL é complexa porque não há dois loops locais com características idênticas. Em vez
disso, a habilidade de transportar sinais depende da distância, do tipo de cabeamento usado e do
nível de interferência elétrica. Desse modo, os projetistas não podiam escolher um conjunto
particular de frequências portadora ou técnicas de modulação que funcionariam em todos os casos.
Por exemplo, considere dois assinantes que vivem em partes diferentes de uma cidade. Se a linha
telefônica que está indo ao primeiro assinante passa próxima a uma estação de rádio comercial, o
sinal da estação causará interferência na frequência que a estação usa. Se o segundo assinante
não vive próximo à mesma estação de rádio, a frequência que a estação de rádio usa pode
funcionar bem para dados naquela linha do assinante. Porém, a segunda linha pode sofrer
interferência em outra frequência.
Para acomodar as diferenças em características de loop local, o ADSL é adaptativa. Ou
seja, quando os modems ADSL são ligados, eles examinam a linha entre eles para descobrir suas
características, e então concordam em se comunicar usando técnicas que são ótimas para a linha.
Em particular, o ADSL usa um esquema conhecido como modulação DMT (Discrete Multi
Tone – Multi Tom Discreto), que combina multiplexação por divisão de freqüência e técnicas de
multiplexação inversa.
A multiplexação por divisão de frequência no DMT é implementada dividindo-se a largura
de banda em 286 frequências separadas ou subcanais1, com 255 frequências usadas para
transmissão downstream de dados, 31 usadas para transmissão upstream de dados e 2 usadas para
informações de controle. Conceitualmente, existe um “modem” separado executando em cada
subcanal, que tem sua própria portadora modulada. As portadoras são espaçadas em intervalos
de 4,1325 KHz para evitar que os sinais interfiram um com o outro. Além disso, para garantir
que suas transmissões não interfiram com sinais de telefonia analógica, o ADSL evita usar a
largura de banda abaixo de 4 KHz. Quando o ADSL inicia, ambas as pontas examinam as
frequências disponíveis para determinar que sinais passam e que sinais experimentam
interferência. Além de selecionar as frequências, as duas pontas avaliam a qualidade do sinal em
cada frequência e usam a qualidade para selecionar um esquema de modulação. Se uma
frequência em particular tem uma relação sinal-ruído alta, o ADSL seleciona um esquema de
modulação que codifica muitos bits por baud. Se a qualidade em uma determinada frequência é
baixa, o ADSL seleciona um esquema de modulação que codifica menos bits por baud.
1
A terminologia surge porque a capacidade de uma conexão ADSL pode ser dividida em canais de 1,544 Mbps conectados
cada um a um circuito T1.
82
O resultado da adaptação é uma tecnologia robusta que pode se adaptar a várias condições
de linha automaticamente. Do ponto de vista de um usuário, a adaptação tem uma propriedade
interessante: o ADSL não garante uma taxa de dados. Em vez disso, o ADSL pode garantir
somente que fará tanto quanto as condições da linha permitirem que suas técnicas operem. Deste
modo, a taxa downstream varia de 32 Kbps a 6,4 Mbps e a taxa upstream varia de 32 Kbps a
640 Kbps.
6.5.1
Outras Tecnologias de DSL
Além do ADSL, foram desenvolvidas outras tecnologias DSL. Cada uma usa a largura
de banda para alcançar uma meta ligeiramente diferente. Deste modo, cada uma apresenta
vantagens para alguns aplicativos. Por exemplo, a SDSL (Symmetric Digital Subscriber
Line – Linha Digital de Assinante Simétrica) fornece taxas de bits simétricas em ambas as
direções. Como descrito anteriormente, a maioria dos indivíduos que usam redes de
computadores seguem um padrão assimétrico de uso. Diversas companhias pequenas
seguem o mesmo padrão. Elas geralmente usam a rede para obter informações. Porém, as
empresas que fornecem informações para outras tendem a ter exatamente a assimetria oposta,
exportam mais dados que importam. Infelizmente, poucas companhias telefônicas oferecem
ADSL com direções de assimetria invertida. Deste modo, as empresas que exportam
informações podem preferir o SDSL. Além disso, como o SDSL usa um esquema de
codificação diferente do ADSL, o SDSL pode operar através de loops locais para os quais o
ADSL é impróprio. Deste modo, algumas companhias telefônicas escolhem oferecer serviço
de SDSL em vez de ADSL.
Outro serviço de DSL é conhecido como HDSL (High-Rate Digital Subscriber
Line – Linha Digital de Assinante de Taxa Alta). O HDSL fornece uma taxa de bits DS1 (ou
seja, 1,544 Mbps) nas duas direções. Uma das desvantagens do HDSL é uma limitação de
distância em loops locais. Outra desvantagem advém dos requisitos de cabeamento.
Diferente do ADSL, que usa um único par trançado, o HDSL exige dois pares trançados
independentes. Para superar a desvantagem de cabeamento, uma variante conhecida como
HDSL2 foi proposta e executa sobre dois fios1.
Uma das vantagens do HDSL advém de sua tolerância a modificações no loop local
feitas para o sistema telefônico. Em particular, o HDSL pode ser usado em um loop que
inclui uma bridge tap telefônica (algumas tecnologias de DSL não podem). Além disso,
como sua taxa de transferência é compatível com um circuito T1, mover dados entre um
circuito T1 e HDSL é simples.
Outra vantagem do HDSL surge da sua habilidade de tolerar falhas graciosamente. A
tecnologia foi projetada de forma que se um dos dois pares trançados falha, os modems não
falham completamente, mas, em vez disso, continuam a operar a uma metade da taxa máxima
de transferência. O modo de falha graciosa é especialmente atrativo para as empresas porque
é freqüentemente melhor ter uma conexão lenta do que nenhuma conexão.
Outra variante do DSL que foi estudada pode fornecer throughput muito mais alto.
Conhecida como VDSL (Very-high bit rate Digital Subscriber Line – Linha Digital de
Assinante de Taxa muito alta), a tecnologia pode alcançar uma taxa de dados de até 52 Mbps.
Alternativas que oferecem 13 Mbps e 26 Mbps foram também investigadas.
Embora tais taxas altas possam ser alcançadas através de um par trançado de cobre, o
VDSL não pode ser usado no cabeamento existente entre a Estação Central e os assinantes
1
Como o tráfego upstream e downstream compartilham um único par de fios, o HDSL2 é às vezes chamado de SHDSL.
83
telefônicos porque as distâncias são muito longas. Então, a VDSL exige pontos de
concentração intermediários, com fibra óptica conectando os pontos de concentração de volta
para a Estação Central. Em terminologia VDSL, um ponto de concentração é chamado de
ONU (Optical Network Unit – Unidade de Rede Óptica). Como as versões de VDSL com
taxas de dados inferiores correm sobre cobre através de distâncias mais longas, elas não
exigem que pontos de concentração fiquem tão perto do assinante. Desse modo, taxas de
dados mais baixas exigem menos pontos de concentração para cobrir uma dada área
geográfica.
6.6
Cable Modem
As Seções 6.4 e 6.5 examinaram tecnologias que entregam informações digitais através do
cabeamento de par trançado que forma o loop local do sistema telefônico analógico. Esta Seção
considera o uso de um esquema de cabeamento alternativo que pode entregar taxas de bit muito
mais altas.
A motivação primária para considerar alternativas para o loop local telefônico advém das
limitações inerentes. O problema principal reside nas características elétricas do cabeamento de
par trançado. Embora as tecnologias como ADSL possam alcançar taxas de bit muito mais altas
que modems dial-up, o cabeamento impõe um limite máximo na rapidez em que os dados podem
ser transferidos. Além disso, a falta de proteção torna o cabeamento suscetível à interferência, o
que pode degradar substancialmente o desempenho para alguns assinantes.
Em um esforço para superar as limitações do cabeamento de par trançado, os pesquisadores
investigaram tecnologias com e sem-fio para o uso no loop local. Uma tecnologia alternativa
distingue-se como particularmente atraente porque oferece velocidade mais alta do que o
cabeamento telefônico, é menos suscetível à interferência eletromagnética e não exige uma infraestrutura completamente nova: televisão a cabo1. Além disso, muitas áreas residenciais já têm
instalação de TV a cabo disponível.
Um sistema de TV a cabo tem quase todas as facilidades necessárias para o envio de
informações digitais downstream em alta velocidade. O meio consiste em cabo coaxial, que tem
alta capacidade e é imune à interferência eletromagnética, e no hardware de sistema de cabo que
usa sinalização de banda larga (ou seja, multiplexação por divisão de freqüência) para transmitir
múltiplos canais de televisão simultaneamente. Mais importante, como os sistemas de cabo são
projetados para transportar mais sinais de televisão do que aqueles que estão atualmente
disponíveis, o hardware tem largura de banda ociosa (ou seja, canais) que pode ser usada para
enviar dados. As vantagens têm sido suficientes para estimular a pesquisa.
Em teoria, é possível estender um sistema de cabo para enviar informações digitais
downstream usando multiplexação de divisão de frequência. Para fazer isso, é necessário um par
de modems de cabo (cable modem) para cada assinante. Um modem reside na central da TV a
cabo e o outro no site do assinante. Ambos os modems de um dado par devem estar sintonizados
para operar na mesma frequência portadora, que é multiplexada no cabo junto a sinais de televisão.
Os dados passados ao modem na central da TV a cabo são codificados na portadora, que é então
difundida através do cabo para todos os assinantes. Um modem equivalente na localização do
assinante escolhe o sinal de portadora, extrai as informações digitais codificadas e passa a
informação resultante ao computador do assinante.
Na prática, porém, mesmo a grande largura de banda disponível em sistemas de TV a cabo
não é suficiente para tratar de um esquema de multiplexação por divisão de frequência que se
1
Formalmente, a tecnologia é conhecida como Community Antenna TeleVision (CATV).
84
estenda a cada usuário. Para entender por quê, considere o número de assinantes e lembre-se de
que as frequências da portadora devem ser separadas uma das outras para evitar interferência. Em
uma grande área metropolitana, um único provedor de cabo pode ter milhões de assinantes,
impossibilitando que se aloque uma frequência portadora separada para cada assinante. Como
resultado, o esquema de multiplexação de divisão de frequência não é escalável.
Os engenheiros têm explorado várias formas de se tratar do problema da multiplexação
downstream de sinais. Uma solução é uma forma de multiplexação por divisão de tempo. Em
vez de designar uma frequência única para cada assinante, a empresa de cabo usa uma frequência
para um conjunto de assinantes. Além disso, um endereço é associado a cada assinante. O modem
de um assinante escuta a frequência designada para os pacotes que são recebidos. Antes de aceitar
um pacote, o dispositivo verifica se o endereço de destino combina com o endereço designado
para o assinante. Essencialmente, a porção de dados do sistema de hardware de cabo se assemelha
a um conjunto de LANs compartilhadas, ao contrário de um conjunto de links ponto a ponto.
Do ponto de vista de um assinante, o compartilhamento da largura de banda com outros
assinantes pode ser uma desvantagem. Embora os modems de cabo possam entregar até 36 Mbps,
a taxa de dados efetiva disponível para cada estação individual varia com o passar do tempo. Se
N assinantes compartilham uma única frequência, a capacidade disponível para um assinante
individual pode chegar a 1/N.
85
Arquitetura TCP/IP
7.1
A Motivação para Ligação Inter-redes
Cada tecnologia de rede é projetada para satisfazer um conjunto específico de restrições.
Por exemplo, as tecnologias de LAN são projetadas para fornecer comunicação de alta velocidade
através de pequenas distâncias, enquanto que as tecnologias de WAN são projetadas para fornecer
comunicação através de áreas geograficamente distantes, consequentemente, não há uma única
tecnologia de rede que seja a melhor para todas as necessidades.
Uma organização grande, com requisitos de redes diversos, precisa de múltiplas redes
físicas. Mais importante, se a organização escolhe o tipo de rede que é melhor para cada tarefa, a
organização terá vários tipos de redes. Por exemplo, uma tecnologia de LAN como Ethernet
poderia ser a melhor solução por conectar vários computadores em um escritório, mas um serviço
de Frame Relay poderia ser usado para interconectar computadores em uma cidade.
7.2
O Conceito de Serviço Universal
O principal problema com múltiplas redes deveria ser óbvio: um computador acoplado a
uma determinada rede pode se comunicar somente com outros computadores acoplados à mesma
rede. O problema se tornou evidente nos anos 70 quando grandes organizações começaram a
adquirir múltiplas redes. Cada rede na organização formou uma ilha. Em muitas instalações
iniciais, cada computador estava acoplado a uma única rede e os funcionários tinham que escolher
um computador apropriado para cada tarefa. Isto é, um funcionário recebia acesso a múltiplas
telas e teclados, e era forçado a se mover de um computador a outro para enviar uma mensagem
através da rede apropriada.
Os usuários não ficam satisfeitos nem são produtivos quando têm que usar um computador
separado para cada rede. Conseqüentemente, a maioria dos sistemas de comunicação modernos
permite a comunicação entre quaisquer dois computadores de maneira análoga a um sistema
telefônico que fornece comunicação entre quaisquer dois telefones. Conhecido como serviço
universal, o conceito é uma parte fundamental da área de redes. Com o serviço universal, um
usuário em qualquer computador em qualquer parte de uma organização pode enviar mensagens
ou dados para qualquer outro usuário. Além disso, um usuário não precisa mudar de sistema de
computador quando muda tarefas – todas as informações estão disponíveis para todos os
computadores. Como resultado, os usuários são mais produtivos.
7.3
Serviço Universal em um Mundo Heterogêneo
O serviço universal significa que uma organização precisa adotar uma única tecnologia de
rede, ou é possível ter serviço universal através de múltiplas redes que múltiplas tecnologias? É
sabido que incompatibilidades elétricas impossibilitam a formação de uma grande rede apenas se
interconectando os fios de duas redes. Além disso, técnicas de extensão como ligação com
bridges não podem ser usadas com tecnologias de rede heterogêneas porque tecnologias diferentes
usam formatos de pacote e esquemas de endereçamento incompatíveis. Deste modo, um quadro
criado para uma tecnologia de rede não pode ser transmitido em uma rede que usa uma tecnologia
diferente.
86
7.4
Ligação Inter-redes
Apesar das incompatibilidades entre tecnologias de rede, os pesquisadores inventaram um
esquema que fornece serviço universal entre redes heterogêneas. O esquema, chamado ligação
inter-redes, utiliza hardware e software. Os sistemas de hardware adicionais são usados para
interconectar um conjunto de redes físicas. O software em todos os computadores acoplados,
então, fornece serviço universal. O sistema que resulta das redes físicas conectadas é conhecido
como uma inter-rede (internet).
A ligação inter-redes é bastante geral. Em particular, uma inter-rede não é restrita em
tamanho. Existem inter-redes que contêm algumas redes e existem inter-redes que contêm
milhares de redes. Semelhantemente, o número de computadores acoplados a cada rede em uma
inter-rede pode variar. Algumas redes não têm nenhum computador acoplado, enquanto outras
têm centenas.
7.5
Conexão de Rede Física com Roteadores
O componente básico de hardware usado para conectar redes heterogêneas é um roteador.
Fisicamente, os roteadores se assemelham a bridges. Cada roteador é um computador de
propósito específico dedicado à tarefa de interconectar redes. Como uma bridge, um roteador tem
um processador e memória convencional, como também uma interface de E/S separada para cada
rede que conecta. A rede trata uma conexão com um roteador da mesma forma que uma conexão
com qualquer outro computador. A Figura 7.1 mostra que a conexão física de redes com um
roteador é direta.
Figura 7.1 – Duas redes físicas conectadas por um roteador.
A Figura 7.1 usa uma nuvem para representar cada rede em vez de uma linha ou um círculo
porque as conexões de roteadores não são restritas a uma determinada tecnologia de rede. Um
roteador pode conectar duas LANs, uma LAN e uma WAN, ou duas WANs. Além disso, quando
um roteador conectar duas redes na mesma categoria geral, as redes não precisam usar a mesma
tecnologia. Por exemplo, um roteador pode conectar uma LAN Ethernet com uma LAN FDDI
(fibra óptica). Deste modo, cada nuvem representa uma tecnologia de rede arbitrária.
7.6
Arquitetura de Inter-rede
Os roteadores possibilitam a uma organização escolher tecnologias de rede apropriadas para
cada necessidade e usar roteadores para conectar todas as redes em uma única inter-rede. Por
exemplo, a Figura 7.2 mostra como podem ser usados três roteadores para se conectar quatro redes
físicas arbitrárias em uma inter-rede.
Figura 7.2 – Uma inter-rede formada usando três roteadores.
Embora a Figura 7.2 mostre cada roteador com exatamente duas conexões, os roteadores
comerciais podem conectar mais de duas redes. Deste modo, um único roteador poderia conectar
87
todas as quatro redes em nosso exemplo. Porém, uma organização raramente usa um único
roteador para conectar todas as suas redes. Existem duas razões:

Como a CPU e a memória em um roteador são usadas para processar cada pacote, o
processador em um roteador é insuficiente para tratar do tráfego que passa entre um
número arbitrário de redes;

Redundância melhora a confiabilidade da inter-rede. O software de protocolo
continuamente monitora as conexões entre redes e instrui os roteadores para enviar
tráfego através de caminhos alternativos quando uma rede ou roteador falha.
Deste modo, ao planejar uma inter-rede, uma organização deve escolher um projeto que vá
ao encontro das suas necessidades em relação à confiabilidade, à capacidade e ao custo. Em
particular, os detalhes exatos da topologia de inter-rede frequentemente dependem da largura de
banda das redes físicas, do tráfego esperado, dos requisitos de confiabilidade da organização e do
custo do hardware de roteador disponível.
7.7
Obtendo Serviço Universal
A meta da ligação inter-redes é o serviço universal através de redes heterogêneas. Para
fornecer serviço universal entre todos os computadores em uma inter-rede, os roteadores devem
concordar em encaminhar informações de uma origem em uma rede para um destino especificado
em outra. A tarefa é complexa porque formatos de quadros e esquemas de endereçamento usados
pelas redes subjacentes podem diferir. Como resultado, é necessário software de protocolo em
computadores e roteadores para possibilitar o serviço universal.
7.8
Uma Rede Virtual
Em geral, o software de inter-rede fornece a ilusão de um único sistema integrado de
comunicação ao qual muitos computadores são acoplados. O sistema oferece serviço universal:
a cada computador é atribuído um endereço, e qualquer computador pode enviar um pacote para
qualquer outro computador. Além disso, o software de protocolo de inter-rede esconde os detalhes
de conexão de rede física, endereços físicos e informações de roteamento. Nem usuários nem
programas aplicativos estão cientes das redes físicas subjacentes ou dos roteadores que as
conectam.
Dizemos que uma inter-rede é um sistema de rede virtual porque o sistema de comunicações
é uma abstração. Isto é, embora uma combinação de hardware e software forneça a ilusão de um
sistema de rede uniforme, tal rede não existe. A Figura 7.3 mostra o conceito de rede virtual como
também uma estrutura física correspondente.
88
Figura 7.3 – O conceito de inter-rede.
7.9
Protocolos para Ligação Inter-redes
Embora muitos protocolos têm sido adaptados para o uso em inter-redes, um pacote
distingue-se como o mais extensamente usado para a ligação inter-redes. O pacote é formalmente
conhecido como Os Protocolos de Internet TCP/IP (TCP – Transfer Control Protocol; IP –
Internet Protocol). A maioria dos profissionais de redes se refere a eles simplesmente como
TCP/IP.
O TCP/IP foi o primeiro conjunto de protocolos desenvolvido para o uso em uma inter-rede.
De fato, os pesquisadores que inventaram o TCP/IP desenvolveram também a arquitetura de interrede descrita anteriormente neste capítulo. O trabalho com TCP/IP começou nos anos 70,
aproximadamente ao mesmo tempo em que as redes locais estavam sendo desenvolvidas. O
exército dos EUA fundamentou boa parte da pesquisa em TCP/IP e a ligação inter-redes através
da ARPA (Advanced Research Projects Agency). O exército estava entre as primeiras
organizações a ter múltiplas redes físicas. Consequentemente, o exército foi um dos primeiros a
perceber a necessidade do serviço universal. Pela metade dos anos 80, a National Science
Foundation e outras agências do governo dos EUA estavam financiando o desenvolvimento do
TCP/IP e uma grande inter-rede que seria usada para testar protocolos.
7.10 Arquitetura TCP/IP
A pesquisa em protocolos de ligação inter-redes e TCP/IP produziu resultados drásticos. A
ligação inter-redes se tornou uma das idéias mais importantes na área moderna de redes. De fato,
a tecnologia de inter-rede revolucionou a comunicação entre computadores. A maioria das
grandes organizações já usa ligação inter-redes como mecanismo primário de comunicação entre
computadores. Organizações menores e os próprios indivíduos estão começando a fazer o mesmo.
Mais importante, além de inter-redes privadas, a tecnologia de TCP/IP possibilitou uma inter-rede
89
global (Internet) que alcança mais de 36 milhões de computadores em escolas, organizações
comerciais e sites governamentais e militares em mais de 107 países em todo mundo.
A demanda mundial para produtos de ligação inter-redes afetou a maioria das empresas que
vendem tecnologias de rede. A competição aumentou porque foram criadas novas empresas para
vender o hardware e software necessário para a ligação inter-redes. Além disso, muitas empresas
modificaram seus projetos de protocolo para acomodar a ligação inter-redes. Em particular, a
maioria dos protocolos de rede foram originalmente projetados para funcionar com uma
tecnologia de rede e uma rede física de cada vez. Para fornecer capacidade de ligação inter-redes,
as empresas estenderam os projetos de duas maneiras: os protocolos foram adaptados para
funcionar com muitas tecnologias de rede e foram acrescentadas novas características que
permitem aos protocolos transferir dados através de uma inter-rede.
7.11 Divisão em Camadas do Protocolo TCP/IP
O modelo OSI de referência de 7 camadas visto no Capítulo 3 foi criado antes de a ligação
inter-redes ser inventada. Consequentemente, o modelo não contém uma camada para protocolos
de inter-rede. Além disso, o modelo de referência de 7 camadas dedica uma camada inteira a
protocolos de sessão, que se tornaram muito menos importantes à medida que os sistemas de
computadores mudaram de grandes sistemas de tempo compartilhado para workstations pessoais.
Como resultado, os pesquisadores que desenvolveram o TCP/IP inventaram um novo modelo em
camadas.
O modelo de camadas do TCP/IP, que é também chamado de Modelo de Camadas Interredes ou o Modelo de Referência de Inter-redes contém cinco ou quatro camadas dependendo do
autor, como mostra a Figura 7.4.
Camada 5
Camada 4
Camada 3
Camada 2
Camada 1
Aplicação
Transporte
Internet (Rede)
Interface de
Rede
Física
Camada 4
Camada 3
Camada 2
Aplicação
Transporte
Internet (Rede)
Camada 1
Enlace
Figura 7.4 – As camadas do modelo de referência TCP/IP.
Quatro das camadas no modelo de referência TCP/IP correspondem a uma ou mais camadas
no modelo de referência OSI. Porém, o modelo OSI não tem nenhuma camada de Inter-rede.
Abaixo é feito um resumo do propósito de cada camada.
Camada 1: Física
A Camada 1 corresponde ao hardware de rede básico da mesma maneira que
na Camada 1 no modelo de referência OSI de 7 camadas.
Camada 2: Interface de Rede
Os protocolos da Camada 2 especificam como organizar dados em quadros e
como um computador transmite quadros através de uma rede, semelhantemente
aos protocolos da Camada 2 no modelo de referência OSI.
Camada 3: Inter-rede
Os protocolos da Camada 3 especificam o formato dos pacotes enviados
através de uma inter-rede como também os mecanismos usados para
encaminhar pacotes a partir de um computador através de um ou mais
roteadores até um destino final.
90
Camada 4: Transporte
Os protocolos da Camada 4, como a Camada 4 no modelo OSI, especificam
como assegurar transferência confiável.
Camada 5: Aplicação
A Camada 5 corresponde às camadas 6 e 7 no modelo OSI. Cada protocolo da
Camada 5 especifica como um aplicativo usa uma inter-rede.
O TCP/IP define o termo computador host para se referir a qualquer sistema de computador
que esteja conectado a uma inter-rede e execute aplicativos. Um host pode ser tão pequeno quanto
um computador pessoal ou tão grande quanto um mainframe. Além disso, a CPU de um host
pode ser lenta ou rápida, a memória pode ser grande ou pequena, e a rede a qual um host se conecta
pode operar em alta ou baixa velocidade. Os protocolos do TCP/IP possibilitam que qualquer par
de hosts se comunique, apesar das diferenças de hardware.
Ambos os hosts e roteadores precisam de software de protocolo TCP/IP. Porém, os
roteadores não usam protocolos de todas as camadas. Em particular, um roteador não precisa dos
protocolos da Camada 5 para aplicativos como transferência de arquivos porque roteadores não
executam tais aplicativos1.
7.12 Endereços para a Inter-rede Virtual
A meta da ligação inter-redes é fornecer um sistema de comunicação integrado. Para obter
essa meta, o software de protocolo de inter-rede deve esconder os detalhes de redes físicas e
oferecer as facilidades de uma grande rede virtual. A inter-rede virtual opera bastante como
qualquer outra rede, permitindo aos computadores enviar e receber pacotes de informações. A
diferença principal entre uma inter-rede e uma rede física é que uma inter-rede é somente uma
abstração imaginada por seus projetistas e criada completamente por software. Os projetistas têm
a liberdade para escolher endereços, formatos de pacote e técnicas de entrega independentes dos
detalhes do hardware físico.
O endereçamento é um componente crítico da abstração de inter-rede. Para dar a aparência
de um sistema único uniforme, todos os computadores devem usar um esquema de endereçamento
uniforme, e cada endereço deve ser único. Infelizmente, não bastam endereços físicos de rede,
porque uma inter-rede pode incluir múltiplas tecnologias de rede, e cada tecnologia define seu
próprio formato de endereço. Deste modo, os endereços usados por duas tecnologias podem ser
incompatíveis pois possuem tamanhos ou formatos diferentes.
Para garantir o endereçamento uniforme para todos os hosts, o software de protocolo define
um esquema de endereçamento que é independente dos endereços físicos subjacentes. Embora
um esquema de endereçamento de inter-rede seja uma abstração criada por software, são usados
endereços de protocolo como destino de inter-rede virtual analogamente à forma com que os
endereços de hardware são usados como destino em uma rede física. Para enviar um pacote
através de uma inter-rede, o remetente coloca o endereço de destino do protocolo no pacote e
passa o pacote para o software de protocolo para entrega. O software usa o endereço de destino
do protocolo quando encaminha o pacote através da inter-rede para o computador de destino.
O endereçamento uniforme ajuda a criar a ilusão de uma grande rede integrada porque
esconde os detalhes sobre os endereços de rede física subjacente. Dois programas aplicativos
podem se comunicar sem saber o endereço de hardware do outro. A ilusão é tão completa que
alguns usuários ficam surpresos ao saber que endereços de protocolo são fornecidos via software
1
Alguns roteadores, na verdade, rodam aplicativos que permitem a um gerente administrar o roteador remotamente (por
exemplo, mudar a configuração ou corrigir problemas).
91
e não são parte do sistema do computador. Interessantemente, aprenderemos que muitas camadas
de software de protocolo usam também endereços de protocolo.
7.12.1 O Esquema de Endereços IP
Na pilha de protocolos TCP/IP, o endereçamento é especificado pelo Protocolo de
Internet (IP). O padrão IP especifica que a cada host é atribuído um número de 32 bits único
conhecido como endereço de Protocolo de Internet do host, que é frequentemente abreviado
como endereço IP, ou endereço de Internet. Cada pacote enviado através de uma inter-rede
contém o endereço IP de 32 bits do remetente (origem) como também o receptor pretendido
(destino). Deste modo, para transmitir informações através de uma inter-rede TCP/IP, um
computador deve conhecer o endereço IP do computador remoto para o qual as informações
estão sendo enviadas.
7.12.2 A Hierarquia de Endereços IP
Conceitualmente, cada endereço IP de 32 bits é dividido em duas partes: prefixo e
sufixo; a hierarquia de dois níveis é projetada para fazer uso eficiente de roteamento. O
prefixo do endereço identifica a rede física ao qual o computador está acoplado, enquanto o
sufixo identifica um computador naquela rede. Isto é, a cada rede física em uma inter-rede é
atribuído um valor único conhecido como número de rede (network number). O número de
rede aparece como um prefixo no endereço de cada computador acoplado à rede. Além disso,
a cada computador em uma determinada rede física é atribuído um sufixo de endereço único.
Embora não possa ser atribuído a duas redes o mesmo número de rede, e dois
computadores na mesma rede não possam ser designados com o mesmo sufixo, um valor de
sufixo pode ser usado em mais de uma rede. Por exemplo, se uma inter-rede contém três
redes, elas poderiam ser designadas com números de rede 1, 2 e 3. Três computadores
acoplados à rede 1 podem ser designados com os sufixos 1, 3 e 5, enquanto três computadores
acoplados à rede 2 podem ser designados com os sufixos 1, 2 e 3.
A hierarquia de endereços IP garante duas propriedades importantes:

A cada computador é atribuído um endereço único (isto é, um único endereço nunca
é atribuído a mais de um computador);

Embora as designações de números de rede devam ser coordenadas globalmente, os
sufixos podem ser atribuídos localmente sem coordenação global.
A primeira propriedade é garantida porque um endereço completo contém prefixo e
sufixo, que são atribuídos para assegurar a unicidade. Se dois computadores estão acoplados
a redes físicas diferentes, seus endereços têm prefixos diferentes. Se dois computadores estão
acoplados à mesma rede física, seus endereços têm sufixos diferentes.
7.12.3 Classes de Endereços IP
Uma vez que os projetistas do IP escolheram um tamanho para endereços IP e
decidiram dividir cada endereço em duas partes, eles tiveram que determinar quantos bits
colocar em cada parte. O prefixo precisa de bits suficientes para permitir que um número de
rede único seja atribuído a cada rede física em uma inter-rede. O sufixo precisa de bits
suficientes para permitir que a cada computador acoplado a uma rede seja atribuído um sufixo
único. Nenhuma escolha simples foi possível porque acrescentar bits a uma parte significa
subtrair bits da outra. Escolher um prefixo grande acomoda muitas redes, mas limita o
tamanho de cada rede; escolher um sufixo grande significa que cada rede física pode conter
muitos computadores, mas limita o número de redes.
92
Como uma inter-rede pode incluir tecnologias de rede arbitrárias, uma inter-rede
poderia ser construída de algumas redes físicas grandes, enquanto outras poderiam consistir
em muitas redes pequenas. Mais importante, uma única inter-rede pode conter uma mistura
de redes grandes e pequenas. Consequentemente, os projetistas escolheram um esquema de
endereçamento que é um meio-termo para acomodar uma combinação de redes grandes e
pequenas. O esquema divide o espaço de endereçamento IP em três classes primárias, onde
cada classe tem um prefixo e um sufixo de tamanhos diferentes.
Os primeiros quatro bits de um endereço determinam a classe a que o endereço pertence
e especificam como o restante do endereço é dividido em prefixo e sufixo. A Figura 7.5
mostra as cinco classes de endereços, os bits iniciais usados para identificar cada classe e a
divisão em prefixo e sufixo. A figura segue a convenção usada nos protocolos TCP/IP de
numerar bits da esquerda para a direita e usando zero para o primeiro bit.
Bits 
0
Classe A
0
Classe B
1
0
Classe C
1
1
0
Classe A
1
1
1
0
Classe D
1
1
1
1
1
2
3
8
1
6
Prefixo
2
4
3
1
Sufixo
Prefixo
Sufixo
Prefixo
Sufixo
Endereço Multicast
Reservado para uso futuro
Figura 7.5 – Divisão em Classes do endereçamento IP.
As classes A, B e C são chamadas de classes primárias porque são usadas para
endereços de hosts. A classe D é usada para multicasting, que permite a entrega a um
conjunto de computadores1. Para usar IP multicasting, um conjunto de hosts deve concordar
em compartilhar um endereço multicast. Uma vez que o grupo multicast foi estabelecido,
uma cópia de qualquer pacote enviado para o endereço multicast será entregue para cada host
no conjunto.
Como mostra a Figura 7.5, as classes primárias usam limites de octeto para dividir um
endereço em prefixo e sufixo. A classe A coloca a divisão entre o primeiro e o segundo
octetos. A classe B coloca o limite entre o segundo e o terceiro octetos, e a classe C coloca
o limite entre o terceiro e o quarto octetos.
7.12.4 Computando a Classe de um Endereço
O software IP computa a classe do endereço de destino sempre que recebe um pacote.
Como a computação é frequentemente repetida, ela de ser eficiente. Os endereços IP são
chamados de auto-identificadores porque a classe de um endereço pode ser computada a
partir do endereço propriamente dito.
Parte da motivação para se usar bits iniciais para denotar uma classe de endereço em
vez de usar uma faixa de valores advém de considerações computacionais: usar bits pode
diminuir o tempo de computação. Em particular, alguns computadores podem examinar bits
mais rapidamente do que podem comparar inteiros. Por exemplo, em um computador que
inclui instruções booleanas and, deslocamento (shift) e pesquisa de índice, quatro bits de
endereço podem ser extraídos e usados como um índice em uma tabela para determinar a
classe de endereço. A Tabela 7.1 mostra o conteúdo de uma tabela usada na computação.
1
IP multicasting é análogo ao multicasting por hardware. Em ambos os casos, os endereços multicast são opcionais, e
mesmo quando um computador participa em um multicast, ele sempre retém seu endereço individual.
93
Primeiros Quatro
Bits do Endereço
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
Índice da Tabela
(em decimal)
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Classe do
endereço
A
A
A
A
A
A
A
A
B
B
B
B
C
C
D
E
Tabela 7.1 – Relação dos primeiros 4 bits com a classe de um endereço IP.
7.12.5 Notação Decimal Pontilhada
Embora os endereços IP sejam números de 32 bits, os usuários raramente entram ou
lêem os valores em binário. Em vez disso, quando está interagindo com um usuário, o
software usa uma notação que é mais conveniente para as pessoas entenderem. Chamada de
notação decimal pontilhada (dotted decimal notation), a forma expressa cada seção de 8 bits
de um número de 32 bits como um valor decimal e usa pontos para separar as seções. A
Tabela 7.2 mostra alguns exemplos de números binários e as formas decimais pontilhadas
equivalentes.
Número Binário de 32 bits
10000001.00110100.00000110.00000000
11000000.00000101.00110000.00000011
00001010.00000010.00000000.00100101
10000000.00001010.00000010.00000011
10000000.10000000.11111111.00000000
Notação Decimal Pontilhada Equivalente
129.52.6.0
192.5.48.3
10.2.0.37
128.10.2.3
128.128.255.0
Tabela 7.2 – Exemplos de Endereços IP em Binário e Notação Decimal Pontilhada.
A notação decimal pontilhada trata cada octeto como um inteiro binário sem sinal.
Como mostra o exemplo final na figura, o menor valor possível, 0 (zero), acontece quando
todos os bits de um octeto são zero, e o maior valor possível, 255, acontece quando todos os
bits de um octeto são um. Deste modo, os endereços em notação decimal pontilhada variam
de 0.0.0.0 à 255.255.255.255.
7.12.6 Classes e Notação Decimal Pontilhada
A notação decimal pontilhada trabalha bem com endereços IP porque o IP usa limites
de octeto para separar um endereço em prefixo e sufixo. Em um endereço classe A, os
últimos três octetos correspondem a um sufixo de host. Semelhantemente, os endereços
classe B têm dois octetos de sufixo de host, e os endereços de classe C tem um octeto.
94
Infelizmente, como a notação decimal pontilhada não mostra os bits individuais de um
endereço, a classe deve ser reconhecida a partir do valor decimal do primeiro octeto. A
Tabela 7.3 mostra o alcance decimal de valores para cada classe.
Classe
A
B
C
D
E
Faixa de Valores
Binário
Decimal
0000 0000 até 0111 1111 0 até 127
1000 0000 até 1011 1111 128 até 191
1100 0000 até 1101 1111 192 até 223
1110 0000 até 1110 1111 224 até 239
1111 0000 até 1111 1111 240 até 255
Tabela 7.3 – Faixa de Valores do Primeiro Octeto para as Classes IP.
7.12.7 Autoridade para Endereços
Na inter-rede como um todo, cada prefixo de rede deve ser único. Para as redes
conectadas à Internet global, uma organização obtém números de rede da empresa de
comunicação que fornece conexões de Internet. Tais empresas são chamadas de ISPs
(Internet Service Providers – Provedores de Serviço de Internet). Provedores de Serviço de
Internet coordenam com uma organização central, a IANA (Internet Assigned Number
Authority – Autoridade para Designação de Números de Internet), para assegurar que cada
prefixo de rede seja único ao longo de toda a Internet.
Para uma inter-rede privada, a escolha de prefixo de rede pode ser feita pela
organização. Para assegurar que cada prefixo seja único, um grupo que constrói uma interrede privada deve decidir como coordenar números de rede. Freqüentemente, um único
administrador da rede atribui prefixos a todas as redes na inter-rede da empresa para assegurar
que os números não sejam duplicados.
7.12.8 Um Exemplo de Endereçamento IP
Um exemplo elucidará as idéias e explicará como os endereços são atribuídos na
prática. Considere uma organização que escolhe formar uma inter-rede TCP/IP privada que
consiste em quatro redes físicas. A organização deve comprar roteadores para interconectar
as quatro redes e então deve atribuir endereços IP. Para começar, a organização escolhe um
prefixo único para cada rede.
Ao designar um prefixo de rede, um número deve ser escolhido das classes A, B ou C.
A escolha depende do tamanho da rede física. Normalmente, redes são endereços de classe
C atribuídos, a menos que uma classe B seja necessária. A classe A é raramente justificada
porque poucas redes contêm mais de 65534 hosts. Para redes conectadas à Internet global,
um provedor de serviços faz a escolha. Para redes em uma inter-rede privada, o
administrador de rede local seleciona a classe.
Considere o exemplo de uma inter-rede privada descrita acima. O administrador de
rede estima o tamanho final de cada rede física e utiliza aquele tamanho para escolher um
prefixo. Se a organização espera uma rede pequena, duas redes de tamanho médio e uma
rede extremamente grande, o administrador poderia escolher atribuir um prefixo de classe C
(por exemplo: 192.5.48), dois prefixos de classe B (por exemplo: 128.10 e 128.211) e um
prefixo de classe A (por exemplo: 10). A Figura 7.6 ilustra uma inter-rede com quatro redes
físicas às quais foram atribuídos estes prefixos e mostra alguns exemplos de endereços IP
atribuídos aos hosts.
95
Figura 7.6 – Uma inter-rede de exemplo privado com endereços IP atribuídos aos hosts.
Como mostra a figura, o endereço IP atribuído a um host sempre começa com o prefixo
que foi atribuído à rede física do host. Os sufixos, que são atribuídos pelo administrador de
rede local, podem ser números arbitrários. No exemplo, aos dois hosts conectados à rede
com prefixos 128.10 foram atribuídos sufixos 1 e 2. Embora muitos administradores
prefiram atribuir sufixos consecutivos, o IP não exige que um administrador assim o faça.
As atribuições de exemplos na figura mostram que os sufixos podem ser valores arbitrários
como 37 ou 85.
7.12.9 Endereços IP Especiais
Além de atribuir um endereço a cada computador, é conveniente ter endereços que
podem ser usados para denotar redes ou conjuntos de computadores. O IP define um conjunto
de formas de endereço especial que é reservado. Isto é, endereços especiais nunca são
atribuídos a hosts. Essa seção descreve a sintaxe e a semântica de cada forma de endereço
especial.
7.12.9.1 Endereço de Rede
Uma das motivações para definir formas de endereço especial pode ser vista na
Figura 7.6. É conveniente ter um endereço que possa ser usado para denotar o prefixo
atribuído a uma determinada rede. O IP reserva um endereço de host zero e o usa para
denotar uma rede. Deste modo, o endereço 128.211.0.0 denota a rede à qual foi atribuído
o prefixo de classe B 128.211.
O endereço de rede se refere à rede propriamente dita e não aos computadores de
host acoplados àquela rede. Deste modo, o endereço de rede nunca deveria aparecer em
um pacote.
7.12.9.2 Endereço de Broadcast Direcionado
Às vezes, é conveniente enviar uma cópia de um pacote para todos os hosts em
uma rede física. Para facilitar o broadcasting, o IP define um endereço de broadcast
dirigido para cada rede física. Quando um pacote é enviado para um endereço de
broadcast dirigido de uma rede, uma única cópia do pacote viaja através da inter-rede
até que ele alcance a rede especificada. O pacote é então entregue a todos os hosts na
rede.
96
O endereço de broadcast dirigido para uma rede é formado somando-se ao prefixo
de rede um sufixo que consiste em todos os bits 1. Para assegurar que cada rede possa
ter broadcast dirigido, o IP reserva o endereço de host que contém todos os bits 1. Um
administrador não deve atribuir a um computador específico o endereço de host com
tudo em zero ou tudo em um ou, caso contrário, o software pode não funcionar
corretamente.
Se um hardware de rede suporta broadcast, um broadcast dirigido será entregue
usando a capacidade de broadcast do hardware. Em tais casos, uma transmissão do
pacote alcançará todos os computadores na rede. Quando um broadcast dirigido for
enviado para uma rede que não tem suporte de hardware para broadcast, o software
deve enviar uma cópia separada do pacote para cada host na rede.
7.12.9.3 Endereço de Broadcast Limitado
O termo broadcast limitado se refere a um broadcast em uma rede física local.
Informalmente, dizemos que o broadcast é limitado a um “único fio”. O broadcast
limitado é usado durante a partida do sistema por um computador que ainda não sabe o
seu número de rede.
O IP reserva o endereço que consiste em todos os bits 1 para se referir ao broadcast
limitado. Deste modo, o IP irá transmitir um broadcast através da rede local qualquer
pacote enviado para o endereço que tenho todos os bits 1.
7.12.9.4 Endereço deste Computador
Um computador precisa saber seu endereço IP para enviar ou receber pacotes de
inter-rede porque cada pacote contém o endereço da origem e do destino. O conjunto
de protocolos TCP/IP contém protocolos que um computador pode usar para obter seu
endereço IP automaticamente quando o computador realiza o boot. Interessantemente,
os protocolos de inicialização (startup) usam IP para se comunicar. Ao usar tais
protocolos de inicialização, um computador não pode fornecer um endereço IP de
origem correto. Para tratar de tais casos, o IP reserva o endereço que consiste em todos
os bits zero para significar este computador.
7.12.9.5 Endereço de Loopback
O IP define um endereço de loopback usado para testar aplicativos de rede. Os
programadores frequentemente usam o teste de loopback para depuração preliminar
depois de ser criado um aplicativo de rede. Para executar um teste de loopback, um
programador deve ter dois programas aplicativos que planejam se comunicar através de
uma rede. Cada aplicativo inclui o código necessário para interagir com o software de
protocolo TCP/IP. Em vez de executar cada programa em um computador separado, o
programador executa ambos os programas em um único computador e os instrui para
usar um endereço de loopback IP ao se comunicar. Quando um aplicativo envia dados
para outro, os dados descem a pilha de protocolos até o software IP, que os encaminha
para cima através da pilha de protocolos até o segundo programa. Deste modo, o
programador pode testar rapidamente a lógica do programa sem precisar de dois
computadores e sem enviar pacotes através de uma rede.
O IP reserva o prefixo 127 de rede classe A para usar como loopback. O endereço
de host usado com 127 é irrelevante. Todos os endereços de host são tratados da mesma
forma. Por convenção, os programadores usam frequentemente o número de host 1,
tornando 127.0.0.1 a forma mais popular de loopback.
97
Durante o teste de loopback, nenhum pacote deixa o computador. O software IP
encaminha pacotes de um programa aplicativo a outro. Consequentemente, o endereço
de loopback nunca aparece em um pacote que viaja através de uma rede.
7.12.9.6 Resumo de Endereços IP Especiais
A Tabela 7.4 resume as formas de endereço IP especiais. Dissemos que os
endereços especiais são reservados e nunca deveriam ser atribuídos a hosts. Além disso,
cada endereço especial é restrito para certos usos. Por exemplo, um endereço de
broadcast nunca deve aparecer como um endereço de origem, e o endereço com todos
os bits em zero não deve ser usado depois de um host completar o procedimento de
inicialização e obter um endereço IP.
Prefixo
Tudo em 0
Rede
Rede
Tudo em 1
127
Sufixo
Tudo em 0
Tudo em 0
Tudo em 1
Tudo em 1
Qualquer valor
Tipo de endereço
Este computador
Rede
Broadcast Dirigido
Broadcast Limitado
Loopback
Propósito
Usado durante o bootstrap
Identifica uma rede
Broadcast em rede específica
Broadcast na rede local
Testes
Tabela 7.4 – Resumo das formas de endereços IP especiais.
7.12.10 Divisão do Espaço de Endereçamento
O esquema de classe IP não divide o espaço de endereçamento de 32 bits em classes
de tamanho igual, e as classes não contêm o mesmo número de redes. Por exemplo, a metade
de todos os endereços IP (aqueles endereços em que o primeiro bit é zero) pertence à classe
A. Surpreendentemente, a classe A pode conter somente 128 redes porque o primeiro bit de
um endereço classe A deve ser zero e o prefixo ocupa um octeto. Deste modo, apenas sete
bits permanecem disponíveis para numerar as redes classe A. A Tabela 7.5 resume o número
máximo de redes disponíveis em cada classe e o número máximo de hosts por rede.
Como mostra a Tabela 7.5, o número de bits alocados a um prefixo ou sufixo determina
a quantidade de redes e de hosts únicos que podem ser atribuídos. Para calcular o total de
redes, eleva-se 2 ao total de bits do número de rede, isto é, TRedes  2 r , onde r é o total de bits
do número da rede. Para calcular o total de hosts disponíveis na rede, devemos realizar o
mesmo cálculo, só que com o total de bits referente ao host. Neste caso em especial, devese subtrair 2 ao total encontrado, pois temos dois endereços reservados em uma rede. O
endereço de rede e o endereço de broadcast. Sendo assim, o cálculo fica: THosts  2 h  2 ,
onde h representa o total de bits de host.
Classe
A
B
C
Bits no Prefixo
Total de Redes Bits no Sufixo Total de Hosts
7
128
24
16.777.214
14
16.384
16
65.534
21
2.097.152
8
254
Tabela 7.5 – Total de Redes e Hosts em cada Classe Primária.
7.12.11 Roteadores e o Princípio de Endereçamento IP
Além de designar um endereço de inter-rede para cada host, o IP especifica que os
roteadores deveriam ter endereços IP atribuídos também. De fato, cada roteador é designado
com dois ou mais endereços IP. Para entender por que, recorde dois fatos:

Um roteador tem conexões com múltiplas redes físicas;
98

Cada endereço IP contém um prefixo que especifica uma rede física.
Deste modo, um único endereço IP não basta para um roteador, porque cada roteador
se conecta a múltiplas redes. O esquema IP pode ser explicado por um princípio fundamental:
um endereço IP não identifica um computador específico. Em vez disso, cada endereço IP
identifica uma conexão entre um computador e uma rede. Um computador com múltiplas
conexões de rede (por exemplo, um roteador) deve ser designado com um endereço IP para
cada conexão.
A Figura 7.7 ilustra a idéia em um exemplo que mostra endereços IP atribuídos a dois
roteadores que conectam três redes.
Figura 7.7 – Um exemplo de endereços IP atribuídos a dois roteadores.
O IP não exige que o mesmo sufixo seja atribuído a todas as interfaces de um roteador.
Na figura, por exemplo, o roteador conectando a Ethernet e a Token Ring tem sufixos 99.5
(conexão com a Ethernet) e 2 (conexão com a Token Ring). Porém, o IP não previne o uso
do mesmo sufixo em todas as conexões. Deste modo, o exemplo mostra que o administrador
escolheu usar o mesmo sufixo, 17, para ambas as interfaces do roteador que conecta a rede
de Token Ring com a WAN. Por uma questão prática, usar o mesmo sufixo pode ajudar as
pessoas que administram a inter-rede, porque um único número é mais fácil de lembrar.
7.12.12 Host Multi-Homed
Um host pode ter múltiplas conexões de rede? Sim. Um computador de host que
conecta múltiplas redes é chamado de multi-homed. Homing múltiplo é às vezes usado para
aumentar a confiabilidade. Se uma rede falha, o host pode ainda alcançar a inter-rede através
da segunda conexão. Alternativamente, homing múltiplo é usado para aumentar o
desempenho. Conexões com múltiplas redes podem possibilitar o envio de tráfego
diretamente e evitar roteadores, que estão às vezes congestionados. Como um roteador, um
host multi-homed tem múltiplos endereços de protocolo, um para cada conexão de rede.
7.12.13 Sub-redes
Como vimos, todos os hosts de uma rede devem ter o mesmo número de rede. Essa
propriedade do endereçamento IP poderá causar problemas à medida que as redes crescem.
Por exemplo, imagine uma universidade que começou com uma rede da classe B usada pelo
departamento de ciência da computação para os computadores em sua Ethernet. Um ano
mais tarde, o departamento de engenharia elétrica quis entrar na Internet, e assim comprou
um repetidor para estender a rede Ethernet do departamento de ciência da computação até
seu edifício. Com o tempo, muitos outros departamentos adquiriram computadores, e o
99
limite de quatro repetidores por rede Ethernet logo foi alcançado. Tornou-se necessária uma
organização diferente.
Seria difícil obter um segundo endereço de rede, pois os endereços de rede são escassos,
e a universidade já tinha endereços suficientes para 65.534 hosts. O problema é a regra
segundo a qual um único endereço da classe A, B ou C se refere a uma rede, e não a um
conjunto de LANs. À medida que mais e mais organizações se encontravam nessa situação,
era feita uma pequena mudança no sistema de endereçamento para lidar com ela.
A solução para esses problemas é permitir que uma rede seja dividida em diversas
partes para uso interno, mas externamente continue a funcionar como uma única rede. Hoje,
uma rede de campus típica seria semelhante à da Figura 7.8, com um roteador principal
conectado a um ISP ou a uma rede regional e numerosas redes Ethernet espalhadas pelo
campus em diferentes departamentos. Cada uma das redes Ethernet tem seu próprio roteador
conectado ao roteador principal (possivelmente por meio de uma LAN de backbone, mas a
natureza da conexão entre roteadores não é relevante nesse caso). Na literatura sobre
Internet, as partes da rede (nesse caso, redes Ethernet) são chamadas de sub-redes.
Figura 7.8 – Uma rede de campus consistindo em LANs para vários departamentos.
Quando um pacote entra no roteador principal, como este sabe para qual sub-rede
(Ethernet) deve entregar o pacote? Uma alternativa seria uma tabela com 65.534 entradas
no roteador principal, informando que roteador usar para cada host do campus. Essa ideia
funcionaria, mas iria exigir uma tabela muito grande no roteador principal e um grande
volume de manutenção manual, à medida que os hosts fossem acrescentados, movidos ou
retirados de serviço.
Em vez disso, foi criado um esquema diferente. Basicamente, em vez de ter um único
endereço da classe B com 14 bits para indicar o número da rede e 16 bits para indicar o
número do host, alguns bits são retirados do número do host para criar um número de subrede. Por exemplo, se a universidade tivesse 35 departamentos, ela poderia usar um número
de sub-rede de 6 bits e um número de host de 10 bits, permitindo até 64 redes Ethernet, cada
uma com o máximo de 1.022 hosts. Essa divisão poderia ser alterada mais tarde, caso ela se
mostrasse incorreta.
Para implementar a divisão em sub-redes, o roteador principal precisa de uma máscara
de sub-rede que indique a divisão entre o número de rede + sub-rede e o host, como mostra
a Figura 7.9. As máscaras de sub-redes também são escritas em notação decimal pontilhada,
com a inclusão de uma barra vertical seguida pelo número de bits na parte de rede + subrede. No exemplo da Figura 7.9, a máscara de sub-rede pode ser escrita como 255.255.252.0.
Uma notação alternativa é /22 para indicar que a máscara de sub-rede tem 22 bits.
100
Figura 7.9 – Uma rede da classe B dividida em 64 sub-redes.
Fora da rede, a divisão em sub-redes não é visível, assim, a alocação de uma nova subrede não exige a intervenção do IANA ou a mudança de quaisquer bancos de dados externos.
Nesse exemplo, a primeira sub-rede pode usar os endereços IP a partir de 130.50.4.1, a
segunda sub-rede pode se iniciar em 130.50.8.1, a terceira sub-rede pode começar em
130.50.12.1 e assim por diante. Para ver por que as sub-redes estão sendo contadas de quatro
em quatro, observe que os endereços binários correspondentes são:
Sub-rede 1: 10000010.00110010.000001|00.00000001 130.50.4.1
Sub-rede 2: 10000010.00110010.000010|00.00000001  130.50.8.1
Sub-rede 3: 10000010.00110010.000011|00.00000001  130.50.12.1
Aqui a barra vertical ( | ) mostra o limite entre o número da sub-rede e o número de
host. À sua esquerda está o número de sub-rede de 6 bits; à sua direita está o número de host
de 10 bits.
Para ver como as sub-redes funcionam, é necessário explicar como os pacotes IP são
processados em um roteador. Cada roteador tem uma tabela que lista algum número de
endereços IP (rede, 0) e uma série de endereços IP (esta rede ou host). O primeiro tipo
informa como chegar a redes distantes. O segundo, como chegar a hosts locais. Associadas
a essa tabela estão a interface de rede usada para alcançar o destino e algumas outras
informações.
Quando um pacote IP é recebido, seu endereço de destino é procurado na tabela de
roteamento. Se o destino for uma rede distante, o pacote será encaminhado para o próximo
roteador da interface fornecida na tabela. Caso o destino seja um host local (por exemplo,
na LAN do roteador), o pacote será enviado para um roteador predefinido que tenha tabelas
maiores. Esse algoritmo significa que cada roteador só precisa controlar as outras redes e
hosts locais, deixando de lado os pares (rede, host), o que reduz muito o tamanho da tabela
de roteamento.
Quando a divisão em sub-redes é introduzida, as tabelas de roteamento são alteradas
acrescentando-se entradas da forma (rede, sub-rede, 0) e (esta rede, esta sub-rede, host).
Sendo assim, um roteador da sub-rede k sabe como alcançar todas as outras sub-redes, e
também como chegar a todos os hosts da sub-rede k. Ele não precisa saber detalhes sobre os
hosts de outras sub-redes. Na realidade, a única modificação é fazer com que cada roteador
seja submetido a um AND booleano com a máscara de sub-rede, a fim de eliminar o número
do host e pesquisar o endereço resultante em suas tabelas (depois de determinar qual é a
classe da rede). Por exemplo, um pacote endereçado a 130.50.15.6 recebido no roteador
principal passa pela operação AND booleana com a máscara de sub-rede 255.255.252.0 para
gerar o endereço 130.50.12.0. Esse endereço é usado para acessar as tabelas de roteamento
com a finalidade de descobrir que linha de entrada usar para chegar ao roteador
correspondente à sub-rede 3. Desse modo, a divisão em sub-redes reduz o espaço na tabela
do roteador, criando uma hierarquia de três níveis que consiste em rede, sub-rede e host.
101
7.13 Técnicas para Resolução de Endereços
Anteriormente foi visto o esquema de endereço do TCP/IP (onde cada host recebe um
endereço de 32 bits) e também foi visto que uma inter-rede se comporta como uma rede virtual,
usando apenas os endereços atribuídos ao enviar e receber pacotes. Também foi visto
anteriormente que duas máquinas em uma determinada rede física só podem se comunicar se
conhecerem o endereço físico uma da outra, com exceção dos casos de broadcasting. O que não
foi mencionado é como um host ou um roteador mapeia um endereço IP para o endereço físico
correto quando precisa enviar um pacote por uma rede física. Veremos agora como este
mapeamento é implementado para os dois esquemas de endereço físico de rede mais comuns.
7.13.1 O Problema da Tradução de Endereço
Considere duas máquinas A e B que se conectam à mesma rede física. Cada uma possui
um endereço IP atribuído IA e IB e um endereço físico FA e FB. Por fim, a comunicação
precisa ser executada pelas redes físicas usando qualquer esquema de endereço físico que o
hardware da rede subjacente fornece. Nosso objetivo, porém, é idealizar o software que
esconde os endereços físicos e permite que programas de alto nível trabalhem apenas com
endereços IP. Por exemplo, considere que a máquina A precise enviar um datagrama à
máquina B pela rede física à qual ambas se conectam, mas A só conhece o endereço IP de B,
IB. Surge a pergunta: como A mapeia o endereço IP de B (IB) no endereço físico de B (FB)?
O mapeamento de endereços precisa ser realizado a cada passo ao longo do caminho
desde a origem até o destino final. Em particular, surgem dois casos. Primeiro, no último
passo da entrega de um datagrama, o datagrama precisa ser enviado por uma rede física até
o destino final. O computador que envia o datagrama precisa mapear o endereço IP do
destino final para o endereço físico do destino antes que a transmissão seja possível. Em
segundo lugar, em qualquer ponto ao longo do caminho da origem ao destino, fora o passo
final, o datagrama precisa ser enviado a um roteador intermediário. Assim, o emissor precisa
mapear o endereço IP do roteador intermediário para o endereço físico.
O problema de mapear os endereços de alto nível em endereços físicos é conhecido
como problema de resolução e foi resolvido de várias maneiras. Alguns pacotes de
protocolos mantêm tabelas em cada máquina, contendo pares de endereços de alto nível e
físicos. Outros protocolos resolvem o problema codificando endereços físicos em endereços
de alto nível. O uso de qualquer uma das técnicas de forma exclusiva torna o endereçamento
de alto nível, no mínimo, desajeitado. Aqui serão discutidas duas técnicas para tradução de
endereços usados pelos protocolos TCP/IP, e mostra quando cada uma é apropriada.
7.13.2 Dois Tipos de Endereços Físicos
Existem dois tipos básicos de endereços físicos: endereços grandes e fixos, como
aqueles usados com Ethernet, e endereços pequenos e facilmente configurados. O TCP/IP
pode acomodar cada um, mas a popularidade da Ethernet significa que a maior parte de todo
o hardware de rede atualmente utiliza endereços grandes. Portanto, consideraremos os
endereços pequenos rapidamente, concentrando-se nos endereços grandes.
7.13.3 Tradução por Mapeamento Direto
Considere o hardware de rede que usa inteiros pequenos e configuráveis, como
endereços físicos. Sempre que um novo computador é acrescentado a essa rede, o
administrador do sistema escolhe um endereço físico e configura a placa de interface de rede
do computador. A única regra importante é que dois computadores não podem ter o mesmo
endereço. Para tornar a atribuição fácil e segura, um administrador normalmente atribui
102
endereços sequencialmente: o primeiro computador na rede recebe o endereço 1, o segundo
computador recebe o endereço 2, e assim por diante.
A chave para fazer a tradução de endereço funcionar com esse hardware de rede está
na observação de que, enquanto alguém tem a liberdade de escolher os endereços IP e físico,
os endereços podem ser selecionados de modo que partes deles sejam idênticas. Em
particular, o endereço IP de um computador pode ter uma parte hostid igual ao endereço
físico. Por exemplo, suponha que o prefixo para uma rede seja 192.5.48.0 com o prefixo de
rede ocupando os três primeiros octetos. O primeiro computador na rede recebe endereço
físico 1 e endereço IP 192.5.48.1, o segundo computador recebe o endereço físico 2 e o
endereço IP 192.5.48.2, e assim por diante. Essencialmente, cada endereço IP na rede
codifica o endereço físico do computador no octeto de baixa ordem.
Se o endereço IP codifica o endereço físico, a tradução de endereço é trivial. No
exemplo anterior, se o software receber o endereço IP de um computador na rede (por
exemplo, 192.5.48.3), o endereço físico correspondente pode ser calculado extraindo o octeto
de baixa ordem. Dizemos que a tradução é realizada pelo mapeamento direto. Por exigir
apenas algumas instruções de máquina, o mapeamento de exemplo é computacionalmente
eficaz e não envolve referências a dados externos. Finalmente, novos computadores podem
ser acrescentados à rede sem alterar as atribuições existentes ou propagar informações para
computadores existentes.
Matematicamente, mapeamento direto significa selecionar uma função f que mapeia
endereços IP para endereços físicos, e resolver o endereço IP IA significa calcular FA  f (I A )
.
Embora seja possível escolher mapeamentos diferentes desse exemplo, queremos que
o cálculo de f seja eficiente, e queremos que as escolhas sejam fáceis para um humano
entender. Assim, é preferível um esquema em que o relacionamento entre o endereço IP e o
endereço físico seja óbvio.
7.13.4 Tradução por Vínculo Dinâmico
Embora eficiente, o mapeamento direto não pode ser usado para tecnologias de
hardware que utilizam o endereçamento Ethernet. Para ver por que, lembre-se de que cada
placa de rede Ethernet recebe um endereço físico de 48 bits quando o dispositivo é fabricado.
Como consequência, quando o hardware falha e exige que uma interface Ethernet seja
substituída, o endereço físico da máquina muda. Além do mais, como o endereço Ethernet
tem 48 bits de extensão, não há esperança de que possa ser codificado em um endereço IP de
32 bits1.
Os projetistas dos protocolos TCP/IP descobriram uma solução criativa para o
problema de tradução de endereço para redes como Ethernet, que possuem capacidade de
broadcast. A solução permite que novos hosts ou roteadores sejam acrescentados à rede sem
recompilar o código, e não exige a manutenção de um banco de dados centralizado. Para
evitar a manutenção de um banco de dados centralizado, os projetistas escolheram usar um
protocolo de baixo nível para vincular endereços dinamicamente. Chamado de ARP
(Address Resolution Protocol – Protocolo de Resolução de Endereços), o protocolo oferece
um mecanismo que é razoavelmente eficiente e fácil de manter.
1
Como o mapeamento direto é mais conveniente e eficaz do que o vínculo dinâmico, a próxima geração do IP (IPv6) está
sendo projetada para permitir que endereços físicos de 48 bits sejam codificados em endereços IP.
103
Como mostra a Figura 7.10, a idéia por trás da tradução dinâmica com ARP é simples:
Quando o host A quer traduzir o endereço IP IB, ele envia por broadcast um pacote especial
que pede ao host com endereço IP IB para responder com seu endereço físico, FB. Todos os
hosts, incluindo B, recebem a requisição, mas somente o host B reconhece seu endereço IP e
envia uma resposta que contém seu endereço físico. Quando A recebe a resposta, ele usa o
endereço físico para enviar o pacote de inter-rede diretamente para B.
Figura 7.10 – O protocolo ARP.
7.13.5 O Cache de Tradução de Endereço
Pode parecer tolice que, para A enviar um pacote para B, ele primeiro envia um
broadcast que atinge B. Ou então pode parecer ainda mais tolice que A transmita por
broadcast a pergunta “como posso alcançar você?” em vez de apenas transmitir o pacote que
deseja entregar. Mas existe um motivo importante para a troca. O broadcasting é muito
mais dispendioso de ser usado toda vez que uma máquina precisa transmitir um pacote para
outra, pois cada máquina na rede precisa receber e processar o pacote broadcast.
7.13.6 Timeout de Cache ARP
Para reduzir os custos de comunicação, os computadores que utilizam ARP mantêm
um cache de vínculos de IP para cada endereço físico adquirido. Ou seja, sempre que um
computador enviar uma requisição ARP e receber uma resposta ARP, ele salva o endereço
IP e a informação do endereço físico correspondente em seu cache para pesquisas sucessivas.
Ao transmitir um pacote, um computador sempre examina seu cache em busca de um vínculo
antes de enviar uma requisição ARP. Se ele encontrar o vínculo desejado em seu cache ARP,
o computador não precisa transmitir um broadcast na rede. Assim, quando dois
computadores em uma rede se comunicam, eles começam com uma requisição (request) e
resposta (reply) ARP, e depois transferem repetidamente os pacotes sem usar ARP para cada
um. A experiência mostra que, como a maior parte da comunicação da rede envolve mais de
uma transferência de pacote, até mesmo um cache pequeno é proveitoso.
O cache ARP oferece um exemplo de estado flexível, uma técnica normalmente usada
nos protocolos de rede. O nome descreve uma situação em que a informação pode se tornar
“velha” sem aviso. No caso do ARP, considere dois computadores, A e B, ambos conectados
a uma rede Ethernet. Considere que A tenha enviado uma requisição ARP e B tenha
respondido. Além disso, considere que, depois da troca, B falhe. O computador A não
receberá qualquer notificação da falha. Além do mais, por já ter a informação de vínculo de
endereço para B em seu cache ARP, o computador A continuará a enviar pacotes para B. O
104
hardware Ethernet não fornece indicação de que B não está mais on-line, pois a Ethernet não
tem entrega garantida. Assim, A não tem como saber quando as informações em seu cache
ARP se tornaram incorretas.
Para acomodar o estado flexível, a responsabilidade pela exatidão se encontra com o
proprietário da informação. Normalmente, os protocolos que implementam estado flexível
utilizam timers, com a informação de estado sendo excluída quando o timer expira. Por
exemplo, sempre que a informação de vínculo é colocada em um cache ARP, o protocolo
exige que um timer seja definido, com tempo limite (timeout) típico de 20 minutos. Quando
o timer expira, a informação precisa ser removida. Depois da remoção, existem duas
possibilidades: se nenhum outro pacote for enviado ao destino, nada ocorrerá. Se um pacote
tiver de ser enviado ao destino e não houver um vínculo presente no cache, o computador
seguirá o procedimento normal de transmitir uma requisição ARP por broadcast e obter o
vínculo. Se o destino ainda for alcançável, o vínculo novamente será colocado no cache
ARP. Se não, o emissor descobrirá que o destino está off-line.
O uso do estado flexível no ARP tem vantagens e desvantagens. A principal vantagem
surge pela autonomia. Primeiro, um computador pode determinar quando a informação em
seu cache ARP deve ser invalidada, independente dos outros computadores. Segundo, um
emissor não precisa da comunicação bem sucedida com o receptor ou um terceiro para
determinar que um vínculo se tornou inválido. Se um destino não responder a uma requisição
ARP, o emissor declarará o destino como parado. Terceiro, o esquema não conta com o
hardware da rede para fornecer transferência confiável. A principal desvantagem do estado
flexível surge pelo retardo. Se o intervalo do timer for de N segundos, um emissor não
detectará que um receptor falhou antes que se passem N segundos.
7.13.7 Funcionamento do ARP
7.13.7.1 Envio de um Datagrama dentro da mesma rede
Vamos supor que o nó 222.222.222.220 da Figura 7.11 queira enviar um
datagrama que tem endereço IP para outro nó daquela rede. O nó remetente precisa
obter o endereço de rede do nó de destino, dado o endereço IP daquele mesmo nó. Essa
tarefa é fácil se a tabela ARP do nó remetente tiver um registro para esse nó de destino.
E se a tabela ARP não tiver o registro do destinatário? Em particular, suponha que o nó
222.222.222.220 queira enviar um datagrama para o nó 222.222.222.222. Nesse caso,
o nó remetente usa o protocolo ARP para converter o endereço. De início, ele monta
um pacote especial chamado pacote ARP. Um pacote ARP tem diversos campos,
incluindo os endereços IP e físico de envio e de recepção, como veremos na
Seção 7.13.12.
105
Figura 7.11 – Cada nó em uma LAN tem um endereço IP e um endereço MAC.
Voltando ao exemplo, o nó 222.222.222.220 passa um pacote de consulta ARP ao
adaptador de rede juntamente com uma indicação de que o adaptador deveria enviar o
pacote ao endereço de broadcast da rede, ou seja, FF–FF–FF–FF–FF–FF. O adaptador
encapsula o pacote ARP em um frame de enlace, usa o endereço de broadcast como
endereço de destino do frame e transmite o frame para dentro da rede. O frame que
contém a consulta ARP é recebido por todos os outros adaptadores da rede, e, por causa
do endereço de broadcast, cada adaptador passa o pacote ARP que está dentro do frame
para seu próprio hospedeiro. Cada nó verifica se seu endereço IP combina com o
endereço IP de destino no pacote ARP. O único nó que atende a essa condição devolve
um pacote ARP de resposta ao nó que fez a consulta, com o mapeamento desejado. O
nó que fez a consulta (222.222.222.220) pode, então, atualizar sua tabela ARP e enviar
seu datagrama IP.
O protocolo ARP apresenta algumas características interessantes. Em primeiro
lugar, a mensagem de consulta ARP é enviada dentro de um frame broadcast, ao passo
que a mensagem de resposta ARP é enviada dentro de um frame padrão unicast. Antes
de continuar a leitura, é bom que você pense por que isso acontece. Em segundo lugar,
o ARP é do tipo plug and play, isto é, uma tabela de nós ARP é construída
automaticamente, ela não tem de ser configurada por um administrador de sistemas. E,
se um nó for desligado da rede, seu registro poderá ser apagado da tabela.
7.13.7.2 Envio de um Datagrama para um nó que está fora da rede
Já deve estar claro agora como o ARP opera quando um nó quer enviar um
datagrama a um outro nó na mesma rede. Mas vamos examinar uma situação mais
complicada, em que um nó de uma rede quer enviar um datagrama de camada de rede
para um nó que esta fora da rede. A Figura 7.12 mostra uma rede virtual simples
constituída de duas redes interconectadas por um roteador.
106
Figura 7.12 – Duas LANs interconectadas por um roteador.
Há diversos pontos interessantes a notar nesta figura. Primeiramente, há dois tipos
de nós: host e roteadores. Cada host tem exatamente um endereço IP e um adaptador.
Mas, como discutimos na Seção 7.12.11, um roteador tem um endereço IP para cada
uma de suas interfaces. Cada interface de roteador também tem seu próprio módulo
ARP (dentro do roteador) e seu próprio adaptador. Como o roteador da Figura 7.12 tem
duas interfaces, ele apresenta dois endereços IP, dois módulos ARP e dois adaptadores.
É claro que cada adaptador da rede tem seu próprio endereço físico.
Note também que todas as interfaces conectadas à rede 1 têm endereços no formato
111.111.111.xxx e que todas as interfaces conectadas à rede 2 têm o formato
222.222.222.xxx. Assim, nesse exemplo, os três primeiros octetos do endereço IP
especificam a rede, enquanto o último octeto indica host específico da rede.
Agora, suponha que o host 111.111.111.111 queira enviar um datagrama IP ao
host 222.222.222.222. O host remetente passa o datagrama a seu adaptador, como
sempre. Mas ele deve indicar a seu adaptador um endereço físico de destino apropriado.
E que endereço físico o adaptador deveria usar? Poderíamos arriscar o palpite que o
endereço físico apropriado é aquele do adaptador do host 222.222.222.222, ou seja, 49–
BD–D2–C7–56–2A. Mas esse palpite está errado. Se o adaptador remetente usasse esse
endereço físico, nenhum dos adaptadores da rede 1 se preocuparia em passar os
datagramas IP para cima, para sua camada de rede, já que o endereço de destino do
frame não combinaria com o endereço físico de nenhum adaptador da rede 1. O
datagrama morreria ali mesmo.
Se examinarmos com cuidado a Figura 7.12, veremos que, para um datagrama ir
de 111.111.111.111 a um nó da rede 2, ele teria de ser enviado antes à interface do
roteador 111.111.111.110. Sendo assim, o host 111.111.111.111 saberia que, para
chegar até o host 222.222.222.222, o datagrama teria de ser enviado antes à interface
do roteador 111.111.111.110. Assim, o endereço físico apropriado para o frame é o
endereço do adaptador da interface do roteador 111.111.111.110, ou seja, E6–E9–00–
17–BB–4B. Como o host remetente consegue o endereço físico de 111.111.111.110?
Usando ARP, é claro! Uma vez que o adaptador remetente tenha seu endereço físico,
ele cria um frame e o envia para a rede 1. O adaptador do roteador da rede 1 verifica
que o frame está endereçado a ele e, por conseguinte, o passa para a camada de rede do
roteador. Viva! O datagrama IP foi transportado com sucesso do host de origem para
o roteador! Mas não acabamos. Ainda temos que levar o datagrama do roteador até o
destino! Como veremos adiante, isso é feito pela consulta a uma tabela de roteamento
107
no roteador. A tabela de roteamento indica ao roteador que o datagrama deve ser
repassado via interface de rede 222.222.222.220 do roteador. Essa interface então passa
o datagrama a seu adaptador, que encapsula em um novo frame e envia o frame para a
rede 2. Dessa vez, o endereço físico de destino do frame é, na verdade, o endereço físico
do destino final. E de onde o roteador obtém esse endereço físico de destino? Do ARP,
é claro.
7.13.8 Refinamentos do ARP
Diversos refinamentos do ARP foram incluídos no protocolo. Primeiro, observe que
se o host A estiver para usar ARP, pois precisa enviar para B, existe uma alta probabilidade
de que o host B precise enviar para A no futuro próximo. Para antecipar a necessidade de B
e evitar tráfego extra na rede, A inclui seu vínculo de endereço IP para físico ao enviar uma
requisição para B. B extrai o vínculo de A da requisição, salva o vínculo em seu cache ARP
e depois envia uma resposta para A. Segundo, observe que, como A envia sua requisição
inicial por broadcast, todas as máquinas na rede recebem e podem extrair o vínculo de
endereço IP para físico A e usar a informação a fim de atualizar o vínculo em seu cache.
Terceiro, quando um computador tiver sua interface de host substituída (por exemplo, porque
o hardware falhou), seu endereço físico mudará. Outros computadores na rede que
armazenaram um vínculo em seu cache ARP precisam ser informados para que possam
mudar a entrada. O computador pode notificar os outros quanto ha um novo endereço
enviando uma requisição ARP gratuita por broadcast ao reiniciar1.
7.13.9 Relacionamento do ARP com outros Protocolos
O ARP forneceu um mecanismo possível para mapear endereços IP para endereços
físicos. Já vimos que as tecnologias de hardware que admitem mapeamento direto não
precisam de ARP. O ponto é que o ARP seria completamente desnecessário se pudéssemos
fazer com que todo o hardware da rede reconheça endereços IP. Assim, o ARP simplesmente
impõe um novo esquema de endereço em cima de qualquer mecanismo de endereço de baixo
nível que o hardware utilize.
7.13.10 Implementação do ARP
Funcionalmente, o ARP é dividido em duas partes. A primeira parte mapeia um
endereço IP para um endereço físico ao enviar um datagrama, e a segunda parte responde as
requisições de outras máquinas. A tradução de endereços para os datagramas que saem
parece ser direta, mas pequenos detalhes complicam uma implementação. Dado um endereço
IP de destino, o software consulta seu cache ARP para ver se conhece o mapeamento do
endereço IP para o endereço físico. Se conhecer, o software extrai o endereço físico, coloca
os dados em um frame usando esse endereço e envia o frame. Se não conhecer o
mapeamento, o software precisa enviar uma requisição ARP por broadcast e esperar uma
resposta.
O broadcasting de uma requisição ARP para encontrar um mapeamento de endereço
pode se tornar complexo. A máquina de destino pode estar parada ou muito ocupada para
aceitar a requisição. Se isso acontecer, o emissor pode não receber uma resposta ou a resposta
pode ser atrasada. Como a Ethernet é um sistema de entrega pelo melhor esforço, a
requisição por broadcast ARP inicial também pode ser perdida (quando o emissor deve
retransmitir, pelo menos uma vez). Nesse meio tempo, o host precisa armazenar o pacote de
1
Tipicamente, a máquina reiniciando envia uma requisição para seu próprio endereço IP como um meio de verificar se
nenhum outro computador acidentalmente recebeu o mesmo endereço IP.
108
saída original de modo que ele possa ser enviado quando o endereço tiver sido traduzido1.
De fato, o host precisa decidir se permitirá que outras aplicações prossigam enquanto
processa uma requisição ARP (a maioria faz isso). Nesse caso, o software precisa lidar com
o caso em que uma aplicação gera datagramas que exigem tradução do mesmo endereço sem
o broadcasting de várias requisições para determinado destino.
Finalmente, considere o caso em que a máquina A obteve um vínculo com a máquina
B, mas depois o hardware de B falha e é substituído. Embora o endereço de B tenha mudado,
o vínculo em cache de A não mudou, de modo que A usa um endereço físico inexistente,
impossibilitando o sucesso do recebimento. Esse caso mostra por que é importante ter o ARP
tratando sua tabela de vínculos como um cache e remover as entradas após um período
determinado. Naturalmente, o timer para uma entrada no cache precisa ser reiniciado sempre
que um broadcast ARP chega contendo o vínculo (mas ele não é reiniciado quando a entra é
usada para enviar um pacote).
A segunda parte do código ARP trata de pacotes ARP que chegam da rede. Quando
um pacote ARP chega, o software primeiro extrai o endereço IP do emissor e o par de
endereços físicos. Logo em seguida, examina o cache local a fim de verificar se já tem uma
entrada para o emissor. Se existir uma entrada de cache para determinado endereço IP, o
software atualiza essa entrada sobrescrevendo o endereço físico com o endereço físico obtido
do pacote. Então, o receptor processa o restante do pacote ARP.
Um receptor precisa lidar com dois tipos de pacotes ARP que chegam. Se uma
requisição ARP chegar, a máquina receptora precisa ver se ela é o destino da requisição (ou
seja, alguma outra máquina enviou uma requisição por broadcast para o endereço físico do
receptor). Se isso aconteceu, o ARP forma uma resposta fornecendo seu endereço físico e
envia a resposta diretamente de volta ao requisitante. O receptor também acrescenta o par de
endereços do emissor ao seu cache se o par ainda não estiver presente. Se o endereço IP
mencionado na requisição ARP não combinar com o endereço IP local, o pacote está
solicitando um mapeamento para alguma outra máquina na rede e pode ser ignorado.
O outro caso interessante ocorre quando chega uma resposta ARP. Dependendo da
implementação, o software pode ter de criar uma entrada de cache, ou a entrada pode ter sido
criada quando a requisição foi gerada. De qualquer forma, uma vez atualizado o cache, o
receptor tenta combinar a resposta com uma requisição previamente emitida. Normalmente,
as respostas chegam como resultado de uma requisição, que foi gerada porque a máquina tem
um pacote a enviar. Entre o momento em que uma máquina envia sua requisição ARP e
recebe a resposta, os programas de aplicativos ou protocolos de níveis superiores podem gerar
requisições adicionais para o mesmo endereço. O software precisa lembrar de que já enviou
uma requisição e então não enviar outra. Normalmente, o ARP coloca os pacotes adicionais
em uma fila e usa o vínculo de endereço para preencher o endereço físico do destino. Se ele
não emitiu anteriormente uma requisição para o endereço IP na resposta, a máquina atualiza
a entrada do emissor em seu cache e depois simplesmente termina o processamento do
pacote.
7.13.11 Encapsulamento e Identificação do ARP
Quando as mensagens ARP trafegam de uma máquina para outra, elas precisam ser
transportadas em frames físicos. A Figura 7.13 mostra que a mensagem ARP é transportada
na parte de dados de um frame.
1
Se o atraso for significativo, o host poderá decidir descartar o(s) datagrama(s) de saída.
109
Figura 7.13 – Uma mensagem ARP encapsulada em um frame de rede física.
Para identificar o frame que está transportando uma mensagem ARP, o emissor atribui
um valor especial ao campo de tipo no cabeçalho do frame e coloca a mensagem ARP no seu
campo de dados. Quando um frame chega a um computador, o software de rede utiliza o tipo
de frame para determinar seu conteúdo. Na maioria das tecnologias, um único valor de tipo
é usado para todos os frames que transportam uma mensagem ARP. O software de rede no
receptor precisa examinar melhor a mensagem ARP para distinguir entre requisições ARP e
respostas ARP. Por exemplo, em uma Ethernet, os frames transportando mensagens ARP
têm um campo de tipo com o valor (0806)16. Esse é um valor padrão atribuído pela autoridade
para Ethernet. Outras tecnologias de hardware de rede utilizam outros valores.
7.13.12 Formato do Protocolo ARP
Diferente da maioria dos protocolos, os dados nos pacotes ARP não possuem um
cabeçalho de formato fixo. Em vez disso, para tornar o ARP útil para diversas tecnologias
de rede, a extensão dos campos que contêm endereços depende do tipo de rede. Porém, para
possibilitar a interpretação de uma mensagem ARP qualquer, o cabeçalho inclui campos fixos
perto do início, que especificam os tamanhos dos endereços encontrados nos campos
seguintes. De fato, o formato da mensagem ARP é genérico o suficiente para permitir que
seja usado com quaisquer endereços físicos e de protocolo. O exemplo na Figura 7.14 mostra
o formato da mensagem ARP em 28 octetos usado no hardware Ethernet (em que os
endereços físicos possuem 48 bits ou 6 octetos de extensão), ao traduzir endereços de
protocolo IP (que possuem 4 octetos de extensão).
0
1
2
3
8
6
4
1
TIPO DE HARDWARE
TIPO DE PROTOCOLO
HLEM
PLEM
OPERAÇÃO
Endereço de Hardware EMISSOR (octetos 0 – 3)
Endereço de Hardware EMISSOR (octetos 4 – 5)
IP EMISSOR (octetos 0 – 1)
IP EMISSOR (octetos 2 – 3)
Endereço de Hardware DESTINO (octetos 0 – 1)
Endereço de Hardware DESTINO (octetos 2 – 5)
IP DESTINO (octetos 0 – 3)
Figura 7.14 – Formato de uma Mensagem ARP/RARP para o padrão Ethernet.
A Figura 7.14 mostra uma mensagem ARP com 4 octetos por linha. Infelizmente,
diferente da maioria dos protocolos restante, os campos de tamanho variável nos pacotes
ARP não se alinham bem em limites de 32 bits, tornando o diagrama difícil de ser lido. Por
exemplo, o endereço físico do emissor, rotulado como Endereço de Hardware EMISSOR,
ocupa 6 octetos contíguos, de modo que se espalha por duas linhas no diagrama.
O campo TIPO DE HARDWARE especifica um tipo de interface de hardware para o
qual o emissor busca uma resposta. Ele contém o valor 1 para Ethernet. De modo
semelhante, o campo TIPO DE PROTOCOLO especifica o tipo de endereço de protocolo de
alto nível que o emissor forneceu. Ele contém (0800) 16 para endereços IP. O campo
OPERAÇÃO especifica uma requisição ARP (7), resposta ARP (2), requisição RARP (3) ou
110
resposta RARP (4). Mais à frente falaremos sobre o RARP. Os campos HLEN e PLEN
permitem que o ARP seja usado com redes quaisquer, pois especificam o tamanho do
endereço de hardware e o tamanho do endereço de protocolo de alto nível. O emissor fornece
seu endereço de hardware e endereço IP, se conhecidos, nos campos ENDEREÇO DE
HARDWARE EMISSOR e IP EMISSOR.
Ao fazer uma requisição, o emissor também fornece o endereço de hardware de destino
(RARP) ou endereço IP de destino (ARP) usando os campos ENDEREÇO DE HARDWARE
DESTINO ou IP DESTINO. Antes que a máquina de destino responda, ela preenche os
endereços que faltam, inverte os pares de destino e emissor e muda a operação para uma
resposta. Assim, uma resposta transporta os endereços IP e físicos do requisitante original,
além dos endereços IP e físicos da máquina para a qual um vínculo foi buscado.
7.13.13 Revalidação Automática de Cache ARP
É possível usar uma técnica que evita a introdução de jitter (ou seja, variação nos
tempos de transferência de pacotes). Para entender a situação, observe que sempre que um
timer ARP expira, o próximo datagrama enviado ao endereço experimenta um atraso extra
porque o datagrama espera em uma fila até que o ARP envie uma requisição e receba uma
resposta. Além do mais, a expiração pode ocorrer a qualquer momento, possivelmente
durante um período de tráfego constante. Embora esses atrasos normalmente sejam
negligenciáveis, eles introduzem jitter.
A chave para evitar o jitter surge da revalidação antecipada, ou seja, a implementação
associa dois contadores a cada entrada no cache ARP: o timer tradicional e um timer de
revalidação. Quando o timer de revalidação expira, o software examina a entrada. Se os
datagramas tiverem usado a entrada recentemente, o software envia uma requisição ARP e
continua a usar a entrada. Ao receber a requisição, a estação destino responde, e os dois
timers são reiniciados. Se nenhuma resposta chegar, o timer tradicional expira, e os
datagramas são mantidos enquanto o ARP tenta obter uma resposta. Na maioria dos casos,
porém, uma revalidação pode reiniciar o timer sem interrupção.
7.13.14 Reverse Address Resolution (RARP)
Vimos que o campo de operação em um pacote ARP pode especificar uma mensagem
RARP (Reverse Address Resolution). RARP não é mais importante na Internet, mas já foi
um protocolo essencial usado para efetuar o boot de sistemas que não tinham armazenamento
estável. Essencialmente, RARP permite que um sistema obtenha um endereço IP na partida.
O procedimento é simples: ao inicializar, o sistema envia uma requisição RARP e espera uma
resposta. Outro computador na rede precisa ser configurado para escutar requisições RARP
e gerar uma resposta RARP que contém o endereço IP do requisitante. Quando a resposta
chega, o sistema continua a inicialização e usa o IP para toda a comunicação.
Ao fazer uma requisição RARP, um sistema precisa se identificar para que o
computador, recebendo a requisição, possa substituir o endereço IP correto na resposta.
Embora qualquer identificação exclusiva de hardware seja suficiente (por exemplo, o
número de série da CPU), RARP utiliza uma identificação óbvia: o endereço MAC do
sistema. Ou seja, um sistema inicializando coloca seu endereço MAC na requisição RARP
e recebe seu endereço IP na resposta RARP.
É interessante que o RARP use o mesmo formato de pacote ARP. Uma requisição
RARP é formada preenchendo o campo de endereço do protocolo de destino, alterando o tipo
de mensagem de requisição para resposta e enviando a resposta de volta diretamente para a
máquina que fez a requisição.
111
Assim como uma mensagem ARP, uma mensagem RARP é enviada de uma máquina
para outra encapsulada na parte de dados de um frame de rede. Por exemplo, um frame
Ethernet transportando uma requisição ARP possui o preâmbulo normal, os endereços de
origem e destino Ethernet e o campo de tipo de pacote na frente do frame. O tipo de frame
contém o valor (8035)16 para identificar o conteúdo do frame como uma mensagem RARP.
7.14 Entrega de Datagramas Sem Conexão
Nesta seção veremos o princípio fundamental da entrega sem conexão e também como ele
é fornecido pelo IP, que é um dos dois principais protocolos usados nas inter-redes (TCP sendo o
outro). Veremos o formato dos pacotes IP na versão 4 (IPv4) e também como eles formam a base
para toda a comunicação na inter-rede.
7.14.1 Sistema de Entrega sem Conexão
O serviço de inter-rede mais fundamental consiste em um sistema de entrega de
pacotes. Tecnicamente, o serviço é definido como um sistema de entrega de pacotes nãoconfiável, de melhor esforço, sem conexão, semelhante ao serviço fornecido pelo hardware
de rede que opera sobre um paradigma de entrega pelo melhor esforço. O serviço é
denominado não-confiável porque a entrega não é garantida. O pacote pode ser perdido,
duplicado, adiado ou entregue fora de ordem, mas o serviço não detectará essas condições,
nem informará ao emissor ou receptor. O serviço é denominado sem conexão porque cada
pacote é tratado independentemente de todos os outros. Uma sequência de pacotes enviados
de um computador para outro pode trafegar por diferentes caminhos, ou alguns podem se
perder enquanto outros são entregues. Finalmente, o serviço é considerado como entrega
pelo melhor esforço porque o software de inter-rede faz a melhor tentativa de entregar os
pacotes, ou seja, a Rede não descarta pacotes caprichosamente. A não confiabilidade surge
apenas quando os recursos são esgotados ou as redes subjacentes falham.
7.14.2 Finalidade do Internet Protocol (IP)
O protocolo que define o mecanismo de entrega não confiável, sem conexão, é
denominado Internet Protocol (IP). Como a versão atual do protocolo é a versão 4,
normalmente ele é conhecido como IPv4: quando a versão não é ambígua, ele é conhecido
como IP. O IP provê três definições importantes. Primeiro, o protocolo IP define a unicidade
básica de transferência de dados usada por toda uma Rede TCP/IP. Assim, ele especifica o
formato exato de todos os dados à medida que passam pela inter-rede. Segundo, o IP realiza
a função de encaminhamento, escolhendo um caminho pelo qual um pacote será enviado.
Terceiro, além da especificação precisa e formal dos formatos de dados e encaminhamento,
o IP inclui um conjunto de regras que incorporam a ideia da entrega não-confiável. As regras
caracterizam como os hosts e roteadores devem processar pacotes, como e quando as
mensagens de erro devem ser geradas e as condições sob as quais os pacotes podem ser
descartados. IP é uma parte tão fundamental do projeto que a Internet às vezes é chamada
de tecnologia baseada em IP.
7.14.3 O Datagrama IPv4
A analogia entre uma rede física e uma inter-rede TCP/IP é forte. Em uma rede física,
a unidade de transferência é um frame que contém um cabeçalho e dados, onde o cabeçalho
dá informações como os endereços (físicos) de origem e destino. A inter-rede chama sua
unidade de transferência básica de datagrama internet, normalmente abreviado como
datagrama IP ou simplesmente datagrama. Assim como um frame, de rede física, um
datagrama é dividido em áreas de cabeçalho e dados. Também como um frame, o cabeçalho
do datagrama contém os endereços de origem e destino e um campo de tipo que identifica o
conteúdo do datagrama. A diferença, naturalmente, é que o cabeçalho do datagrama contém
112
endereços IP, enquanto o cabeçalho do frame contém endereços físicos. A Figura 7.15
mostra o formato geral de um datagrama.
Cabeçalho do Datagrama
Área de dados do Datagrama
Figura 7.15 – Formato Geral de um Datagrama IP.
7.14.4 Formato do Datagrama
Agora que descrevemos o layout geral de um datagrama IP, podemos examinar o
conteúdo com mais detalhes. A Figura 7.16 mostra o arranjo dos campos em um datagrama.
0
2
3
4
1
VERS
HLEN
TIPO DE SERVIÇO
TAMANHO TOTAL
IDENTIFICAÇÃO
FLAGS
OFFSET DO FRAGMENTO
Tempo de Vida (TTL)
PROTOCOLO
CHECKSUM DO CABEÇALHO
ENDEREÇO IP ORIGEM
ENDEREÇO IP DESTINO
OPÇÕES IP (SE HOUVER)
PREENCHIMENTO
DADOS
DADOS (CONTINUAÇÃO) ...
Figura 7.16 – Formato de um Datagrama IP.
4
8
1
6
1
9
Como o processamento do datagrama ocorre no software, o conteúdo e o formato não
são restritos por qualquer hardware. Por exemplo, o primeiro campo de 4 bits em um
datagrama (VERS) contém a versão do protocolo IP que foi usada para criar o datagrama.
Ele é usado para verificar se o emissor, receptor e quaisquer roteadores entre eles concordam
sobre o formato do datagrama. Todo protocolo IP precisa verificar o campo de versão antes
de processar um datagrama, para garantir que ele combine com o formato que o software
espera. Se os padrões mudarem, as máquinas rejeitarão datagramas com versões de
protocolo que diferem da sua, evitando que interpretem de forma errada o conteúdo do
datagrama, de acordo com um formato desatualizado. Para o IPv4, o campo de versão
contém 4.
O campo de tamanho do cabeçalho (HLEN), também de 4 bits, dá o tamanho do
cabeçalho do datagrama, medido em palavras de 32 bits. Como veremos, todos os campos
no cabeçalho possuem tamanho fixo, exceto para os campos de OPÇÕES IP e
PREENCHIMENTO correspondentes. O cabeçalho mais comum, que não contém opções e
preenchimento, mede 20 octetos e tem um campo de tamanho de cabeçalho igual a 5.
O campo de TAMANHO TOTAL indica o tamanho do datagrama IP medido em octetos,
incluindo os octetos no cabeçalho e nos dados. O tamanho da área de dados pode ser
calculado subtraindo o tamanho do cabeçalho (HLEN) do TAMANHO TOTAL. Como o
campo TAMANHO TOTAL possui 16 bits de extensão, o tamanho máximo possível de um
datagrama IP é de 216 – 1 ou 65.535 octetos. Na maioria das aplicações, isso não é uma
limitação severa. Pode se tornar mais importante no futuro se redes de maior velocidade
puderem transportar pacotes maiores do que 65.535 octetos.
7.14.5 Encapsulamento de Datagramas IP
Antes que possamos entender os próximos campos em um datagrama, é importante
considerar como os datagramas se relacionam com os frames da rede física. Começamos
com uma pergunta: “que tamanho um datagrama pode ter?” Diferente dos frames de rede
física, que precisam ser reconhecidos pelo hardware, os datagramas são tratados pelo
software. Eles podem ter qualquer tamanho escolhido pelos projetistas de protocolo. Vimos
113
que o formato do datagrama IPv4 aloca 16 bits ao campo de tamanho total, limitando o
datagrama a no máximo 65.535 octetos.
Na prática, surgem limites mais fundamentais no tamanho do datagrama. Sabemos
que, quando os datagramas passam de uma máquina para outra, eles sempre precisam ser
transportados pela rede física subjacente. Para tornar o transporte da inter-rede eficiente, é
preciso garantir que cada datagrama trafegue em um frame físico distinto. Ou seja, queremos
que nossa abstração do pacote da rede física seja mapeada diretamente para um pacote real,
se possível.
A ideia de transportar um datagrama em um frame de rede é chamada de
encapsulamento. Para a rede subjacente, um datagrama é como qualquer outra mensagem
enviada de uma máquina para outra. O hardware não reconhece o formato do datagrama,
nem entende o endereço de destino IP. Assim, como mostra a Figura 7.17, quando uma
máquina envia um datagrama IP para outra, o datagrama inteiro trafega na parte de dados
do frame de rede1.
Figura 7.17 – O encapsulamento de um datagrama IP em um frame.
7.14.6 Tamanho do Datagrama, MTU da rede e Fragmentação
No caso ideal, o datagrama IP inteiro se encaixa em um frame físico, tornando eficiente
a transmissão pela rede física. Para alcançar essa eficiência, os projetistas do IP poderiam
ter selecionado um tamanho de datagrama máximo, de modo que um datagrama sempre
encaixe em um frame. Mas qual tamanho de frame deve ser escolhido? Afinal, um
datagrama pode trafegar por muitos tipos de redes físicas enquanto passa por uma inter-rede
até o seu destino final.
Para entender o problema, precisamos de um fato sobre o hardware da rede: cada
tecnologia de comutação de pacotes impõe um limite superior fixo sobre a quantidade de
dados que podem ser transferidos em um frame físico. Por exemplo, Ethernet limita as
transferências a 1.500 octetos de dados. Vamos nos referir aos limites como MTU (Maximum
Transfer Unit – Unidade Máxima de Transferência). Os tamanhos de MTU podem ser
maiores do que 1.500 ou menores: algumas tecnologias de hardware limitam as
transferências a 128 octetos. Limitar os datagramas para caber na menor MTU possível na
inter-rede torna as transferências ineficazes quando os datagramas passam por uma rede que
pode transportar frames de maior tamanho. Porém, permitir que os datagramas sejam
maiores que a MTU mínima da rede em uma inter-rede significa que um datagrama nem
sempre poderá caber em um único frame da rede.
A escolha deve ser óbvia: a finalidade de uma inter-rede é ocultar as tecnologias de
rede básicas e tornar a comunicação conveniente para o usuário. Assim, em vez de projetar
1
Um campo no cabeçalho do frame normalmente identifica os dados sendo transportados: Ethernet usa o valor (0800)16,
para especificar que a área de dados contém um datagrama IP encapsulado.
114
datagramas que aderem às restrições das redes físicas, o TCP/IP escolhe um tamanho de
datagrama inicial conveniente e arruma uma maneira de dividir datagramas grandes em
partes menores quando o datagrama precisa atravessar uma rede que possui uma MTU
pequena. As partes pequenas em que um datagrama é dividido são chamadas de fragmentos,
e o processo de dividir um datagrama é conhecido como fragmentação.
Como a Figura 7.18 mostra, a fragmentação normalmente ocorre em um roteador em
algum lugar entre a origem do datagrama e seu destino final. O roteador recebe um
datagrama de uma rede com uma MTU grande e precisa enviá-lo por uma rede para a qual a
MTU é menor do que o tamanho do datagrama.
Figura 7.18 – Um exemplo de necessidade de fragmentação.
Na figura, os dois hosts se conectam diretamente a Ethernet que possuem uma MTU
de 1.500 octetos. Assim, os dois hosts podem gerar e enviar datagramas com até 1.500
octetos de extensão. O caminho entre eles, porém, inclui uma rede com uma MTU de 620
octetos. Se o host A enviar ao host B um datagrama maior que 620 octetos, o roteador R1
fragmentará o datagrama. De modo semelhante, se o host B enviar um datagrama maior
para o host A, o roteador R2 fragmentará o datagrama.
O tamanho do fragmento é escolhido de modo que cada fragmento possa ser entregue
pela rede em um único frame. Além disso, como o IP representa o offset dos dados em
múltiplos de oito octetos, o tamanho do fragmento precisa ser escolhido como um múltiplo
de oito. Naturalmente, a escolha do múltiplo de oito octetos mais próxima da MTU da rede
em geral não divide o datagrama em partes de mesmo tamanho. A última parte normalmente
é menor que as outras. Os fragmentos precisam ser remontados para produzir uma cópia
completa do datagrama original antes que ele possa ser processado no destino.
O protocolo IP não limita os datagramas a um tamanho pequeno, nem garante que
datagramas grandes serão entregues sem fragmentação. A origem pode escolher qualquer
tamanho de datagrama que achar apropriado. A fragmentação e a remontagem ocorrem
automaticamente, sem que a origem tome alguma ação especial. A especificação IP afirma
que os roteadores precisam aceitar datagramas até o máximo das MTUs das redes às quais
se conectam. Além disso, um roteador sempre precisa tratar de datagramas com até 576
octetos, consequentemente, os hosts também precisam aceitar e remontar, se necessário,
datagramas de 576 octetos.
A fragmentação de um datagrama significa dividi-lo em várias partes. Você poderá
ficar surpreso ao descobrir que cada parte tem o mesmo formato do cabeçalho original. A
Figura 7.19 ilustra o resultado da fragmentação de um datagrama com 1.400 octetos para a
transmissão da Figura 7.18.
115
Cabeçalho IP
(20 bytes)
Dados 1
(600 octetos)
Dados 2
(600 octetos)
Dados 3
(200 octetos)
Cabeçalho IP do Fragmento 1
(20 bytes)
Dados 1
(600 octetos)
mf = 1
offset 0
(20 bytes)
Dados 2
(600 octetos)
mf = 1
offset 600
(20 bytes)
Dados 3
(200 octetos)
mf = 0
offset 1.200
Figura 7.19 – Exemplo de Fragmentação de um Datagrama.
Cada fragmento contém um cabeçalho de datagrama que duplica a maior parte do
cabeçalho do datagrama original (exceto por um bit no campo de FLAGS que o mostra como
um fragmento), seguido pelo máximo de dados que puderem ser transportados no fragmento
enquanto mantém o tamanho total menor que a MTU da rede na qual deverá atravessar.
7.14.7 Remontagem de Fragmentos
Um datagrama deverá ser remontado depois de passar por uma rede, ou os fragmentos
devem ser transportados para o host final antes da remontagem? Em uma inter-rede TCP/IP,
quando um datagrama é fragmentado, os fragmentos trafegam como datagramas separados
por todo o caminho até o destino final, onde precisam ser remontados. A preservação de
fragmentos até o destino final tem duas desvantagens. Primeiro, como os datagramas não
são remontados imediatamente depois de passar por uma rede com MTU pequena, os
pequenos fragmentos precisam ser transmitidos do ponto da fragmentação até o destino final.
A remontagem de datagramas no destino final pode levar a ineficiência, mesmo que algumas
das redes físicas encontradas após o ponto de fragmentação tenham grande capacidade de
MTU, pois somente pequenos fragmentos as atravessarão. Em segundo lugar, se quaisquer
fragmentos forem perdidos, o datagrama não poderá ser remontado. A máquina receptora
inicia um timer de remontagem quando recebe um fragmento inicial. Se o timer expirar antes
que todos os fragmentos cheguem, a máquina receptora descartará as partes sobreviventes
sem processar o datagrama. Assim, a probabilidade de perda de datagrama aumenta quando
a fragmentação ocorre, pois a perda de um único fragmento resulta na perda do datagrama
inteiro.
Apesar das pequenas desvantagens, a realização da remontagem no destino final
funciona bem. Ela permite que cada fragmento seja encaminhado de forma independente, e
não exige que os roteadores intermediários armazenem ou remontem fragmentos.
7.14.8 Controle de Fragmentação
Três campos no cabeçalho do datagrama, IDENTIFICAÇÃO, FLAGS e OFFSET DO
FRAGMENTO, controlam a fragmentação e a remontagem de datagramas. O campo
IDENTIFICAÇÃO contém um inteiro exclusivo que identifica o datagrama. Lembre-se de
que, quando um roteador fragmenta um datagrama, ele copia a maior parte dos campos no
cabeçalho do datagrama em cada fragmento. Assim, o campo IDENTIFICAÇÃO precisa ser
copiado. Sua finalidade principal é permitir que o destino saiba quais fragmentos que chegam
pertencem a quais datagramas. Quando um fragmento chega, o destino usa o campo
IDENTIFICAÇÃO junto com o endereço de origem do datagrama para identificar o
datagrama. Os computadores que enviam datagramas IP precisam gerar um valor exclusivo
116
para o campo IDENTIFICAÇÃO para cada datagrama. Uma técnica utilizada pelo IP é
manter um contador global na memória, incrementando-o toda vez que um novo datagrama
é criado e atribui o resultado ao campo IDENTIFICAÇÃO do datagrama.
Lembre-se de que cada fragmento tem exatamente o mesmo formato de um datagrama
completo. Para um fragmento, o campo OFFSET DO FRAGMENTO especifica o offset no
datagrama original dos dados sendo transportados no fragmento, medidos em unidades de 8
octetos1, começando com o offset zero. Para remontar o datagrama, o destino precisa obter
todos os fragmentos a partir do fragmento que possui offset 0 até aquele com offset mais alto.
Os fragmentos não necessariamente chegam na ordem, e não existe comunicação entre o
roteador que fragmentou o datagrama e o destino tentando remontá-lo.
Os dois bits de baixa ordem do campo FLAGS de 3 bits controlam a fragmentação.
Normalmente, a aplicação que utiliza TCP/IP não se importa com a fragmentação, pois tanto
a fragmentação quanto a remontagem são procedimentos automáticos, que ocorrem em um
nível baixo no sistema operacional, invisível aos usuários finais. Porém, para testar o
software de inter-rede ou depurar problemas operacionais, pode ser importante testar os
tamanhos dos datagramas para os quais ocorre a fragmentação. O primeiro bit de controle
ajuda no teste, especificando se o datagrama pode ser fragmentado. Uma aplicação pode
escolher não permitir a fragmentação quando somente o datagrama inteiro é útil. Por
exemplo, considere uma seqüência de bootstrap em que um pequeno sistema embutido
executa um programa na ROM que envia uma requisição pela inter-rede à qual outra máquina
responde enviando de volta uma imagem da memória. Se o sistema embutido tiver sido
projetado de modo que precise da imagem inteira ou nenhuma dela, o datagrama deverá ter
o bit não fragmentar marcado. Sempre que um roteador precisar fragmentar um datagrama
que tenha o bit não fragmentar marcado, o roteador descarta o datagrama e envia uma
mensagem de erro de volta à origem.
O bit de baixa ordem no campo FLAGS especifica se o fragmento contém dados do
meio do datagrama original ou do final. Ele é chamado de bit mais fragmentos. Para ver
por que esse bit é necessário, considere o protocolo IP no destino final tentando remontar um
datagrama. Ele receberá fragmentos (possivelmente fora de ordem) e precisa saber quando
recebeu todos os fragmentos para um datagrama. Quando um fragmento chega, o campo de
TAMANHO TOTAL no cabeçalho refere-se ao tamanho do fragmento e não ao tamanho do
datagrama original, de modo que o destino não pode usar o campo TAMANHO TOTAL para
dizer se ele coletou todos os fragmentos. O bit mais fragmentos soluciona o problema com
facilidade: quando o destino recebe um fragmento com o bit mais fragmentos desmarcado,
ele sabe que esse fragmento transporta dados da ponta do datagrama original. Examinando
o OFFSET DO FRAGMENTO e o TAMANHO TOTAL de todos os fragmentos que chegaram,
um receptor pode saber se os fragmentos disponíveis contêm todas as partes necessárias para
remontar o datagrama original.
7.14.9 Time to Live (TTL)
A princípio, o campo TIME TO LIVE especifica quanto tempo, em segundos, o
datagrama tem permissão para permanecer no sistema da inter-rede. A ideia é simples e
importante: sempre que um computador injeta um datagrama na inter-rede, ele define um
tempo máximo em que o datagrama deve sobreviver. Os roteadores e os hosts que processam
datagramas precisam decrementar o campo TIME TO LIVE à medida que o tempo passa e
remover o datagrama da inter-rede quando seu tempo expirar.
1
Para economizar espaço no cabeçalho, os offsets são especificados em múltiplos de 8 octetos.
117
A estimativa de tempos exatos é difícil porque os roteadores normalmente não
conhecem o tempo de trânsito para as redes físicas. Algumas regras simplificam o
processamento e facilitam o tratamento de datagramas sem clocks sincronizados. Primeiro,
cada roteador ao longo do caminho da origem ao destino precisa decrementar o campo TIME
TO LIVE em 1 quando processar o cabeçalho do datagrama. Além do mais, como os
roteadores eram inicialmente lentos, o padrão original especificava que, se um roteador
mantém um datagrama por K segundos, o roteador deve decrementar o TIME TO LIVE em
K.
Embora já tenha sido importante, a noção de um roteador atrasando um datagrama por
muitos segundos agora está desatualizada. Os roteadores e as redes atuais são projetados
para encaminhar cada datagrama dentro de alguns milissegundos, no máximo. Se o atraso
se tornar excessivo, o roteador simplesmente descartará o datagrama. Assim, na prática, o
TIME TO LIVE atua como um “limite de salto”, em vez de uma estimativa de atraso. Cada
roteador no caminho (ou seja, cada salto) decrementa o valor em 1.
Sempre que um campo TIME TO LIVE atingir zero, o roteador descarta o datagrama e
envia uma mensagem de erro de volta à origem. A ideia de manter um timer para os
datagramas é interessante porque garante que os datagramas não podem trafegar por uma
inter-rede para sempre, mesmo que as tabelas de roteamento sejam adulteradas e os
roteadores encaminhem datagramas em um círculo. Assim, o campo TIME TO LIVE pode
ser visto como um mecanismo seguro contra falhas.
7.15 Encaminhamento de Datagramas
Vimos que todos os serviços inter-rede utilizam um sistema de entrega de pacotes
subjacentes, sem conexão, e que a unidade básica de transferência em uma Rede TCP/IP é o
datagrama IP. Veremos agora a descrição do serviço sem conexão, mostrando como os
roteadores encaminham datagramas IP e os remetem aos seus destinos finais. Pensamos no
formato de datagrama visto anteriormente como caracterizando os aspectos estáticos do IP. A
descrição de encaminhamento caracteriza os aspectos operacionais.
7.15.1 Encaminhamento em uma Inter-rede
Tradicionalmente, o termo roteamento (routing) era usado com sistemas de comutação
de pacotes, como a inter-rede, para se referir ao processo de escolher um caminho pelo qual
os pacotes são enviados, e o termo roteador era usado para descrever o sistema que faz essa
escolha.
Mais recentemente, os engenheiros adotaram o termo encaminhamento
(forwarding) para se referir ao processo de escolha do caminho para um pacote, mas
retiveram o termo roteador para se referir ao sistema que faz a escolha. Seguiremos o uso
popular, e usaremos o termo encaminhamento.
O encaminhamento ocorre em vários níveis. Por exemplo, dentro de uma Ethernet
comutada, que se espalha por vários chassis físicos, os switches são responsáveis por
encaminhar frames Ethernet do momento em que um frame entra inicialmente até o frame
ser entregue ao host de destino. Esse encaminhamento interno é completamente autocontido
dentro da rede. As máquinas no lado de fora não podem participar das decisões; elas
simplesmente veem a rede como uma entidade que aceita e entrega pacotes.
Lembre-se de que o objetivo do protocolo IP é fornecer uma rede virtual, que abrange
várias redes físicas e oferece um serviço de entrega de datagrama sem conexão. Portanto,
vamos nos concentrar no endereço IP (que tradicionalmente se chamava roteamento IP). A
informação usada para tomar decisões de encaminhamento é conhecida como informação de
encaminhamento IP. Assim como o encaminhamento dentro de uma única rede física, o
encaminhamento IP escolhe um caminho pelo qual um datagrama deve ser enviado.
118
Diferente do encaminhamento dentro de uma única rede, o algoritmo de encaminhamento IP
precisa escolher como enviar um datagrama por várias redes físicas.
O encaminhamento em uma inter-rede pode ser difícil, especialmente entre
computadores que possuem várias conexões de rede física. O ideal é que o software de
encaminhamento examine a carga da rede. O tamanho do datagrama, os dados sendo
transportados ou o tipo de serviço especificado no cabeçalho do datagrama ao selecionar o
melhor caminho. A maior parte do software de encaminhamento inter-rede é muito menos
sofisticada, e seleciona as rotas com base nas suposições físicas sobre os caminhos mais
curtos.
Para entender completamente o encaminhamento IP, temos de rever a arquitetura de
uma Rede TCP/IP. Primeiro, lembre-se de que uma inter-rede é composta de várias redes
físicas interconectadas por sistemas chamados roteadores. Cada roteador possui conexões
diretas com duas ou mais redes, ao contrário de um host que normalmente se conecta
diretamente a uma rede física. Também sabemos que é possível ter um host multi-homed
conectado diretamente a diversas redes.
Tanto hosts quanto roteadores participam de encaminhamento de um datagrama IP até
o seu destino. Quando um aplicativo em um host tenta se comunicar, os protocolos TCP/IP
por fim geram um ou mais datagramas IP. O host precisa tomar uma decisão de
encaminhamento inicial quando escolhe para onde enviar os datagramas. Como mostra a
Figura 7.20, os hosts precisam tomar decisões de encaminhamento mesmo que tenham
apenas uma conexão de rede.
Figura 7.20 – Um exemplo de um host singly-homed que precisa encaminhar datagramas.
A finalidade principal dos roteadores é tomar decisões de encaminhamento IP. E que
tal os hosts multi-homed? Qualquer computador com várias conexões de rede pode atuar
como um roteador e, conforme veremos, os hosts multi-homed executando TCP/IP terão todo
o software necessário para encaminhar datagramas. De fato, os sites que não possuem
condições de ter roteadores separados às vezes utilizam computadores de uso geral como
hosts e roteadores. Porém, os padrões TCP/IP fazem uma distinção nítida entre as funções
de um host e as de um roteador, e os sites que tentam misturar funções de host e roteador em
uma única máquina às vezes descobrem que seus hosts multi-homed se engajam em
interações inesperadas. Por enquanto, distinguiremos os hosts dos roteadores, e
consideraremos que os hosts não realizam a função do roteador de transferir pacotes de uma
rede para outra.
7.15.2 Entrega Direta e Indireta
Falando de forma livre, podemos dividir o encaminhamento em duas formas: entrega
direta e entrega indireta. A entrega direta, é a transmissão de um datagrama de uma máquina
de uma única rede física diretamente para outra, é a base de toda a comunicação da inter-
119
rede. Duas máquinas só podem se engajar na entrega direta se ambas se conectarem
diretamente ao mesmo sistema de transmissão física subjacente (por exemplo, uma única
Ethernet). A entrega indireta ocorre quando o destino não está em uma rede conectada
diretamente, forçando o emissor a passar o datagrama a um roteador para entrega.
7.15.3 Entrega de Datagrama por uma Única Rede
Sabemos que uma máquina em determinada rede física pode enviar um frame físico
diretamente para outra máquina na mesma rede. Para transferir um datagrama IP, o emissor
encapsula o datagrama em um frame físico, conforme descrito anteriormente, usando o
protocolo ARP para mapear o endereço IP de destino para um endereço físico e usa o
hardware de rede para transferir o frame. Assim, examinamos todas as partes necessárias
para entender a entrega direta.
Como o emissor pode saber se o destino se encontra em uma rede conectada
diretamente? O teste é simples. Cada endereço IP é dividido em um prefixo específico da
rede e um sufixo específico do host. Para determinar se um destino se encontra em uma das
redes conectadas diretamente, o emissor extrai a parte da rede do endereço IP de destino e
compara os bits extraídos com a parte da rede do(s) seu(s) próprio(s) endereço(s) IP. Uma
correspondência significa que o datagrama pode ser enviado diretamente. Aqui, vemos uma
das vantagens do esquema de endereço IP.
De um ponto de vista da inter-rede, é mais fácil pensar na entrega direta como a última
etapa em qualquer transmissão de datagramas, mesmo que o datagrama atravesse muitas
redes e roteadores intermediários. O roteador final ao longo do caminho entre a origem do
datagrama e seu destino se conectará diretamente à mesma rede física do destino. Assim, o
roteador final entregará o datagrama usando a entrega direta. Também podemos pensar na
entrega direta entre a origem e o destino como um caso especial do encaminhamento de uso
geral. Em uma rota direta, o datagrama não passa por roteadores intermediários.
7.15.4 Entrega Indireta
A entrega indireta é mais difícil do que a entrega direta, pois o emissor precisa
identificar um roteador inicial ao qual o datagrama pode ser enviado. O roteador precisa,
então, encaminhar o datagrama para a rede de destino.
Para visualizar como funciona o encaminhamento indireto, imagine uma grande rede
virtual com muitas redes físicas interconectadas por roteadores, mas somente com dois hosts
nas extremidades. Quando um host possui um datagrama para enviar, ele encapsula o
datagrama e o envia ao roteador mais próximo. Sabemos que o host pode alcançar um
roteador porque todas as redes físicas estão interconectadas, de modo que é preciso haver um
roteador conectado a cada rede. Assim, o host de origem pode alcançar um roteador usando
uma única rede física. Quando o frame alcança o roteador, o software extrai o datagrama
encapsulado, e o IP seleciona o próximo roteador ao longo do caminho até o destino. O
datagrama novamente é colocado em um frame e enviado pela próxima rede física até um
segundo roteador, e assim por diante, até que possa ser entregue diretamente.
Como um roteador pode saber para onde enviar cada datagrama? Como um host pode
saber qual roteador usar para determinado destino? As duas perguntas estão relacionadas,
pois ambas envolvem o encaminhamento IP.
7.15.5 Encaminhamento IP controlado por Tabela
O algoritmo de encaminhamento IP emprega uma estrutura de dados em cada máquina,
que armazena informações sobre possíveis destinos e como alcançá-los. A estrutura de dados
120
é conhecida formalmente como uma tabela de roteamento IP, e informalmente como
simplesmente tabela de roteamento.
Como tanto os hosts quanto roteadores roteiam datagramas, ambos possuem tabelas
de roteamento IP. Sempre que o software de encaminhamento IP em um host ou roteador
precisa transmitir um datagrama, ele consulta a tabela de roteamento a fim de decidir para
onde enviar o datagrama.
Que informações devem ser mantidas em uma tabela de roteamento? Se a tabela de
roteamento tivesse informações sobre cada endereço de destino possível, seria impossível
manter as tabelas atualizadas. Além do mais, como o número de destinos possíveis é grande,
pequenos sistemas de uso especial não poderiam se conectar à Internet, pois não teriam
espaço suficiente para armazenar as informações.
Conceitualmente, é desejável usar o princípio de esconder informações e permitir que
as máquinas tomem decisões de encaminhamento com o mínimo de informações. Por
exemplo, gostaríamos de isolar informações sobre hosts específicos para o ambiente local em
que eles existem e organizar as máquinas que estão distantes de modo a encaminhar pacotes
para elas sem conhecer tais detalhes. Felizmente, o esquema de endereçamento IP ajuda a
conseguir esse objetivo. Lembre-se de que os endereços IP são atribuídos para fazer com
que todas as máquinas conectadas a determinada rede física compartilhem um prefixo
comum (a parte de rede do endereço). Já vimos que essa atribuição torna eficiente o teste de
entrega direta. Isso também significa que as tabelas de roteamento só precisam conter
prefixos de rede e não endereços IP completos.
7.15.6 Encaminhamento do Próximo Salto
O uso da parte de rede de um endereço IP no lugar do endereço de host completo torna
o encaminhamento eficiente e mantém as tabelas de roteamento pequenas. Mais importante,
isso ajuda a ocultar informações, mantendo os detalhes dos hosts específicos confinados ao
ambiente local em que os hosts operam. Normalmente, uma tabela de roteamento contém
pares (N, R), onde N é o endereço IP de uma rede de destino, e R é o endereço IP do
“próximo” roteador ao longo do caminho até a rede N. O roteador R é chamado de próximo
salto (next hop), e a ideia de usar uma tabela de roteamento para armazenar o próximo salto
para cada destino é chamado de encaminhamento no próximo salto ou roteamento no
próximo salto. Assim, a tabela de roteamento em um roteador R só especifica uma etapa ao
longo do caminho de R até uma rede de destino. O roteador não conhece o caminho completo
até um destino.
É importante entender que cada entrada em uma tabela de roteamento aponta para um
roteador que pode ser alcançado por uma única rede. Ou seja, todos os roteadores listados
na tabela de roteamento da máquina M precisam estar em redes às quais M se conecta
diretamente. Quando um datagrama estiver pronto para sair de M, o Protocolo de Internet
localiza o endereço IP de destino e extrai a parte da rede. Depois, M usa a parte da rede para
tomar uma decisão de encaminhamento, selecionando um roteador que pode ser alcançado
diretamente.
Na prática, aplicamos o princípio de esconder informações também para hosts.
Insistimos que, embora os hosts tenham tabelas de roteamento IP, eles precisam manter
informações mínimas em suas tabelas. A ideia é forçar os hosts a contarem com roteadores
para a maior parte do encaminhamento.
A Figura 7.21 mostra um exemplo concreto que ajuda a explicar as tabelas de
roteamento. A rede virtual de exemplo consiste em quatro redes físicas conectadas por três
roteadores. A tabela na figura corresponde à tabela de roteamento para o roteador R. Como
121
R se conecta diretamente às redes 20.0.0.0 e 30.0.0.0, ele pode usar a entrega direta para
enviar a um host em qualquer uma dessas redes (possivelmente usando o ARP para encontrar
endereços físicos). Dado um datagrama destinado a um host na rede 40.0.0.0, R o roteia
para o endereço do roteador S, 30.0.0.7. Depois, S entregará o datagrama diretamente. R
pode alcançar o endereço 30.0.0.7 porque tanto R quanto S se conectam diretamente à rede
30.0.0.0.
Como demonstra a Figura 7.21, o tamanho da tabela de roteamento depende do número
de redes na rede virtual. A tabela só cresce quando novas redes são acrescentadas. Ou seja,
o tamanho e o conteúdo da tabela dependem do número de hosts individuais conectados às
redes.
Figura 7.21 – Uma internet de exemplo com 4 redes e 3 roteadores.
A escolha de rotas com base apenas no ID da rede de destino apresenta diversas
conseqüências. Primeiro, na maior parte das implementações, isso significa que todo o
tráfego destinado a determinada rede segue o mesmo caminho. Como resultado, mesmo
quando existem vários caminhos, eles podem não ser usados simultaneamente. Além disso,
no caso mais simples, todo o tráfego segue o mesmo caminho, sem considerar o atraso ou a
vazão das redes físicas. Segundo, como apenas o roteador final do caminho tenta se
comunicar com o host de destino, somente ele pode determinar se o host existe ou está
operacional. Assim, precisamos arrumar um meio para que o roteador final envie relatórios
de problemas de entrega de volta à origem. Terceiro, como cada roteador encaminha o
tráfego independentemente, os datagramas trafegando do host A para o host B podem seguir
um caminho inteiramente diferente dos datagramas trafegando do host B para o host A.
Precisamos nos assegurar que os roteadores cooperem para garantir que a comunicação
bidirecional sempre seja possível.
7.15.7 Rotas Default
Outra técnica utilizada para esconder informações e manter tamanhos pequenos de
tabela de roteamento e consolidar várias entradas em um caso default. A idéia é fazer com
que o software de encaminhamento IP primeiro examine a tabela de encaminhamento para a
rede de destino. Se nenhuma rota aparecer na tabela, o software de encaminhamento envia
o datagrama para um roteador default.
122
O encaminhamento default é útil especialmente quando um site possui um pequeno
conjunto de endereços locais e somente uma conexão com o restante da rede virtual. Por
exemplo, as rotas default funcionam bem nos computadores host que se conectam a uma
única rede física e só alcançarão um roteador levando ao restante da rede virtual. A decisão
de endereço consiste em dois testes: um para a rede local e um default que aponta para o
único roteador. Mesmo que o site contenha algumas redes locais, o encaminhamento é
simples porque consiste em testes para as redes locais mais um default para todos os outros
destinos.
7.15.8 Rotas Específicas do Host
Embora tenhamos dito que todo o encaminhamento é baseado em redes e não em hosts
individuais, a maioria dos softwares de encaminhamento IP permite que as rotas por host
sejam especificadas como um caso especial. Ter rotas por host dá ao administrador da rede
local mais controle sobre o uso da rede, permite o teste e também pode ser usado para
controlar o acesso para fins de segurança. Ao depurar conexões de rede ou tabelas de
roteamento, a capacidade de especificar uma rota especial a uma máquina individual prova
ser especialmente útil.
7.15.9 O Algoritmo de Encaminhamento IP
Levando em consideração tudo o que dissemos, o algoritmo original usado para
encaminhar datagramas IP com endereçamento com classe foi:
Algoritmo:
ForwardDatagram (Datagram, RoutingTable)







Extrair o endereço IP de destino, D, do datagrama;
Se a tabela contiver uma rota específica do host para D, enviar o datagrama ao
próximo salto especificado na tabela e sair;
Calcular N, o prefixo de rede do endereço D;
Se N combinar com qualquer endereço de rede conectado diretamente, entregar o
datagrama ao destino D por essa rede. (Isso envolve traduzir D para endereço físico,
encapsular o datagrama e enviar o frame).
Senão, se a tabela contiver uma rota para o prefixo de rede N, enviar o datagrama
ao próximo salto especificado na tabela;
Senão, se a tabela contiver uma rota default, enviar o datagrama ao roteador default
especificado na tabela;
Senão, declarar um erro de encaminhamento.
7.15.10 Encaminhamento com Endereços IP
É importante entender que, exceto por decrementar o tempo de vida e recalcular o
checksum, o encaminhamento IP não altera o datagrama original. Em particular, os
endereços de origem e destino do datagrama permanecem inalterados. Eles especificam o
endereço IP da origem e o endereço IP do destino final1. Quando o IP executa o algoritmo
de encaminhamento, ele seleciona um novo endereço IP, o endereço IP da máquina à qual o
datagrama deve ser enviado em seguida. O novo endereço provavelmente é o endereço de
um roteador. Porém, se o datagrama puder ser entregue diretamente, o novo endereço é o
mesmo que o do destino final.
1
A única exceção ocorre quando o datagrama contém a opção de rota de origem.
123
Dissemos que o endereço IP selecionado pelo algoritmo de endereço IP é conhecido
como endereço do próximo salto, pois diz aonde o datagrama precisa ser enviado em seguida.
Onde o protocolo IP armazena o endereço do próximo salto? Não no datagrama. Não há
lugar reservado para ele. Na verdade, o protocolo IP não armazena qualquer endereço do
próximo salto. Depois de executar o algoritmo de encaminhamento, o protocolo IP passa o
datagrama e o endereço do próximo salto ao software de interface de rede responsável pela
rede física sobre a qual o datagrama precisa ser enviado. O software de interface de rede
vincula o endereço do próximo salto a um endereço físico, forma um frame usando esse
endereço físico, coloca o datagrama na parte de dados do frame e envia o resultado. Depois
de usar o endereço do próximo salto para encontrar um endereço físico, o software de
interface de rede descarta o endereço do próximo salto.
Pode parecer estranho que as tabelas de roteamento armazenem o endereço IP de um
próximo salto para cada rede de destino quando esses endereços precisam ser traduzidos para
os endereços físicos correspondentes antes que o datagrama possa ser enviado. Se
imaginarmos um host enviando uma seqüência de datagramas ao mesmo endereço de
destino, o uso de endereços IP parecerá incrivelmente ineficaz. O protocolo IP fielmente
extrai o endereço de destino em cada datagrama e usa a tabela de roteamento para produzir
um endereço de próximo salto. Depois, ele passa o datagrama e o endereço do próximo salto
para a interface de rede, que recalcula o vínculo para um endereço físico. Se a tabela de
roteamento usasse endereços físicos, o vínculo entre o endereço IP do próximo salto e o
endereço físico poderia ser realizado uma vez, economizando computação desnecessária.
Porque o IP evita o uso de endereços físicos ao armazenar e calcular rotas? Conforme
ilustra a Figura 7.22, existem dois motivos importantes.
Figura 7.22 – O IP e a tabela de roteamento residem acima do limite de endereço.
Primeiro, a tabela de roteamento provê uma interface clara entre o protocolo IP que
encaminha datagramas e o software de alto nível que trata as rotas. Para depurar problemas
de encaminhamento, os gerentes de rede normalmente precisam examinar as tabelas de
roteamento. Usar apenas endereços IP na tabela de roteamento faz com que os
administradores entendam e determinem melhor se o software atualizou as rotas
corretamente. Segundo, o objetivo do protocolo IP é montar uma abstração que esconde os
detalhes das redes básicas.
A Figura 7.22 mostra o limite de endereço, a divisão conceitual entre o software de
baixo nível que entende os endereços físicos e o software de rede virtual, que só usa
124
endereços de alto nível. Acima desse limite, todo software pode ser escrito para se comunicar
usando endereços de rede virtual. O conhecimento dos endereços físicos é relegado a
algumas rotinas pequenas, de baixo nível. Veremos que observar o limite também facilita a
compreensão, o teste e a modificação da implementação dos protocolos TCP/IP restantes.
7.15.11 Tratando de Datagramas que Chegam
Até aqui, discutimos o encaminhamento IP descrevendo como as decisões de
encaminhamento são tomadas a respeito dos datagramas que saem. Porém, deve ficar claro
que o protocolo IP precisa processar também os datagramas que chegam.
Quando um datagrama IP chega em um host, o software de interface de rede entrega o
datagrama ao módulo IP para processamento. Se o endereço de destino do datagrama
combinar com o endereço IP do host, o protocolo IP no host aceita o datagrama e o passa
para o software de protocolo de nível superior apropriado, para mais processamento. Se o
endereço IP de destino não combinar, um host precisa descartar o datagrama (ou seja, os
hosts são proibidos de tentar encaminhar datagramas enviados acidentalmente à máquina
errada).
Ao contrário dos hosts, os roteadores realizam o encaminhamento. Quando um
datagrama IP chega em um roteador, ele é entregue ao protocolo IP. Novamente, surgem
dois casos: o datagrama atingiu seu destino final, ou ele pode ter de viajar ainda mais. Assim
como nos hosts, se o endereço IP de destino do datagrama combinar com o próprio endereço
IP do roteador, o protocolo IP passa o datagrama para o protocolo de nível superior para
processamento1. Se o datagrama não tiver atingido seu destino final, o protocolo IP
encaminha o datagrama usando o algoritmo padrão e a informação na tabela de roteamento
local.
Determinar se um datagrama IP alcançou seu destino final não é tão trivial quanto
parece. Lembre-se de que um roteador possui várias conexões físicas, cada uma com seu
próprio endereço IP. Quando um datagrama IP chega, a máquina receptora precisa comparar
o endereço IP de destino com o endereço IP de cada uma de suas conexões de rede. Se houver
qualquer combinação, ela mantém o datagrama e o processa. Uma máquina também precisa
aceitar os datagramas que foram enviados por broadcast IP direcionado para essa rede. Os
endereços sem classe, de sub-rede e de multicast tornam o reconhecimento do endereço ainda
mais complexo. De qualquer forma, se o endereço não combinar com qualquer um dos
endereços da máquina local, o IP decrementa o campo TTL no cabeçalho do datagrama,
descartando o datagrama se a contagem atingir zero, ou recalculando um novo checksum e
encaminhando o datagrama se a contagem permanecer positiva.
Cada máquina deve encaminhar os datagramas IP que ela recebe? Obviamente, um
roteador precisa encaminhar os datagramas que chegam, pois essa é sua função principal.
Dissemos que alguns sites também configuram computadores de uso geral para operar como
roteadores, e esses computadores precisam ser configurados para encaminhar datagramas.
Porém, os hosts não projetados para ser roteadores não podem encaminhar datagramas. Se
tal host receber um datagrama que não corresponde a qualquer um dos endereços do host, o
host precisa descartar o datagrama.
Existem quatro motivos para um host não projetado a servir como roteador evitar a
realização de quaisquer outras funções. Primeiro, quando esse tipo de host recebe um
1
Normalmente, os únicos datagramas destinados a um roteador são aqueles usados para testar a conectividade ou aqueles
que transportam comandos de gerenciamento do roteador, mas um roteador também recebe uma cópia de qualquer
datagrama que é enviado por broadcast na rede.
125
datagrama direcionado para alguma outra máquina, algo saiu errado com o endereçamento,
encaminhamento ou entrega da rede virtual. O problema pode não ser revelado se o host
tomar uma ação corretiva encaminhando o datagrama. Segundo, o encaminhamento causará
tráfego desnecessário na rede (e pode roubar tempo de CPU para usos legítimos do host).
Terceiro, erros simples podem causar caos. Suponha que cada host encaminhe tráfego, e
imagine o que acontece se uma máquina acidentalmente transmitir por broadcast um
datagrama destinado a um host, H. Por ter sido enviado por broadcast, cada host na rede
recebe uma cópia do datagrama. Cada host encaminha sua cópia para H, que será
bombardeado com muitas cópias. Quarto, os roteadores realizam mais do que simplesmente
encaminhar tráfego. Os roteadores usam um protocolo especial para relatar erros, enquanto
os hosts não fazem isso (novamente, para evitar que vários relatórios de erro bombardeiem
uma origem). Os roteadores também propagam informações para garantir que suas tabelas
de roteamento sejam consistentes e corretas. Se os hosts encaminharem datagramas sem
participar totalmente de todas as funções do roteador, podem surgir anomalias inesperadas.
7.16 IPv6
A evolução da tecnologia TCP/IP sempre esteve interligada a evolução da Internet global.
Com centenas de milhões de usuários em sites no mundo inteiro dependendo da internet global
como parte do seu ambiente de trabalho diário, pode parecer que passamos dos primeiros estágios
de desenvolvimento e agora temos uma facilidade de produção completamente estável. Apesar
das aparências, porém, nem a internet nem o conjunto de protocolos TCP/IP são estáticos. Os
pesquisadores e engenheiros descobrem novas maneiras de usar a tecnologia e melhorar os
mecanismos básicos.
A finalidade desta seção é considerar o processo evolucionário contínuo e examina um dos
esforços de engenharia mais significativos: uma revisão proposta do IP. Se a proposta for adotada
por fornecedores, ela terá um forte impacto sobre os protocolos e a internet global.
7.16.1 Por que Mudar?
No início da década de 1990, os pesquisadores argumentaram que a internet era
insuficiente para novas aplicações, como voz e vídeo. Eles argumentaram ainda que o
crescimento da internet, que estava dobrando em tamanho a cada nove meses, ou mais rápido
ainda, logo esgotaria o conjunto de endereços disponíveis. Desde então, duas coisas ficaram
claramente visíveis. Primeiras aplicações como telefonias funcionam bem pela internet
existente. Em segundo lugar, os endereçamentos CIDR e NAT forneceram as extensões de
endereço necessárias, as projeções atuais sugerem que teremos endereços suficientes até
2022 (2028, se os endereços não usados forem reaproveitados).
7.16.2 Além do IPv4
A versão 4 do Internet Protocol (IPv4) foi a primeira versão de trabalho; ela
permaneceu quase inalterada desde o seu surgimento no final da década de 1970. A
longevidade da versão 4 mostra que o projeto é flexível e poderoso. Desde o momento em
que o IPv4 foi projetado, o desempenho do processador aumentou por três ordens de
grandeza, os tamanhos típicos da memória aumentaram por um fator maior que 400, as
larguras de banda dos enlaces de maior velocidade na internet aumentaram por um fator de
150.000. As tecnologias de LAN emergiam e o número de hosts na internet aumentou de
alguns para centenas de milhões.
A principal motivação para atualizar o IP é a eventual limitação no espaço de
endereços. Quando o IP foi projetado, um espaço de endereços de 32 bits foi mais do que
suficiente. Somente algumas das organizações usavam uma LAN, e nenhum tinha um PC.
126
Agora, porém, até mesmo corporações pequenas possuem LANs e vários computadores. Se
cada telefone celular receber um endereço IP, os endereços serão esgotados rapidamente.
7.16.3 A Estrada para uma Nova Versão do IP
Foram necessários vários anos para que o IETF formulasse uma nova versão do IP.
Como o IETF produz padrões abertos, ele convidou representantes de muitas comunidades
para participarem do processo. Os fabricantes de computadores, fornecedores de hardware
e softwares, usuários, gerentes, programadores, companhias de telefones e o setor inteiro de
televisão a cabo especificaram seus requisitos para a próxima versão do IP, e todos
comentaram sobre propostas específicas.
Muitos projetos foram propostos para servir a uma finalidade em particular ou a uma
comunidade em particular. No fim, um projeto conhecido como SIP 1 (Simple IP) tornou-se
a base para uma proposta estendida, que incluía idéias de outras propostas. A versão
estendida foi chamada de SIPP (Simple IP Plus) e tornou-se o projeto escolhido como base
para o próximo IP.
7.16.4 O Nome do Próximo IP
O IETF decidiu atribuir à revisão do IP o número de versão 6 e chamou-o de IPv6 (ele
era conhecido originalmente como “IP – The Next Generation” (IPng). O número de versão
5 foi pulado depois de uma serie de erros e mal entendidos. A escolha de numerar a nova
versão com 6 eliminou a confusão e a ambiguidade.
7.16.5 Características do IPv6
O protocolo IPv6 proposto retém muitas das características que contribuíram para o
sucesso do IPv4. Na verdade, os projetistas caracterizaram o IPv6 como sendo basicamente
o mesmo que o IPv4, com algumas pequenas modificações. Por exemplo, o IPv6 ainda
admite entrega sem conexão (ou seja, cada datagrama é roteado independentemente),
permite que o emissor escolha o tamanho de um datagrama e exige que o emissor especifique
o número máximo de saltos que um datagrama pode fazer antes de ser terminado. Como
veremos, o IPv6 também retém a maior parte dos conceitos fornecidos pelas opções do IPv4,
incluindo facilidades para fragmentação e roteamento de origem.
Apesar de muitas semelhanças conceituais, o IPv6 muda a maior parte dos detalhes do
protocolo. Por exemplo, o IPv6 usa endereços maiores e acrescenta alguns novos recursos.
Mais importante, o IPv6 revisa completamente o formato de datagrama, substituindo o
campo de opções de tamanho variável do IPv4 por uma série de cabeçalhos de formato fixo.
Examinaremos os detalhes depois de considerar as principais mudanças e a motivação
básica para cada um.
As mudanças introduzidas pelo IPv6 podem ser agrupadas em sete categorias:
1

Endereços maiores: o novo tamanho do endereço é a mudança mais observável.
O IPv6 quadruplica o tamanho de um endereço IPv4 de 32 bits para 128 bits.

Hierarquia de endereço estendida: o IPv6 usa o espaço de endereço maior para
criar níveis adicionais de hierarquia de endereçamento (por exemplo, para
permitir que um ISP aloque blocos de endereços a cada cliente).
O acrônimo SIP agora se refere a Session Initiation Protocol.
127

Formato de cabeçalho flexível: o IPv6 usa um formato de datagrama
completamente novo e incompatível, que inclui um conjunto de cabeçalhos
opcionais.

Opções avançadas: o IPv6 permite que um datagrama inclua informações de
controle opcionais; as opções do IPv6 fornecem facilidades adicionais não
disponíveis no IPv4.

Provisão para extensão de protocolo: em vez de especificar todos os detalhes, a
capacidade de extensão do IPv6 permite que o IETF adapte o protocolo ao novo
hardware de rede e novas aplicações.

Suporte para autoconfiguração e renumeração: o IPv6 permite que os
computadores em uma rede isolada atribuam endereços locais
automaticamente; o projeto também permite que um gerente renumere redes em
um site dinamicamente.

Suporte para alocação de recurso: o IPv6 inclui uma abstração de fluxo e bits
para a especificação de serviço diferenciado (DiffServ).
7.16.6 Forma Geral de um Datagrama IPv6
O IPv6 muda completamente o formato do datagrama. Como mostra a Figura 7.23,
um datagrama IPv6 possui um cabeçalho básico de tamanho fixo seguido por zero ou mais
cabeçalhos de extensão, seguidos pelos dados.
opcional
Cabeçalho
Básico
Cabeçalho de
Extensão 1
...
Cabeçalho de
Extensão N
Dados...
Figura 7.23 – Formato Geral de um Datagrama IPv6.
7.16.6.1 Formato de Cabeçalho Básico do IPv6
Embora deva acomodar endereços maiores, um cabeçalho básico IPv6 contem
menos informações do que um cabeçalho de datagrama IPv4. As opções e alguns dos
campos fixos que aparecem em um cabeçalho de datagrama IPv4 foram movidos para
cabeçalhos de extensão no IPv6. Em geral, as mudanças no cabeçalho do datagrama
refletem as mudanças no protocolo:

O alinhamento foi alterado de múltiplos de 32 bits para 64 bits.

Um campo de tamanho de cabeçalho foi eliminado, e o campo de tamanho
do datagrama foi substituído por um campo de TAMANHO DO PAYLOAD
(PAYLOAD LENGTH).

O tamanho dos campos de endereços de origem e destino foi aumentado
para 16 octetos cada um.

A informação de fragmentação foi movida para fora dos campos fixos no
cabeçalho básico para um cabeçalho de extensão.

O campo TEMPO DE VIDA (TIME TO LIVE) foi substituído por um
campo LIMITE DE SALTOS (HOP LIMIT).

O TIPO DE SERVIÇO (SERVICE TYPE) teve o nome alterado para
CLASSE DE TRÁFEGO (TRAFFIC CLASS) e estendido com um campo
RÓTULO DE FLUXO (FLOW LABEL).
128

O campo PROTOCOLO (PROTOCOL) foi substituído por um campo que
especifica o tipo do próximo cabeçalho.
A Figura 7.24 mostra o conteúdo e o formato de um cabeçalho IPv6 básico. Vários
campos em um cabeçalho básico de IPv6 correspondem diretamente aos campos em um
cabeçalho IPv4. Assim como no IPv4, o campo VERS de 4 bits inicial especifica a
versão do protocolo; VERS sempre contem 6 em um datagrama IPv6. Assim como no
IPv4, os campos ENDEREÇO DE ORIGEM (SOURCE ADDRESS) e ENDEREÇO DE
DESTINO (DESTINATION ADDRESS) especificam os endereços do emissor e
destinatários desejados. Porém, no IPv6, cada endereço requer 16 octetos. O campo
LIMITE DE SALTO corresponde ao campo TEMPO DE VIDA do IPv4. Diferente do
IPv4, que interpreta um tempo de vida como uma combinação de contagem de saltos e
tempo máximo, o IPv6 interpreta o valor como dado um limite estrito sobre o numero
máximo de saltos que um datagrama pode fazer antes de ser descartado.
0
4
VERS
12
Classe de Tráfego
Tamanho do Payload
16
24
31
Rótulo de Fluxo
Próximo Cabeçalho
Limite de Saltos
Endereço de Origem
Endereço de Destino
Figura 7.24 – O Formato do Cabeçalho Básico do IPv6 de 40 octetos.
O IPv6 trata de especificações de tamanho de datagrama de uma nova maneira.
Primeiro, como o tamanho do cabeçalho básico é fixado em 40 octetos, o cabeçalho
básico não inclui um campo para o tamanho do cabeçalho. Em segundo lugar, o IPv6
substitui o campo de tamanho do datagrama do IPv4 por um campo de TAMANHO DO
PAYLOAD que especifica o número de octetos transportados no datagrama, excluindo
o próprio cabeçalho. Assim, um datagrama IPv6 pode conter 64K octetos de dados.
Dois campos no cabeçalho básico são usados na tomada de decisões de
encaminhamento. O campo TIPO DE SERVIÇO do IPv4 foi renomeada como CLASSE
DE TRÁFEGO. Além disso, um novo mecanismo no IPv6 admite reserva de recurso e
permite que um roteador associe a cada datagrama uma determinada alocação de
recurso. A abstração básica, um fluxo, consiste em um caminho por uma internet junto
à quais roteadores intermediárias garantem uma qualidade de serviço especifico. O
campo RÓTULO DE FLUXO no cabeçalho básico contém informações que os
roteadores utilizam para associar um datagrama a um fluxo e prioridade especificos.
Por exemplo, duas aplicações que precisam enviar vídeo podem estabelecer um fluxo
em que o atraso e a largura da banda sejam garantidos. Como alternativa, um provedor
de rede pode exigir que um assinante especifique a qualidade de serviço desejada e
depois use um fluxo para limitar o tráfego que um computador específico ou aplicação
específica envia. Observe que os fluxos também podem ser usados dentro de
determinada organização para gerenciar recursos de rede e garantir que todas as
aplicações recebam uma fatia justa. Um roteador usa a combinação de endereço de
origem do datagrama e identificador de fluxo ao associar um datagrama a um fluxo
específico.
129
7.16.6.2 Cabeçalhos de Extensão do IPv6
O paradigma de um cabeçalho de base fixa seguida por um conjunto de cabeçalhos
de extensão foi escolhido como um compromisso entre generalidade e eficiência. Para
ser totalmente geral, o IPv6 precisa incluir mecanismo de modo a dar suporte a funções
como fragmentação, roteamento de origem e autenticação. Porém, a escolha de alocar
campos fixos no cabeçalho do datagrama para todos os mecanismos é ineficaz, pois a
maioria dos datagramas não usa todos os mecanismos; o grande tamanho de endereços
do IPv6 aumenta a ineficiência. Por exemplo, ao enviar um datagrama por uma única
rede local, um cabeçalho que contem campos de endereço vazios pode ocupar uma
fração substancial de cada frame.
Mais importante, os projetistas observam que ninguém pode prever quais
facilidades serão necessárias.
O paradigma do cabeçalho de extensão do IPv6 funciona de modo semelhante às
funções do IPv4. Um emissor pode escolher quais cabeçalhos de extensão incluir em
determinado datagrama e quais omitir. Assim, os cabeçalhos de extensão oferecem o
máximo de flexibilidade.
7.16.7 Analisando um Datagrama IPv6
Cada um dos cabeçalhos básico e de extensão contém um campo PRÓXIMO
CABECALHO (NEXT HEADER) que os roteadores intermediários e o destino final utilizam
para desmembrar o datagrama. O processamento é sequencial. O campo PRÓXIMO
CABEÇALHO em cada cabeçalho diz o que aparece em seguida. Por exemplo, a Figura 7.25
mostra os campos PROXIMO CABEÇALHO de três datagramas que contêm zero, um e dois
cabeçalhos de extensão.
Cabeçalho BÁSICO
Próximo = TCP
Segmento TCP
(a)
Cabeçalho BÁSICO
Próximo = ROUTE
Cabeçalho BÁSICO
Próximo = ROUTE
Cabeçalho ROUTE
Próximo = TCP
(b)
Cabeçalho ROUTE
Próximo = AUTH
Segmento TCP
Cabeçalho AUTH
Próximo = TCP
Segmento TCP
(c)
Figura 7.25 – Três Datagramas IPv6.
Para agilizar o processamento, o IPv6 exige que os cabeçalhos de extensão utilizados
por roteadores intermediários sejam colocados antes dos cabeçalhos de extensão usados pelo
destino final. O IPv6 usa o termo cabeçalho salto-a-salto (hop-by-hop header) para se referir
a um cabeçalho de extensão que um roteador intermediário precisa processar. Assim os
cabeçalhos salto-a-salto precedem os cabeçalhos de fim-a-fim.
7.16.8 Fragmentação e Remontagem do IPv6
A fragmentação de datagramas IPv6 é permitida; um cabeçalho de extensão é usado
para especificar que um datagrama é um fragmento. Assim como no IPv4, o IPv6
providencia para que o destino final realize a remontagem do datagrama. Porém, os
projetistas escolheram fazer mudanças que evitam a fragmentação por roteadores. Lembrese de que o IPv4 requer que um roteador intermediário fragmente qualquer datagrama que
130
seja muito grande para a MTU da rede que ele precisa atravessar. No IPv6, a fragmentação
é de fim-a-fim; nenhuma fragmentação ocorre nos roteadores intermediários. A origem, que
é responsável pela fragmentação, tem duas escolhas: ela pode usar a MTU mínima garantida
de 1.280 octetos ou realiza a descoberta de MTU do caminho (Path MTU Discovery) para
identificar a MTU mínima ao longo do caminho até o destino. De qualquer forma, a origem
fragmenta de modo que cada fragmento seja menor que a MTU esperada do caminho. A
Figura 7.26 mostra o conteúdo de um cabeçalho de extensão de fragmento (Fragmentation
Extension Header).
0
8
Próximo Cabeçalho
16
RESERVADO
Offset de Fragmento
IDENTIFICAÇÃO DO DATAGRAMA
29
RS
31
M
Figura 7.26 – O Formato de um Cabeçalho de Extensão de Fragmento.
O IPv6 retém a funcionalidade de fragmentação básica. Cada fragmento precisa ser
um múltiplo de 8 octetos, o único bit do campo M marca o último fragmento, como o bit
MORE FRAGMENTS do IPv4, e o campo IDENTIFICAÇÃO DO DATAGRAMA transporta
uma ID exclusiva que o receptor usa para agrupar fragmentos1. Finalmente, o campo RS é
atualmente reservado. Os dois bits são definidos como zero na transmissão e ignorados pelo
receptor.
7.16.9 A Conseqüência da Fragmentação de fim-a-fim
A motivação para usar a fragmentação de fim-a-fim está em sua capacidade de reduzir
o overhead em roteadores e permitir que cada roteador trate de mais datagramas por tempo
unitário. Na realidade, a sobrecarga de CPU exigida para a fragmentação IPv4 pode ser
significativa. Em um roteador convencional, a CPU pode atingir 100% de utilização se o
roteador fragmentar todos os datagramas que ele recebe. Porém, a fragmentação de fim-afim tem uma consequência importante: ela altera a suposição fundamental do IPv4 de que as
rotas mudam dinamicamente.
Para entender a consequência da fragmentação de fim-a-fim, lembre-se de que o IPv4
foi projetado para permitir que as rotas mudem a qualquer hora. Por exemplo, se uma rede
ou roteador falhar, o tráfego pode ser roteado por um caminho diferente. A principal
vantagem desse sistema é a flexibilidade. O tráfego pode ser roteado ao longo de um caminho
alternativo sem atrapalhar o serviço e sem informar a origem ou o destino. Porém, no IPv6,
as rotas não podem ser alteradas tão facilmente, pois uma mudança em uma rota também
pode alterar a MTU do caminho, então um roteador intermediário precisa fragmentar o
datagrama ou a origem precisa ser informada.
Para resolver o problema de mudanças de rota que afetam a MTU do caminho, o IPv6
inclui uma nova mensagem de erro ICMP. Quando um roteador descobrir que a
fragmentação é necessária, ele enviará a mensagem de volta à origem. Ao receber tal
mensagem, a origem realizará outra descoberta de MTU do caminho para determinar uma
nova MTU mínima e depois fragmentará os datagramas de acordo com o novo valor.
7.16.10 Roteamento de Origem IPv6
O IPv6 retém a capacidade para um emissor especificar uma rota de origem solta.
Diferente do IPv4, em que o roteamento de origem é fornecido por opções, o IPv6 usa um
cabeçalho de extensão separado. Como mostra a Figura 7.27, os quatro primeiros campos
do Cabeçalho de Roteamento são fixos. O TIPO DE ROTEAMENTO (ROUTING TYPE)
1
O IPv6 expande o campo de IDENTIFICAÇÃO do IPv4 para 32 bits, a fim de acomodar redes de maior velocidade.
131
especifica o tipo de informação de roteamento. O único tipo que foi definido, tipo 0,
corresponde ao roteamento de origem solto. O campo DADOS ESPECÍFICOS DO TIPO
(TYPE-SPECIFIC DATA) contém uma lista de endereços de roteadores através dos quais o
datagrama precisa passar. O campo SEGMENTOS RESTANTES (SEG LEFT) especifica o
número total de endereços na lista. Finalmente, o campo TAMANHO DO CABEÇALHO DE
EXTENSÃO (HDR EXT LEN) especifica o tamanho do cabeçalho de roteamento.
0
8
Tamanho do Cabeçalho
de Extensão
Próximo Cabeçalho
16
24
Tipo de Roteamento
31
Segmentos Restantes
DADOS ESPECÍFICOS DO TIPO
.
.
.
Figura 7.27 – O Formato de um Cabeçalho de Roteamento IPv6.
7.16.11 Opções do IPv6
Pode parecer que os cabeçalhos de extensão do Ipv6 substituem completamente as
opções Ipv4. Porém, os projetistas propõem dois cabeçalhos de extensão adicionais do Ipv6
para acomodar informações diversificadas não incluídas nos outros cabeçalhos de extensão.
Os cabeçalhos adicionais são um cabeçalho de estensão salto-a-salto e um cabeçalho de
extensão de fim-a-fim.
Embora cada um dos dois cabeçalhos de opção tenha um código de tipo exclusivo, os
dois cabeçalhos utilizam o formato ilustrado na Figura 7.28.
0
8
Próximo Cabeçalho
Tamanho Cabeçalho
16
24
31
UMA OU MAIS OPÇÕES
Figura 7.28 – O Formato de um Cabeçalho de Extensão de Opção IPv6.
Como sempre, o campo PRÓXIMO CABEÇALHO indica o tipo do cabeçalho que vem
em seguida. Como um cabeçalho de opção não tem tamanho fixo, o campo rotulado com
TAMANHO CABEÇALHO especifica o tamanho total do cabeçalho. A área rotulada com
UMA OU MAIS OPÇÕES representa uma seqüência de opções individuais. A Figura 7.29
ilustra que cada opção individual é codificada com um tipo, tamanho e valor 1. As opções
não estão alinhadas ou preenchidas.
0
8
TIPO
16
TAMANHO
VALOR
Figura 7.29 – A Codificação de uma Opção Individual em um Cabeçalho de Extensão IPv6.
Como mostra a figura, as opções do Ipv6 seguem o mesmo formato das opções do IPv4.
Cada opção começa com um campo TIPO de um octeto, seguido por um campo de
1
Na literatura, uma codificação de tipo, tamanho e valor às vezes é chamada de codificação TLV (Type, Length, Value).
132
TAMANHO de um octeto. Se a opção exigir dados adicionais, os octetos que constituem o
VALOR vêm após o TAMANHO.
Os bits de alta ordem de cada campo TIPO da opção especificam como um host ou
roteador deve descartar um datagrama se não entender a opção. A Tabela 7.6 Mostra os bits
de tipo e o seu significado.
Bits no Tipo
00
01
10
11
Significado
Pular esta Opção.
Descartar datagrama; não enviar mensagem ICMP.
Descartar datagrama; enviar mensagem ICMP à origem.
Descartar datagrama; enviar ICMP se não multicast.
Tabela 7.6 – Significado do Campo TIPO.
Além disso, o terceiro bit no campo TIPO especifica se a opção pode mudar em trânsito.
É importante ter essa informação para autenticação. O conteúdo de uma opção que pode
mudar em trânsito e tratado como zeros, para fins de autenticação.
7.16.12 Tamanho do Espaço de Endereços do IPv6
No IPv6, cada endereço ocupa 16 octetos, quatro vezes o tamanho de um endereço
IPv4. O espaço de endereços grande garante que o IPv6 pode tolerar qualquer esquema de
atribuição de endereço razoável. Na verdade, se os projetistas decidirem mudar o esquema
de endereçamento mais tarde, o espaço de endereços é suficientemente grande para acomodar
uma reatribuição.
É difícil compreender o tamanho do espaço de endereços do IPv6. Um modo de
examinar isso é relacionar a magnitude ao tamanho da população: o espaço de endereços é
tão grande que cada pessoa no planeta pode ter endereços suficientes para ter sua própria
Internet Global, tão grande quanto a Internet atual. Uma segunda forma de pensar no
endereçamento IPv6 é relacioná-lo ao espaço físico disponível: a superfície da terra tem
aproximadamente 5,1x108 quilômetros quadrados, significando que existem mais de 10 24
endereços por metro quadrado da superfície da terra. Outra forma de entender o tamanho é
relacioná-lo ao esgotamento de endereços. Por exemplo, considere quanto tempo levaria para
atribuir todos os endereços possíveis. Um inteiro de 16 octetos pode manter 2 128 valores.
Assim, o espaço de endereços é maior do que 3,4x1038. Se os endereços forem atribuídos na
velocidade de um milhão de endereços a cada microssegundo, seriam necessários mais de
1020 anos para atribuir todos os endereços possíveis.
7.16.13 Notação Hexadecimal de dois pontos do IPv6
Embora solucione o problema de ter capacidade insuficiente, o tamanho grande de
endereço impõe um novo problema interessante: os seres humanos que mantêm inter-redes
precisam ler, digitar e manipular esses endereços. Obviamente, a notação binária é
impraticável. Porém, a notação decimal pontilhada usada para o IPv4 também não torna
esses endereços suficientemente compactos. Para entender por que, considere um número de
128 bits de exemplo, expresso na notação decimal pontilhada.
104.230.140.100.255.255.255.255.0.0.17.128.150.10.255.255
Para ajudar a tornar os endereços ligeiramente mais compactos e mais fáceis de entrar,
os projetistas do IPv6 propõem o uso da notação hexadecimal com dois pontos, em que o
valor de cada quantidade de 16 bits é representado em hexadecimal separado por sinais de
dois pontos. Por exemplo, quando o valor mostrado antes em notação decimal pontilhada é
traduzido para a notação hexadecimal com dois pontos, ele fica da forma abaixo:
133
68E6:8C64:FFFF:FFFF:0:1180:96A:FFFF
A notação hexadecimal com dois pontos tem a vantagem óbvia de exigir menos dígitos
e menos caracteres separados que o decimal pontilhado. Além disso, a notação hexadecimal
com dois pontos inclui duas técnicas que a tornam extremamente útil. Primeiro, permite a
compactação de zeros, em que uma sequência de zeros repetidos é substituída por um par de
sinais de dois pontos. Por exemplo, o endereço:
FF05:0:0:0:0:0:0:B3
Pode ser escrito como:
FF05::B3
Para garantir que a compactação de zeros produza uma interpretação não ambígua, a
proposta especifica que ela pode ser aplicada apenas uma vez em qualquer endereço. A
compactação de zero é especialmente útil quando usada com o esquema de atribuição de
endereço proposto, pois muitos endereços terão sequências contíguas de zeros. Em segundo
lugar, a notação hexadecimal com dois pontos incorpora os sufixos decimais pontilhados.
Veremos que essas combinações devem ser usadas durante a transição do IPv4 para o IPv6.
Por exemplo, a sequência a seguir é uma notação hexadecimal com dois pontos válida:
0:0:0:0:0:0:128.10.2.1
Observe que, embora os números separados por sinais de dois pontos especifiquem o
valor de uma quantidade de 16 bits, os números na parte decimal com ponto especificam,
cada um, o valor de um octeto. Naturalmente, a compactação de zeros pode ser usada com o
número anterior para produzir uma seqüência hexadecimal de dois pontos equivalente, muito
semelhante a um endereço IPv4:
::128.10.2.1
Finalmente, o IPv6 estende a notação tipo CIDR, permitindo que um endereço seja
seguido por uma barra e um inteiro que especifica um número de bits. Por exemplo:
12AB::CD30:0:0:0:0/60
Esta notação especifica os primeiros 60 bits do endereço ou (12AB00000000CD3) 16.
7.16.14 Endereços IPv4 Embutidos e Transição
Embora o prefixo 0000 0000 seja rotulado como reservado, os projetistas planejam usar
uma pequena fração dos endereços nessa seção para codificar os endereços IPv4. Em
particular, qualquer endereços que começa com 80 bits zero seguidos por 16 bits 1 ou 16 bits
0 contém um endereço IPv4 nos 32 bits de baixa ordem. O valor do campo de 16 bits indica
se o nó também tem um endereço de unicast IPv6 convencional. A Figura 7.30 ilustra as
duas formas.
80 bits zero
0000.......0000
0000.......0000
16 bits
0000
FFFF
32 bits
Endereço IPv4
Endereço IPv4
Figura 7.30 – Codificação de um Endereço IPv4 em um Endereço IPv6.
A codificação será necessária durante a transição do IPv4 para IPv6 por dois motivos.
Primeiro, um computador pode escolher atualizar do IPv4 para IPv6 antes de receber um
endereço IPv4 válido. Segundo, um computador usando IPv6 pode ter de se comunicar com
um computador que usa IPv4.
134
Ter um modo de codificar um endereço IPv4 em um endereço IPv6 não soluciona o
problema de tornar as duas versões interoperáveis. Além de resolver a codificação, a
tradução é necessária. Para usar um tradutor, um computador IPv6 gera um datagrama que
contém a codificação IPv6 do endereço de destino IPv4. O computador IPv6 envia o
datagrama a um tradutor, que usa IPv4 para se comunicar com o destino. Quando o tradutor
recebe uma resposta do destino, ele traduz o datagrama IPv4 para IPv6 e o envia de volta à
origem IPv6.
Pode parecer que a tradução de endereços de protocolo poderia falhar porque
protocolos de camada mais alta verificam a integridade do endereço. Em particular, TCP e
UDP utilizam um pseudocabeçalho em seu cálculo de checksum. O pseudocabeçalho inclui
os endereços de protocolo de origem e destino, de modo que alterar esses endereços poderia
afetar o cálculo. Porém, os projetistas planejaram cuidadosamente para permitir que o TCP
ou UDP em uma máquina IPv4 se comuniquem com o protocolo de transporte
correspondente em uma máquina IPv6. Para evitar divergências do checksum, a codificação
IPv6 de um endereço IPv4 foi escolhida de modo que o checksum do complemento a 1 de 16
bits para um endereço IPv4 e a codificação IPv6 do endereço sejam idênticos.
7.16.15 Endereços Não-Especificados e de Loopback
Assim como no IPv4, alguns endereços IPv6 receberam significado especial. Por
exemplo, o endereço tudo zero:
0:0:0:0:0:0:0:0
Este é um endereço não-especificado. Que não pode ser atribuído a qualquer
computador ou usado como destino. Ele só é usado como endereço de origem durante a
inicialização por um computador que ainda não descobriu seu endereço.
Assim como o IPv4, o IPv6 também possui um endereço de loopback que é usado para
testar o software. O endereço de loopback do IPv6 é:
0:0:0:0:0:0:0:1
Qualquer datagrama enviado ao endereço de loopback será entregue à máquina local.
Ele nunca deve ser usado como endereço de destino em um datagrama que sai.
7.16.16 Estrutura de Endereço Unicast
A versão mais recente da estrutura de endereçamento unicast do IPv6 é semelhante ao
esquema de endereçamento de sub-rede, em que cada endereço é dividido em três partes
conceituais. No IPv6, as três partes correspondem a: um prefixo exclusivamente definido
usado para rotear o datagrama, uma ID de sub-rede, usada para distinguir entre várias redes
físicas em determinado site, e uma ID de interface, para identificar uma conexão em
particular com a sub-rede. A Figura 7.31 ilustra como um endereço IPv6 é desmembrado em
partes.
N bits
PREFIXO DE ROTEAMENTO GLOBAL
64–N bits
ID DE SUB-REDE
64 bits
ID DE INTERFACE
Figura 7.31 – A Divisão de um Endereço de Unicast IPv6 em Três Partes.
7.17 ICMP
Anteriormente mostrou-se como o Internet Protocol provê um serviço de entrega de
datagrama não confiável e sem conexão, fazendo com que cada roteador encaminhe datagramas.
Um datagrama viaja de um roteador para outro até que alcance um que possa entregar o
datagrama diretamente para o seu destino final. Se um roteador não puder encaminhar ou entregar
135
um datagrama, ou se o roteador detectar uma condição incomum que afete sua capacidade de
realizar o encaminhamento (por exemplo, congestionamento de rede), o roteador precisa informar
à origem para que esta tome uma ação no sentido de evitar ou corrigir o problema. Nesta seção
discutiremos um mecanismo que os roteadores e hosts da Internet utilizam para comunicar essa
informação de controle ou erro. Veremos que os roteadores usam o mecanismo para relatar
problemas e os hosts o utilizam para testar se os destinos são alcançáveis.
7.17.1 O Internet Control Message Protocol
No sistema sem conexão que descrevemos até aqui, cada roteador opera de forma
autônoma, encaminhando e entregando datagramas que chegam sem coordenar com o
emissor original. O sistema funciona bem se todos os hosts e roteadores operarem
corretamente e combinarem a respeito das rotas. Infelizmente, nenhum sistema de
comunicação grande funciona corretamente o tempo todo. Além de falhas das linhas de
comunicação e processadores, o IP deixa de entregar datagramas quando a máquina de
destino for temporariamente ou permanentemente desconectada da rede, quando o contador
de tempo de vida expirar, ou quando roteadores intermediários ficarem tão congestionados
que não possam processar o tráfego que chega. A diferença importante entre ter uma única
rede implementada com hardware homogêneo, dedicado, e uma rede implementada com
vários sistemas independentes é que, no primeiro caso, o projetista pode arrumar o hardware
para informar aos hosts conectados quando surgirem problemas. Em uma rede, que não
possui tal mecanismo de hardware, um emissor não pode saber se uma falha de entrega
resultou de um defeito local ou de um remoto. A depuração se torna extremamente difícil.
O próprio protocolo IP não contém nada para ajudar o emissor a testar a conectividade ou
descobrir tais falhas.
Para permitir que os roteadores em uma internet informem erros ou ofereçam
informações sobre circunstâncias inesperadas, os projetistas incluíram um mecanismo de
mensagem de uso especial aos protocolos TCP/IP. O mecanismo, conhecido como Internet
Control Message Protocol (ICMP), é considerado uma parte obrigatória do IP e precisa ser
incluído em toda implementação IP.
Assim como outros tipos de tráfego, as mensagens ICMP atravessam a Rede na parte
de dados dos datagramas IP. Porém, o destino final de uma mensagem ICMP não é um
aplicativo ou usuário na máquina de destino, mas o software de Internet Protocol nessa
máquina. Ou seja, quando chega uma mensagem de erro ICMP, o módulo de software ICMP
trata dela. Naturalmente, se o ICMP estabelece que determinado protocolo ou aplicativo de
nível superior causou um problema, ele informa o módulo apropriado.
Inicialmente projetado para permitir que os roteadores informem a causa dos erros de
entrega aos hosts, o ICMP não é restrito a roteadores. Embora as diretrizes restrinjam o uso
de algumas mensagens ICMP, uma máquina qualquer pode enviar uma mensagem ICMP a
qualquer outra máquina. Assim, um host pode usar ICMP para corresponder com um
roteador ou outro host. A principal vantagem de permitir que os hosts utilizem ICMP é que
oferece um único mecanismo, usado para todas as mensagens de controle e informação.
7.17.2 Relato de erro versus correção de erro
Tecnicamente, o ICMP é um mecanismo de relato de erro. Ele fornece um meio para
que os roteadores que encontram um erro relatem o erro à origem do datagrama. Embora a
especificação do protocolo esboce os usos intencionados do ICMP e sugira possíveis ações a
serem tomadas em resposta aos relatórios de erro, o ICMP não especifica totalmente a ação
a ser tomada para cada erro possível.
136
A maioria dos erros vem da origem, mas outros não. Como o ICMP relata problemas
à origem, ele não pode ser usado para informar aos roteadores intermediários sobre os
problemas. Por exemplo, suponha que um datagrama percorra um caminho por uma
seqüência de roteadores R1, R2, ..., Rk. Se Rk tiver informações de roteamento incorretas e
por engano encaminhar o datagrama ao roteador RE, RE não poderá usar o ICMP para
informar o erro ao roteador Rk. O ICMP só pode enviar um relatório de volta à origem.
Infelizmente, a origem não tem responsabilidade pelo problema ou controle sobre o roteador
com erro de comportamento. Na verdade, a origem pode não ser capaz de determinar qual
roteador causou o problema.
Por que restringir o ICMP à comunicação com a origem? A resposta deverá ser clara
pela nossa discussão sobre formatos e encaminhamento de datagrama. Um datagrama só
contém campos que especificam a origem e o destino final. Ele não contém um registro
completo de sua viagem pela rede (exceto para casos incomuns, em que a opção de registro
de rota é utilizada). Além do mais, como os roteadores podem estabelecer e alterar suas
próprias tabelas de roteamento, não existe um conhecimento global das rotas. Assim, quando
um datagrama alcança determinado roteador, é impossível conhecer o caminho que foi
tomado para chegar lá. Se o roteador detectar um problema, o IP não poderá saber o conjunto
de máquinas intermediárias que processaram o datagrama, de modo que não poderá
informar-lhes quanto ao problema. Em vez de descartar silenciosamente o datagrama, o
roteador utiliza o ICMP para informar à origem de que ocorreu um problema e confia que os
administradores do host cooperarão com os administradores da rede para localizar e reparar
o problema.
7.17.3 Entrega de mensagem ICMP
As mensagens ICMP exigem dois níveis de encapsulamento, como mostra a
Figura 7.32. Cada mensagem ICMP atravessa a internet na parte de dados de um datagrama
IP, que por si só trafega por cada rede física na parte de dados de um frame. Os datagrarnas
transportando mensagens ICMP são encaminhados exatamente como datagramas que
transportam informações para usuários. Não existe confiabilidade ou prioridade adicional.
Assim, as próprias mensagens de erro podem ser perdidas ou descartadas. Além do mais, em
uma rede já congestionada, uma mensagem de erro pode causar congestionamento adicional.
Existe uma exceção nos procedimentos de tratamento de erro se um datagrama IP
transportando uma mensagem ICMP causar um erro. A exceção, estabelecida para evitar o
problema de haver mensagens de erro sobre mensagens de erro, especifica que as mensagens
ICMP não são geradas para erros que resultam de datagramas transportando mensagens de
erro ICMP.
Figura 7.32 – Dois níveis de encapsulamento ICMP.
137
É importante ter em mente que, embora as mensagens ICMP sejam encapsuladas e
enviadas usando IP, o ICMP não é considerado um protocolo de nível superior. Ele é uma
parte obrigatória do IP. O motivo para usar o IP para entregar mensagens ICMP é que elas
podem ter de atravessar várias redes físicas para alcançar seu destino final. Assim, elas não
podem ser entregues apenas pelo transporte físico.
7.17.4 Formato de mensagem ICMP
Embora cada mensagem ICMP tenha seu próprio formato, todas elas começam com os
mesmos três campos: um campo de TIPO (TYPE) de mensagem inteiro de 8 bits, que
identifica a mensagem, um campo de CÓDIGO (CODE) de 8 bits, que oferece mais
informações sobre o tipo de mensagem e um campo de CHECKSUM de 16 bits (o ICMP usa
o mesmo algoritmo de checksum aditivo do IP, mas o checksum ICMP só abrange a
mensagem ICMP). Além disso, as mensagens ICMP que informam erros sempre incluem o
cabeçalho e mais octetos adicionais do datagrama que causou o problema1.
O motivo para o ICMP retornar mais do que o cabeçalho do datagrama é apenas de
permitir que o receptor determine mais exatamente quais protocolos e quais programas de
aplicativos foram responsáveis pelo datagrama. Como veremos mais adiante, os protocolos
de nível superior no conjunto TCP/IP são projetados de modo que as informações cruciais
sejam codificadas nos primeiros 64 bits após o cabeçalho IP.
O campo de TIPO do ICMP define o significado da mensagem, além de seu formato.
A Tabela 7.7 lista os tipos possíveis de mensagem ICMP:
1
Para manter as mensagens de erro pequenas e evitar a fragmentação, não é possível incluir o datagrama inteiro que causou
o problema.
138
Campo de Tipo
0
3
4
5
6
8
9
10
11
12
13
14
15
16
17
18
30
31
32
33
34
35
36
37
38
39
40
Tipo de mensagem ICMP
Resposta de eco
Destino inalcançável
Extinção de origem
Redirecionamento (mudar de rota)
Endereço de host alternativo
Requisição de eco
Anúncio de roteador
Solicitação de roteador
Tempo excedido para um datagrama
Problema de parâmetro em um datagrama
Requisição de estampa de tempo
Resposta de estampa de tempo
Requisição de informações
Resposta de informações
Requisição de máscara de tempo
Resposta de máscara de tempo
Traceroute
Erro de conversão de datagrama
Redirecionar host móvel
“Onde está você” do IPv6
“Eu estou aqui” do IPv6
Requisição de registro móvel
Resposta de registro móvel
Requisição de nome de domínio
Resposta de nome de domínio
SKIP
Photuris
Tabela 7.7 – Valores do campo TYPE de uma mensagem ICMP.
As próximas seções descrevem cada uma dessas mensagens, dando detalhes do formato
de mensagem e seu significado.
7.17.5 Teste de alcance e status do destino (ping)
Os protocolos TCP/IP oferecem facilidades para ajudar os gerentes ou usuários de rede
a identificar problemas de rede. Uma das ferramentas de depuração mais utilizadas envolve
as mensagens de requisição de eco e resposta de eco ICMP. Um host ou roteador envia uma
mensagem de requisição de eco ICMP a um destino especificado. Qualquer máquina que
receber uma requisição de eco formula uma resposta de eco e a retoma ao emissor original.
A requisição contém uma área de dados opcional. A resposta contém uma cópia dos dados
enviados do solicitante. A requisição de eco e a resposta associada podem ser usadas para
testar se um destino é alcançável e está respondendo. Como a requisição e a resposta
trafegam nos datagramas IP, o recebimento bem sucedido de uma resposta verifica se as
principais partes do sistema de transporte funcionam. Primeiro, o IP no computador de
origem precisa encaminhar o datagrama. Segundo, os roteadores intermediários entre a
origem e o destino precisam estar operando e precisam encaminhar o datagrama
corretamente. Terceiro, a máquina de destino precisa estar funcionando (pelo menos, ela
precisa responder a interrupções), e o software ICMP e IP precisam estar funcionando.
139
Finalmente, as tabelas de roteamento em todos os roteadores ao longo do caminho de retorno
precisam conter informações que formam um caminho viável.
Em muitos sistemas, o comando que os usuários invocam para enviar requisições de
eco ICMP é chamado de ping1. Algumas versões de ping enviam um número fixo de pacotes
de requisição e esperam respostas. Outras versões enviam uma série de requisições de eco
ICMP, capturam respostas e fornecem estatísticas sobre a perda de datagramas. A maioria
das versões permite que o usuário especifique o tamanho dos dados sendo enviados e o
intervalo entre as requisições. O envio de um pacote ping grande é útil para testar a
fragmentação e a remontagem.
7.17.6 Requisição de eco e formato de mensagem de resposta
A Figura 7.33 mostra o formato das mensagens de requisição de ecos e resposta.
0
8
16
24
31
TIPO (8 ou 0)
CÓDIGO (0)
CHECKSUM
IDENTIFICADOR
NÚMERO DE SEQÜÊNCIA
DADOS OPCIONAIS
...
Figura 7.33 – Formato de uma mensagem de requisição ou resposta de eco do ICMP.
O campo listado como DADOS OPCIONAIS é um campo de tamanho variável que
contém dados a serem retornados ao emissor. Uma resposta de eco sempre retorna
exatamente os mesmos dados que foram recebidos na requisição.
Os campos
IDENTIFICADOR e NÚMERO DE SEQÜÊNCIA são usados pelo emissor para combinar as
respostas com as requisições. O valor do campo TIPO especifica se a mensagem é uma
requisição (8) ou uma resposta (0).
7.17.7 Relatos de destinos inalcançáveis
Quando um roteador não pode encaminhar ou entregar um datagrama IP, ele envia
uma mensagem de destino inalcançável (unreacheble destination) de volta à origem, usando
o formato mostrado na Figura 7.34.
0
8
16
24
31
CÓDIGO (0 – 15)
CHECKSUM
NÃO USADO (PRECISA SER ZERO)
CABEÇALHO INTERNET + PRIMEIROS 64 BITS DO DATAGRAMA
...
TIPO (3)
Figura 7.34 – Formato da mensagem de destino inalcançável do ICMP.
O campo de CÓDIGO em uma mensagem de destino inalcançável contém um inteiro
que descreve ainda mais o problema. Os valores possíveis são mostrados na Tabela 7.8.
Embora o IP seja um mecanismo de entrega pelo melhor esforço, descartar datagramas
não deve ser desconsiderado. Sempre que um erro impede um roteador de encaminhar ou
entregar um datagrama, o roteador envia uma mensagem destino inalcançável de volta à
origem e depois descarta (desconsidera) o datagrama. Os erros de rede inalcançável
implicam no encaminhamento de falhas em pontos intermediários. Erros de host
inalcançável implicam em falhas de entrega 2. Como a mensagem de erro ICMP contém um
1
2
Dave Mills ceta vez sugeriu que PING é um acr6onimo para Packet InterNet Groper.
O IETF recomenda apenas relatar mensagens de host inalcançável à origem e usar protocolos de roteamento para lidar com
outros problemas de encaminhamento.
140
prefixo curto do datagrama que causou o problema, a origem saberá exatamente qual
endereço é inalcançável.
Valor do Código
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Significado
Rede inalcançável
Host inalcançável
Protocolo inalcançável
Porta inalcançável
Fragmentação necessária e DF marcado
Rota de origem falhou
Rota de destino desconhecida
Host de destino desconhecido
Host de origem isolado
Comunicação com rede de destino proibida administrativamente
Comunicação com host de destino proibida administrativamente
Rede inalcançável para tipo de serviço
Host inalcançável para tipo de serviço
Comunicação proibida administrativamente
Violação de precedência de host
Corte de precedência em vigor
Tabela 7.8 – Valores possíveis para o campo CÓDIGO.
Os destinos podem ser inalcançáveis porque o hardware está temporariamente fora de
serviço, pois o emissor especificou um endereço de destino inexistente, ou (em raras
circunstâncias) porque o roteador não tem uma rota para a rede de destino. Observe que,
embora os roteadores informem falhas que eles encontram, não podem saber de todas as
falhas de entrega. Por exemplo, se a máquina de destino se conecta a uma rede Ethernet, o
hardware de rede não oferece confirmações. Portanto, um roteador pode continuar a enviar
pacotes a um destino depois que o destino for desligado sem receber qualquer indicação de
que os pacotes não estão sendo entregues.
O significado das mensagens de protocolo e porta inalcançável se tornará claro quando
estudarmos como os protocolos de nível superior usam pontos de destino abstratos chamados
portas. A maioria das mensagens restantes é fácil de entender. Se o datagrama tiver a opção
de rota de origem com uma rota incorreta, ele pode disparar uma mensagem de falha de rota
de origem. Se um roteador precisar fragmentar um datagrama, mas o bit “não fragmentar”
estiver marcado, o roteador enviará uma mensagem fragmentação necessária de volta à
origem.
7.17.8 Controle de congestionamento e fluxo de datagramas
Como o IP é sem conexão, um roteador não pode reservar recursos de memória ou de
comunicação antes do recebimento dos datagramas. Como resultado, os roteadores podem
ser sobrecarregados de tráfego, uma condição conhecida como congestionamento. É
importante entender que o congestionamento pode surgir por dois motivos inteiramente
diferentes. Primeiro, um computador de alta velocidade pode ser capaz de gerar tráfego mais
rapidamente do que uma rede pode transferi-lo. Por exemplo, imagine um supercomputador
gerando tráfego de intemet. Os datagramas podem precisar cruzar uma conexão discada de
baixa velocidade, embora o próprio supercomputador se conecte a uma rede local de alta
velocidade. O congestionamento ocorrerá no roteador que conecta a rede de alta velocidade
à linha discada de baixa velocidade, pois os datagramas chegam mais rapidamente do que
141
podem ser enviados. Em segundo lugar, se muitos computadores precisarem enviar
simultaneamente datagramas por um único roteador, o roteador pode experimentar
congestionamento, embora nenhuma origem isolada cause o problema.
Quando os datagramas chegam muito rapidamente para um host ou roteador processar,
ele os enfileira na memória temporariamente. Se os datagramas fizerem parte de uma
pequena rajada, esse uso de buffer soluciona o problema. Se o tráfego continuar, o host ou
roteador, por fim, esgota a memória e precisa descartar datagramas adicionais que chegam.
Uma máquina usa mensagens de extinção de origem ICMP para informar descarte de
datagrama à origem. Uma mensagem de extinção de origem é uma requisição para a origem
reduzir sua taxa atual de transmissão de datagramas. Normalmente, os roteadores
congestionados enviam uma mensagem de extinção de origem para cada datagrama que eles
descartam. Os roteadores também podem usar técnicas de controle de congestionamento
mais sofisticadas. Alguns monitoram o tráfego que chega e extinguem as origens que
possuem as taxas de transmissão de datagrama mais altas. Outros tentam evitar
completamente o congestionamento, enviando requisições quando suas filas começam a se
tornar longas, mas antes que estourem.
Não existe mensagem ICMP para reverter o efeito de uma extinção de origem. Em vez
disso, um host que recebe mensagens de extinção de origem para um destino, D, reduz a taxa
em que envia datagramas para D até que termine de receber mensagens de extinção de
origem. Depois, ele pode gradualmente aumentar a taxa, desde que nenhuma outra requisição
de extinção de origem seja recebida. Na prática, a maioria das implementações ignora a
extinção de origem e conta com protocolos da camada superior como TCP para reagir ao
congestionamento.
7.17.9 Formato de extinção de origem
Além dos campos ICMP normais de TIPO, CÓDIGO, CHECKSUM e um campo não
usado de 32 bits, as mensagens de extinção de origem possuem um campo que contém um
prefixo de datagrama. A Figura 7.35 ilustra o formato. Assim como a maioria das
mensagens ICMP que relatam um erro, o campo de prefixo de datagrama contém um prefixo
do datagrama que disparou a requisição de extinção de origem.
0
8
16
24
31
TIPO (4)
CÓDIGO (0)
CHECKSUM
...
Figura 7.35 – Formato da mensagem de extinção de origem ICMP.
7.17.10 Requisições de mudança de rota dos roteadores
As tabelas de roteamento de intemet normalmente permanecem estáticas por longos
períodos de tempo. Os hosts as inicializam por um arquivo de configuração na partida do
sistema, e os administradores do sistema raramente mudam de rotas durante as operações
normais. Conforme veremos em outros casos, os roteadores são mais dinâmicos. Eles trocam
informações de roteamento periodicamente para acomodar mudanças de rede e manter suas
rotas atualizadas. Assim, via de regra, os roteadores conhecem rotas corretas. Os hosts
começam com informações de roteamento mínimas e descobrem novas rotas a partir dos
roteadores.
Para ajudar a seguir essa regra e evitar duplicação de informações no arquivo de
configuração em cada host, a configuração inicial da rota do host especifica a informação
142
mínima possível da rota necessária para se comunicar (por exemplo, o endereço de um único
roteador). Assim, o host começa com informações mínimas e conta com roteadores para
atualizar sua tabela de roteamento. Em um caso especial, quando um roteador detecta um
host usando uma rota não ideal, ele envia ao host uma mensagem ICMP, chamada
redirecionamento (Redirect), solicitando que o host mude sua rota. O roteador também
encaminha o datagrama original para o seu destino.
A vantagem do esquema de redirecionamento ICMP é a simplicidade: ele permite que
um host dê partida sabendo o endereço de apenas um roteador na rede local. O roteador
inicial retorna as mensagens de redirecionamento ICMP sempre que um host envia um
datagrama para o qual existe uma rota melhor. A tabela de roteamento do host permanece
pequena, mas ainda contém rotas ideais para todos os destinos em uso.
Por serem limitadas a interações entre um roteador e um host em uma rede conectada
diretamente, as mensagens de redirecionamento não solucionam o problema de propagar
informações de roteamento de uma maneira geral. A Figura 7.36 ilustra a limitação. Na
figura, considere que a origem S envia um datagrama ao destino D. Suponha que o roteador
R1 encaminhe incorretamente o datagrama pelo roteador R2 no lugar do roteador R4 (ou seja,
R1 incorretamente escolhe um caminho maior que o necessário). Quando o roteador R5
recebe um datagrama, ele não pode enviar uma mensagem de redirecionamento ICMP para
R1, pois não conhece o endereço de R1.
Figura 7.36 – Mensagens de redirecionamento ICMP.
Além dos campos obrigatórios TIPO, CÓDIGO e CHECKSUM, cada mensagem de
redirecionamento contém um campo de ENDEREÇO INTERNET DE ROTEADOR e um
campo CABEÇALHO DE INTERNET, como mostra a Figura 7.37.
0
8
16
24
31
TIPO (5)
CÓDIGO (0 a 3)
CHECKSUM
ENDEREÇO INTERNET DO ROTEADOR
...
Figura 7.37 – Formato da mensagem de redirecionamento ICMP.
O campo ENDEREÇO INTERNET DO ROTEADOR contém o endereço de um
roteador que o host deve usar para alcançar o destino mencionado no cabeçalho do
datagrama. O campo de CABEÇALHO INTERNET contém o cabeçalho IP mais os próximos
64 bits do datagrama que dispararam a mensagem. Assim, um host recebendo um
redirecionamento ICMP examina o prefixo do datagrama para determinar o endereço de
destino do datagrama. O campo CÓDIGO de uma mensagem de redirecionamento ICMP
especifica ainda como interpretar o endereço de destino com base nos valores atribuídos,
como mostra a Tabela 7.9.
143
Valor do Código
0
1
2
3
Significado
Redirecionar datagramas para a Rede (agora obsoleto)
Redirecionar datagramas para o Host
Redirecionar datagramas para o Tipo de Serviço; e Rede
Redirecionar datagramas para o Tipo de Serviço; e Host
Tabela 7.9 – Valor do campo CÓDIGO para uma mensagem de redirecionamento.
Via de regra, os roteadores só enviam requisições de redirecionamento ICMP para os
hosts e não para outros roteadores.
7.17.11 Detectando rotas circulares ou excessivamente longas
Como os roteadores da internet calculam um próximo salto usando tabelas locais, os
erros nas tabelas de roteamento podem produzir um ciclo de roteamento para algum
destino, D. Um ciclo de roteamento pode consistir em dois roteadores, e cada um encaminha
um datagrama para o destino D ao outro, ou pode consistir em vários roteadores. Quando
vários roteadores formam um ciclo, cada um deles encaminha um datagrama para o destino
D ao próximo roteador no ciclo. Se um datagrama entrar em um ciclo de roteamento, ele
passará o ciclo adiante sem fim. Como já mencionamos, para evitar que os datagramas
circulem para sempre em uma Rede TCP/IP, cada datagrama IP contém um contador de
tempo de vida, às vezes chamado de contador de salto. Sempre que processa um datagrama,
um roteador decrementa o contador de tempo de vida e descarta o datagrama quando o
contador chega a zero.
Sempre que ele descarta um datagrama porque seu próximo salto atingiu zero ou
porque ocorreu um timeout enquanto esperava por fragmentos de um datagrama, um roteador
envia uma mensagem de tempo excedido do ICMP de volta à origem do datagrama, usando
o formato mostrado na Figura 7.38.
0
8
16
24
31
CÓDIGO (0 – 1)
CHECKSUM
...
TIPO (11)
Figura 7.38 – Formato da mensagem de tempo excedido do ICMP.
O ICMP usa o campo CÓDIGO em cada mensagem de tempo excedido (valor zero ou
um) para explicar a natureza do timeout sendo relatado, com mostra a Tabela 7.10.
Valor do Código
0
1
Significado
Contador de tempo de vida excedido
Tempo de remontagem de fragmento excedido
Tabela 7.10 – Valor do campo CÓDIGO para um tempo excedido.
A remontagem de fragmento refere-se à tarefa de coletar todos os fragmentos de um
datagrama. Quando o primeiro fragmento de um datagrama chega, o host receptor inicia
um timer e considera um erro se o timer expirar antes que todas as partes do datagrama
cheguem. O valor de código 1 é usado para informar tais erros ao emissor; uma mensagem
é enviada para cada erro.
7.17.12 Relatando outros problemas
Quando um roteador ou host encontrar problemas com um datagrama não coberto
pelas mensagens de erro ICMP anteriores (por exemplo, um cabeçalho de datagrama
144
incorreto), ele envia uma mensagem “problema de parâmetro” para a origem. Uma possível
causa desses problemas ocorre quando os argumentos de uma opção estão incorretos. A
mensagem, formatada como na Figura 7.39, só é enviada quando o problema é tão severo
que o datagrama precisa ser descartado.
0
8
16
24
31
TIPO (12)
CÓDIGO (0 – 1)
CHECKSUM
PONTEIRO
...
Figura 7.39 – Formato da mensagem de problema de parâmetro do ICMP.
Para que a mensagem não fique ambígua, o emissor usa o campo PONTEIRO do
cabeçalho da mensagem a fim de identificar o octeto no datagrama que causou o problema.
O código 1 é usado para informar que uma opção obrigatória está faltando (por exemplo,
uma opção de segurança na comunidade militar). O campo PONTEIRO não é usado para o
código 1.
7.17.13 Sincronismo de clock e estimativa de tempo de trânsito
Embora as máquinas em uma internet possam se comunicar, elas normalmente operam
de forma independente, com cada máquina mantendo sua própria noção da hora atual. Os
clocks que diferem muito podem confundir os usuários ou software de sistemas distribuídos.
O conjunto de protocolos TCP/IP inclui vários protocolos que podem ser usados para
sincronizar clocks. Uma das técnicas mais simples utiliza uma mensagem ICMP para obter
a hora de outra máquina. Uma máquina solicitante envia uma mensagem de “requisição de
estampa de tempo” do ICMP para outra máquina, pedindo que a segunda máquina retorne
seu valor atual para a hora do dia. A máquina receptora retorna uma resposta de estampa de
tempo à máquina que faz a requisição. A Figura 7.40 mostra o formato da requisição de
estampa de tempo e mensagens de resposta.
0
8
16
24
31
TIPO (13 ou 14)
CÓDIGO (0)
CHECKSUM
IDENTIFICADOR
ESTAMPA DE TEMPO DE ORIGEM
ESTAMPA DE TEMPO DE RECEBIMENTO
ESTAMPA DE TEMPO DE TRANSMISSÃO
Figura 7.40 – Formato da mensagem de requisição ou resp. de estampa de tempo do ICMP.
O campo TIPO identifica a mensagem como uma requisição (13) ou uma resposta (14);
os campos IDENTIFICADOR e NÚMERO DE SEQÜÊNCIA são usados pela origem para
associar respostas a requisições. Os campos restantes especificam horas, dadas em
milissegundos desde a meia-noite no Universal Time1. O campo ESTAMPA DE TEMPO DE
ORIGEM é preenchido pelo emissor original imediatamente antes de o pacote ser
transmitido. O campo ESTAMPA DE TEMPO DE RECEBIMENTO é preenchido
imediatamente no recebimento de uma requisição; e o campo ESTAMPA DE TEMPO DE
TRANSMISSÃO é preenchido imediatamente antes que a resposta seja transmitida.
Os hosts utilizam os três campos de estampa de tempo para calcular estimativas do
tempo de retardo entre eles e sincronizar seus clocks. Como a resposta inclui o campo
ESTAMPA DE TEMPO DE ORIGEM, um host pode calcular o tempo total exigido para uma
1
Universal Time anteriormente era chamado Greenwich Mean Time: é a hora do dia no meridiano principal.
145
requisição atravessar até um destino, ser transformada em uma resposta e retornar. Como a
resposta transporta tanto a hora em que a requisição entrou na máquina remota quanto a hora
em que a resposta saiu, o host pode calcular o tempo de trânsito na rede e, a partir disso,
estimar as diferenças nos clocks remoto e local.
Na prática, a estimativa exata do retardo de ida e volta pode ser difícil e pode restringir
substancialmente a utilidade das mensagens de estampa de tempo do ICMP. Naturalmente,
para obter uma estimativa precisa do retardo de ida e volta, deve-se fazer muitas medições e
calcular sua média. Porém, o retardo de ida e volta entre um par de máquinas que se conectam
a uma internet grande pode variar muito, mesmo por períodos de tempo curtos. Além do
mais, lembre-se de que, como o IP é uma tecnologia do melhor esforço, os datagramas
podem ser descartados, adiados ou entregues fora da ordem. Assim, simplesmente apanhar
muitas medições pode não garantir a consistência; uma análise estatística sofisticada é
necessária para produzir estimativas precisas.
7.17.14 Mensagens ICMP mais antigas e não mais necessárias
Originalmente, o ICMP definia um conjunto de mensagens que um host usava na
partida para determinar seu endereço IP, o endereço de um roteador e a máscara de endereço
usada na rede. Atualmente, um protocolo conhecido como DHCP oferece toda a informação
necessária em uma única troca, e as mensagens ICMP mais antigas não são mais usadas.
Mensagens de requisição e resposta de informações. As mensagens de requisição e
resposta de informações do ICMP (tipos 75 e 16) tinham por finalidade permitir que os hosts
descobrissem seu endereço Internet na partida do sistema. O IETF as declarou obsoletas, de
modo que não devem ser usadas.
Mensagens de requisição e resposta de máscara de endereço. As mensagens de
requisição e resposta de máscara de endereço do ICMP (tipos 17 e 18) tinham por finalidade
permitir que um host obtivesse a máscara de endereço usada na rede local. Uma requisição
era enviada por broadcast, e os roteadores na rede enviavam uma resposta.
Mensagens de requisição e anúncio de roteador. As mensagens de requisição e anúncio
de roteador do ICMP tinham por finalidade permitir que um host descobrisse os roteadores
atualmente disponíveis em uma rede local. Diferente do DHCP, que usa um arquivo de
configuração para fornecer o endereço de um roteador, o mecanismo de descoberta de
roteador ICMP oferece comunicação direta. Um host recebe anúncios diretamente dos
roteadores.
Embora não sendo mais usada, a descoberta de roteador ICMP oferece duas diferenças
conceituais do DHCP. Primeiro, como a informação é obtida diretamente do próprio
roteador, a informação nunca fica velha. Segundo, a descoberta de roteador ICMP utiliza
uma técnica de estado flexível com timers para impedir que os hosts retenham uma entrada
de tabela de roteamento após a falha de um roteador. Os roteadores anunciam suas
informações periodicamente, e um host descarta uma rota se o timer para a rota expirar.
7.18 UDP
Anteriormente foi descrita uma rede abstrata capaz de transferir datagramas IP entre
computadores host, em que cada datagrama é encaminhado pela internet com base no endereço
IP do destino. No nível de internet, um endereço de destino identifica um host; nenhuma outra
distinção é feita com relação a qual usuário ou qual programa aplicativo receberá o datagrama.
Esta seção e a seção 7.19 estendem o conjunto de protocolos TCP/IP, acrescentando um
mecanismo que distingue entre destinos dentro de determinado host, permitindo que vários
146
programas aplicativos executando em um determinado computador enviem e recebam
datagramas independentemente.
7.18.1 Identificando o destino final
Os sistemas operacionais na maioria dos computadores admitem multiprogramação, o
que significa que eles permitem que vários programas aplicativos sejam executados
simultaneamente. Usando o jargão do sistema operacional, nos referimos a cada programa
executando como um processo, tarefa, programa aplicativo ou processo em nível de usuário.
Os sistemas são denominados sistemas de multitarefa. Pode parecer natural dizer que um
processo é o destino final para uma mensagem, porém, é um tanto enganoso especificar que
um processo em particular em determinada máquina é o destino final para um datagrama.
Primeiro, como os processos são criados e destruídos dinamicamente, os emissores raramente
conhecem o suficiente para identificar um processo em outra máquina. Segundo,
gostaríamos de ser capazes de substituir processos que recebem datagramas sem informar a
todos os emissores (por exemplo, reinicializar uma máquina pode mudar todos os processos,
mas os emissores não devem ter de saber a respeito dos novos processos). Terceiro, é
desejável identificar um destino pela função que ele oferece sem conhecer o processo que
implementa a função (por exemplo, permitir que um emissor entre em contato com um
servidor de e-mail sem saber qual processo na máquina de destino implementa função do
servidor). Mais importante, nos sistemas que permitem que um único processo trate de duas
ou mais funções, é essencial que arrumemos um meio para um processo decidir exatamente
qual função o emissor deseja.
Em vez de pensar em um processo como o destino final, imaginaremos que cada
máquina contém um conjunto de pontos de destino abstratos, chamados portas de protocolo.
Cada porta de protocolo é identificada por um inteiro positivo. O sistema operacional local
oferece um mecanismo de interface que processa o uso para especificar uma porta ou acessála.
A maioria dos sistemas operacionais fornece acesso síncrono às portas. Do ponto de
vista de um processo em particular, o acesso síncrono significa que a computação termina
durante uma operação de acesso à porta. Por exemplo, se um processo tenta extrair dados de
uma porta antes que quaisquer dados cheguem, o sistema operacional temporariamente para
(bloqueia) o processo até que os dados cheguem. Quando os dados chegam, o sistema
operacional os passa para o processo e os reinicia. Em geral, as portas são bufferizadas, de
modo que os dados que chegam antes que um processo esteja pronto para aceitá-los não serão
perdidos. Para usar os buffers, o protocolo localizado dentro do sistema operacional coloca
pacotes que chegam para determinada porta do protocolo em uma fila (finita) até que um
processo os extraia.
Para se comunicar com uma porta externa, um emissor precisa conhecer tanto o
endereço IP da máquina de destino quanto o número de porta de protocolo do destino dentro
dessa máquina. Cada mensagem precisa transportar o número da porta de destino da máquina
à qual a mensagem é enviada e o número da porta de origem da máquina de origem à qual as
respostas devem ser endereçadas. Assim, é possível que qualquer processo que receba uma
mensagem responda ao emissor.
7.18.2 O User Datagram Protocol
No conjunto de protocolos TCP/IP, o User Datagram Protocol, ou UDP, provê o
mecanismo principal que os programas aplicativos utilizam para enviar datagramas a outros
programas aplicativos. O UDP fornece portas de protocolo utilizadas para fazer a distinção
entre vários programas executando em uma única máquina. Ou seja, além dos dados
147
enviados, cada mensagem UDP contém um número de porta de destino e um número de porta
de origem, permitindo que o UDP no destino entregue a mensagem ao destinatário correto e
que o destinatário envie uma resposta.
O UDP utiliza a camada de internet subjacente para transportar uma mensagem de uma
máquina a outra e fornece a mesma semântica de entrega de datagrama não-confiável, sem
conexão, que o IP. Ele não usa confirmações para certificar-se de que as mensagens chegam;
ele não ordena as mensagens que chegam, nem provê retorno para controlar a taxa em que as
informações fluem entre as máquinas. Assim, as mensagens UDP podem ser perdidas,
duplicadas ou chegar fora de ordem. Além do mais, os pacotes podem chegar mais rápido
do que o destinatário poderá processá-los.
Um programa aplicativo que usa UDP aceita a responsabilidade total por lidar com o
problema de confiabilidade. Infelizmente, os programadores de aplicação em geral ignoram
esses problemas quando projetam o software. Além do mais, como os programadores
normalmente testam o software de rede usando redes locais altamente confiáveis, com pouco
atraso, o teste pode não expor falhas em potencial. Assim, muitos programas aplicativos que
contam com UDP funcionam bem em um ambiente local, mas falham de várias maneiras
quando usados na Internet global.
7.18.3 Formato de mensagens UDP
Cada mensagem UDP é denominada datagrama do usuário. Conceitualmente, um
datagrama do usuário consiste em duas partes: um cabeçalho UDP e uma área de dados UDP.
Como mostra a Figura 7.41, o cabeçalho é dividido em quatro campos de 16 bits que
especificam a porta da qual a mensagem foi enviada, a porta para a qual a mensagem é
destinada, o tamanho da mensagem e um checksum UDP.
Os campos de PORTA DE ORIGEM e PORTA DE DESTINO contêm os números de
porta do protocolo UDP de 16 bits usados para demultiplexar datagramas entre os processos
esperando para recebê-los. A PORTA DE ORIGEM é opcional. Quando usada, ela especifica
a porta para a qual as respostas devem ser enviadas; se não for usada, ela deve ser igual a
zero.
O campo de TAMANHO contém um contador de octetos do datagrama UDP, incluindo
o cabeçalho UDP e os dados do usuário. Assim, o valor mínimo para TAMANHO é oito, o
tamanho do cabeçalho isolado.
O checksum UDP é opcional e nem precisa ser usado; um valor zero no campo
CHECKSUM significa que o checksum não foi calculado. Os projetistas decidiram tornar o
checksum opcional para permitir que as implementações operem com pouca sobrecarga de
cálculo ao usar o UDP por uma rede local altamente confiável. Porém, lembre-se de que o
IP não calcula um checksum na parte de dados de um datagrama IP. Assim, o checksum
UDP é a única maneira de garantir que os dados chegaram intactos e devem ser usados.
0
16
PORTA DE ORIGEM UDP
TAMANHO DA MENSAGEM UDP
31
PORTA DE DESTINO UDP
CHECKSUM UDP
DADOS
...
Figura 7.41 – O formato dos campos em um datagrama UDP.
Os iniciantes normalmente questionam o que acontece com as mensagens UDP para as
quais o checksum calculado é zero. Um valor calculado igual a zero é possível porque o UDP
usa o mesmo algoritmo de checksum do IP. Ele divide os dados em quantidades de 16 bits e
148
calcula o complemento a um de sua soma. De modo surpreendente, zero não é um problema
porque a aritmética de complemento a um possui duas representações para zero: todos os bits
definidos como zero ou todos os bits definidos como um. Quando o checksum calculado é
zero, o UDP usa a representação com todos os bits definidos como um.
7.18.4 Pseudocabeçalho UDP
O checksum UDP abrange mais informações que existem apenas no datagrama UDP.
Para calcular o checksum, o UDP insere um pseudocabeçalho no início do datagrama UDP,
anexa um octeto de zeros para preencher o datagrama até um múltiplo exato de 16 bits e
calcula o checksum pelo objeto inteiro. O octeto usado para preenchimento e o
pseudocabeçalho não são transmitidos com o datagrama UDP e nem são incluídos no
tamanho. Para calcular o checksum, o software primeiro armazena zero no campo
CHECKSUM, depois acumula uma soma do complemento a um de 16 bits do objeto inteiro,
incluindo o pseudocabeçalho, o cabeçalho UDP e os dados do usuário.
A finalidade de usar um pseudocabeçalho é verificar se o datagrama UDP alcançou
seu destino correto. A chave para entender o pseudocabeçalho está na observação de que o
destino correto consiste em uma máquina específica e uma porta de protocolo específica
dentro dessa máquina. O próprio cabeçalho UDP especifica apenas o número de porta do
protocolo. Assim, para verificar o destino, o UDP na máquina emissora calcula um checksum
que abrange o endereço IP de destino e também o datagrama UDP. No destino final, o UDP
verifica o checksum usando o endereço IP de destino obtido pelo cabeçalho do datagrama IP
que transportou a mensagem UDP. Se os checksums combinarem, então deve ser verdade
que o datagrama alcançou o host de destino desejado e também a porta de protocolo correta
dentro desse host.
O pseudocabeçalho usado no cálculo do checksum UDP consiste em 12 octetos de
dados arrumados como mostra a Figura 7.42. Os campos do pseudocabeçalho intitulados
ENDEREÇO IP DE ORIGEM e ENDEREÇO IP DE DESTINO contêm os endereços IP de
origem e destino que serão usados no envio da mensagem UDP. O campo PROTOCOLO
contém o código do tipo de protocolo IP (17 para UDP), e o campo rotulado com TAMANHO
UDP contém o tamanho do datagrama UDP (sem incluir o pseudocabeçalho). Para verificar
o checksum, o receptor precisa extrair esses campos do cabeçalho IP, montá-los no formato
do pseudocabeçalho e recalcular o checksum.
0
8
ZERO
16
31
ENDEREÇO IP DE ORIGEM
ENDEREÇO IP DE DESTINO
PROTOCOLO
TAMANHO UDP
Figura 7.42 – Os 12 octetos do pseudocabeçalho para o cálculo do checksum.
7.18.5 Encapsulamento e camadas de protocolos UDP
O UDP é nosso primeiro exemplo de um protocolo de transporte. No modelo em
camadas do TCP/IP, o UDP se encontra na camada acima da camada de inter-rede
(transporte). Conceitualmente, os programas aplicativos acessam o UDP, que usa o IP para
enviar e receber datagramas, como mostra a Figura 7.43.
149
Camadas conceituais
Aplicação
Datagrama do usuário (UDP)
Inter-rede (IP)
Interface de rede
Figura 7.43 – As camadas conceituais do UDP entre programas aplicativos e o IP.
A disposição em camadas do UDP acima do IP significa que uma mensagem UDP
completa, incluindo o cabeçalho e dados UDP, é encapsulada em um datagrama IP enquanto
trafega por uma inter-rede, como mostra a Figura 7.44.
Figura 7.44 – Um datagrama UDP encapsulado em um datagrama IP.
Para os protocolos que examinamos, o encapsulamento significa que o UDP insere um
cabeçalho aos dados que um usuário envia e o passa ao IP. A camada IP insere um cabeçalho
ao que recebe do UDP. Finalmente, a camada de interface de rede embute o datagrama em
um frame antes de enviá-lo de uma máquina para outra. O formato do frame depende da
tecnologia da rede subjacente. Normalmente, os frames de rede incluem um cabeçalho
adicional.
Na entrada, um pacote chega na camada mais baixa do software de rede e inicia sua
ascensão por camadas cada vez mais altas. Cada camada remove um cabeçalho antes de
passar a mensagem adiante, de modo que, quando o nível mais alto passa os dados para o
processo receptor, todos os cabeçalhos foram removidos. Assim, o cabeçalho mais externo
corresponde à camada de protocolo mais baixa, enquanto o cabeçalho mais interno
corresponde à camada de protocolo mais alta. Ao considerar como os cabeçalhos são
inseridos e removidos, é importante ter em mente o princípio das camadas. Em particular,
observe que o princípio de camadas se aplica ao UDP, de modo que o datagrama UDP
recebido do IP na máquina de destino é idêntico ao datagrama que o UDP passou ao IP na
máquina de origem. Além disso, os dados que o UDP entrega a um processo do usuário na
máquina receptora serão exatamente os dados que um processo do usuário passou ao UDP
na máquina emissora.
A divisão de tarefas entre as diversas camadas de protocolo é rígida e clara. A camada
IP é responsável apenas por transferir dados entre um par de hosts em uma inter-rede,
enquanto a camada UDP é responsável apenas por diferenciar entre diversas origens ou
destinos dentro de um host.
150
Assim, somente o cabeçalho IP identifica os hosts de origem e destino; somente a
camada UDP identifica as portas de origem ou destino dentro de um host.
7.18.6 Camadas e o cálculo de checksum do UDP
Os leitores atentos terão notado uma aparente contradição entre as regras de camadas
e o cálculo do checksum UDP. Lembre-se de que o checksum UDP inclui um
pseudocabeçalho que possui campos para os endereços IP de origem e destino. Pode-se
argumentar que o endereço IP de destino precisa ser conhecido pelo usuário no envio de um
datagrama UDP, e o usuário precisa passá-lo para a camada UDP. Assim, a camada UDP
pode obter o endereço IP de destino sem interagir com o cabeçalho IP. Porém, o endereço
IP de origem depende da rota que o IP escolhe para o datagrama, pois o endereço IP de
origem identifica a interface de rede sobre a qual o datagrama é transmitido. Assim, a menos
que interaja com a camada IP, o UDP não pode saber o endereço de origem IP.
Consideremos que o UDP peça à camada IP para calcular os endereços IP de origem e
(possivelmente) destino, usa-os para construir um pseudocabeçalho, calcula o checksum,
descarta o pseudocabeçalho e depois passa o datagrama UDP ao IP para transmissão. Uma
técnica alternativa que produz maior eficiência faz com que a camada UDP encapsule o
datagrama UDP em um datagrama IP, obtenha o endereço de origem do IP, armazene os
endereços de origem e destino nos campos apropriados do cabeçalho do datagrama, calcule
o checksum UDP e depois passe o datagrama IP à camada IP, que só precisa preencher os
campos restantes do cabeçalho IP.
A forte interação entre UDP e IP viola nossa premissa básica de que as camadas
refletem a separação da funcionalidade? Sim. O UDP tem sido bastante integrado ao
protocolo IP. Ele é claramente um compromisso de separação pura, feita por motivos
totalmente práticos. Desejamos passar por cima da violação de camadas porque é impossível
identificar totalmente um programa aplicativo de destino sem especificar a máquina de
destino, e queremos tornar eficiente o mapeamento entre os endereços usados pelo UDP e
aqueles usados pelo IP.
7.18.7 Multiplexação, demultiplexação e portas UDP
Vimos anteriormente que o software das camadas de uma hierarquia de protocolos
precisa multiplexar ou demultiplexar entre vários objetos na próxima camada. O software
UDP oferece outro exemplo de multiplexação e demultiplexação. Ele aceita datagramas
UDP de muitos programas aplicativos e os passa para o IP para transmissão, e aceita a
chegada de datagramas UDP do IP e passa cada um ao programa aplicativo apropriado.
Conceitualmente, toda a multiplexação e demultiplexação entre o UDP e os programas
aplicativos ocorre por meio do mecanismo de porta. Na prática, cada programa aplicativo
precisa negociar com o sistema operacional para obter uma porta de protocolo e um número
de porta associado antes de poder enviar um datagrama UDP. Quando a porta tiver sido
atribuída, qualquer datagrama que o programa aplicativo enviar por ela terá esse número de
porta em seu campo PORTA DE ORIGEM UDP.
Ao processar a entrada, o UDP aceita datagramas que chegam do IP e demultiplexa
com base na porta de destino UDP, como mostra a Figura 7.45.
O modo mais fácil de pensar em uma porta UDP é como uma fila. Na maioria das
implementações, quando um programa aplicativo negocia com o sistema operacional para
usar determinada porta, o sistema operacional cria uma fila interna que pode manter as
mensagens que chegam. Normalmente, a aplicação pode especificar ou alterar o tamanho da
fila. Quando o UDP recebe um datagrama, ele verifica se o número da porta de destino
151
combina com uma das portas atualmente em uso. Se não, ele envia uma mensagem de erro
ICMP de porta inalcançável (port unreacheable) e descarta o datagrama. Se for achada uma
combinação, o UDP enfileira o novo datagrama na porta em que o programa aplicativo pode
acessá-lo. Naturalmente, haverá um erro se a porta estiver cheia, e o UDP descarta o
datagrama que chega.
Figura 7.45 – Exemplo de demultiplexação de uma camada acima do IP.
7.18.8 Números de porta UDP reservados e disponíveis
Como os números de porta de protocolo devem ser atribuídos? O problema é
importante porque dois computadores precisam combinar a respeito dos números de porta
antes que possam interoperar. Por exemplo, quando o computador A precisa obter um
arquivo do computador B, ele precisa saber qual porta o programa de transferência de
arquivos no computador B utiliza. Existem duas técnicas fundamentais para a atribuição de
porta. A primeira técnica usa uma autoridade central. Todos concordam em permitir que
uma autoridade central atribua números de porta conforme a necessidade e publique a lista
de todas as atribuições. Depois, todo o software é criado de acordo com a lista. Essa técnica
às vezes é chamada de atribuição universal, e as atribuições de porta especificadas pela
autoridade são chamadas atribuições de porta bem conhecidas (well-known port
assignments).
A segunda técnica para atribuição de porta utiliza o vínculo dinâmico. Na técnica de
vínculo dinâmico, as portas não são conhecidas globalmente. Em vez disso, sempre que um
programa precisa de uma porta, o software de rede atribui uma. Para descobrir a atribuição
de porta em outro computador, é preciso enviar uma requisição que pergunte a atribuição de
porta atual (por exemplo, “que porta o serviço de transferência de arquivos está usando?”).
A máquina de destino responde dando o número de porta correto a usar.
Os projetistas do TCP/IP adotaram uma técnica híbrida que atribui alguns números de
porta a priori, mas deixa muitos disponíveis para os sites locais ou os programas aplicativos
atribuírem dinamicamente. Os números de porta atribuídos começam com valores baixos e
se estendem para cima, deixando valores inteiros grandes disponíveis para atribuição
dinâmica. A Tabela 7.11 lista alguns dos números de porta UDP atualmente atribuídos. A
segunda coluna contém palavras-chave padrão da Internet, enquanto a terceira contém
palavras-chave usadas na maioria dos sistemas UNIX.
152
Decimal
Palavra-Chave
0
7
9
11
13
15
17
19
37
42
43
53
67
68
69
88
111
123
161
162
512
513
514
525
–
ECHO
DISCARD
USERS
DAYTIME
–
QUOTE
CHARGEN
TIME
NAMESERVER
NICNAME
DOMAIN
BOOTPS
BOOTPC
TFTP
KERBEROS
SUNRPC
NTC
–
–
–
–
–
–
Palavra-Chave do
Unix
–
echo
discard
systat
daytime
netstat
qotd
chargen
time
name
whois
nameserver
bootps
bootpc
tftp
kerberos
sunrpc
ntp
snmp
snmp-trap
biff
who
syslog
timed
Descrição
Reservado
Eco
Descarte
Usuários ativos
Hora do dia
Programa de status da rede
Citação do dia
Gerador de caracteres
Hora
Servidor de nome de host
Quem é
Domain Name Server
Servidor BOOTP ou DHCP
Cliente BOOTP ou DHCP
Trivial File Transfer
Serviço de segurança Kerberos
Sun Remote Procedure Call
Network Time Protocol
Simple Network Management Protocol
Traps SNMP
Comsat do UNIX
Daemon rwho do UNIX
Log do sistema
Daemon de hora
Tabela 7.11 – Exemplos de portas UDP atualmente atribuídas.
7.19 TCP
Anteriormente foi explorado o serviço de entrega de pacote sem conexão não-confiável que
forma a base para toda a comunicação da Internet e o protocolo IP que a define. Esta seção
apresenta o segundo serviço em nível de transporte mais importante, com entrega de fluxo
confiável. É o Transmission Control Protocol (TCP) que o define. Veremos que o TCP
acrescenta funcionalidade substancial aos protocolos já discutidos, mas que sua implementação
também é substancialmente mais complexa.
Embora o TCP seja apresentado aqui como parte do conjunto de protocolos TCP/IP da
Internet, ele é um protocolo independente, de uso geral, que pode ser adaptado para uso com
outros sistemas de entrega. Por exemplo, como o TCP faz muito poucas suposições a respeito da
rede subjacente, é possível usá-lo por uma única rede, como uma Ethernet, e também pela Internet
global.
7.19.1 A necessidade de entrega de fluxo
No nível mais baixo, as redes de comunicação por computador provêem entrega de
pacote não-confiável. Os pacotes podem ser perdidos ou destruídos quando os erros de
transmissão interferem com os dados, quando o hardware de rede falha ou quando as redes
se tornam muito carregadas para acomodar a carga apresentada. Os sistemas de comutação
de pacotes mudam de rotas dinamicamente, entregam pacotes fora de ordem, entregam-nos
após um atraso substancial ou entregam duplicatas. Além do mais, as tecnologias de rede
153
básicas podem ditar um tamanho de pacote ideal ou impor outras restrições necessárias para
alcançar taxas de transferência eficientes.
No nível mais alto, os programas aplicativos normalmente precisam enviar grandes
volumes de dados de um computador para outro. O uso de um sistema de remessa nãoconfiável sem conexão para grandes transferências de volume se torna tedioso e incômodo,
e isso exige que os programadores montem detecção e recuperação de erro em cada programa
aplicativo. Por ser difícil projetar, entender ou modificar o software que oferece a
confiabilidade corretamente, poucos programadores de aplicação têm a base técnica
necessária, como conseqüência, um dos objetivos da pesquisa do protocolo de rede tem sido
encontrar soluções de uso geral para os problemas de fornecer entrega de fluxo confiável,
permitindo que os especialistas montem uma única instância do software de protocolo de
fluxo que todos os programas aplicativos utilizam. Ter um único protocolo de uso geral ajuda
a isolar programas aplicativos dos detalhes das redes, e possibilita a definição de uma
interface uniforme para o serviço de transferência de fluxo.
7.19.2 Propriedades do serviço de entrega confiável
A interface entre programas aplicativos e o serviço de entrega confiável do TCP/IP
pode ser caracterizada por cinco elementos:
 Orientação de fluxo. Quando dois programas aplicativos transferem grandes volumes
de dados, os dados são vistos como um fluxo de bits, divididos em octetos ou bytes.
O serviço de entrega de fluxo na máquina de destino passa para o receptor exatamente
a mesma seqüência de octetos que o emissor passa para ele na máquina de origem.
 Conexão de circuito virtual. Criar uma transferência de fluxo é semelhante a fazer
uma ligação telefônica. Antes que a transferência possa iniciar, os programas
aplicativos, emissor e receptor, interagem com seus respectivos sistemas operacionais,
informando-lhes que desejam uma transferência de fluxo. Conceitualmente, uma
aplicação faz uma “chamada” que precisa ser aceita pela outra. Os módulos de
protocolo nos dois sistemas operacionais se comunicam enviando mensagens pela
inter-rede básica, verificando se a transferência está autorizada e se os dois lados estão
prontos. Quando todos os detalhes tiverem sido definidos, os módulos de protocolo
informam aos programas aplicativos que uma conexão foi estabelecida e que a
transferência pode ser iniciada. Durante a transferência, o protocolo nas duas
máquinas continua a se comunicar para verificar se os dados são recebidos
corretamente. Se a comunicação falhar por qualquer motivo (por exemplo, porque o
hardware de rede ao longo do caminho entre as máquinas falhar), as duas máquinas
detectam a falha e a informam aos programas aplicativos apropriados. Usamos o
termo circuito virtual para descrever essas conexões, pois embora os programas
aplicativos vejam a conexão como um circuito de hardware dedicado, a
confiabilidade é uma ilusão fornecida pelo serviço de entrega de fluxo.
 Transferência em buffer. Os programas aplicativos enviam um fluxo de dados pelo
circuito virtual repetidamente, passando octetos de dados ao protocolo. Ao transferir
dados, uma aplicação usa qualquer tamanho que achar conveniente, que pode ser a
partir de um único octeto. No extremo receptor, o protocolo entrega octetos do fluxo
de dados exatamente na mesma ordem em que foram enviados, tornando-os
disponíveis ao programa aplicativo receptor assim que tiverem sido recebidos e
verificados. O protocolo é livre para dividir o fluxo em pacotes independentes das
partes que o programa aplicativo transfere. Para tornar a transferência mais eficiente
e minimizar o tráfego da rede, as implementações normalmente coletam dados
154
suficientes de um fluxo a fim de preencher um datagrama razoavelmente grande antes
de transmiti-lo por uma internet. Assim, mesmo que o programa aplicativo gere o
fluxo de um octeto de cada vez, a transferência por uma inter-rede pode ser muito
eficiente. De modo semelhante, se o programa aplicativo escolher gerar blocos de
dados extremamente grandes, o protocolo pode escolher dividir cada bloco em partes
menores para a transmissão.
Para as aplicações em que os dados devem ser entregues sem esperar preencher um
buffer, o serviço de fluxo oferece um mecanismo push que as aplicações usam para forçar a
transferência imediata. No lado emissor, um push força o protocolo a transferir todos os
dados que foram gerados sem esperar para preencher um buffer. Ao alcançar o lado receptor,
o push faz com que o TCP torne os dados disponíveis à aplicação sem atraso. Porém, o leitor
deverá observar que a função push só garante que todos os dados serão transferidos; ele não
oferece limites de registro. Assim, mesmo que a remessa seja forçada, o protocolo pode
decidir dividir o fluxo de maneiras inesperadas.
 Fluxo não-estruturado. É importante entender que o serviço de fluxo TCP/IP não
honra fluxos de dados estruturados. Por exemplo, não existe um meio de uma
aplicação de folha de pagamento fazer com que o serviço de fluxo marque os limites
entre registros de funcionários ou identifique o conteúdo do fluxo como sendo dados
de folha de pagamento. Os programas aplicativos que utilizam o serviço de fluxo
precisam entender o conteúdo de fluxo e combinar com o formato do fluxo antes que
iniciem uma conexão.
 Conexão full duplex. As conexões fornecidas pelo serviço de fluxo TCP/IP permitem
a transferência simultânea nas duas direções. Essas conexões são chamadas de full
duplex. Do ponto de vista de um processo de aplicação, uma conexão full duplex
consiste em dois fluxos independentes, indo em sentidos opostos, sem qualquer
interação aparente. O serviço de fluxo permite que um processo de aplicação termine
o fluxo em um sentido enquanto os dados continuam a fluir no outro sentido, tornando
a conexão half duplex. A vantagem de uma conexão full duplex é que o protocolo
básico pode enviar informações de controle para um fluxo de volta para a origem em
datagramas transportando dados na direção oposta. Esse piggybacking reduz o
tráfego da rede.
7.19.3 Fornecendo confiabilidade
Dissemos que o serviço de entrega de fluxo confiável garante entregar um fluxo de
dados enviados de uma máquina para outra sem duplicação ou perda de dados. A questão é:
“como o protocolo pode oferecer transferência confiável se o sistema de comunicação
subjacente oferece apenas a remessa de pacotes não-confiável?” A resposta é complicada,
mas a maioria dos protocolos confiáveis usa uma única técnica fundamental, conhecida como
confirmação positiva com retransmissão
(Positive Acknowledgement with
Retransmition – PAR). A técnica requer que um destinatário se comunique com a origem,
enviando de volta uma mensagem de confirmação (ACK) enquanto recebe dados. O emissor
mantém um registro de cada pacote que envia e espera uma confirmação antes de enviar o
próximo pacote. O emissor também inicia um timer quando envia um pacote, e retransmite
o pacote se o timer expirar antes que a confirmação chegue.
A Figura 7.46 mostra como o protocolo de confirmação positiva mais simples transfere
dados.
155
Figura 7.46 – Um protocolo usando confirmação positiva com retransmissão.
Na figura, os eventos no emissor e no receptor são mostrados à esquerda e à direita
respectivamente. Cada linha diagonal atravessando o meio mostra a transferência de uma
mensagem pela rede.
A Figura 7.47 utiliza o mesmo diagrama de formato da Figura 7.46 para mostrar o que
acontece quando um pacote é perdido ou adulterado. O emissor inicia um timer depois de
transmitir um pacote. Quando o timer expira, o emissor assume que o pacote foi perdido e o
retransmite.
O problema final de confiabilidade surge quando um sistema de remessa de pacotes
subjacente duplica pacotes. As duplicatas também surgem quando as redes experimentam
altos atrasos, que causam retransmissão prematura. A solução da duplicação exige
pensamento cuidadoso, pois pacotes e confirmações podem ser duplicados. Normalmente,
os protocolos confiáveis detectam pacotes duplicados atribuindo um número de sequência a
cada pacote e exigindo que o receptor se lembre de quais números de sequência ele recebeu.
Para evitar a confusão causada por confirmações adiadas ou duplicadas, os protocolos de
confirmação positiva enviam números de sequência em confirmações, de modo que o
receptor possa associar corretamente confirmações com pacotes.
Figura 7.47 – Timeout e retransmissão que ocorre quando um pacote é perdido.
156
7.19.4 A idéia por trás das janelas deslizantes
Antes de examinar o serviço de fluxo TCP, precisamos explorar um conceito adicional
que está por trás da transmissão de fluxo. O conceito, conhecido como janela deslizante,
torna a transmissão de fluxo eficiente. Para entender a motivação para as janelas deslizantes,
lembre-se da sequência de eventos que a Figura 7.46 representa. Para conseguir
confiabilidade, o emissor transmite um pacote e depois espera por uma confirmação antes de
transmitir outro. Como mostra a Figura 7.46, os dados só fluem entre as máquinas em uma
direção, mesmo que a rede seja capaz de comunicação simultânea nas duas direções. A rede
permanecerá completamente ociosa durante os momentos em que as máquinas atrasam as
respostas (por exemplo, enquanto as máquinas calculam rotas ou somas de verificação). Se
imaginarmos uma rede com altos atrasos de transmissão, o problema se torna claro. Um
protocolo de confirmação positiva simples desperdiça uma quantidade substancial de largura
de banda de rede, pois precisa adiar o envio de um novo pacote até que receba uma
confirmação para o pacote anterior.
A técnica de janela deslizante é uma forma mais complexa de confirmação positiva e
retransmissão do que o método simples discutido anteriormente. Os protocolos de janela
deslizante utilizam melhor a largura de banda da rede, pois permitem que o emissor transmita
vários pacotes antes de esperar uma confirmação. O modo mais fácil de ver a operação da
janela deslizante é pensar em uma sequência de pacotes a ser transmitido conforme mostrado
na Figura 7.48. O protocolo coloca uma janela pequena, de tamanho fixo, na sequência e
transmite todos os pacotes que se encontram dentro da janela.
Figura 7.48 – Um protocolo de janela deslizante com oito pacotes na janela.
Dizemos que um pacote é não-confirmado se tiver sido transmitido, mas nenhuma
confirmação tiver sido recebida. Tecnicamente, o número de pacotes que podem ser
confirmados em determinado momento é restringido pelo tamanho da janela, que é limitado
a um número pequeno e fixo. Por exemplo, em um protocolo de janela deslizante com
tamanho de janela 8, o emissor tem permissão para transmitir 8 pacotes antes de receber uma
confirmação.
Como mostra a Figura 7.48, quando o emissor recebe uma confirmação para o primeiro
pacote dentro da janela, ele “desliza” a janela e envia o próximo pacote. A janela continua a
deslizar enquanto as confirmações são recebidas.
O desempenho dos protocolos de janela deslizante depende do tamanho de janela e da
velocidade em que a rede aceita pacotes. A Figura 7.49 mostra um exemplo da operação de
157
um protocolo de janela deslizante ao enviar três pacotes. Observe que o emissor transmite
todos os três pacotes antes de receber quaisquer confirmações.
Com um tamanho de janela igual a 1, um protocolo de janela deslizante é exatamente
o mesmo que nosso protocolo de confirmação positiva simples. Aumentando o tamanho da
janela, é possível eliminar completamente o tempo ocioso da rede. Ou seja, no estado
constante, o emissor pode transmitir pacotes tão rápido quanto a rede pode transferi-los. O
ponto principal é o seguinte: como um protocolo de janela deslizante bem ajustado mantém
a rede completamente saturada com pacotes, ele obtém um throughput substancialmente
maior que um protocolo de confirmação positiva simples.
Conceitualmente, um protocolo de janela deslizante sempre se lembra de quais pacotes
foram confirmados e mantém um timer separado para cada pacote não-confirmado. Se um
pacote é perdido, o timer expira e o emissor retransmite esse pacote. Quando o emissor
desliza sua janela, ele ultrapassa todos os pacotes confirmados. No extremo receptor, o
protocolo mantém uma janela semelhante, aceitando e confirmando pacotes à medida que
eles chegam. Assim, a janela particiona a sequência de pacotes em três conjuntos: os pacotes
à esquerda da janela foram transmitidos, recebidos e confirmados com sucesso; e os pacotes
que se encontram na janela estão sendo transmitidos. O pacote de número mais baixo na
janela é o primeiro pacote na sequência que não foi confirmado.
Figura 7.49 – Um exemplo de três pacotes transmitidos usando a janela deslizante.
7.19.5 O Transmission Control Protocol
Agora que entendemos o princípio das janelas deslizantes, podemos examinar o serviço
de fluxo confiável fornecido pelo conjunto de protocolos TCP/IP da Internet. O serviço é
definido pelo Transmission Control Protocol, ou TCP. O serviço de fluxo confiável é tão
significativo que o conjunto de protocolos inteiro é denominado TCP/IP. É importante
entender que o TCP é um protocolo de comunicação, e não uma parte do software.
A diferença entre um protocolo e o software que o implementa é semelhante à diferença
entre a definição de uma linguagem de programação e um compilador. Como no mundo das
linguagens de programação, a distinção entre definição e implementação às vezes se torna
confusa. As pessoas encontram o TCP com muito mais freqüência do que encontram a
especificação de protocolo, de modo que é natural pensar em uma implementação em
particular como o padrão. Apesar disso, o leitor deve tentar distinguir entre os dois.
Exatamente o que o TCP oferece? TCP é complexo, de modo que não existe uma
resposta simples. O protocolo especifica o formato dos dados e confirma que dois
158
computadores trocam dados para conseguir uma transferência confiável, além dos
procedimentos que os computadores utilizam para garantir que os dados chegam
corretamente. Ele especifica como o TCP distingue entre vários destinos em determinada
máquina, e como as máquinas em comunicação se recuperam de erros como pacotes perdidos
ou duplicados. O protocolo também especifica como os dois computadores iniciam uma
transferência de fluxo TCP e como concordam quando ela termina.
Também é importante entender o que o protocolo não inclui. Embora a especificação
TCP descreva como os programas aplicativos utilizam TCP em termos gerais, ele não dita os
detalhes da interface entre um programa aplicativo e o TCP. Ou seja, a documentação do
protocolo só discute as operações que o TCP fornece; ele não especifica os procedimentos
exatos que os programas aplicativos invocam para acessar essas operações. O motivo para
deixar a interface do programa aplicativo não especificada é a flexibilidade. Em particular,
como os programadores normalmente implementam TCP no sistema operacional do
computador, eles precisam empregar qualquer interface que o sistema operacional ofereça.
Permitir a flexibilidade do implementador torna possível ter uma única especificação para
TCP que pode ser usada para montar software para uma série de máquinas.
Como o TCP assume pouco a respeito do sistema de comunicação subjacente, o TCP
pode ser usado com diversos sistemas de remessa de pacote. Em particular, por não exigir
que o sistema subjacente seja confiável ou rápido, o TCP pode rodar sobre uma série de
mecanismos de hardware, como a linha telefônica discada, uma rede local, uma rede de fibra
óptica de alta velocidade, uma conexão por satélite ou uma conexão sem fio com ruído, em
que muitos pacotes são perdidos. A grande variedade de sistemas de entrega que o TCP pode
usar é um de seus pontos fortes.
7.19.6 Portas, conexões e extremidades
Assim como o User Datagram Protocol (UDP) apresentado na seção 7.18, o TCP
reside acima do IP no esquema de camadas do protocolo. A Figura 7.50 mostra a organização
conceitual. O TCP permite que vários programas aplicativos em determinada máquina se
comuniquem simultaneamente, e demultiplexa o tráfego TCP que chega entre os programas
aplicativos. Assim como o User Datagram Protocol, o TCP usa os números de porta de
protocolo para identificar o destino final dentro de uma máquina. Cada porta recebe um
pequeno inteiro usado para identificá-la.
Camadas conceituais
Aplicação
Fluxo confiável (TCP)
Datagrama do usuário (UDP)
Inter-rede (IP)
Interface de rede
Figura 7.50 – A disposição conceitual em camadas do UDP e TCP acima do IP.
Quando discutimos sobre as portas UDP, dissemos para pensar em cada porta como
uma fila na qual o protocolo coloca os datagramas que chegam. As portas TCP são muito
mais complexas, pois determinado número de porta não corresponde a um único objeto. Em
vez disso, o TCP foi montado sobre a abstração da conexão, em que os objetos a serem
identificados são conexões de circuito virtual, e não portas individuais. É fundamental
entender que o TCP usa a noção de conexões, pois ajuda a explicar o significado e o uso dos
159
números de porta TCP. O TCP usa a conexão, e não a porta do protocolo, como sua abstração
fundamental; as conexões são identificadas por um par de extremidades.
Quais são exatamente as “extremidades” de uma conexão? Dissemos que uma conexão
consiste em um circuito virtual entre dois programas aplicativos, de modo que pode ser
natural considerar que um programa aplicativo serve como “extremidade” de conexão, mas
não é. Em vez disso, o TCP define uma extremidade como sendo um par de inteiros (host,
porta), em que host é o endereço IP para um host e porta é uma porta TCP nesse host. Por
exemplo, a extremidade (128.10.2.3, 25) especifica a porta TCP 25 na máquina com endereço
IP 128.10.2.3.
Agora que definimos as extremidades, será fácil entender as conexões. Lembre-se de
que uma conexão é definida por suas duas extremidades. Assim, se houver uma conexão da
máquina (18.26.0.36) no MIT com a máquina (128.10.2.3) na Purdue University, ela pode
ser definida pelas extremidades:
(18.26.0.36, 1069) e (128.10.2.3, 25).
Nesse meio tempo, outra conexão poderia estar em andamento da máquina (128.9.0.32)
no Information Sciences Institute com a mesma máquina em Purdue, identificada por suas
extremidades:
(128.9.0.32, 1184) e (128.10.2.3, 53).
Até aqui, nossos exemplos de conexões foram simples, pois as portas usadas em todas
as extremidades foram exclusivas. Porém, a abstração da conexão permite que várias
conexões compartilhem uma extremidade. Por exemplo, poderemos acrescentar outra
conexão às duas listadas anteriormente, da máquina (128.2.254.139) na CMU até a máquina
em Purdue:
(128.2.254.139, 1184) e (128.10.2.3, 53).
Pode parecer estranho que duas conexões possam usar a porta TCP 53 na máquina
128.10.2.3 simultaneamente, mas não existe ambiguidade. Como o TCP associa as
mensagens que chegam a uma conexão, em vez de uma porta de protocolo, ele usa as duas
extremidades para identificar a conexão apropriada. A ideia importante a lembrar é: como o
TCP identifica uma conexão por um par de extremidades, determinado número de porta TCP
pode ser compartilhado por várias conexões na mesma máquina.
Do ponto de vista de um programador, a abstração da conexão é significativa. Isso
significa que um programador pode criar um programa que ofereça serviço concorrente a
várias conexões simultaneamente, sem exigir os números de porta locais para cada conexão.
Por exemplo, a maioria dos sistemas fornece acesso simultâneo ao seu serviço de correio
eletrônico, permitindo que vários computadores enviem correio eletrônico simultaneamente.
Como o programa que aceita o correio que chega usa TCP para se comunicar, ele só precisa
usar uma porta TCP local, embora permita que várias conexões prossigam simultaneamente.
7.19.7 Aberturas passivas e ativas
Diferente do UDP, o TCP é um protocolo orientado a conexão, que exige que as duas
extremidades concordem em participar. Ou seja, antes que o tráfego TCP possa passar por
uma rede, os programas aplicativos nas duas extremidades da conexão precisam combinar
que a conexão é desejada. Para isso, o programa aplicativo em uma extremidade realiza uma
função de abertura passiva, contatando seu sistema operacional e indicando que ele aceitará
160
uma conexão que chega. Nesse momento, o sistema operacional atribui um número de porta
TCP para sua extremidade da conexão. O programa aplicativo na outra extremidade precisa
então contatar seu sistema operacional usando uma requisição de abertura ativa para
estabelecer uma conexão. Os dois módulos de TCP se comunicam para estabelecer e
verificar uma conexão. Quando uma conexão tiver sido criada, os programas aplicativos
podem começar a passar dados; os módulos de TCP em cada extremidade trocam mensagens
que garantem a entrega confiável. Retomaremos aos detalhes do estabelecimento de
conexões depois de examinar o formato da mensagem TCP.
7.19.8 Segmentos, fluxos e números de sequência
O TCP vê o fluxo de dados como uma sequência de octetos ou bytes que ele divide em
segmentos para transmissão. Normalmente, cada segmento trafega por uma inter-rede
subjacente em um único datagrama IP.
O TCP usa um mecanismo especializado de janela deslizante para solucionar dois
problemas importantes: transmissão eficiente e controle de fluxo. Assim como o protocolo
de janela deslizante descrito anteriormente, o mecanismo de janela TCP possibilita o envio
de vários segmentos antes que uma confirmação chegue. Isso aumenta o throughput total,
pois mantém a rede ocupada. O formato TCP de um protocolo de janela deslizante também
soluciona o problema de controle de fluxo de fim-a-fim, permitindo que o receptor restrinja
a transmissão até que tenha espaço de buffer suficiente para acomodar mais dados.
O mecanismo de janela deslizante do TCP opera no nível de octeto, e não no nível de
segmento ou pacote. Os octetos do fluxo de dados são numerados sequencialmente, e um
emissor mantém três ponteiros associados a cada conexão. Os ponteiros definem uma janela
deslizante, conforme a Figura 7.51 ilustra. O primeiro ponteiro marca a esquerda da janela
deslizante, separando os octetos que foram enviados e confirmados daqueles ainda a serem
confirmados. Um segundo ponteiro marca a direita da janela deslizante e define o octeto
mais alto na sequência que pode ser enviado antes que mais confirmações sejam recebidas.
O terceiro ponteiro marca o limite dentro da janela que separa aqueles octetos que já foram
enviados dos octetos que não foram enviados. O protocolo envia todos os octetos na janela
sem atraso, de modo que o limite dentro da janela normalmente se move rapidamente da
esquerda para a direita.
Figura 7.51 – Um exemplo da janela deslizante do TCP.
Descrevemos como a janela TCP do emissor se desliza e mencionamos que o receptor
precisa manter uma janela semelhante para unir o fluxo novamente. Porém, é importante
entender que, como as conexões TCP são full duplex, duas transferências prosseguem
simultaneamente em cima de cada conexão, uma em cada direção. Consideramos as
transferências completamente independentes, pois a qualquer momento os dados podem fluir
pela conexão em uma direção, ou em ambas as direções. Assim, o TCP em cada extremidade
mantém duas janelas por conexão (com um total de quatro), uma desliza pelo fluxo de dados
sendo enviado, e a outra desliza enquanto os dados são recebidos.
161
7.19.9 Tamanho de janela variável e controle de fluxo
Uma diferença entre o protocolo de janela deslizante do TCP e o protocolo de janela
deslizante simplificado, apresentado anteriormente, ocorre porque o TCP permite que o
tamanho da janela varie com o tempo. Cada confirmação, que especifica quantos octetos
foram recebidos, contém um anúncio de janela que especifica quantos octetos adicionais de
dados o receptor está preparado para aceitar. Pensamos no anúncio da janela como
especificando o tamanho de buffer atual do receptor. Em resposta a um anúncio de janela
maior, o emissor aumenta o tamanho de sua janela deslizante e prossegue para enviar octetos
que não foram confirmados. Em resposta a um anúncio de janela diminuída, o emissor
diminui o tamanho de sua janela e para de enviar octetos além do limite. O TCP não pode
contradizer os anúncios anteriores, encurtando a janela além das posições anteriormente
aceitáveis no fluxo de octetos. Em vez disso, anúncios menores acompanham confirmações,
de modo que o tamanho da janela muda na hora em que ela desliza para a frente.
A vantagem de usar uma janela de tamanho variável é que ela oferece controle de fluxo
e também transferência confiável. Para evitar receber mais dados do que pode armazenar, o
receptor envia anúncios de janela menores enquanto seu buffer se enche. No caso extremo,
o receptor anuncia um tamanho de janela zero para interromper todas as transmissões. Mais
adiante, quando o espaço do buffer se tomar disponível, o receptor anunciará um tamanho de
janela diferente de zero para disparar o fluxo de dados novamente1.
É essencial ter um mecanismo para controle de fluxo em um ambiente no qual as
máquinas de várias velocidades e tamanhos se comunicam por redes e roteadores de diversas
velocidades e capacidades. Existem dois problemas independentes. Primeiro, os protocolos
precisam oferecer controle de fluxo de fim-a-fim entre a origem e o destino final. Por
exemplo, quando um PDA de mão se comunica com um PC rápido, o PDA precisa regular o
fluxo de dados, ou o protocolo ficaria rapidamente defasado. Assim, o TCP precisa
implementar o controle de fluxo de fim-a-fim para garantir a entrega confiável. Em segundo
lugar, é necessário haver um mecanismo que permita que os sistemas intermediários (ou seja,
roteadores) controlem uma origem que envia mais tráfego do que a máquina pode tolerar.
Quando as máquinas intermediárias se tornam sobrecarregadas, a condição é chamada
de congestionamento, e os mecanismos para solucionar o problema são denominados
mecanismos de controle de congestionamento. O TCP usa seu esquema de janela deslizante
para solucionar o problema de controle de fluxo de fim-a-fim. Discutiremos o controle de
congestionamento mais tarde, mas deve ser observado que um protocolo bem projetado pode
detectar e recuperar-se do congestionamento, enquanto um protocolo mal projetado tornará
o congestionamento pior. Em particular, um esquema de retransmissão cuidadosamente
escolhido pode ajudar a evitar o congestionamento, mas um esquema mal escolhido pode
exacerbá-lo retransmitindo agressivamente.
7.19.10 Formato do segmento TCP
A unidade de transferência entre o TCP nas duas máquinas é chamada de segmento.
Os segmentos são trocados para se estabelecer conexões, transferir dados, enviar
confirmações, anunciar tamanhos de janela e fechar conexões. Como o TCP utiliza o
piggybacking, uma confirmação trafegando da máquina A para a máquina B pode trafegar
1
Existem duas exceções para a transmissão quando o tamanho da janela for zero. Primeiro, um emissor tem permissão para
transmitir um segmento com o bit urgente marcado para informar ao receptor que existem dados urgentes à disposição.
Segundo, para evitar um impasse em potencial, que pode surgir se um anúncio diferente de zero for perdido após o tamanho
da janela alcançar zero, o emissor sonda uma janela de tamanho zero periodicamente.
162
nos mesmos segmentos dos dados atravessando da máquina A para a máquina B, embora a
confirmação se refira aos dados enviados de B para A1. A Figura 7.52 mostra o formato do
segmento TCP.
0
4
HLEN
10
16
24
31
PORTA DE ORIGEM
PORTA DE DESTINO
NÚMERO DE CONFIRMAÇÃO
RESERVADO BITS CÓDIGO
JANELA
CHECKSUM
PONTEIRO DE URGENTE
OPÇÕES (SE HOUVER)
PREENCHIMENTO
DADOS
...
Figura 7.52 – O formato de um segmento TCP com um cabeçalho TCP seguido por dados.
Cada segmento é dividido em duas partes, um cabeçalho seguido por dados. O
cabeçalho, conhecido como cabeçalho TCP, transporta a identificação esperada e
informações de controle. Os campos PORTA DE ORIGEM e PORTA DE DESTINO contêm
os números de porta TCP que identificam os programas aplicativos nas extremidades da
conexão. O campo NÚMERO DE SEQÜÊNCIA identifica a posição no fluxo de bytes do
emissor dos dados no segmento. O campo NÚMERO DE CONFIRMAÇÃO identifica o
número do octeto que a origem espera receber em seguida. Observe que o número de
seqüência refere-se ao fluxo que segue na mesma direção do segmento, enquanto o número
de confirmação refere-se ao fluxo que segue na direção oposta do segmento.
O campo HLEN2 contém um inteiro que especifica o tamanho do cabeçalho do
segmento medido em múltiplos de 32 bits. Ele é necessário porque o campo OPÇÕES varia
em tamanho, dependendo de quais opções foram incluídas. Assim, o tamanho do cabeçalho
TCP varia, dependendo das opções selecionadas. O campo de 6 bits marcado como
RESERVADO é reservado para uso futuro.
Alguns segmentos transportam apenas uma confirmação, enquanto outros transportam
dados. Outros transportam requisições para estabelecer ou fechar uma conexão. O TCP
utiliza um campo de 6 bits rotulado como BITS DE CÓDIGO para determinar a finalidade e
o conteúdo do segmento. Os seis bits dizem como interpretar outros campos no cabeçalho,
de acordo com a Tabela 7.12.
Bit (esquerda para direita)
URG
ACK
PSH
RST
SYN
FIN
Significado se bit definido como 1
Campo ponteiro de urgente é válido
Campo de confirmação é válido
Este segmento requer um push
Reinicia a conexão
Sincroniza números de sequência
Emissor alcançou final do seu fluxo de bytes
Tabela 7.12 – Bits do campo BITS DE CÓDIGO no cabeçalho TCP.
O TCP anuncia quantos dados ele espera aceitar toda vez que envia um segmento,
especificando seu tamanho de buffer no campo JANELA. O campo contém um inteiro não
1
Na prática, o piggybacking normalmente não ocorre, porque a maioria das aplicações não envia dados nas duas direções
simultaneamente.
2
A especificação diz que o campo HLEN é o deslocamento da área de dados dentro do segmento.
163
sinalizado de 16 bits na ordem de bytes padrão da rede. Anúncios de janela oferecem outro
exemplo de piggybacking, pois acompanham todos os segmentos, incluindo aqueles
transportando dados e também aqueles carregando apenas uma confirmação.
7.19.11 Dados fora de faixa
Embora o TCP seja um protocolo orientado para fluxo, às vezes é importante que o
programa em uma extremidade de uma conexão envie dados fora da faixa, sem esperar que
o programa na outra extremidade da conexão consuma octetos já no fluxo. Por exemplo,
quando o TCP é usado para uma sessão de login remota, o usuário pode decidir enviar uma
sequência de teclado que interrompe ou aborta o programa na outra extremidade. Esses sinais
normalmente são necessários quando um programa na máquina remota deixa de operar
corretamente. Os sinais precisam ser enviados sem esperar que o programa leia octetos já no
fluxo TCP (ou alguém não seria capaz de abortar programas que param de ler a entrada).
Para acomodar a sinalização fora de faixa, o TCP permite que o emissor especifique
dados como urgentes, significando que o programa receptor deve ser notificado sobre sua
chegada o mais rápido possível, independente de sua posição no fluxo. O protocolo
especifica que, quando dados urgentes são encontrados, o TCP receptor deve notificar o
programa aplicativo associado à conexão para entrar no “modo urgente”. Depois que todos
os dados urgentes tiverem sido consumidos, o TCP diz ao programa aplicativo para retornar
à operação normal.
Os detalhes exatos de como o TCP informa ao programa aplicativo sobre dados
urgentes dependem do sistema operacional do computador. O mecanismo usado para marcar
dados urgentes ao transmiti-los em um segmento consiste no bit de código URG e no campo
PONTEIRO DE URGENTE. Quando o bit URG é marcado, o campo PONTEIRO DE
URGENTE especifica a posição no segmento onde os dados urgentes terminam.
7.19.12 Opções do TCP
Como mostra a Figura 7.52, um segmento TCP pode conter zero ou mais opções no
cabeçalho. Cada opção começa com um campo de 1 octeto que especifica a opção tipo,
seguida por um campo de tamanho de 1 octeto que especifica o tamanho da opção em octetos.
Se as opções não ocuparem um múltiplo exato de 32 bits, o PREENCHIMENTO é
acrescentado ao final do cabeçalho.
7.19.12.1Opção de tamanho máximo do segmento
Um emissor pode escolher a quantidade de dados que é colocada em cada
segmento. Porém, as duas extremidades de uma conexão TCP precisam combinar sobre
um segmento máximo que elas transferirão.
O TCP usa uma opção de tamanho máximo de segmento (Maximum Segment
Size – MSS) para permitir que um receptor especifique o segmento de tamanho máximo
que ele desejará receber. Assim, um sistema embutido que possui apenas algumas
centenas de bytes de espaço em buffer pode especificar um MSS que restringe os
segmentos de modo que caibam no buffer. A negociação do MSS é especialmente
significativa porque permite que sistemas heterogêneos se comuniquem. Um
supercomputador pode se comunicar com um sistema embutido pequeno. Para
maximizar o throughput, quando dois computadores se conectam à mesma rede física,
o TCP normalmente calcula um tamanho máximo de segmento de modo que os
datagramas IP resultantes combinem com a MTU da rede. Se as extremidades não
estiverem na mesma rede física, elas poderão tentar descobrir a MTU mínima ao longo
164
do caminho entre elas, ou escolher um tamanho de segmento máximo de 536 (o tamanho
default de um datagrama IP, 576, menos o tamanho padrão dos cabeçalhos IP e TCP).
Em um ambiente geral de inter-rede, a escolha de um bom tamanho máximo de
segmento pode ser difícil, pois o desempenho pode ser fraco para tamanhos de segmento
extremamente grandes ou extremamente pequenos. Por um lado, quando o tamanho do
segmento é pequeno, a utilização da rede permanece baixa. Para ver por que, lembre-se
de que os segmentos TCP trafegam encapsulados nos datagramas IP, que estão
encapsulados nos frames físicos da rede. Assim, cada segmento possui pelo menos 40
octetos de cabeçalhos TCP e IP, além dos dados. Portanto, os datagramas transportando
apenas um octeto de dados utilizam no máximo 1/41 da largura de banda da rede
subjacente para dados do usuário; na prática, as lacunas mínimas entre pacotes e os bits
de enquadramento de hardware da rede tornam a razão ainda menor.
Por outro lado, tamanhos de segmento extremamente grandes também podem
produzir um desempenho fraco. Segmentos grandes resultam em datagramas IP
grandes. Quando esses datagramas atravessam uma rede com MTU pequena, o IP
precisa fragmentá-los. Diferente de um segmento TCP, um fragmento não pode ser
confirmado ou retransmitido de forma independente; todos os fragmentos precisam
chegar, ou o datagrama inteiro precisa ser retransmitido. Como a probabilidade de
perder determinado fragmento é diferente de zero, aumentar o tamanho de segmento
acima do patamar de fragmentação diminui a probabilidade de o datagrama chegar, o
que diminui o throughput.
Em teoria, o tamanho de segmento ideal, S, ocorre quando os datagramas IP
transportando os segmentos são os maiores possíveis sem exigir fragmentação em
qualquer lugar ao longo do caminho da origem até o destino. Na prática, encontrar S é
difícil por vários motivos. Primeiro, a maioria das implementações do TCP não inclui
um mecanismo para fazer isso1. Segundo, como os roteadores em uma inter-rede podem
mudar de rotas dinamicamente, o caminho que os datagnamas seguem entre um par de
computadores em comunicação pode mudar dinamicamente, assim como o tamanho em
que os datagramas precisam ser fragmentados. Terceiro, o tamanho ideal depende dos
cabeçalhos de protocolo de nível inferior (por exemplo, o tamanho do segmento precisa
ser reduzido para acomodar opções do IP).
7.19.12.2Opção de janela móvel
Como o campo JANELA no cabeçalho TCP tem 16 bits de extensão, o tamanho
máximo da janela é de 64 Kbytes. Embora a janela seja suficiente para as primeiras
redes, um tamanho de janela maior é necessário para obter um alto throughput em uma
rede como um canal de satélite que possui um produto com grande atraso-largura de
banda (informalmente chamado de pipe longo e gordo).
Para acomodar tamanhos de janela maiores, uma opção de escala de janela foi
proposta para o TCP. A opção consiste em três octetos: um tipo, um tamanho e um valor
de shift, S. Essencialmente, o valor de shift especifica um fator de escala binário a ser
aplicado ao valor da janela. Quando a escala da janela está em vigor, um receptor extrai
o valor do campo JANELA, W, e desloca W à esquerda por S bits, a fim de obter o
tamanho real da janela.
1
Para descobrir a MTU do caminho, um emissor sonda o caminho enviando datagramas com o bit não fragmentar do IP
marcado. Depois, ele diminui o tamanho se as mensagens de erro ICMP informarem que a fragmentação foi necessária.
165
Diversos detalhes complicam o projeto. A opção pode ser negociada quando a
conexão é estabelecida inicialmente, quando todos os anúncios de janela sucessivos são
considerados como usando a escala negociada, ou a opção pode ser especificada em cada
segmento, quando o fator de escala pode variar de um segmento para outro. Além do
mais, se qualquer lado de uma conexão implementar a escala de janela, mas não precisar
dimensionar sua janela, esse lado envia a opção definida como zero, o que cria o fator
de escala 1.
7.19.12.3Opção de estampa de tempo
A opção de estampa de tempo TCP foi inventada para ajudar o TCP a calcular o
atraso na rede subjacente, e também é usada para lidar com o caso em que os números
de sequência do TCP excedem 232 (conhecidos como números Protect Against Wrapped
Sequence, PAWS). Além dos campos obrigatórios de tipo e tamanho, uma opção de
estampa de tempo inclui dois valores: um valor de estampa de tempo e um valor de
estampa de tempo de resposta de eco. Um emissor coloca a hora de seu clock atual no
campo de estampa de tempo ao enviar um pacote; um receptor copia o campo de estampa
de tempo para o campo de resposta de eco antes de retornar uma confirmação para o
pacote. Assim, quando uma confirmação chega, o emissor pode calcular com precisão
o tempo gasto total desde que o segmento foi enviado.
7.19.13 Cálculo do checksum TCP
O campo CHECKSUM no cabeçalho TCP contém um checksum inteiro de 16 bits,
usado para verificar a integridade dos dados, além do cabeçalho TCP. Para calcular o
checksum, o TCP na máquina emissora segue um procedimento como aquele descrito na
seção 7.18.6 para o UDP. Ele anexa um pseudocabeçalho ao segmento, anexa bits zero
suficientes para tornar o segmento um múltiplo de 16 bits e calcula o checksum de 16 bits
sobre o resultado inteiro. O TCP não conta o pseudocabeçalho ou o preenchimento no
tamanho do segmento, nem os transmite. Além disso, ele assume que o próprio campo de
checksum é zero para fins de cálculo do checksum. Assim como outros checksums, o TCP
usa a aritmética de 16 bits e apanha o complemento de um da soma do complemento a um.
No site receptor, o TCP realiza o mesmo cálculo para verificar se o segmento chegou intacto.
A finalidade do uso de um pseudocabeçalho é exatamente a mesma que no UDP. Ele
permite que o receptor verifique se o segmento alcançou seu destino correto, que inclui um
endereço IP do host e também um número de porta de protocolo. Os endereços IP de origem
e destino são importantes para o TCP porque ele precisa usá-los para identificar a conexão à
qual o segmento pertence. Portanto, sempre que um datagrama chega transportando um
segmento TCP, o IP precisa passar ao TCP os endereços IP de origem e destino do
datagrama, além do próprio segmento. A Figura 7.53 mostra o formato do pseudocabeçalho
usado no cálculo do checksum.
0
8
ZERO
16
31
ENDEREÇO IP DE ORIGEM
ENDEREÇO IP DE DESTINO
PROTOCOLO
TAMANHO DO TCP
Figura 7.53 – O formato do pseudo cabeçalho usado pelo TCP.
O TCP emissor atribui ao campo PROTOCOLO o valor que o sistema de remessa
subjacente usará em seu campo de tipo de protocolo. Para os datagramas IP transportando
o TCP, o valor é 6. O campo TAMANHO DO TCP especifica o tamanho total do segmento
TCP, incluindo o cabeçalho TCP. No extremo receptor, a informação usada no
166
pseudocabeçalho é extraída do datagrama IP que transportou o segmento e incluída no
cálculo do checksum para verificar se o segmento chegou intacto no destino correto.
7.19.14 Estabelecendo uma conexão TCP
Para estabelecer uma conexão, o TCP usa um handshake de três vias. No caso mais
simples, o processo de handshake funciona como na Figura 7.54.
Figura 7.54 – A sequência de mensagens em um handshake de três vias.
O primeiro segmento de um handshake pode ser identificado porque possui o bit SYN1
marcado no campo de código. A segunda mensagem possui os bits SYN e ACK marcados,
indicando que ele confirma o primeiro segmento SYN, além de continuar com o handshake.
A mensagem de handshake final é apenas uma confirmação, e é simplesmente usada para
informar ao destino de que ambos os lados concordam que uma conexão foi estabelecida.
Normalmente, o TCP em uma máquina espera passivamente pelo handshake, e o TCP
em outra máquina o inicia. Porém, o handshake é cuidadosamente projetado para funcionar
mesmo que as duas máquinas tentem iniciar uma conexão simultaneamente. Assim, uma
conexão pode ser estabelecida de qualquer extremidade ou das duas extremidades
simultaneamente. Quando a conexão tiver sido estabelecida, os dados podem fluir nas duas
direções igualmente bem. Não existe mestre ou escravo.
O handshake de três vias é necessário e suficiente para o sincronismo correto entre as
duas extremidades da conexão. Para entender por que, lembre-se de que o TCP é baseado
em um serviço de remessa de pacotes não-confiável, de modo que as mensagens podem ser
perdidas, adiadas, duplicadas ou entregues fora da ordem. Assim, o protocolo precisa usar
um mecanismo de timeout e retransmitir requisições perdidas. O problema surge se as
requisições retransmitidas e originais chegarem enquanto a conexão estiver sendo
estabelecida, ou se as requisições retransmitidas forem adiadas até depois que a conexão tiver
sido estabelecida, usada e terminada. Um handshake de três vias (mais a regra de que o TCP
ignora requisições adicionais para conexão após uma conexão ter sido estabelecida)
soluciona esses problemas.
7.19.15 Números de sequência iniciais
Um handshake de três vias realiza duas funções importantes. Ele garante que os dois
lados estão prontos para transferir dados (e que sabem que ambos estão prontos) e permite
1
SYN significa sincronismo; a pronúncia é “sin”.
167
que os dois lados concordem sobre números de sequência iniciais. Os números de sequência
são enviados e confirmados durante o handshake. Cada máquina precisa escolher um número
de sequência inicial aleatoriamente, que usará para identificar os bytes no fluxo que está
enviado. Os números de sequência não podem começar sempre com o mesmo valor. Em
particular, o TCP não pode simplesmente escolher a sequência 1 toda vez que criar uma
conexão. Naturalmente, é importante que os dois lados concordem sobre um número inicial,
de modo que os números de octeto usados nas confirmações combinem com aqueles usados
nos segmentos de dados.
Para ver como as máquinas podem combinar sobre números de sequência para dois
fluxos após somente três mensagens, lembre-se de que cada segmento contém um campo de
número de sequência e um campo de confirmação. A máquina que inicia um handshake, que
chamaremos de A, passa seu número de sequência inicial, x, no campo de sequência do
primeiro segmento SYN do handshake de três vias. A segunda máquina, B, recebe o SYN,
registra o número de sequência e responde enviando seu número de sequência inicial no
campo de sequência, além de uma confirmação que especifica que B espera o octeto x+l. Na
mensagem final do handshake, A “confirma” receber de B todos os octetos até y. Em todos
os casos, as confirmações seguem a convenção de usar o número do próximo octeto esperado.
Descrevemos como o TCP normalmente executa o handshake de três vias, trocando
segmentos que contêm uma quantidade mínima de informações. Devido ao projeto do
protocolo, é possível enviar dados junto com os números de sequência iniciais nos segmentos
de handshake. Nesses casos, o TCP precisa manter os dados até que o handshake termine.
Quando uma conexão for estabelecida, o TCP pode liberar dados sendo mantidos e entregálos rapidamente a um programa aplicativo aguardando.
7.19.16 Fechando uma conexão TCP
Dois programas que usam o TCP para se comunicar podem terminar a conversação de
modo controlado usando a operação close. Internamente, o TCP usa um handshake de três
vias modificado para fechar as conexões. Lembre-se de que as conexões do TCP são full
duplex e que as vemos como contendo duas transferências de fluxo independentes, cada uma
em uma direção. Quando um programa aplicativo diz ao TCP que não possui mais dados
para enviar, o TCP fecha a conexão em uma direção. Para fechar sua metade de uma conexão,
o TCP de envio termina de transmitir os dados restantes, espera que o receptor confirme e
depois envia um segmento com o bit FIN marcado. O TCP receptor confirma o segmento
FIN e informa ao programa aplicativo em sua extremidade que não há mais dados disponíveis
(por exemplo, usando o mecanismo de fim de arquivo do sistema operacional).
Quando uma conexão tiver sido fechada em determinada direção, o TCP se recusa a
aceitar mais dados para essa direção. Nesse meio tempo, os dados podem continuar a fluir
na direção oposta até que o emissor a feche. Naturalmente, as confirmações continuam a
fluir de volta ao emissor, mesmo depois que uma conexão tiver sido fechada. Quando as
duas direções tiverem sido fechadas, o TCP em cada extremidade exclui seu registro da
conexão.
Os detalhes do fechamento de uma conexão são ainda mais sutis do que o sugerido
antes, pois o TCP usa um handshake de três vias modificado para fechar uma conexão. A
Figura 7.55 ilustra o procedimento.
168
Figura 7.55 – O handshake de três vias modificado usado para fechar conexões.
A diferença entre os handshakes de três vias usados para estabelecer e interromper
conexões ocorre depois que uma máquina recebe o segmento FIN inicial. Em vez de gerar
um segundo segmento FIN imediatamente, o TCP envia uma confirmação e depois informa
à aplicação quanto à requisição para encerrar. Pode ser necessário muito tempo para informar
ao programa aplicativo quanto à requisição e obter uma resposta (por exemplo, isso pode
envolver interação humana). A confirmação impede a retransmissão do segmento FIN inicial
durante a espera. Finalmente, quando o programa aplicativo instrui o TCP a encerrar a
conexão completamente, o TCP envia o segundo segmento FIN, e o site original responde
com a terceira mensagem, um ACK.
7.19.17 Reinício da conexão TCP
Normalmente, um programa aplicativo usa a operação close para encerrar uma conexão
quando termina de usá-la. Assim, fechar conexões é considerado uma parte normal do uso,
semelhante a fechar arquivos. Às vezes, surgem condições anormais que forçam um
programa aplicativo ou o software da rede a interromper uma conexão. O TCP oferece uma
facilidade de reset para essas desconexões anormais.
Para reiniciar uma conexão, um lado inicia o término enviando um segmento com o bit
RST no campo CÓDIGO marcado. O outro lado responde a um segmento de reset
imediatamente, abortando a conexão. O TCP também informa ao programa aplicativo que
houve um reset. Um reset é um aborto instantâneo, que significa que a transferência nas duas
direções termina imediatamente e que recursos como buffers são liberados.
7.19.18 Números de porta TCP reservados
Assim como UDP, o TCP combina o vínculo de porta estático e dinâmico, usando um
conjunto de atribuições de porta bem conhecidas para programas comumente invocados (por
exemplo, correio eletrônico), mas omitindo a maioria dos números de porta disponíveis para
o sistema operacional, para serem alocados quando os programas precisarem deles. Agora,
existem muitas portas bem conhecidas. Originalmente, os números de porta bem conhecida
eram pequenos, mas algumas portas acima de 1.024 agora já foram atribuídas (em sistemas
UNIX, as primeiras 1.023 portas são consideradas privilegiadas e só estão disponíveis a
programas privilegiados). A Tabela 7.13 lista algumas das portas TCP atualmente atribuídas.
Devemos explicar que, embora os números de porta TCP e UDP sejam independentes, os
projetistas escolheram usar os mesmos números de porta inteiros para qualquer serviço que
169
seja acessível por UDP e TCP. Por exemplo, um servidor de nome de domínio pode ser
acessado com TCP ou com UDP. Em qualquer um desses protocolos, o número de porta 53
foi reservado para servidores no sistema de nome de domínio (Domains Name System –
DNS).
7.19.19 Desempenho do TCP
Como vimos, o TCP é um protocolo complexo, que lida com a comunicação por uma
grande variedade de tecnologias de rede subjacentes. Muitas pessoas consideram que, como
o TCP trata de uma tarefa muito mais complexa do que outros protocolos de transporte, o
código precisa ser desajeitado e ineficaz. Surpreendentemente, a generalidade que
discutimos parece não atrapalhar o desempenho do TCP. As experiências em Berkeley
mostraram que o mesmo TCP que opera de forma eficiente pela Internet global pode entregar
8 Mbps de throughput sustentado de dados do usuário entre duas estações de trabalho em
uma Ethernet a 10 Mbps1. Na Cray Research, Inc., os pesquisadores demonstraram um
throughput TCP aproximando-se de 1 Gbps.
1
Cabeçalhos Ethernet, IP e TCP e a lacuna entre pacotes exigida são responsáveis pela largura de banda restante.
170
Decimal
0
7
9
11
13
15
17
19
20
21
22
23
25
37
53
67
79
80
88
110
111
119
123
143
161
443
465
515
873
993
995
1080
Palavra-Chave
–
ECHO
DISCARD
USERS
DAYTIME
NETSAT
QUOTE
CHARGEN
FTP-DATA
FTP
SSH
TELNET
SMTP
TIME
DOMAIN
BOOTPS
FINGER
WWW
KERBEROS
POP3
SUNRPC
NNTP
NTC
IMAP
SNMP
HTTPS
SMTPS
SPOOLER
RSYNC
IMAPS
POP3S
SOCKS
Descrição
Reservado
Eco
Descarte
Usuários ativos
Hora do dia
Programa de status da rede
Citação do dia
Gerador de caracteres
File Transfer Protocol (dados)
File Transfer Protocol (controle)
Secure Shell
Conexão de terminal
Simple Mail Transport Protocol
Hora
Domain Name Server
Servidor BOOTP ou DHCP
Finger
World Wide Web Server
Serviço de segurança Kerberos
Post Office Protocol versão 3
Sun Remote Procedure Call
USENET News Transfer Protocol
Network Time Protocol
Internet Message Access Protocol
Simple Network Management Protocol
http seguro
SMTP over SSL (TLS)
Spooler LPR
Protocolo Rsync
IMAP seguro
POP3 seguro
Protocolo servidor de Proxy
Tabela 7.13 – Exemplos de números de porta TCP.
171
Serviços e Tecnologias Web
8.1
Atribuição Dinâmica de Endereços
8.1.1
BOOTP
O ARP resolve o problema de encontrar um endereço Ethernet que corresponda a um
determinado endereço IP. Às vezes, é necessário resolver o problema inverso: qual é o
endereço IP correspondente a um endereço Ethernet? Isso ocorre especificamente quando
uma estação de trabalho sem disco é inicializada. Em geral, essa máquina obterá a imagem
binária de seu sistema operacional a partir de um servidor de arquivos remoto. No entanto,
como ela descobrirá seu endereço IP?
A primeira solução imaginada foi usar o RARP – Reverse Address Resolution Protocol
(definido na RFC 903). Esse protocolo permite que uma estação de trabalho recém
inicializada transmita seu endereço Ethernet e informe: meu endereço Ethernet de 48 bits é
14–04–05–18–01–25. Alguém conhece meu endereço IP? O servidor RARP vê essa
solicitação, procura o endereço Ethernet em seus arquivos de configuração e envia de volta
o endereço IP correspondente.
O uso do RARP é melhor que a inclusão de um endereço IP na imagem de memória,
porque permite que a mesma imagem seja usada em todas as máquinas. Se o endereço IP
fosse embutido na imagem, cada estação de trabalho precisaria ter sua própria imagem.
Uma desvantagem do RARP é que ele utiliza um endereço de destino composto
somente por valores 1 (broadcast limitado) para chegar ao servidor RARP. Entretanto, essas
difusões não são encaminhadas pelos roteadores; portanto, é necessário um servidor RARP
em cada rede. Para resolver esse problema, foi criado um protocolo de inicialização
alternativo, chamado BOOTP. Diferente do RARP, o BOOTP utiliza mensagens UDP, que
são encaminhadas pelos roteadores. O BOOTP também fornece informações adicionais a
uma estação de trabalho sem disco, inclusive o endereço IP do servidor de arquivos que
contém a imagem de memória, o endereço IP do roteador padrão e a máscara de subrede a
ser usada. O BOOTP é descrito nas RFCs 951, 1048 e 1084.
Um problema sério com o BOOTP é que ele exige configuração manual de tabelas que
mapeiam endereços IP para endereços Ethernet. Quando um novo host é adicionado a uma
LAN, ele não pode usar o BOOTP enquanto um administrador não tiver atribuído a ele um
endereço IP e inserido manualmente seu par (endereço Ethernet, endereço IP) nas tabelas de
configuração do BOOTP. Para eliminar essa etapa propensa a erros, o BOOTP foi ampliado
e recebeu um novo nome, DHCP (Dynamic Host Configuration Protocol). O DHCP permite
a atribuição manual e a atribuição automática de endereços IP. Ele é descrito nas RFCs 2131
e 2132. Na maioria dos sistemas, o DHCP substituiu em grande parte o RARP e o BOOTP.
Como hoje se usa basicamente o DHCP, a seção 8.1.2 detalha o seu funcionamento.
8.1.2
DHCP
Esta seção mostra como o modelo cliente-servidor é usado para bootstrapping. Cada
computador anexado a uma rede TCP/IP precisa obter um endereço IP e a máscara de
endereço associada para a rede, bem como outras informações, incluindo os endereços de um
roteador e um nome de servidor. Esta seção descreve um protocolo que permite que um host
determine as informações automaticamente na inicialização. Essa inicialização automática é
172
importante porque permite que um usuário conecte um computador à Internet sem conhecer
os detalhes dos endereços, máscaras, roteadores ou como configurar o protocolo.
O procedimento de bootstrapping descrito aqui é surpreendente porque usa o UDP para
transferir mensagens. Pode parecer impossível usar UDP para encontrar um endereço, pois
cada mensagem UDP é enviada em um modelo IP. Entretanto, veremos que os endereços IP
especiais mencionados anteriormente o tornam possível.
O protocolo RARP foi inicialmente desenvolvido para permitir que um computador
obtenha um endereço IP. Um protocolo mais geral chamado BOOTstrap Protocol (BOOTP)
posteriormente substituiu o RARP. Finalmente, o Dynamic Host Configuration Protocol
(DHCP) foi desenvolvido como um sucessor para o BOOTP. Como o DHCP é um sucessor
do BOOTP, a descrição nesta seção geralmente se aplica a ambos.
Como usa o UDP e IP, o DHCP pode ser implementado por um programa aplicativo.
Assim como outros protocolos de aplicação, o DHCP segue o modelo cliente-servidor; o
protocolo exige apenas uma única troca de pacotes em que um computador envia um pacote
para requisitar informações de bootstrap e um servidor responde enviando um único pacote
que especifica itens necessários na partida, incluindo o endereço IP do computador, o
endereço de um roteador e o endereço de um nome de servidor. O DHCP também inclui um
campo opções na resposta que permite que os fornecedores enviem informações adicionais
usadas apenas para seus computadores.
8.1.2.1
Usando IP para determinar um endereço IP
Dissemos que o DHCP utiliza UDP para transportar mensagens, e que mensagens
UDP são encapsuladas em datagramas IP para distribuição. Para entender como um
computador pode enviar DHCP em um datagrama IP antes de aprender seu endereço
IP, lembre-se, de que existem vários endereços IP de uso especial. Particularmente,
quando usado como um endereço de destino, o endereço IP consistindo de todos os bits
em 1 (255.255.255.255) especifica broadcast limitado. O IP pode aceitar e difundir
datagramas que especificam o endereço de broadcast limitado mesmo antes que o
software tenha descoberto suas informações de endereço IP locais. A questão é que um
programa aplicativo pode usar o endereço IP de broadcast limitado para obrigar o IP a
difundir um datagrama na rede local antes que o IP tenha descoberto o endereço IP da
rede local ou o endereço IP da máquina.
Suponha que uma máquina cliente A queira usar o DHCP para encontrar
informações de boostrap (incluindo seu endereço IP) e suponha que B seja o servidor
na mesma rede física que responderá à requisição. Como A não sabe o endereço IP de
B ou o endereço IP da rede, ele precisa difundir sua requisição DHCP inicial usando o
endereço IP de broadcast limitado. E quanto à resposta? B pode enviar uma resposta
direcionada? Não, embora ele conheça o endereço IP de A. Para ver por quê, considere
o que acontece se um programa aplicativo em B tentar enviar um datagrama usando o
endereço IP de A. Após rotear o datagrama, o IP em B passará o datagrama para o
software de interface de rede. O software de interface precisa mapear o endereço IP do
próximo salto para um endereço de hardware correspondente, presumivelmente usando
o ARP, como descrito, na seção 7.13.4. Entretanto, como A ainda não recebeu a resposta
DHCP, ele não reconhece seu endereço IP e, portanto, não pode responder à requisição
ARP de B. Assim, B tem apenas duas alternativas: difundir a resposta ou usar
informações do pacote de requisição para acrescentar manualmente uma entrada ao seu
cache ARP. Em sistemas que não permitem que programas aplicativos modifiquem o
cache ARP, o broadcasting é a única solução.
173
8.1.2.2
A política de retransmissão do DHCP
O DHCP coloca toda a responsabilidade da comunicação segura no cliente.
Sabemos que, como o UDP usa IP para distribuição, as mensagens podem ser retardadas,
perdidas, distribuídas fora de ordem ou duplicadas. Além disso, como o IP não fornece
um checksum para os dados, o datagrama UDP poderia chegar com alguns bits
danificados. Para se prevenir de danos, o DHCP exige que o UDP use checksums. Ele
também especifica que as requisições e respostas devem ser enviadas com o bit não
fragmentar definido para acomodar clientes que têm muito pouca memória para
remontar datagramas. O DHCP, também é construído para permitir múltiplas respostas;
ele aceita e processa a primeira.
Para tratar a perda de datagramas, o DHCP usa a técnica convencional do timeout
e retransmissão. Quando o cliente transmite uma requisição, ele inicia um timer. Se
nenhuma resposta chegar antes que o timer expire, o cliente precisa retransmitir a
requisição. É claro, após uma interrupção de energia, todas as máquinas em uma rede
reiniciarão simultaneamente, possivelmente enchendo o servidor ou servidores DHCP
com requisições. Se todos os clientes usarem exatamente o mesmo timeout de
retransmissão, muitos ou todos eles tentarão retransmitir simultaneamente. Para evitar
as colisões resultantes, a especificação do DHCP recomenda usar um retardo aleatório.
Além disso, a especificação recomenda iniciar com um valor de timeout aleatório entre
0 e 4 segundos, e dobrar o timer após cada retransmissão. Após o timer atingir um valor
alto, 60 segundos, o cliente não aumenta o timer, mas continua a usar a aleatoriedade.
Dobrar o timeout após cada retransmissão evita que o DHCP acrescente tráfego
excessivo a uma rede congestionada; a aleatoriedade ajuda a evitar transmissões
simultâneas.
8.1.2.3
O formato de mensagem DHCP
Para manter uma implementação o mais simples possível, as mensagens DHCP
possuem campos de tamanho fixo, e as respostas têm o mesmo formato das requisições.
Embora tenhamos dito que clientes e servidores são programas, o protocolo DHCP usa
os termos livremente, referindo-se à máquina que envia a requisição DHCP como o
cliente e qualquer máquina que envia uma resposta como servidor. A Figura 8.1 mostra
o formato de mensagem DHCP.
O campo OP especifica se a mensagem é uma requisição (1) ou uma resposta (2).
Como no ARP, os campos TIPO_H e TAM_H especificam o tipo de hardware de rede
e o tamanho do endereço de hardware (por exemplo, Ethernet tem tipo 1 e o tamanho
de endereço 6). O cliente coloca 0 no campo SALTOS. Se receber a requisição e decidir
passar a requisição para outra máquina (por exemplo, para permitir o boostrapping
através de múltiplos roteadores), o servidor DHCP incrementa a contagem de SALTOS.
O campo ID DA TRANSAÇÃO contém um inteiro que o cliente usa para adequar as
respostas às requisições. O campo SEGUNDOS informa o número de segundos desde
que o cliente inicializou.
O campo ENDEREÇO IP DO CLIENTE e todos os campos que o seguem contêm
as informações mais importantes. Para permitir a maior flexibilidade, os clientes
preenchem o máximo de informações que eles conhecem e deixam os campos restantes
definidos em zero. Por exemplo, se um cliente sabe o nome ou endereço de um servidor
específico do qual queira informações, ele pode preencher os campos ENDEREÇO IP
DO SERVIDOR ou NOME DO HOST SERVIDOR. Se esses campos forem não zero,
apenas o servidor com nome/endereço correspondentes responderá à requisição; se eles
forem zero, qualquer servidor que receba a requisição responderá.
174
0
8
OP
16
24
TIPO_H
TAM_H
ID DA TRANSAÇÃO
SEGUNDOS
31
SALTOS
FLAGS
ENDEREÇO IP DO CLIENTE
SEU ENDEREÇO IP
ENDEREÇO IP DO SERVIDOR
ENDEREÇO IP DO ROTEADOR
ENDEREÇO DE HARDWARE DO CLIENTE (16 OCTETOS)
...
NOME DO HOST SERVIDOR (64 OCTETOS)
...
NOME DO ARQUIVO DE BOOT (128 OCTETOS)
...
OPÇÕES (VARIÁVEL)
...
Figura 8.1 – Formato de uma mensagem DHCP.
O DHCP pode ser usado através de um cliente que já conheça seu endereço IP (ou
seja, para obter outras informações). Um cliente que conhece o endereço IP o coloca no
campo ENDEREÇO IP DO CLIENTE; outros clientes usam zero. Se o endereço IP do
cliente for zero na requisição, um servidor retorna o endereço IP do cliente no campo
SEU ENDEREÇO IP.
O campo FLAG de 16 bits permite o controle da requisição e resposta. Como a
Figura 8.2 mostra, um significado apenas é atribuído ao bit de ordem superior do campo
FLAGS.
0
B
15
PRECISA SER ZERO
Figura 8.2 – Formato do campo FLAGs de 16 bits do DHCP.
Um cliente usa o bit de ordem superior no campo FLAGS para controlar se o
servidor envia a resposta via unicast ou broadcast. Para entender por que um cliente
poderia escolher uma resposta de broadcast, lembre-se de que, embora se comunique
com um servidor DHCP, um cliente ainda não tem um endereço IP, o que significa que
o cliente não pode responder a consultas ARP. Portanto, para garantir que o cliente
possa receber mensagens enviadas por um servidor DHCP, um cliente pode requisitar
que o servidor envie respostas usando broadcast IP, que corresponde ao broadcast de
hardware. As regras para o processamento de datagrama permitem que o IP descarte
qualquer datagrama que chegue via unicast de hardware se o endereço de destino não
corresponder ao endereço do computador. Entretanto, o IP precisa aceitar e tratar
qualquer datagrama enviado para o endereço de broadcast IP.
Interessantemente, o DHCP não provê espaço na mensagem para baixar uma
imagem de memória específica para um sistema incorporado. Em vez disso, o DHCP
fornece um campo NOME DE ARQUIVO DE BOOT que um pequeno sistema sem disco
pode usar. O cliente pode usar o campo para fornecer um nome genérico como “Unix”,
que significa “quero inicializar o sistema operacional UNIX para esta máquina”. O
servidor DHCP consulta seu banco de dados de configuração a fim de mapear o nome
genérico para um nome de arquivo específico que contém a imagem de memória
175
apropriada para o hardware de cliente e retorna o nome de arquivo totalmente
qualificado em sua resposta. É claro, o banco de dados de configuração também permite
bootstrapping completamente automático, em que o cliente coloca zeros no campo
NOME DO ARQUIVO DE BOOT, e o DHCP seleciona uma imagem de memória para
a máquina. O cliente, então, usa um protocolo de transferência de arquivo padrão, como
o TFTP, para obter a imagem. A vantagem do método é que um cliente sem disco pode
usar um nome genérico sem codificar um arquivo específico e o gerente de rede pode
mudar o local de uma imagem de inicialização sem mudar a ROM nos sistemas
incorporados.
Todos os itens na área OPÇÕES usam uma codificação de estilo Tipo-TamanhoValor (TTV) – cada item contém um octeto de tipo, um octeto de tamanho e termina
com um valor do tamanho especificado.
8.1.2.4
A necessidade da configuração dinâmica
Os primeiros protocolos de bootstrap operavam em um ambiente relativamente
estático em que cada host tinha uma conexão de rede permanente. Um gerente criava
um arquivo de configuração que especificava um conjunto de parâmetros para cada host,
incluindo um endereço IP. O arquivo não mudava frequentemente porque a
configuração normalmente permanecia estável.
Em geral, uma configuração
permanecia inalterada por semanas.
Na Internet moderna, porém, os provedores de serviço possuem um conjunto de
clientes que muda continuamente, e os computadores laptop portáteis com conexões sem
fio possibilitam mover um computador de um local para outro de maneira rápida e fácil.
Para tratar a atribuição de endereço automatizada, o DHCP permite que um computador
obtenha um endereço IP rápido e dinamicamente. Ou seja, ao configurar um servidor
DHCP, um gerente fornece um conjunto de endereços IP. Sempre que um novo
computador se conecta a uma rede, ele contata o servidor e requisita um endereço. O
servidor escolhe um dos endereços do conjunto que o gerente especificou e aloca o
endereço para o computador.
Para ser completamente geral, o DHCP permite três tipos de atribuição de
endereço; um gerente escolhe como o DHCP responderá para cada rede ou cada host.
Como seu predecessor, BOOTP, o DHCP permite configuração manual em que um
gerente configura um endereço específico para um computador específico. O DHCP
também tem uma forma de configuração automática, ou autoconfiguração, em que um
gerente permite que um servidor DHCP atribua um endereço permanente assim que um
computador se conecta a uma rede. Finalmente, o DHCP permite completamente a
configuração dinâmica, em que um servidor “aluga” um endereço para um computador
por um tempo limitado. A atribuição de endereço dinâmica é o aspecto mais poderoso
e novo do DHCP.
O DHCP usa a identidade do cliente e os arquivos de configuração do servidor
para decidir como proceder. Quando um cliente contata um servidor DHCP, o cliente
envia um identificador, normalmente o endereço de hardware do cliente. O servidor
usa o identificador do cliente e a rede à qual o cliente se conectou para determinar como
atribuir ao cliente o endereço IP. Portanto, um gerente possui controle completo sobre
como os endereços são atribuídos. Um servidor pode ser configurado no sentido de
alocar endereços para computadores específicos estaticamente, enquanto permite que
outros computadores obtenham endereços permanentes ou temporários dinamicamente.
176
8.1.2.5
Conceito de aluguel do DHCP
A atribuição de endereço dinâmica é temporária. Dizemos que um servidor DHCP
aluga um endereço para um cliente por um período finito de tempo. O servidor
especifica o período de aluguel quando ele aloca o endereço. Durante o período de
aluguel, o servidor não alugará o mesmo endereço para outro cliente. No fim do período,
entretanto, o cliente precisa renovar o aluguel ou parar de usar o endereço.
Quanto tempo deve durar um aluguel de DHCP? O tempo ideal depende da rede
específica e das necessidades de um host em particular. Por exemplo, para garantir que
endereços possam ser reciclados rapidamente, os computadores em uma rede usada por
alunos em um laboratório universitário podem usar um curto período de aluguel (por
exemplo, uma hora). Por outro lado, uma rede corporativa pode usar um período de
aluguel de um dia ou uma semana. Um ISP poderia fazer a duração de um aluguel
depender do contrato de um cliente. Para acomodar todos os ambientes possíveis, o
DHCP não especifica uma constante fixa para o período de aluguel. Em vez disso, o
protocolo permite que um cliente requisite um período de aluguel específico e permite
que um servidor informe ao cliente o período de aluguel que ele concede. Portanto, um
gerente pode decidir quanto tempo cada servidor deve alocar um endereço para um
cliente. No outro extremo, o DHCP reserva um valor infinito para permitir que um
aluguel dure um período arbitrariamente longo (ou seja, para tornar uma atribuição de
endereço permanente).
8.2
NAT
Foi criada uma tecnologia que resolve o problema geral de fornecer acesso em nível de IP
entre hosts em um site e o restante da Internet, sem exigir que cada host no site tenha um endereço
IP globalmente válido. Conhecida como Network Address Translation (NAT), a tecnologia
requer que um site tenha uma única conexão com a Internet global e, pelo menos, um endereço
IP globalmente válido, G. O endereço G é atribuído a um computador (um host multi-homed ou
um roteador) que conecta o site com a Internet e executa o software NAT. Informalmente, nos
referimos a um computador que executa o NAT como uma caixa NAT; todos os datagramas
atravessam a caixa NAT enquanto viajam do site para a Internet ou da Internet para o site.
O NAT traduz os endereços nos datagramas que saem e que entram substituindo o endereço
de origem em cada datagrama que entra com o endereço privado do host correto. Portanto, do
ponto de vista de um host externo, todos os datagramas vêm da caixa NAT, e todas as respostas
retornam à caixa NAT. Da visão dos hosts internos, a caixa NAT parece ser um roteador que
pode alcançar a Internet global.
A principal vantagem do NAT surge de sua combinação de generalidade e transparência. O
NAT é mais geral do que os gateways de aplicação porque permite que um host interno qualquer
acesse um serviço qualquer em um computador na Internet. O NAT é transparente porque permite
que um host interno envie e receba datagramas usando um endereço privado (ou seja, não
roteável).
8.2.1
Criação da tabela de tradução NAT
Nosso resumo do NAT omite um detalhe importante porque não especifica como o
NAT sabe que host interno deve receber um datagrama que chega da Internet. Na verdade,
o NAT mantém uma tabela de tradução que usa para realizar o mapeamento. Cada entrada
na tabela especifica dois itens: o endereço IP de um host na Internet e o endereço IP interno
de um host no site. Quando um datagrama chega da Internet, o NAT consulta o endereço de
destino do datagrama na tabela de tradução, extrai o endereço correspondente de um host
177
interno, extrai o endereço correspondente de um host interno, substitui o endereço de destino
do datagrama pelo endereço do host e encaminha o datagrama pela rede local até o host1.
A tabela de tradução NAT precisa estar pronta antes de um datagrama chegar da
Internet. Caso contrário, o NAT não tem como identificar o host interno correto para o qual
o datagrama deve ser encaminhado. Como e quando a tabela é inicializada? Há várias
possibilidades:

Inicialização manual: um gerente configura a tabela de tradução manualmente
antes que qualquer comunicação ocorra.

Datagramas de saída: a tabela é construída como um efeito colateral de um host
interno enviando um datagrama. O NAT usa o datagrama de saída para criar uma
entrada da tabela de tradução que registra os endereços de origem e destino.

Consultas de nome de entrada: a tabela é construída como um efeito colateral de
manipular consultas de nome de domínio. Quando um host na Internet consulta o
nome de domínio de um host interno, o DNS envia o endereço G como resposta e,
depois, cria uma entrada na tabela de tradução NAT para encaminhar datagramas
que chegam para o host interno correto.
Cada técnica de inicialização apresenta vantagens e desvantagens. A inicialização
manual fornece mapeamentos permanentes e permite que datagramas IP sejam enviados em
qualquer direção a qualquer hora. Usar um datagrama de saída para inicializar a tabela tem
a vantagem de ser automático, mas não permite que a comunicação seja iniciada de fora.
Usar consultas de nome de domínio que entra exige modificar o software de nome de
domínio. Isso acomoda a comunicação iniciada de fora do site, mas funciona apenas se o
emissor realizar uma consulta de nome de domínio antes de enviar datagramas.
A maioria das implementações do NAT usa datagramas de saída para inicializar a
tabela; a estratégia é especialmente popular entre os ISPs. Para entender o porquê, considere
um pequeno ISP que serve clientes com conexão discada. A Figura 8.3 ilustra a arquitetura.
Figura 8.3 – O uso de um NAT por um pequeno ISP.
O ISP precisa atribuir um endereço IP a um cliente sempre que o cliente disca. O NAT
permite que o ISP atribua um endereço privado (por exemplo, 10.0.0.1 é atribuído ao primeiro
cliente, 10.0.0.2 ao segundo e assim por diante). Quando um cliente envia um datagrama a
um destino na Internet, o NAT usa o datagrama de saída para inicializar sua tabela de
tradução.
8.2.2
NAT multiendereço
Até agora, descrevemos uma implementação simplista do NAT que realiza um
mapeamento de endereço um-para-um entre um endereço externo e um endereço interno. Ou
1
Sempre que substitui um endereço em um cabeçalho de datagrama, o NAT recalcula o checksum do cabeçalho.
178
seja, um mapeamento um-para-um permite que no máximo um computador no site possa
acessar uma determinada máquina na Internet a qualquer hora. Na prática, são usadas formas
mais complexas do NAT que permitem que hosts em um site acessem um determinado
endereço externo concorrentemente.
Uma variação do NAT permite concorrência conservando o mapeamento um-para-um,
mas permitindo que a caixa NAT armazene múltiplos endereços da Internet. Conhecido
como NAT multiendereço, o esquema atribui à caixa NAT um conjunto de K endereços
globalmente válidos, G1, G2, ... , Gk. Quando o primeiro host interno acessa um determinado
destino, a caixa NAT escolhe o endereço G1, acrescenta uma entrada à tabela de tradução e
envia o datagrama. Se outro host iniciar contato com o mesmo destino, a caixa NAT escolhe
o endereço G2, e assim por diante. Portanto, o NAT multiendereço permite que até K hosts
acessem um determinado destino concorrentemente.
8.2.3
NAT mapeado em porta
Outra variante popular do NAT fornece concorrência traduzindo números de porta de
protocolo TCP ou UDP, bem como endereços. Algumas vezes chamado Network Address
Port Translation (NAPT), o esquema expande a tabela de tradução NAT para incluir campos
adicionais. Além de um par de endereços IP de origem e destino, a tabela contém um par de
números de porta de protocolo de origem e de destino e um número de porta de protocolo
usado pela caixa NAT. A Tabela 8.1 ilustra o conteúdo da tabela.
Endereço
Privado
10.0.0.5
10.0.0.1
10.0.2.6
10.0.0.3
Porta
Privada
21.023
386
26.600
1.274
Endereço
Externo
128.10.19.20
128.10.19.20
207.200.75.200
128.210.1.5
Porta
Externa
80
80
21
80
Porta NAT
14.003
14.010
14.012
14.007
Protocolo
usado
Tcp
Tcp
Tcp
Tcp
Tabela 8.1 – Um exemplo de uma tabela de tradução usada pelo NAPT.
A Tabela 8.1 possui entradas para quatro computadores internos que estão atualmente
acessando destinos na Internet global. Toda a comunicação está usando TCP. É interessante
que a tabela mostra dois hosts internos, 10.0.0.5 e 10.0.0.1, ambos acessando a porta de
protocolo 80 (um servidor Web) no computador 128.10.19.20. Nesse caso, ocorre que as
duas portas de origem sendo usadas para as duas conexões diferem. Entretanto, a
exclusividade da porta de origem não pode ser garantida, poderia acontecer que dois hosts
internos escolhessem o mesmo número de porta de origem. Assim, para evitar possíveis
conflitos, o NAT atribui um número de porta único a cada comunicação que é usada na
Internet. Lembre-se de que o TCP identifica cada conexão com uma tupla de 4 entradas que
representa o endereço IP e o número de porta de protocolo de cada extremidade. Os dois
primeiros itens na tabela correspondem a conexões TCP que os dois hosts internos
identificam com as tuplas de 4:
(10.0.0.5, 21023, 128.10.19.20, 80)
(10.0.0.1, 386, 128.10.19.20, 80)
Entretanto, o computador na Internet que recebe os datagramas após o NAPT realizar
a tradução identifica as mesmas duas conexões com as tuplas de 4 entradas:
(G, 14003, 128.10.19.20, 80)
(G, 14010, 128.10.19.20, 80)
179
onde G é o endereço globalmente válido da caixa NAT.
A principal vantagem do NAPT reside na generalidade que ele consegue com um único
endereço IP globalmente válido; a maior desvantagem surge porque ele restringe a
comunicação ao TCP ou ao UDP. Como toda comunicação usa TCP ou UDP, o NAPT
permite que um computador interno acesse vários computadores externos, e vários
computadores internos acessem o mesmo computador externo sem interferência. Um espaço
de porta de 16 bits permite que até 216 pares de aplicações se comuniquem ao mesmo tempo.
8.2.4
Interação entre NAT e ICMP
Mesmo mudanças simples em um endereço IP podem causar resultados inesperados
nos protocolos de camada mais alta. Em especial, para manter a ilusão de transparência, o
NAT precisa manipular o ICMP. Por exemplo, suponha que um host interno use o ping para
testar a acessibilidade de um destino na Internet. O host espera receber uma mensagem ICMP
echo reply para cada mensagem echo request que ele envia. Portanto, o NAT precisa
encaminhar as respostas de eco para o host correto. Entretanto, o NAT não encaminha todas
as mensagens ICMP que chegam da Internet. Se os roteadores na caixa NAT estiverem
incorretos, por exemplo, uma mensagem ICMP redirect precisará ser processada localmente.
Assim, quando uma mensagem ICMP chega da Internet, o NAT precisa primeiro determinar
se a mensagem deve ser manipulada localmente ou enviada para um host interno. Antes de
encaminhar para um host interno, o NAT traduz a mensagem ICMP.
Para entender a necessidade da tradução ICMP, considere uma mensagem ICMP
destino inalcançável (destination unreachable). A mensagem contém o cabeçalho de um
datagrama, D, que causou o erro. Infelizmente, o NAT traduziu endereços antes de enviar
D, de modo que o endereço de origem não é o endereço que o host interno usou. Portanto,
antes de encaminhar a mensagem, o NAT precisa abrir a mensagem ICMP e traduzir os
endereços em D de modo que apareçam exatamente na forma que o host interno usou. Após
efetuar a mudança, o NAT precisa recalcular o checksum em D, o checksum no cabeçalho
ICMP e o checksum no cabeçalho de datagrama externo.
8.2.5
Interação entre NAT e aplicações
Embora o ICMP torne o NAT complexo, os protocolos de aplicação têm um efeito mais
sério. Em geral, o NAT não funcionará com qualquer aplicação que envie endereços IP ou
portas de protocolo como dados. Por exemplo, quando dois programas usam o File Transfer
Protocol (FTP), eles têm uma conexão TCP entre si. Como parte do protocolo, um programa
obtém uma porta de protocolo na máquina local, converte o número para ASCII e envia o
resultado através de uma conexão TCP para outro programa. Se a conexão entre os
programas atravessar o NAPT de um host interno para um host na Internet, o número de porta
no fluxo de dados precisa ser alterado para estar de acordo com o número de porta que o
NAPT selecionou em vez da porta que o host interno está usando. Na verdade, se o NAT
falhar em abrir o fluxo de dados e mudar o número, o protocolo falhará. Foram criadas
implementações do NAT que reconhecem protocolos populares, como o FTP, e fazem a
mudança necessária no fluxo de dados; além disso, foram criadas variantes de aplicações que
evitam a formação de conexões na direção inversa. Entretanto, é possível definir uma
aplicação que não opere através do NAT.
Mudar itens em um fluxo de dados aumenta a complexidade do NAPT de duas
maneiras. Primeiro, isso significa que o NATP precisa ter conhecimento detalhado de cada
aplicação que transfere essas informações. Segundo, se os números de porta forem
representados no ASCII, como no caso do FTP, mudar o valor pode mudar o número de
octetos transferidos. Inserir mesmo um octeto adicional em uma conexão TCP é difícil
180
porque cada octeto no fluxo tem um número sequencial. Como um emissor não sabe que
dados adicionais foram inseridos, ele continua a atribuir números sequenciais sem os dados
adicionais. Ao receber dados adicionais, o receptor gera reconhecimentos (acks) que formam
os dados. Portanto, após inserir dados adicionais, o NAT precisa traduzir os números
sequenciais em cada segmento que sai e em cada reconhecimento que entra.
8.2.6
NAT na presença de fragmentação
A descrição do NAT anterior fez uma importante suposição sobre o IP: um sistema
NAT recebe datagramas IP completos e não fragmentos. O que acontece se um datagrama
for fragmentado? Existem duas situações. Para o NAT básico, a fragmentação não
representa um problema porque cada fragmento transporta os endereços de origem e destino
IP. Porém, no caso do NAPT (a variante mais usada do NAT), a consulta de tabela utiliza
números de porta de protocolo do cabeçalho de transporte, bem como endereços IP do
cabeçalho IP. Infelizmente, apenas o primeiro fragmento de um datagrama transporta o
cabeçalho de protocolo de transporte. Assim, antes de realizar a consulta, um sistema NAPT
precisa receber e examinar o primeiro fragmento do datagrama.
Consequentemente, um sistema NAPT pode seguir um de dois projetos: o sistema pode
salvar os fragmentos e tentar remontar o datagrama, ou o sistema pode descartar os
fragmentos e processar apenas datagramas completos. Nenhuma das duas opções é
desejável. A remontagem exige informações de estado, o que significa que o sistema não
pode escalar para alta velocidade ou altos números de fluxos. O descarte de fragmentos
significa que o sistema não processará tráfego arbitrário. Na prática, apenas os sistemas
NAPT que são projetados para redes de baixa velocidade escolhem a remontagem; muitos
sistemas rejeitam datagramas fragmentados.
8.2.7
Domínios de endereço conceituais
Descrevemos o NAT como uma tecnologia que pode ser usada para conectar uma rede
privada à Internet global. Na verdade, o NAT pode ser usado para interconectar quaisquer
dois domínios de endereço. Portanto, o NAT pode ser usado entre duas corporações que
possuem, cada uma, uma rede privada usando o endereço 10.0.0.0. Mais importante, o NAT
pode ser usado em dois níveis: entre os domínios de endereço privado de um cliente e os
domínios de endereço privado de um ISP, bem como entre o domínio de endereço do ISP e
a Internet global. Finalmente, o NAT pode ser combinado com a tecnologia VPN para formar
uma arquitetura híbrida em que endereços privados são usados dentro da organização e o
NAT é usado para fornecer conectividade entre cada site e a Internet.
Como exemplo de múltiplos níveis do NAT, considere um indivíduo que trabalha em
casa com vários computadores que estão conectados a uma LAN. O indivíduo pode atribuir
endereços privados aos computadores em casa e usar o NAT entre a rede doméstica e a
intranet corporativa. A corporação também pode atribuir endereços privados e usar o NAT
entre sua intranet e a Internet global.
8.2.8
Slirp e Iptables
Duas implementações do NAT foram especialmente populares em várias ocasiões; as
duas foram projetadas para o sistema operacional UNIX. O programa slirp, derivado do 4.4
BSD, foi projetado para uso em uma arquitetura discada como a mostrada na Figura 19.4. O
slirp combina PPP e NAT em um único programa. Ele é executado em um computador que
possui: um endereço IP válido, uma conexão permanente com a Internet e um ou mais
modems discados. A maior vantagem do slirp é que ele pode usar uma conta de usuário
comum em um sistema UNIX para acesso à Internet de finalidade geral. Um computador
que tem um endereço privado efetua o logon e executa o slirp. Uma vez iniciado o slirp, a
181
linha discada comuta de comandos ASCII para PPP. O computador com acesso discado
inicia o PPP e obtém acesso à Internet (por exemplo, para acessar um Web site).
O slirp implementa o NAPT – ele usa números de porta de protocolo para
demultiplexar conexões, e pode reescrever números de porta de protocolo e também
endereços IP. É possível ter vários computadores (por exemplo, computadores em uma
LAN) acessando a Internet ao mesmo tempo através de uma única ocorrência do slirp
executando em um sistema UNIX.
Outra implementação comum do NAT foi projetada para o sistema operacional Linux.
Conhecido como iptables, o software é uma combinação de ferramentas e suporte de kernel
para reescrita de pacotes e aplicação de firewall. Como o iptables provê inspeção de pacote
com informações de estado, o NAT ou NAPT pode ser formado usando conjuntos específicos
de regras do iptables.
8.3
DNS
Os protocolos descritos anteriormente utilizam inteiros de 32 bits chamados endereços
Internet Protocol (endereços IP) para identificar as máquinas. Embora esses endereços ofereçam
uma representação conveniente e compacta para especificar a origem e o destino nos datagramas
enviados por uma internet, os usuários preferem atribuir às máquinas nomes pronunciáveis,
facilmente lembrados.
Esta seção considera um esquema para atribuir nomes de domínio de alto nível significativos
a um grande conjunto de máquinas, e discute um mecanismo que mapeia entre nomes de máquina
de alto nível e endereços IP. Ele considera a tradução dos nomes de alto nível para endereços IP
e a tradução de endereços IP para nomes de máquina de alto nível. O esquema de nomes é
interessante por dois motivos. Primeiro, ele foi usado para atribuir nomes de máquina pela
Internet. Segundo, por usar um conjunto de servidores geograficamente distribuídos para mapear
nomes a endereços, a implementação do mecanismo de mapeamento de nome oferece um exemplo
em grande escala do paradigma cliente-servidor.
8.3.1
Nomes para máquinas
Os sistemas de computador mais antigos forçavam os usuários a entender os endereços
numéricos para objetos como tabelas do sistema e dispositivos periféricos. Os sistemas de
tempo compartilhado avançaram a computação, permitindo que os usuários inventem nomes
simbólicos significativos para objetos físicos (por exemplo, dispositivos periféricos) e
objetos abstratos (por exemplo, arquivos). Um padrão semelhante surgiu nas redes de
computador. Os primeiros sistemas admitiam conexões ponto-a-ponto entre computadores e
usavam endereços de hardware de baixo nível para especificar as máquinas. A interligação
de redes introduziu o endereçamento universal e também o software de protocolo para
mapear endereços universais em endereços de hardware de baixo nível. Como a maioria dos
ambientes de computação contém várias máquinas, os usuários precisam de nomes
significativos, simbólicos, para identificá-las.
Os primeiros nomes de máquina refletiam o ambiente pequeno em que eram
escolhidos. Era bastante comum que um site com um punhado de máquinas escolhesse
nomes com base nas finalidades das máquinas. Por exemplo, as máquinas normalmente
tinham nomes como contabilidade, desenvolvimento e produção. Os usuários preferem esses
nomes a endereços de hardware complicados.
Embora a distinção entre endereço e nome seja intuitivamente atraente, ela é artificial.
Qualquer nome é simplesmente um identificador que consiste em uma seqüência de
caracteres escolhida de um alfabeto finito. Os nomes só são úteis se o sistema puder mapeá-
182
los eficientemente para o objeto que representam. Assim, pensamos em um endereço IP
como um nome de baixo nível e dizemos que os usuários preferem nomes de alto nível para
as máquinas.
O formato dos nomes de alto nível é importante porque determina como os nomes são
traduzidos para nomes de baixo nível ou vinculados a objetos, além de como as atribuições
de nome são autorizadas. Com apenas algumas máquinas, a escolha de nomes é fácil. Cada
administrador pode escolher um nome qualquer e verificar se o nome não está em uso. Por
exemplo, quando seu computador departamental principal foi conectado à Internet em 1980,
o Computer Science Department na Purdue University escolheu o nome purdue para
identificar a máquina conectada. A lista de conflitos em potencial continha apenas algumas
dezenas de nomes. Por volta de 1986, a lista oficial de host na Internet continha 3.100 nomes
oficialmente registrados e 6.500 aliases oficiais. Embora a lista estivesse crescendo
rapidamente na década de 1980, a maioria dos sites tinha máquinas adicionais (por exemplo,
computadores pessoais) que não eram registrados. Na Internet atual, com centenas de
milhões de máquinas, a escolha de nomes simbólicos é muito mais difícil.
8.3.2
Espaço de nomes plano
O conjunto original de nomes de máquina usados pela Internet formou um espaço de
nomes plano, em que cada nome consistia em uma sequência de caracteres sem qualquer
estrutura adicional. No esquema original, um site central, o Network Information Center
(NIC), administrava o namespace e determinava se um novo nome era apropriado (ou seja,
ele proibia nomes obscenos ou nomes novos que entravam em conflito com os nomes
existentes).
A principal vantagem de um espaço de nomes plano é que os nomes são convenientes
e curtos; a principal desvantagem é que um espaço de nomes plano não pode generalizar para
conjuntos grandes de máquinas por motivos técnicos e administrativos. Primeiro, como os
nomes são tirados de um único conjunto de identificadores, o potencial para conflito aumenta
à medida que o número de sites aumenta. Segundo, como a autoridade para acrescentar novos
nomes precisa estar em um único site, a carga de trabalho administrativa nesse site central
também aumenta com o número de sites. Para entender a seriedade do problema, imagine
uma rede de crescimento rápido com milhares de sites, cada um com centenas de
computadores pessoais e estações de trabalho individuais. Toda vez que alguém adquire e
conecta um novo computador pessoal, seu nome precisa ser aprovado pela autoridade central.
Terceiro, como os vínculos entre nome e endereço mudam com frequência, o custo de manter
cópias corretas da lista inteira em cada site é alto e aumenta à medida que o número de sites
cresce. Como alternativa, se o banco de dados de nomes residir em um único site, o tráfego
da rede para esse site aumenta com o número de sites.
8.3.3
Nomes hierárquicos
Como um sistema de nomeação pode acomodar um conjunto de nomes grande e em
expansão rápida sem exigir que um site central o administre? A resposta está na
descentralização do mecanismo de nomes, delegando autoridade para partes do espaço de
nomes e distribuindo a responsabilidade pelo mapeamento entre nomes e endereços. A
Internet utiliza esse esquema. Antes de examinar os detalhes, vamos considerar a motivação
e a intuição por trás disso.
O particionamento de um espaço de nomes precisa ser definido de modo que admita o
mapeamento eficiente de nome e garanta o controle autônomo da atribuição de nomes. A
otimização apenas para mapeamento eficiente pode levar a soluções que retêm um espaço de
nomes plano e reduzem o tráfego dividindo os nomes entre várias máquinas de mapeamento.
183
A otimização apenas por facilidade administrativa pode levar a soluções que tornam a
delegação de autoridade fácil, mas o mapeamento de nomes dispendioso ou complexo.
Para entender como o espaço de nomes deve ser dividido, considere a estrutura interna
de grandes organizações. No topo, um diretor executivo tem responsabilidade geral. Como
o diretor não pode supervisionar tudo, a organização pode ser particionada em divisões, com
um executivo encarregado de cada divisão. O diretor executivo concede a cada divisão
autonomia dentro de limites especificados. Mais diretamente ao ponto, o executivo
encarregado de determinada divisão pode contratar ou demitir funcionários, atribuir
escritórios e delegar autoridade, sem pedir autorização direta do diretor executivo.
Além de facilitar a delegação de autoridade, a hierarquia de uma organização grande
apresenta operação autônoma. Por exemplo, quando um trabalhador de escritório precisa de
informações como o número de telefone de um novo funcionário, ele ou ela começa
perguntando aos funcionários administrativos locais (que podem contatar funcionários
administrativos em outras divisões). O ponto é que, embora a autoridade sempre passe para
baixo na hierarquia corporativa, a informação pode fluir pela hierarquia de um escritório para
outro.
8.3.4
Delegação de autoridade para nomes
Um esquema de nomes hierárquico funciona como a administração de uma grande
organização. O espaço de nomes é particionado no nível superior, e a autoridade para nomes
em subdivisões é passada para agentes designados. Por exemplo, alguém poderia decidir
particionar o espaço de nomes com base no nome do site e delegar a cada site
responsabilidade por manter nomes dentro de sua partição. O nível superior da hierarquia
divide o espaço de nomes e delega autoridade para cada divisão; ele não precisa se preocupar
com mudanças dentro de uma divisão.
Em geral, a sintaxe dos nomes atribuídos hierarquicamente reflete a delegação
hierárquica de autoridade usada para atribuí-los. Como exemplo, considere um espaço de
nomes no formato:
local.site
onde o site é o nome do site autorizado pela autoridade central, local é a parte de um nome
controlada pelo site e o ponto (“.”) é um delimitador usado para separá-los. Quando a
autoridade superior aprova a inclusão de um novo site, X, ela acrescenta X à lista de sites
válidos e delega ao site X autoridade para todos os nomes que terminam com “.X”.
8.3.5
Autoridade de subconjunto
Em um espaço de nomes hierárquico, a autoridade pode ser subdividida ainda mais em
cada nível. Em nosso exemplo de partição por sites, o próprio site pode consistir em vários
grupos administrativos, e a autoridade do site pode escolher subdividir seu espaço de nomes
entre os grupos. A ideia é manter a subdivisão do espaço de nomes até que cada subdivisão
seja pequena o suficiente para ser administrável.
Sintaticamente, a subdivisão do espaço de nomes introduz outra partição do nome. Por
exemplo, a inclusão de uma subdivisão de grupo para nomes já particionados por site produz
a seguinte sintaxe de nome:
local.group.site
Como o nível mais alto delega autoridade, os nomes de grupo não precisam combinar
entre todos os sites. Um site de universidade poderia escolher nomes de grupo como
184
engenharia, ciência e artes, enquanto um site corporativo poderia escolher nomes de grupo
como produção, contabilidade e pessoal.
O sistema telefônico dos Estados Unidos oferece outro exemplo de sintaxe de nomes
hierárquica. Os dez dígitos de um número de telefone foram particionados em um código de
área de três dígitos, uma central de três dígitos e um número de assinante de quatro dígitos
dentro da central. Cada central tem autoridade para atribuir números de assinante dentro de
sua parte do espaço de nomes. Embora seja possível agrupar assinantes quaisquer em centrais
e agrupar centrais quaisquer em códigos de área, a atribuição de números de telefone não é
caprichosa; eles são cuidadosamente escolhidos para facilitar o roteamento de chamadas
telefônicas pela rede telefônica.
O exemplo de telefone é importante porque ilustra uma distinção básica entre o
esquema de nomes hierárquico usado em uma internet TCP/IP e outras hierarquias: o
particionamento do conjunto de máquinas possuídas por uma organização por linhas de
autoridade não necessariamente implica o particionamento do local físico. Por exemplo,
pode ser que, em alguma universidade, um único prédio acomode o departamento de
matemática e também o departamento de ciência da computação. Pode acontecer até mesmo
que, embora as máquinas desses dois grupos fiquem sob domínios administrativos
completamente separados, elas se conectem à mesma rede física. Também pode acontecer
que um único grupo possua máquinas em várias redes físicas. Por esses motivos, o esquema
de nomes do TCP/IP permite a delegação arbitrária de autoridade para o espaço de nomes
hierárquico sem considerar as conexões físicas.
Naturalmente, em muitos sites, a hierarquia organizacional corresponde à estrutura das
interconexões físicas da rede. Por exemplo, suponha que os computadores em determinado
departamento se conectem à mesma rede. Se o departamento também receber parte da
hierarquia de nomes, todas as máquinas com nomes nessa parte da hierarquia também se
conectarão a uma única rede física.
8.3.6
Internet Domain Names
O Domain Name System (DNS) é o sistema que fornece mapeamento de nome para
endereço para a Internet. O DNS possui dois aspectos conceitualmente independentes. O
primeiro é abstrato: ele especifica a sintaxe de nome e as regras para delegar autoridade sobre
os nomes. O segundo é concreto: ele especifica a implementação de um sistema de
computação distribuído que eficientemente mapeia nomes a endereços. Esta seção considera
a sintaxe de nome, e outras seções examinam a implementação.
O Domain Name System utiliza um esquema de nomes hierárquico conhecido como
nomes de domínio. Assim como em nossos exemplos anteriores, um nome de domínio
consiste em uma sequência de subnomes separados por um caractere delimitador, o ponto.
Em nossos exemplos, dissemos que as seções individuais do nome poderiam representar sites
ou grupos, mas o sistema de nome de domínio simplesmente chama cada seção de label.
Assim, o nome de domínio
cs.purdue.edu
contém três labels: cs, purdue e edu. Qualquer sufixo de um rótulo em um nome de
domínio também é chamado de domínio. Nesse exemplo, o domínio de nível mais baixo é
cs.purdue.edu (o nome de domínio para o Computer Science Department na Purdue
University), o domínio de segundo nível é purdue.edu (o nome de domínio para a Purdue
University), e o domínio de alto nível é edu (o nome de domínio para instituições
educacionais). Como o exemplo mostra, os nomes de domínio são escritos com o rótulo local
185
primeiro e o domínio superior por último. Conforme veremos, sua escrita na ordem
possibilita a compactação de mensagens que contêm vários nomes de domínio.
8.3.7
Domínios de nível superior
Conceitualmente, os nomes de nível superior permitem duas hierarquias de nomes
completamente diferentes: geográfica e organizacional. O esquema geográfico divide o
universo de máquinas por país. As máquinas nos Estados Unidos ficam sob o domínio de
nível superior us; quando outro país deseja registrar máquinas no sistema de nome de
domínio, a autoridade central atribui ao país um novo domínio de nível superior com o
identificador de padrão internacional do país com duas letras como seu label. A autoridade
para o domínio US escolheu dividi-lo em um domínio de segundo nível por estado. Por
exemplo, o domínio para o estado de Virginia é
va.us
A Tabela 8.2 lista os nomes de domínio superior.
Nome do Domínio
Significado
aero
arpa
biz
com
coop
edu
gov
info
int
mil
museum
name
net
org
pro
Código do país
Setor de transporte aéreo
Domínio de infra-estrutura
Negócios
Organização comercial
Associações cooperativas
Instituição educacional (4 anos)
Governo dos Estados Unidos
Informação
Organizações de tratado internacional
Militares dos Estados Unidos
Museus
Indivíduos
Principais centros de suporte de rede
Organizações diferentes das citadas
Profissionais credenciados
Cada país (esquema geográfico:br=Brasil; il=Israel; pt=Portugal)
Tabela 8.2 – Os domínios de Internet de nível superior e seus significados.
Como alternativa à hierarquia geográfica, os domínios de alto nível também permitem
que as organizações sejam agrupadas por tipo organizacional. Quando uma organização
deseja participar do sistema de nomes de domínio, ela escolhe como deseja ser registrada e
requisita aprovação. Um registrador de nome de domínio revê a aplicação e atribui um
subdomínio à organização sob um dos domínios existentes de nível superior. O proprietário
de determinado domínio de alto nível pode decidir o que permitir e como particionar o espaço
de nomes ainda mais. Por exemplo, no Reino Unido, que possui o código de país de duas
letras uk, as universidades e outras instituições acadêmicas são registradas sob o domínio
ac.uk.
Um exemplo poderá ajudar a esclarecer o relacionamento entre a hierarquia de nomes
e a autoridade para nomes. Uma máquina chamada xinu no Computer Science Department
da Purdue University tem o nome de domínio oficial
xinu.cs.purdue.edu
186
O nome da máquina foi aprovado e registrado pelo administrador da rede local no
Computer Science Department. O administrador do departamento anteriormente obteve
autoridade para o subdomínio cs.purdue.edu por uma autoridade de rede da universidade, que
obteve permissão para administrar o subdomínio purdue.edu da autoridade da Internet. A
autoridade da Internet retém controle do domínio edu, de modo que novas universidades só
podem ser acrescentadas com sua permissão. De modo semelhante, o gerente de rede da
universidade, na Purdue University, retém autoridade para o subdomínio purdue.edu, de
modo que novos domínios de terceiro nível só podem ser acrescentados com a permissão do
administrador.
A Figura 8.4 ilustra uma pequena parte da hierarquia de nome de domínio da Internet.
Como mostra a figura, a IBM Corporation, uma organização comercial, registrou-se como
ibm.com, a Purdue University registrou-se como purdue.edu, e a National Science
Foundation, uma agência do governo, registrou-se como nsfgov. Ao contrário, a
Corporation for National Research Initiatives decidiu registrar-se sob a hierarquia geográfica
como cnn.reston.va.us.
Figura 8.4 – Uma pequena parte da hierarquia de nome de domínio da Internet.
8.3.8
Sintaxe e tipo de nome
O sistema de nome de domínio é bastante genérico, pois permite que várias hierarquias
de nomes sejam incorporadas em um sistema. Para permitir que os clientes distingam entre
vários tipos de entradas, cada item nomeado armazenado no sistema recebe um tipo que
especifica se ele é o endereço de uma máquina, uma caixa de correio, um usuário e assim por
diante. Quando um cliente pede ao sistema de domínio para traduzir um nome, ele precisa
especificar o tipo de resposta desejada. Por exemplo, quando uma aplicação de e-mail usa o
sistema de domínio para traduzir um nome, ela especifica que a resposta deve ser o endereço
de uma central de correio. Uma aplicação de login remoto especifica que busca o endereço
IP de uma máquina. É importante entender o seguinte: determinado nome pode ser mapeado
em mais de um item no sistema de domínio. O cliente especifica o tipo de objeto desejado
ao traduzir um nome, e o servidor retorna objetos desse tipo.
Além de especificar o tipo de resposta procurada, o sistema de domínio permite que o
cliente especifique a família de protocolo a usar. O sistema de domínio particiona o conjunto
187
inteiro de nomes por classe, permitindo que um único banco de dados armazene
mapeamentos para vários conjuntos de protocolos.
A sintaxe de um nome não determina que tipo de objeto ele nomeia ou a classe do
conjunto de protocolos. Em particular, o número de labels em um nome não determina se o
nome se refere a um objeto individual (máquina) ou um domínio. Assim, em nosso exemplo,
é possível ter uma máquina chamada
gwen.purdue.edu
embora
cs. purdue. edu
nomeie um subdomínio. Podemos resumir este ponto importante: não se pode distinguir os
nomes dos subdomínios dos nomes dos objetos individuais ou do tipo de um objeto usando
apenas a sintaxe do nome de domínio.
8.3.9
Mapeando nomes de domínio para endereços
Além das regras para a sintaxe de nome e delegação de autoridade, o esquema de nome
de domínio inclui um sistema distribuído eficiente, confiável, de uso geral, para mapear
nomes a endereços. O sistema é distribuído no sentido técnico, significando que um conjunto
de servidores operando em vários sites soluciona cooperativamente o problema de
mapeamento. Ele é eficiente no mesmo sentido de que a maioria dos nomes pode ser
mapeada localmente; somente alguns exigem tráfego de internet. Ele é de uso geral porque
não está restrito a nomes de máquina (embora usaremos esse exemplo por enquanto).
Finalmente, ele é confiável porque nenhuma falha de máquina isolada impedirá que o sistema
opere corretamente.
O mecanismo de domínio para o mapeamento de nomes a endereços consiste em
sistemas independentes, cooperativos, chamados servidores de nome. Um servidor de nome
é um programa servidor que fornece tradução de nome para endereço, mapeando de nomes
de domínio para endereços IP. Normalmente, o software servidor é executado em um
processador dedicado, e a própria máquina é chamada servidor de nome. O software cliente,
chamado tradutor de nome, utiliza um ou mais servidores de nome ao traduzir um nome.
O modo mais fácil de entender como os servidores de domínio funcionam é imaginálos arrumados em uma estrutura de árvore que corresponde à hierarquia de nomeação, como
ilustra a Figura 8.5. A raiz da árvore é um servidor que reconhece os domínios de alto nível
e sabe qual servidor traduz cada domínio. Dado um nome para traduzir, a raiz pode escolher
o servidor correto para esse nome. No próximo nível, um conjunto de servidores de nome
oferece respostas para um domínio de alto nível (por exemplo, edu). Um servidor nesse nível
sabe quais servidores podem traduzir cada um dos subdomínios sob seu domínio. No terceiro
nível da árvore, os servidores de nomes oferecem respostas para subdomínios (por exemplo,
purdue sob edu). A árvore conceitual continua com um servidor em cada nível para o qual
um subdomínio foi definido.
188
Figura 8.5 – A organização conceitual dos servidores de nome de domínio.
Os links na árvore conceitual não indicam conexões físicas de rede. Em vez disso, eles
mostram quais outros servidores de nomes determinado servidor conhece e contata. Os
próprios servidores podem estar localizados em locais quaisquer em uma internet. Assim, a
árvore de servidores é uma abstração que usa uma internet para comunicação.
Se os servidores no sistema de domínio funcionassem exatamente como nosso modelo
simplista sugere, o relacionamento entre conectividade e autorização seria muito simples.
Quando a autoridade fosse concedida a um subdomínio, a organização que a solicitou teria
de estabelecer um servidor de nome de domínio para esse subdomínio e vinculá-lo à árvore.
Na prática, o relacionamento entre a hierarquia de nomes e a árvore de servidores não
é tão simples quanto nosso modelo implica. A árvore de servidores possui poucos níveis,
pois um único servidor físico pode conter toda a informação para grandes partes da hierarquia
de nomes. Em particular, as organizações normalmente coletam informações de todos os
seus subdomínios para um único servidor. A Figura 8.6 mostra uma organização mais realista
dos servidores para a hierarquia de nomes da Figura 8.4.
Um servidor raiz contém informações sobre a raiz e domínios de alto nível, e cada
organização utiliza um único servidor para seus nomes. Como a árvore de servidores é
superficial, no máximo dois servidores precisam ser contatados para traduzir um nome como
xinu.cs.purdue.edu: o servidor raiz e o servidor para o domínio purdue.edu (ou seja, o
servidor raiz sabe qual servidor trata de purdue.edu, e a informação de domínio inteira para
Purdue reside em um servidor).
Figura 8.6 – Uma organização realista de servidores para a Hierarquia de nomes.
189
8.3.10 Tradução de nome de domínio
Embora a árvore conceitual facilite a compreensão do relacionamento entre os
servidores, ela esconde diversos detalhes sutis. O exame do algoritmo de tradução de nomes
ajudará a explicá-los. Conceitualmente, a tradução de nome de domínio prossegue de cima
para baixo, começando com o servidor de nomes raiz e prosseguindo para servidores
localizados nas folhas da árvore. Existem duas maneiras de usar o sistema de nome de
domínio: contatando servidores de nomes um de cada vez ou pedindo ao sistema de servidor
de nomes para realizar a tradução completa. De qualquer forma, o software cliente forma
uma consulta de nome de domínio que contém o nome a ser traduzido, uma declaração da
classe do nome, o tipo da resposta desejada e um código que especifica se o servidor de
nomes deve traduzir o nome completamente. Ele envia a consulta a um servidor de nomes
para tradução.
Quando um servidor de nomes de domínio recebe uma consulta, ele verifica se o nome
se encontra no subdomínio para o qual é uma autoridade. Nesse caso, ele traduz o nome para
um endereço, de acordo com seu banco de dados, e anexa uma resposta à consulta antes de
enviá-la de volta ao cliente. Se o servidor de nomes não puder traduzir o nome
completamente, ele procura ver que tipo de interação o cliente especificou. Se o cliente
solicitou tradução completa (tradução recursiva, na terminologia de nome de domínio), o
servidor contata um servidor de nomes de domínio que pode traduzir o nome e retorna a
resposta ao cliente. Se o cliente solicitou tradução não recursiva (tradução iterativa), o
servidor de nomes não pode fornecer uma resposta. Ele gera uma resposta que especifica o
servidor de nomes que o cliente deve contatar em seguida para traduzir o nome.
Como um cliente encontra um servidor de nomes em que começará a busca? Como
um servidor de nomes encontra outros servidores de nomes que possam responder a
perguntas quando ele não puder? As respostas são simples. Um cliente precisa saber como
contatar pelo menos um servidor de nomes. Para garantir que um servidor de nome de
domínio possa alcançar outros, o sistema de domínio exige que cada servidor saiba o
endereço de pelo menos um servidor raiz1. Além disso, um servidor pode saber o endereço
de um servidor para o domínio imediatamente acima dele (chamado de pai).
Os servidores de nome de domínio utilizam uma porta de protocolo bem conhecida
para toda a comunicação, de modo que os clientes saibam como se comunicar com um
servidor uma vez conhecendo o endereço IP da máquina em que o servidor é executado. Não
existe um modo padrão para os hosts localizarem uma máquina no ambiente local em que
um servidor de nomes é executado; isso fica para quem projetar o software cliente. Em
alguns sistemas, o endereço da máquina que fornece o serviço de nome de domínio está
vinculado a programas aplicativos em tempo de compilação, enquanto em outros, o endereço
é armazenado em um arquivo no armazenamento secundário. Muitos sistemas obtêm o
endereço de um servidor de domínio automaticamente como parte do processo de bootstrap.
8.3.11 Tradução eficiente
Embora possa parecer natural resolver consultas descendo pela árvore de servidores de
nomes, isso pode causar ineficiências por três motivos. Primeiro, a maior parte da tradução
de nome se refere a nomes locais, encontrados dentro da mesma subdivisão do espaço de
nomes que a máquina da qual a requisição origina. Rastrear um caminho pela hierarquia para
contatar a autoridade local seria ineficiente. Segundo, se cada tradução de nome sempre
1
Por confiabilidade, existem vários servidores para cada nó na árvore do servidor de domínio; o servidor raiz é replicado
ainda mais para fornecer balanceamento de carga.
190
iniciasse contatando o nível mais alto da hierarquia, a máquina nesse ponto ficaria
sobrecarregada. Terceiro, a falha das máquinas nos níveis mais altos da hierarquia impediria
a tradução de nomes, mesmo que a autoridade local pudesse traduzir o nome. A hierarquia
de nomes de telefone mencionada anteriormente ajuda a explicar. Embora os números de
telefone sejam atribuídos hierarquicamente, eles são traduzidos de baixo para cima. Como a
maioria das ligações telefônicas é local, elas podem ser traduzidas pela central local sem
pesquisar a hierarquia. Além do mais, as chamadas dentro de determinado código de área
podem ser traduzidas sem contatar sites fora do código de área. Quando aplicadas a nomes
de domínio, essas ideias levam a um mecanismo de tradução de nome de duas etapas, que
preserva a hierarquia administrativa, mas permite a tradução eficiente.
Dissemos que a maioria das consultas a servidores de nomes refere-se a nomes locais.
No processo de tradução de nomes em duas etapas, a tradução começa com o servidor de
nomes local. Se o servidor local não puder traduzir um nome, a consulta precisa então ser
enviada a outro servidor no sistema de domínio.
8.3.12 Caching: a chave para a eficiência
O custo de pesquisa para nomes não locais pode ser extremamente alto se os tradutores
enviarem cada consulta ao servidor raiz. Mesmo que as consultas pudessem ir diretamente
para o servidor que tem autoridade para o nome, a pesquisa de nome pode apresentar uma
carga intensa para uma internet. Assim, para melhorar o desempenho geral de um sistema
servidor de nomes, é necessário reduzir o custo de pesquisa para nomes não locais.
Os servidores de nomes da Internet utilizam o caching para otimizar os custos de
pesquisa. Cada servidor mantém um cache de nomes recentemente usados, além de um
registro de onde a informação de mapeamento para esse nome foi obtida. Quando um cliente
pede ao servidor para traduzir um nome, o servidor primeiro verifica se tem autoridade para
o nome de acordo com o procedimento padrão. Se não, o servidor verifica seu cache para
ver se o nome foi traduzido recentemente. Os servidores dão informações do cache aos
clientes, mas as marcam como um vínculo não-autorizado, e dão o nome de domínio do
servidor, S, do qual obtiveram o vínculo. O servidor local também envia informações
adicionais que dizem ao cliente o vínculo entre S e um endereço IP. Portanto, os clientes
recebem respostas rapidamente, mas a informação pode estar desatualizada. Se a eficiência
for importante, o cliente decidirá aceitar a resposta não-autorizada e prosseguir. Se a precisão
for mais importante, o cliente decidirá contatar a autoridade e verificar se o vínculo entre
nome e endereço ainda é válido.
O caching funciona bem no sistema de nome de domínio porque os vínculos entre nome
e endereço mudam com pouca frequência. Porém, eles mudam. Se os servidores colocassem
informações em cache na primeira vez que ela fosse solicitada e nunca as atualizassem, as
entradas no cache ficariam passadas (ou seja, incorretas). Para manter o cache correto, os
servidores temporizam cada entrada e descartam as entradas que excedem um tempo
razoável. Quando um servidor precisa de informações depois que a entrada em seu cache foi
removida, ele precisa voltar à origem autorizada e obter o vínculo novamente. Mais
importante, os servidores não aplicam um único timeout fixo a todas as entradas, mas
permitem que a autoridade para uma entrada configure seu timeout. Sempre que uma
autoridade responde a uma solicitação, ela inclui um valor Time To Live (TTL) na resposta,
que especifica por quanto tempo ele garante que o vínculo permanecerá válido. Assim, as
autoridades podem reduzir o overhead de rede especificando timeouts longos para entradas
que esperam permanecer inalteradas, enquanto melhoram a exatidão especificando timeouts
curtos para entradas que deverão mudar com frequência.
191
O caching é importante nos hosts e também em servidores de nome de domínio locais.
A maioria dos softwares tradutores coloca entradas de DNS em cache no host. Assim, se um
usuário pesquisar o mesmo nome repetidamente, pesquisas subsequentes podem ser
traduzidas do cache local sem usar a rede.
8.4
Correio Eletrônico
Uma facilidade de correio eletrônico (e-mail) permite que os usuários enviem memorandos
pela Internet. O e-mail é um dos serviços mais usados, pois fornece um método rápido e
conveniente de transferir informações, acomoda pequenas notas ou memorandos grandes e
volumosos e permite a comunicação entre os indivíduos ou entre um grupo.
O correio eletrônico difere fundamentalmente da maioria dos outros usos das redes, pois um
sistema de correio precisa providenciar instâncias quando o destino remoto é temporariamente
inalcançável. Para lidar com a entrega adiada, os sistemas de correio eletrônico utilizam uma
técnica conhecida como spooling. Quando o usuário envia uma mensagem de correio, o sistema
coloca uma cópia em seu armazenamento privado (chamado spool1) junto com a identificação do
emissor, destinatário, máquina de destino e tempo de depósito. O sistema, então, inicia a
transferência para a máquina remota como uma atividade em segundo plano, permitindo que o
emissor prossiga com outras atividades computacionais. A Figura 8.7 ilustra o conceito.
O processo de transferência de correio em segundo plano se torna um cliente que usa o
sistema de nome de domínio para mapear o nome da máquina de destino a um endereço IP e
depois tenta formar uma conexão TCP com o servidor de correio na máquina de destino. Se tiver
sucesso, o processo de transferência passa uma cópia da mensagem ao servidor remoto, que
armazena a cópia na área de spool do sistema remoto. Quando o cliente e o servidor concordam
que a cópia foi aceita e armazenada, o cliente remove a cópia local. Se não puder formar uma
conexão TCP ou se a conexão falhar, o processo de transferência registra a hora em que a entrega
foi tentada e termina. O processo de transferência em segundo plano varre a área de spool
periodicamente, normalmente uma vez a cada 30 minutos, procurando correio não entregue.
Sempre que encontra uma mensagem ou sempre que um usuário deposita novo correio de saída,
o processo em segundo plano tenta a entrega. Se descobrir que uma mensagem de correio não
pode ser entregue após algumas horas, o software de correio informa ao emissor; depois de um
tempo estendido (por exemplo, 3 dias), o software de correio retorna a mensagem ao emissor.
Figura 8.7 – Componentes conceituais de uma sistema de correio eletrônico.
1
Uma área de spool de correio às vezes é chamada de fila de correio, embora o termo seja tecnicamente impreciso.
192
8.4.1
Nomes e aliases da caixa de correio
Existem três ideias importantes escondidas em nossa descrição simples da entrega de
correio. Primeiro, os usuários especificam cada destinatário dando uma string de texto que
contém dois itens separados por um sinal de arroba:
parte-local@nome-domínio
onde nome-domínio é o nome de domínio de um destino ao qual o correio deve ser entregue,
e parte-local é o endereço de uma caixa de correio nessa máquina. Por exemplo, o endereço
de correio eletrônico do professor é:
[email protected]
Segundo, os nomes usados nessas especificações são independentes de outros nomes
atribuídos às máquinas. Normalmente, uma caixa de correio é igual ao id de login de um
usuário, e o nome de domínio de um computador é usado como destino de correio. Porém,
muitos outros projetos são possíveis. Por exemplo, uma caixa de correio pode designar um
cargo como chefe-departamento. Como o sistema de nome de domínio inclui um tipo de
consulta separado para destinos de correio, é possível desacoplar os nomes de destino de
correio dos nomes de domínio normais para máquinas. Assim, o correio enviado a um
usuário em exemplo.com pode ir para uma máquina diferente de uma requisição ping enviada
ao mesmo nome. Terceiro, nosso diagrama simplista falha ao considerar o encaminhamento
de correio, em que algum correio que chega em determinada máquina é encaminhado a outra
máquina.
8.4.2
Expansão de alias e encaminhamento de correio
A maioria dos servidores de correio eletrônico fornece um software de
encaminhamento de correio (mail forwarder) que inclui um mecanismo de expansão de alias
de correio. Um encaminhador permite que as cópias de uma mensagem de entrada sejam
enviadas a um ou mais destinos. Normalmente, o servidor consulta um banco de dados
pequeno de aliases de correio para mapear um endereço de destinatário em conjunto de
endereços, A, e depois encaminha uma cópia para cada endereço em A.
Figura 8.8 – Uma extensão do sistema de correio da Figura 8.7.
Como eles podem ser muitos-para-um ou um-para-muitos, os mapeamentos de alias
aumentam substancialmente a funcionalidade e a conveniência do sistema de correio. Um
193
único usuário pode ter vários identificadores de correio, ou um grupo pode ter um único alias
de correio. No último caso, o conjunto de destinatários associado a um identificador é
chamado de lista de correspondência eletrônica. A Figura 8.8 ilustra os componentes de um
sistema de correio que admite aliases de correio e expansão de lista.
Como mostra a figura, o correio de entrada e saída passa pelo encaminhador de correio
que expande aliases. Assim, se o banco de dados de alias especificar que o endereço de
correio x é mapeado para o substituto y, a expansão de alias reescreverá o endereço de destino
x, trocando por y. O programa de expansão de alias, então, determina se y especifica um
endereço local ou remoto, de modo que saiba se deve colocar a mensagem na fila de correio
que chega ou de correio que sai.
A expansão de alias de correio pode ser perigosa. Suponha que dois sites estabeleçam
aliases em conflito. Por exemplo, suponha que o site A mapeie o endereço de correio x para
o endereço de correio y no site B, enquanto o site B mapeia o endereço de correio y no
endereço x do site A. Uma mensagem de correio enviada ao endereço x no site A poderia
ricochetear para sempre entre os dois sites1.
8.4.3
Padrões do TCP/IP para serviço de correio eletrônico
Lembre-se de que o objetivo do esforço do protocolo TCP/IP é providenciar
interoperabilidade pela maior faixa de sistemas de computador e redes possível. Para
estender a interoperabilidade do correio eletrônico, o TCP/IP divide seus padrões de correio
em dois conjuntos. Um padrão, dado na RFC 2822, especifica o formato sintático usado para
mensagens de correio; o outro padrão especifica os detalhes da troca de correio eletrônico
entre dois computadores.
De acordo com a RFC 2822, uma mensagem de correio é representada em formato
texto e dividida em duas partes: um cabeçalho e um corpo, que são separados por uma linha
em branco. O padrão para mensagens de correio especifica o formato exato dos cabeçalhos
de correio, além da interpretação semântica de cada campo de cabeçalho; ele deixa o formato
do corpo a cargo do emissor. Em particular, o padrão especifica que os cabeçalhos contêm
texto legível, dividido em linhas que consistem em uma palavra-chave seguida por um sinal
de dois pontos seguido por um valor. Algumas palavras-chave são obrigatórias, outras são
opcionais, e o restante não é interpretado. Por exemplo, o cabeçalho precisa conter uma linha
que especifica o destino. A linha começa com “To:” contém o endereço de correio eletrônico
do destinatário no restante da linha. Uma linha que começa com “From:” contém o endereço
de correio eletrônico do emissor. Opcionalmente, o emissor pode especificar um endereço
para o qual as respostas devem ser enviadas (ou seja, permitir que o emissor especifique que
as respostas devem ser enviadas para um endereço diferente da caixa de correio do emissor).
Se estiver presente, uma linha que começa com “Reply-to:” especifica o endereço para
respostas. Se não houver uma linha assim, o destinatário usará informações na linha “From:”
como endereço de retorno.
O formato da mensagem de correio é escolhido para que se torne fácil processar e
transportar dados por máquinas heterogêneas. Manter o formato do cabeçalho de correio
simples permite que ele seja usado em uma grande variedade de sistemas. Restringir as
mensagens a texto legível evita os problemas de selecionar uma representação binária padrão
e traduzir entre a representação padrão e a representação da máquina local.
1
Na prática, a maior parte dos encaminhadores de correio (mail forwarders) termina as mensagens após o número de trocas
atingir um limite predeterminado.
194
8.4.4
Simple Mail Transfer Protocol (SMTP)
Além dos formatos de mensagem, o conjunto de protocolos TCP/IP especifica um
padrão para a troca de correio entre as máquinas. Ou seja, o padrão especifica o formato
exato das mensagens que um cliente em uma máquina utiliza a fim de transferir correio para
um servidor em outra máquina. O protocolo de transferência padrão é conhecido como
Simple Mail Transfer Protocol (SMTP). Como você poderia imaginar, o SMTP é mais
simples do que o anterior Mail Transfer Protocol (MTP). O protocolo SMTP foca
especificamente como o sistema de entrega de correio subjacente passa mensagens por uma
internet de uma máquina para outra. Ele não especifica como o sistema de correio aceita
correio de um usuário ou como a interface com o usuário apresenta o correio que chega ao
usuário. Além disso, o SMTP não especifica como o correio é armazenado ou com que
freqüência o sistema de correio tenta enviar mensagens.
SMTP é surpreendentemente simples. A comunicação entre um cliente e o servidor
consiste em texto ASCII legível. Como em outros protocolos de aplicação, o programa lê os
comandos abreviados e números de 3 dígitos no início das linhas; o texto restante serve para
ajudar os humanos a depurar o software de correio. Embora o SMTP defina rigidamente o
formato do comando, os humanos podem facilmente ler uma transcrição das interações entre
um cliente e o servidor, pois cada comando aparece em uma linha separada. Inicialmente, o
cliente estabelece uma conexão de fluxo confiável com o servidor e espera que o servidor
envie uma mensagem “220 READY FOR MAIL”. (Se o servidor estiver sobrecarregado, ele
pode adiar o envio da mensagem 220 temporariamente). Ao receber a mensagem 220, o
cliente envia um comando “HELO”1 (se o cliente admitir extensões das RFC 2821, ele envia
o comando “HELO”). O final de uma linha marca o final de um comando. O servidor
responde identificando-se. Quando a comunicação tiver sido estabelecida, o emissor pode
transmitir uma ou mais mensagens de correio e depois terminar a conexão. O receptor precisa
confirmar cada comando. Ele também pode abortar a conexão inteira ou abortar a
transferência da mensagem atual.
As transações de correio começam com um comando “MAIL” que dá a identificação
do emissor e também um campo “FROM:” que contém o endereço ao qual os erros devem
ser relatados. Um destinatário prepara suas estruturas de dados para receber uma nova
mensagem de correio e responde a um comando “MAIL” enviando a resposta 250. A
resposta 250 significa que tudo está bem. A resposta completa consiste no texto “250 OK”.
Após um comando “MAIL” bem-sucedido, o emissor emite uma série de comandos
“RCPT” que identificam os destinatários da mensagem de correio. O receptor precisa
confirmar cada comando “RCPT” enviando “250 OK” ou enviando a mensagem de erro “550
No such user here”.
Depois que todos os comandos “RCPT” tiverem sido confirmados, o emissor emite um
comando “DATA”. Essencialmente, um comando “DATA” informa ao receptor que o
emissor está pronto para transferir uma mensagem de correio completa. O receptor responde
com a mensagem “354 Start mail input” e especifica a sequência de caracteres usada para
terminar a mensagem de correio. A sequência de término consiste em 5 caracteres: carriage
return, line feed, ponto, carriage return e line feed2.
1
2
HELO é uma abreviatura para “hello”
O SMTP utiliza CR-LF para terminar uma linha e não permite que o corpo de uma mensagem tenha um ponto isolado em
uma linha.
195
Um exemplo esclarecerá a troca SMTP. Suponha que o usuário Smith no host
Alpha.edu envie uma mensagem aos usuários Jones, Green e Brown, no host Beta.gov. O
software cliente SMTP no host Alpha.edu contata o software servidor de SMTP no host
Beta.gov e inicia a troca mostrada na Figura 8.9.
S: 220 Beta.gov Simple Mail Transfer Service Ready
C: HELO Alpha.edu
S: 250 Beta.gov
C: MAIL FROM:<[email protected]>
S: 250 OK
C: RCPT TO:<[email protected]>
S: 250 OK
S: 550 No such user here
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CR><LF>.<CR><LF>
C: ...envia corpo da mensagem de correio...
C: ...continua pela quantidade de linhas que a mensagem tiver
C: <CR><LF>.<CR><LF>
S: 250 OK
C: QUIT
S: 221 Beta.gov Service closing transmission channel
Figura 8.9 – Exemplo de transferência SMTP de Alpha.edu para Beta.gov.
No exemplo, o servidor rejeita o destinatário Green, pois não reconhece o nome como
um destino de correio válido (ou seja, ele nem é um usuário nem uma lista de correio). O
protocolo SMTP não especifica os detalhes de como um cliente trata desses erros, o cliente
precisa decidir. Embora os clientes possam abortar a entrega completamente se houver um
erro, a maioria dos clientes não faz isso. Em vez disso, eles continuam a entrega a todos os
destinatários válidos e depois informam sobre problemas com o emissor original.
Normalmente, o cliente informa erros usando o correio eletrônico. A mensagem de erro
contém um resumo do erro, além do cabeçalho das mensagens de correio que causaram o
problema.
Quando tiver acabado de enviar todas as mensagens de correio, um cliente emite um
comando “QUIT”. O outro lado responde com o comando 221, que significa que ele
concorda em terminar. Os dois lados, então, fecham a conexão TCP de forma controlada.
O SMTP é muito mais complexo do que esboçamos aqui. Por exemplo, se um usuário
tiver mudado, o servidor poderá saber o novo endereço da caixa de correio do usuário. O
SMTP permite que o servidor informe ao cliente sobre o novo endereço, de modo que o
cliente possa usá-lo no futuro. Ao informar ao cliente sobre um novo endereço, o servidor
pode decidir encaminhar o correio que disparou a mensagem, ou pode requisitar que o cliente
tenha responsabilidade pelo encaminhamento. Além disso, o SMTP inclui extensões
Transport Layer Security (TLS) que permitem que uma sessão SMTP seja criptografada.
8.4.5
Recuperação de correio e protocolos de manipulação de caixa de correio
O esquema de transferência SMTP descrito anteriormente implica que um servidor
precisa permanecer pronto para aceitar o correio eletrônico o tempo todo. O cenário funciona
bem se o servidor for executado em um computador que possui uma conexão permanente
com a Internet, mas não funciona bem para um computador que possui conectividade
intermitente (por exemplo, um computador laptop que está desconectado quando estiver
sendo movido). Não faz sentido que esse computador execute um servidor de correio
196
eletrônico, pois o servidor só estará disponível enquanto o computador do usuário estiver
conectado – todas as outras tentativas de contatar o servidor falharão, e o correio enviado ao
usuário permanecerá sem ser entregue. Surge a pergunta: “como um usuário sem uma
conexão permanente recebe correio eletrônico?”
A resposta para a pergunta está em um processo de entrega em dois estágios. No
primeiro estágio, cada usuário recebe uma caixa de correio em um computador que sempre
está ligada e possui uma conexão permanente com a Internet. O computador executa um
servidor SMTP convencional, que sempre permanece pronto para aceitar correio eletrônico.
No segundo estágio, o usuário se conecta à Internet e depois executa um protocolo que
apanha mensagens da caixa de correio permanente. O protocolo transfere as mensagens para
o computador do usuário, de onde elas podem ser lidas.
Existem dois protocolos que permitem que um usuário remoto acesse o correio em uma
caixa de correio permanente. Embora tenham funcionalidade semelhante, os protocolos
utilizam técnicas opostas: um permite que o usuário baixe uma cópia das mensagens, e o
outro permite que um usuário veja e manipule mensagens no servidor. As duas seções
seguintes descrevem os dois protocolos.
8.4.5.1
Post Office Protocol
O protocolo mais popular usado para transferir mensagens de correio eletrônico
de uma caixa de correio permanente para um computador local é conhecido como versão
3 do Post Office Protocol (POP3); uma versão segura do protocolo é conhecida como
POP3S. O usuário invoca um cliente POP3, que cria uma conexão TCP com um servidor
POP3 no computador da caixa de correio. O usuário primeiro envia um login e uma
senha para autenticar a sessão. Quando a autenticação tiver sido aceita, o cliente envia
comandos para apanhar uma cópia de uma ou mais mensagens e excluir a mensagem da
caixa de correio permanente. As mensagens são armazenadas e transferidas como
arquivos de texto no formato do padrão 2822.
Observe que o computador com uma caixa de correio permanente precisa executar
dois servidores – um servidor SMTP que aceita o correio enviado a um usuário e
acrescenta cada mensagem que chega à caixa de correio permanente no usuário, e um
servidor POP3 que permite que um usuário extraia mensagens da caixa de correio e as
exclua. Para garantir a operação correta, os dois servidores precisam coordenar o uso
da caixa de correio, para que, se uma mensagem chegar por SMTP enquanto um usuário
estiver extraindo mensagens via POP3, a caixa de correio fique em um estado válido.
8.4.5.2
Internet Message Access Protocol
A versão 4 do Internet Message Access Protocol (IMAP4) é uma alternativa ao
POP3, que permite que os usuários vejam e manipulem mensagens; uma versão segura
do IMAP foi definida, e é conhecida como IMAPS. Assim como POP3, IMAP4 define
uma abstração conhecida como caixa de correio; as caixas de correio estão localizadas
no mesmo computador que um servidor. Também como o POP3, um usuário executa
um cliente IMAP4 que contata o servidor para manipular mensagens. Porém, diferente
do POP3, o IMAP4 permite que um usuário acesse mensagens de correio a partir de
vários locais (por exemplo, do trabalho e de casa) e garante que todas as cópias sejam
sincronizadas e coerentes.
IMAP4 também provê funcionalidade estendida para recuperação e
processamento de mensagem. Um usuário pode obter informações sobre uma
mensagem ou examinar campos de cabeçalho sem apanhar a mensagem inteira. Além
disso, um usuário pode procurar uma string especificada e apanhar partes de uma
197
mensagem. A recuperação parcial é especialmente útil para conexões discadas de baixa
velocidade, pois significa que um usuário não precisa baixar informações inúteis.
8.5
FTP
A transferência de arquivos está entre as aplicações TCP/IP mais utilizadas e ainda
considera uma quantidade significativa de tráfego da Internet. Os protocolos de transferência de
arquivo padrão existiam para a ARPANET antes de o TCP/IP se tornar operacional. Essas
primeiras versões do software de transferência de arquivo evoluíram para um padrão atual
conhecido como File Transfer Protocol (FTP).
8.5.1
Recursos do FTP
Dado um protocolo de transporte ponto a ponto confiável como o TCP, a transferência
de arquivos pode parecer simples. Entretanto, os detalhes da autorização, nomeação e
representação entre máquinas heterogêneas tornam o protocolo complexo. Além disso, o
FTP oferece muitos recursos além da função de transferência propriamente dita.
8.5.2

Acesso interativo: Embora o FTP seja projetado para ser usado por programas, a
maioria das importações também fornece uma interface interativa que permite aos
humanos interagirem com servidores remotos.

Especificação de formato: O FTP permite que o cliente especifique o tipo e a
representação dos dados armazenados. Por exemplo, o usuário pode especificar se
um arquivo contém texto ou dados binários e se os arquivos de texto usam os
conjuntos de caracteres ASCII ou EBCDIC.

Controle de autenticação: O FTP exige que os clientes se autorizem enviando o
nome de login e uma senha para o servidor antes de requisitar transferências de
arquivo. O servidor recusa acesso a clientes que não fornecem um login e uma
senha válidos.
Modelo de processo do FTP
Como outros servidores, a maioria das implementações de servidor FTP permite acesso
concorrente por vários clientes. Os clientes usam o TCP para se conectarem a um servidor.
Como descrito anteriormente, um único processo de servidor mestre espera conexões e cria
um processo escravo para manipular cada conexão. Diferente da maioria dos servidores, no
entanto, o processo escravo FTP não realiza toda a computação necessária. Em vez disso, o
escravo aceita e manipula uma conexão de controle através do cliente, mas usa um processo
adicional e uma conexão TCP adicional para manipular cada operação de transferência de
dados. A conexão de controle transporta comandos que dizem ao servidor qual arquivo
transferir. Uma nova conexão TCP e um novo processo no lado do cliente e do servidor são
criados para cada operação de transferência de dados (ou seja, cada transferência de arquivo).
Embora os detalhes exatos da arquitetura do processo dependam dos sistemas operacionais
usados, a Figura 8.10 ilustra o conceito.
198
Figura 8.10 – Um cliente e um servidor FTP com conexões TCP entre eles.
Como mostra a Figura 8.10, o processo de controle do cliente se conecta ao processo
de controle do servidor usando uma conexão TCP, enquanto os processos de transferência de
dados associados usam sua própria conexão TCP. Em geral, os processos de controle e a
conexão de controle permanecem ativos desde que o usuário mantenha a seção FTP ativa, e
uma conexão de transferência de dados persiste para uma transferência de arquivo.
8.5.3
Números de porta TCP e conexões de dados
Quando um cliente forma uma conexão inicial com o servidor, o cliente usa um número
de porta de protocolo aleatório e localmente atribuído e contata o servidor em uma porta
conhecida (21). Um servidor que usa apenas uma porta de protocolo pode aceitar conexões
de muitos clientes porque o TCP usa os dois lados para identificar uma conexão. A pergunta
que surge é: “Quando os processos de controle criam uma nova conexão TCP para uma
determinada transferência de dados, que números de porta de protocolo eles usam?”
Obviamente, eles não podem usar o mesmo par de números de porta usados na conexão de
controle. Em vez disso, o cliente obtém uma porta não usada em sua máquina, envia o
número de porta através da conexão de controle e espera que o servidor forme uma conexão
TCP com a porta especificada. Ou seja, quando forma uma conexão de dados, o cliente FTP
se torna um servidor e o servidor FTP se torna um cliente! Interessantemente, quando forma
uma conexão de dados, o servidor FTP usa uma porta bem conhecida: a porta reservada para
transferência de dados FTP (20).
Podemos ver por que o protocolo usa duas conexões – o processo de controle do cliente
obtém uma porta local para ser usada na transferência de arquivo, cria um processo de
transferência na máquina do cliente para escutar nessa porta, comunica o número de porta
para o servidor através da conexão de controle e depois espera que o servidor estabeleça uma
conexão TCP com a porta. Em geral, além de passar comandos do usuário para o servidor,
o FTP usa a conexão de controle para permitir que os processos de controle do cliente e do
servidor coordenem seu uso das portas de protocolo TCP dinamicamente atribuídas e a
criação dos processos de transferência de dados que usam essas portas.
Como o projeto FTP original não funciona bem com firewalls de segurança e sistemas
NAT, uma extensão foi acrescentada. Conhecida como FTP passivo, a extensão permite que
um cliente inicie cada conexão de transferência de dados, o que significa que o FTP pode ser
usado através de um firewall ou sistema NAT sem ser um caso especial. A maioria dos
servidores e clientes FTP aceita a extensão de FTP passivo.
Que formato o FTP deve usar para transferência de dados através da conexão de
controle? Embora pudessem ter inventado uma nova especificação, os projetistas do FTP
199
não o fizeram. Em vez disso, eles permitem que o FTP use o protocolo de terminal virtual
de rede TELNET. Diferente do protocolo TELNET completo, o FTP não permite negociação
de opção. Em vez disso, o FTP usa apenas a definição NVT básica, que torna o
gerenciamento de uma conexão de controle FTP muito mais simples do que o gerenciamento
de uma conexão TELNET. Apesar de suas limitações, usar a definição TELNET em vez de
criar uma nova definição ajuda a simplificar o FTP consideravelmente.
8.5.4
A visão do usuário do FTP
Embora o FTP tenha sido originalmente implementado como um programa aplicativo
interativo, poucos usuários agora chamam o FTP diretamente. Em vez disso, muitos usuários
acessam FTP através de um navegador Web. Portanto, suponha que alguém tenha colocado
uma cópia on-line de um livro-texto em um arquivo chamado tcpbook.tar no diretório
/pub/comer no computador ftp.cs.purdue.edu. Para obter uma cópia, um usuário pode iniciar
um navegador e digitar o seguinte URL:
ftp://ftp.cs.purdue.edu/pub/comer/tcpbook.tar
O navegador recuperará uma cópia do arquivo. Além disso, se o usuário digitar uma
URL que corresponda a um diretório, o navegador exibirá uma lista dos arquivos no diretório:
ftp://ftp.cs.purdue.edu/pub/comer
8.5.5
FTP anônimo
Embora o mecanismo de autorização do FTP possa ajudar a impedir que arquivos
confidenciais sejam acessados, exigir um login e uma senha proíbe que os usuários acessem
arquivos públicos até que o usuário obtenha uma conta. Para fornecer acesso a arquivos
públicos, a maioria dos sites TCP/IP permite FTP anônimo. O acesso de FTP anônimo
significa que um cliente não precisa de uma conta ou senha. Em vez disso, o usuário
especifica o nome de login anonymous e uma senha igual ao endereço de e-mail do usuário
ou a senha guest. Um servidor que permite logins anônimos restringe o acesso a arquivos
publicamente disponíveis.
8.6
World Wide Web – HTTP
Até a década de 90, a Internet era usada basicamente por pesquisadores, acadêmicos e
estudantes universitários. Eles a usavam para se interligar com hosts remotos, transferir arquivos
de hosts locais para hosts remotos e vice-versa, enviar e receber notícias e enviar e receber correio
eletrônico. Embora essas aplicações fossem (e continuem a ser) muito úteis, a Internet não era
conhecida fora das comunidades acadêmica e de pesquisa. Então, no início da década de 90,
entrou em cena a aplicação-chave da Internet – a WWW. A Web foi a aplicação da Internet que
chamou a atenção do público em geral. Ela está provocando uma drástica transformação na
maneira como as pessoas interagem dentro e fora de seu ambiente de trabalho. Ela gerou milhares
de novas empresas. Elevou a Internet do nível que ocupava, como apenas mais uma das muitas
redes de dados (inclusive redes on-line como a Prodigy, a America Online e a Compuserve, redes
de dados de alcance nacional como a Minitel/franspac da França, a rede privada X.25 e as redes
frame relay), para o nível que agora ocupa, como, essencialmente, a única rede de dados.
A história está repleta de exemplos de lançamentos de tecnologias de comunicação
eletrônica que provocaram enormes impactos sociais. A primeira dessas tecnologias foi o
telefone, inventado na década de 1870. O telefone permitiu que duas pessoas se comunicassem
oralmente em tempo real, sem que estivessem na mesma localização física. Ele causou um grande
impacto na sociedade – tanto bom quanto mau. Outra tecnologia de comunicação eletrônica que
200
provocou enorme impacto social foi a transmissão de grande alcance de rádio/televisão. Surgida
no período 1920 – 1930, a transmissão de rádio (e mais tarde a de televisão) permitiu que o público
recebesse vastas quantidades de informação. Ela também causou um enorme impacto na
sociedade – tanto bom quanto mau. A terceira grande tecnologia de comunicação que mudou o
modo de viver das pessoas foi a Web. Talvez o que mais atrai a maioria dos usuários da Web é o
fato de ela funcionar por demanda. Os usuários recebem o que querem e quando querem. Isso
não é igual à transmissão de rádio e de televisão, que força o usuário a “sintonizar” apenas quando
o provedor disponibiliza o conteúdo. Além de funcionar por demanda, a Web tem muitas outras
características maravilhosas que as pessoas adoram e apreciam. É muitíssimo fácil para qualquer
indivíduo fazer com que uma informação fique disponível na Web; todo mundo pode se
transformar em editor a um custo extremamente baixo. Os hiperlinks e os dispositivos de busca
nos ajudam a navegar pelo oceano dos sites Web. Gráficos e animações gráficas estimulam nossos
sentidos. Formulários, applets e componentes Active X, bem como muitos outros dispositivos,
nos habilitam a interagir com as páginas e os sites. E a Web está sempre oferecendo mais e mais
menus de interface para vastas quantidades de material de vídeo e áudio armazenados na
Internet – áudio e vídeo que podem ser acessados por demanda.
8.6.1
Descrição Geral do HTTP.
O HTTP (HiperText Transfer Protocol – Protocolo de Transferência de Hipertextos),
o protocolo de camada de aplicação da Web, está implementado em dois programas: um
programa cliente e um programa servidor. O programa cliente e o programa servidor,
executados em diferentes sistemas finais, “conversam” pela troca de mensagens HTTP. O
HTTP define a estrutura dessas mensagens e o modo como o cliente e o servidor trocam as
mensagens. Antes de examinarmos detalhadamente o HTTP, é bastante útil revisarmos a
terminologia da Web.
Uma página Web (Web Page – também chamada de documento) é constituída de
objetos. Um objeto é simplesmente um arquivo – tal como um arquivo HTML, uma imagem
JPEG, uma imagem GIF, um applet Java, um clipe de áudio e assim por diante – que se pode
acessar por meio de uma única URL. A maioria das páginas Web é constituída de um
arquivo-base HTML e diversos objetos relacionados. Por exemplo, se uma página Web
contiver texto em HTML e cinco imagens JPEG, então a página Web tem seis objetos: o
arquivo-base em HTML e mais as cinco imagens. O arquivo-base HTML relaciona os outros
objetos da página com suas URLs. Cada URL tem dois componentes: o nome do host do
servidor que abriga o objeto e o nome do caminho do objeto. Por exemplo, a URL
www.someSchool.edu/someDepartment/picture.gif
tem www.someSchool.edu como nome de host e /someDepartment/picture.gif como nome
do caminho. Um browser é um agente usuário para a Web; ele apresenta a página Web
solicitada e fornece numerosas características de navegação e de configuração. Os browsers
Web também implementam o lado cliente do HTTP. Assim, no contexto da Web, podemos
permutar as palavras “browser” e “cliente”. São browsers populares o Netscape
Communicator e o Microsoft Internet Explorer. Um servidor Web abriga objetos Web, cada
um endereçado por uma URL. Os servidores Web também implementam o lado servidor do
HTTP. Dentre os servidores populares da Web estão o Apache, o Microsoft Internet
Information Server e o Netscape Enterprise Server.
O HTTP define como os clientes Web (isto é, os browsers) solicitam páginas Web aos
servidores (isto é, aos servidores Web) e como os servidores transferem páginas Web aos
clientes. Vamos discutir em detalhes a interação entre cliente e servidor mais adiante, mas a
idéia geral está ilustrada na Figura 8.11. Quando um usuário solicita uma página Web (por
201
exemplo, clica sobre um hiperlink), o browser envia ao servidor mensagens de requisição
HTTP para os objetos da página. O servidor recebe as requisições e responde com uma
mensagem de resposta HTTP que contém os objetos. Até 1997, essencialmente todos os
browsers e servidores Web implementavam a versão HTTP/1.0, que é definida no RFC 1945.
A partir de 1998, alguns servidores Web e browsers começaram a implementar a versão
HTTP/1.1, que está definida no RFC 2616. O HTTP/1.1 é compatível com o HTTP/1.0; um
servidor Web que roda a versão 1.1 pode “conversar” com um browser que roda a versão 1.0,
e um browser que roda a versão 1.1 pode “conversar” com um servidor que roda a versão
1.0.
Figura 8.11 – Comportamento de requisição-resposta do HTTP.
Tanto o HTTP/1.0 quanto o HTTP/1.1 usam o TCP como seu protocolo de transporte
subjacente (em vez de utilizarem o UDP). O cliente HTTP primeiramente inicia uma
conexão TCP com o servidor. Assim que a conexão é estabelecida, os processos do browser
e do servidor acessam o TCP por meio de sua interface de porta. Como descrito
anteriormente, no lado cliente a porta é o meio de comunicação entre o processo cliente e a
conexão TCP; no lado servidor, ela é o caminho entre o processo servidor e a conexão TCP.
O cliente envia mensagens de requisição HTTP para a interface desse protocolo através da
porta e recebe mensagens de resposta HTTP de sua interface de porta. De maneira
semelhante, o servidor HTTP recebe mensagens de requisição de sua interface de porta e
envia mensagens de resposta através da interface de porta. Assim que o cliente envia uma
mensagem para sua interface de porta, a mensagem “sai de suas mãos” e “passa para as mãos
do TCP”. Lembre-se de que o TCP fornece ao HTTP um serviço confiável de transferência
de dados. Isso significa que toda mensagem de requisição HTTP emitida por um processo
cliente chegará intacta ao servidor. Percebemos, nesse ponto, uma das grandes vantagens de
uma arquitetura de camadas – o HTTP não precisa se preocupar com dados perdidos ou com
os detalhes de como o TCP recupera a perda de dados ou os reordena dentro da rede. Esta é
uma tarefa do TCP e dos protocolos das camadas mais inferiores da pilha de protocolos.
O TCP também emprega um mecanismo de controle de congestionamento. Esse
mecanismo força toda nova conexão TCP a transmitir, de início, dados a uma velocidade
relativamente baixa, mas depois permite que toda conexão acelere até uma velocidade
relativamente alta quando a rede não está congestionada. A fase inicial de transmissão
vagarosa é conhecida como partida lenta.
202
É importante notar que o servidor envia os arquivos solicitados ao cliente sem
armazenar nenhuma informação de estado sobre o cliente. Se um determinado cliente solicita
o mesmo objeto duas vezes em um período de poucos segundos, o servidor não responde
dizendo que ele acabou de servir o objeto ao cliente; em vez disso, ele reenvia o objeto, pois
já esqueceu completamente o que fez antes. Como o servidor HTTP não mantém nenhuma
informação sobre os clientes, ele é chamado de protocolo sem estado.
8.6.2
Conexões não persistentes e conexões persistentes
O HTTP pode usar conexões não persistentes e conexões persistentes. O HTTP/l.0 usa
conexões não persistentes. O modo default do HTTP/1.1, por sua vez, usa conexões
persistentes.
8.6.2.1
Conexões não persistentes
Vamos percorrer os estágios da transferência de uma página Web de um servidor
para um cliente para o caso de conexões não persistentes. Suponha que uma página
consista em um arquivo-base HTML e em dez imagens JPEG e que todos esses 11
objetos residam no mesmo servidor. Suponha também que a URL para o arquivo-base
HTTP seja
www.someSchool.edu/someDepartment/home.index.
Eis o que acontece:
1. O cliente HTTP inicia uma conexão TCP para o servidor www.someSchool.edu. O
número de porta 80 é usado como número de porta default na qual o servidor HTTP
estará na escuta pelos clientes HTTPs que queiram extrair documentos usando o
HTTP.
2. O cliente HTTP envia uma mensagem de requisição HTTP ao servidor através da
porta associada à conexão TCP que foi estabelecida no estágio 1. A mensagem de
requisição inclui o nome do caminho /someDepartment/home.index. (Discutiremos
as mensagens HTTP em detalhes mais adiante.)
3. O servidor HTTP recebe a mensagem de requisição através da porta associada à
conexão que foi estabelecida no estágio 1, recupera o objeto
/someDepartment/home.index de seu sistema de armazenamento (RAM ou disco),
encapsula o objeto em uma mensagem de resposta HTTP e envia a mensagem de
resposta ao cliente através da porta.
4. O servidor HTTP ordena que o TCP encerre a conexão TCP. (Mas o TCP, na
realidade, só encerrará a conexão quando o cliente receber a mensagem de resposta
intacta).
5. O cliente HTTP recebe a mensagem de resposta. A conexão TCP é encerrada. A
mensagem mostra que o objeto encapsulado é um arquivo HTML. O cliente extrai
o arquivo da mensagem de resposta, analisa o arquivo HTML e encontra referências
a dez objetos JPEG.
6. Os primeiros quatro estágios são repetidos para cada um dos objetos JPEG
referenciados.
À medida que o browser recebe a página Web, ele a apresenta ao usuário. Dois
browsers diferentes podem interpretar (isto é, apresentar ao usuário) uma página Web
de modos um tanto diferentes. O HTTP não tem nada a ver com o modo como uma
página Web é interpretada por um cliente. As especificações do HTTP [RFC 1945] e
203
[RFC 2616] apenas definem o protocolo de comunicação entre o programa cliente HTTP
e o programa servidor HTTP.
Os estágios apresentados usam conexões não persistentes porque cada conexão
TCP é fechada depois que o servidor envia o objeto – a conexão não persiste para outros
objetos. Note que cada conexão TCP transporta exatamente uma mensagem de
requisição e uma mensagem de resposta. Assim, nesse exemplo, quando um usuário
solicita uma página Web, são geradas 11 conexões TCP.
Nos estágios descritos, fomos intencionalmente vagos sobre se os clientes obtêm
as dez JPEGs por meio de dez conexões TCP em série ou se algumas das JPEGs são
obtidas por conexões TCP paralelas. De fato, os usuários podem configurar os browsers
modernos para controlar o grau de paralelismo. Nos modos default, a maioria dos
browsers abre de cinco a dez conexões TCP paralelas, cada uma das quais manipula uma
transação requisição/resposta. Se o usuário preferir, o número máximo de conexões
paralelas poderá ser fixado em um, caso em que as dez conexões são estabelecidas em
série. Como veremos no próximo capítulo, o uso de conexões paralelas reduz o tempo
de resposta.
Antes de continuarmos a análise, vamos fazer um cálculo simples para estimar o
tempo que transcorre entre um cliente fazer a requisição de um arquivo-base HTTP e
receber o arquivo. Para essa finalidade, vamos definir o tempo de viagem de ida e volta
(round-trip time – RTT), ou seja, o tempo que leva para um pequeno pacote viajar do
cliente ao servidor e de volta ao cliente. O RTT inclui os atrasos de propagação de
pacotes, os atrasos de fila de pacotes nos roteadores e comutadores intermediários e os
atrasos de processamento de pacotes. Considere, agora, o que acontece quando um
usuário clica sobre um hiperlink. Isso faz com que o browser inicie uma conexão TCP
entre ele e o servidor Web e envolve um “aperto de mãos em três vias” – o cliente envia
uma pequena mensagem TCP ao servidor, que reconhece e responde com uma pequena
mensagem ao cliente, que, por fim, reconhece novamente o servidor. O RTT transcorre
depois das duas primeiras partes do aperto de mãos em três vias. Após completar as
duas primeiras partes do aperto de mãos, o cliente envia a mensagem de requisição
HTTP por meio da conexão TCP e o TCP “dá uma carona” ao último reconhecimento
(a terceira parte do aperto de mãos em de três vias) na mensagem de requisição. Assim
que a mensagem de requisição chega ao servidor, ele envia o arquivo HTML por meio
da conexão TCP. Essa requisição/resposta HTTP causa mais um RTT. Assim, em linhas
gerais, o tempo total de resposta são dois RTTs mais o tempo de transmissão do arquivo
HTML no servidor.
8.6.2.2
Conexões Persistentes
As conexões não persistentes têm algumas desvantagens. Em primeiro lugar, uma
nova conexão deve ser estabelecida e conservada para cada objeto solicitado. Para cada
uma dessas conexões, devem ser alocados buffers do TCP e conservadas variáveis do
TCP tanto no cliente quanto no servidor. Isso pode sobrecarregar seriamente o servidor
Web, que poderá estar processando requisições de centenas de diferentes clientes ao
mesmo tempo. Em segundo lugar, como acabamos de descrever, cada objeto sofre dois
RTTs – um RTT para estabelecer a conexão TCP e um RTT para solicitar e receber o
objeto. Por fim, cada objeto sofre com a partida lenta do TCP, porque cada conexão
TCP se inicia com uma fase de partida lenta de TCP. Todavia, os impactos dos atrasos
de RTT e das partidas lentas podem ser parcialmente aliviados pelo uso de conexões
TCP paralelas.
204
Nas conexões persistentes, o servidor deixa a conexão TCP aberta após ter enviado
uma resposta. As requisições e respostas subseqüentes entre os mesmos cliente e
servidor podem ser enviadas por meio da mesma conexão. Em particular, uma página
Web inteira (no exemplo anterior, o arquivo-base HTML e as dez imagens) pode ser
enviada mediante uma única conexão TCP persistente. Além disso, múltiplas páginas
Web, residindo no mesmo servidor, podem ser enviadas por meio de uma única conexão
TCP persistente. Normalmente, o servidor HTTP fecha uma conexão quando ela não é
usada durante um tempo determinado (o intervalo de pausa), o que quase sempre é
configurável. Há duas versões de conexões persistentes: sem paralelismo e com
paralelismo. Para a versão sem paralelismo, o cliente lança uma nova requisição
somente quando a resposta prévia é recebida. Nesse caso, cada um dos objetos
relacionados (as dez imagens do exemplo anterior) sofre um RTT para solicitar e receber
o objeto. Embora isso seja uma melhoria em relação aos dois RTTs da conexão não
persistente, o atraso de RTT pode ser reduzido ainda mais com paralelismo. Outra
desvantagem de não se ter paralelismo é que, após o servidor enviar um objeto por meio
de uma conexão TCP persistente, a conexão fica pendurada – não faz nada – enquanto
espera a chegada de outra requisição. Isso causa desperdício de recursos do servidor.
O modo default do HTTP/1.1 usa conexões persistentes com paralelismo. Nesse
caso, o cliente HTTP lança uma requisição assim que ele encontra uma referência. Desse
modo, ele pode fazer requisições completas para os objetos relacionados. Quando o
servidor recebe as requisições, ele pode enviar todos os objetos. Se todas as requisições
forem enviadas completas e todas as respostas forem devolvidas da mesma maneira,
então se gastará apenas um RTT para todos os objetos relacionados (em vez de um RTT
por objeto relacionado como quando não se está usando paralelismo). E mais, a conexão
TCP com paralelismo fica pendurada por uma fração menor de tempo. Além da redução
dos atrasos de RTT, as conexões persistentes (com ou sem paralelismo) têm um atraso
menor de partida lenta do que as conexões não persistentes. A razão para isso é que o
servidor persistente, após ter enviado o primeiro objeto, não tem de enviar o próximo
objeto à taxa inicial lenta, já que continua usando a mesma conexão TCP. Em vez disso,
o servidor pode retomar a mesma taxa com que o primeiro objeto partiu.
8.6.3
Formato da mensagem HTTP
As especificações do HTIP/1.0 [RFC 1945] e do HTIP/1.1 [RFC 2616] definem os
formatos das mensagens HTIP. Há dois tipos de mensagens HTIP: as mensagens de
requisição e as mensagens de resposta. Ambas serão discutidas a seguir.
8.6.3.1
Mensagem de requisição HTTP
Apresentamos a seguir uma mensagem de requisição HTTP típica:
GET /somedir/page.html HTTP/l.l
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/4.0
Accept-language: fr
(extra carriage return, 1ine feed)
Podemos aprender bastante examinando essa simples mensagem de requisição.
Antes de mais nada, vemos que ela está escrita em texto ASCII comum, de modo que
pode ser lida por qualquer ser humano que conheça computadores. Em segundo lugar,
vemos que ela é constituída de cinco linhas, cada uma delas seguida de “carriage return”
205
e “line feed” (fim de linha) para o início de uma nova linha. A última linha é seguida de
um comando adicional de “carriage return” e “line feed”. Embora essa mensagem de
requisição tenha cinco linhas, uma mensagem de requisição pode ter muito mais linhas,
poucas linhas e até uma linha apenas. A primeira linha de uma mensagem de requisição
HTTP é chamada de linha de requisição; as linhas subsequentes são chamadas de linhas
de cabeçalho. As linhas de requisição têm três campos: o campo do método, o campo
da URL e o campo da versão do HTTP. O campo do método pode assumir diversos
valores diferentes, entre eles GET, POST e HEAD. A grande maioria das mensagens
de requisição HTTP usa o método GET. Esse método é usado quando o browser solicita
um objeto; o objeto solicitado é identificado no campo do URL. Nesse exemplo, o
browser está solicitando o objeto /somedir/page.html. A versão é auto explicativa.
Nesse exemplo, o browser implementa a versão HTTP/1.1.
Vamos agora examinar as linhas de cabeçalho do exemplo. A linha de cabeçalho
“Host: www.some.school.edu” especifica o host no qual esse objeto reside. Ao incluir
a linha de cabeçalho “Connection: close”, o browser está dizendo ao servidor que ele
não quer usar conexões persistentes; quer que o servidor feche a conexão após o envio
do objeto solicitado. Embora o browser que gerou essa mensagem de requisição
implemente o HTTP/1.1, ele não quer se preocupar com conexões persistentes. A linha
de cabeçalho “User-agent:” especifica o agente usuário, isto é, o tipo de browser que
está fazendo a requisição ao servidor. Nesse caso, o agente usuário é o Mozilla/4.0, um
browser da Netscape. Essa linha de cabeçalho é útil porque o servidor pode na realidade
enviar diferentes versões do mesmo objeto a diferentes tipos de agentes usuários. (Cada
uma das versões é endereçada pela mesma URL). Por fim, o cabeçalho “Acceptlanguage:” mostra que o usuário prefere receber uma versão em francês do objeto, se
esse objeto existir no servidor; se não existir, o servidor deve enviar a versão default. O
cabeçalho “Accept-language:” é apenas um dos muitos cabeçalhos de negociação de
conteúdo disponíveis no HTTP.
Acabamos de examinar um exemplo. Vamos agora analisar o formato geral de
uma mensagem de requisição, ilustrado na Figura 8.12.
Figura 8.12 – Formato geral de uma mensagem de requisição.
Vemos que o formato geral de uma mensagem de requisição é muito parecido com
nosso exemplo. Contudo, você provavelmente notou que, após as linhas de cabeçalho
(e após a linha adicional com “carriage return” e “line feed”), há um “corpo de
entidade”. O corpo de entidade não é usado com o método GET, mas com o método
POST. O cliente HTTP usa o método POST quando o usuário preenche um
206
formulário – por exemplo, quando o usuário fornece uma palavra de busca a um site de
busca como o Altavista. Com uma mensagem POST, o usuário continua solicitando
uma página Web ao servidor, mas o conteúdo específico da página Web depende do que
o usuário escreveu nos campos do formulário. Se o valor escrito no campo do método
for POST, então o corpo de entidade conterá o que o usuário digitou nos campos do
formulário. O método HEAD é semelhante ao método GET. Quando um servidor
recebe uma requisição com o método HEAD, ele responde com uma mensagem HTTP,
mas deixa de fora o objeto solicitado. Esse método é frequentemente usado pelos
desenvolvedores de servidores HTTP para depuração.
8.6.3.2
Mensagem de resposta HTTP
Apresentamos a seguir uma típica mensagem de resposta HTTP. Essa mensagem
pode ser a resposta ao exemplo de mensagem de requisição que acabamos de discutir.
HTTP/1.1 200 OK
Connection: close
Date: Thu. 06 Aug 1998 12:00:15 GMT
Server: Apache/l.3.0 (Unix)
Last-Modified: Mon. 22 Jun 1998 09:23:24 GMT
Content-Length: 6821
Content-Type: text/htrnl
(data data data data data ...)
Vamos examinar cuidadosamente essa mensagem de resposta. Ela tem três
seções: uma linha de status inicial, seis linhas de cabeçalho e, em seguida, o corpo da
entidade. O corpo da entidade é o “filé mignon” da mensagem – ele contém o objeto
solicitado (representado por data data data data data ...). A linha de status tem três
campos: o campo da versão do protocolo, uma codificação para o status e uma
mensagem de estado correspondente. Nesse exemplo, ela mostra que o servidor está
usando o HTTP/1.1 e que está tudo OK (isto é, o servidor foi encontrado e está enviando
o objeto solicitado).
Vamos agora examinar as linhas de cabeçalho. O servidor usa a linha de cabeçalho
“Connection: close” para informar ao cliente que ele vai fechar a conexão TCP após
enviar a mensagem. A linha de cabeçalho “Date:” indica a hora e a data em que a
resposta HTTP foi criada e enviada pelo servidor. Note que esse não é o horário em que
o objeto foi criado nem o de sua mais recente modificação, mas é a hora em que o
servidor extraiu o objeto do sistema de arquivo, inseriu o objeto na mensagem de
resposta e enviou a mensagem de resposta. A linha de cabeçalho “Server:” mostra que
a mensagem foi gerada por um servidor Web Apache; ela é análoga à linha de cabeçalho
“User-agent:” na mensagem de requisição HTTP. A linha de cabeçalho “LastModified:” indica a hora e a data em que o objeto foi criado ou sofreu a última
modificação. O cabeçalho “Last-Modified:”, que estudaremos em detalhes, é
fundamental para fazer o cache do objeto, tanto no cliente local quanto nos servidores
de cache da rede (também conhecidos como servidores proxy). A linha de cabeçalho
“Content-Length:” indica o número de bytes do objeto que está sendo enviado. A linha
de cabeçalho “Content-Type:” mostra que o objeto presente no corpo da mensagem é
um texto HTML. (O tipo do objeto é oficialmente indicado pelo cabeçalho “ContentType:”, e não pela extensão do arquivo).
207
Note que, se o servidor receber uma requisição HTTP/1.0, ele não vai usar
conexões persistentes, mesmo que seja um servidor HTTP/1.1. Em vez disso, o servidor
HTTP/1.1 vai fechar a conexão TCP após o envio do objeto. Isso é necessário porque
um cliente HTTP/1.0 espera que o servidor feche a conexão.
Acabamos de ver um exemplo. Vamos agora examinar o formato geral de uma
mensagem de resposta, ilustrado na Figura 8.13. Esse formato geral da mensagem de
resposta condiz com o exemplo que demos desse tipo de mensagem.
Figura 8.13 – Formato geral de uma mensagem de resposta.
Vamos abordar as codificações de status e suas frases. A codificação de status e
a frase associada a ela indicam o resultado da requisição. Eis algumas codificações de
status e frases associadas comuns:

200 OK: a requisição foi bem-sucedida e a informação volta para a resposta.

301 Moved Permanently: o objeto requisitado foi removido permanentemente; uma
nova URL está especificada no cabeçalho “Location:” da mensagem de resposta. O
software do cliente vai automaticamente recuperar a nova URL.

400 Bad Request: uma codificação genérica de erro mostrando que a requisição não
pode ser entendida pelo servidor.

404 Not Found: o documento requisitado não existe no servidor.

505 HTTP Version Not Supported: aversão do protocolo HTTP requisitada não é
suportada pelo servidor.
Gostaria de ver uma mensagem de resposta HTTP real? É muito fácil!
Primeiramente, dê um comando Telnet em seu servidor Web favorito. Em seguida, digite
uma mensagem de requisição de uma linha solicitando algum objeto abrigado no
servidor. Por exemplo, se você possui uma senha de acesso em uma máquina Unix,
digite:
telnet www.eurecom.fr 80
GET /~ross/index.html HTTP/1.0
(Clique duas vezes na tecla “enter” após digitar a segunda linha). Essa seqüência
de comandos abre uma conexão TCP na porta número 80 do host www.eurecom.fr e,
208
em seguida, envia o comando HTTP GET. Com isso, deverá aparecer a mensagem de
resposta, que inclui o arquivo básico HTML da homepage do professor Ross. Se você
preferir apenas ver as linhas de mensagem HTTP e não receber o objeto em si, substitua
GET por HEAD. Finalmente, substitua /~ross/index.html por /~ross/banana.html e veja
que tipo de mensagem você obtém.
Nesta seção, examinamos algumas linhas de cabeçalho que podem ser usadas em
mensagens de requisição e de resposta HTTP. A especificação do HTTP (especialmente
a do HTTP/1.1) define muitas outras linhas de cabeçalho que podem ser inseridas por
browsers, servidores Web e servidores cache de redes. Vimos apenas um pequeno
número da totalidade das linhas de cabeçalho. Vamos examinar mais algumas linhas a
seguir e mais outro pequeno número quando discutirmos o Web caching no final desta
seção.
Como um browser decide quais linhas de cabeçalho serão incluídas em uma
mensagem de requisição? Como um servidor Web decide quais linhas de cabeçalho
serão incluídas em uma mensagem de resposta? Um browser vai gerar linhas de
cabeçalho em razão de seu tipo e de sua versão (por exemplo, um browser HTTP/1.0
não vai gerar nenhuma linha de cabeçalho 1.1), da configuração do usuário para o
browser (por exemplo, idioma preferido) e de o browser ter uma versão do objeto
possivelmente ultrapassada em sua memória cache. Os servidores Web se comportam
de maneira semelhante: há diferentes produtos, versões e configurações, e tudo isso tem
influência sobre quais linhas de cabeçalho são incluídas nas mensagens de resposta.
8.6.4
Interação usuário/servidor: autenticação e cookies
Mencionamos anteriormente que um servidor HTTP não conserva informação de
estado. Isso simplifica o projeto do servidor e vem permitindo que os engenheiros
desenvolvam servidores Web de alto desempenho. No entanto, é sempre bom que um site
Web identifique usuários, seja porque o servidor deseja restringir o acesso do usuário, seja
porque ele quer servir conteúdo em razão da identidade do usuário. O HTTP fornece dois
mecanismos para ajudar um servidor a identificar um usuário: a autenticação e os cookies.
8.6.4.1
Autenticação
Muitos sites exigem que os usuários forneçam um nome de usuário e uma senha
para permitir o acesso aos documentos armazenados no servidor. Essa exigência se
denomina autenticação. O HTTP fornece codificações de status e cabeçalhos especiais
para auxiliar os sites a realizar a autenticação. Vamos tomar um exemplo para sentir
como funcionam essas codificações de status e cabeçalhos especiais. Suponha que um
cliente requisite um objeto de um servidor e que o servidor requisite autorização do
usuário.
O cliente envia primeiramente uma mensagem de requisição comum, sem linhas
de cabeçalho especiais. O servidor então responde com um corpo de entidade vazio
juntamente com uma codificação de status “401 Authorization Required”. Nessa
mensagem de resposta, ele inclui o cabeçalho “WWW-Authenticate:”, que especifica
em detalhes como proceder à autenticação. (Normalmente, ele mostra que o usuário
precisa fornecer um nome de usuário e uma senha).
O cliente recebe a mensagem de resposta, pede ao usuário um nome de usuário e
uma senha e reenvia a mensagem de requisição, mas, dessa vez, inclui uma linha de
cabeçalho “Authorization:”, que inclui o nome do usuário e a senha.
209
Após obter o primeiro objeto, o cliente continua a enviar o nome de usuário e a
senha nas requisições subsequentes de objetos que estão no servidor. Isso normalmente
continua até que o cliente feche o browser. Contudo, enquanto o browser permanece
aberto, o nome de usuário e sua senha ficam na memória cache, de modo que não há um
novo pedido ao usuário de seu nome e sua senha para cada objeto que ele requisita!
Dessa maneira, o site pode identificar o usuário para cada pedido.
8.6.4.2
Cookies
Os cookies são um mecanismo alternativo que os sites usam para obter
informações dos usuários. Eles são definidos no RFC 2109. Alguns sites Web usam
cookies, outros, não. Vamos examinar um exemplo. Suponha que um cliente entre em
um site Web pela primeira vez e que esse site use cookies. A resposta do servidor vai
incluir um cabeçalho “Set-cookie:”. Frequentemente, essa linha de cabeçalho contém
um número de identificação gerado pelo servidor Web. Por exemplo, a linha de
cabeçalho poderia ser:
Set-cookie: 1678453
Quando o cliente HTTP recebe a mensagem de resposta, ele vê o cabeçalho “Setcookie:” e o número de identificação. Em seguida, ele anexa uma linha a um arquivo
especial de cookies que está armazenado na máquina cliente. Essa linha inclui o nome
do host do servidor e o número de identificação associado ao usuário. Nas requisições
subsequentes ao mesmo servidor, digamos, uma semana mais tarde, o cliente inclui um
cabeçalho de requisição “Cookie:”, e essa linha de cabeçalho especifica o número de
identificação para o servidor. No exemplo em curso, a mensagem de requisição inclui
a linha de cabeçalho:
Cookie: 1678453
Dessa maneira, o servidor não sabe o nome do usuário, mas sabe, na verdade, que
esse usuário é o mesmo que fez determinada requisição uma semana atrás.
Os servidores Web usam cookies para diferentes finalidades:

Se um servidor necessita de identificação mas não quer perturbar o usuário com um
pedido de nome de usuário e senha toda vez que ele visita o site, ele pode aplicar um
cookie.

Se um servidor quiser se lembrar das preferências de um usuário de modo que possa
oferecer propaganda dirigida durante as visitas subsequentes, ele pode aplicar um
cookie.

Se o usuário estiver fazendo compras em um site (por exemplo, comprando diversos
CDs), o servidor pode usar cookies para anotar os itens que o usuário está
comprando, ou seja, para criar um carrinho de compras virtual.
Devemos mencionar, no entanto, que os cookies causam problemas para um
usuário nômade que acessa o mesmo site de máquinas diferentes. O site vai tratar o
usuário como se fosse um usuário diferente para cada máquina diferente que ele usar.
8.6.5
O GET condicional
Por armazenar objetos que foram extraídos anteriormente, a função de Web cache pode
reduzir os atrasos de extração de objetos e diminuir a quantidade de tráfego enviado pela
Internet. Os Web caches podem residir em um cliente ou em um servidor de cache
210
intermediário da rede. Vamos tratar do cache em rede no final desta seção. Nesta subseção,
restringiremos nossa atenção ao cache no cliente.
Embora o uso de Web caching possa reduzir os tempos de resposta do ponto de vista
do usuário, ele introduz um novo problema – a cópia de um objeto existente no cache pode
estar desatualizada. Em outras palavras, o objeto abrigado no servidor Web pode ter sido
modificado desde a data em que a cópia passou para o cache no cliente. Felizmente, o HTTP
tem um mecanismo que permite que o cliente empregue o cache e, ao mesmo tempo, tenha
certeza de que todos os objetos apresentados estão atualizados. Esse mecanismo é chamado
de GET condicional (conditional GET). Uma mensagem de requisição HTTP é chamada de
mensagem GET condicional se (1) usa o método GET e (2) possui uma linha de cabeçalho
“If-Modified-Since”:
Para ilustrar como o GET condicional opera, vamos examinar um exemplo. Em
primeiro lugar, um browser requisita, de algum servidor Web, um objeto que não está no
cache.
GET /fruit/kiwi.gif HTTP/1.0
Em segundo lugar, o servidor Web envia ao cliente uma mensagem de resposta com o
objeto:
HTTP/1.0 200 OK
Date: Wed. 12 Aug 1998 15:39:29
Server: Apache/l.3.0 (Unix)
Last-Modified: Mon. 22 Jun 1998 09:23:24
Content-Type: image/gif
(data data data data data ...)
O cliente mostra o objeto ao usuário e também o guarda em sua memória cache local.
O importante é que o cliente também guarde no cache, juntamente com o objeto, a data da
última modificação.
Em terceiro lugar, uma semana depois, o usuário requisita o mesmo objeto, e o objeto
ainda está no cache. Como esse objeto pode ter sido modificado no servidor Web na semana
anterior, o browser realiza uma verificação de atualização enviando um GET condicional.
Especificamente, o browser envia:
GET /fruit/kiwi.gif HTTP/l.0
If-modified-since: Mon. 22 Jun 1998 09:23:24
Note que o valor da linha de cabeçalho “If-modified-since:” é exatamente igual ao valor
da linha de cabeçalho “Last-Modified:”, que foi enviada pelo servidor há uma semana. Esse
GET condicional está dizendo ao servidor para enviar o objeto somente se ele tiver sido
modificado depois da data especificada. Suponha que ele não tenha sido modificado desde
22 Jun 1998 09:23:24. Então, por fim, em quarto lugar, o servidor Web envia a mensagem
de resposta ao cliente:
211
HTTP/l.0 304 Not Modified
Date: Wed. 19 Aug 1998 15:39:29
Server: Apache/1.3.0 (Unix)
(corpo de mensagem vazio)
Vemos que, em resposta ao GET condicional, o servidor Web ainda envia uma
mensagem de resposta, mas não inclui nela o objeto requisitado. Incluir o objeto requisitado
apenas desperdiçaria largura de banda e aumentaria o tempo de resposta do ponto de vista do
usuário, particularmente se o objeto fosse grande. Note que essa última mensagem de
resposta traz inserida a linha de status “304 Not Modified”, que informa ao cliente que ele
pode seguir adiante e usar a cópia do objeto que está em seu cache.
8.6.6
Web Caches
Um Web cache – também chamado de servidor proxy – é uma entidade da rede que
atende às requisições HTTP em nome de um cliente. Ele tem seu próprio disco de
armazenagem e conserva, dentro dele, cópias de objetos recentemente requisitados. Como
ilustrado na Figura 8.14, os usuários configuram seu browser de modo que todas as suas
requisições HTTP sejam primeiramente dirigidas ao Web cache. Esse é um procedimento
simples para os browsers da Microsoft e da Netscape. Uma vez que o browser é configurado,
a requisição de um objeto feita por ele é primeiramente dirigida ao Web cache. Como
exemplo,
suponha
que
um
browser
esteja
requisitando
o
objeto
http://www.someschool.edu/campus.gif.

O browser estabelece uma conexão TCP com o Web cache e envia a ele uma requisição
HTTP para um objeto.

O Web cache verifica se ele tem uma cópia do objeto armazenada localmente. Se tiver,
ele envia ao browser do cliente o objeto dentro de uma mensagem de resposta HTTP.

Se o Web cache não tiver o objeto, ele abre uma conexão TCP com o servidor original,
isto é, com www.someschool.edu. Ele então envia uma requisição HTTP do objeto por
meio da conexão TCP. Após ter recebido essa requisição, o servidor original envia o
objeto dentro de uma resposta HTTP ao Web cache.

Quando o Web cache recebe o objeto, ele armazena uma cópia em seu arquivo local e
envia uma cópia, dentro de uma mensagem de resposta, ao browser do cliente (por meio
da conexão TCP existente entre o browser do cliente e o Web cache).
Note que o cache é tanto um servidor como um cliente. Quando recebe requisições de
um browser e envia respostas a ele, ele é um servidor. Quando envia requisições para um
servidor de origem e recebe respostas dele, ele é um cliente.
212
Figura 8.14 – Clientes requisitando objetos por meio de um Web Cache.
Então, por que se incomodar com um Web caching? Que vantagens ele tem? Web
caches são utilizados em larga escala na Internet por, no mínimo, três razões. Em primeiro
lugar, o Web cache pode reduzir substancialmente o tempo de resposta para a requisição de
um cliente, em particular se o gargalo da largura de banda entre o cliente e o servidor original
for muito menor do que o gargalo da largura de banda entre o cliente e o cache. Se houver
uma conexão de alta velocidade entre o cliente e o cache, como é em geral o caso, e se o
cache tiver o objeto requisitado, então ele poderá entregar rapidamente o objeto ao cliente.
Em segundo lugar, como logo vamos ilustrar com um exemplo, os Web caches podem reduzir
substancialmente o tráfego no enlace de acesso de uma instituição qualquer à Internet. Ao
reduzir o tráfego, a instituição (por exemplo, uma empresa ou uma universidade) não precisa
ampliar sua largura de banda tão rapidamente, reduzindo assim os custos. Além disso, os
Web caches podem reduzir muito o tráfego na Web como um todo, melhorando, assim, o
desempenho para todas as aplicações. Em 1998, mais de 75 por cento do tráfego da Internet
era da Web; portanto, uma redução significativa no tráfego da Web pode ser traduzida em
melhoria significativa do desempenho da Internet. Em terceiro lugar, uma Internet com alta
densidade de cachês – tais como as de nível institucional, regional e nacional – fornece uma
infra-estrutura para rápida distribuição de conteúdo, mesmo para os provedores de conteúdo
que rodam seu site em servidores de baixa velocidade apoiados em enlaces de acesso de baixa
velocidade. Se esse provedor de conteúdo de “parcos recursos” de repente tiver um conteúdo
muito popular para distribuir, esse conteúdo será rapidamente copiado para os caches da
Internet e a grande demanda será satisfeita.
Para um entendimento mais profundo dos benefícios dos caches, vamos considerar um
exemplo no contexto da Figura 8.15. Essa figura mostra duas redes: uma rede institucional
e a Internet pública. A rede institucional é uma LAN de alta velocidade. Um roteador da
rede institucional e um roteador da Internet estão ligados por um enlace de 1,5 Mbps. Os
servidores originais estão todos ligados à Internet, mas localizados pelo mundo todo.
Suponha que o tamanho médio do objeto seja 100 Kbits e que a taxa média de requisição dos
browsers da instituição até os servidores de origem seja de 15 requisições por segundo.
Suponha também que o tempo entre o envio de uma requisição HTTP (dentro de um
datagrama IP) pelo roteador do lado da Internet do enlace de acesso mostrado na Figura 8.15
e o recebimento do datagrama IP (normalmente, muitos datagramas IPs) contendo a resposta
correspondente seja de 2 segundos em média. Vamos nos referir informalmente a esse atraso
como “atraso da Internet”.
213
Figura 8.15 – Gargalo entre uma rede institucional e a Internet.
O tempo de resposta total – isto é, o tempo transcorrido entre a requisição de um objeto
feita pelo browser e o recebimento desse objeto – é a soma do atraso da LAN, do atraso de
acesso (isto é, o atraso entre os dois roteadores) e do atraso da Internet. Vamos fazer agora
um cálculo bastante rudimentar para estimar esse atraso. A intensidade de tráfego na LAN
é:
(15 requisições/segundo) (100 Kbits/requisição)/(10 Mbps) = 0,15,
ao passo que a intensidade de tráfego no enlace de acesso (do roteador da Internet ao roteador
da instituição) é:
(15 requisições/segundo) (100 Kbits/requisição)/(1,5 Mbps) = 1.
Uma intensidade de tráfego de 0,15 em uma LAN resulta em, no máximo, dezenas de
milissegundos de atraso; consequentemente, podemos desprezar o atraso da LAN. Contudo,
à medida que a intensidade de tráfego se aproxima de 1 (como é o caso do enlace de acesso
da Figura 8.15), o atraso em um enlace se torna muito grande e cresce sem limites. Assim, o
tempo médio de resposta para atender às requisições vai ser da ordem de minutos, se não for
maior, o que é inaceitável para os usuários da instituição. Evidentemente, algo precisa ser
feito.
Uma possível solução seria aumentar a velocidade de acesso de 1,5 Mbps para,
digamos, 10 Mbps. Isso reduz a intensidade de tráfego no enlace de acesso a 0,15, o que se
traduz em atrasos desprezíveis entre os dois roteadores. Nesse caso, o tempo total de
resposta, isto é, o atraso da Internet, será aproximadamente de 2 segundos. Mas essa solução
também significa que a instituição tem de atualizar seu enlace de acesso de 1,5 Mbps para
10 Mbps, o que pode ser muito dispendioso.
214
Figura 8.16 – Adição de um cache à rede institucional.
Considere agora a solução alternativa de não atualizar o enlace de acesso, mas, em vez
disso, instalar um Web cache na rede institucional. Essa solução está ilustrada na Figura 8.16.
As taxas de resposta local – a fração de requisições que são satisfeitas por um cache – em
geral ficam na faixa de 0,2 a 0,7 na prática. Com a finalidade de ilustrar, vamos supor que
um cache forneça uma taxa de resposta local de 0,4 para essa instituição. Como os clientes
e o cache estão conectados à mesma LAN de alta velocidade, 40 por cento das requisições
serão satisfeitas pelo cache quase imediatamente, digamos, em 10 milissegundos. Todavia,
os demais 60 por cento das requisições ainda precisam ser satisfeitos pelos servidores
originais. Mas, com apenas 60 por cento dos objetos passando pelo enlace de acesso, a
intensidade de tráfego reduz de 1,0 para 0,6. Uma intensidade de tráfego menor do que 0,8
corresponde a um atraso pequeno, digamos, de dezenas de milissegundos, para um enlace de
1,5 Mbps. Esse atraso é desprezível se comparado aos 2 segundos do atraso da Internet.
Dadas essas considerações, o atraso médio é, por consequência,
0,4 (0,010 segundo) + 0,6 (2,01 segundos),
que é apenas ligeiramente maior do que 1,2 segundo. Assim, essa segunda solução fornece
um tempo de resposta até menor do que o oferecido pela troca do enlace de acesso e não
requer que a instituição atualize seu enlace com a Internet. Evidentemente, a instituição terá
de comprar e instalar um Web cache. Mas esse custo é baixo – muitos caches usam software
de domínio público que roda em servidores baratos e em PCs.
215
Segurança em Redes
9.1
O que é segurança na rede?
Queremos lhe apresentar Alice e Bob, duas pessoas que desejam se comunicar “com
segurança”. Gostaríamos de observar que Alice e Bob podem ser dois roteadores que querem
trocar tabelas de roteamento com segurança, dois hosts que querem estabelecer uma conexão de
transporte segura ou duas aplicações de e-mail que querem trocar e-mails seguros – todos esses
tópicos serão examinados mais adiante neste capítulo. Alice e Bob são componentes conhecidos
da comunidade de segurança, talvez porque o nome deles seja mais interessante do que uma
entidade genérica chamada “A” que quer se comunicar com segurança com uma entidade genérica
“B”. Amores proibidos, comunicações em tempo de guerra e transações financeiras são as
necessidades dos seres humanos comumente citados quando o assunto é segurança; preferimos a
primeira necessidade e vamos usar, com muito prazer, Alice e Bob como nosso remetente e nosso
destinatário e imaginá-los nesse primeiro cenário.
9.1.1
Comunicação Segura
Dissemos que Alice e Bob querem se comunicar “com segurança”, mas o que isso
significa exatamente? Com certeza, Alice quer que Bob entenda a mensagem que ela enviou,
mesmo que eles estejam se comunicando por um meio “inseguro”, em que um intruso (Trudy,
a intrusa) pode interceptar, ler e registrar qualquer dado que seja transmitido de Alice a Bob.
Bob também quer ter certeza de que a mensagem que recebe de Alice foi de fato enviada por
ela, enquanto Alice quer ter certeza de que a pessoa com quem está se comunicando é de fato
Bob. Alice e Bob também querem ter certeza de que o conteúdo da mensagem de Alice não
foi alterado em trânsito. Dadas essas considerações, podemos identificar as seguintes
propriedades desejáveis da comunicação segura:

Sigilo: somente o remetente e o destinatário pretendido devem poder entender o conteúdo
da mensagem transmitida. O fato de “abelhudos” poderem interceptar a mensagem exige,
necessariamente, que esta seja cifrada de alguma maneira (que seus dados sejam
disfarçados) para impedir que a mensagem interceptada seja decifrada (entendida) por
um interceptador. Esse aspecto do sigilo é, provavelmente, o significado mais percebido
em “comunicação segura”. Note, contudo, que essa não é apenas uma definição limitada
de comunicação segura (relacionamos a seguir aspectos adicionais da segurança), mas
também uma definição bastante restrita de sigilo. Por exemplo, Alice poderia também
querer que o mero fato de ela estar se comunicando com Bob (ou os horários ou a
frequência de suas comunicações) fosse também um segredo! Estudaremos as técnicas
de criptografia para cifrar e decifrar dados na Seção 9.2.

Autenticação: o remetente e o destinatário precisam confirmar a identidade da outra parte
envolvida na comunicação – confirmar que a outra parte realmente é quem alega ser. A
comunicação pessoal entre seres humanos resolve facilmente esse problema pelo
reconhecimento visual. Quando entidades comunicantes trocam mensagens por um meio
pelo qual não podem “ver” a outra parte, a autenticação não é assim tão simples. Por que,
por exemplo, você deveria acreditar que o e-mail que recebeu e que contém uma sentença
afirmando que aquele e-mail veio de um amigo seu realmente veio daquele amigo? Se
alguém o chama ao telefone dizendo ser de seu banco e perguntando qual é o número de
sua conta, sua senha e seu saldo bancário, alegando finalidades de verificação, você dá
216
essas informações? Esperamos que não. Examinaremos as técnicas de autenticação na
Seção 9.3, incluindo algumas que, talvez surpreendentemente, também dependem de
técnicas criptográficas, que estudaremos na Seção 9.2.

Integridade de mensagem: mesmo que o remetente e o destinatário consigam se autenticar
reciprocamente, eles querem assegurar que o conteúdo de sua comunicação não seja
alterado, por acidente ou por má intenção, durante a transmissão. Extensões das técnicas
de soma de verificação que encontramos em protocolos de transporte e de enlace
confiáveis serão examinadas na Seção 9.4; essas técnicas também dependem dos
conceitos criptográficos apresentados na Seção 9.2.
Agora que estabelecemos o que significa comunicação segura nesse contexto, vamos
considerar o que quer dizer exatamente “canal inseguro”. A que informações um intruso tem
acesso e que ações podem ser tomadas sobre os dados transmitidos? A Figura 9.1 ilustra esse
cenário.
Alice, a remetente, quer enviar dados a Bob, o destinatário. A fim de trocar dados com
segurança, além de atender aos requisitos de sigilo, autenticação e integridade das
mensagens, Alice e Bob trocarão mensagens de controle e de dados (de maneira muito
semelhante ao modo como os remetentes e os destinatários TCP trocam segmentos de
controle e segmentos de dados). Todas ou algumas dessas mensagens serão cifradas de modo
típico. Um intruso passivo pode ouvir e gravar as mensagens de controle e de dados no canal;
um intruso ativo pode remover mensagens do canal e/ou adicioná-las a ele.
Figura 9.1 – Remetente, destinatário e intruso (Alice, Bob e Trudy).
9.1.2
Considerações sobre segurança de rede na Internet
Antes de analisarmos os aspectos técnicos de segurança da rede nas próximas seções,
vamos concluir nossa introdução relacionando as personagens fictícios – Alice, Bob e
Trudy – a cenários do “mundo real” da Internet de hoje.
Vamos começar com Trudy, a intrusa da rede. Um intruso de rede do “mundo real”
pode de fato ouvir e gravar mensagens da rede? É fácil fazer isso? Um intruso ativamente
pode injetar ou remover mensagens da rede? A resposta a isso tudo é um enfático sim. Um
analisador de pacotes (packet sniffer) é um programa que roda em um dispositivo acoplado
à rede e que recebe passivamente todos os quadros de camada de enlace que passam por sua
interface de rede. Em ambiente broadcast como uma LAN Ethernet, isso significa que o
analisador de pacotes recebe todos os quadros que estão sendo transmitidos para todos os
hosts da LAN. Qualquer host que tenha uma placa Ethernet pode facilmente servir de
analisador de pacotes, pois é só ajustar o NIC da Ethernet no modo promíscuo (promiscuous
mode) para que ele receba todos os quadros que passam pela Ethernet. Esses quadros podem,
então, ser passados aos programas de aplicação, que extraem os dados de aplicação. Por
217
exemplo, no cenário Telnet mostrado na Figura 9.2, o pedido de senha de login enviado de
A para B – bem como a senha informada em B – é “capturado” no host C. A captura de
pacotes é uma “faca de dois gumes” – pode ser de inestimável valor para um administrador
de rede realizar a monitoração e a administração da rede, mas também pode ser usada por um
hacker inescrupuloso. O software analisador de pacotes pode ser obtido de graça em vários
sites Web ou adquirido no mercado. Sabe-se que professores que ministram cursos sobre
redes têm passado exercícios de laboratório que envolvem escrever um programa de captura
de pacotes e de recuperação de dados no nível de aplicação.
Figura 9.2 – Analisador de Pacotes.
Qualquer equipamento conectado à Internet necessariamente envia datagramas IP para
a rede. Lembre-se de que esses datagramas transportam o endereço IP, bem como os dados
da camada superior. Um usuário que tenha completo controle sobre o software do
equipamento (em particular sobre o sistema operacional) pode facilmente modificar os
protocolos daquele equipamento e colocar um endereço IP arbitrário no campo de endereço
de origem do datagrama. Isso é conhecido como falsificação do IP. Dessa maneira, um
usuário pode montar um pacote IP que contenha qualquer carga útil (de camada superior) que
quiser e fazer com que pareça que os dados foram enviados de um host IP arbitrário. A
captura de pacotes e a falsificação do IP são apenas duas das maneiras mais comuns de
“ataques” à segurança da Internet.
Uma ampla terceira classe de ameaça à segurança são os ataques de recusa de serviço
(denial of service – DoS). Como o nome sugere, um ataque DoS torna impossível a utilização
da rede, do host ou de qualquer outro componente da infra-estrutura pelos usuários legítimos.
Em geral, ele funciona pela criação de uma quantidade tão grande de trabalho para a infraestrutura sob ataque que o trabalho legítimo não pode ser realizado. No chamado ataque de
inundação SYN, o atacante inunda um servidor com pacotes TCP SYN, cada um com um
endereço IP de fonte falsificado. O servidor, incapaz de diferenciar um pacote SYN legítimo
de um falsificado, completa o segundo estágio do estabelecimento de conexão TCP para um
SYN falsificado, alocando a ele uma estrutura de dados e estado. O terceiro estágio da
apresentação de três vias nunca é completado pelo atacante, o que deixa um número sempre
crescente de conexões abertas. A carga de pacotes SYN a ser processada e a exaustão da
memória livre podem derrubar o servidor. Um ataque DoS “smurf” opera fazendo com que
um grande número de hosts inocentes responda a pacotes ICMP de solicitação de eco (Ping)
contendo um endereço IP de fonte falsificado. Isso resulta no envio de um grande número
de pacotes de resposta de eco ao host cujo endereço IP é objeto da falsificação. O RFC 2267
e o RFC 2644 descrevem diversas medidas simples que podem ser tomadas para evitar esses
e outros ataques DoS.
Como há, na verdade, bichos-papões reais (também conhecidos como “Trudy”) à solta
na Internet, quais são os equivalentes de Alice e Bob na Internet, esses nossos dois amigos
218
que precisam se comunicar com segurança? Certamente, “Bob” e “Alice” são dois usuários
humanos em dois sistemas finais, por exemplo uma Alice real e um Bob real que de fato
querem trocar e-mails seguros. Eles podem também ser os participantes de uma transação
comercial eletrônica. Por exemplo, uma Alice real pode querer transmitir o número de seu
cartão de crédito a um servidor Web para comprar um produto por meio da rede. Como
ressalta o RFC 1636, contudo, esses mesmos participantes que necessitam de comunicação
segura podem também ser componentes da infra-estrutura da rede. Lembre-se de que o DNS
ou os roteadores daemons, que trocam tabelas de roteamento, exigem comunicação segura
entre dois participantes. Isso é válido para aplicações de gerenciamento de rede. Um intruso
que conseguisse interferir, controlar ou corromper ativamente consultas e atualizações do
DNS, processamentos de roteamento ou funções de gerenciamento de rede causaria uma
devastação na Internet.
Estabelecida a estrutura da rede, apresentadas algumas das mais importantes definições
e justificada a necessidade de segurança na rede, vamos examinar a criptografia, um tópico
de importância fundamental para muitos aspectos da segurança na rede.
9.2
Princípios da criptografia
Embora a criptografia tenha uma longa história que remonta, no mínimo, a Júlio César (daí
existir uma cifra chamada César), as modernas técnicas de criptografia, incluindo muitas das
usadas na Internet de hoje, são baseadas em progressos feitos nos últimos 30 anos. O livro de
Kahn The codebreakers nos oferece um fascinante panorama dessa longa história. Kaufman
apresenta uma discussão técnica detalhada (mas interessante e de fácil leitura) sobre criptografia,
sobretudo do ponto de vista da rede. Diffie fornece uma análise atraente e atualizada das questões
políticas e sociais (a respeito, por exemplo, da privacidade) que hoje estão inextricavelmente
entrelaçadas com a criptografia. Uma discussão completa sobre a criptografia exige um livro
inteiro; portanto, apenas trataremos de seus aspectos essenciais, em particular do modo como as
técnicas criptográficas são postas em prática na Internet de hoje.
As técnicas criptográficas permitem que um remetente disfarce os dados de modo que um
intruso não consiga obter nenhuma informação com base nos dados interceptados. O destinatário,
é claro, deve estar habilitado a recuperar os dados originais a partir dos dados criptografados. A
Figura 9.3 apresenta alguns dos mais importantes componentes criptográficos.
Figura 9.3 – Componentes Criptográficos.
219
Suponha agora que Alice queira enviar uma mensagem a Bob. A mensagem de Alice em
seu modelo original (por exemplo, “Bob. I love you. Alice”1) é conhecida como texto aberto ou
texto claro. Alice criptografa sua mensagem em texto aberto usando um algoritmo de criptografia,
de modo que a mensagem criptografada, conhecida como texto cifrado, pareça ininteligível para
qualquer intruso. O interessante é que em muitos sistemas criptográficos modernos, incluindo os
usados na Internet, a técnica de codificação é conhecida – publicada, padronizada [RFC 1321,
RFC 2437, RFC 2420] e disponível para qualquer um, mesmo para um intruso em potencial!
Evidentemente, se todos conhecem o método para codificar os dados, então deve haver algum
pedaço de informação secreta que impede que um intruso decifre os dados transmitidos. É aqui
que entra o segredo da chave.
Na Figura 9.3, Alice fornece uma chave, KA, uma cadeia de números ou de caracteres como
entrada para o algoritmo de criptografia. O algoritmo de criptografia pega essa chave e o texto
aberto como entrada e produz o texto cifrado como saída. De maneira semelhante, Bob fornecerá
uma chave, KB, ao algoritmo de decriptogratia, que pega o texto cifrado e a chave de Bob como
entrada e produz o texto original como saída. Nos denominados sistemas de chaves simétricas,
as chaves de Bob e Alice são idênticas e secretas. Nos sistemas de chaves públicas, é usado um
par de chaves. Uma das chaves é conhecida por Bob e por Alice (na verdade, é conhecida pelo
mundo inteiro). A outra chave é somente conhecida por Bob ou por Alice (mas não por ambos).
Nas duas subseções seguintes, veremos em detalhes os sistemas de chaves simétricas e de chaves
públicas.
9.2.1
Criptografia de chaves simétricas
Todos os algoritmos criptográficos envolvem a substituição de um dado por outro,
como, por exemplo, tomar um trecho de um texto e então, calculando e substituindo esse
texto por outro cifrado apropriado, criar uma mensagem cifrada. Antes de examinarmos o
sistema criptográfico moderno baseado em chaves, vamos abordar um velho algoritmo de
chaves simétricas muito simples – atribuído a Júlio César – conhecido como cifra de César
(uma cifra é um método para criptografar dados).
A cifra de César funciona tomando cada letra da mensagem do texto aberto e a
substituindo pela k-ésima letra sucessiva do alfabeto (permitindo a alternância das letras do
alfabeto, isto é, a letra “z” seria seguida novamente da letra “a”). Por exemplo, se k = 3,
então a letra “a” do texto aberto fica sendo “d” no texto cifrado; “b” no texto aberto se
transforma em “e” no texto cifrado, e assim por diante. Nesse caso, o valor de k serve de
chave. Por exemplo, a mensagem “bob. I love you. a1ice.” se toma “ere. 1oryh brx. dolfh.”
em texto cifrado. Embora o texto cifrado realmente pareça não ter nexo, você não levaria
muito tempo para quebrar o código se soubesse que foi usada a cifra de César, pois há
somente 25 valores possíveis para as chaves.
Um aprimoramento da cifra de César é a denominada cifra monoalfabética, que
também substitui uma letra do alfabeto por outra. Contudo, em vez de substituir as letras
seguindo um padrão regular (por exemplo, substituição por um deslocamento de k para todas
as letras), qualquer letra pode ser substituída por qualquer outra, contanto que cada letra tenha
uma letra substituta exclusiva e vice-versa. A regra de substituição apresentada na Figura 9.4
mostra uma regra possível para codificar textos abertos.
1
A mensagem foi mantida no idioma original porque será apresentado o texto cifrado para ela. A tradução é “Bob, eu amo
você. Alice”.
220
Figura 9.4 – Uma cifra monoalfabética.
A mensagem do texto aberto “bob. I love you. alice.” se torna “nkn, s gktc wky.
mgsbc.” Como aconteceu no caso da cifra de César, o texto parece sem nexo. A cifra
monoalfabética também parece ser melhor que a cifra de César, pois há 26! (10 26) possíveis
pares de letras, em vez de 25 pares possíveis! Usar a “força bruta” para experimentar 1026
pares demandaria um esforço demasiadamente grande e impediria que esse fosse um método
exequível para quebrar o algoritmo criptográfico e decodificar a mensagem. Contudo,
fazendo-se a análise estatística do texto aberto, por exemplo, e sabendo quais letras e grupos
de letras são mais frequentes nos textos do idioma em questão, torna-se relativamente fácil
quebrar esse código. Se o intruso tiver algum conhecimento sobre o possível texto da
mensagem, então ficará mais fácil ainda quebrar o código. Por exemplo, se a intrusa Trudy
for a esposa de Bob e suspeitar que ele está tendo um caso com Alice, ela poderá imaginar
que os nomes “Bob” e “Alice” aparecem no texto. Se Trudy tivesse certeza de que esses dois
nomes aparecem no texto cifrado e tivesse uma cópia do texto cifrado da mensagem do
exemplo, ela poderia imediatamente determinar sete dos 26 pares de letras, o que resultaria
em 109 possibilidades a menos para verificar pelo método da “força bruta”. Na verdade, se
Trudy suspeitasse que Bob estava tendo um caso, ela poderia muito bem esperar encontrar
algumas outras palavras preferenciais no texto também.
Ao considerarmos que seria fácil para Trudy quebrar o código criptográfico de Bob e
Alice, podemos distinguir três diferentes cenários, dependendo do tipo de informação que o
intruso tem:

Ataque exclusivo ao texto cifrado. Em alguns casos, o intruso pode ter acesso somente
ao texto cifrado interceptado, sem ter nenhuma informação exata sobre o conteúdo do
texto aberto. Já vimos como a análise estatística pode ajudar o ataque exclusivo ao texto
cifrado em um esquema criptográfico.

Ataque ao texto aberto conhecido. Vimos anteriormente que, se Trudy de algum modo
tivesse certeza de que “bob” e “Alice” apareciam no texto cifrado, ela poderia determinar
os pares (texto cifrado, texto aberto) para as letras a, l, i, c, e, b e o. Trudy poderia
também ser muito sortuda e ter gravado todas as transmissões de texto cifrado e
descoberto uma versão decifrada pelo próprio Bob escrita em um pedaço de papel.
Quando um intruso conhece alguns dos pares (texto aberto, texto cifrado), referimo-nos
a isso como ataque ao esquema criptográfico a partir do texto aberto conhecido.

Ataque ao texto aberto escolhido. Nesse tipo de ataque, o intruso pode escolher a
mensagem em texto aberto e obter seu modelo cifrado correspondente. Para os
algoritmos criptográficos que vimos até aqui, se Trudy conseguisse que Alice enviasse a
mensagem "The quick fox jumps over the lazy brown dog", ela poderia decifrar
completamente o esquema criptográfico. Veremos em breve que, para técnicas de
criptografia mais sofisticadas, um ataque a um texto aberto escolhido não significa
necessariamente que a técnica criptográfica possa ser decifrada.
Quinhentos anos atrás foram inventadas técnicas que aprimoravam a cifra
monoalfabética. Conhecidas hoje como cifras polialfabéticas, essas técnicas, incorretamente
atribuídas a Blaise de Vigenere, foram chamadas de cifras de Vigenere. A idéia subjacente
221
às cifras de Vigenere é usar múltiplas cifras monoalfabéticas e uma cifra monoalfabética
específica para codificar uma letra em uma posição específica no texto aberto da mensagem.
Assim, a mesma letra, quando aparece em posições diferentes no texto aberto da mensagem,
pode ser codificada de maneira diferente. A cifra de Vigenere mostrada na Figura 9.5 tem
duas cifras de César (com k = 5 e k = 19) que aparecem nas linhas da figura. Podemos optar
pelo uso dessas duas cifras de César, C1 e C2, seguindo o modelo de repetição C1, C2, C2, C1
C2. Em outras palavras, a primeira letra do texto deve ser cifrada usando-se C1, a segunda e
a terceira, C2, a quarta, C1 e a quinta, C2. O modelo, então, se repete, com a sexta letra sendo
cifrada usando-se C1; a sétima, C2, e assim por diante. Dessa maneira, a mensagem em texto
aberto “bob, I 1ove you.” é cifrada como “ghu, n etox dhz.”. Note que o primeiro “b” da
mensagem em texto aberto é cifrado usando-se C1 ao passo que o segundo “b” é cifrado
usando-se C2. Nesse exemplo, a “chave” da codificação e da decodificação é o conhecimento
das duas cifras de César (k = 5, k = 19) e do modelo C1, C2, C2, C1 C2.
Figura 9.5 – Uma cifra de Vigenere usando duas cifras de César.
9.2.2
Criptografia de chaves públicas
Por mais de dois mil anos (desde a época da cifra de César até a década de 70), a
comunicação cifrada exigia que as duas partes comunicantes compartilhassem um segredo
em comum – a chave simétrica usada para cifrar e decifrar. Uma dificuldade dessa
abordagem é que as duas partes têm de escolher, conjuntamente, de alguma maneira, qual é
a chave; mas, para fazê-lo, é preciso comunicação (presumivelmente segura)! Talvez as
partes pudessem se encontrar, escolher a chave pessoalmente (por exemplo, dois dos
centuriões de César poderiam se encontrar nos banhos romanos) e, mais tarde, comunicar a
cifra. No atual mundo em rede, contudo, o mais provável é que as partes comunicantes nunca
possam se encontrar e jamais possam conversar a não ser pela rede. É possível que elas se
comuniquem por criptografia sem compartilhar uma chave comum secreta conhecida com
antecedência? Em 1976, Diffie e Hellman apresentaram um algoritmo (conhecido como
Troca de Chaves Diffie Hellman – Diffie Hellman Key Exchange) que faz exatamente
isso – uma abordagem da comunicação segura radicalmente diferente e de uma elegância
maravilhosa que levou ao desenvolvimento dos atuais sistemas de criptografia de chaves
públicas. Veremos em breve que os sistemas de criptografia de chaves públicas também têm
diversas propriedades maravilhosas que os tornam úteis não somente para criptografia, mas
também para autenticação e assinaturas digitais. As primeiras ideias de comunicação segura
([Diffie, 1976] e [RSA, 1978]) constituem a base da atual atividade de comércio eletrônico
(veja a Seção 9.7). Recentemente, veio à luz que ideias semelhantes às de [Diffie, 1976] e
às da [RSA, 1978] foram desenvolvidas independentemente no início da década de 70 em
uma série de relatórios secretos escritos por pesquisadores do Grupo de Segurança para
Comunicação e Eletrônica (Communications-Electronics Security Group) do Reino Unido
[Cesg, 2000]. Como acontece com frequência, grandes ideias podem surgir de modo
independente em diversos lugares; felizmente, os progressos da criptografia de chaves
públicas ocorreram não apenas no âmbito privado, mas também no público.
O uso da criptografia de chaves públicas é bastante simples. Suponha que Alice queira
se comunicar com Bob. Como mostra a Figura 9.6, em vez de Bob e Alice compartilharem
222
uma única chave secreta (como no caso dos sistemas de chaves simétricas), Bob (o
destinatário das mensagens de Alice) tem duas chaves – uma chave pública, que está à
disposição do mundo todo (inclusive à disposição de Trudy, a intrusa), e uma chave privada,
que apenas ele “Bob” conhece. Para se comunicar com Bob, Alice busca primeiramente a
chave pública de Bob. Em seguida, ela criptografa sua mensagem usando a chave pública de
Bob e um algoritmo criptográfico conhecido (por exemplo, padronizado). Bob recebe a
mensagem criptografada de Alice e usa sua chave privada e um algoritmo de decriptografia
conhecido (por exemplo, padronizado) para decifrar a mensagem de Alice. Dessa maneira,
Alice pode enviar uma mensagem secreta a Bob sem que nenhum deles tenha de permutar
alguma chave secreta!
Figura 9.6 – Criptografia de chaves públicas.
Usando a notação da Figura 9.6, para qualquer mensagem m, dB(eB(m)) = m, isto é,
aplicando a chave pública de Bob, eB, e em seguida a chave privada de Bob, dB, à mensagem
m, recuperamos m. Veremos em breve que podemos permutar as chaves criptográficas
pública e privada e obter o mesmo resultado, isto é, e B(dB(m)) = dB(eB(m)) = m.
O uso da criptografia de chave pública é, portanto, conceitualmente simples. Mas
apresenta duas preocupações. A primeira preocupação diz respeito ao conhecimento público
da chave e do algoritmo de criptografia, isto é, embora um intruso que intercepta a mensagem
cifrada de Alice veja apenas dados ininteligíveis, ele conhece tanto a chave (a chave pública
de Bob, que está disponível a todos) quanto o algoritmo que Alice usou para a criptografia.
Assim, Trudy pode montar um ataque ao texto aberto escolhido utilizando o algoritmo
criptográfico padronizado conhecido e a chave criptográfica de acesso público de Bob para
codificar a mensagem que quiser! Ela pode até tentar, por exemplo, decodificar mensagens,
ou partes delas, que suspeita que Alice tenha enviado. Fica claro que, para a criptografia de
chave pública funcionar, a escolha de chaves e de códigos de criptografia/decriptografia deve
ser feita de tal maneira que seja impossível (ou, ao menos, tão difícil que se torne quase
impossível) para um intruso determinar a chave privada de Bob ou conseguir decifrar ou
adivinhar a mensagem de Alice a Bob. A segunda preocupação se refere ao envio da
mensagem cifrada, ou seja, como a chave criptográfica de Bob é pública, qualquer um pode
enviar uma mensagem cifrada a Bob, incluindo Alice ou alguém se passando por Alice. No
caso de uma única chave secreta compartilhada, o fato de o remetente conhecer a chave
secreta identifica implicitamente o remetente para o destinatário. No caso da criptografia de
chave pública, contudo, isso não acontece, já que qualquer um pode enviar uma mensagem
cifrada a Bob usando a chave dele, que está publicamente disponível a todos. É preciso uma
assinatura digital, um tópico que estudaremos na Seção 9.4, para vincular um remetente à
mensagem.
223
9.3
Autenticação: quem é você?
Autenticação é o processo de provar a própria identidade a alguém. Como seres humanos,
autenticamo-nos mutuamente de muitas maneiras: reconhecemos mutuamente nosso rosto quando
nos encontramos, reconhecemos mutuamente nossa voz ao telefone, somos autenticados pela
autoridade alfandegária que nos compara à foto em nosso passaporte.
Nesta seção, veremos como uma parte pode autenticar uma outra parte quando as duas estão
se comunicando por uma rede. Examinaremos aqui a autenticação de uma parte “ao vivo”, no
instante em que a comunicação está realmente ocorrendo. Veremos que esse problema é um
pouco diferente do problema de provar que uma mensagem recebida em algum momento no
passado (por exemplo, que possa ter sido arquivada) é, na verdade, de quem se declarou como o
remetente. Esse último problema é chamado de problema de assinatura digital, um assunto que
examinaremos na Seção 9.4.
Ao fazer a autenticação pela rede, as partes comunicantes não podem confiar em
informações biométricas, como a aparência visual ou a voz característica. Na verdade, veremos
em nossos estudos de caso posteriores que são muitas vezes componentes da rede, como
roteadores e processos cliente/servidor, que devem se autenticar mutuamente. Aqui, a
autenticação deve ser feita somente na base de mensagens e de dados trocados como parte de um
protocolo de autenticação. Em geral, um protocolo de autenticação deveria rodar antes que as
duas partes comunicantes rodassem qualquer outro protocolo (por exemplo, um protocolo de
transferência de dados confiável, um protocolo de troca de tabelas de roteamento ou um protocolo
de e-mail). O protocolo de autenticação estabelece primeiramente as identidades das partes de
maneira satisfatória para ambas; somente após a autenticação as partes se lançam à tarefa que têm
em mãos.
Desenvolveremos várias versões de um protocolo de autenticação, que chamaremos de
PA – protocolo de autenticação, com alguns furos (isto é, falhas na segurança) que deverão ser
descobertos durante a apresentação de cada versão. Vamos começar supondo que Alice precisa
se autenticar para Bob.
9.3.1
Protocolo de autenticação PA 1.0
O protocolo de autenticação mais básico que podemos imaginar talvez seja um
protocolo em que Alice simplesmente envia uma mensagem a Bob dizendo que ela é Alice.
Esse protocolo é mostrado na Figura 9.7. A falha aqui é óbvia – não há meios de Bob saber
se a pessoa que está enviando a mensagem “Eu sou Alice” é realmente Alice. Por exemplo,
Trudy (a intrusa) poderia muito bem enviar essa mensagem.
Figura 9.7 – Protocolo PA 1.0 e um cenário de falha.
224
9.3.2
No caso em que Alice tem um endereço de rede conhecido (por exemplo, um endereço
IP), que usa sempre que quer se comunicar, Bob poderia tentar autenticar Alice verificando
se o endereço de fonte do datagrama IP que carrega a mensagem de autenticação é o mesmo
daquele endereço conhecido de Alice. Se for, Alice estará autenticada. Isso poderia impedir
que um intruso de rede muito ingênuo se fizesse passar por Alice. Mas não deteria o
estudante determinado que está lendo este livro e muitos outros! Veja a Figura 9.8.
Dado que já estudamos a rede e a camada de enlace, sabemos que não é tão difícil (por
exemplo, se alguém tivesse acesso ao código do sistema operacional e pudesse construir seu
próprio núcleo de sistema operacional, como é o caso do Linux e de vários outros sistemas
operacionais de acesso grátis) criar um datagrama IP, colocar qualquer endereço IP de fonte
que quiséssemos (por exemplo, incluir o endereço IP conhecido de Alice) dentro do
datagrama IP e enviá-lo pelo protocolo de camada de enlace ao próximo roteador. Dali em
diante, o datagrama incorretamente endereçado seria transmitido até Bob. Essa abordagem
é um tipo de falsificação do IP, uma técnica muito conhecida de ataque à segurança. A
falsificação do IP poderá ser evitada se o roteador estiver configurado para recusar
datagramas IP que não têm um dado endereço IP. Por exemplo, o roteador de primeiro salto
de Trudy poderia ser configurado para repassar apenas datagramas que contivessem o
endereço IP de fonte da própria Trudy. Contudo, essa capacidade não é universalmente
disseminada nem obrigatória. Assim, seria tolice de Bob achar que o administrador de rede
de Trudy (que poderia ser ela mesma) configuraria o roteador de primeiro salto dela para
repassar apenas os datagramas adequadamente endereçados.
9.3.3
Uma abordagem clássica para a autenticação é usar uma senha secreta. Temos números
secretos para nos identificarmos nos caixas automáticos e senhas de login para sistemas
operacionais. A senha é um segredo compartilhado pelo autenticador e pela pessoa que está
sendo autenticada. Vimos que o HTTP usa um esquema de autenticação baseado em senha.
O Telnet e o FTP também utilizam senha de autenticação. Assim, no protocolo PA 3.0, Alice
envia sua senha secreta a Bob, como mostra a Figura 9.9.
A falha de segurança, nesse caso, é visível. Se Trudy bisbilhotar uma comunicação de
Alice, ela poderá descobrir a senha dela. Para que você não pense que isso é improvável,
considere o fato de que, quando se inicia uma sessão Telnet com outro computador e se faz
o login, a senha de login não é criptografada para ser enviada ao servidor Telnet. Alguém
conectado ao Telnet cliente ou ao servidor da LAN poderia “procurar” (ler e armazenar) todos
os pacotes transmitidos pela LAN e, dessa maneira, se apossar da senha de login. De fato,
225
essa é uma abordagem muito conhecida para roubar senhas. Essa ameaça, obviamente, é
muito real; portanto, o PA 3.0 com certeza não é apropriado.
9.3.4
Como acabamos de estudar a criptografia na seção anterior, nossa próxima ideia para
consertar o PA 3.0 é, naturalmente, usar a criptografia. Criptografando a senha de Alice,
Trudy não conseguirá descobri-la! Supondo-se que Alice e Bob compartilhem uma chave
simétrica secreta, KA–B, então Alice pode codificar a senha e enviar sua mensagem de
identificação, “Eu sou Alice”, e sua senha criptografada a Bob. Bob então decifra a senha e,
se a senha estiver correta, autentica Alice. Ele fica tranquilo ao autenticar Alice, já que ela
conhece não somente a senha, mas também o número da chave secreta necessário para
codificar a senha. Vamos chamar esse protocolo de PA 3.1.
Embora seja verdade que o PA 3.1 impede que Trudy descubra a senha de Alice, o uso
de criptografia nesse caso não resolve o problema da autenticação! Bob novamente está
sujeito ao denominado ataque de reprodução: basta Trudy bisbilhotar uma comunicação de
Alice, gravar a versão criptografada da senha e, mais tarde, reproduzir essa versão
criptografada para Bob, fingindo que é Alice. O uso de uma senha criptografada não faz com
que a situação fique muito diferente daquela da Figura 9.9.
9.3.5
O problema com o PA 3.1 é que a mesma senha é usada repetidamente. Um modo de
solucionar esse problema seria utilizar cada vez uma senha diferente. Alice e Bob poderiam
combinar uma sequência de senhas (ou um algoritmo para geração de senhas) e usar cada
uma delas apenas uma vez, em sequência. Essa ideia é usada no sistema S/KEY [RFC 1760],
que adota um mecanismo lançado por Lamport para gerar uma sequência de senhas.
No entanto, em vez de pararmos nesse ponto da solução, vamos considerar uma
abordagem mais geral para combater o ataque de reprodução. O cenário de falha da
Figura 9.9 resultou do fato de Bob não conseguir distinguir a autenticação original de Alice
da reprodução da autenticação original de Alice. Em outras palavras, Bob não conseguiu
saber se Alice estava “ao vivo” na conexão (isto é, se naquela ocasião Alice estava realmente
na outra extremidade da conexão) ou se as mensagens que ele estava recebendo eram uma
reprodução gravada de uma autenticação anterior de Alice. O leitor muito (muito) observador
vai lembrar que o protocolo de apresentação de três vias do TCP tinha de enfrentar o mesmo
problema – o lado servidor de uma conexão TCP não era obrigado a aceitar uma conexão se
o segmento SYN recebido fosse uma cópia antiga (retransmissão) de um segmento SYN de
226
uma conexão anterior. Como o lado servidor do TCP resolvia o problema de determinar se
o cliente estava realmente “ao vivo”? Ele escolhia um número de sequência inicial que não
era usado a um longo período de tempo, enviava esse número ao cliente e ficava esperando
que o cliente respondesse com um segmento ACK contendo esse número. Podemos adotar
a mesma ideia aqui, para a finalidade de autenticação.
Um nonce é um número que um protocolo vai usar apenas uma vez. Assim que um
protocolo usar um nonce, nunca mais o utilizará. Nosso protocolo PA 4.0 usa um nonce
como segue:
1. Alice envia a mensagem “Eu sou A1ice” para Bob.
2. Bob escolhe um nonce, R, e o envia a Alice.
3. Alice criptografa o nonce usando a chave simétrica secreta KA–B que combinou com Bob
e envia o nonce cifrado KA–B(R) de volta a Bob. Como acontece no protocolo PA 3.1, é
o fato de Alice conhecer a chave KA–B e usá-la para codificar um valor que permite que
Bob saiba que a mensagem que recebeu foi gerada por Alice. O nonce é utilizado para
assegurar que Alice está “ao vivo”.
4. Bob decifra a mensagem recebida. Se o nonce decifrado for igual ao nonce que enviou a
Alice, então ela estará autenticada.
O protocolo PA 4.0 está ilustrado na Figura 9.10. Usando um valor R apenas uma
única vez e, em seguida, verificando o valor devolvido, KA–B(R), Bob pode ter certeza de que
Alice é quem diz ser (já que conhece o valor da chave secreta necessário para cifrar R), e
também de que ela está “ao vivo” (já que ela tem o nonce cifrado R que Bob acabou de criar).
9.3.6
O uso de um nonce e da criptografia de chaves simétricas criou a base de nosso bemsucedido protocolo de autenticação PA 4.0. Uma pergunta natural é se podemos usar um
nonce juntamente com a criptografia de chaves públicas (em vez de a criptografia de chaves
simétricas) para resolver o problema de autenticação. A utilização de uma abordagem de
chaves públicas evitaria a dificuldade existente em qualquer sistema compartilhado – a
preocupação com o modo pelo qual as duas partes ficarão conhecendo o valor da chave
secreta compartilhada, em primeiro lugar. O uso que o protocolo PA 5.0 faz da criptografia
de chaves públicas é análogo ao uso que o protocolo PA 4.0 faz da criptografia de chaves
simétricas:
1. Alice envia a mensagem “Eu sou A1ice” para Bob.
2. Bob escolhe um nonce, R, e o envia a Alice. Novamente, o nonce é usado para ele se
certificar de que Alice está “ao vivo”.
3. Alice usa seu algoritmo criptográfico privado com sua chave privada, dA, para o nonce e
envia o valor resultante dA(R) a Bob. Como somente Alice conhece sua chave privada,
ninguém, exceto ela, pode gerar dA(R).
227
4. Bob aplica o algoritmo criptográfico público de Alice, e A, à mensagem recebida, isto é,
ele processa eA(dA(R)). Lembre-se de que em nossa discussão sobre a criptografia de
chave pública RSA, na Seção 9.2, eA(dA(R)) = R = dA(eA(R)). Assim, Bob calcula R e
autentica Alice.
A operação do protocolo PA 5.0 é ilustrada na Figura 9.11. O protocolo PA 5.0 é tão
seguro quanto o protocolo PA 4.0? Ambos usam nonces. Como o PA 5.0 usa técnicas de
chave pública, ele requer que Bob recupere a chave pública de Alice. Isso leva a um cenário
interessante, mostrado na Figura 9.12, em que Trudy pode se passar por Alice perante Bob:
Figura 9.11 – Protocolo PA 5.0 trabalhando corretamente.
1. Trudy envia a mensagem “Eu sou A1ice” para Bob.
2. Bob escolhe um nonce, R, e o envia a Alice, mas a mensagem é interceptada por Trudy.
3. Trudy aplica seu algoritmo criptográfico privado com sua chave privada, d T para o nonce
e envia o valor resultante, dT(R), a Bob. Para Bob, dT(R) é apenas uma porção de bits, e
ele não sabe se os bits representam dT(R) ou dA(R).
4. Bob deve agora pegar a chave pública de Alice para aplicar e A ao valor que acabou de
receber. Ele envia a mensagem a Alice, pedindo seu e A (Bob também pode recuperar a
chave pública de Alice do site Web dela). Trudy intercepta também essa mensagem e
responde a Bob devolvendo eT, isto é, a chave pública dela. Bob então calcula
eT(dT(R)) = R e, assim, autentica Trudy como se ela fosse Alice!
Figura 9.12 – Falha de segurança no protocolo PA 5.0.
Fica claro nesse cenário que o protocolo PA 5.0 é tão “seguro” quanto a distribuição
de chaves públicas. Felizmente, existem maneiras seguras de distribuir chaves públicas,
como veremos na Seção 9.5.
No cenário da Figura 9.12, Bob e Alice podem acabar descobrindo, em conjunto, que
alguma coisa está errada, pois Bob vai dizer que interagiu com Alice, mas Alice sabe que
isso não aconteceu. Há um ataque ainda mais insidioso que poderia evitar essa descoberta.
228
No cenário da Figura 9.13, Alice e Bob estão conversando, mas Trudy, explorando a mesma
falha no protocolo de autenticação, consegue se interpor de maneira transparente entre Alice
e Bob. Em particular, se Bob começar a enviar dados cifrados a Alice usando a chave
criptográfica que recebeu de Trudy, Trudy poderá recuperar o texto aberto da comunicação
entre Bob e Alice. Ao mesmo tempo, Trudy pode repassar os dados de Bob a Alice (após ter
decifrado os dados usando a chave pública real de Alice).
Bob está lá, feliz da vida, enviando dados criptografados. Alice também está lá, feliz
da vida, recebendo dados criptografados e usando para isso sua própria chave pública; ambos
não sabem da presença de Trudy. Se acontecer de Bob e Alice se encontrarem mais tarde e
discutirem sua interação, Alice terá recebido exatamente o que Bob enviou, de modo que não
se perceberá que alguma coisa está errada. Esse é um exemplo do chamado ataque do homem
do meio (no caso, da “mulher do meio”). Às vezes ele também é chamado de ataque da
brigada do balde, já que o modo como Trudy está passando os dados entre Alice e Bob parece
a passagem dos baldes de água pela longa fila de pessoas (chamada de “brigada do balde”)
que estão apagando um incêndio utilizando uma fonte de água longínqua.
Figura 9.13 – Um ataque do homem do meio.
9.4
Integridade
Pense no número de vezes em que você pôs sua assinatura em um pedaço de papel durante
a última semana. Você assina cheques, comprovantes de operação de cartões de crédito,
documentos legais e cartas. Sua assinatura atesta o fato de que você (e não outra pessoa) conhece
o conteúdo do documento e/ou concorda com ele. No mundo digital, frequentemente se quer
indicar o dono ou o criador de um documento ou deixar claro que alguém concorda com o
conteúdo de um documento. A assinatura digital é uma técnica criptográfica usada para cumprir
essa finalidade no mundo digital.
Exatamente como acontece com a assinatura de próprio punho, a assinatura digital deve ser
verificável, não falsificável e incontestável. Em outras palavras, deve ser possível “provar” que
um documento assinado por um indivíduo foi na verdade assinado por ele (a assinatura tem de ser
verificável) e que somente aquele indivíduo poderia ter assinado o documento (a assinatura não
pode ser falsificada, e o signatário não pode mais tarde negar ter assinado o documento). Isso se
consegue facilmente com a criptografia de chaves públicas.
229
9.4.1
Geração de assinaturas digitais
Suponha que Bob queira assinar “digitalmente” um documento m. Imagine que o
documento seja um arquivo ou uma mensagem que Bob vai assinar e enviar. Como mostra
a Figura 9.14, para assinar esse documento Bob simplesmente usa sua chave criptográfica
privada dB para processar dB(m). A princípio, pode parecer estranho que Bob esteja rodando
um algoritmo de decriptografia sobre um documento que não foi codificado. Mas lembre-se
de que ”decriptografia” nada mais é do que uma operação matemática (exponenciação à
potência d no RSA; veja a Seção 9.2) e que a intenção de Bob não é embaralhar ou disfarçar
o conteúdo do documento, mas assinar o documento de maneira que seja verificável, não
falsificável e incontestável. Bob tem o documento, m, e sua assinatura digital do documento,
dB(m).
Figura 9.14 – Criação de uma assinatura digital para um documento.
A assinatura digital dB(m) atende às nossas exigências de ser verificável, não
falsificável e incontestável? Suponha que Alice tenha m e dB(m). Ela quer provar na Justiça
(em ação litigiosa) que Bob de fato assinou o documento e que ele era a única pessoa que
poderia tê-lo assinado. Ela pega a chave pública de Bob, e B, e a aplica à assinatura digital
dB(m) associada ao documento m. Em outras palavras, ela processa eB(dB(m)) e, voilà, com
dramática encenação, produz m, que é uma reprodução exata do documento original! Ela
então argumenta que somente Bob poderia ter assinado o documento porque:

Quem quer que tenha assinado o documento deve ter usado a chave criptográfica privada
dB para processar a assinatura dB(m), de modo que eB(dB(m)) = m.

A única pessoa que poderia conhecer a chave privada d B é Bob. Lembre-se que dissemos
em nossa discussão do RSA, na Seção 9.2, que conhecer a chave pública eB não serve
para descobrir a chave privada dB. Portanto, a única pessoa que poderia conhecer d B é
aquela que gerou o par de chaves (eB, dB) em primeiro lugar, ou seja, Bob. (Note que,
para isso, supomos que Bob não passou dB a ninguém e que ninguém “roubou” dB de
Bob).
Também é importante notar que, se o documento original m for modificado para algum
modelo alternativo m’, a assinatura que Bob criou para m não será válida para m’, já que
eB(dB(m)) não é igual a m’.
Assim, vemos que as técnicas da criptografia de chaves públicas fornecem uma
maneira simples e elegante de assinar documentos digitalmente, uma maneira que é
verificável, não falsificável e incontestável e que protege contra modificações posteriores do
documento.
230
9.4.2
Resumo de mensagem
Vimos na subseção anterior que a tecnologia de criptografia de chaves públicas pode
ser usada para criar uma assinatura digital. Uma preocupação quanto à assinatura de dados
por criptografia, contudo, é que codificar e decifrar são processamentos dispendiosos. No
caso da assinatura digital de um documento realmente importante, digamos, uma fusão entre
duas grandes empresas multinacionais ou um acordo com uma criança para que ela limpe seu
quarto uma vez por semana, o custo de processamento pode não ser importante. No entanto,
muitos dispositivos e processos de rede (por exemplo, roteadores trocando informações de
tabela de roteamento e agentes de usuários trocando correspondência por e-mail) trocam de
modo rotineiro, dados que poderiam não ser necessariamente criptografados. No entanto,
eles querem garantir que:

O remetente dos dados seja quem diz ser, ou seja, que o remetente assine os dados e que
essa assinatura possa ser verificada.

Os dados transmitidos não foram modificados desde o momento em que o remetente os
criou e assinou.
Dada a sobrecarga de criptografia e decriptografia, a assinatura de dados por
criptografia/decriptografia completa pode ser exagerada. Uma abordagem mais eficiente,
usando os chamados resumos de mensagem, pode atingir esses dois objetivos sem codificar
completamente a mensagem.
Um resumo de mensagem é muito parecido com uma soma de verificação. Os
algoritmos de resumo de mensagem pegam uma mensagem m, de comprimento arbitrário, e
calculam uma “impressão digital” de comprimento fixo dos dados, conhecida como resumo
de mensagem H(m). O resumo de mensagem protege os dados, uma vez que, se m for
modificado para m’ (seja por má intenção ou por acidente), então a mensagem H(m)
processada para os dados originais (e transmitida com os dados) não vai combinar com a
H(m) processada sobre os dados modificados. O resumo de mensagem provê integridade aos
dados, mas que auxílio presta na assinatura da mensagem m? O objetivo aqui é que, em vez
de Bob assinar digitalmente (criptografar) a mensagem inteira processando d B(m), seria
possível que ele assinasse apenas o resumo de mensagem processando dB(H(m)). Em outras
palavras, ter o conjunto m e dB(H(m)) (note que m não é criptografada) deve ser “tão bom
quanto” ter uma mensagem completa assinada dB(m). Isso significa que o conjunto m e
dB(H(m)) deve ser não falsificável, verificável e incontestável. A não falsificabilidade exigirá
que o algoritmo de resumo de mensagem que calcula o resumo de mensagem tenha algumas
propriedades especiais, como veremos a seguir.
Nossa definição de resumo de mensagem pode parecer muito semelhante à definição
de uma soma de verificação (por exemplo, a soma de verificação da Internet) ou de um código
de detecção de erros muito mais poderoso, como a verificação de redundância cíclica. Ele é
realmente diferente? Somas de verificação, verificações de redundância cíclica e resumos de
mensagem são exemplos das denominadas funções de hash. Como mostra a Figura 9.15,
uma função de hash pega uma entrada de dados, m, e processa uma cadeia de tamanho fixo
conhecida como hash. A soma de verificação da Internet, as CRCs e os resumos de
mensagem estão de acordo com essa definição. Se assinar uma “resumo de mensagem” deve
ser “tão bom quanto” assinar a mensagem inteira, em particular se deve satisfazer à exigência
de que não haja possibilidade de falsificação, então o algoritmo de resumo de mensagem
deve ter as seguintes propriedades adicionais:

Dado um valor de resumo de mensagem x, não deve ser factível descobrir, por meio de
processamento, uma mensagem y, tal que H(y) = x.
231

Não deve ser, em termos computacionais, factível descobrir quaisquer duas mensagens x
e y, tais que H(x) = H(y).
Figura 9.15 – Funções de hash são usadas para criar resumos de mensagem.
Informalmente, essas duas propriedades significam que, em termos de processamento,
é impraticável que um intruso substitua uma mensagem por outra se a primeira estiver
protegida por um resumo de mensagem. Em outras palavras, se (m, H(m)) for o par do
resumo de mensagem criado pelo remetente, então um intruso não poderá falsificar o
conteúdo de outra mensagem, y, de modo que esta tenha o mesmo valor do resumo de
mensagem da mensagem original. Quando Bob assina m, processando dB(H(m)), sabemos
que nenhuma outra mensagem pode substituir m. Além disso, a assinatura digital de Bob,
H(m), identifica exclusivamente Bob como o signatário verificável e incontestável de H(m)
(e, em consequência, também de m), como discutimos na Seção 9.4.1.
Figura 9.16 – Envio de uma mensagem assinada digitalmente.
No contexto em que Bob envia uma mensagem a Alice, a Figura 9.16 apresenta um
resumo do procedimento operacional para a criação de uma assinatura digital. Bob processa
sua mensagem longa original por meio de uma função de hash para criar um resumo de
mensagem. Então, ele criptografa o resumo de mensagem com sua própria chave privada.
A mensagem original (em texto aberto) e o resumo de mensagem digitalmente assinado
(daqui em diante denominado assinatura digital) são, então, enviados a Alice. A Figura 9.17
232
mostra um resumo do procedimento operacional de verificação da integridade da mensagem.
Alice aplica a chave pública do remetente à mensagem para recuperar o resumo de
mensagem. Ela também aplica a função de hash ao texto aberto da mensagem para obter um
segundo resumo de mensagem. Se os dois resumos coincidirem, então Alice poderá ter
certeza quanto à integridade e ao autor da mensagem.
Figura 9.17 – Verificação da integridade de uma mensagem assinada.
9.4.3
Algoritmos de função de hash
É bom nos convencermos de que uma simples soma de verificação, como a da Internet,
daria um péssimo algoritmo de resumo de mensagem. Em vez de processarmos a aritmética
de complemento de 1 (como é feito para a soma de verificação da Internet), vamos processar
uma soma de verificação tratando cada caracter como um byte e somando os bytes em
conjunto usando porções de 4 bytes por vez. Suponha que Bob deva a Alice 100,99 dólares
e lhe envie um vale constituído da sentença encadeada. “IOU100.99BOB.” – (IOU – I Owe
You – Eu devo a você.). A representação ASCII (em notação hexadecimal) para essas letras
é 49, 4F, 55, 31, 30,30, 2E, 39, 39, 42, 4F, 42.
A Figura 9.18 (a parte superior dela) mostra que a soma de verificação dessa mensagem
é B2 Cl D2 AC. Uma mensagem ligeiramente diferente (e que sairia muito mais cara para
Bob) é mostrada na parte de baixo da Figura 9.18. As mensagens “IOUI00.99BOB” e
“IOU900.19BOB” têm a mesma soma de verificação. Assim, esse algoritmo simples viola
as duas exigências citadas anteriormente. Fornecidos os dados originais, é simples descobrir
outro conjunto de dados com a mesma soma de verificação. É claro que, para efeito de
segurança, precisaremos de uma função de hash muito mais poderosa do que a soma de
verificação.
O algoritmo de resumo de mensagem MD5 de Ron Rivest é amplamente usado hoje.
Ele processa um resumo de mensagem de 128 bits por meio de um processo de quatro
estágios, constituído de um estágio de recheio (adição de um “um” seguido de “zeros”
233
suficientes, de modo que o comprimento da mensagem satisfaça a determinadas condições),
um estágio de anexação (anexação de uma representação de 64 bits do comprimento da
mensagem antes do recheio), uma inicialização de um acumulador e um estágio final de
looping, no qual os blocos de 16 palavras da mensagem são processados (destroçados) em
quatro rodadas de processamento. Não se sabe se o MD5 de fato satisfaz às exigências
citadas anteriormente. O autor do MD5 declara: “Conjectura-se que a dificuldade de produzir
duas mensagens que tenham o mesmo resumo é da ordem de 2 64 operações e que a dificuldade
de produzir qualquer mensagem que tenha um dado resumo de mensagem é da ordem de 2128
operações”. Ninguém contestou essas declarações. Para uma descrição do MD5 (incluindo
uma implementação em código de fonte C), consulte o RFC 1321. Aspectos computacionais
do MD5 são discutidos no RFC 1810.
Figura 9.18 – Mensagem inicial e mensagem fraudulenta têm a mesma soma de verificação.
O segundo principal algoritmo de resumo de mensagem em uso atualmente nos Estados
Unidos é o SHA–1 (secure hash algorithm – algoritmo de hash seguro). Esse algoritmo se
baseia em princípios similares aos usados no projeto do MD4 [RFC 1320], o predecessor do
MD5. O uso do SHA–1, um padrão federal norte-americano, é exigido sempre que
aplicações de âmbito federal requerem um algoritmo de resumo de mensagem seguro. Ele
produz um resumo de mensagem de 160 bits.
9.5
Distribuição de chaves e certificação
Na Seção 9.2, vimos que uma desvantagem da criptografia de chaves simétricas era a
necessidade de que as duas partes comunicantes concordassem com sua chave secreta
previamente. Com a criptografia de chaves públicas, a priori esse acordo quanto a um valor
secreto não é necessário. Contudo, como discutimos na Seção 9.2, a criptografia de chaves
públicas também tem suas dificuldades, em particular o problema de obter a chave pública
verdadeira de alguém. Ambos os problemas – determinação de uma chave compartilhada para a
criptografia de chaves simétricas e obtenção de uma chave pública segura, no caso da criptografia
de chaves públicas – podem ser solucionados usando-se um intermediário de confiança. Para a
criptografia de chaves simétricas, esse intermediário de confiança é chamado de central de
distribuição de chaves (Key Distribution Center – KDC), uma entidade de rede única e de
confiança com quem o usuário estabelece uma chave secreta compartilhada. Veremos que a KDC
pode ser usada para obter as chaves compartilhadas necessárias para uma comunicação segura
com todas as outras entidades de rede, evitando algumas das armadilhas que identificamos na
Seção 9.3. No caso da criptografia de chaves públicas, o intermediário de confiança é chamado
de autoridade certificadora (Certification Authority – CA). Uma CA certifica que uma chave
pública pertence a uma determinada entidade (uma pessoa ou uma rede). No caso de uma chave
pública certificada, se a confiança depositada na CA que certificou a chave for absoluta,
234
poderemos ter certeza quanto a quem pertence a chave pública. Uma vez que uma chave pública
é certificada, ela pode ser distribuída de qualquer lugar, incluindo um servidor de chave pública,
uma página Web pessoal ou um disquete.
9.5.1
KDC (central de distribuição de chaves)
Suponha novamente que Bob e Alice queiram se comunicar usando criptografia de
chaves simétricas. Eles nunca se encontraram (talvez tenham se conhecido em uma sala de
bate-papo on-line) e, assim, não combinaram uma chave secreta. Como é possível, então,
que eles combinem uma chave secreta, dado que só podem se comunicar um com o outro
pela rede? Uma solução frequentemente adotada na prática é usar uma KDC.
A KDC é um servidor que compartilha uma chave simétrica secreta diferente com cada
um de seus usuários registrados. Essa chave pode ser instalada manualmente no servidor
quando o usuário se registrar pela primeira vez. A KDC conhece a chave secreta de cada
usuário, e cada um deles pode se comunicar com segurança com a KDC usando essa chave.
Vejamos como o conhecimento dessa única chave permite que um usuário obtenha uma
chave para se comunicar com qualquer outro usuário registrado. Suponha que Alice e Bob
sejam usuários da KDC; eles conhecem apenas suas próprias chaves individuais, KA–KDC e
KB–KDC, respectivamente, para se comunicar com segurança com a KDC. Alice dá o primeiro
passo, e eles continuam como ilustrado na Figura 9.19.
Figura 9.19 – Estabelecimento de uma chave de sessão única usando uma KDC.
1. Usando KA–KDC para codificar sua comunicação com a KDC, Alice envia uma mensagem
à KDC dizendo que ela (A) quer se comunicar com Bob (B). Denominamos essa
mensagem de KA–KDC(A, B).
2. A KDC, como conhece KA–KDC, decriptografa KA–KDC(A, B). Em seguida, ela gera um
número aleatório R1. Esse é o valor da chave compartilhada que Alice e Bob usarão para
realizar criptografia simétrica quando se comunicarem mutuamente. Essa chave é
chamada de chave de sessão única, pois Alice e Bob a utilizarão apenas durante essa
única sessão que estão estabelecendo no momento. A KDC agora precisa informar Alice
e Bob do valor de R1. Assim, ela devolve a mesma mensagem a Alice, criptografada
usando KA–KDC, contendo o seguinte:

R1, a chave de sessão única que Alice e Bob vão usar para se comunicarem.

Um par de valores: A e R1, criptografados pela KDC usando a chave de Bob, KB–KDC.
Chamamos esse valor de KB–KDC(A, R1). É importante notar que a KDC está
enviando à Alice não somente o valor de R1 para seu uso, mas também uma versão
criptografada de R1 e do nome de Alice, criptografados usando a chave de Bob. Alice
não pode decifrar esse par de valores da mensagem (ela não conhece a chave
235
criptográfica de Bob), mas, na verdade, ela não precisa fazê-lo. Veremos em breve
que Alice simplesmente repassa o par de valores criptografados para Bob (que pode
decifrá-los).
Esses itens são colocados na mensagem e criptografados usando a chave compartilhada
de Alice. A mensagem da KDC para Alice é, portanto, KA–KDC(R1, KB–KDC(R1)).
3. Alice recebe a mensagem da KDC, extrai R1 da mensagem e a salva. Ela agora conhece
a chave de sessão única, R1. Ela também extrai KB–KDC(A, R1) e a repassa a Bob.
4. Bob decifra a mensagem recebida KB–KDC(A, R1) usando KB–KDC e extrai A e R1. Ele
agora conhece a chave de sessão única R1 e sabe quem é a pessoa com a qual está
compartilhando essa chave, A. É claro que ele toma o cuidado de autenticar Alice usando
R1 antes de prosseguir.
9.5.2
Kerberos
Kerberos [RFC 1510; Neuman, 1994] é um serviço de autenticação desenvolvido no
MIT que usa técnicas de criptografia de chaves simétricas e uma central de distribuição de
chaves. Embora seja conceitualmente idêntico à KDC genérica descrita na Seção 9.5.1, o
Kerberos tem um vocabulário levemente diferente. Ele contém também diversas variações e
extensões interessantes dos mecanismos básicos da KDC. Ele foi projetado para autenticar
usuários que acessam servidores de rede e era inicialmente dirigido para o uso de um único
domínio administrativo, como um campus ou uma empresa. Assim, ele é estruturado na
linguagem de usuários que querem acessar os serviços da rede (servidores) utilizando
programas de rede de camada de aplicação, como o Telnet (para login remoto) e o NFS (para
acesso a arquivos remotos), em vez de ser estruturado na linguagem de pessoas que querem
conversar entre si e precisam se autenticar mutuamente, como nos exemplos apresentados
até aqui. Não obstante, a chave (trocadilho proposital) subjacente às duas técnicas continua
a mesma.
O servidor de autenticação Kerberos (authetication server – SA) desempenha o papel
da KDC. Ele é o repositório não apenas das chaves secretas de todos os usuários (de modo
que cada usuário pode se comunicar com o SA com segurança), mas também das informações
sobre quais usuários têm acesso privilegiado a quais serviços em quais servidores de rede.
Quando Alice quer acessar um serviço em Bob (que agora consideramos um servidor), o
protocolo segue fielmente o exemplo dado na Figura 9.19:
1. Alice contata o SA Kerberos e indica que quer usar Bob. Toda a comunicação entre Alice
e o SA é criptografada usando uma chave secreta que é compartilhada entre Alice e o SA.
No Kerberos, Alice primeiramente fornece seu nome e senha a seu hospedeiro local. Este
e o SA então determinam a chave de sessão única para criptografar a comunicação entre
Alice e o SA.
2. O SA autentica Alice, verifica se ela tem acesso privilegiado a Bob e gera uma chave
simétrica de sessão única, R1, para a comunicação entre Bob e Alice. O servidor de
autenticação (no jargão do Kerberos, servidor bilheteiro) envia a Alice o valor de R 1 e
também um bilhete de entrada para os serviços de Bob. O bilhete contém o nome de
Alice, a chave da sessão Alice – Bob, R1 e o horário de término, tudo criptografado
usando a chave secreta de Bob (conhecida apenas por Bob e SA), como na Figura 9.19.
O bilhete de Alice é válido só até o horário de término e será rejeitado por Bob se
apresentado após esse horário. Para o Kerberos V4, o tempo máximo de vida útil de um
bilhete é de cerca de 21 horas. No Kerberos V5, o tempo de vida útil deve expirar antes
do final do ano de 9.999, um sério problema para o ano 10.000!
236
3. Alice então envia seu bilhete a Bob. Ela também envia uma marca de tempo
criptografada por R1 que é usada como um nonce. Bob decifra o bilhete usando sua chave
secreta, obtém a chave da sessão e decifra a marca de tempo utilizando a chave da sessão
que acabou de descobrir. Ele devolve o nonce a Alice, criptografado por R1, mostrando,
assim, que ele conhece R1 e que está “ao vivo”.
9.5.3
Certificação de chaves públicas
Uma das características principais da criptografia de chaves públicas é que é possível
que duas entidades troquem mensagens secretas sem ter de trocar chaves secretas. Por
exemplo, quando Alice quer enviar uma mensagem secreta a Bob, ela simplesmente
criptografa a mensagem com a chave pública de Bob e envia a mensagem criptografada a
ele; ela não precisa conhecer a chave secreta (isto é, privada) de Bob nem Bob precisa
conhecer a chave secreta de Alice. Assim, a criptografia de chaves públicas evita a
necessidade de infra-estrutura de KDC, como o Kerberos.
Evidentemente, com a criptografia de chaves públicas, as entidades comunicantes têm
de trocar chaves públicas. Um usuário pode disponibilizar o conhecimento de sua chave
pública de muitas maneiras, como, por exemplo, apresentando a chave em sua página Web
pessoal, colocando-a em um servidor público de chaves ou enviando-a a um correspondente
por e-mail. Um site Web de comércio pode colocar sua chave pública em seu servidor de
modo que os browsers descarreguem automaticamente a chave pública ao se conectarem ao
site. Roteadores podem colocar sua chave pública em servidores de chaves públicas,
permitindo, desse modo, que outras entidades da rede a recuperem.
Há, contudo, um problema sutil, mas importante, com a criptografia de chaves públicas.
Para termos uma percepção desse problema, vamos considerar uma transação comercial pela
Internet, por exemplo. Suponha que Alice trabalhe no ramo de pizzas para viagem e que
aceite pedidos pela Internet. Bob, que adora pizza, envia a Alice uma mensagem em texto
aberto que contém o endereço de sua casa e o tipo de pizza que quer. Nessa mensagem, ele
inclui também sua assinatura digital (isto é, um resumo de mensagem criptografado extraído
da mensagem original em texto aberto). Como discutimos na Seção 9.4, Alice pode obter a
chave pública de Bob (de sua página Web pessoal, de um servidor de chaves públicas ou de
uma mensagem de e-mail) e verificar a assinatura digital. Dessa maneira, ela se certifica de
que foi Bob, e não algum adolescente brincalhão, quem fez o pedido.
Tudo parece caminhar bem até que entra em cena a esperta Trudy. Como mostrado na
Figura 9.20, Trudy decide fazer uma travessura. Ela envia uma mensagem a Alice na qual
diz que é Bob, fornece o endereço de Bob e pede uma pizza. Ela também anexa uma
assinatura digital, mas faz isso assinando o resumo de mensagem com sua chave privada.
Ela também se faz passar por Bob enviando a Alice sua chave pública, mas dizendo que a
chave pertence a Bob. Nesse exemplo, Alice aplicará a chave pública de Trudy (pensando
que é a de Bob) na assinatura digital e concluirá que a mensagem em texto aberto foi, na
verdade, criada por Bob. Este ficará muito surpreso quando o entregador aparecer em sua
casa com uma pizza, com tudo acertado!
237
Figura 9.20 – Trudy se passa por Bob usando a criptografia de chaves públicas.
Por esse exemplo, vemos que, para que a criptografia de chaves públicas seja útil, as
entidades (usuários, browsers, roteadores) precisam ter certeza de que possuem a chave
pública da entidade com a qual estão se comunicando. Por exemplo, quando Alice estiver se
comunicando com Bob usando criptografia de chaves públicas, ela precisa saber, com
certeza, que a chave pública, que supostamente é de Bob, é de fato dele. Tínhamos
preocupações semelhantes em nossos protocolos de autenticação apresentados na Figura 9.12
e na Figura 9.13.
A vinculação de uma chave pública a uma entidade particular é feita, tipicamente, por
uma autoridade certiticadora (certification authority – CA), cuja tarefa é validar identidades
e emitir certificados. A CA tem as seguintes incumbências:
1. A CA verifica se uma entidade (pessoa, roteador e assim por diante) é quem se diz ser.
Não há procedimentos obrigatórios quanto ao modo como deve ser feita a certificação.
Ao tratarmos com uma CA, devemos confiar que ela tenha realizado uma verificação
rigorosa da entidade. Por exemplo, se Trudy conseguisse entrar na autoridade
certificadora Fly-by-night, e simplesmente declarasse “Eu sou Alice” e recebesse
certificados associados à identidade “Alice”, então não se deveria dar muita credibilidade
às chaves públicas certificadas pela autoridade certificadora Fly-by-night. Por outro lado,
seria mais sensato (ou não!) estar inclinado a confiar em uma CA que faz parte de um
programa federal ou estadual. O grau de confiança que se tem na “identidade” associada
a uma chave pública equivale apenas ao grau de confiança depositada na CA e em suas
técnicas de verificação de identidades. Em que rede emaranhada estamos enredados!
2. Assim que a CA verifica a identidade da entidade, ela cria um certificado que vincula a
chave pública da entidade à identidade. O certificado contém a chave pública e a
informação exclusiva que identifica mundialmente a chave pública do proprietário (por
exemplo, o nome de alguém ou um endereço IP). Esses passos são mostrados na
Figura 9.21.
238
Figura 9.21 – Bob obtém um certificado de uma CA.
Vejamos, agora, como os certificados podem ser usados para combater os espertinhos
das pizzas, como Trudy e outros indesejáveis. Quando Alice recebe o pedido de Bob, ela
pega o certificado de Bob, que pode estar na página Web dele, em uma mensagem de e-mail
ou em um servidor de certificados. Alice usa a chave pública da CA para verificar se a chave
pública do certificado de Bob é, de fato, de Bob. Supomos que a chave pública da CA seja
conhecida de todos (por exemplo, poderia ser divulgada em um local conhecido e de
confiança, como no jornal The New York Times, de modo que todos a conheçam e que não
possa ser falsificada) e que Alice então possa ter certeza de que está realmente tratando com
Bob. A Figura 9.21 ilustra os passos envolvidos na criptografia de chaves públicas mediada
por uma CA.
Tanto a International Telecommunication Union (ITU) quanto a IETF desenvolveram
padrões para autoridades certificadoras. Na recomendação ITU X.509, encontramos
especificado um serviço de autenticação, bem como uma sintaxe própria para os certificados.
O RFC 1422 descreve um gerenciamento de chaves baseado em CA para uso com o e-mail
seguro pela Internet. Essa recomendação é compatível com a X.509, mas vai além desta,
pois estabelece procedimentos e convenções para uma arquitetura de gerenciamento de
chaves. A Tabela 9.1 apresenta alguns campos importantes de um certificado.
Nome do Campo
Descrição
Versão
Número de Série
Assinatura
Número da versão da especificação X.509
Identificador exclusivo emitido pela CA para um certificado
Especifica o algoritmo usado pela CA para “assinar” esse certificado
Identidade da CA que emitiu o certificado no formato chamado de nome distinto (DN)
Nome do Emissor
especificado no RFC 2253
Período de Validade
Início e fim do período de validade de um certificado
Nome do Sujeito
Identidade da entidade cuja chave pública está associada a esse certificado, em formato DN
A chave pública do sujeito, bem como uma indicação do algoritmo de chave pública (e
Chave Pública do Sujeito
parâmetros do algoritmo) a ser usado com essa chave
Tabela 9.1 – Campos selecionados de um certificado de chave pública X.509 e RFC 1422.
Com o crescimento do comércio eletrônico e a consequente necessidade de garantir a
segurança das transações, tem havido um interesse crescente em autoridades certificadoras.
239
Dentre as empresas que fornecem serviços de CA destacam-se a Cybertrust, a Verisign e a
Netscape.
9.6
E-mail seguro
Nas seções anteriores, examinamos as questões fundamentais da segurança na rede,
incluindo a criptografia de chaves simétricas e a de chaves públicas, a autenticação, a distribuição
de chaves, a integridade de mensagens e as assinaturas digitais. Vamos agora examinar como
essas ferramentas estão sendo usadas para fornecer segurança na Internet. É interessante o fato
de que é possível fornecer serviços de segurança em qualquer uma das quatro camadas superiores
da pilha de protocolos da Internet. Quando é fornecida segurança para um protocolo específico
de camada de aplicação, a aplicação que usa o protocolo desfruta de um ou mais serviços de
segurança, como sigilo, autenticação ou integridade. Quando a segurança é fornecida para um
protocolo de camada de transporte, todas as aplicações que usam o protocolo desfrutam dos
serviços de segurança do protocolo de transporte. Quando a segurança é fornecida na camada de
rede, na base de host a host, todos os segmentos de camada de transporte (e, por conseguinte,
todos os dados de camada de aplicação) desfrutam dos serviços de segurança da camada de rede.
Quando a segurança é fornecida com base no enlace, todos os dados de todos os quadros que estão
trafegando pelo enlace recebem os serviços de segurança do enlace.
Nesta e nas duas seções seguintes, veremos como as ferramentas de segurança estão sendo
usadas nas camadas de aplicação, transporte e rede. Começaremos pelo topo da pilha de
protocolos, discutindo a segurança no nível da camada de aplicação. Nessa discussão, usaremos
uma aplicação específica, ou seja, o e-mail, como estudo de caso para a segurança na camada de
aplicação. Em seguida, desceremos pela pilha de protocolos. Na Seção 9.7, examinaremos o
protocolo SSL, que fornece segurança ao TCP na camada de transporte. Na Seção 9.8,
consideraremos o IPsec, que fornece segurança à camada de rede.
É bem possível que você esteja pensando por que a funcionalidade de segurança da Internet
está sendo fornecida em mais de uma camada. Não seria suficiente simplesmente fornecer
funcionalidade de segurança na camada de rede e esquecer o assunto? Essa pergunta pode ser
respondida de dois modos. Em primeiro lugar, embora exista na camada de rede um “cobertor de
segurança” com a criptografia de todos os dados dos datagramas (isto é, de todos os segmentos
de camada de transporte) e com a autenticação de todos os endereços IP de origem, isso não
garante segurança no nível do usuário. Por exemplo, um site comercial não pode confiar na
segurança da camada IP para autenticar um cliente que está comprando mercadorias nesse site.
Assim, há necessidade de uma funcionalidade de segurança nas camadas mais altas, bem como
um “cobertor de segurança” nas camadas mais baixas. Em segundo lugar, é geralmente mais fácil
disponibilizar novos serviços de Internet, incluindo serviços de segurança, nas camadas mais altas
da pilha de protocolos. Enquanto aguardamos que a segurança seja disseminada de maneira ampla
na camada de rede, o que ainda levará alguns anos para acontecer, muitos desenvolvedores de
aplicação tomam a iniciativa de fazê-lo mesmo assim e introduzem a funcionalidade em suas
aplicações favoritas. Um exemplo clássico é o PGP, que fornece e-mail seguro (o PGP será
discutido mais adiante nesta seção). Como exige apenas programas de aplicação cliente e
servidor, o PGP foi uma das primeiras tecnologias de segurança a ser usada amplamente na
Internet.
9.6.1
Princípios de segurança para e-mail
Nesta seção, usaremos muitas das ferramentas apresentadas na seção anterior para criar
um projeto de alto nível para um sistema de e-mail seguro. Criamos esse projeto de alto nível
de maneira incremental, introduzindo, a cada estágio, novos serviços de segurança. Ao
projetarmos um sistema de e-mail seguro, vamos manter em mente o exemplo malicioso
240
apresentado na Seção 9.1 – o caso de amor entre Alice e Bob. Nesse contexto, Alice quer
enviar uma mensagem de e-mail para Bob e Trudy quer bisbilhotar a mensagem.
Antes de avançarmos e projetarmos um sistema de e-mail seguro para Alice e Bob,
devemos considerar quais características de segurança seriam as mais desejáveis para eles.
A primeira característica, e a mais importante, é o sigilo. Como foi discutido na Seção 9.1,
nem Alice nem Bob querem que Trudy leia a mensagem de e-mail de Alice. A segunda
característica que Alice e Bob provavelmente gostariam de ver no sistema de e-mail seguro
é a autenticação do remetente. Em particular, quando Bob receber a seguinte mensagem de
Alice “Eu não o amo mais. Nunca mais quero vê-lo. Da anteriormente sua, Alice”, ele
naturalmente vai querer ter certeza de que a mensagem veio de Alice, e não de Trudy. Outra
característica de segurança que os dois amantes gostariam de dispor é a integridade de
mensagem, isto é, a certeza de que a mensagem que Alice enviar não será modificada no
trajeto até Bob. Por fim, o sistema de e-mail deve fornecer autenticação do receptor, isto é,
Alice quer ter certeza de que ela de fato está mandando a mensagem para Bob, e não para
outra pessoa (por exemplo, Trudy) que possa estar se passando por Bob.
Assim, vamos começar abordando a primeira preocupação de Alice e Bob, ou seja, o
sigilo. A maneira mais direta de consegui-lo é Alice criptografar a mensagem por tecnologia
de chaves simétricas (como o DES) e Bob decifrar a mensagem ao recebê-la. Como discutido
na Seção 9.2, se a chave simétrica for suficientemente longa e se somente Alice e Bob
possuírem a chave, então será reduzidíssima a possibilidade de alguém (incluindo Trudy) ler
a mensagem. Embora essa seja uma abordagem direta, ela apresenta a dificuldade
fundamental que discutimos na Seção 9.2 – é difícil distribuir chaves simétricas de modo que
apenas Bob e Alice tenham cópias delas. Assim, a criptografia de chaves públicas (usando,
por exemplo, RSA) é, naturalmente, uma ferramenta alternativa. Na abordagem de chave
pública, Bob disponibiliza publicamente sua chave pública (por exemplo, em um servidor de
chaves públicas ou em sua página Web pessoal) e Alice criptografa a mensagem com a chave
pública de Bob, enviando a mensagem cifrada para o endereço de e-mail de Bob. (A
mensagem codificada é encapsulada com cabeçalhos Mime e enviada sobre SMTP comum.)
Quando Bob recebe a mensagem, ele simplesmente a decifra com sua chave privada.
Supondo que Alice tenha certeza de que a chave pública que usou é a de Bob (e de que esta
é suficientemente longa), então essa abordagem é um meio excelente de fornecer o desejado
sigilo. Um problema, contudo, é que a criptografia de chaves públicas é relativamente
ineficiente, sobretudo para as mensagens longas. (Mensagens de e-mail longas agora são
muito comuns na Internet, devido ao crescimento do uso de anexos, imagens, áudio e vídeo.)
Para superarmos o problema da eficiência, vamos fazer uso de uma chave de sessão
(discutida na Seção 9.5). Em particular, Alice (1) escolhe uma chave simétrica, KS,
aleatoriamente, (2) criptografa sua mensagem m com a chave simétrica KS, (3) criptografa a
chave simétrica com a chave pública de Bob, e B, (4) concatena a mensagem cifrada e a chave
simétrica cifrada de modo que formem um “pacote” e (5) envia o pacote ao endereço de email de Bob. Os passos estão ilustrados na Figura 9.22. (Nessa figura e nas subsequentes, o
sinal “+” representa a concatenação e o sinal “–“, a desconcatenação.) Quando Bob receber
o pacote, ele vai (1) usar sua chave privada d B para obter a chave simétrica KS e (2) utilizar
a chave simétrica KS para decifrar a mensagem m.
241
Figura 9.22 – Alice usa uma chave de sessão simétrica K S.
Agora que projetamos um sistema de e-mail seguro que fornece sigilo, vamos
desenvolver um outro sistema que forneça a autenticação do remetente e a integridade da
mensagem. Vamos supor, no momento, que Alice e Bob não estejam mais preocupados com
o sigilo (querem compartilhar seus sentimentos com todos!) e que estejam somente
preocupados com a autenticação do remetente e com a integridade da mensagem. Para
realizarmos essa tarefa, faremos uso de assinaturas digitais e resumos de mensagem, como
descrito na Seção 9.4. Especificamente, Alice (1) aplica uma função de hash H (por exemplo,
MD5) à sua mensagem m, para obter um resumo de mensagem, (2) criptografa o resultado
da função de hash com sua chave privada dA, para criar uma assinatura digital, (3) concatena
o original (mensagem não codificada) com a assinatura para criar um pacote e (4) envia o
pacote ao endereço de e-mail de Bob. Quando Bob recebe o pacote, ele (1) aplica a chave
pública de Alice, eA, ao resumo de mensagem assinado e (2) compara o resultado dessa
operação com o próprio hash H da mensagem. Os passos são ilustrados na Figura 7.25.
Como discutimos na Seção 9.5, se os dois resultados forem os mesmos, Bob poderá estar
certo de que a mensagem veio de Alice e não foi alterada.
Figura 9.23 – Uso de funções de hash e assinaturas digitais.
Vamos considerar agora o projeto de um sistema de e-mail que forneça sigilo,
autenticação do remetente e integridade de mensagem. Isso pode ser feito pela combinação
dos procedimentos da Figura 9.22 e Figura 9.23. Primeiramente, Alice cria um pacote
preliminar, exatamente como mostra a Figura 9.23, constituído de sua mensagem original
junto com um hash da mensagem assinado digitalmente. Em seguida, ela trata esse pacote
preliminar como uma mensagem em si e envia essa nova mensagem seguindo os passos do
remetente mostrados na Figura 9.22, criando um novo pacote que é enviado a Bob. Os passos
dados por Alice são mostrados na Figura 9.24. Quando Bob recebe o pacote, ele aplica
primeiramente seu lado da Figura 9.22 e depois seu lado da Figura 9.23. Deve ficar claro
que esse projeto atinge o objetivo de fornecer sigilo, autenticação do remetente e integridade
de mensagem. Note que nesse esquema Alice aplica a criptografia de chaves públicas duas
242
vezes: uma vez com sua chave privada e uma vez com a chave pública de Bob. De maneira
semelhante, Bob aplica a criptografia de chave pública duas vezes – uma vez com sua chave
privada e uma vez com a chave pública de Alice.
O projeto de e-mail seguro ilustrado na Figura 9.24 provavelmente fornece segurança
satisfatória para os usuários de e-mail na maioria das ocasiões. Mas ainda resta uma questão
importante a ser abordada. O projeto da Figura 9.24 requer que Alice obtenha a chave pública
de Bob e que Bob obtenha a chave pública de Alice. A distribuição dessas chaves é um
problema incomum. Por exemplo, Trudy poderia se disfarçar de Bob e dar a Alice sua chave,
dizendo que é a chave pública de Bob. Como aprendemos na Seção 9.5, uma abordagem
popular para distribuir chaves públicas com segurança é certificá-las.
Figura 9.24 – Alice usa várias técnicas para enviar uma mensagem.
9.6.2
PGP (privacidade razoável)
Projetado originalmente por Phil Zimmermann em 1991, o PGP (Pretty Good
Privacy – privacidade razoável) é um esquema de criptografia para e-mail que se tornou um
padrão de fato. O site do PGP é acessado mais de um milhão de vezes por mês por usuários
de 166 países. Versões do PGP estão disponíveis em domínio público; por exemplo, você
pode encontrar o software PGP para sua plataforma favorita, bem como grande quantidade
de material de leitura interessante, na home page internacional do PGP. O PGP também pode
ser adquirido no comércio. Ele pode ser encontrado ainda como elemento adicional para
muitos agentes de usuário de e-mail, incluindo o Exchange e o Outlook da Microsoft e o
Eudora da Qualcomm.
O projeto do PGP é em essência idêntico ao projeto apresentado na Figura 9.24.
Dependendo da versão, o software do PGP usa MD5 ou SHA para processar o resumo de
mensagem; Cast, DES triplo ou Idea para criptografar chaves simétricas, e RSA para
criptografar chaves públicas. Além disso, o PGP fornece compressão de dados.
Quando o PGP é instalado, o software cria um par de chaves públicas para o usuário.
A chave pública pode então ser colocada no site do usuário ou em um servidor de chaves
públicas. A chave privada é protegida pelo uso de uma senha. A senha tem de ser informada
todas as vezes que o usuário acessa a chave privada. O PGP oferece ao usuário a opção de
assinar digitalmente a mensagem, criptografar a mensagem ou, ainda, ambas as opções:
assinar digitalmente e criptografar a mensagem. A Figura 9.25 mostra uma mensagem PGP
assinada. Essa mensagem aparece após o cabeçalho Mime. Os dados codificados da
mensagem correspondem a dA(H(m)), ou seja, ao resumo de mensagem assinado
digitalmente. Como discutimos antes, para que Bob verifique a integridade da mensagem,
ele precisa ter acesso à chave pública de Alice.
243
- - - - BEGIN PGP SIGNED MESSAGE - - - - Hash: SHA1
Bob:
My husband is out of town tonight.
Passionately yours, Alice
- - - - - BEGIN PGP SIGNATURE - - - - Version: PGP for Personal Privacy 5.0
Charset: noconv
yhHJRHhGJGhgg/12EpJ+1º8gE4vB3mqJhFEvZP9t6n7G6m5Gw2
- - - - - END PGP SIGNATURE - - - - Figura 9.25 – Mensagem PGP assinada.
A Figura 9.26 mostra uma mensagem PGP secreta. Essa mensagem também aparece
após o cabeçalho Mime. É claro que a mensagem em texto aberto não está incluída na
mensagem de e-mail secreta. Quando um remetente (como Alice) quer não apenas o sigilo,
mas também a integridade, o PGP contém uma mensagem como a da Figura 9.26 dentro da
mensagem da Figura 9.25.
- - - - - BEGIN PGP MESSAGE - - - - Version: PGP for Personal Privacy 5.0
U2R4d+/jKmn8Bc5hgDsqAewsDfrGdszX681iKm5F6Gc4sDfcXytRfdS10juHgb
cfDssWe7/K=1KhnMikLo0+1/BvcX4t==Ujk9PbcD4Thdf2awQfgHbnmK1ok8iy
6gThlp
- - - - - END PGP MESSAGE
Figura 9.26 – Mensagem PGP secreta.
O PGP também fornece um mecanismo para certificação de chaves públicas, mas esse
mecanismo é bem diferente daquele da autoridade certificadora mais convencional. As
chaves públicas do PGP são certificadas por uma rede de confiabilidade. A própria Alice
pode certificar qualquer par chave/usuário quando ela achar que esse par está correto. Além
disso, o PGP permite que Alice declare que ela confia em outro usuário para atestar a
autenticidade de mais chaves. Alguns usuários do PGP assinam reciprocamente suas chaves
montando grupos de assinatura de chaves. Os usuários se reúnem fisicamente, trocam
disquetes contendo as chaves públicas e certificam suas chaves reciprocamente, assinandoas com suas chaves privadas. As chaves públicas PGP também são distribuídas por
servidores de chaves públicas PGP, pela Internet. Quando um usuário apresenta uma chave
pública a esse servidor, este armazena uma cópia da chave, envia uma cópia a todos os outros
servidores de chaves públicas e serve a chave a quem quer que a solicite. Embora os grupos
de assinantes de chaves e os servidores de chaves públicas PGP realmente existam, o modo
mais comum utilizado pelos usuários para distribuir suas chaves públicas é, de longe, colocálas em sua página Web pessoal. Evidentemente, as chaves que aparecem nessas páginas não
são certificadas por ninguém, mas são fáceis de acessar.
9.7
Comércio pela Internet
Na seção anterior, consideramos a utilização feita pela camada de aplicação (no e-mail
seguro) das várias tecnologias de segurança que estudamos anteriormente neste capítulo:
criptografia, autenticação, distribuição de chaves, integridade de mensagem e assinaturas digitais.
Nesta seção, continuaremos nossos estudos de caso dos vários mecanismos de segurança,
descendo uma camada na pilha de protocolos e abordando as portas seguras e a camada de
transporte segura. Usaremos o comércio pela Internet como aplicação motivadora, uma vez que
os negócios e as transações financeiras são importantes impulsionadores da segurança na Internet.
244
Chamamos de comércio pela Internet a compra de “bens” pela Internet. Nesse contexto,
consideramos o termo “bens” em um sentido muito amplo, que engloba desde livros, CDs,
hardwares, softwares e passagens aéreas até ações e títulos, serviços de consultoria e assim por
diante. Durante a década de 90, muitos sistemas foram projetados para o comércio pela Internet,
alguns oferecendo níveis mínimos de segurança e outros fornecendo altos níveis de segurança,
acompanhados do anonimato do cliente – semelhante ao anonimato oferecido pelas transações
comerciais pessoais comuns, feitas em dinheiro. No final da década de 90, no entanto, houve uma
grande mudança de cenário, pois apenas alguns desses sistemas foram amplamente
implementados em browsers e servidores. Dois sistemas se firmaram: a SSL, que é correntemente
usada na grande maioria das transações pela Internet, e a SET, a qual se acredita que concorrerá
com a SSL nos próximos anos.
O comércio pela Internet, seja com SSL ou com SET, faz uso extensivo da infra-estrutura
de cartões de pagamento (de crédito e de débito) que os consumidores, comerciantes e instituições
financeiras usam há muitos anos. Há três participantes importantes nessa infra-estrutura: o cliente
que está comprando um produto, o comerciante que está vendendo o produto e o banco comercial,
que autoriza a compra. Veremos, em nossa discussão a seguir, que o comércio pela Internet com
a SSL fornece segurança para as comunicações entre os dois primeiros participantes (isto é, entre
o cliente e o comerciante), ao passo que a SET oferece segurança para as comunicações entre os
três participantes.
9.7.1
Comércio pela Internet usando SSL
Vamos considerar um cenário típico de comércio pela Internet. Bob está navegando
pela Web e encontra o site Alice Incorporated, que vende bens duráveis. Esse site apresenta
um formulário no qual Bob deve informar a quantidade desejada, seu endereço e o número
do seu cartão de pagamento. Bob registra essas informações, clica em “apresentar” e, então,
aguarda o recebimento (digamos, pelo correio convencional) do bem adquirido; ele também
espera receber a cobrança da mercadoria na próxima fatura de seu cartão de crédito. Isso
tudo parece ser muito bom, mas, se não forem tomadas medidas de segurança – como
criptografia ou autenticação – Bob poderá ter algumas surpresas:

Um intruso pode interceptar a ordem de pagamento, obter as informações sobre o cartão
de crédito e, então, fazer compras na conta de Bob.

O site pode apresentar o famoso logotipo da Alice Incorporated, mas, na realidade, ser
mantido por Trudy, que está se fazendo passar pela Alice Incorporated. Trudy poderia
se apossar do dinheiro de Bob e fugir. Ou ela poderia fazer compras e enviar a fatura
para a conta de Bob.
Muitas outras surpresas também são possíveis; discutiremos algumas delas na próxima
subseção. Mas esses dois problemas apresentados são os mais sérios. O comércio pela
Internet usando SSL pode enfrentar ambos os problemas.
A SSL (secure sockets layer – camada de portas de segurança), originalmente
desenvolvida pela Netscape, é um protocolo projetado para fornecer criptografia de dados e
autenticação entre um cliente e um servidor Web. O protocolo começa com uma fase de
apresentação mútua que negocia um algoritmo de criptografia (por exemplo, DES ou Idea) e
chaves e autentica o servidor para o cliente. Opcionalmente, o cliente pode também ser
autenticado para o servidor. Uma vez completada a mútua apresentação e iniciada a
transmissão da aplicação de dados, todos os dados são criptografados usando as chaves de
sessão negociadas durante a fase de apresentação mútua. O protocolo SSL é amplamente
usado no comércio pela Internet, sendo implementado em quase todos os browsers populares
245
e servidores Web. Além disso, ele é a base do protocolo TLS (transport layer
security – segurança da camada de transporte).
Os protocolos SSL e TLS não são limitados à aplicação na Web; por exemplo, eles
podem ser usados de maneira semelhante para autenticação e criptografia de dados no acesso
ao correio IMAP. A camada SSL pode ser vista como uma camada que se situa entre a
camada de aplicação e a camada de transporte. No lado remetente, o protocolo SSL recebe
os dados (como uma mensagem HTTP ou IMAP vinda de uma aplicação), criptografa-os e
direciona os dados criptografados a uma porta TCP. No lado receptor, ele lê a porta TCP,
decifra os dados e os direciona à aplicação. Embora o protocolo SSL possa ser usado com
muitas aplicações da Internet, ele será discutido no contexto da Web, em que é utilizado
principalmente para o comércio pela Internet.
A SSL tem as seguintes características:

Autenticação do servidor SSL, que permite que um usuário confirme a identidade de um
servidor. Um browser habilitado para SSL mantém uma lista de CAs de confiança,
juntamente com as chaves públicas dessas CAs. Quando um browser quer fazer negócios
com um servidor Web habilitado para SSL, ele obtém um certificado do servidor contendo
a chave pública deste. O certificado é emitido (ou seja, é assinado digitalmente) pela CA
que aparece na lista de CAs de confiança do cliente. Essa característica permite que o
browser autentique o servidor antes de o usuário informar o número de seu cartão de
pagamento. No contexto do exemplo apresentado, essa autenticação do servidor permite
que Bob verifique se ele está realmente enviando o número de seu cartão de pagamento
à Alice Incorporated, e não a alguém que possa estar se fazendo passar pela Alice
Incorporated.

Autenticação do cliente SSL, que permite que um servidor confirme a identidade de um
usuário. Análoga à autenticação do servidor, a autenticação do cliente faz uso de
certificados dos clientes que também foram emitidos pelas CAs. Essa autenticação será
importante se o servidor, por exemplo, for um banco que está enviando informações
financeiras confidenciais para um cliente e quer verificar a identidade do receptor. A
autenticação do cliente, embora suportada pela SSL, é opcional. Para mantermos nossa
discussão em um único foco, vamos ignorar a autenticação do cliente daqui em diante.

Uma sessão SSL criptografada, na qual toda a informação enviada entre browser e
servidor é criptografada pelo software remetente (browser ou servidor Web). Essa
confidencialidade pode ser importante tanto para o cliente quanto para o comerciante. O
protocolo SSL também fornecerá um mecanismo que detecta a alteração de informação
por um intruso.
9.7.1.1
Como a SSL funciona
Um usuário – digamos, Bob – navega pela Web e pressiona um ponteiro que o
transporta a uma página segura abrigada pelo servidor habilitado à SSL de Alice. A
parte do URL que se refere ao protocolo para essa página é “HTTPS”, e não o “HTTP”
comum. O browser e o servidor então rodam o protocolo de mútua apresentação SSL
que (1) autentica o servidor e (2) gera uma chave simétrica compartilhada. Ambas as
tarefas fazem uso da tecnologia de chaves públicas RSA. O fluxo principal de eventos
na fase de mútua apresentação é mostrado na Figura 9.27. Durante essa fase, Alice envia
a Bob seu certificado, a partir do qual Bob obtém a chave pública de Alice. Bob então
cria uma chave simétrica aleatória, criptografa-a com a chave pública de Alice e a envia
criptografada para Alice. Agora, Bob e Alice compartilham uma chave de sessão
simétrica. Assim que esse protocolo de mútua apresentação se completa, todos os dados
246
enviados entre o browser e o servidor (pelas conexões TCP) são criptografados usando
a chave de sessão simétrica.
Figura 9.27 – Visão de alto nível da fase de mútua apresentação SSL.
Agora que apresentamos uma visão de alto nível da SSL, vamos examinar melhor
alguns dos detalhes mais importantes. A fase de mútua apresentação SSL percorre os
seguintes passos:
1. O browser envia ao servidor o número da versão da SSL que utiliza e as preferências
criptográficas. Ele envia essas preferências criptográficas porque browser e servidor
negociam qual algoritmo de chaves simétricas vão usar.
2. O servidor envia ao browser o número da versão da SSL que utiliza, suas
preferências criptográficas e seu certificado. Lembre-se de que o certificado contém
a chave pública RSA do servidor e é certificado por uma CA, isto é, o certificado é
criptografado por uma chave pública da CA.
3. O browser tem uma lista de CAs de confiança e uma chave pública para cada CA da
lista. Se não tiver, o usuário será avisado do problema e informado de que não pode
ser estabelecida uma conexão criptografada e autenticada. Se a CA estiver na lista,
o browser usará a chave pública da CA para decifrar o certificado e obter a chave
pública do servidor.
4. O browser gera uma sessão de chave simétrica, criptografa-a com a chave pública
do servidor e envia a chave de sessão criptografada ao servidor.
247
5. O browser envia uma mensagem ao servidor informando que as futuras mensagens
do cliente serão criptografadas com a chave de sessão. Ele então envia uma
mensagem separada (criptografada) mostrando que sua parte na mútua apresentação
está encerrada.
6. O servidor envia uma mensagem ao browser informando que as futuras mensagens
do servidor serão criptografadas com a chave de sessão. Ele então envia uma
mensagem separada (criptografada) mostrando que sua parte na mútua apresentação
está encerrada.
7. Agora, a mútua apresentação SSL está completa e começa a sessão SSL. O browser
e o servidor usam as chaves de sessão para codificar e decifrar os dados que enviam
um ao outro e para validar sua integridade.
A mútua apresentação SSL tem na verdade mais passos do que os apresentados.
Você pode encontrar mais informações sobre a SSL na Security Developer Central da
Netscape. Além das compras feitas com cartão de crédito, destacamos que a SSL pode
ser (e é) usada para outras transações financeiras, incluindo home banking e comércio
de ações.
9.7.1.2
A SSL em ação
Recomendamos que visite um site seguro, como por exemplo um site da cidade de
Quebec de xarope de bordo (http://www.jam.ca/syrup). Quando entrar na seção de
segurança de um site desse tipo, a SSL executará o protocolo de mútua apresentação.
Supondo-se que o certificado do servidor passe na verificação, o browser o notificará,
por exemplo, apresentando um ícone especial. Dali em diante, toda informação trocada
entre você e o servidor será criptografada. Seu browser deverá permitir que você
realmente veja o certificado do comerciante. (Por exemplo, com o Internet Explorer,
consulte Arquivo, Propriedades, Certificados.) Em fevereiro de 2000, o certificado do
site de xarope de bordo continha as seguintes informações:
Empresa: Netfarmers Enterprises Inc.
Autoridade Cerlificadora: Thawte Certification
Chave pública (em notação hexadecima/):
3E:BD:DD:46:10:D1:92:95:D6:12:ED:A8:18:88:51:60
Se seu browser permitir que se realizem transações seguras com o comerciante,
então você deverá também poder ver o certificado da CA, isto é, da Thawte Certification.
Por exemplo, no Internet Explorer, consulte Ferramentas, Opções da Internet, Conteúdo,
Certificados.
9.7.1.3
As limitações no comércio pela internet
Devido à sua simplicidade e a seu desenvolvimento precoce, a SSL é amplamente
implementada em browsers, servidores e produtos para comércio pela Internet. Esses
servidores e browsers habilitados à SSL fornecem uma plataforma popular para
transações com cartões de pagamento. No entanto, devemos ter sempre em mente que
a SSL não foi produzida especificamente para transações com cartões de pagamento,
mas para comunicações genéricas seguras entre um cliente e um servidor. Por causa de
seu projeto genérico, faltam à SSL muitas características que o setor de cartões de
pagamento gostaria de ver incorporadas a um protocolo de comércio pela Internet.
Considere novamente o que acontece quando Bob compra algo do site Alice
Incorporated por meio da SSL. O certificado assinado que Bob recebe de Alice garante
248
que ele está negociando com a Alice Incorporated e que a Alice Incorporated é uma
empresa bona fide. Contudo, o certificado genérico não indica se a Alice Incorporated
está autorizada a aceitar compras com cartão de pagamento nem se a empresa é um
estabelecimento comercial de confiança. Isso abre uma porta para a fraude do
comerciante. E há um problema semelhante com a autorização do cliente. Mesmo que
seja usada a autenticação do cliente SSL, o certificado do cliente não vincula Bob a um
determinado cartão de pagamento autorizado; assim, a Alice Incorporated não pode ter
certeza de que Bob está autorizado a fazer uma compra usando cartão de pagamento.
Isso abre a porta para todos os tipos de fraude, incluindo compras com cartões de crédito
roubados e recusa de bens comprados.
Evidentemente, esse tipo de fraude é crescente nas compras pelo correio ou pelo
telefone (mail order and telephone order – Moto). Nas transações desse tipo, a lei
estabelece que o comerciante se responsabilize por transações fraudulentas. Assim, se
um cliente fizer uma compra pelo correio ou telefone com um cartão de pagamento e
declarar que nunca fez a compra, o comerciante será responsável, ou seja, ele será
obrigado por lei a devolver o dinheiro ao cliente (a não ser que ele possa provar que o
cliente realmente pediu e recebeu a mercadoria). De maneira semelhante, se uma
compra pelo correio ou telefone for feita com um cartão de pagamento roubado, o
responsável será o comerciante. Por outro lado, nas transações feitas pessoalmente, o
banco do comerciante aceita a responsabilidade. Como era de esperar, é mais difícil um
cliente recusar uma compra que fez pessoalmente e que envolve uma assinatura por
escrito ou um número de identificação pessoal.
As compras SSL são semelhantes às compras pelo correio ou telefone, e
naturalmente o comerciante é responsável por uma compra SSL fraudulenta. Seria
preferível, é claro, usar um protocolo que fornecesse autenticação superior do cliente e
do comerciante, algo que fosse tão bom quanto uma transação realizada pessoalmente
ou até melhor. A autenticação que envolve a autorização de cartões de pagamento
reduziria a fraude e a responsabilidade do comerciante.
9.7.2
Comércio pela Internet usando SET
O protocolo de transações eletrônicas seguras (Secure Electronic Transactions – SET)
é um protocolo especificamente projetado para transações seguras com cartões de pagamento
pela Internet. Ele foi originalmente desenvolvido pela Visa International e MasterCard
International em fevereiro de 1996 com a participação de empresas de tecnologia expoentes
de todo o mundo. O protocolo SET LLC, comumente conhecido como SETCo, foi
estabelecido em dezembro de 1997 como uma entidade legal para administrar e promover a
adoção global do protocolo SET. Eis algumas das principais características do protocolo
SET:

O protocolo SET foi projetado para criptografar tipos específicos de mensagens
relacionadas com cartões de pagamento; ele não pode ser usado para criptografar dados
arbitrários (como textos e imagens), como acontece com o protocolo SSL.

O protocolo SET envolve os três participantes do ato de uma compra: o cliente, o
comerciante e o banco do comerciante. Todas as informações importantes trocadas entre
as três partes são criptografadas.

O protocolo SET requer que os três participantes tenham certificados. Os certificados
dos clientes e dos comerciantes são emitidos por seus bancos, assegurando, dessa
maneira, que esses participantes tenham permissão para fazer compras e receber por
vendas realizadas com cartões de pagamento. O certificado do cliente dá segurança ao
249
comerciante de que as cobranças das transações fraudulentas não recairão sobre sua
cabeça. Ele é uma representação eletrônica do cartão de pagamento do cliente e contém
informações sobre sua conta, a instituição financeira que o emitiu e outras informações
criptografadas. O certificado do comerciante assegura ao consumidor que aquele
comerciante está autorizado a aceitar compras feitas por cartões de pagamento. Ele
contém informações sobre o comerciante, o banco do comerciante e a instituição
financeira que emitiu o certificado.

O protocolo SET especifica o significado legal do certificado em poder de cada
participante e a atribuição de responsabilidades vinculadas à transação.

Em uma transação SET, o número do cartão de pagamento do cliente é passado ao banco
do comerciante sem que ele nunca veja esse número em texto aberto. Essa característica
evita que comerciantes fraudulentos ou descuidados roubem ou deixem vazar,
acidentalmente, o número do cartão.
Uma transação SET usa três componentes de software:

Carteira do browser: a aplicação de carteira do browser é integrada ao browser e fornece
ao cliente armazenagem e administração de cartões de pagamento e certificados durante
as compras. Ela responde a mensagens SET do comerciante, solicitando ao cliente que
escolha um cartão de pagamento para o pagamento da compra.

Servidor do comerciante: o servidor do comerciante é o mecanismo da comercialização
e do fechamento de pedidos de compra para os comerciantes que vendem pela Web. Para
pagamentos, ele processa as transações do portador do cartão e se comunica com o banco
do comerciante para aprovação e subsequente captura do pagamento.

Gateway do adquirente: o gateway do adquirente é o componente do software no banco
do comerciante. Ele processa a transação do cartão de pagamento do comerciante
referente à aprovação e ao pagamento.
Na descrição a seguir, apresentaremos uma visão bastante simplificada do protocolo
SET. Na realidade, esse protocolo é substancialmente mais complexo.
9.7.2.1
Estágios de uma compra
Suponha que Bob queira comprar uma mercadoria da Alice Incorporated pela
Internet, usando o protocolo SET.
1. Bob diz a Alice que está interessado em fazer uma compra com cartão de crédito.
2. Alice envia a Bob uma fatura e um identificador de transação exclusivo.
3. Alice envia a Bob o certificado do comerciante, que contém a chave pública do
comerciante. Ela envia também o certificado de seu banco, que contém a chave
pública do banco. Ambos os certificados são criptografados com a chave privada de
uma CA.
4. Bob usa a chave pública da CA para decifrar os dois certificados. Ele agora tem a
chave pública de Alice e a chave pública do banco.
5. Bob gera dois pacotes de informação: o pacote de informação de ordem (IO) e o
pacote de instruções de compra (IC). O pacote de IO, destinado a Alice, contém o
identificador da transação e a bandeira do cartão que está sendo usado; ele não inclui
o número do cartão de Bob. O pacote de IC, destinado ao banco de Alice, contém o
250
identificador da transação, o número do cartão e o valor da compra acertado com
Bob. Os pacotes de IO e IC são duplamente criptografados: o pacote de IO é
criptografado com a chave pública de Alice; o pacote de IC é criptografado com a
chave pública do banco de Alice. (Estamos distorcendo um pouco a realidade aqui
para entender melhor o quadro. Na realidade, os pacotes de IO e IC são
criptografados com uma chave de sessão cliente/comerciante e com uma chave de
sessão cliente/banco.) Bob envia os pacotes de IO e IC para Alice.
6. Alice gera um pedido de autorização para a solicitação do cartão de pagamento, o
qual contém o identificador da transação.
7. Alice envia a seu banco a mensagem criptografada com a chave pública do banco.
(Na realidade, é usada uma chave de sessão.) Essa mensagem contém o pedido de
autorização, o pacote de IC recebido de Bob e o certificado de Alice.
8. O banco de Alice recebe a mensagem e a decodifica. Ele verifica se houve alguma
falsificação e também se certifica de que o identificador da transação contido no
pedido de autorização combina com o existente no pacote de IC de Bob.
9. O banco de Alice então envia uma solicitação de autorização de pagamento ao cartão
de pagamento de Bob por meio dos canais bancários tradicionais para
cartões – exatamente como o banco de Alice solicitaria autorização para qualquer
transação normal de pagamento feita com cartão.
10. Uma vez que o banco de Bob autoriza o pagamento, o banco de Alice envia a ela
uma resposta, que é (obviamente) criptografada. A resposta contém o identificador
da transação.
11. Se a transação for aprovada, Alice enviará sua própria mensagem de resposta a Bob.
Essa mensagem servirá de recibo e informará a Bob que o pagamento foi aceito e
que a mercadoria será entregue.
Uma das características principais do protocolo SET é a não-exposição do número
do cartão de crédito ao comerciante. Essa característica é dada pelo estágio 5, no qual o
cliente criptografa o número do cartão de crédito com a chave do banco. Criptografar o
número com a chave do banco evita que o comerciante veja o cartão de crédito. Note
que há uma grande simetria entre os estágios de uma compra com o protocolo SET e os
estágios de uma transação normal com cartão de pagamento. Para processar todas as
tarefas do protocolo SET, o cliente terá uma carteira digital que roda o lado cliente do
protocolo SET e armazena as informações do cartão de pagamento do cliente (como por
exemplo: número do cartão e data de validade).
9.8
Segurança na camada de rede: o IPsec
O protocolo de segurança IP, mais conhecido como IPsec, é um conjunto de protocolos que
oferece segurança na camada de rede. O IPsec é um mecanismo bastante complexo; diferentes
partes desse conjunto de protocolos são descritas em mais de uma dúzia de RFCs. Nesta seção,
vamos discutir o IPsec em um contexto específico, ou seja, em um cenário em que todos os hosts
da Internet suportam o IPsec. Esse contexto, embora esteja ainda muito distante, simplificará a
discussão e ajudará a entender as características principais do IPsec. Dois RFCs-chave são o RFC
2401, que descreve a arquitetura geral da segurança IP, e o RFC 2411, que fornece uma visão do
conjunto de protocolos IPsec e apresenta os documentos que o descrevem.
Antes de examinarmos em detalhes o IPsec, vamos dar um passo atrás e considerar o que
significa oferecer segurança na camada de rede. Considere, de início, o que significa fornecer
251
sigilo na camada de rede. A camada de rede ofereceria sigilo se todos os dados transportados
pelos datagramas IP fossem criptografados. Isso significa que, sempre que um host quisesse
enviar um datagrama, ele criptografaria o campo de dados do datagrama antes de despachá-lo
para a rede. Em princípio, a criptografia poderia ser feita com chaves simétricas, chaves públicas
ou chaves de sessão que são negociadas com o uso de criptografia de chaves públicas. O campo
de dados poderia ser um segmento TCP, um segmento UDP, uma mensagem ICMP e assim por
diante. Se esse serviço de camada de rede existisse, todos os dados enviados pelos
hosts – incluindo e-mail, páginas Web, mensagens de controle e de administração (como ICMP e
SNMP) – ficariam ocultos de qualquer terceiro que estivesse “fazendo uma escuta eletrônica” na
rede. Assim, esse serviço forneceria uma “cobertura completa” para todo tráfego da Internet e
daria a todos nós, por conseguinte, uma certa sensação de segurança.
Além do sigilo, poderíamos querer que a camada de rede fornecesse autenticação da fonte.
Quando um host destinatário recebesse um datagrama IP com um endereço IP específico, ele
autenticaria a fonte certificando-se de que o datagrama IP, na verdade, tinha sido gerado pelo host
cujo endereço IP de fonte é aquele. Esse serviço evitaria que estelionatários falsificassem
endereços IP.
No conjunto IPsec, há dois protocolos principais: o protocolo de autenticação de cabeçalho
(Authentication Header – AH) e o protocolo de segurança de encapsulamento da carga útil
(Encapsulation Security Payload – ESP). Quando um host de origem envia um datagrama a um
host de destino, ele o faz com o protocolo AH ou com o protocolo ESP. O protocolo AH fornece
autenticação da fonte e integridade de dados, mas não oferece sigilo. O protocolo ESP fornece
integridade de dados, autenticação da fonte e sigilo. Como oferece mais serviços, esse protocolo
é naturalmente mais complicado e exige mais processamento do que o protocolo AH.
Discutiremos esses dois protocolos mais adiante.
Tanto para o protocolo AH quanto para o ESP, antes de enviar datagramas seguros de um
a outro, os hosts de origem e de destino fazem uma mútua apresentação e criam uma ligação lógica
de camada de rede. Esse canal lógico é chamado de acordo de segurança (Security
Agreement – AS). Assim, o IPsec transforma a tradicional camada de rede não orientada à
conexão em uma rede com conexões lógicas! A conexão lógica definida por um AS é uma
conexão simples, isto é, unidirecional. Se ambos os hosts quiserem enviar datagramas seguros
reciprocamente, então dois ASs (isto é, conexões lógicas) precisarão ser estabelecidos, um em
cada direção. Um AS é identificado, exclusivamente, pelos seguintes três elementos:

Um identificador de protocolo de segurança (AH ou ESP);

O endereço IP de fonte para a conexão simples, e

Um identificador de conexão de 32 bits chamado de Índice dos Parâmetros de Segurança
(Security Parameter Index – SPI).
Para um dado AS (isto é, uma dada conexão lógica de host de origem a host de destino),
cada datagrama IPsec terá um campo especial para o SPI. Todos os datagramas do AS usarão o
mesmo valor do SPI nesse campo.
9.8.1
AH (protocolo de autenticação de cabeçalho)
Como mencionamos anteriormente, o protocolo AH fornece identificação do host de
origem e integridade de dados, mas não sigilo. Quando um determinado host de origem quer
enviar um ou mais datagramas seguros a um destino particular, ele primeiramente estabelece
um AS com o destino. Após ter estabelecido o AS, ele pode enviar datagramas seguros ao
host de destino. Os datagramas seguros contêm o cabeçalho AH, que é inserido entre o
252
datagrama de dados IP original (por exemplo, um segmento TCP ou UDP) e o cabeçalho IP,
como mostra a Figura 9.28. Assim, o cabeçalho AH amplia o campo de dados original, e
esse campo ampliado é encapsulado como um datagrama IP padrão. Para o campo de
protocolo no cabeçalho IP, o valor 51 é usado para mostrar que o datagrama contém um
cabeçalho AH. Quando o host de destino recebe o datagrama IP, ele percebe o número 51
no campo de protocolo e processa o datagrama usando o protocolo AH. (Lembre-se de que
o campo de protocolo do datagrama IP é usado para determinar o protocolo da camada
acima – por exemplo, UDP, TCP ou ICMP – para a qual será passada a porção de dados de
um datagrama IP.) Roteadores intermediários processam os datagramas exatamente como
sempre o fazem – examinam o endereço de destino IP e roteiam os datagramas de acordo
com esse destino.
Figura 9.28 – Posição do cabeçalho AH no datagrama IP.
O cabeçalho AH contém diversos campos, tais como:

Campo do próximo cabeçalho, que desempenha o papel do campo de protocolo de um
datagrama comum. Ele indica se os dados que se seguem ao cabeçalho AH são um
segmento TCP, um segmento UDP, um segmento ICMP etc. (Lembre-se de que o campo
de protocolo do datagrama IP agora está sendo usado para indicar o protocolo AH e,
assim, não pode mais ser utilizado para identificar o protocolo da camada de transporte.)

Campo do SPI, um valor arbitrário de 32 bits que, combinado ao endereço de destino IP
e ao protocolo de segurança, identifica exclusivamente o AS para o datagrama.

Campo do número de sequência, um campo de 32 bits que contém um número de
seqüência para cada datagrama. Ele é inicialmente estabelecido em zero quando do
estabelecimento do AS. O protocolo AH usa os números de sequência para evitar os
ataques de reprodução e do homem do meio (veja a Seção 9.3).

Campo da autenticação de dados, um campo de comprimento variável que contém um
resumo de mensagem assinado (isto é, uma assinatura digital) para esse datagrama. O
resumo de mensagem é calculado sobre o datagrama IP original, fornecendo, desse
modo, autenticação do host de origem e integridade ao datagrama IP. A assinatura digital
é processada usando o algoritmo de autenticação especificado pelo AS, como o DES, o
MD5 ou o SHA.
Quando o host de destino recebe um datagrama IP com um cabeçalho AH, ele
determina o AS para o datagrama e, em seguida, autentica a integridade do datagrama
processando o campo da autenticação de dados. O esquema de autenticação do IPsec (tanto
para o protocolo AH como para o ESP) usa um sistema chamado HMAC, que é um resumo
de mensagem criptografado descrito no RFC 2104. O HMAC usa uma chave secreta
compartilhada pelas duas partes, em vez de métodos de chaves públicas para autenticação de
mensagens.
253
9.8.2
ESP (protocolo de segurança de encapsulamento da carga útil)
O protocolo ESP fornece sigilo na camada de rede, bem como autenticação do host de
origem. Novamente, tudo começa com um host de origem estabelecendo um AS com
um host de destino. Como mostra a Figura 9.29, um datagrama seguro é criado
envolvendo o datagrama IP original com campos de cabeçalho e de trailer e, em seguida,
inserindo esses dados encapsulados no campo de dados de um datagrama IP. No campo
de protocolo do cabeçalho do datagrama IP, o valor 50 é usado para mostrar que o
datagrama contém um cabeçalho e um trailer ESP. Quando o host de destino recebe um
datagrama IP, ele percebe o número 50 no campo de protocolo e processa o datagrama
usando o protocolo ESP. Como mostra a Figura 9.29, o datagrama IP original e o campo
de trailer ESP são criptografados. O sigilo é fornecido pela criptografia DES–CBC [RFC
2405]. O cabeçalho ESP consiste em um campo de 32 bits para o SPI e um campo de 32
bits para o número de sequência, os quais desempenham exatamente a mesma função
que exercem no protocolo AH. O trailer contém o campo do próximo cabeçalho, cuja
função é idêntica à função realizada no protocolo AH. Note que, como o campo do
próximo cabeçalho é criptografado juntamente com os dados originais, um intruso não
pode descobrir qual protocolo de transporte está sendo usado. Após o trailer, há um
campo da autenticação de dados, que também desempenha o mesmo papel que o campo
da autenticação de dados no protocolo AH.
Figura 9.29 – Campos ESP no datagrama IP.
9.8.3
O AS e a administração de chaves
Para a disponibilização bem-sucedida do IPsec, é necessário um acordo de segurança
(AS) e um esquema automatizado de gerenciamento de chaves, cuja escala possa ser
expandida. Diversos protocolos foram definidos para realizar essas tarefas, entre os quais:

O algoritmo de troca de chaves da Internet (Internet Key Exchange – IKE) [RFC 2409] é
o protocolo default de administração de chaves para o IPsec.

A associação de segurança na Internet e protocolo de administração de chave (Internet
Security Association and Key Management Protocol – ISKMP) define procedimentos
para estabelecer e encerrar ASs [RFC 2407; RFC 2408]. A ISKMP é completamente
independente da troca de chaves da IKE.
Isso encerra nosso resumo sobre o IPsec. Discutimos o IPsec no contexto do IPv4 e do
“modo de transporte”. O IPsec também determina um “modo de túnel”, no qual são os
roteadores – e não os host – que introduzem a funcionalidade de segurança. Por fim, ele
descreve os procedimentos de criptografia para o IPv6 e também para o IPv4.
254
Apêndice A
Série de Fourier
Em qualquer rede de comunicações entre computadores, desejamos que o sinal recebido por um
nó seja idêntico ao sinal transmitido pelo nó emissor. Infelizmente, esse cenário só pode ocorrer quando
o comprimento do canal de comunicação é bastante curto e a taxa de transmissão de dados relativamente
baixa. Isso é obviamente pouco prático na maioria das aplicações de redes. Como consequência,
quando o comprimento do cabo é longo ou as taxas de transmissão de dados alta, um sinal recebido não
é exatamente o mesmo que o sinal originalmente transmitido. Isso é conhecido como distorção de sinal.
A análise de Fourier é um método sistemático para prever distorções de sinal.
A análise de Fourier foi desenvolvida pelo matemático francês Jean Fourier, que provou que
qualquer onda periódica pode ser representada como a soma de uma agregação de senóides. Uma boa
aproximação requer um número finito de ondas, já uma representação perfeita requer um número
infinito de ondas. Usando a análise de Fourier, podemos prever como um sinal transmitido será
recebido. A análise de Fourier se fundamenta em duas observações. Primeiro, qualquer sinal usado em
sistemas de comunicação entre computadores pode ser escrito como uma soma de ondas senoidais.
Segundo, um sinal representado como uma onda senoidal é preservado (ou seja, não é distorcido)
quando é transmitido através de um meio, lembrando que o sinal ainda está sujeito a atrasos e
atenuações. Um resultado da análise de Fourier aplicada a redes de comunicações entre computadores
é que somente senóides têm a garantia de não serem distorcidas durante a transmissão. Uma segunda
implicação da análise de Fourier é que uma onda quadrada pode ser decomposta como uma soma de
senóides. De uma perspectiva matemática, isso é semelhante a aproximar funções contínuas usando
polinômios, denominados polinômios de Taylor. Isso também é similar à expansão em séries de Taylor
ou de MacLaurin para funções em que uma dada função é representada como uma série infinita.
Para usar a análise de Fourier visando prever qual será o sinal recebido, faz-se o seguinte:
1. Determine a atenuação do canal de comunicação e o desvio de fase em uso. Esses valores
são tipicamente fornecidos pelo fabricante.
2. Determine a função de decomposição, ou seja, a análise de Fourier correspondente.
3. Entre com o ganho e desvio de fase para a função decomposta e avalie. Com isso temos
uma função resposta, que representa a saída de um sinal de entrada após a transmissão
através de um canal de comunicação.
A análise de Fourier nos proporciona uma ferramenta para prever distorções de sinais, que nos
possibilita determinar o comprimento adequado para uma linha de transmissão, dadas a frequência e a
taxa de dados. Essa é uma das razões pelas quais as restrições de comprimento de cabo para a Ethernet
convencional (10 Mbps), Fast Ethernet (100 Mbps) e Gigabit Ethernet (1000 Mbps) são diferentes,
dependendo de qual taxa de dados está sendo usada e da frequência do cabo.
Resumindo, sempre que tivermos uma função periódica f (t ) de período T integrável neste
período, ela poderá ser decomposta em um somatório de infinitas ondas, que são os harmônicos de
Fourier, cujo resultado tenderá a função original f (t ) . Isto é, a cada novo harmônico somado estaremos
nos aproximando cada vez mais da onda original formada pela função f (t ) . Esta série de funções é
denominada Série de Fourier e é definida pela Equação A-1, onde para cada valor de n temos a geração
de um novo harmônico que é então adicionado aos anteriores.
255
f (t ) 


1
a 0   a n sen(2nft)   bn cos(2nft)
2
n 1
n 1
Equação A-1 – Forma Geral da Série de Fourier.
Onde:
T
2
a 0   f (t )dt
T 0
T
an 
2
f (t ) sen(2nft)dt
T 0
T
2
bn   f (t ) cos(2nft)dt
T 0
Equação A-2 – Coeficientes da Série de Fourier.
Se o sinal que queremos representar pela Série de Fourier não for periódico, poderemos simular
uma periodicidade considerando que o sinal em questão se repete no tempo, isto é, o sinal transmitido
possui um tempo de transmissão igual a T. O que faremos é supor que após este tempo T, ele será
repetido infinitas vezes. A partir deste ponto de vista, poderemos dizer que o sinal agora é periódico
com período igual a T, já que a cada T unidades de tempo o sinal se repete. Faremos esta consideração
devido ao fato da Série de Fourier considerar que o sinal é periódico. Do ponto de vista prático não
haverá qualquer alteração na nossa análise, pois iremos nos limitar a visualizar o sinal no intervalo de
tempo de 0 a T.
A primeira etapa para montar a Série de Fourier é calcular os coeficientes a 0 , a n e bn que são
baseados na função original f (t ) . A complexidade deste cálculo está diretamente relacionada com a
função f (t ) . No nosso caso, estaremos trabalhando com sinais digitais cujos valores só podem ser 0
ou 1. Desta forma, o cálculo dos Coeficientes de Fourier serão limitados a integração da função seno e
cosseno no caso de a n e bn respectivamente e apenas da função dt no caso do a 0 .
Devida a necessidade de se integrar função seno e cosseno, na Seção A.3 é feita uma breve
recordação de como integra-las, pois serão utilizadas nos exemplos a seguir.
Cada harmônico de Fourier terá uma determinada amplitude de média quadrática que pode ser
calculada através da Equação A-3. Estas amplitudes são importantes porque são proporcionais a energia
contida na onda. Como os meios de transmissão oferecem atenuações diferentes para cada harmônico,
é importante saber até qual harmônico a diferença de atenuação não é suficiente para distorcer o sinal a
ponto de não ser mais reconhecido. Se todos os harmônicos tivessem o mesmo nível de atenuação, o
sinal transmitido teria a sua amplitude reduzida, mas não seria distorcido. É em função desta variação
no nível de atenuação oferecido a cada harmônico que é feita a definição da largura de banda do meio.
A  a n2  bn2
Equação A-3 – Amplitude de Média Quadrática de cada Harmônico de Fourier.
256
A.1
Exemplo 1: Cálculo dos Coeficientes de Fourier de um Sinal NRZ
Vamos supor a transmissão de um conjunto de 8 bits (01100010) codificados no formato
NRZ. O sinal transmitido está ilustrado na Figura A-1.
Figura A-1 – Exemplo 1: Sinal NRZ.
A função f (t ) abaixo representa o sinal NRZ da Figura acima.
T

0 se 0  t  8

1 se T  t  3T

8
8

3T
6T

f (t )  0 se
t 
8
8

6T
7T

1 se 8  t  8

0 se 7T  t  8T

8
8

Equação A-4 – Função Representante do Sinal NRZ.
A.1.1 Cálculo do a 0
T
2
a 0   f (t )dt
T 0
3T
6T
7T
8T
 T8

8
8
8
8


2
a0    0  dt   1  dt   0  dt   1  dt   0  dt 
T 0
T
3T
6T
7T

8
8
8
8


7T
 3T

8

2 8
a 0    dt   dt 
TT
6T

8
8

a0 
7T 8
2  3T 8

t
t

6T 8 
T T8
257
a0 
2  3T T   7T 8T 
 



T  8 8   8
8 
a0 
2  2T T 
 

T 8
8
a0 
2 3T

T 8
a0 
3
4
Equação A-5 – Coeficiente a0 do Sinal NRZ.
A.1.2 Cálculo do a n
T
an 
2
T 0
3T
6T
7T
8T
T

8
8
8
8
2 8

a n    0  sen(2nft)dt   1  sen(2nft)dt   0  sen(2nft)dt   1  sen(2nft)dt   0  sen(2nft)dt 
T 0
T
3T
6T
7T


8
8
8
8


3T
7T


8
28

a n    sen(2nft)dt   sen(2nft)dt 
T T
6T


8
8

Considerando k  2fn temos:
7T
 38T

8
2

a n    sen(kt)dt   sen(kt)dt 
T T
6T


8
8

an 
2
Tk
3T 8
7T 8

 


cos(kt )  cos(kt )  
T 8 
6T 8  


an 
2
Tk

 3kT 
 kT  
 7kT 
 6kT  
  cos    cos
  cos
 
 cos
 8 
 8  
 8 
 8  

Substituindo o valor de k e considerando que f 
an 
2T
2nT
1
temos:
T

 3  2nT 
 2nT 
 7  2nT 
 6  2nT 
  cos

 cos 8T   cos 8T   cos 8T






 8T


258
Simplificando os termos semelhantes e mudando a ordem dos cossenos ficamos com:
an 
1   n 
 3n 
 6n 
 7n 
cos   cos
  cos
  cos


n   4 
 4 
 4 
 4 
Equação A-6 – Coeficiente an do Sinal NRZ.
A.1.3 Cálculo do bn
T
2
bn   f (t ) cos(2nft)dt
T 0
3T
6T
7T
8T
 T8

8
8
8
8
2

bn    0  cos(2nft)dt   1 cos(2nft)dt   0  cos(2nft)dt   1 cos(2nft)dt   0  cos(2nft)dt 
T 0
T
3T
6T
7T


8
8
8
8
7T
 38T

8
2

bn    cos(2nft)dt   cos(2nft)dt 
T T
6T


8
8

7T
 38T

8
2

bn    cos(kt)dt   cos(kt)dt 
T T
6T


8
8

bn 
2
Tk
3T 8
7T 8

 


sen
(
kt
)
sen
(
kt
)




T 8 
6T 8 



bn 
2
Tk
  3kT 
 kT 
 7kT 
 6kT 
 sen 8   sen 8   sen 8   sen 8 

 




 
bn 
2T
2nT
1
temos:
T
  3  2nT 
 2nT 
 7  2nT 
 6  2nT 
  sen

 sen 8T   sen 8T   sen 8T





 8T

 
Simplificando os termos semelhantes e mudando a ordem dos senos ficamos com:
bn 
1 
 n 
 3n 
 6n 
 7n 
 sen   sen
  sen
  sen


n 
 4 
 4 
 4 
 4 
Equação A-7 – Coeficiente bn do Sinal NRZ.
259
A Série de Fourier completa da função f (t ) é:
f (t ) 
1 3   sen(2nft)   n 
 3n 
 6n 
 7n  
  
  cos
  cos
  

2 4 n 1 
n
 4 
 4 
 4  
  4 
 cos(2nf ) 
 n 
 3n 
 6n 
 7n  
  sen
  sen
 

n
 4
 4 
 4 
 4  
n 1 



3   sen(2nft)   n 
 3n 
 6n 
 7n  
f (t )    
  cos
  cos
  

8 n 1 
n
 4 
 4 
 4  
  4 
 cos(2nf ) 
 n 
 3n 
 6n 
 7n  
  sen
  sen
 

n
 4 
 4 
 4 
 4  
n 1 



Equação A-8 – Série de Fourier Completa para o Sinal NRZ.
A.1.4 Gráficos do Exemplo 1
A seguir serão apresentados os gráficos referentes à Série de Fourier calculada nos itens
anteriores considerando um período de 8 unidades de tempo, isto é, T  8 u.t. logo a
1
freqüência será de f  u.f. (unidade de freqüência). Foram feitos gráficos considerando
8
até 10 harmônicos, isto é, de n  1 até n  10 .
A Figura A-2 mostra o formato do Sinal Original puro. A princípio, este é o sinal que
desejamos transmitir, porém, os meios de transmissão irão transmitir apenas os seus
harmônicos. A Figura A-3 mostra os 10 primeiros harmônicos referentes ao sinal original.
Conforme foi comentado na definição da Série de Fourier, conforme vão se somando
os seus harmônicos, mais próximo chegaremos a função original. Neste nosso exemplo, nos
limitamos a um total de 10 harmônicos.
A Figura A-4 mostra o primeiro harmônico sendo comparado ao sinal original. Notase que este único harmônico está muito distante de representar o sinal original. A Figura A-5
mostra a soma dos dois primeiros harmônicos. Houve uma considerável mudança, estando
agora mais próximo do sinal original que no caso de apenas um único harmônico. Na
Figura A-6 é feita a soma dos 3 primeiros harmônicos. Apesar da mudança ter sido pequena,
ela mudou o sinal aproximando-o do sinal original. Na Figura A-7 temos a soma dos 4
primeiros harmônicos. Neste gráfico já temos o intervalo de 3 u.t. a 6 u.t. mais bem definido
do que tínhamos nas figuras anteriores. Ao acrescentar o quinto harmônico, não houve
mudanças significativas, como mostra a Figura A-8. Ao acrescentarmos o sexto harmônico,
já é possível identificar o sinal original a partir deste somatório de harmônicos, como mostra
a Figura A-9. Com o acréscimo do sétimo, oitavo, nono e décimo harmônico, teremos um
refinamento melhor do sinal como podem ser vistos na Figura A-10 até a Figura A-13
respectivamente. Porém, como cada novo harmônico aumenta a largura de banda, se torna
um desperdício adicionar mais harmônicos do que o necessário para que o equipamento de
destino reconheça o sinal emitido.
A Figura A-14 mostra as amplitudes de média quadrática de cada um dos 10
harmônicos exemplificados aqui. O oitavo harmônico possui uma amplitude tão pequena em
relação aos demais que sua representação nem chegou a ser apresentada.
260
Sinal Original
1,2
Amplitude
1
0,8
Sinal Original
0,6
0,4
0,2
0
0
1
2
3
4
5
6
7
8
Tempo
Figura A-2 – Sinal Original.
Harmônicos de Fourier
1
n=1
0,8
n=2
n=3
Amplitude
0,6
n=4
n=5
0,4
n=6
n=7
0,2
n=8
n=9
0
n=10
-0,2
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
5
5,5
6
Tempo
Figura A-3 – 10 Harmônicos de Fourier.
261
6,5
7
7,5
8
Primeiro Harmônico
1,2
Amplitude
1
0,8
1 Harmônico
0,6
Dados Originais
0,4
0,2
0
0
1
2
3
4
5
6
7
8
Tempo
Figura A-4 – Primeiro Harmônico de Fourier.
Somatório dos 2 primeiros harmônicos
1,2
1
Amplitude
0,8
0,6
2 Harmônicos
0,4
Dados Originais
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
Figura A-5 – Somatório dos 2 primeiros Harmônico de Fourier.
262
Somatório dos 3 primeiros Harmônicos
1,4
1,2
Amplitude
1
0,8
0,6
3 Harmônicos
0,4
Dados Originais
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
1,4
1,2
1
Amplitude
0,8
0,6
4 Harmônicos
0,4
Dados Originais
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
263
1,2
1
Amplitude
0,8
0,6
5 Harmônicos
0,4
Dados Originais
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
1,4
1,2
Amplitude
1
0,8
6 Harmônicos
0,6
Dados Originais
0,4
0,2
0
-0,2
0
1
2
3
4
5
6
7
8
Tempo
264
1,4
1,2
Amplitude
1
0,8
7 Harmônicos
0,6
Dados Originais
0,4
0,2
0
-0,2
0
1
2
3
4
5
6
7
8
Tempo
1,4
1,2
Amplitude
1
0,8
8 Harmônicos
0,6
Dados Originais
0,4
0,2
0
-0,2
0
1
2
3
4
5
6
7
8
Tempo
265
1,4
1,2
Amplitude
1
0,8
9 Harmônicos
0,6
Dados Originais
0,4
0,2
0
-0,2
0
1
2
3
4
5
6
7
8
Tempo
1,2
1
Amplitude
0,8
0,6
10 Harmônicos
0,4
Dados Originais
0,2
0
-0,2
0
1
2
3
4
5
6
7
8
Tempo
266
Amplitude de Média Quadrática dos Harmônicos
0,6
0,50383
0,5
Amplitude
0,4
Amplitude
0,3
0,24336
0,19544
0,2
0,16757
0,15924
0,11840
0,10099
0,1
0,03522
0,02670
0,00038
0
1
2
3
4
5
6
7
8
9
10
Harmônicos
Figura A-14 – Amplitude de Média Quadrática de cada Harmônico de Fourier.
267
A.2
Exemplo 2: Cálculo dos Coeficientes de Fourier de um Sinal Manchester
Vamos supor a transmissão do mesmo conjunto de 8 bits (01100010) codificados no
formato Manchester. O sinal transmitido está ilustrado na Figura A-15.
Figura A-15 – Exemplo 2: Sinal Manchester.
A função f (t ) abaixo representa o sinal NRZ da Figura acima.
T

1 se 0  t  16

0 se T  t  3T

16
16

1 se 3T  t  4T

16
16

4T
5T
0 se
t
16
16


5T
7T
t
1 se
16
16

7T
8T

0 se
t


16
16
f (t )  
1 se 8T  t  9T

16
16

9T
10T
0 se
t
16
16


10T
11T
t
1 se
16
16


11T
13T
t
0 se
16
16

1 se 13T  t  15T

16
16

0 se 15T  t  16T

16
16

Equação A-9 – Função Representante do Sinal Manchester.
268
A.2.1 Cálculo do a 0
T
a0 
2
f (t )dt
T 0
4T
7T
9T
11T
15T
 16T

8
16
16
16
16

2
a 0    1  dt   1  dt   1  dt   1  dt   1  dt   1  dt 
T0
3T
5T
8T
10T
13T

16
16
16
16
16


a0 
4T 16
7T 16
9T 16
11T 16
15T 16
2  T 16

t
t
t
t
t
t

3T 16
5T 16
8T 16
10T 16
13T 16 
T 0
a0 
2  T
  4T 3T   7T 5T   9T 8T   11T 10T   15T 13T 





  0  






T  16
16   16
16 
  16 16   16 16   16 16   16
a0 
2  T T 2T T T 2T 
  
  

T  16 16 16 16 16 16 
a0 
2 8T

T 16
a0  1
Equação A-10 – Coeficiente a0 do Sinal Manchester.
A.2.2 Cálculo do a n
T
an 
2
T 0
4T
7T
16T

16
16


  1  sen(2nft)dt   1  sen(2nft)dt   1  sen(2nft)dt  
3T
5T
0

2
16
16

a n   9T
11T
15T
T

16
16
16


  1  sen(2nft)dt   1  sen(2nft)dt   1  sen(2nft)dt 
10T
13T
 816T

16
16
269
4T
7T
16T

16
16


  1  sen(kt)dt   1  sen(kt)dt   1  sen(kt)dt  
3T
5T
0

2
16
16

a n   9T
11T
15T
T

16
16
16


  1  sen(kt)dt   1  sen(kt)dt   1  sen(kt)dt 
10T
13T
 816T

16
16
T 16
4T 16
7T 16


 
 



 

cos(
kt
)

cos(
kt
)

cos(
kt
)







0 
3T 16 
5T 16 
2 



an 


9
T
16
11
T
16
15
T
16
Tk  
 
 

 cos(kt )
 cos(kt )
 cos(kt )
 
8T 16 
10T 16 
13T 16 
 
 
 


 
 kT 
 4kT 
 3kT  
 7 kT 
 5kT 
  cos
   cos
  cos
 
 cos   cos0    cos

 16 
 16 
 16  
 16 
 16 
2 
 

an 


Tk  
 9kT 
 8kT  
 11kT 
 10kT  
 15kT 
 13kT  
  cos
  cos
   cos
  cos
   cos
  cos

 
 16 
 16  
 16 
 16  
 16 
 16  

1
temos:
T

 2nT 
 4  2nT 
 3  2nT 
 7  2nT  
 cos 16T   1  cos 16T   cos 16T   cos 16T   







 

2T 
 5  2nT 
 9  2nT 
 8  2nT 
 11 2nT  
an 
  cos
  cos
  cos
 
 cos
2nT 
 16T 
 16T 
 16T 
 16T  


 10  2nT 
 15  2nT 
 13  2nT 
  cos
  cos

 cos

 16T 
 16T 
 16T 


Simplificando os termos semelhantes e mudando a ordem dos cossenos ficamos com:

 n 
 3n 
 4n 
 5n 
 7n 
 8n  
1  cos 8   cos 8   cos 8   cos 8   cos 8   cos 8  
1 
 









 
an 

n   9n 
 10n 
 11n 
 13n 
 15n 
  cos
  cos
  cos
  cos

cos

 8 
 8 
 8 
 8 
  8 

Equação A-11 – Coeficiente an do Sinal Manchester.
270
A.2.3 Cálculo do bn
T
bn 
2
f (t ) cos(2nft)dt
T 0
4T
7T
16T

16
16


  1  cos(2nft)dt   1  cos(2nft)dt   1  cos(2nft)dt  
3T
5T
0

2
16
16

bn   9T
11T
15T
T

16
16
16


  1  cos(2nft)dt   1  cos(2nft)dt   1  cos(2nft)dt 
10T
13T
 816T

16
16
4T
7T
16T

16
16


  1  cos(kt)dt   1  cos(kt)dt   1  cos(kt)dt  
3T
5T
0

2
16
16

bn   9T
11T
15T
T

16
16
16


  1  cos(kt)dt   1  cos(kt)dt   1  cos(kt)dt 
10T
13T
 816T

16
16
T 16
4T 16
7T 16


 
 



 
sen
(
kt
)
sen
(
kt
)
sen
(
kt
)







0 
3T 16 
5T 16 
2 



bn 


9
T
16
11
T
16
15
T
16
Tk  
 
 

 sen(kt )
 sen(kt )
 sen(kt )
 
8T 16 
10T 16 
13T 16 
 
 
 
  kT 

   4kT 
 3kT    7kT 
 5kT 
  sen
   sen
  sen
 
 sen   sen0   sen

 16    16 
 16 
2   16 
   16 

bn 


Tk    9kT 
 8kT    11kT 
 10kT    15kT 
 13kT  
 sen
 sen
   sen
  sen
   sen
  sen

   16 
16
16
16
16








 16  





1
temos:
T
  2nT 
 4  2nT 
 3  2nT 
 7  2nT  
 sen 16T   0  sen 16T   sen 16T   sen 16T   






 
 
2T   5  2nT 
 9  2nT 
 8  2nT 
 11 2nT  
bn 
  sen
  sen
  sen
 
 sen
2nT   16T 
 16T 
 16T 
 16T  
  10  2nT 

 15  2nT 
 13  2nT 
  sen
  sen

 sen

 16T 
 16T 
  16T 

271
Simplificando os termos semelhantes e mudando a ordem dos senos ficamos com:
  n 
 3n 
 4n 
 5n 
 7n 
 8n  
 sen 8   sen 8   sen 8   sen 8   sen 8   sen 8   
1   









 
bn 

n 
 9n 
 10n 
 11n 
 13n 
 15n 
  sen
  sen
  sen
  sen

 sen

 8 
 8 
 8 
 8 
 8 


Equação A-12 – Coeficiente bn do Sinal Manchester.
A Série de Fourier completa da função f (t ) é:


 n 
 3n 
 4n 
 5n   

1  cos 8   cos 8   cos 8   cos 8   
 





 


 
1
 sen(2nft)   7n 
 8n 
 9n 
 10n   
f (t )   1   
  cos
  cos
  cos
   
cos
2
n
8
8
8
8







 
n 1 


  11n 

 13n 
 15n 
  cos
  cos


cos


 8 
 8 
  8 
 

  n 
 3n 
 4n 
 5n 
 7n 
 8n   

 sen 8   sen 8   sen 8   sen 8   sen 8   sen 8    
 cos(2nf )   









 





n
 9n 
 10n 
 11n 
 13n 
 15n 
n 1 
  sen
  sen
  sen
  sen

 sen


 8 
 8 
 8 
 8 
 8 





 n 
 3n 
 4n 
 5n   

1  cos 8   cos 8   cos 8   cos 8    
 





 


 
1
 sen(2nft)   7n 
 8n 
 9n 
 10n   
f (t )    
  cos
  cos
  cos
   
cos
2 n 1 
n
8
8
8
8







 


  11n 

 13n 
 15n 
  cos
  cos


cos


 8 
 8 
  8 
 

  n 
 3n 
 4n 
 5n 
 7n 
 8n   
sen

sen

sen

sen

sen

sen











 



 cos(2nf )   8 
 8 
 8 
 8 
 8 
 8  





n
 9n 
 10n 
 11n 
 13n 
 15n 
n 1 
  sen
  sen
  sen
  sen

 sen


 8 
 8 
 8 
 8 
 8 


Equação A-13 – Série de Fourier Completa para o Sinal Manchester.
A.2.4 Gráficos do Exemplo 2
A seguir serão apresentados os gráficos referentes à Série de Fourier calculada nos itens
anteriores considerando um período de 8 unidades de tempo, isto é, T  8 u.t. logo a
1
freqüência será de f  u.f. (unidade de freqüência). Foram feitos gráficos considerando
8
até 13 harmônicos, isto é, de n  1 até n  13 .
A análise a ser feita é a mesma utilizada no Exemplo 1 na Seção A.1.4. O mais
importante a ser observado é que no Exemplo 1, bastavam seis harmônicos para o sinal ser
272
reconhecido. Neste novo exemplo, onde estamos utilizando a codificação Manchester, seis
harmônicos não são mais suficientes para identificar o sinal. Neste caso precisamos de no
mínimo 11 harmônicos, mas dependendo da distância e das condições do meio de transmissão
provavelmente será necessário o uso de mais harmônico. Foram feitas as representações da
Série de Fourier até o 13º harmônico para mostrar como ele foi ficando mais semelhante ao
sinal original.
A Figura A-31 mostra as amplitudes de média quadrática de cada um dos 13
harmônicos exemplificados aqui.
Sinal Original
1,2
1
Amplitude
0,8
0,6
Sinal Original
0,4
0,2
0
0
1
2
3
4
5
6
7
8
Tempo
Figura A-16 – Sinal Original.
Harmônicos de Fourier
1
n=1
0,9
Amplitude
n=2
0,8
n=3
0,7
n=4
n=5
0,6
n=6
n=7
0,5
n=8
0,4
n=9
0,3
n=10
0,2
n=11
n=12
0,1
n=13
0
0
0,5
1
1,5
2
2,5
3
3,5
4
4,5
5
5,5
6
Tempo
Figura A-17 – 13 Harmônicos de Fourier.
273
6,5
7
7,5
8
Primeiro Harmônico
1,2
1
Amplitude
0,8
1 Harmônico
Dados Originais
0,6
0,4
0,2
0
0
1
2
3
4
5
6
7
8
Tempo
Figura A-18 – Primeiro Harmônico de Fourier.
1,2
1
Amplitude
0,8
2 Harmônicos
Dados Originais
0,6
0,4
0,2
0
0
1
2
3
4
5
6
7
8
Tempo
274
1,2
1
Amplitude
0,8
3 Harmônicos
Dados Originais
0,6
0,4
0,2
0
0
1
2
3
4
5
6
7
8
Tempo
1,2
1
Amplitude
0,8
4 Harmônicos
0,6
Dados Originais
0,4
0,2
0
0
1
2
3
4
5
6
7
8
Tempo
275
1,2
1
Amplitude
0,8
0,6
5 Harmônicos
Dados Originais
0,4
0,2
0
-0,2
0
1
2
3
4
5
6
7
8
Tempo
1,6
1,4
1,2
Amplitude
1
0,8
6 Harmônicos
Dados Originais
0,6
0,4
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
276
1,6
1,4
1,2
Amplitude
1
0,8
7 Harmônicos
Dados Originais
0,6
0,4
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
1,6
1,4
1,2
Amplitude
1
0,8
8 Harmônicos
Dados Originais
0,6
0,4
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
277
1,4
1,2
1
Amplitude
0,8
0,6
9 Harmônicos
Dados Originais
0,4
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
1,4
1,2
1
Amplitude
0,8
0,6
10 Harmônicos
Dados Originais
0,4
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
278
1,4
1,2
1
Amplitude
0,8
0,6
11 Harmônicos
Dados Originais
0,4
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
1,4
1,2
1
Amplitude
0,8
0,6
12 Harmônicos
Dados Originais
0,4
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
279
1,4
1,2
1
Amplitude
0,8
0,6
13 Harmônicos
Dados Originais
0,4
0,2
0
-0,2
-0,4
0
1
2
3
4
5
6
7
8
Tempo
Amplitude de Média Quadrática dos Harmônicos
0,45
0,40486
0,4
0,35
Amplitude
0,3
0,24349
0,25
0,20822
Amplitude
0,2
0,17752
0,15962
0,15
0,17588
0,15923
0,13533
0,13000
0,1
0,07867
0,05272
0,03131
0,04889
0,05
0
1
2
3
4
5
6
7
8
9
10
11
12
13
Harmônicos
Figura A-31 – Amplitude de Média Quadrática de cada Harmônico de Fourier.
280
A.3
Como Integrar Funções Seno e Cosseno
Recordando conceitos importantes:
 cos(u)du  sen(u)
 sen(u)du   cos(u)
Se tivermos que calcular
 cos(kx)dx ,
devemos realizar uma mudança de variável,
como segue abaixo:
Se tivermos que calcular
 sen(kx)dx ,
devemos realizar uma mudança de variável,
como segue abaixo:
 sen(kx)dx
 cos(kx)dx
u  kx
du  kdx
du
dx 
k
Realizando as substituições temos:
sen(u )du
 sen(kx)dx   k
1
1
sen(u )du   cos(u )

k
k
Logo,
1
 sen(kx)dx  k  cos(kx)
u  kx
du  kdx
du
dx 
k
Realizando as substituições temos:
cos(u )du
 cos(kx)dx   k
1
1
cos(u )du  sen(u )

k
k
Logo,
1
 cos(kx)dx  k sen(kx)
281
Apêndice B
Cálculo relacionado à Órbita de Satélites
Para que um satélite fique em órbita, é necessário satisfazer uma simples relação física. Como a
órbita do satélite é circular, deve-se garantir que a soma das forças resultantes seja igual a força


centrípeta isto é: Fresultante  Fcentrípeta . A Figura B-1 mostra o esquema da órbita de um satélite.
Figura B-1 – Órbita de um Satélite.
A única força que está atuando no satélite é a força gravitacional fazendo com que esta também
G  M terra  M satélite
seja a força resultante. Ela é representada pela seguinte relação: Fgravitacional 
, onde
2
Rsatélite
G é a constante gravitacional universal, M terra é a massa da terra, M satélite é a massa do satélite e Rsatélite
é a distância do satélite até o centro da terra, isto é, o raio da órbita do satélite.
M  v2
considerando a velocidade
R
linear (v) ou Fcentrípeta  M   2  R considerando a velocidade angular ().


Considerando a relação inicial em que Fresultante  Fcentrípeta temos:
A força centrípeta é dada pela seguinte relação: Fcentrípeta 
M satélite   2  Rsatélite 
2 
G  M terra  M satélite
2
Rsatélite
G  M terra
3
Rsatélite
282

G  M terra
3
Rsatélite
Equação B-1 – Velocidade Angular do Satélite.
3
Rsatélite

G  M terra
2
Rsatélite  3
G  M terra
2
Equação B-2 – Raio do Satélite.
A velocidade linear (v) pode ser calculada pela seguinte relação: v    R
Sendo assim, podemos calcular a velocidade linear a partir da Equação B-1 como mostra abaixo:
vsatélite  Rsatélite 
vsatélite 
G  M terra
3
Rsatélite
2
G  M terra  Rsatélite
3
Rsatélite
vsatélite 
G  M terra
Rsatélite
Equação B-3 – Velocidade Linear do Satélite.
Para calcular a altura (h) do satélite utilizamos a seguinte relação:
h  Rsatélite  Rterra
Equação B-4 – Altura do Satélite em Relação à Superfície da Terra.
Ao analisar tanto a Equação B-1 como Equação B-3, verificamos que quanto maior for o raio do
satélite ( Rsatélite ), e com isso a sua altitude (h), a sua velocidade (v e ) vão diminuindo para que
mantenha a respectiva órbita.
Se considerarmos órbitas geoestacionárias, a velocidade angular do satélite (  satélite ) deverá ser
igual à velocidade angular da Terra ( terra ). Sendo assim teremos:
satélite   terra
Equação B-5 – Condição Necessária para Órbitas Geoestacionárias.
Calculando a velocidade angular da Terra ( terra ):
 terra 
2
Radianos Hora
24
283
 terra 
 terra 

12
Radianos Hora

12 3.600
Radianos Segundo
 terra 

43.200
Radianos Segundo
Equação B-6 – Velocidade Angular da Terra.
Logo, a velocidade angular do satélite (  satélite ) deverá ser:
 satélite 

43.200
Radianos Segundo
Equação B-7 – Velocidade Angular do Satélite para Órbitas Geoestacionárias.
Sabendo-se que a Massa da Terra, o Raio da Terra e a Constante Gravitacional Universal valem:
M terra  5,97 1024 Kg
Equação B-8 – Massa da Terra.
Rterra  6.376,5 Km
Equação B-9 – Raio da Terra.
G  6,6742 1011 Newton  Metro2 Kg 2
Equação B-10 – Constante Gravitacional Universal (G).
Ao substituir esses valores na Equação B-2 e convertendo o resultado de metros para quilômetros
teremos o Raio do Satélite sendo igual a:
Rsatélite  42.235,77 Km
Logo a sua altura em relação à superfície da terra (h) será dada pela Equação B-4:
h  35.859,27 Km
Equação B-11 – Altura do Satélite para uma Órbita Geoestacionária.
284
Apêndice C
Técnicas de Criptografia
C.1
DES (padrão para criptografia de dados)
Vamos agora avançar rapidamente até os tempos modernos e examinar o DES (Data
Encryption Standard – padrão para criptografia de dados), um padrão de criptografia de chaves
simétricas desenvolvido em 1977 e atualizado mais recentemente em 1993 pelo V.S. National
Bureau of Standards para uso comercial e não confidencial do governo norte-americano. O DES
codifica o texto aberto em porções de 64 bits usando uma chave de 64 bits. Na verdade, oito
desses 64 bits da chave são bits de paridade ímpar (há um bit de paridade para cada um dos 8 bits),
de modo que a chave DES tem efetivamente 56 bits de comprimento. O National Institute of
Standards (sucessor do National Bureau of Standards) assim estabelece o objetivo do DES: “O
objetivo é embaralhar completamente os dados e a chave, de modo que todos os bits do texto
cifrado dependam de todos os bits de dados e de todos os bits da chave (...) com um bom algoritmo,
não deverá haver nenhuma correlação entre o texto cifrado e os dados originais e a chave”.
A operação básica do DES é ilustrada na Figura C-1. Em nossa discussão, vamos apenas
descrever de maneira geral a operação do DES, deixando os detalhes fundamentais referentes aos
bits (há muitos) para outras fontes. O DES consiste em dois estágios de permutação (o primeiro
e o último passo do algoritmo), nos quais todos os 64 bits são permutados, havendo 16 “rodadas”
idênticas de operação entre eles. A operação de cada rodada é idêntica e toma a saída de dados
da rodada anterior como entrada. Durante cada rodada, os 32 bits da extrema direita da entrada
são deslocados para os 32 bits da esquerda da saída. Toda a entrada de 64 bits até a i-ésima rodada
e a chave de 48 bits para a i-ésima rodada (derivada da chave DES maior de 56 bits) são tomadas
como entrada para uma função que envolve a expansão das porções de 4 bits da entrada para
porções de 6 bits, fazendo-se o OU exclusivo com as porções expandidas de 6 bits da chave Ki de
48 bits, uma operação de substituição, e o ulterior OU excludente com os 32 bits da extrema
esquerda da entrada. A saída de 32 bits resultante da função é então usada como os 32 bits da
extrema direita da saída de 64 bits da rodada, como mostra a Figura C-1. A decriptografia
funciona pela reversão das operações dos algoritmos.
Até que ponto o DES funciona? Até que ponto ele é seguro? Ninguém pode ter certeza.
Em 1997, uma empresa de segurança em rede, a RSA Data Security Inc., lançou um desafio (DES
Challenge) para “quebrar” (decodificar) uma frase curta que tinha sido criptografada usando o
DES de 56 bits. A frase “Strong cryptography makes the world a safer place.” (a boa criptografia
faz do mundo um lugar mais seguro) foi decodificada em menos de quatro meses por uma equipe
que usou voluntários por toda a Internet para explorar sistematicamente o espaço de chaves. A
equipe reivindicou o prêmio de dez mil dólares após ter testado apenas um quarto do espaço de
chaves – cerca de 18 quatrilhões de chaves. O mais recente desafio, o DES Challenge III que
aconteceu em 1999, foi vencido no tempo recorde de pouco mais de 22 horas por uma rede de
voluntários e um computador especialmente construído para a ocasião, que custou menos de 250
mil dólares (apelidado de “Deep Crack”) e está documentado na Internet.
285
Figura C-1 – Operação básica do DES.
Se o DES de 56 bits for considerado muito inseguro, pode-se simplesmente rodar o
algoritmo de 56 bits múltiplas vezes, tomando a saída de 64 bits de uma iteração do DES como
entrada para a iteração DES seguinte e usando uma chave criptográfica diferente para cada rodada.
Por exemplo, o chamado DES triplo (3DES), um padrão proposto pelo governo norte-americano,
é o padrão de criptografia para o PPP para a camada de enlace. Uma discussão detalhada sobre
os comprimentos das chaves e sobre o tempo e o orçamento estimados necessários para quebrar
o DES pode ser encontrada em [Blaze, 1996].
Devemos ressaltar que em nossa descrição anterior consideramos apenas a criptografia de
uma quantidade 64 bits. Quando são criptografadas mensagens mais longas, o que é tipicamente
o caso, o DES é em geral usado junto com a técnica conhecida como encadeamento de blocos de
cifras, em que a versão criptografada da quantidade de 64 bits de ordem j é “OU exclusiva” com
a unidade de dados de ordem (j + 1) antes de a unidade de ordem (j + 1) ser criptografada.
C.2
RSA
Embora existam muitos algoritmos e chaves que tratam dessas preocupações, o algoritmo
RSA (cujo nome se deve a seus inventores, Ron Rivest, Adi Shamir e Leonard Adleman) se tornou
quase um sinônimo de criptografia de chave pública. De início, vamos ver como o RSA funciona
e, depois, examinar por que ele funciona. Suponha que Bob queira receber mensagens cifradas,
como mostra a Figura C-2. Há dois componentes inter-relacionados no RSA:
286

Escolha da chave pública e da chave privada.

O algoritmo de criptografia/decriptografia.
Figura C-2 – Criptografia de chaves públicas.
Para escolher as chaves pública e privada, Bob deve fazer o seguinte:
1. Escolher dois números primos grandes, p e q. Que ordem de grandeza devem ter p e q?
Quanto maiores os valores, mais difícil será quebrar o RSA, mas mais tempo se levará para
realizar a codificação e a decodificação. O RSA Laboratories recomenda que o produto de p
e q seja da ordem de 768 bits para uso pessoal e de 1.024 bits para uso empresarial. (O que
nos leva a pensar por que o uso empresarial é considerado muito mais importante do que o
uso pessoal!)
2. Computar n = pq e z = (p – 1)(q – 1).
3. Escolher um número e menor do que n que não tenha fatores comuns (exceto o 1) com z.
(Nesse caso, dizemos que e e z são números primos entre si.) A letra “e” é usada já que esse
valor será utilizado na criptografia (“encryption”, em inglês).
4. Achar um número d, tal que ed – 1 seja exatamente divisível (isto é, não haja resto na divisão)
por z. A letra “d” é usada porque seu valor será utilizado na decriptografia. Em outras
palavras, dado e, escolhemos d tal que o resto da divisão de ed por z seja o número inteiro 1.
(O número inteiro, que é o resto da divisão de x por um inteiro n, é chamado de x mod n.)
Portanto, a chave pública de Bob que está disponível a todos é o par de números (n, e); sua
chave privada é o par de números (n, d).
A criptografia feita por Alice e a decriptografia feita por Bob acontecem como segue:
1. Suponha que Alice queira enviar a Bob um padrão de bits, ou número m, tal que m < n. Para
codificar, Alice calcula a potência me e, então, determina o resto inteiro da divisão de me por
n. Assim, o valor cifrado, c, da mensagem em texto aberto, m, que Alice envia é:
c = me mod n.
2. Para decifrar a mensagem em texto cifrado, c, Bob processa:
m = cd mod n
que exige o uso de sua chave secreta (n, d).
287
Como exemplo simples de RSA, suponha que Bob escolha p = 5 e q = 7. (Admitimos que
esses valores são muito pequenos para serem seguros.) Então, n = 35 e z = 24. Bob escolhe e = 5,
já que 5 e 24 não têm fatores comuns. Por fim, ele escolhe d = 29, já que 5 x 29 – 1 (isto é, ed – 1)
é divisível exatamente por 24. Ele divulga os dois valores, n = 35 e e = 5, e mantém em segredo
o valor d = 29. Observando esses dois valores públicos, suponha que Alice queira agora enviar
as letras ‘1’, ‘o’, ‘v’ e ‘e’ a Bob. Interpretando cada letra como um número entre 1 e 26 (com ‘a’
sendo 1 e ‘z’ sendo 26), Alice e Bob realizam a criptografia e a decriptografia mostradas na
Tabela C-1 e na Tabela C-2, respectivamente.
Letra do Texto Aberto
m: Representação Numérica
me
Texto Cifrado c = me mod n
l
12
248.832
17
o
15
759.375
15
v
22
5.153.632
22
e
5
3.125
10
Tabela C-1 – Criptografia RSA para Alice: e = 5, n = 35.
cd
Texto Cifrado c
17
15
22
10
m = cd mod n
481968572106750915091411825223072000
12
12783403948858939111232757568359400
15
8.51643331908653770195619449972111e+38
22
100000000000000000000000000000
5
Tabela C-2 – Decriptografia RSA para Bob: d = 29, n = 35.
Letra do Texto
Aberto
l
o
v
e
Dado que o exemplo “de mentirinha” da Tabela C-1 e da Tabela C-2 já produziu alguns
números extremamente grandes e visto que sabemos, porque vimos anteriormente, que p e q
devem ter, cada um, algumas centenas de bits de comprimento, várias questões práticas nos vêm
à mente no caso do RSA. Como escolher números primos tão grandes? Como escolher e e d?
Como calcular exponenciais de números tão grandes?
Notamos que a exponenciação exigida pelo RSA é um processo que consome considerável
tempo. A RSA Data Security declara que as ferramentas de seu software podem cifrar/decifrar a
uma taxa de 21,6 Kbits por segundo com um valor de 512 bits para n e a uma taxa de 7,4 Kbits
por segundo com um valor de 1.024 bits. O DES é, no mínimo, cem vezes mais veloz em software
e entre mil e dez mil vezes mais veloz em hardware. Como resultado, o RSA é freqüentemente
usado na prática em combinação com o DES. Por exemplo, se Alice quiser enviar a Bob a uma
velocidade alta uma grande quantidade de dados cifrados à alta velocidade, ela pode fazer o
seguinte. Primeiramente, ela escolhe uma chave DES que será utilizada para codificar os dados
em si; essa chave às vezes é chamada de chave de sessão, Ks. Alice deve informar a Bob essa
chave de sessão, já que essa é a chave secreta compartilhada que eles vão usar para o DES. Ela
então criptografa o valor da chave de sessão usando a chave pública RSA de Bob, isto é, ela
processa c = (Ks)e mod n. Bob recebe a chave de sessão codificada RSA, c, e a decifra para obter
a chave de sessão Ks. Ele agora conhece a chave que Alice vai usar para transferir dados cifrados
em DES.
C.2.1 Porque o RSA funciona?
A criptografia/decriptografia do RSA parece mágica. Por que será que, aplicando o
algoritmo de criptografia e, em seguida, o algoritmo de decriptografia, podemos recuperar a
mensagem original? Para entendermos por que o RSA funciona, precisamos realizar algumas
operações usando a aritmética de módulo n. Na aritmética modular, são realizadas as
operações comuns de adição, multiplicação e exponenciação. Contudo, o resultado de cada
operação é substituído pelo resto inteiro da divisão de cada resultado por n. Tomemos n = pq,
onde p e q são os números primos grandes usados no algoritmo RSA.
288
Lembre-se de que na criptografia RSA uma mensagem (representada por um número
inteiro) m é primeiramente elevada à potência e usando-se a aritmética de módulo n para
fazer a codificação. A decifração é feita elevando-se esse valor à potência d, novamente
usando a aritmética de módulo n. O resultado de uma etapa de codificação, seguida de uma
etapa de decifração, é então (me)d. Vamos fazer agora algumas considerações sobre essa
quantidade. Temos:
(me)d mod n = med mod n.
Embora estejamos tentando remover um pouco do caráter “mágico” do modo de
funcionamento do RSA, precisaremos usar, aqui, outro resultado bastante mágico da teoria
dos números. Especificamente, precisamos de um resultado que diga que, se p e q forem
primos e n = pq, então xy mod n será o mesmo que x(y mod (p – 1)(q – 1)) mod n. Aplicando esse
resultado, temos
(me)d mod n = m(ed mod (p – l)(q – l)) mod n.
Mas lembre-se de que escolhemos e e d tais que ed – 1 seja exatamente divisível (isto
é, não há resto) por (p – 1)(q – 1), o que equivale a dizer que ed é divisível por (p – 1)(q – 1)
com resto 1 e então ed mod (p – l)(q – 1) = 1. Isso nos dá
(me)d mod n = m1 mod n = m
Ou seja
(me)d mod n = m
Esse é o resultado que esperávamos! Operando primeiramente a exponenciação da
potência e (isto é, codificando) e depois a exponenciação da potência d (isto é, decifrando),
obtemos o valor original m. E mais notável ainda é o fato de que primeiramente
exponenciamos ao fator d e, em seguida, ao fator e, isto é, revertendo a ordem da codificação
e da decifração, realizando inicialmente a operação de decifração e, em seguida, aplicando a
operação de codificação, também obtemos o valor original m! (A prova desse resultado segue
o mesmo raciocínio anterior.) Veremos em breve que essa propriedade maravilhosa do
algoritmo RSA
(me)d mod n = m = (md)e mod n
será de grande utilidade.
A segurança do RSA reside no fato de que não se conhecem algoritmos para fatorar
rapidamente um número; nesse caso, o valor público n, em números primos p e q. Se alguém
289
conhecesse os números p e q, então, dado o valor público e, poderia facilmente processar a
chave secreta d. Por outro lado, não se sabe se existem ou não algoritmos rápidos para fatorar
um número e, nesse sentido, a segurança do RSA não é “garantida”
290
Bibliografia
1. Redes de Computadores: das LANs, MANs e WANs às Redes ATM
Autor: Luiz Fernando Gomes Soares
2a Edição
Editora: Campus
2. Redes de Computadores e Internet
Autor: Douglas E. Comer
2a Edição
Editora: Bookman
3. Redes de Computadores
Autor: Andrew S. Tanenbaum
4a Edição
Editora: Campus
4. Comunicações entre Computadores e Tecnologias de Rede
Autores: Michael A. Gallo e William M. Hancock
1a Edição
Editora: Thomson Learning
5. Interligação de Redes com TCP/IP (Volume 1)
Autor: Douglas E. Comer
Tradução da 5a Edição
Editora: Campus
6. Redes de Computadores e a Internet – uma nova abordagem
Autores: James F. Kurose e Keith W. Ross
Tradução da 1a Edição
Editora: Addison Wesley
291

Apostila (Versão 2.10)

Transcrição

Documentos relacionados

Integrantes: Fabíola Dias, Jordan Gonçalvez, Lucas Rossales

Programa Trainees TCP (Advent International) TCP – CIA DE

Mariah Carey anuncia nome e data de lançamento

TCP/IP - Fabricio Breve

Trabalho de Revisão – UNIRIO – FRC 2014/1 Prof.: Sidney C. de

Bob Esponja Colorindo o Fundo do Mar

Encaminhamento de datagramas em roteadores IP Objetivo

ATENÇÃO!

- Folheto - Elgin Newera E1