Podemos dizer que a função de qualquer rede é simplesmente transportar informações de um ponto a outro. Pode ser entre dois micros ligados através de um simples cabo cross-over, ou pode ser entre dois servidores situados em dois continentes diferentes. Do ponto de vista do sistema operacional e dos aplicativos, não faz muita diferença.
No nível mais baixo temos os cabos de rede, que são enquadrados no primeiro nível do modelo OSI (camada física) e se destinam unicamente a transportar os impulsos elétricos de um micro a outro. Ao utilizar uma rede wireless ou cabos de fibra óptica, os sinais são transmitidos (respectivamente) na forma de sinais de rádio ou luz, mas a função básica (transportar dados de um ponto a outro) continua a mesma, independentemente da mídia utilizada.
Em seguida temos os switches ou hub-switches que utilizamos para interligar os micros da rede local. Na verdade, o termo “hub-switch” foi inventado pelos fabricantes para diferenciar os switches mais baratos, que carecem de funções mais avançadas dos switches “de verdade”, que possuem mais portas e incluem interfaces de administração elaboradas.
O termo “switch” está mais relacionado ao modo de funcionamento do aparelho e não ao seu custo ou funções. Um switch é capaz de encaminhar os frames Ethernet para o destinatário correto, fechando “circuitos” entre as duas portas envolvidas, enquanto um hub antigo simplesmente repete os sinais recebidos em todas as portas.
Assim como as placas de rede, os switches trabalham no nível 2 do modelo OSI (link de dados), enviando frames Ethernet e endereçando os outros dispositivos da rede usando endereços MAC ao invés de endereços IP. Só para efeito de comparação, os hubs “burros” trabalham no nível 1, assim como os cabos de rede. Eles são meros dispositivos de transmissão, que não realizam processamento.
Os frames Ethernet são “envelopes” para os pacotes TCP/IP. O aplicativo (um navegador, um servidor web, ou qualquer outro aplicativo transmitindo dados pela rede) envia os dados ao sistema operacional, que divide o stream em pacotes TCP/IP e os envia à placa de rede. As placas de rede (que não entendem o protocolo TCP/IP) tratam os pacotes como um fluxo de dados qualquer e adicionam mais uma camada de endereçamento, desta vez baseada nos endereços MAC dos dispositivos da rede, gerando o frame Ethernet que é finalmente transmitido. Ao chegar do outro lado, o “envelope” é removido e o pacote TCP/IP é entregue.
A transmissão de cada frame começa com o envio de 8 bytes, contendo um preâmbulo e uma sequência de inicialização. Ele serve para avisar outros micros da rede de que uma transmissão está prestes a começar. Estes 8 bytes iniciais não fazem parte do frame e são descartados pelas placas de rede depois de recebidos, por isso não aparecem no relatório mostrado por sniffers de rede, como o wireshark.
O pacote TCP/IP é incluído dentro do campo de dados, que pode incluir até 1500 bytes por frame. Pacotes maiores do que este valor precisam ser divididos em fragmentos com até 1500 bytes e enviados usando vários frames.
Junto com os dados é transmitido o cabeçalho do frame (14 bytes no total), que inclui o endereço MAC de destino, endereço MAC de origem e um campo para o tipo de dados e mais 4 bytes finais, que contém códigos de CRC, usados (pelas placas de rede) para verificar a integridade do frame recebido. Este cabeçalho é também chamado de “MAC Header”. Ao receber cada frame, a placa de rede usa os 4 bytes (32 bits) de CRC para verificar a integridade do frame recebido e, caso ele esteja corrompido ou incompleto, ela o descarta e solicita sua retransmissão.
Dentro do pacote TCP/IP temos novos headers, que contém 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.
O limite de 1500 bytes para o conteúdo dos frames foi criado originalmente como parte das especificações do padrão 10BASE-5, o padrão Ethernet original, de 10 megabits. A idéia era que frames muito grandes agravariam o problema das colisões, permitindo que uma única estação utilizasse o cabo durante um tempo muito longo. Além disso, frames maiores demorariam mais tempo para serem retransmitidos em caso de corrupção do conteúdo, de forma que os 1500 bytes foram aceitos como o melhor custo-benefício.
O problema é que, de lá pra cá muita muita coisa mudou. O cabeamento evoluiu, a velocidade das redes aumentou para 100, 1000 e agora para 10000 megabits (1000 vezes a velocidade do padrão original!) e, com a substituição dos hubs burros por switches, as colisões de pacotes deixaram de ser um problema.
Em uma rede de 10 megabits, é possível transmitir 819 frames com 1500 bytes de dados por segundo (lembre-se de que cada frame precisa de 26 bytes adicionais, que incluem os endereços, códigos de CRC e os demais componentes), o que faz com que cada frame demore 1221 nanosegundos para ser transmitido. Em uma rede Gigabit Ethernet, onde a velocidade é 100 vezes maior, o tempo de transmissão de cada frame cai para apenas 12 nanosegundos.
Como o processo de verificação do conteúdo dos frames consome processamento, trabalho que aumenta proporcionalmente conforme aumenta o volume de frames transmitidos, a velocidade das transferências acaba sendo limitada não apenas pelo desempenho das placas, mas também pelo desempenho do processador principal.
Nas redes de 10 e 100 megabits isso não chegava a ser um grande problema, mas a popularização das redes Gigabit Ethernet trouxe o assunto à tona. Percebendo a possibilidade de melhorarem o desempenho de seus produtos, muitos fabricantes passaram a desenvolver extensões proprietárias, que permitem utilizar frames maiores e assim reduzir o overhead. Estes frames gigantes são chamados de jumbo frames.
Inicialmente, estes diferentes padrões eram incompatíveis, mas, com o passar do tempo, os fabricantes concordaram em padronizar o tamanho em 9000 bytes, o que permitiu a interoperabilidade entre produtos de diferentes fabricantes.
A idéia é que o processamento necessário para verificar o CRC de um frame de 1500 bytes de dados não é muito diferente do para verificar um de 9000 bytes, de forma que o uso do processador decai brutalmente com a redução no número de frames transmitidos. Outra vantagem é que recheando cada frame com mais dados, a perda causada pelos 26 bytes adicionais decai proporcionalmente, melhorando o desempenho da rede.