Fontes de Distorção de Sinais em Transmissão Comuns/Redes/Apostila (v2.10).pdf · 5.2.3 Wireless...

Apostila de Fundamentos de

Redes de Computadores

Versão 2.10

Apostila de Fundamentos de Redes de Computadores Prof: Ricardo Quintão

2

Í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 Sinais Analógicos .............................................................................................................. 17 1.1.1.1.2 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 Ruído Térmico .................................................................................................................. 22 1.1.4.1.2 Ruído de Intermodulação ................................................................................................... 22 1.1.4.1.3 Ruído de Crosstalk (Linha Cruzada) .................................................................................. 22 1.1.4.1.4 Ruído Impulsivo ................................................................................................................ 23 1.1.4.1.5 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 Modulação por Amplitude (AM) ....................................................................................... 24 1.1.5.1.2 Modulação por Frequência (FM) ....................................................................................... 25 1.1.5.1.3 Modulação por Fase (PM) ................................................................................................. 25

1.1.5.2 Modulação Digital ........................................................................................................ 25 1.1.5.2.1 Modulação por Deslocamento de Amplitude (ASK) .......................................................... 25 1.1.5.2.2 Modulação por Deslocamento de Frequência (FSK) .......................................................... 26 1.1.5.2.3 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 Comutação de Pacotes – Circuito Virtual ........................................................................... 29 1.1.6.3.2 Comutação de Pacotes – Datagrama ................................................................................. 29

1.1.6.4 Células .......................................................................................................................... 30


3

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 TDM Síncrono .................................................................................................................. 33 1.1.8.2.2 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 Sinalização em Banda Básica ............................................................................................ 36 1.1.8.4.2 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 Codificação Manchester .................................................................................................. 41 1.1.10.2.2 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


4

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


5

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


6

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


7

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


8

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.3.2 Protocolo de autenticação PA 2.0 ....................................................................................... 225 9.3.3 Protocolo de autenticação PA 3.0 ....................................................................................... 225 9.3.4 Protocolo de autenticação PA 3.1 ....................................................................................... 226 9.3.5 Protocolo de autenticação PA 4.0 ....................................................................................... 226 9.3.6 Protocolo de autenticação PA 5.0 ....................................................................................... 227

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


9

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 0a .................................................................................................................... 257

A.1.2 Cálculo do na .................................................................................................................... 258

A.1.3 Cálculo do nb ..................................................................................................................... 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 0a .................................................................................................................... 269

A.2.2 Cálculo do na .................................................................................................................... 269

A.2.3 Cálculo do nb ..................................................................................................................... 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


10

Í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


11

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


12

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


13

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


14

Í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


15

Í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


16

Í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


17

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


18

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.


19

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


20

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: )(.)( senAf ou )cos(.)( Af , 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.


21

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 bps Llog 1 2baud (onde L é o número de níveis


22

utilizados na codificação), então a capacidade D do canal na ausência de ruído é dada

por:

bps Llog 2BD 2

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 sinal-

ruído é dada por S/N. É muito comum utilizar-se, ao invés desta razão diretamente, o

valor (S/N)log 10 10 . 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.


23

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:

S/N1log BD 2max

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.


24

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.


25

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


26

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


27

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


28

(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).


29

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.


30

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.

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.

1.1.8 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.


31

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


32

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.


33

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 tem-

se 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


34

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.


35

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, associa-

se 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.


36

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).


37

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 3n , 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á Kbps 648000.8 .

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,


38

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.


39

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:

tr nff

Como temos a relação entre frequência e período dada por: F

T1

, podemos

escrever que:

r

rf

T1

t

rnf

T1

Como t

tT

f1

temos que:

t

r

Tn

T1

1

n

TT t

r

Detectado o início de uma recepção, a amostragem se fará depois de passados 2n

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 nTt , 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.


40

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 2n 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 2n .

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


41

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.


42

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 43 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.


43

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.


44

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


45

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 10k é representado pelo polinômio

1)( 34689 XXXXXXXD . A ordem do polinômio D(X) será 1k .

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.


46

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.

Quadro 1101011011 1)( 34689 XXXXXXXD

Polinômio Gerador 10011 1)( 4 XXXG (ordem 4 4n )

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).


47

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:

112CRC 231112 XXXXX

116CRC 21516 XXX

1CCITTCRC 51216 XXX

132CRC 245781011121622232632 XXXXXXXXXXXXXX

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.


48

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.


49

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


50

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


51

(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


52

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 comunicar-

se 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


53

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:


54

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.

2.3 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


55

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.


56

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 bem-

definidas 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.


57

Funcionalidades das Camadas do Modelo OSI

Camadas Funcionalidades

Aplicação (7)

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.

Apresentação (6)

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.

Sessão (5)

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.


Transporte (4)

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



Rede (3)

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.

Enlace (2)

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.


Física (1)

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.


58

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


59

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ão-

confiá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


60

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.


61

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


62

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.


63

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 Lista do Segmento 1 Lista do Segmento 2

Bridge inicializada -------------------------- --------------------------

U envia para V U --------------------------

V envia para U U, V --------------------------

Z faz broadcast U, V Z

Y envia para V U, V Z, Y

Y envia para X U, V Z, Y

X envia para W U, V Z, Y, X

W envia para Z U, V, W 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,


64

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 é

2

nT , onde T é a taxa em que um determinado computador pode transmitir dados e n é o número

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.


65

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.


66

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


67

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.


68

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.


69

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).


