Redes TCP/IP. Protocolos de Transporte e Aplicação

Transcrição

1 Redes TCP/IP Protocolos de Transporte e Aplicação O objetivo desta unidade é apresentar uma revisão dos principais conceitos relacionados aos protocolos de transporte TCP e UDP, bem com os protocolos de aplicação. Os conceitos dessa unidade são requisitos importantes para compreender o funcionamento dos mecanismos de Proxy e NAT que serão abordados na seqüência deste módulo. Eles serão igualmente importantes nas disciplinas que abordarão aspectos de segurança da arquitetura TCP/IP. A leitura desse capítulo não é obrigatória para os alunos que se sentem familiarizados com esses conceitos. 1

2 Protocolo do nível n de transporte DADOS Aplicação Camada de Aplicação HTTP, FTP, SMTP, etc Seqüência de empacotamento S.O. Placa de rede Interface Sockets Camada de Transporte TCP, UDP Camada de Rede IP Camada de Enlace e Fisica quadro pacote transporte aplicação Conforme vimos, a arquitetura TCP/IP é composta por três camadas: Aplicação, Transporte e Rede. Os protocolos que compõe a arquitetura TCP/IP são padronizados e publicados por uma entidade denominada IETF (Internet Engineering Task Force). Os documentos gerados pelo IETF são denominados RFC (Request for Comments) e descrevem em detalhes o funcionamento dos protocolos. Todas as RFCs são acessíveis gratuitamente pelo site As camadas inferiores (Enlace e Física) não são consideradas parte da arquitetura TCP/IP pois são definidas por outra entidade (geralmente, o IEEE - Institute of Electrical and Electronics Engineers). A arquitetura TCP/IP define dois protocolos de transporte: TCP (Transmission Control Protocol) e UDP (User Datagram Protocol). Como pertencem a mesma camada, os protocolos TCP e UDP são concorrentes, isto é, eles nunca podem ser usados ao mesmo tempo. Observe que os protocolos TCP e UDP são implementados pelo sistema operacional. Isso simplifica consideravelmente o desenvolvimento de aplicações que funcionam em rede, pois as especificidades de cada protocolo podem ficar escondidas da aplicação. Cabe a aplicação decidir qual dos dois protocolos será utilizado. Isto é feito através da interface padronizada com o sistema operacional denominada sockets. Essa interface define um conjunto de APIs (funções padronizadas) para mapear aplicações em portas e enviar e receber pacotes. A escolha do protocolo de transporte depende muito dos objetivos da aplicação, como será discutido na seqüência dessa unidade. 2

3 Endereçamento por Portas Computador 1 Computador 2 Processo A Processo Processo Processo Processo B Processo Porta 1024 Porta Porta Porta Porta 80 Porta TCP UDP TCP UDP Endereço IP Endereço IP IP IP End. Físico End. Físico Ethernet Ethernet barramento Mensagem Antes de iniciar a discussão referente as diferenças entre os protocolos TCP e UDP, convém discutirmos suas semelhanças. O objetivo de ambos os protocolos é oferecer um nível de endereçamento para processos no computador. Como vimos anteriormente, esse endereçamento é feitos por números de 16 bits, denominados portas. A maneira como as portas são mapeadas aos processos é definido pela interface sockets. Uma processo (aplicação) pode ou não escolher uma porta quando é iniciado utilizando uma operação denominada BIND. Se o processo for iniciado sem chamar o BIND, uma porta aleatória (geralmente entre 1024 e 65535) será atribuída pelo sistema operacional. O sistema operacional garante que nunca duas portas sejam atribuídas para dois processos ao mesmo tempo. Geralmente, os processos clientes não executam a operação de BIND. Os processos servidores sempre precisam fazer um BIND, pois sua porta não pode ser aleatória (já que os clientes não teriam como endereçá-los). Como discutido na unidade de introdução, a porta usada pelos processos servidores depende de sua natureza. Ela pertence a faixa de portas bem conhecidas (0 a 1023) para aplicações padronizadas para Internet (como web, , e outros) e a faixa de portas registradas (1024 a 49151) para as aplicações servidoras de fabricantes específicos (como Bancos de Dados). 3

