Redes de Computadores

Transcrição

1 UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE) UNIDADE ACADÊMICA DE EDUCAÇÃO A DISTÂNCIA E TECNOLOGIA Redes de Computadores Juliano Bandeira Lima Obionor Nóbrega Volume 2 Recife, 2011

2 Universidade Federal Rural de Pernambuco Reitor: Prof. Valmar Corrêa de Andrade Vice-Reitor: Prof. Reginaldo Barros Pró-Reitor de Administração: Prof. Francisco Fernando Ramos Carvalho Pró-Reitor de Extensão: Prof. Paulo Donizeti Siepierski Pró-Reitor de Pesquisa e Pós-Graduação: Prof. Fernando José Freire Pró-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira Pró-Reitora de Ensino de Graduação: Profª. Maria José de Sena Coordenação Geral de Ensino a Distância: Profª Marizete Silva Santos Produção Gráfica e Editorial Capa e Editoração: Rafael Lira, Italo Amorim e Arlinda Torres Revisão Ortográfica: Elias Vieira Ilustrações: Moisés de Souza Coordenação de Produção: Marizete Silva Santos

3 Sumário Apresentação... 4 Conhecendo o Volume Capítulo 1 A Camada de Transporte Introdução Multiplexação e demultiplexação na camada de transporte UDP Protocolo de Datagrama do Usuário TCP Protocolo de Controle de Transmissão TCP e UDP: Tópicos Adicionais...21 Capítulo 2 A Camada de Rede e o Protocolo IP Introdução Algoritmos de roteamento A Camada de Rede na Internet...42 Capítulo 3 Internet, Intranet e Extranet Internet Intranet Extranet...58 Considerações Finais Conheça os Autores... 63

4 Apresentação Caro(a) aluno(a), Seja bem-vindo(a) ao curso de Redes de Computadores. Este curso é composto por 4 volumes. Neste primeiro volume, vamos estudar os conceitos introdutórios e os principais modelos de referência na área Redes de Computadores. Também estudaremos, neste volume, as principais aplicações utilizadas em ambiente de Internet (como, por exemplo, navegação na Web, correio eletrônico, telefonia via Internet, dentre outros). No segundo volume, serão abordados os protocolos que fazem transporte de informações em uma rede. Um outro assunto que será abordado é a identificação e localização de computadores em um ambiente de Rede. No terceiro volume, você aprenderá sobre como os dados são enviados através dos meios físicos de comunicação com e sem fio. Por fim, o quarto e último volume abordará tópicos de gerenciamento e segurança de redes de computadores. Concluindo a nossa disciplina, apresentaremos conceitos sobre a Próxima Geração de Redes de Computadores. Bons estudos! Juliano Bandeira Lima e Obionor O. Nóbrega Professores Autores 4

5 Conhecendo o Volume 2 Módulo 2 O Protocolo TCP/IP e a Internet Carga Horária: 15 h/aula Objetivo: Introduzir os principais conceitos relacionados à camada de transporte e à camada de rede, apresentando seus protocolos básicos e descrevendo suas funcionalidades. Conceituar Internet, Intranet e Extranet, relacionando a sua importância nos diversos cenários das redes de computadores. Conteúdo Programático» Camada de Transporte;» Camada de Rede;» Internet, Intranet e Extranet. 5

6 Capítulo 1 A Camada de Transporte Vamos conversar sobre o assunto? Caro(a) aluno(a), No volume 1, você teve a oportunidade de conhecer importantes conceitos relacionados às redes de computadores. Ao longo da sua apresentação a este mundo cheio de novidades, você estudou aspectos como topologia e classificação de redes, meios físicos e técnicas de comutação. Você pôde perceber, também, a importância do uso de modelos de camadas para descrever e estudar as redes de computadores. Considerando de maneira particular este último tópico, podemos iniciar nossa conversa levantando um simples questionamento: por que o modelo TCP/IP recebeu este nome? Por que não recebeu, por exemplo, o nome HTTP/FTP, como referência a dois dos protocolos que conhecemos na camada de aplicação? Bom, a respota à pergunta feita guarda uma relação com as duas camadas que, neste capítulo, começaremos a estudar: a camada de transporte e a camada de rede. Alguns autores mencionam que, sem as funções desempenhadas por essas camadas, o conceito de protocolos em camadas não faria qualquer sentido. Naturalmente, esta é uma afirmação que só será compreendida de forma completa quando voltarmos nossa atenção para as próximas páginas e descobrirmos os detalhes que a justificam. Por enquanto, é suficiente que mantenhamos acesa a vontade de conhecer cada vez mais sobre as redes de computadores e que, em nossa memória, estejam presentes os conceitos aprendidos nos tópicos estudados enteriormente. Assim, será mais fácil reunir as informações e perceber a interdependência que existe entre os diversos assuntos dessa disciplina. Vamos em frente! 1.1 Introdução Ao longo dos nossos estudos sobre a camada de aplicação, realizados no volume 1 desta disciplina, algumas manchetes sobre a camada de transporte já foram publicadas. Neste capítulo, entretanto, conheceremos de forma mais minuciosa certos aspectos que concedem a esta camada o status de núcleo de toda a hierarquia de protocolos. Para começar, podemos descrever as três responsabilidades básicas da camada de transporte. A primeira delas depende, fundamentalmente, da relação entre esta camada e a camada de rede. Quando, num sistema de origem (um computador pessoal que temos em casa, por exemplo), monta-se um datagrama, os algoritmos e protocolos da camada de rede devem se encarregar de encaminhá-lo até o sistema de destino (um servidor no qual estejamos buscando uma página, por exemplo). No entanto, é de responsabilidade da camada de transporte ampliar este serviço e fazer com que a comunicação aconteça, não entre os sistemas simplesmente, mas entre dois processos das camadas de aplicação que rodam nesses sistemas finais. 6 A segunda responsabilidade da camada de transporte tem a ver com a heterogeneidade que se pode encontrar nos níveis mais baixos de uma pilha de protocolos. Sinais transmitidos por meio de fibras ópticas, por exemplo, estão menos propensos à ação de ruído do que aqueles transmitidos por cabos metálicos ou num meio físico sem fio; nas camadas de enlace e na de rede, protocolos com características bem distintas podem ser

