Uma coisa que é rotineiramente ensinada aos novatos em protocolos de rede, e escrita em praticamente todos os compêndios a respeito do assunto, é que TCP é um protocolo "com conexão" e UDP é um protocolo "sem conexão".
Num contexto maior, também ensinamos que antes da comunicação baseada em pacotes de dados (que hoje é prevalente), havia a comunicação baseada em circuitos, ou seja, linhas telefônicas (mediante discagem ou privativas). Também existe a tendência de dizer que linha telefônica é uma conexão, enquanto na comunicação por pacotes 'não há' conexão.
O primeiro exemplo didático que se costuma dar para comunicação por datagrama ("sem conexão"), é a carta enviada pelo correio, que não tem garantia de entrega, e o tempo de entrega é apenas melhor esforço (ou seja, depende do bom humor do Correio).
Agora, quem disse que não há conexão entre remetente e destinatário? É claro que há. A questão é que o Correio não toma conhecimento dela; apenas transmite cartas. E isto não é ruim; pelo contrário, é bom, pois eu posso mandar cartas para milhares de pessoas diferentes sem que eu precise dizer ao Correio porque estou fazendo isso.
O mesmo aplica-se a diferença entre linha telefônica (privada ou comutada) e pacotes de dados. Quando dois terminais comunicam-se usando pacotes de dados, é claro que existe uma conexão entre esses dois terminais. De outro modo, por que eles estariam trocando dados, se não houvesse interesse mútuo nisso?
A diferença é que, numa ligação telefônica, a companhia telefônica "sabe" que essa conexão existe, e é diretamente responsável por ela. Além disso, cada conexão serve apenas para uma dupla (ou tupla) de terminais. Se João precisa falar com Maria e também com José, precisa estabelecer duas conexões separadas. Mesmo que ele use cada uma delas 50% do tempo, ele paga por minuto, pelas duas ligações.
Já num serviço de pacotes de dados, a infra-estrutura é análoga à do Correio: ela só promete entregar pacotes ao destino, sem confirmação, na base do melhor esforço. O serviço de dados não quer nem saber se dois terminais vão trocar 1 ou 1 milhão de pacotes entre si. A responsabilidade de criar e manter as conexões é do terminal, não do serviço. Isto sobrecarrega o terminal. Por outro lado, a maioria dos serviços de dados custa o mesmo, esteja você comunicando com 1, 10 ou 1000 interlocutores diferentes.
No caso dos protocolos TCP/IP, a responsabilidade de manter a conexão é sempre do terminal. Resta saber que parte do software que roda no terminal (sistema operacional ou aplicação) vai tomar conta disso.
No caso do TCP, o sistema operacional é o responsável por manter a conexão entre os terminais. Isto facilita a vida da aplicação. Por exemplo, quem desenvolve um browser não precisa tratar coisas como perdas de pacotes e retransmissões. Isto é muito conveniente, evita muita duplicação de código, e o protocolo TCP é utilizado sempre que possível.
Já o protocolo UDP transfere a responsabilidade da conexão para a aplicação. Isto torna o desenvolvimento da mesma bem mais complicado, e bem mais difícil de "fazer direito". Por outro lado, há situações em que isto é necessário e conveniente.
Por exemplo, quando um serviço atende milhões de clientes num curto espaço de tempo, trocando mensagens curtas, UDP é muito melhor que TCP, pois em geral os sistemas operacionais têm limites no número de conexões TCP, enquanto uma aplicação pode usar memória virtual e controlar milhões de conexões UDP sem maiores problemas. É por isso que serviços como DNS utilizam UDP.
Outro motivo para usar UDP é delegar o controle de congestionamento à aplicação. TCP faz controle de congestionamento, mas o faz de um jeito que é inadequado para serviços como multimídia e voz sobre IP. UDP permite delegar tal controle à aplicação.
O último motivo para utilizar-se UDP em vez de TCP é o uso de multicast/broadcast. Analogamente a uma ligação telefônica, TCP "custa" muito para conectar com diversos clientes ao mesmo tempo. E quando o serviço manda dados majoritariamente numa única direção, é mais econômico utilizar broadcast e multicast, pois permite atingir inúmeros destinatários, custando uma única transmissão ao remetente.
Existem tentativas de adicionar-se suporte a multicast a protocolos confirmados, caso do XTP. Mas está longe de ser algo largamente adotado.
Mas o fato é que é errado rotular UDP de um serviço "sem conexão". A conexão sempre existe; a questão é quem toma conta dela.
De modo geral, quanto mais empurra-se a responsabilidade da conexão para a aplicação que roda no computador do usuário final, mais barato é o serviço, menor é sua confiabilidade, e mais flexível é o seu uso.
Assim, temos os serviços a seguir numa ordem decrescente de responsabilidade pela conexão:
* broadcasting (TV ou rádio);
* linha privada implantada pelo próprio usuário (raro);
* linha privada da telecom;
* linha discada ou ISDN da telecom;
* X.25 da Embratel;
* Internet, TCP;
* Internet, UDP.
A tendência geral é a migração de todo e qualquer serviço de dados para a Internet. Apesar da confiabilidade menor que as outras alternativas, é a mais flexível. E o contínuo investimento na Internet, tanto na melhoria do serviço em si quanto nos algoritmos que rodam nos terminais têm aproximado a qualidade de serviço das demais opções. Há uns oito ou nove anos atrás, VoIP era uma mera curiosidade, um brinquedo. Hoje em dia, todo mundo usa, até mesmo as telecoms.
Esta transferência de responsabilidade da conexão para o usuário do serviço é maravilhosa, pois é a liberdade de expressão ao extremo. Basta ter uma ADSL, e você pode comunicar-se com o mundo todo, em qualquer protocolo, sendo cliente ou servidor de qualquer serviço de dados. Talvez haja telecoms que registrem suas conexões TCP e UDP para fins forenses, mas isso tem antídoto fácil e rápido: criptografia e/ou protocolos exóticos. O gênio está fora da garrafa.
Por outro lado é algo assustador, pois existem inúmeros mecanismos sociais que perdem parte considerável da sua força num mundo assim. Quantos políticos já não foram "enquadrados" por conta das suas ligações telefônicas? E se eles estivessem usando VoIP? É bem verdade que provavelmente todos os serviços VoIP mantém registros das ligações, porém a tendência a longo prazo é o VoIP independer de serviços centrais (embora requisitar uma informação destas para a Skype que é sediada em Luxemburgo deva ser uma epopéia judiciária).
Skype funciona bem, mas no fundo é um subproduto dos roteadores NAT e da necessidade de conectar-se a telefones convencionais (SkypeOut). Num mundo ideal futuro, ("imagine all the people...") vamos usar IPv6 e usaremos telefones SIP que discam diretamente uns para os outros, sem necessidade de serviços intermediários.
Naturalmente, as autoridades policiais perdem uma ferramenta mas têm ganhado outra, que é o uso cada vez mais raro do dinheiro vivo em favor das operações on-line. Até alguém inventar o e-money. Na verdade o que falta ao e-money é disseminar seu uso, porque ele está inventado.
