Uma revisão sobre o TCP/IP.txt

Todos os dados transmitidos através da Internet são agrupados em pacotes TCP que, que podem conter até 1460 bytes de dados. Além dos dados, cada pacote inclui 40 bytes adicionais, contendo o endereço IP de origem, endereço IP de destino, porta de origem, porta de destino, códigos de verificações, número do pacote, campo para inclusão de opções e assim por diante.

No total, temos 20 bytes para os headers do protocolo TCP e mais 20 bytes para os headers do protocolo IP, totalizando 40 bytes de headers por pacote. Desta forma, temos 1460 bytes de dados em um pacote de 1500 bytes e 536 bytes de dados em um pacote de 576 bytes.

À primeira vista, pode parecer estranho que sejam incluídos headers separados para o TCP e o IP, mas a verdade é que os dois são complementares e por isso não podem ser dissociados. É por isso que usamos o termo “TCP/IP”, como se os dois protocolos fossem uma coisa só.

Os headers do protocolo IP incluem o endereço IP de origem e de destino, enquanto os headers do TCP incluem a porta de origem e de destino, por exemplo. Em resumo, podemos dizer que o IP se encarrega da entrega dos pacotes, enquanto o TCP se encarrega da verificação de erros, numeração de portas e outras funções (na verdade, o protocolo TCP/IP permite o uso de pacotes com até 64 kbytes, mas o tamanho de pacote mais usado é de 1500 bytes, que equivalem ao volume de dados que podem ser transmitidos em um único frame Ethernet. Como mesmo dentro de um datacenter são usadas placas de redes e switchs para ligar os servidores aos roteadores da rede, acaba sendo inviável utilizar pacotes maiores).

Em um pacote de 1500 bytes, temos até 1460 bytes de dados e 40 bytes referentes aos headers IP e TCP. Arquivos e outros tipos de informações são transmitidas na forma de sequências de vários pacotes. Um arquivo de 15 KB, por exemplo, seria dividido em um total de 11 pacotes; os 10 primeiros contendo 1460 bytes cada um e o último contendo os últimos 760 bytes. É graças aos códigos de verificação e numeração dos pacotes que arquivos grandes podem ser transmitidos de forma íntegra mesmo através de conexões via modem ou links wireless, onde diversos pacotes são corrompidos ou perdidos. Basta retransmitir os pacotes extraviados ou danificados quantas vezes for necessário.

O tamanho dos pacotes pode variar também de acordo com o meio de transmissão usado. No ADSL PPPoE, por exemplo, são utilizados pacotes de 1492 bytes, pois o protocolo usado demanda o uso de 8 bytes adicionais para o header. Nas conexões discadas, onde a conexão é mais lenta e a perda de pacotes é mais comum, são geralmente utilizados pacotes de apenas 576 bytes. Existem ainda casos de pacotes maiores, utilizados em situações específicas.

Depois dos endereços IP, usados para endereçar os hosts na Internet e nas redes locais, temos as portas TCP, usadas pelos diferentes serviços e programas que transmitem dados através da rede.

Existem 65.536 portas TCP, numeradas de 0 a 65535. Cada porta pode ser usada por um programa ou serviço diferente, de forma que em teoria poderíamos ter até 65536 serviços diferentes ativos simultaneamente em um mesmo servidor, com um único endereço IP válido. As portas TCP mais usadas (também chamadas de “well known ports”) são as portas de 0 a 1023, que são reservadas para serviços mais conhecidos e utilizados, como servidores web, FTP, servidores de e-mail, compartilhamento de arquivos, etc. A porta 80, por exemplo, é reservada para uso de servidores web, enquanto a porta 21 é a porta padrão para servidores FTP. A porta “0” é reservada, por isso não entra realmente na lista.

Além do endereço IP, qualquer pacote que circula na Internet precisa conter também a porta TCP a que se destina. É isso que faz com que um pacote chegue até o servidor web e não ao servidor FTP instalado na mesma máquina.

Além das 65.536 portas TCP, temos o mesmo número de portas UDP. O UDP oferece uma forma alternativa de envio de dados, onde em vez da confiabilidade é privilegiada a velocidade e a simplicidade.

