Backup pela WAN: janela TCP e a vazão que sobra de verdade

O caso: uma filial faz backup noturno de 800 GB para o data center, das 22h às 4h (6 horas). O link é de 1 Gbps e o RTT medido é de 35 ms. O software de backup usa uma conexão TCP com janela de 256 KiB (valores de exemplo). O monitoramento mostra perda de 0,01% no horário do backup.

Resposta curta: para caber na janela, o backup precisa de 296 Mbps úteis. Uma conexão com janela de 256 KiB a 35 ms não passa de 59,9 Mbps, e com 0,01% de perda o teto cai para 40,7 Mbps. Nesse ritmo, o backup levaria 1 d 19 h 39 min. O link está sobrando; quem manda é a perda. Com 8 fluxos em paralelo, a conta fecha.

1. Quanto o backup precisa

A primeira conta é a vazão mínima para o volume caber na janela:

vazão necessária = volume em bits ÷ duração da janela em segundos

800 GB são 6.400.000.000.000 bits. A janela tem 6 × 3.600 = 21.600 segundos. A vazão útil necessária é 296 Mbps, sustentada do começo ao fim.

Somando um overhead de 10% para cabeçalhos e protocolo (o padrão da calculadora de tempo de transferência), o link precisa entregar 329 Mbps. É 32,9% de 1 Gbps. O contrato do link não é o problema.

2. O primeiro teto: a janela

Uma conexão TCP só tem em trânsito, a cada RTT, o que a janela permite. O teto é janela ÷ RTT:

256 KiB × 8.192 bits ÷ 0,035 s = 59,9 Mbps

Com esse teto, os 800 GB levariam 1 d 5 h 40 min, muito além das 6 horas. Para uma única conexão entregar os 296 Mbps, a janela precisaria ter pelo menos 1.266 KiB (1,24 MiB). Para o link inteiro, o BDP de 1 Gbps a 35 ms, 4,17 MiB.

A opção window scale da RFC 7323 permite janelas desse tamanho; o deslocamento mínimo para 1,24 MiB é 5. Se a janela do backup está presa em 256 KiB, procure a causa em três lugares: a configuração de buffer do software de backup, os limites de buffer do sistema operacional e algum equipamento no caminho que remova a opção na abertura da conexão.

3. O segundo teto: a perda

Aumentar a janela resolve só se não houver outro limite. Com perda de pacotes, uma conexão com controle de congestionamento clássico reduz o ritmo a cada perda. O modelo de Mathis, Semke, Mahdavi e Ott (1997) estima o teto em regime:

teto ≈ MSS ÷ RTT × 1,22 ÷ √perda

Com MSS de 1.460 bytes, RTT de 35 ms e 0,01% de perda, o teto é 40,7 Mbps, abaixo até do teto da janela. A perda, e não a janela, é o limite que manda no caso. A calculadora de BDP mostra os três tetos lado a lado e indica qual deles está mandando.

Como o teto cai com a perda:

Perda	Teto por conexão	Tempo para 800 GB com 1 conexão
0,001%	129 Mbps	13 h 48 min 30 s
0,01%	40,7 Mbps	1 d 19 h 39 min
0,05%	18,2 Mbps	4 d 1 h 38 min
0,1%	12,9 Mbps	5 d 18 h 5 min

Os próprios autores do modelo publicaram em 2019 que ele perde validade com algoritmos como o BBR, que não reagem à perda da mesma forma. Se as pontas usam outro controle de congestionamento, trate o número como ordem de grandeza e confie na medição.

Disco rígido interno visto de perto — O volume de cada noite sai do disco da filial e precisa caber na janela de backup, conexão por conexão. Foto: Vincent Botta / Unsplash

4. Fluxos em paralelo

O teto da janela e o teto da perda valem por conexão. Várias conexões em paralelo somam seus tetos, até o limite do link. Se o software de backup permitir dividir o trabalho em vários fluxos, a conta fica assim:

Limite por conexão	Teto	Fluxos para 296 Mbps
Janela de 256 KiB	59,9 Mbps	5
Perda de 0,01%	40,7 Mbps	8

O número que vale é o maior, porque cada fluxo está sujeito aos dois limites: 8 fluxos. Com eles, a vazão somada chega a 326 Mbps, acima dos 296 Mbps necessários, e ainda abaixo do link.

Paralelismo é um paliativo eficiente, mas tem custo. Mais fluxos disputam o disco da filial e do data center, e o total pode ocupar o link inteiro se não houver limite. Configure o teto de banda do backup se o link também atende outro tráfego à noite.

