4

Camada de Transporte OSI

CAMADA DE TRANSPORTE OSI ------------------------------------------------------------------------------------------ 1 4.0 INTRODUO AO CAPTULO ---------------------------------------------------------------------------------------------- 2 4.0.1 Objetivos 2 4.1 FUNES DA CAMADA DE TRANSPORTE --------------------------------------------------------------------------------- 3 4.1.1 Propsito da Camada de Transporte 3
4.1.1.1 4.1.1.2 4.1.1.3 4.1.1.4 4.1.1.5 4.1.1.6 4.1.2.1 4.1.2.2 4.1.2.3 4.1.2.4 4.1.3.1 4.1.4.1 4.1.4.2 4.1.5.1 4.1.5.2 Rastreamento de Conversaes Individuais -------------------------------------------------------------------3 Segmentao de Dados --------------------------------------------------------------------------------------------3 Reagrupamento de Segmentos-----------------------------------------------------------------------------------3 Identificao das Aplicaes --------------------------------------------------------------------------------------3 As Necessidades de Dados Variam ------------------------------------------------------------------------------4 Separao de Mltiplas Comunicaes-------------------------------------------------------------------------4

4.1.2 Controle das Conversaes

Estabelecimento de uma Sesso ---------------------------------------------------------------------------------6 Entrega Confivel ----------------------------------------------------------------------------------------------------6 Entrega na Mesma Ordem -----------------------------------------------------------------------------------------6 Controle de Fluxo ----------------------------------------------------------------------------------------------------6

4.1.3 Suporte de Comunicao Confivel 4.1.4 TCP e UDP 4.1.5 Endereamento de Porta

6 8 9

Determinao da Necessidade de Confiabilidade -----------------------------------------------------------7 Protocolo UDP (User Datagram Protocol) ---------------------------------------------------------------------8 Protocolo TCP ---------------------------------------------------------------------------------------------------------8 Identificao de Conversaes -----------------------------------------------------------------------------------9 Utilizao do TCP e do UDP-------------------------------------------------------------------------------------- 10

4.1.6 Segmentao e Reagrupamento - Dividir e Conquistar 12 4.2 O PROTOCOLO TCP - COMUNICANDO COM CONFIABILIDADE ------------------------------------------------------- 12 4.2.1 TCP - Tornando as Conversaes Confiveis 12 4.2.2 Processos TCP em Servidores 13 4.2.3 Estabelecimento e Trmino de conexes TCP 14 4.2.4 Handshake Triplo TCP 16
4.2.4.1 4.2.4.2 4.2.4.3 Etapa 1---------------------------------------------------------------------------------------------------------------- 16 Etapa 2---------------------------------------------------------------------------------------------------------------- 16 Etapa 3---------------------------------------------------------------------------------------------------------------- 17

4.2.5 Encerramento de Sesso TCP 18 4.3 GERENCIAMENTO DE SESSES TCP ------------------------------------------------------------------------------------ 20 4.3.1 Reagrupamento de Segmentos TCP 20
4.3.1.1 4.3.2.1 4.3.3.1 4.3.4.1 4.3.4.2 Refazendo o Sequenciamento de Segmentos na Ordem Transmitida -------------------------------- 20

4.3.2 Confirmao TCP com Janelamento 4.3.3 4.3.3 Retransmisso TCP 4.3.4 Controle de Congestionamento TCP - Minimizando a Perda de Segmentos

21 22 23

Confirmao de Recebimento de Segmentos --------------------------------------------------------------- 21 Lidando com a Perda de Segmento --------------------------------------------------------------------------- 22 Controle de Fluxo -------------------------------------------------------------------------------------------------- 23 Reduo do Tamanho de Janela-------------------------------------------------------------------------------- 24

4.4 O PROTOCOLO UDP - COMUNICAO COM BAIXO OVERHEAD----------------------------------------------------- 26 4.4.1 UDP - Baixo Overhead versus Confiabilidade 26 4.4.2 Reagrupamento de Datagramas UDP 26 4.4.3 Solicitaes UDP e Processos de Servidores 27 4.4.4 Processos de cliente UDP 28 4.5 RESUMO E REVISO ----------------------------------------------------------------------------------------------------- 29

4.0 Introduo ao Captulo

As redes de dados e a Internet suportam a rede humana atravs do fornecimento de comunicao contnua e confivel entre pessoas localmente e ao redor do mundo. Atravs de um simples dispositivo, as pessoas podem usar mltiplos servios como e-mail, web e mensagens instantneas para enviar mensagens ou recuperar informao. Aplicaes como clientes de e-mail, navegadores e clientes de envio de mensagem instantnea permitem s pessoas usarem os computadores e redes para enviar mensagens e encontrar informao. Dados de cada uma dessas aplicaes so empacotadas, transportadas e entregues ao servidor daemon apropriado ou aplicao no dispositivo de destino. Os processos descritos na camada de Transporte do modelo OSI aceitam dados da Camada de Aplicao e os preparam para endereamento na camada de Rede. A camada de Transporte responsvel pela transferncia fim-a-fim geral de dados de aplicao. Neste captulo, ns examinaremos o papel da camada de Transporte no encapsulamento de dados de aplicao para uso pela camada de Rede. A camada de Transporte tambm abrange estas funes: Habilita a comunicao de mltiplas aplicaes na rede ao mesmo tempo em um nico dispositivo Assegura que, se necessrio, todos os dados sejam recebidos confiavelmente e em ordem pela aplicao correta. Emprega mecanismos de tratamento de erros

4.0.1 Objetivos Aps o trmino deste captulo, voc ser capaz de: Explicar a necessidade da camada de Transporte. Identificar o papel da camada de Transporte, visto que, ela proporciona a transferncia fim-a-fim de dados entre aplicaes. Descrever o papel de dois protocolos TCP/IP da camada de Transporte: TCP e UDP. Explicar as funes principais da camada de Transporte, incluindo confiabilidade, endereamento de porta e segmentao. Explicar como o TCP e o UDP gerenciam funes-chave. Identificar quando apropriado usar o TCP ou o UDP e apresentar exemplos de aplicaes que usam cada um desses protocolos.

4.1 Funes da Camada de Transporte

4.1.1 Propsito da Camada de Transporte A camada de Transporte proporciona a segmentao de dados e o controle necessrio para reagrupar esses segmentos em fluxos de comunicao. Suas responsabilidades primrias para realizar isto so: Rastrear a comunicao individual entre as aplicaes nos hosts de origem e destino. Segmentar dados e gerenciar cada segmento Reagrupar os segmentos em fluxos de dados de aplicao Identificar as diferentes aplicaes Rastreamento de Conversaes Individuais

