QoS: o que é, como funciona, DSCP e DiffServ

Entenda o que é QoS em redes e como DSCP, DiffServ, filas, shaping, policing, AQM, Wi‑Fi, L4S e NQB determinam a Qualidade de Serviço.

Confira!

QoS (Quality of Service, ou Qualidade de Serviço) é o conjunto de mecanismos usados para controlar como diferentes classes de tráfego disputam recursos finitos de uma rede. Em engenharia, QoS envolve classificação, marcação, condicionamento, enfileiramento, escalonamento e controle de congestionamento para que aplicações com requisitos distintos de atraso, variação de atraso, perda e vazão recebam tratamentos coerentes com esses requisitos.

QoS não cria largura de banda e não significa simplesmente “dar prioridade” a determinados pacotes. Uma marcação DSCP, por exemplo, apenas identifica uma intenção de tratamento; o resultado depende das políticas configuradas em cada domínio, das filas disponíveis, do scheduler, do estado de congestionamento e da preservação — ou não — dessa marcação ao longo do caminho.

Na prática, QoS se torna relevante quando existe contenção. Em uma rede folgada, diferentes classes podem apresentar desempenho semelhante. Quando um enlace, rádio, uplink ou interface de saída se aproxima da saturação, as filas passam a determinar quem espera, quem transmite primeiro, quem pode consumir banda excedente e quais pacotes serão descartados ou sinalizados antes que o buffer fique completamente cheio.

O que o QoS realmente controla em uma rede

A Qualidade de Serviço deve ser entendida a partir das características mensuráveis do serviço, e não a partir de uma lista fixa de aplicações “importantes”. A arquitetura DiffServ, a ITU-T Y.1540/Y.1541 e a literatura clássica de redes convergem para quatro dimensões centrais: vazão, atraso, variação de atraso e perda.

Métrica	O que representa	Por que importa para QoS
Vazão / throughput	quantidade de dados efetivamente entregue por unidade de tempo	fluxos de backup, vídeo de alta resolução e grandes transferências podem exigir capacidade sustentada, mesmo sem necessidade de baixa latência extrema
Latência	tempo de trânsito entre origem e destino	aplicações interativas, voz, controle e determinados fluxos operacionais degradam quando o atraso cresce
Jitter / IPDV	variação do atraso entre pacotes	áudio e vídeo em tempo real dependem de regularidade de entrega; buffers de reprodução conseguem absorver apenas parte dessa variação
Perda de pacotes	parcela dos pacotes que não chega ao destino	perda pode reduzir qualidade de mídia, disparar retransmissões ou diminuir throughput em transportes orientados a congestionamento

Essas grandezas têm causas diferentes. A latência de um caminho pode ser decomposta, de forma simplificada, em atraso de propagação, serialização/transmissão, processamento e fila. QoS atua principalmente onde existe disputa por recursos e formação de fila; ele não elimina a velocidade finita de propagação nem corrige, por si só, um enlace fisicamente subdimensionado.

Essa distinção evita um erro comum: tentar “resolver com prioridade” um problema que na verdade é de capacidade, arquitetura ou percurso. O artigo sobre tráfego de rede aprofunda justamente a relação entre fluxos, carga e capacidade.

Latência, jitter e perda não são a mesma coisa

Latência é atraso. Jitter é a variação desse atraso. Uma comunicação pode ter latência relativamente alta e estável, enquanto outra apresenta latência média baixa, mas grande dispersão entre os tempos de chegada. Para aplicações interativas, os dois problemas produzem efeitos diferentes.

A perda também precisa ser interpretada no contexto do protocolo e da aplicação. Em TCP, perdas podem induzir retransmissões e redução da janela de congestionamento. Em UDP/RTP, a aplicação pode optar por continuar sem retransmitir, privilegiando temporalidade em vez de recuperação perfeita. Portanto, a política de QoS deve ser definida a partir do comportamento real do fluxo.

Por que o congestionamento cria o problema que o QoS precisa administrar

Uma interface de saída transmite pacotes em uma taxa finita. Quando chegam mais bits do que ela consegue transmitir naquele intervalo, pacotes precisam esperar em memória. Surge uma fila.

Filas pequenas absorvem rajadas naturais. Filas excessivamente profundas, porém, podem esconder a saturação durante algum tempo e introduzir centenas de milissegundos de atraso — fenômeno associado ao bufferbloat. O problema deixa de ser apenas “falta de banda”: aplicações interativas passam a compartilhar o mesmo buffer com fluxos agressivos e orientados à ocupação de toda a capacidade disponível.

QoS moderno, portanto, não se resume ao scheduler. Ele combina mecanismos de classificação, marcação, traffic conditioning, queue scheduling, Active Queue Management (AQM) e, quando suportado, Explicit Congestion Notification (ECN).

Como o QoS funciona: da aplicação à interface de saída