No TCP, os dados são transmitidos através de conexões. Tudo começa com o cliente enviando o pacote “SYN”, que solicita a abertura da conexão. Caso a porta esteja fechada, o servidor responde com um pacote “RST” e a conversa pára por aí. Caso, por outro lado, exista algum servidor disponível na porta solicitada (um servidor http, por exemplo), então ele responde com outro pacote “SYN”, seguido de um um pacote “ACK”, avisando que a porta está disponível e prosseguindo com a abertura da conexão.

O cliente responde então com outro pacote “ACK”, o que abre oficialmente a conexão. Começa então a transferência dos dados, que são organizados em pacotes. O protocolo TCP/IP permite o uso de pacotes com até 64 kbytes, mas normalmente são usados pacotes com até 1500 bytes, que é o tamanho máximo de um frame Ethernet. Pacotes maiores podem ser transmitidos normalmente através da rede, mas precisam ser fragmentados, ou seja, divididos em pedaços menores, com até 1500 bytes.

Para cada pacote recebido, a estação envia um pacote de confirmação e, caso algum pacote se perca, ela solicita a retransmissão. Cada pacote inclui 4 bytes adicionais com um código de CRC, que permite verificar a integridade do pacote. É através dele que o cliente sabe quais pacotes chegaram danificados.

Depois que todos os dados são transmitidos, o servidor envia um pacote “FYN” que avisa que não tem mais nada a transmitir. O cliente responde com outro pacote “FYN” e a conexão é oficialmente encerrada.

Graças a tudo isso, a confiabilidade é muito boa. Quando a conexão está ruim, é normal ocorrerem mais perdas de pacotes e retransmissões, mas as corrupções são geralmente causadas pelo próprio programa que está baixando o arquivo e não pelo protocolo. O problema é que toda esta formalidade torna as transferências um pouco mais lentas. Imagine que, para transmitir uma mensagem de texto com 300 bytes, via TCP, seria necessário transmitir um total de 9 pacotes! Veja um exemplo de como a transmissão funcionaria:

Estação: SYN (solicita a abertura da conexão)
Servidor: SYN (confirma o recebimento e avisa que a porta está disponível)
Servidor: ACK (inicia a conexão)
Estação: ACK (confirma)
Estação: DATA (é enviado o pacote com a mensagem de texto)
Servidor: OK (a confirmação, depois de verificar a integridade do pacote)
Estação: FYN (solicita o fechamento da conexão)
Servidor: FYN (confirma)
Estação: FYN (confirma que recebeu a confirmação)

No UDP, as coisas são mais simples. Nele não existe abertura de conexão, os pacotes são transmitidos diretamente. A estação solicita alguma informação e o servidor envia a resposta. Assim como no TCP, são usados pacotes de até 1500 bytes (o protocolo permite o uso de pacotes com até 64 kbytes, mas, assim como no caso do TCP eles são raramente usados devido ao limite de tamanho dos frames Ethernet), contendo os bits adicionais de verificação. A estação pode verificar a integridade dos pacotes, mas não tem como perceber se algum pacote se perdeu, ou solicitar a retransmissão de um pacote corrompido. Se um pacote se perde, fica por isso mesmo.

Um exemplo típico de uso do UDP é o streaming de vídeo e audio via web, uma situação onde o que vale é a velocidade e não a confiabilidade. Você não gostaria nada se o navegador parasse a exibição do vídeo para solicitar uma retransmissão cada vez que um pacote se perdesse ou chegasse corrompido. É preferível que ele pule o quadro e continue exibindo o restante do vídeo.

Outra aplicação comum são os servidores DNS. Sempre que você acessa um site, a solicitação do endereço IP referente ao domínio do site e a resposta do servidor são enviadas via UDP, para ganhar tempo. Ao configurar o firewall, é importante prestar atenção com relação ao uso do TCP ou do UDP, já que alguns protocolos (como no caso do DNS) utilizam uma combinação de portas TCP e UDP. Um bom exemplo é o Samba, que utiliza um total de 4 portas: 137 UDP, 138 UDP, 139 TCP e 445 TCP, usadas pelos protocolos SMB e CIFS, usados por ele.