4.1.1.1 Rastreamento de Conversaes Individuais Qualquer host pode ter mltiplas aplicaes que se comunicam atravs da rede. Cada uma destas aplicaes ir se comunicar com uma ou mais aplicaes em hosts remotos. responsabilidade da camada de Transporte manter fluxos mltiplos de comunicao entre estas aplicaes. 4.1.1.2 Segmentao de Dados Como cada aplicao cria um fluxo de dados para ser enviado a uma aplicao remota, estes dados devem ser preparados para serem enviados atravs do meio em segmentos gerenciveis. Os protocolos de camada de Transporte descrevem servios que segmentam estes dados a partir da camada de Aplicao. Isto inclui o encapsulamento necessrio em cada lado do segmento. Cada segmento de dados de aplicao requer a adio de cabealhos da camada de Transporte para indicar a qual comunicao ele est associado. 4.1.1.3 Reagrupamento de Segmentos No host de destino, cada segmento de dados pode ser direcionado para a aplicao apropriada. Em adio a isso, estes segmentos de dados individuais tambm precisam ser reconstrudos em um fluxo completo de dados que seja til para a camada de Aplicao. Os protocolos da camada de Transporte descrevem como a informao do cabealho da camada de Transporte usada para reagrupar os segmentos de dados em fluxos a serem passados para a camada de Aplicao. 4.1.1.4 Identificao das Aplicaes Para passar os fluxos de dados para as aplicaes apropriadas, a camada de Transporte deve identificar a aplicao de destino. Para realizar isso, a camada de Transporte designa aplicao um identificador. Os protocolos TCP/IP chamam esse identificador de nmero de porta. A cada processo de software que precise acessar a rede designado um nmero de porta nico naquele host. Este nmero de porta usado no cabealho da camada de transporte para indicar a qual aplicao aquele segmento de dado est associado.

A camada de Transporte o link entre a camada de Aplicao e a camada inferior, que so responsveis pela transmisso na rede. Esta camada aceita dados de diferentes conversaes e os passa para as camadas inferiores como segmentos gerenciveis que podem ser finalmente multiplexados no meio. As aplicaes no precisam saber dos detalhes operacionais da rede em uso. As aplicaes geram dados que so enviados de uma aplicao a outra, sem considerar o tipo de host de destino, o tipo de meio sobre o qual o dado deve trafegar, o caminho tomado pelo dado, o congestionamento em um link, ou o tamanho da rede. Adicionalmente, as camadas inferiores no esto a par de que existem mltiplas aplicaes enviando dados na rede. Sua responsabilidade entregar os dados ao dispositivo apropriado. A camada de transporte ento organiza esses segmentos antes de entreg-los aplicao apropriada. 4.1.1.5 As Necessidades de Dados Variam Devido ao fato de diferentes aplicaes terem diferentes necessidades, existem mltiplos protocolos da camada de Transporte. Para algumas aplicaes, os segmentos devem chegar em uma sequncia especfica para serem processados com sucesso. Em alguns casos, todos os dados precisam ser recebidos por qualquer um deles para poderem ser usado. Em outros casos, uma aplicao pode tolerar alguma perda de dados durante a transmisso atravs da rede. Nas redes convergidas atuais, as aplicaes com diferentes necessidades de transporte podem se comunicar na mesma rede. Os diferentes protocolos da camada de Transporte tm diferentes regras que permitem aos dispositivos lidar com essas necessidades diversas de dados. Alguns protocolos fornecem apenas as funes bsicas para entregar eficientemente os segmentos de dados entre as aplicaes apropriadas. Estes tipos de protocolos so teis para aplicaes cujos dados so sensveis a atrasos. Outros protocolos da camada de Transporte descrevem processos que fornecem caractersticas adicionais, tais como assegurar a entrega confivel entre as aplicaes. Embora estas funes adicionais proporcionem uma comunicao mais robusta na camada de Transporte entre as aplicaes, elas geram uma sobrecarga adicional e fornecem maiores demandas sobre a rede. 4.1.1.6 Separao de Mltiplas Comunicaes Considere um computador conectado a uma rede que est simultaneamente recebendo e enviando e-mails e mensagens instantneas, exibindo websites e conduzindo uma chamada VoIP. Cada uma destas aplicaes est enviando e recebendo dados atravs da rede ao mesmo tempo. No entanto, os dados da chamada telefnica no so direcionados ao navegador web, e o texto de uma mensagem instantnea no aparece em um e-mail. Alm disso, os usurios necessitam que um e-mail ou pgina web sejam completamente recebidos e apresentados para que a informao seja considerada til. Atrasos leves so considerados aceitveis para assegurar que a informao completa seja recebida e apresentada. Em contraste, pequenas perdas ocasionada de partes de uma conversa telefnica pode ser considerada aceitvel.

Uma pessoa pode inferir a perda de udio a partir do contexto da conversa ou pedir a outra pessoa para repetir o que foi dito. Isto considerado prefervel a atrasos que resultariam de pedido rede para gerenciar e reenviar os segmentos perdidos. Neste exemplo, o usurio - no a rede - gerencia o reenvio ou substituio da informao perdida. Conforme foi explicado no captulo anterior, o envio de alguns tipos de dados um vdeo por exemplo - atravs da rede com um fluxo de comunicao completa pode impedir que outras comunicaes ocorram ao mesmo tempo. Isso tambm dificulta a recuperao de erro e retransmisso de dados danificados. A diviso de dados em partes pequenas, e o envio dessas partes a partir da origem, habilita muitas comunicaes diferentes que podem estar intercaladas (multiplexadas) na mesma rede. A segmentao de dados, de acordo com os protocolos de camada de Transporte, fornece os meios para enviar e receber dados quando se executam mltiplas aplicaes concorrentemente em um computador. Sem segmentao, apenas uma aplicao, o vdeo em streaming, por exemplo, seria capaz de receber dados. Voc no poderia receber e-mails, conversar em um programa de mensagens instantneas, ou exibir pginas web em quanto estivesse exibindo o vdeo. Na camada de Transporte, cada conjunto particular de segmentos que flui entre uma aplicao de origem e uma aplicao de destino conhecido com uma conversao. Para identificar cada segmento de dados, a camada de Transporte adiciona ao segmento um cabealho contendo dados binrios. Este cabealho contm campos de bits. So os valores nesses campos que habilitam que diferentes protocolos de camada de Transporte realizem diferentes funes. 4.1.2 Controle das Conversaes As funes principais especificadas por todos os protocolos da camada de Transporte incluem: Segmentao e Reagrupamento - A maioria das redes tem uma limitao da quantidade de dados que podem ser includos em uma nica PDU. A camada de Transporte divide os dados da aplicao em blocos de dados que esto em um tamanho apropriado. No destino, a camada de Transporte reagrupa os dados antes de envi-los aplicao ou servio de destino. Multiplexao de Conversao - Podem haver muitas aplicaes ou servios sendo executados em cada host na rede. Cada uma destas aplicaes ou servios designado a um endereo conhecido como uma porta para que a camada de Transporte possa determinar com qual aplicao ou servio o dado identificado. Alm de usar a informao contida nos cabealhos, para as funes bsicas de segmentao e reagrupamento de dados, alguns protocolos da camada de Transporte fornecem: Conversaes orientadas conexo Entrega Confivel Reconstruo de dados ordenados Controle de Fluxo