QoS eficiente começa antes da configuração do switch: é preciso caracterizar fluxos, localizar gargalos, definir classes, trust boundaries, política de marcação e critérios mensuráveis de aceite.

A A3A estrutura projetos de redes corporativas com arquitetura, capacidade, segmentação, redundância e política de QoS documentada de ponta a ponta.

Conheça o serviço de Projeto de Rede Lógica e Redes Corporativas

Um projeto coerente de QoS começa por identificar o tráfego e termina na interface que realmente enfrenta contenção. Entre esses pontos, a rede precisa manter uma política consistente.

Cadeia funcional de QoS desde a identificação do fluxo até a transmissão

A sequência não implica que todos os equipamentos executem todas as funções. Em arquiteturas DiffServ, operações mais complexas podem ficar concentradas nas bordas do domínio, enquanto o núcleo aplica Per-Hop Behaviors (PHBs) de forma escalável.

Classificação

Classificar é decidir a qual classe um pacote pertence. O classificador pode considerar origem e destino, prefixos, portas, protocolo, VLAN, interface, aplicação identificada, contexto de segurança ou outros atributos disponíveis no equipamento.

Uma boa política prefere critérios estáveis. Classificar exclusivamente por porta TCP/UDP, por exemplo, tornou-se menos confiável em aplicações modernas que compartilham HTTPS, QUIC ou túneis. Quando a própria aplicação marca seus pacotes, a rede ainda precisa definir se confia nessa marcação.

Trust boundary: onde a rede passa a confiar na marcação

A fronteira de confiança é um dos pontos mais importantes do projeto. Marcação recebida de um endpoint não deve ser aceita automaticamente em qualquer ambiente; caso contrário, um dispositivo poderia autodeclarar todo o seu tráfego como crítico.

Na borda, a política pode:

confiar na marcação de um endpoint ou sistema administrado;
reclassificar o fluxo com base em política local;
remarcar DSCP/PCP para os valores internos do domínio;
limitar ou policiar classes com recursos reservados;
remover marcações não autorizadas.

Essa decisão é parte da segurança e da governança de recursos da rede, não apenas de desempenho.

DSCP, DS Field e por que marcação não é prioridade automática

O Differentiated Services Code Point (DSCP) ocupa seis bits do campo DS no cabeçalho IP. Os dois bits restantes do octeto são utilizados por ECN. O DSCP seleciona o comportamento que a rede pretende associar ao pacote dentro de um domínio DiffServ.

É incorreto tratar o valor decimal do DSCP como uma escala universal em que “quanto maior, maior a prioridade”. Codepoints representam semânticas definidas por padrões ou por políticas de domínio. O tratamento só existe se os nós estiverem configurados para mapear aquele codepoint para o PHB e para os mecanismos de fila correspondentes.

Da mesma forma, marcar não reserva banda. Um pacote EF não recebe magicamente baixa latência porque contém determinado bit pattern; a rede precisa provisionar capacidade, limitar a admissão na classe e configurar um comportamento de encaminhamento compatível.

DSCP x PCP/CoS em Ethernet

Em redes Ethernet com VLAN, o IEEE 802.1Q fornece o campo Priority Code Point (PCP) de três bits no tag VLAN. Isso permite representar oito valores de prioridade de usuário no domínio de camada 2.

DSCP e PCP operam em camadas diferentes:

DSCP: marcação de camada 3 no cabeçalho IPv4/IPv6;
PCP: informação de prioridade associada ao tag IEEE 802.1Q na camada 2;
mapeamento entre eles: política do domínio, não equivalência automática.

Ao cruzar fronteiras L2/L3, túneis ou domínios administrativos, a engenharia precisa definir explicitamente o que é preservado, traduzido ou removido.

DiffServ: a arquitetura mais importante para QoS IP escalável

A arquitetura Differentiated Services (DiffServ) foi concebida para fornecer diferenciação de serviço de forma escalável. O tráfego é classificado e condicionado nas bordas, marcado no campo DS e agregado em classes de comportamento. No núcleo, cada pacote recebe um Per-Hop Behavior associado ao seu DSCP.

Essa ideia resolve uma limitação de arquiteturas baseadas em estado por fluxo: o core não precisa manter uma reserva individual para cada sessão. Ele trata agregados.

PHB: o tratamento que um nó aplica por salto

Um PHB descreve o comportamento observável que um agregado recebe em um nó. Isso é diferente de prometer um resultado end-to-end. A experiência fim a fim resulta da composição de todos os saltos e domínios atravessados.