As portas mais usadas em serviços disponibilizados para a Internet são a porta 22 (SSH), 21 (FTP), 25 (SMTP), 53 TCP e 53 UDP (DNS), 80 (HTTP), 110 (POP3), 123 UDP (NTP), 143 (IMAP) e 443 (HTTPS). A elas se somam portas como a 1194 UDP, usada pelo OpenVPN a porta 5901, usada pelo VNC e assim por diante.

Você pode ver uma lista longa e completa, com todos os serviços conhecidos e as portas utilizadas por cada um no: http://www.iana.org/assignments/port-numbers.

Além do TCP e do UDP, temos o ICMP (Internet Control Message Protocol), um protocolo de controle. Ao contrário do TCP e do UDP, o ICMP não é usado para a transmissão de dados, mas nem por isso deixa de desempenhar diversas funções importantes. A mais trivial delas é o ping (echo request), que usamos para verificar se uma determinada máquina está online e medir a latência da conexão.

Outra função importante do ICMP é o controle do TTL (time to live) de cada pacote TCP ou UDP. Os pacotes tem vida curta e sua única função é carregar os dados até o destino. Eles são transmitidos de um roteador a outro e, uma vez que chegam ao destino, são desmontados e destruídos. Mas, o que acontece em casos onde não existe uma rota possível até o destino, seja porque a máquina está desligada, por erro no endereçamento, ou por um problema em algum dos links?

Existem duas possibilidades. A primeira é um roteador próximo perceber que a máquina está fora do ar e destruir o pacote. Neste caso, ele responde ao emissor com um pacote ICMP “Destination Unreachable”, avisando do ocorrido. Caso isso não aconteça, o pacote fica circulando pela rede, passando de um roteador a outro, sem que consiga chegar ao destino final.

O TTL existe para evitar que estes pacotes fiquem em loop eterno, sendo retransmitidos indefinidamente e assim consumindo banda de forma desnecessária. Graças a ele, os pacotes têm “vida útil”.

O TTL default varia de acordo com o sistema operacional usado. No Windows XP o default são 128 hops, enquanto nas versões atuais do Linux os pacotes são criados com um TTL de 64 hops. Cada vez que o pacote passa por um roteador, o número é reduzido em um. Se o número chegar a zero, o roteador destrói o pacote e avisa o emissor enviando um pacote ICMP “Time Exceeded”.

Os pacotes ICMP “Time Exceeded” são usados pelo comando “traceroute” (no Linux) para criar um mapa do caminho percorrido pelos pacotes até chegarem a um determinado endereço. Ele começa enviando um pacote com um TTL de apenas 1 hop, o que faz com que ele seja descartado logo pelo primeiro roteador. Ao receber a mensagem de erro, o traceroute envia um segundo pacote, desta vez com TTL de 2 hops, que é descartado no roteador seguinte. Ele continua, enviando vários pacotes, aumentando o TTL em 1 hop a cada tentativa. Isso permite mapear cada roteador por onde o pacote passa até chegar ao destino.

Na Internet, os roteadores são espertos o suficiente para conhecerem os roteadores vizinhos e escolherem a melhor rota para cada destino. Sempre que um roteador fica congestionado, os demais passam a evitá-lo, escolhendo rotas alternativas. Essa comunicação é feita através de pacotes ICMP “Redirect”, que avisam o emissor que uma rota mais rápida está disponível e os pacotes seguintes devem ser encaminhados através dela.

Os pacotes ICMP são usados (durante as transferências de dados) também para regular a velocidade da transmissão, fazendo com que o servidor envie pacotes na maior velocidade possível permitida pelo link, sem entretanto sobrecarregar o link do cliente. Sempre que um dos roteadores pelo caminho, percebe que o link está saturado, envia um pacote ICMP “Source Quench”, que faz o servidor reduzir a velocidade da transmissão. Sem isso, os pacotes excedentes seriam descartados, causando um grande desperdício de banda.