Qualidade de serviço (telecomunicações): diferenças entre revisões

Origem: Wikipédia, a enciclopédia livre.
Conteúdo apagado Conteúdo adicionado
RibotBOT (discussão | contribs)
Luckas-bot (discussão | contribs)
Linha 92: Linha 92:
[[fr:Qualité de service]]
[[fr:Qualité de service]]
[[gl:Calidade de servizo]]
[[gl:Calidade de servizo]]
[[hi:सेवा की गुणवत्ता]]
[[id:Quality of Service]]
[[id:Quality of Service]]
[[it:Qualità di servizio]]
[[it:Qualità di servizio]]
Linha 99: Linha 100:
[[nl:Quality of service]]
[[nl:Quality of service]]
[[pl:Quality of service]]
[[pl:Quality of service]]
[[ro:Calitatea serviciilor (rețele de calculatoare)]]
[[ro:Calitatea serviciilor]]
[[ru:QoS]]
[[ru:QoS]]
[[sk:QoS]]
[[sk:QoS]]

Revisão das 11h12min de 2 de junho de 2010

No campo das telecomunicações e redes de computadores, o termo Qualidade de Serviço (QoS) pode tender para duas interpretações relacionadas, mas distintas.

Em redes de comutação de circuitos, refere-se à probabilidade de sucesso em estabelecer uma ligação a um destino. Em redes de comutação de pacotes refere-se à garantia de largura de banda ou, como em muitos casos, é utilizada informalmente para referir a probabilidade de um pacote circular entre dois pontos de rede.

Problemas Relacionados

A Internet foi projectada sem prever a necessidade de QoS, de maneira que esta funcionava num regime "best effort". Existiam então 4 bits para o "tipo de serviço" (ToS) e 3 bits de "precedência" em cada mensagem, embora raramente utilizados. Durante a transmissão podem existir inúmeras coisas aos pacotes enquanto circulam entre pontos, que resultam nos seguintes problemas, do ponto de vista emissor/receptor:

  • pacotes descartados (dropped packets) - os routers podem recusar-se a entregar alguns pacotes (drop) se estes chegarem quando os buffers se encontram preenchidos. Estes podem ser descartados todos, ou apenas alguns, dependendo do estado da rede, e não existe forma de determinar quais à priori. As aplicações a receber serão então responsáveis por pedir a retransmissão, o que resulta frequentemente em "soluços" na transmissão;
  • atraso (delay) - pode decorrer muito tempo até um pacote atingir o seu destino, já que este é mantido em longas filas, ou segue um caminho alternativo (menos directo) para evitar congestionamento da rede. No entanto a transmissão também pode ocorrer muito rapidamente, e não existe forma de determinar perante qual das situações nos encontramos;
  • entrega desordenada (out-of-order) - ocorre frequentemente a entrega de pacotes numa ordem diferente da que foram enviados, uma vez que estes podem ser enviados por diferentes rotas, o que provoca a exigência de protocolos especiais para que a informação possa ser reconstruída à chegada;
  • erros - também pode ocorrer que os pacotes sejam enviados para destinos errados, ou misturados, ou mesmo serem corrompidos em trânsito. O receptor terá então que detectá-lo e, tal como se o pacote tivesse sido descartado, pedir a retransmissão.

Como obter QoS

Existem, essencialmente, duas formas de oferecer garantias QoS. A primeira procura oferecer bastantes recursos, suficientes para o pico esperado, com uma margem de segurança substancial. É simples e eficaz, mas na prática é assumido como dispendioso, e tende a ser ineficaz se o valor de pico aumentar além do previsto: reservar recursos gasta tempo.

O segundo método é o de obrigar os utentes a reservar os recursos, e apenas aceitar as reservas se os routers conseguirem servi-las com confiabilidade. Naturalmente, as reservas podem ter um custo monetário associado! As duas variações mais conhecidas são:

O modelo DiffServ é tipicamente utilizado para:

O equipamento de rede que suporta DiffServ e algumas vezes IntServ é designado por multilayer. Um comutador que suporte DiffServ (e provavelmente IntServ) é designado por comutador multilayer.

Porém, o mercado ainda não favorece os serviços QoS. Alguns técnicos justificam-no com uma rede que oferece largura de banda suficiente para a maioria das aplicações, na maioria das vezes, economicamente estável, com poucos incentivos para implementar aplicações não standard baseadas em QoS.

Hoje em dia, os acordos entre os fornecedores de serviços internet são já complexos, e parece não existir iniciativa entre eles para suportar QoS entre interligações de backbones, ou acordar que políticas devem ser suportadas para potenciar o seu crescimento.

Os mais cépticos afirmam que se uma ligação elástica está a descartar muitos pacotes, então está muito próxima do colapso de congestão nas aplicações inelásticas, sem qualquer forma de descartar tráfego sem violar as cláusulas do acordo.

Problemas do QoS em algumas tecnologias

As seguintes propriedades podem ser usadas apenas nas portas do receptor, mas não nos servidores, backbones ou outras portas que se encontram a gerir fluxos concorrentes.

  • half-duplex - as colisões na ligação transformam-se em variações no atraso (jitter), já que os pacotes são retidos em cada colisão durante o tempo de backoff.
  • Port queue buffer (IEEE 802.3x - "Flow" control).

IEEE 802.3x "Flow"-control não é um protocolo de controlo de fluxo propriamente dito, mas uma gestão específica das filas. Muitos dos comutadores de hoje incluem o suporte IEEE 802.3x activo - inclusivé em portas de uplink/backbone.

Citação de Network World, 09/13/99, 'Flow control feedback': "...Hewlett-Packard afirma que a qualidade de serviço é uma forma melhor de lidar com o potencial congestionamento, e a Cabletron e Nortel acrescentam que as características QoS não podem operar devidamente se um comutador envia [IEEE 802.x] tramas de pausa..."

Isto sugere que a norma IEEE 802.3x e QoS são incompatíveis.

Uma ligação ethernet a 100 Mbit/s full-duplex em vez de 100 Mbit/s half-duplex aumenta a velocidade efectiva de cerca de 60-100 Mbit/s half-duplex para 200 Mbit/s (100 Mbit/s no envio + 100 Mbit/s na recepção).

Ver também

Ligações externas