Summary

  • O RFC 1692 propôs o TMux para colocar vários segmentos pequenos de Telnet ou Rlogin, destinados ao mesmo host, num único datagrama IP e reduzir o custo de processar pacotes.
  • O pacote externo escondia as portas TCP de roteadores que filtravam por porta. O RFC mandava esses equipamentos bloquear TMux ou inspecionar cada segmento dentro dele. O RFC 4450 levou a proposta para Historic.

Um caractere digitado na tela vira um pacote. Dez salas de terminais fazem isso ao mesmo tempo, quase sempre rumo a poucos hosts. O link ainda parece livre; o host recebe uma fila de interrupções. No RFC 1692, publicado em agosto de 1994, os autores compararam o trabalho de processar um pacote com um octeto ao de processar um com 1.500: para o host, a diferença podia ser pequena. O gargalo que importava era a contagem de pacotes, não apenas o volume de bits.

Peter Cameron, David Crocker, Danny Cohen e Jon Postel propuseram então agrupar segmentos curtos entre um servidor e o host de destino. O TMux colocava um minicabeçalho de quatro octetos diante de cada segmento, com comprimento, protocolo original e verificação do próprio minicabeçalho. Por fora, o datagrama IP usava o protocolo 18. O receptor separava os segmentos e os entregava a TCP ou UDP como se tivessem chegado em datagramas próprios. As aplicações não precisavam enxergar o embrulho.

O benefício dependia de haver companheiros para a viagem. O primeiro segmento iniciava um temporizador; os demais que chegassem antes do prazo dividiam o datagrama. O RFC sugeria 20 a 30 milissegundos configuráveis e via aproximadamente um décimo de segundo como limite provável para não prejudicar o eco interativo. Encher o buffer antecipava o envio. Segmentos grandes, por exemplo acima de 700 octetos, podiam seguir em pacotes normais. Empacotar um único segmento só acrescentava demora.

Antes de enviar um pacote TMux, o host precisava ter indícios de que o outro saberia abri-lo. Um TMux válido recebido do par servia; para começar, o RFC descrevia um ENQ vazio com protocolo 18. Sem resposta, as tentativas ficavam mais espaçadas, enquanto datagramas comuns podiam continuar. O conhecimento da capacidade expirava, pois um host reiniciado poderia deixar de aceitar TMux. A forma de transporte podia alternar ao longo da sessão.

O custo mais agudo aparecia na seção de segurança. Um roteador que decide pelo número da porta TCP vê apenas o protocolo 18 no lado de fora. As portas estão escondidas dentro do lote. Pior: segmentos maiores da mesma conexão podem passar fora do TMux e receber um julgamento diferente. O RFC 1692 instruía roteadores com filtro de portas, mas sem compreensão de TMux, a bloquear esse tráfego nas duas direções. Roteadores capazes de abri-lo poderiam examinar cada segmento e retirar os que não cumprissem a regra.

TMux nasceu como Proposed Standard. Entre 2004 e 2005, uma revisão de especificações antigas perguntou quais ainda seriam implementadas ou mantidas. O RFC 4450 incluiu TMux entre as que passaram a Historic, situação mostrada pelo RFC Editor. O mesmo invólucro que aliviava o host retirava informação do roteador. Economia de processamento num ponto da rede podia transformar-se em trabalho de inspeção no ponto seguinte.

Fontes