Duas bibliotecas, dois trabalhos diferentes
Quase todo desenvolvedor Delphi já usou o Indy em algum momento. Ele vem incluído na IDE, está por aí desde o final dos anos 1990 e uma geração de código de rede em Delphi foi construída sobre TIdHTTP, TIdTCPClient, TIdSMTP e companhia. O sgcWebSockets é uma biblioteca comercial bem mais recente, focada nos protocolos que surgiram depois que o Indy foi originalmente projetado — WebSocket, HTTP/2, HTTP/3 / QUIC, MQTT 5, AMQP 1.0, SSE, WAMP, WebRTC, MCP — além de um amplo catálogo de integrações com APIs REST.
A pergunta mais comum nos fóruns da Embarcadero e no Stack Overflow é alguma variação de “Por que eu pagaria pelo sgcWebSockets se o Indy é gratuito?”. A resposta curta é que eles resolvem problemas diferentes e, em muitos projetos reais, você acabará usando os dois. Este artigo percorre as diferenças práticas em 2026 para que você possa decidir qual deles (ou qual combinação) se encaixa na sua aplicação.
O que cada biblioteca realmente faz
O Indy é um toolkit TCP/UDP de uso geral com uma longa lista de protocolos clássicos da Internet: HTTP/1.1, FTP, SMTP, POP3, IMAP, NNTP, DNS, IRC, Telnet, Whois, além de um framework de servidor TCP. Seu design é baseado em thread por conexão e I/O bloqueante. Não há cliente ou servidor WebSocket nativo no Indy padrão — é necessário adicionar um, e vários projetos da comunidade fazem exatamente isso, com resultados variados.
O sgcWebSockets é uma biblioteca focada e rica em protocolos, voltada para cenários modernos de cliente/servidor. Está organizada em torno de um par central TsgcWebSocketClient / TsgcWebSocketHTTPServer com complementos opcionais para HTTP/2, HTTP/3 sobre QUIC, MQTT, AMQP, STOMP, SSE, WAMP, P2P/WebRTC, IoT (CoAP, AWS IoT, Azure IoT), criptografia ponta a ponta e mais de 30 wrappers de API (OpenAI, Anthropic, Google, AWS, Azure, Binance, Coinbase, Kraken, Telegram, WhatsApp etc.).
Um detalhe importante e frequentemente ignorado: o sgcWebSockets usa o Indy internamente como um de seus backends de transporte. A camada TCP/TLS de vários componentes é, por baixo, um TIdTCPClient / TIdHTTPServer do Indy, então instalar o sgcWebSockets não substitui o Indy — ele se apoia em cima dele. A biblioteca também oferece transportes alternativos (estilo Synapse, ICS, SChannel) para cenários em que o Indy não é a melhor opção.
Comparação recurso a recurso
| Recurso | Indy (padrão) | sgcWebSockets |
|---|---|---|
| Cliente HTTP/1.1 | Sim (TIdHTTP) | Sim (TsgcHTTPComponentClient, pode usar backend Indy ou ICS) |
| Servidor HTTP/1.1 | Sim (TIdHTTPServer) | Sim (TsgcWebSocketHTTPServer, trata HTTP + WS na mesma porta) |
| Cliente/servidor WebSocket | Sem suporte nativo | RFC 6455 completo, permessage-deflate, subprotocolos, testado com Autobahn |
| HTTP/2 (h2 + h2c) | Não | Sim, HPACK e camada de frames customizados |
| HTTP/3 / QUIC | Não | Sim (baseado em msquic) |
| MQTT 3.1.1 e 5.0 | Não | Sim, cliente e broker |
| AMQP 1.0 / 0.9.1 | Não | Sim |
| STOMP, SSE, WAMP | Não | Sim |
| WebRTC / P2P / STUN / TURN | Não | Sim |
| CoAP e nuvem IoT (AWS, Azure) | Não | Sim |
| OpenAI, Anthropic, Gemini, MCP | Não | Sim, componentes dedicados |
| FTP / SMTP / POP3 / IMAP | Sim | Não (use o Indy para isso) |
| Gratuito / comercial | Gratuito, estilo MIT | Comercial, várias edições incl. Free |
| Versões do Delphi | D7 em diante (varia por fork) | D7 até D13 |
| Manutenção ativa | Comunidade (IndyProject no GitHub) | Fornecedor, releases mensais |
Onde o Indy ainda vence
Se o seu projeto é um cliente Internet clássico — baixar um arquivo por HTTP, enviar um formulário, mandar um e-mail por SMTP, buscar mensagens por IMAP, conversar com um servidor FTP antigo — o Indy padrão é a resposta certa. Ele é gratuito, vem com a IDE, a API é familiar e você não precisa de mais nada. O mesmo vale para servidores TCP de hobby e protocolos que o Indy traz nativamente (NNTP, IRC, Telnet, Whois). Para esses casos de uso, adicionar uma biblioteca paga é exagero.
O Indy também é a escolha óbvia quando você precisa interoperar com código que já usa tipos do Indy — por exemplo, componentes que esperam um TIdSSLIOHandlerSocketOpenSSL ou um TIdHTTPServerCommandHandler.
Onde o sgcWebSockets é a ferramenta certa
Qualquer coisa que envolva a pilha moderna da web é significativamente mais fácil com sgcWebSockets. Concretamente:
- WebSocket — mensageria full-duplex é recurso de primeira classe. O servidor lida com HTTP e WebSocket na mesma porta, gerencia subprotocolos, suporta compressão e se integra ao WatchDog de reconexão automática de fábrica.
- HTTP/2 e HTTP/3 — obrigatórios para Apple Push Notifications, serviços do Google e um número crescente de APIs REST que passaram a exigir h2 como mínimo. O Indy não tem resposta aqui.
- Brokers de mensageria — MQTT 5, AMQP 1.0, STOMP, WAMP e SSE vêm como componentes prontos para uso, com TLS, reconexão e autenticação.
- Multimídia em tempo real — WebRTC, ICE, STUN, TURN e DTLS-SRTP para áudio/vídeo e canais de dados compatíveis com navegadores.
- APIs de IA e nuvem — OpenAI, Anthropic, Google Gemini, AWS, Azure, Telegram, WhatsApp, Stripe e algumas dezenas de outras são encapsuladas como componentes tipados, em vez de chamadas REST cruas.
Desempenho e escalabilidade
O modelo de thread por conexão do Indy é simples e correto, mas limita a vazão prática a alguns milhares de conexões concorrentes em um servidor Windows típico antes que a troca de contexto se torne o gargalo. O sgcWebSockets oferece o mesmo backend Indy para compatibilidade, além de um transporte de servidor baseado em IOCP no Windows que, em benchmarks, alcança dezenas de milhares de conexões WebSocket concorrentes por processo. Para vazão pura de HTTP a diferença é menor, mas para conexões de longa duração (WebSocket, MQTT, SSE) a diferença arquitetural importa.
O footprint de memória por conexão ociosa também é menor com o transporte IOCP, porque não há uma thread de SO dedicada por socket. No Linux o cenário é semelhante, com servidores baseados em epoll por meio do fork do Indy que o sgcWebSockets distribui.
Manutenção e cadência de releases
O Indy é mantido por um pequeno grupo de voluntários no repositório GitHub do IndyProject. Os releases são lentos, mas a base de código é estável. Correções críticas (compatibilidade com TLS, bindings modernos para OpenSSL) chegam, mas nem sempre rapidamente.
O sgcWebSockets é um produto comercial da eSeGeCe com releases mensais, um arquivo público de histórico e suporte direto do fornecedor. Novas versões do Delphi normalmente são suportadas no dia do lançamento — o Delphi 13 foi suportado desde o primeiro beta — e novas revisões de protocolo (MQTT 5.0.1, HTTP/3 final, atualizações da spec MCP) saem em dias, em vez de anos.
Licença e preço
O Indy é gratuito e vem com o Delphi. O sgcWebSockets é comercial, mas possui uma Edição Free para uso não comercial, além de edições pagas (Standard, Professional, Enterprise, All-Access) com cobertura de protocolos progressivamente mais ampla. A maioria dos projetos comerciais consegue justificar uma licença Professional para um único desenvolvedor com apenas um cliente implantado.
Uma regra simples de decisão
Uma regra prática de bolso para 2026:
- Use Indy para SMTP/POP3/IMAP/FTP, para downloads HTTP de curta duração dentro de uma base já existente com Indy, ou para qualquer protocolo clássico da Internet que o Indy já trate nativamente.
- Use sgcWebSockets no momento em que WebSocket, HTTP/2, HTTP/3, MQTT, AMQP, WebRTC, IoT ou qualquer API de IA/REST entrarem em cena, ou quando você precisar de um servidor que escale além de alguns milhares de conexões.
- Use os dois no mesmo projeto — esse é, de fato, o padrão mais comum. O Indy fica com a camada de e-mail e FTP, o sgcWebSockets cuida da camada em tempo real e das APIs modernas, e os dois compartilham a mesma infraestrutura SSL/IO do Indy por baixo.
Considerações finais
O Indy não vai a lugar nenhum — é o martelo de confiança em toda caixa de ferramentas Delphi. Mas os protocolos que definem a internet de 2026 (WebSocket, HTTP/2/3, MQTT, WebRTC, APIs de IA) simplesmente não existiam quando o Indy foi projetado. O sgcWebSockets preenche essa lacuna com uma biblioteca focada, mantida ativamente e com suporte comercial, que se apoia no Indy onde é útil e o substitui onde é necessário. Para projetos novos voltados a back-ends modernos, a pergunta deixou de ser Indy ou sgcWebSockets? — passou a ser como combinar os dois?