Tentando descobrir o custo indireto exato do TCP

9

Correspondendo a este tópico:

/programming/3613989/what-of-traffic-is-network-overhead-on-top-of-http-s-requests

O tamanho máximo do segmento (que não inclui os cabeçalhos TCP ou IP) normalmente é negociado entre as camadas para o tamanho da MTU menos o tamanho dos cabeçalhos. Para Ethernet, a MTU geralmente é configurada em 1500 bytes. O cabeçalho TCP é de 160 bits ou 20 bytes. A parte fixa do cabeçalho IPv4 é de 160 bits ou 20 bytes também. ... Portanto:

para HTTP sobre TCP / IPv4

sobrecarga = TCP + IP = 40 bytes

carga = 1500 - 40 = 1460 bytes

% de despesas gerais = 2% (40 * 100/1460)

Aqui estão os resultados de iperf de 100 Mbit e 1 Gbit no modo TCP com distribuições padrão do Debian:

[  5] local 10.0.51.1 port 5001 connected with 10.0.51.20 port 45009
[  5]  0.0-10.0 sec   112 MBytes  94.1 Mbits/sec
[  4] local 10.0.51.1 port 5001 connected with 10.0.51.94 port 35065
[  4]  0.0-10.0 sec  1.10 GBytes   941 Mbits/sec

Eu posso baixá-lo para quase 2% de sobrecarga, aumentando o MTU para 9000:

[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.14 GBytes   982 Mbits/sec

Mas não deveria ser menos ainda?

overhead = TCP + IP = 40 bytes
payload = 9000 - 40 = 8960 bytes
overhead % = 0.4% (40 * 100 / 8960)

Por que a "perda de largura de banda" real é notavelmente maior que a teórica? Se fórmula faltando algo valioso?

tcp bandwidth

— agrrh
fonte

15

Pacotes Ethernet 1.5k

1500 - 20 B (IPv4) - 20 B (TCP + soma de verificação) = DADOS de 1460 B (e sobrecarga de 40 B)

Adicione 40 B + 14 B (Ethernet) + 4 B (FCS) + 12 B (gap entre quadros) + 8 B (preâmbulo) = 78 B Overhead

78/1460 * 100 = 5,34% de despesas gerais

1460 / (1460 + 78) * 100 = 94,93% Taxa de transferência / Goodput

1.000.000.000 (1Gbit) * 94,93% = 949Mbit / s (0,949Gbit / s)

você mediu 941Mbit / s que resulta em (949 - 941) / 949 * 100 = 0,84% de erro entre o teórico e o real.

Pacotes jumbo 9k - Teórico máx.

(9000-40) / ( 9000 - 40 + 78 ) *100 = 99.14%  (Overhead 0.86%)

1.000.000.000 (1Gbit) * 99,14% = 991Mbit / s (0,99Gbit / s)

— Pieter
fonte

11

Provavelmente também há influência do recurso de início lento, mas não tenho certeza se é grande o suficiente. Obrigado. :)

— agrrh

Ah, a Ethernet tem um FCS de 4 bytes no final do quadro, deixe-me acrescentar isso ao cálculo.

— Pieter

4

As despesas gerais são geralmente calculadas com base no tamanho total dos dados. Dessa forma, a figura corresponde ao valor da eficiência.

Para TCP sobre IPv4 sobre Ethernet, você tem (sem opções de cabeçalho):

Sobrecarga L1 - preâmbulo, IPG: 8 + 12 = 20
Sobrecarga L2 - cabeçalho Ethernet, FCS = 18
Sobrecarga L3 - cabeçalho IPv4 = 20
Sobrecarga L4 - cabeçalho TCP = 20

O tamanho máximo de pacote L3 de 1500 resulta em um tamanho total de dados L1 de 1500 + 18 + 20 = 1538 bytes e um tamanho máximo de carga útil L4 de 1500-20-20 = 1460 bytes .

Despesas gerais: 78/1538 * 100% = 5,07%
Eficiência: 1460/1538 * 100% = 94,93%

Com os quadros jumbo de 9k (não 802.3), você obterá

Despesas gerais: 78/9038 * 100% = 0,86%
Eficiência: 8960/9038 * 100% = 99,14%

Esses são valores teóricos e de melhor caso . Na vida real, você também teria sobrecarga de hardware e sistema operacional que levaria um pouco para o valor da eficiência. Recursos como descarga e direção de interrupção com vários núcleos podem reduzir a sobrecarga do processamento e aproximá-lo dos valores teóricos (mais relevantes com placas de rede de velocidade mais alta). Os que você mediu parecem bem realistas, como Pieter já apontou.

— Zac67
fonte