真正的WEB服务器是不会用Indy写的。因为它是基于每连接每线程的。
其实真正的服务器需要下很多功夫，无法快速开发的。
比如说，字符串处理。玩服务器基本上就是玩内存。举个例子：
var
str:AnsiString;
begin
str:='HTTP 1.1/200 OK'#$D#$A;
str:=str+xxxxxxx;
str:=str+yyyyyyy;
......
end;
编译器实际上上怎么做的？第一行代码：先根据字符长度，为str分配17字节空间（这里不讨论头部计数器和锁占用的空间）。第二行代码，假设xxxxxx的长度为3，那么再申请一个20字节的空间，将原来17字节的内容拷贝过去，再在后面接上3个字节的内容，然后释放原来的17个字节。第三行同理。内存会变成怎么样？
[ 17个字节的空洞][ 20字节的新内容]..........
这个时候，如果你需要分配一个18字节的内存，只能从[ 20字节的新内容]后面申请，因为内存块必须是连续的。换句话说，前面那个17字节的内存就废了。除非分配的是小于等于17字节的。
随着运行的时间越来越长，类似的空洞会越来越多。最后，如果你是32位应用程序，那么有可能面临很多错误（比如说：GetMem失败，对象创建失败）。
MFC的CString实质上原理类似。
服务器开发跟桌面应用是两码事，因为桌面应用程序，从你启动到结束，一般就运行几个小时，但服务器是24小时*365运行的，需要注意的事情海了去。很多时候，一些好像不要紧的细节，累加起来，就有质的区别。
服务器开发，不是有一个不错的网络库就OK的。网络仅是负责数据的收发，你如何快速处理收到的数据呢（比如说，使用传统锁来生产者消费者队列，或者双队列，或者原子队列，或者真正逻辑上完全无锁队列）？如果避免更多的内核和应用层切换？启动多少个线程刚好合适？选用什么加密算法？等等等等。不要小看效率，假如你的服务器长连接峰值是10万，一个加密算法提示了10毫秒，10毫秒乘以10万就是16分钟，8核服务器在理想状态下，最后那个登录的可怜虫也要多等待2分钟。仅仅追求连接数是毫无意义的，如果你的机器性能够强大，如果你使用完成端口，如果客户端仅是连接而不用做其它事情，一个最蹩脚的程序员写的也能同时支持百万级别的连接。但这个是操作系统的功劳，跟你的程序关系不大。仅连接不做事情的程序也没什么用处。
当然，桌面程序开发人员是不用关心这些的。如果仅是开发http server，我强烈建议直接调用操作系统的http.sys，这个也是IIS的本质。除了避免内核和应用层的切换，还可以避免很多问题。你自己实现一个其实是不可能比这个更好－－－你用的操作系统都是人家的，你会比他更了解系统么？
http://bbs.2ccc.com/topic.asp?topicid=517080
http://www.codeproject.com/Articles/437733/Demystify-http-sys-with-HttpSysManager
http://blog.synopse.info/tag/http.sys
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364510(v=vs.85).aspx