7 utilizados. Tudo isso tem impacto sobre o desempenho de uma comunicação, mas, a camada de transporte possui a atribuição de fazer com que duas entidades possam se comunicar de maneira confiável, independentemente dos cenários implementados na chamada subrede. O terceiro desafio enfrentado pela camada de transporte diz respeito aos controles de congestionamento e de fluxo. A taxa em que um processo da camada de aplicação de um host produz dados a serem entregues às camadas inferiores e, posteriormente, enviados nem sempre é comportada pelos recursos disponíveis na rede. Se o envio de pacotes for feito sem qualquer preocupação, podem-se formar filas nas entradas dos roteadores e, consequentemente, haver descartes de dados. Essa é uma situação de congestionamento. De outra forma, mesmo que os enlaces e equipamentos da subrede sejam capazes de lidar com a injeção de pacotes num ritmo acelerado, o sistema de destino pode não ser suficientemente robusto para isso, isto é, não ter a capacidade de processar os dados na velocidade em que a rede os entrega. Neste caso, estamos diante de um problema de fluxo, algo cujo controle também se deve à camada de transporte. A fim de cumprir com as responsabilidades descritas, a camada de transporte estabelece uma comunicação lógica entre processos de aplicação que rodam em hosts diferentes. Isso significa que, para uma aplicação, é como se dois computadores que se comunicam estivessem diretamente ligados, mesmo que, na realidade, existam entre eles dezenas de roteadores e tipos bem distintos de enlaces. Esta ideia pode ser melhor compreendida se observarmos a Figura 1.1. Nesta ilustração, vê-se que, nos equipamentos da subrede (roteadores), acessa-se apenas até a camada 3, o que é suficiente para o desempenho da tarefa básica desses equipamentos (determinação do percurso a ser seguido pelos datagramas). Os dados referentes à camada de transporte, que, na terminologia da Internet, são denominados segmentos, são encapsulados e desencapsulados apenas nos sistemas finais; o mesmo acontece com as mensagens recebidas de um processo de aplicação do sistema de origem e entregues a outro processo de aplicação no sistema de destino. Redes de Computadores Figura 1.1 Comunicação lógica provida pela camada de transporte Por meio dessa comunicação lógica entre processos, diversos serviços são oferecidos pelas entidades de transporte (hardware/software que executam o trabalho). Nesse contexto, os serviços orientados a conexão possuem destacada importância. Com eles, uma entidade remetente estabelece uma espécie de contato com a entidade de 7

8 destino, para se certificar de que ela está lá, aguardando a chegada dos dados que só depois serão enviados. Isso é necessário sempre que, nos níveis inferiores da rede, estiverem trabalhando protocolos que simplesmente injetam os dados nos enlaces, sem saber se, no outro extremo, existe alguém os aguardando. Os serviços com confirmação também são de grande importância. Por meio deles, entidades de transporte que se comunicam trocam dados para informar se um segmento específico foi entregue com sucesso. Quando isso não acontece, ações como a de reenvio de segmentos podem ser executadas. A lista a seguir resume algumas das propriedades comuns que se espera que um protocolo de transporte ofereça:» Garantia de entrega da mensagem;» Entrega de mensagens na mesma ordem em que foram enviadas;» Entrega de, no máximo, uma cópia de cada mensagem;» Admissão de mensagens arbitrariamente grandes;» Implementação de controle de fluxo entre o transmissor e o receptor;» Concentração dos vários processos de aplicação existentes em cada host. Apesar de boa parte dos processos de aplicação requisitar serviços orientados a conexão e com garantias de entrega (o que não se consegue com a camada de rede), há situações em que serviços sem conexão e não confiáveis são necessários. Considere, por exemplo, uma situação em que se deseja assistir a um vídeo pela Internet. Você já imaginou se, a cada quadro de vídeo recebido, nosso computador tivesse que enviar uma informação ao remetente, confirmando a entrega, para só então ele injetar um novo quadro na rede? A sensação de movimento do filme seria completamente perdida. Por outro lado, se nossa máquina deixar de receber ou receber com erro um ou outro quadro, dentre os 30 quadros que recebemos por segundo, talvez o prejuízo não seja tanto. Na Internet, essa questão é administrada pelo uso de dois protocolos na camada de transporte: o UDP (User Datagram Protocol, Protocolo de Datagrama de Usuário), que provê à aplicação solicitante um serviço não confiável e não orientado a conexão, e o TCP (Transmission Control Protocol, Protocolo de Controle de Transmissão), que provê à aplicação solicitante um serviço confiável e orientado a conexão. O projetista de uma aplicação de rede deve especificar o protocolo de transporte a ser usado. Aprenderemos mais sobre o UDP e o TCP noutras seções. 1.2 Multiplexação e demultiplexação na camada de transporte 8 Na seção introdutória deste capítulo, colocamos como a primeira responsabilidade de uma camada de transporte a ampliação do serviço de entrega desempenhado pela camada de rede. Esta tarefa é necessária porque, sobre uma única interface de rede por meio da qual um host se comunique, diversos processos de aplicação podem estar em execução. Para explicar melhor, consideremos uma situação em que estejamos, simultaneamente, acessando uma página da Internet, enviando um arquivo via FTP e mandando um , o que envolve 3 processos de aplicação. Os dados que são gerados por essas aplicações, ao serem repassados para as camadas inferiores, devem possuir um único identificador de rede, visto que estão relacionados ao mesmo sistema de origem. Até aí, tudo bem... mas quando precisarmos receber de volta esses dados da camada de rede (ou entregálos nos respectivos destinos), como saberemos para que processo de aplicação cada um deve seguir? É por este motivo que existem os sockets, que são portas pelas quais os dados passam da rede para o processo e do processo para a rede.

