Resumo

  • A RFC 3135 pesquisou proxies que tentavam melhorar TCP em enlaces de satélite e redes sem fio por meio de tratamento de ACKs, retransmissão local, conexões divididas, compressão, túneis e ocultação de desconexões.
  • Um ACK criado pelo proxy provava custódia intermediária, não recebimento pelo TCP distante nem conclusão pela aplicação. A otimização transferia também a obrigação de recuperar dados e explicar falhas.

Uma confirmação mais perto do emissor

Em um salto geoestacionário, cada ida e volta carrega centenas de milissegundos de propagação. Se TCP só puder avançar conforme confirmações atravessam todo esse caminho, a janela pode deixar capacidade ociosa.

Um proxy antes do salto pode aceitar segmentos e responder imediatamente. Para o emissor, o RTT encolhe. Mais dados entram em voo. Uma perda na parte sem fio pode ser corrigida perto dela, sem obrigar o emissor remoto a interpretar o evento local como congestionamento de toda a rota.

Entretanto, os bytes continuam onde estavam: talvez no buffer do proxy, ainda antes do satélite, da rádio, do segundo componente, do TCP receptor e da aplicação. Se sumirem depois do ACK local, o emissor original já recebeu uma notícia de sucesso. O proxy passa a dever a recuperação.

A RFC 3135 chamou essa família de Performance Enhancing Proxies, PEPs. Publicada como Informational em junho de 2001, ela não padronizou uma caixa nem recomendou implantação geral. Catalogou mecanismos usados diante de latência, assimetria, erros, pouca banda e períodos de desconexão. Depois perguntou o que esses mecanismos mudavam no modelo de responsabilidade da Internet.

O ponto histórico não era negar o ganho. Era limitar a autoridade do sinal: uma resposta próxima só pode falar pelo ator próximo.

A mesma sigla cobria mecanismos diferentes

Um PEP de transporte podia observar TCP e ajustar seu comportamento sem alterar o protocolo da aplicação. Um PEP de aplicação podia compreender, comprimir ou transformar mensagens e terminar a própria sessão da aplicação. Um desenho integrado reunia tudo em um nó; um desenho distribuído colocava componentes nas duas bordas do enlace degradado.

Nos caminhos assimétricos, cada lado podia exercer uma função. A direção de maior capacidade recebia ACK local para permanecer ocupada. A direção pequena filtrava confirmações redundantes. O proxy tentava casar duas economias de banda diferentes.

Na conexão dividida, o TCP iniciado pelo host terminava no intermediário. O proxy criava outro TCP até o destino. Entre dois PEPs podia haver uma terceira conexão otimizada, talvez um protocolo proprietário sobre UDP, e várias sessões de usuários podiam ser multiplexadas nela.

Outras técnicas eram menos invasivas. Espaçar ACKs mudava o ritmo de respostas originadas pelo receptor. Filtrar ACKs economizava o retorno. Uma função do tipo Snoop guardava segmentos na base e reparava perdas locais. Compressão apenas reduzia bytes. Não se pode inferir a semântica a partir da palavra proxy.

Por isso a RFC separou transparência de preservação ponta a ponta. Um PEP invisível aos hosts podia dividir a conexão. Um serviço explícito podia manter a confirmação da aplicação até o destino. Transparência dizia quem sabia da existência do intermediário; não dizia quem havia recebido os dados.

Quem confirma cedo assume a recuperação

Mesmo o ACK TCP do host distante tem alcance limitado. Ele indica entrega à implementação TCP, não garante que a aplicação leu, validou, armazenou ou concluiu a operação. Uma aplicação que precisa de entrega confiável deve possuir uma verificação de ponta a ponta adequada ao seu próprio significado.

O ACK local adicionava um recibo anterior. A RFC 3135 dizia que, quando o PEP confirmava dados, recaía sobre ele o ônus de recuperar qualquer perda posterior. Isso exigia reter bytes, sequências, temporizadores e informação do trecho descendente.

O benefício podia ser grande. A retransmissão local não esperava a volta completa. Durante uma interrupção, o proxy podia parar de receber, anunciar janela zero, preservar estado e retomar após a reconexão. Uma conexão dividida podia suspender tráfego de baixa prioridade por longo tempo sem produzir no emissor original a mesma sequência de timeouts.

