Resumo

  • O RDP tornava confiável a entrega de mensagens sobre IP, mas tratava a ordem visível à aplicação como uma escolha feita no Open para toda a conexão.
  • ACK mantinha a fronteira contínua; EACK nomeava segmentos corretos além de uma lacuna, evitando retransmitir o que o receptor já tinha.
  • Confirmação de transporte, cópia ao usuário e conclusão da operação continuavam separadas; nem o fechamento com RST nem o número 27 da IANA encerravam a prova.

A economia de não reenviar o que já existe

Considere quatro segmentos: 100 chega, 101 some, 102 e 103 chegam. O receptor não pode avançar a confirmação cumulativa para 103, porque a sequência contínua termina em 100. Também não precisa desperdiçar a notícia de que 102 e 103 passaram pelo checksum e caíram dentro da janela aceitável.

No RFC 908, o EACK transportava justamente essa notícia. O ACK comum continuava indicando o último número recebido em ordem. O cabeçalho variável de EACK listava os números recebidos corretamente fora de ordem. O remetente podia retransmitir 101 sem tratar 102 e 103 como perdidos.

O ganho tinha limite. A borda esquerda da janela continuava presa ao buraco. Novos segmentos avançavam apenas até a borda direita calculada a partir da capacidade anunciada pelo receptor. Se 101 não fosse resolvido, o envio novo acabaria parando. O EACK poupava repetição; não transformava recepção parcial em progresso ilimitado.

O aplicativo conhecia o custo da ordem

O RDP foi desenhado para carregamento remoto, despejo de memória e depuração. Esses trabalhos precisavam receber todas as mensagens. Um buraco permanente numa imagem de memória era inaceitável. Por isso o núcleo comum tinha sequência, checksum, confirmação positiva, temporizador e retransmissão.

Já a ordem de entrega podia ser desperdício ou requisito. Um bloco que carrega seu endereço pode ser colocado imediatamente, mesmo que o bloco anterior esteja atrasado. Uma sequência de comandos de depuração pode exigir o contrário: preparar o estado antes de mandar a execução continuar.

Em vez de escolher por todos, o RDP colocava o modo na solicitação Open. A entrega sequenciada ou não sequenciada permanecia válida durante a conexão. No modo não sequenciado, 102 podia ser copiado para o buffer do usuário assim que fosse aceito. No modo sequenciado, o transporte ainda podia EACKar 102, mas esperava 101 para expô-lo à aplicação.

Logo, a estratégia de reconhecimento e a estratégia de entrega eram eixos diferentes. O receptor podia informar o remetente cedo sem liberar o dado cedo.

A conexão era a moldura da evidência

O SYN carregava número inicial de sequência, máximo de segmentos pendentes, tamanho máximo aceito e opções como o modo de entrega. Esses parâmetros definiam a época da conexão. Um observador que perdesse o SYN poderia ler os mesmos ACKs e EACKs, mas não saberia se os dados fora de ordem já eram visíveis à aplicação.

Cada lado expressava seus próprios limites de buffer. A regra compartilhada obrigava o par a respeitá-los, sem declarar um único tamanho como política universal de desempenho. A especificação comum era rigorosa no que precisava ser comum e deixava a capacidade local com quem fornecia a memória.

Os estados CLOSED, LISTEN, SYN-SENT, SYN-RCVD, OPEN e CLOSE-WAIT organizavam essa moldura. O protocolo incluía abertura simultânea: SYNs que se cruzavam podiam ser respondidos com SYN e ACK, preservando o número inicial de cada lado.

Um NUL dizia menos do que parece

Para verificar certas conexões meio abertas, o RDP podia transmitir NUL. O NUL consumia o próximo número de sequência e precisava de confirmação. Um ACK correspondente indicava que o RDP remoto ainda reconhecia aquela conexão.

Essa resposta não dizia se o processo de aplicação estava saudável. Tampouco um checksum válido autenticava o par. As peças do protocolo eram testemunhas de estado de transporte, não credenciais nem recibos de negócio.

O fechamento preservava a mesma modéstia. Um Close enviava RST, passava por CLOSE-WAIT e depois eliminava o registro. O RFC 908 exigia que o usuário determinasse, antes do Close, que os dados necessários haviam sido entregues de modo confiável. O transporte não convertia sua terminação em commit da aplicação.

A versão 2 trouxe o custo do hardware para o papel

O RFC 1151 registrou problemas vistos em experimentos de 1986 e 1987. O checksum não linear de 32 bits da versão original tinha desempenho muito dependente da representação de dados do host. Implementações otimizadas em bases de hardware comparáveis variavam por um fator de cinco. O RDP v2 adotou o checksum TCP de 16 bits.

Os identificadores de porta internos cresceram de oito para dezesseis bits. Como o formato do cabeçalho mudou, o número da versão também mudou. O texto ainda corrigiu SND.UNA: depois de confirmar SEG.ACK, o mais antigo ainda não confirmado deveria ser SEG.ACK + 1.

Não há base para dizer que a publicação colocou v2 em toda parte. O próprio RFC 1151 menciona demanda limitada por implementações e explica por que as correções não viraram uma reescrita integral. A experiência mudou a proposta de compatibilidade; a adoção ficou como fato a ser demonstrado por código e operação.

O registro de números de protocolo da IANA associa 27 a RDP. Isso conserva o identificador. Não revela versão, tráfego, implementação, suporte a EACK ou conformidade atual.

Quatro perguntas para a palavra confiável

O segmento passou no controle de dano? O RDP de destino confirmou sua recepção? A aplicação recebeu a mensagem? A operação produziu o efeito pretendido? RDP separava essas perguntas em vez de responder todas com um ACK.

Sua escolha histórica não elimina a ordem. Ela coloca a ordem no ponto em que sua necessidade pode ser conhecida. Esse limite torna a confiabilidade mais verificável, não menos séria.

Fontes