Qual evento ocorre se houver uma violação de segurança na porta s1 fa0/ 1 switch?

Arquitetura e

Índice Show

O que acontece com as portas membros de uma VLAN quando ela é excluída?
Qual é o resultado de um ataque de privação de DHCP?
Qual é o endereço IP da interface virtual do switch SVI no Switch0?
Quais são os dois protocolos que são usados pelo AAA para autenticar usuários em um banco de dados central de nomes de usuário e senha?

Protocolos de Rede TCP-IP Glêdson Elias Luiz Carlos Lobato

A RNP – Rede Nacional de Ensino e Pesquisa – é qualificada como uma Organização Social (OS), sendo ligada ao Ministério da Ciência, Tecnologia e Inovação (MCTI)

responsável

pelo

Programa Interministerial RNP, que conta com a participação dos ministérios da Educação (MEC), da Saúde (MS) e da Cultura (MinC). Pioneira no acesso à Internet no Brasil, a RNP planeja e mantém a rede Ipê, a rede óptica nacional acadêmica de alto desempenho. Com Pontos de Presença nas 27 unidades da federação, a rede tem mais de 800 instituições conectadas. São aproximadamente 3,5 milhões de usuários usufruindo de uma infraestrutura de redes avançadas para comunicação, computação e experimentação, que contribui para a integração entre o sistema de Ciência e Tecnologia, Educação Superior, Saúde e Cultura.

Ministério da Cultura Ministério da Saúde Ministério da Educação Ministério da Ciência, Tecnologia e Inovação

Arquitetura e

Protocolos de Rede TCP-IP

Glêdson Elias Luiz Carlos Lobato

Arquitetura e

Protocolos de Rede TCP-IP Glêdson Elias Luiz Carlos Lobato

Rio de Janeiro Escola Superior de Redes 2013

Nelson Simões Diretor de Serviços e Soluções

José Luiz Ribeiro Filho

Escola Superior de Redes Coordenação

Luiz Coelho Edição

Pedro Sangirardi Coordenação Acadêmica de Administração e Projeto de Redes

Luiz Carlos Lobato

Equipe ESR (em ordem alfabética)

Celia Maciel, Cristiane Oliveira, Derlinéa Miranda, Edson Kowask, Elimária Barbosa, Evellyn Feitosa, Felipe Nascimento, Lourdes Soncin, Luciana Batista, Renato Duarte, Sérgio Souza e Yve Abel Marcial. Capa, projeto visual e diagramação

Tecnodesign Versão

2.2.1

Este material didático foi elaborado com fins educacionais. Solicitamos que qualquer erro encontrado ou dúvida com relação ao material ou seu uso seja enviado para a equipe de elaboração de conteúdo da Escola Superior de Redes, no e-mail [email protected] A Rede Nacional de Ensino e Pesquisa e os autores não assumem qualquer responsabilidade por eventuais danos ou perdas, a pessoas ou bens, originados do uso deste material. As marcas registradas mencionadas neste material pertencem aos respectivos titulares. Distribuição

Escola Superior de Redes

Rua Lauro Müller, 116 – sala 1103 22290-906 Rio de Janeiro, RJ http://esr.rnp.br [email protected]

Dados Internacionais de Catalogação na Publicação (CIP) E42a Elias, Glêdson. Arquitetura e protocolo de rede TCP-IP / Glêdson Elias, Luiz Carlos Lobato. – 2. ed. – Rio de Janeiro: RNP/ESR, 2013. 414 p. : il. ; 28 cm.

Bibliografia: p. 393-395. ISBN 978-85-63630-18-6

Arquitetura e protocolo de rede TCP-IP / Glêdson Elias, Luiz Carlos Lobato. – 2. ed. – Rio de Janeiro: RNP/ESR, 2013.

CDD 004.6

Sumário 1. Conceitos básicos de redes Redes de computadores 1 Tipos de redes 2 Redes par-a-par 3 Redes cliente-servidor 4 Vantagens da rede cliente-servidor 5 Tipos de conexões 6 Conexão ponto-a-ponto 6 Conexão multiponto 7 Topologias de redes 7 Topologia Barramento 8 Topologia Anel 9 Topologia Estrela 10 Redes LAN, MAN e WAN 11 LAN 11 MAN 12 WAN 13 Meios de comunicação 15 Cabo metálico 15 Cabo coaxial 15 Cabo par trançado 17 Cabo fibra óptica 19 Cabeamento estruturado 22 Redes sem fio 24 Componentes da WLAN 24 Padrões WLAN IEEE 802.11 26 iii

Equipamentos de rede 27 Placas de rede 27 Exercício de fixação 1 – Identificando as informações da interface de rede 29 Concentradores 29 Switches 30 Roteadores 32 Roteiro de Atividades 1 35 Atividade 1.1 – Montagem de uma rede par-a-par 35 Atividade 1.2 – Conectando a rede ao switch do laboratório 37 Atividade 1.3 – Teste de conectividade do grupo com a internet 37 Atividade 1.4 – Análise da troca de pacotes na rede 38 Atividade 1.5 – Montagem de uma rede sem fio ponto-a-ponto 40

2. Arquitetura de protocolos Conceito de protocolo 45 Arquitetura em camadas 45 Conceito de camada 46 Conceito de interface 46 Modelo de Referência OSI 46 Histórico do modelo OSI 47 Objetivos de um sistema aberto 47 Estrutura em camadas 47 Camadas do modelo OSI 48 Camada física 49 Camada de enlace de dados 50 Camada de rede 51 Camada de transporte 52 Camada de sessão 53 Camada de apresentação 53 Camada de aplicação 54 Encapsulamento de dados 54 Comunicação par-a-par 55 Arquitetura TCP/IP 56 Histórico 56 Família de protocolos TCP/IP 59 Tecnologia de inter-redes 60

Camadas da arquitetura TCP/IP 62 Camada de aplicação 63 Camada de transporte 63 Camada de rede 64 Camada de interface de rede 64 Encapsulamento 64 Exercício de fixação 1 – Demonstração do processo de encapsulamento 66 Desencapsulamento 68 Interação dos protocolos 69 Endereços físicos e lógicos 71 Comparação das arquiteturas TCP/IP e OSI 72 Roteiro de Atividades 2 73 Atividade 2.1 – Captura de pacotes 73 Atividade 2.2 – Caminhos de rede 74 Atividade 2.3 – Estações multihomed 75 Atividade 2.4 – Modelo OSI 75

3. Endereçamento IP (parte 1) Endereço IPv4 77 Notação decimal 77 Atribuição de endereços 78 Hierarquia de endereçamento 78 Regras de atribuição de endereços 78 Classes de endereços 79 Endereços especiais 81 Exercício de fixação 1 – Classes de endereçamento 82 Espaço de endereçamento e endereços permitidos 83 Máscara de rede 83 Exercício de fixação 2 – Formatos de representação 84 Resolução de endereços 85 Técnicas de resolução de endereços 86 Protocolo ARP 86 Tabela ARP 87 Protocolos para configuração automática de endereços IP 88 Protocolo DHCP 89

Mecanismos de entrega 90 Entrega direta 90 Entrega indireta 90 Desperdício de endereços 92 Sub-redes 93 Arquiteturas de endereçamento 94 Diferenças entre arquiteturas 95 Endereçamento de sub-redes 95 Regras de atribuição de endereços 96 Endereços de sub-rede e broadcast direto 97 Máscara de sub-rede 98 Protocolo DHCP 99 Cálculo de máscara de sub-redes 101 Método BOX 102 Método binário 104 Método decimal 106 Exercício de fixação 3 – Verificando o endereço IP 107 Roteiro de Atividades 3 109 Atividade 3.1 – Validade de endereços 109 Atividade 3.2 – Atribuição de endereços 109 Atividade 3.3 – Expansão da rede 110 Atividade 3.4 – Configuração de endereços IPv4 111 Atividade 3.5 – Entrega direta e indireta 112 Atividade 3.6 – Protocolo ARP 113 Atividade 3.7 – Tabela ARP 114 Atividade 3.8 – Modificando a tabela ARP 115 Atividade 3.9 – Servidores DHCP 115

4. Endereçamento IP (parte 2) Super-redes 117 CIDR 119 Blocos de endereços 119 Hierarquia de endereçamento 120 Máscara do bloco 120 Endereço de bloco e de broadcast 121 Espaço de endereçamento e endereços permitidos 122

Regras de atribuição de endereços 123 Subdivisão de blocos 124 Agregação de blocos 126 Máscaras de tamanho fixo 127 Máscaras de tamanho variável 130 Algoritmo de atribuição de blocos 132 Exercício de fixação 1 – Máscara de tamanho variável 135 Contiguidade de sub-redes 135 Agregação de rotas 136 Endereços privados 137 Endereços públicos x privados 138 Endereços privados – motivação 138 Exemplo NAT 140 Tipos de NAT 142 NAT Estático 142 NAT Dinâmico 144 PAT 146 Endereços IPv6 152 Formato do endereço IPv6 153 Distribuição de endereços IPv6 153 Implantação do IPv6 154 Representação do endereço IPv6 154 Tipos de endereços IPv6 155 Transição de IPv4 para IPv6 155 Ausência de NAT no IPv6 156 Roteiro de Atividades 4 159 Atividade 4.1 – Configuração do exemplo 1 de VLSM 159 Atividade 4.2 – Estudo de caso 160 Atividade 4.3 – Configuração de NAT Estático e Dinâmico 161

5. Protocolos de enlace Fundamentos dos protocolos de enlace 167 Rede local virtual (VLAN) 167 Conceito de VLAN 168 Operação de VLAN em sub-redes IP 169 VLAN estática 172 VLAN dinâmica 172

vii

VLAN Tagging 173 IEEE 802.1Q 174 IEEE 802.1ad (QinQ) 175 GARP VLAN Registration Protocol (GVRP) 176 VLAN Trunking Protocol (VTP) 177 Configurando VLANs 178 Configuração de VLANs estáticas 178 Acessando e gerenciando o switch 181 Configurando trunking 181 Roteamento Inter-VLAN 182 Spanning Tree Protocol (STP) 185 Protocolo Spanning Tree 185 Loops na rede 185 Broadcast de camada 2 187 Conceitos chave em STP 188 Sequência de decisão de 5 passos 190 Convergência STP 190 Eleição da “root bridge” 191 Estados de porta – Spanning Tree 200 Temporizadores STP 200 Rapid Spanning Tree Protocol (RSTP) 201 RSTP versus STP 202 Estados de portas RSTP 202 Portas RSTP 202 Protocolo PPP 204 Camada de enlace da WAN 204 Point-to-Point Protocol (PPP) 205 Fases PPP 207 Configurando PPP Multilink (MLP) 211 Digital Subscriber Line (DSL) 212 Intervalo de frequência de DSL 212 Implementações de DSL 213 ADSL 214 Dados sobre ADSL com bridging 215 PPPoE 216 Roteiro de Atividades 5 219 Atividade 5.1 – Configuração de VLANs 219 Atividade 5.2 – Configuração do protocolo PPP 231 viii

6. Camada de rede Funcionalidades da camada de rede 239 Roteamento de redes 240 Protocolos da camada de rede 241 Protocolo IP 241 Campos do datagrama 242 Fragmentação e remontagem 245 Controle de fragmentação 246 Processo de remontagem 248 Processamento de datagramas 249 Protocolo ICMP 254 Comando ping 256 Comando traceroute 256 Exemplo de traceroute em Windows 258 Captura de pacotes do primeiro hop 259 Roteiro de Atividades 6 265 Atividade 6.1 – Campo TTL 265 Atividade 6.2 – Funcionamento do TTL 266 Atividade 6.3 – Remontagem no destino 269 Atividade 6.4 – Descobrindo a MTU 269 Atividade 6.5 – Descobrindo tamanhos de datagramas 269 Atividade 6.6 – Fragmentação 270

7. Roteamento Roteamento TCP/IP 271 Algoritmo de roteamento 272 Métricas de roteamento 273 Métrica da rota 274 Tabela de roteamento 274 Protocolo de roteamento 275 Representação de rotas 278 Rotas para estações 280 Rota padrão (default) 280 Rotas nulas 282 Listando tabelas de roteamento 283 Exercício de fixação 1 – Análise de tabela de rotas 284

Estratégias de roteamento 285 Roteamento estático 285 Roteamento dinâmico 286 Roteamento híbrido 287 Arquiteturas de roteamento 288 Arquitetura classful 288 Arquitetura classless 289 Protocolos de roteamento padrão 290 Protocolo RIP 291 Protocolo OSPF 292 Protocolo BGP 293 Roteiro de Atividades 7 295 Atividade 7.1 – Estratégia de roteamento 295 Atividade 7.2 – Estratégia de roteamento (2) 296 Atividade 7.3 – Rotas estáticas 296 Atividade 7.4 – Rotas RIP 300 Atividade 7.5 – Rotas OSPF 301

8. Camada de transporte Fundamentos da camada de transporte 303 Serviço de datagramas 304 Serviço de circuito virtual 304 Identificação de processos 305 Protocolos da camada de transporte 307 Protocolo UDP 307 Protocolo TCP 311 Mecanismos de controle 317 Exercício de fixação 1 – Abertura de conexão TCP 321 Exercício de fixação 2 – Envio de dados em conexão TCP 326 Exercício de fixação 3 – Fechamento de conexão TCP 330 Roteiro de Atividades 8 333 Atividade 8.1 – Portas TCP e UDP 333 Atividade 8.2 – Campo com tamanho do cabeçalho 333 Atividade 8.3 – Portas, conexões e endpoints 333

Atividade 8.4 – Portas UDP 333 Atividade 8.5 – Portas TCP 334

9. Camada de aplicação Fundamentos e protocolos da camada de aplicação 335 Modelo cliente-servidor 336 Identificação de clientes e servidores 337 Negociação de portas 338 Atribuição de portas 339 Interface socket 339 Estados de um socket 340 Tratamento de endpoints 341 Implementação 343 Clientes e servidores UDP 344 Clientes e servidores TCP 346 Servidores de aplicação 348 Servidor iterativo 348 Servidor concorrente 349 Compartilhamento de portas 350 Gerenciamento de conexões TCP 351 Multiplicidade de serviços 352 Roteiro de Atividades 9 355 Atividade 9.1 – Serviços e portas 355 Atividade 9.2 – Monitorando portas TCP 355 Atividade 9.3 – Portas TCP e UDP 356 Atividade 9.4 – Processamento de segmentos TCP 357 Atividade 9.5 – Servidores iterativos e concorrentes 357

10. Protocolos de aplicação Protocolos da camada de aplicação 359 DNS 360 Hierarquia de nomes 361 Delegação de autoridade 363 Autoridade Raiz 364 Consulta ao DNS 364

Servidor de nomes 365 Cliente (Resolver) 366 Servidor Bind 366 Servidor primário e secundário 366 Requisições iterativa e recursiva 367 Tipos de servidores 368 Tipos de respostas 369 Mecanismo de cache 369 Processamento de requisições 370 SMTP 372 Componentes 372 Protocolo SMTP 373 Modelo de interação 375 Estrutura da mensagem 377 HTTP 377 Protocolo HTTP 379 Tipos de conexões 379 Serviço de Acesso Remoto Seguro 382 Componentes 382 Modelo de interação 383 Roteiro de Atividades 10 387 Atividade 10.1 – Captura de pacotes UDP do serviço DNS 387 Atividade 10.2 – Requisições iterativas e recursivas 389 Atividade 10.3 – Servidores raiz 389 Atividade 10.4 – Consultas DNS 389 Atividade 10.5 – Serviço SSH 390

Bibliografia 393

xii

Escola Superior de Redes A Escola Superior de Redes (ESR) é a unidade da Rede Nacional de Ensino e Pesquisa (RNP) responsável pela disseminação do conhecimento em Tecnologias da Informação e Comunicação (TIC). A ESR nasce com a proposta de ser a formadora e disseminadora de competências em TIC para o corpo técnico-administrativo das universidades federais, escolas técnicas e unidades federais de pesquisa. Sua missão fundamental é realizar a capacitação técnica do corpo funcional das organizações usuárias da RNP, para o exercício de competências aplicáveis ao uso eficaz e eficiente das TIC. A ESR oferece dezenas de cursos distribuídos nas áreas temáticas: Administração e Projeto de Redes, Administração de Sistemas, Segurança, Mídias de Suporte à Colaboração Digital e Governança de TI. A ESR também participa de diversos projetos de interesse público, como a elaboração e execução de planos de capacitação para formação de multiplicadores para projetos educacionais como: formação no uso da conferência web para a Universidade Aberta do Brasil (UAB), formação do suporte técnico de laboratórios do Proinfo e criação de um conjunto de cartilhas sobre redes sem fio para o programa Um Computador por Aluno (UCA).

A metodologia da ESR A filosofia pedagógica e a metodologia que orientam os cursos da ESR são baseadas na aprendizagem como construção do conhecimento por meio da resolução de problemas típicos da realidade do profissional em formação. Os resultados obtidos nos cursos de natureza teórico-prática são otimizados, pois o instrutor, auxiliado pelo material didático, atua não apenas como expositor de conceitos e informações, mas principalmente como orientador do aluno na execução de atividades contextualizadas nas situações do cotidiano profissional. A aprendizagem é entendida como a resposta do aluno ao desafio de situações-problema semelhantes às encontradas na prática profissional, que são superadas por meio de análise, síntese, julgamento, pensamento crítico e construção de hipóteses para a resolução do problema, em abordagem orientada ao desenvolvimento de competências. Dessa forma, o instrutor tem participação ativa e dialógica como orientador do aluno para as atividades em laboratório. Até mesmo a apresentação da teoria no início da sessão de aprendizagem não é considerada uma simples exposição de conceitos e informações. O instrutor busca incentivar a participação dos alunos continuamente.

xiii

As sessões de aprendizagem onde se dão a apresentação dos conteúdos e a realização das atividades práticas têm formato presencial e essencialmente prático, utilizando técnicas de estudo dirigido individual, trabalho em equipe e práticas orientadas para o contexto de atuação do futuro especialista que se pretende formar. As sessões de aprendizagem desenvolvem-se em três etapas, com predominância de tempo para as atividades práticas, conforme descrição a seguir: Primeira etapa: apresentação da teoria e esclarecimento de dúvidas (de 60 a 90 minutos). O instrutor apresenta, de maneira sintética, os conceitos teóricos correspondentes ao tema da sessão de aprendizagem, com auxílio de slides em formato PowerPoint. O instrutor levanta questões sobre o conteúdo dos slides em vez de apenas apresentá-los, convidando a turma à reflexão e participação. Isso evita que as apresentações sejam monótonas e que o aluno se coloque em posição de passividade, o que reduziria a aprendizagem. Segunda etapa: atividades práticas de aprendizagem (de 120 a 150 minutos). Esta etapa é a essência dos cursos da ESR. A maioria das atividades dos cursos é assíncrona e realizada em duplas de alunos, que acompanham o ritmo do roteiro de atividades proposto no livro de apoio. Instrutor e monitor circulam entre as duplas para solucionar dúvidas e oferecer explicações complementares. Terceira etapa: discussão das atividades realizadas (30 minutos). O instrutor comenta cada atividade, apresentando uma das soluções possíveis para resolvê-la, devendo ater-se àquelas que geram maior dificuldade e polêmica. Os alunos são convidados a comentar as soluções encontradas e o instrutor retoma tópicos que tenham gerado dúvidas, estimulando a participação dos alunos. O instrutor sempre estimula os alunos a encontrarem soluções alternativas às sugeridas por ele e pelos colegas e, caso existam, a comentá-las.

Sobre o curso O curso fornece uma visão geral dos conceitos básicos de redes, noções de meios de comunicação, equipamentos de rede e redes sem fio. Aprofunda conceitos de NAT e VLANs, incluindo a configuração de VLANs através de atividades práticas. Oferece uma visão aprofundada da arquitetura de rede TCP/IP, sua pilha de protocolos e serviços oferecidos, abordando ainda: projeto de endereçamento IP; cálculo de máscaras de sub-redes e super-redes; VLSM e CIDR; roteamento estático e dinâmico; protocolos TCP e UDP; modelo cliente-servidor e interface socket; serviços DNS, Mail e Web. Ao final do curso, o aluno será capaz de projetar uma rede TCP/IP e de conectá-la à internet.

A quem se destina O público-alvo do curso é composto por profissionais de redes (segmento corporativo) e estudantes de informática (formandos em Ciência da Computação/ Informática), interessados em obter um maior domínio da arquitetura TCP/IP, condição fundamental para a formação de especialistas em gerência e segurança de redes de computadores.

xiv

Convenções utilizadas neste livro As seguintes convenções tipográficas são usadas neste livro: Itálico Indica nomes de arquivos e referências bibliográficas relacionadas ao longo do texto.

Largura constante Indica comandos e suas opções, variáveis e atributos, conteúdo de arquivos e resultado da saída de comandos.

Conteúdo de slide Indica o conteúdo dos slides referentes ao curso apresentados em sala de aula.

Símbolo Indica referência complementar disponível em site ou página na internet.

Símbolo Indica um documento como referência complementar.

Símbolo Indica um vídeo como referência complementar.

Símbolo Indica um arquivo de aúdio como referência complementar.

Símbolo Indica um aviso ou precaução a ser considerada.

Símbolo Indica questionamentos que estimulam a reflexão ou apresenta conteúdo de apoio ao entendimento do tema em questão.

Símbolo Indica notas e informações complementares como dicas, sugestões de leitura adicional ou mesmo uma observação.

Permissões de uso Todos os direitos reservados à RNP. Nada nesta licença prejudica ou restringe os direitos morais do autor. Agradecemos sempre citar esta fonte quando incluir parte deste livro em outra obra. Exemplo de citação: ELIAS; G.; LOBATO, L. C. Arquitetura e Protocolos de Rede TCP-IP. Rio de Janeiro: Escola Superior de Redes, RNP, 2013.

Comentários e perguntas Para enviar comentários e perguntas sobre esta publicação: Escola Superior de Redes RNP Endereço: Av. Lauro Müller 116 sala 1103 – Botafogo Rio de Janeiro – RJ – 22290-906 E-mail: [email protected]

Sobre os autores Glêdson Elias recebeu o título de Doutor em Ciência da Computação do Centro de Informática (Cin) da Universidade Federal de Pernambuco (UFPE), em junho de 2002. De 1993 até o presente, é professor adjunto no Departamento de Informática e Matemática Aplicada (DIMAp) da Universidade Federal do Rio Grande do Norte (UFRN). No período de 1993 a 1996, foi responsável (Coordenador Técnico dos Projetos: A Rede de Pesquisa da UFRN; Implantação do Ponto de Presença da RNP no Rio Grande do Norte; e Internet/RN – Integração da Comunidade Científica do Rio Grande do Norte) pela implantação da Internet no Estado do Rio Grande do Norte e na Universidade Federal do Rio Grande do Norte. Estas atividades estão inseridas no contexto do projeto da Rede Nacional de Pesquisa, que implantou a Internet no Brasil, do qual foi participante ativo, tendo atuado na sede do projeto em Campinas de 1991 a 1993. Em ensino, o Prof. Glêdson Elias leciona na graduação e pós-graduação em diferentes cursos, por exemplo: redes de computadores, redes de alta velocidade, gerência de redes, redes móveis e sem fio, arquitetura TCP/IP, roteamento TCP/ IP, middleware, e sistemas operacionais. Participa como pesquisador colaborador de projetos de pesquisa com outras instituições, a saber: InfraVida (UFPE) – desenvolvendo um sistema de videoconferência com aplicação em telemedicina; e I2TV/HiTV (UFPB) – desenvolvendo um middleware para televisão digital interativa. Atua no Grupo de Trabalho RNP de Vídeo Digital 2003/2004, na coordenação local da equipe de Natal. Luiz Carlos Lobato é formado em Engenharia Eletrônica pelo ITA, com pós-graduação em Negócios e Serviços de Telecomunicações pelo CEFET-RJ. Possui certificação de redes Cisco CCNA. Gerente da Divisão de Suporte Técnico da Telebrás até a privatização das Telecomunicações, sendo responsável pela operação e gerência da Rede de Dados do Sistema Telebrás. Após a privatização atuou como Coordenador de Cursos de Tecnologia de Redes (Graduação Superior) em diversas faculdades. É colaborador da Escola Superior de Redes desde 2008, tendo elaborado material de treinamento e lecionado diversos cursos na área de Redes. Atualmente é Coordenador Acadêmico de Administração e Projeto de Redes da ESR.

xvi

1 Apresentar os conhecimentos básicos para entender como as redes de computadores interagem, e como podem ser organizadas e interligadas para serem aproveitadas para prover os mais variados serviços.

conceitos

Introdução a redes de computadores, conceitos básicos e terminologia; interconexão de redes, equipamentos que a possibilitam, categorias e topologias de redes mais usuais e meios de comunicação utilizados na maioria das redes.

Redes de computadores Uma rede de computador é uma interconexão de estações de trabalho, periféricos,

terminais e outros dispositivos. Características de uma rede: 11 Dois ou mais computadores interligados. 11 Meio físico de comunicação (hardware e software). 11 Aplicativos para transferência de informação. Existem diversas definições para uma rede de computadores. Segundo William Stallings, “quando dois ou mais computadores estão interconectados via uma rede de comunicação, o conjunto das estações de computadores é chamado de rede de computadores”. Já a organização internacional de padronização ISO define uma rede de computadores na norma ISO/IEC 7498-1: “Um conjunto de um ou mais computadores, o software associado, periféricos, terminais, operadores humanos, processos físicos, meios de transferência de informação, entre outros componentes, formando um conjunto autônomo capaz de executar o processamento e a transferência de informações”. Todas as definições têm algumas características em comum, a saber: 11 Dois ou mais computadores interligados; 11 Meio físico de comunicação (com fio, sem fio, metálico, fibra etc); 11 Vários tipos de equipamentos (estações de usuários, servidores, concentradores etc); 11 Software para comunicação entre os equipamentos (protocolos); 11 Software de aplicação, para transferência de informação.

Capítulo 1 - Conceitos básicos de redes

objetivos

Conceitos básicos de redes

De maneira geral, podemos dizer que os componentes de uma rede são: 11 Estações de trabalho de usuários, que podem ser de vários tipos: desktops, laptops, dispositivos móveis em geral: celulares, tablets etc; 11 Meios de comunicação de qualquer tipo para interconexão dos equipamentos de rede; 11 Equipamentos de rede que compõem a infraestrutura da rede: hubs, switches, roteadores, etc. É importante ressaltar que a rede não é um fim em si mesmo, isto é, ninguém monta uma rede simplesmente para interligar equipamentos fisicamente, sem que haja algum tipo de transferência de informação. A motivação básica para a criação de redes é a transferência de informações entre os equipamentos que a compõem. A transferência de informações pode ser feita de várias maneiras, dependendo das necessidades dos usuários, das aplicações desenvolvidas, dos protocolos de redes e da infraestrutura física propriamente dita da rede. Em resumo, podemos conceituar uma rede como uma interconexão de estações de trabalho, periféricos, terminais e outros dispositivos.

Para que servem as redes? As redes fazem parte do nosso dia a dia, permitindo o acesso a partir de nossos celulares, tablets e notebooks, seja ela a rede da nossa organização ou os serviços da internet. Cabe à organização prover a infraestrutura de rede de acesso sobre a qual são disponibilizados os serviços e aplicações corporativas. As redes servem para:

11 Permitir aos usuários acesso remoto a serviços e aplicações como: correio eletrônico, internet banking e comércio eletrônico, para citar os mais comuns. 11 Permitir a comunicação entre os usários, como os serviços de voz sobre IP e videoconferência, entre tantos outros. 11 Compartilhar recursos especializados como impressoras, disco e processamento (exemplo: grids computacionais).

Tipos de redes Mesmo com essas semelhanças, as redes podem ser divididas em duas categorias

Arquitetura e Protocolos de Rede TCP-IP

mais amplas:

11 Redes par-a-par. 11 Redes cliente-servidor.

Figura 1.1 Redes par-a-par e cliente-servidor.

A distinção entre as redes par-a-par (peer-to-peer) e as redes cliente-servidor é importante, pois cada uma possui capacidades diferentes. O tipo de rede a ser implementada depende de características que incluem as relacionadas a seguir.

Redes par-a-par 11 Cada computador funciona como cliente e servidor.

11 Redes relativamente simples. 11 Nível de suporte administrativo disponível. 11 Sem hierarquia. 11 Sem servidores dedicados. 11 Todos os computadores podem ser cliente e servidor. 11 Construídas com os serviços do sistema operacional. 11 Mais simples e baratas do que as redes cliente-servidor. 11 Também chamadas de grupos de trabalho. 11 Tipicamente têm menos de 10 computadores. 11 Todos os usuários estão localizados na mesma área geral. 11 A segurança não é uma questão importante. 11 A empresa e a rede terão um crescimento limitado em um futuro previsível. Em uma rede par-a-par, não existem servidores dedicados ou hierarquia entre os computadores. Todos os computadores são iguais e, portanto, chamados pares. Normalmente, cada computador funciona tanto como cliente quanto como servidor, e nenhum deles é designado para ser um servidor para toda a rede. O usuário de qualquer computador determina os dados de seu computador que são compartilhados na rede. As redes par-a-par são relativamente simples. Uma vez que cada computador funciona como cliente e servidor, não há necessidade de um servidor central complexo ou de outros componentes para uma rede de grande capacidade. As redes par-a-par podem ser mais baratas do que as redes cliente-servidor.

Pelo termo subentende-se um pequeno grupo de pessoas. Uma rede par-a-par, tipicamente, tem pouco menos de 10 computadores.

As redes par-a-par também são chamadas de grupos de trabalho. Em uma rede par-a-par, o software de comunicação de rede não requer o mesmo nível de desempenho e segurança de um software de comunicação de rede projetado para servidores dedicados. Os servidores dedicados funcionam apenas como servidores e não são utilizados como um cliente ou uma estação de trabalho. Eles serão discutidos com mais detalhes posteriormente. Em sistemas operacionais como Microsoft Windows, desde a versão 2000, bem como nos sistemas Unix/Linux, as redes par-a-par são construídas dentro do sistema operacional, sem a exigência de nenhum outro software para configurar uma rede deste tipo. Em um ambiente par-a-par típico, várias questões de rede possuem soluções de implementação padronizadas, que incluem: 11 Computadores localizados nas mesas dos usuários; 11 Usuários que atuam como seus próprios administradores e planejam sua própria segurança; 11 Utilização de um sistema simples de cabeamento de fácil visualização, que conecta computador a computador na rede.

Capítulo 1 - Conceitos básicos de redes

Grupo de trabalho

As redes par-a-par são uma boa escolha para ambientes com as seguintes características: 11 Menos de 10 usuários; 11 Todos os usuários estão localizados na mesma área geral; 11 A segurança não é uma questão importante; 11 A empresa e a rede terão um crescimento limitado em um futuro previsível.

Requisitos do computador para rede par-a-par Em um ambiente par-a-par, cada computador deve:

11 Utilizar uma porcentagem significativa de seus recursos para suportar o usuário local (o usuário no computador). 11 Utilizar recursos adicionais para suportar cada usuário remoto (o usuário que está acessando o computador via a rede) que estiver acessando seus recursos. Em uma rede par-a-par, cada usuário administra seu próprio computador, uma vez que não existe servidor de rede e, portanto, também não há necessidade de administração centralizada, nem da figura do administrador de rede. Assim, cada usuário configura os recursos de seu computador que estarão disponíveis para os demais usuários da rede: discos, pastas, impressoras, entre outros, definindo se o acesso vai ser livre para todos ou mediante senha, e assim por diante. Então, parte dos recursos de seu computador será usada pelos demais membros da rede, e parte usada pelo próprio usuário. Essa proporção de utilização de recursos fica a critério de cada usuário. Usuários mais “conservadores” poderão liberar pouco ou nenhum recurso para a rede, enquanto usuários mais “liberais” poderão liberar mais recursos para a rede.

Redes cliente-servidor 11 Servidores dedicados.

11 Estações clientes não oferecem serviços à rede. 11 Usadas em ambientes com mais de 10 usuários. Podem ser necessários vários servidores: 11 Servidores de Arquivo e Impressão. 11 Servidores de Aplicações. 11 Servidores de Correio. 11 Servidores de Fax.

Arquitetura e Protocolos de Rede TCP-IP

11 Servidores de Comunicação. Em um ambiente com mais de 10 usuários, uma rede par-a-par, com os computadores operando como servidores e clientes, provavelmente não será adequada. Portanto, a maior parte das redes possui servidores dedicados. Um servidor dedicado é aquele que funciona apenas como servidor e não é utilizado como cliente ou estação de trabalho. Os servidores são “dedicados” porque são otimizados para processar rapidamente as requisições dos clientes da rede e para garantir a segurança dos arquivos e pastas. As redes baseadas em servidor tornaram-se o modelo padrão para a comunicação de rede e serão utilizadas como exemplos básicos. Conforme aumentam o tamanho e o tráfego das redes, mais de um servidor é necessário na rede. Como a diversidade de tarefas que os servidores devem desempenhar é variada 4

e complexa, a distribuição de tarefas entre vários servidores garante que cada tarefa seja desempenhada da maneira mais eficiente possível. Os servidores de grandes redes se tornaram especializados para acomodar as necessidades crescentes dos usuários. Em uma rede típica baseada em servidor, os diferentes tipos de servidores incluem os que serão analisados a seguir.

Servidores de arquivo e impressão Os servidores de arquivo e impressão gerenciam o acesso do usuário e a utilização dos recursos de arquivos e impressora. Por exemplo, se você estivesse executando um aplicativo de processamento de texto, o aplicativo seria executado no seu computador e o documento seria armazenado no servidor de arquivos e impressão, mas transferido e carregado na memória de seu computador para que você possa utilizá-lo localmente.

Servidores de aplicações Os servidores de aplicações executam as funções de servidor, disponibilizando dados para os clientes. Por exemplo, os servidores armazenam enorme quantidade de dados que estão estruturados para facilitar sua recuperação. Servidores de aplicações são diferentes de um servidor de arquivo e impressão, em que os dados ou o arquivo são carregados para o computador que fez a requisição. Com um servidor de aplicação, o banco de dados fica no servidor e apenas os resultados requeridos são carregados no computador que fez a requisição. Uma aplicação cliente executada localmente tem acesso aos dados no servidor de aplicação. Em vez de todo o banco de dados ser carregado do servidor para o seu computador local, apenas os resultados da sua consulta são carregados nele.

Servidores de correio Os servidores de correio gerenciam mensagens eletrônicas entre os usuários da rede.

Servidores de fax Os servidores de fax gerenciam o tráfego de fax para dentro e para fora da rede, compartilhando uma ou mais placas de fax modem.

Servidores de comunicação Os servidores de comunicação manipulam o fluxo de dados (por exemplo, arquivos, mensagens, programas, etc.) entre a própria rede do servidor e outras redes, computadores mainframe ou usuários remotos, através da utilização de modems e linhas telefônicas para

Vantagens da rede cliente-servidor 11 Compartilhamento de recursos. 11 Compartilhamento de dados. 11 Redundância. 11 Escalabilidade. 11 Computador cliente mais simples.

Capítulo 1 - Conceitos básicos de redes

discar para o servidor.

Vantagens da rede cliente-servidor: 11 Compartilhamento de recursos – um servidor é projetado para fornecer acesso a muitos arquivos e impressoras, ao mesmo tempo em que mantém o desempenho e a segurança para o usuário. 11 Compartilhamento de dados – o compartilhamento de dados baseado em servidor pode ser administrado e controlado de forma centralizada. Em geral, os recursos são centralizados e mais fáceis de localizar e suportar do que os recursos distribuídos em diversos computadores. 11 Redundância – através de sistemas de redundância, os dados em qualquer servidor podem ser duplicados e mantidos on-line para que, mesmo se algo acontecer aos dados na área de armazenamento de dados principal, uma cópia de backup dos dados possa ser usada para recuperá-los. 11 Escalabilidade – uma rede baseada em servidor pode dar suporte a milhares de usuários, pois os utilitários de monitoração e gerenciamento de rede possibilitam a operação da rede para um grande número de usuários. Este tipo de rede jamais poderia ser gerenciada como uma rede par-a-par. 11 Computador cliente mais simples – o hardware do computador cliente pode ser limitado às necessidades do usuário, pois os clientes não precisam de RAM adicional e armazenamento em disco para fornecer serviços do servidor.

Tipos de conexões

11 Conexão ponto-a-ponto. 11 Conexão multiponto.

Existem dois tipos básicos de conexão entre redes: ponto-a-ponto e multiponto; da combinação destas duas surgem as demais topologias que serão aqui abordadas.

Conexão ponto-a-ponto

11 Conexão entre dois pontos. 11 Enlace dedicado. 11 Sem escalabilidade.

Este é o tipo mais simples de ligação entre redes, em que os equipamentos são conectados entre si por uma única linha de comunicação. Quando algum deles tiver algo a transmitir, a

Arquitetura e Protocolos de Rede TCP-IP

linha estará disponível.

Esse tipo de conexão não é adequado para maior quantidade de equipamentos, como podemos ver na próxima figura, que reproduz as conexões ponto-a-ponto para 4 equipamentos.

Figura 1.2 Exemplo de conexão ponto-a-ponto.

Figura 1.3 Exemplo de múltiplas conexões ponto-a-ponto.

Observe que são necessárias 6 linhas para interligar todos os equipamentos entre si. O cálculo para “n” estações é feito através da fórmula: número de conexões = n(n-1)/2. No nosso exemplo, o número de conexões = 4(4-1)/2 = 6. Imagine agora o caso de uma centena ou mais de equipamentos interligados dessa forma; é o mesmo problema que os projetistas de redes telefônicas tiveram que resolver. Essa solução não tem escalabilidade. A solução adotada pelos projetistas de redes telefônicas foi uma das topologias clássicas que serão abordadas adiante neste curso. Antes disso, vamos apresentar outro tipo de conexão que não apresenta problemas de escalabilidade.

Conexão multiponto

11 Muitos pontos ligados ao mesmo meio físico. 11 Mensagens propagadas por difusão. 11 Escalabilidade. Este tipo de conexão permite que todas as estações se comuniquem entre si diretamente, e não apresenta os problemas de escalabilidade da conexão ponto-a-ponto. Existe apenas um único meio de comunicação interligando todas as estações, através de muitos pontos

de conexão, um para cada estação; daí o nome de multiponto. A principal característica de conexões multiponto é permitir a conexão de uma grande quantidade de estações.

Ponto de

Meio físico

Figura 1.4 Conexão multiponto.

As topologias clássicas e suas derivadas são tipos especiais de redes que usam as características dos dois tipos básicos (ponto-a-ponto e multiponto).

Topologias de redes 11 Barramento. 11 Anel. 11 Estrela.

Capítulo 1 - Conceitos básicos de redes

conexão

A topologia é a forma de ligação dos equipamentos em uma rede. A topologia se refere ao nível físico e ao meio de conexão entre os dispositivos, sendo dependente do projeto de suas funções, da confiabilidade e do seu custo de manutenção. Ao se planejar uma rede, muitos fatores devem ser considerados. Um dos fatores mais importantes é o tipo de participação dos nós. Um nó pode ser fornecedor ou usuário de recursos, ou uma mescla de ambos os tipos.

Topologia Barramento 11 Conexões multiponto.

11 Mensagens propagadas por difusão. 11 Controle de acesso ao meio centralizado ou descentralizado. 11 Escalabilidade. 11 Limitada fisicamente pelo tamanho do barramento. 11 Boa tolerância a falhas. Neste tipo de topologia todos os nós (estações) se ligam ao mesmo meio de transmissão. A barra é geralmente compartilhada em tempo e frequência, permitindo a transmissão de informações. O tráfego das informações é bidirecional e cada nó conectado à barra pode escutar todas as informações transmitidas. Esta característica facilita as aplicações que requerem a propagação das mensagens por difusão.

Figura 1.5 Topologia Barramento.

Observe que essa topologia é uma simples aplicação do tipo básico multiponto, normalmente usada com cabeamento coaxial, que requer o uso de terminadores nas extremidades do barramento para casar a impedância e evitar a reflexão do sinal elétrico. O barramento pode ser um simples segmento de rede interligando as estações dos usuários ou um backbone

Backbone

que interliga diversos segmentos de rede.

A interconexão central de uma rede pode ser entendida como uma espinha dorsal de conexões que interliga pontos distribuídos da rede, formando uma grande via de tráfego de informações.

Existe uma variedade de mecanismos para o controle de acesso ao barramento, que podem ser centralizados ou descentralizados. A técnica adotada para acesso à rede é a multiplexação no tempo. No controle centralizado, o direito de acesso é determinado por uma estação especial da rede. Em um ambiente de controle descentralizado, a responsabilidade de

Arquitetura e Protocolos de Rede TCP-IP

acesso é distribuída entre todos os nós.

Nas topologias em barramento, as falhas nas estações não causam a parada total do sistema, que no entanto pode ser causada por falhas no barramento. O desempenho de um sistema em barramento é determinado pelo meio de transmissão, número de nós conectados, controle de acesso e tipo de tráfego, entre outros fatores. O tempo de resposta pode ser altamente dependente do protocolo de acesso utilizado.

Topologia Anel 11 Conexões ponto-a-ponto.

11 Mensagens propagadas de uma estação para outra. 11 Controle de acesso ao meio determinístico. 11 Pouca tolerância a falhas. Uma rede em anel consiste de estações conectadas através de um caminho fechado. Nesta configuração, redes em anel são capazes de transmitir e receber dados em qualquer direção, mas as configurações mais usuais são unidirecionais, de forma a tornar menos sofisticados os protocolos de comunicação que asseguram a entrega da mensagem ao destino corretamente e em sequência. Observe que esta topologia nada mais é do que uma sucessão de conexões ponto-a-ponto entre as estações, de maneira a formar um anel.

Figura 1.6 Topologia Anel.

Quando uma mensagem é enviada por um nó, ela entra no anel e circula até ser retirada pelo nó destino, ou então até voltar ao nó fonte, dependendo do protocolo empregado. O último procedimento é mais desejável porque permite o envio simultâneo de um pacote para múltiplas estações. Outra vantagem é permitir que determinadas estações possam receber pacotes enviados por qualquer outra estação da rede, independentemente de qual seja o nó destino. Os maiores problemas desta topologia são relativos à sua baixa tolerância a falhas. Qualquer controle de acesso empregado pode ser perdido por problemas de falha, podendo ser difícil determinar com certeza se este controle foi perdido ou decidir o nó que deve recriá-lo. Erros de transmissão e processamento podem fazer com que uma mensagem continue eternamente a circular no anel. A utilização de uma estação de monitoramento contorna teste e diagnóstico e outras tarefas de manutenção. A estação monitora pode ser dedicada ou outra qualquer que assuma essas funções em algum momento. Esta configuração requer que cada nó seja capaz de remover seletivamente mensagens da rede ou passá-las adiante para o próximo nó. Nas redes unidirecionais, se uma linha entre dois nós cair, todo o sistema sairá do ar até que o problema seja resolvido. Se a rede for bidirecional, nenhum nó ficará inacessível, já que poderá ser atingido pelo outro lado.

Capítulo 1 - Conceitos básicos de redes

estes problemas. Outras funções desta estação seriam: iniciar o anel, enviar pacotes de

Topologia Estrela 11 Conexões ponto-a-ponto.

11 Mensagens propagadas através do nó central. 11 Controle de acesso ao meio centralizado ou descentralizado. 11 Boa tolerância a falhas. 11 O nó central é chamado de “barramento colapsado”. Neste tipo de rede, todos os usuários comunicam-se com um nó central, por onde são transmitidas todas as mensagens. Através do nó central, os usuários podem transmitir mensagens entre si. O nó central funciona como um comutador de mensagens para transmissão dos dados entre eles. Observe que essa topologia é também uma combinação de conexões ponto-a-ponto, só que todas as conexões convergem para o nó central.

Figura 1.7 Topologia Estrela.

O arranjo em estrela é a melhor escolha se o padrão de comunicação da rede for de um conjunto de estações secundárias que se comunicam com o nó central. As situações onde isto é mais comum são aquelas em que o nó central está restrito às funções de comutação de mensagens. O nó central pode realizar outras funções além da comutação e processamento das mensagens. Por exemplo, pode compatibilizar a velocidade de comunicação entre o transmissor e o receptor. Se os dispositivos fonte e destino utilizarem diferentes protocolos, o nó central pode atuar como um conversor, permitindo a comunicação entre duas redes de fabricantes diferentes.

Arquitetura e Protocolos de Rede TCP-IP

No caso de ocorrer falha em uma estação ou no elo de ligação com o nó central, apenas esta estação ficará fora de operação. Entretanto, se uma falha ocorrer no nó central, todo o sistema poderá ficar fora do ar. A solução deste problema seria a redundância do nó central, mas isto acarretaria um aumento considerável dos custos. A expansão de uma rede deste tipo só pode ser feita até certo limite, imposto pelo nó central: em termos de capacidade de comutação, número de circuitos concorrentes que podem ser gerenciados e número de nós que podem ser servidos. O desempenho de uma rede em estrela depende da quantidade de tempo requerido pelo nó central para processar e encaminhar mensagens, e da carga de tráfego de mensagens, ou seja, o desempenho é limitado pela capacidade de processamento do nó central. A maioria dos sistemas de computação com funções de comunicação possui um software que implementa esta configuração que facilita o controle da rede. 10

Comparação entre topologias O quadro seguinte resume os pontos positivos e negativos de cada topologia descrita até aqui. Tipos de topologia

Pontos positivos

Pontos negativos

Topologia Estrela

11Mais tolerante a falhas.

11Custo de instalação maior porque usa mais cabos.

11Facilidade para instalar usuários. 11Monitoramento centralizado.

Topologia Anel (Token Ring)

Figura 1.8 Comparação entre topologias de rede.

Topologia Barramento

11Razoavelmente fácil de instalar. 11Requer menos cabos.

11Se uma estação para, todas param.

11Desempenho uniforme.

11Os problemas são difíceis de isolar.

11Simples e fácil de instalar.

11A rede fica mais lenta em períodos de uso intenso.

11Requer menos cabos. 11Fácil de entender.

11Os problemas são difíceis de isolar.

Redes LAN, MAN e WAN Uma rede de comunicação pode ser classificada segundo um ou mais critérios. Podemos

classificar as redes de acordo com: 11 Topologia (barramento, anel, estrela, híbrida). 11 Meio físico (cobre, fibra óptica, micro-ondas, infravermelho). 11 Tecnologia de suporte (comutação de pacotes, comutação de circuitos, assíncronas, plesiócronas, síncronas etc). 11 Segundo o ambiente ao qual se destinam (redes de escritório, redes industriais, redes militares, redes de sensores etc). No entanto, a classificação mais comum baseia-se na área geográfica ou organizacional e aí entram os termos que normalmente ouvimos: LAN, MAN, WAN, PAN etc. Vamos apresentar as definições mais comuns.

LAN 11 Cabeamento em distâncias de até 10 km.

11 Alta taxa de transmissão (Mbps, Gbps). 11 Baixa taxa de erros. 11 Baixo custo de cabeamento. 11 Propriedade privada. 11 Topologia básica (barramento, anel, estrela). Redes LAN (Local Area Networks) também são designadas como redes locais. Tipo de rede mais comum, uma vez que permite interligar computadores, servidores e outros equipamentos de rede em uma área geográfica limitada, como uma sala de aula, residência, escritório etc.

Capítulo 1 - Conceitos básicos de redes

Topologia híbrida Combinação de duas ou mais topologias de qualquer tipo.

Corporate ﬁrewall

Internet

Características: 11 Cabeamento em distâncias de até 10 km, dependendo do tipo de cabo usado (par metálico, fibra óptica, sem fio etc); 11 Alta taxa de transmissão (Mbps, Gbps), em função das curtas distâncias e do tipo de cabeamento que permite taxas elevadas de transmissão; 11 Baixa taxa de erros, uma consequência das curtas distâncias e da qualidade do cabeamento; 11 Baixo custo de cabeamento, em função das distâncias envolvidas, uma vez que o custo do cabeamento é diretamente proporcional à distância; 11 Propriedade privada, devido à facilidade de cabear pequenas distâncias, usualmente

Arquitetura e Protocolos de Rede TCP-IP

dentro das instalações de uma empresa ou de uma residência;

11 Topologia básica (barramento, anel ou estrela).

MAN 11 Cabeamento em distâncias de até 100 km. 11 Alta taxa de transmissão (Mbps, Gbps). 11 Baixa taxa de erros. 11 Custo de cabeamento médio. 11 Propriedade privada ou pública. 11 Topologia em anel.

Figura 1.9 Redes LAN.

Redes MAN (Metropolitan Area Networks) são redes de comunicação que cobrem uma área do tamanho de uma cidade ou bairro. Permitem a interligação de redes e equipamentos numa área metropolitana, como em locais situados em diversos pontos de uma cidade. LAN

LAN

Metropolitan Area Network

NPE

MAN

LAN

NPE

Figura 1.10 Redes MAN.

NPE

Características: 11 Cabeamento em distâncias de até 100 km, para cobrir um bairro, uma cidade pequena ou um campus universitário; 11 Alta velocidade de transmissão (Mbps, Gbps), como no caso das LANs; 11 Baixa taxa de erros, como também ocorre com as LANS; 11 Custo de cabeamento médio, uma vez que as distâncias envolvidas são maiores do que numa rede local; 11 Propriedade privada ou pública, dependendo de quem construiu a rede; numa rede local sempre é a própria empresa, mas em uma rede MAN pode ser um serviço oferecido por terceiros, em função dos custos de infraestrutura; 11 Topologia em anel, mais econômica para as distâncias metropolitanas. As redes MANs atuais estão usando a tecnologia Ethernet de LANs, porque as fibras ópticas permitem alcançar distâncias maiores com alta taxa de transmissão (dezenas de Gbps) a um custo inferior ao das redes WANs nas mesmas condições. Essas redes são chamadas redes Metro Ethernet.

alcançando distâncias cada vez maiores, fazendo com que a simples classificação em função da distância fique rapidamente ultrapassada. Para diferenciar as redes entre si, a tecnologia utilizada é mais importante do que a distância entre os enlaces.

WAN 11 Cabeamento de longas distâncias (sem limite). 11 Baixa a alta taxa de transmissão (Kbps, Mbps, Gbps). 11 Taxa de erros maior do que nas LANs. 11 Alto custo de cabeamento. 11 Propriedade pública.

Capítulo 1 - Conceitos básicos de redes

Graças à facilidade de instalação de fibras ópticas e ao seu baixo custo, as redes estão

Redes WAN (Wide Area Netwoks) permitem a interligação de redes locais, metropolitanas e equipamentos de rede, em uma grande área geográfica, como um país ou continente.

Figura 1.11 Redes WAN.

Características: 11 Cabeamento de longas distâncias (sem limite), devido à maior abrangência geográfica; 11 Taxa de transmissão pode ser de baixa a alta (Kbps, Mbps, Gbps), em função dos diferentes tipos de meios físicos adotados e das distâncias envolvidas; 11 Taxa de erros superior a das LANs, em função do tipo de meio físico adotado e das distâncias envolvidas; 11 Alto custo de cabeamento, por causa da abrangência geográfica; 11 Propriedade pública, devido ao alto custo dos investimentos em infraestrutura. As redes WAN projetadas para o serviço de dados têm velocidades muito altas, da ordem de Gigabits por segundo (Gbps), graças às facilidades de instalação de fibras ópticas e à

Arquitetura e Protocolos de Rede TCP-IP

redução do custo dos equipamentos de grande capacidade de transmissão. Tais redes se

justificam pela velocidade de transferência de dados e pela possibilidade de compartilhamento dos enlaces de alta velocidade entre muitos usuários. Desta forma, é possível encontrar WANs com velocidades muito altas (da ordem de dezenas de Gbps), superando as velocidades usuais de LANs (Mbps, Gbps). Normalmente essas WANs de velocidade muito alta são usadas nos backbones das operadoras de telecomunicações que prestam serviços de dados para o público em geral, normalmente usando a arquitetura TCP/IP.

w Consulte a versão atual do mapa em http://www.rnp.br/ backbone/

Meios de comunicação Cabo metálico:

11 Cabo coaxial. 11 Cabo par trançado. Cabo fibra óptica. Cabeamento estruturado. Redes sem fio. O projeto de cabeamento de uma rede, que faz parte do meio físico usado para interligar computadores, é um fator de extrema importância para o bom desempenho de uma rede. Esse projeto envolve aspectos sobre a taxa de transmissão, largura de banda, facilidade de instalação, imunidade a ruídos, confiabilidade, custos de interfaces, exigências geográficas, conformidade com padrões internacionais e disponibilidade de componentes.

Cabo metálico Cabo coaxial:

11 Cabo fino 10Base2 com conector BNC. 11 Cabo grosso 10Base5. 11 Obsoleto – substituído pelo par trançado e fibra óptica. Cabo par trançado: 11 Quatro pares trançados dois a dois. 11 Conector RJ-45 (8 fios). 11 Velocidades de 10 Mbps até 10 Gbps. 11 Facilidade de manutenção. Nessa categoria encontram-se atualmente dois tipos de cabos: coaxial e par trançado, sendo que o coaxial está praticamente fora de uso para redes locais, mas ainda é muito utilizado nas instalações de TV a cabo.

Cabo coaxial 11 Velocidade de 10 Mbps.

11 Distância máxima do segmento: 185m ou 500m.

Os cabos coaxiais permitem que os dados sejam transmitidos através de uma distância maior que a permitida pelos cabos de par trançado sem blindagem (UTP), embora sejam mais caros e menos flexíveis que estes. O cabo coaxial foi o primeiro cabo disponível no mercado. Até alguns anos atrás era o meio de transmissão mais moderno que existia em termos de transporte de dados. Em redes locais são usados dois tipos de cabos coaxiais: 10Base5 e 10Base2. Os cabos 10Base2, também chamados de cabos coaxiais finos (ou cabos Thinnet) são os cabos coaxiais usados em redes Ethernet para a conexão de estações dos usuários. Seu diâmetro é de apenas 0.18 polegadas, cerca de 4.7 milímetros, o que os torna razoavelmente flexíveis. Segundo a norma IEEE802.3 de redes Ethernet, o comprimento máximo do cabo coaxial fino

Capítulo 1 - Conceitos básicos de redes

11 Obsoleto, devido à dificuldade de manutenção.

é de 185m e as estações a ele conectadas constituem um “segmento Ethernet”. Podem ser necessários vários segmentos para conectar todas as estações de uma rede local, dependendo da quantidade de estações e das distâncias envolvidas. Os cabos 10Base5, também chamados de cabos coaxiais grossos (ou cabos Thicknet), possuem cerca de 0,4 polegadas ou quase 1 centímetro de diâmetro, e por isso são caros e difíceis de instalar, devido à baixa flexibilidade. Também podem ser usados vários segmentos para conectar todas as estações de uma rede local, dependendo da quantidade de estações e das distâncias envolvidas. É possível conectar segmentos 10Base2 e 10Base5, desde que atendendo à regra 5-4-3, alcançando distâncias entre 925m e 2500m. A regra 5-4-3 diz que uma rede Ethernet com cabo coaxial fino pode conter 5 segmentos unidos por 4 repetidores, mas somente 3 desses segmentos podem ser povoados por estações. Os outros dois segmentos restantes são usados como ligações entre repetidores. Repetidores podem ser usados para interligar segmentos Ethernet e estender a rede para um comprimento total de 925 metros até 2500 metros. A Figura 1.12 exemplifica essa regra.

Trunk segment 1 Repeater 1 Trunk segment 2 Trunk segment 3 Repeater 2

Repeater 3

Trunk segment 4 Repeater 4 Trunk segment 5

Figura 1.12 Regra 5-4-3.

Os cabos coaxiais são constituídos de 4 camadas: 11 Um condutor interno, o fio de cobre que transmite os dados; 11 Uma camada isolante de plástico, chamada de dielétrico, que envolve o cabo interno; 11 Uma malha de metal que protege as duas camadas internas e conduz o aterramento elétrico;

Arquitetura e Protocolos de Rede TCP-IP

11 Uma nova camada de revestimento, chamada de jaqueta, conforme mostra a figura a seguir.

Jaqueta

Malha de metal

Isolamento interno (dielétrico)

Fio de cobre

Para conectar as estações dos usuários ao cabo coaxial fino são usados conectores do tipo BNC, mostrados na figura a seguir. O “T” BNC é usado para conectar as estações ao cabo coaxial. O terminador é usado nas duas pontas do segmento do cabo coaxial para casamento de impedância e para eliminar a reflexão do sinal elétrico.

Figura 1.13 Estrutura do cabo coaxial.

Conector T

Figura 1.14 Conectores “T” BNC.

Terminador

Conector BNC

O número 10 na sigla 10Base2 significa que os cabos podem transmitir dados a uma velocidade de 10 Mbps; “Base” significa “banda base” e se refere ao tipo de transmissão digital com uma única frequência portadora, na qual somente uma estação transmite de cada vez, e o número 2, que teoricamente significaria 200 metros, na prática é apenas um arredondamento, pois nos cabos 10Base2 a distância máxima utilizável é de 185 metros. O mesmo vale para o cabo 10Base5, com a diferença de que a distância máxima é de 500 metros.

Cabo par trançado 11 Velocidade de 10 Mbps/10 Gbps.

11 Topologia física estrela. 11 Topologia lógica barramento. 11 Exige concentrador. 11 Facilidade de manutenção. Os cabos par trançado são os mais usados, pois têm um melhor custo benefício. Podem ser comprados em lojas de informática, feitos sob medida ou ainda produzidos pelo próprio usuário, e ainda têm velocidade 10 vezes maior do que os cabos coaxiais, no mínimo. O cabo par trançado surgiu da necessidade de se ter cabos mais flexíveis e com maior velocidade de transmissão. Ele vem substituindo os cabos coaxiais desde o início da década de 90. Hoje em dia é rara a utilização de cabos coaxiais em novas instalações de rede, apesar do custo adicional decorrente da utilização de hubs ou switches. O custo do cabo é mais baixo e a instalação é mais simples. O nome “par trançado” não é exatamente a tradução do termo original (que seria “par torcido”, do inglês “twisted pair”). Os cabos coaxiais usam uma malha de metal que protege o cabo de dados contra interferências externas; os cabos de par trançado, por sua vez, usam um tipo de proteção mais sutil: o entrelaçamento dos cabos cria um campo eletromagnético que oferece uma razoável proteção contra interferências externas. Estes cabos são constitu-

Figura 1.15 Cabo par trançado.

As chamadas “categorias” em sistemas de cabeamento em par trançado seguem padrões determinados e normatizados pela ANSI/EIA (American National Standards Institute/ Electronic Industries Alliance), que define diversas categorias (tipos de cabo, velocidades, junções, conectores etc) e seus usos. A tabela a seguir resume as categorias de cabos do tipo par trançado mais usadas e suas características.

Capítulo 1 - Conceitos básicos de redes

ídos justamente por 4 pares de cabos torcidos par-a-par, conforme mostra a figura a seguir.

Categoria

Taxa máxima de transmissão

Aplicação usual

CAT 1

Até 1 Mbps (1 MHz)

Voz Analógico (POTS) ISDN (Integrated Services Digital Network) Basic Rate Interface Fiação tipo fio de telefone

CAT 2

4 Mbps

Utilizado em sistemas de cabeamento IBM Token Ring

CAT 3

10 / 16 Mbps

Voz e dados em rede 10BASE-T Ethernet

CAT 4

16 / 20 Mbps

Usado em redes Token Ring de 16 Mbps

CAT 5

100 Mbps 1 Gbps (4 pares)

100 Mbps TPDDI 155 Mbps ATM Não é mais utilizado, substituído pelo CAT 5E

CAT 5E

1 Gbps (10 Gbps – protótipo)

100 Mbps TPDDI 155 Mbps ATM Gigabit Ethernet

CAT 6

Até 400 MHz

Aplicações de banda larga “super-rápidas”

CAT 6A

Até 625 MHz (testado em campo até 500 MHz)

Suporta completamente 10 Gigabit Ethernet (10GBASE-T)

CAT 7

600-700 MHz 1.2 GHz em pares com conector Siemon

Vídeo em Full-motion Telerradiologia Redes especializadas de governo Redes especializadas de manufatura Redes especializadas de ensino Sistema blindado

Observações sobre a tabela:

Figura 1.16 Categorias de cabos par trançado.

11 As categorias 3 e 5 ainda são grande maioria das instalações existentes. 11 Com a queda nos preços de equipamentos que suportam Gigabit Ethernet, os padrões CAT6 e CAT6A têm sido os preferidos para novas instalações, pois já oferecem suporte aos padrões Gigabit e 10 Gigabit Ethernet. A utilização do cabo par trançado tem suas vantagens e desvantagens. Veremos em seguida as principais.

Vantagens 11 Preço – mesmo com a obrigação da utilização de outros equipamentos na rede, a

relação custo benefício é melhor. 11 Flexibilidade – como é bastante flexível, ele pode ser facilmente passado por dentro Arquitetura e Protocolos de Rede TCP-IP

de conduítes embutidos em paredes. 11 Facilidade de manutenção – cada estação é conectada ao concentrador com seu próprio cabo, de forma independente das demais estações. 11 Velocidade – atualmente esse cabo trabalha com taxas de transferência de 10 Mbps (categoria 3), 100 Mbps (categorias 5 e 5E), 1 Gbps (categorias 5 e 6) e de 10 Gbps (categorias 6 e 6A).

Desvantagens 11 Comprimento – sua principal desvantagem é o limite de comprimento do cabo, de aproximadamente 100m entre a estação e o concentrador. 11 Interferência – baixa imunidade à interferência eletromagnética, fator preocupante em ambientes industriais.

A montagem do cabo par trançado é relativamente simples. Além do cabo, você precisará de um conector RJ-45 de pressão para cada extremidade do cabo e de um alicate de pressão para conectores RJ-45, também chamado de alicate crimpador. Assim como ocorre com o cabo coaxial, fica difícil passar o cabo por conduítes e por estruturas usadas para ocultar o cabo, depois que os conectores RJ-45 estão instalados. Por isso, o cabo deve ser passado antes da instalação dos conectores, sendo cortado no comprimento desejado. Lembre-se de deixar uma folga de alguns centímetros, já que o micro poderá posteriormente precisar mudar de lugar. Além disso, você poderá errar na hora de instalar o conector RJ-45, fazendo com que seja preciso cortar alguns poucos centímetros do cabo para instalar novamente outro conector. Para a utilização de alguns poucos cabos, vale a pena comprá-los prontos. Já para quem vai precisar de muitos cabos, ou para quem vai trabalhar com instalação e manutenção de redes, é mais vantajoso ter os recursos necessários para construir os cabos. Devem ser comprados os conectores RJ-45, rolos de cabo, um alicate para fixação do conector e um testador de cabos. Vale a pena destacar que a montagem manual de uma rede de par trançado é viável em ambiente de uma LAN pequena ou rede doméstica. Em redes corporativas, é necessário utilizar ferramentas e equipamentos especiais de infraestrutura física, como será visto adiante quando tratarmos de cabeamento estruturado.

Cabo fibra óptica

11 Velocidade 1 Gbps/10 Gbps/ 40 Gbps/100 Gbps. 11 Conexões ponto-a-ponto. 11 Redes LAN e MAN Ethernet. 11 Imune a ruído eletromagnético. Ao contrário dos cabos coaxiais e de par trançado, que nada mais são do que fios de cobre

que transportam sinais elétricos, a fibra óptica transmite luz e por isso é totalmente imune a qualquer tipo de interferência eletromagnética. Além disso, como os cabos são feitos de plástico e fibra de vidro (ao invés de metal), são resistentes à corrosão. O cabo de fibra óptica é formado por um núcleo extremamente fino de vidro, ou mesmo de um tipo especial de plástico. Uma nova cobertura de fibra de vidro, bem mais grossa, envolve e protege o núcleo. Em seguida há uma camada de plástico protetora chamada de cladding, uma nova camada de isolamento e finalmente uma capa externa chamada bainha,

Figura 1.17 Estrutura do cabo de fibra óptica.

Bainha

Isolamento

Cladding

Cobertura de ﬁbra

Núcleo

A transmissão de dados por fibra óptica é realizada pelo envio de um sinal de luz codificado, dentro do domínio de frequência do espectro visível. As fontes de transmissão de luz podem ser diodos emissores de luz (LED) ou lasers semicondutores. O cabo óptico com transmissão de raio laser é o mais eficiente em potência, devido à sua espessura reduzida. Já os cabos com diodos emissores de luz são muito baratos, além de mais adaptáveis à temperatura ambiente e de terem um ciclo de vida maior que o do laser. O princípio de propagação da luz

Capítulo 1 - Conceitos básicos de redes

conforme mostra a figura a seguir.

em fibras ópticas está demonstrado na figura a seguir. 19

O Princípio de Propagação em Fibras Ópticas Revestimento primário Casca Núcleo Revestimento Casca Núcleo primário O raio de luz com ângulo menor que o crítico é absorvido pela casca

Ângulo de

incidência

reﬂexão

A luz é propagada pela reﬂexão interna total

Figura 1.18 Princípio de progação da luz em fibras ópticas.

Existem dois tipos de fibra óptica: monomodo e multimodo. A primeira é usada principalmente em telecomunicações, devido às grandes distâncias que consegue alcançar. A segunda é usada em redes locais sem requisitos severos de distância, e são mais baratas do que as monomodo. A diferença entre elas está no modo de propagação da luz, conforme mostrado nas figuras a seguir.

Casca Eixo Núcleo Casca

Núcleo Fibra Monomodo

Casca

Figura 1.19 Fibra óptica monomodo.

Núcleo - entre 8 à 9 microns Casca - 125 microns

Casca Eixo Núcleo Casca

Núcleo Raio refratado

Fibra Gradual Multimodo

Casca

Núcleo - 50 ou 62,5 microns Casca - 125 microns

Apesar de alcançar distâncias muito maiores do que os cabos metálicos, a fibra óptica também sofre do fenômeno de atenuação do sinal luminoso, por causa da absorção de luz pela casca e imperfeições do material (sílica). Algumas frequências de luz sofrem mais atenuação do que outras. A figura a seguir mostra os comprimentos de onda mais usados e

Arquitetura e Protocolos de Rede TCP-IP

as atenuações máximas permitidas pela recomendação.

Figura 1.20 Fibra óptica multimodo

Primeira Janela

Segunda Janela

Terceira Janela

Atenuação (dB/km)

6 5 4 3 2 1 Figura 1.21 Comprimentos de onda mais usados em fibras ópticas.

0 800

900

1000

1100

1200

1300

1400

1500

1600

1700

1800

Comprimento de Onda (nm) A fibra óptica tem inúmeras vantagens sobre os condutores de cobre, sendo as principais: 11 Maior alcance; 11 Maior velocidade; 11 Imunidade a interferências eletromagnéticas. O custo do metro de cabo de fibra óptica não é elevado em comparação com os cabos convencionais. Entretanto, seus conectores são bastante caros, assim como a mão de obra necessária para a sua montagem. A montagem desses conectores requer, além de um curso especializado, o uso de instrumentos como microscópios, ferramentas especiais para corte e polimento, máquinas de fusão de fibra, medidores e outros aparelhos sofisticados. A Figura 1.22 mostra os principais padrões de fibra óptica. Os termos OS1 e OS2 são classificações de fibras ópticas monomodo, onde OS2 tem menor atenuação. Existem outros tipos de

Figura 1.22 Padrões de fibra óptica.

Padrão

Taxa

Comprimento de onda

OS1

OS2

100BASE-SX

100Mb/s

850nm

100BASE-FX

100Mb/s

1310nm

100BASE-BX

100Mb/s

1310/1550nm

10-40Km

100BASE-LX10

100Mb/s

1310nm

10Km

1000BASE-SX

1Gb/s

850nm

1000BASE-LX

1Gb/s

1310nm

5Km

1000BASE-LX10

1Gb/s

850nm

10Km

1000BASE-BX10

1Gb/s

1310/1490nm

10Km

1000BASE-ZX

1Gb/s

1550nm

70Km

Capítulo 1 - Conceitos básicos de redes

fibras especificadas no documento “Understanding OM1,OM2,OM3, OS1,OS2 Fiber.pdf”.

Padrão

Taxa

Comprimento de onda

OS1

OS2

10GBASE-SR/SW

10Gb/s

850nm

10GBASE-LR/LW

10Gb/s

1310nm

4,2Km

10Km

10GBASE-LRM

10Gb/s

1310nm

10GBASE-LX4

10Gb/s

1310nm

4,2Km

10Km

10GBASE-ER/EW

10Gb/s

1550nm

8,9Km

22,25Km

10GBASE-ZR/ZW

10Gb/s

1550nm

40GBASE-SR4

40Gb/s

850nm

40GBASE-LR4

40Gb/s

1310nm

100GBASE-SR10

100Gb/s

850nm

100GBASE-LR4

100Gb/s

100GBASE-LR10 100GBASE-ER4

80Km

4.7Km

10Km

1295/1310nm

8.3Km

10Km

100Gb/s

1310nm

8.3Km

10Km

100Gb/s

1295/1310nm

16Km

40Km

Cabeamento estruturado 11 Norma ANSI/TIA/EIA-568-B.

11 Norma NBR 14565 ABNT 2001. 11 Cabeamento do prédio inteiro. 11 Patch panel. Montar uma rede doméstica é bem diferente de montar uma rede local de 100 pontos em uma empresa de médio porte. Não apenas porque o trabalho é mais complexo, mas também porque existem normas mais estritas a cumprir. O padrão para instalação de redes locais em prédios é o ANSI/TIA/EIA-568-B, que especifica normas para a instalação do cabeamento, topologia da rede e outros quesitos, chamados genericamente de cabeamento estruturado. No Brasil, temos a norma NBR 14565, publicada pela ABNT em 2001. A ideia central do cabeamento estruturado é cabear todo o prédio de forma a colocar pontos de rede em todos os locais onde eles possam ser necessários. Todos os cabos vão para um Arquitetura e Protocolos de Rede TCP-IP

ponto central, onde ficam os switches e outros equipamentos de rede. Os pontos não pre-

cisam ficar necessariamente ativados, mas a instalação fica pronta para quando precisar ser usada. A longo prazo, sai mais barato instalar todo o cabeamento de uma vez, de preferência antes do local ser ocupado, do que fazer modificações a cada vez que for preciso adicionar um novo ponto de rede. Além dos switches, um equipamento muito usado para a concentração dos cabos é o painel de conexão (patch panel), um intermediário entre as tomadas de parede e outros pontos de conexão e os switches da rede. Os cabos vindos dos pontos individuais são numerados e instalados em portas correspondentes do patch panel e as portas utilizadas são então ligadas aos switches. Veja o detalhe do patch panel na figura a seguir.

Figura 1.23 Patch panel.

Além de melhorarem a organização dos cabos, os patch panels permitem o uso de um número muito maior de pontos de rede do que de portas nos switches. A ideia é que todo o escritório ou andar do prédio seja cabeado, com todas as tomadas ligadas ao patch panel. No caso de um escritório novo, provavelmente poucas tomadas serão usadas no início, permitindo o uso de um único switch. Conforme mais tomadas sejam usadas, são adicionados novos switches e outros componentes de rede, conforme a necessidade. Outra vantagem é que com os cabos concentrados no patch panel, tarefas como desativar um ponto ou ligá-lo a outro segmento da rede (ligando-o a outro switch ou roteador) ficam muito mais simples. Os patch panels são apenas suportes, sem componentes eletrônicos. Por isso são relativamente baratos, normalmente instalados em bastidores (racks), junto com os switches e outros equipamentos. Os switches são ligados às portas do patch panel através de cabos de rede curtos, chamados de cabos de conexão (patch cords).

Cabeamento horizontal Temos em seguida a rede secundária, que na norma internacional é chamada de cabeamento horizontal (horizontal cabling), sendo composta pelos cabos que ligam o armário de telecomunicações às tomadas onde são conectados os computadores da rede. Estes são os cabos permanentes, instalados como parte do cabeamento inicial e usados ainda por muito

Cabeamento secundário

Figura 1.24 Cabeamento estruturado. Fonte: Morimoto, Carlos E. Redes, Guia Prático. GDH Press e Sul Editores, 2008

Armário de telecomunicações

Pontos de rede

Área de trabalho

Capítulo 1 - Conceitos básicos de redes

tempo. Veja a figura a seguir.

Como é possível notar, este sistema prevê o uso de três segmentos de cabo: 11 O patch cord ligando o switch ao patch panel; 11 O cabo da rede secundária, ligando o patch panel à tomada na área de trabalho; 11 O cabo entre a tomada e o computador.

Cabeamento vertical O cabeamento vertical (ou backbone) provê a ligação dos armários de telecomunicações com a sala central de equipamentos, sendo constituído dos meios de transmissão, seus conectores e terminações. Para este subsistema é recomendado utilizar: 11 Fibra óptica multimodo de 62.5/125 microns;

11 Par trançado UTP de 100 Ohms; 11 Par trançado STP de 150 Ohms. Para outras aplicações são indicados os cabos: 11 Fibra óptica multimodo tipo 50/125 ou 100/140 microns; 11 Fibra óptica monomodo; 11 Par trançado STP de 100 Ohms.

Redes sem fio Rede sem fio é um conjunto de equipamentos de rede conectados por ondas eletromagnéticas. O meio de comunicação é o ar, ao invés de fios. Uma rede sem fio dispensa cabeamento, tomadas, conectores, dutos, calhas etc. Também conhecida por WLAN (ou Wireless LAN). A motivação para o uso de rede sem fio pode ser: 11 Mobilidade – WLANs permitem aos usuários o acesso à informação de qualquer lugar

da organização, sem necessidade de procurar um ponto de rede para se conectar, aumentando a flexibilidade e a produtividade. 11 Confiabilidade – menos fios e conectores significam menos pontos de falha e, portanto, menos problemas para usuários e gerentes de rede. 11 Facilidade de instalação – WLANs não precisam de caras e demoradas instalações de cabeamento, especialmente em áreas que não tenham sido construídas com a previsão de cabeamento estruturado; dispensam fios pendurados no forro ou nas paredes ou, ainda pior, espalhados pelo chão. 11 Custo – o custo da instalação de uma WLAN pode ser menor do que o de uma solução Arquitetura e Protocolos de Rede TCP-IP

cabeada, principalmente em ambientes que sofrem frequentes mudanças de layout.

11 Escalabilidade – sistemas WLAN são facilmente configurados e remanejados para suportar uma variedade de ambientes de rede, tanto de pequenas como de grandes empresas.

Componentes da WLAN 11 Estações de trabalho e dispositivos sem fio.

11 Pontos de acesso. A Figura 1.21 representa uma rede sem fio típica, onde o roteador sem fio é o ponto central de conexão dos equipamentos que usam a interface de rede sem fio (wireless NIC).

Esse roteador é chamado de Ponto de Acesso (Access Point). Os computadores e notebooks na figura representam as estações de trabalho dos usuários que requerem mobilidade e, portanto, não devem ser conectados a pontos fixos de rede, como ocorre com os desktops.

WLAN de pequeno porte

11 Rede sem cabeamento. 11 Encontrada em casas e pequenas empresas. Em instalações pequenas, podemos encontrar backbones WLAN sem rede cabeada, como na Figura 1.25.

PC com NIC

Notebook com NIC

de rede sem ﬁo

Internet Modem ADSL Roteador sem ﬁo

Notebook com NIC

de rede sem ﬁo

Esse tipo de instalação não é usual, principalmente no ambiente corporativo. Os usuários se conectam através de um ponto de acesso (access point), que atua como um switch ou roteador. Cada ponto de acesso pode conectar vários usuários, teoricamente não havendo limite de conexões. Na prática, o limite é a largura de banda disponível para os usuários.

WLAN corporativa Integrada à rede cabeada da empresa.

A placa de rede sem fio é tratada pelo sistema operacional (Windows, Linux ou outro) como se fosse uma placa de rede Ethernet comum, simplificando assim a instalação e configuração. É mais comum a ocorrência de um misto de rede cabeada e WLAN, conforme mostrado na Figura 1.26.

Capítulo 1 - Conceitos básicos de redes

Figura 1.25 Backbone WLAN.

PC com NIC de rede sem ﬁo

Roteador banda larga

Modem ADSL Internet

Switch Ethernet Roteador sem ﬁo

Figura 1.26 Rede integrada LAN e WLAN.

PCs com NIC par trançado O backbone da rede não exige mobilidade e pode ser cabeado, mesmo porque as exigências de velocidade e capacidade podem exceder as especificações de uma WLAN. Os usuários, que exigem mobilidade, podem ser conectados via WLAN, integrando assim o melhor dos dois mundos. O ponto de acesso permite conexão à rede cabeada como se fosse um switch ou roteador.

Padrões WLAN IEEE 802.11 11 802.11b.

11 802.11g. 11 802.11a. 11 802.11n. Todos os padrões mostrados operam com técnicas de transmissão específicas como, por exemplo, Direct Sequence Spread Spectrum – DSSS (Espalhamento Espectral por Sequência Direta), técnica desenvolvida para fins militares, com o objetivo de confundir a detecção de sinal Arquitetura e Protocolos de Rede TCP-IP

por terceiros. O sinal resultante se assemelha a um ruído radioelétrico. A frequência de 2.4 GHz,

embora tenha maior alcance do que a de 5.8 GHz, está mais sujeita a interferências de outros dispositivos como telefones sem fio, fornos de micro-ondas e controles remotos diversos. Devido à compatibilidade entre os padrões 802.11b e 802.11g, é comum encontrar notebooks e placas de rede sem fio que suportam os dois padrões. O padrão 802.11n é relativamente mais recente e os equipamentos que o suportam são mais caros e difíceis de encontrar.

Padrão IEEE

Frequëncia de operação

Técnica de modulação

Velocidade

802.11b

2400-2483,5 MHz

DSSS

11 Mbps

DSSS, OFDM

54 Mbps

OFDM

54 Mbps

MIMO-OFDM

600 Mbps

802.11g 802.11a

5150-5350 MHz 5470-5725 MHz 5725-5850 MHz

802.11n

2400-2483,5 MHz 5150-5350 MHz 5470-5725 MHz

Figura 1.27 Padrões WLAN IEEE 802.11.

5725-5850 MHz Nos padrões 802.11b e 802.11g, as frequências das portadoras variam de 2,401 a 2,473 GHz e são divididas em 11 canais sobrepostos, sendo ortogonais apenas os canais 1, 6 e 11, cada um com largura de banda de 22 MHz e banda de guarda (espaço entre os canais) de 3 MHz. A figura seguinte mostra essa distribuição de frequências pelos diversos canais. No caso de mais de um equipamento operando no mesmo local, é recomendável que cada equipamento utilize um canal ortogonal diferente dos demais, tanto quanto possível. Desta forma a interferência entre eles será mínima.

Frequência (GHz) 2,412 Figura 1.28 Canais de transmissão WLAN.

2,437

2,462

Equipamentos de rede 11 Placas de rede.

11 Concentradores. 11 Switches. 11 Roteadores. Os equipamentos de rede são específicos para operar em rede, não fazendo parte do hardware padrão das estações de trabalho, em geral. Mesmo as interfaces de rede, que já como periféricos opcionais pelo sistema operacional. Se não estiverem presentes, nenhuma funcionalidade da estação de trabalho será comprometida, exceto, é claro, o acesso à rede. A função principal desses equipamentos de redes é permitir o acesso à rede e o suporte da infraestrutura necessária para o bom funcionamento da rede.

Placas de rede Interface Dispositivo físico ou lógico que faz a adaptação entre dois sistemas.

As interfaces de rede são fisicamente materializadas através das placas de rede, também conhecidas como NIC (Network Interface Card – Cartão de Interface de Rede). A placa de rede é o hardware que permite aos computadores conversarem entre si através da rede.

Capítulo 1 - Conceitos básicos de redes

vêm normalmente embutidas nos computadores IBM-PC e notebooks, são consideradas

Sua função é controlar todo o envio e recebimento de dados através da rede. Além da arquitetura usada, as placas de rede à venda no mercado diferenciam-se também pela taxa de transmissão, cabos de rede suportados e barramento utilizado. Cada arquitetura de rede exige um tipo específico de placa de rede; você jamais poderá usar uma placa de rede Token Ring em uma rede Ethernet, pois ela simplesmente não conseguirá comunicar-se com as demais. As placas de rede mais usadas são as placas Ethernet. Elas adotam um esquema de endereçamento específico para identificar os computadores na rede local Ethernet, chamado de endereço MAC (MAC Address). 11 Cada placa Ethernet tem um único endereço MAC. 11 Endereços MAC proveem uma forma dos computadores se identificarem, fornecendo um nome único e permanente. Os 3 primeiros octetos identificam o fabricante (OUI) e os 3 últimos a placa de rede propriamente dita. O fabricante assume o compromisso de não repetir endereços.

Endereços MAC Gravados na memória ROM da placa de rede, identificam origem e destino do quadro

Ethernet. Têm 48 bits expressos em hexadecimal: 11 24 bits – OUI. 11 24 bits – número serial. Endereços MAC são chamados às vezes de Burned-in Addresses (BIAs), porque são “queimados” na memória ROM da placa de rede e copiados na RAM quando a NIC inicializa. Possuem 48 bits em comprimento, expressos como 12 dígitos em hexadecimal; os primeiros 6 dígitos hexadecimais são administrados pelo IEEE e identificam o fabricante, sendo chamados de Organizational Unique Identifier (OUI); os 6 dígitos hexadecimais restantes traduzem o número serial da placa de rede. O protocolo Ethernet usa endereço MAC para identificar origem e destino do quadro Ethernet. Quando um computador envia um quadro Ethernet, ele inclui o endereço MAC na sua placa de rede (NIC) como o endereço MAC de origem. Analogia: como se, ao enviar uma carta, usássemos apenas um nome, ao invés de um endereço estruturado com CEP.

Desvantagens dos endereços MAC: 11 Não identificam a rede, apenas o equipamento.

Arquitetura e Protocolos de Rede TCP-IP

11 Não são estruturados hierarquicamente e são considerados “flat address space”.

11 Devido a essa característica, não são roteáveis de uma rede para outra.

Quadro Ethernet A figura a seguir mostra os campos do quadro Ethernet, destacando os campos de endereço.

Preâmbulo

Endereço destino

Endereço origem

Tipo

46-1500 Dados

4 FCS

Figura 1.29 Quadro Ethernet.

Descrição dos campos: 11 Preâmbulo – sequência de 8 octetos com a finalidade específica de sincronizar os relógios (clock) do receptor com o do transmissor; os primeiros 7 octetos têm o mesmo conteúdo (em binário): 10101010 e o oitavo octeto (Start Field Delimiter) tem o seguinte conteúdo (em binário): 10101011; 11 Endereço destino – endereço MAC da estação de destino do quadro; quando o quadro se destina a todas as estações da rede local (broadcast) o endereço é (em hexadecimal): ff:ff:ff:ff:ff:ff; 11 Endereço origem – endereço MAC da estação que enviou o quadro; 11 Tipo – indica o protocolo de camada de rede que está sendo encapsulado no quadro; os valores mais comuns nesse campo são (em hexadecimal): 0x8000 (protocolo IP – Internet Protocol) e 0x0806 (protocolo ARP – Address Resolution Protocol); 11 Dados – campo que contém os dados recebidos da camada de rede, como por exemplo um datagrama IP; o tamanho mínimo desse campo é de 46 octetos e o máximo de 1500 octetos; 11 Frame Check Sequence (FCS) – campo de verificação de erros; se algum bit do quadro estiver corrompido, este campo indicará que o quadro está errado, mas não indicará o erro. Portanto, o quadro será descartado na impossibilidade de corrigi-lo.

Exercício de fixação 1 e Identificando as informações da interface de rede No prompt de comando do Windows, utilize o comando ipconfig /all e identifique as informações da interface de rede do desktop da sala de aula. Descrição do adaptador físico: Endereço físico: Endereço IP: Máscara de rede: Gateway padrão: Faça a mesma consulta ao Linux da máquina virtual CORE disponibilizado no desktop. Para isto utilize o comando ifconfig. Caso possua outro dispositivo com tecnologia wireless, como celular ou tablet,

Concentradores 11 Todos os dispositivos conectados ao concentrador estão no mesmo domínio

de colisão. 11 Dispositivos compartilham banda sob demanda. Concentradores (hubs) são pontos de conexão para dispositivos em uma rede, que contêm múltiplas portas e são usados para conectar segmentos de uma LAN. Quando um pacote chega a uma porta, este é copiado para as outras portas; assim, todos os segmentos podem “ver” todos os pacotes. Um hub passivo simplesmente serve de conduto para os dados, habilitando-o a ir de um dispositivo (ou segmento) para outro.

Capítulo 1 - Conceitos básicos de redes

procure identificar estas informações no seu aparelho.

Figura 1.30 Analogia para o funcionamento de um hub.

Todos os dispositivos conectados em um concentrador estão no mesmo domínio de colisão; o domínio de colisão é definido como um conjunto de equipamentos, em que apenas um pode transmitir de cada vez. Os equipamentos conectados a um hub, independente da quantidade de portas, estão todos no mesmo domínio de colisão. A banda disponível é dividida pelos dispositivos conectados. Enquanto A fala com B, C não pode falar com D: um único domínio de colisão. Por esse motivo, equipamentos do tipo hub não são recomendados nos dias de hoje. A Figura 1.30 compara concentradores (hubs) com uma autoestrada de uma única faixa de rolamento e com múltiplos pontos de acesso (entradas e saídas). Quanto mais pontos de entrada na autoestrada, maior a probabilidade de ocorrer uma colisão. Analogamente, quanto maior for o número de estações terminais (hosts) conectadas em um concentrador (hub) tentando acessar o meio físico, maior será a probabilidade de ocorrerem colisões.

Switches 11 Cada segmento de rede tem seu próprio domínio de colisão. 11 Cada porta do switch é um domínio de colisão. 11 O switch é capaz de ler os endereços MAC de origem e destino. Para reduzir o número de colisões, um switch pode ser “dividido” em vários segmentos, cada um definindo um domínio de colisão distinto. Um switch de 24 portas possui

Arquitetura e Protocolos de Rede TCP-IP

24 domínios de colisão.

2 Figura 1.31 Esquema de operação de switch.

3 4

Funcionamento do switch A grande vantagem do switch, em relação ao hub, decorre do fato do switch ser capaz de ler os endereços MAC de origem e destino no quadro Ethernet, enquanto o hub não lê os endereços MAC, apenas repete os quadros que entram por uma porta para todas as demais. Switch Ethernet é o equipamento que realiza a função de comutação de quadros na camada de enlace. Em redes Ethernet, os quadros da LAN são transferidos através da rede, com base nos endereços de origem e destino contidos no cabeçalho MAC do quadro. Essencialmente, é a mesma coisa que bridging, mas sempre empregando hardware dedicado para realizar a comutação (switching).

Switch

Figura 1.32 Analogia do funcionamento de switches.

A Figura 1.32 compara um switch a uma autoestrada. Compare com a figura do concentrador (hub), observando as diferenças e semelhanças. Note que a estrada tem várias faixas de rolamento, uma para cada domínio de colisão.

Capítulo 1 - Conceitos básicos de redes

Memória

Roteadores Roteadores são dispositivos de rede mais tradicionais, como de backbone das intranets

e da internet. Eles tomam decisões baseadas nos endereços de rede. Atualmente é comum que switches desempenhem funções de roteador. Principais funções: 11 Seleção dos melhores caminhos de saída para os pacotes de entrada. 11 Roteamento destes pacotes para a interface de saída apropriada. Roteador é o dispositivo responsável pelo encaminhamento de pacotes de comunicação em uma rede ou entre redes. Tipicamente, uma instituição, ao se conectar à internet, deverá adquirir um roteador para conectar sua rede local (LAN) ao ponto de presença mais próximo. Roteadores escolhem os melhores caminhos através da construção de tabelas de roteamento e da troca de informações de rede com outros roteadores da rede. Esta troca, que pode ser realizada de várias formas e com diferentes algoritmos, caracteriza os protocolos de roteamento. Exemplos de protocolos de roteamento: RIPv1, RIPv2, OSPF, EIGRP, BGP, IS-IS. Um exemplo simples de roteador é o roteador sem fio usado em instalações de pequeno porte, também conhecido como roteador doméstico, que tem uma porta WAN (que se conecta à internet através de um provedor) e uma porta LAN para conectar a rede local do usuário. Essa rede local do usuário pode ser sem fio, através de adaptadores de redes sem fio (NIC ou adaptadores USB) ou com fio, conectada através do switch embutido no próprio roteador (usualmente com 4 portas LAN). E1

R2 R1

É possível configurar manualmente (estaticamente) tabelas de roteamento, mas em geral elas são mantidas e atualizadas dinamicamente pelos protocolos de roteamento, que

Arquitetura e Protocolos de Rede TCP-IP

trocam informações sobre a topologia de rede com outros roteadores vizinhos. O estudo

avançado de protocolos de roteamento não faz parte do programa deste curso. Roteadores mantêm tabelas de roteamento construídas a partir da troca de informações entre roteadores vizinhos. Antes de qualquer roteamento, o administrador deve configurar o roteador para adquirir, estática ou dinamicamente, informações que popularão sua tabela de roteamento. Funções dos roteadores: 11 Determinação do melhor caminho; 11 Endereçamento lógico; 11 Conexão com serviços WAN.

Figura 1.33 Escolha do melhor caminho pelo roteador.

Um tipo comum de roteador é o ponto de acesso sem fio.

Tabelas de roteamento

11 Endereçamento lógico permite hierarquização das redes. 11 Requer configuração: não é “plug and play”. 11 Usa informação configurada para identificar os melhores caminhos.

Rede 1.0

Rede 4.0

1.3

2.1

1.2

Figura 1.34 Tabelas de roteamento.

Rede 2.0

2.2

4.3

Tabela de roteamento

NET

INT

Métrica

NET

INT

Métrica

1 2 4

E0 S0 S0

0 0 1

1 2 4

S0 S0 E0

1 0 0

4.1

4.2

As tabelas de roteamento da figura anterior mostram o caminho para chegar às redes. Cada interface do roteador fica numa rede diferente. As interfaces conectadas às LANs são chamadas E0, E1 ..., enquanto as conectadas às WANs são chamadas S0, S1 etc. A métrica fornece uma ideia da distância até a rede, isto é, da quantidade de roteadores no caminho até o destino. Essa métrica é chamada de “Vetor Distância” e mede a quantidade de saltos (hops) até o destino final. Veremos mais adiante que o endereçamento lógico em redes TCP/IP usa o endereço IP no formato de notação decimal pontuada como, por exemplo, 200.130.26.201, onde cada número representa um octeto, totalizando 4 octetos ou 32 bits. O esquema de endereçamento IP adota uma abordagem hierárquica que identifica a rede e a estação dentro da rede, utilizando a máscara de rede para separar a identificação da rede da identificação da estação. A máscara de rede também adota o formato de notação decimal pontuada, tendo bits 1 no identificar de rede e bits 0 no identificador de estação. Por exemplo, a máscara 255.255.255.0 indica que o identificador de rede possui 24 bits e o identificador de estação possui 8 bits. Veremos também que o roteador que encaminha pacotes para outras redes é denominado gateway padrão, sendo também identificado com um endereço IP. Capítulo 1 - Conceitos básicos de redes

1.1

Arquitetura e Protocolos de Rede TCP-IP

Roteiro de Atividades 1 Atividade 1.1 – Montagem de uma rede par-a-par Cada bancada montará uma rede local par-a-par utilizando um switch do tipo mostrado na figura seguinte. O modelo pode variar de um fabricante para outro, mas o importante são as 8 portas LAN mostradas na figura. As bancadas serão respectivamente denominadas: grupo1, grupo2, ..., grupo6 (máximo de 6 grupos).

Figura 1.35 Portas LAN do switch.

TODOS os equipamentos devem estar DESLIGADOS durante a montagem da rede. 1. O primeiro passo é desconectar as máquinas da bancada da rede local do laboratório

e conectá-las às portas LAN do switch, em qualquer ordem. Use os cabos par trançado fornecidos pelo instrutor. 2. Depois de conferir todas as conexões, ligue todos os equipamentos. Observe se os led’s

do switch que correspondem às portas LAN utilizadas estão acesos. Isso significa que o cabo está corretamente conectado. 3. A configuração dos endereços IPv4 deve ser feita manualmente.

O endereço IP que será usado deve ser escolhido da tabela abaixo, de acordo com o grupo ao qual sua bancada pertence. A máscara de sub-rede será sempre 255.255.255.0 e o gateway padrão será sempre 192.168.1.254. Nome do grupo

Faixa de endereços IPv4

Endereço por aluno (Windows e Linux)

grupo1

192.168.1.1 a 192.168.1.10

Aluno1: 192.168.1.1 e 192.168.1.2 Aluno2: 192.168.1.3 e 192.168.1.4 Aluno3: 192.168.1.5 e 192.168.1.6 Aluno5: 192.168.1.9 e 192.168.1.10

grupo2

192.168.1.11 a 192.168.1.20

Aluno1: 192.168.1.11 e 192.168.1.12 Aluno2: 192.168.1.13 e 192.168.1.14 Aluno3: 192.168.1.15 e 192.168.1.16 Aluno4: 192.168.1.17 e 192.168.1.18 Aluno5: 192.168.1.19 e 192.168.1.20

grupo3

192.168.1.21 a 192.168.1.30

Aluno1: 192.168.1.21 e 192.168.1.22 Aluno2: 192.168.1.23 e 192.168.1.24 Aluno3: 192.168.1.25 e 192.168.1.26 Aluno4: 192.168.1.27 e 192.168.1.28 Aluno5: 192.168.1.29 e 192.168.1.30

Capítulo 1 - Conceitos básicos de redes

Aluno4: 192.168.1.7 e 192.168.1.8

Nome do grupo

Faixa de endereços IPv4

Endereço por aluno (Windows e Linux)

grupo4

192.168.1.31 a 192.168.1.40

Aluno1: 192.168.1.31 e 192.168.1.32 Aluno2: 192.168.1.33 e 192.168.1.34 Aluno3: 192.168.1.35 e 192.168.1.36 Aluno4: 192.168.1.37 e 192.168.1.38 Aluno5: 192.168.1.39 e 192.168.1.40

grupo5

192.168.1.41 a 192.168.1.50

Aluno1: 192.168.1.41 e 192.168.1.42 Aluno2: 192.168.1.43 e 192.168.1.44 Aluno3: 192.168.1.45 e 192.168.1.46 Aluno4: 192.168.1.47 e 192.168.1.48 Aluno5: 192.168.1.49 e 192.168.1.50

grupo6

192.168.1.51 a 192.168.1.60

Aluno1: 192.168.1.51 e 192.168.1.52 Aluno2: 192.168.1.53 e 192.168.1.54 Aluno3: 192.168.1.55 e 192.168.1.56 Aluno4: 192.168.1.57 e 192.168.1.58 Aluno5: 192.168.1.59 e 192.168.1.60

4. Verifique no Windows ou no Linux se a configuração do endereço IP foi realizada com sucesso.

Verifique no Painel de Controle do Windows se o firewall está desabilitado. Esse passo é importante, porque se o firewall estiver ativo, os testes de conectividade serão prejudicados. 5. Teste a conectividade com as máquinas do seu grupo que estão ligadas ao switch de sua

bancada, com o comando ping. No exemplo a seguir, assumindo que o endereço IP: 192.168.1.2 pertence à sua bancada.

C:\>ping 192.168.1.2 Disparando contra 192.168.1.2 com 32 bytes de dados: Resposta de 192.168.1.2: bytes=32 tempo=1ms TTL=128 Resposta de 192.168.1.2: bytes=32 tempo=16ms TTL=128 Resposta de 192.168.1.2: bytes=32 tempoping 192.168.11.1 Disparando contra 192.168.11.1 com 32 bytes de dados: Esgotado o tempo limite do pedido. Esgotado o tempo limite do pedido. Esgotado o tempo limite do pedido. Esgotado o tempo limite do pedido. Estatísticas do Ping para 192.168.11.1: Pacotes: Enviados = 4, Recebidos = 0, Perdidos = 4 (100% de perda), Como podemos verificar, o ping NÃO funcionou, indicando que não existe conectividade com as máquinas das outras bancadas. Por quê?

Atividade 1.2 – Conectando a rede ao switch do laboratório Nesta atividade conectaremos a rede do grupo à rede do laboratório, formando uma única rede na sala de aula. 1. Conecte uma porta LAN do switch num ponto de rede do laboratório. Aproveite o ponto

livre de uma das máquinas da bancada. A ligação deve ficar semelhante à mostrada na figura seguinte.

Rede local do laboratório

Bancada

Aguarde até que todas as demais bancadas façam o mesmo. O instrutor deve coordenar essa atividade. Repita o teste de conectividade entre os grupos.

Atividade 1.3 – Teste de conectividade do grupo com a internet Para conexão com a internet, será necessário configurar o endereço do “Servidor DNS preferencial” com o endereço IP fornecido pelo instrutor. O servidor DNS, também chamado de servidor de nomes, traduz os nomes dos equipamentos em endereços IP, para que os usuários não precisem decorar os endereços dos

Capítulo 1 - Conceitos básicos de redes

Figura 1.36 Rede local par-a-par.

servidores que pretendem acessar. Por exemplo, é mais fácil decorar www.google.com do que o endereço IP: 74.125.234.112.

1. Verifique a conectividade com a internet, através do mesmo comando ping, conforme

abaixo (podem ser escolhidos outros endereços na internet).

C:\>ping esr.rnp.br Disparando contra esr.rnp.br [200.130.35.73] com 32 bytes de dados: Resposta de 200.130.35.73: bytes=32 tempo=23ms TTL=61 Resposta de 200.130.35.73: bytes=32 tempo=1ms TTL=61 Resposta de 200.130.35.73: bytes=32 tempo=1ms TTL=61 Resposta de 200.130.35.73: bytes=32 tempo=1ms TTL=61 Estatísticas do Ping para 200.130.35.73: Pacotes: Enviados = 4, Recebidos = 4, Perdidos = 0 (0% de perda), Aproximar um número redondo de vezes em milissegundos: Mínimo = 1ms, Máximo = 23ms, Média = 6ms 2. Observe que usamos o nome no lugar do endereço IP, mas mesmo assim funcionou. Por quê?

Atividade 1.4 – Análise da troca de pacotes na rede Nesta atividade, usaremos o software Wireshark, que pode ser obtido gratuitamente em: http://www.wireshark.org O software pertence a uma categoria específica de ferramentas de rede chamada Network Protocol Analyzer (Analisador de Protocolo de Rede ou sniffer). O Wireshark captura pacotes IP na interface de rede do equipamento onde está sendo executado. Se o equipamento tiver várias interfaces de rede, é necessário especificar em QUAL interface de rede será realizada a captura de pacotes IP. 1. A tela inicial do Wireshark está mostrada a seguir, na qual aparece como é feita a escolha

da interface de rede para iniciar a captura, bastando clicar no primeiro ícone à esquerda

Arquitetura e Protocolos de Rede TCP-IP

na barra de ferramentas superior.

Figura 1.37 Tela inicial do Wireshark.

No nosso caso, foi escolhida a interface de rede com o endereço IP: 192.168.1.101. Para isso, basta clicar no botão “Start” da interface escolhida. As demais são interfaces virtuais para outras finalidades que não se aplicam aqui. 2. Vamos agora repetir o teste de conectividade entre as estações, usando a mesma janela

DOS. O resultado apresentado a seguir corresponde a um ping da estação com endereço IP 192.168.1.101 para a estação com endereço IP: 192.168.1.102.

C:\>ping 192.168.1.102 Disparando contra 192.168.1.102 com 32 bytes de dados: Resposta de 192.168.1.102: bytes=32 tempo=7ms TTL=128 Resposta de 192.168.1.102: bytes=32 tempoarp -a No ARP entries found Após os seguintes comandos:

C:>ping 192.168.10.2 Pinging 192.168.10.2 with 32 bytes of data: Reply from 192.168.10.2 on Eth, time192.168.2.1, d=172.16.2.2 [2] NAT: s=10.1.1.1->192.168.2.1, d=172.16.2.2 [3] NAT*: s=172.16.2.2, d=192.168.2.1->10.1.1.1 [1] NAT: s=172.16.2.2, d=192.168.2.1->10.1.1.1 [1] NAT: s=10.1.1.1->192.168.2.1, d=172.16.2.2 [4] NAT: s=10.1.1.1->192.168.2.1, d=172.16.2.2 [5] NAT: s=10.1.1.1->192.168.2.1, d=172.16.2.2 [6] NAT: s=172.16.2.2, d=192.168.2.1->10.1.1.1 [2] Os pacotes restantes trafegarão pelo caminho rápido se existir uma entrada no cache. 11 S é o endereço de origem; 11 a.b.c.d -> w.x.y.z é o endereço que foi traduzido; 11 d é o endereço de destino. O valor entre colchetes é o número de identificação IP. Esta informação pode ser útil para debug, pois permite comparar os dados do debug com os dados de outras fontes, tal como pacotes de trace originados por sniffers.

Limpando traduções NAT Uma vez que NAT é habilitado, nenhuma mudança pode ser feita no seu processo enquanto traduções dinâmicas estiverem ativas. Use o comando clear ip nat translation * para limpar a tabela NAT.

router# show ip nat translations Pro Inside global

Inside local

Outside local

Outside

global tcp 192.168.2.1:11003

10.1.1.1:11003

172.16.2.2:23

tcp 192.168.2.1:11067

10.1.1.1:11067

172.16.2.3:23

router#

q Capítulo 4 - Endereçamento IP (parte 2)

Figura 4.37 Depuração (debug) em traduções NAT.

151

router# clear ip nat trans * router# show ip nat trans

Figura 4.38 Limpando traduções NAT.

router# Tendo sido habilitada a tradução NAT num roteador ou servidor, enquanto traduções dinâmicas estiverem ativas, nenhuma modificação pode ser feita, sob pena de perder sessões TCP/UDP em andamento e, por conseguinte, prejudicar as aplicações que estão usando as traduções NAT. Não existindo traduções ativas, a tabela NAT pode ser limpa através do comando:

clear ip nat translation * NAT Overlaping não será tratado neste curso porque envolve uma situação particular, na qual duas redes privadas usando a mesma faixa de endereços devem ser interligadas, e o administrador da rede optou por não refazer o esquema de endereçamento em um primeiro momento.

Endereços IPv6 Objetivo:

11 Identificar, de forma única e individual, cada dispositivo da inter-rede TCP/IP. 11 Inicialmente denominado IPng (Next Generation). Representação: 11 8 grupos de 16 bits = 128 bits. 11 Permite até 2128 endereços. Os 32 bits dos endereços IPv4 são divididos em quatro grupos de 8 bits cada, separados por “.”, escritos com dígitos decimais.

192.168.10.1 A representação dos endereços IPv6, divide o endereço em oito grupos de 16 bits, separando-os por “:”, escritos com dígitos hexadecimais.

Figura 4.39 Representação de endereços IPv4 e IPv6.

2001:0DB8:AD1F:25E2:DFA1:F0C4:5311:84C1 Vamos discutir inicialmente o porquê de um novo esquema de endereçamento. 11 Arquitetura classful x classless.

Arquitetura e Protocolos de Rede TCP-IP

11 Administração endereços IPv4 IANA.

152

11 Últimos 5 blocos /8 distribuídos em 03/02/2011.

Figura 4.40 Registros regionais da internet. Fonte: IANA.

Vimos que a arquitetura classful, originalmente concebida, teve de ser abandonada por causa do crescimento da internet e da própria estrutura de classes que se mostrou ineficiente na atribuição de endereços para as diferentes redes físicas. Em função da necessidade de evitar o desperdício de endereços IPv4 e seu rápido esgotamento, foi amplamente adotada a arquitetura classless. Mas essa solução apenas adia o inevitável, uma vez que o crescimento desordenado da internet exigia cada vez mais quantidades maiores de endereços IPv4, muito acima da capacidade de endereçamento do IPv4 com apenas 32 bits. Para se ter uma ideia do problema de esgotamento de endereços IP, vamos dar um panorama da situação atual da atribuição de endereços IPv4. O órgão encarregado de atribuir endereços IPv4 é o Internet Assigned Numbers Authority (IANA) – Autoridade de Atribuição de Números na Internet, que delega essa atribuição para 5 grandes Regional Internet Registry (RIR)– Registro Regional da Internet, conforme mostra a Figura 4.40. No Brasil, estamos situados na área do LACNIC. Cada RIR possui certa quantidade de blocos /8 (16 milhões de endereços) para distribuir aos países da sua área de atuação. O RIR distribui os blocos de acordo com a demanda. Em geral, são distribuídos pedaços dos blocos de endereços (sub-blocos) de acordo com a necessidade devidamente justificada pelo usuário.

A situação da distribuição atualizada desses blocos pode ser vista digitando “Contador do Esgotamento do IPv4” em sua ferramenta de busca. Por ele pode-se verificar que o RIR APNIC já não tem mais endereços para distribuir desde 15/04/2011. Idem para o IANA, uma vez que todos os blocos IPv4 já foram distribuídos para os 5 RIR desde 03/02/2011. Os demais RIR têm seu esgotamento de endereços IPv4 previsto para os próximos anos.

Prevendo a escassez de endereços IPv4, a Microsoft comprou um bloco de endereços da Nortel (digite em seu buscador “Microsoft foge da implantação do IPv6”). Esta notícia prenuncia a existência de um “mercado negro” de endereços IPv4.

Formato do endereço IPv6 Os endereços IPv6 são divididos em grupos de 16 bits separados por “:” (diferente do IPv4, em que os octetos são separados por “.”) e representados em hexadecimal (decimal no caso do IPv4). A hierarquia é a mesma do endereço IPv4: prefixo de rede e identificador de estação. Não existem classes de endereços com restrição de quantidade de octetos para rede e estação. A máscara de rede/sub-rede é sempre representada no formato de contagem de bits.

Distribuição de endereços IPv6 Blocos IPv6 são distribuídos de forma hierárquica:

11 Cada RIR recebe da IANA um bloco /12. 11 Os provedores recebem dos RIRs blocos /32. 11 Os clientes dos provedores recebem blocos /48 ou /56. 11 Cliente doméstico recebe bloco /64 (apenas 1 rede). A distribuição de blocos IPv6 é feita de forma hierárquica: 11 Cada RIR recebe da IANA um bloco /12; 11 Os provedores recebem dos RIRs blocos /32; 11 Os clientes dos provedores devem receber blocos /48 ou /56, dependendo das suas necessidades. Um cliente só deve receber um bloco /64 se tiver certeza de que apenas uma rede atende às suas necessidades (exemplo: usuários domésticos). Isto significa que não devem existir sub-redes IPv6 com prefixos de rede maiores que /64.

Capítulo 4 - Endereçamento IP (parte 2)

153

Os provedores devem entregar aos seus clientes blocos variando entre /48 e /56, dependendo de suas necessidades: 11 Um bloco /48 pode ser dividido em até 65.536 sub-redes diferentes; 11 Um bloco /56 pode ser dividido em até 256 sub-redes diferentes.

Implantação do IPv6 No âmbito acadêmico, existem diversos grupos de pesquisa que trabalham no desenvolvimento de projetos relacionados ao protocolo IPv6, destacando-se os projetos: 11 Rede CLARA (Cooperação Latino-Americana de Redes Avançadas); 11 GÉANT2; 11 Internet2; 11 KAME; 11 USAGI (Universal playground for IPv6). No Brasil, a Rede Nacional de Ensino e Pesquisa (RNP) tem se destacado desde o projeto Br6Bone. Atualmente toda a rede da RNP está apta a operar com o protocolo IPv6 em modo nativo, além de fornecer conexão IPv6 a instituições localizadas nos estados que se beneficiam de sua rede. A RNP também possui conexão IPv6 nativa com outras redes acadêmicas e comerciais.

Representação do endereço IPv6 Abreviação de zeros contínuos só pode ser feita uma vez em cada endereço IPv6. Certo: 11 2001:0000:0000:0058:0000:0000:0000:0320 ou 11 2001::58:0:0:0:320 ou 11 2001:0:0:58::320 Errado: 11 2001::58::320 Como foi dito, o endereço IPv6 é representado por 8 grupos de 16 bits separados por “:”. Nesta representação é permitido utilizar caracteres maiúsculos e minúsculos e regras de abreviação como: 11 Omitir os zeros à esquerda; 11 Representar os zeros contínuos por “::”. Arquitetura e Protocolos de Rede TCP-IP

Exemplos:

154

11 2001:0db8:0000:130F:0000:0000:087C:140b ou 11 2001:0db8:0:130F::087C:140b

A abreviação de zeros contínuos só pode ser realizada uma única vez, caso contrário poderá haver ambiguidade na representação do endereço. Por exemplo, o endereço: 2001:0000:0000:0058:0000:0000:0000:0320 pode ser abreviado como: 2001::58:0:0:0:320 ou 2001:0:0:58::320, mas nunca na forma 2001::58::320 (errada!).

11 Prefixos de rede usam contagem de bits. 11 Formato: endereço-IPv6/tamanho do prefixo. A representação dos prefixos de rede continua do mesmo modo que no IPv4, utilizando a contagem de bits. Esta notação é representada da forma “endereço-IPv6/tamanho do

prefixo”, onde “tamanho do prefixo” é um valor decimal que especifica a quantidade de bits contíguos à esquerda do endereço, que compreendem o prefixo. Exemplos: 11 2001:db8:3003::/48 11 2001:db8:3003:2:a:20ff:fe18:4c/64 Não há qualquer tipo de definição de classes de endereços como no IPv4.

Tipos de endereços IPv6

11 Unicast. 11 Multicast. 11 Anycast. No IPv6 foram definidos 3 tipos de endereços: 11 Unicast – identifica apenas uma única interface; 11 Multicast – identifica um grupo de interfaces e o pacote é enviado para todas as interfaces do grupo; todos os nós devem suportar obrigatoriamente multicast; substitui o endereço broadcast: multicast “all nodes on link”: FF02::1;

11 Anycast – também identifica um grupo de interfaces, porém o pacote é entregue apenas para a interface do grupo mais próxima do nó de origem.

Transição de IPv4 para IPv6 Técnicas de transição IPv4 para IPv6:

Pilha dupla

Tunelamento

Tradução

Como não é possível substituir de uma hora para outra o protocolo IPv4 pelo protocolo IPv6 em toda a internet, haverá necessidade de convivência entre os dois protocolos.

Capítulo 4 - Endereçamento IP (parte 2)

Figura 4.41 Técnicas de transição de IPv4 para IPv6.

155

Figura 4.42 Convivência entre IPv4 e IPv6.

Para que a adoção do IPv6 seja bem-sucedida, é necessário que seja realizada de forma gradual e transparente para a maioria dos usuários. Desta forma, na fase inicial da transição haverá um período de coexistência entre os dois protocolos, em que redes IPv4 precisarão comunicar-se com redes IPv6 e vice-versa. Com o intuito de facilitar esse processo, foram desenvolvidas técnicas para manter a compatibilidade de toda a base das redes instaladas sobre IPv4 com o novo protocolo IPv6. As técnicas de transição podem ser classificadas nas seguintes categorias: 11 Pilha dupla – provê o suporte a ambos os protocolos no mesmo dispositivo.

11 Tunelamento – permite o tráfego de pacotes IPv6 sobre estruturas de rede IPv4, ou o inverso. 11 Tradução – permite a comunicação entre nós com suporte apenas a IPv6 com nós que suportem apenas IPv4 e vice-versa.

Ausência de NAT no IPv6 11 Em IPv6 não existem endereços privados.

11 Não há necessidade de usar NAT em IPv6. 11 Os usuários devem usar redes com prefixo máximo /64, sem sub-redes. 11 Sub-redes só de prefixos menores que /64 (/48 ou /56). 11 Não haverá escassez de endereços IPv6 para as redes físicas. Em IPv6, não são definidos endereços privados da mesma forma que em IPv4. A ideia é que não haja escassez de endereços que justifique a adoção de NAT. Assim, os endereços IPv6 poderão ser usados como endereços públicos, se for necessário. Recomenda-se que as menores redes dos usuários tenham prefixo /64. Se forem necessárias sub-redes, o usuário deverá receber um bloco maior (/48 ou /56). No caso de utilização

Arquitetura e Protocolos de Rede TCP-IP

de redes locais Ethernet, deve-se usar os 64 bits de identificação da estação para inserir o

156

endereço MAC (48 bits). É premissa básica do endereçamento IPv6 que não haverá escassez de prefixos de rede e que os 64 bits de identificação da estação serão suficientes para qualquer tamanho de rede física.

157

Capítulo 4 - Endereçamento IP (parte 2)

158

Arquitetura e Protocolos de Rede TCP-IP

Roteiro de Atividades 4 Atividade 4.1 – Configuração do exemplo 1 de VLSM 1. Inicie o simulador Netsimk. 2. Abra o arquivo Rede_Atividade4_1.nsw. Este arquivo contém a rede desenhada, mas não

configurada. 3. Configure o roteador e os computadores, um em cada sub-rede, obedecendo à seguinte

distribuição: 3.1. Sub-rede 192.168.10.0/25 na interface E0 do roteador; 3.2. Sub-rede 192.168.10.128/26 na interface E1; 3.3. Sub-rede 192.168.10.192/26 na interface E2.

Faça a configuração completa dos computadores: endereço IP, máscara de sub-rede e gateway padrão. A Figura 4.43 mostra a rede que deve ser configurada de acordo com as premissas acima. PC2

PC1

PC3

2 2

2 1

1 E0

Figura 4.43 Rede VLSM_ Exemplo 1.

Capítulo 4 - Roteiro de Atividades

Router

159

Atividade 4.2 – Estudo de caso Uma empresa recebeu do seu provedor a faixa de endereços IP, definida pelo prefixo 200.10.10.0/24, para a construção de sua rede interna de computadores. Essa empresa é dividida em cinco departamentos (Produção, Compras, Vendas, Pessoal e Pesquisa) e cada um terá sua própria sub-rede IP. Considere que cada departamento conta com a seguinte quantidade de máquinas: Produção=10, Compras=25, Vendas=40, Pessoal=100 e Pesquisa=8. Determine o prefixo de rede e o endereço de broadcast de cada departamento para que todas as máquinas recebam um endereço. Os prefixos devem ser alocados de tal forma que departamentos com um maior número de máquinas recebam endereços mais próximos do início do espaço de endereçamento disponível. Os prefixos devem ser informados através da notação X.Y.W.Z/máscara, como na representação do prefixo fornecido pelo provedor (ENADE 2008, questão 39). Após efetuar os cálculos usando VLSM e o método BOX, configure a rede mostrada a seguir. PC3

PC2

PC4

2 2

2 1

PC1

1 E1

PC5

E3 E4

Router

Arquitetura e Protocolos de Rede TCP-IP

160

Figura 4.44 Rede da Atividade 4.2.

Configure na mesma ordem de cálculo das sub-redes: a maior sub-rede na interface E0, a segunda maior na interface E1 e assim por diante, até a menor sub-rede na interface E4. Inicie o simulador e abra a rede: Rede_Atividade4_2.nsw. A rede está desenhada, mas não está configurada. Observe que o enunciado obriga a calcular as maiores sub-redes primeiro e as menores na sequência, exatamente como o algoritmo de atribuição de blocos.

Atividade 4.3 – Configuração de NAT Estático e Dinâmico Um Provedor de Acesso à Internet (ISP) atribuiu a uma empresa a rede 199.99.9.32/27, que equivale a 30 endereços IP públicos. Como a empresa tem um requisito interno de mais de 30 endereços, o gerente de TI decidiu implementar o NAT: os endereços 199.99.9.33 – 199.99.9.39 para alocação estática e 199.99.9.40 – 199.99.9.62 para alocação dinâmica. Rota estática Rota definida pelo administrador da rede e inserida manualmente na tabela de rotas.

O roteamento entre o ISP e o roteador da empresa RA é feito com o uso de uma rota estática entre o ISP (RB) e o gateway RA e de uma rota padrão entre o roteador RA e o ISP (RB). A conexão do ISP com a internet será representada por um endereço de loopback no roteador RB (Figura 4.45).

Rota padrão Rota usada pela estação ou roteador quando o destino não está na tabela de roteamento.

10.10.10.10

PC1

10.10.10.20 2

PC2

S0 DCE

PC3

Figura 4.45 Configuração de NAT Estático e Dinâmico.

10.10.10.30

Nome do roteador

Tipo de interface

Endereço IP

Máscara de rede

Ethernet 0

10.10.10.1

255.255.255.0

Serial 0

200.2.2.18

255.255.255.252

Serial 0

200.2.2.17

255.255.255.252

Loopback 0

172.16.1.1

255.255.255.255

1. Inicie o simulador Netsimk e carregue a rede Rede_Atividade4_3.nsw. Os computadores

PC1, PC2 e PC3 já estão configurados. É necessário configurar as interfaces dos rotea-

2. Os comandos de configuração do roteador RA estão listados abaixo.

RA>en RA#conf t RA(config)#int e0 RA(config-if)#ip address 10.10.10.1 255.255.255.0 RA(config-if)#no shut

Capítulo 4 - Roteiro de Atividades

dores e a tradução NAT.

161

%LDXX - Line protocol on Interface Ethernet 0, changed state to up RA(config-if)#int s0 RA(config-if)#clock rate 64000 RA(config-if)#ip address 200.2.2.18 255.255.255.252 RA(config-if)#no shut RA(config-if)# RA# 3. Os comandos de configuração do roteador RB estão listados abaixo.

RB>en RB#conf t RB(config)#int loopback0 RB(config-if)#ip address 172.16.1.1 255.255.255.255 %LDXX - Line protocol on Interface Loopback 0, changed state to up RB(config-if)#int s0 RB(config-if)#ip address 200.2.2.17 255.255.255.252 RB(config-if)#no shut %LDXX - Line protocol on Interface Serial 0, changed state to up RB(config-if)# RB# Observe que o comando no shut “levanta” a interface, tanto em hardware como em software. Porém, as interfaces seriais conectadas a um link WAN dependem uma da outra. Depois que a interface serial de RB estiver configurada, a interface serial de RA ficará “up”. Basta olhar o console de RA para verificar que s0 está “up”. Por outro lado, a interface “Loopback0” ficou no estado “up” assim que foi configurado o endereço, sem necessidade do comando no shut, porque ela é uma interface virtual e não depende do hardware para ser ativada.

Arquitetura e Protocolos de Rede TCP-IP

4. Crie uma rota estática do roteador do ISP para o roteador RA. Foram atribuídos os ende-

162

reços 199.99.9.32/27 para acesso à internet fora da empresa. Use os seguintes comandos:

RB#conf t RB(config)#ip route 199.99.9.32 255.255.255.224 200.2.2.18 RB(config)#ex RB#sh ip route

/* lista a tabela de rotas do roteador

A tabela de rotas deve ser como a mostrada a seguir.

172.16.1.1/32 is directly connected to Loopback 0

199.99.9.32/27 [1/0] via 200.2.2.18 00:00:06 S0

200.2.2.16/30 is directly connected to Serial 0

5. Adicione uma rota padrão do roteador RA para o roteador RB do ISP. Isso encaminhará

qualquer tráfego com endereço de destino desconhecido ao ISP. Use os seguintes comandos:

RA#conf t RA(config)#ip route 0.0.0.0 0.0.0.0 200.2.2.17 RA(config)#ex RA#sh ip route A tabela de rotas deve ser como a mostrada a seguir.

200.2.2.16/30 is directly connected to Serial 0

S* 0.0.0.0/0 [1/0] via 200.2.2.17 00:00:05 S0 C

10.10.10.0/24 is directly connected to Ethernet 0

Por que criamos uma rota padrão no sentido de RA para RB e uma rota estática no sentido oposto? Não poderia ser o mesmo tipo de rota nos dois sentidos?

Para testar a continuidade entre a rede interna e o roteador RB do ISP, a partir do PC2 vamos digitar o comando ping para a serial 0 do roteador RB. O resultado deve ser parecido com o mostrado na listagem a seguir:

C:>ping 200.2.2.17 Pinging 200.2.2.17 with 32 bytes of data: Ping request timed out. Ping request timed out. Ping request timed out.

C:> Como podemos perceber, o ping não funcionou. A razão disso é que os endereços internos da rede 10.10.10.0/24 não são roteáveis na internet. Assim, o ICMP echo request chega até o RB, mas o ICMP Echo reply nunca retorna. Falta configurar a tradução NAT.

Capítulo 4 - Roteiro de Atividades

Ping request timed out.

163

6. Para definir o conjunto de endereços IPv4 públicos utilizáveis para o NAT Dinâmico (reveja

o enunciado desta atividade), use os seguintes comandos:

RA#conf t RA(config)#ip nat pool nat_din 199.99.9.40 199.99.9.62 netmask 255.255.255.224 7. Para funcionar com NAT, o roteador Cisco RA exige que se defina um filtro dos endereços

IPv4 internos que serão traduzidos para os endereços IPv4 públicos. Esse filtro chama-se “lista de acesso”. Esta lista faz o mesmo papel que o iptables no Linux. Use os seguintes comandos:

RA(config)#access-list 1 permit 10.10.10.0 0.0.0.255 Caso o endereço IP não esteja no intervalo 10.10.10.0 – 10.10.10.255, o pacote será descartado, porque no final de toda lista de acesso está implícito um deny. 8. Vamos definir agora a tradução NAT Dinâmica da lista interna para o conjunto externo.

Use os seguintes comandos:

RA(config)#ip nat inside source list 1 pool nat_din 9. Para especificar as interfaces interna e externa do NAT, use os seguintes comandos:

RA(config)#int e0 RA(config-if)#ip nat inside RA(config-if)#int s0 RA(config-if)#ip nat outside 10. Repita o comando ping usado no item 5. Desta vez funciona, porque os endereços internos

da rede 10.10.10.0/24 estão traduzidos em endereços públicos através do NAT dinâmico.

C:>ping 200.2.2.17 Pinging 200.2.2.17 with 32 bytes of data: Reply from 200.2.2.17 on Eth, timeping 10.0.20.5 Pinging 10.0.20.5 with 32 bytes of data: Ping request timed out. Reply from 10.0.20.5 on Eth, timeenable Sw1#conf t Enter configuration commands, one per line.

End with CNTL/Z.

Sw1(config)#interface FastEthernet0/23 Sw1(config-if)#switchport mode trunk Vamos agora repetir o último teste: Execute o comando ping de Adm3 (IP: 10.0.20.9) da VLAN2 para Dir3 (IP: 10.0.30.4) da VLAN3.

C:>ping 10.0.30.4 Pinging 10.0.30.4 with 32 bytes of data: Ping request timed out. Reply from 10.0.30.4 on Eth, timeipconfig Configuração de IP do Windows Adaptador Ethernet Conexão local: Sufixo DNS específico de conexão. . . . . . : esr.rnp.br Endereço IPv6 de link local . . . . . . . . : fe80::6964:d7b1:6170:4ae4%10 Endereço IPv4. . . . . . . .

. . . . . . . : 192.168.100.130

Máscara de Sub-rede . . . . . . . . . . . . : 255.255.255.0 Gateway Padrão. . . . . . . . . . . . . . . : 192.168.100.1 Informações importantes obtidas da listagem acima: 1. Endereço IPv4 da estação: 192.168.100.130

Este endereço deverá aparecer nos pacotes capturados durante os testes, que veremos a seguir.

Arquitetura e Protocolos de Rede TCP-IP

2. Gateway padrão: 192.168.100.1

258

Este é o endereço do roteador que dá acesso à internet e é o primeiro hop da rede. 11 Servidor DNS para obtenção do endereço IP de destino. 11 Entrega indireta com tradução NAT. 11 Primeiro hop: gateway padrão; último: destino final. 11 3 roteadores intermediários (TTL vai até 4). Agora a listagem do comando traceroute para o sítio esr.rnp.br, a partir da unidade da ESR de Brasília.

C:\>tracert esr.rnp.br

Rastreando a rota para esr.rnp.br [200.130.35.73] com no máximo 30 saltos: 1

1 ms

192.168.100.1

2 ms

1 ms

200.130.26.254

1 ms

rt.pop-df.rnp.br [200.130.101.94]

1 ms

200.130.35.73

Rastreamento concluído. Informações importantes obtidas da listagem acima: 1. O comando traceroute teve como destino o sítio da web: www.esr.rnp.br, que foi traduzido

pelo servidor DNS (Serviço de Nome de Domínio) para o endereço IPv4: 200.130.35.73. Este será o endereço de destino dos pacotes que serão disparados pelo traceroute. 2. Visto que o endereço da estação é um endereço privado (192.168.100.130) e o endereço de

destino é um endereço público (200.130.35.73), que está em outra rede, podemos concluir: 2.1. Haverá uma entrega indireta, passando por pelo menos um roteador intermediário; 2.2. Haverá uma tradução NAT do endereço privado da estação, uma vez que o ende-

reço de destino é um endereço público que está em algum lugar da internet. 3. O primeiro hop, como não podia deixar de ser, é o gateway padrão da nossa rede:

192.168.100.1, visto na listagem anterior de configuração. 4. Temos 3 roteadores intermediários: 192.168.100.1 (gateway padrão), 200.130.26.254 e

200.130.101.94; portanto, o pacote que chegará ao destino tem obrigatoriamente TTL=4. 5. Da mesma forma que o primeiro hop é sempre o gateway padrão, o último hop é sempre

o destino final, no nosso caso um servidor, e não um roteador. Note que essa análise preliminar é essencial para o entendimento dos pacotes capturados. O software Wireshark simplesmente mostra o conteúdo dos pacotes, não fazendo a interpretação do que está ocorrendo. Esse é o nosso trabalho.

Captura de pacotes do primeiro hop 11 Consulta ao servidor DNS (com sucesso)

11 3 pacotes Echo (ping) request para TTL=1. 11 3 pacotes Time-to_live exceeded. 11 Consulta ao DNS reverso (sem sucesso). Vamos abrir o arquivo Trace_Captura.pcap com o Wireshark e analisar os pacotes capturados durante a execução do comando traceroute. A tela com os primeiros 10 pacotes está mostrada na Figura 6.14.

Capítulo 6 - Camada de rede

Figura 6.14 Arquivo de captura Wireshark Windows.

259

O pacote número 1 é uma consulta padrão ao servidor DNS (tipo A) para obter o endereço IP do nome: www.esr.rnp.br e o pacote número 2 é a resposta a essa consulta, informando que o endereço IP desejado é: 200.130.35.73. Obtido esse endereço, de agora em diante todos os pacotes serão disparados para esse destino. Por exemplo, o pacote 3 é um “Echo (ping) request” (mensagem Echo request – ICMP tipo 8) e o pacote 4 é um “Time-to-live exceeded” (mensagem Time exceeded – ICMP tipo 11), que é a resposta à mensagem anterior. Essa resposta é dada pelo gateway padrão, que é o primeiro roteador no caminho até o destino. Observe que o Wireshark informa, no pacote 3, que o TTL=1. É importante destacar que, ao invés de enviar datagramas UDP ao destino, o comando tracert no Windows envia mensagens ICMP Echo request. Os pacotes 5 a 8 são a repetição dessas mesmas mensagens com TTL=1 (lembre-se de que o traceroute sempre envia 3 pacotes de cada vez). Já o pacote 9 é uma consulta ao servidor DNS reverso, ou seja, é uma consulta tipo PTR para obter o nome da máquina com endereço IP: 192.168.100.1 (no caso é o gateway padrão). Esse tipo de consulta é sempre feito para um servidor específico no domínio “arpa”. O pacote 10 informa que não há nome registrado para esse endereço IP. A consulta ao servidor DNS tipo A (dado um nome, obter o endereço IP), também chamada de “resolução de nome”, é um tipo de consulta pública cujo funcionamento é mandatório, sob pena de o referido sítio nunca ser acessado (quem lembra o IP do www.google.com?). Por outro lado, a consulta ao DNS reverso é opcional, porque o nome não é essencial para o acesso ao equipamento. O traceroute tenta obter o nome do roteador por uma questão meramente informativa. Se não conseguir, imprime somente o endereço IP.

Demais pacotes 11 Pacotes 13 a 18 para TTL=2 – resposta dada pelo roteador seguinte.

11 Pacotes 25 a 30 para TTL=3 – resposta dada pelo terceiro roteador. 11 Pacotes 33 a 38 para TTL=4 – chegam até o destino final; a resposta não é mais “Time-to-live exceeded”; assim o traceroute fica sabendo que chegou ao destino. Os pacotes 13 a 18 repetem a mesma informação que os pacotes 3 a 8, agora para o TTL=2. Observe que o roteador que responde, nesse caso, é o seguinte ao gateway padrão no caminho até o destino: 200.130.26.254 (veja a listagem do comando traceroute). Os pacotes 25 a 30 repetem a mesma informação que os pacotes 3 a 8, agora para o TTL=3. Observe que, neste caso, o roteador que responde é o terceiro roteador no caminho até o Arquitetura e Protocolos de Rede TCP-IP

destino: 200.130.101.94. O pacote 31 tenta obter o nome desse roteador, e o pacote 32 é a

260

resposta bem-sucedida. O nome é: rt.pop-df.rnp.br. Os pacotes 33 a 38 repetem a mesma informação que os pacotes 3 a 8, agora para o TTL=4. Observe que neste caso quem responde é o destino final, com a mensagem “Echo (ping) reply” (mensagem Echo reply – ICMP tipo 0). Como o destino não é um roteador, ele não decrementa o TTL e simplesmente responde à mensagem “Echo (ping) request” (mensagem Echo resquest – ICMP tipo 8), como se estivesse recebendo um ping. Novamente, é importante destacar que, ao invés de enviar como resposta uma mensagem ICMP Destination unreachable, o destino envia uma mensagem ICMP Echo reply.

O traceroute do Windows usa um mecanismo diferente do Linux para obter a rota até o destino: usa somente mensagens ICMP, como se fosse o ping, apenas ajustando o TTL.

Exemplo de traceroute em Linux Vamos agora fazer a mesma análise para o Linux. A configuração da estação é a mesma. Mostramos a seguir a listagem do comando traceroute para o sítio ipv6.br. [email protected]:~$ traceroute ipv6.br traceroute to ipv6.br (200.160.4.22), 30 hops max, 60 byte packets 1 192.168.100.1 (192.168.100.1) 2.248 ms 2.439 ms 9.990 ms 2 200.130.26.254 (200.130.26.254) 15.331 ms 16.599 ms 16.876 ms 3 xe-2-0-0-2910-r0-df.bkb.rnp.br (200.143.255.169) 15.405 ms 15.629 ms 16.949 ms 4 xe-3-1-1-3000-r0-rj.bkb.rnp.br (200.143.252.77) 27.937 ms xe-2-1-1-3000-r0-mg.bkb.rnp. br (200.143.252.81) 27.136 ms xe-3-1-1-3000-r0-rj.bkb.rnp.br (200.143.252.77) 30.320 ms 5 xe-3-1-0-3000-r0-sp.bkb.rnp.br (200.143.252.73) 38.430 ms 39.088 ms xe-2-1-0-3000-r0sp.bkb.rnp.br (200.143.252.69) 40.063 ms 6 as22548.sp.ptt.br (187.16.217.2) 40.609 ms 28.587 ms 28.665 ms 7 xe-5-1-0-0.core2.nu.registro.br (200.160.0.172) 29.296 ms 30.900 ms 31.354 ms 8 ae0-0.ar4.nu.registro.br (200.160.0.250) 32.806 ms 33.315 ms 34.282 ms 9 ipv6.br (200.160.4.22) 34.856 ms 35.413 ms 37.786 ms

[email protected]:~$ Informações importantes obtidas da listagem acima: 1. O comando traceroute teve como destino o sítio da web: ipv6.br, que foi traduzido pelo

servidor DNS (Serviço de Nome de Domínio) para o endereço IPv4: 200.160.4.22. Este será o endereço de destino dos pacotes que serão disparados pelo traceroute. 2. Visto que o endereço da estação é um endereço privado (192.168.100.130) e o endereço de

destino é um endereço público (200.160.4.22), que está em outra rede, podemos concluir: 2.1. Haverá uma entrega indireta, passando por pelo menos um roteador intermediário. 2.2. Haverá uma tradução NAT do endereço privado da estação, uma vez que o ende-

reço de destino é um endereço público que está em algum lugar da internet.

192.168.100.1, visto na listagem anterior de configuração. 4. Temos 8 roteadores intermediários: 192.168.100.1 (gateway padrão), 200.130.26.254,

200.143.255.169, 200.143.252.77, 200.143.252.73, 187.16.217.2, 200.160.0.172 e 200.160.0.250; portanto, o pacote que chegará ao destino tem obrigatoriamente TTL=9. 5. Da mesma forma que o primeiro hop é sempre o gateway padrão, o último hop é sempre

o destino final, que no nosso caso é um servidor e não um roteador.

Capítulo 6 - Camada de rede

3. O primeiro hop, como não podia deixar de ser, é o gateway padrão da nossa rede:

261

Vamos abrir o arquivo Trace_Captura_Linux.pcap com o Wireshark e analisar os pacotes capturados durante a execução do comando traceroute. A tela com os primeiros 10 pacotes está mostrada na Figura 6.15.

11 Comando traceroute.

11 Servidor DNS para obtenção do endereço IP de destino. 11 Entrega indireta, com tradução NAT. 11 Primeiro hop: gateway padrão. 11 Último hop: destino final. 11 8 roteadores intermediários (TTL vai até 9). O pacote número 1 é uma consulta padrão ao servidor DNS (tipo A) para obter o endereço IP do nome: ipv6.br e o pacote número 2 é a resposta a essa consulta, informando que o endereço IP desejado é: 200.160.4.22. Obtido esse endereço, todos os pacotes de agora em diante serão disparados para esse destino. Por exemplo, os pacotes de número 3 até 18 usam o protocolo UDP com números de porta que não existem no destino (números de porta muito altos), de forma a forçar uma resposta de porta UDP inexistente no destino final. Mas como o TTL inicia em 1 e vai crescendo, chegam as mensagens de erro “Time-to-live exceeded” (mensagem Time exceeded – ICMP tipo 11) dos roteadores intermediários (por exemplo, os pacotes de número 19 e 20, entre outros). Já o pacote 51 é uma consulta ao servidor DNS reverso, ou seja, é uma consulta tipo PTR com o objetivo de obter o nome da máquina que tem o endereço IP: 200.143.255.169 (no caso é um roteador intermediário). Esse tipo de consulta é sempre feito para um servidor específico no domínio “arpa”. E o pacote 52 informa o nome: xe-2-0-0-2910-r0-df.bkb.rnp.br. Essa sequência de pacotes se repete várias vezes, uma vez que foi necessário passar por 8 roteadores intermediários no caminho até o destino final e o traceroute envia 3 pacotes para cada hop, com o mesmo TTL.

Arquitetura e Protocolos de Rede TCP-IP

Vamos agora analisar em detalhe a sequência de pacotes enviada pelo host 192.168.100.130

262

para o destino 200.160.4.22, usando o protocolo UDP e que provocou igual sequência de respostas “Destination unreachable (Port unreachable)” (mensagem Destination unreachable – ICMP tipo 3). Vimos pela listagem do comando traceroute que o destino final estava no hop 9, portanto, os pacotes com TTL=9 (ou maior) chegaram até o destino final, porque passaram pelos 8 roteadores intermediários e, no destino final, provocaram a mensagem de erro ICMP acima referida. Para saber o TTL, precisamos selecionar o pacote na primeira janela do Wireshark, selecionar a linha do protocolo IP na janela imediatamente abaixo (segunda janela), clicar no ícone do sinal “+” na primeira posição à esquerda da linha.

Figura 6.15 Arquivo de captura Wireshark Linux.

Analisando a sequência de pacotes UDP, vemos que o pacote 72 é o primeiro com TTL=9, seguido pelos pacotes 73 e 74 também com TTL=9. Esses pacotes chegaram com certeza até o destino final, mas como a resposta demorou para voltar, o traceroute continuou emitindo pacotes UDP e aumentando o TTL, até que começaram a chegar as respostas do destino final.

11 Consulta ao servidor DNS. 11 Pacotes 3 a 18: protocolo UDP. 22 Mensagens de erro Time-to-live exceeded 11 Pacote 51: consulta ao DNS reverso (com sucesso). 11 Pacote 52: nome Xe-2-0-02910-r0-df.bkb.rnp.br. 11 Sequência repetida várias vezes: 22 8 roteadores intermediários. 22 3 pacotes para cada hop com o mesmo TTL. 11 TTL = 9 ou acima chegam até o destino final. 22 Provocam a mensagem de erro Destination unreachable. 11 Resumo dos pacotes com TTL = 9 ou maior. 22 Pacotes 72 a 80. 22 Pacotes 82, 91, 100. 22 Pacotes 102 a 105. 11 Total: 16. TTL

72 a 74

75 a 77

78 a 80

82, 91, 100

102 a 104

105

Total de pacotes com TTL=9 ou maior: 16. Resumo das mensagens de erro do destino final:

11 Pacotes 92, 94 a 97. 11 Pacotes 99, 101, 107 e 108. 11 Pacotes 110 a 116. 11 Total: 16. 11 Note que o TTL na resposta = 56 (64 – 8). 11 Parâmetro –I força o uso de mensagens ICMP Echo request e Echo reply.

Capítulo 6 - Camada de rede

Figura 6.16 Resumo dos pacotes UDP enviados com TTL=9 ou maior.

Número

263

Número

TTL

94 a 97

99, 101

107, 108

110 a 116

Esses 16 pacotes que chegaram com certeza até o destino final devem ter provocado igual número de mensagens de erro ICMP Destination unreachable (Port unreachable). Total de pacotes de resposta: 16. Note que em todos os pacotes o TTL = 56, porque por padrão, o pacote é enviado com TTL = 64 e passa por 8 roteadores intermediários (64 – 8 = 56). Se quiser que o traceroute do Linux use o mesmo esquema do Windows (somente mensagens ICMP Echo request e Echo Reply), use a opção –I na linha de comando. Resumindo: observe que os datagramas UDP são sempre enviados da estação origem 192.168.100.130 para a estação destino 200.160.4.22. A estação origem usa a porta UDP 46446 e outras portas de número alto nos pacotes seguintes. No entanto, o traceroute usa uma porta possivelmente inexistente no destino, que é incrementada a cada novo datagrama UDP. Nesse caso, a porta UDP de destino varia de 33434 (padrão traceroute) a 33473. Nos três primeiros datagramas UDP, o TTL é 1. Assim, o primeiro roteador do caminho (192.168.100.1) descarta esses datagramas, enviando uma mensagem Time exceeded para cada um deles. Nos últimos datagramas UDP com TTL=9 ou maior, a estação destino já foi alcançada. Nesse caso, como não existe um processo recebendo pacotes nas portas UDP 33458 e acima, a estação destino descarta esses datagramas, enviando a mensagem Port unreachable, um subtipo da mensagem Destination unreachable, para cada um deles. É dessa forma criativa que o comando traceroute consegue mostrar o caminho pelo qual um data-

Arquitetura e Protocolos de Rede TCP-IP

grama passa da origem até o seu destino.

264

Figura 6.17 Resumo dos pacotes com mensagens de erro ICMP.

Roteiro de Atividades 6 Atividade 6.1 – Campo TTL Na figura mostrada a seguir, a estação E1 está gerando datagramas IP com TTL igual a 2. Na operação normal da rede, E1 envia datagramas para E2 via o roteador R3. No entanto, quando a estação E1 perde a conectividade com o roteador R3, ela envia datagramas para E2 via o roteador R1.

1. Os datagramas são entregues à estação E2 em ambos os casos? Explique.

2. Alguma mensagem de erro é gerada? Qual?

3. Quando e por que a mensagem de erro é gerada? Para quem a mensagem de erro é enviada?

Capítulo 6 - Roteiro de Atividades

Figura 6.18 Rede da Atividade 6.1

265

Atividade 6.2 – Funcionamento do TTL 1. Inicie o Virtual Box e selecione a opção “Open a Virtual Machine”, selecione a máquina

virtual “vcore-4.2” no diretório que o instrutor indicar, e inicie esta máquina virtual. 2. Aguarde a carga completa da máquina virtual CORE. Essa máquina virtual possui ins-

talado um simulador de protocolos de roteamento, que usaremos de agora em diante. Execute o simulador CORE. 3. Selecione “File” no menu, selecione a opção “Open” e localize o diretório onde se encontra

a rede: “Rede_Atividade6_2.imn”, seguindo a orientação do instrutor. 4. A rede deverá ser igual à Figura 6.19.

Rede2 eth2 10.0.2.1/24

e0 e1

eth0 10.0.0.2/24

eth0 10.0.2.2/24

e1 eth0 10.0.0.10/24

Figura 6.19 Rede da Atividade 6.2.

Rede0

eth2 10.0.1.2/24

eth0 10.0.0.1/24

eth2 10.0.1.1/24

eth0 10.0.1.10/24

Rede1

5. Os endereços IPv4 já estão configurados, conforme mostrado na figura. Há 3 redes físicas

representadas pelos switches Rede0, Rede1 e Rede2. Cada rede física tem um prefixo de

Arquitetura e Protocolos de Rede TCP-IP

rede diferente, conforme a Figura 6.20. Rede

Endereço de rede

Gateway padrão

Nome PC

Endereço PC

Rede0

10.0.0.0/24

10.0.0.1

10.0.0.10/24

Rede1

10.0.1.0/24

10.0.1.1

10.0.1.10/24

Rede2

10.0.2.0/24

6. O modo inicial de operação do simulador é o Modo de Edição. Este modo é utilizado para

desenhar a rede e configurar o endereçamento IPv4. Para efetivamente executar os protocolos de roteamento e as aplicações, é necessário iniciar o experimento, que pode ser feito de duas maneiras: 11 Clicando no ícone

à esquerda na barra de ferramentas;

11 Selecionando no menu superior a opção Experiment/Start. 266

Figura 6.20 Endereços IPv4 da rede da Atividade 6.2.

No Modo de Experimento não é possível fazer edição da topologia da rede (note a barra de ferramentas modificada). Aguarde até que toda a rede seja iniciada, até desaparecerem os colchetes vermelho/verde em cada nó da rede. 7. Vamos testar o comando ping com TTL=2 da estação E1 para a estação E2. Siga o seguinte

procedimento: 11 Aponte com o mouse para E1, clique no botão direito e selecione a opção Shell window/bash. No console do E1 digite o comando ping para E2:

[email protected]:/tmp/pycore.39156/E1.conf# ping –c 2 –t 2 10.0.1.10 O resultado deve ser semelhante ao listado a seguir:

PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data. 64 bytes from 10.0.1.10: icmp_req=1 ttl=2 time=15.4ms 64 bytes from 10.0.1.10: icmp_req=2 ttl=2 time=1.00ms --- 10.0.1.10 ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1013ms rtt min/avg/max/mdev = 1.009/8.227/15.446/7.219 ms [email protected]:/tmp/pycore.39156/E1.conf# Com TTL=2 funcionou, porque a rota seguida pelos datagramas de E1 para E2 passa por apenas um roteador: R3. Para confirmar isso, vamos executar o comando traceroute no console do E1. O resultado deve ser semelhante ao listado a seguir:

[email protected]:/tmp/pycore.39156/E1.conf# traceroute –n 10.0.1.10 traceroute to 10.0.1.10 (10.0.1.10), 30 hops max, 60 bytes packet 1 10.0.0.1 (10.0.0.1) 1.185 ms 0.485 ms 0.166 ms 2 10.0.1.10 (10.0.1.10) 20.983 ms 1.523 ms 0.370 ms [email protected]:/tmp/pycore.39156/E1.conf# A opção “-n” evita a consulta ao servidor DNS para resolução de nomes. Como não existe servidor DNS configurado, o comando aguarda o “timeout” do DNS e a execução fica muito demorada. 8. Vamos forçar a rota pelo roteador R1. Para isso, simplesmente mudaremos a tabela de

rotas da estação E1. Para ver a tabela de rotas da estação E1, digite o comando a seguir.

Kernel IP routing table Destination

Gateway

Genmask

10.0.0.0

0.0.0.0

255.255.255.0

0 eth0

0.0.0.0

10.0.0.1

0.0.0.0

0 eth0

[email protected]:/tmp/pycore.39156/E1.conf#

Flags Metric Ref Use Iface

Capítulo 6 - Roteiro de Atividades

[email protected]:/tmp/pycore.39156/E1.conf# route –n

267

Para alterar a rota padrão da estação E1, vamos excluir a rota padrão pelo roteador R3 e incluir uma rota padrão pelo roteador R1. Siga o seguinte procedimento:

[email protected]:/tmp/pycore.39156/E1.conf# route del default gw 10.0.0.1 [email protected]:/tmp/pycore.39156/E1.conf# route add default gw 10.0.0.2 [email protected]:/tmp/pycore.39156/E1.conf# route –n Kernel IP routing table Destination

Gateway

Genmask

Flags Metric Ref Use Iface

10.0.0.0

0.0.0.0

255.255.255.0

0 eth0

0.0.0.0

10.0.0.2

0.0.0.0

0 eth0

[email protected]:/tmp/pycore.39156/E1.conf# Pronto. Agora a rota padrão de E1 aponta para o roteador R1. 9. Repita o comando ping com TTL=2, conforme a seguir.

[email protected]:/tmp/pycore.39156/E1.conf# ping –c 2 –t 2 10.0.1.10 PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data. From 10.0.2.2 icmp_seq=1 Time to live exceeded From 10.0.2.2 icmp_seq=2 Time to live exceeded --- 10.0.1.10 ping statistics --2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1005ms [email protected]:/tmp/pycore.39156/E1.conf#

Observe que foi o roteador R2 que enviou as mensagens de erro. 10. Para confirmar, repita o mesmo comando, agora com TTL=3.

[email protected]:/tmp/pycore.39156/E1.conf# ping –c 2 –t 3 10.0.1.10 PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.

Arquitetura e Protocolos de Rede TCP-IP

64 bytes from 10.0.1.10: icmp_req=1 ttl=3 time=14.0ms

268

64 bytes from 10.0.1.10: icmp_req=2 ttl=3 time=1.37ms --- 10.0.1.10 ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1013ms rtt min/avg/max/mdev = 1.376/7.712/14.049/6.337 ms [email protected]:/tmp/pycore.39156/E1.conf#

Funcionou, conforme mostrado acima. Finalmente, use o comando traceroute para confirmar a rota dos datagramas.

[email protected]:/tmp/pycore.39156/E1.conf# traceroute –n 10.0.1.10 traceroute to 10.0.1.10 (10.0.1.10), 30 hops max, 60 bytes packet 1 10.0.0.2 (10.0.0.2) 0.976 ms 0.213 ms 0.143 ms 2 10.0.2.2 (10.0.2.2) 0.177 ms 0.172 ms 0.203 ms 3 10.0.1.10 (10.0.1.10) 0.466 ms 0.340 ms 0.302 ms [email protected]:/tmp/pycore.39156/E1.conf#

Atividade 6.3 – Remontagem no destino O processo de fragmentação de datagramas pode ocorrer em diversos roteadores intermediários. Porém, o processo de remontagem ocorre somente no destino final. Identifique e comente possíveis vantagens e desvantagens dessa abordagem.

Atividade 6.4 – Descobrindo a MTU Uma determinada rede física limita o tamanho máximo do quadro a 1500 bytes, sendo 100 bytes de cabeçalho e 1400 bytes de dados. Qual a MTU dessa rede? Qual o maior datagrama IP que pode ser encapsulado em um quadro dessa rede? Qual a maior quantidade de dados que um datagrama IP pode transportar nessa rede?

Atividade 6.5 – Descobrindo tamanhos de datagramas Um determinado datagrama IP possui Total length e Hlen iguais a 1500 e 8, respectivamente.

2. Qual o tamanho do cabeçalho deste datagrama em bytes?

Capítulo 6 - Roteiro de Atividades

1. Qual o tamanho total deste datagrama em bytes?

269

3. O campo Options é utilizado?

Atividade 6.6 – Fragmentação Na figura a seguir, considere que a estação E1 envia dois datagramas para a estação E2. Esses datagramas possuem 500 e 200 bytes, incluindo o cabeçalho de 20 bytes.

MTU=500

N2 MTU=200

MTU=500

1. A fragmentação é necessária?

2. Em caso afirmativo, adotando o esquema da figura acima, apresente o datagrama original

Arquitetura e Protocolos de Rede TCP-IP

e os respectivos fragmentos.

270

7 Apresentar os conceitos básicos de roteamento, descrever os protocolos de roteamento RIP, OSPF e BGP, apresentando suas características principais e sua configuração básica.

conceitos

Roteamento em redes IP e conceitos básicos de protocolos de roteamento.

Este capítulo trata de roteamento em redes IP e explora os conceitos básicos de protocolos de roteamento, descrevendo os protocolos básicos de maneira simplificada, pois não é objetivo deste curso tratar em detalhes o roteamento.

Roteamento TCP/IP 11 Inter-rede TCP/IP

22 Composta por um conjunto de redes físicas interconectadas por roteadores. 11 Roteador 22 Roteia datagramas entre essas redes. 22 Recebe datagramas nas várias interfaces. 22 Escolhe rotas através de outras interfaces. 22 Encaminha datagramas através das interfaces selecionadas. 11 Roteamento 22 Processo de escolha das rotas para envio dos datagramas, permitindo que eles alcancem seus destinos através de diversas redes e roteadores intermediários. Sabemos que a estrutura de interconexão de inter-redes TCP/IP é composta por um conjunto de redes físicas interconectadas por roteadores. Nessa estrutura, o papel dos roteadores é interconectar as redes físicas e rotear datagramas IP entre essas redes. Em outras palavras, um roteador é capaz de receber datagramas nas suas várias interfaces de rede, escolher rotas através de interfaces conectadas às outras redes físicas e, por fim, encaminhar esses datagramas através dessas interfaces selecionadas. Por exemplo, na Figura 7.1, quando a estação E1 deseja enviar datagramas para a estação E9, ela roteia os datagramas para o roteador R3, através da interface conectada à rede N1. Por sua vez, R3 entrega diretamente os datagramas para a estação E9 através da interface conectada à rede N5.

Capítulo 7 - Roteamento

objetivos

Roteamento

271

Os roteadores não proveem conexão direta entre todas as redes físicas. Consequentemente, para alcançar um determinado destino, pode ser necessário encaminhar os datagramas através de diversos roteadores e redes intermediárias. Por exemplo, na Figura 7.1, datagramas enviados da estação E1 à estação E8 devem ser encaminhados através dos roteadores R3 e R4, sendo, desta forma, transmitidos nas redes N1, N5 e N4. Além disso, podem existir diversas rotas alternativas para encaminhar os datagramas entre alguns pares de estações. Por exemplo, quando a estação E1 deseja transmitir datagramas para a estação E5, os roteadores R1 e R3 se apresentam como possíveis rotas alternativas

Gateway

até o destino. Portanto, E1 pode encaminhar os datagramas para R1 ou R3 através da

Sinônimo de roteador na arquitetura TCP/IP. Em outras arquiteturas de redes, um gateway é um dispositivo (hardware ou software) que converte mensagens de um protocolo em mensagens de outro protocolo.

interface conectada à rede N1. Com base nisso, podemos definir o processo de roteamento como sendo a escolha dos caminhos (rotas) a serem usados para enviar os datagramas, de modo a permitir que alcancem seus respectivos destinos finais, possivelmente através de diversas redes e roteadores intermediários. Dito de outra forma, o processo de roteamento determina a rota que cada datagrama deve seguir para alcançar a estação destino, indicada no cabeçalho do datagrama. É importante lembrar que roteadores são também conhecidos como gateways ou sistemas intermediários, na família de protocolos TCP/IP. Roteadores não são necessariamente equipamentos especializados na função de roteamento, mas podem ser estações multihomed

Estações multihomed

que possuem a função de roteamento configurada.

Estações convencionais com várias conexões físicas.

E2 R2

Arquitetura e Protocolos de Rede TCP-IP

Para realizar o processo de roteamento, as implementações do protocolo IP devem ser projetadas levando em consideração diversos conceitos associados à função de roteamento, bem como alguns componentes de software. Neste capítulo, cada um desses conceitos e componentes será detalhado.

Algoritmo de roteamento 11 Procedimento de tomada das decisões de roteamento para cada datagrama. 11 Implementado em todos os roteadores e estações da inter-rede.

272

Figura 7.1 Inter-rede TCP/IP.

11 Encaminha os datagramas até seus respectivos destinos finais.

11 Descobre a melhor rota até o destino final de cada datagrama.

Conjunto de regras adotadas pelo protocolo IP para descobrir a melhor rota até o destino final de cada datagrama.

Para rotear os datagramas, as implementações do protocolo IP adotam um algoritmo de roteamento bem definido e conhecido, cuja finalidade é tomar as decisões de roteamento para cada datagrama, encaminhando-o ao seu destino final. Portanto, o objetivo do algoritmo de roteamento é descobrir a melhor rota até o destino final de cada datagrama. Obviamente, todos os roteadores implementam o algoritmo de roteamento, pois estão diretamente envolvidos nesse processo. Além deles, as estações também tomam decisões de roteamento. No exemplo em que a estação E1 envia datagramas à estação E5, E1 deve tomar decisões de roteamento, escolhendo se encaminha os datagramas através do roteador R1 ou R3, pois cada um deles provê uma rota possível para E5. Portanto, da mesma forma que os roteadores, todas as estações devem implementar o algoritmo de roteamento. O algoritmo de roteamento adotado na arquitetura TCP/IP é diferente para cada arquitetura de endereçamento (classful e classless). Mais à frente, discutiremos os algoritmos de roteamento adotados nas duas arquiteturas de endereçamento.

Métricas de roteamento Parâmetros adotados pelo algoritmo de roteamento para selecionar as melhores rotas.

11 Comprimento da rota. 11 Retardo. 11 Confiabilidade. 11 Taxa de transmissão. 11 Carga. 11 Tamanho do datagrama. 11 Tipo de serviço. Métricas são parâmetros qualitativos e operacionais adotados por um algoritmo de roteamento para definir a melhor rota a ser usada, preferindo uma rota específica a outras possíveis. Como podem existir múltiplas rotas para um determinado destino, o algoritmo de roteamento deve utilizar parâmetros qualitativos para definir a melhor rota a ser usada. Idealmente, o algoritmo de roteamento deve considerar alguns parâmetros operacionais da rede, evitando a seleção de rotas que encaminham os datagramas através de porções da rede que estão congestionadas ou falhando. Os parâmetros qualitativos e operacionais adotados por um algoritmo de roteamento são denominados métricas de roteamento. Diversas métricas podem ser usadas pelos algoritmos de roteamento: 11 Comprimento da rota – número de roteadores ao longo do caminho. 11 Retardo – tempo necessário para os bits transmitidos alcançarem o destino. 11 Confiabilidade – probabilidade de ocorrência de erros de transmissão. 11 Taxa de transmissão – número de bits que podem ser transmitidos por unidade de tempo. 11 Carga – percentual de utilização dos enlaces. 11 Tamanho do datagrama (MTU) – pode ser usado para evitar a fragmentação. 11 Tipo de serviço requerido – define a importância das demais métricas de roteamento

Capítulo 7 - Roteamento

Algoritmo de roteamento

na seleção da rota. 273

No entanto, as implementações dos algoritmos de roteamento são menos sofisticadas e, geralmente, selecionam rotas baseadas em um subconjunto reduzido dessas métricas de roteamento, ou apenas uma única métrica.

Métrica da rota 11 Número inteiro não negativo que indica a qualidade da rota.

11 Derivada das métricas de roteamento. 11 Algoritmos de roteamento adotam um número reduzido de métricas de roteamento. 11 Métricas de roteamento são aplicadas a uma equação bem definida, gerando a métrica ou custo da rota. 11 Quanto menor a métrica, melhor a rota. As métricas de roteamento adotadas são aplicadas a uma equação bem conhecida, gerando o conceito de custo ou métrica da rota. Na prática, a métrica de uma rota é apenas um número inteiro não negativo que indica a qualidade da rota. Consequentemente, adotando a perspectiva de custo, quanto menor a métrica de uma rota, então melhor será esta rota. Por exemplo, uma rota de custo 5 é melhor que outra rota de custo 10. Portanto, com base nas métricas das rotas possíveis, o algoritmo de roteamento toma as decisões de roteamento para cada datagrama. Vale ressaltar que existe uma distinção entre métricas de roteamento e métricas de rotas. As métricas de roteamento são os parâmetros qualitativos ou operacionais usados para derivar as métricas (custos) das rotas. No entanto, muitas vezes, esses termos são usados com o mesmo significado, principalmente quando uma única métrica de roteamento é usada para derivar a métrica das rotas. Resumo Após receber um datagrama, o algoritmo de roteamento identifica as possíveis rotas para o destino do datagrama, avalia as métricas associadas a cada uma dessas rotas e, então, seleciona a rota de menor métrica.

Tabela de roteamento 11 Mantém informações de roteamento para todas as redes físicas da inter-rede.

11 Descreve a topologia geral da inter-rede. 11 Identifica rotas para todos os destinos. 11 Sinaliza os custos das rotas, provendo a noção de melhor rota para cada destino.

Arquitetura e Protocolos de Rede TCP-IP

11 Direciona as decisões de roteamento realizadas pelo algoritmo de roteamento.

274

11 Existe em todos os roteadores e estações da inter-rede. 11 Adota um modelo de roteamento baseado em redes. 22 Mantém rotas que apontam para prefixos de rede e não para estações individuais. 22 Reduz a quantidade de informações armazenadas. 22 Melhora a eficiência do roteamento. 22 Torna o tamanho da tabela dependente do número de redes, mas independente do número de estações. Estrutura de dados que mantém informações que descrevem a topologia geral da inter-rede, identificando rotas para todos os possíveis destinos e a melhor forma de alcançá-los. Para ser

capaz de rotear corretamente os datagramas, os algoritmos de roteamento dos roteadores e estações precisam conhecer a topologia geral de toda a inter-rede, e não apenas das redes físicas às quais estão diretamente conectados. Assim, os algoritmos de roteamento precisam manter informações de roteamento para todas as redes físicas que compõem a inter-rede TCP/IP. Essas informações de roteamento são armazenadas na tabela de roteamento. A noção de melhor rota para cada destino é sinalizada nos custos das respectivas rotas possíveis, derivados a partir das métricas de roteamento adotadas. Assim, as tabelas de roteamento direcionam todas as decisões realizadas pelos algoritmos de roteamento. Em cada roteador ou estação, sempre que a camada de rede precisa enviar datagramas, o algoritmo de roteamento consulta a tabela de roteamento para descobrir a rota a ser adotada para encaminhar cada datagrama. Portanto, considerando que roteadores e estações implementam algoritmos de roteamento, concluímos que ambos possuem tabelas de roteamento. É importante lembrar que os esquemas de endereçamento pressupõem que todas as interfaces conectadas a uma rede física compartilham um prefixo de rede, sub-rede ou bloco. Essa característica permite que as tabelas de roteamento possuam apenas informações sobre os prefixos de rede, ao invés de informações sobre estações individuais. Portanto, a arquitetura TCP/IP adota um modelo de roteamento baseado em redes, ao invés de estações. Em outras palavras, as rotas das tabelas de roteamento apontam para as redes, e não para as estações individuais. Essa abordagem torna mais eficiente o roteamento, pois reduz sensivelmente a quantidade de informações mantidas na tabela de roteamento. Considerando o modelo de roteamento baseado em redes, podemos concluir que o tamanho da tabela de roteamento depende da quantidade de redes físicas e/ou blocos que compõem a inter-rede, variando à medida que redes e/ou blocos são acrescentados ou removidos. Por outro lado, o tamanho das tabelas de roteamento é independente do número de estações existentes na inter-rede.

Protocolo de roteamento 11 Mecanismo que implementa a atualização automática das tabelas de roteamento nos

roteadores. 11 Permite a definição de tabelas completas e consistentes. 11 Atualizações são realizadas a partir das informações de roteamento propagadas e trocadas entre roteadores. 11 Propagações sinalizam mudanças operacionais das várias redes físicas. 11 Diversos protocolos são padronizados: 22 RIP (Routing Information Protocol). 22 OSPF (Open Shortest Path First).

11 Características operacionais diferenciam os protocolos de roteamento: 22 Número de caminhos. 22 Propagação das rotas. 22 Organização estrutural. 22 Hierarquia de roteamento. 22 Propagação de máscaras.

Capítulo 7 - Roteamento

22 BGP (Border Gateway Protocol).

275

Já vimos que os algoritmos de roteamento adotam métricas de roteamento para derivar os custos das várias rotas possíveis. Nesse processo, as métricas de roteamento permitem que os algoritmos de roteamento evitem porções da rede congestionadas ou com falha. No entanto, considerando que as condições operacionais das várias redes físicas podem variar a cada momento, as métricas de roteamento devem ser atualizadas para refletir as mudanças ocorridas na inter-rede. Como as tabelas de roteamento mantêm os custos das várias rotas, essas tabelas devem, consequentemente, ser sempre atualizadas para refletir as mudanças na situação operacional das várias redes físicas. Observe que mudanças no conteúdo das tabelas de roteamento modificam os caminhos que os datagramas devem seguir. Para atualizar as tabelas de roteamento, certo grau de cooperação dinâmica é necessário entre os roteadores. Em particular, roteadores devem trocar informações de roteamento que sinalizam as mudanças operacionais das várias redes físicas. Para tal, protocolos específicos devem ser usados para viabilizar a propagação e a troca de informações de roteamento entre roteadores. Tais protocolos são denominados protocolos de roteamento. Em resumo, podemos definir um protocolo de roteamento como um mecanismo que implementa a atualização automática das tabelas de roteamento nos diversos roteadores. As atualizações são realizadas a partir das informações de roteamento trocadas entre os roteadores, permitindo a definição de tabelas completas e consistentes. Por tabelas completas, entende-se as que possuem rotas para todos os possíveis destinos. Por tabelas consistentes, entende-se as que possuem rotas válidas que consideram a situação operacional atual das várias redes físicas. Existem diversos protocolos de roteamento padronizados na arquitetura TCP/IP. Dentre esses, os protocolos RIP (Routing Information Protocol), OSPF (Open Shortest Path First) e BGP (Border Gateway Protocol) são os principais, por serem os mais adotados na prática. Vale ressaltar que o objetivo aqui não é o de estudar e avaliar detalhadamente os protocolos de roteamento padronizados na arquitetura TCP/IP, mas apenas identificar as principais características operacionais que os diferenciam.

Número de caminhos 11 Caminho único

22 Instala uma única rota para cada destino. 11 Múltiplos caminhos 22 Instala, quando possível, diversas rotas para cada destino.

Arquitetura e Protocolos de Rede TCP-IP

Os protocolos de roteamento podem inserir diferentes rotas para um mesmo destino na

276

tabela de roteamento: 11 Protocolo de caminho único – insere uma única rota para cada destino (exemplo: protocolo RIP). 11 Protocolo de múltiplos caminhos – insere, quando possível, diversas rotas para cada destino (exemplo: protocolo OSPF).

Propagação de rotas 11 Vetor-distância 22 Periodicamente, envia informações de roteamento aos roteadores vizinhos. 22 Propagações são realizadas de forma independente das mudanças operacionais.

11 Estado de enlace

22 Envia a todos os roteadores informações sobre as redes físicas (enlaces) diretamente conectadas. 22 Novas propagações somente são realizadas após mudanças operacionais nos enlaces. Os mecanismos de propagação de rotas também diferenciam os diversos protocolos de roteamento. Em termos gerais, existem dois mecanismos de propagação: 11 Vetor-distância (distance-vector) – este tipo de protocolo envia, periodicamente, informações da tabela de roteamento apenas aos roteadores vizinhos, independentemente da ocorrência ou não de mudanças operacionais nas redes físicas (exemplo: protocolo RIP). 11 Estado de enlace (link-state) – este tipo de protocolo, inicialmente, propaga a todos os roteadores da inter-rede, informações sobre as redes físicas (enlaces) diretamente conectadas e, posteriormente, realiza novas propagações somente após mudanças no estado destes enlaces (exemplo: protocolo OSPF).

Organização estrutural 11 Estrutura plana

22 Roteadores desempenham o mesmo papel, realizando as mesmas funções. 11 Estrutura hierárquica 22 Roteadores são organizados de forma hierárquica, desempenhando diferentes papéis. 22 Função de cada roteador depende de sua localização física na inter-rede. Alguns protocolos de roteamento definem diferentes funções para os roteadores, de acordo com a localização física desses roteadores dentro da inter-rede. Disso derivam, por consequência, diferentes organizações estruturais: 11 Estrutura plana – adotada por um protocolo quando todos os roteadores desempenham o mesmo papel (exemplo: protocolo RIP). 11 Estrutura hierárquica – adotada por um protocolo quando os roteadores são organizados hierarquicamente, desempenhando diferentes papéis nessa hierarquia (exemplo: protocolo OSPF).

Hierarquia de roteamento 11 IRP (Interior Routing Protocol)

22 Protocolo de roteamento adotado dentro de sistemas autônomos. 11 ERP (Exterior Routing Protocol) 22 Protocolo de roteamento adotado entre sistemas autônomos.

controladas por uma única autoridade administrativa é chamado de Sistema Autônomo (AS – Autonomous System). Dessa forma, a internet é composta por um conjunto de sistemas autônomos interconectados. Dentro de um determinado sistema autônomo, a autoridade administrativa possui autonomia para selecionar o protocolo de roteamento a ser adotado. Logo, podemos classificar os protocolos de roteamento de acordo com a sua área de abrangência: 11 Protocolos de roteamento interior (IRP – Interior Routing Protocol) – protocolos de roteamento

Capítulo 7 - Roteamento

Para organizar e administrar a propagação de rotas na internet, um conjunto de redes

que podem ser adotados dentro de sistemas autônomos (exemplo: protocolos RIP e OSPF). 277

11 Protocolos de roteamento exterior (ERP – Exterior Routing Protocol) – protocolos de roteamento que podem ser adotados entre sistemas autônomos (exemplo: protocolo BGP).

Propagação de máscaras 11 Protocolo classful

22 Não inclui as máscaras de rede quando propaga informações de roteamento. 11 Protocolo classless 22 Inclui as máscaras de rede quando propaga informações de roteamento. Por fim, da mesma forma que os esquemas de endereçamento, os protocolos de roteamento também são classificados em protocolos classful e classless. A única diferença é a capacidade de propagar as máscaras de rede: 11 Protocolos classful – não propagam as máscaras de rede (exemplo: protocolo RIPv1). 11 Protocolos classless – propagam as máscaras de rede (exemplo: protocolo OSPF e versão 2 do protocolo RIP).

Principais protocolos de roteamento na arquitetura TCP/IP 11 RIP (Routing Information Protocol) – protocolo de roteamento tipo vetor-distância que propaga, periodicamente, informações de roteamento aos roteadores vizinhos, independentemente de ocorrerem ou não mudanças operacionais nas redes físicas. 11 OSPF (Open Shortest Path First) – protocolo de roteamento tipo estado de enlace que propaga as informações dos enlaces de rede para todos os roteadores, apenas na inicialização ou após mudanças no estado dos enlaces. 11 BGP (Border Gateway Protocol) – protocolo de roteamento tipo exterior usado para propagar informações sobre o alcance das redes que compõem os diversos sistemas autônomos.

Representação de rotas 11 Modelo de roteamento 22 A arquitetura TCP/IP adota o modelo de roteamento passo-a-passo (hop-by-hop). 22 Estações de uma mesma rede podem enviar datagramas diretamente entre si. 22 Estações de redes distintas devem enviar datagramas ao próximo roteador do caminho (next-hop). 22 Datagramas são encaminhados de um roteador para outro, até que possam ser

Arquitetura e Protocolos de Rede TCP-IP

entregues diretamente.

278

11 Tabela de roteamento 22 Rotas indicam apenas o próximo roteador (next-hop) do caminho até a rede de destino. 33 Roteadores e estações não conhecem o caminho completo até o destino. 22 Rotas são representadas por pares (N, R). 33 N: endereço da rede de destino. 33 R: endereço do próximo roteador. 22 O próximo roteador R deve residir em uma rede diretamente conectada. 33 Para redes diretamente conectadas, R é apenas uma indicação de entrega direta.

Sistema autônomo

Conjunto de redes controladas por uma única autoridade administrativa, que possui autonomia para selecionar o protocolo de roteamento interno.

Na arquitetura TCP/IP, a camada de rede adota o modelo de roteamento hop-by-hop (passo-a-passo), técnica de roteamento na qual a estação origem e cada roteador intermediário entregam o datagrama ao próximo roteador do caminho, até que algum deles possa entregar o datagrama diretamente à estação destino. Nesse modelo, se as estações origem e destino estão conectadas na mesma rede física, o algoritmo de roteamento da estação origem encaminha o datagrama diretamente à estação destino. No entanto, se as estações origem e destino estão conectadas a redes físicas distintas, o algoritmo de roteamento da estação origem roteia o datagrama ao próximo roteador (next-hop) do melhor caminho até o destino. Por sua vez, esse roteador intermediário assume a responsabilidade de continuar encaminhando o datagrama ao destino. Seguindo esse modelo passo-a-passo, o algoritmo de roteamento de cada roteador intermediário roteia o datagrama para o próximo roteador, até que algum deles possa realizar uma entrega direta à estação destino. Assim, os datagramas atravessam a inter-rede e são encaminhados de um roteador para outro, até que possam ser entregues diretamente ao destino final. Para implementar o modelo de roteamento passo-a-passo, tipicamente, a tabela de roteamento contém rotas representadas por pares (N, R), em que N é o endereço da rede destino e R é o endereço IP do próximo roteador (next-hop) do caminho até a rede N. Geralmente, R reside em uma rede diretamente conectada, permitindo a entrega direta do datagrama para ele. Quando a rede N já é diretamente conectada, ao invés de indicar um próximo roteador, a rota apenas indica que uma entrega direta pode ser realizada ao destino. A Figura 7.2 ilustra uma inter-rede de exemplo, mostrando as tabelas de roteamento dos roteadores e algumas estações. Observe que cada entrada da tabela de roteamento indica apenas o próximo roteador para cada possível rede destino. Portanto, as rotas não indicam o caminho completo até o destino, mas apenas o endereço IP do próximo roteador do caminho até a rede destino. Consequentemente, no modelo de roteamento da arquitetura TCP/IP, estações origem e roteadores intermediários não conhecem a rota completa até o destino, exceto quando o roteador está diretamente conectado. Além disso, observe que cada entrada da tabela de roteamento aponta para um roteador intermediário que pode ser alcançado através de uma rede diretamente conectada. Ou seja,

Figura 7.2 Tabela de roteamento.

todos os roteadores intermediários listados nas tabelas de roteamento devem estar diretamente conectados à mesma rede da estação ou roteador. E3

Rede

Next-hop

Rede

Next-hop

10.0.0.0 150.10.0.0 200.10.1.0

Direct 10.0.0.1 10.0.0.1

10.0.0.0 150.10.0.0 200.10.1.0

200.10.1.2 200.10.1.2 Direct

N1 10.0.0.0

10.0.0.1

200.10.1.2 N2 150.10.0.0

N3 200.10.1.0

150.10.0.2

Rede

Next-hop

Rede

Next-hop

10.0.0.0 150.10.0.0 200.10.1.0

Direct Direct 150.10.0.2

10.0.0.0 150.10.0.0 200.10.1.0

150.10.0.1 Direct Direct

Capítulo 7 - Roteamento

150.10.0.1

279

Na Figura 7.2, quando a estação E1 deseja enviar datagramas à estação E2, que está conectada à mesma rede física, o algoritmo de roteamento da estação E1 identifica que a estação E2 pertence à rede 10.0.0.0 e, assim, encaminha o datagrama diretamente para E2. Nesse caso, observe que a tabela de roteamento da estação E1 possui a rota (10.0.0.0, Direct), indicando que a rede 10.0.0.0 está diretamente conectada à estação E1. No entanto, quando a estação E1 deseja enviar datagramas à estação E3, que está conectada a uma rede física distinta, o algoritmo de roteamento da estação E1 identifica que a estação E3 pertence à rede 200.10.1.0 e, assim, roteia o datagrama para a interface 10.0.0.1 do roteador R1. Nesse caso, a tabela de roteamento da estação E1 possui a rota (200.10.1.0, 10.0.0.1), indicando que a rede 200.10.1.0 pode ser alcançada através da interface 10.0.0.1 do roteador R1, que está diretamente conectada à mesma rede da estação E1. Então, baseado na rota (200.10.1.0, 150.10.0.2), o algoritmo de roteamento do roteador R1 encaminha o datagrama para a interface 150.10.0.2 do roteador R2. Por fim, o algoritmo de roteamento do roteador R2 identifica que a rede destino 200.10.1.0 está diretamente conectada e, assim, encaminha o datagrama diretamente à estação E3.

Rotas para estações 11 Permitem realizar testes e depuração de tabelas de roteamento.

11 Adotadas para controle de acesso. 11 Devem ser evitadas para não aumentar o tamanho das tabelas de roteamento. 11 Também representadas por pares (N, R). 22 N: endereço da estação de destino. 22 R: endereço do próximo roteador. 11 O algoritmo de roteamento prioriza rotas para estações. Embora o roteamento adote o modelo baseado em endereços de rede, rotas específicas para estações também são suportadas pelas implementações do protocolo IP. Rotas para estações também são representadas por pares (N, R), porém, nesses casos, o termo N é o endereço IP da estação destino, enquanto R é o endereço IP do próximo roteador (nexthop) do caminho até a estação destino N. O algoritmo de roteamento sempre prefere rotas para estações a rotas para redes. Em outras palavras, o algoritmo de roteamento tenta, primeiramente, uma rota específica para a estação destino do datagrama. Se uma rota específica não existe, então a rota para a respectiva rede destino é adotada.

Arquitetura e Protocolos de Rede TCP-IP

Rotas para estações proveem melhor controle sobre o uso da rede, permitindo a realização

280

de testes e depuração de conexões de rede e tabelas de roteamento. Além disso, rotas para estações podem ser adotadas como mecanismo de controle de acesso. Na prática, porém, rotas para estações devem ser utilizadas apenas quando estritamente necessárias, evitando, assim, o aumento desnecessário das tabelas de roteamento.

Rota padrão (default) 11 Consolidam diversas rotas em uma única entrada da tabela de roteamento. 11 Reduzem o tamanho das tabelas de roteamento. 11 Tornam o roteamento mais eficiente.

11 São representadas por um par (N, R). 22 N: endereço reservado 0.0.0.0. 22 R: endereço do próximo roteador. 11 Adotadas apenas quando não existe uma rota para a estação ou rede de destino. Rota padrão é a rota adotada quando nenhuma outra rota da tabela de roteamento está

associada ao endereço de rede do destino do datagrama. Comumente, muitas redes físicas possuem apenas uma única conexão com as demais redes que compõem a inter-rede institucional, ou mesmo a internet. Por exemplo, na Figura 7.3, as redes N1 e N3 possuem apenas uma única conexão com as demais redes através dos roteadores R1 e R2, respectivamente. Nesses casos, o conceito de rota padrão pode ser utilizado para reduzir o tamanho das tabelas de roteamento, tornando mais eficiente o roteamento em roteadores e estações. E3

Rede

Next-hop

Rede

Next-hop

10.0.0.0 Default

Direct 10.0.0.1

200.10.1.0 Default

Direct 200.10.1.2

150.10.0.1 R1 10.0.0.1

Figura 7.3 Rotas padrão.

N2 150.10.0.0

N3 200.10.1.0

150.10.0.2

Rede

Next-hop

Rede

Next-hop

10.0.0.0 150.10.0.0 Default

Direct Direct 150.10.0.2

150.10.0.0 200.10.1.0 Default

Direct Direct 150.10.0.1

A rota padrão permite a consolidação de diversas rotas em uma única entrada da tabela de roteamento. Por exemplo, considerando a inter-rede da Figura 7.3, as tabelas de roteamento das estações E1 e E3, ao adotarem rotas padrão, são reduzidas. Observe que nas estações E1 e E3 as duas rotas que apontavam para 10.0.0.1 e 200.10.1.2, respectivamente, foram consolidadas em uma única rota padrão. Para ilustrar a maior redução das tabelas de roteamento, suponha que diversos roteadores e redes físicas foram conectados à rede N2 e aos roteadores R1 e R2 (Figura 7.3). Observe que, nesse caso, as tabelas de roteamento das estações E1 e E3 continuam a ser aquelas apresentadas na figura. Embora o exemplo apresente o uso de rotas padrão apenas em estações, roteadores também podem definir rotas padrão. Por exemplo, suponha que diversos roteadores e redes físicas foram conectados à rede N3 e ao roteador R2. Nesse caso, a tabela de roteamento do roteador R1 pode ser configurada, adotando rota padrão, como ilustra a Figura 7.3. Lembre-se de que o endereçamento IP reserva o endereço 0.0.0.0 para representar a rota padrão. Por exemplo, a rota (default, 150.10.0.2) é internamente representada (0.0.0.0, 150.10.0.2). Um datagrama é encaminhado pela rota padrão somente quando nenhuma outra entrada da tabela de roteamento está associada ao endereço de rede do destino do datagrama. Assim, o

Capítulo 7 - Roteamento

N1 10.0.0.0

200.10.1.2

algoritmo de roteamento tenta, primeiramente, uma rota específica para a estação de destino. 281

Se esta rota específica para a estação de destino não existe, o algoritmo de roteamento tenta uma rota para a rede de destino. Se a rota para a rede não existe, então a rota padrão é adotada.

Rotas nulas

11 Próximo roteador (next-hop) é “nulo”. 11 Simplesmente descarta os pacotes que utilizam essa rota. 11 Usadas para mitigar ataques de negação de serviço. 11 Podem ser utilizadas para evitar loops de roteamento.

Usualmente, o próximo passo (next-hop) para se chegar a um determinado destino é outro roteador, ou então uma interface física conectada à rede onde se localiza o destino final do pacote. No entanto, em alguns casos, é desejável que uma rota aponte para um próximo roteador (next-hop) “nulo”, fazendo com que os pacotes que utilizam essa rota sejam descartados. Chamamos esse tipo de rota de rota nula ou blackhole (buraco negro). A rota nula funciona como uma espécie de regra de firewall, com a vantagem de que o impacto no desempenho do roteador é quase inexistente. Por isso, rotas nulas são comumente usadas para mitigar ataques de negação de serviço nos roteadores de grandes provedores. Rotas nulas são também utilizadas para se evitar um problema conhecido como loop de roteamento, que veremos a seguir. R1

Next-hop

Rede

192.168.0.0/30

192.168.0.2 192.168.0.2 Conectada

Rota Default

200.200.201.0/24

200.200.200.0/24

200.200.200.0/24 200.200.201.0/24 192.168.0.0/30

Rede

Arquitetura e Protocolos de Rede TCP-IP

200.200.200.0/24

Conectada Conectada 192.168.0.1

Um loop de roteamento acontece quando há uma condição cíclica no roteamento dos pacotes. Normalmente é causada por erros na configuração de roteadores. Para entender melhor como isso acontece, vamos ver um exemplo. Considere uma topologia de rede simples (Figura 7.4), onde o roteador R1, de um provedor de acesso, está conectado ao roteador R2 de um cliente. O provedor designou dois blocos /24 para o cliente, que deverão ser configurados no roteador R2 (200.200.200.0/24 e 200.200.201.0/24). No entanto, como ainda não havia necessidade de se utilizar o segundo bloco, o administrador de redes do cliente configurou apenas o primeiro bloco no roteador R2 (200.200.200.0/24), embora as rotas para ambos os prefixos já tenham sido configuradas pelo provedor no roteador R1. Considere a rede onde estão os dois roteadores como sendo a rede 192.168.0.0/30.

282

200.200.200.0/24 192.168.0.0/30 Default

Next-hop Figura 7.4 Loop de roteamento.

A tabela de roteamento do roteador R2 possui rotas para as redes 192.168.0.0/30 e 200.200.200.0/24, que estão diretamente conectadas, e uma rota padrão. Se uma estação, localizada na rede do provedor, enviar um pacote com destino à rede 200.200.201.0/24, ele será encaminhado pelo roteador R1 para o roteador R2. Como o roteador R2 não possui uma rota específica para essa rede, ele utilizará a sua rota padrão para encaminhar o pacote de volta para o roteador R1. Esse ciclo continuará até o TTL do pacote expirar. Uma forma de evitar essa situação é inserir uma rota nula para a rede 200.200.201.0/24 no roteador R2, enquanto esse bloco não é efetivamente usado.

Listando tabelas de roteamento E3

R1 N1 10.0.0.0

10.0.0.1

150.10.0.1

N2 150.10.0.0

N3 200.10.1.0

200.10.1.2

150.10.0.2

> route –n

Figura 7.5 Listagem das tabelas de roteamento.

Destination

Gateway

Genmask

Flags

Metric

Ifaces

10.0.0.0

0.0.0.0

255.0.0.0

eth0

150.10.0.0

0.0.0.0

255.255.0.0

eth2

127.0.0.0

0.0.0.0

255.0.0.0

0.0.0.0

150.10.0.2

0.0.0.0

eth2

Com base no conhecimento sobre a representação de rotas, podemos apresentar exemplos práticos de tabelas de roteamento em sistemas Linux. Observe a Figura 7.5, que mostra a tabela de roteamento do roteador R1. O comando route lista a tabela de roteamento e, por default, mostra os nomes associados aos endereços de redes e roteadores. A opção -n força a apresentação apenas dos endereços. Observe que, na prática, a tabela de roteamento possui mais informações que apenas os pares (N, R). As principais informações mostradas incluem: 11 Endereço da rede destino (Destination), em que 0.0.0.0 ou default representa a rota padrão. 11 Endereço do próximo roteador (Gateway), em que 0.0.0.0 ou um asterisco (*) indica um destino diretamente conectado. 11 Máscara da rede destino (Genmask), em que 0.0.0.0 e 255.255.255.255 são as máscaras

Capítulo 7 - Roteamento

Comando route Sua função é listar a tabela de roteamento.

de uma rota padrão e de uma rota para a estação, respectivamente. 283

11 Estado da rota (Flags). 11 Métrica da rota (Metric). 11 Interface usada para enviar os datagramas (Iface). Principais indicadores de estado da rota: 11 U – rota válida (up). 11 H – rota para a estação (host). 11 G – rota indireta via um roteador intermediário (gateway).

Exercício de fixação 1 e Análise de tabela de rotas Na Figura 7.5, é destacada a tabela de rotas do roteador R1. Para quais redes o roteador poderá encaminhar pacotes?

Qual interface do roteador R1 será responsável por encaminhar pacotes para a rede 200.10.1.0?

Qual entrada na tabela de rotas irá tratar os pacotes originados de 10.0.0.0 para 200.10.1.0?

Também é possível listar a tabela de roteamento usando o comando netstat com a opção –r.

Comando netstat –r

Similarmente, a opção –n força a apresentação dos endereços, ao invés de nomes de redes

Sua função é listar a tabela de roteamento.

e roteadores. A Figura 7.6 mostra a tabela de roteamento do roteador R1. Observe que o comando netstat não mostra as métricas das rotas.

Arquitetura e Protocolos de Rede TCP-IP

N1 10.0.0.0

284

10.0.0.1

150.10.0.1

N2 150.10.0.0

150.10.0.2

N3 200.10.1.0

200.10.1.2

> netstat –rn Destination

Gateway

Genmask

Flags

Ifaces

10.0.0.0

0.0.0.0

255.0.0.0

eth0

150.10.0.0

0.0.0.0

255.255.0.0

eth2

127.0.0.0

0.0.0.0

255.0.0.0

0.0.0.0

150.10.0.2

0.0.0.0

eth2

Figura 7.6 Tabela de roteamento do roteador R1.

Estratégias de roteamento Sabendo que os algoritmos de roteamento encaminham os datagramas consultando as tabelas de roteamento, vamos, a seguir, descrever as diferentes formas de inicialização e manutenção das tabelas de roteamento.

Roteamento estático 11 Permite instalar ou remover manualmente rotas estáticas.

11 Rotas devem ser manualmente atualizadas após mudanças na inter-rede. 11 Processo é lento e sujeito a erros. 11 Não acomoda crescimento e mudanças na inter-rede de forma satisfatória. 11 Adequado para inter-redes pequenas, simples e estáveis. 11 Comandos de configuração de rotas são incluídos em arquivos de inicialização. Roteamento estático é a estratégia de roteamento na qual as tabelas de roteamento de roteadores e estações são manualmente configuradas pelo administrador. As tabelas de roteamento podem ser diretamente manipuladas pelos administradores através de comandos específicos, que permitem instalar ou remover rotas manualmente. Assim, os administradores podem configurar as tabelas de roteamento de roteadores e estações, definindo as rotas para todos os possíveis destinos. As rotas configuradas manualmente são denominadas de rotas estáticas. Da mesma forma, a estratégia de roteamento baseada apenas em rotas estáticas é denominada de roteamento estático. No roteamento estático, sempre que redes são acrescentadas, removidas ou mudam de estado operacional, os administradores devem atualizar, manualmente, as tabelas de roteamento de todos ou de parte dos roteadores e estações. Portanto, o roteamento estático pode consumir bastante tempo de configuração e está sujeito a erros, não acomodando de forma satisfatória o crescimento e as mudanças na inter-rede. Consequentemente, o roteamento estático é adequado para inter-redes pequenas, simples e estáveis, em que as redes físicas possuem apenas uma única conexão com as demais redes que compõem a inter-rede, não existindo rotas redundantes e em um contexto em que mudanças no estado operacional das várias redes sejam incomuns. Essas características reduzem o tamanho das tabelas de roteamento e evitam a constante configuração manual de rotas. Por exemplo, na inter-rede da Figura 7.6, as tabelas de roteamento dos roteadores e estações podem ser facilmente configuradas pelos administradores, pois apenas um pequeno conjunto de rotas precisa ser efetivamente criado. No roteamento estático, na prática, as entradas das tabelas de roteamento são criadas por comandos que realizam a configuração do endereçamento das interfaces de rede e, também, por comandos específicos que permitem a configuração de rotas estáticas. durante a inicialização dos sistemas. Comando ifconfig Sua função é configurar os endereços das interfaces e automaticamente instalar rotas para as redes diretamente conectadas.

Por exemplo, em sistemas Linux, o comando ifconfig configura os endereços das interfaces e automaticamente instala rotas para as respectivas redes diretamente conectadas. A Figura 7.7 mostra a configuração do endereço da interface eth2 do roteador R1 da Figura 7.6 e a definição automática da rota para a respectiva rede.

Capítulo 7 - Roteamento

Geralmente, tais comandos são incluídos em arquivos de configuração que são processados

285

O comando route, por sua vez, permite criar e remover rotas da tabela de roteamento. Na mesma figura, é mostrada a criação de uma rota estática para a rede 200.10.1.0/24 no roteador R1. A opção add indica que uma rota deve ser criada para a rede 200.10.1.0 (-net), cuja máscara é 255.255.255.0 (netmask), via o roteador intermediário 150.10.0.2 (gw). Para criar rotas para estações, deve-se adotar a mesma sintaxe, porém substituindo a opção –net por –host.

> ifconfig

eth2

150.10.0.1 netmask 255.255.0.0

> route –n Destination

Gateway

Genmask

Flags

Metric

Iface

150.10.0.0

0.0.0.0

255.255.255.0

eth2

. . .

> route

add -net

200.10.1.0

netmask

255.255.255.0

gw 150.10.0.2

> route –n Destination

Gateway

Genmask

Flags

Metric

Iface

150.10.0.0

0.0.0.0

255.255.255.0

eth2

200.10.1.0

150.10.0.2

255.255.255.0

eth2

. . . > route

add

default

gw 10.0.0.1

> route –n Destination

Gateway

Genmask

Flags

Metric

Iface

10.0.0.0

0.0.0.0

255.0.0.0

eth0

0.0.0.0

10.0.0.1

0.0.0.0

eth0

Figura 7.7 Roteamento estático.

Para remover rotas, deve-se utilizar o comando route com a opção del. Similarmente, deve-se adotar a mesma sintaxe para remover rotas para estações, porém substituindo a opção –net por –host. O comando route também permite criar e remover a rota padrão. A Figura 7.7 ilustra a criação da rota padrão na estação E1. A opção add default indica que uma rota padrão deve ser criada via o roteador intermediário 10.0.0.1 (gw). Para remover a rota padrão, basta Arquitetura e Protocolos de Rede TCP-IP

substituir a opção add por del.

Roteamento dinâmico 11 Adota protocolos de roteamento para criar, remover e atualizar rotas dinâmicas. 11 Rotas são manipuladas de forma automática, rápida e confiável. 11 Melhora a confiabilidade da rede e o tempo de resposta às mudanças operacionais. 11 Adequado para inter-redes grandes, complexas e instáveis. 11 Adequado também para redes pequenas com rotas redundantes e mudanças frequentes. Estratégia de roteamento em que todas as tabelas de roteamento de roteadores e estações são automaticamente configuradas pelos protocolos de roteamento. Em inter-redes

286

complexas, grandes e instáveis, tal como a internet, os administradores não conseguem atualizar as rotas manualmente, de forma rápida e confiável, em resposta às mudanças na inter-rede. Portanto, protocolos de roteamento devem ser adotados para atualizar automaticamente as tabelas de roteamento, de modo a melhorar a confiabilidade da rede e o tempo de resposta às mudanças operacionais. Vale ressaltar que protocolos de roteamento também podem ser interessantes em redes pequenas que possuem rotas redundantes e que apresentam frequentes mudanças na situação operacional das redes físicas. Nesses casos, a atualização das rotas pode ser realizada de forma automática, rápida e confiável. Para realizar a atualização automática das rotas, os protocolos de roteamento propagam informações de roteamento, a partir das tabelas de roteamento completas e consistentes que podem ser dinamicamente configuradas. Na prática, os protocolos de roteamento permitem a criação de novas rotas, atualização de rotas existentes e remoção de rotas inválidas. Por exemplo, quando o protocolo de roteamento detecta uma nova rede física, uma nova rota é acrescentada às tabelas de roteamento. Após perceber alterações nas métricas de roteamento, o protocolo de roteamento pode atualizar as métricas das rotas. Por fim, se o protocolo de roteamento detecta a falha de um determinado enlace, as rotas afetadas podem ser removidas e rotas alternativas, que resolvem o problema, podem ser criadas. Quando existem rotas redundantes, o protocolo de roteamento encontra múltiplas rotas para determinados destinos. Nesses casos, com base nas métricas de roteamento, o protocolo de roteamento escolhe a melhor rota e a instala na tabela de roteamento. Alguns protocolos instalam múltiplas rotas na tabela de roteamento e, dependendo da implementação, o algoritmo de roteamento usa apenas a melhor rota ou realiza o balanceamento de carga entre essas possíveis rotas. As rotas manipuladas pelos protocolos de roteamento são denominadas rotas dinâmicas e, por consequência, a estratégia de roteamento baseada apenas em rotas dinâmicas é chamada de roteamento dinâmico. A adoção do roteamento dinâmico não muda a forma como o algoritmo de roteamento encaminha os datagramas. As entradas das tabelas de roteamento é que são modificadas para refletir as mudanças na inter-rede.

Roteamento híbrido Inicialmente, as tabelas de roteamento são configuradas com rotas estáticas.

11 Rotas diretas para redes diretamente conectadas. 11 Rotas estáticas para redes que proveem serviços essenciais. Posteriormente, protocolos de roteamento complementam as tabelas de roteamento, através de rotas dinâmicas para as demais redes físicas que compõem a inter-rede. Estratégia de roteamento em que as tabelas de roteamento de roteadores e estações são inicialmente configuradas com algumas rotas estáticas e, posteriormente, complementadas e desvantagens. O roteamento dinâmico pode resolver situações complexas de roteamento de forma mais rápida e confiável. Porém, consome recursos de processamento e comunicação para propagar e processar as informações de roteamento. O roteamento estático evita o consumo de recursos de processamento e comunicação, pois não existe propagação de informações de roteamento. Entretanto, não acomoda de forma satisfatória o crescimento e as mudanças operacionais, pois a intervenção manual é lenta e

Capítulo 7 - Roteamento

com rotas dinâmicas. As estratégias de roteamento estático e dinâmico têm suas vantagens

sujeita a erros. Consequentemente, na prática, é comum encontrarmos uma estratégia de 287

roteamento híbrida. Nesse caso, a configuração inicial da tabela de roteamento é composta por rotas diretas para as redes diretamente conectadas e por rotas estáticas para as redes que proveem serviços essenciais de conectividade. Em seguida, os protocolos de roteamento acrescentam rotas dinâmicas para as demais redes físicas que compõem a inter-rede. No roteamento híbrido, geralmente, as estações são configuradas com rotas estáticas.

Arquiteturas de roteamento Conforme já foi mencionado, tanto os esquemas de endereçamento quanto os protocolos de roteamento são classificados nas categorias classful ou classless. Da composição de esquema de endereçamento e os protocolos de roteamento derivam as arquiteturas de roteamento classful e classless. A arquitetura de roteamento classful é caracterizada pela adoção do esquema de endereçamento classful e protocolos de roteamento classful. Já a arquitetura de roteamento classless é caracterizada pela adoção do esquema de endereçamento classless e protocolos de roteamento classless. Embora a diferença entre os protocolos de roteamento classful e classless pareça pequena (apenas a incapacidade ou a capacidade de propagar as máscaras de rede), os efeitos são importantes.

Arquitetura classful 11 Adota o esquema de endereçamento e protocolos de roteamento classful. 11 Protocolos de roteamento não propagam as máscaras das sub-redes. 11 Algoritmo de roteamento deve deduzir as máscaras das sub-redes. 22 Assume que as sub-redes, derivadas de um endereço classe A, B, ou C, adotam máscaras idênticas. 22 Suporta apenas sub-redes com máscaras de tamanho fixo. 11 Algoritmo de roteamento: 22 Extrair endereço IP de destino (D) do datagrama. 22 Determinar o endereço da rede ou sub-rede de destino (N): 33 Identificar o endereço da rede (C) classe A, B ou C. 33 Deduzir a máscara da rede ou sub-rede de destino (S):

33 Se existe alguma interface de sub-redes do endereço de rede C:

Arquitetura e Protocolos de Rede TCP-IP

33 Deduzir a máscara S a partir da configuração dessa interface.

288

33 Senão:Assumir que a máscara S é igual à máscara default da rede C. 33 Deduzir o endereço da rede ou sub-rede destino (N = D and S). 22 Se existe rota para o destino D: 33 Rotear o datagrama para o roteador R dessa rota e sair. 22 Se existe rota para a rede N: 33 Rotear o datagrama diretamente ou via o roteador R dessa rota e sair. 22 Se existe rota padrão: 33 Rotear o datagrama para o roteador R indicado na rota padrão e sair. 22 Gerar mensagem de erro.

Na arquitetura de roteamento classful, os protocolos de roteamento classful não propagam as máscaras das sub-redes. Dessa forma, o algoritmo de roteamento não conhece as máscaras das sub-redes, cujas rotas foram aprendidas por meio dos protocolos de roteamento. Consequentemente, o algoritmo de roteamento deve adotar algum mecanismo para deduzir estas máscaras. Para permitir a dedução das máscaras, a arquitetura classful suporta apenas sub-redes com máscaras de tamanho fixo. Em outras palavras, a arquitetura classful assume que todas as sub-redes derivadas de um determinado endereço classe A, B ou C adotam máscaras idênticas. Em função dessa limitação, o algoritmo de roteamento deduz a máscara de uma sub-rede, cuja rota foi aprendida por meio de um protocolo de roteamento, a partir da configuração de interfaces diretamente conectadas a sub-redes do mesmo endereço classe A, B ou C. Por exemplo, se a rota para 192.168.10.64 é aprendida por meio do protocolo de roteamento e existe uma interface diretamente conectada à sub-rede 192.168.10.32/27, então o algoritmo de roteamento deduz que a rota aprendida aponta para a sub-rede 192.168.1.64/27. Considerando os conceitos que estudamos, o algoritmo de roteamento classful adota o seguinte comportamento: prioritariamente, o algoritmo tenta encaminhar o datagrama através de uma rota específica para a estação destino. Em segundo lugar, o algoritmo tenta adotar uma rota para a rede destino. Por último, a rota padrão é utilizada. Se nenhuma dessas rotas existe, o algoritmo gera uma mensagem de erro. Observe também que o algoritmo assume que todas as sub-redes derivadas de um determinado endereço de rede possuem máscaras idênticas. Essa pressuposição pode ser percebida na dedução da máscara da rede destino (S) a partir da configuração de alguma interface pertencente a sub-redes do endereço de rede (C).

Arquitetura classless 11 Adota o esquema de endereçamento e protocolos de roteamento classless.

11 Protocolos de roteamento propagam as máscaras das sub-redes. 11 Algoritmo de roteamento sempre conhece as máscaras das sub-redes. 11 Permite que as sub-redes, derivadas de um endereço de bloco, adotem máscaras diferentes. 11 Suporta sub-redes com máscaras de tamanho variável. 11 Algoritmo de roteamento: 22 Extrair endereço IP de destino (D) do datagrama. 22 Para cada rota i da tabela, declarar a rota possível se Ni = (D and Si). 22 Se existe alguma rota possível: 33 Selecionar a rota possível de maior prefixo de rede.

22 Gerar mensagem de erro. Na arquitetura de roteamento classless, os protocolos de roteamento classless propagam as máscaras das sub-redes. Assim, o algoritmo de roteamento sempre conhece as máscaras das sub-redes cujas rotas foram aprendidas através dos protocolos de roteamento. Consequentemente, o algoritmo de roteamento não precisa adotar qualquer mecanismo para deduzir estas máscaras.

Capítulo 7 - Roteamento

33 Rotear o datagrama para o roteador R da rota selecionada e sair.

289

Como as máscaras das várias sub-redes são sempre individualmente propagadas e conhecidas, a arquitetura classless suporta sub-redes com máscaras de tamanho variável. Em outras palavras, a arquitetura classless permite que as sub-redes derivadas de um determinado endereço de bloco adotem máscaras diferentes. O algoritmo de roteamento classless não explora o conceito de classes de endereços e tampouco adota qualquer pressuposição sobre as máscaras dos blocos. Ao invés disso, o algoritmo de roteamento classless explora o conceito de equivalência de maior prefixo (longest prefix match), realizando uma comparação entre o endereço de destino (D) do datagrama e o endereço de destino de cada rota (Ni) da tabela de roteamento. Essa comparação é realizada através da operação lógica entre o endereço de destino D e a máscara da rota Si. Se o resultado é igual ao endereço de destino da rota (Ni), então tal entrada é declarada uma rota possível. Dentre as rotas possíveis, aquela que possui o maior prefixo de rede é escolhida para rotear o datagrama. Observe que a rota possível com o maior prefixo de rede é sempre a que possui a maior máscara e, portanto, é a rota mais específica. Lembre-se de que rotas para estações e a rota padrão sempre adotam as máscaras 255.255.255.255 e 0.0.0.0, respectivamente. Portanto, implicitamente, a seleção da rota de maior prefixo prioriza as rotas para estações, pois as mesmas possuem a maior máscara (255.255.255.255). Em seguida, rotas para sub-redes mais específicas são priorizadas. Por último, a rota padrão é adotada apenas quando é a única rota possível, pois ela possui a menor máscara (0.0.0.0). Vale ressaltar que a rota padrão é sempre uma rota válida. Se nenhuma dessas rotas existe, então o algoritmo gera uma mensagem de erro.

> route –n Destination

Gateway

Genmask

Flags

Metric

Iface

200.10.1.1

150.10.1.1

255.255.255.0

UGH

eth0

200.10.1.1

150.10.1.1

255.255.255.255

UGH

eth0

0.0.0.0

150.30.3.3

0.0.0.0

eth2

Figura 7.8 Exemplo de tabela de rotas.

Por exemplo, considerando a tabela de roteamento mostrada na Figura 7.8, um datagrama destinado ao endereço 200.10.1.1 possui as entradas 200.10.1.1/32, 200.10.1.0/27 e 0.0.0.0/0 como rotas possíveis. Nesse caso, o algoritmo adota a rota para a estação 200.10.1.1/32, pois ela possui o maior prefixo. Por outro lado, um datagrama para o endereço 200.10.1.2 possui as entradas 200.10.1.0/27 Arquitetura e Protocolos de Rede TCP-IP

e 0.0.0.0/0 como rotas possíveis. Nesse outro caso, o algoritmo adota a rota para a sub-rede

290

200.10.1.0/27, pois ela possui o maior prefixo. Por fim, um datagrama para 192.168.1.1 adota rota padrão, que é a única rota possível.

Protocolos de roteamento padrão 11 ARPAnet 22 Rede pequena. 22 Rotas estáticas. 11 Crescimento da internet 22 Atualização dinâmica das tabelas de roteamento.

11 Protocolos interiores

22 RIP. 22 OSPF. 11 Protocolos exteriores 22 BGP. Na arquitetura TCP/IP, diversos protocolos de roteamento foram desenvolvidos para atender a necessidades específicas, mas a grande motivação para o seu desenvolvimento foi, sem dúvida, o crescimento massivo e sem controle da internet. No início da ARPAnet, a rede experimental da agência ARPA do Departamento de Defesa norte-americano (DoD), as rotas eram configuradas manualmente pelos administradores (rotas estáticas) e funcionavam adequadamente, pois era uma rede pequena. Com o término da experiência ARPAnet e o início da internet sustentada pela iniciativa privada, o crescimento da rede obrigou os administradores a rever essa posição. Surgiram então os protocolos de roteamento que permitiam uma atualização dinâmica das tabelas de roteamento.

Protocolo RIP 11 Baseado no algoritmo Bellman-Ford.

11 Métrica hop count. 11 Envia a tabela de rotas completa a cada 30 segundos. 11 RIPv2 22 Envia informação de máscara de rede (classless). 22 Autentica mensagens. 22 Mensagens multicast. Routing Information Protocol (RIP) é o protocolo de roteamento mais antigo baseado no algoritmo de vetor distância (Bellman-Ford). Possui duas versões: 11 RIPv1 (classful); 11 RIPv2 (classless). O RIPv1 já era distribuído no Unix BSD desde 1982, mas só foi padronizado em junho de 1988 pelo RFC 1058. Características do RIPv1: 11 Usa a porta 520 do protocolo UDP para enviar mensagens de broadcast; 11 Envia mensagens do tipo request solicitando informações de rotas dos vizinhos; 11 Recebe mensagens do tipo response com atualizações de rotas; 11 Métrica usada é o hop count (contagem de saltos):

22 hop count = 16 (rede inatingível). 11 A cada 30 segundos envia a tabela de rotas completa através das mensagens do tipo response; 11 Não envia informação de máscara de rede (classful). O RIPv2 foi inicialmente definido pelo RFC 1388, de janeiro de 1993, tornado obsoleto pelo RFC 1723, de novembro de 1994, e finalmente padronizado pelo RFC 2453, de novembro de 1998, que tornou obsoletos os anteriores. Principais diferenças em relação ao RIPv1:

Capítulo 7 - Roteamento

22 hop count = 1 (rede diretamente conectada).

291

11 Envia informação de máscara de rede (classless); 11 Usa autenticação de mensagens para maior segurança; 11 Usa mensagens multicast para o endereço 224.0.0.9. As demais características são semelhantes às do RIPv1. A limitação mais séria do protocolo RIP é o fato de não suportar mais de 15 hops, limitando seu uso a redes pequenas. Face a isso, foi necessário definir um novo protocolo que suportasse redes grandes e atendesse às exigências de crescimento da internet.

Protocolo OSPF O protocolo OSPF é baseado na tecnologia de estado de enlace (link state), tendo como

principais características: 11 Não existe limite de saltos. 11 Suporta VLSM. 11 Convergência mais rápida do que o RIP. 11 Hierarquia de redes. 11 Divisão da rede em áreas. 11 Mais complexo. O protocolo Open Shortest Path First (OSPF), definido no RFC 2328, é um protocolo Interior Gateway Protocol (IGP), ou seja, projetado para uso intra-AS (Sistema Autônomo). Foi desenvolvido para atender às necessidades da comunidade da internet, que demandava um protocolo IGP eficiente, não proprietário e interoperável com outros protocolos de roteamento. A natureza aberta do OSPF significa que ele pode ser implementado por qualquer fabricante, sem pagamento de licença, de modo a ser utilizado por todos. O OSPF baseia-se na tecnologia link state, diferente e mais avançada que a usada em protocolos puramente vetoriais, como o RIP, que utiliza o algoritmo Bellman-Ford para o cálculo da melhor rota. O OSPF resolve todas as limitações do protocolo RIP: 11 Não existe limite de saltos. 11 Suporta VLSM. 11 Utiliza anúncios multicast e as atualizações apenas são disparadas quando existe alguma alteração na rede (anúncios incrementais). 11 Redes OSPF convergem mais eficientemente do que redes RIP, principalmente as Arquitetura e Protocolos de Rede TCP-IP

redes maiores.

292

11 Permite a implementação de hierarquia às redes, por meio das áreas. Isso facilita o planejamento da rede, assim como tarefas de agregação e sumarização de rotas. O protocolo OSPF permite um meio mais eficaz de balanceamento de carga e a divisão de uma rede em áreas. Ele possibilita o roteamento dentro de cada área e através das áreas, usando os chamados roteadores de borda. Com isso, é possível criar redes hierárquicas de grande porte, sem que seja necessário que cada roteador tenha uma tabela de roteamento gigantesca, com rotas para todas as redes, como seria necessário no caso do RIP. Em outras palavras, o OSPF foi projetado para intercambiar informações de roteamento em uma interconexão de redes de tamanho grande ou muito grande.

A divisão em áreas reduz o tráfego de overhead enviado pela rede, além de reduzir o tamanho da base de dados topológica que cada roteador deve manter. Entretanto, o OSPF é mais complexo de ser planejado, configurado e administrado, se comparado com RIP. Além disso, processos OSPF consomem mais CPU que processos RIP, uma vez que o algoritmo e a estrutura utilizados pelo OSPF são muito mais complexos. O protocolo OSPF possui algumas restrições quando mais de uma área é configurada. Se apenas uma área existe, esta área é SEMPRE a área 0, chamada de backbone area. Quando existem múltiplas áreas, uma delas deve ser a área 0. Ao se projetar redes com o protocolo OSPF, uma boa prática é começar pela área 0 e expandir a rede com a criação de outras áreas (ou segmentando a área 0).

Protocolo BGP 11 Interliga os Sistemas Autônomos (ASs).

11 IANA atribui a cada AS um número: ASN. 11 Suporta CIDR. 11 Permite implementar políticas de roteamento. 11 Atualização incremental da tabela de rotas. 11 Estabelece sessões BGP com seus vizinhos. Parafraseando Douglas Comer, o protocolo de roteamento BGP versão 4 (BGP-4) pode ser considerado “a cola que mantém a internet unida e permite a interconexão universal nos dias de hoje”. O BGP-4 possibilita o intercâmbio de informações de roteamento entre os diversos sistemas autônomos ou Autonomous Systems (ASs), que em conjunto, formam a internet. Explicando de forma simplificada, ele permite que os dados trafeguem entre os ASs até chegarem ao AS de destino, e dentro dele sigam até o seu destino final (máquina). Há alguns anos, quando o principal backbone da internet era a ARPAnet, as instituições de pesquisa conectadas à rede precisavam gerenciar manualmente as tabelas de rotas para todos os possíveis destinos, ou seja, todas as outras redes conectadas. Com o crescimento da internet, verificou-se que era impraticável manter todas as tabelas atualizadas de forma manual, assim como também seria necessário criar mecanismos de atualização automática entre as diversas redes. Para anunciar as rotas para suas redes internas entre si, os ASs precisavam concordar em usar um esquema único, como um mesmo idioma para toda a internet. Para permitir a um algoritmo de roteamento automatizado distinguir entre um AS e outro, um número (Autonomous System Number – ASN) foi designado para cada AS pela IANA, autoridade central encarregada de atribuir todos os endereços identificadores das redes conectadas à internet. O BGP é um protocolo de roteamento para ser usado entre múltiplos sistemas autônomos em inter-redes baseadas no protocolo TCP/IP. O BGP-4 [RFCs 1771, 1772] foi projetado para evitar loops de roteamento entre ASs e permitir o uso de políticas de roteamento entre ASs do BGP a suportar endereços agregados (Classless Interdomain Routing, ou simplesmente CIDR) e o conceito de super-redes. O protocolo BGP-4 assume que o roteamento interno do AS é feito através de um sistema IGP de roteamento interno. Este pode ser um protocolo de roteamento como RIP e OSPF, por exemplo, ou até mesmo através de rotas estáticas.

Capítulo 7 - Roteamento

com base em regras arbitrárias definidas por eles. Além disso, o BGP-4 foi a primeira versão

293

O BGP constrói um grafo dos ASs, usando as informações trocadas pelos “vizinhos BGP” (BGP neighbors), que são compostas dos números identificadores dos ASs (ASN). A conexão entre os ASs forma um “caminho” (path), e a coleção desses caminhos acaba formando uma rota composta pelos números dos ASs que devem ser percorridos até se chegar a um determinado AS destino. Outra característica do BGP-4 é a atualização das tabelas de rotas feitas de forma incremental, como nos algoritmos de estado de enlace. A atualização completa da tabela de rotas

Arquitetura e Protocolos de Rede TCP-IP

é feita somente uma vez, quando se estabelece a sessão entre os vizinhos.

294

Roteiro de Atividades 7 Atividade 7.1 – Estratégia de roteamento Uma determinada instituição possui a inter-rede mostrada na figura 7.9. Suponha que você foi contratado como consultor para definir a estratégia de roteamento a ser adotada nesta inter-rede. Você recomendaria o roteamento estático ou dinâmico? Apresente argumentos favoráveis à sua recomendação e contrários à outra estratégia.

Figura 7.9 Rede da Atividade 7.1.

Capítulo 7 - Roteiro de Atividades

295

Atividade 7.2 – Estratégia de roteamento (2) Algum tempo depois, a inter-rede da Atividade 7.1 ficou um pouco mais complexa, conforme mostra a figura a seguir. Agora, você foi contratado para avaliar a estratégia de roteamento atual, sugerida por você anteriormente, e, caso necessário, propor uma nova estratégia. Qual a sua avaliação da estratégia atual? É necessária alguma mudança na estratégia de roteamento? Explique. R4

R2 R1

Arquitetura e Protocolos de Rede TCP-IP

296

Atividade 7.3 – Rotas estáticas Vamos usar a rede da Atividade 7.1 para configurar rotas estáticas. Siga o procedimento: 1. Inicie o Virtual Box e selecione a opção “Open a Virtual Machine”, selecione a máquina

virtual “vcore-4.2” no diretório que o instrutor indicar e inicie esta máquina virtual. 2. Aguarde a carga completa da máquina virtual CORE. 3. Selecione “File” no menu, selecione a opção “Open” e localize o diretório onde se encontra a

rede: “Rede_Atividade7_3.imn”, seguindo a orientação do instrutor. Carregue o arquivo da rede. 4. A rede deverá ser idêntica à Figura 7.11 mostrada a seguir.

Figura 7.10 Rede da Atividade 7.2.

Figura 7.11 Rede da Atividade 7.3.

5. Os endereços IPv4 já estão configurados, conforme a figura. Temos 4 redes físicas

representadas pelos switches N1, N2, N3 e N4. Cada rede física tem um prefixo de rede diferente, conforme a tabela abaixo. Rede

Endereço de rede

Gateway padrão

Nome PC

Endereço PC

192.168.1.0/24

192.168.1.1

PC1

192.168.1.10/24

192.168.2.0/24

192.168.2.1

PC2

192.168.2.10/24

192.168.3.0/24

192.168.3.1

PC3

192.168.3.10/24

192.168.4.0/24

192.168.4.1

PC4

192.168.4.10/24

6. Nenhum tipo de rota ou protocolo de roteamento está configurado. Nesta atividade

vamos configurar as rotas estáticas nos 3 roteadores: R1, R2 e R3. O modo inicial de operação do simulador é o Modo de Edição. Este modo é utilizado para desenhar a rede e configurar o endereçamento IPv4. Para efetivamente executar os protocolos de roteamento e as aplicações, é necessário iniciar o experimento, que pode ser feito

11 Clicando no ícone

à esquerda na barra de ferramentas;

11 Selecionando no menu superior a opção Experiment/Start.

Capítulo 7 - Roteiro de Atividades

de duas maneiras:

297

No Modo de Experimento, não é possível fazer edição da topologia da rede (note a barra de ferramentas modificada). Aguarde até que toda a rede seja iniciada (até desaparecerem os colchetes vermelho/verde em cada nó da rede). 7. Para configurar rotas estáticas no roteador R1, é preciso abrir o console do roteador.

Neste simulador o procedimento é o seguinte: 11 Aponte com o mouse para o roteador R1, clique no botão direito e selecione a opção: Shell window/vtysh, conforme mostrado na Figura 7.12.

Figura 7.12 Abertura do console roteador R1.

8. O console deverá ser parecido com a Figura 7.13, onde digitamos o comando sh ip route,

que lista as rotas IP conhecidas pelo roteador.

Hello, this is Quagga (version 0.99.17mr2.0).

Arquitetura e Protocolos de Rede TCP-IP

R1# sh ip route Codes: K – kernel route, C – connected, S – static, R – RIP, 0 – OSPF, I - ISIS, B – BGP, > - selected route, * - FIB route, o – OSPFv3

C>* 127.0.0.0/8 is directly connected, lo C>* 192.168.1.0/24 is directly connected, eth0

298

C>* 192.168.4.0/24 is directly connected, eth2 R1# Observe que o roteador R1 só conhece as redes diretamente conectadas: 192.168.1.0/24 e 192.168.4.0/24. 9. Vamos precisar “ensinar” ao roteador R1 como encaminhar pacotes para as redes

192.168.2.0/24 e 192.168.3.0/24, que são redes remotas e que só podem ser alcançadas através de outros roteadores. Para isso, os seguintes comandos devem ser digitados no console de R1:

R1# conf t R1(config)# ip route 192.168.2.0 255.255.255.0 192.168.4.2 R1(config)# ip route 192.168.3.0 255.255.255.0 192.168.4.3 R1(config)# exit R1# sh ip route Codes: K–kernel route, C–connected, S–static, R–RIP, O-OSPF I-ISIS, B-BGP, >-selected route, *-FIB route, o-OSPFv3 C>* 127.0.0.0/8 is directly connected, lo C>* 192.168.1.0/24 is directly connected, eth0 S>* 192.168.2.0/24 [1/0] via 192.168.4.2, eth2 S>* 192.168.3.0/24 [1/0] via 192.168.4.3, eth2 C>* 192.168.4.0/24 is directly connected, eth2 R1# Os dois comandos ip route informam as rotas para as redes remotas, dizendo para onde encaminhar os pacotes (next-hop). Em seguida listamos a tabela de rotas IP novamente, e então aparecem as rotas estáticas para as duas redes remotas. Observe que as rotas estáticas aparecem com um “S>*” no início da linha e as redes diretamente conectadas com um “C>*”. 10. Precisamos fazer a configuração de rotas estáticas para os roteadores R2 e R3, adequando

os comandos mostrados acima às rotas específicas para cada um. Liste a tabela de rotas antes e depois de configurar as rotas estáticas para conferir se estão corretas. Dicas: 11 Roteador R2 – rotas para as redes 192.168.1.0/24 e 192.168.3.0/24; 11 Roteador R3 – rotas para as redes 192.168.1.0/24 e 192.168.2.0/24. 11. Todos os roteadores conhecem as rotas para todas as redes, portanto podemos testar

a conectividade entre os PCs. Por exemplo, a partir do PC1 vamos enviar ping para os demais PCs. Para isso, siga o seguinte procedimento: 11 Aponte com o mouse para o PC1, clique no botão direito e selecione a opção: Shell window/bash.

Capítulo 7 - Roteiro de Atividades

Figura 7.13 Console do roteador R1.

299

No console do PC1, digite o seguinte comando (ping para o PC2):

[email protected]:/tmp/pycore.39156/PC1.conf# ping –c 2 192.168.2.10 O resultado deve ser semelhante ao listado a seguir.

PING 192.168.2.10 (192.168.2.10) 56(84) bytes of data. 64 bytes from 192.168.2.10: icmp_req=1 ttl=62 time=198ms 64 bytes from 192.168.2.10: icmp_req=2 ttl=62 time=1.95ms --- 192.168.2.10 ping statistics --2 packets transmitted, 2 received, 0% packet loss, time 1005ms rtt min/avg/max/mdev = 1.957/100.115/198.273/98.158 ms [email protected]:/tmp/pycore.39156/PC1.conf# 12. Se digitarmos o comando traceroute para o PC3, o resultado deve ser semelhante ao

listado a seguir.

[email protected]:/tmp/pycore.39156/PC1.conf# traceroute –n 192.168.3.10 traceroute to 192.168.3.10 (192.168.3.10), 30 hops max, 60 bytes packet 1 192.168.1.1 (192.168.1.1) 14.144 ms 0.189 ms 0.104 ms 2 192.168.4.3 (192.168.4.3) 33.604 ms 33.412 ms 3 192.168.3.10 (192.168.3.10) 46.833 ms 46.228 ms 45.650 ms [email protected]:/tmp/pycore.39156/PC1.conf# Observe que o pacote seguiu a rota configurada no roteador R1. Os mesmos testes devem ser efetuados entre os demais PCs. Todos devem funcionar.

Atividade 7.4 – Rotas RIP Vamos usar a mesma rede da Atividade 7.1 para configurar rotas RIP. Siga o procedimento: 1. Selecione “File” no menu, selecione a opção “Open” e localize o diretório onde se encontra

a rede: “Rede_Atividade7_4.imn”, seguindo a orientação do instrutor. Este arquivo é diferente do arquivo da atividade anterior. O protocolo RIP está habili-

Arquitetura e Protocolos de Rede TCP-IP

tado, mas não está configurado.

300

2. A rede deverá ser idêntica à da Figura 7.11. 3. Nesta atividade vamos configurar as rotas RIP nos 3 roteadores: R1, R2 e R3. 4. Para configurar rotas RIP no roteador R1 é preciso abrir o console do roteador. A configu-

ração é mais simples do que a anterior. Basta digitar os comandos:

R1# conf t R1(config)# router rip R1(config-router)# network 192.168.0.0/16 R1#

São os mesmos comandos em TODOS os roteadores. Só depois de todos os roteadores estarem configurados é que as tabelas de rotas estarão completamente atualizadas. Note que informamos no comando network a rede que deve ser anunciada pelo protocolo RIP aos demais roteadores (vizinhos). Não precisamos informar as sub-redes, basta informar a super-rede: 192.168.0.0/16. Essa super-rede é na verdade um bloco de 256 redes classe C: 192.168.0.0/24, 192.168.1.0/24,..., 192.168.255.0/24 (ver RFC 1918). O protocolo RIP descobre as sub-redes classe C pela máscara de sub-rede. 5. Para verificar as tabelas de rotas, basta digitar o comando sh ip route listado abaixo, com

o resultado correspondente, no caso do roteador R1.

R1# sh ip route Codes: K–kernel route, C–connected, S–static, R–RIP, O-OSPF I-ISIS, B-BGP, >-selected route, *-FIB route, o-OSPFv3 C>* 127.0.0.0/8 is directly connected, lo C>* 192.168.1.0/24 is directly connected, eth0 R>* 192.168.2.0/24 [120/2] via 192.168.4.2, eth2, 00:01:06 R>* 192.168.3.0/24 [120/2] via 192.168.4.3, eth2, 00:01:30 C>* 192.168.4.0/24 is directly connected, eth2 R1# Observe que as rotas RIP aparecem com o indicador “R>*” no lugar do indicador de rotas estáticas da atividade anterior. Os demais roteadores devem mostrar tabelas de rotas semelhantes. Todas as redes precisam aparecer em todas as tabelas de rotas. 6. Todos os roteadores conhecem as rotas para todas as redes. Podemos então testar a

conectividade entre os PCs. Por exemplo, a partir do PC1 podemos enviar ping e/ou traceroute para os demais PCs, seguindo o mesmo procedimento da atividade anterior.

Atividade 7.5 – Rotas OSPF Vamos usar a rede da Atividade 7.1 para configurar rotas OSPF. Siga o procedimento: 1. Selecione “File” no menu, selecione a opção “Open” e localize o diretório onde se encontra

a rede: “Rede_Atividade7_5.imn”, seguindo a orientação do instrutor.

habilitado, mas não está configurado. 2. A rede deverá ser idêntica à da Figura 7.11. 3. Nesta atividade vamos configurar as rotas OSPF nos 3 roteadores: R1, R2 e R3. 4. Para configurar rotas OSPF no roteador R1, é preciso abrir o console do roteador. A confi-

guração é tão simples quanto a anterior. Basta digitar os comandos:

R1# conf t R1(config)# router ospf

Capítulo 7 - Roteiro de Atividades

Este arquivo é diferente do arquivo da atividade anterior. O protocolo OSPF está

301

R1(config-router)# network 192.168.0.0/16 area 0 R1# São os mesmos comandos em TODOS os roteadores. Só depois de todos os roteadores estarem configurados é que as tabelas de rotas estarão completamente atualizadas. Note que informamos no comando network a rede que deve ser anunciada pelo protocolo OSPF aos demais roteadores (vizinhos). Não precisamos informar as sub-redes, bastando informar a super-rede: 192.168.0.0/16. 5. Para verificar as tabelas de rotas, basta digitar o comando sh ip route listado abaixo, com

o resultado correspondente, no caso do roteador R1.

R1# sh ip route Codes: K–kernel route, C–connected, S–static, R–RIP, O-OSPF I-ISIS, B-BGP, >-selected route, *-FIB route, o-OSPFv3 C>* 127.0.0.0/8 is directly connected, lo O

192.168.1.0/24 [110/10] is directly connected, eth0, 00:02:33

C>* 192.168.1.0/24 is directly connected, eth0 O>* 192.168.2.0/24 [110/20] via 192.168.4.2, eth2, 00:01:45 O>* 192.168.3.0/24 [110/20] via 192.168.4.3, eth2, 00:01:47 O

192.168.4.0/24 [110/10] is directly connected, eth2, 00:02:28

C>* 192.168.4.0/24 is directly connected, eth2 R1# Observe que as rotas OSPF aparecem com o indicador “O>*” no lugar do indicador de rotas RIP da atividade anterior. Os demais roteadores devem mostrar tabelas de rotas semelhantes. Todas as redes precisam aparecer em todas as tabelas de rotas. 6. Todos os roteadores conhecem as rotas para todas as redes. Podemos então testar a

conectividade entre os PCs. Por exemplo, a partir do PC1 podemos enviar ping e/ou

Arquitetura e Protocolos de Rede TCP-IP

traceroute para os demais PCs, seguindo o mesmo procedimento da Atividade 7.3.

302

8 objetivos

Camada de transporte Descrever os protocolos da camada de transporte da arquitetura TCP/IP e apresentar os mecanismos do TCP que permitem a entrega confiável de datagramas, enfatizando as diferenças com o protocolo UDP.

conceitos

Funcionalidades dos protocolos da camada de transporte da arquitetura TCP/IP, serviços de datagrama e circuito virtual e processos de aplicação.

Fundamentos da camada de transporte A camada de transporte tem o objetivo de prover a comunicação fim-a-fim entre pro-

cessos de aplicação. Funcionalidades: 11 Serviço de datagramas. 11 Serviço de circuito virtual. 11 Identificação de processos. Como vimos, a camada de rede é responsável por encaminhar e rotear datagramas IP entre estações da inter-rede. Nesta camada, os endereços IP identificam apenas as estações. Logo, após entregar um datagrama IP à estação destino, o protocolo IP não sabe distinguir qual dos processos de aplicação deve receber o conteúdo do datagrama. Neste capítulo, vamos entender os mecanismos adotados pela camada de transporte para permitir que os diversos processos de aplicação, executando em cada estação, possam enviar e receber dados de forma independente. Na arquitetura TCP/IP, a camada de transporte provê a comunicação fim-a-fim entre processos de aplicação, definindo dois diferentes serviços de transporte: o serviço de datagramas e o serviço de circuito virtual. Em ambos os serviços, a camada de transporte adota mecanismos para distinguir e identificar os múltiplos processos de aplicação que estão executando em cada estação. A seguir, estudaremos estas modalidades de serviço e discutiremos o mecanismo de identificação de processos de aplicação. É importante não confundir o serviço de datagramas da camada de transporte com o serviço de mesmo nome da camada de rede.

Capítulo 8 - Camada de transporte

Camada de rede Também conhecida como camada de inter-rede, é responsável pela transferência de dados entre dispositivos da inter-rede. Nela se realiza a função de roteamento.

303

Serviço de datagramas O serviço de datagramas apresenta as seguintes características:

11 Serviço não confiável 22 Não garante a entrega dos datagramas, podendo perder e retardar datagramas. 22 Provê apenas a detecção de erros, garantindo a integridade dos dados. 11 Serviço sem conexão 22 Datagramas são individuais e independentes. 22 Sequência dos datagramas não é assegurada. O serviço de datagramas é um serviço de transporte bastante simples, sendo caracterizado como não confiável e sem conexão, capaz de realizar a entrega fim-a-fim de dados entre os processos de aplicação de origem e destino, mas não garante que os dados enviados sejam entregues sequencialmente. Este serviço pode ser visto como uma simples extensão do serviço de entrega de datagramas da camada de rede. No entanto, ao contrário deste último, que realiza a entrega de datagramas IP entre estações origem e destino, o serviço de datagramas da camada de transporte é capaz de realizar a entrega fim-a-fim entre os processos de aplicação origem e destino. Este serviço é considerado não confiável porque não garante que os datagramas enviados pela aplicação origem sejam entregues com sucesso à respectiva aplicação destino. Além disso, quando os datagramas são entregues à aplicação destino, o serviço não garante a entrega na sequência original. Na verdade, datagramas podem ser perdidos, retardados e até mesmo chegar fora de ordem. Na prática, o serviço de datagramas provê apenas a detecção de erros, não suportando mecanismos de correção de erros, controle de fluxo e controle de sequência. Quando desejada, a confiabilidade deve ser provida pela camada de aplicação. O serviço de datagramas é denominado sem conexão porque, antes do envio dos datagramas, não existe qualquer comunicação prévia entre as aplicações origem e destino, com o objetivo de definir o caminho a ser seguido pelos datagramas ou reservar recursos ao longo deste caminho. Consequentemente, cada datagrama é tratado de forma individual e completamente independente dos demais, sendo encaminhado ao destino através do caminho mais conveniente, definido pela função de roteamento implementada pela camada de rede. Logo, nenhuma informação é mantida sobre a sequência dos datagramas enviados. Se uma determinada aplicação envia uma sequência de datagramas para outra, estes datagramas podem ser encaminhados pela camada de rede por diversos caminhos, trafegando por diferentes redes e roteadores intermediários. Alguns destes datagramas podem ser Arquitetura e Protocolos de Rede TCP-IP

perdidos, enquanto outros podem, inclusive, ser entregues à aplicação destino fora da

304

sequência original.

Serviço de circuito virtual 11 Serviço orientado a fluxo 22 Divide o fluxo de dados em segmentos. 11 Serviço confiável 22 Garante a entrega do fluxo de dados na sequência correta e sem erros. 22 Provê controle de erro, sequência e fluxo.

11 Serviço orientado à conexão

22 Negocia parâmetros operacionais na abertura da conexão. 22 Conexões são full-duplex. O serviço de circuito virtual é um serviço de transporte confiável e orientado à conexão, capaz de realizar a entrega fim-a-fim de dados entre os processos de aplicação origem e destino, garantindo que os dados enviados sejam entregues na sequência. O serviço de circuito virtual é bem mais complexo que o serviço de datagramas. Este serviço Segmento Nome da unidade de dados do serviço de circuito virtual da camada de transporte.

divide o fluxo de dados (data stream), gerado pelo processo de aplicação origem em segmentos. Por sua vez, estes segmentos são enviados ao processo de aplicação destino. Este serviço é considerado confiável porque garante que os dados enviados pela aplicação origem são entregues na sequência correta e sem erros à respectiva aplicação destino. Portanto, o serviço de circuito virtual provê um fluxo confiável de dados, oferecendo mecanismos implícitos de detecção e correção de erro, controle de fluxo e controle de sequência, que garantem um alto nível de confiabilidade. O serviço de circuito virtual é denominado orientado à conexão porque, antes do envio do fluxo de dados, o processo de aplicação origem deve comunicar-se com o processo de aplicação destino, com o objetivo de abrir uma conexão. Durante a abertura de uma conexão, as entidades de transporte envolvidas negociam parâmetros operacionais, como a inicialização dos mecanismos de controle de erro, fluxo e sequência, bem como os tamanhos dos buffers de transmissão e recepção. A conexão deve permanecer ativa durante a fase de transferência de dados. Quando os processos não desejam mais transferir dados, a conexão deve ser fechada, liberando os recursos associados nas entidades de transporte envolvidas. No serviço de circuito virtual, toda conexão é full-duplex, permitindo a ambos os processos enviar e receber dados simultaneamente. No contexto de uma conexão, cada segmento não é independente dos demais, pois transporta informações que permitem ao respectivo destino recuperar a sequência correta dos segmentos. Embora o serviço de circuito virtual seja orientado à conexão, quando um processo de aplicação envia uma sequência de segmentos para outro, os datagramas IP que encapsulam estes segmentos podem ser encaminhados pela camada de rede por diversos caminhos, trafegando por diferentes redes e roteadores intermediários. Consequentemente, tais datagramas IP podem ser perdidos, duplicados ou chegar fora da sequência original. No entanto, o serviço de circuito virtual provê mecanismos de controle de erro e sequência que requisitam a retransmissão de segmentos perdidos ou recebidos com erro, descartam segmentos duplicados e reorganizam os segmentos na sequência correta.

Identificação de processos 11 Uma porta é identificada por um número inteiro positivo que representa um

ponto de comunicação. 11 Processos são associados a portas. 11 Par (endereço IP, porta) identifica unicamente cada ponto de comunicação. A maioria dos sistemas operacionais permite a execução simultânea de vários processos de aplicação. Para permitir que múltiplos processos, executando em uma mesma estação, possam simultaneamente receber e transmitir dados de forma independente, a camada de transporte adota o conceito de porta. Uma porta é uma representação interna do sistema

Capítulo 8 - Camada de transporte

Full-duplex Modo de comunicação no qual as entidades origem e destino podem simultaneamente enviar dados em ambas as direções.

305

operacional de um ponto de comunicação para envio e recepção de dados. É importante ressaltar que o conceito de porta é adotado tanto no serviço de datagramas, quanto no serviço de circuito virtual. Cada porta é identificada por um número inteiro positivo que representa um ponto de comunicação para envio e recepção de dados. Os processos de aplicação comunicantes devem ser associados a portas. Vale ressaltar que um determinado processo de aplicação pode estar associado a uma ou múltiplas portas. Portanto, para a camada de transporte, cada processo de aplicação (usuário da camada de transporte) é representado por uma ou várias portas diferentes. A figura 8.1 ilustra um exemplo de associação de processos a portas. Observe que os processos P1 e P2 estão associados às portas 25 e 53, respectivamente. Logo, todos os dados recebidos nas portas 25 e 53 são repassados pela camada de transporte para P1 e P2, respectivamente. Por outro lado, o processo P3 está associado às portas 161 e 162. Portanto, todos os dados recebidos nas portas 161 e 162 são repassados para P3. P1

Porta 25

Porta 53

Figura 8.1 Identificação de processos na camada de transporte.

Aplicação Transporte Porta 161

Porta 162

Para permitir a associação de processos de aplicação a portas, o sistema operacional local de cada estação provê uma interface de programação para que os processos possam abrir, acessar e fechar portas. O sistema operacional deve assegurar que, sempre que um determinado processo requisitar a abertura de uma dada porta, somente este processo estará associado àquela porta. Mais detalhes desta interface de programação serão estudados no próximo capítulo. No momento, é suficiente entender que os processos dispõem de mecanismos para indicar as portas a que desejam se associar, como também enviar e receber dados através destas portas. Como os números das portas são atribuídos isoladamente pela entidade de transporte de cada estação, estes números não são únicos em toda a inter-rede. Para obter um identificador único para cada ponto de comunicação (porta), cada entidade de transporte utiliza o par (endereço IP, porta), onde o endereço IP identifica a estação na qual a porta está sendo usada. Por exemplo, a porta 9.000, usada na estação 192.168.10.1, é identificada unicamente pelo par (192.168.10.1, 9000).

Arquitetura e Protocolos de Rede TCP-IP

Quando um processo de aplicação origem deseja se comunicar com um processo de aplicação

306

destino, o processo origem deve conhecer o endereço IP da estação onde o processo destino está executando e a porta associada ao processo destino naquela estação. As mensagens enviadas são encapsuladas em datagramas IP. Cada datagrama IP transporta os endereços IP de origem e destino, identificando as estações origem e destino. Por outro lado, cada unidade de dados do protocolo de transporte inclui um campo de controle que sinaliza as portas origem e destino, identificando os processos origem e destino associados a elas. Na estação destino, baseada na porta destino, a implementação do protocolo de transporte no sistema operacional realiza a demultiplexação, encaminhando o conteúdo das mensagens recebidas ao respectivo processo de aplicação. Portanto, a porta destino permite a entrega das mensagens à aplicação destino associada a ela. Por outro lado, a porta origem

Interface de programação Conjunto de procedimentos, funções ou métodos providos por um componente ou biblioteca de software.

permite à aplicação destino retornar mensagens à aplicação origem, caso necessário. Observe que, neste caso, os processos de aplicação invertem seus papéis de origem e destino.

Protocolos da camada de transporte 11 UDP (User Datagram Protocol)

22 Provê o serviço de datagramas não confiável e sem conexão. 22 Pode ser visto como uma extensão do protocolo IP que realiza a entrega de datagramas entre processos. 11 TCP (Transmission Control Protocol) 22 Provê o serviço de circuito virtual confiável e orientado à conexão. Para prover o serviço de datagramas e o serviço de circuito virtual, a camada de transporte da arquitetura TCP/IP define dois diferentes protocolos: UDP e TCP. O protocolo UDP provê o serviço de datagramas não confiável e sem conexão. Apenas envia pacotes, denominados datagramas UDP, de um processo de aplicação para outro, mas não garante que eles sejam entregues com sucesso ao processo de aplicação de destino. Desta forma, o protocolo UDP pode ser visto como uma simples extensão do protocolo IP. No entanto, ao contrário do protocolo IP, que realiza a entrega de datagramas IP entre estações, o protocolo UDP realiza a entrega fim-a-fim de datagramas UDP entre processos de aplicação. O protocolo TCP provê o serviço de circuito virtual. Ele é um protocolo orientado à conexão que provê um fluxo confiável de dados, oferecendo serviços de controle de erro, fluxo e sequência. O protocolo TCP divide o fluxo de dados (data stream) em segmentos, que são enviados de um processo de aplicação para outro de forma confiável, garantindo que eles sejam entregues ao processo de aplicação destino na sequência correta e sem erros.

Protocolo UDP Fundamentos:

11 Define a unidade de dados do serviço de datagramas, denominada datagrama UDP. 22 Especifica o formato e a função dos campos. 11 Multiplexa mensagens geradas pelos processos no serviço da camada de rede. 22 Encapsula datagramas UDP em datagramas IP. 11 Demultiplexa datagramas UDP para os respectivos processos de destino. 22 Extrai mensagens dos datagramas UDP. O protocolo UDP é um protocolo de transporte simples que provê o serviço de datagramas

11 Especificação, de forma precisa, do formato da unidade de dados do serviço de datagramas da camada de transporte, denominada datagrama UDP. 11 Multiplexação das mensagens geradas pelos vários processos de aplicação origem no serviço provido pela camada de rede. 11 Demultiplexação, no destino, dos datagramas UDP recebidos da camada de rede para os respectivos processos de aplicação destino. O protocolo UDP utiliza o protocolo IP para transportar datagramas UDP entre as aplicações origem e destino. Ou seja, cada mensagem gerada por um processo de aplicação origem é

Capítulo 8 - Camada de transporte

não confiável e sem conexão. Ele define três importantes conceitos:

307

encapsulada em um datagrama UDP, que, por sua vez, é encapsulado em um datagrama IP. Então, o protocolo IP encaminha o datagrama IP da estação origem até a estação destino. Na estação destino, baseado no campo Protocol do datagrama IP, o sistema operacional decodifica o datagrama UDP. Por fim, a implementação do protocolo UDP entrega a mensagem encapsulada ao respectivo processo de destino. O protocolo UDP não garante que os datagramas enviados pelo processo de aplicação origem sejam entregues com sucesso ao respectivo processo de aplicação destino. Ele provê apenas a detecção de erros, assegurando a integridade dos datagramas que por ventura venham a ser entregues ao processo de aplicação destino. Além disso, o protocolo UDP não implementa qualquer mecanismo de reconhecimento para informar sobre a entrega de datagramas à entidade UDP de destino. Portanto, a aplicação origem não tem conhecimento sobre a entrega das mensagens à aplicação destino. Vale ressaltar que o UDP não implementa correção de erros, controle de fluxo e controle de sequência. Portanto, ele não garante que os datagramas sejam entregues na sequência original. Na verdade, datagramas podem ser perdidos, retardados e até mesmo chegar fora de ordem. Portanto, quando desejada, a confiabilidade deve ser provida pela camada de aplicação. Sendo o UDP um protocolo sem conexão, quando um processo de aplicação deseja enviar uma mensagem para outro processo, o protocolo UDP simplesmente encapsula a mensagem em um datagrama UDP e o envia ao outro processo. Desta forma, cada datagrama UDP é tratado de forma individual e completamente independente dos demais, podendo ser encaminhado por diferentes caminhos, definidos pela função de roteamento da camada de rede. Além disso, a entidade UDP de origem não mantém nenhuma informação sobre os datagramas UDP enviados.

Formato do datagrama Cada datagrama é tratado de forma individual e independente, e pode ser encaminhado

por diferentes rotas. 0

16 Source port

Destination port

Length

Checksum Figura 8.2 Formato do datagrama UDP.

Data

Cada datagrama UDP é dividido em duas partes: cabeçalho e dados. O cabeçalho contém Arquitetura e Protocolos de Rede TCP-IP

informações de controle específicas do protocolo UDP, como as portas origem e destino.

308

A porção dos dados encapsula informações de protocolos da camada de aplicação. A figura 8.2 ilustra o formato de datagramas UDP, detalhando o formato dos campos do cabeçalho. Observe que o campo de dados não é explicitamente detalhado, permitindo o encapsulamento de diferentes protocolos de aplicação.

Campos do datagrama Source port 11 Porta associada ao processo de origem. 11 Permite ao processo de destino retornar mensagens ao processo de origem.

11 Porta de origem é opcional.

Destination port 11 Porta associada ao processo de destino. 11 Usada na demultiplexação das mensagens encapsuladas nos datagramas. Length 11 Tamanho total do datagrama em bytes. 11 Inclui o cabeçalho e os dados. Checksum 11 Assegura a integridade do datagrama. 11 Inclui o cabeçalho e os dados. 11 Detecção de erros é opcional. Data 11 Dados do datagrama. Como já sabemos, datagramas UDP transportam as portas associadas aos processos de aplicação origem e destino. Os campos Source port e Destination port são usados com este propósito. Observe que cada um destes campos possui 16 bits, indicando que o maior número de porta possível é 65.535. O campo Source port é opcional. Quando indicado, permite que o processo de aplicação destino retorne dados para o processo de aplicação de origem. Quando não indicado, o processo destino não tem como retornar dados para o processo origem. Neste último caso, o valor do campo Source port deve ser 0. Portanto, podemos concluir que a porta 0 nunca é usada por processos de aplicação. Na estação destino, o campo Destination port é usado pela entidade UDP para selecionar o processo de aplicação destino que receberá a mensagem encapsulada no datagrama. Portanto, o protocolo UDP utiliza o número da porta destino para demultiplexar os datagramas UDP que recebe do protocolo IP.

Estrutura de dados que armazena diversos itens de dados, consumidos na mesma sequência em que são incluídos.

No UDP, uma porta é geralmente implementada como uma fila interna do sistema operacional, utilizada para armazenar as mensagens recebidas. Ao receber um datagrama, o sistema operacional verifica se a porta destino do datagrama é igual a alguma porta atualmente aberta. Caso a porta destino exista, o sistema operacional armazena a mensagem encapsulada no final da fila daquela porta. Por outro lado, o processo de aplicação associado àquela porta acessa as mensagens armazenadas no início da fila. Caso a porta destino não exista, o sistema operacional simplesmente descarta o datagrama UDP e gera uma mensagem ICMP port unreachable para a estação origem. Lembre-se de que o comando traceroute explora estas mensagens Port unreachable para descobrir a rota entre duas estações ou roteadores, no sistema operacional Linux. O campo Length indica o tamanho do datagrama UDP em bytes, incluindo o cabeçalho e os dados. Logo, sendo o cabeçalho de tamanho fixo (8 bytes), o tamanho mínimo do datagrama UDP é de 8 bytes. Este tamanho mínimo somente ocorre quando o campo de dados do datagrama UDP não transporta nenhum conteúdo. A integridade dos datagramas UDP é assegurada pelo campo Checksum. Portanto, este campo é utilizado para detectar erros no datagrama UDP, incluindo os campos de cabeçalho e dados.

Capítulo 8 - Camada de transporte

Fila

309

A detecção de erros é fim-a-fim, sendo calculada pela entidade UDP origem e verificada pela entidade UDP destino. Uma vez que o campo Checksum é calculado sobre todo o datagrama, ele permite detectar mudanças nos campos de cabeçalho e dados que possam ter ocorrido em qualquer ponto intermediário entre a origem e o destino. É importante ressaltar que a detecção de erros é opcional. Quando não utilizada pela entidade UDP origem, o campo Checksum deve ser preenchido com valor 0. Embora seja opcional, é interessante que a detecção de erros seja sempre implementada e habilitada, pois o protocolo IP não realiza a detecção de erros do campo de dados, no qual o datagrama UDP é transportado. Em outras palavras, a detecção de erros do UDP é a única forma de assegurar que os dados recebidos estão corretos. Lembre-se de que o protocolo UDP não suporta correção de erros. Quando a entidade UDP destino detecta um erro no datagrama, este é simplesmente descartado e nenhuma mensagem de erro é enviada ao processo de aplicação origem.

Cálculo do checksum

11 Considera um pseudocabeçalho 22 Assegura que a entrega é realizada à estação e ao processo de destino. 11 Pode incluir um byte pad (0). 22 Torna par o tamanho do datagrama. 11 O pseudocabeçalho e o byte pad não são transmitidos com o datagrama. Para calcular o campo Checksum, a entidade UDP origem acrescenta um pseudocabeçalho ao datagrama UDP original. O objetivo deste pseudocabeçalho é assegurar, na entidade UDP destino, que o datagrama foi realmente entregue à estação destino e ao protocolo de transporte destino. Vale ressaltar que o pseudocabeçalho não é transmitido junto com o datagrama UDP, sendo utilizado unicamente para calcular o campo Checksum. A figura 8.3 mostra o formato do pseudocabeçalho. 0

Source IP address Destination IP address 00000000

Protocol

Length

Arquitetura e Protocolos de Rede TCP-IP

Os campos Source IP address e Destination IP address contêm os endereços IP das estações

310

origem e destino, respectivamente. O campo Protocol sempre contém o valor 17, indicando o UDP como protocolo de transporte destino. O campo Length é apenas uma repetição do tamanho do datagrama UDP, incluindo o cabeçalho e os dados. Observe que o pseudocabeçalho não é incluído no campo Length. Além disso, para calcular o campo Checksum, o UDP considera que o datagrama possui um número par de bytes. Quando o datagrama possui um número ímpar de bytes, o UDP adiciona um byte com valor 0 (pad) ao final do datagrama. Da mesma forma que o pseudocabeçalho, o byte pad também não é transmitido junto com o datagrama UDP.

Figura 8.3 Pseudocabeçalho UDP.

Protocolo TCP 11 Fundamentos

22 Define a unidade de dados do serviço de circuito virtual, denominada segmento TCP. 22 Especifica o formato e a função dos campos. 22 Multiplexa mensagens geradas pelos processos no serviço da camada de rede. 22 Encapsula segmentos em datagramas IP. 22 Demultiplexa segmentos para os respectivos processos de destino. 22 Extrai mensagens dos segmentos. 11 Adota uma abordagem baseada em fluxo de dados (data stream). 22 Trata o fluxo de dados como uma cadeia contínua de bytes. 22 Decide como agrupar bytes em segmentos. 11 Adota uma abordagem orientada à conexão full-duplex. 22 Estabelecimento da conexão. 22 Transferência de dados. 22 Fechamento da conexão. 11 Define mecanismos integrados de controle de erro e sequência. 22 Asseguram a entrega do fluxo de dados na sequência correta e sem erros. 11 Define mecanismo de controle de fluxo. 22 Regula e compatibiliza a taxa de transmissão das entidades envolvidas. 22 Evita o descarte de segmentos por falta de recursos na estação de destino. O TCP é um protocolo de transporte bem mais complexo que o UDP. O TCP provê o serviço de circuito virtual fim-a-fim, confiável e orientado à conexão. Para tal, o protocolo TCP define importantes conceitos e mecanismos. Primeiramente ele especifica, de forma precisa, o formato da unidade de dados do serviço de circuito virtual da camada de transporte, denominada segmento TCP. De forma semelhante ao UDP, a implementação do protocolo TCP multiplexa as mensagens geradas pelos vários processos de aplicação origem no serviço provido pela camada de rede e, no destino, demultiplexa os segmentos TCP recebidos da camada de rede para os respectivos processos de aplicação destino. Portanto, ele também utiliza o protocolo IP para transportar segmentos entre as aplicações origem e destino. Ou seja, mensagens geradas por um processo de aplicação origem são encapsuladas em segmentos, que, por sua vez, são encapsulados em datagramas IP. O protocolo IP é então utilizado para encaminhar datagramas IP da estação origem até a estação destino. Na estação de destino, baseado no campo Protocol dos datagramas IP, o sistema operacional entrega os segmentos à implementação do protocolo TCP, que, então, repassa as mensagens encapsuladas ao respectivo processo de aplicação destino. Enquanto o protocolo UDP é baseado em datagramas independentes, o protocolo TCP é orientado a fluxo de dados (data stream). Na prática, podemos pensar o fluxo de dados como uma cadeia contínua de bytes, composta pela sequência de mensagens geradas pelo processo de aplicação origem. Normalmente, o TCP decide, internamente, a quantidade de bytes que devem ser agrupados e encapsulados em um segmento.

Capítulo 8 - Camada de transporte

Segmento TCP Unidade de dados do protocolo TCP.

311

Portanto, diferentemente do protocolo UDP, onde cada mensagem gerada pelo processo de aplicação é encapsulada em um único datagrama UDP, no protocolo TCP, o fluxo de dados gerado pelo processo de aplicação origem tem pouco ou nenhum relacionamento com os segmentos enviados pela entidade TCP. Ou seja, uma determinada mensagem pode ser dividida em várias partes e cada uma delas encapsulada em um segmento. Várias mensagens também podem ser agrupadas e posteriormente encapsuladas em um único segmento. Sendo o TCP um protocolo orientado à conexão, quando um processo de aplicação deseja enviar um fluxo de dados para outro processo, a entidade TCP origem deve primeiro requisitar a abertura de uma conexão com a entidade TCP destino. Na abertura de uma conexão, as portas associadas à conexão são definidas e os recursos necessários para gerenciar a conexão são reservados nestas entidades. Em seguida, inicia-se a fase de transferência de dados na conexão, onde os fluxos de dados gerados pelos processos de aplicação podem ser enviados e recebidos. Por fim, quando os processos não desejam mais trocar dados, solicitam o fechamento da conexão. Neste momento, as portas e os recursos atribuídos à conexão são liberados. Portanto, no TCP, a comunicação entre processos tem três fases: abertura da conexão, transferência de dados e fechamento da conexão. Vale ressaltar que a conexão TCP é full-duplex, permitindo a ambos os processos enviar e

Protocolo orientado à conexão Adota o conceito de conexão para gerenciar a comunicação entre as entidades comunicantes. Antes de iniciar a comunicação, as entidades devem estabelecer uma conexão. Em seguida, podem transferir os dados. Por fim, quando não mais desejam trocar dados, fecham a conexão.

receber, simultaneamente, fluxos de dados independentes. Desta forma, observe que os termos “processo origem” e “processo destino” são usados apenas para simplificar as explicações e facilitar o entendimento do uso das conexões. Para prover a confiabilidade fim-a-fim, o protocolo TCP define mecanismos integrados de controle de erro e sequência. Embora segmentos possam ser perdidos, duplicados, retardados e até mesmo chegar fora de ordem, os mecanismos de controle de erro e sequência asseguram a entrega do fluxo de dados gerado pelo processo origem, na sequência correta e sem erros, ao respectivo processo destino. Para tal, o controle de erros realiza a detecção e correção de erros, assegurando a integridade dos segmentos recebidos e a recuperação de segmentos corrompidos. Em complemento, o controle de sequência recupera a sequência original do fluxo de dados. Para realizar estas funções, ambos os mecanismos exploram mensagens de reconhecimento positivo, que informam a entidade TCP origem sobre a entrega com sucesso de segmentos à entidade TCP destino. Por fim, o protocolo TCP adota um mecanismo de controle de fluxo que regula e compatibiliza a taxa de transmissão das entidades envolvidas, evitando o descarte de segmentos por falta de recursos na estação destino. 0

Arquitetura e Protocolos de Rede TCP-IP

Source port

Mensagem de resposta enviada por uma entidade que implementa um determinado protocolo para sinalizar a correta recepção de unidades de dados deste protocolo.

Destination port Sequence number Acknowledgment number

Hlen

Reserved

Code bits

Window

Checksum

Urgent pointer Padding

Options Data

No TCP, cada segmento é dividido em duas partes: cabeçalho e dados. O cabeçalho contém informações de controle específicas do protocolo TCP, por exemplo, as portas origem

312

Reconhecimento positivo

Figura 8.4 Formato do segmento TCP.

e destino. A porção dos dados encapsula informações de protocolos da camada de aplicação. A figura 8.4 ilustra o formato dos segmentos, detalhando os campos que compõem o cabeçalho. Observe que o campo de dados não é explicitamente definido, permitindo o encapsulamento de diferentes protocolos de aplicação.

Campos do cabeçalho 11 Hlen

22 Tamanho do cabeçalho em unidades de 4 bytes. 11 Reserved 22 Reservado para uso futuro (não utilizado). 11 Checksum 22 Assegura a integridade do segmento. 22 Considera um pseudocabeçalho. 22 Pode incluir um byte pad (0). 11 Code bits 22 Indica propósito e conteúdo do segmento. 33 URG: dados urgentes. 33 ACK: reconhecimento. 33 PSH: mecanismo push. 33 RST: aborto de conexão (reset). 33 SYN: abertura de conexão. 33 FIN: fechamento de conexão. 11 Options 22 Lista variável de informações opcionais. 33 Maximum Segment Size (MSS) 22 Torna o tamanho do cabeçalho variável. 11 Padding 22 Bits 0 que tornam o cabeçalho múltiplo de 32 bits. 11 Data 22 Dados do segmento. O tamanho do cabeçalho é variável, mas é sempre múltiplo de 32 bits. Para identificar corretamente o cabeçalho, o campo Hlen (header length) identifica o tamanho do cabeçalho Geralmente, o cabeçalho possui 20 bytes, exceto quando opções estão presentes (Options). Observe que o cabeçalho é limitado a 60 bytes, pois Hlen possui 4 bits. O campo Reserved não é utilizado, sendo reservado para uso futuro. A integridade dos segmentos é assegurada pelo campo Checksum. Portanto, este campo é utilizado para realizar a detecção de erros no segmento, incluindo os campos de cabeçalho e dados. A detecção de erros é fim-a-fim, sendo calculada pela entidade TCP origem e verificada pela entidade TCP destino. Lembramos que o protocolo TCP suporta correção de erros, como veremos adiante. Assim, quando a entidade TCP destino detecta um erro no segmento, este é simplesmente descartado e o mecanismo de correção de erros é ativado

Capítulo 8 - Camada de transporte

em unidades de 4 bytes. Por exemplo, Hlen igual a 5 representa um cabeçalho de 20 bytes.

para corrigi-lo via retransmissão. 313

Da mesma forma que o protocolo UDP, para calcular o campo Checksum, o protocolo TCP acrescenta um pseudocabeçalho ao segmento original, assegurando que o mesmo será realmente entregue à estação destino e ao protocolo de transporte destino. Além disso, como no UDP, o TCP pode acrescentar um byte com valor 0 (pad) ao final do segmento para torná-lo múltiplo de 16 bits. Vale ressaltar que o pseudocabeçalho e o byte pad não são transmitidos junto com o segmento, sendo utilizados unicamente para calcular o campo Checksum. O formato do pseudocabeçalho é idêntico ao usado no UDP. Porém, neste caso, o campo Protocol contém o valor 6, indicando o protocolo TCP. 0

URG

ACK

PSH

RST

SYN

FIN

Figura 8.5 Code bits do segmento TCP.

O campo Code bits é usado para indicar o propósito e conteúdo do segmento. Por exemplo, segmentos podem ser usados para estabelecer uma conexão, transferir dados e fechar uma conexão. Este campo é composto por 6 bits (Figura 8.5) que sinalizam o modo como outros campos do segmento devem ser interpretados. Vários destes bits podem ser ativados em um único segmento. 11 URG – segmento transporta dados urgentes; 11 ACK – segmento transporta um reconhecimento; 11 PSH – mecanismo push foi adotado para encaminhar o segmento; 11 RST – sinalização de que a conexão deve ser imediatamente abortada (reset); 11 SYN – segmento transporta uma requisição de abertura de conexão; 11 FIN – segmento transporta uma requisição de fechamento de conexão.

Code bits também são chamados de flags TCP. Os campos descritos acima foram definidos no RFC 793, que especifica o protocolo TCP. Posteriormente, o RFC 3168 modificou essa definição, acrescentando mais dois code bits: 11 Congestion Window Reduced (CWR) 11 Explicit Congestion Notification (ECE – ECN-Echo) O campo Options é uma lista variável de informações opcionais, sendo usado principalmente para definir o tamanho máximo dos segmentos (Maximum Segment Size – MSS) que podem ser recebidos por uma entidade TCP. Esta opção é sinalizada no segmento (SYN) que trans Arquitetura e Protocolos de Rede TCP-IP

porta um pedido de conexão.

314

Sendo o campo Options variável, o campo Padding contém bits 0 que estendem o cabeçalho para torná-lo múltiplo de 32 bits. Observe que o campo Padding somente é usado quando o

campo Options não é múltiplo de 32 bits.

Saiba mais

Os campos Source port e Destination port são usados na identificação das entidades comu-

Para mais informações, consulte o RFC 3168: “The Addition of Explicit Congestion Notification (ECN) to IP”.

nicantes, enquanto os campos Sequence number, Acknowledgment number, Window e Urgent pointer são usados pelos mecanismos de controle de erro, sequência e fluxo. Em função da importância destes campos, iremos estudá-los a seguir, bem como detalhes dos vários bits que compõem o campo Code bits.

Estrutura de conexão 11 Portas

22 Source port – porta associada ao processo origem. 22 Destination port – porta associada ao processo destino. 11 Endpoint 22 Definido pelo par endereço IP e porta. 22 Identifica de forma única cada porta ou ponto de comunicação na inter-rede. 22 Também conhecido como socket (linguagem C). 11 Conexão 22 Identificada de forma única por um par de endpoints. 22 Também conhecida como socket pair. 22 Cada endpoint pode participar de diversas conexões. 22 Sistema operacional deve assegurar que o par de endpoints da conexão é único. O endpoint identifica, de forma individual e única, um ponto de comunicação em toda a inter-rede, sendo representado pelo endereço IP da estação e a porta associada ao respectivo processo de aplicação. Da mesma forma que o protocolo UDP, o protocolo TCP também explora o conceito de porta. Portanto, segmentos transportam as portas associadas aos processos de aplicação origem e destino. Os campos Source port e Destination port são usados com este propósito. Como no UDP, no TCP cada um destes campos possui 16 bits, indicando que o maior número de porta possível é 65.535. Embora TCP e UDP adotem portas, os números das portas TCP são independentes dos números das portas UDP. Por exemplo, a porta TCP 10.000 e a porta UDP 10.000 podem ser usadas por diferentes processos de aplicação, executando na mesma estação. Observe que um mesmo número de porta não causa qualquer confusão, pois, primeiramente, o protocolo IP identifica o protocolo de transporte destino, baseado no campo Protocol dos datagramas IP. Apesar desta independência, na prática, se um determinado serviço é provido através de ambos os protocolos, o número da porta adotada é geralmente idêntico para os dois protocolos. Por exemplo, a porta 80 é reservada para o serviço web nos protocolos TCP e UDP. Vale ressaltar que esta identidade é pura convenção, não existindo qualquer imposição por parte dos protocolos. Como vimos, uma entidade de transporte deve utilizar o par (endereço IP, porta) para identificar cada endpoint em toda a inter-rede. No TCP, cada par (endereço IP, porta) define um endpoint identifica, de forma única, um ponto de comunicação em toda a inter-rede, ao qual está associado um processo de aplicação. Sendo o protocolo TCP orientado à conexão, ele deve identificar unicamente cada conexão, não apenas portas ou processos de aplicação individuais. No TCP, cada conexão é identificada por um par de endpoints, também conhecido como socket pair.

Capítulo 8 - Camada de transporte

ponto final de comunicação, comumente denominado endpoint ou socket. Portanto, cada

315

172.16.1.5

192.168.10.1

10.1.1.1

Porta 5000

Porta 80

Porta 25

Porta 1800

(172.16.1.5, 5000) e (192.168.10.1, 80)

Figura 8.6 Exemplo de conexão TCP.

(192.168.10.1, 25) e (10.1.1.1, 1800)

A Figura 8.6 mostra a identificação de duas conexões TCP: 11 A primeira conexão envolve o processo P1, executando na estação 172.16.1.5 e associado à porta 5.000, e o processo P2, executando na estação 192.168.10.1 e associado à porta 80. 11 A segunda conexão envolve o processo P3, executando na estação 192.168.10.1 e associado à porta 25; e o processo P4, executando na estação 10.1.1.1 e associado à porta 1.800.

172.16.1.5

192.168.10.1

10.1.1.1

Porta 5000

Porta 80

Porta 2000

(172.16.1.5, 5000) e (192.168.10.1, 80)

Figura 8.7 Exemplo de conexão TCP (2).

(192.168.10.1, 80) e (10.1.1.1, 2000)

Observe que, em uma mesma estação, várias conexões podem ser estabelecidas simultaneamente. Além disso, um mesmo endpoint local pode participar de várias conexões diferentes com endpoints remotos, ou seja, conexões podem compartilhar endpoints. Por exemplo, na Figura 8.7, o endpoint (192.168.10.1, 80) participa de duas conexões. Embora um determinado endpoint possa participar de diversas conexões, localmente, cada sistema operacional deve assegurar que o par de endpoints de cada conexão é único, constituindo, portanto, uma identificação única para cada conexão.

Demultiplexação de mensagens 11 Segmentos recebidos são associados às conexões, não apenas às portas.

11 Avalia o par de endpoints da conexão. 22 Portas origem e destino são obtidas do segmento recebido.

Arquitetura e Protocolos de Rede TCP-IP

22 Endereços IP origem e destino são obtidos do datagrama IP.

316

11 Cada conexão possui um buffer de transmissão e um buffer de recepção em cada extremidade. O compartilhamento de endpoints parece tornar problemática a demultiplexação de mensagens destinadas à porta compartilhada. No entanto, o protocolo TCP associa os segmentos recebidos às respectivas conexões, não apenas às portas. Ou seja, o processo de demultiplexação avalia o par de endpoints para apropriadamente identificar a respectiva conexão. No destino, para identificar a conexão que receberá a mensagem encapsulada no segmento, a entidade TCP associa os campos Source port e Destination port do segmento TCP com os endereços IP de origem e destino, recuperados do datagrama IP que transportou o segmento.

Vimos que, no UDP, uma porta é geralmente implementada como uma fila interna do sistema operacional. No TCP, em função do compartilhamento de endpoints, cada conexão Buffer Espaço de memória reservado para armazenar pacotes recebidos (buffer de recepção) ou a serem enviados (buffer de transmissão).

possui um buffer de transmissão e um buffer de recepção. Ao receber um segmento, o TCP verifica se existe a conexão associada ao segmento. Caso exista, a mensagem encapsulada é armazenada no final do buffer de recepção da conexão. Por outro lado, o processo de aplicação associado àquela conexão acessa as mensagens armazenadas no buffer de recepção. Caso a conexão não exista, o protocolo TCP simplesmente descarta o segmento e gera um segmento reset (bit RST ligado) para a entidade TCP de origem, indicando que o segmento não referencia uma conexão válida.

Mecanismos de controle

11 Controle de sequência 22 Fluxo de dados é tratado como uma sequência de bytes. 33 Cada byte possui um número de sequência. 33 Numeração não inicia sempre em 0, sendo negociada no estabelecimento da conexão. 11 Sequence number 22 Indica o número de sequência do primeiro byte de dados contido no segmento. Controle de sequência é o mecanismo que assegura que os dados recebidos por uma entidade estão na sequência em que foram transmitidos pela outra entidade. O protocolo TCP trata o fluxo de dados como uma sequência de bytes, que é dividida nos vários segmentos transmitidos. Conceitualmente, cada byte do fluxo de dados é sequen-

cialmente numerado, possuindo, assim, um número de sequência. Ao invés de transportar os números de sequência de todos os bytes do fluxo de dados, cada segmento transporta apenas o número de sequência do primeiro byte de dados contido no segmento. Este número de sequência é informado no campo Sequence number do segmento, comumente denominado número de sequência do segmento. Logo, o número de sequência é um inteiro de 32 bits. Para permitir a transmissão de grandes volumes de dados, a numeração dos bytes volta ao valor 0 após atingir 2 32-1.

151

198

Segmento 150 Figura 8.8 Controle de sequência TCP.

199

200

201

348

Segmento 200

349

350

351

448

449

Segmento 350

A Figura 8.8 mostra um exemplo de divisão de uma sequência de bytes em segmentos, destacando o número de sequência (Sequence number) de cada segmento enviado. Observe que cada segmento informa apenas o número de sequência do primeiro byte de dados contido no segmento. Além disso, é importante observar que a numeração do fluxo de dados não necessariamente é iniciada em 0 e os segmentos não transportam a mesma quantidade de dados. Como veremos adiante, o número de sequência inicial é negociado no estabelecimento da conexão. Na entidade TCP destino, os números de sequência dos segmentos são usados pelo mecanismo de controle de sequência para restabelecer a sequência original do fluxo de dados, recuperando a ordem correta dos segmentos recebidos e descartando os segmentos duplicados. No exemplo da Figura 8.8, se a entidade TCP destino receber os segmentos com números de sequência 150, 350, 200 e 350, ela recupera a sequência original 150, 200 e 350, trocando a

Capítulo 8 - Camada de transporte

150

ordem dos segmentos 350 e 200, bem como descartando o segmento 350 duplicado. 317

Controle de erros

11 Reconhecimento positivo 22 Destino retorna uma mensagem indicando o recebimento correto do segmento. 22 Reconhecimento pode pegar carona nos segmentos de dados do fluxo inverso. 11 Reconhecimento cumulativo 22 Diversos segmentos consecutivos podem ser reconhecidos em uma única mensagem. 11 Acknowledgment number 22 Indica o número de sequência do próximo byte que espera receber. 22 Indica o correto recebimento dos bytes com número de sequência inferior. 22 Bit ACK deve estar ativo. 11 Retransmissão 22 Origem adota um temporizador para cada segmento transmitido. 22 Segmento é retransmitido quando a origem não recebe o reconhecimento antes de expirar o temporizador. 22 O temporizador é reativado em cada retransmissão. O controle de erros é o mecanismo que realiza a detecção de erros em dados recebidos, e, em seguida, ativa procedimentos para correção destes erros. Na prática, geralmente, a correção é realizada através da retransmissão dos dados. O controle de erros é dividido em detecção e correção de erros. A detecção de erros

assegura a integridade dos segmentos, enquanto a correção de erros recupera segmentos perdidos ou corrompidos. Como vimos, o protocolo TCP implementa a detecção de erros usando o campo Checksum, onde segmentos corrompidos são simplesmente descartados. Para correção de erros, o protocolo TCP adota a técnica de reconhecimento positivo cumulativo com retransmissão. Nesta técnica, a entidade TCP destino retorna mensagens de reconhecimento positivo para a entidade TCP origem, indicando o correto recebimento de segmentos. A mensagem de reconhecimento transporta, no campo Acknowledgment number do segmento, o número de sequência do próximo byte que a entidade TCP destino (origem do reconhecimento) espera receber, indicando o correto recebimento dos bytes com número de sequência inferior. O campo Acknowledgment number é válido apenas quando o bit ACK está ativo. No exemplo da Figura 8.9, após receber o segmento 150, que transporta 50 bytes de dados

Arquitetura e Protocolos de Rede TCP-IP

(byte 150 até byte 199), a entidade TCP destino retorna um segmento de reconhecimento

318

que possui o valor 200 no campo Acknowledgment number, indicando o correto recebimento do fluxo de dados até o byte 199 e sinalizando que espera os dados a partir da posição 200.

150

151

198

Seq number 150 Ack number 200

199

200

201

348

Seq number 200 Ack number 350

349

350

351

Figura 8.9 Controle de erros.

448

Seq number 350 Ack number 450

449

Para reduzir o número de mensagens de reconhecimento, ao invés de retornar uma mensagem de reconhecimento para cada segmento recebido, a entidade TCP destino pode enviar um único reconhecimento para indicar a correta recepção de vários segmentos consecutivos. Diz-se, então, que o TCP adota reconhecimento cumulativo. Por exemplo, na Figura 8.9, após receber os segmentos 150, 200 e 350, ao invés de enviar um reconhecimento para cada um destes segmentos (como indicado na figura), a entidade TCP de destino pode enviar um único reconhecimento que possui o valor 450 no campo Acknowledgment number, indicando o correto recebimento do fluxo de dados até o byte 449 e sinalizando que aguarda os dados a partir da posição 450. Sendo a conexão TCP full-duplex, ao invés de gerar segmentos que apenas sinalizam os reconhecimentos, as entidades TCP podem enviar estes reconhecimentos em segmentos de dados do fluxo inverso. Ou seja, os reconhecimentos podem pegar carona (piggybacking) em segmentos de dados do fluxo inverso, melhorando a eficiência do protocolo. Para tal, segmentos que transportam reconhecimentos devem ativar o bit ACK e incluir o número de sequência do próximo byte esperado no campo Acknowledgment number. Considerando que segmentos podem ser perdidos ou descartados, o protocolo TCP utiliza a retransmissão para garantir a entrega do fluxo de dados. Quando uma entidade TCP origem envia um segmento, ela mantém uma cópia dos dados deste segmento e ativa um temporizador, esperando que a entidade TCP destino envie um reconhecimento dos dados. Se o reconhecimento é recebido antes do temporizador expirar, a cópia dos dados é descartada. Caso contrário, a entidade TCP origem assume que o segmento foi perdido ou descartado e retransmite os dados em um novo segmento. Em cada retransmissão, o temporizador é reativado para aguardar pelo reconhecimento. A adoção de reconhecimento cumulativo permite que uma entidade TCP origem envie vários segmentos consecutivos, antes de receber qualquer reconhecimento. No entanto, o TCP deve adotar mecanismos de controle de fluxo para regular a comunicação entre duas entidades, evitando que uma entidade envie mais dados do que a outra é capaz de receber.

Controle de fluxo 11 Janela deslizante

22 Entidades negociam o número de bytes adicionais que podem ser recebidos a partir do último reconhecimento. 33 Destino define o tamanho de sua janela de recepção em cada segmento. 33 Origem atualiza o tamanho da janela de transmissão a cada reconhecimento. 33 Reconhecimentos deslocam a janela de transmissão da origem para o primeiro 11 Window 22 Sinaliza o tamanho da janela de recepção da entidade em cada segmento enviado. Controle de fluxo é o mecanismo que regula e compatibiliza a taxa de transmissão de dados entre duas entidades, assegurando que uma entidade somente envia dados quando a outra é capaz de recebê-los. Para controle de fluxo, o protocolo TCP adota a técnica de janela deslizante (sliding window). Nesta técnica, as entidades TCP comunicantes informam, uma para a outra, o número de bytes adicionais que podem ser recebidos a partir da posição do último reconhecimento.

Capítulo 8 - Camada de transporte

byte sem reconhecimento.

Este número de bytes define o tamanho da janela de recepção da entidade TCP destino. 319

Com base nesta informação, a entidade TCP origem atualiza sua janela de transmissão, ou seja, define o número de bytes que pode enviar antes de receber outro reconhecimento.

100

101

498

499

500

501

Ack number 300

100

101

300

301

698

699

700

Figura 8.10 Controle de fluxo por janela deslizante.

701

A técnica de janela deslizante recebe esta denominação porque, após receber um reconhecimento, a janela de transmissão da entidade TCP de origem desloca-se, passando a ser iniciada no primeiro byte do fluxo que ainda não obteve uma mensagem de reconhecimento. Por exemplo, na Figura 8.10, uma janela de transmissão de 400 bytes, iniciando na posição 100, é deslocada de 200 bytes após o recebimento de um segmento, cujo Acknowledgement number seja 300. Vale ressaltar que, após receber este reconhecimento (ACK 300), a entidade TCP de origem pode transmitir mais 200 bytes. O tamanho da janela de recepção de uma conexão é informado pela entidade TCP no campo Window de cada segmento. Sendo este campo de 16 bits, o tamanho da janela é limitado a 65.535 bytes. Vale ressaltar que o protocolo TCP define uma opção que permite o incremento deste tamanho máximo da janela. Observe que, sendo ajustada a partir do campo Window de cada segmento recebido da estação destino, a janela de transmissão da estação origem representa o número de bytes que a estação destino pode armazenar em seu buffer de recepção. Portanto, o mecanismo de janela deslizante evita que segmentos enviados sejam descartados no destino por falta de espaço no buffer de recepção. O mecanismo de janela deslizante também é utilizado para evitar congestionamento na rede. Neste caso, a entidade TCP monitora os retardos associados aos reconhecimentos. Geralmente, incrementos nos retardos representam situações de congestionamento na rede. Para evitar congestionamento, a entidade TCP reduz a taxa de transmissão, diminuindo o tamanho da janela de transmissão, quando detecta incrementos nos retardos dos reconhecimentos.

Estabelecimento de conexão 11 Estabelecimento de conexão

Arquitetura e Protocolos de Rede TCP-IP

22 Three-way handshake

320

33 Negocia e sincroniza o valor inicial dos números de sequência em ambas as direções. 11 Urgent pointer 22 Sinaliza a posição na porção de dados em que terminam os dados urgentes. 22 Bit URG deve estar ativo. 11 Mecanismo push 22 Força a geração de um segmento com os dados já presentes no buffer. 22 Não aguarda o preenchimento do buffer. 22 Segmentos gerados pelo mecanismo push são marcados com a ativação do bit PSH.

Quando dois processos desejam se comunicar, as respectivas entidades TCP devem, primeiramente, estabelecer uma conexão. O protocolo TCP adota o algoritmo Three-way handshake para estabelecer uma conexão, negociando e sincronizando o valor inicial dos números de sequência dos fluxos de dados, conforme mostrado na Figura 8.11.

Entidade A (requisitante)

Entidade B (requisitada)

SYN SEQ=x SYN SEQ=x SYN SEQ=y ACK=x+1 SYN SEQ=y ACK=x+1 SEQ=x+1ACK=y+1 SEQ=x+1ACK=y+1

Inicialmente, a entidade requisitante envia um segmento SYN, que possui o bit SYN ativado, indicando um pedido de abertura de conexão. O campo Sequence number deste segmento contém o número de sequência inicial (x) escolhido pela entidade requisitante para esta conexão. Após o estabelecimento da conexão, o valor x+1 é o número de sequência do primeiro byte do fluxo de dados gerado pela entidade requisitante. Após receber e aceitar o pedido de conexão, a entidade requisitada envia um segmento SYN, cujo campo Sequence number contém o número de sequência inicial (y) escolhido pela entidade. Além disso, o campo Acknowledgement number indica que a entidade requisitada aguarda o primeiro byte (x+1) do fluxo de dados gerado pela entidade requisitante. De forma semelhante, o valor y+1 é o número de sequência do primeiro byte do fluxo de dados gerado pela entidade requisitada. Por fim, a entidade requisitante envia um segmento à entidade requisitada, informando que ambos aceitam a conexão estabelecida. Neste segmento, o campo Acknowledgement number indica que a entidade requisitante aguarda o primeiro byte (y+1) do fluxo de dados gerado pela entidade requisitada.

Exercício de fixação 1 e Abertura de conexão TCP 1. Vamos ativar o Wireshark, como fizemos anteriormente, só que desta vez para configurar

um filtro de captura. Na tela inicial do Wireshark, em vez de selecionar o botão “Start”, vamos selecionar o botão “Options” na interface de rede local. Teremos então a tela a seguir. Na janela “Capture Filter:”, digite o filtro: tcp port 80 and host “o endereço IP de sua estação” (sem as aspas). No exemplo usamos o IP: 192.168.100.103, conforme mostrado na Figura 8.12. Observe que a janela de filtro de captura fica com o fundo verde quando a sintaxe do comando está correta e vermelho quando não está correta. Essa sintaxe é compatível com a sintaxe adotada pelo programa Tcpdump.

Capítulo 8 - Camada de transporte

Figura 8.11 Abertura de conexão TCP.

321

Figura 8.12 Opções de captura de pacotes do Wireshark.

Em seguida clique em “Start” para iniciar a captura; porém, somente serão capturados os pacotes de/para a sua estação e que sejam destinados/recebidos da porta TCP 80. Os demais pacotes IP serão descartados. 2. Abra o navegador instalado na sua máquina e digite o seguinte URL: www.uol.com.br.

Aguarde alguns minutos até que todas as operações tenham sido concluídas. Feche a janela do navegador e aguarde mais um minuto, para que as conexões TCP ainda abertas possam ser fechadas. Volte para a janela do Wireshark (que ficou aberta) e só então termine a captura de pacotes clicando no quarto ícone da esquerda para a direita da barra de ferramentas (Stop the running live capture). A tela do Wireshark deverá ser semelhante à mostrada na Figura 8.13.

Observe na sua tela que foram abertas diversas conexões TCP para a carga da página inicial do Arquitetura e Protocolos de Rede TCP-IP

URL acessado, de modo a obter um melhor desempenho. As telas de todos os alunos serão

322

semelhantes, mas diferentes nos detalhes, endereços e portas envolvidos na conexão TCP. Para facilitar a compreensão dos detalhes operacionais da conexão TCP, será necessário trabalhar com um arquivo capturado previamente, para que todos tenham exatamente os mesmos valores. O arquivo em questão chama-se “Sessao8_Captura1.pcap” e está mostrado na Figura 8.13. 3. Uma vez aberto o arquivo mencionado, a tela deverá ser igual à mostrada na Figura 8.13, onde

aparecem todos os 18 registros do arquivo. Todos os registros se referem à mesma conexão TCP, que usa as portas: 80 (servidor) e 50288 (cliente). Para conseguir isso, foi necessário usar o seguinte filtro: “tcp.port == 50288” (sem as aspas). Essa sintaxe é diferente da sintaxe adotada pelo Tcpdump no filtro de captura, porque é uma sintaxe proprietária do programa Wireshark que usa interface gráfica (ao contrário do Tcpdump, que usa linha de comando).

Figura 8.13 Pacotes capturados durante o acesso a www.uol.com.br.

4. Vamos agora analisar os pacotes envolvidos na abertura desta conexão TCP, que são

exatamente os 3 primeiros pacotes (1 a 3), mostrados na Figura 8.14.

Figura 8.14 Pacotes referentes ao three-wayhandshake capturados.

Observe que os 3 pacotes são pacotes do protocolo TCP, que não tem dados da aplicação. Eles mostram o processo de abertura de conexão TCP (three-way-handshake), que é realizado ANTES do envio dos dados da aplicação. 5. Reproduzimos a seguir a Figura 8.11, que mostra o mecanismo da abertura de conexão TCP.

Entidade A (requisitante)

Entidade B (requisitada)

SYN SEQ=x SYN SEQ=x SYN SEQ=y ACK=x+1 SYN SEQ=y ACK=x+1 SEQ=x+1ACK=y+1 SEQ=x+1ACK=y+1

O primeiro pacote é enviado pelo cliente (Entidade A – requisitante) e tem o code bit SYN ligado para solicitar a abertura da conexão TCP no sentido cliente -> servidor, e informa ao servidor (Entidade B – requisitada) o seu contador de octetos enviados (SEQ=x), a partir do qual será feita a contagem dos octetos (inicialização do contador de octetos enviados). Note que o Wireshark aponta o valor zero (Seq: 0) na linha do TCP selecionada na figura, mas sabemos que esse valor é um valor randômico de 32 bits. Só é possível saber o valor real desse contador detalhando o cabeçalho do TCP, conforme mostra a Figura 8.15. O Wireshark indica zero porque ele é, na realidade, o zero relativo da contagem de octetos enviados.

Capítulo 8 - Camada de transporte

Figura 8.15 Primeiro pacote da abertura de conexão TCP.

323

6. Nesta figura foi selecionado o campo “Sequence number: 0 (relative sequence number)”.

Note que o Wireshark adverte que é um “número de sequência relativo”. O valor em hexadecimal aparece em destaque na janela inferior e vale em hexadecimal: x = fd a8 21 ac. Em decimal é: x = 4255654316. Observações importantes: 11 O endereço IP da origem é o do cliente: 192.168.100.103; 11 O endereço IP de destino é o do servidor: 200.147.3.191; 11 Portas TCP de origem e destino, respectivamente: 50288 e 80; 11 Flags: 0x02 (SYN) (significa que o code bit SYN está ligado). 7. Vamos agora visualizar os detalhes do pacote 2, que deve ser o pacote enviado pelo

servidor, no qual ele também liga o code bit SYN para solicitar a abertura da conexão TCP no sentido servidor -> cliente (lembre-se de que a conexão TCP é full-duplex), aceita o pedido de abertura de conexão TCP do cliente, inicializa seu contador de octetos enviados (SEQ=y) e reconhece o contador do cliente (x), indicando seu contador de octetos recebidos ACK=x+1 (Figura 8.11). Esse pacote está detalhado na Figura 8.16.

O contador de octetos enviados do servidor (SEQ=y) tem o valor em hexadecimal: y = 71 02 49 be, e em decimal: y = 1895975358. Observe que o contador de octetos enviados do cliente deve bater com o contador

Arquitetura e Protocolos de Rede TCP-IP

de octetos recebidos do servidor, e vice-versa.

324

Observações importantes: 11 O endereço IP da origem é o do servidor: 200.147.3.191; 11 O endereço IP de destino é o do cliente: 192.168.100.103; 11 Portas TCP de origem e destino, respectivamente: 80 e 50288; 11 Flags: 0x12 (SYN, ACK) – significa que os code bits SYN e ACK estão ligados; 11 Acknowledgement number: 1 (relative ACK number) efetua o reconhecimento do contador de octetos enviados do cliente (x), indicando o valor x+1, conforme podemos constatar na última janela (em hexadecimal: x+1 = fd a8 21 ad; em decimal: x+1 = 4255654317).

Figura 8.16 Segundo pacote da abertura de conexão TCP.

Se x é o contador dos octetos enviados pelo cliente para o servidor, e o pacote 1 não enviou nenhum octeto de dados (assim como os pacotes 2 e 3) por que, no reconhecimento efetuado pelo servidor, o contador foi incrementado de 1 (x+1)?

Note que o Wireshark informa na linha referente ao protocolo TCP o tamanho do campo de dados “Len: 0”. Nesses 3 primeiros pacotes o valor Len é sempre zero. 8. Finalmente, vamos visualizar os detalhes do pacote 3, que deve ser o pacote enviado pelo

cliente, no qual ele aceita o pedido de abertura de conexão TCP do servidor, e confirma os valores dos contadores de octetos de ambos os lados (SEQ=x+1, ACK=y+1). Esse pacote está detalhado na Figura 8.17.

O contador de octetos recebidos do cliente (ACK=y+1) tem o valor em hexadecimal: y = 71 02 49 bf, e em decimal: y = 1895975359. Observações importantes: 11 O endereço IP da origem é o do cliente: 192.168.100.103; 11 O endereço IP de destino é o do servidor: 200.147.3.191; 11 Portas TCP de origem e destino, respectivamente: 50288 e 80; 11 Flags: 0x10 (ACK) – significa que o code bit ACK está ligado. Se y é o contador dos octetos enviados pelo servidor para o cliente e o pacote 2 não enviou nenhum octeto de dados (bem como os pacotes 1 e 3), por que no reconhecimento efetuado pelo cliente o contador foi incrementado de 1 (y+1)?

Nesse ponto, a conexão TCP está estabelecida nos dois sentidos, e os contadores de octetos de ambos os lados (x e y) estão inicializados e devidamente reconhecidos; portanto, os dados da aplicação podem ser enviados a partir do pacote 4, como veremos adiante.

Capítulo 8 - Camada de transporte

Figura 8.17 Terceiro pacote da abertura de conexão TCP.

325

Transferência de dados Após estabelecer uma conexão, os respectivos processos podem enviar e receber dados simultaneamente. Os mecanismos de controle de erro, sequência e fluxo atuam durante esta fase de transferência de dados, assegurando a entrega dos fluxos de dados em ambas as direções. Vale ressaltar que, para aumentar a eficiência do protocolo contra variações dos retardos da inter-rede, o TCP adota mecanismos de ajuste dinâmico dos temporizadores de retransmissão e tamanho das janelas de transmissão e recepção. O escopo deste curso não inclui o detalhamento destes mecanismos. Embora o protocolo TCP seja orientado a fluxo, em algumas situações, um processo de aplicação pode necessitar enviar dados urgentes para o outro processo, que precisam ser tratados por este outro processo, antes dos bytes que já estão em seu buffer de recepção. Para tratar o envio de dados urgentes, o TCP usa o bit URG e o campo Urgent pointer. Quando o bit URG está ligado, o campo Urgent pointer especifica a posição na porção de dados onde terminam os dados urgentes. Portanto, o campo Urgente pointer somente é válido quando o bit URG está ligado. Como já sabemos, internamente, a entidade TCP decide como dividir o fluxo de dados em segmentos. No entanto, em aplicações interativas, é interessante o envio instantâneo dos dados para o outro processo. Para tal, o TCP provê a operação push, que força a entidade TCP a gerar um segmento com os dados presentes no buffer de transmissão, sem esperar pelo seu preenchimento. Segmentos enviados pelo mecanismo push são marcados pelo bit PSH ligado.

Exercício de fixação 2 e Envio de dados em conexão TCP 1. Os dados foram enviados através dos pacotes 4 a 16 (ver Figura 8.14). Vamos analisar

esses pacotes e descobrir como funcionam os contadores de octetos de ambos os lados.

Arquitetura e Protocolos de Rede TCP-IP

A Figura 8.18 mostra o pacote 4 em detalhe.

326

Observações importantes: 11 Sentido do pacote: cliente -> servidor; 11 Portas de origem e destino: 50288 e 80, respectivamente; 11 SEQ = 1 – contador de octetos enviados do cliente; 11 ACK = 1 – contador de octetos recebidos do cliente (não confundir com o code bit ACK);

Figura 8.18 Pacote número 4 de dados.

11 [Next sequence number: 390 (relative sequence number)] – número meramente informativo, fornecido pelo Wireshark a título de orientação; a diferença entre esse número e o contador de enviados pelo cliente deve refletir a quantidade de octetos enviados neste pacote (390 – 1 = 389). 11 Flags: 0x18 (PSH, ACK) – indica que os code bits PSH e ACK estão ligados; o uso do PSH pelo TCP do cliente é para informar ao TCP do servidor que os dados deste pacote devem ser IMEDIATAMENTE enviados para a aplicação destino, sem esperar o preenchimento do buffer de recepção do TCP; a razão disso fica clara: este pacote carrega um pedido de página web (operação GET do protocolo HTTP), de forma que o cliente não tem mais nada para enviar neste momento e vai ficar aguardando o envio da página web solicitada. 11 [SEQ/ACK analysis] [Bytes in flight: 389] – esta informação fornecida pelo Wireshark é apenas a título de orientação; o Wireshark analisa os contadores e informa que foram enviados 389 octetos “in flight”, o que significa que foram enviados, mas ainda não reconhecidos pelo servidor. Portanto, o contador de octetos enviados ainda não pode ser atualizado; o cliente tem que aguardar a confirmação (ver figuras 8.8, 8.9 e 8.10, que descrevem os mecanismos de controle de sequência, erro e fluxo). 11 Len: 389 – esta informação está na linha onde aparece o protocolo TCP e indica a quantidade de octetos de dados enviados neste pacote. 11 A última linha da janela informa que existem dados do protocolo HTTP; observe que na primeira janela onde aparece o pacote número 4, o protocolo indicado é o HTTP, porque o Wireshark informa apenas o protocolo de camada mais alta presente no pacote. 2. Vamos analisar agora o pacote de dados número 5 enviado pelo servidor em resposta ao

pacote número 4, que solicitava uma página web, conforme mostra a Figura 8.19.

Capítulo 8 - Camada de transporte

Figura 8.19 Pacote número 5 de dados.

327

11 [SEQ/ACK analysis] [This is an ACK to the segment in frame : 4] – esta informação fornecida pelo Wireshark é apenas a título de orientação; o Wireshark analisa os contadores e informa que este segmento confirma o recebimento do segmento contido no quadro 4 recebido. 11 Observe que na primeira janela onde aparece o pacote número 5, o protocolo indicado é o TCP, o que significa que não existem dados da aplicação neste pacote (ver o Len: 0). Uma vez que o servidor confirmou ter recebido os 389 octetos enviados pelo cliente no pacote número 4, o contador de octetos enviados pelo cliente deverá ser atualizado de acordo. 3. Vamos analisar o pacote de dados número 6 enviado pelo servidor, conforme mostra a

figura 8.20.

Observações importantes: 11 Sentido do pacote: servidor -> cliente; 11 Portas de origem e destino: 80 e 50288, respectivamente; 11 SEQ = 1 – contador de octetos enviados do servidor; 11 ACK = 390 – contador de octetos recebidos do servidor; 11 Flags: 0x10 (ACK) – indica que o code bit ACK está ligado, porém neste caso não tem significado especial; 11 [SEQ/ACK analysis] [Bytes in flight: 1460] – esta informação fornecida pelo Wireshark é apenas a título de orientação; o Wireshark analisa os contadores e informa que este segmento está enviando 1460 octetos de dados; 11 [Next sequence number: 1461 (relative sequence number)] – este número é meramente Arquitetura e Protocolos de Rede TCP-IP

informativo, fornecido pelo Wireshark a título de orientação; ele está indicando que o

328

próximo SEQ do servidor deverá ser atualizado para 1461, DESDE QUE o cliente reconheça os dados enviados neste pacote; 11 Observe que na primeira janela onde aparece o pacote número 6, o protocolo indicado é o HTTP, o que significa que existem dados da aplicação neste pacote. 4. O pacote número 7 é semelhante ao número 6, onde também estão sendo enviados

1460 octetos, totalizando 2920 bytes in flight (2x1460). O pacote número 8 traz algumas novidades, conforme mostrado na Figura 8.21.

Figura 8.20 Pacote número 6 de dados.

Observações importantes: 11 Sentido do pacote: cliente -> servidor; 11 Portas de origem e destino: 50288 e 80, respectivamente; 11 SEQ = 390 – contador de octetos enviados do cliente; 11 ACK = 2921 – contador de octetos recebidos do cliente; 11 Flags: 0x10 (ACK) – indica que o code bit ACK está ligado; 11 [SEQ/ACK analysis] [This is an ACK to the segment in frame : 7] – esta informação fornecida pelo Wireshark é apenas a título de orientação; o Wireshark analisa os contadores e informa que este segmento confirma o recebimento do segmento contido no quadro 7 recebido anteriormente. Observe que este pacote foi enviado pelo TCP, não contém dados da aplicação e faz um reconhecimento cumulativo dos dados enviados nos pacotes 6 e 7 pelo servidor (reveja o texto após a Figura 8.9). Os demais pacotes (até o de número 16) repetem esse mecanismo e não trazem nenhuma novidade.

Fechamento de conexão O fechamento de conexão ocorre separadamente em cada direção da conexão. Quando

os processos associados a uma conexão não mais desejam enviar dados, qualquer um deles pode solicitar o fechamento da conexão. Internamente, para fechar uma conexão, as entidades TCP adotam o algoritmo ilustrado na Figura 8.22.

Capítulo 8 - Camada de transporte

Figura 8.21 Pacote número 8 de dados.

329

Entidade A

Entidade B

FIN SEQ=x FIN SEQ=x ACK=x+1 ACK=x+1 FIN SEQ=y ACK=x+1 FIN SEQ=y ACK=x+1 ACK=y+1 ACK=y+1

Figura 8.22 Fechamento de conexão TCP.

Após receber o reconhecimento do último byte de dados transmitido, a entidade que deseja fechar a conexão (A) envia um segmento FIN, que possui o bit FIN ligado, indicando um pedido de fechamento da conexão. O campo Sequence number deste segmento contém o valor do número de sequência (x) do último byte enviado pela entidade nesta conexão. Após receber o segmento FIN, a entidade B envia um reconhecimento deste segmento, indicando o valor x+1 no campo Acknowledgement number. Neste ponto, a conexão está fechada na direção da entidade A para a entidade B. Na outra direção, a entidade B ainda pode continuar enviando dados. Quando deseja fechar a conexão nesta outra direção, a entidade B segue o mesmo procedimento, enviando um segmento FIN e recebendo um reconhecimento deste segmento. Observe que o campo Acknowledgement number do segmento FIN, enviado pela entidade B, ainda é igual a x+1, indicando que nenhum dado foi recebido da entidade A, após o fechamento da conexão naquela direção.

Exercício de fixação 3 e Fechamento de conexão TCP 1. Nas atividades anteriores, estudamos a abertura e o envio de dados numa conexão TCP.

Agora vamos analisar o fechamento da conexão. A Figura 8.23 mostra o pacote número 17

Arquitetura e Protocolos de Rede TCP-IP

do fluxo analisado nas atividades anteriores.

330

Observações importantes: 11 Sentido do pacote: cliente -> servidor; 11 Portas de origem e destino: 50288 e 80, respectivamente; 11 SEQ = 390 – contador de octetos enviados do cliente;

Figura 8.23 Pacote número 17.

11 ACK = 11033 – contador de octetos recebidos do cliente; 11 Flags: 0x11 (FIN, ACK) – indica que os code bits FIN, ACK estão ligados; portanto, o cliente está solicitando o fechamento da conexão no sentido cliente -> servidor. Este pacote foi enviado pelo protocolo TCP e não carrega dados da aplicação. 2. Analisemos o pacote 18 deste mesmo fluxo, mostrado na Figura 8.24.

Observações importantes: 11 Sentido do pacote: servidor -> cliente; 11 Portas de origem e destino: 80 e 50288, respectivamente; 11 SEQ = 11033 – contador de octetos enviados do servidor; 11 ACK = 391 – contador de octetos recebidos do servidor; 11 Flags: 0x10 (ACK) – indica que o code bit ACK está ligado; 11 [SEQ/ACK analysis] [This is an ACK to the segment in frame : 17] – esta informação fornecida pelo Wireshark é apenas a título de orientação; o Wireshark analisa os contadores e informa que este segmento confirma o recebimento do segmento contido no quadro 17 recebido anteriormente. No pacote 17 (Figura 8.23), o cliente informa que o seu contador de octetos enviados é SEQ=390, e o referido pacote não enviou dados da aplicação. Por que o contador de recebidos do servidor no pacote 18 indica: ACK=391?

Capítulo 8 - Camada de transporte

Figura 8.24 Pacote número 18.

331

A Figura 8.25 mostra um resumo do fluxo de pacotes aqui analisado. Número

Sentido

Octetos

Flags

Dados

Contadores SEQ

ACK

Observações

CLI -> SER

SYN

Solicita estabelecimento de conexão; inicializa contador SEQ.

SER -> CLI

SYN,ACK

Solicita estabelecimento de conexão; inicializa contador SEQ; aceita pedido de conexão.

CLI -> SER

ACK

Aceita pedido de conexão.

CLI -> SER

389

PSH,ACK

Envia 389 octetos.

SER -> CLI

ACK

390

Reconhece o envio de dados.

SER -> CLI

1460

ACK

390

Envia 1460 octetos.

SER -> CLI

1460

ACK

1461

390

Envia 1460 octetos.

CLI -> SER

ACK

390

2921

Reconhece o envio de dados.

SER -> CLI

1460

ACK

2921

390

Envia 1460 octetos.

SER -> CLI

1460

ACK

4381

390

Envia 1460 octetos.

CLI -> SER

ACK

390

5841

Reconhece o envio de dados.

SER -> CLI

1460

ACK

5841

390

Envia 1460 octetos.

SER -> CLI

1460

ACK

7301

390

Envia 1460 octetos.

SER -> CLI

1460

ACK

8761

390

Envia 1460 octetos.

SER -> CLI

811

FIN,PSH,ACK

10221

390

Envia 811 octetos; solicita fechamento de conexão.

CLI -> SER

ACK

390

11033

Reconhece o envio de dados; aceita fechamento de conexão.

CLI -> SER

FIN,ACK

390

11033

Solicita fechamento de conexão.

SER -> CLI

ACK

11033

391

Aceita fechamento de conexão.

Em resumo, os pacotes 1 a 3 executam a abertura da conexão TCP, os pacotes 4 a 15 executam o envio dos dados da aplicação e os pacotes 15 a 18 fecham a conexão TCP.

Arquitetura e Protocolos de Rede TCP-IP

Os dados enviados pelo servidor para o cliente foram na quantidade de 1460 bytes em cada

332

pacote, exceto no último, de 811 bytes. Por quê?

Figura 8.25 Resumo do fluxo de pacotes.

Roteiro de Atividades 8 Atividade 8.1 – Portas TCP e UDP Uma determinada aplicação utiliza a porta TCP 500, enquanto outra aplicação utiliza a porta UDP 500. Dado que ambas as aplicações estão sendo executadas na mesma estação, como o sistema operacional é capaz de diferenciar os dados que devem ser repassados para cada uma destas portas?

Atividade 8.2 – Campo com tamanho do cabeçalho Avaliando os formatos dos datagramas UDP e segmentos TCP, podemos perceber que o TCP adota um campo que indica o tamanho do cabeçalho. Por que o protocolo UDP não adota um campo com a mesma funcionalidade?

Atividade 8.3 – Portas, conexões e endpoints Diferentemente do protocolo UDP, que usa apenas a porta de destino para demultiplexar os datagramas recebidos, o protocolo TCP utiliza a identificação da conexão, ou seja, um par de endpoints. Por que o TCP não pode utilizar apenas a porta de destino?

Atividade 8.4 – Portas UDP > netstat –uan Proto

Send–Q Local Address

Foreign Address

udp

0 0.0.0.0:5000

0.0.0.0:*

udp

0 0.0.0.0:10000

0.0.0.0:*

udp

0 0.0.0.0:15000

0.0.0.0:*

State

Em sistemas Linux, o comando netstat, ativado com a opção –u, permite a visualização das portas UDP em uso. A Figura 8.26 mostra um exemplo de uso do comando netstat. A opção –a sinaliza que todas as portas UDP ativas devem ser listadas. A opção –n indica que os endereços IP e as portas não devem ser traduzidos para os respectivos nomes. Para cada porta, o comando netstat mostra: o protocolo adotado (Proto); o número de bytes na fila de recepção (Recv-Q); o número de bytes na fila de transmissão (Send-Q); o endereço IP e a porta UDP local (Local Address); o endereço IP e a porta UDP remota (Foreign Address). O endereço IP local 0.0.0.0 indica que os datagramas UDP serão aceitos quando encapsulados em datagramas IP que são endereçados a qualquer endereço IP da estação. Por outro lado, o endereço IP remoto 0.0.0.0 indica que os datagramas UDP serão aceitos de qualquer endereço IP remoto.

Capítulo 8 - Roteiro de Atividades

Figura 8.26 Exemplo de uso do comando netstat.

Recv–Q

333

1. Execute o comando netstat e identifique as portas UDP ativas na sua estação. Em esta-

ções Windows, o comando deve ser c:\netstat –p UDP -an.

2. No Linux, o arquivo /etc/services descreve a associação de portas TCP e UDP com os

nomes dos respectivos serviços. No Windows, o arquivo services está localizado em “C:\Windows\System32\drivers\etc”. Identifique os nomes dos serviços UDP que estão ativos na sua estação.

Atividade 8.5 – Portas TCP O comando netstat, ativado com a opção –t, permite identificar as conexões TCP ativas, como também as portas TCP que estão aguardando requisições de conexão. A Figura 8.27 mostra outro exemplo de uso do comando netstat. A opção –a sinaliza que todas as conexões e portas TCP devem ser listadas. A opção –n indica que os endereços IP e as portas não devem ser traduzidos para os respectivos nomes.

> netstat –tan Proto

Recv–Q

Send–Q Local Address

Foreign Address

State

tcp

0 0.0.0.0:7

0.0.0.0:*

LISTEN

tcp

0 0.0.0.0:9

0.0.0.0:*

LISTEN

tcp

0 0.0.0.0:13

0.0.0.0:*

LISTEN

tcp

0 192.168.1.2:9

192.168.1.1:32000 ESTABLISHED

Para cada conexão, o comando netstat mostra: o protocolo adotado (Proto); o número de bytes no buffer de recepção (Recv-Q); o número de bytes no buffer de transmissão (Send-Q); o endpoint local (Local Address); o endpoint remoto (Foreign Address); e o estado da conexão. As portas que aguardam requisições de conexão possuem o estado LISTEN (mostrado apenas com a opção –a). Já as conexões ativas possuem o estado ESTABLISHED. No estado LISTEN, o endereço IP local 0.0.0.0 indica que as requisições de conexão serão aceitas quando encapsuladas em datagramas IP que são endereçados a qualquer endereço IP da

Arquitetura e Protocolos de Rede TCP-IP

estação. Por outro lado, o endereço IP remoto 0.0.0.0 indica que as requisições de conexão

334

serão aceitas de qualquer endereço IP remoto. 1. Execute o comando netstat e identifique as conexões TCP ativas e as portas TCP que

estão aguardando requisições de conexão. Em estações Windows, o comando deve ser c:\netstat –p TCP -an.

2. Identifique os nomes dos serviços TCP que estão ativos e aguardando conexões.

Figura 8.27 Exemplo de uso do comando netstat.

9 Descrever as principais funções providas pela interface socket para implementar os diversos clientes e servidores. Apresentar considerações sobre o projeto de servidores, identificando e discutindo os diferentes modelos de implementação.

conceitos

Camada de aplicação, com o detalhamento do uso do modelo cliente-servidor para o desenvolvimento de aplicações em uma rede TCP/IP.

Fundamentos e protocolos da camada de aplicação 11 Trata os detalhes específicos de cada tipo de aplicação.

22 Mensagens trocadas por cada tipo de aplicação definem um protocolo de aplicação. 22 Cada protocolo de aplicação especifica a sintaxe e a semântica de suas mensagens. 11 Existem diversos protocolos de aplicação: 22 FTP 22 SMTP 22 DNS 22 HTTP 11 Implementada via processos de aplicação. 11 Processos interagem usando o modelo cliente-servidor. 11 Processos usam os serviços da camada de transporte. 11 Processos interagem com as implementações dos protocolos de transporte, através de uma API. 11 A interface socket é um dos principais exemplos de interface de interação. Até aqui, estudamos detalhes da arquitetura TCP/IP, incluindo os protocolos que proveem os serviços de comunicação fim-a-fim e a função de roteamento de datagramas. Neste capítulo, vamos estudar a camada de aplicação, que na arquitetura TCP/IP trata dos detalhes específicos de cada tipo de aplicação. O conjunto de mensagens trocadas por cada tipo de aplicação define um protocolo de aplicação. Cada protocolo de aplicação especifica a sintaxe e a semântica de suas mensagens. Existem vários protocolos de aplicação, como: FTP (File Transfer Protocol), SMTP (Simple Mail

Capítulo 9 - Camada de aplicação

objetivos

Camada de aplicação

Transfer Protocol), DNS (Domain Name System) e HTTP (Hypertext Transfer Protocol). 335

Ao contrário das demais camadas (transporte, rede e interface de rede), que são diretamente implementadas no núcleo (kernel) do sistema operacional, a camada de aplicação é Modelo cliente-servidor

implementada através de processos, que são representações do sistema operacional para programas em execução. Ou seja, na arquitetura TCP/IP, uma aplicação é apenas um pro-

cação interagem adotando o padrão de interação denominado modelo cliente-servidor.

Modelo de interação em um sistema distribuído no qual o processo servidor oferece um serviço requisitado pelo processo cliente.

A camada de aplicação usa os serviços da camada de transporte para permitir que as

Camada de transporte

aplicações se comuniquem. Uma aplicação interage com um dos protocolos de transporte

Provê a comunicação fim-a-fim entre aplicações.

grama em execução (processo). Na camada de aplicação, os usuários executam programas de aplicação que acessam serviços disponíveis através de uma inter-rede TCP/IP. Na arquitetura TCP/IP, os programas de apli-

para enviar e receber dados. Cada aplicação escolhe o serviço de transporte requerido. Se a aplicação adota o protocolo TCP, suas mensagens são encapsuladas em segmentos TCP, compondo um fluxo contínuo de dados. Caso contrário, se a aplicação adota o protocolo UDP, suas mensagens são encapsuladas em datagramas UDP, compondo uma sequência de mensagens individuais. Para selecionar e usar os serviços da camada de transporte, os processos de aplicação interagem com as implementações dos protocolos de transporte no sistema operacional através de uma API (Application Programming Interface), provida pelo próprio sistema operacional. A interface socket é um dos principais exemplos de interface de interação. Neste capítulo, estudaremos a camada de aplicação examinando o modelo cliente-servidor, a interface socket, os modelos de implementação de servidores e os principais serviços e protocolos de aplicação.

Modelo cliente-servidor Componentes:

11 Servidor 22 Processo que oferece um serviço que pode ser requisitado pelos clientes através da rede. 22 Comunica-se com o cliente somente após receber requisição. 22 Executa continuamente. 11 Cliente 22 Processo que requisita um serviço oferecido por um servidor. 22 Inicia a interação com o servidor. Arquitetura e Protocolos de Rede TCP-IP

22 Disponibiliza a interface para o usuário.

336

22 Finaliza a execução após ser utilizado pelo usuário. No modelo cliente-servidor, um servidor é um processo de aplicação que oferece um serviço que pode ser requisitado pelos clientes através da rede. Um servidor aceita requisições dos clientes, executa o processamento das requisições, e retorna os resultados para os respectivos clientes. Um cliente é um processo de aplicação que requisita um serviço oferecido por um servidor. Um cliente envia requisições através da rede para um ou mesmo para vários servidores, e, em seguida, aguarda o recebimento das respectivas respostas.

Paradigma requisição-resposta 11 Servidor

22 Aceita requisições dos clientes. 22 Executa o processamento das requisições. 22 Retorna os resultados para os clientes. 11 Cliente 22 Envia requisições através da rede para um ou vários servidores. 22 Aguarda o recebimento das respostas. A interação entre cliente e servidor adota o paradigma requisição-resposta, onde o cliente envia uma requisição e aguarda a resposta do servidor. Observe que o cliente é responsável por iniciar a interação com o servidor. O servidor somente se comunica com o cliente após receber uma requisição. É importante ressaltar que, geralmente, um cliente disponibiliza a interface para o usuário e somente existe enquanto está sendo utilizado pelo usuário. Desta forma, o cliente sempre finaliza sua execução após enviar um número finito de requisições a um ou vários servidores. Por outro lado, o servidor executa continuamente, enquanto o sistema está operacional, aceitando requisições e enviando respostas. Por exemplo, quando o usuário utiliza um navegador (cliente) para acessar recursos disponibilizados por servidores web, o navegador envia requisições para estes servidores para recuperar os recursos desejados. Quando não deseja mais utilizar o navegador, o usuário simplesmente finaliza a sua execução. No entanto, após o término da execução do navegador, os servidores que foram acessados continuam executando, atendendo a requisições de outros clientes. Para desenvolver uma aplicação cliente-servidor, uma das primeiras decisões que o projetista deve tomar diz respeito ao protocolo de transporte a ser adotado. A interação cliente-servidor pode ser realizada usando o serviço de datagramas ou o serviço de circuito virtual da camada de transporte. Ou seja, os protocolos UDP e TCP podem ser utilizados para transportar mensagens do cliente para o servidor e vice-versa. O protocolo UDP fornece um serviço não confiável e baseado em datagramas, que não garante a entrega e a sequência dos datagramas. Diferentemente, o protocolo TCP fornece um serviço confiável e baseado em fluxo de dados, que garante a entrega e a sequência do fluxo de dados.

Identificação de clientes e servidores 11 Clientes e servidores são identificados por meio de portas.

11 Servidor não precisa conhecer, previamente, a porta usada pelo cliente. 11 Servidor descobre a porta usada pelo cliente somente após receber a requisição. 11 Portas são permanentemente reservadas para serviços padronizados e bem conhecidos. 22 Porta 53 (DNS) 22 Porta 161 (SNMP) 11 Portas reservadas são utilizadas pelos servidores que implementam os respectivos serviços. 11 Demais portas são disponíveis para os clientes.

Capítulo 9 - Camada de aplicação

11 Cliente deve conhecer, previamente, a porta usada pelo servidor.

337

Vimos que a arquitetura TCP/IP adota o conceito de porta para identificar os processos

Porta

comunicantes. Portanto, no modelo cliente-servidor, o cliente e o servidor devem identificar-se

Representação interna do sistema operacional de um ponto de comunicação para envio e recebimento de dados.

usando determinados números de portas. Lembre-se de que o cliente é sempre responsável por iniciar a interação com o servidor. Para tal, o cliente deve, previamente, conhecer o número da porta usada pelo servidor. Por outro lado, o servidor somente se comunica com o cliente após receber uma requisição dele. O servidor descobre o número da porta usada pelo cliente somente após receber a requisição. Logo, o servidor não precisa, previamente, conhecer a porta usada pelo cliente. Consequentemente, no modelo cliente-servidor, somente a porta usada pelo servidor deve ser previamente conhecida pelo cliente. Em função disso, na arquitetura TCP/IP, algumas portas são permanentemente atribuídas ou reservadas para serviços padronizados e conhecidos (well known services). Por exemplo, as portas 53 e 161 são reservadas para DNS e SNMP, respectivamente. As portas reservadas são utilizadas pelos servidores que oferecem estes serviços bem conhecidos. Diferentemente, as demais portas são disponíveis para uso pelos clientes. Em sistemas Unix, os números das portas reservadas e os nomes dos respectivos serviços são indicados no arquivo /etc/services. A atribuição de uma porta única a cada serviço simplifica o desenvolvimento de clientes e servidores, pois nenhum serviço adicional é requerido para que o cliente descubra o número da porta utilizada pelo servidor que oferece o serviço desejado.

Negociação de portas 11 Servidor requisita uma porta reservada e conhecida, previamente reservada ao

seu serviço. 22 Servidor informa ao sistema operacional a porta que quer utilizar. 11 Cliente requisita uma porta qualquer não reservada. 22 Sistema operacional escolhe a porta arbitrária do cliente. O processo servidor negocia com o sistema operacional a possibilidade de abrir e usar uma porta conhecida, previamente reservada para o serviço oferecido pelo servidor. Geralmente, o processo servidor informa ao sistema operacional o número da porta que deseja utilizar. Após obter a permissão de utilizar a porta, o processo servidor aguarda, passivamente, requisições naquela porta. Após receber uma requisição, o servidor trata a requisição, retorna a resposta para o cliente, e volta a aguardar novas requisições. No outro lado, o processo cliente negocia com o sistema operacional a possibilidade de abrir e usar uma porta qualquer não reservada. Geralmente, a escolha do número da porta usada Arquitetura e Protocolos de Rede TCP-IP

pelo cliente é realizada pelo próprio sistema operacional. Após obter a permissão de utilizar

338

uma porta, o processo cliente envia uma requisição ao servidor através daquela porta, e, então, aguarda a resposta do servidor. Observe que o cliente não usa portas conhecidas, mas qualquer porta atribuída pelo sistema operacional. Lembre-se de que, dependendo do serviço de transporte adotado na interação cliente-servidor, as mensagens de requisição e resposta são transportadas em datagramas UDP ou segmentos TCP, que, como já sabemos, possuem campos que identificam as portas de origem e destino. Nas requisições, as portas de origem e destino identificam o cliente e o servidor, respectivamente. Já nas respostas, as portas origem e destino identificam o servidor e o cliente, respectivamente.

O sistema operacional deve assegurar que, quando um processo solicita a criação de uma determinada porta, somente este processo estará associado àquela porta. Vale ressaltar que, em sistemas Unix, um processo (pai) pode criar outros processos (filhos), que também estarão associados à mesma porta do processo pai. Portanto, é comum encontrar situações onde vários processos (pai e filhos) estão simultaneamente associados a uma mesma porta. Nestes casos, o projetista da aplicação é responsável por definir e controlar o acesso à porta usada conjuntamente pelos vários processos. Além disso, um determinado processo pode requisitar diversas portas ao sistema operacional.

Atribuição de portas 11 Reservada (0 – 1.023)

22 Atribuídas a serviços padronizados. 22 Acessadas apenas por processos privilegiados. 11 Registradas (1.024 – 49.151) 22 Não são reservadas, mas apenas listadas para coordenar o uso para serviços não padronizados. 22 Acessadas por quaisquer processos. 11 Dinâmicas (49.152 – 65.535) 22 Não possuem reserva, podendo ser usadas pelos clientes. 22 Acessadas por quaisquer processos. A atribuição dos números de portas é realizada pela IANA (Internet Assigned Numbers Authority), autoridade responsável pela atribuição dos números de portas reservadas e registradas. Os números das portas são divididos em três faixas: portas reservadas ou conhecidas (0 até 1.023); portas registradas (1.024 até 49.151); e portas dinâmicas (49.152 até 65.535). A lista completa de portas reservadas e registradas pode ser encontrada no catálogo de portas mantido pela IANA.

ou por alguns processos privilegiados. As portas registradas não são atribuídas, mas apenas listadas pela IANA para coordenar o uso delas pela comunidade para serviços não padronizados. As portas dinâmicas não possuem qualquer tipo de reserva e, na maioria dos casos, são usadas apenas pelos clientes. Em muitos sistemas, as portas registradas e dinâmicas podem ser acessadas por qualquer processo não privilegiado.

Interface socket 11 Socket 22 Representação interna do sistema operacional para um ponto de comunicação. 11 Interface socket 22 Define a interface entre os processos de aplicação e as implementações dos serviços de transporte. 22 Originalmente proposta para sistemas Unix e linguagem C. 22 Amplamente adotada em diversas plataformas e linguagens.

Capítulo 9 - Camada de aplicação

Para identificar as portas reservadas e registradas, consulte: http://www.iana.org/ assignments/ port-numbers

portas reservadas são atribuídas pela IANA aos serviços mais utilizados. Em muitos w As sistemas, as portas reservadas somente podem ser manipuladas por processos do sistema

339

22 Um socket é um ponto de comunicação:

33 Identificado pelos endpoints local e remoto. 33 Cada endpoint é representado pelo par (endereço IP, porta). A arquitetura TCP/IP especifica o conjunto de protocolos, mas não define a interface de interação entre os processos de aplicação e implementação dos protocolos no sistema operacional. Portanto, a interface de interação está fora do escopo das especificações da família de protocolos TCP/IP. Apesar da falta de padronização, avaliar um exemplo de interface de interação auxilia o entendimento do uso da arquitetura TCP/IP e do modelo cliente-servidor. A interface socket é apenas um exemplo de interface de interação entre os processos de aplicação e implementação dos protocolos da arquitetura TCP/IP. Originalmente, a interface socket foi proposta para sistemas Unix e linguagem C. No entanto, esta interface

Linguagem C

tem sido amplamente adotada em diversas plataformas e linguagens de programação.

Linguagem de programação procedural utilizada para desenvolver as diversas famílias do sistema operacional Unix.

Por exemplo, a interface Winsocket é adotada em sistemas Windows. Em Java, as classes Socket, DatagramSocket e ServerSocket são oferecidas para permitir a comunicação através dos protocolos UDP e TCP. Neste capítulo, a título de exemplificação, adotaremos a interface socket proposta para sistemas Unix e linguagem C. É importante ressaltar que o estudo da interface socket tem por objetivo apenas identificar as funcionalidades, não tratando de detalhes de uso das várias funções. Assim, os parâmetros de entrada e saída de cada uma das funções mencionadas não serão discutidos em detalhes, mas apenas citados. Antes de estudar as funções suportadas pela interface socket, vamos, primeiramente, entender como o sistema operacional identifica e gerencia os diversos sockets.

Estados de um socket

11 Socket ativo 22 Usado pelo cliente para enviar ativamente requisições de conexão ao servidor. 11 Socket passivo 22 Usado pelo servidor para aguardar passivamente por requisições de conexão. closed

established

Arquitetura e Protocolos de Rede TCP-IP

Figura 9.1 Estados de um socket ativo.

340

Para os processos cliente e servidor, um socket representa apenas um ponto de comunicação. Internamente, o sistema operacional identifica o socket pelos endpoints local e

Endpoint

remoto, cada um deles representado pelo par (endereço IP, porta).

Identifica de forma individual e única um ponto de comunicação em toda a inter-rede, sendo representado pelo endereço IP da estação e a porta associada ao respectivo processo de aplicação.

Considerando a interação cliente-servidor, um processo servidor deve abrir um socket e ficar passivamente aguardando requisições dos clientes. Já o processo cliente deve abrir um socket e ativamente utilizá-lo, enviando uma requisição ao servidor. Diz-se que o servidor abre o socket no modo passivo, enquanto o cliente abre o socket no modo ativo.

closed

listen

established

Figura 9.2 Estados de um socket passivo.

Internamente, o sistema operacional identifica e gerencia a interação entre o cliente e o servidor usando o respectivo socket, que, por sua vez, identifica seus endpoints local e remoto. No entanto, sockets UDP e TCP são gerenciados de forma diferente. 11 O protocolo UDP não adota o conceito de conexão. Assim, exceto quando a fila de transmissão e recepção da respectiva porta está cheia, um socket UDP está sempre pronto para enviar e receber dados. Ou seja, a qualquer momento, o processo local pode escrever ou receber dados. Desta forma, o sistema operacional não precisa definir diferentes estados para sockets UDP. 11 Já o protocolo TCP é orientado à conexão. Cada conexão é identificada de forma única Socket UDP Socket que utiliza o protocolo UDP como mecanismo de transporte. Socket TCP Socket que utiliza o protocolo TCP como mecanismo de transporte. Socket ativo Socket utilizado pelo cliente para estabelecer uma conexão com um servidor.

pelo par de endpoints associado ao socket. Ao contrário de um socket UDP, que está sempre pronto para enviar e receber dados, um socket TCP deve, primeiramente, estabelecer uma conexão com a outra extremidade. Após estabelecer a conexão, o processo local pode enviar e receber dados usando o socket TCP. Por fim, a conexão deve ser fechada, liberando o socket. Para sinalizar a situação atual da conexão, um socket TCP passa por vários estados, onde os principais são: listen, established e closed. Todo socket TCP encontra-se inicialmente no estado closed. Vale ressaltar que existem estados intermediários que não foram mencionados, para simplificar o entendimento. A figura 9.1 ilustra os estados de um socket TCP manipulado pelo cliente. Lembre-se de que o cliente cria o socket no modo ativo. Neste caso, após a criação e configuração, o cliente imediatamente envia uma requisição de conexão para o servidor. Após o estabelecimento da conexão, o socket do cliente passa do estado closed para o estado established. Por fim,

Socket utilizado pelo servidor para aguardar requisições dos clientes.

quando a conexão é fechada, o socket volta ao estado closed. No outro lado, o servidor cria o socket no modo passivo. A figura 9.2 ilustra os estados de um socket manipulado pelo servidor. Neste caso, após a criação e configuração, o socket do servidor passa do estado closed para o estado listen, indicando que está passivamente aguardando por requisições de conexão. No estado listen, o servidor pode decidir fechar o socket por um motivo qualquer, levando-o ao estado closed. No entanto, na operação normal do servidor, após receber e aceitar uma requisição de conexão, o socket passa do estado listen para o estado established. Por fim, quando a conexão é fechada, o socket volta ao estado closed.

Tratamento de endpoints 11 Endpoint local

11 Endpoint remoto Como já sabemos, internamente o sistema operacional identifica o socket pelos endpoints local e remoto, cada um deles representado pelo par (endereço IP, porta). O sistema operacional adota um procedimento default para atribuir valores aos endpoints local e remoto, mas a inter-

Capítulo 9 - Camada de aplicação

Socket passivo

face socket prevê a possibilidade dos processos especificarem os valores destes endpoints. 341

Endpoint local Criado, por default, com o endereço IP especial 0.0.0.0 e uma porta arbitrária, selecionada

pelo sistema operacional. Pode ser atribuído um endereço IP e uma porta específica. 11 Endereço IP específico deve ser evitado em sistemas multihomed, exceto por questões de segurança. 11 Servidor deve configurar uma porta específica. 11 Cliente usa a porta selecionada pelo sistema operacional. Por default, o endpoint local de um socket UDP ou TCP é identificado com o endereço IP especial 0.0.0.0 e uma porta qualquer disponível, selecionada pelo próprio sistema operacional. O endereço 0.0.0.0 indica que datagramas UDP ou requisições de conexão TCP são aceitos quando transportados em datagramas IP destinados a qualquer endereço IP das interfaces de rede do sistema. No entanto, o processo que está manipulando o socket UDP ou TCP pode especificar o endereço IP e a porta do endpoint local. Quando um endpoint local possui um endereço IP específico, os datagramas UDP ou segmentos TCP (destinados à sua porta) somente são aceitos quando endereçados àquele endereço IP. O servidor deve configurar uma porta específica e o cliente deve utilizar a porta selecionada pelo sistema operacional. Observe que, no caso de roteadores e estações multihomed, que possuem múltiplos endereços IP, a associação de um endereço IP específico ao endpoint local força que datagramas UDP ou segmentos TCP somente possam ser aceitos quando destinados àquele endereço IP. Desta forma, exceto por questões de segurança, geralmente deve-se evitar a associação de um endereço IP específico ao endpoint local.

Endpoint remoto Criado, por default, com o endereço IP especial 0.0.0.0 e a porta “*”. Pode ser atribuído

um endereço IP e uma porta específica. 11 Cliente UDP ou TCP deve especificar o endereço IP e a porta do servidor. 11 Servidor UDP pode configurar um endereço IP e uma porta específica, devendo ser evitado em sistemas multihomed (exceto por questão de segurança). 11 Servidor TCP usa a associação default. Como mencionado, o sistema operacional também gerencia o endereço IP e a porta associada ao endpoint remoto de um socket. Por default, na criação de um socket UDP ou TCP, Arquitetura e Protocolos de Rede TCP-IP

internamente, o sistema operacional associa o endereço IP especial 0.0.0.0 e a porta “*” ao

342

endpoint remoto, indicando, no servidor, que datagramas UDP ou requisições de conexão TCP são aceitos quando enviados de qualquer endereço IP e porta remota. A interface socket também provê mecanismos que permitem especificar o endereço IP e a porta do endpoint remoto. Antes de interagir com um servidor, o cliente UDP ou TCP deve associar o endereço IP e a porta do servidor ao endpoint remoto do seu socket. O servidor UDP pode atribuir um endereço IP e uma porta ao seu endpoint remoto. Neste caso, apenas os datagramas UDP enviados a partir daquele endereço IP e porta são aceitos. Novamente, exceto por questões de segurança, comumente, deve-se evitar a associação de um endereço

IP e uma porta específica ao endpoint remoto do socket de um servidor UDP. Em geral, a interface socket não permite ao servidor TCP explicitamente associar um endereço IP e uma porta ao endpoint remoto de seu socket passivo. Portanto, os sockets passivos de servidores TCP usam a associação default.

Endpoints local e remoto Vários sockets podem utilizar o mesmo número de porta local, desde que seus respec-

tivos endpoints local e remoto sejam diferentes.

> netstat –uan Proto

Recv–Q

Send–Q Local Address

Foreign Address

udp

192.168.1.33:161

0.0.0.0:*

udp

192.168.1.65:161

0.0.0.0:*

udp

0.0.0.0:161

0.0.0.0:*

State

> netstat –tan Recv–Q

Send–Q

Local Address

Foreign Address

State

tcp

192.168.1.65:25

0.0.0.0:*

LISTEN

tcp

192.168.1.129:25

0.0.0.0:*

LISTEN

tcp

0.0.0.0:25

0.0.0.0:*

LISTEN

É possível que vários sockets utilizem o mesmo número de porta local UDP ou TCP, desde que seus respectivos endpoints local e remoto possuam valores distintos. Por exemplo, o primeiro quadro da figura 9.3 mostra três sockets UDP que utilizam a porta 161. Os dois primeiros somente aceitam datagramas UDP destinados aos endereços IP: 192.168.1.33 e 192.168.1.65. Por outro lado, datagramas UDP destinados a quaisquer outros endereços IP locais, diferentes de 192.168.1.33 e 192.168.1.65, serão repassados ao terceiro socket, que possui o endereço especial 0.0.0.0 associado ao endpoint local. Portanto, na demultiplexação, o endpoint local que possui o endereço especial 0.0.0.0 deve ser avaliado por último. O mesmo comportamento também se aplica a sockets TCP. Por exemplo, o segundo quadro da mesma figura 9.3 mostra um exemplo de três sockets TCP que utilizam a porta 25. Os dois primeiros somente aceitam requisições de conexão TCP destinadas ao endereço IP: 192.168.1.65 e 192.168.1.129. Por outro lado, requisições de conexão destinadas a quaisquer outros endereços IP locais, diferentes de 192.168.1.65 e 192.168.1.129, serão repassadas ao terceiro socket, que possui o endereço especial 0.0.0.0 associado ao endpoint local.

Implementação Modelo de programação:

11 Explora chamadas ao sistema operacional. 11 Adota o modelo de arquivo baseado no paradigma “abrir-ler-escrever-fechar”. Nos sistemas Unix, a interface socket explora o conceito de chamada ao sistema operacional (system call), cuja ativação é semelhante à chamada de procedimento em linguagens de programação, onde argumentos são passados e resultados são retornados. A interface socket utiliza um modelo de programação bastante semelhante ao modelo adotado para mani-

Capítulo 9 - Camada de aplicação

Figura 9.3 Endpoints local e remoto.

Proto

343

pular arquivos, baseado no paradigma “abrir-ler-escrever-fechar”, mecanismo utilizado pelos processos para ativar facilidades providas pelo núcleo (kernel) do sistema operacional. Neste modelo, inicialmente, o processo realiza uma chamada ao sistema operacional para criar e obter a permissão de uso de um determinado socket. Em seguida, após configurar algumas características deste socket, o processo pode ler e escrever dados neste socket. Por fim, o processo realiza uma chamada ao sistema operacional para fechar o socket, indicando que não mais deseja utilizá-lo. Para permitir o uso da interface socket, os sistemas Unix proveem um conjunto de funções na linguagem C. As principais funções usadas pelos processos cliente e servidor são: 11 Socket – cria novo socket.

11 Bind – associa endereço IP e porta ao endpoint local do socket. 11 Listen – indica que socket está pronto para receber conexão. 11 Accept – bloqueia processo até chegada de conexão. 11 Connect – estabelece conexão com endpoint remoto. 11 Read/Recvfrom – lê dados de um socket TCP/socket UDP. 11 Write/Sendto – envia dados pelo socket TCP/socket UDP. Embora os processos cliente e servidor adotem a mesma interface socket, existem algumas diferenças na forma e tipo das funções utilizadas. Algumas destas funções são utilizadas tanto pelo cliente quanto pelo servidor. Por exemplo, a função socket é usada por ambos os processos para criar um novo socket. No entanto, existem funções exclusivamente utilizadas pelo cliente ou pelo servidor. Por exemplo, somente o processo cliente utiliza a função connect, enquanto apenas o processo servidor utiliza a função accept. Além disso, dependendo do protocolo de transporte adotado pelo socket, algumas destas funções não são utilizadas ou podem ser opcionalmente utilizadas. Por exemplo, as funções connect e accept não precisam ser utilizadas em sockets UDP, enquanto são essenciais em sockets TCP. Consequentemente, embora a interface socket suporte ambos os protocolos de transporte, existem diferenças na implementação de clientes e servidores UDP e TCP. Considerando as diferentes possibilidades de uso das funções providas na interface socket, a seguir vamos discutir os modelos clássicos de implementação de clientes e servidores que adotam os protocolos UDP e TCP.

Clientes e servidores UDP Arquitetura e Protocolos de Rede TCP-IP

11 Baseados em datagramas.

344

11 Mapeados sobre o protocolo UDP. 11 Bind associa a porta específica ao endpoint local. 11 Endereço 0.0.0.0 reservado ao endpoint local. 11 Recvfrom processa as mensagens recebidas. 11 O servidor envia uma resposta com sendto.

Servidor UDP

socket

bind

recvfrom

sendto

recvfrom

Comunicação

socket

sendto

Cliente UDP A figura 9.4 mostra o modelo clássico de implementação de clientes e servidores UDP. Inicialmente, o cliente e o servidor criam e obtêm a permissão de uso de seus respectivos sockets usando a função socket. Como parâmetro desta função, os processos cliente e servidor informam que o socket deve adotar o serviço de transporte baseado em datagramas. Internamente, o sistema operacional mapeia este serviço para o protocolo UDP. Como resultado, a função socket retorna o descritor do socket, que o identifica internamente no sistema operacional. Lembre-se de que o servidor adota uma porta reservada e conhecida. No entanto, a função socket não define o número da porta associada ao endpoint local do socket criado. Para tal, o servidor deve usar a função bind, informando o endereço IP e o número da porta específica que devem ser associados ao endpoint local do socket. Desta forma, mensagens destinadas ao endereço IP e à porta do endpoint local são diretamente inseridas no buffer de recepção do respectivo socket. Vale ressaltar que o endereço IP associado ao endpoint local pode ser um endereço IP específico ou o endereço especial 0.0.0.0. Conforme foi visto, geralmente o endereço especial 0.0.0.0 é associado ao endpoint local. Como o cliente não é previamente conhecido, o servidor não precisa definir o endpoint remoto do socket. Portanto, após configurar o endpoint local (bind), o servidor está pronto para receber e processar mensagens dos clientes. Para receber mensagens, o servidor utiliza a função recvfrom. Quando uma mensagem é recebida, a função recvfrom retorna o conteúdo da mensagem, bem como a identificação do endpoint remoto do cliente que a enviou. Após receber uma mensagem, o servidor processa a mensagem e envia a respectiva resposta usando a função sendto, informando como parâmetro o endpoint remoto do cliente, que foi previamente recebido através da função recvfrom. Após processar uma mensagem, o servidor volta a ativar a função recvfrom para receber novas mensagens. No outro lado, logo após criar o socket UDP, o cliente está pronto para enviar mensagens ao servidor. Para tal, o cliente deve conhecer o endpoint remoto do servidor, ou seja, o endereço IP e a porta do servidor. Para enviar mensagens, o cliente utiliza a função sendto, informando o endpoint remoto do servidor. Em seguida, o cliente usa a função recvfrom para receber a respectiva resposta do servidor. Lembre-se de que o cliente adota uma porta qualquer não reservada. Portanto, ao contrário do servidor, o cliente não precisa usar a função bind para associar um número de porta específica ao endpoint local do socket criado. No cliente, a associação de uma porta arbitrária ao endpoint local é transparentemente realizada pelo próprio sistema operacional

Capítulo 9 - Camada de aplicação

Figura 9.4 Modelo de implementação de clientes e servidores UDP.

durante a execução da função sendto. 345

Após interagir com o servidor, usando as funções sendto e recvfrom, o cliente fecha o socket com a função close, e depois finaliza a sua execução. Por outro lado, como as requisições dos vários clientes devem ser continuamente processadas, o servidor raramente utiliza a função close, exceto quando detecta alguma situação especial que requer a reinicialização do socket ou do próprio servidor.

Clientes e servidores TCP

11 Orientados à conexão. 11 Baseados em circuitos virtuais. 11 Criam novo socket a cada nova requisição. A figura 9.5 mostra o modelo clássico de implementação de clientes e servidores TCP. Da mesma forma que clientes e servidores UDP, inicialmente, o cliente e o servidor TCP criam e obtêm a permissão de uso de seus respectivos sockets usando a função socket. No entanto, como parâmetro desta função, o cliente e o servidor informam que o socket deve adotar o serviço de transporte orientado à conexão. Internamente, o sistema opera-

cional mapeia este serviço para o protocolo TCP. A função socket retorna como resultado o descritor do socket, que o identifica internamente no sistema operacional.

Figura 9.5 Modelo de implementação de clientes e servidores TCP.

Servidor TCP

socket

bind

listen

Sincronização socket

connect

read

write

Comunicação write

read

Cliente TCP Como servidores UDP, servidores TCP também adotam uma porta reservada e conhecida. No entanto, como já sabemos, a função socket não define o número da porta associada ao endpoint local do socket criado. De forma similar ao servidor UDP, o servidor TCP deve usar a função bind, informando o endereço IP e o número da porta específica que devem ser associados ao endpoint local do socket. O endereço IP associado ao endpoint local pode ser um endereço específico ou o endereço especial 0.0.0.0. No entanto, geralmente, o endereço Arquitetura e Protocolos de Rede TCP-IP

especial 0.0.0.0 é associado ao endpoint local. Como o cliente não é previamente conhecido, o servidor não precisa definir o endpoint remoto do socket. Neste ponto, o socket do servidor ainda se encontra no estado closed. Para indicar que está passivamente aguardando por requisições de conexão, o socket TCP deve estar no estado listen. Para tal, o servidor utiliza a função listen, mudando o socket para o estado listen. A partir de então, o socket está pronto para receber requisições de conexão. Desta forma, requisições de conexão destinadas ao endereço IP e à porta do endpoint local são diretamente endereçadas ao respectivo socket. Para aguardar por requisições de conexão, o servidor utiliza a função accept, que bloqueia o processo servidor até a chegada de uma requisição de conexão. Quando uma requisição de conexão é recebida, o sistema operacional cria um novo socket, e, em seguida, retorna 346

o descritor deste novo socket para o processo servidor. Neste ponto, o servidor possui dois sockets: o socket original e o novo socket. O socket original não é modificado e, portanto, ainda se encontra no estado listen. O endpoint local é aquele configurado com a função bind, e o endpoint remoto não está definido. Por outro lado, o novo socket encontra-se no estado established, indicando que está conectado ao cliente. O endpoint local do novo socket possui o endereço IP e a porta do servidor. Já o endpoint remoto do novo socket possui o endereço IP e a porta do cliente. O sistema operacional utiliza as informações do segmento TCP e o respectivo datagrama IP, que transportaram a requisição de conexão, para configurar os endereços IP e os números de portas dos endpoints local e remoto do novo socket. Logo, os endpoints local e remoto do novo socket possuem endereços IP e portas específicas. Neste estágio, o servidor está pronto para receber e processar mensagens do cliente. O servidor interage com o cliente usando o novo socket, enquanto o socket original é usado apenas para aguardar novas requisições de outros clientes. É importante ressaltar que existem diferentes formas do servidor usar estes dois sockets. Adiante vamos identificar e avaliar as principais formas. Para receber mensagens, o servidor utiliza a função read no novo socket. Após receber uma mensagem, o servidor processa a mensagem e envia a respectiva resposta via função write no novo socket. Após processar uma mensagem, o servidor volta a ativar a função read no novo socket para receber outra mensagem do cliente. Vale ressaltar que, diferentemente das funções recvfrom e sendto, que explicitamente informam o endpoint remoto do socket, as funções read e write não informam o endpoint remoto, pois ele já foi previamente configurado pelo sistema operacional durante o estabelecimento da conexão. Após interagir com o cliente usando as funções read e write, o servidor fecha o novo socket através da função close. Em seguida, como as requisições dos vários clientes devem ser continuamente processadas, o servidor volta a ativar a função accept no socket original. O servidor raramente utiliza a função close no socket original, exceto quando detecta alguma situação especial que requer a reinicialização do socket ou do próprio servidor. No outro lado, após criar o socket TCP usando a função socket, o cliente deve ativamente estabelecer uma conexão com o servidor. Para tal, o cliente utiliza a função connect, informando como parâmetro o endereço IP e a porta específica do endpoint remoto do servidor. Após estabelecer a conexão, o sistema operacional altera o estado do socket ativo para established. Observe que as funções connect e accept representam um ponto de sincronização entre o cliente e o servidor.

endereços IP e portas definidas. Lembre-se de que o cliente adota uma porta qualquer não reservada. Portanto, da mesma forma que o cliente UDP, o cliente TCP também não precisa usar a função bind para associar um número de porta específica ao endpoint local do socket criado. No cliente TCP, a associação de uma porta arbitrária ao endpoint local é transparentemente realizada pelo próprio sistema operacional durante a execução da função connect. Neste ponto, o cliente está pronto para interagir com o servidor. Para enviar mensagens ao servidor, o cliente utiliza a função write. Em seguida, o cliente usa a função read para receber a respectiva resposta do servidor. Após interagir com o servidor, usando as funções write e read, o cliente fecha o socket usando a função close, e, posteriormente, finaliza a sua execução.

Capítulo 9 - Camada de aplicação

Após o estabelecimento da conexão, o socket do cliente possui endpoints local e remoto com

347

Em resumo, o processo servidor realiza as seguintes atividades: cria um socket TCP com a função socket; associa o endereço IP e o número da porta ao endpoint local com a função bind; sinaliza que o socket está pronto para receber requisições de conexão com a função listen; aguarda requisições de conexão com a função accept; interage com o cliente usando as funções read e write no novo socket; fecha o novo socket ao final da interação com o cliente usando a função close; e, por fim, volta a aguardar requisições de conexão no socket original usando a função accept. No outro lado, o processo cliente realiza as seguintes atividades: cria um socket TCP com a função socket; estabelece uma conexão com o servidor usando a função connect; interage com o servidor usando as funções write e read; e, por fim, fecha o socket usando a função close.

Servidores de aplicação 11 Servidor iterativo (single threaded)

22 Trata requisições de um único cliente a cada instante. 22 Implementado como um único processo. 11 Servidor concorrente (multi-threaded) 22 Trata simultaneamente requisições de vários clientes. 22 Implementado com vários processos independentes. 22 Cada processo trata individualmente as requisições de um determinado cliente. Na maioria das vezes, os clientes iniciam a execução, trocam mensagens com um único servidor e depois terminam a execução. Por outro lado, geralmente, os servidores executam indefinidamente, enquanto o sistema está operacional, tratando as várias requisições dos diversos clientes. Portanto, o projeto de servidores é, geralmente, bem mais complexo que o projeto de clientes, requerendo, assim, um estudo mais detalhado das estratégias de projeto e implementação. Após receber uma requisição de conexão através da função accept, o servidor obtém o socket original, no estado listen, e o novo socket, que se encontra no estado established. Além disso, sabemos que o servidor utiliza o novo socket para comunicar-se com o cliente e o socket original apenas para aguardar novas requisições de outros clientes. No entanto, dependendo da carga de requisições do serviço e da carga de processamento destas requisições, a implementação do servidor pode ser estruturada adotando dois modelos diferentes de tratamento de requisições: o modelo iterativo e o modelo concorrente. Vale ressaltar que não existe uma categorização para os clientes, pois eles não sabem se estão se

Arquitetura e Protocolos de Rede TCP-IP

comunicando com um servidor iterativo ou concorrente.

348

Servidor iterativo Adequado para serviços com reduzida taxa de requisições e serviços cujas requisições

possuem baixa carga de processamento. No modelo iterativo, o servidor trata requisições de um único cliente a cada instante. Neste modelo, o servidor é implementado como um único processo, que trata individualmente cada requisição. Em função disso, o modelo iterativo é também denominado modelo single-threaded. A figura 9.6 ilustra a estrutura de um servidor iterativo. Nela, podemos identificar as funções que atuam no socket original e no novo socket, que é retornado pela função accept.

Servidor TCP

socket

bind

listen

read

write

Socket original Novo socket Figura 9.6 Tratamento de requisições: servidor iterativo.

Como já sabemos, o processo servidor aguarda por requisições de conexão usando a função accept. Após receber uma requisição, o servidor interage com o cliente ativando as funções read e write no novo socket. Ao final desta interação, o servidor fecha o novo socket com a função close. A seguir, o servidor reativa a função accept no socket original e volta a aguardar pela próxima requisição de conexão. Observe que o servidor iterativo processa requisições de um único cliente a cada instante. Considerando que um servidor iterativo atende um único cliente por vez, o modelo iterativo é adequado apenas para serviços com taxa reduzida de requisições e serviços cujas requisições possuem baixa carga de processamento. Desta forma, existe uma grande probabilidade de uma requisição não ser retardada ou descartada enquanto outra está sendo processada pelo servidor.

Servidor concorrente Adequado para serviços com elevada taxa de requisições e serviços cujas requisições

possuem alta carga de processamento. Por outro lado, no modelo concorrente, o servidor trata requisições de vários clientes simultaneamente. Neste modelo, o servidor é implementado como vários processos ou threads indepenFigura 9.7 Tratamento de requisições: servidor concorrente.

dentes, onde cada um deles é responsável por tratar individualmente as requisições de um determinado cliente. Em função disso, o modelo concorrente é também denominado modelo multi-threaded. A figura 9.7 ilustra a estrutura de um servidor concorrente.

Servidor TCP

socket

Socket original

bind

listen

read

write

read

write

Como no modelo iterativo, no modelo concorrente, o processo servidor (mestre) também aguarda por requisições de conexão usando a função accept. Entretanto, diferentemente do modelo iterativo, no modelo concorrente, o servidor cria um novo processo ou thread (escravo) após a chegada de uma requisição de conexão. O mestre é responsável por tratar as novas requisições de conexão de outros clientes. Para tal, o mestre reativa a função accept no socket original, que se encontra no estado listen. Por outro lado, o escravo é responsável por gerenciar a comunicação com o cliente que solicitou o estabelecimento da conexão. Para tal, o escravo interage com o cliente ativando as funções read e write no novo socket, que se encontra no estado established. Ao final desta interação, o

Capítulo 9 - Camada de aplicação

Novo socket

escravo fecha o novo socket com a função close, e, em seguida, finaliza sua execução. 349

Observe que o mestre está sempre em execução. Por outro lado, o escravo interage com um único cliente e, em seguida, finaliza sua execução. Seguindo este procedimento, em um dado momento, existe um único processo mestre, que aguarda por requisições de conexão de outros clientes, e podem existir vários processos escravos, que são responsáveis por tratar as requisições dos seus respectivos clientes. Considerando que um servidor concorrente atende a diversos clientes de forma simultânea, o modelo concorrente é adequado para serviços com elevada taxa de requisições e serviços cujas requisições possuem alta carga de processamento. A vantagem do servidor concorrente é que ele ativa outros processos para tratar cada requisição. Portanto, cada cliente possui seu próprio servidor (processo ou thread) dedicado e suas requisições são processadas concorrentemente.

Compartilhamento de portas 11 Socket do mestre:

22 Está sempre no estado listen. 22 Endpoint local possui o endereço especial 0.0.0.0 e a porta específica do servidor. 22 Endpoint remoto possui o endereço especial 0.0.0.0 e a porta “*”. 11 Sockets dos escravos: 22 Estão sempre no estado established. 22 Endpoints locais possuem o endereço IP da estação e a porta específica do servidor. 22 Endpoints remotos possuem os endereços IP e as portas dos respectivos clientes. 11 Servidor concorrente: 22 Existe um único socket no estado listen. 33 Somente processa segmentos SYN. 22 Podem existir diversos sockets no estado established. 33 Somente processam segmentos de dados. 33 Endpoints local e remoto desses sockets devem ser diferentes. Em um servidor concorrente, cada processo ou thread usa seu próprio socket. O socket do mestre está sempre no estado listen e, geralmente, seu endpoint local possui o endereço IP especial 0.0.0.0 e a porta específica do servidor. Por outro lado, os sockets dos escravos encontram-se no estado established e seus endpoints locais possuem o endereço IP da estação e a porta específica do servidor. Consequentemente, todos os sockets de um servidor concorrente possuem o mesmo número de porta. Além disso, geralmente, todos os Arquitetura e Protocolos de Rede TCP-IP

escravos de um servidor concorrente possuem o mesmo endpoint local.

350

Embora possam existir vários sockets cujos endpoints locais adotam o mesmo número de porta, o sistema operacional assegura que os endpoints remotos destes sockets são sempre diferentes. Em geral, o socket do mestre possui o endereço especial 0.0.0.0 e a porta “*” associada ao endpoint remoto, permitindo que o socket possa se conectar com qualquer cliente. Por outro lado, os sockets dos escravos possuem os endereços IP e os números das portas dos seus respectivos clientes associados aos seus endpoints remotos. Em resumo, para uma determinada porta, pode existir apenas um único socket no estado listen. No entanto, para esta mesma porta, podem existir diversos sockets no estado established, desde que seus respectivos endpoints local e remoto sejam distintos.

Vale ressaltar que, embora não seja usual, para uma determinada porta, também é possível existirem diversos sockets no estado listen, desde que cada um deles possua um diferente endereço IP associado ao endpoint local. Para cada segmento TCP recebido, a entidade TCP identifica os endpoints local e remoto. Se o segmento transporta uma requisição de conexão, a entidade TCP o encaminha ao respectivo socket no estado listen. Caso contrário, se o segmento transporta dados, a entidade TCP o envia ao respectivo socket no estado established. Portanto, o socket no estado listen somente processa segmentos que transportam requisições de conexão. Por outro lado, os demais sockets no estado established somente recebem/enviam segmentos de dados. No exemplo da figura 9.8, ao receber um segmento SYN, cujos endpoints local e remoto são (150.1.20.1, 25) e (10.1.5.1, 62789), a entidade TCP o encaminha ao socket no estado listen. Por outro lado, ao receber um segmento TCP de dados, cujos endpoints local e remoto são (150.1.20.1, 25) e (200.50.2.10, 58461), a entidade TCP o entrega ao segundo socket no estado established, presente na figura 9.8.

> netstat –tan Proto

Send–Q

Local Address

Foreign Address

tcp

tcp tcp tcp

State

0.0.0.0:25

0.0.0.0:*

150.1.20.1:25

192.10.1.50:57568

ESTABLISHED

150.1.20.1:25

200.50.2.10:58461

ESTABLISHED

150.1.20.1:25

150.10.1.20:60496

ESTABLISHED

LISTEN

Gerenciamento de conexões TCP Fila de requisições:

11 Associada a sockets TCP no estado listen. 11 Armazena requisições de conexão que já foram aceitas pela entidade TCP. 22 Processamento da requisição é realizado pela entidade TCP, e não pelo servidor. 22 Requisição presente na fila ainda não foi aceita pelo servidor. 22 Requisição somente é aceita e removida da fila quando o servidor ativa a função accept. 11 Possui capacidade fixa, mas pode ser configurada pelo servidor com a função listen. Mesmo em um servidor concorrente, quando a taxa de requisições de conexão é demasiadamente elevada, diversas requisições de conexão podem ser recebidas enquanto o processo ou thread mestre está criando o processo ou thread escravo, ou o sistema operacional está escalonando o processador a outros processos de maior prioridade. Nestes casos, tais requisições de conexão não serão aceitas pelo servidor e os respectivos clientes, erroneamente, concluirão que o servidor não está operacional. Para evitar estes casos, o sistema operacional implementa um mecanismo de tratamento de requisições de conexão, associando uma fila de requisições de conexão a cada socket TCP que se encontra no estado listen. Como o protocolo UDP não adota o conceito de conexão, a fila de requisições é usada apenas para sockets TCP. A fila de requisições apenas armazena, temporariamente, as requisições de conexão que já foram aceitas pela entidade TCP, ou seja, o procedimento three-way handshake foi realizado

Capítulo 9 - Camada de aplicação

Figura 9.8 Compartilhamento de portas.

Recv–Q

com sucesso. Observe que, neste esquema, o processamento das requisições de conexão 351

é realizado diretamente pela entidade TCP, residente no sistema operacional, e não pelo processo servidor. No entanto, as requisições presentes na fila ainda não foram aceitas pelo processo servidor. Uma requisição presente na fila somente é aceita e removida da fila quando o processo servidor ativa a função accept. A fila de requisições possui uma capacidade fixa, mas configurável. O servidor pode especificar o tamanho da fila de requisições usando a função listen. Vale ressaltar que o tamanho da fila de requisições não tem qualquer relação com o número máximo de conexões que podem ser simultaneamente estabelecidas pelo sistema, ou com o número de clientes que o servidor concorrente pode tratar simultaneamente. Quando uma requisição de conexão é recebida e a fila de requisições está cheia, a requisição é simplesmente ignorada e nenhum segmento de resposta é devolvido. Desta forma, o cliente retransmite a requisição de conexão, e, eventualmente, esta retransmissão poderá encontrar a fila de requisições com disponibilidade para aceitar novas requisições.

Multiplicidade de serviços 11 Servidor de um único serviço: aguarda requisições de conexão em um único socket,

que possui uma única porta associada ao endpoint local (implementação baseada na função accept). 11 Servidor de múltiplos serviços: aguarda requisições de conexão em diversos sockets, que possuem diferentes portas associadas aos respectivos endpoints locais (implementação baseada na função select). Para reduzir o número de processos executando em um determinado sistema, e, assim, tornar mais eficiente o escalonamento de processos realizado pelo sistema operacional, a interface socket permite que um único processo aguarde requisições de conexão em diversos sockets simultaneamente. Desta forma, um único processo servidor pode oferecer diversos serviços. Em função desta facilidade, podemos definir dois tipos de servidores: o servidor de um único serviço e o servidor de múltiplos serviços. No primeiro caso, o processo servidor aguarda requisições de conexão em um único socket, que possui uma única porta associada ao endpoint local. No segundo caso, o processo servidor aguarda requisições de conexão em diversos sockets, onde em cada um deles o endpoint local está associado a uma porta diferente. A implementação de um servidor de um único serviço é realizada usando a função accept, como foi comentado. Para suportar a implementação de um servidor de múltiplos serviços,

Arquitetura e Protocolos de Rede TCP-IP

a interface socket provê a função select, que recebe como parâmetro o conjunto de sockets,

352

nos quais o servidor deve aguardar requisições de conexão. Em um servidor de múltiplos serviços, inicialmente, o servidor cria todos os sockets desejados com a função socket, ativa a função bind em cada um destes sockets para configurar seus endpoints locais, sinaliza que estes sockets estão prontos para receber requisições de conexão com a função listen, e, então, ativa a função select para aguardar por requisições de conexão em algum destes sockets.

Da mesma forma que a função accept, a função select bloqueia a execução do servidor até que uma requisição de conexão seja recebida em alguma das portas associadas aos endpoints locais destes sockets. Após receber uma requisição em algum destes sockets, o processo servidor adota um procedimento semelhante ao descrito para o servidor concorrente. Por exemplo, em sistemas Linux, o processo xinetd implementa um servidor de múltiplos serviços. Na inicialização do sistema, este processo avalia um conjunto de arquivos de configuração que, por default, estão presentes no diretório /etc/xinetd.d. Cada um destes arquivos descreve um serviço que deve ser oferecido pelo xinetd, indicando, por exemplo, o nome do serviço, o protocolo de transporte, a porta adotada pelo serviço e o comando a ser

Capítulo 9 - Camada de aplicação

executado para tratar cada requisição dos clientes.

353

354

Arquitetura e Protocolos de Rede TCP-IP

Roteiro de Atividades 9 Atividade 9.1 – Serviços e portas Um processo servidor negocia com o sistema operacional a possibilidade de abrir e usar uma determinada porta, que foi previamente reservada para o serviço oferecido pelo servidor. Por sua vez, o sistema operacional deve assegurar que, quando um processo solicita a criação de uma determinada porta, somente esse processo estará associado àquela porta. Considere que um determinado processo está oferecendo o serviço X na porta Y, adotando o serviço de datagramas da camada de transporte. 1. Outro processo, também adotando o serviço de datagramas da camada de transporte,

pode oferecer o mesmo serviço X em outra porta Z?

2. Outro processo, adotando o serviço de circuito virtual da camada de transporte, pode

oferecer o mesmo serviço X na mesma porta Y? Explique.

Atividade 9.2 – Monitorando portas TCP O administrador de rede de uma universidade, usando o comando netstat, está monitorando as conexões do servidor web, que usa a porta TCP 80.

> netstat –tan Proto

Recv–Q

Send–Q

Local Address

Foreign Address

State

tcp

0.0.0.0:25

0.0.0.0:*

LISTEN

tcp

0.0.0.0:80

0.0.0.0:*

LISTEN

tcp

150.2.10.1:25

150.50.1.20:57461

ESTABLISHED

tcp

150.2.10.1:25

192.20.2.10:61296

ESTABLISHED

1. Na primeira execução do comando netstat, a saída obtida é mostrada na figura anterior.

Capítulo 9 - Roteiro de Atividades

O servidor web está ativo? Existem clientes conectados neste servidor? Explique.

355

2. Algum tempo depois, o administrador executou novamente o comando netstat, obtendo a

saída mostrada na figura abaixo. Existem clientes conectados nesse servidor? Explique.

> netstat –tan Proto

Recv–Q

Send–Q

Local Address

Foreign Address

State

tcp

0.0.0.0:25

0.0.0.0:*

LISTEN

tcp

0.0.0.0:80

0.0.0.0:*

LISTEN

tcp

150.2.10.1:80

192.10.1.1:55272

ESTABLISHED

tcp

150.2.10.1:80

150.10.50.1:63127

ESTABLISHED

Atividade 9.3 – Portas TCP e UDP O administrador de um determinado sistema foi recém-contratado e está tentando identificar os serviços que estão sendo oferecidos em uma determinada estação. Para tal, ele executou o comando netstat, cuja saída é mostrada na figura a seguir.

> netstat –tuan Proto

Recv–Q

Send–Q

Local Address

Foreign Address

State

tcp

0.0.0.0:25

0.0.0.0:*

LISTEN

tcp

0.0.0.0:80

0.0.0.0:*

LISTEN

tcp

192.10.1.33:25

0.0.0.0:*

LISTEN

tcp

192.10.1.33:25

200.20.1.1:55120

ESTABLISHED

tcp

192.10.1.65:25

192.10.1.1:63472

ESTABLISHED

tcp

192.10.1.65:80

150.10.50.1:54387 ESTABLISHED

udp

0.0.0.0:7

0.0.0.0:*

udp

192.10.1.97:53

0.0.0.0:*

1. Quantos servidores estão em execução nessa estação? Quais os protocolos de transporte Arquitetura e Protocolos de Rede TCP-IP

adotados por esses servidores?

356

2. Identifique os sockets usados para aguardar requisições de conexão.

3. Quantos clientes estão conectados a cada servidor?

4. Identifique os sockets usados pelos servidores para interagir com seus respectivos clientes.

Atividade 9.4 – Processamento de segmentos TCP Um determinado sistema possui três interfaces de rede, cujos endereços IP são: 192.10.1.33, 192.10.1.65 e 192.10.1.97. Considere que esse sistema possui os sockets TCP ilustrados na figura da atividade anterior. 1. Esse sistema recebeu um segmento SYN, cujas portas origem e destino são 56.267 e 25. Esse

segmento TCP foi transportado em um datagrama IP, cujos endereços origem e destino são 192.10.2.5 e 192.10.1.97. Para qual socket este segmento SYN será encaminhado?

2. Considere que o endereço destino do datagrama IP do item anterior (item 1) é 192.10.1.33.

Nesse caso, o segmento SYN será encaminhado ao mesmo socket? Explique.

3. Esse sistema recebeu e aceitou outro segmento TCP, cujas portas de origem e destino são

63.472 e 25. Esse segmento TCP foi transportado em um datagrama IP, cujos endereços origem e destino são 192.10.1.1 e 192.10.1.65. Esse segmento TCP transporta dados ou uma requisição de conexão?

Atividade 9.5 – Servidores iterativos e concorrentes Usando o comando netstat, o administrador de um determinado sistema vem monitorando o uso de dois servidores TCP, cujas portas são X e Y. Em um único caso, o administrador percebeu que a porta X estava sendo usada, simultaneamente, por cinco sockets, um deles no estado listen e os demais no estado established. Na porta Y, mesmo quando o administrador solicitou que clientes estabelecessem conexões simultâneas com o servidor, o administrador percebeu que nunca existiram mais que dois sockets associados a essa porta, sendo um no estado listen e outro no estado established. Além disso, o administrador também

Esses servidores são implementados como servidores iterativos ou concorrentes? Explique.

Capítulo 9 - Roteiro de Atividades

observou que um cliente somente é atendido após o outro fechar a conexão.

357

358

Arquitetura e Protocolos de Rede TCP-IP

10 Descrever o serviço de nomes (DNS), o serviço de correio eletrônico (SMTP) e o serviço web (HTTP).

conceitos

Protocolos da camada de aplicação e suas caraterísticas , funcionalidades e componentes das principais aplicações usadas na arquitetura TCP/IP.

Protocolos da camada de aplicação Este capítulo trata de protocolos da camada de aplicação, abordando as características, funcionalidades e componentes das principais aplicações usadas na arquitetura TCP/IP: serviço de nomes (DNS – Domain Name System); serviço de correio eletrônico (SMTP – Simple Mail Transfer Protocol); e serviço web (HTTP – Hypertext Transfer Protocol). Usa os serviços da camada de transporte para permitir a comunicação entre os

processos de aplicação. 11 Serviço de datagramas. 11 Serviço de circuito virtual. Desenvolvedor de aplicação deve selecionar o serviço de transporte a ser adotado. 11 Serviço de aplicação sem conexão: adota o protocolo UDP. 11 Serviço de aplicação com conexão: adota o protocolo TCP. Vamos conhecer um serviço de aplicação que utiliza o serviço de datagramas da camada de transporte, especificamente o protocolo UDP e dois serviços de aplicação que utilizam o serviço de circuito virtual, especificamente o protocolo TCP. Veremos as principais características dos serviços de aplicação orientados e não orientados à conexão. Serão estudadas as características, funcionalidades e componentes do serviço de nomes (DNS – Domain Name System), que utiliza o protocolo de transporte UDP, cujo principal objetivo é traduzir nomes de estações para endereços IP. A seguir estudaremos os serviços de correio eletrônico (SMTP – Simple Mail Transfer Protocol) e serviço Web (HTTP – Hypertext Transfer Protocol), que utilizam o protocolo de transporte TCP. Na arquitetura TCP/IP, a camada de aplicação usa os serviços da camada de transporte para permitir a comunicação entre os processos de aplicação. Um processo de aplicação interage

Capítulo 10 - Protocolos de aplicação

objetivos

Protocolos de aplicação

com um dos protocolos da camada de transporte para enviar e receber dados. 359

No projeto de um serviço de aplicação, uma das primeiras decisões do desenvolvedor é selecionar o serviço de transporte a ser adotado. Como já sabemos, a camada de transporte oferece os serviços de datagramas e de circuito virtual. No serviço de datagramas, os processos se comunicam usando o protocolo UDP, que não é orientado à conexão e oferece um serviço de transferência de dados não confiável. Neste caso, as mensagens geradas pelos processos de aplicação são encapsuladas em datagramas UDP independentes, compondo um conjunto de mensagens individuais, que podem não chegar ao destino ou chegar fora da sequência original. Serviços de aplicação que adotam o protocolo UDP são denominados serviços sem conexão. Por outro lado, no serviço de circuito virtual, os processos se comunicam usando o protocolo TCP, que é orientado à conexão e oferece um serviço confiável de transferência de dados. Neste caso, as mensagens geradas pelos processos de aplicação são encapsuladas em segmentos TCP, compondo um fluxo contínuo de dados que são entregues ao destino sem erros e em sequência. Serviços de aplicação que adotam o protocolo TCP são denominados serviços com conexão. Vamos estudar um exemplo de serviço de aplicação não orientado à conexão, que, portanto, adota o protocolo UDP. Veremos também exemplos de serviços de aplicação orientados à conexão, que adotam o protocolo TCP.

DNS 11 Implementa o serviço de nomes da arquitetura TCP/IP.

11 Implementado em um conjunto hierárquico e geograficamente distribuído de servidores de nomes. 11 Provê um esquema para atribuir nomes às estações. 11 Especifica um mecanismo de mapeamento automático de nomes de estações para seus respectivos endereços IP. 11 Esquema de atribuição de nomes. 22 Define a sintaxe dos nomes. 22 Define as regras de delegação de autoridade para gerenciamento de nomes. 11 Mecanismo de mapeamento. 22 Define uma base de dados distribuída que associa um determinado nome a um conjunto de atributos. 22 Adota um algoritmo de resolução distribuído que mapeia nomes para seus atributos. Arquitetura e Protocolos de Rede TCP-IP

22 Especifica um protocolo de aplicação que viabiliza a resolução de nomes.

360

Datagramas IP adotam endereços IP para identificar as estações origem e destino. Embora os endereços representem uma forma compacta de especificar as estações comunicantes, os usuários preferem identificá-las através de nomes. Consequentemente, para facilitar o uso dos diversos serviços, a arquitetura TCP/IP deve prover um serviço de nomes que permita a qualquer processo de aplicação obter o endereço IP de uma estação a partir do seu respectivo nome. Na arquitetura TCP/IP, o serviço de nomes, denominado Domain Name System (DNS), provê um esquema para atribuir nomes únicos às estações conectadas à internet e especifica um mecanismo de mapeamento direto de nomes de estações para seus respectivos endereços

Mapeamento direto Mapeamento automático de um nome de estação para seu respectivo endereço IP.

IP. O serviço de nomes da arquitetura TCP/IP é especificado nos RFCs 1034 e 1035, sendo complementado por outro conjunto de RFCs. Sintaxe de nomes

No DNS, o esquema de atribuição de nomes define a sintaxe dos nomes, bem como as

Conjunto de regras que definem como os nomes DNS devem ser escritos

regras para delegação de autoridade para gerenciamento de nomes. Por outro lado, o

Delegação de autoridade Processo no qual a responsabilidade do gerenciamento de nomes das várias zonas é delegada às diversas instituições conectadas, não existindo uma entidade central que gerencia todo o espaço de nomes. Base de dados distribuída Repositório de informações que armazena dados em servidores geograficamente distribuídos.

mecanismo de mapeamento é suportado por uma base de dados distribuída, um algoritmo de resolução distribuído e um protocolo de aplicação. A base de dados distribuída associa um determinado nome a um conjunto de atributos, por exemplo, o endereço IP. O algoritmo de resolução realiza o mapeamento dos nomes para seus respectivos atributos, mantidos na base de dados. Por sua vez, o protocolo de aplicação DNS permite a comunicação de clientes e servidores de nomes com o objetivo de realizar a resolução de nomes. O protocolo DNS utiliza a porta UDP 53. No entanto, como veremos, o DNS também utiliza a porta TCP 53 para alguns tipos de operações. O DNS define um serviço de nomes implementado em um conjunto hierárquico e geograficamente distribuído de servidores de nomes. Cada servidor de nomes é um processo de aplicação que mantém sua própria base de dados e permite que os clientes e outros processos de aplicação (locais ou remotos) possam consultar suas informações. Nenhum servidor de nomes mantém todas as informações do serviço de nomes. Ao contrário dos demais serviços que, geralmente, são utilizados diretamente pelos usuários, o DNS fornece facilidades básicas que são utilizadas de forma transparente pelos demais serviços, para traduzir nomes de estações para seus respectivos endereços IP. Por exemplo, quando o usuário informa a URL www.di.ufpb.br/index.html, antes de contatar o servidor web www.di.ufpb.br, o navegador (cliente) deve obter o endereço IP deste servidor. Para tal, o navegador simplesmente envia uma requisição ao serviço de nomes, solicitando o endereço IP associado ao nome www.di.ufpb.br. Vale ressaltar que o DNS não realiza apenas o mapeamento do nome da estação para seu respectivo endereço IP, que é apenas um tipo de atributo mantido na base de dados distri-

Mapeamento do endereço IP para seu respectivo nome de estação.

buída. Por exemplo, o DNS também permite o mapeamento reverso do endereço IP para seu respectivo nome de estação. A seguir, vamos estudar os principais aspectos do DNS. No entanto, por ser um sistema de razoável complexidade, não serão apresentados detalhes de configuração dos servidores de nomes.

Hierarquia de nomes Espaço de nomes DNS é hierárquico e tem o formato de uma árvore.

11 Notação utilizada: 22 A raiz da árvore é “.” (root). 22 Os nós intermediários são os domínios. 22 Cada nó folha representa uma estação. 22 O nome de cada nó é uma sequência de rótulos. 11 Os domínios podem ser: 22 Organizacionais. 22 Geográficos. 22 ARPA.

Capítulo 10 - Protocolos de aplicação

Mapeamento reverso

361

Raiz

arpa

com

edu

gov

int

mil

net

org

in-addr rnp

ufpb

com

gov

192 www

www.rnp.br

168 10

65.10.168.192.in-addr.arpa

Figura 10.1 Espaço de nomes.

Como ilustrado na figura 10.1, o espaço de nomes DNS possui uma organização hierárquica. Cada nó da árvore hierárquica tem um rótulo de até 63 caracteres. A raiz da árvore é um nó especial, cujo rótulo é representado por um ponto (root – raiz). Cada nó intermediário é denominado um domínio. Cada nó folha representa uma estação. O nome de um nó (domínio ou estação) é a sequência de rótulos, separados por ponto, iniciando no próprio nó e concluindo na raiz. Por exemplo, br e rnp.br são nomes de domínios, enquanto www.rnp.br é um nome de estação. Vale ressaltar que, geralmente, a literatura TCP/IP adota o termo nome de domínio (domain name) para designar o nome de ambos os tipos de nós. Todos os nós devem possuir um nome de domínio único. Desta forma, dois ou mais nós

Nome de domínio

não devem ter o mesmo rótulo, quando associados ao mesmo nó de nível superior. No

Sequência de rótulos, separados por ponto, iniciando no próprio nó e concluindo na raiz.

entanto, o mesmo rótulo pode ser usado por dois ou mais nós, desde que estejam associados a diferentes nós de nível superior. Por exemplo, na figura 10.1, os nós que representam os domínios com e com.br possuem os mesmos rótulos, mas estão associados a diferentes nós de nível superior (raiz e br). Um nome de domínio que termina com um ponto denomina-se nome de domínio absoluto. Por exemplo, www.rnp.br é um nome de domínio absoluto. O serviço DNS somente resolve nomes de domínio absolutos. Portanto, um nome de domínio incompleto, que não termina com um ponto, precisa ser completado para tornar-se um nome de domínio absoluto. A forma de completar nomes de domínios depende da implementação DNS adotada. Geral Arquitetura e Protocolos de Rede TCP-IP

mente, um nome de domínio com dois ou mais rótulos já é considerado um nome de domínio

362

absoluto pela maioria das implementações, mesmo que não termine com um ponto. Por outro lado, um nome de domínio que possui um único rótulo deve ser complementado com um sufixo, tornando-se um nome de domínio absoluto. Por exemplo, o nome www pode ser completado com o sufixo rnp.br, tornando-se o nome de domínio absoluto www.rnp.br. Conceitualmente, os domínios no nível mais alto da árvore (imediatamente abaixo da raiz) são divididos em três grupos: 11 Domínios organizacionais – compostos por rótulos de três ou mais caracteres que designam as áreas de atuação das instituições, profissionais e indivíduos: aero, coop, biz, com, edu, gov, info, int, mil, museum, name, net, org, pro.

11 Domínios geográficos – compostos por rótulos de dois caracteres que designam os códigos dos países: br, fr, uk, ... us. Padronizados pela norma ISO 3166. 11 Domínio arpa – domínio especial usado para realizar o mapeamento reverso de endereços IP para nomes de estações. Os domínios organizacionais, também denominados domínios genéricos, são usados principalmente por instituições norte-americanas. Já os domínios geográficos são usados por instituições dos demais países. No entanto, instituições que não são norte-americanas também podem usar os domínios organizacionais. Os únicos domínios organizacionais que são exclusivamente usados por instituições norte-americanas são os domínios gov e mil. Algumas instituições norte-americanas também usam o domínio geográfico us. Os domínios no nível mais alto da árvore também são conhecidos como Top Level Domain (TLD). Assim, o TLD de www.rnp.br é br, enquanto o TLD de www.google.com é com. Muitos países criam subdomínios organizacionais locais no segundo nível da hierarquia de nomes. Por exemplo, no Brasil, os domínios com.br e gov.br designam instituições comerciais e governamentais, respectivamente. No caso particular do Brasil, por razões históricas, os nomes de domínio de algumas instituições são definidos no segundo nível da hierarquia. Por exemplo, os domínios rnp.br e ufpb.br são adotados pela Rede Nacional de Ensino e Pesquisa (RNP) e Universidade Federal da Paraíba (UFPB), respectivamente. Na hierarquia de domínios, o domínio in-addr.arpa é definido com o propósito de realizar o mapeamento reverso de endereços IP para os respectivos nomes de estações. Para um dado endereço A.B.C.D, o domínio imediatamente inferior ao domínio in-addr.arpa deve ser o primeiro byte do endereço IP (A). Abaixo do domínio A, o próximo nível é o próximo byte (B), e assim por diante. Nomes de domínios são escritos do nível mais baixo para o nível mais alto. Portanto, o nome de domínio associado ao endereço A.B.C.D é D.C.B.A.in-addr. arpa. Por exemplo, o nome de domínio associado ao endereço 192.168.10.65 é 65.10.168.192. in-addr.arpa, como mostrado na figura 10.1. Na prática, o mapeamento reverso é bastante explorado como mecanismo de segurança auxiliar. Por exemplo, alguns serviços mantêm arquivos de configuração que identificam os nomes das estações autorizadas a utilizá-los. Neste caso, ao receber uma requisição, tais serviços verificam se o endereço IP da estação requisitante pertence a uma estação autorizada.

Delegação de autoridade 11 A responsabilidade do gerenciamento dos nomes é delegada às diversas instituições

conectadas à internet.

11 Divide o espaço de nomes em zonas. 11 Uma zona é uma sub-árvore do espaço de nomes. 11 Cada zona é composta por seus domínios e estações. 11 A delegação de autoridade é distribuída entre as zonas. 11 Cada zona é administrada por uma entidade autorizada. 11 A autoridade de uma zona tem autonomia para subdividi-la em subzonas menores. 11 A autoridade de uma zona pode delegar a autoridade das subzonas para diferentes entidades.

Capítulo 10 - Protocolos de aplicação

11 Não existe uma autoridade central que gerencie todo o espaço de nomes.

363

Sempre que ocorrem mudanças nas redes e estações conectadas à internet, a base de dados do serviço DNS deve ser manualmente atualizada. Em função da imensa quantidade de instituições conectadas à internet, é impossível centralizar o gerenciamento de nomes em uma única entidade. Desta forma, deve-se pensar em um esquema de delegação de autoridade, no qual a responsabilidade do gerenciamento de nomes é delegada às diversas instituições conectadas, não existindo uma entidade central gerenciadora de todo o espaço de nomes. Para tal, no DNS, o espaço de nomes hierárquico é subdividido em zonas. Conceitualmente, uma zona é uma sub-árvore do espaço de nomes hierárquico, sendo composta por seus

Zona Sub-árvore do espaço de nomes hierárquico, composta por seus domínios e estações.

domínios e estações. A delegação de autoridade é distribuída entre as várias zonas. Desta forma, cada zona é individualmente administrada por uma determinada entidade autorizada, responsável pelo gerenciamento de seus nomes. A autoridade de uma zona tem autonomia para subdividi-la em subzonas menores. Além disso, a autoridade de uma zona pode delegar a autoridade das subzonas a diferentes entidades. Por exemplo, a zona ufpb.br, delegada à Universidade Federal da Paraíba, pode ser subdividida em subzonas menores, que são delegadas aos vários centros e departamentos. Neste caso, a autoridade da zona ufpb.br é responsável por administrar a criação e remoção de subdomínios de nível imediatamente inferior, bem como atribuir nomes às estações do domínio ufpb.br. Por sua vez, a autoridade de cada subzona, por exemplo di.ufpb.br, é responsável por administrar seus subdomínios de nível inferior e suas respectivas estações.

Autoridade Raiz 11 ICANN / IANA

22 Administração dos servidores raiz. 22 Delegam os diversos TLDs (Top Level Domain). 11 Autoridade “br” 22 NIC.br/Registro.br 22 Responsável pelo .br e pelos domínios de 2o nível. 33 com.br 33 edu.br 33 gov.br O controle da zona raiz é exercido pela Internet Assigned Numbers Authority (IANA), que por sua vez é uma das entidades sob o controle da Internet Corporation for Assigned Names and Numbers (ICANN). A IANA é responsável pela administração dos dados contidos nos

Arquitetura e Protocolos de Rede TCP-IP

chamados servidores raiz (root servers), que são um conjunto de servidores de nomes, espalhados geograficamente pelo mundo, que respondem pela zona raiz. Estes servidores delegam os diversos TLDs para os servidores de outras instituições responsáveis por cada TLD. Por exemplo, o TLD br é delegado para um conjunto de servidores operados pelo Núcleo de Informação e Coordenação do Ponto BR (NIC.br). O registro de domínios dentro do TLD br é feito através do Registro.br, que é o executor do NIC.br para registros de domínios. O Registro.br é responsável também pelos domínios de 2º nível disponíveis no Brasil, como .com.br, .edu.br, .gov.br, entre outros.

Consulta ao DNS Cada nome de domínio está associado a um conjunto de atributos, e cada atributo definido por um registro de recurso (RR).

364

Como foi dito, DNS não realiza apenas o mapeamento de nomes de estações para endereços IP. Na base de dados, cada nome de domínio está associado a um conjunto de atributos, cada Registro de recurso

um deles especificado através de um registro de recurso (RR – Resource Record). Desta forma,

Estrutura adotada pelo serviço de nomes para realizar a associação de nomes de domínios a seus diferentes tipos de atributos.

para um dado nome de domínio, diferentes tipos de informações podem ser solicitados. Existem cerca de 20 diferentes tipos de registros de recursos, dos quais alguns são obsoletos. Principais tipos de registros de recursos: 11 A – associa o nome da estação ao respectivo endereço IP.

11 PTR – associa o endereço IP ao respectivo nome da estação. 11 CNAME – define um nome alternativo, ou apelido (alias), para o nome da estação. 11 HINFO – indica o hardware e o sistema operacional da estação. 11 MX – configura o roteamento de mensagens do serviço de correio eletrônico. 11 NS – define os servidores de nomes do domínio. Os registros A e PTR são usados para realizar os mapeamentos direto e reverso, respectiva-

Resolução de nomes

mente. O mapeamento direto realiza a resolução de nomes de estações para seus respec-

Processo de tradução de um determinado nome para seu respectivo endereço IP.

tivos endereços IP. Por outro lado, o mapeamento reverso realiza a resolução de endereços IP para os respectivos nomes das estações. O registro CNAME é bastante usado para identificar uma estação pelo tipo de serviço oferecido. Por exemplo, a estação sol.rnp.br pode ter os nomes alternativos www.rnp.br e ftp.rnp.br, indicando que oferece os serviços web e FTP. O DNS é particularmente importante para o serviço de correio eletrônico. O registro MX identifica o servidor de correio eletrônico que manipula as mensagens de um determinado nome de domínio, indicando onde os usuários daquele domínio recebem suas mensagens. Cada domínio pode possuir diversos registros MX, que são usados em uma ordem de preferência, indicada por um número inteiro positivo. O registro NS é utilizado para indicar o servidor de nomes de um domínio ou subdomínio. Um servidor de nomes que faça a delegação de um subdomínio utiliza o registro NS para indicar o servidor de nomes responsável pelo subdomínio.

Servidor de nomes 11 Processo de aplicação que provê os diferentes tipos de mapeamento.

11 Servidores estão geograficamente distribuídos e cooperativamente realizam a resolução de nomes. 11 O servidor de um domínio mantém informações locais sobre os seus subdomínios 11 O servidor de um domínio conhece todos os servidores de seus subdomínios imediatos. 11 Servidores formam uma árvore hierárquica, correspondendo ao espaço de nomes hierárquico. Servidor de nomes (name server) é um termo também utilizado para identificar a estação que executa o processo servidor de nomes. Além de definir as regras para sintaxe de nomes e delegação de autoridade, o DNS especifica um serviço de resolução de nomes distribuído baseado no modelo cliente-servidor. O serviço DNS é composto por um conjunto de servidores de nomes que estão geograficamente distribuídos e realizam a resolução de nomes de forma cooperativa.

Capítulo 10 - Protocolos de aplicação

e estações.

365

Um servidor de nomes é um processo de aplicação que provê diferentes tipos de mapeamento. Uma vez que a autoridade de uma zona é delegada, a entidade responsável pela zona deve definir vários servidores de nomes para a zona, provendo um mecanismo de tolerância a falhas. O servidor de nomes de um determinado domínio mantém informações locais sobre os seus subdomínios e estações, conhecendo todos os servidores de nomes dos seus subdomínios imediatamente inferiores. Assim, os servidores do domínio raiz conhecem todos os servidores dos domínios de nível mais alto, que, por sua vez, conhecem os servidores dos seus subdomínios, e assim por diante. Portanto, os servidores de nomes formam uma árvore hierárquica, correspondendo ao espaço de nomes hierárquico.

Cliente (Resolver) 11 Processo de aplicação que acessa um ou mais servidores de nomes.

11 Implementado em bibliotecas de função. 11 Torna-se parte do código da aplicação. Um cliente é qualquer processo de aplicação que acessa um ou mais servidores de nomes. O cliente é denominado resolver. Em sistemas Unix, o resolver é implementado e acessado através de bibliotecas de funções, incluídas no código da aplicação no processo de compilação ou carregadas dinamicamente em tempo de execução. Desta forma, o resolver torna-se parte do código da aplicação. O resolver envia requisições de mapeamento a um ou mais servidores de nomes para, por exemplo, obter o endereço IP de uma estação a partir do seu respectivo nome ou identificar o servidor de correio eletrônico de um dado domínio.

Servidor Bind Bind é a implementação mais adotada em sistemas Unix.

11 Servidor de nomes é denominado named. 11 Cliente é configurado no arquivo /etc/resolv.conf. nameserver 192.168.10.65 nameserver 150.10.1.1 domain rnp.br Em sistemas Unix, a implementação DNS mais adotada é denominada Berkeley Internet Name Domain (BIND), cujo servidor é denominado named. Em sistemas Linux, o arquivo

Arquitetura e Protocolos de Rede TCP-IP

/etc/resolv.conf indica como o resolver deve se comportar. A primitiva nameserver indica o endereço IP do servidor de nomes que deve ser acessado. Até três primitivas nameserver podem ser incluídas, indicando diferentes servidores de nomes que podem ser acessados em caso de falha. A primitiva domain especifica o domínio default que é automaticamente acrescentado a qualquer nome incompleto, ou seja, não termina com um ponto. Por exemplo, se o usuário informa apenas o nome www, o resolver acrescenta o sufixo rnp.br, e, em seguida, requisita ao servidor de nomes a resolução do nome absoluto www.rnp.br.

Servidor primário e secundário 11 Servidor primário (servidor mestre) 22 Mantém arquivos de configuração local com informações da zona em que possui autoridade.

366

22 Arquivos de configuração são criados e mantidos pelo administrador.

11 Servidor secundário (servidor escravo) 22 Mantém uma cópia das informações das zonas em que possui autoridade. 22 Informações são diretamente obtidas do servidor primário (transferência de zona) 22 Cada zona deve possuir um único servidor primário e, preferencialmente, um ou mais servidores secundários. 33 Devem ser independentes. 33 Devem estar localizados em diferentes segmentos físicos ou instituições. 11 Um determinado servidor pode ser primário ou secundário de diversas zonas. Existem dois tipos de servidores de nomes: primário e secundário. O servidor primário, também denominado servidor mestre, mantém as informações sobre a zona sobre a qual possui autoridade em arquivos de configuração local. Estes arquivos de configuração são criados e mantidos pelo administrador do domínio. O servidor secundário, também denominado servidor escravo, apenas mantém uma cópia das informações da zona sobre a qual possui autoridade. Estas informações são obtidas diretamente do servidor primário. Após qualquer modificação nos arquivos de configuração da zona, o administrador deve solicitar que o servidor primário releia os arquivos de configuração. Em seguida, o servidor primário envia notificações de atualização aos servidores secundários. Além disso, periodicamente, em intervalos configurados pelo administrador, o servidor secundário consulta o servidor primário para verificar se ocorreu alguma atualização nas informações da zona. O processo de transferência das informações do servidor primário para o servidor secundário é denominado transferência de zona (zone transfer). Na operação de transferência de zona, os servidores de nomes envolvidos adotam a porta TCP 53. Existe um único servidor primário para cada zona. No entanto, um determinado servidor de nomes pode ser o servidor primário ou secundário de diversas zonas. O administrador responsável pelo gerenciamento de uma zona deve configurar um servidor primário e, preferencialmente, um ou mais servidores secundários. Uma determinada zona pode não possuir servidores secundários. No entanto, para tornar o sistema menos susceptível a falhas, o administrador deve configurar pelo menos um servidor secundário. Os servidores primário e secundário devem ser independentes e estarem localizados em diferentes segmentos físicos da inter-rede ou, preferencialmente, em diferentes instituições, de modo que a disponibilidade do serviço de nomes para a zona não é afetada por uma falha em

Requisições iterativa e recursiva 11 Iterativa 22 Servidor utiliza apenas suas informações locais para resolver a requisição. 22 Resposta contém informações auxiliares que identificam os servidores com autoridade no domínio de nível mais inferior. 11 Recursiva 22 Servidor utiliza suas informações locais e, caso necessário, envia requisições a outros servidores para resolver a requisição. 22 Resposta contém as informações requisitadas.

Capítulo 10 - Protocolos de aplicação

um destes servidores, ou mesmo por uma falha na conexão da instituição com a internet.

367

Existem dois tipos de requisições: iterativa e recursiva. Em uma requisição iterativa, também denominada não recursiva, o servidor de nomes utiliza apenas suas informações locais para resolver a requisição. Se o servidor de nomes possui as informações solicitadas, ele retorna estas informações para o cliente. Caso contrário, retorna apenas informações auxiliares que permitem ao cliente prosseguir no processo de resolução da requisição. Geralmente, estas informações auxiliares identificam os servidores de nomes com autoridade no domínio de nível mais inferior, que devem ser contatados para resolver a requisição. Por exemplo, quando um servidor de nomes com autoridade no domínio ufpb.br recebe uma requisição iterativa para resolver o nome www.di.ufpb.br, ele retorna uma resposta que apenas identifica os servidores de nomes com autoridade no domínio di.ufpb.br. Desta forma, a entidade requisitante pode contatar um destes servidores de nomes do domínio di.ufpb.br para resolver o nome www.di.ufpb.br. Por outro lado, em uma requisição recursiva, o servidor de nomes utiliza suas informações locais e, caso necessário, envia requisições iterativas para outros servidores de nomes para resolver o nome requisitado pelo cliente. Observe que, ao receber uma requisição recursiva, o servidor de nomes requisitado torna-se um cliente de outros servidores de nomes. Após resolver o nome requisitado, o servidor de nomes, que foi inicialmente requisitado, retorna a informação solicitada na requisição do cliente. Desta forma, uma requisição recursiva define um processo distribuído de resolução de requisições, que será detalhado adiante. Geralmente, a maioria dos servidores suporta requisições recursivas. No entanto, os servidores do domínio raiz, também denominados servidores raiz, suportam apenas requisições iterativas.

Tipos de servidores 11 Autoritativo

22 Responde autoritativamente por um domínio. 11 Recursivo 22 Recebe requisições recursivas e envia requisições iterativas para descobrir a resposta. 11 Forwarder 22 Recebe requisições recursivas e as repassa para um servidor recursivo. Um servidor de nomes pode ser classificado também de acordo com o tipo de requisição que é capaz de atender. Um servidor de nomes que é autoridade de um ou mais domínios, e que responde a requisições sobre este(s) domínio(s), é chamado de autoritativo. Já um Arquitetura e Protocolos de Rede TCP-IP

servidor de nomes que recebe requisições recursivas, usualmente originadas de estações de

368

trabalho, e utiliza requisições iterativas para obter a resposta, é chamado de recursivo. Na prática, um servidor de nomes pode ser autoritativo e recursivo ao mesmo tempo. No entanto, os servidores do domínio raiz são apenas autoritativos e suportam apenas requisições iterativas. Um terceiro tipo de servidor de nomes é o forwarder. Usualmente encontrado em roteadores ADSL/wireless, esse tipo de servidor recebe requisições das estações de trabalho e as repassa para um servidor recursivo. Após obter a resposta do servidor recursivo, ele a repassa à estação que o solicitou.

Tipos de respostas 11 Com autoridade

22 Gerada por servidores que possuem autoridade no domínio do nome resolvido. 22 Resposta é bastante confiável, mas pode estar incorreta. 11 Sem autoridade 22 Gerada por servidores que não possuem autoridade no domínio do nome resolvido. 22 Resposta não é tão confiável, pois as informações podem ter sido modificadas. Um servidor pode retornar dois tipos de respostas: com autoridade (authoritative) e sem autoridade (non-authoritative). A resposta com autoridade somente é gerada por um servidor de nomes que possui autoridade sobre o domínio, ao qual pertence o nome que deve ser resolvido. Desta forma, a resposta com autoridade somente pode ser fornecida pelo servidor primário ou pelos servidores secundários do domínio. Neste caso, a resposta retornada é bastante confiável. No entanto, eventualmente, se um servidor secundário ainda não está sincronizado com o servidor primário, existe a possibilidade da resposta fornecida por um servidor secundário ser incorreta. A resposta sem autoridade é gerada por um servidor de nomes que não possui autoridade sobre o domínio, ao qual o nome que deve ser resolvido pertence. A resposta sem autoridade é fornecida por servidores de nomes que mantêm em cache local as informações sobre o nome que deve ser resolvido. Neste caso, a resposta retornada não é tão confiável, pois as informações do domínio podem ter sido modificadas.

Mecanismo de cache 11 Cada servidor mantém uma cache de resolução de nomes.

11 Cache armazena todas as respostas mais recentes. 22 Reduz o tráfego DNS. 22 Torna eficiente a resolução de nomes. 11 Resposta fornecida a partir da cache é sem autoridade. 11 Resposta indica os servidores com autoridade no respectivo domínio. 11 Cada entrada da cache possui um tempo de vida (Time to Live). 22 Tempo de vida de cada entrada é configurado pela entidade com autoridade no respectivo domínio. 11 Cada resposta sinaliza seu tempo de vida na cache.

Para reduzir o tráfego DNS na internet, os servidores de nomes adotam um mecanismo Cache

de cache. Cada servidor mantém uma cache de resolução de nomes que armazena todas

Mecanismo de armazenamento temporário de informações, cujas entradas são automaticamente removidas após um intervalo de tempo.

as respostas associadas aos nomes que foram recentemente resolvidos. Sempre que um servidor de nomes resolve um determinado nome, ele mantém as respectivas informações em memória. Desta forma, novas requisições para aquele mesmo nome podem usar as informações em cache. Este mecanismo reduz o tráfego DNS na internet, pois consultas adicionais a outros servidores de nomes não são necessárias. Para cada nome resolvido, a cache mantém as próprias informações associadas ao nome. Além disso, a cache também armazena informações sobre a origem das respectivas res-

Capítulo 10 - Protocolos de aplicação

11 Entrada é automaticamente removida da cache quando o seu tempo de vida expira.

postas. Quando um cliente solicita a resolução de um dado nome, primeiramente, o servidor 369

de nomes verifica se tem autoridade para aquele nome. Em caso afirmativo, ele retorna uma resposta com autoridade. Caso contrário, o servidor de nomes verifica se a cache possui o mapeamento requisitado pelo cliente. Caso afirmativo, o servidor de nomes retorna uma resposta sem autoridade, que também inclui a lista de servidores com autoridade para aquele domínio. O mecanismo de cache é bastante eficiente no DNS porque os registros de recursos de um determinado domínio não mudam frequentemente. No entanto, se as informações na cache são mantidas indefinidamente, existe uma razoável probabilidade destas informações se tornarem incorretas, pois as informações de um domínio podem ser modificadas pela entidade com autoridade. Para manter a consistência das informações na cache, os servidores de nomes associam um tempo de vida (Time to Live) a cada entrada da cache. Após expirar este intervalo de tempo, a entrada é automaticamente removida da cache. Os tempos de vida não são idênticos para todas as entradas da cache. O tempo de vida de cada entrada é configurado pela entidade com autoridade no respectivo domínio, pois esta entidade possui condições de indicar o tempo de validade das informações. Nas respostas, os servidores de nomes informam o tempo de vida da resposta, especificando o número de segundos que a entrada pode permanecer na cache.

Processamento de requisições

11 Processo distribuído de resolução de requisições. 11 Servidores de nomes usam arquivos de configuração. 11 Exemplo de processamento de requisições DNS. Como já sabemos, o DNS adota um processo distribuído de resolução de requisições. Para assegurar a correta resolução de requisições, todo cliente (resolver) deve conhecer um ou mais servidores de nomes. No entanto, os servidores de nomes não conhecem todos os

outros servidores. Todo servidor de nomes conhece os endereços dos servidores raiz. Além disso, um servidor de nomes de um determinado domínio conhece os servidores de nomes de todos os seus subdomínios de nível imediatamente inferior. Estas informações são incluídas nos arquivos de configuração dos servidores de nomes. A figura 10.2 ilustra um exemplo completo do processamento de uma requisição, no qual as requisições e respostas são mostradas usando a sintaxe do comando tcpdump. 2A? www.rnp.br Arquitetura e Protocolos de Rede TCP-IP

a.root-servers.net

370

2- 0/5/5 1+ A? www.rnp.br Resolver 1 2/4/0

Name server

3A? www.rnp.br a.dns.br 3- 0/4/4 4A? www.rnp.br 4*- 2/4/4

lua.na-df.rnp.br

Figura 10.2 Processamento de requisições DNS.

Inicialmente, o cliente (resolver) envia uma requisição recursiva para o servidor de nomes local (name server), solicitando o endereço IP (A?) associado ao nome www.rnp.br. Nesta requisição, o termo 1+ identifica o número da requisição (1) e indica que ela é recursiva (+). Após receber a requisição recursiva, o servidor de nomes local verifica se já existe uma entrada na cache com este mapeamento. Caso afirmativo, o servidor local retorna uma resposta sem autoridade para o cliente. No entanto, vamos considerar que o servidor local não possui esta informação em cache. Neste caso, o servidor local envia uma requisição iterativa para um servidor raiz (a.root-servers.net), também solicitando o endereço IP (A?) associado ao nome www.rnp.br. Nesta requisição, o termo 2 identifica o número da requisição. A ausência do termo + indica que a requisição é iterativa. Ao receber a requisição iterativa 2, o servidor raiz a.root-servers.net retorna uma resposta que contém os nomes e os respectivos endereços IP dos servidores de nomes do domínio br. Nesta resposta, o termo 2- identifica o número da resposta (2) e indica que o servidor raiz não suporta requisições recursivas (-). O termo 0/5/5 indica que a resposta não contém o endereço IP requisitado (0), mas contém cinco registros de autoridade (5) e cinco registros auxiliares (5). Os registros de autoridade identificam os nomes dos cinco servidores com autoridade no domínio br. Em complemento, os registros auxiliares identificam os endereços IP destes cinco servidores. Neste ponto, o servidor de nomes local envia uma nova requisição iterativa para um dos servidores do domínio br, também solicitando o endereço IP (A?) associado ao nome www.rnp.br. Neste exemplo, estamos assumindo que o servidor local envia a requisição ao servidor a.dns.br. Nesta requisição, o termo 3 identifica o número da requisição. Novamente, a ausência do termo + indica que a requisição é iterativa. Ao receber a requisição iterativa 3, o servidor a.dns.br retorna uma resposta que contém os nomes e os respectivos endereços IP dos servidores de nomes do domínio rnp.br. Nesta resposta, o termo 3- identifica o número da resposta (3) e indica que o servidor a.dns.br também não suporta requisições recursivas (-). O termo 0/4/4 indica que a resposta não contém o endereço IP da estação www.rnp.br (0), mas contém quatro registros de autoridade (4) e quatro registros auxiliares (4). Os registros de autoridade identificam os nomes dos quatro servidores com autoridade no domínio rnp.br. Além disso, os registros auxiliares identificam os endereços IP destes quatro servidores. Conhecendo os endereços dos servidores do domínio rnp.br, o servidor de nomes local envia uma nova requisição iterativa para um dos servidores do domínio rnp.br, também solicitando o endereço IP (A?) associado ao nome www.rnp.br. Neste exemplo, estamos

Ao receber a requisição iterativa 4, o servidor lua.na-df.rnp.br retorna uma resposta com autoridade (*) que contém os endereços IP da estação www.rnp.br. O termo 2/4/4 indica que a resposta contém dois registros de resposta (2), quatro registros de autoridade (4) e quatro registros auxiliares (4). Os dois registros de resposta contêm os endereços IP da estação www.rnp.br. Em complemento, os registros de autoridade e auxiliares sinalizam os nomes e os endereços IP dos servidores com autoridade no domínio rnp.br. Após obter os endereços IP da estação www.rnp.br, o servidor local armazena esta informação na cache, e, em seguida, retorna para o cliente a resposta sem autoridade que contém os endereços IP da estação www.rnp.br, também indicando os nomes dos quatro

Capítulo 10 - Protocolos de aplicação

assumindo que o servidor local envia a requisição iterativa 4 ao servidor lua.na-df.rnp.br.

servidores com autoridade no domínio rnp.br. 371

Como pode ser observado no exemplo, o servidor de nomes local envia requisições aos servidores de todos os domínios superiores. No entanto, na maioria dos casos, não é necessário enviar requisições aos servidores de todos os domínios superiores, pois é bastante comum um servidor de nomes ter autoridade sobre diversos domínios. Por exemplo, um único servidor de nomes pode conter informações sobre os domínios br e rnp.br, eliminando assim uma ou mais consultas remotas. Além disso, considerando que o servidor de nomes local mantém uma cache com as informações das respostas mais recentes, existe uma razoável probabilidade das requisições serem resolvidas localmente com as informações da cache.

SMTP Simple Mail Transfer Protocol (SMTP) implementa o serviço de correio eletrônico da

arquitetura TCP/IP. O serviço de correio eletrônico é uma das aplicações mais populares na internet. O serviço de correio é padronizado nos RFCs 821 e 822, que especificam o protocolo Simple Mail Transfer Protocol (SMTP) e o formato das mensagens.

Componentes

11 Agente usuário 22 Programa usado pelo usuário para ler, compor e enviar mensagens. 22 Usado pelo usuário remetente e destinatário. 22 Também denominado leitor de correio. 11 Servidor de correio 22 Realiza o roteamento de mensagens. 22 Configurado pelo administrador de domínio. 22 Também denominado agente de transferência de mensagens. 11 Caixa de mensagens (mailbox) 22 Mantém as mensagens enviadas aos respectivos usuários. 22 Cada usuário possui uma caixa de mensagens. 22 Viabiliza o modelo de comunicação assíncrona. 11 Fila de mensagens 22 Armazena temporariamente as mensagens até que seja possível entregá-las. Arquitetura e Protocolos de Rede TCP-IP

22 Adota a técnica de spooling para tratar falhas temporárias nos servidores de correio.

372

Remetente

Agente usuário

Fila de mensagens

SMTP

Servidor de correio

Caixa de mensagens

Destinatário

Fila de mensagens

SMTP

Servidor de correio

Caixa de mensagens

POP3 IMAP

Agente usuário

Figura 10.3 Serviço de correio eletrônico (SMTP).

Como mostrado na figura 10.3, o serviço de correio eletrônico envolve dois tipos de componentes: o agente usuário e o servidor de correio. O agente usuário (UA – User Agent), comumente denominado leitor de correio, é o programa usado pelo usuário para ler, compor e enviar mensagens. Assim, o agente é utilizado, tanto pelo usuário remetente, quanto pelo usuário destinatário. Como exemplos de agentes, podemos citar: pine, elm, Thunderbird e Microsoft Outlook. Os usuários escolhem o agente mais adequado às suas necessidades. O servidor de correio, também denominado Agente de Transferência de Mensagens (MTA – Message Transfer Agent), é responsável pelo roteamento de mensagens na internet. O servidor de correio mais usado em sistemas Linux é o sendmail. Os usuários não usam diretamente o servidor de correio. É responsabilidade do administrador configurar o servidor de correio de um determinado domínio. O serviço de correio eletrônico suporta um modelo de comunicação assíncrona, que não requer que o usuário esteja conectado para que mensagens possam ser enviadas para ele. Para tal, no servidor de correio de um determinado domínio, cada usuário do domínio possui uma caixa de mensagens (mailbox), também denominada caixa postal. A caixa de mensagens de um determinado usuário mantém as mensagens enviadas ao usuário. Além disso, o serviço de correio eletrônico adota a técnica de spooling para tratar de falhas temporárias nos servidores. Nesta técnica, cada servidor mantém uma fila de mensagens (spool), que armazena temporariamente as mensagens até que seja possível entregá-las.

Protocolo SMTP 11 Protocolo de aplicação do serviço de correio eletrônico da arquitetura TCP/IP.

11 Define um conjunto de comandos e respostas. 11 Especificado no RFC 821. 11 Utiliza a porta TCP 25. 11 Adotado para transportar as mensagens nos seguintes estágios: 22 Agente e servidor de correio do usuário remetente. 22 Servidores de correio dos usuários remetente e destinatário. O SMTP é o protocolo de aplicação do serviço de correio eletrônico. O SMTP utiliza a porta TCP 25. O SMTP define como as mensagens são enviadas. Na maioria dos casos, como mostra a figura 10.3, o envio de uma mensagem envolve os agentes do usuário remetente e do destinatário, como também seus respectivos servidores de correio.

11 Agente do usuário remetente envia a mensagem para o servidor do remetente.

11 Servidor do remetente armazena a mensagem na fila. 11 Servidor do remetente envia a mensagem para o servidor do destinatário. 22 Consulta o DNS, solicitando os registros MX associados ao domínio do usuário destinatário. 22 Em caso de falha, servidor do remetente mantém a mensagem na fila e tenta reenviar. 11 Servidor do destinatário armazena a mensagem na respectiva caixa de mensagens. Quando o usuário solicita o envio de uma mensagem, inicialmente, usando o protocolo SMTP, o agente do usuário remetente envia a mensagem ao servidor de correio do usuário

Capítulo 10 - Protocolos de aplicação

Envio de mensagem

373

remetente. Após receber a mensagem, o servidor do usuário remetente armazena a mensagem na fila, e, imediatamente, tenta entregá-la ao servidor do usuário destinatário. Para entregar a mensagem, primeiramente, o servidor do usuário remetente deve descobrir o servidor do usuário destinatário. Para isso, o servidor do usuário remetente consulta o serviço de nomes (DNS), solicitando os registros MX associados ao domínio do usuário destinatário. Por exemplo, se o endereço do usuário destinatário é [email protected], o servidor do usuário remetente solicita ao serviço de nomes os registros MX associados ao domínio di.ufpb.br. Caso existam diversos registros MX, o registro que possui o menor valor de preferência é selecionado. Após descobrir o endereço do servidor do usuário destinatário, usando o protocolo SMTP, o servidor do usuário remetente envia a mensagem para o servidor do usuário destinatário. Se não é possível realizar a entrega a algum servidor do usuário destinatário, o servidor do usuário remetente mantém a mensagem na fila e tenta enviar posteriormente em intervalos configurados pelo administrador. A especificação recomenda um tempo de espera de 30 minutos entre cada tentativa e um tempo de espera total de 4 ou 5 dias. Se a mensagem não é entregue dentro do tempo de espera total, que também pode ser configurado pelo administrador, o servidor do usuário remetente remove a mensagem da fila e notifica o usuário remetente enviando uma mensagem para a sua caixa de correio. Ao receber a mensagem, o servidor do usuário destinatário armazena a mensagem na caixa de mensagens do usuário. Por fim, quando o usuário destinatário deseja ler a mensagem, usando um agente usuário, ele acessa a mensagem armazenada em sua caixa de mensagens.

Leitura de mensagem Agente do usuário recupera mensagens da caixa de mensagens do servidor de correio

do usuário. 11 Acesso direto 22 Agente usuário executa na mesma estação em que reside o arquivo que contém a caixa de mensagens do usuário. 11 Acesso via protocolo de acesso 22 Agente usuário pode executar em estação diferente daquela em que reside o arquivo que contém a caixa de mensagens do usuário. 22 Adota os protocolos POP3 ou IMAP. O agente usuário pode acessar a caixa de mensagens diretamente ou através de um

Arquitetura e Protocolos de Rede TCP-IP

protocolo de acesso. No primeiro caso, o agente usuário executa na estação onde reside o arquivo que contém a caixa de mensagens e, portanto, pode acessá-lo diretamente. No segundo caso, o agente usuário pode residir em uma estação remota, diferente daquela que armazena a caixa de mensagens do usuário. Neste caso, o agente usuário adota o protocolo POP3 ou IMAP para recuperar o conteúdo da caixa de mensagens.

Comandos do protocolo O protocolo SMTP define um conjunto de comandos e respostas. Os comandos são enviados pelo cliente para o servidor. As respostas são enviadas do servidor para o cliente. O servidor deve enviar uma resposta para cada comando enviado pelo cliente. Cada resposta possui um código numérico, que sinaliza o correto processamento do comando ou indica um determinado tipo de erro. Opcionalmente, a resposta possui um pequeno texto associado, que descreve o significado da resposta.

374

Principais comandos do protocolo: 11 HELO – identifica o cliente ao servidor. 11 MAIL – indica o remetente da mensagem. 11 RCPT – informa o destinatário da mensagem. 11 DATA – envia o conteúdo da mensagem. 11 QUIT – finaliza a sessão. 11 TURN – inverte a direção de envio. 11 RSET – aborta a transação de correio. 11 VRFY – verifica a validade de um usuário. 11 EXPN – identifica a composição de uma lista. Vale ressaltar que, na comunicação entre o agente e o servidor do usuário remetente, os papéis de cliente e servidor são desempenhados pelo agente e servidor de correio, respectivamente. Além disso, na comunicação entre o servidor do usuário remetente e o servidor do usuário destinatário, os papéis de cliente e servidor são desempenhados pelo servidor remetente e servidor destinatário, respectivamente.

Modelo de interação Em geral, a interação cliente-servidor é realizada usando cinco comandos. A listagem a seguir apresenta um exemplo de envio de mensagem, onde os principais comandos e respostas do protocolo podem ser identificados. Inicialmente, o cliente estabelece uma conexão na porta TCP 25 do servidor. Imediatamente após o estabelecimento da conexão, o servidor envia a resposta de saudação 220, que sinaliza que o mesmo está pronto para iniciar uma transação. A resposta de saudação identifica o nome absoluto do servidor. Neste exemplo, o servidor é mail.rnp.br. Em seguida, o cliente identifica-se enviando o comando HELO, que contém o seu nome absoluto. Neste exemplo, o cliente é mail.di.ufpb.br. Após receber o comando HELO, se o servidor aceita a identificação do cliente, ele retorna a resposta 250, que contém os nomes absolutos do servidor e do cliente. Caso contrário, o servidor retorna uma resposta de erro 501.

S: 220 mail.rnp.br C: HELO mail.di.ufpb.br S: 250 mail.rnp.br Hello mail.di.ufpb.br, pleased to meet you C: MAIL From: [email protected] S: 250 ... Sender ok S: 250 ... Recipient ok C: DATA S: 354 Enter mail, end with “.” on a line by itself C: Teste C: . S: 250 Message accepted for delivery C: QUIT S: 221 mail.rnp.br closing connection Após a identificação das estações cliente e servidor, o cliente envia o comando MAIL para

Capítulo 10 - Protocolos de aplicação

C: RCPT To:[email protected]

indicar o início de uma transação. Neste comando, o cliente identifica o endereço de correio 375

eletrônico do usuário remetente da mensagem. No exemplo acima, o usuário remetente é [email protected] Após receber o comando MAIL, se o servidor aceita o endereço do usuário remetente, ele envia a resposta de aceitação 250. Caso contrário, o servidor retorna uma resposta de erro 501. Iniciada a transação, o cliente envia o comando RCPT, que identifica o endereço de correio eletrônico do usuário destinatário da mensagem. No exemplo acima, o usuário destinatário é [email protected] Após receber o comando RCPT, se o servidor aceita o endereço do usuário destinatário, ele envia a resposta de aceitação 250. Caso contrário, o servidor retorna a resposta de erro 550. Para uma mensagem com múltiplos destinatários, o cliente deve enviar diversos comandos RCPT, cada um deles identificando um diferente usuário destinatário. Neste caso, para cada comando RCPT enviado pelo cliente, o servidor deve retornar uma resposta de aceitação ou erro. Após indicar o remetente e os destinatários, o cliente envia o comando DATA, informando que deseja iniciar a transferência do conteúdo da mensagem. Após receber o comando DATA, o servidor envia a resposta 354, confirmando que está pronto para receber o conteúdo da mensagem. Em seguida, o cliente envia o conteúdo da mensagem. Para sinalizar o fim da mensagem, o cliente envia uma linha contendo apenas a sequência de bytes ., onde e representam os caracteres de retorno do cursor (Carriage Return) e mudança de linha (Line Feed), respectivamente. Após detectar o fim da mensagem, o servidor retorna a resposta de aceitação 250. Neste momento, a mensagem já está armazenada na fila do servidor. Desta forma, o cliente pode fechar a sessão usando o comando QUIT. O servidor confirma o fechamento da sessão enviando a resposta 221, que indica que a mensagem está sendo encaminhada ao usuário destinatário. Se o cliente possui várias mensagens para o mesmo servidor, ele pode enviar todas as mensagens na mesma sessão. Para tal, ao concluir o envio de uma mensagem, ao invés de usar o comando QUIT, o cliente inicia uma nova transação com um novo comando MAIL. Neste caso, o comando QUIT somente será usado após o envio de todas as mensagens. Consequentemente, em uma única sessão de troca de mensagens, podem existir diversas transações. Cada transação consiste de um comando MAIL, um ou vários comandos RCPT, e um comando DATA. Por fim, a sessão é fechada com o comando QUIT. Antes de fechar uma sessão, opcionalmente, o cliente pode enviar o comando TURN, solicitando a troca de papéis entre o cliente e o servidor. O comando TURN permite que mensagens sejam enviadas na direção inversa. Ao receber o comando TURN, se o servidor aceita a troca de papéis, ele envia a resposta de aceitação 250. Caso contrário, o servidor envia a Arquitetura e Protocolos de Rede TCP-IP

resposta de rejeição 502.

376

Embora os comandos apresentados sejam os mais utilizados, o protocolo SMTP define outros comandos. Por exemplo, a qualquer momento, uma transação pode ser abortada com o comando RSET, fazendo com que qualquer informação armazenada no servidor seja descartada. O comando VRFY permite ao cliente verificar se um determinado usuário é válido no servidor. O comando EXPN expande uma lista de distribuição, identificando os membros da

Lista de distribuição

lista. Geralmente, estes comandos são usados pelos administradores para depurar pro-

Grupo de usuários com algum interesse comum que se organizam para trocar mensagens através do serviço de correio eletrônico.

blemas no serviço de correio eletrônico. Por questão de segurança e privacidade, muitos administradores desabilitam os comandos VRFY e EXPN.

Estrutura da mensagem 11 Envelope

22 Contém os endereços dos usuários remetente e destinatário. 11 Cabeçalho 22 Descreve características das mensagens (From, To, Subject). 11 Corpo 22 Conteúdo da mensagem. 22 Contém apenas caracteres ASCII de 7 bits. 22 MIME permite mensagens com múltiplas partes e diferentes formatos. As mensagens são compostas por três partes, cada uma com sua função própria: 11 O envelope é usado pelo servidor de correio para realizar a entrega da mensagem. O envelope contém o endereço do remetente e o endereço do destinatário. 11 O cabeçalho contém diversas entradas. Cada entrada possui um nome, seguido pelo símbolo dois pontos (:) e o valor do campo. As entradas do cabeçalho descrevem algumas características da mensagem, como por exemplo: o endereço do usuário remetente (From), o endereço do usuário destinatário (To) e o assunto da mensagem (Subject). 11 O corpo é o conteúdo propriamente dito da mensagem e deve conter apenas caracteres ASCII de 7 bits. O agente usuário adiciona o cabeçalho ao corpo da mensagem e envia o resultado para o servidor do usuário remetente. Por sua vez, o servidor do usuário remetente adiciona algumas entradas no cabeçalho e envia o resultado ao servidor do usuário destinatário. Por fim, o servidor do usuário destinatário adiciona algumas entradas no cabeçalho e armazena a mensagem na caixa de mensagens do usuário destinatário. Como originalmente especificado, o serviço de correio eletrônico somente suporta mensagens ASCII de 7 bits. Para suportar mensagens que transportam dados binários arbitrários, a extensão MIME foi proposta nos RFCs 2045 e 2046. Esta extensão permite estruturar o corpo da mensagem em múltiplas partes. Vale ressaltar que, independente do conteúdo da mensagem, o cabeçalho e o corpo de uma mensagem MIME continuam sendo transmitidos com apenas caracteres ASCII de 7 bits. Para transportar dados binários arbitrários, a extensão MIME define mecanismos que codificam dados binários para caracteres ASCII de 7 bits. Para tal, um agente MIME remetente adiciona algumas entradas no cabeçalho e no corpo da mensagem que indicam ao agente MIME destinatário a estrutura e a codificação da mensagem. Desta forma, a extensão MIME não impõe qualquer modificação nos servidores de correio, pois apenas os agentes devem interpretar a extensão MIME.

HTTP 11 Hypertext Transfer Protocol (HTTP) 22 Implementa o serviço web. 22 Permite aos provedores de conteúdo a publicação de documentos. 22 Permite aos usuários a recuperação, visualização e navegação nos documentos.

Capítulo 10 - Protocolos de aplicação

MIME Multipurpose Internet Mail Extensions é a extensão do serviço de correio eletrônico que permite estruturar o corpo da mensagem em múltiplas partes e viabilizar o envio de mensagens que transportam dados binários arbitrários.

377

11 Cliente web (browser) 22 Permite a recuperação, visualização e navegação em documentos web. 22 Mantém uma cache que armazena os documentos recentemente recuperados. 11 Servidor web 22 Permite a publicação de documentos. 22 Gerencia um repositório de documentos que contém os objetos publicados. O serviço web, formalmente denominado World Wide Web (WWW), é a aplicação mais

usada na internet. Ele é suportado pelo protocolo Hypertext Transfer Protocol (HTTP), cuja versão 1.1 é especificada no RFC 2616. O serviço web permite aos provedores de conteúdo a publicação de documentos na internet. Por outro lado, o serviço web permite aos usuários a recuperação e a visualização de documentos, bem como a navegação na estrutura de hipertexto definida pelos documentos. Um documento web, também conhecido como página web, é composto por diversos objetos com diferentes conteúdos e formatos. A estrutura hipertexto de um documento web é definida por um arquivo Hypertext Markup Language (HTML), que contém referências (links) aos demais objetos que compõem o documento. Em um documento web (arquivo HTML), cada referência representa um objeto que deve ser recuperado. Existem diversos tipos de objetos, por exemplo: arquivos HTML, imagens JPEG e GIF e applets Java. Cada objeto é identificado por um Universal Resource Locator (URL). Cada URL identifica o nome do servidor web que armazena o objeto e o nome do objeto no sistema de arquivos deste servidor. Por exemplo, o URL www.rnp.br/newsgen/index.html está armazenado no servidor www.rnp.br e no arquivo /newsgen/index.html, relativo ao repositório de documentos deste servidor. Como mostra a figura 10.4, o serviço web envolve dois tipos de componentes: o cliente e o servidor.

Cliente Web

Cache

HTTP

Servidor Web

cumento web

O cliente web, denominado navegador, é um processo de aplicação utilizado pelo usuário Arquitetura e Protocolos de Rede TCP-IP

para recuperar e visualizar os documentos web, bem como navegar na estrutura de hiper-

378

texto definida pelos vários documentos. Existem diversas implementações do cliente web, sendo as mais populares o Firefox, o Google Chrome e o Microsoft Internet Explorer. Por outro lado, o servidor web é um processo de aplicação que gerencia um repositório de documentos web, publicados pelos respectivos provedores de conteúdo. Além disso, o servidor web permite que os clientes web possam recuperar estes documentos. Também existem diversas implementações de servidores web, onde os mais adotados são o Apache e o Microsoft Internet Information Service. Por default, o servidor web aguarda requisições de conexão na porta TCP 80. No entanto, a

Figura 10.4 Características do HTTP.

porta adotada pode ser configurada pelo administrador do servidor. Neste caso, a nova porta deve ser explicitamente informada em todas as URLs que referenciam documentos armazenados neste servidor. O cliente web também assume, por default, que o servidor aguarda requisições na porta TCP 80. Desta forma, a porta 80 não precisa ser informada nas URLs.

Protocolo HTTP 11 Define um conjunto de mensagens de requisição e resposta.

11 Especificado no RFC 2616. 11 Adota a porta TCP 80. 11 Requisição 22 Composta por uma linha de requisição, linhas de cabeçalho e corpo. 11 Resposta 22 Composta por uma linha de status, linhas de cabeçalho e corpo. O protocolo HTTP define os tipos e os formatos das mensagens trocadas entre os clientes e os servidores. Quando o usuário clica em uma determinada URL, solicitando um documento web, o cliente envia uma mensagem de requisição HTTP para o respectivo servidor, solicitando o objeto especificado na URL. Ao receber uma requisição, o servidor recupera o documento solicitado e retorna uma mensagem de resposta que contém este documento. Após recuperar um documento web, o cliente identifica cada objeto que compõe este documento base, e, em seguida, envia uma nova mensagem de requisição HTTP para recuperar cada um destes objetos. Para cada mensagem de requisição, o servidor retorna uma resposta que contém o objeto solicitado. O HTTP é um protocolo sem estado, pois os servidores web não armazenam qualquer informação sobre os clientes web.

Tipos de conexões 11 Conexão não persistente

22 Transporta uma única requisição e sua respectiva resposta. 22 Recupera um único objeto. 22 Servidor fecha a conexão após a resposta. 11 Conexão persistente 22 Pode transportar diversas requisições e suas respectivas respostas. 22 Todos os objetos de um documento podem ser recuperados em uma única conexão.

11 Conexão não persistente serial 22 Cliente estabelece uma conexão por vez e recupera um objeto em cada conexão. 11 Conexão não persistente paralela 22 Cliente estabelece conexões simultâneas e recupera um objeto em cada conexão. 11 Conexão persistente não paralela 22 Uma nova requisição é enviada somente após o recebimento da resposta anterior. 11 Conexão persistente paralela 22 Diversas requisições podem ser enviadas antes do recebimento de qualquer resposta.

Capítulo 10 - Protocolos de aplicação

22 Servidor fecha a conexão após um intervalo de inatividade.

379

O protocolo HTTP adota o conceito de conexões persistentes e conexões não persistentes. Vale ressaltar que a versão 1.0 do protocolo HTTP suporta apenas conexões não persistentes. Em uma conexão não persistente, o cliente estabelece a conexão com o servidor e envia a mensagem de requisição para recuperar um determinado objeto. No outro lado, o servidor processa a requisição, retorna a mensagem de resposta contendo o objeto solicitado, e, em seguida, imediatamente fecha a conexão. Desta forma, cada conexão não persistente transporta uma única mensagem de requisição e sua respectiva resposta. Consequentemente, uma conexão não persistente deve ser estabelecida para cada objeto requisitado pelo cliente. Dependendo da implementação do cliente web, para um determinado documento web composto por diversos objetos, as conexões não persistentes podem ser estabelecidas no modo serial ou paralelo. No modo serial, o cliente estabelece uma conexão por vez e recupera um objeto em cada conexão. No modo paralelo, o cliente estabelece diversas conexões simultâneas e recupera um objeto em cada conexão. Na prática, muitos clientes web permitem que os usuários configurem o número máximo de conexões paralelas que podem ser estabelecidas. Em uma conexão persistente, após enviar a resposta, o servidor mantém a conexão aberta, permitindo que requisições e respostas subsequentes possam ser enviadas na mesma conexão. Desta forma, o cliente pode solicitar diversos objetos, e o servidor devolver diversas respostas em uma única conexão. Consequentemente, um documento web e todos os seus objetos podem ser recuperados em uma única conexão. Geralmente, o servidor web fecha uma conexão persistente após um tempo de inatividade, que é configurável pelo administrador. Nas conexões persistentes, as requisições podem ser realizadas com ou sem paralelismo. No modo não paralelo, o cliente envia uma nova requisição somente após receber a resposta da requisição anterior. No modo paralelo, o cliente envia diversas requisições antes de receber as respostas anteriores. Desta forma, todos os objetos que compõem um documento podem ser requisitados, antes de receber qualquer um deles. As conexões persistentes melhoram o desempenho do serviço web, pois evitam o desperdício de tempo e recursos com o estabelecimento e fechamento de conexões individuais para cada objeto. No lado cliente, o desempenho do serviço web também é melhorado com a implementação de um repositório local (cache) que armazena os documentos recentemente recuperados. O mecanismo de cache reduz os atrasos na recuperação de objetos e diminui o tráfego gerado na internet, pois documentos previamente armazenados no repositório local não precisam ser transmitidos novamente. Além disso, o mecanismo de cache permite ao usuário visualizar um conteúdo previamente armazenado, mesmo na ausência de conectividade.

Modelo de interação Arquitetura e Protocolos de Rede TCP-IP

11 Protocolo HTTP 22 Requisição 33 GET: recupera o objeto informado na URL. 33 POST: envia informações de formulário. 22 Resposta 33 200: requisição processada com sucesso. 33 301: objeto solicitado foi movido. 33 400: erro genérico no processamento. 33 404: objeto solicitado não existe. 33 505: versão requisitada não é suportada. 380

O protocolo HTTP define dois tipos de mensagens: a requisição e a resposta. As mensagens de requisição e resposta adotam o formato ASCII, exceto no conteúdo dos objetos enviados. Desta forma, como nos protocolos SMTP e FTP, as requisições e as respostas HTTP podem ser facilmente lidas pelos usuários. No exemplo de interação entre o cliente e o servidor, mostrado na listagem a seguir, os principais elementos que compõem as requisições e as respostas podem ser identificados.

C: GET /newsgen/index.html HTTP/1.1 Host: www.rnp.br Connection: close User-Agent: Mozilla/4.0 Accept-Language: sgn-BR

S: HTTP/1.1 200 OK Connection: close Date: Sun, 01 Aug 2004 15:00:00 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 2004 10:04:17 GMT Content-Length: 1500 Content-Type: text/html LF> ... Inicialmente, o cliente estabelece uma conexão na porta TCP 80 do servidor. Em seguida, o cliente envia a mensagem de requisição, que é composta por uma linha de requisição, algumas linhas de cabeçalho e o corpo. A linha de requisição identifica o método a ser executado pelo servidor, o objeto a ser recuperado (URL) e a versão do protocolo HTTP. No exemplo o cliente está usando o método GET para solicitar o objeto /newsgen/index.html através do protocolo HTTP/1.1. O protocolo HTTP define alguns métodos; os mais usados são: GET e POST. O método GET é usado pelo cliente para solicitar a recuperação de um determinado objeto do servidor. A maioria das interações entre o cliente e o servidor adota o método GET. O método POST é semelhante ao método GET, mas envia informações adicionais para o servidor. Estas informações adicionais são obtidas de formulários preenchidos pelos usuários. As linhas do cabeçalho possuem informações que auxiliam o servidor no tratamento da requisição. Cada linha de cabeçalho possui um nome e um valor associado. Existem diversos tipos de linhas de cabeçalho, o exemplo de interação acima apresenta apenas alguns tipos

O cabeçalho Host especifica o servidor no qual o objeto solicitado está armazenado. O cabeçalho Connection indica se o servidor deve ou não fechar a conexão após enviar o objeto. Neste exemplo, após enviar o objeto, o servidor deve fechar a conexão (close). O cabeçalho User-Agent sinaliza o tipo de cliente que está gerando a requisição. Neste exemplo, o cliente é o Mozilla/4.0. Esta linha permite que o servidor possa enviar diferentes versões do mesmo objeto, dependendo do tipo de cliente. Por fim, o cabeçalho Accept-Language indica o idioma de preferência do usuário. Se o objeto solicitado não existe naquele idioma, o servidor envia o objeto no idioma default. Na mensagem de requisição, após as linhas de cabeçalho, existe o corpo da mensagem. O método GET não usa o corpo da mensagem. Por outro lado, no método POST, o corpo da

Capítulo 10 - Protocolos de aplicação

de linhas de cabeçalho.

requisição contém as informações do formulário que foi preenchido pelo usuário. 381

As linhas do cabeçalho e o corpo da mensagem de requisição devem ser separados por uma linha contendo apenas a sequência de bytes , onde e representam os caracteres de retorno do cursor (Carriage Return) e mudança de linha (Line Feed), respectivamente. Após receber uma requisição, o servidor processa a requisição e retorna uma mensagem de resposta, que é composta por uma linha de status, algumas linhas de cabeçalho e o corpo. A linha de status contém a versão do protocolo HTTP, o código de processamento da requisição e uma mensagem textual. No exemplo de interação acima, o servidor adotou o protocolo HTTP/1.1 e a requisição foi processada com sucesso (200). Nas respostas, também existem diversos tipos de linhas de cabeçalho. Novamente, o exemplo ilustra apenas alguns tipos de linhas de cabeçalho. O cabeçalho Connection informa ao cliente se o servidor vai fechar ou não a conexão após o envio da resposta. Neste exemplo, o servidor fecha a conexão (close). O cabeçalho Date indica a hora e a data em que a resposta foi enviada pelo servidor. Por sua vez, o cabeçalho Last-Modified indica a data de criação ou modificação do objeto no servidor. Esta informação é usada pelo cliente para manter a cache local atualizada. O cabeçalho Server identifica o tipo do servidor que está gerando a resposta. Este exemplo foi realizado usando o servidor Apache/1.3.0. Os cabeçalhos Content Length e Content-Type indicam o tamanho em bytes do corpo da mensagem de resposta e o tipo de objeto que está sendo enviado. Estas informações permitem ao cliente tratar adequadamente o objeto recebido. Na mensagem de resposta, após as linhas de cabeçalho, o corpo da mensagem contém o objeto solicitado na requisição. As linhas do cabeçalho e o corpo da mensagem de resposta também devem ser separados por uma linha contendo apenas a sequência de bytes .

Serviço de Acesso Remoto Seguro O serviço de acesso remoto seguro (SSH – Secure Shell) provê comunicação segura para aplicações de terminal remoto, transferência de arquivos e execução remota de comandos. Em sistemas Linux, o serviço SSH tem funcionalidades semelhantes àquelas providas pelos comandos rlogin (remote login), rcp (remote copy) e rsh (remote shell). Entretanto, no SSH, os dados transmitidos são automática e transparentemente cifrados, assegurando autenticidade, privacidade e integridade. Ou seja, o SSH garante que as entidades comunicantes são autênticas e assegura que os dados enviados não são lidos ou modificados por outras entidades.

Componentes Como mostrado da Figura 10.5, o serviço SSH adota a arquitetura cliente-servidor. Um servidor SSH é um programa, tipicamente instalado e executado pelo administrador, que aceita Arquitetura e Protocolos de Rede TCP-IP

ou rejeita requisições de conexão dos clientes SSH, provendo autenticação, privacidade e inte-

382

gridade. Em sistemas Linux, a implementação do servidor SSH mais adotada é o servidor sshd.

Chave do Servidor

Sessão SSH Estações Conhecidas

Cliente SSH

Protocolo SSH Chave de Sessão

Servidor SSH

Chave de Sessão

Chave da Estação

Figura 10.5 Arquitetura do serviço SSH.

Por outro lado, um cliente SSH é um programa tipicamente executado pelo usuário em estações remotas, que envia requisições ao servidor SSH para abrir uma sessão de terminal remoto, transferir arquivos ou executar comandos. Em sistemas Linux, os clientes SSH são implementados pelos programas ssh e scp. O serviço SSH é suportado pelo protocolo SSH, que define um canal seguro de comunicação entre o cliente e o servidor. O protocolo SSH utiliza a porta TCP 22. Existem duas versões incompatíveis do protocolo: SSH-1 e SSH-2. Embora o SSH-2 seja melhor e mais seguro, o SSH-1 ainda é a versão mais utilizada, pois o SSH-2 foi inicialmente proposto como uma solução comercial. Atualmente, um grupo de trabalho do Internet Engineering Task Force (IETF) está concentrando esforços para padronizar o SSH-2. No SSH, uma sessão representa uma conexão segura entre um cliente e um servidor. Todos os acessos ao serviço SSH envolvem duas autenticações: o cliente verifica a identidade do servidor (autenticação do servidor), e o servidor verifica a identidade do usuário que está requisitando o acesso (autenticação do usuário). A sessão SSH inicia depois que o cliente autentica o usuário no servidor e finaliza quando a conexão é fechada. O serviço SSH manipula duas chaves assimétricas (chave da estação e chave do servidor) e uma chave simétrica (chave de sessão). Cada chave assimétrica é composta pelo par: chave privada e chave pública. A chave simétrica possui uma única chave. Estas chaves são usadas pelos algoritmos de criptografia. A chave da estação (host key) é uma chave assimétrica usada pelo servidor SSH como prova da identidade da estação onde ele é executado. A chave da estação deve ser armazenada localmente na estação onde o servidor SSH é executado. A chave do servidor (server key) é uma chave assimétrica que é usada pelo servidor SSH para proteger a chave de sessão (descrita posteriormente). A chave do servidor é temporária, pois ela é recriada pelo servidor SSH em intervalos regulares (por default, a cada hora). A chave do servidor nunca é armazenada em memória secundária. Além disso, a chave privada do servidor nunca é transmitida em uma conexão. A chave de sessão é uma chave simétrica usada para cifrar a comunicação entre um cliente e um servidor SSH. A chave de sessão é gerada durante o procedimento de estabelecimento da sessão e destruída quando a sessão é finalizada. A chave de sessão é compartilhada entre o cliente e o servidor SSH. O protocolo SSH-1 usa uma única chave de sessão. No entanto, o protocolo SSH-2 possui várias chaves de sessão. Por exemplo, existem duas chaves de sessão que são usadas para cifrar a comunicação em cada direção: cliente-servidor e servidor-cliente.

armazena as chaves públicas das estações conhecidas. Quando um cliente e um servidor SSH estabelecem uma conexão, o cliente autentica o servidor usando as informações contidas nesta base de dados. Sempre que o cliente estabelece uma sessão com um novo servidor, o cliente armazena a identificação do servidor e a respectiva chave pública da estação. Cada vez que o cliente se conecta ao servidor, o cliente verifica a identidade do servidor usando esta chave pública.

Modelo de interação Para estabelecer uma sessão, o cliente e o servidor SSH trocam informações para negociar a chave de sessão e definir os algoritmos de criptografia e autenticação a serem adotados.

Capítulo 10 - Protocolos de aplicação

Para realizar a autenticação dos vários servidores, o cliente mantém uma base de dados que

383

Além disso, durante o estabelecimento de uma sessão, o cliente e o servidor se autenticam mutuamente. A Figura 10.6 apresenta um exemplo de estabelecimento de sessão, onde as principais informações trocadas entre o cliente e o servidor podem ser identificadas.

Figura 10.6 Estabelecimento de uma sessão SSH.

Inicialmente, o cliente estabelece uma conexão na porta TCP 22 do servidor. Imediatamente após o estabelecimento da conexão, o cliente e o servidor enviam a identificação da versão do protocolo SSH suportado. Opcionalmente, o cliente e o servidor podem acrescentar a versão da implementação. Neste exemplo, cliente e servidor suportam a versão SSH-1, identificada pelos termos SSH1.51.2.30 e SSH1.99OpenSSH_2.2.0. Os termos 1.2.30 e OpenSSH_2.2.0 identificam a versão da implementação do cliente e do servidor, respectivamente. Se o cliente e o servidor detectam que suas versões são compatíveis, o procedimento de estabelecimento da sessão prossegue. Caso contrário, a conexão é imediatamente fechada. Após negociar a versão do protocolo, o cliente e o servidor passam a se comunicar usando um protocolo de pacotes sobre a conexão TCP. Neste protocolo, cada pacote contém diversos campos, entre eles: um código que identifica o tipo de pacote (1 byte), os dados do pacote, e um campo de verificação de integridade (4 bytes). Neste momento, o servidor identifica-se para o cliente e provê alguns parâmetros da sessão. O servidor envia as seguintes informações para o cliente: a chave pública da estação, a chave pública do servidor, a sequência de verificação (check bytes), a lista de algoritmos de criptografia suportados pelo servidor, e a lista de algoritmos de autenticação suportados pelo servidor. A sequência de verificação protege o serviço de alguns tipos de ataques. Arquitetura e Protocolos de Rede TCP-IP

O cliente deve devolver a mesma sequência de verificação na próxima mensagem enviada

384

ao servidor. Caso contrário, o servidor rejeita a mensagem do cliente. Vale ressaltar que estas informações ainda não são cifradas. No entanto, todas as informações podem ser publicamente conhecidas, não apresentando qualquer risco à segurança do serviço. Neste ponto, o cliente e o servidor computam um identificador de sessão de 128 bits, que é usado em algumas operações subsequentes do protocolo para identificar de forma única a sessão SSH. Este identificador é calculado usando a chave pública da estação, a chave pública do servidor e a sequência de verificação. Como o cliente e o servidor possuem estas informações, ambos computam um mesmo identificador.

Em seguida, consultando a base de dados de estações conhecidas, o cliente verifica se a estação do servidor já é conhecida. Se a estação do servidor está na base de dados e a chave pública armazenada é igual àquela recebida, o cliente aceita a sessão. Caso contrário, existem duas outras possibilidades: a estação do servidor não está presente na base de dados; ou a estação do servidor está presente, mas a chave pública armazenada não é igual àquela recebida. Em ambos os casos, o cliente solicita o auxílio do usuário, perguntando se ele aceita ou rejeita a chave pública recebida. Se o usuário aceita a chave pública da estação, o cliente estabelece a sessão e armazena a nova chave na base de dados de estações conhecidas. Caso contrário, o cliente rejeita a sessão e fecha a conexão. Após aceitar o estabelecimento da sessão, o cliente gera uma chave de sessão, que será usada posteriormente para cifrar e decifrar as mensagens enviadas, tanto pelo cliente, quanto pelo servidor. O cliente deve enviar a chave de sessão para o servidor de forma segura. No entanto, neste instante, a comunicação entre o cliente e o servidor ainda não é segura. Para tal, o cliente cifra a chave de sessão com a chave pública da estação, e, em seguida, cifra novamente com a chave pública do servidor. A criptografia dupla assegura que somente o servidor pode recuperar a chave de sessão. Após cifrar a chave de sessão, o cliente envia a chave de sessão cifrada para o servidor, juntamente com a sequência de verificação e uma indicação do algoritmo de criptografia selecionado. Agora, o cliente aguarda uma mensagem de confirmação do servidor, que, como todas as demais mensagens, já deve ser cifrada com a chave de sessão. A mensagem de confirmação cifrada realiza a autenticação do servidor, pois somente ele pode decifrar a chave de sessão, uma vez que ela foi cifrada com a chave pública da estação e a chave pública do servidor. Se a mensagem de confirmação cifrada não é recebida, o cliente fecha a conexão. O protocolo SSH-1 não é específico neste ponto, mas a segunda versão especifica a necessidade desta mensagem de confirmação, quando a autenticação do servidor é realizada de forma implícita através da chave de sessão. Neste momento, a comunicação segura pode ser iniciada, pois o cliente e o servidor conhecem a chave de sessão. Desta forma, ambos começam a cifrar todos os dados da sessão, usando o algoritmo de criptografia selecionado e a chave de sessão. Antes de permitir qualquer tipo de acesso, o servidor deve, primeiramente, autenticar o usuário do cliente. O protocolo SSH suporta vários métodos de autenticação do usuário, por exemplo, usando senhas e chaves públicas. O cliente tenta os métodos suportados pelo servidor, informados na lista de algoritmos de autenticação, até que um tenha sucesso ou todos falhem. Para ilustrar a autenticação do usuário, vamos descrever a autenticação baseada em senhas. Nesta modalidade, o usuário fornece sua identificação e senha ao cliente SSH. O servidor autentica a senha para aquele usuário e, caso válida, permite o acesso remoto seguro. Geralmente, o servidor SSH verifica a validade da senha usando o mecanismo de autenticação do próprio sistema operacional.

Capítulo 10 - Protocolos de aplicação

Usando a conexão segura, o cliente transmite a identificação e a senha para o servidor.

385

386

Arquitetura e Protocolos de Rede TCP-IP

Roteiro de Atividades 10 Atividade 10.1 – Captura de pacotes UDP do serviço DNS 1. Vamos ativar o Wireshark, como fizemos anteriormente, só que desta vez para configurar

um filtro de captura. Na tela inicial do Wireshark, em vez de selecionar o botão “Start”, selecione o botão “Options” na interface de rede local. Teremos então a tela a seguir. Na janela “Capture Filter:”, digite a palavra udp, conforme mostrado na figura 10.7. Observe que a janela de filtro de captura fica com o fundo verde quando a sintaxe do comando está correta e vermelha quando não está correta.

Figura 10.7 Opções de captura de pacotes do Wireshark.

Em seguida clique em “Start” para iniciar a captura, porém, somente serão capturados os pacotes que contenham o protocolo UDP. Os demais pacotes IP serão descartados. 2. Abra uma janela de prompt de comando e digite os seguintes comandos:

ping www.google.com.br ping www.esr.rnp.br Aguarde até que todas as operações tenham sido concluídas, volte para a janela do Wireshark (que ficou aberta) e só então termine a captura de pacotes clicando no quarto ícone da esquerda para a direita da barra de ferramentas (Stop the running live capture). A janela de captura do Wireshark deve ser semelhante à mostrada na figura 10.8. Podem surgir mais alguns pacotes eventualmente, dependendo da rede local do laboratório, mas somente os mostrados na figura são importantes. Esta janela se refere ao arquivo de captura: “Sessao10_Captura1.pcap”.

Capítulo 10 - Roteiro de Atividades

Figura 10.8 Captura de pacotes UDP.

387

3. Nesta figura o pacote 1 está selecionado na primeira janela e na segunda janela

estão os protocolos que foram utilizados. Note que aparecem, de cima para baixo, as seguintes camadas: 3.1. Camada física (Frame 1) 3.2. Camada de enlace (Ethernet II) 3.3. Camada de rede (Internet Protocol Version 4) 3.4. Camada de transporte (User Datagram Protocol) 3.5. Camada de aplicação (Domain Name System) 4. Selecionando a camada de transporte na segunda janela, teremos a janela mostrada na

figura 10.9.

Observe que na terceira janela, onde estão representados os dados no formato hexadecimal, estão destacados apenas os dados do cabeçalho UDP (8 bytes). Os dados importantes são: 11 Porta de origem: 59840 11 Porta de destino: 53 Essa porta é a “porta bem conhecida” utilizada pelo servidor DNS e se trata de uma consulta ao servidor DNS para resolução do nome www.google.com.br, que foi o nome usado no comando ping na janela DOS. 5. Na linha do protocolo IP (camada de rede), podemos ver que a estação de origem tem o

IP: 192.168.100.103 e o servidor DNS consultado tem o IP: 200.130.77.69. 6. O próximo pacote (número 2) é a resposta do servidor DNS, destinado à estação que

enviou a solicitação no pacote 1. Essa resposta contém o endereço IP do nome solicitado. Qual é o endereço IP do nome solicitado?

Arquitetura e Protocolos de Rede TCP-IP

Os pacotes 3 e 4 são semelhantes, referentes à resolução do nome: www.esr.rnp.br.

388

Qual o endereço IP do nome solicitado?

Nos dois casos, foram usadas as mesmas portas? Explique.

Figura 10.9 Detalhe do pacote UDP número 1.

Atividade 10.2 – Requisições iterativas e recursivas O serviço de nomes possui dois componentes. O resolver envia requisições aos servidores de nomes, que, por sua vez, processam essas requisições e devolvem as respectivas respostas. Considerando o modelo cliente-servidor, qual o papel do resolver e do servidor de nomes em requisições iterativas e recursivas?

Atividade 10.3 – Servidores raiz Todo servidor de nomes deve conhecer os endereços IP dos servidores do domínio raiz. Para facilitar a atualização da lista de servidores raiz, essa informação é disponibilizada na internet. No entanto, não existe um mecanismo para informar aos administradores sobre atualizações nas informações dos servidores raiz. Dessa forma, não é incomum encontrar servidores que possuem endereços incorretos de alguns servidores raiz. Como o serviço de nomes pode continuar funcionando mesmo com a existência dessas inconsistências?

Atividade 10.4 – Consultas DNS O comando host é um utilitário para realizar consultas ao serviço de nomes. O exemplo listado a seguir mostra a sintaxe do comando. A opção –t indica o tipo de registro de recurso a ser consultado, por exemplo: A, PTR, CNAME, HINFO, MX e NS. O primeiro parâmetro (www.esr.rnp.br) é o nome a ser resolvido, podendo ser um nome de domínio, um nome de estação ou um endereço IP. O segundo parâmetro (lua.na-df.rnp.br) é o nome do servidor de nomes a ser consultado. Se o servidor de nomes não é informado, o comando host usa o servidor de nomes default, configurado no arquivo /etc/resolv.conf (Linux) ou na configuração da interface de rede no campo DNS (Windows).

[email protected]:~$ host –t A www.esr.rnp.br lua.na-df.rnp.br Using domain Server: Name: lua.na-df.rnp.br

Aliases: www.esr.rnp.br has address 200.130.35.73 No exemplo, uma requisição tipo A é enviada ao servidor de nomes lua.na-df.rnp.br para mapear o nome da estação www.esr.rnp.br para seu respectivo endereço IP 200.130.35.73. Se a opção –t não é usada e o primeiro parâmetro é um nome de estação, por default, o comando host realiza uma consulta do tipo de registro A, mapeando o nome da estação para seu respectivo endereço IP. No entanto, se a opção –t não é usada e o primeiro parâmetro é um endereço IP, por default, o comando host realiza uma consulta do tipo de registro PTR,

Capítulo 10 - Roteiro de Atividades

Address: 200.130.77.69#53

mapeando o endereço IP para seu respectivo nome de estação. 389

Este exemplo foi executado na máquina virtual CORE, usando o console “Terminal”, cujo ícone está na área de trabalho do Ubuntu. Para as próximas atividades, use o mesmo console. 1. Usando o mesmo servidor de nomes, identifique o endereço IP da estação www.rnp.br.

2. Usando o mesmo servidor de nomes, descubra o nome da estação cujo endereço IP é

200.130.25.1.

3. Usando o mesmo servidor de nomes, encontre os servidores de nomes do domínio rnp.br.

4. Usando o mesmo servidor de nomes, identifique os servidores de correio eletrônico do

domínio rnp.br.

Atividade 10.5 – Serviço SSH Instalação do serviço SSH 1. Digite o seguinte comando no terminal do Linux:

# sudo apt-get install ssh 2. Informe a senha do usuário: core. 3. Aguarde até que a instalação esteja terminada.

Criar uma conexão segura ao servidor remoto 1. Digite o seguinte comando no terminal do Linux:

# ssh 2. Confirme a autenticidade da chave apresentada:

Arquitetura e Protocolos de Rede TCP-IP

Are you sure you want to continue connecting (yes/no)? yes

390

A partir de agora não é mais solicitada a confirmação, somente a senha do usuário. 3. Confirme se está no computador desejado com o seguinte comando:

# hostname

Incluir um novo usuário na máquina remota 1. Digite o seguinte comando no terminal do Linux:

# adduser

2. Digite as informações solicitadas. Não se esqueça de criar uma senha e confirmá-la. 3. Para fechar a conexão SSH:

# exit

Transferir um arquivo remoto para o host local e vice-versa Suponha o host local com endereço 192.168.100.123 e o host remoto (servidor SSH) com endereço 192.168.100.127. Sequência de comandos:

# ssh 192.168.100.127 (estabelece a conexão SSH com o servidor remoto) # scp Rede_Atividade6_2.imn [email protected]:/home/lobato The authenticity of host ‘192.168.100.123 (192.168.100.123)’ can’t be established. RSA key fingerprint is 43:44:f2:4d:78:20:60:d7:31:d3:26:b1:20:ee:dc:f3. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘192.168.100.123’ (RSA) to the list of known hosts. [email protected]’s password: Rede_Atividade6_2.imn

100% 2866

2.8KB/s

00:00

# A sequência de comandos acima mostra a transferência do arquivo “Rede_Atividade6_2. imn” do host remoto para o host local.

Análise dos pacotes SSH Iniciando o Wireshark na interface de rede de um dos hosts envolvidos na transferência acima podemos ver os pacotes trocados entre eles, que foram capturados no arquivo “Sessao10_Captura2.cap”. A Figura 10.10 mostra os primeiros pacotes capturados, com destaque para o pacote 7.

Observações importantes sobre a Figura 10.10: 11 Os pacotes 3 e 4 do protocolo ARP são para obter o endereço MAC da estação 192.168.100.123 e a pergunta foi feita pela estação 192.168.100.127. 11 Os pacotes 2, 5 e 6 estabelecem uma conexão TCP entre os dois hosts. 11 O pacote 7 é do protocolo SSH versão 2.0.

Capítulo 10 - Roteiro de Atividades

Figura 10.10 Pacotes capturados com destaque para o pacote 7.

391

A Figura 10.11 mostra alguns pacotes criptografados pelo SSH.

Na Figura 10.11, os pacotes 37, 40 e 43 são do protocolo TCP e destinam-se ao controle da conexão, com informações sobre a quantidade de octetos transmitidos/recebidos. Os demais pacotes são do protocolo SSH e estão criptografados.

Backup de uma estação remota com SSH Um administrador de rede necessita criar um backup de uma estação de trabalho remota utilizando SSH. Como deve proceder? 1. Acesse o computador remoto através do SSH:

# ssh 2. Utilize o comando tar para fazer um backup da estação remota:

# tar –cvzf /backup.tar.gz -–exclude=/proc -–exclude=/lost+found --exclude=/backup.tar.gz –exclude=/mnt –exclude=/sys / 3. Volte para o terminal local:

# exit 4. Copie o arquivo compactado da máquina remota para a máquina local:

Arquitetura e Protocolos de Rede TCP-IP

# scp [email protected]:/backup.tar.gz

392

Figura 10.11 Pacotes criptografados.

Bibliografia 11 ALBITZ, P.; LIU, C. DNS and Bind. O’Reilly & Associates, 1993. 11 Apostila de redes: http://serverapostilando.com/tutorials2/2719_2834_redes_boa.zip 11 BALLEW, Scott M. Managing IP Networks with Cisco Routers. O’Reilly & Associates, 1997. 11 BRISA (Sociedade Brasileira para Interconexão de Sistemas Abertos). Gerenciamento de redes: uma abordagem de sistemas abertos. Makron Book, 1 ed., 1993. 11 CCNA ICND Exam Certification Guide (CCNA Self-Study, 640-811, 640-801). 11 CCNP BCRAN Exam Certification Guide (CCNP Self-Study, 642-821) 2 ed. Inc. Cisco Systems. Internetworking Technologies Handbook. 2 ed., Cisco Press, 2000. 11 COMER, Douglas E. Internetworking with TCP/IP – Volume I: Principles, Protocols and Architecture. Fourth Edition. Prentice Hall, 2000. 11 Country codes in ISO 3166: http://www.davros.org/misc/iso3166.html 11 Dígitro: http://www.digitro.com/pt/index.php/sala-imprensa/glossario. Acesso em: 05 fevereiro 2011. 11 FEIT, Sidnie. SNMP: A guide to Network Management. McGraw-Hill, 1 ed., 1995. 11 GILMORE, Mike. Understanding OM1, OM2, OM3, OS1, OS2 and more! The Fibreoptic Industry Association. Disponível em https://learningnetwork.cisco.com/docs/DOC-3791. Acesso em 23/08/2013. 11 GONÇALVES, José. O Protocolo OSPF. UFES. http://www.inf.ufes.br/~zegonc/material/S.O.%20II/Protocolo%20OSPF.pdf 11 GONÇALVES, José. O Protocolo RIPv1. UFES. http://www.inf.ufes. br/~zegonc/material/S.O.%20II/Protocolo%20RIPv1%20(1pag).pdf 11 GONÇALVES, José. O Protocolo RIPv2. UFES. http://www.inf.ufes. 11 HARNEDY, Sean. Total SNMP: Exploring the Simple Network Management Protocol. Prentice-Hall, 2 ed., 1997.

Bibliografia

br/~zegonc/material/S.O.%20II/Protocolo%20RIPv2%20(1pag).pdf

393

11 IEEE 802.1Q Standard: http://standards.ieee.org/getieee802/ download/802.1Q-1998.pdf 11 Infraestrutura de redes: http://www.apostilando.com/download_final. php?cod=3162 11 Lynx Networks. Tabela de fibras ópticas: http://www.lynxdatacabling.co.uk/documents/fibre_optic_interfaces.pdf 11 MARTINS, Joberto. Qualidade de Serviço (QoS) em Redes IP. http://professores.unisanta.br/santana/downloads%5CTelematica%5CCom_ Dados_2%5CTexto%20QoS_IP_Itelcon.pdf 11 MARTINS; Agnaldo Lopes; MARANI, Sandro. Topologias de redes. http://web.archive.org/web/20100331110201/http://www.micropic.com. br/noronha/Informatica/REDES/Redes.pdf 11 MENDES, Douglas Rocha. Redes de Computadores. Novatec: http://novatec.com.br/livros/redescom/capitulo9788575221273.pdf 11 MONTEIRO, Edmundo; BOAVIDA, Fernando. Engenharia de Redes de Informática, 10a. Ed., FCA, 2000. 11 MORIMOTO, Carlos E. Cabeamento estruturado, 2008. http://www.hardware.com.br/livros/redes/cabeamento-estruturado.html 11 MOURA, Alex Soares de. O Protocolo BGP4 - Parte 1. http://www.rnp.br/newsgen/9903/bgp4.html 11 NOGUEIRA, Mauro Lúcio Baioneta; MELCHIORS, Cristina. Um pequeno estudo sobre par trançado: http://penta.ufrgs.br/rc952/Cristina/utpatual.html 11 O que é uma rede: www.inf.ufsc.br/~bosco/ensino/ine5344/o_que_e_uma_rede.ppt 11 Overview of Generic Attribute Registration Protocol: http://www.alliedtelesyn.co.nz/documentation/at8700/261/pdf/garp.pdf 11 Projeto da Topologia da Rede http://www.dsc.ufcg.edu.br/~jacques/cursos/pr/html/logico/logico1.htm 11 Redes sem fio: http://www.teleco.com.br/tutoriais/tutorialss/pagina_1.asp 11 RFC 1058 11 RFC 1388

Arquitetura e Protocolos de Rede TCP-IP

11 RFC 1723

394

11 RFC 2328 11 RFC 2453 11 ROSE, Marshall. The Simple Book. Prentice-Hall, 2 ed. revisada, 1996. 11 SENGER, Hermes. Redes Locais, Metropolitanas e de Longa Distância: http://www-usr.inf.ufsm.br/~candia/aulas/espec/Aula_2_LAN_MAN_WAN.pdf 11 STALLINGS, William. Data and Computer Communications, 9a. ed., Ed. Prentice Hall, 2010. 11 STALLINGS, William. Data and Computer Networks. Prentice-Hall, 2004.

11 STEVENS, W. Richard. TCP/IP Illustrated Volume 1: The Protocols. Addison Wesley, 1994. 11 TANENBAUM, Andrew S. Rede de Computadores. Editora Campus, 2003. 11 Topologia: http://www.m8.com.br/antonio/redes/Topologia.htm 11 Tutorial sobre tipos de redes: http://tutorial-info-dica.blogspot. com/2010/12/infolan-man-wan-pan-san-sabe-diferenca.html 11 TYSON, Jeff. HowStuffWorks: como funcionam os switches LAN (rede de comunicação local). http://informatica.hsw.uol.com.br/lan-switch2.htm. Publicado em 2001, atualizado em 10 de abril de 2008. Acesso em 03 de outubro de 2011. 11 VILHENA, Antonio. Categorias de cabo par trançado: http://www.boadica.com.br/dica/546/categoria-de-par-trancado

Bibliografia

-(twisted-pair)-em-sistemas-de-cabeamento

395

396

Arquitetura e Protocolos de Rede TCP-IP

Gledson Elias recebeu o título de Doutor em Ciência da Computação do Centro de Informática (CIn) da Universidade Federal de Pernambuco (UFPE), em junho de 2002. Iniciou a carreira acadêmica em 1993, e, atualmente, é professor associado do Programa de Pós-Graduação em Informática do Centro de Informática (CI) da Universidade Federal da Paraíba (UFPB). No período de 1993 a 1996, coordenou a implantação da Internet no Estado do Rio Grande do Norte e na Universidade Federal do Rio Grande do Norte. Estas atividades estão inseridas no contexto do projeto da Rede Nacional de Ensino e Pesquisa (RNP), que implantou a Internet no Brasil, do qual foi participante ativo, tendo atuado na sede do projeto em Campinas de 1991 a 1993. Em ensino, tem lecionado na graduação e pós-graduação em diferentes cursos na área de Redes de Computadores e Sistemas Distribuídos. Desde 2006, é colaborador da Escola Superior de Redes (ESR), onde tem atuado como Coordenador Acadêmico da Unidade João Pessoa, bem como tem elaborado material didático e lecionado diversos cursos. Luiz Carlos Lobato é formado em Engenharia Eletrônica pelo ITA, com pós-graduação em Negócios e Serviços de Telecomunicações pelo CEFET-RJ. Possui certificação de redes Cisco CCNA. Gerente da Divisão de Suporte Técnico da Telebrás até a privatização das Telecomunicações, sendo responsável pela operação e gerência da Rede de Dados do Sistema Telebrás. Após a privatização atuou como Coordenador de Cursos de Tecnologia de Redes (Graduação Superior) em diversas faculdades. É colaborador da Escola Superior de Redes desde 2008, tendo elaborado material de treinamento e lecionado diversos cursos na área de Redes. Atualmente é Coordenador Acadêmico de Administração e Projeto de Redes da ESR.

LIVRO DE APOIO AO CURSO

O curso fornece uma visão geral das redes, conceitos básicos, noções de meios de comunicação, equipamendes práticas. Oferece também uma visão aprofundada da arquitetura de rede TCP/IP, sua pilha de protocolos e de projetar uma rede TCP/IP e de conectá-la à Internet. Este livro inclui os roteiros das atividades práticas e o conteúdo dos slides apresentados em sala de aula, mento em suas organizações ou localidades de origem.

ISBN 978-85-63630-18-6

9 788563 630186

O que acontece com as portas membros de uma VLAN quando ela é excluída?

A VLAN 30 será excluída. A porta Fa0 / 11 será devolvida à VLAN 1.

Qual é o resultado de um ataque de privação de DHCP?

Qual é o resultado de um ataque de privação de DHCP? Invasor fornece DNS incorreto e informações de gateway padrão aos clientes. Os endereços IP atribuídos a clientes legítimos são sequestrados.

Qual é o endereço IP da interface virtual do switch SVI no Switch0?

Qual o endereço IP da interface virtual do switch (SVI) no Switch0? Resposta: 192.168.5.10 12.

Quais são os dois protocolos que são usados pelo AAA para autenticar usuários em um banco de dados central de nomes de usuário e senha?

Quando falamos de AAA para CCNA temos que falar também dos protocolos que podem ser utilizados na implementação prática: RADIUS e TACACS.

qual evento ocorre se houver uma violação de segurança na porta s1 fa0/ switch

Qual evento ocorre se houver uma violação de segurança na porta s1 fa0/ 1 switch?

O que acontece com as portas membros de uma VLAN quando ela é excluída?

Qual é o resultado de um ataque de privação de DHCP?

Qual é o endereço IP da interface virtual do switch SVI no Switch0?

Quais são os dois protocolos que são usados pelo AAA para autenticar usuários em um banco de dados central de nomes de usuário e senha?

Postagens relacionadas

Qual a importância do ensino de história e cultura Afro

Quais os principais problemas relacionados ao uso de medicamentos pelos idosos?

Que características naturais do território estadunidense contribuíram para o início de sua industrialização?

Quantos são os estímulos que podemos utilizar na comunicação alternativa?

Vai ter 2 temporada de Mãe Só Tem Duas?

Qual é a probabilidade de um casal com quatro filhos ter dois do sexo masculino?

Qual é a probabilidade de um casal com quatro filhos ter dois do sexo masculino é dois do sexo feminino?

Quais as ligações ou interações entre os aminoácidos que permitem as diferentes estruturas?

O que acontece com os pontos de fusão e ebulição nos hidrocarbonetos?

Quais as principais proteínas contráteis presentes na estrutura do sarcômero?

Publicidade

ÚLTIMAS NOTÍCIAS

Qual a relação do petróleo com o efeito estufa?

Qual o tipo de microscópio mais indicado na rotina microbiológica?

Qual é o papel de um educador?

Por que os fungos são tão importantes para a indústria de alimentos?

Quando foi lançado o iphone 6

É possível fazer transferência de dinheiro de um banco para outro?

Um acionista ao analisar uma empresa pode estar preocupado em verificar

Sao paulo e rentistas onde assistir

Quais os aspectos que caracterizam o clima organizacional escolar?

Em que o caso Cambridge Analytica importa para jurisdição Digital?

Publicidade

Populer

Publicidade

Sobre

Jurídica

Ajuda

Social