comet 的主要問題如下:
1.他無法支援網頁壓縮的技術,因為js stream一直都在進行中,尚未結束,所以無從壓縮也無從解壓縮
2.他可能無法支援SSL加密模式
3.他會受到特殊設備的阻擋,有些防火牆/PROXY 會一直等斷線才一次送出資訊
4.某些瀏覽器必須要超過某個數量的資訊,才會處理資訊,所以必須填充很多無用的字,浪費多於頻寬
5.他給現有的伺服器很大的挑戰(這也是謂何前一個例子;我自己寫WEB SERVER的原因),因為它的連線時間很長,但是實際資料的傳輸並不多,這不利PREFORK 架構的APACHE,目前APACHE 有幾種架構我尚未測試(MINA EVENT-MPM),之前在WIN32 上測試過THREAD-MPM , 結果並不理想
現在的WEB SERVER幾乎都把焦點放在epoll/kqueue身上,不像以前使用MUTI-THREAD/MUTI-PROCESS這類的架構,這讓COMET 這類的技術得以延續,但是基本上它只會是配角,永遠不可能變成主角,或是取代AJAX
1.他無法支援網頁壓縮的技術,因為js stream一直都在進行中,尚未結束,所以無從壓縮也無從解壓縮
2.他可能無法支援SSL加密模式
3.他會受到特殊設備的阻擋,有些防火牆/PROXY 會一直等斷線才一次送出資訊
4.某些瀏覽器必須要超過某個數量的資訊,才會處理資訊,所以必須填充很多無用的字,浪費多於頻寬
5.他給現有的伺服器很大的挑戰(這也是謂何前一個例子;我自己寫WEB SERVER的原因),因為它的連線時間很長,但是實際資料的傳輸並不多,這不利PREFORK 架構的APACHE,目前APACHE 有幾種架構我尚未測試(MINA EVENT-MPM),之前在WIN32 上測試過THREAD-MPM , 結果並不理想
現在的WEB SERVER幾乎都把焦點放在epoll/kqueue身上,不像以前使用MUTI-THREAD/MUTI-PROCESS這類的架構,這讓COMET 這類的技術得以延續,但是基本上它只會是配角,永遠不可能變成主角,或是取代AJAX
留言