4 TCP X UDP TCP Orientado a Conexão Identifica uma seqüência de pacotes com pertencentes a uma mesma transmissão Transmissão por Fluxo Segmentação e Remontagem feita pelo S.O. Transmissão Confiável Confirma recebimento e retransmite pacotes perdidos Não Orientado a Conexão Cada pacote é uma transmissão independente Transmissão por Datagramas: Segmentação e Remontagem feita pela aplicação. Não confiável UDP Cabe a aplicação implementar os mecanismos de retransmissão Os protocolos TCP e UDP são muito diferentes. O protocolo UDP é muito simples, e praticamente só oferece um serviço de endereçamento por portas para a aplicação. Já o TCP é um protocolo muito sofisticado, que realiza diversas operações para a aplicação, como a verificação de recebimento e a retransmissão automática de pacotes perdidos. A primeira diferença entre o TCP e o UDP refere-se a existência ou não de conexão. Uma conexão é criada através de uma troca de pacotes de controle entre um cliente e o servidor que ocorre antes do início do primeiro pacote de dados ser transmitido. O TCP utiliza os pacotes de controle para criar, monitorar e encerrar as conexões. A conexão é um requisito para realizar muitos dos serviços adicionais oferecidos pelo TCP. O UDP, transmite apenas pacotes de dados. A segunda diferença refere-se ao modo de transmissão dos dados. No TCP, uma aplicação não precisa controlar quantos dados cabem em um pacote. Ela pode simplesmente transmitir os dados em um fluxo contínuo, que o S.O. decide como segmentar os dados em pacotes. O S.O. no receptor também remonta os pacotes de forma transparente para a aplicação, que recebe os dados também como um fluxo contínuo. No caso do UDP, cabe a aplicação fornecer para o S.O. uma quantidade de dados que caiba em um pacote. A terceira diferença refere-se ao controle de recebimento e a retransmissão de pacotes perdidos. No caso do TCP os pacotes enviados são confirmados pelo receptor. Caso eles não sejam confirmados, eles são re-enviados automaticamente pelo sistema operacional, sem necessidade de intervenção da aplicação. No caso do UDP, a detecção de pacotes perdidos e a retransmissão precisa ser feita pela aplicação. 4

5 TCP X UDP TCP Controle de Fluxo Controle de Congestionamento Somente Unicast Indicado para transferir grandes quantidades de dados em modo confiável Sem controle UDP Unicast, Multicast ou BroadCast Indicado para transmissões rápidas (poucos dados) ou que não admitam grande atraso (tempo-real) O TCP implementa ainda dois mecanismos bastante sofisticados que não são implementados pelo UDP: o controle de fluxo e o controle de congestionamento. O controle de fluxo é um ajuste automático da velocidade do transmissor, que reduz sua taxa de envio de pacotes para evitar que o receptor perca pacotes por não ter capacidade de recebê-los. Isso é necessário quando dois computadores de capacidade muito distinta se comuniquem numa rede de alta-velocidade. Nesse caso, o limitante de velocidade não é a rede, mas a capacidade de processamento dos computadores. O controle de congestionamento é também um ajuste de velocidade, mas provocado pela perda de pacotes na rede. Quando o TCP detecta perda de pacotes, ele assume que os roteadores da rede tiveram que descartar os pacotes porque a rede está congestionada. Esse mecanismo foi implementado nos primórdios da Internet, quando se percebeu que a retransmissão automática de pacotes sem controle de congestionamento podia levar a rede rapidamente a um colapso. As funcionalidades adicionais oferecidas pelo TCP sobre o UDP vem com um custo: o TCP só suporta transmissões em unicast. Isto é, não é possível usar endereços de broadcast ou multicast em conexão TCP. Isso acontece, entre outras coisas, porque os pacotes TCP precisam ser confirmados pelo receptor. A confirmação não funciona quando se usa um endereço genérico de destino, pois o transmissor não sabe de quantos destinatários ele deve aguardar a confirmação. Todas as aplicações que precisam transmitir broadcast ou multicast precisam usar UDP. O TCP também é um protocolo mais custoso em termos de processamento para os sistemas operacionais e também em termos do volume de dados transmitido pela rede. Ele não é indicado quando a aplicação precisa transmitir apenas mensagens curtas ou mensagens sensíveis ao atraso, que não podem ser retransmitidas. 5

