Intelligent Routing Blog


Implicações técnicas do congestionamento da rede

02/07/2012

Durante a transferência de informações na Internet, há várias situações relacionadas com determinado host ou inacessibilidade da rede, ou sobrecarga de canais de comunicação. Nestes casos, ocorre uma perda de pacote, o que leva a retransmissão do quadro de dados já enviados ou reconhecimento (TCP ACK).

Estes dois casos levam à perda de pacotes e mais retransmissão de quadro de dados ou pacotes de reconhecimento (no caso do TCP ACK para a última janela de dados).

Vamos ver quando a perda de pacotes ocorre durante o início da sessão TCP:

14:53:15.994623 IP 10.1.1.100.54431 > 10.1.1.200.22: Flags [S], seq 392805912, win 14600, options [mss 1460,sackOK,TS val 301221205 ecr 0,nop,wscale 4], length 0

14:53:18.997924 IP 10.1.1.100.54431 > 10.1.1.200.22: Flags [S], seq 392805912, win 14600, options [mss 1460,sackOK,TS val 301221956 ecr 0,nop,wscale 4], length 0

14:53:25.013946 IP 10.1.1.100.54431 > 10.1.1.200.22: Flags [S], seq 392805912, win 14600, options [mss 1460,sackOK,TS val 301223460 ecr 0,nop,wscale 4], length 0

14:53:37.029939 IP 10.1.1.100.54431 > 10.1.1.200.22: Flags [S], seq 392805912, win 14600, options [mss 1460,sackOK,TS val 301226464 ecr 0,nop,wscale 4], length 0

Теxt 1: Listing of SYN blackout

Nesta lista pode ser visto que a falta de resposta a partir do lado oposto (proveniente do não-receptor do SYN inicial, ou por causa da não-resposta para confirmar a abertura da ligação SYN + ACK), a parte da realização da conexão, repete o envio de pacotes SYN na esperança de estabelecer uma conexão.

Além disso, considere a situação em que ocorreu perda de pacotes no momento em que a conexão é estabelecida. Aqui deve-se notar, separadamente, que em uma operação normal - quando esta opção é desativada e a ausência do TCP Keepalive de mecanismos para completar a inatividade de ligação TCP é estabelecida, a ligação TCP pode existir indefinidamente em caso de ausência de comunicação entre as partes remotas.

Por esta razão, a evidência de perda de pacotes pode ser detectada apenas quando é necessário passar para o próximo quadro de dados ou após ter recebido a confirmação para o quadro de dados:

14:48:41.417886 IP 10.1.1.100.56722 > 10.1.1.200.22: Flags [P.], seq 48:96, ack 97, win 4006, options [nop,nop,TS val 301152560 ecr 1835816346], length 48

14:48:49.925934 IP 10.1.1.100.56722 > 10.1.1.200.22: Flags [P.], seq 48:96, ack 97, win 4006, options [nop,nop,TS val 301154688 ecr 1835816346], length 48

14:49:06.949935 IP 10.1.1.100.56722 > 10.1.1.200.22: Flags [P.], seq 48:96, ack 97, win 4006, options [nop,nop,TS val 301158944 ecr 1835816346], length 48

14:49:40.997947 IP 10.1.1.100.56722 > 10.1.1.200.22: Flags [P.], seq 48:96, ack 97, win 4006, options [nop,nop,TS val 301167456 ecr 1835816346], length 48

Теxt 2: Blackout during TCP session

Esta relação mostra que o envio do quadro de dados (com a opção PSH ) não é suficiente, porque o computador não confirmou a recepção do quadro, de modo que o host de origem mantém o reenvio de pacotes perdidos.

Mecanismo de retransmissão na ausência de resposta esperada é regulado pela relevante RFC793

(Vale ressaltar que os mecanismos normais de transmissão de auto-velocidade são uma reação natural à perda de pacotes TCP).

Devido ao fato de que os pacotes de reenvio são realizados em intervalos regulares - não há uma fronteira clara entre a perda temporária de pacotes no caso de canais de comunicação sobrecarregados e completa falta de comunicação com um único host ou em uma determinada direção.

Assim, a diferenciação entre Apagão e Congestionamento pode ser expressa por considerar a informação estatística de perda de pacote, durante um período de tempo.

Como exemplo, podemos considerar um protocolo HTTP - 1-2% de perda de pacotes, em caso de congestionamento da rede pequena, quase não tem efeito sobre o desempenho do trabalho. No entanto, deve-se notar aqui que, por definição, o servidor para HTTP solicita muito mais conexão à rede do que para o navegador da Web - assim, a perda de pacotes ocorre sempre - mas não notamos, não é?

Isto é causado pelo fato de que o TCP foi concebido para resolver a situação de perda de pacotes - que é também um dos princípios da auto- limitação de velocidade de transferência de dados utilizando o protocolo TCP. Além disso, o tempo limitado para reenviar o pacote permite que o usuário não perceba a perda de pacotes.

Significativamente maior porcentagem de perda de pacotes levará a uma significativa cadeia de transmissão e como conseqüência - um grande impacto no desempenho da rede BGP.

Por outro lado - se você estiver usando o protocolo TCP para jogos on-line, o curto tempo de atraso de transferência de informação afeta muito a qualidade do serviço, uma vez que este tipo de informação impõe maiores exigências de qualidade, velocidade e mais importante - tempestividade da transferência de informação.

A perda de pacotes (apagão ou congestionamento) tem um impacto significativo sobre a qualidade de serviço na Internet. Por esta razão - o diagnóstico precoce e encaminhamento de soluções de otimização para a detecção de congestionamento de rede tem um grande impacto sobre a estabilidade da rede. Usando as soluções de engenharia de tráfego, como a Plataforma de Encaminhamento Inteligente pode levar à otimização da rede e evitar congestionamentos. A solução IRP está em usar sondagem ativa de rede para a detecção de congestionamento e usar inovações inteligente de encaminhamento contribuindo para a otimização da rede BGP. A Ferramento de Encaminhamento Inteligente pode ser usada como uma plataforma inteligente de encaminhamento BGP, a fim de aumentar o desempenho da rede. Além disso, a plataforma utiliza soluções líderes em custos de tráfego e compromete o controle para reduzir despesas.

Nota de rodapé
Pedido de Comentários - Conjunto de normas que regem o funcionamento técnico dos vários aspectos da Internet

‹  Back to the list