Summary

  • A RFC 914 calculou que um caractere Telnet ocupava 41 bytes num pacote TCP/IP. Numa linha de 1200 baud, os autores estimaram cerca de 0,3 segundo por pacote e 30 baud efetivos para tráfego de um caractere, segundo as hipóteses do próprio texto.
  • Thinwire I reduzia o exemplo a 17 bytes; Thinwire II, a 13. Thinwire III entregava as funções de transporte e rede a um gateway e projetava cerca de 900 baud efetivos em média. Cada economia colocava a responsabilidade num lugar diferente.

Uma bicicleta barata perde a graça quando toda pedalada precisa rebocar um caminhão de mudanças. Foi mais ou menos essa conta que David Farber, Gary Delp e Thomas Conte fizeram em setembro de 1984. Computadores pessoais entre US$ 3 mil e US$ 10 mil podiam aparecer em casas e escritórios afastados dos enlaces rápidos. Uma linha dedicada de 56k custava caro e demorava a chegar; modems telefônicos de 1200 ou 2400 baud estavam disponíveis. O detalhe inconveniente era o tráfego: um único byte de letra vinha acompanhado por quarenta bytes do mecanismo TCP/IP. A máquina ficara acessível; o formulário exigido para cada tecla continuava pesado.

Na RFC 914, os autores calcularam cerca de 0,3 segundo para transmitir aquele pacote mínimo de 41 bytes numa linha de 1200 baud. Para caracteres isolados, equivalia a apenas 30 baud de utilidade. Era uma estimativa que supunha a linha como único limite e a tratava como síncrona. Interrupções, processamento e enquadramento poderiam piorar o tempo em 10% a 50%. Eco local ou edição da linha podiam disfarçar a espera em algumas aplicações; outras precisavam mandar cada caractere de imediato. Nessas, a burocracia do pacote aparecia em cada toque.

Thinwire I atacava o excesso pela diferença. Em cada ponta, guardava-se o pacote anterior. O seguinte carregava instruções sobre onde substituir bytes e quantos trocar. No exemplo, a atualização típica caía para 17 bytes, com taxa efetiva calculada em cerca de 70 baud. A simplicidade cobrava um limite: se pacotes de naturezas diferentes se alternassem, o último pacote deixaria de ser um bom molde. Uma técnica que dependia de semelhança não podia obrigar a rede inteira a ser parecida.

Thinwire II distribuía os pacotes em classes por conexão TCP. Cada classe mantinha seu próprio modelo; um mapa de bits indicava os campos alterados, e diferenças curtas substituíam números longos repetidos. O pacote de exemplo encolhia a 13 bytes, aproximadamente 95 baud efetivos para teclas isoladas. O preço agora era memória no PC e tabelas no gateway. Se as cópias do estado discordassem, o fluxo parava. O texto exigia um enlace serial confiável e pacotes completos periódicos para recolocar os dois lados de acordo. Protocolos que o compressor não conhecesse seguiriam inteiros. O fio ficava leve porque as pontas se lembravam do passado.

Thinwire III mandava a mala para outro balcão. O gateway central cuidaria das conexões TCP e UDP com a Internet, a pedido do PC. Entre ambos, um fluxo serial confiável, multiplexado, levaria dados e comandos. A taxa efetiva média estimada subia para a faixa de 900 baud. Mas o PC deixava de ser diretamente responsável por toda a sua conversa de rede. O gateway iniciava as conexões externas como seu agente. O PC podia pedir uma abertura passiva no gateway para prestar serviço; uma conexão de entrada inesperada não o alcançava como a um host completo. A aceleração vinha junto com um intermediário indispensável.

A ficha do RFC Editor hoje marca o documento como histórico. Em 1984, os autores ofereciam alternativas para discussão, não uma norma pronta. Seus números eram estimativas de projeto. Mesmo assim, a escolha que registraram é concreta: comprimir pouco com pouco estado, comprimir mais mantendo estados sincronizados, ou deslocar o trabalho inteiro para um gateway. A primeira tecla do usuário já continha essa pergunta maior: quem carregaria a Internet quando a linha não pudesse?