4.1.2.1 Estabelecimento de uma Sesso A camada de Transporte pode fornecer essa orientao de conexo atravs da criao de sesses entre as aplicaes. Estas conexes preparam as aplicaes para se comunicarem entre si antes que qualquer dado seja transmitido. Dentro destas sesses, os dados para uma comunicao entre as duas aplicaes podem ser gerenciados de perto. 4.1.2.2 Entrega Confivel Por muitas razes, possvel que um segmento de dados se torne corrompido, ou completamente perdido, quando ele transmitido atravs da rede. A camada de Transporte pode assegurar que todos os segmentos atinjam seu destino tendo o dispositivo de origem para retransmitir qualquer dado que seja perdido. 4.1.2.3 Entrega na Mesma Ordem Devido ao fato de que as redes podem fornecer mltiplas rotas que podem ter diferentes tempos de transmisso, os dados podem chegar na ordem errada. Atravs da numerao e sequenciamento dos segmentos, a camada de Transporte pode assegurar que esses segmentos sejam reagrupados na ordem apropriada. 4.1.2.4 Controle de Fluxo Os hosts de rede tm recursos limitados, como memria e largura de banda. Quando a camada de Transporte est ciente de que esses recursos esto sobrecarregados, alguns protocolos podem solicitar que a aplicao de envio reduza a taxa de fluxo de dados. Isto feito na camada de Transporte regulando a quantidade de dados que a origem transmite como um grupo. O controle de fluxo pode prevenir a perda de segmentos na rede e evitar a necessidade de retransmisso. medida que os protocolos forem discutidos neste captulo, estes servios sero explicados mais detalhadamente. 4.1.3 Suporte de Comunicao Confivel Relembre que a funo principal da camada de Transporte gerenciar os dados da aplicao para as conversaes entre os hosts. No entanto, diferentes aplicaes tm diferentes necessidades para seus dados e, por isso, diferentes protocolos de Transporte tm sido desenvolvidos para satisfazer estas necessidades. O protocolo da camada de Transporte pode implementar um mtodo para assegurar a entrega confivel dos dados. Em termos de rede, confiabilidade significa assegurar que cada segmento de dado enviado pela origem chegue ao seu destino. Na camada de Transporte, as trs operaes bsicas de confiabilidade so: rastreamento de dados transmitidos confirmao de dados recebidos retransmisso de quaisquer dados no confirmados

Isto requer que os processos da camada de Transporte da origem rastreiem todos os segmentos de dados de cada conversao e retransmitam quaisquer dados que realmente no foram confirmados pelo destino. A camada de Transporte do host

receptor tambm deve rastrear o dado medida que ele recebido e confirmar o recebimento do dado. Estes processos de confiabilidade colocam uma sobrecarga adicional sobre os recursos de rede devido confirmao, rastreamento e retransmisso. Para suportar estas operaes de confiabilidade, mais dados de controle so trocados entre os hosts de envio e recepo. Esta informao de controle est contida no cabealho da Camada 4. Isto cria um dilema entre o valor de confiabilidade e a carga que ela coloca sobre a rede. Os desenvolvedores de aplicaes devem escolher que tipo de protocolo de transporte apropriado com base nas necessidades de suas aplicaes. Na camada de Transporte, existem protocolos que especificam mtodos que sejam para entrega confivel, entrega garantida ou entrega de melhor esforo. No contexto de rede, a entrega de melhor esforo referida como no confivel, porque no h confirmao de que o dado foi recebido no seu destino. 4.1.3.1 Determinao da Necessidade de Confiabilidade As aplicaes, tais como as bases de dados, pginas web e e-mail, necessitam de que todos os dados enviados cheguem ao destino em seu estado original, em ordem, para que os dados sejam teis. Quaisquer perdas de dados podem causar uma comunicao corrompida que incompleta ou ilegvel. Portanto, estas aplicaes so projetadas para usar um protocolo da camada de Transporte que implemente confiabilidade. A sobrecarga adicional de rede considerada como uma necessidade para essas aplicaes. Outras aplicaes so mais tolerantes com a perda de pequenas quantidades de dados. Por exemplo, se um ou dois segmentos de um fluxo de vdeo falharem ao chegar, isso cria apenas uma interrupo momentnea no fluxo. Isto pode parecer como uma distoro na imagem, mas pode at mesmo no ser notado pelo usurio. A imposio de sobrecarga para assegurar a confiabilidade para essa aplicao pode reduzir a utilidade da mesma. A imagem do vdeo em streaming seria muito degradada se o dispositivo de destino tivesse de se responsabilizar pelos dados perdidos e pelo retardo no fluxo quando da espera por sua chegada. melhor projetar uma boa imagem possvel no tempo com os segmentos que chegam e abrir mo da confiabilidade. Se a confiabilidade necessria por alguma razo, estas aplicaes podem apresentar solicitaes de verificao de erro e retransmisso.

4.1.4 TCP e UDP Os dois protocolos da camada de Transporte mais comuns da pilha de protocolos TCP/IP so o Protocolo TCP e o Protocolo UDP. Ambos os protocolos gerenciam a comunicao de mltiplas aplicaes. As diferenas entre os dois so as funes especficas que cada protocolo implementa. 4.1.4.1 Protocolo UDP (User Datagram Protocol) O UDP um protocolo simples e sem conexo, descrito na RFC 768. Ele tem a vantagem de fornecer uma entrega de dados de baixa sobrecarga. Os segmentos de comunicao em UDP so chamados datagramas. Estes datagramas so enviados como o "melhor esforo" por este protocolo da camada de Transporte. As aplicaes que usam UDP incluem: (DNS) Vdeo em Streaming Voz Sobre IP (VOIP)

4.1.4.2 Protocolo TCP O TCP um protocolo orientado conexo, descrito na RFC 793. O TCP causa sobrecarga adicional para adicionar funes. As funes adicionais especificadas pelo TCP so as ditas entrega ordenada, entrega confivel e controle de fluxo. Cada segmento TCP tem 20 bytes de overhead no cabealho que encapsula o dado da camada de Aplicao, enquanto que o segmento UDP tem apenas 8 bytes. As aplicaes que usam TCP so: Navegadores web E-mail FTP

4.1.5 Endereamento de Porta 4.1.5.1 Identificao de Conversaes Considere o exemplo anterior de um computador que simultaneamente recebe e envia e-mail, mensagens instantneas, pginas web e chamada VOIP. Os servios baseados em TCP e UDP rastreiam as vrias aplicaes que esto se comunicando. Para diferenciar os segmentos e datagramas para cada aplicao, o TCP e o UDP tm campos de cabealho que podem identificar unicamente essas aplicaes. Estes identificadores nicos so os nmeros de porta. No cabealho de cada segmento ou datagrama, h uma porta de origem e destino. O nmero da porta de origem o nmero para essa comunicao associado aplicao originada no host local. O nmero da porta de origem o nmero para essa comunicao associada aplicao originada no host local. Os nmeros de porta so designados de vrias maneiras, dependendo se a mensagem uma solicitao ou uma resposta. Embora os processos do servidor tenham nmeros de porta estticos designados a eles, os clientes escolhem dinamicamente um nmero de porta para cada conversao. Quando uma aplicao cliente envia uma solicitao aplicao servidor, a porta de destino contida no cabealho o nmero da porta que designado ao servio daemon executado no host remoto. O software cliente deve conhecer qual nmero de porta est associado ao processo servidor no host remoto. Este nmero de porta de destino configurado, seja atravs do padro ou manualmente. Por exemplo, quando uma aplicao de navegador web faz uma solicitao a um servidor web, o navegador usa o TCP nmero de porta 80, a menos que um outro seja especificado. Isso acontece porque a porta 80 TCP a porta padro designada a aplicaes web. Muitas aplicaes comuns tm designaes de porta padro. A porta de origem em um cabealho de segmento ou datagrama de uma solicitao de cliente gerada aleatoriamente. Contanto que ela no entre em conflito com outras portas em uso no sistema, o cliente pode escolher qualquer nmero de porta. Este nmero de porta age com um endereo de retorno para a aplicao que faz a solicitao. A camada de Transporte rastreia esta porta e a aplicao que iniciou a solicitao, de modo que quando uma resposta retornada, ela pode ser encaminhada para a aplicao correta. O nmero de porta da aplicao solicitante usado com o nmero de porta de destino na resposta que volta do servidor. A combinao do nmero de porta da camada de Transporte e do endereo IP da camada de Rede designada ao host identifica exclusivamente um processo particular sendo executado em um dispositivo de host especfico. Esta combinao chamada de soquete. Ocasionalmente, voc pode encontrar os termos nmero de porta e soquete sendo usados alternadamente. No contexto deste curso, o termo soquete se refere apenas combinao nica de endereo IP e nmero de porta. Um par de soquete, que consiste de endereos IP de origem e destino, tambm nico e identifica a conversao entre os dois hosts. Por exemplo, uma solicitao de pgina HTTP sendo enviada a um servidor web (porta 80) sendo executado em um host com um endereo de IPv4 Camada 3 192.168.1.20 seria destinado ao soquete 192.168.1.20:80.