PHB / tratamento	Finalidade	Observação de engenharia
Default / Best Effort	serviço padrão da Internet	adequado a tráfego sem requisito especial; não significa “tráfego ruim”
EF — Expedited Forwarding	base para serviços de baixo atraso, baixo jitter e baixa perda	depende de taxa configurada e controle de admissão/condicionamento; não deve virar uma fila ilimitada de “tudo que é importante”
AF — Assured Forwarding	quatro classes com diferentes recursos e três níveis de precedência de descarte em cada classe	útil quando se deseja diferenciar probabilidade de encaminhamento sob congestionamento
LE — Lower Effort	tráfego que pode ceder recursos ao Best Effort em congestionamento	apropriado a serviços de menor urgência, como determinadas sincronizações e transferências oportunistas
NQB — Non-Queue-Building	isolar microfluxos suaves, de baixa taxa e não formadores de fila do tráfego que cria filas profundas	PHB recente; não oferece capacidade reservada nem “prioridade alta”

A RFC 4594 organiza classes de serviço a partir das características das aplicações e de seus requisitos de desempenho. O documento apresenta um conjunto amplo de classes de referência, mas não recomenda que toda rede implemente todas elas. Na prática, menos classes, bem definidas e mensuráveis, costumam produzir políticas mais robustas do que dezenas de classes difíceis de operar.

EF não é sinônimo de voz e AF não é sinônimo de vídeo

Essas associações aparecem em muitos exemplos de fabricantes, mas o projeto deve partir do requisito. Um fluxo de sinalização de controle pode merecer tratamento diferente de um fluxo de mídia; vídeo gravado para armazenamento pode tolerar atraso de fila que uma videoconferência não tolera; tráfego de câmera pode demandar throughput elevado sem exigir tratamento de baixa latência equivalente a voz interativa.

O PHB deve ser escolhido pela engenharia da classe, não pelo nome da aplicação.

Filas e schedulers: quem transmite quando existe contenção

Depois da classificação, pacotes são normalmente associados a filas de saída. O scheduler decide em que ordem e em que proporção essas filas utilizam a interface.

Os nomes exatos variam por plataforma, mas os modelos conceituais mais comuns incluem FIFO, prioridade estrita e algoritmos de compartilhamento ponderado como WFQ, WRR/DRR e derivações implementadas comercialmente.

FIFO

Em First In, First Out, todos os pacotes compartilham uma fila e saem na ordem de chegada. É simples, mas não diferencia classes. Um grande fluxo pode aumentar o atraso experimentado por um pequeno fluxo interativo.

Prioridade estrita

Uma fila de prioridade estrita pode ser atendida antes das demais. É útil para tráfego com requisitos rigorosos, mas exige proteção contra starvation: se a classe prioritária puder ocupar indefinidamente a interface, as outras classes podem ficar sem serviço suficiente.

Por isso, classes de prioridade devem ser dimensionadas e controladas. “Marcar mais coisas como prioritárias” tende a destruir o próprio benefício da prioridade.

Compartilhamento ponderado

Schedulers ponderados distribuem capacidade entre classes de acordo com pesos, garantias mínimas ou políticas equivalentes. Eles são úteis para classes que precisam de participação previsível sob congestionamento, mas podem aproveitar banda excedente quando outras filas estão vazias.

Um desenho comum combina uma fila estrita limitada para tráfego realmente sensível a tempo com filas ponderadas para as demais classes. O princípio é mais importante que o nome comercial do mecanismo.

Shaping x policing: dois mecanismos que não devem ser confundidos

Traffic shaping e traffic policing controlam taxa, mas fazem isso de maneiras diferentes.

Mecanismo	Ação quando o tráfego excede o perfil	Efeito típico
Shaping	retém temporariamente pacotes e suaviza a taxa de saída	adiciona fila e atraso controlado para adequar o fluxo a uma taxa configurada
Policing	identifica tráfego fora do perfil e pode descartar ou remarcar pacotes	limita o uso do recurso sem criar uma fila de espera equivalente ao shaping

Shaping é particularmente útil antes de um gargalo cuja taxa efetiva é menor do que a velocidade física da interface local, porque permite que o equipamento forme a fila em um ponto onde possui controle de QoS.

Policing é útil em fronteiras de contrato ou para proteger classes. Porém, descartar agressivamente tráfego orientado a TCP pode reduzir throughput e gerar ciclos de retransmissão. A política precisa considerar o comportamento do transporte.

Token bucket, srTCM e trTCM

Muitos conditioners são explicados por modelos de token bucket. Tokens representam permissão para transmitir uma quantidade de bytes; eles são acumulados segundo uma taxa e limitados por um tamanho de burst.

A RFC 2697 define o Single Rate Three Color Marker (srTCM), baseado em CIR, CBS e EBS. A RFC 2698 define o Two Rate Three Color Marker (trTCM), que adiciona uma taxa de pico. Esses modelos permitem distinguir tráfego dentro do perfil, excedente e claramente fora do perfil, viabilizando políticas de AF e policing mais refinadas que um simples “passa ou descarta”.

AQM, ECN e bufferbloat: QoS também é controlar a fila antes de ela transbordar

Em uma fila tradicional com tail drop, os pacotes só são descartados quando o buffer chega ao limite. Esse comportamento pode manter filas persistentemente cheias e introduzir atraso elevado.

