各廠商都有自己的軟、硬件的針對以上提到的三種協議病毒過濾的產品。想法和理念都很好，可實際碰到的問題，效果又如何呢?

　　我可以很負責的告訴大家，非常差!通過我下面的分析，大家可以明確一個觀點，從目前的技術水平來說對http協議進行實時的病毒掃描得不償失。

　　首先，大家先要了解病毒檢測的機理。病毒是一段代碼，最終的形態是一個文件。任何在網上傳播的數據流必須重組成文件，才能被防毒掃描引擎所檢測。大家在瀏覽網頁的時候其實是通過http協議get了許多的html文件、gif圖標以及腳本文件，最終到達用 戶處都是文件。網關防毒產品要實現http的病毒過濾，必須把http流量中的數據重組為文件，也就是OSI7層的還原。要做到這步，目前所有的解決辦法都是利用proxy技術，無論是self-proxy還是icap方式，都是在用戶發起對某個網頁進行瀏覽請求的時候，由網關防毒設備先把這個網頁上所有的頁面文件以及gif先下載下來，經過掃描再給用戶。我們要明確，通過proxy方式把http流量還原成文件是一個過程，把這個文件進行病毒掃 描是另外一個過程，這兩個過程可以分開進行。

　　這就凸現了第一個問題，基于局域網的企業內部用戶，并不愿意為了進行http的病毒掃描而在IE瀏覽器中設置代理，而且如果設置代理，許多不支持代理的應用將無法進行。要實現http的病毒掃描，又要對用戶表現為透明，我在早前的文章中有過介紹，這里就不多說了，請詳見企業網關透明HTTP掃毒解決方案

　　第二個問題就直接反映了進過http病毒掃描后，用戶處會感到非常嚴重的延遲。

　　一般我們可以忍受的頁面延遲為不超過5秒鐘，同時http timeout的默認時間為60秒(還是30秒?)。我們下面可以來算一下進過http掃描后的理論延遲。假設一個公司的因特網出口為10Mb(先不管是獨享還是共享，已經蠻可以的了)，理論的下載速度為1MB/S多，我們必須要考慮到電信和網通互聯，以及網站限速等其他因素的影響，一般從隨機網站單線下載可以達到100KB/S已經很好了。根據前面已經介紹過的病毒掃描方式，需要由網關防毒設備先下載這個文件掃描后再給用戶，我們不考慮ttl的延時，訪問頁面上的小gif等只有幾k的文件的延遲小于1S，但是如果用戶要下載補丁或者文件時，文件為10MB，那怎么辦呢?10M B的文件以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病毒的，卻大大降 低了企業內部員工的工作效率，很不值得!因此我覺得，http的網關病毒掃描方式可以休已。