70

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,


71

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.


72

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 462 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


73

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:. TempoTaxaQuadro , sendo assim, obteremos como

tamanho mínimo para um quadro Ethernet o valor de

bits 50010501010 66 Quadro , 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


74

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 123 .

Em geral, depois de i colisões, é escolhido um número aleatório entre 0 e 12 i ,

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


75

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 sem-

fio 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.


76

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;


77

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


78

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.


79

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.


80

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


81

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.


82

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.


83

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.


84

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 infra-

estrutura 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).


85

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.


86

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.


87

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


88

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.


89

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 inter-

rede 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


90

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 Inter-

redes 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 Aplicação Camada 4 Aplicação

Camada 4 Transporte Camada 3 Transporte

Camada 3 Internet (Rede) Camada 2 Internet (Rede)

Camada 2 Interface de

Rede

Camada 1 Enlace

Camada 1 Física 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.


91

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).


92

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.


93

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 1 2 3 8 1

6

2

4

3

1

Classe A 0 Prefixo Sufixo

Classe B 1 0 Prefixo Sufixo

Classe C 1 1 0 Prefixo Sufixo

Classe A 1 1 1 0 Endereço Multicast

Classe D 1 1 1 1 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.


94

Primeiros Quatro

Bits do Endereço

Índice da Tabela

(em decimal)

Classe do

endereço

0000 0 A

0001 1 A

0010 2 A

0011 3 A

0100 4 A

0101 5 A

0110 6 A

0111 7 A

1000 8 B

1001 9 B

1010 10 B

1011 11 B

1100 12 C

1101 13 C

1110 14 D

1111 15 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 Notação Decimal Pontilhada Equivalente

10000001.00110100.00000110.00000000 129.52.6.0

11000000.00000101.00110000.00000011 192.5.48.3

00001010.00000010.00000000.00100101 10.2.0.37

10000000.00001010.00000010.00000011 128.10.2.3

10000000.10000000.11111111.00000000 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.


95

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 Faixa de Valores

Binário Decimal

A 0000 0000 até 0111 1111 0 até 127

B 1000 0000 até 1011 1111 128 até 191

C 1100 0000 até 1101 1111 192 até 223

D 1110 0000 até 1110 1111 224 até 239

E 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 inter-

rede 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.


96

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.


97

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.


98

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 Sufixo Tipo de endereço Propósito

Tudo em 0 Tudo em 0 Este computador Usado durante o bootstrap

Rede Tudo em 0 Rede Identifica uma rede

Rede Tudo em 1 Broadcast Dirigido Broadcast em rede específica

Tudo em 1 Tudo em 1 Broadcast Limitado Broadcast na rede local

127 Qualquer valor Loopback 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 é, rT 2Redes , 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, deve-

se 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: 22Hosts hT ,

onde h representa o total de bits de host.

Classe Bits no Prefixo Total de Redes Bits no Sufixo Total de Hosts

A 7 128 24 16.777.214

B 14 16.384 16 65.534

C 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;


99

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


100

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 sub-

rede. 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 + sub-

rede. 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.


101

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 sub-

rede 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.


102

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


103

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 )I(F AA f

.

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.


104

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


105

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.


106

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.


107

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


108

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.


109

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.


110

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 8

1

6

2

4

3

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


111

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.


112

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ão-

confiá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


113

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 4 8

1

6

1

9

2

4

3

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.

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


114

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.


115

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.


116

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


117

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.


118

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.


119

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-


120

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


121

é 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


122

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.


123

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:

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.

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.


124

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


125

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.


126

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.


127

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 SIP1 (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:

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).

1 O acrônimo SIP agora se refere a Session Initiation Protocol.


128

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).


129

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 12 16 24 31

VERS Classe de Tráfego Rótulo de Fluxo

Tamanho do Payload 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.


130

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 ROUTE


(b)

Cabeçalho BÁSICO

Próximo = ROUTE

Cabeçalho ROUTE

Próximo = AUTH

Cabeçalho AUTH


(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. Lembre-

se de que o IPv4 requer que um roteador intermediário fragmente qualquer datagrama que


131

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 16 29 31

Próximo Cabeçalho RESERVADO Offset de Fragmento RS M

IDENTIFICAÇÃO DO DATAGRAMA 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-a-

fim 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.


132

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 16 24 31

Próximo Cabeçalho Tamanho do Cabeçalho

de Extensão

Tipo de Roteamento 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 16 24 31

Próximo Cabeçalho Tamanho Cabeçalho

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 valor1. As opções

não estão alinhadas ou preenchidas.

0 8 16

TIPO 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).