6 Protocolo TCP Byte 1 Byte 2 Byte 3 Byte 4 Porta de Origem Porta de Destino Número de Seqüência Número de Confirmação HLEN Reservado Flags Janela de Recepção Checksum Ponteiro de Urgência Opções Dados... FLAGS: ACK, SYN, FIN, RST, URG, CWR, ECN, PUSH A unidade de informação do TCP é denominada segmento. A estrutura do cabeçalho TCP é mostrada na figura. Além das portas de origem e destino, os demais campos do cabeçalho TCP estão relacionadas as funções oferecidas pelo protocolo. Os campos Número de Seqüência e Número de Confirmação estão relacionados com o mecanismo de transmissão confiável. O campo Janela de Recepção está relacionado com o mecanismo de controle de fluxo. O campo de Flags contém um conjunto de bits de controle utilizado no controle da conexão TCP e também no processo de transmissão confiável. O campo Ponteiro de Urgência é pouco usado na prática. Ele permite informar ao receptor que os dados recebidos devem ser processados de forma mais prioritária, passando a frente de outros dados que estão no buffer aguardando processamento. O campo de Opções não é obrigatório, sendo frequentemente omitido do cabeçalho TCP. Todavia, devido a sua existência, o cabeçalho TCP tem tamanho variável. Por isso, o campo HLEN define o tamanho do cabeçalho em palavras de 4 bytes. 6

7 Transmissão por Fluxo (TCP) socket aplicação TCP IP Fluxo contínuo de bytes (stream) segmentos aplicação socket TCP IP Fluxo contínuo de bytes (stream) segmentos Quando se utiliza o TCP, a decisão de quando um segmento é criado e transmitido é feita pelo protocolo e não pela aplicação. Essa estratégia é denominada de transmissão por fluxo. Utilizando a API de sockets, a aplicação pode solicitar ao sistema operacional (TCP) que transmita bytes em um fluxo contínuo. Cada pedido de transmissão não gera necessariamente um pacote, pois o TCP pode aguardar que uma quantidade razoável de bytes seja recebida, a fim de não gerar muitos pacotes de tamanho pequeno. O tamanho do pacote é uma solução de compromisso entre minimizar o número de pacotes transmitidos, e não causar um atraso excessivo na transmissão quando o volume de dados a ser transmitido é pequeno. Teoricamente, um pacote IP pode ter até 64Kbytes. A principio seria aproximadamente esse o volume de dados (menos o tamanho do cabeçalho TCP) que o TCP deveria aguardar antes de gerar um pacote. Nas implementações dos sistemas operacionais modernos, contudo, a quantidade de bytes que o TCP acumula é definida de acordo com o MTU da interface de rede (1500 bytes para o Etherent). Isso é feito para evitar que o pacote seja fragmentado pela camada IP. O tamanho máximo de um segmento é denominado MSS (Maximum Segment Size), ele corresponde a 1460 bytes (1500 bytes 20 bytes do cabeçalho IP 20 bytes do cabeçalho TCP). 7

