Confiabilidade e controle de fluxo
Confiabilidade e controle de fluxo

Confiabilidade e controle de fluxo

Confiabilidade 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 os pacotes perdidos e numera os pacotes para indicar seu pedido correto 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 compreendida pelo destinatário, todos os dados devem ser recebidos e os dados nesses segmentos devem ser remontados no pedido original. Os números de sequência são atribuídos no cabeçalho de cada pacote para atingir esse objetivo. O número de sequência representa o primeiro byte de dados do segmento TCP.

Durante a configuração da 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. Conforme os dados são transmitidos durante a sessão, o número da sequência é incrementado pelo número de bytes que foram transmitidos. Esse rastreamento de bytes de dados permite que cada segmento seja identificado e reconhecido de forma única. Os segmentos ausentes podem ser identificados.

O ISN não começa em um, mas é efetivamente um número aleatório. Isso evita certos tipos de ataques maliciosos. Para simplificar, usaremos um ISN de 1 para os exemplos neste capítulo.

Os números de sequência do segmento indicam como remontar e reordenar os segmentos recebidos, conforme mostrado na figura.

Os segmentos TCP são reordenados no destino

Os segmentos TCP são reordenados no destino

O processo TCP de recebimento coloca os dados de um segmento em um buffer de recebimento. Os segmentos são então colocados na ordem de sequência apropriada e passados para a camada de aplicativo quando remontados. Quaisquer segmentos que cheguem com números de sequência fora de ordem são retidos para processamento posterior. Então, quando os segmentos com os bytes ausentes chegam, esses segmentos são processados em ordem.

Vídeo – Confiabilidade TCP – Números de sequência e reconhecimentos

Uma das funções do TCP é garantir que cada segmento chegue ao seu destino. Os serviços TCP no host de destino reconhecem os dados que foram recebidos pelo aplicativo de origem.

Clique em Reproduzir na figura para ver uma lição sobre números de sequência TCP e confirmações.

Confiabilidade TCP – perda de dados e retransmissão

Não importa o quão bem projetada seja uma rede, ocasionalmente ocorre perda de dados. O TCP fornece métodos de gerenciamento dessas perdas de segmento. Entre eles está um mecanismo para retransmitir segmentos para dados não confirmados.

Antes de aprimoramentos posteriores, o TCP só podia reconhecer o próximo byte esperado. Por exemplo, na figura, usando números de segmento para simplificar, 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 responderá com confirmação, especificando que o próximo segmento esperado é o segmento 3. O Host A não tem ideia se algum outro segmento chegou ou não. O Host A, portanto, reenviaria os segmentos 3 a 10. Se todos os segmentos reenviados chegassem com êxito, os segmentos 5 a 10 seriam duplicados. Isso pode levar a atrasos, congestionamentos e ineficiências.

Confiabilidade TCP – perda de dados e retransmissão

Os sistemas operacionais de host de hoje geralmente empregam um recurso TCP opcional denominado confirmação seletiva (SACK), negociado durante o handshake triplo. Se ambos os hosts suportam SACK, o receptor pode reconhecer explicitamente quais segmentos (bytes) foram recebidos, incluindo quaisquer segmentos descontínuos. O host de envio precisaria, portanto, apenas retransmitir os dados ausentes. Por exemplo, na próxima figura, novamente usando números de segmento para simplificar, 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 pode reconhecer que recebeu os 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.

Números de segmento TCP

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 retransmissão e perda de dados TCP.

Vídeo – Confiabilidade TCP – Perda de dados e retransmissão

Clique em Reproduzir na figura para ver uma lição sobre retransmissão TCP.

Controle de fluxo TCP – tamanho da janela e confirmações

O TCP também fornece mecanismos para controle de fluxo. O 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 ajustando a taxa de fluxo de dados entre a origem e o destino para uma determinada sessão. Para fazer isso, o cabeçalho TCP inclui um campo de 16 bits denominado tamanho da janela.

A figura mostra um exemplo de tamanho de janela e confirmações.

Exemplo de tamanho de janela TCP

