我在很多项目中使用Indy。我主要使用9和10作为HTTP服务器和代理。项目有时会遇到非常密集的流量（HTTP）。印第从来没有让我失望过。它的工作非常稳定。
但我也遇到过一些“奇怪”的情况，我不得不深入挖掘，以找到潜在的问题。我也不喜欢Indy倾向于通过异常处理很多事情的方式。总体而言，我更喜欢ICS的编码风格。让我们去ICS。
ICS使用非阻塞套接字，而indy使用阻塞套接字。虽然非阻塞是确定的，似乎是更好的第一眼看，我发现它在很多情况下令人恼火。问题是，由于回调函数，代码的自然流丢失了。这使得编写过程类型的库变得更加困难。此外，我不喜欢一切都通过消息处理。对我来说，它变得混乱真实的快时，与多线程混合。而多线程是当今的主流。
因此，虽然我喜欢ICS中代码的编码风格和质量，但我更喜欢Indy的简单使用和阻塞模式。你更喜欢什么取决于你，但这两个库都是成熟和稳定的。
这是我的两分钱。

我也使用Indy和ICS。
大多数时候我更喜欢Indy，因为用它实现顺序类型的协议非常容易（请求在它自己的线程中运行，所以你只需对连接进行读/写，非常容易）。使用Indy需要扎实的线程和同步知识。与Runner不同的是，我喜欢Indy如何使用try-finally来处理“异常”的东西，因为它允许我专注于协议的正常流程（我使用try-finally块来确保我释放资源）。
我还在一个应用程序中使用了ICS，Indy只是失败了：我将它用于实现TCP/IP代理的应用程序。使用ICS更简单，因为它的非阻塞特性。我能够“代理”TCP/IP协议，我一无所知，所以我不知道字节将如何从一端流到另一端。Indy在这个场景中失败了，因为在Indy中，你要么在阅读，要么在写，你不能同时做这两件事。使用ICS来实现一个顺序类型的协议是有点痛苦的：你基本上需要使用状态机逻辑，在小的比特中制动协议，保持标志在周围，这样你就知道你在协议中的位置。一个很大的优势：François Piette，ICS的作者，在许多论坛和邮件列表上非常活跃，非常有帮助，并且非常迅速地帮助与ICS相关的任何事情。
对我来说，如果我需要用TCP/IP做一些事情，决策路径非常简单：能和Indy一起做吗？那就是印第如果不能用Indy完成，那么就用ICS完成！

我已经使用Indy 9和10的TCP，HTTP和FTP的问题很少。ICS也是不错的选择。它是非阻塞的，这将改变你使用它的方式。
我没有用过它，但我听说过Synapse的好消息，它也是阻塞的。

我们测试了Indy10 IdTCPClient从远程服务器接收视频流，它是OK的。但是当它在接收流的同时，用它向服务器发送一些数据，过了一段时间，接收到的流数据开始丢失数据字节。我们使用嗅探器工具跟踪这个问题，确认IdTCPClient在接收流时丢失了一些字节。
所以，我们测试印地9.018，同样的问题发生，但几次VS。印地10号。

请记住，Indy始终处于beta阶段。有时候你需要在晚上工作。

哪一个更好真的取决于具体的用例，但我对indy作为一个http客户端感到不满，ICS最终成为了我所需要的，少了很多随机的怪癖。
请注意，虽然它是非阻塞的，所以它不只是一个下降的替代品。

我使用Indy 9为超过100万用户提供稳定的，已发布的生产代码，并且从未收到任何奇怪的错误。

我想说的是，答案取决于你想用互联网做什么。Indy很好，如果你准备参与了解它是如何工作的，并且非常有能力。ICS是一种不同的方式，我已经有效地将它用于多连接系统。但是对于日常的“抓取文件或发送电子邮件”类型的东西，你想做一个基本的任务，我几乎总是使用Clever Components Internet Suite，因为你只需要创建组件，设置选项，它就可以工作了。该套件是相当全面的，并得到有用的更新。

我知道这是一个旧的职位，但如果有人在2023+发现它：

1. Indy不再有官方稳定更新。只有贝塔。

• ICS支持TLS 1.3（https），并将易于查找的兼容SSL DLL文件打包到组件zip中。也可用于特定用例，例如：
• 约瑟签名，
• 证书过期检查，
• 证书生成和转换等。

我们不得不放弃Indy10，因为最新的政府项目有特定的证书要求。ICS工作稳定。