8 Segmentação e Remontagem Início da Conexão Fim da Conexão Fluxo Contínuo de Bytes bytes NIS + 0 Dados NIS Dados NIS Dados SEGMENTO SEGMENTO SEGMENTO A fim de tornar o processo de segmentação e remontagem transparente para as aplicações, o TCP inclui em seu cabeçalho informações necessárias para que o sistema operacional do receptor efetue a remontagem de forma automática. É importante ressaltar que uma conexão TCP é identificada por quatro endereços: IP de Origem, Porta de Origem, IP de Destino e Porta de Destino. Conforme ilustrado na figura, após o estabelecimento de uma conexão TCP, todos os segmentos transmitidos são numerados em bytes, utilizando o campo Número de Seqüência. A contagem em bytes, todavia, não começa no número zero, mas sim em um número inicial de seqüência (NIS) escolhido de forma aleatória. O valor do NIS é escolhido para cada conexão. Se um par de computadores (A e B) encerrar uma conexão e iniciar uma outra entre si imediatamente depois, um outro NIS será utilizado. O valor do NIS é também unidirecional, isto é, um NIS é utilizado para o fluxo de pacotes de A para B, e outro de B para A. A justificativa inicial para o NIS ser aleatório é justamente evitar uma montagem errônea de pacotes quando uma conexão entre os mesmos computadores usando o mesmo par de portas é iniciada muito próximo da conexão previamente encerrada. Devido a atrasos da rede, os pacotes da conexão encerrada anteriormente poderiam ser confundidos com os pacotes da nova conexão. 8

9 Comunicação Confiável segmento 1 segmento 2 segmento A segmento B cliente seq=1000, conf=2000, dados=500 bytes servidor seq=2000, conf=1500, dados=100 bytes seq=1500, conf=2100, dados=300 seq=2100, conf=1800, dados=890 bytes tempo tempo O TCP implementa um processo de comunicação confiável denominado retransmissão por ausência de confirmação. Conforme mostra a figura, os segmentos enviados entre os computadores utilizam os campos número de seqüência (seq) e número de confirmação (conf) para implementar essa estratégia. O campo seq indica sempre o primeiro byte do segmento sendo transmitido. O campo conf indica o próximo byte que o transmissor espera receber do seu parceiro (peer). Observe que o campo conf tem o significado implícito de reconhecimento de recebimentos. Isto é, se um peer envia um segmento com o número de confirmação 2000, por exemplo, ele está confirmado que já recebeu os bytes anteriores numerados até No TCP não é necessário enviar uma mensagem só para confirmar o recebimento de dados. O TCP utiliza uma estratégia em que o mesmo segmento usado para transmitir novos dados também confirma o recebimento dos dados já recebidos. Para ilustrar esse conceito, suponha que o cliente tem dois segmentos para transmitir: segmento 1 (bytes 1000 a 1499) e segmento 2 (bytes de 1500 a 1799). O servidor também tem dois segmentos para transmitir: segmento A (bytes 2009 a 2099) e segmento B (bytes 2100 a 2989). O cliente transmite o segmento 1 (500 bytes) com seq=1000 e conf=2000. Isso significa que ele está confirmado para o servidor que ele já recebeu os bytes anteriores a O servidor responde com seq=2000 e conf=1500. Observe o campo seq corresponde exatamente ao próximo byte esperado pelo cliente e o campo conf confirma o recebimento dos bytes correspondentes ao segmento 1. O processo se repete conforme ilustrado na figura. 9

