ICAP的全名是Internet Content Adaptation Protocol，它是在HTTP传送过程中进行RPC的一种轻量级协议，本质是在HTTP传输过程中通过ICAP client(这个角色由squid来充当)和ICAP Server(比如，某些反病毒网关)对传输过程的某些部分进行匹配和修改，HTTP传输过程包括HTTP请求和HTTP应答，ICAP可以修改的HTTP传输过程包括HTTP请求和HTTP应答。常见的基于ICAP的应用包括内容过滤、内容压缩、病毒扫描、广告投放、页面翻译等等。ICAP目前在很多反病毒网关上应用很广泛，TrendMicro、Kaspersky、Blue Coat等等都可以看到ICAP的影子。上面这些提到的都是商用的ICAP Server，开源的ICAP Server有下面两个，有兴趣的人可以试试:
ICAP-SERVER :一个用Python写的ICAP Server
C-ICAP-SERVER :用C实现的ICAP Server，跟clamav集成比较紧密
ESI由Akamai、Oracle(Akamai和oracle提出规范，其它厂商附和)、IBM、BEA等等15家厂商于2001年推出，其全名是Edge Side Includes，跟SSI(Server Side Include)比较类似的一种技术，所不同的是SSI由Web Server解析，而ESI由cache server解析。说到ESI不得不提到的是传统cache server的cache方式:以页面为单位，但实际上，一个页面上包含的内容可能很多样，比如需要动态更新的股票信息、用户信息和一年也不会更改的网站logo，ESI就是针对一个页面里不同的部分采用不同的cache策略实现cache server最大的性价比的一种技术。关于ESI的规范可以从这个链接获得。
在squid3.0RC1上发现一个比较有趣的现象是squid在FreeBSD和Linux上的分化，以前的经验是，Squid在FreeBSD上运行比较有优势，现在我看到的是，epoll(configure时不需要--enable-epoll，程序会自动判断)这个在Linux2.6上特有的东西已经可以在squid3.0RC中自动判断了，而FreeBSD引以为豪的kqueue在squid3.0RC里的支持却仍然被认为是experimental，当然，我不是说kqueue不好(连Linus也说kqueue over design了)，我只是说，现在的核心开发人员在Linux和FreeBSD的支持上已经产生分化了。当然，这个扯远了，不过，核心开发人员在Linux和FreeBSD上的功力显然会影响你对squid运行平台的选择。
由于开发组实际上在squid2.6上花了很多心思，所以造成了squid2.6上有的一些特性反而在3.0上没有，而且，3.0是用c++完全重写的，2.6的一些特性要port到3.0(你没看错)估计还要一段时间，所以，除非你不需要2.6的这些特性，还是继续用2.6吧。