Mas a confirmação antecipada precisava ser acompanhada por prova de custódia. O buffer era volátil? Os dados estavam íntegros antes do ACK? O que acontecia com pressão de memória ou reinício? Qual evento demonstrava que a obrigação havia passado ao TCP remoto e, depois, à aplicação?

O ACK do proxy podia ser verdadeiro. Ele dizia “chegou até mim”. O erro operacional surgia quando throughput ou telemetria o traduzia como “chegou ao destino”.

Cinco recibos não cabiam em uma curva

Primeiro, a aplicação de origem entrega bytes ao TCP local. Segundo, o PEP aceita, armazena e talvez confirme. Terceiro, os bytes cruzam o subcaminho degradado. Quarto, o TCP distante os recebe. Quinto, a aplicação remota responde conforme sua semântica: análise, enfileiramento, gravação durável, commit ou conclusão.

Uma etapa não preenche a outra. Até a confirmação de aplicação precisa de definição. “Aceito” pode significar apenas colocado em fila.

O exemplo do correio na RFC 3135 mostrava uma transferência explícita. Um MTA de relay podia gravar a mensagem em armazenamento não volátil, emitir uma confirmação de aplicação e assumir tentativas posteriores de entrega. Não era garantia absoluta de chegada final, mas tornava a custódia verificável.

PEPs de transporte geralmente deixavam a confirmação da aplicação correr ponta a ponta. Isso preservava a prova superior e precisa ser reconhecido. Ainda assim, o primeiro ACK observado continuava sendo um evento diferente. Entre a custódia do proxy e o trabalho concluído havia um enlace, um host e uma aplicação.

O estado intermediário passou a compartilhar o destino

No desenho ponta a ponta, o estado indispensável da conexão fica nos terminais. Se um roteador falha e outra rota existe, os pacotes podem mudar de caminho sem apagar a memória dos hosts.

Um PEP que mantém dados já confirmados e o estado de uma conexão dividida não é substituível como um roteador comum. Sua queda pode encerrar a sessão mesmo quando a rede dispõe de caminho alternativo. A conectividade existe; a memória da promessa desapareceu.

A RFC não chamou toda essa troca de irracional. Muitos proxies protegiam um último enlace sem alternativa. Uma falha longa da própria rádio já encerraria a utilidade da sessão. O usuário podia preferir desempenho melhor na maior parte do tempo, aceitando um ponto de falha adicional.

A condição era controle informado: entender a consequência, escolher o uso e poder recorrer ao IP ponta a ponta quando necessário. Um PEP obrigatório e transparente enfraquecia essa condição. A operadora capturava o ganho agregado, o fornecedor dominava buffers e recuperação, e a aplicação sofria a perda sem saber quem havia emitido o ACK.

IPsec retirou a visão exigida pela otimização

Reconhecer ACKs, sequências, janelas e opções requer cabeçalhos TCP visíveis. Dividir a conexão exige terminar o transporte. Modificar uma aplicação exige ainda mais conteúdo.

Com ESP ponta a ponta, IPsec escondia cabeçalho e carga do nó intermediário. A RFC 3135 observou que muitos PEPs não funcionariam de modo ótimo ou não funcionariam de forma alguma. Mesmo o espaçamento de ACK, que poderia preservar semântica, precisava identificar as confirmações.

Era possível terminar segurança no proxy e iniciar uma segunda associação. Os dois trechos ficavam cifrados, mas os dados eram expostos dentro do PEP e os terminais precisavam confiar nele. Níveis diferentes nos dois lados podiam ainda produzir uma impressão enganosa sobre a proteção total.

Um túnel apenas entre PEPs, bypass seletivo ou segurança na aplicação mitigavam partes do problema. Nenhuma dessas escolhas recriava automaticamente a propriedade ponta a ponta; apenas estabelecia outra fronteira de confiança.

Documentos posteriores mantiveram a questão viva. A RFC 3449 exigia cabeçalhos visíveis e identificação por fluxo para várias técnicas de assimetria. As RFCs 8404 e 8517 registraram o choque posterior entre cifragem e funções de transporte da rede. A RFC 8684 considerou PEPs capazes de confirmar dados antecipadamente ao definir retransmissões do Multipath TCP. Isso é continuidade arquitetônica, não prova de implantação em 2001.

Esconder a interrupção também mudou o diagnóstico

Ocultar uma queda breve podia preservar uma sessão útil. O proxy mantinha estado, suspendia o emissor e retomava quando o rádio voltava.

