Camada de transporte

Bem-vindo à Camada de Transporte!

A camada de transporte é onde, como o nome indica, os dados são transportados de um host para outro. É aqui que sua rede realmente se move! A camada de transporte usa dois protocolos: TCP e UDP. Pense no TCP como recebendo uma carta registrada pelo correio. Você tem que assinar antes que a transportadora de correio lhe dê. Isso retarda um pouco o processo, mas o remetente sabe com certeza que você recebeu a carta e quando a recebeu. UDP é mais como uma carta regular e carimbada. Ele chega em sua caixa de correio e, se isso acontecer, provavelmente é destinado a você, mas pode realmente ser para alguém que não mora lá. Além disso, ele pode não chegar em sua caixa de correio em tudo. O remetente não pode ter certeza de que você o recebeu. No entanto, há momentos em que UDP, como uma carta carimbada, é o protocolo que é necessário. Este tópico mergulha em como TCP e UDP funcionam na camada de transporte. Mais tarde neste módulo existem vários vídeos para ajudá-lo a entender esses processos.

Título do módulo: Camada de transporte

Objetivo do módulo: Comparar as operações de protocolos de camada de transporte no suporte da comunicação de ponta a ponta.

Título do Tópico

Objetivo do Tópico

Transporte de dados

Explicar a finalidade da camada de transporte no gerenciamento do transporte de dados em comunicação de ponta a ponta.

Visão geral do TCP

Explicar as características do TCP.

Visão Geral do UDP

Explicar as características da UDP.

Números de porta

Explicar como TCP e UDP usam números de porta.

Processo de comunicação TCP

Explicar como o estabelecimento e encerramento da sessão TCP processa Facilitar uma comunicação fiável.

Confiabilidade e controle de fluxo

Explicar como as unidades de dados do protocolo TCP são transmitidas e reconhecidas para garantia de entrega.

Comunicação UDP

Comparar as operações dos protocolos da camada de transporte no suporte comunicação de ponta a ponta.

Transporte de Dados

14.1.1

Propósito da Camada de Transporte

Os programas da camada de aplicação geram dados que devem ser trocados entre os hosts de origem e de destino. A camada de transporte é responsável pela comunicação lógica entre aplicativos executados em hosts diferentes. Isso pode incluir serviços como o estabelecimento de uma sessão temporária entre dois hosts e a transmissão confiável de informações para um aplicativo.

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 pela rede.

A camada de transporte não tem conhecimento do tipo de host de destino, o tipo de mídia pela qual os dados devem percorrer, o caminho percorrido pelos dados, o congestionamento em um link ou o tamanho da rede.

A camada de transporte inclui dois protocolos:

Protocolo TCP (Transmission Control Protocol)
Protocolo UDP (User Datagram Protocol)

14.1.2

Responsabilidades da Camada de Transporte

A camada de transporte tem muitas responsabilidades.

Rastreamento de Conversações Individuais

Na camada de transporte, cada conjunto de dados que flui entre um aplicativo de origem e um aplicativo de destino é conhecido como conversa e é rastreado separadamente. É responsabilidade da camada de transporte manter e monitorar essas várias conversações.

Como ilustrado na figura, um host pode ter vários aplicativos que estão se comunicando pela rede simultaneamente.

A maioria das redes tem uma limitação da quantidade de dados que pode ser incluída em um único pacote. Portanto, os dados devem ser divididos em partes gerenciáveis.

Segmentação de Dados e Remontagem de Segmentos

É responsabilidade da camada de transporte dividir os dados do aplicativo em blocos de tamanho adequado. Dependendo do protocolo de camada de transporte usado, os blocos de camada de transporte são chamados de segmentos ou datagramas. A figura ilustra a camada de transporte usando blocos diferentes para cada conversa.

A camada de transporte divide os dados em blocos menores (ou seja, segmentos ou datagramas) que são mais fáceis de gerenciar e transportar.

Adicionar Informações de Cabeçalho

O protocolo da camada de transporte também adiciona informações de cabeçalho contendo dados binários organizados em vários campos a cada bloco de dados. 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.

Por exemplo, as informações de cabeçalho são usadas pelo host de recebimento para remontar os blocos de dados em um fluxo de dados completo para o programa de camada de aplicativo de recebimento.

