root@blog:/# chmod o+r *

Leia as partes anteriores desse curso antes de prosseguir

Galera, muitas reviravoltas na minha vida! Quase não to aparecendo no Forum, daqui a pouco me destituem do cardo de Moderador Acabei me envolvendo em outros projetos, tenho um monte de curso pendentes!

Achei que essa semana ia passar batido sem o curso de redes! Mas ainda bem que consegui recuperar parte do conteúdo do meu TCC e extraí de lá parte desse conteúdo de TCP! Então talvez vocês notem uma diferença no mode de escrever em alguns trechos!

Vamos lá que TCP não é simples não...

Transmission Control Protocol (TCP)

O TCP (Protocolo de Controle de Transmissão) foi projetado para oferecer um fluxo de bytes fim a fim confiável em uma inter-rede não confiável. Ele é um protocolo orientado a conexão que permite a entrega sem erros de um fluxo de bytes originado de uma determinada máquina para qualquer computados da rede. Esse protocolo fragmenta o fluxo de entrada em mensagens e passa cada uma delas para a camada de redes. No destino, o processo TCP remonta as mensagens recebidas gerando o fluxo de saída. O TCP foi projetado para se adaptar dinamicamente às propriedades da camada de rede e ser robusto diante dos muitos tipos de falhas que podem ocorrer.

O TCP foi formalmente definido na RFC 793, posteriormente alguns erros foram corrigidos e o TCP foi definido na RFC 1122. O protocolo TCP define um cabeçalho para suas mensagens composto dos seguintes campos:

http://under-linux.org/members/magnu...ecalho-tcp.png
Cabeçalho TCP

• Porta de Origem e Porta de Destino – identifica os pontos terminais locais da conexão;
• Número de Seqüência – Identifica o fragmento dentro de todo o fluxo gerado;
• Numero de Confirmação – Indica qual o próximo byte esperado;
• Tamanho do Cabeçalho – Informa quantas palavras de 32 bits compõem o cabeçalho TCP;
• URG – Indica a utilização do urgent pointer;
• ACK – É utilizado para indicar que este segmento é um ACK e que o campo Número de Confirmação deve ser interpretado;
• PSH – Indica que este segmento não deve ser enfileirado como todos os outros, mas sim posto à frente na fila;
• RST – É utilizado para reiniciar uma conexão que tenha ficado confusa devido a falhas no host ou por qualquer outra razão;
• SYN – Este bit é utilizado para indicar um pedido de conexão e a confirmação da conexão;
• FIN – Utilizado para indicar que o emissor não possui mais dados para enviar e deseja finalizar a conexão;
• Tamanho da Janela – Indica quantos bytes podem ser enviados a partir do byte confirmado. Este campo é utilizado no controle de fluxo do TCP;
• Checksum – Indicador de integridade do segmento;
• Urgent Pointer – Indica um deslocamento de bytes a partir do número de seqüência atual em que os dados urgentes devem ser encontrados;
• Opções – Projetado para que o TCP possa oferecer recursos extras que não foram previstos em seu protocolo;

Estabelecimento de Conexões

O estabelecimento de uma conexão TCP ocorre antes que qualquer outro recurso TCP possa começar seu trabalho. O estabelecimento da conexão se fundamenta no processo de inicialização dos campos referentes à seqüência, aos ACKs e na troca dos números de sockets usados. As conexões são estabelecidas no TCP por meio do three way handshake (handshake de três vias).

http://under-linux.org/members/magnu...-handshake.png
Three Way Handshake

O estabelecimento da conexão é feito usando dois bits na cabeçalho TCP: SYN e ACK. Um segmento que possua a flag SYN ativa sinaliza uma requisição de sincronia do número de seqüência. Essa sincronização é necessária em ambos os sentidos, pois origem e destino utilizam números de seqüência distintos. Cada pedido de conexão é seguido de uma confirmação utilizando o bit ACK. O segundo segmento do three way handshake exerce as duas funções ao mesmo tempo: Confirma a sincronização do servidor com o cliente e requisita a sincronização do cliente com o servidor.

É interessante aqui analisar a imagem acima. Basicamente o Three way handshake ‘simula’ um acordo. O Cliente pergunta pro servidor: “Você está ai?” e servidor responde: “Sim estou...”. Depois o servidor pergunta: “Você está ai?” e o cliente responde: “Sim estou...”. Mas perai! Como tem 4 sentenças em apenas 3 trocas de mensagens?? Simples, a segunda mensagem contém uma resposta e uma pergunta. Como podemos verificar isso?? Através das Flags:

Cliente: Servidor, você está ai?? (SYN)
Servidor: Sim estou... (ACK) E você, está ai? (SYN)
Cliente: Sim, estou... (ACK)

Deu pra entender ne?! Mas porque o servidor precisa perguntar se o cliente está lá?? Pela simples necessidade de sincronização do número de seqüência. O número de seqüência é utilizado para garantir a entrega de todas as mensagens. Vamos imaginar da seguinte forma:

Cliente: Cambio servidor, mensagem 200 (Numero de seqüência do cliente), o senhor está disponível (SYN)?
Servidor: Positivo cliente! Mensagem 1450 (Numero de seqüência do servidor) Prossiga com a mensagem 2001 (ACK=201), cambio.
Cliente: Positivo servidor! Mensagem 201 (numero de sequencia), confirmando número da próxima mensagem: 1451, cambio!

Dessa forma eles trocam o número de seqüência, que tem como função “enumerar” as mensagens de cada um. Por exemplo, se a última mensagem foi a 201 e a mensagem que chegou pro servidor foi a 203, ele tem completa certeza que uma mensagem (202) se perdeu no caminho! Então basta somente solicitar uma retransmissão. O número de seqüência nem sempre é incrementado por 1, ele pode ser incrementado com base no número de bytes enviados pela origem.

O ACK tem como objetivo solicitar a continuidade das mensagens. Podemos interpretar um ACK=210 como sendo: “Pronto, recebi até a 209, pode mandar a 210”. Isso vai ser demonstrado com mais calma para frente.


Recuperação de Erros

O TCP também proporciona uma transferência confiável de dados, o que também é chamado de confiabilidade ou recuperação de erros. Para conseguir a confiabilidade o TCP enumera os bytes de dados usando os campos referentes à seqüência e aos ACKs no cabeçalho TCP. O TCP alcança a confiabilidade em ambas as direções, usando um campo referente ao número de seqüência de uma direção, combinado com o campo referente ao ACK na direção oposta.

http://under-linux.org/members/magnu...6-4-ack-ok.png
ACKs TCP sem erros

Como dito anteriormente o campo ACK implica o próximo byte a ser recebido. O número de seqüência indica o número do primeiro byte do segmento correspondente à sua posição no fluxo de dados

http://under-linux.org/members/magnu...4-ack-erro.png
ACKs TCP com erros

Controle de Fluxo

O TCP implementa o controle de fluxo utilizando os dados dos campos Número de Seqüência, Número de Confirmação e Tamanha da Janela. O controle de fluxo no TCP pode utilizar uma janela de tamanho fixo ou uma janela deslizante.
O campo Tamanho da Janela indica, em tempo real, o número máximo de bytes sem confirmação que podem ser enviados. Com a utilização de janelas um emissor só poderá enviar o número de bytes, previsto na janela, antes de receber alguma confirmação.

http://under-linux.org/members/magnu...anela-fixa.png
Comunicação com janela fixa

Podemos interpretar a imagem a cima da seguinte forma:

O Cliente fala pro servidor: Olha servidor, to meio ocupado mas quero continuar esse donwload. Então não me envia mais que 3000 (tamanho da janela) bytes não confirmados OK??

O servidor enviar 3 pacotes cada um com 1000 bytes, mas por algum motivo o primeiro chega mais rápido e os dois últimos demoraram um pouco.

O cliente recebe o pacote de seqüência 1000 espera e não recebe mais nada. Então ele envia uma confirmação: “Bora ai cara!! Eu falei 3000!! Só recebi 1000, manda o próximo (ACK)”

O servidor recebe esse ACK e verifica que enviou 3000 mas só 1000 foram confirmados, ou seja tem 2000 não confirmados e 1000 de espaço livre. Então ele envia mais 1000.

O cliente de repente recebe todos os pacotes, então ele responde: “Beleza, recebi até o 4000, manda o 5000!!! (ACK)”

Então o servidor manda mais 3000 bytes.

Caso o protocolo TCP esteja utilizando janelas deslizantes o tamanho da janela irá variar ao longo de uma transmissão. Ao iniciar uma conexão a janela começa pequena e aumentará gradativamente até que ocorram erros ou o destinatário seja sobrecarregado. Ao serem detectados erros a janela diminui, após um tempo o tamanho da janela começa a aumentar novamente. Caso o destinatário perceba uma sobrecarga, no próximo ACK enviado por ele haverá um novo tamanho de janela, o qual ele acredita ser apropriado para sua recuperação. Caso seja enviado um valor igual à zero o destinatário esta informando que não possui condições de processar mais dados e a comunicação estará suspensa até que o remetente receba um tamanho de janela diferente de zero.

http://under-linux.org/members/magnu...deslizante.png

Comunicação com janela deslizante

Aqui vemos uma inicio com uma janela de 2000, logo depois sendo incrementada pra 3000. Como houve um timeout, o cliente imagina que pode ter havido algum problema e solicita a redução do tamanho da janela para 2000. Como ele percebeu que tudo ocorreu bem, ele solicita uma aumento para 4000.

É por causa desse comportamento que o tempo de download nunca é confiável, pois o número de bytes transmitidos é variável. E também por isso que no início o download começa com uma taxa de transferência baixa e vai aumentando aos poucos


Finalizando Conexões

A finalização de uma conexão TCP é feita por meio de uma confirmação de três ou quatro vias. Nela é utiliza a flag FIN para indicar um pedido de desconexão. Este procedimento deve ser feito em ambas as direções.

http://under-linux.org/members/magnu...38-4-fin-3.png
Finalização em três vias

http://under-linux.org/members/magnu...39-4-fin-4.png
Finalização em quatro vias