Active Queue Management (AQM) tenta detectar congestionamento antes do transbordo completo e sinalizá-lo por descarte ou, quando ECN é suportado, por marcação explícita. A RFC 7567 recomenda fortemente o uso de AQM como parte da preservação do desempenho da Internet.

RED/WRED, CoDel e FQ-CoDel

RED e suas derivações introduziram a ideia de descarte probabilístico antecipado. Implementações WRED também podem associar diferentes perfis de descarte a classes ou precedências.

O CoDel, descrito na RFC 8289 como Experimental, usa o tempo de permanência do pacote na fila (sojourn time) para controlar excesso de atraso associado a bufferbloat. O FQ-CoDel, RFC 8290, combina separação de fluxos com AQM, reduzindo a capacidade de um fluxo pesado aumentar a latência de todos os demais.

Esses mecanismos mostram uma evolução importante: qualidade percebida não depende apenas da ordem de saída das classes; depende também de quanto tempo a rede permite que a fila cresça.

ECN: sinalizar congestionamento sem necessariamente descartar

A RFC 3168 introduziu Explicit Congestion Notification no IP/TCP. Em vez de sinalizar congestionamento exclusivamente por perda, um nó AQM pode marcar pacotes ECN-capable, permitindo que endpoints reajam ao congestionamento.

ECN não elimina a necessidade de filas e controle de congestionamento. Ele adiciona uma forma explícita de sinalização entre rede e transporte. Versões modernas de baixa latência, como L4S, ampliam esse conceito.

IntServ e RSVP: reserva por fluxo e a diferença para DiffServ

Antes da consolidação de DiffServ como principal arquitetura escalável de diferenciação, a IETF desenvolveu o modelo Integrated Services (IntServ). A ideia é permitir que aplicações solicitem recursos e que os nós mantenham estado associado a fluxos.

O RSVP, definido na RFC 2205, é um protocolo de sinalização de reservas para fluxos unicast ou multicast. Combinado ao IntServ, permite admission control e tratamento baseado em requisitos explícitos.

A diferença arquitetural é central:

IntServ/RSVP trabalha com estado e reserva por fluxo;
DiffServ agrega tráfego em classes e aplica PHBs escaláveis por domínio.

IntServ continua conceitualmente importante e RSVP possui usos específicos, mas manter estado por fluxo em grandes redes impõe desafios de escalabilidade e operação. Em redes corporativas, campus, WAN e provedores, DiffServ costuma ser a base mais comum das políticas de QoS.

QoS em Ethernet: IEEE 802.1Q e classes de tráfego

O IEEE 802.1Q é a referência central para bridges e redes bridged, incluindo VLANs e mecanismos associados às prioridades de usuário. Em uma rede com tags VLAN, o PCP permite transportar uma indicação de prioridade no domínio Ethernet.

Isso não transforma Ethernet em um domínio automaticamente alinhado ao IP. Um projeto precisa definir o mapeamento DSCP ↔ PCP ↔ filas de hardware em cada tipo de switch, além de identificar situações em que a tag VLAN é removida, adicionada ou alterada.

Em redes convergentes, a coerência entre camadas evita comportamentos paradoxais: um pacote pode estar marcado como crítico em IP, mas entrar em uma fila de Best Effort na camada 2 se não houver política de tradução adequada.

QoS em Wi‑Fi: EDCA, Access Categories e mapeamento de DiffServ

Em WLAN, o meio é compartilhado e o problema muda: além de filas no equipamento, estações competem pelo acesso ao rádio. O IEEE 802.11-2024 consolida os mecanismos MAC/PHY atuais, incluindo os mecanismos de QoS incorporados ao padrão ao longo de suas revisões.

O modelo EDCA utiliza quatro Access Categories:

AC_VO — Voice;
AC_VI — Video;
AC_BE — Best Effort;
AC_BK — Background.

Essas categorias alteram estatisticamente a oportunidade de acesso ao meio. Portanto, traduzir DSCP diretamente para uma Access Category exige cuidado: uma marcação criada para um comportamento em IP pode produzir prioridade diferente quando interpretada em Wi‑Fi.

A RFC 8325 fornece recomendações para mapear classes DiffServ em IEEE 802.11. A engenharia deve usar esse mapeamento conscientemente, especialmente em redes corporativas densas. Para cobertura, capacidade, roaming e comportamento de rádio, veja também o serviço de Projeto de Rede Wi‑Fi Corporativa.

NQB tornou o mapeamento Wi‑Fi ainda mais interessante

A RFC 9956, publicada em 2026, atualiza a orientação da RFC 8325 para o novo NQB PHB. O DSCP recomendado para NQB é 45 decimal. A particularidade é que NQB não representa “alta prioridade”: ele representa tráfego de baixa taxa e não formador de fila que deve ser isolado de fluxos que criam filas persistentes.