A camada de transporte garante que, mesmo com vários aplicativos em execução em um dispositivo, todos os aplicativos recebam os dados corretos.

Identificação das Aplicações

A camada de transporte deve separar e gerenciar várias comunicações com as diferentes necessidades de requisitos de transporte. Para passar fluxos de dados para os aplicativos adequados, a camada de transporte identifica o aplicativo de destino usando um identificador chamado número da porta. Conforme ilustrado na figura, cada processo de software que precisa acessar a rede recebe um número de porta exclusivo para esse host.

Multiplexação das Conversas

O envio de alguns tipos de dados (por exemplo, um vídeo de streaming) através de uma rede, como um fluxo de comunicação completo, pode consumir toda a largura de banda disponível. Isso impediria que outras conversas de comunicação ocorressem ao mesmo tempo. Isso também dificultaria a recuperação de erro e retransmissão dos dados danificados.

Como mostrado na figura, a camada de transporte usa segmentação e multiplexação para permitir que diferentes conversas de comunicação sejam intercaladas na mesma rede.

A verificação de erros pode ser realizada nos dados do segmento, para determinar se o segmento foi alterado durante a transmissão.

Protocolo TCP (Transmission Control Protocol)

O IP se preocupa apenas com a estrutura, o endereçamento e o roteamento de pacotes, do remetente original ao destino final. A IP não é responsável por garantir a entrega ou determinar se uma conexão entre o remetente e o destinatário precisa ser estabelecida.

O TCP é considerado um protocolo de camada de transporte confiável, completo, que garante que todos os dados cheguem ao destino. O TCP inclui campos que garantem a entrega dos dados do aplicativo. Esses campos exigem processamento adicional pelos hosts de envio e recebimento.

Nota: O TCP divide os dados em segmentos.

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.

O TCP fornece confiabilidade e controle de fluxo usando estas operações básicas:

Número e rastreamento de segmentos de dados transmitidos para um host específico a partir de um aplicativo específico;
Confirmar dados recebidos;
Retransmitir todos os dados não confirmados após um determinado período de tempo
Dados de sequência que podem chegar em ordem errada
Enviar dados a uma taxa eficiente que seja aceitável pelo receptor.

Para manter o estado de uma conversa e rastrear as informações, o TCP deve primeiro estabelecer uma conexão entre o remetente e o receptor. É por isso que o TCP é conhecido como um protocolo orientado a conexão.

Protocolo UDP (User Datagram Protocol)

O UDP é um protocolo de camada de transporte mais simples do que o TCP. Ele não fornece confiabilidade e controle de fluxo, o que significa que requer menos campos de cabeçalho. Como o remetente e os processos UDP receptor não precisam gerenciar confiabilidade e controle de fluxo, isso significa que datagramas UDP podem ser processados mais rápido do que segmentos TCP. O UDP fornece as funções básicas para fornecer datagramas entre os aplicativos apropriados, com muito pouca sobrecarga e verificação de dados.

Nota: O UDP divide os dados em datagramas que também são chamados de segmentos.

UDP é um protocolo sem conexão. Como o UDP não fornece confiabilidade ou controle de fluxo, ele não requer uma conexão estabelecida. Como o UDP não controla informações enviadas ou recebidas entre o cliente e o servidor, o UDP também é conhecido como um protocolo sem estado.

UDP também é conhecido como um protocolo de entrega de melhor esforço porque não há confirmação de que os dados são recebidos no destino. Com o UDP, não há processo de camada de transporte que informe ao remetente se a entrega foi bem-sucedida.

O UDP é como colocar uma carta regular, 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.

Protocolo UDP (User Datagram Protocol)

Nota: O UDP divide os dados em datagramas que também são chamados de segmentos.

Visão geral do TCP

14.2.1

Recursos TCP

No tópico anterior, você aprendeu que TCP e UDP são os dois protocolos de camada de transporte. Este tópico fornece mais detalhes sobre o que o TCP faz e quando é uma boa idéia usá-lo em vez de UDP.

Para entender as diferenças entre TCP e UDP, é importante entender como cada protocolo implementa recursos específicos de confiabilidade e como cada protocolo rastreia conversas.

Além de suportar as funções básicas de segmentação e remontagem de dados, o TCP também fornece os seguintes serviços:

Estabelece uma sessão - O TCP é um protocolo orientado à conexão que negocia e estabelece uma conexão (ou sessão) permanente entre os dispositivos de origem e de destino antes de encaminhar qualquer 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.
Garante a entrega confiável - Por várias razões, é possível que um segmento seja corrompido ou perdido completamente, pois é transmitido pela rede. O TCP garante que cada segmento enviado pela fonte chegue ao destino.
Fornece entrega no mesmo pedido - Como as redes podem fornecer várias rotas que podem ter taxas de transmissão diferentes, os dados podem chegar na ordem errada. Ao numerar e sequenciar os segmentos, o TCP garante que os segmentos sejam remontados na ordem correta.
Suporta controle de fluxo - os hosts de rede têm recursos limitados (ou seja, memória e poder 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. Para isso, o TCP regula o volume de dados transmitido pelo dispositivo origem. O controle de fluxo pode impedir a necessidade de retransmissão dos dados quando os recursos do host receptor estão sobrecarregados.

Para obter mais informações sobre o TCP, procure o RFC 793 na Internet.

14.2.2

Cabeçalho TCP

TCP é um protocolo stateful, o que significa que ele controla o estado da sessão de comunicaçã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 com estado começa com o estabelecimento da sessão e termina com o encerramento da sessão.

Um segmento TCP adiciona 20 bytes (ou seja, 160 bits) de sobrecarga ao encapsular os dados da camada de aplicativo. A figura mostra os campos em um cabeçalho TCP.

Campos de cabeçalho TCP

A tabela identifica e descreve os dez campos em um cabeçalho TCP.

Campo de cabeçalho TCP

Descrição

Porta de origem

Um campo de 16 bits usado para identificar o aplicativo de origem por número de porta.

Porta de destino

Um campo de 16 bits usado para identificar o aplicativo de destino por porta número.

Número sequencial

Um campo de 32 bits usado para fins de remontagem de dados.

Número de Confirmação

Um campo de 32 bits usado para indicar que os dados foram recebidos e o próximo byte esperado da fonte.

Comprimento do cabeçalho

Um campo de 4 bits conhecido como 'offset' de datas' que indica o comprimento do cabeçalho do segmento TCP.

Reservado

Um campo de 6 bits que é reservado para uso futuro.

Bits de controle

Um campo de 6 bits que inclui códigos de bits, ou sinalizadores, que indicam a finalidade e função do segmento TCP.

Tamanho da janela

Um campo de 16 bits usado para indicar o número de bytes que podem ser aceitos de uma só vez.

Checksum

Um campo de 16 bits usado para verificação de erros do cabeçalho e dos dados do segmento.

Urgente

Um campo de 16 bits usado para indicar se os dados contidos são urgentes.

14.2.4

Aplicações que usam TCP

O TCP é um bom exemplo de como as diferentes camadas do conjunto de protocolos TCP / IP têm funções específicas. O TCP lida com todas as tarefas associadas à divisão do fluxo de dados em segmentos, fornecendo confiabilidade, controlando o fluxo de dados e reordenando 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.

mostra as setas apontando ambas as direções de HTTP, FTP, SMTP e SSH para TCP e, em seguida, de TCP para IP

Campos de cabeçalho TCP

A tabela identifica e descreve os dez campos em um cabeçalho TCP.

Campo de cabeçalho TCP

Descrição

Porta de origem

Um campo de 16 bits usado para identificar o aplicativo de origem por número de porta.

Porta de destino

Um campo de 16 bits usado para identificar o aplicativo de destino por porta número.

Número sequencial

Um campo de 32 bits usado para fins de remontagem de dados.

Número de Confirmação

Um campo de 32 bits usado para indicar que os dados foram recebidos e o próximo byte esperado da fonte.

Comprimento do cabeçalho

Um campo de 4 bits conhecido como 'offset' de datas' que indica o comprimento do cabeçalho do segmento TCP.

Reservado

Um campo de 6 bits que é reservado para uso futuro.

Bits de controle

Um campo de 6 bits que inclui códigos de bits, ou sinalizadores, que indicam a finalidade e função do segmento TCP.

Tamanho da janela

Um campo de 16 bits usado para indicar o número de bytes que podem ser aceitos de uma só vez.

Checksum

Um campo de 16 bits usado para verificação de erros do cabeçalho e dos dados do segmento.

Urgente

Um campo de 16 bits usado para indicar se os dados contidos são urgentes.

14.2.4

Aplicações que usam TCP

mostra as setas apontando ambas as direções de HTTP, FTP, SMTP e SSH para TCP e, em seguida, de TCP para IP

Campos de Cabeçalho UDP

A tabela identifica e descreve os quatro campos em um cabeçalho UDP.

Campo de Cabeçalho UDP

Descrição

Porta de origem

Um campo de 16 bits usado para identificar o aplicativo de origem por número de porta.

Porta de destino

Um campo de 16 bits usado para identificar o aplicativo de destino por porta número.

Tamanho

Um campo de 16 bits que indica o comprimento do cabeçalho do datagrama UDP.

Checksum

Um campo de 16 bits usado para verificação de erros do cabeçalho e dos dados do datagrama.

14.3.4

Aplicações que usam UDP

Há três tipos de aplicações que são mais adequadas para o UDP:

Aplicativos de vídeo e multimídia ao vivo - Esses aplicativos podem tolerar a perda de dados, mas requerem pouco ou nenhum atraso. Os exemplos incluem VoIP e transmissão de vídeo ao vivo.
Solicitações simples e aplicativos de resposta - aplicativos com transações simples em que um host envia uma solicitação e pode ou não receber uma resposta. Os exemplos incluem DNS e DHCP.
Aplicativos que lidam com a confiabilidade - Comunicações unidirecionais em que o controle de fluxo, a detecção de erros, as confirmações e a recuperação de erros não são necessários ou podem ser gerenciados pelo aplicativo. Os exemplos incluem SNMP e TFTP.

A figura identifica aplicativos que exigem UDP.

Embora por padrão DNS e SNMP usem UDP, ambos podem usar TCP. O DNS usará o TCP se a solicitação ou resposta de DNS for maior que 512 bytes, como quando uma resposta de DNS inclui muitas resoluções de nome. Da mesma forma, em algumas situações o administrador de redes pode querer configurar o SNMP para usar o TCP.

Números de porta

14.4.1

Várias comunicações separadas

Como você aprendeu, existem algumas situações em que o TCP é o protocolo certo para o trabalho e outras situações em que o UDP deve ser usado. Independentemente do tipo de dados que estão sendo transportados, tanto o TCP quanto o UDP usam números de porta.

Os protocolos de camada de transporte TCP e UDP usam números de porta para gerenciar várias conversas simultâneas. Conforme mostrado na figura, os campos de cabeçalho TCP e UDP identificam um número de porta do aplicativo de origem e destino.

O número da porta de origem está associado ao aplicativo de origem no host local, enquanto o número da porta de destino está associado ao aplicativo de destino no host remoto.

Por exemplo, suponha que um host está iniciando uma solicitação de página da Web a partir de um servidor Web. Quando o host inicia a solicitação de página da Web, o número da porta de origem é gerado dinamicamente pelo host para identificar exclusivamente a conversa. Cada solicitação gerada por um host usará um número de porta de origem criado dinamicamente diferente. Este processo permite que várias conversações ocorram simultaneamente.

Na solicitação, o número da porta de destino é o que identifica o tipo de serviço que está sendo solicitado do servidor Web de destino. 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, enquanto oferece o estabelecimento de conexão FTP (File Transfer Protocol) na porta 21.

14.4.2

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.

No exemplo na figura, o PC está solicitando simultaneamente serviços FTP e Web do servidor de destino.

No exemplo, a solicitação FTP gerada pelo PC inclui os endereços MAC da Camada 2 e os endereços IP da Camada 3. A solicitação também identifica o número da porta de origem 1305 (ou seja, gerado dinamicamente pelo host) e a porta de destino, identificando os serviços de FTP na porta 21. O host também solicitou uma página da Web do servidor usando os mesmos endereços de Camada 2 e Camada 3. No entanto, ele está usando o número da porta de origem 1099 (ou seja, gerado dinamicamente pelo host) e a porta de destino identificando o serviço Web na porta 80.

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 da 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.

14.4.3

Grupos de Números de Porta

A Internet Assigned Numbers Authority (IANA) é a organização de padrões responsável por atribuir vários padrões de endereçamento, incluindo os números de porta de 16 bits. Os 16 bits usados para identificar os números de porta de origem e destino fornecem um intervalo de portas de 0 a 65535.

A IANA dividiu a gama de números nos três grupos de portos seguintes.

Grupo de Portas

Intervalo de números

Descrição

Portas Comuns

0 a 1.023

Estes números de porta são reservados para serviços comuns ou populares e aplicativos como navegadores da web, clientes de e-mail e acesso remoto clientes.
Portas bem conhecidas definidas para aplicativos comuns de servidor permite para identificar facilmente o serviço associado necessário.

Portas registradas

1.024 a 49.151

Esses números de porta são atribuídos pela IANA a uma entidade solicitante para usar com processos ou aplicativos específicos.
Esses processos são principalmente aplicativos individuais que um usuário optou por instalar, em vez de aplicativos comuns que receber um número de porta bem conhecido.
Por exemplo, a Cisco registrou a porta 1812 para seu servidor RADIUS processo de autenticação.

Particular e/ou portas dinâmicas

49.152 a 65.535

Essas portas também são conhecidas como portas efêmeras.
O sistema operacional do cliente geralmente atribui números de porta dinamicamente quando uma conexão a um serviço é iniciada.
A porta dinâmica é então usada para identificar o aplicativo cliente durante a comunicação.

Observação: Alguns sistemas operacionais clientes podem usar números de porta registrados em vez de números de porta dinâmicos para atribuir portas de origem.

A tabela exibe alguns números de porta conhecidos comuns e seus aplicativos associados.

Número de Portas Comuns

Número da Porta

Protocolo

Aplicação

TCP

Protocolo de transferência de arquivos (FTP) - Dados

TCP

Protocolo de transferência de arquivos (FTP) - Controle

TCP

Secure Shell (SSH)

TCP

Telnet

TCP

Protocolo SMTP

UDP, TCP

Protocolo DNS

UDP

Protocolo de Configuração Dinâmica de Host (DHCP) - Servidor

UDP

Protocolo de configuração dinâmica de host - cliente

UDP

Protocolo de Transferência Trivial de Arquivo (TFTP)

TCP

Protocolo HTTP

110

TCP

Protocolo POP3 (Post Office Protocol - Protocolo de E-mail)

143

TCP

Protocolo IMAP

161

UDP

Protocolo de Gerenciamento Simples de Rede (SNMP)

443

TCP

HTTPS (Secure Hypertext Transfer Protocol - Protocolo de Transferência de Hipertexto Seguro)

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.

Pesquise no site da IANA o registro de portas para visualizar a lista completa de números de portas e aplicativos associados.

14.4.4

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 mostrado abaixo, digite o comando netstat para listar os protocolos em uso, o endereço local e os números de porta, o endereço externo e os números de porta e o estado da conexão.

Por padrão, o comando netstat tentará resolver endereços IP para nomes de domínio e números de porta para aplicativos conhecidos. A-n opção pode ser usada para exibir endereços IP e números de porta em sua forma numérica.

Processo de Comunicação TCP

14.5.1

Processos em Servidores TCP

Você já conhece os fundamentos do TCP. Compreender a função dos números de porta irá ajudá-lo a compreender os detalhes do processo de comunicação TCP. Neste tópico, você também aprenderá sobre os processos de handshake de três vias e terminação de sessão TCP.

Cada processo de aplicativo em execução em um servidor está configurado para usar um número de porta. O número da porta é atribuído automaticamente ou configurado manualmente por um administrador do sistema.

Um servidor individual não pode ter dois serviços atribuídos ao mesmo número de porta dentro dos mesmos serviços de camada de transporte. Por exemplo, um host executando um aplicativo de servidor web e um aplicativo de transferência de arquivos não pode ter os dois configurados para usar a mesma porta, como a porta TCP 80.

Um aplicativo de servidor ativo atribuído a uma porta específica é considerado aberto, o que significa que a camada de transporte aceita e processa os segmentos endereçados a essa porta. Qualquer solicitação de cliente que chega endereçada ao soquete 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.

Estabelecimento de Conexão TCP

Em algumas culturas, quando duas pessoas se encontram, elas costumam se cumprimentar apertando as mãos. Ambas as partes entendem o ato de apertar as mãos como um sinal para uma saudação amigável. As conexões de rede são semelhantes. Nas conexões TCP, o cliente host estabelece a conexão com o servidor usando o processo de handshake de três vias.

Etapa 1. SYN

O cliente iniciador requisita uma sessão de comunicação cliente-servidor com o servidor.

PCA inicia um handshake de três vias enviando um segmento syn para PCB.

Etapa 2. ACK e SYN

O servidor confirma a sessão de comunicação cliente-servidor e requisita uma sessão de comunicação de servidor-cliente.

Etapa 3. ACK

O cliente iniciador confirma a sessão de comunicação de servidor-cliente.

O handshake de três vias valida se o host de destino está disponível para comunicação. Neste exemplo, o host A validou que o host B está disponível.

Encerramento da Sessão

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. O cliente ou o servidor podem iniciar o encerramento.

No exemplo, os termos cliente e servidor são usados como referência para simplificar, mas dois hosts que possuem uma sessão aberta podem iniciar o processo de finalização.

Etapa 1. FIN

Quando o cliente não tem mais dados para enviar no fluxo, ele envia um segmento com um flag FIN ligado.

Etapa 2. ACK

O servidor envia ACK para confirmar o recebimento de FIN para encerrar a sessão do cliente com o servidor.

Etapa 3. FIN

O servidor envia um FIN ao cliente para encerrar a sessão do servidor-para-cliente.

Etapa 4. ACK

O cliente responde com um ACK para reconhecer o FIN do servidor.

Análise do Handshake Triplo do TCP

Os hosts mantêm o estado, rastreiam cada segmento de dados em 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, em que cada conexão representa duas sessões de comunicação unidirecional. Para estabelecer uma conexão, os hosts realizam um handshake triplo (three-way handshake). Conforme mostrado na figura, os bits de controle no cabeçalho TCP indicam o progresso e o status da conexão.

Estas são as funções do handshake de três vias:

Estabelece que o dispositivo de destino está presente na rede.
Ele verifica se o dispositivo de destino possui um serviço ativo e está aceitando solicitações no número da porta de destino que o cliente inicial pretende usar.
Ele informa ao dispositivo de destino que o cliente de origem pretende estabelecer uma sessão de comunicação nesse número de porta.

Após a conclusão da comunicação, as sessões são fechadas e a conexão é encerrada. Os mecanismos de conexão e sessão ativam a função de confiabilidade do TCP.

mostra os campos de cabeçalho do segmento tcp com o campo de bits de controle de 6 bits destacado

Campo de bits de controle

Os seis bits no campo Bits de Controle do cabeçalho do segmento TCP são também conhecidos como flags. Uma flag (sinalizador, bandeira) é um bit que é definido como ligado (1) ou desligado (0).

Os seis bits de controle sinalizadores são os seguintes:

URG - Campo de ponteiro urgente significativo.
ACK - Indicador de confirmação usado no estabelecimento de conexão e encerramento de sessão.
PSH - Função Push.
RST - Redefina a conexão quando ocorrer um erro ou tempo limite.
SYN - Sincronizar números de sequência usados no estabelecimento de conexão.
FIN - Não há mais dados do remetente e usados no encerramento da sessão.

Pesquise na Internet para saber mais sobre as bandeiras PSH e URG.

Confiabilidade e controle de fluxo

14.6.1

Confiabilidade do TCP - Entrega garantida e solicitada

A razão pela qual o TCP é o melhor protocolo para alguns aplicativos é porque, ao contrário do UDP, ele reenvia pacotes descartados e números de pacotes para indicar sua ordem correta antes da entrega. O TCP também pode ajudar a manter o fluxo de pacotes para que os dispositivos não fiquem sobrecarregados. Este tópico aborda esses recursos do TCP em detalhes.

Pode haver momentos em que os segmentos TCP não chegam ao seu destino. Outras vezes, os segmentos TCP podem chegar fora de ordem. Para que a mensagem original seja entendida pelo destinatário, todos os dados devem ser recebidos e os dados nesses segmentos devem ser remontados na 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 o estabelecimento de uma sessão, um número de sequência inicial (ISN) é definido. Este ISN representa o valor inicial dos bytes que são transmitidos ao aplicativo receptor. À 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.

O ISN não começa em um, mas é efetivamente 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.

mostra que, embora os segmentos possam tomar rotas diferentes e chegar fora de ordem no destino, o TCP tem a capacidade de reordenar os segmentos

Os Segmentos TCP São Reordenados no Destino

O processo TCP receptor coloca os dados de um segmento em um buffer receptor. Os segmentos são então colocados na ordem de sequência correta e passados para a camada de aplicativo 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.

Confiabilidade do TCP - perda de dados e retransmissão

Não importa o quão bem projetada uma rede é, a perda de dados ocasionalmente ocorre. O TCP fornece métodos de gerenciamento dessas perdas de segmento. Entre esses métodos há um mecanismo que retransmite segmentos dos dados não confirmados.

O número de sequência (SEQ) e o número de confirmação (ACK) são usados juntamente para confirmar o recebimento dos bytes de dados contidos nos segmentos. O número SEQ identifica o primeiro byte de dados no segmento que está sendo transmitido. O TCP usa o número de confirmação (ACK) enviado de volta à origem para indicar o próximo byte que o destino espera receber. Isto é chamado de confirmação antecipatória.

Antes de melhorias posteriores, o TCP só podia reconhecer o próximo byte esperado. Por exemplo, na figura, usando números de segmento para simplicidade, o host A envia os segmentos 1 a 10 para o host B. Se todos os segmentos chegarem, exceto os segmentos 3 e 4, o host B responderia com confirmação especificando que o próximo segmento esperado é o segmento 3. O Host A não tem idéia se outros segmentos chegaram ou não. O host A, portanto, reenviaria os segmentos 3 a 10. Se todos os segmentos reenviados chegarem com sucesso, os segmentos 5 a 10 seriam duplicados. Isso pode levar a atrasos, congestionamentos e ineficiências.

mostra PCA enviando 10 segmentos para PCB, mas os segmentos 3 e 4 não chegam. Assim, começando com o segmento 3, a PCA reende os segmentos 3 a 10, embora o PCB necessitasse apenas dos segmentos 3 e 4

Hoje em dia, os sistemas operacionais de host utilizam um recurso TCP opcional chamado reconhecimento seletivo (SACK), negociado durante o handshake de três vias. Se ambos os hosts suportarem SACK, o receptor pode reconhecer explicitamente quais segmentos (bytes) foram recebidos, incluindo quaisquer segmentos descontínuos. O host de envio, portanto, só precisa retransmitir os dados ausentes. Por exemplo, na próxima figura, novamente usando números de segmento para simplicidade, o host A envia segmentos 1 a 10 para o host B. Se todos os segmentos chegarem, exceto os segmentos 3 e 4, o host B pode reconhecer que recebeu segmentos 1 e 2 (ACK 3) e reconhecer seletivamente os segmentos 5 a 10 (SACK 5-10). O host A só precisaria reenviar os segmentos 3 e 4.

Nota: O TCP normalmente envia ACKs para todos os outros pacotes, mas outros fatores além do escopo deste tópico podem alterar esse comportamento.

O TCP usa temporizadores para saber quanto tempo esperar antes de reenviar um segmento. 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.

Controle de Fluxo TCP – Tamanho da Janela e Confirmações

O TCP também fornece mecanismos para controle de fluxo. Controle de fluxo é a quantidade de dados que o destino pode receber e processar de forma confiável. 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.

mostra PCB enviando PCB um tamanho de janela negociado de 10.000 bytes e um tamanho máximo de segmento de 1.460 bytes. PCA começa a enviar segmentos começando com o número de sequência 1. Uma confirmação do PCB pode ser enviada sem esperar até que o tamanho da janela seja atingido e o tamanho da janela possa ser ajustado pela PCA criando uma janela deslizante

Exemplo de Tamanho da Janela TCP

O tamanho da janela determina o número de bytes que podem ser enviados antes de esperar uma confirmação. O número de reconhecimento é o número do próximo byte esperado.

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 é de 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 todos os segmentos TCP, para que o destino possa modificar o tamanho da janela a qualquer momento, dependendo da disponibilidade do buffer.

O tamanho da janela inicial é determinado quando a sessão é estabelecida durante o handshake triplo. O dispositivo de origem deve limitar o número de bytes enviados ao dispositivo de destino com base no tamanho da janela do 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.

Por exemplo, é típico que o PC B não espere até que todos os 10.000 bytes tenham sido recebidos antes de enviar uma confirmação. Isso significa que o PC A pode ajustar sua janela de envio ao receber confirmações do PC B. Como mostrado na figura, quando o PC A recebe uma confirmação com o número de confirmação 2.921, que é o próximo byte esperado. A janela de envio do PC A irá incrementar 2.920 bytes. Isso altera a janela de envio de 10.000 bytes para 12.920. O PC A agora pode continuar enviando até outros 10.000 bytes para o PC B, desde que não envie mais do que sua nova janela de envio em 12.920.

Um destino que envia confirmações enquanto processa os bytes recebidos e o ajuste contínuo da janela de envio de origem é conhecido como janelas deslizantes. No exemplo anterior, a janela de envio do PC A incrementa ou desliza sobre outros 2.921 bytes de 10.000 para 12.920.

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.

Nota: Os dispositivos hoje usam o protocolo de janelas deslizantes. O receptor normalmente envia 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 deslizantes é que permite que o emissor transmita continuamente segmentos, desde que o receptor esteja reconhecendo segmentos anteriores. Os detalhes das janelas deslizantes estão fora do escopo deste curso.

14.6.6

Controle de Fluxo TCP - Tamanho Máximo do Segmento (MSS)

Na figura, a fonte está transmitindo 1.460 bytes de dados dentro de cada segmento TCP. Normalmente, este é o tamanho máximo do segmento (MSS) que o dispositivo de destino pode receber. O MSS faz parte do campo de opções no cabeçalho TCP que especifica a maior quantidade de dados, em bytes, que um dispositivo pode receber em um único segmento TCP. O tamanho do MSS não inclui o cabeçalho TCP. O MSS é normalmente incluído durante o handshake de três vias.

Um MSS comum é 1.460 bytes ao usar IPv4. Um host determina o valor do campo de MSS subtraindo os cabeçalhos de IP e de TCP da MTU (Maximum transmission unit, Unidade máxima de transmissão) da Ethernet. Em uma interface Ethernet, a MTU padrão é 1500 bytes. Subtraindo o cabeçalho IPv4 de 20 bytes e o cabeçalho TCP de 20 bytes, o tamanho padrão do MSS será 1460 bytes, conforme mostrado na figura.

mostra um diagrama de um quadro Ethernet inteiro do qual o MTU é 1500 bytes, com 20 bytes sendo o cabeçalho IP, e 20 bytes sendo o cabeçalho TCP, isso deixa 1460 bytes que é o tamanho máximo do segmento TCP MSS

EthernetIPv4TCPPayloadFCSEthernet MTUIP MTU20 bytes20 bytes1460 bytes1500 bytesTCP MSS

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 atingem seu destino, eles são deixados sem serem reconhecidos. 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 recebimento de uma confirmação. Conforme ilustrado na figura, o PC A detecta que há congestionamento e, portanto, reduz o número de bytes que envia antes de receber uma confirmação do PC B.

mostra PCA enviando segmentos para PCB onde segmentos perdidos e retransmissão podem causar congestionamento

Controle de Congestionamento TCP

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.

Nota: As explicações sobre os mecanismos, cronômetros e algoritmos reais de tratamento de congestionamento estão além do escopo deste curso.

Comunicação UDP

14.7.1

Baixa Sobrecarga do UDP Versus Confiabilidade

Como explicado anteriormente, o UDP é perfeito para comunicações que precisam ser rápidas, como VoIP. Este tópico explica em detalhes por que o UDP é perfeito para alguns tipos de transmissões. Como mostrado na figura, o UDP não estabelece uma conexão. O UDP fornece transporte de dados de baixa sobrecarga, porque tem um cabeçalho de datagrama pequeno e nenhum tráfego de gerenciamento de rede.

mostra um remetente host que precisa enviar dados de voz e vídeo enviados com UDP que não requer conexão negociada prévia

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.

mostra datagramas UDP sendo enviados em ordem, mas chegando fora de ordem devido à possibilidade de diferentes rotas para chegar ao destino

UDP: Sem Conexão e Não Confiável

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.

mostra que um aplicativo de servidor RADIUS usa UDP para escutar solicitações na porta 53

Servidor UDP Escutando Requisições

Note: O servidor RADIUS (Serviço de Usuário Discado por Autenticação Remota) mostrado na figura fornece serviços de autenticação, autorização e auditoria para gerenciar o acesso do usuário. A operação do RADIUS está além do escopo deste curso.

14.7.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 um cliente seleciona as portas de origem e de destino, o mesmo par de portas é usado no cabeçalho de todos os datagramas 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.

Page updated

Google Sites

Report abuse