9 Quando os dados vindos de uma aplicação chegam à camada de transporte, eles trazem consigo um número de porta específico, que indica o seu processo de origem. Este número é, então, escrito em determinado campo do segmento de camada de transporte a ser montado. No segmento, também se escreve o número da porta de destino, que indica o processo ao qual se deve entregar os dados do outro lado da conexão. Só depois desse procedimento é que se faz o repasse dos dados à camada de rede. Fazendo uma simples analogia, é como se desejássemos enviar uma carta a alguém que morasse num edifício. Se escrevêssemos no envelope apenas o número do prédio, o mensageiro não saberia para quem encaminhar a correspondência. O número de porta funciona como o número do apartamento, permitindo o passo final da entrega. A reunião de dados provenientes de diferentes processos, aos quais diferentes números de portas são atribuídos, e seu repasse à camada de rede é denominada multiplexação; a recepção, por meio de uma interface de rede, de um grupo de dados e sua entrega a diferentes processos de aplicação é denominada demultiplexação. A multiplexação e a demultiplexação na camada de transporte são ilustradas na Figura 1.2. Redes de Computadores Figura 1.2 Multiplexação e demultiplexação na camada de transporte Na camada de transporte da Internet, cada um dos campos reservados aos números de portas, presentes tanto no UDP quanto no TCP, possuem 16 bits (números decimais de 0 a 65535). Os números de porta entre 0 e 1023 são denominados números de porta bem conhecidos, estando reservados a protocolos cuja utilização é ampla, como o HTTP (porta de número 80) e o FTP (porta de número 21). A lista completa dos números de porta bem conhecidos pode ser encontrada na RFC 1700 e na RFC 3232, em Como nem todos os protocolos de aplicação possuem números de porta bem conhecidos, outras estratégias são necessárias para prover a multiplexação/ demultiplexação. Uma primeira opção é empregar um servidor de processos, que atua num esquema conhecido como protocolo de conexão inicial. Este servidor atende a uma série de portas ao mesmo tempo, aguardando uma solicitação de conexão. Quando uma solicitação a qual nenhum servidor está associado é recebida, o servidor de processos gera uma conexão para o servidor solicitado, funcionando como uma espécie de proxy (intermediário). Noutro modelo, emprega-se um processo especial chamado servidor de nomes, que mantém um registro com os nomes dos diversos serviços e seus respectivos números de porta. As solicitações recebidas e que contêm, inicialmente, o nome do serviço que desejam são, então, encaminhadas para este servidor, o qual retorna o número de porta após uma consulta no registro. Depois disso, a conexão com o servidor de nomes é encerrada e uma nova conexão com o serviço desejado é estabelecida. 9

10 Você Sabia? Firewall é o nome dado ao dispositivo de uma rede de computadores que tem por objetivo aplicar uma política de segurança a um determinado ponto de controle da rede? Algumas das ações mais importantes de um firewall têm efeito por meio do bloqueio ou da restrição do estabelecimento de conexões de certas portas da camada de transporte. Aprenderemos mais sobre firewalls quando tratarmos de segurança em redes de computadores. 1.3 UDP Protocolo de Datagrama do Usuário Nesta seção, começaremos nossos estudos sobre os protocolos que atuam na camada de transporte da Internet. O primeiro protocolo a ser examinado é o UDP e a sua principal característica é a de não ser orientado a conexão. O UDP não se preocupa em estabelecer um contato inicial com a entidade a quem os dados serão enviados, não sendo, portanto, capaz de oferecer qualquer tipo de garantia de que uma entrega bem sucedida será efetuada. Diante disso, resta a este protocolo a funcionalidade básica que descrevemos na seção anterior: multiplexar e demultiplexar dados, para fins de intermediação entre os diversos processos de aplicação e a interface de rede. Diante da sua simplicidade, a importância do UDP enquanto protocolo de transporte poderia até ser questionada... isso sugere a apresentação de alguns motivos que indicam a sua relevância em certos cenários e diante de necessidades específicas. Quando o TCP é empregado na camada de transporte, antes de repassar os dados vindos dos processos de aplicação à camada de rede, uma série de verificações é realizada. O protocolo precisa verificar, por exemplo, se a entidade de destino possui espaço suficiente para acomodar novos dados (controle de fluxo); além disso, é necessário verificar se confirmações de entrega de segmentos anteriormente enviados já foram recebidas. Em caso negativo, pode-se priorizar o reenvio de dados antigos, em vez de injetar na rede dados mais recentes. Com o UDP, nada disso acontece. Tão logo um processo de aplicação passe dados à entidade de transporte, o UDP ele os empacotará num segmento e os repassará imediatamente à camada de rede. Essa forma de proceder tem grande utilidade em aplicações que requerem o que chamamos de tempo real, como uma videoconferência ou uma chamada de voz pela Internet. Em situações como essas, minimizar o tempo decorrido entre a criação dos dados no lado do transmissor e a sua entrega no destino é a prioridade. O alcance desse objetivo seria fortemente comprometido, caso empregássemos o TCP e tivéssemos aguardar verificações como as que descrevemos. 10 O não estabelecimento de conexões por parte do UDP também traz benefícios a aplicações como o DNS. O que o DNS faz se resume a uma simples consulta a um banco de dados; se este banco, por algum motivo, não responder, o solicitante pode refazer a consulta sem grandes prejuízos. Nesse contexto, ao dispensar toda uma troca inicial de informações de configuração de conexão, o UDP acelera o envio de pedidos e respostas, evitando uma lentidão desnecessária. Uma outra consequência disso é o fato de, no UDP, não ser preciso manter estados de conexão, que incluem buffers de envio e recebimento, parâmetros de controle de congestionamento e parâmetros numéricos de sequência e de reconhecimento (quando estudarmos o TCP, entenderemos melhor tudo isso). Como esses parâmetros não precisam ser monitorados, um servidor dedicado a uma aplicação específica pode suportar um número muito maior de clientes ativos quando a aplicação roda sobre UDP. Por fim, no UDP, temos uma sobrecarga de cabeçalho de pacote menor: apenas 8 bytes, em troca de 20