10 Recomendações RFC 1122 e 2581 EVENTO AÇÃO TCP DESTINATÁRIO Chegada de um segmento na ordem. Aguarda 500 ms. Se outro segmento não chegar, confirma o segmento. Se outro segmento vier, confirma os dois com um único ACK. Chegada de um segmento fora de ordem (número mais alto que o esperado). Envia imediatamente o ACK duplicado com o número do byte aguardado (isto é, repete o último ACK de ordem correta). Chegada de um segmento que preenche a lacuna. Envia imediatamente o ACK (se o preechimento foi na parte contigua baixa da lacuna). A técnica de retransmissão do TCP é o reconhecimento positivo com temporizadores. O TCP não usa mensagens de erro. Se uma confirmação de recebimento não chegar no transmissor num tempo pré-determinado, o segmento é retransmitido. O receptor pode enviar pacotes sem dados, apenas com confirmação, quando não tem nada para transmitir. O tempo máximo para aguardar uma confirmação é estimado em função do tempo médio de Round-Trip Time (RTT) para enviar e confirmar um segmento. O transmissor pode adotar várias técnicas para estimar este tempo. Uma estratégia comum é a seguinte: EstimatedRTT = EstimatedRTT SampleRTT Temporizador = EstimatedRTT + 4. Desvio Desvio = Desvio (SampleRTT EstimatedRTT) onde: SampleRTT: última medição de RTT Temporizador: tempo máximo para aguardar uma confirmação Desvio: medida da flutuação do valor do RTT O receptor não confirma segmentos recebidos fora da ordem. Ao invés disso, para cada segmento recebido fora de ordem, o receptor repete o número de confirmação do último segmento recebido na seqüência correta para o transmissor. Se o transmissor receber 3 segmentos com o mesmo número de confirmação, ele retransmite todos os segmentos ainda não confirmados. Essa técnica é denominada retransmissão rápida (retransmissão antes de expirar o temporizador do segmento). A figura apresenta um resumo das principais recomendações sobre o funcionamento do TCP, descritas nas RFCs 1122 e

11 Conexão TCP cliente seq=c_nis, ACK=0, SYN=1 servidor abertura de conexão seq=s_nis, conf=c_nis+1, ACK=1, SYN=1 seq=c_nis+1, conf=s_nis+1, ACK=1,SYN=0 ACK=1,SYN=0... transmissão dos dados encerramento de conexão FIN=1 ACK=1 FIN=1 ACK=1 tempo tempo Os bits ACK, SYN e FIN (definidos no campo FLAS do TCP) são utilizados para controlar a abertura e o encerramento das conexões TCP. O ACK é o flag de confirmação de recebimento. Ele é 0 no primeiro segmento transmitido (pois não há nada a confirmar) e 1 em todos os demais. O SYN é o flag de sincronismo. Seu valor é 1 é apenas nos dois primeiros segmentos trocados entre o cliente e o servidor. O flag FIN é flag de finalização. Quando seu valor é um, ele indica o desejo de encerrar a conexão. Uma conexão TCP estabelece os números de seqüência iniciais (NIS) usados pelo cliente e o servidor. Isso envolve a troca de três segmentos: 1) O cliente envia para o servidor pedido de abertura de conexão (segmento SYN). Esse segmento define o valor inicial do número de seqüência do cliente (C_NIS), e é identificado pelos flags SYN=1, ACK=0. 2) O servidor envia para o cliente a confirmação da abertura da conexão (segmento SYNACK). Esse segmento informa o valor inicial do número de seqüência do servidor (S_NIS), e é identificado pelos flags SYN=1 e ACK=1. 3) O cliente envia para o servidor a confirmação do recebimento do segmento SYNACK. Após essa fase, os dados podem ser trocados indefinidamente entre o cliente e o servidor. Observe que durante a fase de troca de dados que ACK=1 e SYN=0. O encerramento da conexão pode ser feito por iniciativa do servidor ou do cliente. A conexão TCP é bidirecional, então o encerramento completo da conexão precisa que ambos, o cliente e o servidor, enviem pedidos de encerramento. O encerramento envolve a troca de 4 segmentos. No exemplo da figura, a iniciativa de encerramento da conexão foi feita pelo cliente. Assim, primeiro, o cliente envia para o servidor um segmento com o flag FIN=1. O servidor envia um segmento confirmando o recebimento do FIN, e outro solicitando encerramento da sua conexão. Finalmente o cliente confirma o recebimento do segmento FIN do servidor. O TCP permite também um encerramento rápido da conexão utilizando o flag Reset (RST). Quando o cliente ou o servido enviam um pacote com RST=1, a conexão é encerrada com um único pacote. 11

