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

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?

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.

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.

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.