Se o navegador web que faz a solicitao web est sendo executado no host 192.168.100.48 e o nmero Dinmico de porta designado ao navegador web 49152, o soquete para a pgina web seria 192.168.100.48:49152. A Internet Assigned Numbers Authority (IANA) designa nmeros de porta. A IANA um rgo de padres responsvel pela designao de vrios padres de endereamento. Existem diferentes tipos de nmeros de portas: Portas Conhecidas (Nmeros 0 a 1023) - Esses nmeros esto reservados para servios e aplicaes. Eles so comumente usados para aplicaes como o HTTP (servidor web) POP3/SMTP (servidor de e-mail) e Telnet. Atravs da definio destas portas conhecidas para aplicaes de servidor, aplicaes de clientes podem ser programados para solicitar uma conexo com essa porta especfica e seu servio associado. Portas Registradas (Nmeros 1024 a 49151) - Estes nmeros de portas so designados para processos ou aplicaes de usurio. Estes processos so principalmente aplicaes individuais que um usurio escolheu para instalar em vez de aplicaes comuns que receberiam uma Porta Conhecida. Quando no usadas para um recurso de servidor, estas portas tambm podem ser dinamicamente selecionadas por um cliente como sua porta de origem. Portas Dinmicas ou Privadas (Nmeros 49152 a 65535) - Elas so geralmente designadas dinamicamente a aplicaes de cliente quando se inicia uma conexo. No muito comum um cliente se conectar a um servio usando uma Porta Dinmica ou Privada (embora alguns programas de compartilhamento de arquivos peerto-peer o faam). 4.1.5.2 Utilizao do TCP e do UDP Algumas aplicaes podem usar tanto TCP como UDP. Por exemplo, o baixo overhead (sobrecarga) do UDP habilita ao DNS servir a muitas solicitaes de clientes muito rapidamente. As vezes, no entanto, o envio da informao solicitada pode exigir a confiabilidade do TCP. Neste caso, o nmero 53 de porta conhecida usado por ambos os protocolos com este servio. Uma lista atual de nmeros de porta pode ser encontrada em: http://www.iana.org/assignments/port-numbers. As vezes necessrio conhecer quais conexes TCP ativas esto abertas e sendo executadas em um host de rede. O Netstat um utilitrio de rede importante que pode ser usado para verificar essas conexes. O Netstat lista o protocolo em uso, o endereo local e o nmero de porta, o endereo externo, o nmero de porta e o estado da conexo. Conexes TCP inexplicveis podem ser uma grande ameaa de segurana. Isto acontece porque elas podem indicar que algo ou algum est conectado ao host local. Adicionalmente, as conexes TCP desnecessrias podem consumir recursos valiosos do sistema, reduzindo a velocidade de desempenho do host. O Netstat deve ser usado para examinar as conexes abertas em um host quando o desempenho parecer comprometido.

Muitas opes teis esto disponveis para o comando netstat: C:\>netstat /? Exibe estatsticas de protocolo e conexes de rede TCP/IP atuais. NETSTAT [-a] [-b] [-e] [-n] [-o] [-p proto] [-r] [-s] [-v] [interval] -a Exibe todas as conexes e portas de escuta.

-b Exibe o executvel envolvido na criao de cada conexo ou porta de escuta. Em alguns casos, executveis conhecidos hospedam mltiplos componentes independentes, e nesses casos a seqncia de componentes envolvidos na criao da conexo ou porta de escuta listada. Neste caso, o nome do executvel est em [] na parte inferior, na parte superior est o componente por ele chamado, e assim por diante, at chegar ao TCP/IP. Observe que esta opo pode ser vagarosa e falhar a menos que voc possua permisses suficientes. -e -n -o Exibe estatsticas Ethernet. Isso pode ser combinado opo -s. Exibe endereos e nmeros de porta em formato numrico. Exibe a ID do processo proprietrio associado a cada conexo.

-p proto Exibe conexes para o protocolo especificado por proto; proto pode ser TCP, UDP, TCPv6 ou UDPv6 Se usado com a opo s para exibir estatsticas por protocolo, proto pode ser: IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP ou UDPv6. -r Exibe a tabela de roteamento.

-s Exibe as estatsticas por protocolo. Por padro, as estatsticas so exibidas para IP, IPv6, ICMP, ICMPv6, TCP, TCPv6, UDP e UDPv6; a opo -p pode ser usada para especificar um subconjunto do padro. -v Quando usado junto com -b, ir exibir a seqncia de componentes envolvidos na criao da conexo ou porta de escuta para todos os executveis. interval Exibe novamente as estatsticas selecionadas, fazendo uma pausa de segundos entre cada exibio. Pressione CTRL+C para interromper a reexibio de estatsticas. Caso omitido, netstat ir imprimir as informaes de configurao uma vez.

4.1.6 Segmentao e Reagrupamento - Dividir e Conquistar O captulo anterior explicou como as PDUs so construdas para passar os dados de uma aplicao para os vrios protocolos para criar uma PDU que seja ento transmitida no meio. No host de destino, este processo revertido at que os dados possam ser passados at a aplicao. Algumas aplicaes transmitem grandes quantidades de dados - em alguns casos, muitos gigabytes. Seria impraticvel enviar todos estes dados em um segmento muito grande. Nenhum outro trfego de rede poderia ser transmitido enquanto estes dados estivessem sendo enviados. Um segmento muito grande de dados pode levar minutos ou mesmo horas para ser enviado. Alm disso, se houvesse algum erro, o arquivo inteiro seria perdido ou reenviado. Dispositivos de rede no teriam buffers de memria grandes o suficiente para armazenar estes dados enquanto eles fossem transmitidos ou recebidos. O limite varia dependendo da tecnologia de rede e do meio fsico especfico que est sendo usado. Dividir os dados da aplicao em segmentos assegura que os dados sejam transmitidos dentro dos limites do meio e que os dados de diferentes aplicaes possam ser multiplexadas no meio. O TCP e o UDP Lidam com a Segmentao de Maneira Diferente. No TCP, cada cabealho de segmento contm um nmero sequencial. Este nmero sequencial confere as funes da camada de Transporte no host de destino para reagrupar segmentos na ordem em que eles foram transmitidos. Isso assegura que as aplicaes de destino tenham os dados na forma exata pretendida pelo remetente. Embora os servios que usam UDP tambm rastreiem as conversaes entre as aplicaes, eles no esto preocupados com a ordem que a informao foi transmitida, ou na manuteno de uma conexo. No existe nmero sequencial no cabealho UDP. O UDP um esquema mais simples e gera menos overhead do que o TCP, resultando em uma transferncia mais rpida de dados. A informao pode chegar em ordem diferente da qual ela foi transmitida porque diferentes pacotes podem tomar diferentes caminhos atravs da rede. Uma aplicao que usa o UDP precisa tolerar o fato de que os dados podem no chegar na ordem em que foram enviados.

