A Camada Transporte
Então cá estamos. O computador acabou de empurrar para fora do seu domínio aplicacional uma mensagem que se destina à rede.
Para isso colocou-a numa interface a que chamamos socket.
Socket é uma interface de comunicação entre uma aplicação e a rede. Um socket está associado a um porto e ambos constituem uma forma de comunicação do computador com o exterior. O endereço de um socket é a combinação do endereço IP da máquina com o porto.
Um porto é como uma porta imaginária na couraça da parte aplicacional do computador, ao qual se vai ligar um processo criado pelo Sistema Operativo a partir de uma aplicação de rede. Na Figura 1 tenta-se dar uma imagem gráfica deste relacionamento.
Numa definição mais correta, um porto corresponde a um ponto terminal de comunicações utilizado pelos protocolos de transporte TCP e UDP, a que está associado um processo específico (processos são programas que o Sistema Operativo tem em execução sob o seu controlo).
Um porto é identificado pelo seu número, por um endereço IP e pelo protocolo de transporte que o usa. O número de um porto é definido por 16 bits, pelo que vai desde 0 até 65.535:
- De 0 a 1.021 estão os chamados “Well Known Ports” (Portos bem conhecidos). Estão neste caso, por exemplo, os serviços Telnet (porto 23), SSH (porto 22), SMTP (porto 57), HTTP (porto 80), DNS (porto 53), FTP (portos 20 e 21), etc.
- De 1024 a 49.151 são os portos registados.
- De 49.151 a 65.535 são os portos livres para o utilizador.
Isto quer dizer, por exemplo, que se uma mensagem com o protocolo aplicacional HTTP for enviada a um computador com quem não tem comunicação preestabelecida, ela é enviada diretamente ao porto 80. Não adiantamos mais por agora pois já vamos abordar esta questão em concreto.
O sistema operativo está permanentemente à escuta de quem bate às suas diversas portas, para ir ver quem é e dar-lhe o devido encaminhamento dentro de casa.
Feita esta pequena e importante introdução vamos agora olhar para os serviços fornecidos pela camada de transporte.
Transporte pressupõe que leva e trás. Mas não é o caso desta camada. Ela presta efetivamente serviços de transporte, mas de transporte lógico entre processos em máquinas diferentes. Toda a lógica inerente às garantias da condição de transporte assenta nesta camada.
Vamos falar um pouco sobre pacotes aqui. A camada de enlace não transporta pacotes da dimensão que nós queremos, mas sim de uma dimensão máxima definida. No caso da Ethernet essa dimensão é de 1.500 Bytes, o que dá origem a um MSS (Maximum Segment Size) de 1460, caso os cabeçalhos das camadas de Transporte e Rede não tenham opções. Estes valores são negociados entre os terminais durante a apresentação. A esta dimensão de pacote chama-se MTU (Maximum Transfer Unit) e corresponde à dimensão máxima do Quadro.
Para obtermos a dimensão em bytes da mensagem HTTP que cada segmento da camada de Transporte pode conter, MSS, há que retirar a dimensão dos cabeçalhos desta e das camadas seguintes a MTU.
O pacote HTTP terá então que ser dividido em vários pacotes, que terão o nome de segmentos (o segmento é constituído pelo pedaço de mensagem HTTP mais o cabeçalho da camada de Transporte), tantos quantos os necessários para completar a dimensão do pacote HTTP não excedendo nunca a MSS em cada segmento.
Na Figura 2 ilustra-se graficamente a divisão da mensagem em segmentos, divisão que se vai manter durante todo o percurso até à sua reunião na mesma camada, no destinatário.
Digamos então que: a camada de transporte trata do acondicionamento da mensagem em pacotes com a dimensão possível, dá garantia que todos os pacotes são entregues, que o são pela ordem devida e que não há corrupção dos dados por ele transportados.
Imaginem pequenos carros que viajam na rede e que, porque têm espaço reduzido para transporte, só conseguem levar uma folha da nossa mensagem de cada vez. Logo, como a nossa mensagem tem 4 folhas, vai ter que ir em quatro carrinhos.
A partir daqui há que dizer aos motoristas dos carrinhos qual é o endereço de destino e pô-los na estrada a circular de cruzamento em cruzamento. Esta será a função das camadas seguintes. Mas a estrada está bastante congestionada, os motoristas conduzem a enorme velocidade, uns vão por um caminho, outros por outro, uns apanham mais trânsito que outros e atrasam-se, outros têm acidentes e perdem os pacotes, tendo que i rbuscá-los de novo, mas lá vão chegando ao destino e entregando cada um o seu pacote.
Agora surge o problema. As folhas da carta chegam fora de ordem, ou algumas mesmo não chegam.
Como é que o destinatário vai receber direito o que lhe enviei? Como é que ele vai pôr tudo por ordem e mesmo perceber se falta algum pacote?
Bom, graças aos serviços lógicos de transporte, o processo recetor consegue determinar isso tudo ao abrir os pacotes e depois resolver o problema: Pôr os pacotes por ordem e detetar a falta de algum para o voltar a pedir.
Por esta história, já deu para perceber que os serviços das camadas abaixo desta não dão qualquer garantia. Chama-se-lhes o serviço de entrega de melhor esforço (Best effort service), cujo objetivo é entregar o mais possível no menor tempo possível. É o caso do protocolo IP que funciona na camada de rede, logo abaixo da de transporte, e que se preocupa só com a entrega de máquina a máquina. Mas já lá vamos. Calma, porque devagar se vai ao longe.
Na internet são disponibilizados dois protocolos para a camada de transporte, que são
- o TCP (Transfer Control Protocol) e
- o UDP (User Datagram Protocol).
O TCP é um protocolo dirigido à conexão, fornece serviços de :
- multiplexação e desmultiplexação (entrega da mensagem ao protocolo devido na camada superior),
- controle de erro ou adulteração do conteúdo dos pacotes,
- controle da efetiva entrega de todos os pacotes,
- garantia de que quando os passa para a camada aplicação estão por ordem e
- controlo de congestionamento da rede, isto é, quando deteta que a rede está saturada, reduz o número de pacotes por unidade de tempo.
O UDP é um protocolo não dirigido à conexão, fornece serviços de multiplexação e desmultiplexação e controle de erro, mas mais nada, isto é, ele não acrescenta mais nenhum controlo à camada inferior.
O protocolo TCP é usado por todas as aplicações que pretendam transmissão confiável de dados, como é o caso das que são criadas em HTTP, SMTP, FTP, isto para falarmos das mais conhecidas.
O protocolo UDP é tipicamente usado para aplicações de vídeo, videoconferência e globalmente todas as aplicações que não sejam extremamente exigentes em termos de confiabilidade (note-se por exemplo que a perda de alguns pacotes numa transmissão vídeo é praticamente indetetável ao utilizador). Nestes casos, a maior simplicidade do transporte em UDP torna a circulação dos pacotes muito mais rápida. O facto de a entrega dos pacotes pela camada transporte à aplicação não se atrasar enquanto um pacote não chega, por exemplo, é muito mais importante para uma aplicação de tempo real. Um vídeo que está a ser recebido e visto simultaneamente, certamente é muito menos prejudicado pela falta de um pacote do que pelo atraso de todos.
Mas, para que isto possa ser bem entendido, temos que perceber primeiro o que envolve o transporte em TCP. Como este é o protocolo que vai ser utilizado no nosso caso de estudo, as referências ao UDP serão genéricas e sem pormenores.
Vamos então começar por entender como é estabelecida uma conexão TCP.
Como já dissemos, o Browser (o cliente) já empurrou o pacote HTTP para um socket. Sabido o IP do servidor o Browser envia um pacote ao servidor sinalizando que pretende estabelecer uma conexão com ele. O servidor, por sua vez, responde com um pacote de ACK (ACKnowledge) e finalmente o Browser envia mais um pacote de confirmação. Os dois primeiros pacotes não têm conteúdo, mas o terceiro já pode levar conteúdo.
Observação importante: Quando nesta fase falamos do estabelecimento de uma conexão TCP, é porque é fundamental para que se entenda este protocolo. No entanto, cada um destes pacotes que vamos ver a andar de um lado para o outro, vai ter que utilizar as camadas mais abaixo para que fisicamente chegue ao seu destino. Camadas cuja forma de funcionamento só mais à frente abordaremos.
O Formato de um Segmento TCP
Para já vamos ver como é a constituição de um cabeçalho de TCP, para que possamos perceber tudo o que a seguir abordaremos. Comecemos por traduzir os termos do quadro da Figura 3, que representa o formato de um pacote TCP, com os diferentes campos que o compõem.
Portos da fonte e destino – são as entradas e saídas do computador através das quais o TCP envia e recebe os dados referentes às aplicações que estão em comunicação. Pode haver muitas aplicações em comunicação simultaneamente, mas cada uma terá um porto diferente. É assim que o TCP sabe onde ir buscar ou colocar os pacotes que transporta de ou para uma determinada aplicação.
Número de sequência e número de reconhecimento – são dois identificadores numéricos que vão ser utilizados para confiabilidade da entrega, no que diz respeito à garantia de entrega e de ordem de entrega. .
O campo de janela de receção é utilizado no controlo de fluxo e de congestionamento.
O campo de tamanho de cabeçalho é usado pelo TCP para saber qual a porção real de mensagem que contém e que deve entregar à aplicação. O Tamanho normal deste campo é de 20 Bytes, atendendo a que o campo de opções não é normalmente utilizado.
O campo de opções serve para os pontos terminais negociarem vários fatores, entre os quais o tamanho de MSS. Como já disse este campo raramente é utilizado.
Checksum é um campo de 16 bits usado como forma de verificação da integridade dos dados do pacote, isto é, se por influência de fatores externos, casuais ou não, algum ou alguns bits foram alterados. Vamos ainda neste parágrafo abordar este assunto.
A flag ACK é usada pelo destinatário para indicar ao remetente que recebeu um pacote em condições (o pacote é definido pelos números sequencial e de reconhecimento).
A flag SYN é usada nos primeiros pacotes de estabelecimento da comunicação.
A flag FIN é usada quando algum dos hospedeiros pretende encerrar a comunicação.
A flag RST é usada por um destinatário quando um pacote lhe bate num porto que ele não tem em serviço. Por exemplo, quando se tenta estabelecer uma conexão com um servidor Web no seu porto 80 e o servidor em questão não é um servidor WEB. Neste caso ele usa a flag RST, implementada a 1, para comunicar ao remetente que deve fazer um reset da conexão, pois está enganado. “Eu não tenho por aqui o serviço que tu queres”.
A flag PSH indica que um pacote deve ser passado imediatamente para a camada aplicação. Pode ser usada por exemplo em aplicações de tempo real em TCP, como forma de evitar a retenção de pacotes em buffer, ou em aplicações Telnet que ecoam os dígitos enviados um a um e que sem a implementação desta flag aguardariam que o buffer estivesse cheio para passarem a informação à aplicação.
A flag URG indica que um pacote contém dados urgentes. O campo Ponteiro de urgência indica o último Byte dos Dados urgentes (que deverá estar a partir do primeiro Byte de dados).
As flags NS, CWR e ACE só mais recentemente foram criadas e quando suportadas são utilizadas para controle de congestão de uma forma mais eficiente da utilizada anteriormente. O estudo do Controlo de congestionamento, uma das grandes tarefas do TCP, será feito mais adiante, depois de percebermos os aspetos de uma conexão TCP.
Conhecido o formato do cabeçalho do segmento TCP, vamos agora perceber como se estabelece, como se mantém e como se finaliza uma comunicação TCP. Convém relembrar que é o TCP que estabelece a forma de transmissão, mas que para que cada segmento de que vamos falar viaje pela rede, ele tem que atravessar as camadas abaixo para ser preparado para tal. Antes, uma pequena abordagem ao Checksum, tal como prometido.
Checksum
Existem vários algoritmos de checksum, com vários níveis de rigor e também de complexidade e tempos de execução. O checksum do TCP é pouco exigente, quando olhado pelos padrões atuais de segurança, sendo no entanto compensado pelos métodos de controle de erro das camadas abaixo, essencialmente na camada de enlace.
O checksum do TCP consiste em somar todo o conteúdo de palavras de 16 bits do segmento e depois fazer o complemento para 1 dessa soma. O resultado será o valor de Checksum. O destinatário soma de novo todas as palavras de 16 bits do segmento e ao total, soma o valor de Checksum. O resultado terá que ser uma palavra de 16 bits todos a 1. Se assim não for é porque algum foi alterado no percurso.
Vamos ver um exemplo, com um pacote com 4 palavras de 16 bits:
1001110001010001
1100100010100101 0110010011110110
0010100111110100 0010100111110100 1000111011101010
1110010110010010 1110010110010010
Soma das 4 palavras (Envio) 0111010001111100
Checksum (Complemento) 1000101110000011
Soma das 4 palavras (Receção) 0111010001111100
Soma Final 1111111111111111
Esta soma de binários já é familiar de muitos capítulos atrás. De qualquer forma relembramos que o complemento de 1 corresponde à inversão de todos os bits, o que se consegue pela aplicação de um operador XOR, fazendo a comparação com uma palavra de 16 bits todos a 1.