11 bytes do TCP. A Figura 1.3 apresenta um quadro relacionando aplicações conhecidas e o protocolo de transporte utilizado por cada uma delas. Como era de se esperar, aplicações como o correio eletrônico, o acesso a um terminal remoto e a Web, que requerem certas garantias de entrega, utilizam o TCP. No gerenciamento de uma rede, o UDP é preferível; é comum que tarefas de gerenciamento sejam executadas em momentos em que a rede já está com algum tipo de sobrecarga, o que dificulta a transferência confiável de dados com congestionamento controlado. Como já foi comentado, as aplicações que envolvem multimídia utilizam, normalmente, o UDP. Todavia, em muitos casos, tem-se empregado o TCP, para evitar, por exemplo, situações em que muitos remetentes enviem pacotes indiscriminadamente, sem que a rede tome qualquer atitude. É importante mencionar, ainda, que o uso do UDP permite que a confiabilidade da transferência dos dados esteja embutida na própria aplicação. Aplicação Protocolo de camada de aplicação Protocolo de transporte subjacente Correio eletrônico SMTP TCP Acesso a terminal remoto Telnet TCP Web HTTP TCP Transferência de arquivo FTP TCP Servidor remoto de arquivo NFS Tipicamente UDP Recepção de multimídia Tipicamente proprietária UDP ou TCP Telefonia pela Internet Tipicamente proprietária UDP ou TCP Gerenciamento de rede SNMP Tipicamente UDP Protocolo de roteamento RIP Tipicamente UDP Tradução de nome DNS Tipicamente UDP Figura 1.3 Algumas aplicações da Internet e seus protocolos de transporte subjacentes Na Figura 1.4, é apresentada a estrutura de um segmento UDP. Conforme já tínhamos comentado, além do campo de dados da aplicação, o segmento UDP contém um cabeçalho bastante simples, com apenas quatro informações que perfazem um total de 8 bytes. Na primeira linha, observamos os campos porta de origem e porta de destino, que têm a função de orientar os procedimentos de multiplexação e de demultiplexação descritos na seção anterior. O número da porta de origem é particularmente importante quando uma resposta deve ser devolvida à origem (o processo que transmite a resposta copia o campo porta de origem do segmento de entrada no campo porta de destino no segmento de saída, especificando qual processo na máquina transmissora deve recebê-lo). O campo comprimento especifica o tamanho total do segmento, incluindo o cabeçalho, e o campo soma de verificação serve para detectar erros. O valor do campo soma de verificação auxilia uma espécie de prova dos 9, que envolve os dados presentes no segmento e que é executada na sua entrega. Se, por meio desse procedimento, for 11

12 identificado um erro (proveniente, por exemplo, de alguma imperfeição ao longo da transmissão em camadas inferiores), o segmento será simplesmente descartado ou será repassado à camada de aplicação com algum aviso de alerta (o UDP não realiza a correção de um erro detectado). É importante que se tenha esse mecanismo de controle de erros fim a fim, mesmo no UDP, porque não há garantia de que todos os enlaces entre a origem e o destino forneçam verificação de erros (lembremos que o que acontece na camada de transporte deve ser, de certo modo, independente do que acontece nas camadas inferiores). Figura 1.4 Estrutura do segmento UDP 1.4 TCP Protocolo de Controle de Transmissão O TCP é um protocolo projetado para oferecer um fluxo de bytes fim a fim sobre uma rede possivelmente heterogênea e não-confiável. Quando mencionamos a heterogeneidade da rede, estamos nos referindo à possibilidade de, nas camadas inferiores à de transporte, termos, na prática, um emaranhado de redes com topologias, larguras de banda, tamanhos máximos de pacotes e retardos bem diferentes. Os protocolos que lidam com essa diversidade não oferecem a garantia de que os dados são entregues na ordem em que são enviados, por exemplo; na verdade, muitos deles não oferecem sequer a garantia de que os dados são entregues (ainda que fora de ordem). O TCP vem para cobrir essas brechas, sendo representado por uma entidade de transporte que pode ser um procedimento de biblioteca, um processo do usuário ou parte do núcleo numa máquina. Com o TCP, estabelecem-se conexões lógicas full-duplex entre processos que estão sendo executados sobre dois computadores quaisquer da Internet. Isso significa que, antes do envio dos dados úteis, é necessária uma fase de estabelecimento de conexão explícita, de modo análogo ao que ocorre numa chamada telefônica usual, por exemplo. Também se faz necessária uma fase para que a conexão seja encerrada. Este protocolo precisa, ainda, se adaptar à comunicação entre dois computadores que estão bem distantes um do outro, bem como à comunicação entre máquinas que se encontram numa mesma sala. A diferença básica entre estes dois cenários é que os tempos para que os dados enviados por um dos lados vão até a outra a extremidade e retornem (RTT, round-trip time) podem variar bastante. Veremos que o RTT é uma variável crítica para que o serviço de confirmação oferecido pelo TCP funcione corretamente. 12 Outro aspecto que o TCP considera é a entrega em ordem dos dados. As redes sobre as quais uma camada de transporte é implementada podem ser bastante dinâmicas do ponto de vista de encaminhamento dos dados. Isso acontece porque os algoritmos de roteamento, sobre os quais falaremos no próximo capítulo, buscam direcionar os datagramas por linhas que apresentam custos menores (em relação ao retardo, à distância geográfica a ser percorrida, ao congestionamento a ser enfrentado etc). O fato é que esses custos podem ser modificados com o passar do tempo e datagramas com origem e destino