4.2 O Protocolo TCP - Comunicando com Confiabilidade

4.2.1 TCP - Tornando as Conversaes Confiveis A distino principal entre o TCP e o UDP est na confiabilidade. A confiabilidade da comunicao TCP realizada com o uso de sesses orientadas conexo. Antes que um host usando o TCP envie dados para outro host, a camada de Transporte inicia um processo para criar uma conexo com o destino. Esta conexo habilita o rastreamento de uma sesso, ou um fluxo de comunicao entre os hosts. Este processo assegura que cada host est ciente e preparado para a comunicao. Uma conversao TCP completa exige o estabelecimento de uma sesso entre os hosts em ambas as direes. Aps uma sesso ter sido estabelecida, o destino envia confirmaes para a origem para os segmentos que ele recebe. Estas confirmaes formam a base da confiabilidade dentro de uma sesso TCP. medida que a origem recebe uma confirmao, ela sabe que os dados foram entregues com sucesso e pode parar o

rastreamento daqueles dados. Se a origem no recebe uma confirmao dentro de um perodo pr-determinado de tempo, ela retransmite aqueles dados para o destino. Parte do overhead adicional do uso do TCP o trfego de rede gerado por confirmaes e retransmisses. O estabelecimento de sesses cria um overhead na forma de segmentos adicionais sendo trocados. H tambm um overhead adicional nos hosts individuais criado pela necessidade de rastrear quais segmentos esto esperando pela confirmao e pelo processo de retransmisso. Esta confiabilidade alcanada tendo campos no segmento TCP, cada um com uma funo especfica, conforme mostrado na figura. Estes campos sero discutidos mais tarde nesta seo.

4.2.2 Processos TCP em Servidores Conforme discutido anteriormente neste captulo, os processos de aplicaes so executados nos servidores. Estes processos esperam at que um cliente inicie a comunicao com uma solicitao de informao ou outros servios. Cada processo de aplicao sendo executado no servidor configurado para usar um nmero de porta, seja no modo padro ou manualmente atravs de um administrador do sistema. Um servidor individual no pode ter dois servios designados ao mesmo nmero de porta dentro dos mesmos servios da camada de Transporte. Um host executando uma aplicao de servidor web e uma aplicao de transferncia de arquivo no pode ter ambos configurados para usar a mesma porta (por exemplo, a porta TCP 8080). Quando uma aplicao de servidor ativo designada a uma porta especfica, essa porta considerada como estando "aberta" no servidor. Isto significa que a camada de Transporte aceita e processa segmentos endereados quela porta. Qualquer solicitao de cliente que chega endereada ao soquete correto aceita e os dados so transmitidos aplicao do servidor. Podem haver muitas portas simultneas abertas em um servidor, uma para cada aplicao de servidor ativo. comum para um servidor fornecer mais de um servio, como um servidor web e um servidor FTP, ao mesmo tempo. Uma maneira de melhorar a segurana em um servidor restringir o acesso de servidor a apenas essas portas associadas com os servios e as aplicaes que devem ser acessveis para solicitantes autorizados. A figura mostra a alocao tpica de portas de origem e destino em operaes cliente/servidor TCP.

4.2.3 Estabelecimento e Trmino de conexes TCP Quando dois hosts se comunicam usando o TCP, uma conexo estabelecida antes que os dados possam ser trocados. Depois da comunicao ter sido completada, as sesses so fechadas e a conexo encerrada. Os mecanismos de conexo e sesso habilitam a funo de confiabilidade do TCP. Veja a figura para saber as etapas para estabelecer e terminar uma conexo TCP.

O host rastreia cada segmento de dados dentro de uma sesso e troca informao sobre qual dado recebido por cada host usando a informao no cabealho TCP. Cada conexo representa dois fluxos de comunicao, ou sesses. Para estabelecer uma conexo, os hosts realizam um handshake triplo. Bits de controle no cabeaho TCP indicam o progresso e o status da conexo. O handshake triplo: Estabelece que o dispositivo de destino est presente na rede Verifica se o dispositivo de destino tem um servio ativo e est aceitando solicitaes no nmero de porta de destino que o cliente pretende usar para a sesso. Informa o dispositivo de destino que o cliente de origem pretende estabelecer uma sesso de comunicao nessa nmero de porta

Nas conexes TCP, o host que serve como um cliente inicia a sesso para o servidor. Os trs passos no estabelecimento da conexo TCP so: 1. O cliente iniciador envia um segmento contendo um valor sequencial inicial, que serve como uma solicitao ao servidor para comear uma sesso de comunicaes. 2. O servidor responde com um segmento contendo um valor de confirmao igual ao valor sequencial recebido mais 1, mais seu prprio valor sequencial de sincronizao. O valor maior do que o nmero sequencial porque o ACK sempre o prximo Byte ou Octeto esperado. Este valor de confirmao habilita o cliente a submeter resposta de volta ao segmento original que ele enviou ao servidor. 3. O cliente iniciador responde com um valor de confirmao igual ao valor sequencial que ele recebeu mais um. Isso completa o processo de estabelecimento da conexo. Para entender o processo do handshake triplo, importante examinar os vrios valores que os dois hosts trocam. Dentro do cabealho de segmento TCP, existem seis campos de 1 bit que contm a informao de controle usada para gerenciar os processos TCP. Esses campos so: URG - Indicador urgente de campo significativo ACK - Campo significativo de confirmao PSH - funo Push RST - Restabelecer a conexo SYN - Sincronizar nmeros de sequncia FIN - No h mais dados do remetente Estes campos so referidos como flags (flags), porque o valor de um desses campos apenas 1 bit e, portanto, tem apenas dois valores: 1 ou 0. Quando um valor de bit definido como 1, ele indica que a informao de controle est contida no segmento. Com o uso de um processo de quatro etapas, as flags so trocadas para encerrar uma conexo TCP.

