Resumo

  • A RFC 872 contestou o receio de que TCP fosse pesado demais por natureza para uma rede local rápida, de baixa taxa de erro. A decisão dependia do serviço exigido pelo aplicativo.
  • UDP e o uso direto de recursos locais podiam servir a tarefas específicas; manter outra pilha inteira para a LAN acrescentava trabalho quando as mesmas máquinas também falavam com redes distantes.

O cabo era curto, e TCP parecia ter aparecido para uma visita de cinco minutos com mala para um mês. Michael A. Padlipsky abriu a mala na RFC 872, de setembro de 1982. Corria a ideia de que um protocolo criado para conversar por várias redes seria inadequado dentro de uma LAN. O autor deu à suspeita o nome de Woozle, uma criatura que ganha tamanho quando as pessoas seguem pistas feitas por elas mesmas. A rede local existia de verdade; a criatura precisava passar por uma inspeção das funções de cada peça.

Padlipsky começou definindo a LAN em discussão: uma rede de comunicação de curta distância, boa capacidade de transmissão e poucos erros, onde computadores possivelmente diferentes trocavam dados para compartilhar recursos. O formato e o meio físico podiam variar. O elemento decisivo era o diálogo entre os computadores. Um conjunto de terminais que dava acesso a máquinas separadas, sem protocolos entre elas, pertencia a outra categoria em sua análise. A velocidade do fio não entregava, sozinha, o serviço que um programa solicitava.

TCP oferecia uma conexão lógica confiável, controle de fluxo e entrega ordenada. Um aplicativo de transferência continuava querendo o arquivo completo e na ordem correta mesmo que a outra máquina estivesse na sala ao lado. A curta distância ajudava a transmissão física; as exigências do programa permaneciam. O endereço no mesmo corredor não podia assinar em nome do aplicativo uma dispensa de confiabilidade.

Havia ainda a peça IP. Padlipsky a separou de TCP: IP identificava se o destino estava na rede próxima ou se o pacote precisava ir a um gateway. Também lidava com tamanhos diferentes de pacotes ao atravessar redes e informava ao receptor qual protocolo superior deveria receber os dados. A separação permitia a outros protocolos entre computadores usar o mesmo mecanismo. Uma máquina conectada à LAN e ao restante do conjunto de redes precisava enxergar além do primeiro trecho. O cabo local podia ser excelente; o destino nem sempre morava na vizinhança.

O texto oferecia opções para outras necessidades. Para voz em pacotes, por exemplo, um programa podia preferir velocidade às garantias de TCP; UDP entrava nessa escolha. Um projeto restrito ao ambiente local também podia usar recursos da LAN de forma mais direta. O custo aparecia quando uma equipe mantinha uma pilha especial para dentro da sala e outra para alcançar o mundo exterior. Eram dois conjuntos de código, testes e decisões de manutenção no mesmo computador. Fugir do monstro imaginado podia produzir um armário real cheio de protocolos.

A crítica ao desempenho merecia medições. Numa LAN com poucos erros, o checksum de TCP parecia uma formalidade. Padlipsky relatou medições em tipos de computadores usados pela comunidade de pesquisa; nelas, o cálculo consumia apenas parte do trabalho por transmissão. Essa observação pertencia àquelas implementações de 1982. Para escolher hoje naquela discussão, o comprador técnico precisava avaliar o trabalho completo: leitura do disco, sistema operacional, preparação dos dados, aplicativo e eventual protocolo alternativo. Um enlace muito rápido não faz o host produzir dados mais depressa do que sua própria rotina permite.

A RFC também lembrava que implementações TCP/IP já funcionavam e atendiam a programas de terminal e transferência. Padlipsky pediu medições cuidadosas em LANs, justamente para conhecer limites e descobrir quando uma rota local especializada valeria a pena. A comparação exigia funções equivalentes e incluía a manutenção posterior. A taxa estampada no equipamento era um dado sobre o meio, não a história inteira da comunicação.

A RFC 872 guardou uma boa pergunta de 1982. Que entrega o aplicativo precisa? A máquina também deve falar para além da LAN? Qual parte do sistema realmente limita o resultado medido? Respondidas essas perguntas, o monstro perde o emprego.