13 iguais podem seguir rotas distintas, sendo entregues fora de ordem. O TCP recorre, então, a números de sequência e faz com que, em alguns casos, a entidade de transporte de destino fique aguardando a chegada de um segmento mais antigo, para que os dados recebidos possam ser repassados à camada de aplicação na ordem correta, sem a presença lacunas. Uma última funcionalidade a ser abordada nesta introdução ao TCP é a de controle de fluxo fim a fim, a qual se baseia no emprego de buffers ou janelas (mais tarde, entenderemos o porquê de se utilizar este termo). Um buffer é uma espécie de área de armazenamento de dados presente nas entidades de transporte transmissoras e receptoras. No transmissor, buffers são necessários para armazenar dados cuja entrega ainda não foi confirmada. Caso seja necessária uma retransmissão, os dados estarão lá, seguramente guardados. No receptor, os buffers armazenam dados que estão esperando pedaços mais antigos que ainda não chegaram ou dados que estão simplesmente aguardando o repasse a um processo da camada de aplicação (costuma-se dizer que um processo de aplicação, no momento apropriado, lê dados que estão armazenados num buffer da camada de transporte). Pela ação do controle de fluxo fim a fim, sob condições normais de funcionamento, uma entidade transmissora não pode enviar uma quantidade de segmentos que não caiba na área de armazenamento da entidade receptora. Para isso, juntamente com a confirmação de entrega de um segmento, a entidade de transporte receptora envia à origem um aviso, informando a sua disponibilidade de buffers (ou o tamanho da sua janela). Naturalmente, o controle de fluxo deve observar, também, questões de congestionamento. Não adiantaria termos, por exemplo, dois computadores com grande capacidade de processamento e com janelas grandes se comunicando por uma rede lenta; as limitações de velocidade da rede teriam que ser respeitadas. Algo semelhante aconteceria se tivéssemos dois computadores lentos se comunicando por enlaces de grande velocidade. Redes de Computadores O segmento TCP Como já mencionamos, o nome dado a um pacote trocado entre duas entidades de transporte TCP é segmento. Cada segmento possui um campo de dados, no qual uma certa quantidade de bytes recebidos do processo transmissor é agrupado. Além disso, um segmento TCP possui um cabeçalho como o que é ilustrado na Figura 1.5. Figura 1.4 Estrutura do segmento TCP Os campos porta de origem e porta de destino possuem a finalidade já descrita no estudo do UDP. Juntamente com os endereços das interfaces de rede de origem e destino, esses campos identificam de forma exclusiva uma conexão TCP. Os campos número de sequência, número de confirmação e janela estão envolvidos em algumas das funções que mencionamos (prevenção contra entrega de duplicatas, conformação de entrega, controle de fluxo etc). O número de sequência, especificamente, contém a numeração associada ao 13

14 primeiro byte de dados transportado no segmento. Os campos URG a FIN são todos flags (sinalizadores). SYN e FIN são usados, respectivamente, no estabelecimento e no término de uma conexão. ACK é ativado quando o campo número de confirmação tiver que ser considerado. URG é ativado quando o segmento contém dados urgentes (o campo ponteiro de urgência indica onde começam os dados não urgentes contidos no segmento). A ativação de PSH indica que o receptor deve entregar os dados à aplicação mediante sua chegada, em vez de armazená-los até que um buffer completo tenha sido recebido. RST é utilizado para reiniciliar uma conexão que tenha ficado confusa por algum motivo. O campo soma de verificação funciona como no UDP e o campo opções serve para o oferecimento de recursos extras, não previstos pelo cabeçalho comum. Nas opções, um host pode, por exemplo, estipular o máximo de carga útil do TCP que está disposto a receber Estabelecimento e encerramento de conexões Para explicarmos como uma conexão é estabelecida no TCP, consideraremos que um dos lados, o host 1, desempenha o papel de chamador ou de cliente (entidade que toma a iniciativa para o estabelecimento da conexão) e que o outro lado, o host 2, desempenha a função de chamado ou de servidor (participante passivo). O algoritmo que determina os passos que devem ser seguidos para que a conexão seja estabelecida é denominado handshake de três vias (veja a Figura 1.5). Figura 1.5 Handshake de três vias: estabelecimento de uma conexão TCP (1) Inicialmente, o cliente envia ao servidor um segmento contendo o número de sequência incial que ele pretende usar. O flag SYN deve estar ativado, indicando uma ação para estabelecimento de conexão. O campo número de sequência do segmento carrega o valor x. (2) O servidor responde com um segmento em que, além do SYN, está ativado, também, o flag ACK, indicando que o campo número de confirmação, ao qual se atribui o valor x + 1, contém uma confirmação relacionada ao segmento recebido (o valor atribuído é x + 1 para informar ao outro lado o número de sequência do próximo segmento que o servidor espera receber; noutras palavras, o servidor indica que todos os segmentos com números de sequências iguais ou menores a x já foram recebidos). (3) Finalmente, o cliente responde com um terceiro segmento que confirma o número de sequência do servidor e, a partir de então, os dados úteis podem fluir de um lado a outro. 14 Os critérios para a escolha dos números de sequência iniciais dos segmentos trocados numa conexão TCP não serão tratados em detalhes neste material. No entanto,

