Diferença entre a entrega confiável pelos protocolos de link e pelo TCP

Question

Há uma citação que eu esqueci de qual livro da rede eu copiei há muito tempo.

Some link-layer protocols provide reliable delivery on a link basis, i.e., from transmitting node, over one link, to receiving node. Note that this reliable delivery service is different from the reliable delivery service of TCP, which provides reliable delivery from one end system to another.

Sabemos que o TCP é um protocolo de camada de transporte, não um protocolo de camada de link.

Gostaria de saber como entender a diferença entre a entrega confiável pelos protocolos de link e pelo TCP, conforme destacado em negrito? Obrigado!

    

Answer 1

O nó para o nó também é conhecido como hop . Garantir confiabilidade em um salto e deixar os saltos remanescentes no caminho de dados com confiabilidade desconhecida seria benéfico se esse salto fosse inerentemente mais confiável, por ex. um link sem fio. Protocolos sem fio como 802.11 e 802.15.4 (por exemplo, ZigBee) podem ter que adicionar Ack / Nak e repetir os recursos para atingir um nível de confiabilidade mínimo similar a uma rede com fio. A moderna Ethernet 802.3 com fio, usando uma configuração em estrela, é tipicamente bastante confiável em um salto, mesmo sem qualquer sobrecarga de Ack / Nak. O wireless, por outro lado, pode não ser muito confiável, e um protocolo confiável de camada de enlace poderia melhorar (ou pelo menos não degradar) o rendimento de uma rede com fio e sem fio.

O TCP alcança sua confiabilidade (apesar de usar IP não confiável como seu protocolo subjacente) basicamente usando respostas Ack e Nak pelo receptor e timeouts no transmissor para determinar se o pacote foi entregue. Uma resposta Nak ou tempo limite de resposta requer uma retransmissão do pacote original. Os pacotes também são marcados com números de sequência para detectar pacotes ausentes ou chegada fora de ordem e para realizar a ordenação adequada dos pacotes recebidos.

Um protocolo de camada de enlace pode melhorar sua confiabilidade empregando técnicas semelhantes de timeout de Ack / Nak /. Embora a execução de várias camadas de protocolo possa parecer redundante, o desempenho geral da rede poderia ser beneficiado, pois as retransmissões (quando necessário) seriam localizadas apenas nos links que apresentavam a falha da mensagem.

    

Answer 2

Não há diferença no significado de "entrega confiável". Independentemente da camada de protocolo, o receptor deve confirmar a recepção de pacotes e o remetente deve retransmitir se uma confirmação não for recebida. Não há confiabilidade sem isso. O único diferente está nas camadas. O TCP tem a vantagem de rodar em cima do IP, o que permite que o roteamento de pacotes em múltiplos saltos atinja um destino final. Na camada de enlace, os protocolos em execução apenas se preocupam com saltos únicos.

    

Answer 3

Por que há uma medida de confiabilidade (adicional) necessária em um nível superior: correção. Mesmo se houvesse uma confiabilidade perfeita no nível do link, os pacotes ainda poderiam se perder nos hosts intermediários (filas sobrevoadas, roteadores com falha, etc). Por que, no nível do link: eficiência.

    

Answer 4

"Confiável" não significa a mesma coisa para todos. Confiável para TCP significa que se você usá-lo em redes com perdas ou em redes que corrompem e / ou reordenam pacotes, então você não receberá dados ilegíveis e essencialmente receberá bons dados no final.

O problema é que o TCP é uma droga, e embora funcione nesses casos, é terrivelmente lento. Então, quando você usa TCP bruto em links que perdem regularmente 0,5% dos pacotes, você terá muito menos desempenho do que a taxa de dados teórica de (link_data_rate / (1 - taxa de perda de pacotes)) em um único link, devido à suposição TCP todas as perdas de pacotes são causadas por congestionamento.

O TCP foi projetado para redes que raramente perdem pacotes, então o TCP só precisa tolerar a perda de pacotes.

Uma das tarefas do link confiável na camada dois é principalmente aqui para compensar a sucessão TCP. Eles não devem ser 100% confiáveis como o TCP. Por exemplo, o 802.11 aceita pacotes perdidos se a contagem de retransmissões estiver acima de um certo limite, enquanto o TCP não retransmitirá para sempre até que o aplicativo ou usuário decida que é suficiente.

A coisa confiável do link na camada 2 é principalmente a velocidade. Por exemplo, no 802.11, o mecanismo de confirmação também é usado pelos nós para que eles possam diminuir a velocidade de modulação se o link sem fio se degradar. Quando o 802.11 não pode fazer ACK (por exemplo, para quadros multicast), ele normalmente usa a taxa de modulação mais baixa, que geralmente é de 1 Mb / s, para obter confiabilidade máxima, com a enorme despesa de velocidade.

Às vezes, quando você tem uma rede com muitos links altamente não confiáveis, você pode precisar da confiabilidade da camada 2, caso contrário, o caminho inteiro pode ter muitos links não confiáveis e a taxa de perda de pacotes pode ser muito alta para ser útil. Mas esse não é o caso em suas redes típicas.

Historicamente, o TCP pegou porque permitiu que os roteadores perdessem pacotes. Assim, os roteadores eram mais simples, mais rápidos e o resultado global era que a confiabilidade dos manuseios nos terminais tinha melhor desempenho do que o manuseio na rede principal.