A sobrecarga do protocolo normalmente remove alguns por cento de um link NAS com fios bem preenchido antes de considerar SMB e comportamento da aplicação. Com um MTU padrão de 1500 bytes, o TCP sobre IPv4 pode transportar 1460 bytes de carga útil da aplicação dentro de cada pacote IP, enquanto o enquadramento Ethernet, o preâmbulo e o intervalo entre quadros consomem tempo adicional no cabo.
Essa aritmética é apenas um teto teórico de eficiência para transferências grandes e limpas. Ficheiros pequenos, pacotes parciais, reconhecimentos, mensagens SMB, encriptação, latência, retransmissões, esperas de armazenamento e comportamento do cliente podem reduzir muito mais o goodput real.
Qual é a diferença entre taxa de linha e goodput?
A taxa de linha descreve a rapidez com que a interface sinaliza bits, enquanto o goodput conta apenas os dados da aplicação entregues. Cabeçalhos, reconhecimentos, retransmissões e mensagens de controlo são tráfego real, mas não bytes adicionados ao ficheiro do utilizador concluído.
Uma porta 1GbE, portanto, não pode fornecer 125 MB/s de carga útil de ficheiro indefinidamente. Esse número converte um bilião de bits sinalizados por segundo em bytes antes de subtrair qualquer trabalho de enquadramento ou protocolo.
O goodput deve ser medido na aplicação após a conclusão da transferência. Os contadores da interface medem tráfego mais amplo e podem incluir reenvios ou dados que a aplicação ainda não confirmou.
Quanto removem os cabeçalhos Ethernet, IP e TCP?
Para TCP padrão sobre IPv4 sem opções, os cabeçalhos TCP e IP reduzem a eficiência da carga útil. O custo de 40 bytes do TCP/IP representa cerca de 2,7% do MTU IP antes de incluir a sobrecarga do cabo Ethernet.
Ao nível do cabo Ethernet, um quadro de tamanho completo também utiliza um cabeçalho de 14 bytes, FCS de 4 bytes, preâmbulo e delimitador de início de 8 bytes, e um intervalo entre quadros de 12 bytes. Uma carga útil TCP de 1460 bytes pode, portanto, ocupar aproximadamente 1538 bytes-tempo num caminho Ethernet simples sem etiquetas.
Essa proporção corresponde a cerca de 94,9% de eficiência da carga útil. O teto aproximado é, portanto, cerca de 949 Mbps em 1GbE, 2,37 Gbps em 2,5GbE e 9,49 Gbps em 10GbE antes de SMB, armazenamento, reconhecimentos e limites de implementação.
Porque é que o tamanho da carga útil altera a percentagem perdida?
A maioria dos cabeçalhos tem um tamanho fixo por pacote, por isso cargas maiores amortizam a sobrecarga fixa do quadro. Um pacote completo de 1500 bytes é muito mais eficiente do que um pacote que transporta apenas algumas centenas de bytes.
Pedidos síncronos pequenos podem, portanto, gastar uma parte maior do seu tempo no cabo em estruturação, pedidos, respostas e reconhecimentos. O número de ficheiros e as viagens de ida e volta da aplicação são importantes mesmo quando o total de bytes da carga útil é modesto.
Os quadros jumbo melhoram ainda mais a relação, mas o ganho matemático máximo é menor do que muitos estrangulamentos de armazenamento. Também requerem suporte MTU consistente em todos os dispositivos e camadas virtuais no caminho.
Que Trabalho Adicional o SMB Acrescenta Além do TCP?
O SMB adiciona cabeçalhos de mensagens, semântica de pedidos e respostas, créditos, estado de autenticação, assinatura ou encriptação e viagens de ida e volta para operações de ficheiros. ficheiros pequenos repetem a configuração da aplicação e do protocolo.
Para uma leitura ou escrita em pipeline grande, a sobrecarga SMB pode ser amortizada por cargas substanciais e vários pedidos pendentes. Para ficheiros pequenos e operações de metadados, mensagens de abertura, consulta, permissão, fecho e diretório tornam-se uma parte maior do tempo decorrido.
A assinatura e a encriptação também consomem CPU e largura de banda de memória sem necessariamente adicionar um grande número de bytes no cabo. A sobrecarga do protocolo inclui, portanto, o custo de processamento, não apenas o tamanho do cabeçalho.
Porque é que as Transferências Reais Podem Perder Mais do que a Aritmética dos Cabeçalhos Prevê?
A aritmética dos cabeçalhos assume cargas completas, sem perdas, janelas adequadas e pontos finais que processam os pacotes suficientemente rápido. latência e perda criam custos além dos bytes do cabeçalho.
A perda de pacotes adiciona retransmissões e reduções no controlo de congestionamento. A latência limita a rapidez com que o remetente recebe feedback. Janelas TCP pequenas, filas subutilizadas, pausas no armazenamento ou um núcleo de CPU ocupado podem deixar o cabo ocioso, mesmo que a eficiência teórica da estrutura seja alta.
Um gestor de ficheiros pode também realizar cópias em fluxo único com buffer, enquanto um benchmark utiliza vários trabalhadores ou buffers de memória. A diferença entre essas ferramentas é o comportamento da aplicação, não apenas os cabeçalhos do protocolo.
Como Deve um NAS Doméstico Estimar o Rendimento Prático?
quadros jumbo reduzem a sobrecarga apenas num caminho validado. Comece com o teto de eficiência do fio MTU padrão, depois subtraia os limites medidos de endpoint e carga de trabalho em vez de aplicar uma percentagem universal.
Use um teste apenas de rede para estabelecer o rendimento útil TCP, depois execute uma cópia NAS de arquivo grande, uma carga de trabalho de arquivo pequeno e a aplicação real. Registe a taxa de linha, bytes da aplicação, CPU, latência de armazenamento, retransmissões, tamanho do pacote e se a assinatura ou encriptação está ativada.
Uma margem de planeamento como 10–15% abaixo da taxa de ligação pode ser razoável para agendar grandes transferências, mas não é uma constante do protocolo. Uma LAN bem ajustada pode aproximar-se do teto de eficiência do fio, enquanto arquivos pequenos ou endpoints limitados podem perder muito mais.
| Camada ou Condição | O que Consome | Efeito no Rendimento Útil |
|---|---|---|
| Ethernet + IP + TCP | Cabeçalhos, preâmbulo, FCS e intervalo entre quadros | Alguns por cento com quadros padrão completos |
| SMB | Comandos, créditos, autenticação, assinatura, encriptação | Pequena para E/S pipeline grande; maior para trabalho pesado em metadados |
| Cargas úteis pequenas ou parciais | Sobrecarga fixa repetida em menos bytes | Eficiência menor por pacote e por arquivo |
| Perda, latência e bloqueios de endpoint | Retransmissão, espera, taxa de envio reduzida, tempo ocioso do fio | Pode exceder substancialmente a perda apenas do cabeçalho |
Perguntas Frequentes
Qual é o teto teórico da carga útil TCP em 1GbE?
Com pacotes TCP/IPv4 completos de 1500 bytes e contabilidade simples de fio Ethernet, é cerca de 949 Mbps antes dos limites SMB e de endpoint.
O SMB custa sempre 10 ou 15 por cento?
Não. Seu impacto depende do tamanho da solicitação, contagem de arquivos, assinatura, encriptação, concorrência, CPU, armazenamento e implementação do cliente.
Os quadros jumbo recuperam toda a sobrecarga do protocolo?
Não. Eles reduzem a frequência de enquadramento e processamento por pacote, mas não removem operações SMB, reconhecimentos, esperas de armazenamento ou comportamento da aplicação.
Por que uma cópia NAS 10GbE pode ficar abaixo de 9,49 Gbps?
O array de armazenamento, disco do cliente, CPU, caminho PCIe, configurações SMB, profundidade da fila, perda de pacotes e ferramenta de cópia podem se tornar limitantes antes da eficiência do fio.
Conclusão Final
A sobrecarga do protocolo transforma a taxa de linha em um rendimento útil inferior devido ao trabalho fixo de Ethernet, IP, TCP e SMB. Quadros padrão completos podem reter cerca de 95% da taxa de fio como carga útil TCP, mas transferências reais de NAS também pagam por operações de arquivo, segurança, feedback, perdas, latência e bloqueios de endpoint. Calcule primeiro o teto do cabeçalho e depois meça a lacuna específica da carga de trabalho.
Centro de Tecnologia e IA
Mais para Ler

Estado em tempo de execução vs. estado persistente no Home Assistant: o que tem de sobreviver ao reinício?
O Home Assistant não persiste todos os valores em tempo real; a configuração, os registos, os estados restaurados selecionados, o histórico e os dados...

Como é que o Home Assistant autentica sessões locais e remotas?
As sessões locais e remotas do Home Assistant utilizam o mesmo modelo de identidade do lado do servidor; o acesso remoto altera a rota...

Porque é que as consultas ao histórico do Home Assistant podem ficar mais lentas à medida que os dados do Recorder aumentam?
O crescimento do gravador pode aumentar o custo das consultas do Histórico quando o intervalo solicitado abrange mais linhas, as falhas de cache aumentam...

