O reconhecimento pelo TCP não garante que os dados foram entregues

11

No RFC 793, há uma parte sobre o reconhecimento de segmentos TCP:

Quando o TCP transmite um segmento contendo dados, ele coloca uma cópia em uma fila de retransmissão e inicia um timer; quando a confirmação para esses dados é recebida, o segmento é excluído da fila. Se a confirmação não for recebida antes do tempo acabar, o segmento é retransmitido.

Um reconhecimento pelo TCP não garante que os dados foram entregues ao usuário final , mas apenas que o TCP receptor assumiu a responsabilidade de fazê-lo.

Agora, isso é interessante. Em nosso NOC, geralmente solucionamos problemas de conectividade entre nossa rede e a rede cliente externa e sempre que detectamos tráfego em um firewall e vemos os bits SYN e ACK enviados e recebidos em ambas as direções, assumimos que a conectividade está estabelecida e que o problema não tem nada a resolver. fazer com a rede.

Mas agora essa RFC me fez pensar - o que mais devo verificar (sem configurar o Wireshark) se a conexão TCP for estabelecida, mas os usuários ainda estiverem enfrentando problemas de conectividade?

tcp protocol-theory transport-protocol layer4 rfc Kamokoba
fonte
5
O que essa frase significa é simplesmente o significado literal da sentença em inglês: o fato de o driver de rede receber os dados (e reconhecer a recepção) não garante que o usuário final os receba. Pode haver um erro no servidor da web, por exemplo. Com relação à sua pergunta final: a única maneira de descobrir se o usuário final recebeu os dados é ligar e perguntar.
Jörg W Mittag

Respostas:

24

Essa parte da RFC trata da transferência de responsabilidade para o sistema operacional ou qualquer que seja o próximo estágio do processo. Está fundamentalmente preocupado com a separação de camadas.

Um reconhecimento pelo TCP não garante que os dados foram entregues ao usuário final, mas apenas que o TCP receptor assumiu a responsabilidade de fazê-lo.

Eu sempre pensei sobre isso desta maneira:

  • O sistema operacional pode falhar entre o envio do ACK e os dados que chegam ao processo do cliente ("cliente" aqui significa cliente do sistema operacional, não "cliente da rede")
  • O processo do cliente pode ser buggy ou travar, ou apenas muito mais lento do que o esperado para lidar com os dados recebidos, ou apenas lê-los em circunstâncias não óbvias
  • Se o cliente estiver enviando os dados adiante, talvez para um arquivo de disco, talvez o arquivo ainda não tenha sido gravado ou liberado
  • Se o cliente estiver enviando os dados pelo TCP, o lado remoto pode não ter transmitido os dados, recebido um ACK ou o processo remoto consumiu os dados com êxito

Tudo o que está dizendo é que esse é um reconhecimento da camada 3 ("eu ouço seus bytes") e não um reconhecimento da camada superior . Considere, por exemplo, a diferença entre o TCP ACK, o SMTP 250 OKapós o gateway de correio do próximo salto aceitar uma mensagem, uma mensagem de recebimento de mensagem (por exemplo, de acordo com a RFC 3798 ), um pixel de rastreamento aberto por mensagem, uma nota de agradecimento de um PA, e uma resposta dizendo "Sim, eu farei isso".

Outro exemplo concreto seria uma impressora:

  • Ele deve ACK antes dos dados para saber o que contém no final (pode ser um arquivo Postscript que começa com uma biblioteca incluída maior que a janela de transmissão TCP)
  • Pode conter uma consulta de status ("você tem papel?", Que obviamente pode ser executado)
  • Pode conter um comando de impressão ("imprima isso", que pode falhar se estiver sem papel)

Eu sugeriria que, se os usuários estiverem vendo e enviando ACKs, mas ainda tiverem problemas de conectividade, é muito mais provável que haja problemas de congestionamento, SO ou aplicativo do que qualquer coisa estritamente relacionada à rede.

Para diagnosticar, sugiro procurar retransmissões, em vez dos ACKs especificamente.

jonathanjo
fonte
Outro item de marcador: mesmo que o processo do cliente esteja funcionando bem, talvez ainda não tenha lido os dados.
Barmar
1
O processo do cliente (se estiver preguiçoso ou perverso) pode simplesmente nunca chamar recv()o soquete; nesse caso, os dados recebidos permaneceriam no buffer de recebimento do soquete TCP indefinidamente.
Jeremy Friesner
Agradecemos a ambos, atualizamos para sugerir que o processo do cliente pode ser lento, com erros e inconstante.
jonathanjo
Você não pode confiar no ACK para garantir que o aplicativo processou sua entrada, você deve implementar uma camada de aplicativo ACK ou Verificar. Para colocar isso em outro contexto. Para redes de controle industrial que usam TSN com uma pilha IP no lado do cliente, o TCP ACK não é suficiente para garantir que as variáveis ​​do processo foram bloqueadas. Ou seja, você não pode confiar no TCP ACK para colocar o sistema em um estado seguro ou que possa ser reparado; você deve ter um aviso de um serviço da camada de aplicativo de que é seguro colocar a mão na máquina.
crasic
10

Do ponto de vista da RFC, o "usuário final" é o aplicativo. Não há garantia de que o aplicativo tenha os dados, apenas que o processo TCP os recebeu.

Da sua perspectiva NOC, a rede está funcionando e os dados chegaram ao host final. Presumivelmente, é com isso que você se preocupa.

Ron Trunk
fonte
0

Você poderia ver desta maneira.

Você é M.Smith e deseja enviar uma carta para M.Toto (as pessoas são a camada de aplicação).

Para enviar a carta, vá para a agência postal local A, que enviará a carta para M.Toto agência postal local B (as agências postais são a camada TCP).

Tudo pode correr bem entre você, os correios A e os correios B - B enviarão um ACK para os correios A. Mas nada garante que a carta chegue a M.Toto. Tudo pode acontecer entre os correios B e M.Toto.

Isso é basicamente o que a RFC diz.

toto
fonte