Em equipamentos Wi‑Fi plenamente compatíveis com a recomendação NQB, a intenção é manter NQB em fila separada com preferência de encaminhamento equivalente a Best Effort. Em equipamentos legados, o DSCP 45 pode cair em mapeamentos que o tratam como vídeo, razão pela qual a RFC discute explicitamente interoperabilidade, remarcação e proteção contra uso indevido.

Esse é um bom exemplo de por que ler DSCP como um simples número de prioridade é tecnicamente errado.

QoS em WAN, MPLS, SD-WAN, túneis e múltiplos domínios

Dentro de um único campus, a organização controla quase todo o caminho. Em WANs e conexões com provedores, a política atravessa fronteiras administrativas.

Um pacote pode sair do campus marcado, atravessar um túnel, receber outro cabeçalho, entrar em uma rede MPLS, passar por uma Internet pública que zera DSCP e chegar a um destino onde a marcação original já não existe. Por isso, QoS end-to-end exige distinguir intenção local de tratamento contratado entre domínios.

Pontos de projeto incluem:

quais DSCPs o provedor aceita;
como classes são mapeadas para a oferta WAN;
onde ocorre remarking ou DSCP bleaching;
como túneis copiam ou não informações de QoS entre cabeçalhos interno e externo;
onde está o gargalo real;
qual taxa deve ser usada no shaper quando a interface física é mais rápida que o serviço contratado;
como rotas alternativas mantêm uma política equivalente.

Em SD-WAN, seleção dinâmica de caminho pode complementar QoS: um fluxo sensível pode ser direcionado para um enlace que atende melhor a seus requisitos de perda, latência e jitter. Isso não substitui o gerenciamento de fila no gargalo.

QoS para voz, videoconferência, CFTV e aplicações corporativas

Uma política madura separa requisitos de serviço de rótulos de aplicação.

Voz e comunicações interativas

Voz conversacional é sensível a atraso, jitter e perda. A ITU-T G.114 trata do impacto do atraso unidirecional na qualidade conversacional e lembra que tarefas altamente interativas podem ser afetadas muito antes de limites extremos de atraso.

Para voz, o volume de tráfego costuma ser relativamente pequeno e previsível, o que torna viável uma classe de baixa latência bem dimensionada. Porém, sinalização, mídia e serviços auxiliares não precisam necessariamente receber exatamente o mesmo PHB.

O Projeto de Telefonia IP e Comunicações Unificadas deve integrar codec, capacidade, arquitetura, sinalização e política de QoS, em vez de tratar QoS como configuração isolada do switch.

Videoconferência e AV over IP

Videoconferência combina áudio sensível a atraso com vídeo que demanda mais banda e pode adaptar bitrate. AV over IP pode ainda utilizar multicast, sincronismo e fluxos de altíssima taxa.

Colocar todo esse tráfego em uma fila de prioridade estrita é uma solução simplista. A política deve reservar baixa latência onde ela realmente é necessária e garantir capacidade às classes de mídia sem permitir que uma rajada extensa monopolize a interface.

CFTV IP: prioridade máxima nem sempre é a resposta correta

Em CFTV IP, o tráfego de vídeo não deve ser classificado automaticamente como de prioridade máxima. A política de QoS deve distinguir os fluxos conforme sensibilidade a atraso e jitter, necessidade de throughput sustentado, criticidade operacional e consequência da perda.

Um sistema de CFTV pode ter fluxos diferentes:

Fluxo	Característica predominante	Tratamento possível
stream de gravação câmera → VMS/NVR	throughput sustentado e previsível; alta agregação	classe com banda suficiente e proteção contra congestionamento, sem necessariamente usar prioridade estrita
live view operacional	sensível a atraso/jitter em operação em tempo real	pode justificar classe distinta do tráfego de gravação
PTZ e comandos de controle	baixa taxa, alta interatividade	classe de controle separada pode ser mais importante que priorizar todo o vídeo
exportação de evidência / backup	alta quantidade de dados, baixa urgência relativa	candidato a classe Best Effort ou Lower Effort conforme a política
analytics distribuído	perfil depende da arquitetura: metadados, vídeo ou ambos	classificar pelo fluxo real e pela consequência operacional

A política de QoS para CFTV deve ser definida a partir do bitrate agregado, oversubscription, topologia, uso de multicast ou unicast, redundância, arquitetura de armazenamento e criticidade operacional. O artigo sobre cabeamento de rede para CFTV IP complementa a camada física e de acesso desse problema.

QoS end-to-end: uma marcação isolada não garante qualidade

A expressão end-to-end QoS só faz sentido quando a política é analisada ao longo de todo o caminho relevante. Um pacote pode receber excelente tratamento em nove saltos e sofrer congestionamento severo no décimo. O resultado da aplicação será determinado pelo gargalo.

Isso exige uma visão de arquitetura. A Arquitetura de Rede Corporativa define os domínios, caminhos e pontos de agregação sobre os quais a política de QoS será aplicada.

Método de projeto recomendado