133

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 Significado

00 Pular esta Opção.

01 Descartar datagrama; não enviar mensagem ICMP.

10 Descartar datagrama; enviar mensagem ICMP à origem.

11 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 1024

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 2128 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:


134

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 16 bits 32 bits

0000.......0000 0000 Endereço IPv4

0000.......0000 FFFF 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.


135

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 64–N bits 64 bits

PREFIXO DE ROTEAMENTO GLOBAL ID DE SUB-REDE 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


136

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.


137

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.


138

É 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.


139

Campo de Tipo Tipo de mensagem ICMP

0 Resposta de eco

3 Destino inalcançável

4 Extinção de origem

5 Redirecionamento (mudar de rota)

6 Endereço de host alternativo

8 Requisição de eco

9 Anúncio de roteador

10 Solicitação de roteador

11 Tempo excedido para um datagrama

12 Problema de parâmetro em um datagrama

13 Requisição de estampa de tempo

14 Resposta de estampa de tempo

15 Requisição de informações

16 Resposta de informações

17 Requisição de máscara de tempo

18 Resposta de máscara de tempo

30 Traceroute

31 Erro de conversão de datagrama

32 Redirecionar host móvel

33 “Onde está você” do IPv6

34 “Eu estou aqui” do IPv6

35 Requisição de registro móvel

36 Resposta de registro móvel

37 Requisição de nome de domínio

38 Resposta de nome de domínio

39 SKIP

40 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.


140

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

TIPO (3) CÓDIGO (0 – 15) CHECKSUM

NÃO USADO (PRECISA SER ZERO)

CABEÇALHO INTERNET + PRIMEIROS 64 BITS DO DATAGRAMA

... 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 entrega2. Como a mensagem de erro ICMP contém um

1 Dave Mills ceta vez sugeriu que PING é um acr6onimo para Packet InterNet Groper. 2 O IETF recomenda apenas relatar mensagens de host inalcançável à origem e usar protocolos de roteamento para lidar com

outros problemas de encaminhamento.


141

prefixo curto do datagrama que causou o problema, a origem saberá exatamente qual

endereço é inalcançável.

Valor do Código Significado

0 Rede inalcançável

1 Host inalcançável

2 Protocolo inalcançável

3 Porta inalcançável

4 Fragmentação necessária e DF marcado

5 Rota de origem falhou

6 Rota de destino desconhecida

7 Host de destino desconhecido

8 Host de origem isolado

9 Comunicação com rede de destino proibida administrativamente

10 Comunicação com host de destino proibida administrativamente

11 Rede inalcançável para tipo de serviço

12 Host inalcançável para tipo de serviço

13 Comunicação proibida administrativamente

14 Violação de precedência de host

15 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


142

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


143

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.


144


0 Redirecionar datagramas para a Rede (agora obsoleto)

1 Redirecionar datagramas para o Host

2 Redirecionar datagramas para o Tipo de Serviço; e Rede

3 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




... 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.


0 Contador de tempo de vida excedido

1 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


145

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


PONTEIRO NÃO USADO (PRECISA SER ZERO)


... 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 NÚMERO DE SEQÜÊNCIA

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.


146

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


147

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


148

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 31

PORTA DE ORIGEM UDP PORTA DE DESTINO UDP

TAMANHO DA MENSAGEM 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


149

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 16 31

ENDEREÇO IP DE ORIGEM

ENDEREÇO IP DE DESTINO

ZERO 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.


150

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.


151

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


152

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.


153

Decimal Palavra-Chave Palavra-Chave do

Unix

Descrição

0 – – Reservado

7 ECHO echo Eco

9 DISCARD discard Descarte

11 USERS systat Usuários ativos

13 DAYTIME daytime Hora do dia

15 – netstat Programa de status da rede

17 QUOTE qotd Citação do dia

19 CHARGEN chargen Gerador de caracteres

37 TIME time Hora

42 NAMESERVER name Servidor de nome de host

43 NICNAME whois Quem é

53 DOMAIN nameserver Domain Name Server

67 BOOTPS bootps Servidor BOOTP ou DHCP

68 BOOTPC bootpc Cliente BOOTP ou DHCP

69 TFTP tftp Trivial File Transfer

88 KERBEROS kerberos Serviço de segurança Kerberos

111 SUNRPC sunrpc Sun Remote Procedure Call

123 NTC ntp Network Time Protocol

161 – snmp Simple Network Management Protocol

162 – snmp-trap Traps SNMP

512 – biff Comsat do UNIX

513 – who Daemon rwho do UNIX

514 – syslog Log do sistema

525 – timed 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


154

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ão-

confiá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


155

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.


156

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.


157

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


158

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


159

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


160

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á


161

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.


162

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.


163

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 10 16 24 31

PORTA DE ORIGEM PORTA DE DESTINO

NÚMERO DE SEQÜÊNCIA

NÚMERO DE CONFIRMAÇÃO