12 Controle de Fluxo S.O RcvBuffer 2000 LastByteRcvd 1000 aplicação LastByteRead 0 A conf=1000 RcvWindow=1000 B Transmissor Receptor É importante lembrar que quando um segmento TCP é transmitido, ele primeiramente é recebido pelo sistema operacional (S.O.) da máquina receptora e armazenado em um buffer. Esse processo de recepção ocorre de forma transparente para a aplicação, uma vez que o TCP é implementado pelo S.O. Esse buffer contudo, tem capacidade limitada. A aplicação do receptor deve ser capaz de remover os dados do buffer numa velocidade compatível com a taxa de recebimento. Se o receptor for muito lento (ou a aplicação tiver sido mal escrita), pode ser que a aplicação receptora não dê conta de ler os dados do buffer, e este se encha por completo. Quando o buffer do S.O. está cheio, os novos segmentos recebidos são simplesmente descartados. O controle de fluxo é um mecanismo do TCP que evita que isso aconteça. Nesse mecanismo, o receptor informa junto com a confirmação do recebimento de cada segmento a quantidade de buffer que ele ainda tem disponível utilizando o campo Janela de Recepção (RcvWindow) do cabeçalho do TCP. Para ilustrar como o controle de fluxo funciona, considere o cenário da figura, onde o computador A é o transmissor, e o computador B é o receptor. O algoritmo para o cálculo da Janela de Recepção utiliza três parâmetros: RcvBuffer = buffer de recepção de B LastByteRead = número do último byte lido pela aplicação B LastByteRcvd = último byte recebido por B A Janela de Recepção RcvWindow enviada de B para A é definida por: RcvWindow = RcvBuffer - [LastByteRcvd - LastByteRead] 12

13 Controle de Congestionamento MSS congwindow crescimento exponencial prevenção de congestionamento evento de falha Threshold prevenção de congestionamento Threshold RTT RTT RTT RTT RTT RTT RTT RTT RTT RTT t A envio B RTT confirmação Na prática, o TCP impõe uma outra janela que limita o envio de bytes pelo transmissor. Essa janela é denominada Janela de Congestionamento (CongWindow). Ao contrário da Janela de Recepção, a Janela de Congestinamento não possui um campo correspondente no cabeçalho do TCP. Ela é calculada internamente pelo sistema operacional do transmissor com base no sucesso ou fracasso na transmissão de segmentos. Todas as vezes que um segmento é perdido, o TCP assume que a rede está congestionada e tenta reduzir a velocidade do transmissor. Quando os segmentos são transmitidos com sucesso, a janela é aumentada. A janela CongWindow é calculada em múltiplos de MSS (Maximum Segment Size = 1460 bytes). A figura ilustra como a CongWindow evolui ao longo do tempo. Inicialmente, a janela é ajustada para 1 MSS e é dobrada a cada segmento confirmado com sucesso. Esse processo de crescimento exponencial continua até um certo valor de Threshold. A partir desse ponto, a janela entre numa fase de prevenção de congestionamento, onde o crescimento é mais lento (apenas um 1 MSS a cada confirmação bem sucedida). Em caso de falha, o tamanho da janela e do Threshold são reduzidos a metade. O algorimto de cáculo da CongWin pode ser resumido da seguinte forma: a) Inicialização: CongWin = 1 MSS (Maximum Segment Size = 1460 bytes) Threshold = 65 kbps b) Fase de crescimento exponencial (a cada confirmação recebida) se CongWin < Threshold vai para Partida Lenta: CongWin = CongWin + MSS Isto é, CongWin= Congwin*2 por RTT senão vai para Prevenção de Congestionamento: CongWin = CongWin + (MSS/CongWin) Isto é, CongWin = CongWin + 1 MSS por RTT c) Em caso de detecção de segmentos fora de ordem: Threshold = CongWin = CongWin/2 Vai para prevenção de congestionamento d) Em caso de detecção de perda por temporização Threshold = CongWin/2 CongWin = 1 MSS (volta para partida lenta) 13