5. Atacando a causa

Os fluxos em paralelo contornam o problema. Corrigir a causa costuma render mais:

Reduzir a perda. Com 0,001% de perda em vez de 0,01%, o teto por conexão sobe para 129 Mbps. Procure a origem: enlace com erros, fila cheia em algum equipamento, política de tráfego descartando pacotes.
Aumentar a janela. Sem perda relevante, uma janela de 1,24 MiB faz uma conexão sozinha entregar a vazão necessária.
Rever o volume. Backup incremental, deduplicação e compressão reduzem os bytes que atravessam o link. Refaça a conta com o volume que de fato trafega.

6. A que horas o backup termina

Com a solução do caso, 8 fluxos de até 40,7 Mbps cada, a vazão somada é de 326 Mbps. Os 800 GB levam 5 h 27 min 30 s. Começando às 22h, o backup termina antes das 4h, com 32 minutos de folga.

A folga é pequena. Uma noite com volume maior, ou com perda um pouco mais alta, empurra o fim para depois das 4h. Por isso vale atacar a causa (seção 5) mesmo depois de os fluxos em paralelo resolverem o problema de hoje. E o backup ocupa 32,6% do link durante a madrugada: o resto continua livre para réplicas e atualizações.

7. Medindo do jeito certo

A RFC 6349 descreve uma metodologia para testar vazão TCP em redes gerenciadas. Ela começa por medir o RTT de base, fora do horário de pico, e o BDP do caminho, e usa métricas que juntam o resultado do teste à experiência do usuário. Uma delas é a razão entre o tempo real e o tempo ideal de uma transferência.

No caso, o tempo ideal para os 800 GB, com a vazão útil do link após 10% de overhead, é 1 h 58 min 31 s. Se o backup de ontem levou, digamos, 9 horas (exemplo), a razão é 4,56: o backup levou esse tanto de vezes o ideal. Acompanhar esse número noite a noite mostra se uma mudança na rede melhorou ou piorou o resultado.

8. Roteiro de diagnóstico

Calcule a vazão necessária para o volume caber na janela.
Meça o RTT e a perda no horário do backup, não durante o dia.
Calcule os tetos por janela e por perda e veja qual manda.
Ataque a causa: perda, janela ou volume.
Use fluxos em paralelo para fechar a conta, com limite de banda se o link for compartilhado.
Acompanhe a razão entre tempo real e ideal a cada noite.

Perguntas frequentes

O backup começa rápido e depois desacelera. É normal?

Com perda, o controle de congestionamento clássico reduz o ritmo a cada evento e volta a crescer aos poucos. Uma conexão que começa perto do teto da janela pode se acomodar perto do teto da perda depois de alguns minutos. Compare a vazão estável, não a do primeiro minuto, com os tetos calculados.

Por que medir a perda à noite?

Porque o backup roda à noite. Perda causada por fila cheia depende da carga, e a carga noturna (o próprio backup, réplicas, atualizações) pode ser bem diferente da diurna.

MSS maior ajuda?

Pelo modelo, o teto com perda cresce na proporção do MSS: com 8.960 bytes em vez de 1.460, o teto por conexão a 35 ms e 0,01% iria de 40,7 para 250 Mbps. Mas isso só vale se todo o caminho, incluindo a rede do provedor, aceitar o MTU maior. Confirme antes de mudar; um MTU que não passa no caminho cria um problema novo.

E se a janela do software for de só 64 KiB?

O teto por conexão cai para 15,0 Mbps a 35 ms, abaixo do teto pela perda. Seriam necessários 20 fluxos para chegar aos 296 Mbps. Nesse cenário, a janela volta a ser o limite principal e corrigi-la vem antes de tudo.

Trocar o link para 10 Gbps resolve?

Não neste caso. Os tetos por conexão, de 59,9 e 40,7 Mbps, não dependem da banda do link. O link de 1 Gbps já tem folga para a vazão necessária.

Qual a diferença para o guia da janela TCP em links longos?

O guia por que a janela TCP limita a velocidade em links longos trata de uma conexão presa em 64 KiB em um link intercontinental. Aqui, o RTT é moderado e o limite principal é a perda, com uma janela de backup que precisa fechar todas as noites.

Onde faço a conta com os meus números?

Na calculadora de BDP e janela TCP: informe banda, RTT, janela, perda e MSS. Ela indica o teto de cada limite e qual deles manda. Para o tempo total do backup, use o tempo de transferência com a vazão que sobrou.