4.2.4 Handshake Triplo TCP Usando as entradas Wireshark, voc pode examinar a operao do handshake triplo TCP: 4.2.4.1 Etapa 1 Um cliente TCP inicia o handshake triplo enviando um segmento com a flag de controle SYN (nmero sequencial de sincronia) definido, indicando um valor inicial no campo do nmero de sequncia no cabealho. Este valor inicial para o nmero de sequncia, conhecido como o Nmero de Sequncia Inicial (ISN), escolhido aleatoriamente e usado para iniciar o rastreamento do fluxo de dados do cliente para o servidor para esta sesso. O ISN no cabealho de cada segmento aumentado em um para cada byte de dados enviados do cliente para o servidor medida que a conversao de dados continua. Conforme mostrado na figura, a sada de um analisador de protocolo mostra a flag de controle SYN e o nmero de sequncia relativo. A flag de controle SYN definida e o nmero de sequncia relativo 0. Embora o analisador de protocolo no grfico indique os valores relativos para os nmeros de sequncias e de confirmao, os valores verdadeiros so nmeros binrios de 32 bits. Ns podemos determinar os nmeros reais enviados nos cabealhos do segmento examinando a tela de Pacote de Bytes. Aqui voc pode ver os quatro bytes representados em hexadecimal.

4.2.4.2 Etapa 2 O servidor TCP precisa confirmar o recebimento do segmento SYN do cliente para estabelecer a sesso do cliente para o servidor. Para fazer isso, o servidor envia um segmento de volta para o cliente com a flag ACK indicando que o nmero de

Confirmao significativo. Com esta flag indicada no segmento, o cliente confirma isto como uma confirmao de que o servidor recebeu o SYN do cliente TCP. O valor do campo de nmero de confirmao igual ao nmero de sequncia inicial mais 1. Isto estabelece uma sesso do cliente para o servidor. A flag ACK permanecer definida para o equilbrio da sesso. Relembre que a conversao entre o cliente e o servidor na verdade duas sesses unidirecionais, uma do cliente para o servidor, e outra do servidor para o cliente. Nesta segunda etapa do handshake triplo, o servidor precisa iniciar a resposta do servidor para o cliente. Para iniciar esta sesso, o servidor usa a flag SYN da mesma maneira que o cliente o fez. Ele define a flag de controle SYN no cabealho para estabelecer a sesso do servidor para o cliente. A flag SYN indica que o valor inicial do campo de nmero de sequncia est no cabealho. Este valor ser usado para rastrear o fluxo de dados nesta sesso do servidor de volta para o cliente. Conforme mostrado na figura, a sada do analisador de protocolo mostra que as flags de controle ACK e SYN esto definidas e os nmeros de sequncia relativo e de confirmao so mostrados.

4.2.4.3 Etapa 3 Finalmente, o cliente TCP responde com um segmento contendo um ACK que a resposta para o TCP SYN enviado pelo servidor. No h dado de usurio neste segmento. O valor do campo de nmero de confirmao contm um 1 a mais do que o nmero de sequncia inicial recebido do servidor. J que ambas as sesses esto estabelecidas entre cliente e servidor, todos os segmentos adicionais trocados nesta comunicao tero uma flag ACK definida.

Conforme mostrado na figura, a sada do analisador de protocolo mostra a flag de controle ACK definida e os nmeros de confirmao so mostrados. A segurana pode ser adicionada rede de dados por: Negao de estabelecimento de sesses TCP Apenas permitindo sesses que sejam estabelecidas para servios especficos Apenas permitindo trfego como parte de sesses j estabelecidas

Esta segurana pode ser implementada para todas as sesses TCP ou apenas para as sesses selecionadas.

4.2.5 Encerramento de Sesso TCP Para fechar uma conexo, a flag de fim de comunicao FIN (Finish) no cabealho do segmento precisa ser definida. Para terminar cada sesso TCP unidirecional, um handshake duplo usado, consistindo de um segmento FIN e um segmento ACK. Portanto, para terminar uma conversao nica suportada pelo TCP, quatro trocas so necessrias para finalizar ambas as sesses. Nota: Nesta explicao, os termos cliente e servidor so usados nesta descrio com uma referncia visando a simplicidade, mas o processo de encerramento pode ser iniciado por qualquer um dos dois hosts que completarem a sesso: 1. Quando o cliente no tem mais dados para enviar no fluxo, ele envia um segmento com uma flag FIN definida. 2. O servidor envia uma ACK para confirmar o recebimento do FIN para encerrar a sesso do cliente para o servidor.

3. O servidor envia um FIN para o cliente, para encerrar a sesso do servidor para o cliente. 4. O cliente responde com um ACK para confirmar o FIN do servidor. Quando o cliente final de uma sesso no tem mais dados para transferir, ele define a flag FIN no cabealho de um segmento. A seguir, o servidor ir enviar um segmento normal contendo dados com a flag ACK definida usando o nmero de confirmao, confirmando que todos os bytes de dados foram recebidos. Quando todos os segmentos tiverem sido confirmados, a sesso fechada. A sesso na outra direo fechada usando o mesmo processo. O receptor indica que no h mais dados para enviar definindo uma flag FIN no cabealho de um segmento enviado origem. Uma confirmao de retorno confirma que todos os bytes de dados foram recebidos e que a sesso est, por sua vez, fechada. Conforme mostrado na figura, as flags de controle FIN e ACK so definidas no cabealho do segmento, fechando com isso a sesso HTTP. possvel encerrar a conexo atravs de um handshake triplo. Quando o cliente no tem mais dados para enviar, ele envia um FIN ao servidor. Se o servidor tambm no tem mais dados para enviar, ele pode responder com ambas as flags FIN e ACK definidas, combinando duas etapas em uma. O cliente responde com um ACK.

4.3 Gerenciamento de Sesses TCP

4.3.1 Reagrupamento de Segmentos TCP 4.3.1.1 Refazendo o Sequenciamento de Segmentos na Ordem Transmitida Quando os servios enviam dados usando o TCP, os segmentos podem chegar no seu destino fora de ordem. Para a mensagem original ser entendida pelo receptor, os dados desses segmentos so reagrupados na sua ordem original. Os nmeros de sequncia so designados no cabealho de cada pacote para alcanar essa meta. Durante a instalao de uma sesso, um nmero de sequncia inicial (ISN) definido. Este nmero de sequncia inicial representa o valor de partida para os bytes para esta sesso que ser transmitida para a aplicao receptora. medida que os dados so transmitidos durante a sesso, o nmero de sequncia incrementado pelo nmero de bytes que foram transmitidos. Este rastreamento de bytes de dados habilita a cada segmento ser identificado e reconhecido de forma nica. Segmentos perdidos podem ser identificados. Os nmeros de sequncia do segmento habilitam a confiabilidade, indicando como reagrupar e reordenar segmentos recebidos, conforme mostrado na figura. O processo TCP do receptor coloca os dados de um segmento em um buffer. Os segmentos so colocados na ordem de nmero de sequncia apropriada e passados para a camada de Aplicao quando reagrupados. Quaisquer segmentos que cheguem com nmeros de sequncia no contguos so retidos para processamento posterior. Ento, quando os segmentos com os bytes perdidos chegam, esses segmentos so processados.