14 Congestionamento X Controle de Fluxo Dados a Serem Trasmitidos tempo 2000 RcvWindow 1800 CongWindow 1500 LastByteSent LastByteAcked A envio B RTT confirmação Em um dado instante, a taxa máxima de envio de segmentos pelo transmissor é dada pela menor valor de janela definida pelo controle de fluxo e o controle de congestionamento. Esse valor é calculado da seguinte forma: taxa_máxima = [min(congwindow,rcvwindow) - (LastByteSent-LastByteAcked)]/RTT bytes/s. onde: LastByteSent: último byte enviado pelo transmissor LastByteAcked: última byte confirmado pelo receptor O TCP distingue dois eventos de falha: perda de segmento (isto é, o receptor não enviou nenhuma confirmação) e chegada de segmentos fora de ordem (isto é, o receptor está enviou segmentos com o número de confirmação duplicado). O primeiro evento é considerado mais grave que o segundo, pois no caso dos segmentos fora de ordem, o receptor ainda consegue sinalizar segmentos ao transmissor. Existem algumas variantes na implementação do TCP, de acordo como o mecanismo de controle congestionamento reage a esses eventos de falha. A versão Tahoe é a mais antiga, e volta para partida lenta (CongWin=1MSS) para qualquer evento de falha. A versão Reno é mais recente, e adota uma recuperação rápida (CongWin=CongWin/2) no caso de segmentos fora de ordem, e partida lenta (CongWin=1MSS) em caso de perda de segmentos. O TCP Vegas é uma proposta não implementada em muitos SOs. Ela reduz a taxa de transmissão de pacotes mesmo antes da ocorrência de perda, monitorando o aumento do valor do RTT (tempo de confirmação). 14

15 Protocolo UDP Byte 1 Byte 2 Byte 3 Byte 4 Porta de Origem Ponteiro de Urgência Porta de Destino Checksum Dados... O cabeçalho UDP (User Datagram Protocol) são bem mais simples que o TCP, pois ele não oferece nenhuma funcionalidade além da simples multiplexação de portas. O nome da unidade de dados do protocolo UDP é geralmente denominada datagrama UDP. Apesar do UDP possuir um campo para verificação de erros de transmissão (CheckSum), o protocolo não oferece nenhum serviço de confirmação para o transmissor, nem a retransmissão dos pacotes perdidos. Ele também não tem o conceito de conexão, sendo portanto, incapaz de segmentar e remontar de forma transparente para a aplicação os dados transmitidos. Isso não significa que não é possível desenvolver aplicações sobre o protocolo UDP que sejam confiáveis ou que possam transmitir grandes volumes de dados. Significa, simplesmente, que essas funcionalidades adicionais deverão estar embutidas no código da aplicação, pois elas não serão oferecidas pelo sistema operacional. Por exemplo, o NFS (Network File System) que permite aos sistemas Unix compartilharem diretórios pela rede é construído sobre UDP. Em muitos casos, os desenvolvedores optam por não usar as funcionalidades do TCP devido ao custo de performance associado. Isso é particularmente verdade para as aplicações sensíveis atraso e jitter (i.e., aplicações tempo-real). Por exemplo, em uma aplicação de VoIP (Voz Sobre IP) não vale a pena retransmitir pacotes perdidos, pois a capacidade de re-ordenamento do terminal de VoIP é limitada. O UDP é ainda essencial nos casos das aplicações que precisam transmitir mensagens em multicast ou broadcast, pois TCP suporta apenas o modo unicast. 15