HLEN 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) Significado se bit definido como 1

URG Campo ponteiro de urgente é válido

ACK Campo de confirmação é válido

PSH Este segmento requer um push

RST Reinicia a conexão

SYN Sincroniza números de sequência

FIN 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.


164

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.1 Opçã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


165

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.2 Opçã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.


166

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.3 Opçã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 16 31

ENDEREÇO IP DE ORIGEM

ENDEREÇO IP DE DESTINO

ZERO 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


167

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”.


168

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.


169

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


170

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.


171

Decimal Palavra-Chave Descrição

0 – Reservado

7 ECHO Eco

9 DISCARD Descarte

11 USERS Usuários ativos

13 DAYTIME Hora do dia

15 NETSAT Programa de status da rede

17 QUOTE Citação do dia

19 CHARGEN Gerador de caracteres

20 FTP-DATA File Transfer Protocol (dados)

21 FTP File Transfer Protocol (controle)

22 SSH Secure Shell

23 TELNET Conexão de terminal

25 SMTP Simple Mail Transport Protocol

37 TIME Hora

53 DOMAIN Domain Name Server

67 BOOTPS Servidor BOOTP ou DHCP

79 FINGER Finger

80 WWW World Wide Web Server

88 KERBEROS Serviço de segurança Kerberos

110 POP3 Post Office Protocol versão 3

111 SUNRPC Sun Remote Procedure Call

119 NNTP USENET News Transfer Protocol

123 NTC Network Time Protocol

143 IMAP Internet Message Access Protocol

161 SNMP Simple Network Management Protocol

443 HTTPS http seguro

465 SMTPS SMTP over SSL (TLS)

515 SPOOLER Spooler LPR

873 RSYNC Protocolo Rsync

993 IMAPS IMAP seguro

995 POP3S POP3 seguro

1080 SOCKS Protocolo servidor de Proxy

Tabela 7.13 – Exemplos de números de porta TCP.


172

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 é


173

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.


174

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á.


175

0 8 16 24 31

OP TIPO_H TAM_H SALTOS

ID DA TRANSAÇÃO

SEGUNDOS 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 15

B

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


176

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-Tamanho-

Valor (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.


177

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


178

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.


179

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

Porta

Privada

Endereço

Externo

Porta

Externa

Porta NAT Protocolo

usado

10.0.0.5 21.023 128.10.19.20 80 14.003 Tcp

10.0.0.1 386 128.10.19.20 80 14.010 Tcp

10.0.2.6 26.600 207.200.75.200 21 14.012 Tcp

10.0.0.3 1.274 128.210.1.5 80 14.007 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)


180

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


181

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


182

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á-


183

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.


184

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


185

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


186

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 Setor de transporte aéreo

arpa Domínio de infra-estrutura

biz Negócios

com Organização comercial

coop Associações cooperativas

edu Instituição educacional (4 anos)

gov Governo dos Estados Unidos

info Informação

int Organizações de tratado internacional

mil Militares dos Estados Unidos

museum Museus

name Indivíduos

net Principais centros de suporte de rede

org Organizações diferentes das citadas

pro Profissionais credenciados

Código do país 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


187

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


188

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.


189

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.


190

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.


191

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.


192

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.


193

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


194

ú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.


195

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 HELO é uma abreviatura para “hello” 2 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.


196

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.

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

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


197

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


198

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.

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.

8.5.2 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.


199

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


200

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


201

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


202

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.


203

É 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


204

[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.


205

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”


206

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 “Accept-

language:” 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


207

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 “Last-

Modified:” 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 “Content-

Type:”, e não pela extensão do arquivo).


208

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,


209

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.


210

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 “Set-

cookie:” 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


211

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:


212

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.


213

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”.


214

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.


215

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.


216

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á


217

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


218

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 infra-

estrutura 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


219

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.


220

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”.


221

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! (1026) 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


222

à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


223

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 é, eB(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.


224

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.


225


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.


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,


226

essa é uma abordagem muito conhecida para roubar senhas. Essa ameaça, obviamente, é

muito real; portanto, o PA 3.0 com certeza não é apropriado.



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.


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


227

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).



O uso de um nonce e da criptografia de chaves simétricas criou a base de nosso bem-

sucedido 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).


228

4. Bob aplica o algoritmo criptográfico público de Alice, eA, à 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, dT 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 eA ao valor que acabou de

