病毒检测的机理:病毒是一段代码，最终的形态是一个文件。任何在网上传播的数据流必须重组成文件，才能被防毒扫描引擎所检测。我们在浏览网页的时候其实是通过http协议get了许多的html文件、gif图标以及脚本文件，最终到达用户处都是文件。网关防毒产品要实现http的病毒过滤，必须把http流量中的数据重组为文件，也就是OSI7层的还原。要做到这步，目前所有的解决办法都是利用proxy技术，无论是self-proxy还是icap方式，都是在用户发起对某个网页进行浏览请求的时候，由网关防毒设备先把这个网页上所有的页面文件以及gif先下载下来，经过扫描再给用户。我们要明确，通过proxy方式把http流量还原成文件是一个过程，把这个文件进行病毒扫描是另外一个过程，这两个过程可以分开进行。
这就凸现了第一个问题，基于局域网的企业内部用户，并不愿意为了进行http的病毒扫描而在IE浏览器中设置代理，而且如果设置代理，许多不支持代理的应用将无法进行。要实现http的病毒扫描，又要对用户表现为透明。
第二个问题就直接反映了进过http病毒扫描后，用户处会感到非常严重的延迟。
一般我们可以忍受的页面延迟为不超过5秒钟，同时http timeout的默认时间为60秒(还是30秒?)。我们下面可以来算一下进过http扫描后的理论延迟。假设一个公司的因特网出口为10Mb，理论的下载速度为1MB/S多，我们必须要考虑到电信和网通互联，以及网站限速等其他因素的影响，一般从随机网站单线下载可以达到100KB/S已经很好了。根据前面已经介绍过的病毒扫描方式，需要由网关防毒设备先下载这个文件扫描后再给用户，我们不考虑ttl的延时，访问页面上的小gif等只有几k的文件的延迟小于1S，但是如果用户要下载补丁或者文件时，文件为10MB，那怎么办呢?10MB的文件以100KB/S的速度理论要下载100S再加上对10MB文件的病毒扫描，其中必定需要花费时间进行解压缩，代码匹配等扫描时间。100S对于http都已经timeout了，也就是连接都断了。面对这种情况，防毒厂商给出的折中解决方法是，增加了病毒扫描的文件的大小限制，这样大文件直接pass，小文件意思意思扫扫算了。不可否认这个的确是个好办法。病毒扫描这块的延迟可以去掉了，但是通过代理的方式获取文件的矛盾无法解决，更进一步的是，多线程的http下载文件的工具在这种proxy模式无法使用或者使用不正常。面对代理上出现的这种问题，代理厂商又给出了新的解决办法，就是代理在替用户下载文件的时候，给用户不停的发送保持连接的数据包，使用户的http连接不至于断掉。这个是所有代理都碰的到的问题，这样的解决方式表面上的确避免了矛盾。
第三个问题就显得很难克服了。
随着互联网技术的发展，多协议的应用软件越来越多，特别是IM程序，为了保证强大的通用性和网络连接性能，都可以通过http进行连接和通讯。这就造成了很多很多的msn的聊天数据，因为走的是http协议而转到代理又由病毒网关进行扫描，不但msn无法使用或者使用不顺畅，同时也加重了病毒网关的负担。同时，现在的网络病毒的横行，许多的病毒僵尸会在局域网内不停的发送大量的对外散射的连接请求，有许多用的恰恰是80端口的访问请求，大量的对外不存在的地址的80请求，代理和病毒网关不可能不理睬，但是花费了大量的资源去应答这些不存在的请求，却没有任何效果，网络病毒的网络层攻击是不可能被还原成文件的，网关http的病毒扫描对此是无能为力的。面对这个突出的矛盾，我们能够想到什么对策呢?那就是在http流量经过代理，经过防病毒网关之前，先由可以检测网络层网络病毒攻击的设备过滤一次，drop掉大量的非正常http请求，再交给网关来处理。对，这样可以把以上这些问题都解决了，但是我们花费了多少设备、多少资金呢?有可以检测网络病毒的设备，我们还要http代理网关干什么?就算http页面中有恶意代码，我们装在客户端的防毒client完全可以检测的，或者通过黑白名单屏蔽一些不良网站就可以很大幅度的降低http访问的隐患。花费大量的资源去做效率极低的http病毒扫描，千年都很难检测出几个java病毒的，却大大降低了企业内部员工的工作效率，很不值得!