16 Protocolos de Aplicação Camada de Aplicação HTTP FTP SMTP NFS DNS DHCP Camada de Transporte TCP UDP Camada de Rede IP Os protocolos da camada de aplicação seguem uma estratégia bem diferente dos protocolos das camadas de transporte e rede. Enquanto os protocolos TCP, UDP e IP oferecem a possibilidade de grande quantidade de reuso de código entre aplicações distintas, os protocolos de aplicação são particulares a cada aplicação. Dessa forma, não vale a pena implementar os protocolos de aplicação ao nível do sistema operacional, ficando mais simples implementá-los nas próprias aplicações cliente e servidora. O objetivo dos protocolos de aplicação é permitir a comunicação entre programas desenvolvidos por fabricantes diferentes. Os protocolos de aplicação relacionados aos serviços IP são padronizados na forma de RFCs pelo IETF. Muitos dos protocolos usados na Internet são formados de mensagem em texto. Nesses protocolos, a separação entre campos do protocolo é muitas vezes feitas por um caractere de quebra de linha (\n). Por exemplo, o uma mensagem do protocolo HTTP solicitando a pagina pode ter o seguinte formato: GET /~jamhour/welcome.html HTTP/1.1\r\n Host: espec.ppgia.pucpr.br\r\n Cache-Control: no-cache\r\n \r\n Para os protocolos em formato texto, como o HTTP, a transmissão de informações binárias (como figuras ou videos) precisa ser codificada utilizando algoritmos como o base64, que codificam qualquer tipo de informação binária em caracteres do tipo texto, a fim de que possa ser transmitida. 16

17 Portas bem Conhecidas http httpd 80 >1023 wget ftp control 21 >1023 servidor ftpd 20 ftp data >1023 ftp cliente smptd 25 smtp >1023 firefox nfsd 2049 nfs >1023 nfs client named 53 dns >1023 dig dhcp dhcpd 67 >1023 dhclient Conforme discutido anteriormente, a IANA (Internet Assigned Number Authority) define um mapeamento padrão entre os principais protocolos de aplicação e as portas TCP ou UDP. Essas portas padronizadas são denominadas Portas Bem Conhecidas (WellKnown Ports). A figura ilustra as portas associadas a alguns protocolos bem conhecidos. Observe que a porta bem conhecida é usada apenas no lado do servidor. No lado do cliente, a porta é dinâmica, e é escolhida pelo sistema operacional no momento em que a aplicação cliente solicita uma conexão com o servidor. Por exemplo, o cliente http de comando de linha (modo não gráfico) do Linux é o wget. Quando você digita o comando abaixo o cliente wget vai receber uma porta dinâmica que ficará associada a ele durante a transferência do arquivo vlan.tar.gz, sendo liberada após o término do download do arquivo. : wget Observe que quando você digita o comando wget não é necessário especificar em que porta o servidor http estará escutando. Isso acontece porque o cliente wget assume por default que o servidor estará conectado na porta 80. É possível, contudo, instalar as aplicações servidoras em portas alternativas. Por exemplo, se o servidor http da espec for instalado na porta 8080 (não padrão), o cliente wget precisar informar a porta da seguinte forma. wget Observe também, que a maioria das aplicações servidoras do Linux tem seu nome terminado com d. Isso acontecer porque as aplicações servidoras do Linux que rodam em segundo plano (sem interface visível com o usuário) são denominadas daemon. 17

18 Conclusão Protocolos de Transporte e Aplicação Nesta unidade, fizemos uma revisão dos principais conceitos relacionados aos protocolos de transporte e aplicação da arquitetura TCP/IP. Este documento deve ser revisto pelo aluno sempre que ele tiver dúvidas relativas ao funcionamento desses protocolos. Conhecimentos mais aprofundados sobre o funcionamento dos protocolos TCP e UDP serão necessários, por exemplo, na disciplinas de segurança em redes, que irá discutir a configuração de firewalls. Como veremos a configuração dos firewalls levam em conta o conceito de conexão do TCP e, sua ausência, no caso do UDP. O conhecimento sobre o funcionamento desse protocolos também será importante para compreender o funcionamento do mecanismo de Proxy e NAT, discutidos na seqüência dessa disciplina. O conceito de protocolo de aplicação também é necessário para compreender o funcionamento dos Proxies. 18