15 é suficiente dizermos que as numerações de cada lado são determinadas de maneira a evitar que um mesmo número de sequência seja reutilizado com frequência. Se isso acontecesse, o TCP teria mais dificuldade para rejeitar segmentos duplicados ou entregues fora de ordem. Outro detalhe importante no estabelecimento de conexões no TCP tem a ver com o uso de timers ou temporizadores (estudaremos isso mais à frente). Sempre que um cliente envia um segmento na tentativa de iniciar uma conexão, ele ativa um timer e aguarda o retorno do servidor por um certo tempo. Se este retorno não acontecer, o cliente entende que o segmento inicial se perdeu e realiza um novo pedido. Juntamente com os números de sequência, são os timers que asseguram que não haverá confusão durante o estabelecimento de uma conexão. Redes de Computadores Dica Na página encontra-se uma animação em flash que ilustra o estabelecimento de uma conexão por meio do handshake de três vias. Acesse! No TCP, o encerramento de uma conexão pode ser melhor compreendido se interpretarmos a conexão (que é full-duplex) como um par de conexões simplex, as quais podem ser finalizadas de modo independente de sua parceira (encerramento simétrico). Quando um lado deseja encerrar a conexão, ele simplesmente envia um segmento com o flag FIN ativado e fica no aguardo de uma confirmação. Isso significa que ele não tem mais dados a enviar, embora ainda possa permanecer recebendo dados que o outro lado envia. Depois que este outro lado fizer o mesmo, a conexão estará encerrada em ambos os sentidos. Aqui, um timer também é utilizado. Ele tem o objetivo de fazer com que a resposta ao envio de um FIN seja aguardada apenas durante certo tempo. Se ela não retornar, a conexão será encerrada. Você Sabia? Não existe solução teórica para se ter certeza de que o encerramento de uma conexão TCP pode ser realizado sem perda de dados que ainda se deseja transmitir de um lado a outro? É por isso que se recorre aos timers que, na prática, funcionam muito bem. Essa questão pode ser entendida com mais detalhes por meio do chamado problema dos dois exércitos. Pesquise e descubra do que se trata esse problema e qual a sua relação com o encerramento de conexões na camada de transporte Política de transmissão do TCP Conforme comentamos quando apresentamos alguns campos presentes no cabeçalho do segmento TCP, as principais funcionalidades desse protocolo dependem, fundamentalmente, dos números de sequência, dos números de confirmação e das janelas. Tais funcionalidades estão relacionadas à política de transmissão do TCP, que contempla questões de controle de fluxo e de garantia de entrega. Uma explicação bem ilustrativa dessas questões pode ser conduzida com base na Figura 1.6. Nesta figura, observamos a troca de segmentos entre transmissor e receptor e verificamos os valores que certos campos dos cabeçalhos desses segmentos e que o buffer do receptor assumem. 15

16 Figura 1.6 Política de transmissão e gerenciamento de janelas no TCP Incialmente, o buffer do receptor, que possui um tamanho de 4096 bytes, encontrase vazio. No passo (1), o transmissor envia 2048 bytes de dados, partindo de um número de sequência igual a 0 (zero). Quando este segmento é recebido, metade da janela é preenchida. Por isso, no passo (2), o receptor responde com o número de confirmação igual a 2048 e com a janela igual a 2048, identificando o tamanho do espaço vazio em seu buffer. Lembre-se que o número de confirmação tem relação com o próximo byte que o receptor espera receber; é como se, no primeiro segmento, tivessem chegado os bytes 0 a 2047 e, no próximo segmento, o primeiro byte devesse ser o byte Se, no passo (3), o transmissor enviar mais 2048 bytes, a janela do receptor será completamente preenchida, pois, nesse meio tempo, a aplicação ainda não leu nada que foi armazenado no buffer. Depois disso, em (4), o receptor responde com o número de confirmação igual a 4096 e com a janela igual a 0. Neste momento, o transmissor se encontra bloqueado, pois ele sabe que, do outro lado, não há espaço para guardar novos dados que ele venha a enviar; o transmissor poderia enviar apenas dados urgentes, com o objetivo de eliminar um processo que estivesse sendo executado no receptor, ou um segmento de 1 byte, pedindo para que o receptor enviasse mais uma vez o ACK e a janela atuais. Quando a aplicação, do lado do receptor, lê 2048 bytes que estavam no buffer, o estado da janela muda. Então, em (5), o receptor envia um segmento repetindo o último número de confirmação e indicando a nova situação da janela. A troca de dados volta, agora, a fluir como anteriormente. 16