4.3.2 Confirmao TCP com Janelamento 4.3.2.1 Confirmao de Recebimento de Segmentos Uma das funes do TCP assegurar que cada segmento atinja o seu destino. Os servios TCP no host de destino confirmam os dados que ele recebeu para a aplicao de origem. O nmero de sequncia do cabealho do segmento e o nmero de confirmao so usados juntamente para confirmar o recebimento dos bytes de dados contidos nos segmentos. O nmero de sequncia o nmero relativo de bytes que foram transmitidos nessa sesso mais 1 (que o nmero do primeiro byte de dado no segmento corrente). O TCP usa o nmero de confirmao em segmentos enviados de volta origem para indicar o prximo byte que o receptor espera receber nessa sesso. Isto chamado de confirmao esperada. A origem informada de que o destino recebeu todos os bytes neste fluxo de dados at, mas no incluindo, o byte indicado pelo nmero de confirmao. Espera-se que o host de envio envie um segmento que use um nmero de sequncia que igual ao nmero de confirmao. Lembre-se, cada conexo na verdade composta por duas sesses unidirecionais. Os nmeros de sequncia e de confirmao esto sendo trocados em ambas as direes. No exemplo da figura, o host da esquerda est enviando dados para o host da direita. Ele envia um segmento contendo 10 bytes de dados para essa sesso e um nmero de sequncia igual a 1 no cabealho. O host receptor da direita recebe o segmento na Camada 4 e determina que o nmero de sequncia 1 e que ele tem 10 bytes de dados. O host ento envia um segmento de volta ao host da esquerda para confirmar o recebimento deste dado. Neste segmento, o host define o nmero de confirmao em 11 para indicar que o prximo byte de dados que ele espera receber nessa sesso o byte nmero 11. Quando o host de envio da esquerda recebe essa confirmao, ele pode agora enviar o prximo segmento contendo dados para essa sesso iniciando com o byte nmero 11. Examinando esse exemplo, se o host de envio tiver que esperar pela confirmao de recebimento de cada 10 bytes, a rede teria muito overhead. Para reduzir o overhead dessas confirmaes, mltiplos segmentos de dados podem ser enviados e confirmados com uma nica mensagem TCP na direo oposta. Este confirmao contm um nmero de confirmao baseado no nmero total de bytes recebidos na sesso. Por exemplo, comeando com um nmero de sequncia de 2000, se 10 segmentos de 1000 bytes cada fossem recebidos, o nmero de confirmao 12001 seria retornado origem. A quantidade de dados que a origem pode transmitir antes que uma confirmao seja recebida chamada de tamanho da janela. O Tamanho de Janela um campo no cabealho TCP que habilita o gerenciamento de dados perdidos e controle de fluxo.

4.3.3 4.3.3 Retransmisso TCP 4.3.3.1 Lidando com a Perda de Segmento No importa quanto uma rede seja bem projetada, a perda de dados ocorrer ocasionalmente. Portanto, o TCP fornece mtodos para gerenciar essas perdas de
segmentos. Entre estes mtodos h um mecanismo que retransmite segmentos com dados no confirmados. Um servio de host de destino usando TCP geralmente reconhece os dados apenas para bytes sequenciais contguos. Se estiver faltando um ou mais segementos, apenas os dados nos segmentos que completam o fluxo sero confirmados. Por exemplo, se os segmentos com nmeros de sequncia de 1500 a 3000 e de 3400 a 3500 fossem recebidos, o nmero de confirmao seria 3001. Isto porque existem segmentos com os nmeros de sequncia de 3001 a 3399 que no foram recebidos. Quando o TCP no host de origem no recebeu uma confirmao depois de um perodo pr-determinado de tempo, ele voltar ao ltimo nmero de confirmao que recebeu e retransmitir os dados a partir daquele ponto para frente. O processo de retransmisso no especificado pela RFC, mas deixado para a implementao especfica do TCP. Para uma implementao de TCP tpica, um host pode transmitir um segmento, colocar uma cpia do segmento numa fila de retransmisso e iniciar uma contagem. Quando a confirmao do dado recebida, o segmento deletado da fila. Se a confirmao no for recebida antes da contagem expirar, o segmento retransmitido.

Os hosts atualmente podem tambm empregar um atributo adicional chamado de Confirmaes Seletivas. Se ambos os hosts suportam Confirmaes Seletivas, possvel para o destino confirmar bytes em segmentos no contguos e o host precisar apenas retransmitir os dados perdidos.

4.3.4 Controle de Congestionamento TCP - Minimizando a Perda de Segmentos 4.3.4.1 Controle de Fluxo O TCP tambm fornece mecanismos para o controle de fluxo. O controle de fluxo ajuda na confiabilidade de transmisses TCP atravs do ajuste da taxa de fluxo de dados efetiva entre os dois servios na sesso. Quando a origem informada de que uma quantidade especificada de dados nos segmentos recebida, ela pode continuar a enviar mais dados para essa sesso. O campo Tamanho de Janela no cabealho TCP especifica a quantidade de dados que podem ser transmitidos antes que uma confirmao precise ser recebida. O tamanho de janela inicial determinado durante a inicializao da sesso atravs do handshake triplo. O mecanismo de feedback do TCP ajusta a taxa efetiva de transmisso de dados at o fluxo mximo que a rede e o dispositivo de destino podem suportar sem perda. O TCP tenta gerenciar a taxa de transmisso de modo que todos os dados sejam recebidos e as retransmisses sejam minimizadas. Veja a figura para uma representao simplificada do tamanho de janela e confirmaes. Neste exemplo, o tamanho de janela inicial para uma sesso TCP representada definido em 3000 bytes. Quando o remetente tiver transmitido 3000 bytes, ele espera por uma confirmao destes bytes antes de transmitir mais segmentos nesta sesso.

Quando o remetente tiver recebido esta confirmao do receptor, o remetente poder transmitir mais 3000 bytes. Durante o atraso no recebimento de uma confirmao, o remetente no enviar quaisquer segmentos adicionais para essa sesso. Em perodos em que a rede est congestionada ou os recursos do host de recebimento esto extenuados, o atraso pode aumentar. medida que este atraso aumenta, a taxa de transmisso efetiva dos dados para esta sesso diminui. A diminuio da velocidade na taxa de dados ajuda a reduzir a conteno de recursos.

4.3.4.2 Reduo do Tamanho de Janela Um outro modo de controlar o fluxo de dados usar tamanhos de janela dinmicos. Quando os recursos da rede so restringidos, o TCP pode reduzir o tamanho de janela para exigir que os segmentos recebidos sejam confirmados mais frequentemente. Isto diminui efetivamente a velocidade da taxa de transmisso porque a origem espera que os dados sejam confirmados mais frequentemente. O host de recebimento envia o valor do tamanho de janela ao remetente para indicar o nmero de bytes que ele est preparado para receber como parte desta sesso. Se o destino precisar diminuir a velocidade da taxa de comunicao por causa de memria de buffer limitada, ele pode enviar um valor de tamanho de janela pequeno para a origem como parte de uma confirmao. Conforme mostrado na figura, se um host de recebimento tem um congestionamento, ele pode responder ao host de envio com um segmento com tamanho de janela reduzido. Neste grfico, h uma perda de um dos segmentos. O receptor

