Prévia do material em texto

Capitulo 9 - Camada de Transporte
As redes de dados e a Internet apoiam a rede humana através do fornecimento de comunicação confiável entre pessoas. Com apenas um dispositivo, as pessoas podem usar múltiplas aplicações e serviços como e-mail, a Web e aplicações de envio de mensagem instantânea para enviar mensagens ou recuperar informação. Os dados de cada uma dessas aplicações são empacotados, transportados e entregues à aplicação apropriada no dispositivo de destino. 
Os processos descritos na camada de transporte do modelo OSI aceitam dados da camada de aplicação e os preparam para o endereçamento na camada de rede. Um computador origem se comunica com um computador de destino para decidirem como dividir dados em segmentos, como certificar-se de que nenhum dos segmentos será perdido e como verificar se todos os segmentos chegaram. Quando pensar na camada de transporte, imagine um departamento de expedição que prepara um único pedido de vários pacotes para entrega.
9.1	Protocolos da Camada de Transporte
9.1.1	Transporte de Dados
9.1.1.1	Propósito da Camada de Transporte
A camada de transporte é responsável por estabelecer uma sessão de comunicação temporária entre duas aplicações e fornecer dados entre elas. Uma aplicação gera dados que são enviados de uma aplicação em um host de origem para outro em um host de destino. Isso sem considerar o tipo de host de destino, o tipo de mídia sobre o qual o dado deve viajar, o caminho tomado pelo dado, o congestionamento em um link, ou o tamanho da rede. Como mostra a figura, a camada de transporte é o link entre a camada de aplicação e as camadas inferiores que são responsáveis pela transmissão da rede.
9.1.1.2	Responsabilidades da Camada de Transporte
Rastreamento de Conversações Individuais 
Na camada de transporte, cada conjunto particular de dados que flui entre uma aplicação de origem e uma de destino é conhecido com uma conversação (Figura 1). Um host pode ter várias aplicações que se comunicam através da rede ao mesmo tempo. Cada uma dessas aplicações se comunica com uma ou mais aplicações em um ou mais hosts remotos. É responsabilidade da camada de transporte manter e monitorar essas várias conversações.
Segmentação de Dados e Remontagem de Segmentos 
Os dados devem ser preparados para serem enviados através do meio físico em pedaços gerenciáveis. A maioria das redes tem uma limitação da quantidade de dados que pode ser incluída em um único pacote. Os protocolos da camada de transporte têm serviços que segmentam os dados de aplicações em blocos de um tamanho apropriado (Figura 2). Isso inclui o encapsulamento necessário em cada pedaço dos dados. Um cabeçalho, usado para remontagem, é adicionado em cada bloco de dados. Esse cabeçalho é usado para rastrear o fluxo de dados.
No destino, a camada de transporte deve ser capaz de reagrupar os pedaços de dados em um fluxo completo de dados que seja útil para a camada de aplicação. Os protocolos na camada de transporte descrevem como a informação do cabeçalho da camada de transporte é usada para reagrupar os pedaços de dados em fluxos a serem passados para a camada de aplicação.
Identificação das Aplicações 
Para passar os fluxos de dados para as aplicações apropriadas, a camada de transporte deve identificar a aplicação alvo (Figura 3). Para realizar isso, a camada de transporte atribui um identificador à aplicação, chamado de número de porta. A cada processo de software que precise acessar a rede é designado um número de porta único para aquele host.
9.1.1.3	Multiplexação das Conversações
Enviar alguns tipos de dados (por exemplo, um streaming de vídeo) em uma rede, como um fluxo de comunicação completo, pode usar toda a largura de banda disponível. Então, isso impedirá que outras conversações ocorram ao mesmo tempo. Isso também dificultaria a recuperação de erro e retransmissão dos dados danificados. 
A figura mostra que segmentar os dados em blocos menores permite que muitas comunicações diferentes, de muitos usuários diferentes, sejam intercaladas (multiplexadas) na mesma rede. 
Para identificar cada segmento de dados, a camada de transporte adiciona ao segmento um cabeçalho contendo dados binários organizados em campos. São os valores nesses campos que permitem que os vários protocolos da camada de transporte realizem diferentes funções no gerenciamento da comunicação de dados.
9.1.1.4	Confiabilidade da Camada de Transporte
A camada de transporte também é responsável por gerenciar requisitos de confiabilidade de uma conversação. Diferentes aplicações têm diferentes necessidades de confiabilidade de transporte. 
O IP está preocupado apenas com a estrutura, endereçamento e roteamento de pacotes. O IP não especifica como a entrega ou o transporte de pacotes ocorrem. Os protocolos de transporte especificam como transferir mensagens entre hosts. O TCP/IP oferece dois protocolos da camada de transporte, o protocolo TCP e o protocolo UDP, como mostrado na figura. O IP usa esses protocolos de transporte para permitir que hosts se comuniquem e transfiram dados.
O TCP é considerado um protocolo de camada de transporte confiável, completo, que garante que todos os dados cheguem ao destino. Entretanto, isso requer campos adicionais no cabeçalho TCP, o que aumenta o tamanho do pacote e também aumenta o atraso. Ao contrário, o UDP é um protocolo mais simples da camada de transporte que não fornece confiabilidade. Portanto, possui menos campos e é mais rápido que o TCP.
9.1.1.5	TCP
O transporte TCP é análogo a enviar pacotes que são rastreados da origem ao destino. Se um pedido pelo correio estiver dividido em vários pacotes, um cliente poderá verificar on-line a sequência de recebimento do pedido. 
Com o TCP, existem três operações básicas de confiabilidade:
· Numeração e rastreamento dos segmentos de dados transmitidos para um host específico de uma aplicação específica
· Confirmar dados recebidos
· A retransmissão de dados não confirmados após um determinado período de tempo
Clique em Reproduzir na figura para ver como segmentos TCP e as confirmações são transmitidos do remetente ao destinatário.
9.1.1.6	UDP
Quando as funções de confiabilidade do TCP proporcionam uma comunicação mais eficiente entre aplicações, elas incorrem também em uma sobrecarga adicional e possíveis atrasos na transmissão. Isso cria um dilema entre o valor da confiabilidade e a carga que ela coloca sobre a rede. Acrescentar sobrecarga para garantir a confiabilidade de algumas aplicações pode reduzir a utilidade delas, o que pode ser prejudicial. Nesses casos, o UDP é o melhor protocolo de transporte. 
O UDP oferece as funções básicas fornecendo segmentos de dados apropriados entre as aplicações, com um pouco de sobrecarga e verificação de dados. O UDP é conhecido como um protocolo de entrega de melhor esforço. No contexto de redes, a entrega de melhor esforço é referida como não confiável, porque não há confirmação de que o dado é recebido no seu destino. Com o UDP, não há processo de camada de transporte que informe ao remetente se a entrega foi bem-sucedida.
O UDP é semelhante a colocar uma carta normal, não registrada, no correio. O remetente da carta não tem conhecimento se o destinatário está disponível para receber a carta. Nem a agência de correio é responsável por rastrear a carta ou informar ao remetente se ela não chegar ao destino final. 
Clique em Reproduzir na figura para ver uma animação dos segmentos UDP que estão sendo transmitidos do remetente ao destinatário. 
9.1.1.7	O protocolo de Camada de Transporte Certo para a Aplicação Certa
Para algumas aplicações, os segmentos devem chegar em uma sequência específica para serem processados com sucesso. Para outras aplicações, todos os dados devem ser completamente recebidos antes de serem considerados úteis. Em ambos os casos, o TCP é usado como protocolo de transporte. Os desenvolvedores de aplicações devem escolher que tipo de protocolo de transporte é apropriado com base nas necessidades de suas aplicações. 
Por exemplo, aplicações como bancos de dados, navegadorese clientes de e-mail exigem que todos os dados enviados cheguem ao destino em seu estado original. Quaisquer perdas de dados podem causar uma comunicação corrompida que é incompleta ou ilegível. Essas aplicações são projetadas para usar o TCP. 
Em outros casos, uma aplicação pode tolerar alguma perda de dados durante a transmissão pela rede, mas os atrasos na transmissão são inaceitáveis. O UDP é a melhor escolha para essas aplicações porque menos sobrecarga de rede é necessária. O UDP é preferível para aplicações como a transmissão de áudio e vídeo ao vivo, e Voz sobre IP (VoIP). Confirmações e retransmissões causariam atraso na entrega. 
Por exemplo, se um ou dois segmentos de uma transmissão de vídeo ao vivo não conseguir chegar, isso criará apenas uma interrupção momentânea na transmissão. Isso pode aparecer como uma distorção na imagem ou no som, mas pode não ser notado pelo usuário. Se o dispositivo de destino considerasse os dados perdidos, a transmissão poderia atrasar, enquanto aguardasse as retransmissões, causando, portanto, grandes perdas de áudio e vídeo. Nesse caso, é melhor fornecer a melhor experiência de mídia com os segmentos recebidos e descartar a confiabilidade.
Observação: as aplicações que transmitem áudio e vídeo armazenado usam TCP. Por exemplo, se sua rede, repentinamente, não comportar a largura de banda necessária para a transmissão de um filme sob demanda, a aplicação interrompe a reprodução. Durante essa interrupção, você deverá ver uma mensagem de “buffering...” , enquanto o TCP age para restabelecer a transmissão. Assim que todos os segmentos estiverem em ordem e um nível mínimo de largura de banda for recuperado, sua sessão TCP é retomada e o filme voltará a ser reproduzido. 
9.1.2.	Visão Geral de TCP e UDP
9.1.2.1	Recursos TCP
Para entender as diferenças entre o TCP e o UDP, é importante entender como cada protocolo implementa recursos específicos de confiabilidade e como rastreiam conversações. Além de permitir as funções básicas de segmentação e reagrupamento de dados, o TCP, como mostrado na figura, também oferece outros serviços.
Estabelecimento de Sessão 
O TCP é um protocolo orientado a conexão. Um protocolo orientado a conexão é o que negocia e estabelece uma conexão (ou sessão) permanente entre os dispositivos origem e destino antes de encaminhar o tráfego. Com o estabelecimento da sessão, os dispositivos negociam o volume de tráfego esperado que pode ser encaminhado em determinado momento e os dados de comunicação entre os dois podem ser gerenciados atentamente. 
Entrega confiável 
Em termos de rede, confiabilidade significa assegurar que cada segmento enviado pelo dispositivo origem chegue a seu destino. Por muitos motivos, um segmento pode se corromper ou se perder completamente ao ser transmitido através da rede. 
Entrega na mesma ordem 
Como as redes podem oferecer várias rotas com taxas de transmissão distintas, os dados podem chegar na ordem errada. Por meio da numeração e do sequenciamento dos segmentos, o protocolo TCP pode assegurar que esses segmentos sejam reagrupados na ordem apropriada. 
Controle de fluxo 
Os hosts de rede têm recursos limitados, como memória e capacidade de processamento. Quando percebe que esses recursos estão sobrecarregados, o TCP pode requisitar que a aplicação emissora reduza a taxa de fluxo de dados. Isso é feito pelo TCP, que regula a quantidade de dados que a origem transmite. O controle de fluxo pode prevenir a necessidade de retransmissão de dados, quando os recursos dos hosts que receberão esses dados estiverem sobrecarregados. 
Para obter mais informações sobre TCP, leia RFC.
9.1.2.2	Cabeçalho TCP
O TCP é um protocolo stateful. Um protocolo stateful é um protocolo que mantém o controle do estado da sessão de conversação. Para manter o controle do estado de uma sessão, o TCP registra quais informações ele enviou e quais informações foram confirmadas. A sessão stateful começa com o estabelecimento da sessão e termina quando ela é fechada com o encerramento de sessão.
Como mostra a figura, cada segmento TCP tem 20 bytes de sobrecarga no cabeçalho que encapsula os dados da camada de aplicação:
· Porta de Origem (16 bits) e Porta de Destino (16 bits) - Usadas para identificar a aplicação.
· O Número de sequência (32 bits) - Usado somente para a remontagem dos dados.
· Número de confirmação (32 bits) - Indica que os dados foram recebidos e o próximo byte esperado da origem.
· Comprimento do cabeçalho (4 bits) - Conhecido como "deslocamento dos dados". Mostra o comprimento do cabeçalho do segmento TCP.
· Reservado (6 bits) - Esse campo é reservado para o futuro.
· Bits de controle (6 bits) - Inclui códigos de bit, ou flags, que indicam a finalidade e a função do segmento TCP.
· Tamanho da janela (16 bits) - Indica o número de bytes que podem ser aceitos de uma vez.
· Checksum (16 bits) - Usado para a verificação de erros do cabeçalho e dos dados do segmento.
· Urgente (16 bits) - Indica se os dados são urgentes.
9.1.2.3	Recursos UDP
O UDP (User Datagram Protocol) é considerado um protocolo de transporte de melhor esforço. O UDP é um protocolo de transporte leve que oferece a mesma segmentação de dados e remontagem que o TCP, mas sem a confiabilidade e o controle de fluxo do TCP. O UDP é um protocolo simples, normalmente descrito nos termos do que ele não faz em comparação ao TCP. 
Os recursos do UDP estão descritos na figura. 
Para obter mais informações sobre o UDP, leia a RFC.
9.1.2.4	Cabeçalho UDP
O UDP é um protocolo stateless, que significa que nem o cliente, nem o servidor são obrigados a manter o controle do estado da sessão de comunicação. Se a confiabilidade for necessária ao usar o UDP como protocolo de transporte, ela deve ser tratada pela aplicação.
Um dos requisitos mais importantes para transmitir vídeo ao vivo e voz sobre a rede é que os dados continuem fluindo rapidamente. Vídeo ao vivo e aplicações de voz podem tolerar alguma perda de dados com efeito mínimo ou sem visibilidade e são perfeitos para o UDP.
Os pedaços de comunicação em UDP são chamados datagramas, como mostra a figura. Esses datagramas são enviados com o melhor esforço pelo protocolo da camada de transporte. O UDP tem uma sobrecarga baixa de 8 bytes.
9.1.2.5	Várias Conversações Separadas
A camada de transporte deve separar e gerenciar várias comunicações com as diferentes necessidades de requisitos de transporte. Usuários esperam ser capazes de enviar e receber e-mails e mensagens instantâneas, visualizar sites e realizar chamadas de telefone VoIP simultaneamente. Cada uma dessas aplicações envia e recebe dados através da rede ao mesmo tempo, apesar das exigências de confiabilidade diferentes. Além disso, os dados da chamada telefônica não são direcionados ao navegador e o texto de uma mensagem instantânea não aparece em um e-mail.
O TCP e o UDP gerenciam essas várias conversações simultâneas usando campos de cabeçalho que podem identificar unicamente esses aplicações. Estes identificadores únicos são os números de porta.
9.1.2.6	Números de Porta
O número da porta de origem é associado à aplicação originária no host local. O número da porta de destino é associado à aplicação de destino no host remoto.
Porta de Origem
O número da porta de origem é gerado dinamicamente pelo dispositivo de envio para identificar uma conversação entre dois dispositivos. Este processo permite que várias conversações ocorram simultaneamente. É comum que um dispositivo envie várias solicitações de serviço HTTP para um servidor Web ao mesmo tempo. Cada conversa HTTP separada é rastreada com base em portas origem.
Porta de Destino
O cliente preenche um número de porta de destino no segmento para informar ao servidor de destino qual serviço está sendo solicitado, como mostra a figura. Por exemplo, quando um cliente especifica a porta 80 na porta de destino, o servidor que receber a mensagem sabe que os serviços Web são solicitados. Um servidor pode oferecer mais de um serviço simultaneamente como serviços Web na porta 80, ao mesmo tempo que oferece o estabelecimentode uma conexão FTP na porta 21.
9.1.2.7	Pares de Sockets
As portas origem e destino são colocadas no segmento. Os segmentos são encapsulados em um pacote IP. O pacote IP contém o endereço IP de origem e destino. A combinação do endereço IP de origem e o número de porta de origem, ou do endereço IP de destino e o número de porta de destino é conhecida como um socket. O socket é usado para identificar o servidor e o serviço que está sendo solicitado pelo cliente. Um socket do cliente pode ser assim, com 1099 representando o número da porta de origem: 192.168.1.5:1099
O socket em um servidor Web pode ser: 192.168.1.7:80
Juntos, esses dois sockets se combinam para formar um par de sockets: 192.168.1.5:1099, 192.168.1.7:80
Os sockets permitem que vários processos em execução em um cliente se diferenciem uns dos outros, e várias conexões com um processo no servidor sejam diferentes umas das outras.
Este número de porta age como um endereço de retorno para a aplicação que faz a solicitação. A camada de transporte rastreia essa porta e a aplicação que iniciou a solicitação, de modo que quando uma resposta é retornada, ela pode ser encaminhada para a aplicação correta.
9.1.2.8	Grupos de Números de Porta
A Internet Assigned Numbers Authority (IANA) é a padronizadora responsável pela atribuição de vários endereçamentos padrão, incluindo números de porta. Existem diferentes tipos de números de portas, como mostra a Figura 1:
· Portas bem conhecidas (Números de 0 a 1023) - Esses números estão reservados para serviços e aplicações. Eles são comumente usados para aplicações como navegadores Web, clientes de e-mail e clientes de acesso remoto. Ao definir essas portas bem conhecidas para aplicações em servidores, as aplicações em clientes podem ser programadas para solicitar uma conexão com essa porta específica e seu serviço associado.
· Portas registradas (Números de 1024 a 49151) - Estes números de portas são designados pela IANA para uma entidade solicitante usar com aplicações ou processos específicos. Esses processos são principalmente aplicações individuais que um usuário escolheu para instalar, em vez de aplicações comuns que receberiam uma porta muito conhecida. Por exemplo, a Cisco registrou a porta 1985 para o processo do protocolo HSRP.
· Portas Dinâmicas ou Privadas (Números 49152 a 65535) - Também conhecidas como portas efêmeras, elas são geralmente designadas dinamicamente pelo sistema operacional do cliente, quando a conexão para um serviço se inicia. Em seguida, a porta dinâmica é usada para identificar a aplicação do cliente durante a conversação.
Observação: alguns sistemas operacionais de cliente podem usar números de portas registradas, em vez de números de portas dinâmicas para atribuir portas origem.
A Figura 2 mostra alguns números de porta muito conhecidos e as aplicações associadas a eles. Algumas aplicações podem usar tanto TCP quanto UDP. Por exemplo, o DNS usa o protocolo UDP quando os clientes enviam requisições a um servidor DNS. Contudo, a comunicação entre dois servidores DNS sempre usa TCP.
Clique aqui para exibir a lista completa de números de porta e as aplicações associadas em um site da IANA.
9.1.2.9	O Comando netstat
Conexões TCP desconhecidas podem ser uma ameaça de segurança maior. Elas podem indicar que algo ou alguém está conectado ao host local. Às vezes é necessário conhecer quais conexões TCP ativas estão abertas e sendo executadas em um host de rede. O netstat é um utilitário de rede importante que pode ser usado para verificar essas conexões. Como mostra a figura, digite o comando netstat para listar os protocolos em uso, o endereço local e os números de porta, os endereços remotos e os números de porta além do estado da conexão.
Por padrão, o comando netstat tentará resolver os endereços IP para os nomes de domínio e os números de porta para aplicações bem conhecidas. A opção -n pode ser usada para exibir endereços IP e números de porta em sua forma numérica.
9.2.	TCP e UDP
9.2.1	Processo de Comunicação TCP
9.2.1.1	Processos em Servidores TCP
Cada processo de aplicação executado no servidor é configurado para usar um número de porta, seja o padrão ou manualmente configurado pelo administrador do sistema. Um servidor individual não pode ter dois serviços designados ao mesmo número de porta dentro dos mesmos serviços de camada de transporte.
Por exemplo, um host executando uma aplicação de servidor Web e uma aplicação de transferência de arquivos não pode ter ambas configuradas para usar a mesma porta (por exemplo, a porta TCP 80). Um aplicação ativa em um servidor atribuída a uma porta específica é considerado aberta, o que significa que a camada de transporte aceita e processa segmentos endereçados para aquela porta. Qualquer solicitação de cliente que chega endereçada ao socket correto é aceita e os dados são transmitidos à aplicação do servidor. Pode haver muitas portas abertas ao mesmo tempo em um servidor, uma para cada aplicação de servidor ativa.
Consulte as figuras de 1 a 5 para exibir a alocação típica de portas origem e destino em operações cliente/servidor TCP.
9.2.1.2	Estabelecimento de Conexão TCP
Em algumas culturas, quando duas pessoas se encontram, elas costumam se cumprimentar apertando as mãos. O ato de apertar a mão é entendido por ambas as partes como um sinal de saudação amigável. As conexões de rede são semelhantes. Nas conexões TCP, o host estabelece a conexão com o servidor.
Uma conexão TCP é estabelecida em três etapas:
Etapa 1 - O cliente iniciador requisita uma sessão de comunicação cliente-servidor com o servidor.
Etapa 2 - O servidor confirma a sessão de comunicação cliente-servidor e requisita uma sessão de comunicação servidor-cliente.
Etapa 3 - O cliente iniciador confirma a sessão de comunicação servidor-cliente.
Na figura, clique nos botões 1 a 3 para ver o estabelecimento da conexão TCP.
9.2.1.3	Encerramento de Sessão TCP
Para fechar uma conexão, o flag de controle Finish (FIN) deve ser ligado no cabeçalho do segmento. Para terminar cada sessão TCP de uma via, um handshake duplo, consistindo de um segmento FIN e um segmento ACK (Acknowledgment) é usado. Portanto, para terminar uma conversação única permitida pelo TCP, quatro trocas são necessárias para finalizar ambas as sessões.
Na figura, clique nos botões 1 a 4 para ver o encerramento da conexão TCP.
Observação: Nesta explicação, os termos cliente e servidor são usados como uma referência visando a simplicidade, mas o processo de encerramento pode ser iniciado por qualquer um dos dois hosts que participam da sessão:
Etapa 1 - Quando o cliente não tem mais dados para enviar no fluxo, ele envia um segmento com um flag FIN ligado.
Etapa 2 - O servidor envia um ACK para confirmar o recebimento do FIN para encerrar a sessão do cliente com o servidor.
Etapa 3 - O servidor envia um FIN para o cliente, para encerrar a sessão do servidor com o cliente.
Etapa 4 - O cliente responde com um ACK para confirmar o FIN do servidor.
Quando todos os segmentos tiverem sido reconhecidos, a sessão é encerrada.
9.2.1.4	Análise do Handshake Triplo do TCP
Hosts rastreiam cada segmento de dados dentro de uma sessão e trocam informações sobre quais dados são recebidos usando as informações no cabeçalho TCP. O TCP é um protocolo full-duplex, no qual cada conexão representa dois fluxos de comunicação unidirecional, ou sessões. Para estabelecer uma conexão, os hosts realizam um handshake triplo (three-way handshake). Bits de controle no cabeçalho TCP indicam o progresso e o status da conexão.
O handshake triplo (three-way handshake):
· Estabelece que o dispositivo de destino está presente na rede
· Verifica se o dispositivo de destino tem um serviço ativo e está aceitando requisições no número de porta de destino que o cliente iniciador pretende usar.
· Informa ao dispositivo de destino que o cliente de origem pretende estabelecer uma sessão de comunicação nesse número de porta
Depois de a comunicação ter sido completada, as sessões são fechadas e a conexão é encerrada. Os mecanismos de conexãoe sessão possibilitam a função de confiabilidade do TCP.
Os seis bits no campo Bits de Controle do cabeçalho do segmento TCP são também conhecidos como flags. Um flag é um bit que pode ser ligado ou desligado. Clique no campo Bits de Controle na figura para ver os seis flags. Nós já falamos sobre SYN, ACK, e FIN. O flag RST é usado para reiniciar uma conexão, quando ocorre um erro ou o limite de tempo é esgotado. Clique aqui para saber mais sobre os flags PSH e URG.
9.2	TCP e UDP.
9.2.2	Confiabilidade e Controle de Fluxo
9.2.2.1	Confiabilidade do TCP – Entrega Ordenada
Os segmentos TCP podem chegar ao seu destino fora de ordem. Para a mensagem original ser entendida pelo receptor, os dados nesses segmentos são reagrupados na sua ordem original. Os números de sequência são atribuídos no cabeçalho de cada pacote para alcançar esse objetivo. O número de sequência representa o primeiro byte de dados do segmento TCP.
Durante a estabelecimento de uma sessão, um número de sequência inicial (ISN) é definido. Esse ISN representa o valor inicial dos bytes dessa sessão que é transmitida para a aplicação receptora. À medida que os dados são transmitidos durante a sessão, número de sequência é incrementado do número de bytes que foram transmitidos. Esse rastreamento dos bytes de dados permite que cada segmento seja identificado e confirmado de forma única. Segmentos perdidos podem então, ser identificados.
Observação: o ISN não começa em um, na verdade, ele começa em um número aleatório. Isso é para impedir determinados tipos de ataques maliciosos. Para simplificar os exemplos desse capítulo, usaremos um ISN de 1.
Os números de sequência do segmento indicam como remontar e reordenar os segmentos recebidos, como mostrado na figura.
O processo TCP receptor coloca os dados de um segmento em um buffer receptor. Os segmentos são colocados na ordem sequencial apropriada e passados para a camada de aplicação quando remontados. Qualquer segmento que chegue com números de sequência fora de ordem são retidos para processamento posterior. Por isso, quando os segmentos com os bytes que faltavam chegam, esses segmentos são processados.
9.2.2.2	Demonstração em Vídeo - Números de Sequência e Confirmações
Uma das funções do TCP é assegurar que cada segmento atinja seu destino. Os serviços TCP no host de destino confirmam os dados que ele recebeu pela aplicação de origem.
Clique em Reproduzir na figura para assistir a uma aula sobre números de sequência TCP e confirmações.
Clique aqui para baixar a documentação de suporte de vídeo.
Clique aqui para ler a transcrição do vídeo.
9.2.2.3	Demonstração em vídeo - Perda de Dados e Retransmissão
Não importa o quanto uma rede seja bem projetada, a perda de dados ocorrerá ocasionalmente, portanto, o TCP fornece métodos para gerenciar essas perdas de segmentos. Entre esses métodos há um mecanismo que retransmite segmentos dos dados não confirmados.
Na figura, reproduza o vídeo e clique no link para baixar o arquivo PDF. O vídeo e o arquivo PDF examinam a perda de dados e a retransmissão TCP.
Clique em Reproduzir na figura para assistir a uma aula sobre retransmissão TCP.
Clique aqui para baixar a documentação de suporte de vídeo.
Clique aqui para ler a transcrição do vídeo.
Observação: os hosts atualmente podem também empregar um recurso adicional chamado de confirmação seletiva (SACK). Se ambos os hosts forem compatíveis com SACK, é possível que o destino confirme bytes em segmentos não contíguos e o host precisará apenas retransmitir os dados perdidos.
9.2.2.4	Controle de Fluxo TCP – Tamanho da Janela e Confirmações
O TCP também fornece mecanismos de controle de fluxo, a quantidade de dados que o destino pode receber e processar confiavelmente. O controle de fluxo ajuda a manter a confiabilidade da transmissão TCP definindo a taxa de fluxo de dados entre a origem e o destino em uma determinada sessão. Para realizar isso, o cabeçalho TCP inclui um campo de 16 bits chamado de tamanho da janela.
A figura mostra um exemplo de tamanho da janela e confirmações. O tamanho da janela é número de bytes que o dispositivo de destino de uma sessão TCP pode aceitar e processar de uma vez. Neste exemplo, o tamanho da janela inicial do PC B para a sessão TCP é 10.000 bytes. No caso do primeiro byte ser número 1, o último byte que PC A pode enviar sem receber uma confirmação é o byte 10.000. Isso é conhecido como janela de envio do PC A. O tamanho da janela é incluído em cada segmento TCP de maneira que o destino possa alterar o tamanho da janela a qualquer momento, dependendo da disponibilidade de buffer.
Observação: na figura, a origem transmite 1.460 bytes de dados em cada segmento TCP. Isto é conhecido como o MSS (Maximum Segment Size -Tamanho máximo de segmento).
O tamanho da janela inicial é determinado quando a sessão é estabelecida durante o handshake triplo. O dispositivo de origem deve limitar a quantidade de bytes enviados ao dispositivo de destino com base no tamanho da janela de destino. Somente depois que o dispositivo de origem receber uma confirmação de que os bytes foram recebidos, ele poderá continuar a enviar mais dados para a sessão. Normalmente, o destino não esperará que todos os bytes que a sua janela comporta sejam recebidos para responder confirmando. À medida que os bytes forem recebidos e processados, o destino enviará confirmações para informar à origem que pode continuar a enviar bytes adicionais.
Normalmente, PC B não esperará que os 10.000 bytes sejam recebidos para enviar uma confirmação. Isso significa que PC A pode ajustar sua janela de envio à medida que recebe confirmações do PC B. Como mostrado na figura, quando PC A recebe uma confirmação com o número de confirmação 2.921, a janela de envio do PC A acrescentará outros 10.000 bytes (o tamanho da janela atual de PC B) até 12.920. PC A agora pode continuar a enviar até 10.000 bytes para PC B contanto que o envio não ultrapasse os 12.920 da nova janela de envio.
O processo de envio de confirmações pelo destino enquanto processa os bytes recebidos, e o ajuste contínuo da janela de envio da origem é conhecido como janelas deslizantes.
Se a disponibilidade do espaço de buffer do destino diminui, ele pode reduzir o tamanho da sua janela para informar à origem que reduza o número de bytes que ela deveria enviar sem receber uma confirmação.
Observação: os dispositivos normalmente usam o protocolo de janelas móveis. Com janelas móveis, o destinatário não espera chegar ao número de bytes no tamanho da janela antes de enviar uma confirmação. O receptor envia geralmente uma confirmação após cada dois segmentos que recebe. O número de segmentos recebidos antes de ser confirmado pode variar. A vantagem de janelas móveis é que permite que o emissor transmita continuamente segmentos, desde que o receptor esteja reconhecendo segmentos anteriores. Os detalhes das janelas móveis estão fora do escopo deste curso.
9.2.2.5	Controle de Fluxo TCP - Prevenção de Congestionamento
Quando ocorre um congestionamento em uma rede, isso resulta em pacotes sendo descartados pelo roteador sobrecarregado. Quando pacotes contendo segmentos TCP não chegam ao seu destino, eles não são confirmados. Ao determinar a taxa na qual os segmentos TCP são enviados, mas não confirmados, a origem pode pressupor um certo nível de congestionamento da rede.
Sempre que ocorrer um congestionamento, ocorrerá a retransmissão de segmentos TCP perdidos por parte da origem. Se a retransmissão não for devidamente controlada, a retransmissão adicional dos segmentos TCP pode agravar o congestionamento. Não só novos pacotes com segmentos TCP são introduzidos na rede, como também o efeito de feedback dos segmentos retransmitidos que foram perdidos aumentarão o congestionamento. Para evitar e controlar o congestionamento, o TCP emprega alguns mecanismos para lidar com o congestionamento, temporizadores e algoritmos.
Se a origem determina que os segmentos TCP não são confirmados ou não são confirmados em tempo hábil, isso pode reduzir o número de bytes enviados antes do recebimentode uma confirmação. Observe que é a origem que está reduzindo o número de bytes não confirmados que envia e não o tamanho da janela determinado pelo destino.
Observação: a explicação dos atuais mecanismos para lidar com congestionamentos, temporizadores e algoritmos está fora da abrangência desse curso.
9.2.3.	Comunicação UDP
9.2.3.1	Baixa Sobrecarga do UDP Versus Confiabilidade
O UDP é um protocolo simples que fornece as funções básicas da camada de transporte. Ele tem uma sobrecarga muito mais baixa que o TCP, porque não é orientado a conexão e não oferece retransmissão, sequenciamento e mecanismos de controle de fluxo sofisticados que fornecem confiabilidade.
Isso não significa que as aplicações que usam o UDP sejam sempre não confiáveis, nem significa que o UDP é um protocolo inferior. Isso simplesmente significa que essas funções não são fornecidas pelo protocolo da camada de transporte e devem ser implementadas em outros locais, se houver necessidade.
A baixa sobrecarga do UDP o torna muito interessante para protocolos que efetuam transações simples de requisição e resposta. Por exemplo, usar TCP para o DHCP geraria tráfego de rede desnecessário. Se existir um problema com uma requisição ou uma resposta, o dispositivo simplesmente envia a requisição outra vez, se nenhuma resposta for recebida.
9.2.3.2	Remontagem do Datagrama UDP
Como ocorre com segmentos TCP, quando múltiplos datagramas UDP são enviados a um destino, eles geralmente tomam caminhos diferentes e chegam na ordem errada. O UDP não rastreia os números de sequência da forma que o TCP faz. O UDP não tem como reordernar os datagramas na sua ordem de transmissão, como mostrado na figura.
Portanto, o UDP simplesmente remonta os dados na ordem que eles foram recebidos e os encaminha para a aplicação. Se a sequência de dados for importante para a aplicação, a aplicação deverá identificar a sequência apropriada e determinar como os dados devem ser processados.
9.2.3.3	Processos em Servidores e Requisições UDP
Do mesmo modo que aplicações baseadas em TCP, as aplicações de servidor baseadas em UDP recebem números de portas bem conhecidas ou registradas, como mostrado na figura. Quando as aplicações ou processos estão sendo executados, eles aceitarão os dados correspondentes ao número de porta atribuído. Quando o UDP recebe um datagrama destinado a uma destas portas, ele encaminha os dados à aplicação apropriada com base em seu número de porta.
Observação: o servidor RADIUS (Remote Authentication Dial-in User Service) exibido na figura fornece serviços de autenticação, autorização e auditoria para gerenciar o acesso de usuários. O funcionamento do RADIUS está fora da abrangência deste curso.
9.2.3.4	Processos em Clientes UDP
Assim como o TCP, a comunicação cliente servidor é iniciada por uma aplicação cliente que requisita dados de um processo em um servidor. O processo no cliente UDP seleciona dinamicamente um número de porta a partir de uma faixa de números de portas e a usa como a porta de origem para a conversa. A porta de destino será geralmente o número de porta muito conhecida ou registrada atribuído ao processo no servidor.
Depois que o cliente escolheu as portas de origem e de destino, o mesmo par de portas é usado no cabeçalho de todos os datagramas usados na transação. Para dados que retornam para o cliente vindos do servidor, os números da porta de origem e de destino no cabeçalho do datagrama são invertidos.
Clique nas Figuras 1 até 5 para ver detalhes dos processos nos clientes UDP.
9.2.4	TCP ou UDP
9.2.4.1	Aplicações que usam TCP
O TCP é um excelente exemplo de como as diferentes camadas da suíte de protocolos TCP/IP têm funções específicas. O TCP executa todas as tarefas associadas com a divisão do fluxo de dados em segmentos, fornecendo confiabilidade, controlando o fluxo de dados e reordenando os segmentos. O TCP libera a aplicação da obrigação de gerenciar todas essas tarefas. Aplicações como as mostradas na figura, podem simplesmente enviar o fluxo de dados à camada de transporte e usar os serviços TCP.
9.2.4.2	Aplicações que usam UDP
Há três tipos de aplicações que são mais adequadas para o UDP:
· Aplicações de vídeo ao vivo e multimídia - podem tolerar alguma perda de dados, mas exigem pouco ou nenhum atraso. Os exemplos incluem VoIP e transmissões de vídeo ao vivo.
· Aplicações simples de requisição e resposta - aplicações com transações simples em que o host envia uma requisição e pode ou não receber uma resposta. Os exemplos incluem DNS e DHCP.
· Aplicações que lidam elas mesmas com a confiabilidade - Comunicações unidirecionais onde o controle de fluxo, detecção de erro, confirmações, e recuperação de erros não são necessárias ou podem ser executadas pela aplicação. Os exemplos incluem SNMP e TFTP.
Embora por padrão DNS e SNMP usem UDP, ambos podem usar TCP. DNS usará TCP se a requisição DNS ou resposta DNS estiver acima de 512 bytes, como quando uma resposta DNS inclui um alto número de resoluções de nome. Da mesma forma, em algumas situações o administrador de redes pode querer configurar o SNMP para usar o TCP.
Capítulo 9: RESUMO - Camada de Transporte
A camada de transporte fornece serviços relacionados aos transportes por:
· Divisão de dados recebidos de uma aplicação em segmentos
· Adição de um cabeçalho para identificar e gerenciar cada segmento
· Uso da informação do cabeçalho para remontar os segmentos de volta em dados da aplicação
· Transmitir os dados agrupados para a aplicação correta
O UDP e o TCP são os protocolos comuns da camada de transporte.
Os datagramas UDP e os segmentos TCP têm cabeçalhos adicionados antes dos dados que incluem o número da porta de origem e o número da porta de destino. Estes números de porta permitem que os dados sejam redirecionados para a aplicação correta que está sendo executada no computador de destino.
O TCP não passa qualquer dado para a rede até que saiba que o destino está pronto para recebê-lo. O TCP então gerencia o fluxo de dados e reenvia quaisquer segmentos de dados que não tenham sido reconhecidos como tendo sido recebidos no destino. O TCP usa mecanismos de handshake, temporizadores, mensagens de confirmação e de janelamento dinâmico para alcançar confiabilidade. O processo de confiabilidade, no entanto, impõe uma sobrecarga na rede em termos de maiores cabeçalhos de segmentos e mais tráfego de rede entre a origem e o destino.
Se os dados da aplicação precisam ser entregues rapidamente pela rede ou se a largura de banda da rede não suportar a sobrecarga de mensagens de controle sendo trocadas entre os sistemas de origem e destino, o UDP será o protocolo de camada de transporte preferido pelo programador. O UDP não oferece nenhum dos recursos de confiabilidade do TCP. No entanto, isso não significa necessariamente que a comunicação em si não seja confiável; pode haver mecanismos nos protocolos e serviços da camada de aplicação que processam datagramas perdidos ou com atraso se a aplicação tem essas necessidades.
O desenvolvedor da aplicação decide que protocolo de camada de transporte melhor atende aos requisitos da aplicação. É importante lembrar que todas as outras camadas têm um papel nas comunicações de rede de dados e influenciam o desempenho.