•  
  • 0 items - R$0.00
  •  
Ajudando o QoS – TCP PSH e URG Flags

Ajudando o QoS – TCP PSH e URG Flags

Boa Noite Pessoal

Neste post veio postar sobre Qualidade de Serviço, o famoso QoS mas a idéia não é falar com foco infra-estrutura de redes, equipamentos como QoS em roteadores, Switches e etc. Acredito que o assunto QoS em infra-estrutura de rede ja é um assunto ja bem maduro e com ampla documentação, técnicas de control-plane como RSVP (Legado), MPLS-TE, MPLS Traffic Engineering–DiffServ Aware (DS-TE), MPLS-TE policy-based tunnel selection (pbts) ou técnicas de QoS em data-plane como CBWFQ, LLQ e etc, tais assuntos ja são conhecidos por todos..

Gostaria de na verdade abordar um assunto muito simples mas que poucos desenvolvedores de aplicativos utilizam e que pode auxiliar muito em relação a um dos paramentos de QoS, Delay ou Latencia. Falo das Flags TCP PSH e URG. Ambas as flags foram adicionadas no TCP desde sua primeira RFC 793, veja que naquela época ja foi adicionado mecanismo que QoS no próprio TCP que podem ser muito úteis.

Antes de entender qual a finalidade do flagh PSH  temos que entender o significa o Maximuim Segmet Size (MSS) do TCP e seu uso, quando utilizamos o TCP temos buffer de memória associado a porta (socket) da aplicação, para deixar a comunicação mais eficiente possível é melhor que enviemos a maior quantidade de tráfego possível por vez, do que enviemos a mesma quantidade de tráfego porem em diversos segmentos pequenos, pois em cada segmento TCP teremos o overhead do cabeçalho TCP, IPv(4 ou 6) e a tecnologia de Camada 2 (ethernet, hdlc, pop e etc). Esse tamanho máximo que podemos enviar por segmento é representado pelo valor do MSS. Apenas a título de observação, no MSS não contabilizamos os 20 bytes do cabeçalho IP e 20 bytes do cabeçalho TCP, ou seja, são informações de payload da perpectiva do TCP, o MSS é negociado no momento do estabelecimento da conexão TCP onde ambos os participantes da conexão (Origem e Destino) informam o tamanho de MSS que suportam, veja que o MSS é orientado ao sentido do flor, podemos ter valores negociados diferentes entre ambos os participantes da conexão. Temos algumas ferramentas de Rede que conseguem ajustar o MSS de forma dinâmica como o path-mtu da Cisco, muito utilizado para otimizar Perring BGP, principalmente quando utilizamos Full-Routing e precisamos enviar uma grande quantidade de updates quando existe uma convergência  na rede é melhor que utilizemos o maior MSS e MTU da rede em de enviar um update por segmento TCP.

Após entender o conceito do MSS temos que entender que para a comunicação ser eficiente os dados enviado da aplicação através do socket é armazenado em buffer no TCP até que seu MSS seja atingido ou até que a aplicação informa que tal segmento deve ser enviado,  a aplicação pode informar ao TCP quando grava um dado no socket para envio que o segmento deve ser enviado imediatamente (push the data on the network right now), tal ação é sinalizada no TCP através da flag PSH dessa forma quando o segemnto chega em seu destino também será imediato as camada de aplicação imediatamente em vez de armazena-la em buffer até chegar uma maior quantidade de dados.

É claro que a maioria das aplicações em tempo real como voz e vídeo utiliza UDP que prove uma performance muito melhor que TCP, porem existem aplicações que estão no “meio termo”, são aplicações que precisam de boa performance em relação a latencia e também necessitam da confiabilidade que o TCP oferece com restransmissão dos dados em caso de perda de pacote, como exemplo temos o Telnet, SSH e algumas comunicações (pacotes) utilizadas em games. Veja que quando acessamos nosso roteador via Telnet e digitamos um comando cada letra do comando digitado é enviado imediatamente ao roteador, não precisamos esperar digitar uma grande quantidade de caracteres para depois o software de telnet envie do roteador, veja abaixo uma captura de wireshark para Telnet.

Screen Shot 2014-02-26 at 11.27.35 AM

Screen Shot 2014-02-26 at 11.28.17 AM

Screen Shot 2014-02-26 at 11.28.48 AM

Screen Shot 2014-02-26 at 11.29.03 AM

Perceba que todas as letras digitadas foram enviadas imediatamente e sinalizadas pela flag PSH.

Temos também o flag URG que na RFC  793 indica que esse flag e seu apontador (URG POINTER) devem ser utilizados para sinalizar o TCP de destino e sua aplicação que esse dado é urgente e deve ter prioridade em relação a outros dados TCP e enviado a aplicação, vejamos um trecho da RFC 793.

The Communication of Urgent Information

The objective of the TCP urgent mechanism is to allow the sending user

to stimulate the receiving user to accept some urgent data and to

permit the receiving TCP to indicate to the receiving user when all

the currently known urgent data has been received by the user.

This mechanism permits a point in the data stream to be designated as

the end of urgent information.  Whenever this point is in advance of

the receive sequence number (RCV.NXT) at the receiving TCP, that TCP

must tell the user to go into “urgent mode”; when the receive sequence

number catches up to the urgent pointer, the TCP must tell user to go

into “normal mode”.  If the urgent pointer is updated while the user

is in “urgent mode”, the update will be invisible to the user.

The method employs a urgent field which is carried in all segments

transmitted.  The URG control flag indicates that the urgent field is

meaningful and must be added to the segment sequence number to yield

the urgent pointer.  The absence of this flag indicates that there is

no urgent data outstanding.

To send an urgent indication the user must also send at least one data

octet.  If the sending user also indicates a push, timely delivery of

the urgent information to the destination process is enhanced.

Bom pessoal a idéia é escalrecer que podemos não somente ser cobrados por desenvolvedores que reclamam, a aplicação esta lenta, podemos também cobra-los, dizendo voce utilizou os recursos disponíveis no TCP que pode ser chamados através da aplicação??

Fica a dica ai pessoal, boa noite a todos boa semana.

Abraço
Leandro Almeida
DOUBLE CCIE#29765(R&S/SP)
CCIP, CCNA

About Leandro Almeida - DOUBLE CCIE#29765 (R&S/SP)

Leandro Almeida
MBA (FGV / UCI)
DOUBLE CCIE#29765 (R&S / SP)
CCIP, CCNA

Leandro Almeida é especialista de redes sênior com 12 anos de experiência, Instrutor Sênior e desenvolvedor do Material da NCE Treinamentos, possui duas certificações CCIE, Routing and Switching (2011) e Service Provider (2013) alem das certificações CCIP (2010) e CCNA (2003) e especializações em Data Center DCUFD – Designing Cisco Data Center Unified Fabric e DCUCD -Designing Cisco Data Center Unified Computing.
Leandro também possuir MBA em Gerenciamento de Projetos adquirido pela Universidade de Irvine e FGV (2013). Aprovado no Exame CCIE Data Center Wirtten Exam em 2013 seu próximo foco em certificação é passar no lab do CCIE DC.
Cursos Ministrados: CCDA, CCNA R&S, CCNA SP, CCNA DC, CCNP R&S, CCNP SP, CCNP DC, CCIE R&S, CCIE SP, CCIE DC, DCUFD e DCUCD

Leave a Reply

Your email address will not be published. Required fields are marked *

*