Levantar aplicações e fluxos. Identificar origem, destino, protocolo, direção, taxa média, pico, burst e criticidade.
Definir requisitos mensuráveis. Estabelecer o que realmente importa para cada classe: atraso, IPDV/jitter, perda, throughput ou disponibilidade.
Localizar gargalos. Mapear uplinks, links WAN, rádios, interfaces com oversubscription e serviços contratados abaixo da velocidade física.
Definir poucas classes de serviço. Agrupar aplicações com características semelhantes, evitando uma classe por aplicativo.
Definir trust boundaries. Determinar quem pode marcar, onde a rede confia e onde remarca.
Escolher PHBs e filas. Associar cada classe a tratamento coerente: prioridade limitada, compartilhamento ponderado, Best Effort, Lower Effort ou NQB quando aplicável.
Aplicar shaping/policing. Condicionar tráfego nas bordas e formar a fila antes do gargalo quando necessário.
Definir AQM/ECN. Controlar filas profundas e permitir sinalização de congestionamento quando os endpoints e equipamentos suportarem.
Mapear entre tecnologias. Documentar DSCP, PCP, Access Category Wi‑Fi, classes WAN/MPLS e comportamento em túneis.
Testar sob congestionamento. QoS deve ser validado quando há contenção; testar apenas em rede ociosa não prova a política.
Monitorar e revisar. Confrontar a política com telemetria real e mudanças nas aplicações.

Um Projeto de Rede Lógica e Redes Corporativas deve registrar essa política como parte da arquitetura e da documentação técnica, não como uma coleção de comandos específicos de fabricante.

Como validar se o QoS está funcionando

A validação precisa observar tanto configuração quanto comportamento. Ver um DSCP no pacote confirma marcação, mas não prova que o pacote recebeu o tratamento pretendido.

Indicadores relevantes incluem:

utilização por interface e por classe;
taxa de filas e ocupação de buffers;
drops por classe e causa;
ECN marks quando aplicável;
throughput entregue;
latência, jitter/IPDV e perda fim a fim;
policer drops e tráfego fora de perfil;
alterações de DSCP ao atravessar fronteiras;
distribuição de fluxos que consomem cada classe.

Telemetria de fluxos ajuda a descobrir quem está ocupando a rede. O artigo NetFlow: o que é, como funciona e como analisar tráfego de rede detalha esse nível de observabilidade. Já o Gerenciamento de Redes baseado em FCAPS e SNMP amplia a visão para operação contínua.

Teste em condições controladas

A política deve ser submetida a tráfego concorrente suficiente para criar contenção controlada. Em seguida, mede-se se a classe sensível mantém os objetivos esperados e se as demais classes continuam recebendo serviço adequado.

Uma política que só funciona porque o enlace nunca passa de 20% de utilização não foi efetivamente validada como QoS; ela apenas não encontrou congestionamento.

QoS moderno: L4S e NQB mostram que “prioridade” é uma visão incompleta

Duas evoluções recentes ajudam a compreender a direção atual do tema.

L4S: baixa latência com congestion control escalável e ECN

A arquitetura L4S — Low Latency, Low Loss and Scalable Throughput, descrita na RFC 9330, busca reduzir drasticamente atraso de fila ao combinar controles de congestionamento escaláveis nos endpoints, sinalização ECN mais frequente e AQM compatível no gargalo.

O ponto conceitual é importante: a própria RFC ressalta que baixa latência não surge simplesmente porque a rede “prioriza” um pacote. Ela depende do comportamento do congestion control do emissor e de um feedback de congestionamento mais preciso, com mecanismos de rede que separam tráfego L4S do comportamento Classic.

L4S não substitui DiffServ. São mecanismos que atacam problemas relacionados por ângulos diferentes: DiffServ diferencia classes/PHBs; L4S modifica a relação entre fila, AQM, ECN e controle de congestionamento.

NQB: baixa fila sem reservar capacidade

O Non-Queue-Building PHB, RFC 9956, foi padronizado para microfluxos suaves, de baixa taxa e limitados pela própria aplicação que não contribuem materialmente para a formação de filas.

NQB fornece uma fila rasa separada do Best Effort profundo, mas não oferece banda reservada e não deve receber preferência de encaminhamento superior ao Default. Seu benefício vem do isolamento em relação aos fluxos que constroem filas, não de furar a fila por prioridade.

Isso abre espaço para aplicações interativas de baixa taxa, IoT, determinados fluxos de controle e outros microfluxos que sofrem com bufferbloat mesmo sem consumir largura de banda significativa. Como qualquer PHB, sua adoção exige suporte dos nós relevantes e política coerente de marcação e proteção.

Erros comuns em projetos de QoS

Marcar tudo como prioridade alta

Quando muitas aplicações recebem a classe mais privilegiada, essa classe passa a competir consigo mesma. A rede deixa de conseguir diferenciar o que realmente precisa de baixa latência.

Copiar uma tabela de DSCP sem analisar o tráfego

