Resumo

  • A RFC 2414 tornou opcional uma janela inicial TCP maior, limitada a min(4*MSS, max(2*MSS, 4380 bytes)). A regra tratava do primeiro envio de uma conexão nova; não redefinia todas as retomadas após ociosidade nem a janela após perda.
  • O benefício esperado era que um segundo segmento pudesse obter uma confirmação sem esperar o temporizador de ACK atrasado. Em muitas situações modeladas, as simulações ns-2 da RFC 2415 encontraram menor atraso mediano de páginas web.
  • Os grupos mistos não produziram um veredito único. Em cargas moderadas, IW=3 não prejudicou o grupo IW=1; num cenário de congestionamento extremo com 32/32 clientes web, o grupo de janela maior foi prejudicado.
  • Eram simulações, não um levantamento de implantação na Internet. A velocidade de uma conexão e a distribuição dos efeitos num caminho compartilhado são perguntas distintas.

A primeira confirmação era o objetivo

A proposta parecia modesta: numa conexão TCP nova, enviar mais de um segmento de dados antes de aguardar. O ganho podia surgir antes de uma transferência grande. Com apenas um segmento em voo, um receptor que usa ACK atrasado talvez espere o temporizador. A chegada de um segundo segmento pode provocar a confirmação antes disso. Para um objeto web curto, evitar essa espera poderia permitir que a transferência terminasse numa única ida e volta. A RFC 2414 estimou que, numa conexão capaz de ampliar a janela de congestionamento, a mudança poderia eliminar até três idas e voltas e um timeout de ACK atrasado na fase inicial.

Isso não era uma ordem para começar toda conexão com quatro segmentos. Publicada como Experimental em setembro de 1998, a RFC elevou o limite permitido a min(4*MSS, max(2*MSS, 4380 bytes)) e disse que o TCP MAY usar o valor maior. Conforme o MSS, o teto podia corresponder a dois, três ou quatro segmentos. A regra se aplicava à janela inicial após o handshake de três vias. A janela após perda continuava em um segmento; a retomada após longa ociosidade era tratada numa regra opcional separada. Era uma experiência limitada, não uma licença para aumentar toda janela sempre que o tráfego parasse.

O endpoint podia escolher o primeiro envio; não podia reservar a fila em que os pacotes entrariam. A RFC 2414 reconhecia os dois lados: a rajada podia custar perda ou timeout à conexão iniciadora, enquanto outros fluxos podiam sofrer perdas ou injustiça num enlace congestionado. Os autores também alertaram que navegadores abrindo várias conexões simultaneamente agravariam o problema se cada uma começasse maior. Melhorar um fluxo podia alterar a carga de uma fila compartilhada por muitos.

As simulações mantiveram mais de um marcador

A RFC 2415, documento Informational complementar, estudou a disputa com ns-2. O modelo tinha um gargalo de 1,5 Mbps e 50 ms, enlaces mais rápidos ao redor, 8, 16 ou 32 clientes web, até três transferências FTP longas e janelas iniciais de um a quatro segmentos de 1460 bytes. As páginas pequenas continham três URLs incorporadas e novas solicitações vinham após esperas aleatórias; o FTP transferia arquivos de um megabyte. O desenho permitia comparação controlada, mas também delimitava a que o resultado se aplicava.

Em muitas situações modeladas, janelas maiores reduziram o atraso mediano das páginas, frequentemente em torno de 30%. Os autores relacionaram boa parte do salto de um para dois segmentos à distribuição de tamanhos de URL usada: a mediana dos objetos principais e incorporados cabia em dois pacotes. Outra distribuição poderia produzir outra curva. Era um resultado de mecanismo dentro de um modelo, não uma promessa universal para navegadores ou enlaces.

Separar os clientes em coortes tornou a pergunta mais precisa. Com grupos 8/8 e 16/16 de clientes web em IW=1 e IW=3, os autores não encontraram efeito negativo no grupo de um segmento; o grupo maior manteve vantagem. Já em 32/32, sob o que o artigo chamou de congestionamento patológico, os clientes IW=3 foram prejudicados. A explicação proposta foi a abertura simultânea de muitas conexões e múltiplas perdas. Isso não prova que todo início maior prejudique vizinhos; mostra que uma mediana melhor não resume a experiência de cada grupo sob toda carga modelada.

Essa evidência difere do traço de conexão única e três buffers da RFC 2416, já coberto. A RFC 2415 trata de vários fluxos modelados num gargalo e de como o resultado muda com a mistura. Nenhuma das duas simulações demonstra o comportamento de equipamentos reais na Internet inteira, nem define uma medida universal de justiça. Mais tarde, a RFC 3390 substituiu a RFC 2414 por um limite opcional no Standards Track; a RFC 5681 registrou essa regra e a RFC 6928 explorou experimentalmente dez segmentos. A sequência de publicação não converte retrospectivamente o modelo de 1998 num censo de implantação.

Running-Code Primacy, de Heng Lu, serve aqui apenas como disciplina de evidência: manter visíveis o mecanismo e o sistema efetivamente testado. On Reality Layers sugere não fundir atraso de página, perdas de fila e conclusões sobre uma rede inteira numa única observação. Nenhuma nota fornece evidência histórica sobre TCP; as fontes são as RFCs.

Fontes