17 Dica No link htm, encontra-se uma applet que ilustra por meio de animações um processo semelhante ao que estudamos com base na Figura 1.6. São apresentadas duas máquinas, host A e host B; o usuário pode determinar os tamanhos dos dados que essas máquinas trocam e as respectivas janelas. Quando o início da transmissão é ordenado, é possível observar as confirmações e as mudanças no buffer passando de um lado a outro da conexão. Experimente! O passo a passo descrito parece funcionar muito bem e, do ponto de vista teórico, de fato, funciona! No entanto, se alguns cuidados não forem tomados, a política de transmissão do TCP pode levar a situações de ineficiência, em que a largura de banda disponibilizada pela rede é mal aproveitada e os esforços solicitados ao transmissor e ao receptor são desnecessários. Em primeiro lugar, é importante sabermos que um transmissor não é obrigado a enviar os dados assim que os recebe do processo de aplicação. No cenário que descrevemos, antes de executar o passo (1), o transmissor poderia ter esperado o acúmulo de mais 2048 bytes para, em seguida, enviar um segmento com 4096 bytes de dados. Isso diluiria melhor os bytes do cabeçalho, levando a um melhor aproveitamento da rede. Consideremos, agora, uma situação em que caracteres digitados no teclado de uma máquina (transmissor) estão sendo enviados para uma máquina remota (receptor), como uma espécie de editor interativo via telnet. Você já imaginou se, a cada caractere (byte) digitado e enviado, o receptor tivesse que criar um segmento TCP apenas para enviar confirmações e atualizações de janela?! Quase a totalidade dos bytes retornados seria apenas de cabeçalho, o que, certamente, seria bastante ineficiente. Numa situação como essa, o que o receptor normalmente faz é aguardar a chegada de vários segmentos e confirmar todos de uma só vez, gerando economia de números de sequência e de largura de banda. Do lado do transmissor, que também estaria trabalhando de forma burra, pois, para cada byte enviado, haveria 40 bytes de cabeçalho (considerando os cabeçalhos das camadas de transporte e de rede), outra estratégia é adotada. O que se faz é enviar o primeiro byte recebido do processo de aplicação e acumular em buffer os bytes que vem em seguida, até que o byte pendente tenha sido confirmado. Após essa confirmação, os bytes do buffer são enviados num único segmento TCP e uma nova fase de armazenamento é iniciada até que todas as confirmações retornem. Este procedimento recursivo é conhecido como algoritmo de Nagle. Outra situação específica que pode ocorrer é a chamada síndrome da janela boba, a qual descrevemos a seguir. Imagine um processo de aplicação que repassa à camada de transporte grandes blocos de dados, que, por sua vez, são colocados num segmento TCP e enviados a uma entidade receptora. Considere ainda que, com a janela do receptor totalmente preenchida, o respectivo processo de aplicação inicia a leitura dos bytes recebidos um por vez. Quando 1 byte for lido, o receptor informará ao transmissor sua nova janela, que possui espaço para recebimento de apenas mais 1 byte. Mesmo que o transmissor já possua muitos bytes prontos para envio, ele precisará respeitar a janela do receptor e enviará apenas 1 byte de dados (além de um grande número de bytes de cabeçalho!). A janela do receptor estará novamente cheia e o transmissor deve esperar por uma nova atualização. Se, mais uma vez, a aplicação no receptor ler apenas 1 byte, esse processo voltará a se repetir de maneira indefinida (observe a Figura 1.7). 17

18 Figura 1.7 Síndrome da janela boba A solução para a síndrome da janela boba foi apresentada por Clark. Em vez de o receptor informar ao transmissor pequenas mudanças em sua janela (como a mudança de apenas 1 byte, em nosso exemplo), ele espera até que um espaço maior tenha sido liberado, ou seja, até que um certo número de bytes tenha sido lido pelo processo de aplicação. Na prática, o transmissor aguarda até que o seu buffer esteja ocupado pela metade ou até que haja espaço suficiente para acomodar o tamanho máximo de segmento que as duas entidades combinaram no estabelecimento da conexão. Só depois que uma dessas condições for alcançada é que uma atualização de janela deve ser enviada; é como se o receptor dissesse ao transmissor: pode mandar mais um bloco de bytes, pois, agora, já tenho espaço suficiente. Obviamente, a solução de Clark e o algoritmo de Nagle são complementares. Outras ações podem ser tomadas pelas entidades de transporte a fim de melhorar a eficiência no envio dos segmentos. O próprio transmissor pode acumular um número maior de bytes, antes de enviá-los ao receptor. Apesar de estratégias como essa aumentarem o tempo de resposta, elas elevam o desempenho na transmissão, o que é importante em aplicações como a transferência de arquivos. No que diz respeito à entrega e à confirmação ordenada de dados, o receptor também pode agir. Se os segmentos 1, 2, 3, 4, 6 e 7 chegarem a um receptor, ele pode confirmar os segmentos 1, 2, 3 e 4 e manter os segmentos 6 e 7 armazenados. Quando, do lado do transmissor, o segmento 5 sofrer uma temporização, ele será reenviado. Assim que o receptor recebê-lo, ele poderá ser confirmado juntamente com os segmentos 6 e 7 (o transmissor não precisará reenviar os segmentos 6 e 7) Controle de congestionamento no TCP Em seções anteriores, já conversamos um pouco sobre congestionamento e fluxo. Assim, vamos admitir que você já conhece, de forma clara, as diferenças entre essas questões e as responsabilidades que, nesse contexto, a camada de transporte precisa assumir. Nesta seção, explicaremos de forma mais detalhada a atuação do TCP na prevenção e na reação a situações de congestionamento. Veremos que o TCP recorre a algo que denominamos manipulação dinâmica das janelas e que as diversas opções fornecidas por essa estratégia permitem solucionar as questões mencionadas. Para começar, é interessante que descrevamos como a camada de transporte pode fazer pressuposições acerca do que acontece nas camadas inferiores. Nesse processo, 18