Exemplo de tamanho de 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 confirmação é o número do próximo byte esperado.

O tamanho da janela é o 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. Começando com o primeiro byte, byte número 1, o último byte que o 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 forma que o destino pode modificar o tamanho da janela a qualquer momento, dependendo da disponibilidade do buffer.

O tamanho da janela inicial é acordado quando a sessão TCP é estabelecida durante o handshake de três vias. O dispositivo de origem deve limitar o número de bytes enviados ao dispositivo de destino com base no tamanho da janela de destino. Somente depois que o dispositivo de origem recebe uma confirmação de que os bytes foram recebidos, ele pode continuar enviando mais dados para a sessão. Normalmente, o destino não espera que todos os bytes do tamanho da janela sejam recebidos antes de responder com uma confirmação. À medida que os bytes são recebidos e processados, o destino enviará confirmações para informar à fonte que pode continuar a enviar bytes adicionais.

Por exemplo, é normal 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 à medida que recebe confirmações do PC B. Conforme 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 aumentará 2.920 bytes. Isso altera a janela de envio de 10.000 bytes para 12.920. O PC A agora pode continuar a enviar até outros 10.000 bytes para o PC B, contanto que não envie mais do que sua nova janela de envio em 12.920.

Um destino que envia confirmações à medida que processa os bytes recebidos e o ajuste contínuo da janela de envio de origem é conhecido como janela deslizante. 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 diminuir, ele pode reduzir o tamanho da janela para informar a fonte para reduzir o número de bytes que deve enviar sem receber uma confirmação.

Nota: os dispositivos hoje usam o protocolo de janelas deslizantes. O receptor normalmente envia uma confirmação a cada dois segmentos que recebe. O número de segmentos recebidos antes de serem confirmados pode variar. A vantagem das janelas deslizantes é que elas permitem que o emissor transmita segmentos continuamente, desde que o receptor esteja reconhecendo os segmentos anteriores. Os detalhes das janelas de correr estão além do escopo deste curso.

Controle de fluxo TCP – Tamanho máximo do segmento (MSS)

Na figura, a fonte está transmitindo 1.460 bytes de dados em cada segmento TCP. Normalmente, é 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.

Tamanho máximo do segmento TCP (MSS)

Um MSS comum tem 1.460 bytes ao usar IPv4. Um host determina o valor de seu campo MSS subtraindo os cabeçalhos IP e TCP da unidade de transmissão máxima Ethernet (MTU). Em uma interface Ethernet, o 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á de 1460 bytes, conforme mostrado na figura.

Controle de fluxo TCP

Controle de fluxo TCP – prevenção de congestionamento

Quando ocorre congestionamento em uma rede, os pacotes são descartados pelo roteador sobrecarregado. Quando os pacotes contendo segmentos TCP não alcançam seu destino, eles não são reconhecidos. Ao determinar a taxa na qual os segmentos TCP são enviados, mas não confirmados, a fonte pode assumir um certo nível de congestionamento da rede.

Sempre que houver congestionamento, ocorrerá a retransmissão de segmentos TCP perdidos da origem. Se a retransmissão não for controlada adequadamente, a retransmissão adicional dos segmentos TCP pode tornar o congestionamento ainda pior. Não são apenas novos pacotes com segmentos TCP introduzidos na rede, mas o efeito de feedback dos segmentos TCP retransmitidos que foram perdidos também aumentará o congestionamento. Para evitar e controlar o congestionamento, o TCP emprega vários mecanismos, temporizadores e algoritmos de tratamento de congestionamento.

Se a fonte determinar que os segmentos TCP não estão sendo confirmados ou não estão sendo confirmados em tempo hábil, ela pode reduzir o número de bytes enviados antes de receber 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.

Controle de congestionamento TCP

Controle de congestionamento TCP

Os números de confirmação são para o próximo byte esperado e não para um segmento. Os números dos segmentos usados são simplificados para fins ilustrativos.

Observe que é a fonte 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.

O seu endereço de email não será publicado. Campos obrigatórios marcados com *

CCNA: Introdução às RedesCurso