Com certeza você já fez centenas ou milhares de downloads na internet. Independente do local onde estes arquivos estejam, no Brasil ou na Austrália, é comum notar que a taxa de transferência varia de uma hora para outra e que independente do tamanho, os arquivos chegam sem erros e prontos para serem instalados e usados.
Você já pensou na complexidade do processo de comunicação que possibilita que um arquivo de 600M (Matrix Reloaded, por exemplo), muito comum nas redes P2P como Edonkey e outras trafegue da Austrália até a sua máquina em Belo Horizonte, por exemplo, e seja imediatamente utilizado, possibilitando que você o assista como se o mesmo fosse retirado da vídeo locadora da esquina? Já imaginou a quantos KMs está a Austrália? (Acho que a uns 15.000 km).
Esta viagem é iniciada pelo protocolo IP que fica na responsabilidade de encontrar o destino, descobrindo a rota e escolhendo o melhor caminho e como chegar ao destino pelo menor esforço, ou seja, escolhendo os roteadores e caminhos mais rápidos e de menor tráfego (veremos os aspectos do funcionamento do IP e do processo de roteamento em artigos futuros).
O processo de download é inicializado pelo FTP que é uma aplicação que emprega o TCP como protocolo de transporte que fica responsável pelo “delivery” (entrega) dos dados no computador destino, independente aos inúmeros caminhos por onde estes pacotes passaram (responsabilidade do IP) e do tempo levado entre o destino e origem.
O TCP é um protocolo especializado em processar grandes volumes de dados, pois ele “quebra” qualquer quantidade de dados fornecida pela aplicação (O FTP no caso) em unidade de dados chamados de segmentos. A unidade de dados no protocolo IP se chama datagrama.
O TCP, sem nenhum medo de errar, é um dos mais impressionantes e maravilhosos protocolos existentes (não posso deixar de citar também o IP,o ICMP, o HTTP...). Algumas características do TCP, são:
ØOrientado a conexão ¾ Antes que qualquer dado seja transferido entre os hosts origem e destino as aplicações que realizarão o processo de comunicação através do TCP devem executar formalmente um processo de estabelecimento de sessão para que a troca de dados ocorra (nenhum dado é transferido sem que este procedimento seja executado). Existe também um procedimento formal de fechamento de sessão, que tem como função o termino da sessão e da aplicação iniciada.
ØFull duplex ¾ Quando dois hosts se comunicam através do TCP, é construído logicamente um canal de comunicação duplex e simultâneo entre os dois hosts.
ØConfiável ¾ Todo e qualquer segmento transmitido por um host é gerado um número de seqüência. É esperado que o host destino envie um ACK confirmando que o segmento transmitido chegou no host destino.
ØControle fluxo ¾ OTCP implementa um controle de fluxo evitando que um excesso de dados seja enviado simultaneamente pelos hosts o que poderia causar congestionamento nos host e nos roteadores que compõem a rede. O controle de fluxo, considera que os buffers dos hosts tem limitação evitando um estouro de buffer o que provocaria um desastre em toda rede.
ØRealiza retransmissão ¾ O TCP retransmite qualquer segmento com erro causado pelo cabeamento ou link de transmissão. O TCP também mantém um temporizador interno decrescente para todo segmento enviado. Se um ACK não for recebido até que este temporizador seja zerado, o host que enviou o segmento deverá retransmiti-lo.
Como você pode notar, o TCP é um protocolo bem complexo. Para entendermos como ele se comporta em uma rede LAN ou WAN, é necessário descreve-lo com mais detalhes já que a maioria dos serviços mais importantes em um ambiente de rede, como leitura e escrita em disco, impressão e transferência de grandes volumes de dados. O TCP controla os aspectos complexos da entrega dos dados que estes serviços processam.
Estabelecimento de uma sessão e troca de dados em uma conexãoTCP.
O estabelecimento de sessão é o primeiro procedimento realizado antes que qualquer dado seja transferido entre os hosts. Nenhum dado é trocado se este procedimento não for realizado. A indicação deste procedimento pode ser visto pelo flag SYN, que quando ativo, não deixa dúvidas que está acontecendo uma abertura de sessão. Para estabelecer uma sessão full-duplex TCP, cada host deve aprender, um do outro, as seguintes informações:
-Número de seqüência.
-O tamanho do Buffer que cada host tem para receber os dados.
-O máximo tamanho do segmento que pode ser recebido por cada host.
-As opções TCP suportadas.
Esses parâmetros são aprendidos no estabelecimento da sessão e é realizado através de um processo chamado de 3 way handshanking (3WHS) sendo necessário o tráfego de 3 segmentos para ser realizado. Nenhum dado é trocado enquanto esse procedimento não se realizar.
Para permitir uma conexão TCP no Servidor deve existir um serviço que habilite uma determinada porta, caso contrário o Servidor responderá com um RESET, indicando que não há serviço disponível nesta porta.
A figura abaixo demonstra o processo inicial para estabelecimento de uma sessão TCP.
A partir daí os hosts começam a trocar dados e os números de seqüência e ACK vão sendo incrementados, conforme pode ser observado no desenho abaixo.
Para todo segmento transmitido por um host deverá haver um ACK de resposta, indicando que o segmento chegou ok .
Processo de retransmissão TCP
O processo de retransmissão pode dizer muito da condição real da rede.
O TCP mantém um timer interno que é inicializado e decrementado no momento que um segmento é transmitido. Se houver algum problema no processo de comunicação como link ruim, cabeamento com problema, erro causado por ruído, ou alta latência na rede e o segmento chegar ruím, atrasado ou mesmo destruído, o Host destino simplesmente descartará este segmento, não enviando um ACK de resposta.
O que pode causar retransmissão em uma rede?
Infelizmente podem ser inúmeras as causas, como:
-Aplicações lentas e mal construídas. Muito comum em aplicações antigas como Cobol e Clipper.
-Redes com problemas na infra-estrutura física como cabeamento com problemas de ruídos e erros de transmissão.
-Dispositivos ativos (switches, hubs ) com problemas de hardware.
-Placas de rede com problemas de hardware
-Drivers de placas de rede.
-Excesso de tráfego.
-Redes com problemas de projetos.
-Etc, etc, etc....
Como verificar se sua rede está com problemas?
Utilize o comando netstat –s e verifique as estatísticas listadas. A estação ideal para se fazer o teste é em uma máquina que enxergue a rede inteira, por exemplo, um servidor.
Estatísticas de TCP
Abertos ativos = 489
Abertos passivos = 25
Falha em tentativas de conexão = 67
Conexões redefinidas = 143
Conexões atuais = 3
Segmentos recebidos = 10611
Segmentos enviados = 8872
Segmentos retransmitidos = 140
A listagem acima demonstra o resultado deste comando executado na minha máquina. Como você pode notar, existe uma quantidade de retransmissão e você sempre a verá, independente da máquina e do estado da rede na qual este comando seja executado.
Procedimentos:
1- Digite o comando netstat – s em qualquer máquina na rede:
2 - Verifique a estatística de retransmissão TCP.
3 – Se as retransmissões estão baixas e constantes (5% máximo dos segmentos transmitidos) existe algum problema mais não é grande o bastante para impactar a rede. Não perca tempo em analisar sua rede.
3- Digite o comando netstat –s 5 (este comando realizará um refresh a cada 5 segundos na tela). Se o numero de retransmissões estiver aumentando , provavelmente você está com problemas na sua rede e com certeza você já está sentido que a rede está lenta. Faça uma análise mais detalhada dos cabos, aplicações e dispositivos ativos. Uma boa ferramenta é um analisador de protocolos.
IMPORTANTE: ESTE PROCEDIMENTO NÃO LHE DARÁ AS RAZOES EXATAS DA LENTIDÃO DA REDE. SÃO PROCEDIMENTOS GENÉRICOS. PARA SABER AS RAZÕES EXATAS E DETALHADAS VOCÊ DEVERÁ REALIZAR UMA ANÁLISE LEVANDO-SE CONSIDERAÇÃO OS ITENS ACIMA LISTADOS.
Modo Linear