O mesmo mecanismo adiava a percepção de uma falha extensa. O terminal podia permanecer em estado plausível enquanto o trecho posterior não avançava. Uma aplicação com caminho alternativo talvez demorasse a acioná-lo porque o intermediário ainda simulava continuidade.

Ping e traceroute podiam observar outra realidade. ICMP talvez contornasse o PEP, talvez o atravessasse sem o tratamento aplicado a TCP, ou talvez recebesse uma resposta do próprio proxy. Um ping verde podia provar apenas chegada ao intermediário. O traceroute listava saltos, mas não mostrava a divisão da conexão nem o conteúdo dos buffers.

Roteamento assimétrico podia fazer um sentido escapar da dupla distribuída. Mobilidade podia exigir migração rápida de estado para outro nó. Escala criava novos limites: inspeção acima de IP e estado por fluxo gastavam mais CPU e memória que encaminhamento. PEPs paralelos exigiam outro controle para manter afinidade.

O aparelho construído para esconder a deficiência do enlace precisava de sua própria evidência de funcionamento.

Uma pesquisa não era um veredito universal

A RFC 3135 era Informational. Seus ambientes —VSAT, WAN sem fio, WAP, Snoop— ilustravam escolhas. Não constituíam um censo, um benchmark comparável de produtos ou prova de que todos os PEPs quebravam segurança e confiabilidade.

Os autores mantiveram o princípio ponta a ponta como abordagem predominante. PEPs deveriam servir situações específicas em que não houvesse solução equivalente nos extremos, e novas tecnologias de enlace deveriam evitar essa necessidade quando possível. Ao mesmo tempo, latência física e custo não desapareciam por fidelidade a um princípio.

A RFC 3234 colocou depois os PEPs numa taxonomia maior de middleboxes. A RFC 3426 usou a RFC 3135 como estudo de benefício e custo: desempenho de um lado; IPsec ponta a ponta, novo ponto de falha, diagnóstico, assimetria e mobilidade do outro. A contabilidade só estava completa com ambos.

Medir desempenho e cadeia de custódia

Uma avaliação deve registrar o problema original: direção, topologia, RTT sem PEP, erros, assimetria, cortes, carga e critério de sucesso da aplicação. Depois precisa congelar versão, dono, localização, transparência, divisão, mecanismos e opção de bypass do proxy.

Para cada operação, separe envio, ACK local, entrada no buffer, durabilidade, envio descendente, retransmissão pelo PEP, ACK TCP remoto, resposta de aplicação e confirmação durável. Preserve quem retransmitiu, qual temporizador disparou, o que um reinício apagou, a rota em cada direção e o resultado de handover ou failover.

Registre também os extremos criptográficos, cabeçalhos visíveis, plaintext dentro do proxy, políticas de exceção e diferenças de proteção. Compare throughput e RTT aparente com tempo, integridade e conclusão da aplicação.

As divergências são gatilhos: ACK antes de custódia confiável; reinício que perde bytes confirmados; ping saudável e TCP travado; cifragem que desativa a função; retorno que contorna o estado; handover que o perde; métrica de transporte melhor com resultado de aplicação pior.

A RFC 3135 encurtou um ciclo de controle, não a verdade. O proxy podia dizer com precisão que recebeu os bytes. Até o destino produzir sua própria evidência, ele não podia falar pela aplicação.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3135.txt
  2. https://www.rfc-editor.org/info/rfc3135
  3. https://www.rfc-editor.org/rfc/rfc3135.html
  4. https://www.rfc-editor.org/rfc/rfc793.html
  5. https://www.rfc-editor.org/rfc/rfc1122.html
  6. https://www.rfc-editor.org/rfc/rfc2401.html
  7. https://www.rfc-editor.org/rfc/rfc2488.html
  8. https://www.rfc-editor.org/rfc/rfc2760.html
  9. https://www.rfc-editor.org/rfc/rfc2775.html
  10. https://www.rfc-editor.org/rfc/rfc3234.html
  11. https://www.rfc-editor.org/rfc/rfc3426.html
  12. https://www.rfc-editor.org/rfc/rfc3449.html
  13. https://www.rfc-editor.org/rfc/rfc8404.html
  14. https://www.rfc-editor.org/rfc/rfc8517.html
  15. https://www.rfc-editor.org/rfc/rfc8684.html