receber. Ele envia a mensagem a Alice, pedindo seu eA (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.


229

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.


230

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, eB, 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 dB é 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 dB é

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.


231

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 dB(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.


232

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


233

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”


234

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 264 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,


235

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


236

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 R1 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!


237

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!


238

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.


239

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 da versão da especificação X.509

Número de Série Identificador exclusivo emitido pela CA para um certificado

Assinatura Especifica o algoritmo usado pela CA para “assinar” esse certificado

Nome do Emissor Identidade da CA que emitiu o certificado no formato chamado de nome distinto (DN)

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

Chave Pública do Sujeito A chave pública do sujeito, bem como uma indicação do algoritmo de chave pública (e

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.


240

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


241

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, eB, (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 e-

mail 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 dB para obter a chave simétrica KS e (2) utilizar

a chave simétrica KS para decifrar a mensagem m.


242

Figura 9.22 – Alice usa uma chave de sessão simétrica KS.

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


243

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.


244

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.

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, assinando-

as 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.

- - - - 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 - - - - -

- - - - - BEGIN PGP MESSAGE - - - - -

Version: PGP for Personal Privacy 5.0

U2R4d+/jKmn8Bc5hgDsqAewsDfrGdszX681iKm5F6Gc4sDfcXytRfdS10juHgb

cfDssWe7/K=1KhnMikLo0+1/BvcX4t==Ujk9PbcD4Thdf2awQfgHbnmK1ok8iy

6gThlp

- - - - - END PGP MESSAGE


245

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


246

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


247

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.


248

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


249

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


250

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


251

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


252

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


253

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.


254

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.


255

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 )(tf 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 )(tf . Isto é, a cada novo harmônico somado estaremos

nos aproximando cada vez mais da onda original formada pela função )(tf . 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.


256

11

0 )2cos()2(2

1)(

n

n

n

n nftbnftsenaatf

Equação A-1 – Forma Geral da Série de Fourier.

Onde:

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 0a , na e nb que são

baseados na função original )(tf . A complexidade deste cálculo está diretamente relacionada com a

função )(tf . 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 na e nb respectivamente e apenas da função dt no caso do 0a .

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.

22

nn baA

Equação A-3 – Amplitude de Média Quadrática de cada Harmônico de Fourier.

T

dttfT

a0

0 )(2

T

n dtnftsentfT

a0

)2()(2

T

n dtnfttfT

b0

)2cos()(2


257

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 )(tf abaixo representa o sinal NRZ da Figura acima.

8

8

8

7 se 0

8

7

8

6 se 1

8

6

8

3 se 0

8

3

8 se 1

80 se 0

)(

Tt

T

Tt

T

Tt

T

Tt

T

Tt

tf

Equação A-4 – Função Representante do Sinal NRZ.

A.1.1 Cálculo do 0a

T

dttfT

a0

0 )(2

8

8

8

7

8

7

8

6

8

6

8

3

8

3

8

8

0

0 010102

T

T

T

T

T

T

T

T

T

dtdtdtdtdtT

a

8

7

8

6

8

3

8

0

2

T

T

T

T

dtdtT

a

tt

T

T

T

TTa

87

86

83

80

2


258

8

8

8

7

88

320

TTTT

Ta

88

220

TT

Ta

8

320

T

Ta

4

30 a

Equação A-5 – Coeficiente a0 do Sinal NRZ.

A.1.2 Cálculo do na

T

n dtnftsentfT

a0

)2()(2

8

8

8

7

8

7

8

6

8

6

8

3

8

3

8

8

0

)2(0)2(1)2(0)2(1)2(02

T

T

T

T

T

T

T

T

T

n dtnftsendtnftsendtnftsendtnftsendtnftsenT

a

8

7

8

6

8

3

8

)2()2(2

T

T

T

T

n dtnftsendtnftsenT

a

Considerando fnk 2 temos:

8

7

8

6

8

3

8

)()(2

T

T

T

T

n dtktsendtktsenT

a

)cos()cos(

87

86

83

8

2ktkt

T

T

T

Tn

Tka

8

6cos

8

7cos

8cos

8

3cos

2 kTkTkTkT

Tkan

Substituindo o valor de k e considerando que T

f1

temos:

T

nT

T

nT

T

nT

T

nT

nT

Tan

8

26cos

8

27cos

8

2cos

8

23cos

2

2


259

Simplificando os termos semelhantes e mudando a ordem dos cossenos ficamos com:

4

7cos

4

6cos

4

3cos

4cos

1 nnnn

nan

Equação A-6 – Coeficiente an do Sinal NRZ.

A.1.3 Cálculo do nb

T

n dtnfttfT

b0

)2cos()(2

8

8

8

7

8

7

8

6

8

6

8

3

8

3

8

8

0

)2cos(0)2cos(1)2cos(0)2cos(1)2cos(02

T

T

T

T

T

T

T

T

T

n dtnftdtnftdtnftdtnftdtnftT

b

8

7

8

6

8

3

8

)2cos()2cos(2

T

T

T

T

n dtnftdtnftT

b


8

7

8

6

8

3

8

)cos()cos(2

T

T

T

T

n dtktdtktT

b

)()(

87

86

83

8

2ktsenktsen

T

T

T

Tn

Tkb

8

6

8

7

88

32 kTsen

kTsen

kTsen

kTsen

Tkbn


f1

temos:

T

nTsen

T

nTsen

T

nTsen

T

nTsen

nT

Tbn

8

26

8

27

8

2

8

23

2

2

Simplificando os termos semelhantes e mudando a ordem dos senos ficamos com:

4

7

4

6

4

3

4

1 nsen

nsen

nsen

nsen

nbn

Equação A-7 – Coeficiente bn do Sinal NRZ.


260

A Série de Fourier completa da função )(tf é:

1

1

4

7

4

6

4

3

4

)2cos(

4

7cos

4

6cos

4

3cos

4cos

)2(

4

3

2

1)(

n

n

nsen

nsen

nsen

nsen

n

nf

nnnn

n

nftsentf

1

1

4

7

4

6

4

3

4

)2cos(

4

7cos

4

6cos

4

3cos

4cos

)2(

8

3)(

n

n

nsen

nsen

nsen

nsen

n

nf

nnnn

n

nftsentf

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 é, u.t. 8T logo a

freqüência será de u.f. 8

1f (unidade de freqüência). Foram feitos gráficos considerando

até 10 harmônicos, isto é, de 1n até 10n .

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. Nota-

se 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.


261

Figura A-2 – Sinal Original.

Figura A-3 – 10 Harmônicos de Fourier.

0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo

Sinal Original

Sinal Original

-0,2

0

0,2

0,4

0,6

0,8

1

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 5,5 6 6,5 7 7,5 8

Am

plitu

de

Tempo

Harmônicos de Fourier

n=1

n=2

n=3

n=4

n=5

n=6

n=7

n=8

n=9

n=10


262

Figura A-4 – Primeiro Harmônico de Fourier.

Figura A-5 – Somatório dos 2 primeiros Harmônico de Fourier.

0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo

Primeiro Harmônico

1 Harmônico

Dados Originais

-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo

Somatório dos 2 primeiros harmônicos

2 Harmônicos

Dados Originais


263



-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo

Somatório dos 3 primeiros Harmônicos

3 Harmônicos

Dados Originais

-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Am

plitu

de

Tempo


4 Harmônicos

Dados Originais


264



-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Am

plitu

de

Tempo


5 Harmônicos

Dados Originais

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo


6 Harmônicos

Dados Originais


265



-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo


7 Harmônicos

Dados Originais

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo


8 Harmônicos

Dados Originais


266



-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo


9 Harmônicos

Dados Originais

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Am

pli

tud

e

Tempo


10 Harmônicos

Dados Originais


267

Figura A-14 – Amplitude de Média Quadrática de cada Harmônico de Fourier.

Amplitude de Média Quadrática dos Harmônicos

0,24336

0,50383

0,19544

0,15924

0,11840

0,16757

0,03522

0,000380,02670

0,10099

0

0,1

0,2

0,3

0,4

0,5

0,6

1 2 3 4 5 6 7 8 9 10

Harmônicos

Am

plitu

de

Amplitude


268

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 )(tf abaixo representa o sinal NRZ da Figura acima.

16

16

16

15 se 0

16

15

16

13 se 1

16

13

16

11 se 0

16

11

16

10 se 1

16

10

16

9 se 0

16

9

16

8 se 1

16

8

16

7 se 0

16

7

16

5 se 1

16

5

16

4 se 0

16

4

16

3 se 1

16

3

16 se 0

160 se 1

)(

Tt

T

Tt

T

Tt

T

Tt

T

Tt

T

Tt

T

Tt

T

Tt

T

Tt

T

Tt

T

Tt

T

Tt

tf

Equação A-9 – Função Representante do Sinal Manchester.


269

A.2.1 Cálculo do 0a

T

dttfT

a0

0 )(2

16

15

16

13

16

11

16

10

16

9

16

8

16

7

16

5

8

4

16

3

16

0

0 1111112

T

T

T

T

T

T

T

T

T

T

T

dtdtdtdtdtdtT

a

tttttt

T

T

T

T

T

T

T

T

T

T

T

Ta

1615

1613

1611

1610

169

168

167

165

164

163

16

00

2

16

13

16

15

16

10

16

11

16

8

16

9

16

5

16

7

16

3

16

40

16

20

TTTTTTTTTTT

Ta

16

2

161616

2

1616

20

TTTTTT

Ta

16

820

T

Ta

10 a

Equação A-10 – Coeficiente a0 do Sinal Manchester.

A.2.2 Cálculo do na

T

n dtnftsentfT

a0

)2()(2

16

15

16

13

16

11

16

10

16

9

16

8

16

7

16

5

16

4

16

3

16

0

)2(1)2(1)2(1

)2(1)2(1)2(1

2T

T

T

T

T

T

T

T

T

T

T

n

dtnftsendtnftsendtnftsen

dtnftsendtnftsendtnftsen

Ta


270


16

15

16

13

16

11

16

10

16

9

16

8

16

7

16

5

16

4

16

3

16

0

)(1)(1)(1

)(1)(1)(1

2T

T

T

T

T

T

T

T

T

T

T

n

dtktsendtktsendtktsen

dtktsendtktsendtktsen

Ta

)cos()cos()cos(

)cos()cos()cos(

1615

1613

1611

1610

169

168

167

165

164

163

16

02

ktktkt

ktktkt

T

T

T

T

T

T

T

T

T

T

T

nTk

a

16

13cos

16

15cos

16

10cos

16

11cos

16

8cos

16

9cos

16

5cos

16

7cos

16

3cos

16

4cos0cos

16cos

2

kTkTkTkTkTkT

kTkTkTkTkT

Tkan


f1

temos:

T

nT

T

nT

T

nT

T

nT

T

nT

T

nT

T

nT

T

nT

T

nT

T

nT

T

nT

nT

Tan

16

213cos

16

215cos

16

210cos

16

211cos

16

28cos

16

29cos

16

25cos

16

27cos

16

23cos

16

24cos1

16

2cos

2

2

Simplificando os termos semelhantes e mudando a ordem dos cossenos ficamos com:

8

15cos

8

13cos

8

11cos

8

10cos

8

9cos

8

8cos

8

7cos

8

5cos

8

4cos

8

3cos

8cos1

1

nnnnn

nnnnnn

nan

Equação A-11 – Coeficiente an do Sinal Manchester.


271

A.2.3 Cálculo do nb

T

n dtnfttfT

b0

)2cos()(2

16

15

16

13

16

11

16

10

16

9

16

8

16

7

16

5

16

4

16

3

16

0

)2cos(1)2cos(1)2cos(1

)2cos(1)2cos(1)2cos(1

2T

T

T

T

T

T

T

T

T

T

T

n

dtnftdtnftdtnft

dtnftdtnftdtnft

Tb


16

15

16

13

16

11

16

10

16

9

16

8

16

7

16

5

16

4

16

3

16

0

)cos(1)cos(1)cos(1

)cos(1)cos(1)cos(1

2T

T

T

T

T

T

T

T

T

T

T

n

dtktdtktdtkt

dtktdtktdtkt

Tb

)()()(

)()()(

1615

1613

1611

1610

169

168

167

165

164

163

16

02

ktsenktsenktsen

ktsenktsenktsen

T

T

T

T

T

T

T

T

T

T

T

nTk

b

16

13

16

15

16

10

16

11

16

8

16

9

16

5

16

7

16

3

16

40

162

kTsen

kTsen

kTsen

kTsen

kTsen

kTsen

kTsen

kTsen

kTsen

kTsensen

kTsen

Tkbn


f1

temos:

T

nTsen

T

nTsen

T

nTsen

T

nTsen

T

nTsen

T

nTsen

T

nTsen

T

nTsen

T

nTsen

T

nTsen

T

nTsen

nT

Tbn

16

213

16

215

16

210

16

211

16

28

16

29

16

25

16

27

16

23

16

240

16

2

2

2


272

Simplificando os termos semelhantes e mudando a ordem dos senos ficamos com:

8

15

8

13

8

11

8

10

8

9

8

8

8

7

8

5

8

4

8

3

81

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nbn

Equação A-12 – Coeficiente bn do Sinal Manchester.

A Série de Fourier completa da função )(tf é:

1

1

8

15

8

13

8

11

8

10

8

9

8

8

8

7

8

5

8

4

8

3

8)2cos(

8

15cos

8

13cos

8

11cos

8

10cos

8

9cos

8

8cos

8

7cos

8

5cos

8

4cos

8

3cos

8cos1

)2(1

2

1)(

n

n

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

n

nf

nnn

nnnn

nnnn

n

nftsentf

1

1

8

15

8

13

8

11

8

10

8

9

8

8

8

7

8

5

8

4

8

3

8)2cos(

8

15cos

8

13cos

8

11cos

8

10cos

8

9cos

8

8cos

8

7cos

8

5cos

8

4cos

8

3cos

8cos1

)2(

2

1)(

n

n

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

nsen

n

nf

nnn

nnnn

nnnn

n

nftsentf

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 é, u.t. 8T logo a

freqüência será de u.f. 8

1f (unidade de freqüência). Foram feitos gráficos considerando

até 13 harmônicos, isto é, de 1n até 13n .

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


273

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.

Figura A-16 – Sinal Original.

Figura A-17 – 13 Harmônicos de Fourier.

Sinal Original

0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

Sinal Original

Harmônicos de Fourier

0

0,1

0,2

0,3

0,4

0,5

0,6

0,7

0,8

0,9

1

0 0,5 1 1,5 2 2,5 3 3,5 4 4,5 5 5,5 6 6,5 7 7,5 8

Tempo

Am

plitu

de

n=1

n=2

n=3

n=4

n=5

n=6

n=7

n=8

n=9

n=10

n=11

n=12

n=13


274

Figura A-18 – Primeiro Harmônico de Fourier.


Primeiro Harmônico

0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

1 Harmônico

Dados Originais


0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

2 Harmônicos

Dados Originais


275




0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

3 Harmônicos

Dados Originais


0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

4 Harmônicos

Dados Originais


276




-0,2

0

0,2

0,4

0,6

0,8

1

1,2

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

5 Harmônicos

Dados Originais


-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

6 Harmônicos

Dados Originais


277




-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

7 Harmônicos

Dados Originais


-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

8 Harmônicos

Dados Originais


278




-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

9 Harmônicos

Dados Originais


-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

10 Harmônicos

Dados Originais


279




-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

11 Harmônicos

Dados Originais


-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

12 Harmônicos

Dados Originais


280


Figura A-31 – Amplitude de Média Quadrática de cada Harmônico de Fourier.


-0,4

-0,2

0

0,2

0,4

0,6

0,8

1

1,2

1,4

0 1 2 3 4 5 6 7 8

Tempo

Am

plitu

de

13 Harmônicos

Dados Originais

Amplitude de Média Quadrática dos Harmônicos

0,04889

0,20822

0,13000

0,159620,17752

0,40486

0,175880,15923

0,13533

0,24349

0,07867

0,052720,03131

0

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0,4

0,45

1 2 3 4 5 6 7 8 9 10 11 12 13

Harmônicos

Am

plitu

de

Amplitude


281

A.3 Como Integrar Funções Seno e Cosseno

Recordando conceitos importantes:

)()cos( usenduu

)cos()( uduusen

Se tivermos que calcular dxkx)cos( ,

devemos realizar uma mudança de variável,

como segue abaixo:

dxkx)cos(

kxu

kdxdu

k

dudx

Realizando as substituições temos:

k

duudxkx

)cos()cos(

)(1

)cos(1

usenk

duuk

Logo,

)(1

)cos( kxsenk

dxkx

Se tivermos que calcular dxkxsen )( ,

devemos realizar uma mudança de variável,

como segue abaixo:

dxkxsen )(

kxu

kdxdu

k

dudx

Realizando as substituições temos:

k

duusendxkxsen

)()(

)cos(1

)(1

uk

duusenk

Logo,

)cos(1

)( kxk

dxkxsen


282

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 é: centrípetaresultante FF

. 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

seja a força resultante. Ela é representada pela seguinte relação: 2

satélite

satéliteterranalgravitacio

R

MMGF

, onde

G é a constante gravitacional universal, terraM é a massa da terra, satéliteM é a massa do satélite e satéliteR

é a distância do satélite até o centro da terra, isto é, o raio da órbita do satélite.

A força centrípeta é dada pela seguinte relação: R

vMF

2

centrípeta

considerando a velocidade

linear (v) ou RMF 2

centrípeta considerando a velocidade angular ().

Considerando a relação inicial em que centrípetaresultante FF

temos:

2

satélite

satéliteterrasatélite

2

satéliteR

MMGRM

3

satélite

terra2

R

MG


283

3

satélite

terra

R

MG

Equação B-1 – Velocidade Angular do Satélite.

2

terra3

satélite

MGR

32

terra

satélite

MGR

Equação B-2 – Raio do Satélite.

A velocidade linear (v) pode ser calculada pela seguinte relação: Rv

Sendo assim, podemos calcular a velocidade linear a partir da Equação B-1 como mostra abaixo:

3

satélite

terrasatélitesatélite

R

MGRv

3

satélite

2

satéliteterrasatélite

R

RMGv

satélite

terra

satéliteR

MGv

Equação B-3 – Velocidade Linear do Satélite.

Para calcular a altura (h) do satélite utilizamos a seguinte relação:

terrasatélite RRh

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 ( satéliteR ), 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:

terrasatélite

Equação B-5 – Condição Necessária para Órbitas Geoestacionárias.

Calculando a velocidade angular da Terra ( terra ):

HoraRadianosterra24

2


284

HoraRadianosterra12

SegundoRadianosterra600.312

SegundoRadianosterra200.43

Equação B-6 – Velocidade Angular da Terra.

Logo, a velocidade angular do satélite ( satélite ) deverá ser:

SegundoRadianos200.43

satélite

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:

KgM terra

241097,5

Equação B-8 – Massa da Terra.

KmRterra 5,376.6

Equação B-9 – Raio da Terra.

2211106742,6 KgMetroNewtonG

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:

KmR 77,235.42satélite

Logo a sua altura em relação à superfície da terra (h) será dada pela Equação B-4:

Kmh 27,859.35

Equação B-11 – Altura do Satélite para uma Órbita Geoestacionária.


285

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.


286

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:


287

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).


288

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.

Texto Cifrado c cd m = cd mod n Letra do Texto

Aberto

17 481968572106750915091411825223072000 12 l

15 12783403948858939111232757568359400 15 o

22 8.51643331908653770195619449972111e+38 22 v

10 100000000000000000000000000000 5 e

Tabela C-2 – Decriptografia RSA para Bob: d = 29, n = 35.

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.


289

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


290

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”


291

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

Fontes de Distorção de Sinais em Transmissão Comuns/Redes/Apostila (v2.10).pdf · 5.2.3 Wireless...

Documents

Transcript of Fontes de Distorção de Sinais em Transmissão Comuns/Redes/Apostila (v2.10).pdf · 5.2.3 Wireless...