两个库，两份不同的工作
几乎每位 Delphi 开发者都在某个时刻使用过 Indy。它随 IDE 一起发布，自 1990 年代末以来就一直存在，整整一代 Delphi 网络代码都建立在 TIdHTTP、TIdTCPClient、TIdSMTP 等组件之上。sgcWebSockets 是一个更新得多的商业库，专注于在 Indy 最初设计之后才出现的协议——WebSocket、HTTP/2、HTTP/3 / QUIC、MQTT 5、AMQP 1.0、SSE、WAMP、WebRTC、MCP——加上一个大型的 REST API 集成目录。
Embarcadero 论坛和 Stack Overflow 上最常见的问题是某种形式的"Indy 是免费的，我为什么要为 sgcWebSockets 付费？"。简短的答案是它们解决不同的问题，在许多真实项目中，您最终会同时使用两者。本文走过 2026 年的实际差异，以便您可以决定哪一个（或哪种组合）适合您的应用程序。
每个库实际做什么
Indy 是一个通用 TCP/UDP 工具包，包含一长串经典互联网协议：HTTP/1.1、FTP、SMTP、POP3、IMAP、NNTP、DNS、IRC、Telnet、Whois，加上一个 TCP 服务器框架。其设计是每连接一个线程和阻塞 I/O。原始 Indy 中没有原生 WebSocket 客户端或服务器——您必须自己添加一个，几个社区项目正是这么做的，结果好坏参半。
sgcWebSockets 是一个专注的、协议丰富的库，面向现代客户端/服务器场景。它围绕核心 TsgcWebSocketClient / TsgcWebSocketHTTPServer 配对组织，可选附加 HTTP/2、基于 QUIC 的 HTTP/3、MQTT、AMQP、STOMP、SSE、WAMP、P2P/WebRTC、IoT（CoAP、AWS IoT、Azure IoT）、端到端加密以及 30 多个 API 包装器（OpenAI、Anthropic、Google、AWS、Azure、Binance、Coinbase、Kraken、Telegram、WhatsApp 等）。
一个重要而经常被忽视的细节：sgcWebSockets 在内部使用 Indy 作为其传输后端之一。几个组件的 TCP/TLS 管道在底层是 Indy 的 TIdTCPClient / TIdHTTPServer，因此安装 sgcWebSockets 不会替换 Indy——它构建在 Indy 之上。该库还为 Indy 不太合适的场景提供了备选传输（Synapse 风格、ICS、SChannel）。
功能逐项比较
| 功能 | Indy（原始） | sgcWebSockets |
|---|---|---|
| HTTP/1.1 客户端 | 是（TIdHTTP） | 是（TsgcHTTPComponentClient，可使用 Indy 或 ICS 后端） |
| HTTP/1.1 服务器 | 是（TIdHTTPServer） | 是（TsgcWebSocketHTTPServer，在同一端口处理 HTTP + WS） |
| WebSocket 客户端/服务器 | 没有原生支持 | 完整 RFC 6455、permessage-deflate、子协议、autobahn 测试通过 |
| HTTP/2（h2 + h2c） | 否 | 是，自定义 HPACK + 帧层 |
| HTTP/3 / QUIC | 否 | 是（基于 msquic） |
| MQTT 3.1.1 和 5.0 | 否 | 是，客户端和代理 |
| AMQP 1.0 / 0.9.1 | 否 | 是 |
| STOMP、SSE、WAMP | 否 | 是 |
| WebRTC / P2P / STUN / TURN | 否 | 是 |
| CoAP 和 IoT 云（AWS、Azure） | 否 | 是 |
| OpenAI、Anthropic、Gemini、MCP | 否 | 是，专用组件 |
| FTP / SMTP / POP3 / IMAP | 是 | 否（对这些请使用 Indy） |
| 免费/商业 | 免费，MIT 风格 | 商业，多个版本包括 Free |
| Delphi 版本 | D7 及以上（因 fork 而异） | D7 到 D13 |
| 积极维护 | 社区（GitHub 上的 IndyProject） | 供应商，每月发布 |
Indy 仍然胜出的地方
如果您的项目是经典互联网客户端——通过 HTTP 下载文件、提交表单、发送 SMTP 电子邮件、通过 IMAP 获取邮件、与旧 FTP 服务器通信——原始 Indy 是正确的答案。它免费、与 IDE 捆绑、API 熟悉，您不需要任何其他东西。对于 Indy 原生支持的业余 TCP 服务器和协议（NNTP、IRC、Telnet、Whois）也是如此。对于这些用例，添加付费库是过度的。
当您必须与已使用 Indy 类型的代码互操作时，Indy 也是显而易见的选择——例如，期望 TIdSSLIOHandlerSocketOpenSSL 或 TIdHTTPServerCommandHandler 的组件。
sgcWebSockets 是正确工具的地方
使用 sgcWebSockets 时，涉及现代 Web 栈的任何事情都明显更容易。具体来说：
- WebSocket——全双工消息传递是一流功能。服务器在同一端口处理 HTTP 和 WebSocket、管理子协议、支持压缩，并开箱即用地集成自动重连 WatchDog。
- HTTP/2 和 HTTP/3——Apple Push Notifications、Google 服务以及越来越多开始强制 h2 最低要求的 REST API 所必需。Indy 在这里没有答案。
- 消息代理——MQTT 5、AMQP 1.0、STOMP、WAMP 和 SSE 都作为即用型组件提供，带 TLS、重连和身份验证。
- 实时多媒体——WebRTC、ICE、STUN、TURN 和 DTLS-SRTP，用于浏览器兼容的音频/视频和数据通道。
- AI 和云 API——OpenAI、Anthropic、Google Gemini、AWS、Azure、Telegram、WhatsApp、Stripe 等数十种被包装为类型化组件而非原始 REST 调用。
性能和扩展
Indy 的每连接一个线程模型简单且正确，但在典型 Windows 服务器上，实际吞吐量在上下文切换成为瓶颈之前限制在几千个并发连接。sgcWebSockets 提供相同的 Indy 后端以保证兼容性，加上一个基于 IOCP 的 Windows 服务器传输，已在每进程数万个并发 WebSocket 连接上进行了基准测试。对于纯 HTTP 吞吐量，差异较小，但对于长期连接（WebSocket、MQTT、SSE），架构差距很重要。
每个空闲连接的内存占用在 IOCP 传输中也较低，因为每个套接字没有专用的 OS 线程。在 Linux 上，通过 sgcWebSockets 提供的 Indy fork 的基于 epoll 的服务器，情况类似。
维护和发布节奏
Indy 由 IndyProject GitHub 仓库上的一小群志愿者维护。发布缓慢但代码库稳定。关键修复（TLS 兼容性、现代 OpenSSL 绑定）确实会落地，但并不总是迅速的。
sgcWebSockets 是 eSeGeCe 的商业产品，每月发布、有公共历史文件以及直接供应商支持。新的 Delphi 版本通常在第一天就得到支持——Delphi 13 从第一个测试版开始就得到支持——新的协议修订（MQTT 5.0.1、HTTP/3 最终版、MCP 规范更新）在几天内发布而非几年。
许可和定价
Indy 是免费的，随 Delphi 一起发布。sgcWebSockets 是商业的，但有一个用于非商业用途的免费版，加上付费版（Standard、Professional、Enterprise、All-Access），逐步扩大协议覆盖。大多数商业项目可以为单个部署客户证明单开发者 Professional 许可的合理性。
一个简单的决策规则
一个务实的 2026 经验法则：
- 使用 Indy用于 SMTP/POP3/IMAP/FTP、现有 Indy 代码库内的短期 HTTP 下载，或 Indy 已经原生处理的任何经典互联网协议。
- 使用 sgcWebSockets，一旦 WebSocket、HTTP/2、HTTP/3、MQTT、AMQP、WebRTC、IoT 或任何 AI/REST API 进入画面，或者当您需要一个可扩展到几千个连接以上的服务器时。
- 在同一项目中同时使用两者——这实际上是最常见的模式。Indy 留给电子邮件和 FTP 层，sgcWebSockets 处理实时和现代 API 层，它们在底层共享相同的 Indy SSL/IO 基础设施。
结束思考
Indy 哪儿也不去——它是每个 Delphi 工具箱中可靠的锤子。但定义 2026 年互联网的协议（WebSocket、HTTP/2/3、MQTT、WebRTC、AI API）在 Indy 设计时根本不存在。sgcWebSockets 用一个专注的、积极维护的、商业支持的库填补了这一空白，在有用的地方构建在 Indy 之上，在必要的地方取代它。对于面向现代后端的新项目，问题不再是Indy 还是 sgcWebSockets？——而是我如何将它们结合起来？