Tabelas de referência são úteis, mas não substituem caracterização. O mesmo tipo nominal de aplicação pode ter perfis completamente diferentes conforme codec, resolução, arquitetura e direção do fluxo.

Configurar QoS apenas no core

O congestionamento costuma aparecer em interfaces de saída, acessos, WAN, Wi‑Fi e pontos de agregação. Uma política impecável no core pode ser irrelevante se o gargalo estiver na borda.

Confiar cegamente na marcação do endpoint

QoS também é uma política de autorização de consumo de recursos. Trust boundaries precisam ser explícitas.

Ignorar a taxa contratada do provedor

Uma interface de 1 Gb/s ligada a um serviço WAN de 200 Mb/s não enxerga necessariamente o gargalo no lugar esperado. Sem shaping próximo da taxa real, a fila pode se formar na rede do provedor, fora do controle local.

Confundir QoS com capacidade

QoS administra escassez; não corrige subdimensionamento estrutural. Se a soma dos serviços essenciais excede a capacidade disponível de forma contínua, é necessário rever arquitetura e bandwidth.

Considerações finais

QoS é uma disciplina de engenharia de tráfego e gerenciamento de filas, não um botão de prioridade. Um projeto consistente parte dos requisitos das aplicações, mede a rede, define poucas classes, estabelece fronteiras de confiança, escolhe PHBs e mecanismos de fila adequados, condiciona tráfego onde necessário e valida o resultado sob congestionamento real.

DiffServ e DSCP continuam sendo a base para diferenciação escalável em redes IP; IEEE 802.1Q e IEEE 802.11 determinam como essa intenção encontra os domínios Ethernet e Wi‑Fi; AQM e ECN tratam a dinâmica das filas; IntServ/RSVP explicam a alternativa baseada em reserva por fluxo; e mecanismos recentes como L4S e NQB mostram que baixa latência moderna depende cada vez menos de uma noção simplista de “prioridade máxima”.

O resultado procurado não é ter pacotes com números diferentes no cabeçalho. É obter comportamento mensurável, previsível e documentado para os serviços que compartilham a infraestrutura.

Uma política de QoS precisa ser testada sob congestionamento controlado. Marcação correta sem comportamento mensurável nas filas não comprova qualidade de serviço.

Em redes críticas, o projeto deve transformar requisitos de latência, jitter, perda e throughput em critérios de configuração, comissionamento e monitoramento.

Veja como estruturamos projetos de redes e telecomunicações

Referências técnicas

[1] NICHOLS, K.; BLAKE, S.; BAKER, F.; BLACK, D.. RFC 2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. 1998. Disponível em: https://www.rfc-editor.org/info/rfc2474/.

[2] BLAKE, S. et al.. RFC 2475 — An Architecture for Differentiated Services. 1998. Disponível em: https://www.rfc-editor.org/info/rfc2475/.

[3] HEINANEN, J. et al.. RFC 2597 — Assured Forwarding PHB Group. 1999. Disponível em: https://www.rfc-editor.org/info/rfc2597/.

[4] DAVIE, B. et al.. RFC 3246 — An Expedited Forwarding PHB (Per-Hop Behavior). 2002. Disponível em: https://www.rfc-editor.org/info/rfc3246/.

[5] GROSSMAN, D.. RFC 3260 — New Terminology and Clarifications for Diffserv. 2002. Disponível em: https://www.rfc-editor.org/info/rfc3260/.

[6] BABIARZ, J.; CHAN, K.; BAKER, F.. RFC 4594 — Configuration Guidelines for DiffServ Service Classes. 2006. Disponível em: https://www.rfc-editor.org/info/rfc4594/.

[7] HEINANEN, J.; GUERIN, R.. RFC 2697 — A Single Rate Three Color Marker. 1999. Disponível em: https://www.rfc-editor.org/info/rfc2697/.

[8] HEINANEN, J.; GUERIN, R.. RFC 2698 — A Two Rate Three Color Marker. 1999. Disponível em: https://www.rfc-editor.org/info/rfc2698/.

[9] RAMAKRISHNAN, K.; FLOYD, S.; BLACK, D.. RFC 3168 — The Addition of Explicit Congestion Notification (ECN) to IP. 2001. Disponível em: https://www.rfc-editor.org/info/rfc3168/.

[10] BAKER, F.; FAIRHURST, G.. RFC 7567 / BCP 197 — IETF Recommendations Regarding Active Queue Management. 2015. Disponível em: https://www.rfc-editor.org/info/rfc7567/.

[11] NICHOLS, K. et al.. RFC 8289 — Controlled Delay Active Queue Management. 2018. Disponível em: https://www.rfc-editor.org/info/rfc8289/.

[12] HOILAND-JORGENSEN, T. et al.. RFC 8290 — The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm. 2018. Disponível em: https://www.rfc-editor.org/info/rfc8290/.