mudou o campo da janela no cabealho TCP de segmentos retornados nesta conversao de 3000 para 1500. Isto levou o remetente a reduzir o tamanho de janela para 1500. Aps perodos de transmisso com nenhuma perda de dados ou restrio de recursos, o receptor comear a aumentar o campo da janela. Isto reduz a sobrecarga na rede porque poucas confirmaes precisam ser enviadas. O tamanho de janela continuar a aumentar at que haja perda de dados, o que levar diminuio novamente. Este aumento e diminuio dinmico no tamanho de janela um processo contnuo no TCP, que determina o tamanho de janela adequado para cada sesso TCP. Em redes altamente eficientes, os tamanhos de janela podem se tornar muito grandes porque os dados no esto sendo perdidos. Nas redes em que a infra-estrutura subjacente pressionada, o tamanho de janela provavelmente permanecer pequeno. Detalhes das vrias caractersticas de gerenciamento de congestionamento do TCP podem ser encontrados na RFC 2581. http://www.ietf.org/rfc/rfc2581.txt

4.4

O Protocolo UDP - Comunicao com Baixo Overhead

4.4.1 UDP - Baixo Overhead versus Confiabilidade O UDP um protocolo simples que fornece as funes bsicas da camada de Transporte. Ele possui overhead muito mais baixo do que o TCP, j que no orientado conexo e no fornece mecanismos de retransmisso, sequenciamento e controle de fluxo sofisticados. Isto no significa que as aplicaes que usam UDP sejam sempre no confiveis. Isto simplesmente significa que estas funes no so fornecidas pelo protocolo da camada de Transporte e devem ser implementadas em outros locais se houver necessidade. Embora a quantidade total de trfego UDP encontrada em uma rede tpica geralmente no seja baixo, os principais protocolos da camada de Aplicao que usam UDP incluem: Domain Name System (DNS) Simple Network Management Protocol (SNMP) Protocolo de Configurao Dinmica de Host (DHCP) Routing Information Protocol (RIP) Trivial File Transfer Protocol (TFTP) Jogos On-line

Algumas aplicaes, como jogos on-line ou VOIP, podem tolerar alguma perda de dados. Se estas aplicaes usarem TCP, elas podem passar por grandes atrasos enquanto o TCP detecta a perda e retransmite dados. Estes atrasos seriam mais prejudiciais para a aplicao do que pequenas perdas de dados. Algumas aplicaes, como o DNS, simplesmente iro tentar novamente a solicitao se no receberem resposta e, portanto, eles no precisaro do TCP para garantir a entrega da mensagem. O baixo overhead do UDP o torna muito desejvel para tais aplicaes.

4.4.2 Reagrupamento de Datagramas UDP Por causa do UDP ser sem conexo, as sesses no so estabelecidas antes que a comunicao ocorra enquanto elas esto com TCP. Diz-se que o UDP baseado em transao. Em outras palavras, quando uma aplicao tem dados para enviar, ele simplesmente envia os dados. Muitas aplicaes que usam o UDP enviam pequenas

quantidades de dados que podem se ajustar a um segmento. No entanto, algumas aplicaes enviaro quantidades maiores de dados que precisam ser divididos em mltiplos segmentos. A PDU UDP referida como um datagrama, embora os termos segmento e datagrama sejam usados algumas vezes de modo alternado para descrever uma PDU da camada de Transporte. Quando mltiplos datagramas so enviados a um destino, eles podem tomar diferentes caminhos e chegar na ordem errada. O UDP no rastreia os nmeros de sequncia da forma que o TCP faz. O UDP no tem um modo para reordenar os datagramas na sua ordem de transmisso. Veja a figura.

Portanto, o UDP simplesmente reagrupa os dados na ordem que eles foram recebidos e os encaminha para a aplicao. Se a sequncia dos dados importante para a aplicao, ele ter que identificar a sequncia apropriada dos dados e determinar como os dados devem ser processados. 4.4.3 Solicitaes UDP e Processos de Servidores Do mesmo modo que com as aplicaes baseadas em TCP, aos aplicaes de servidores baseados em UDP so designados nmeros de porta Conhecida ou Registrada. Quando estas aplicaes ou processos esto sendo executados, eles aceitaro os dados correspondentes ao nmero de porta designado. Quando o UDP recebe um datagrama destinado a uma destas portas, ele encaminha os dados aplicao apropriada com base em seu nmero de porta.

4.4.4 Processos de cliente UDP Do mesmo modo que o TCP, a comunicao cliente/servidor iniciada por uma aplicao cliente que est solicitando dados de um processo servidor. O processo cliente UDP seleciona aleatoriamente um nmero de porta a partir de uma faixa dinmica de nmeros de porta e o usa como a porta de origem para a conversao. A porta de destino ser geralmente o nmero de porta Conhecida ou Registrada designado ao processo do servidor. Nmeros de porta de origem randomizados tambm ajudam na segurana. Se h um padro previsvel para seleo da porta de destino, um intruso pode simular um acesso a um cliente mais facilmente tentando conectar-se ao nmero de porta mais provvel de ser aberto. Por no haver sesso a serem criados com o UDP, to logo os dados esteja pronto para serem enviados e a portas identificadas, o UDP pode formar o datagrama e pass-lo para a camada de Rede para ser endereado e enviado pela rede. Lembre-se, uma vez que o cliente escolheu as portas de origem e destino, o mesmo par de portas usado no cabealho de todos os datagramas da transao. Para dados que retornam para o cliente a partir do servidor, os nmeros de porta de origem e destino no cabealho do datagrama so invertidos.

4.5 Resumo e reviso

A camada de Transporte prov as necessidades da rede de dados atravs de: Diviso de dados recebidos de uma aplicao em segmentos Adio de um cabealho para identificar e gerenciar cada segmento Uso da informao do cabealho para reagrupar os segmentos de volta nos dados da aplicao Transmitir os dados agrupados para a aplicao correta O UDP e o TCP so os protocolos da camada de Transporte mais comuns. Os datagramas UDP e os segmentos TCP tm cabealhos pr-fixados aos dados que incluem o nmero de porta de origem e o nmero de porta de destino. Estes nmeros de porta habilitam os dados a serem redirecionados para a aplicao correta sendo executada no computador de destino. O TCP no passa qualquer dado para a rede at que saiba que o destino est pronto para receb-lo. O TCP ento gerencia o fluxo de dados e reenvia quaisquer segmentos de dados que no so confirmados conforme sejam recebidos no destino. O TCP usa mecanismos de handshake triplo, temporizador e confirmaes, e janelamento dinmico para alcanar estas caractersticas confiveis. Esta confiabilidade, no entanto, impe uma sobrecarga na rede em termos de cabealhos de segmentos muito maior e mais trfego de rede entre a origem e o destino no gerenciamento do transporte de dados. Se os dados da aplicao precisam ser entregues rapidamente pela rede, ou se a largura de banda da rede no suporta a sobrecarga ou overhead de mensagens de controle sendo trocadas entre os sistemas de origem e destino, o UDP ser o protocolo da camada de Transporte preferido pelo programador. Devido ao fato do UDP no rastrear ou confirmar o recebimento de datagramas no destino - ele apenas passa os datagramas recebidos para a camada de Aplicao medida que eles chegam - e no reenvia datagramas perdidos. No entanto, isto no significa necessariamente que a comunicao em si no seja confivel; pode haver mecanismos nos protocolos e servios da camada de Aplicao que processam datagramas perdidos ou com atraso se a aplicao tem estas necessidades. A escolha do protocolo da camada de Transporte feito pelo programador da aplicao para melhor satisfazer as necessidades do usurio. O programador tem em mente que, apesar disso, todas as outras camadas tm um papel nas comunicaes de rede de dados e influenciaro o seu desempenho.