A inovação na Internet, uma história de adaptação constante e soluções sob medida

O mais interessante derivado desse modelo foi o conceito de “camada”:  se os dados entre os dispositivos viajam através de alguma forma de meio físico (conexão elétrica) … como esses sinais se tornam efetivamente uma página da Internet? A resposta é que vão percorrendo uma série de camadas e cada uma dessas camadas vai adicionando uma funcionalidade. A camada física (responsável pelos equipamentos físicos e por possibilitar a transferência de dados, como cabos e roteadores, onde os dados se convertem em fluxo bits).  Depois a camada de enlace de dados (responsável pela transferência de informação na mesma rede e pelo controle dos erros e do fluxo de dados) e a camada de rede (responsável pela divisão dos dados no dispositivo do remitente e por repô-los no dispositivo do destinatário quando a transmissão for entre duas redes distintas). O modelo completa-se com a camada de transporte, a camada sessão, a camada de apresentação e a camada de aplicação.

Se bem, o modelo OSI é em tese muito relevante, o que aconteceu com sua implantação concreta tem mais a ver com algo do tipo prático:  levou muito tempo escrever e definir todos os parâmetros, mas uma vez que o stack ficou completo e todas as definições estavam prontas, todo mundo já usava o protocolo TCP/IP.

Quero salientar que OSI chegou mais longe, definindo, até mesmo, protocolos de enlace e protocolos de redes, no entanto, a pesar do investimento de tempo e de dinheiro para a definição desses protocolos, eles não são utilizados, mesmo funcionando corretamente. O único que possui certa utilidade entre os usuários e que os puristas costumam dizer que são utilizados em redes telefônicas, é o protocolo IS-IS, um protocolo de porta de enlace interior (IGP) que usa informação de estado de vínculo para a tomada de decisões de roteamento.

Mas, o que quero dizer com isso? Que às vezes a perfeição é inimiga do que é bom. TCP/IP é o melhor protocolo que existe? Definitivamente não, tem problemas e contras, mas a verdade é que sempre esteve disponível quando as pessoas o precisaram. Imaginemosque naquele momento – quando surgiu a necessidade de interconectar os computadores – a solução era urgente, não dava para esperar que um padrão estivesse pronto. Se eu preciso conectar 20 ministérios ou 20 escritórios ou os computadores de uma universidade, será minha necessidade que determinará o ritmo.

Outro exemplo que ilustra esta questão é que a meados dos anos 90, quando o IETF percebeu que o IPv4 não era sustentável, organizou uma espécie de concurso de ideias acerca de como o IPv4 deveria evoluir. Uma das propostas era utilizar ConnectionLess Network Protocol (CLNP), um protocolo utilizado por OSI para transportar dados e indicação de erros no nível da rede. No seu funcionamento é muito parecido ao IP, porém hospeda endereços maiores, de forma que permite resolver essa conjuntura. No entanto, o que aconteceu é que, se bem existia algo de experiência de trabalho com esse protocolo, praticamente não existiam implementações.

Além disso, no que diz respeito ao CLNP, influiu definitivamente a ausência de um padrão aberto. A existência de processos abertos é fundamental em toda a história de inovação da Internet.  Diferente dos entornos fechados e definidos, os abertos permitem que muitas mais pessoas participem nas decisões e estão disponíveis gratuitamente para sua adoção, implantação e atualização. Dentro de uma indústria as empresas compartilham padrões abertos porque agregam valor a elas mesmas e a seus clientes. As normas costumam ser geridas em conjunto com uma base de partes interessadas. Em geral, existem regras sobre quais tipos de ajustes ou atualizações podem realizar os usuários para garantir que o padrão mantenha a interoperabilidade e a qualidade.

Tudo isso é assunto corriqueiro no âmbito das reuniões do IETF, que publica sua documentação técnica como RFC (“Solicitações de comentários” por suas siglas em inglês) onde são definidos os fundamentos técnicos da Internet, como as tecnologias de endereçamento, roteamento e transporte. Os RFC –que muitas vezes têm ressalvas por seu carácter de processo aberto – recomendam as melhores práticas operacionais e especificam protocolos de aplicação.

Voltando ao ponto central, quando tudo começou, lá por 1969, o stack de OSI possuía toda uma série de funcionalidades pensadas, especificadas e detalhadas, entretanto, quem enviou o primeiro pacote de dados via Internet precisava somente isso e nada mais. Com o tempo, à medida que a necessidade de interconexão foi avançando e evoluindo, as soluções foram se inventando sob medida. Isso ficou registrado em diversos RFC, como ocorrespondente ao primeiro protocolo de roteamento de Internet de 1988 (que surgiu de uma necessidade pontual de troca de rotas de informação entre portas de enlace e que depois resolveram documentar).

Em IP temos a discussão de que as coisas são “best effort”. Por exemplo: meu computador envia um pacote de dados sem ter certeza alguma de que esse pacote vai chegar a seu destino, basicamente funciona porque as leis da estatística estão em seu favor: para fazer com que 100 pacotes cheguem, é preciso transmitir 110. O mais importante aqui é que o modelo funciona bem e de maneira econômica, que é uma das coisas que o diferencia dos outros protocolos. Friso, desta forma, que o stack OSI também é um modelo de pacotes e não de circuitos, porém possui muita camada de controle que aumenta a complexidade para o usuário.

Como contraposição do que aconteceu com OSI, por exemplo, o ponto central aqui é a janela de possibilidade: as pessoas precisam ter as coisas no momento exato em que as coisas são requeridas e isso foi o que caracterizou e marcou a atividade dos pioneiros da Internet, que iam inventando as soluções em resposta a requerimentos pontuais. Distante dos condicionamentos de “cima para baixo”, a inovação que marcou a Internet foi muito mais adaptativa que padronizada e, em definitiva, foi isso que fez com que o modelo fosse muito mais ágil e bem-sucedido.