[13] SARKAR, S. et al.. RFC 8325 — Mapping Diffserv to IEEE 802.11. 2018. Disponível em: https://www.rfc-editor.org/info/rfc8325/.

[14] BLESS, R.. RFC 8622 — A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services. 2019. Disponível em: https://www.rfc-editor.org/info/rfc8622/.

[15] BRISCOE, B. et al.. RFC 9330 — Low Latency, Low Loss, and Scalable Throughput (L4S) Internet Service: Architecture. 2023. Disponível em: https://www.rfc-editor.org/info/rfc9330/.

[16] WHITE, G.; FOSSATI, T.; GEIB, R.. RFC 9956 — A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services. 2026. Disponível em: https://www.rfc-editor.org/info/rfc9956/.

[17] BRADEN, R.; CLARK, D.; SHENKER, S.. RFC 1633 — Integrated Services in the Internet Architecture: an Overview. 1994. Disponível em: https://www.rfc-editor.org/info/rfc1633/.

[18] BRADEN, R. et al.. RFC 2205 — Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification. 1997. Disponível em: https://www.rfc-editor.org/info/rfc2205/.

[19] IEEE. IEEE Std 802.1Q-2022 — IEEE Standard for Local and Metropolitan Area Networks — Bridges and Bridged Networks. 2022. Disponível em: https://standards.ieee.org/ieee/802.1Q/10323/.

[20] IEEE. IEEE Std 802.11-2024 — Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications. 2024. Disponível em: https://standards.ieee.org/ieee/802.11/10548/.

[21] ITU-T. Recommendation Y.1540 — Internet protocol data communication service — IP packet transfer and availability performance parameters. 2019. Disponível em: https://www.itu.int/rec/T-REC-Y.1540/.

[22] ITU-T. Recommendation Y.1541 — Network performance objectives for IP-based services. 2011. Disponível em: https://www.itu.int/rec/T-REC-Y.1541/.

[23] ITU-T. Recommendation G.114 — One-way transmission time. 2003. Disponível em: https://www.itu.int/rec/T-REC-G.114/.

[24] OPPENHEIMER, P.. Top-Down Network Design. 3. ed. Indianapolis: Cisco Press. 2011.

[25] TANENBAUM, A. S.; WETHERALL, D. J.. Computer Networks. 5. ed. Boston: Pearson. 2011.

Perguntas frequentes

O que significa QoS em redes?

QoS significa Quality of Service, ou Qualidade de Serviço. É o conjunto de mecanismos usado para classificar e tratar diferentes classes de tráfego segundo requisitos de atraso, jitter, perda e vazão.

QoS aumenta a velocidade da internet ou da rede?

Não. QoS não cria capacidade. Ele administra como a capacidade existente é compartilhada quando há contenção, podendo reduzir atraso ou perda para determinadas classes às custas de um tratamento diferente para outras.

DSCP é uma prioridade?

Não de forma universal. DSCP é um codepoint no campo DS do cabeçalho IP que seleciona uma intenção de Per-Hop Behavior dentro de um domínio DiffServ. O tratamento depende da política configurada nos equipamentos.

Qual a diferença entre shaping e policing?

Shaping retém pacotes em fila para suavizar a taxa de saída; policing mede o tráfego contra um perfil e pode remarcar ou descartar o excedente. O primeiro introduz atraso controlado, enquanto o segundo limita o uso do recurso sem formar a mesma fila de espera.

Qual a diferença entre EF e AF no DiffServ?

EF é um PHB usado como bloco para serviços de baixo atraso, jitter e perda quando a classe é adequadamente provisionada. AF define quatro classes independentes e três níveis de precedência de descarte dentro de cada classe, permitindo diferentes probabilidades de entrega sob congestionamento.

QoS deve ser configurado para todo tráfego de CFTV como prioridade máxima?

Não. Gravação contínua, live view, PTZ, analytics e exportação têm perfis diferentes. O projeto deve separar os fluxos e definir tratamento pela necessidade de latência, perda e throughput, evitando colocar todo o vídeo em uma fila de prioridade estrita.

Como QoS funciona no Wi-Fi?

No Wi-Fi, além das filas do equipamento, existe disputa pelo meio rádio. IEEE 802.11 usa Access Categories como Voice, Video, Best Effort e Background. O mapeamento entre DSCP e essas categorias precisa ser projetado; a RFC 8325 fornece orientações específicas.

O que é NQB no QoS moderno?

NQB é o Non-Queue-Building PHB padronizado pela RFC 9956 em 2026. Ele usa fila rasa separada para microfluxos suaves e de baixa taxa que não formam filas. Não oferece banda reservada nem prioridade superior ao Best Effort; o DSCP recomendado é 45 decimal.

O que é QoS end-to-end?

É a engenharia do tratamento do tráfego ao longo de todos os domínios relevantes, incluindo LAN, Wi-Fi, WAN, túneis e redes de provedores. Uma marcação isolada em um único equipamento não garante desempenho fim a fim.