19 a chegada (ou não!) de confirmações desempenha um papel imprescindível. Quando uma entidade de transporte envia um segmento para um receptor, se a confirmação da entrega deste segmento não chegar, o transmissor suporá que algo estranho aconteceu. Antigamente, quando boa parte dos enlaces era de baixa qualidade e expunha os sinais à ação intensa das diversas fontes de distorção presentes no meio físico, era difícil saber o real motivo daquela perda. Hoje, a maioria das linhas de longa distância é de fibras ópticas, em que são raros descartes por conta de ruídos ou interferências. Assim, caso não aconteça a chegada de um segmento que uma entidade de transporte está esperando, ela atribuirá, automaticamente, este fato à ocorrência de um congestionamento em algum ponto da rede. Para colaborar com a prevenção de congestionamentos, o TCP precisa, antes de qualquer coisa, respeitar a janela do receptor (isso tem a ver com o controle do fluxo). No entanto, mesmo que o fluxo esteja sob controle, a rede pode não comportar a taxa em que transmissor e receptor desejam trocar segmentos. Por conta disso, cada transmissor deve manter duas janelas: a própria janela do receptor e a janela de congestionamento, e fazer um nivelamento por baixo, isto é, transmitir rajadas de dados segundo a menor dessas janelas. O tamanho da janela de congestionamento começa a ser definido logo após o estabelecimento de uma conexão, sendo ajustado, inicialmente, ao tamanho do segmento máximo acordado entre as duas entidades. Se um segmento de tamanho máximo for transmitido e sua confirmação retornar antes de uma temporização, a janela de congestionamento será reajustada, passando a ter o dobro do tamanho anterior. É como se a entidade de transporte pensasse: já que a rede está suportando, vou injetar segmentos maiores... Esse processo de sucessivos incrementos no tamanho da janela de congestionamento persiste até que um segmento enviado sofra uma temporização. Se isso acontecer, o algoritmo recuará, reatribuindo à janela de congestionamento o último valor com o qual se conseguiu uma transmissão bem sucedida. O procedimento descrito é denominado algoritmo de Jacobson ou algoritmo de inicialização lenta (perceba que não há nada de lento no algoritmo, já que ele é exponencial!). Na Internet, para que o controle de congestionamento funcione efetivamente, é necessário considerar um parâmetro adicional ao algoritmo apresentado, o limiar, que é inicialmente igual a 64KB. O algoritmo de Jacobson, para incremento da janela de congestionamento, continua funcionando normalmente. A diferença é que, quando o limiar é alcançado, o incremento da janela de congestionamento deixa de ser exponencial para se tornar linear; a cada nova confirmação recebida com sucesso, o tamanho da janela de congestionamento, em vez de dobrar, é incrementado de um número de bytes correspondente ao tamanho do segmento máximo acordado no estabelecimento da conexão. Quando uma temporização acontece, o limiar é redefinido para a metade do tamanho da janela de congestionamento em que a temporização ocorreu e o algoritmo de Jacobson volta para o começo. Essa descrição é ilustrada na Figura 1.8. É claro que qualquer alteração na janela de congestionamento deve respeitar a janela do receptor. Quando o tamanho da janela do receptor é alcançado, a janela de congestionamento para de crescer e permanece constante desde que não ocorra outra temporização e desde que a janela do receptor não mude de tamanho por algum outro motivo. Redes de Computadores 19

20 Figura 1.8 Funcionamento do algoritmo de controle de congestionamento na Internet Temporizadores no TCP Você já deve ter percebido que os temporizadores possuem uma importância essencial no bom funcionamento do TCP. Constantemente, temos mencionado a ocorrência de temporizações como um fator determinante para que alguma providência seja tomada na camada de transporte. O principal temporizador do TCP é o temporizador de retransmissão, que consiste no tempo em que um transmissor aguarda o retorno de uma confirmação antes de retransmitir o respectivo segmento. Bom, esse processo de esperar e decidir sobre uma retransmissão é bem simples de entender... mas você já parou para pensar sobre quanto tempo o transmissor deve ficar esperando? Definitivamente, essa não é uma questão simples. Se este tempo for superdimensionado, o transmissor pode estar esperando desnecessariamente por uma confirmação que nunca vai chegar, o que gera atraso na transmissão dos dados; por outro lado, se este tempo for subdimensionado, o transmissor pode realizar uma retransmissão desnecessária (imagine que a confirmação ainda não tinha chegado, mas já estava a caminho...), gerando um tráfego adicional e contribuindo para a sobrecarga da rede. 20 Na camada de transporte, a obtenção do tempo ótimo de espera por uma confirmação requer algumas considerações. Como a comunicação é fim a fim, esse tempo precisa ser, de certo modo, adaptativo; o tempo para que uma confirmação vinda de uma máquina que se encontra do outro lado do mundo retorne ao transmissor será, certamente, bem maior que aquele necessário à chegada de uma confirmação vinda de um computador que se encontra na sala ao lado (já falamos sobre isso antes). Consequentemente, os temporizadores precisarão ter um pouco mais de paciência no primeiro caso. O algoritmo que materializa esse raciocínio foi desenvolvido por Jacobson, em Para cada conexão, o TCP mantém um parâmetro denotado por RTT (round-trip time), que corresponde a melhor estimativa que, em determinado instante, se tem para o tempo de ida e volta até o destino em questão. Quando um segmento TCP é enviado, um cronômetro é acionado. Imaginando que a confirmação retorne após M unidades de tempo, o RTT é atualizado segundo a expressão