關于B/S判斷瀏覽器斷開的問題討論

2024-05-06 14:16:49

字體：大中小

來源：轉載

供稿：網友

客戶端通過腳本和服務器保持請求，每次請求刷新一個時間，服務器檢查這個時間，如果發現時間超過預定，則可以判斷該客戶端瀏覽器已關閉。然后對進行相應得操作。如果你想知道是那個客戶端瀏覽器關閉，可以把會話綁定到輪詢對象中。長連接不是所有服務器都支持得，這種方式，比你的現實多了。
我的個人看法。
我首先同意這幾種做法，它們也能實現這個需求，他們都通過客戶端的輪詢，更新服務器的最后訪問時間，讓服務器檢測超時。我來談談我對這2種做法的理解

1 服務器端如何進行超時判斷，啟動一個后臺線程進行定時輪詢？循環檢查每個session是否超過了間隔？
2 如果用線程，那么服務器端判斷的間隔或者周期是多少，1秒，10秒，20秒..
3 如果大家都用10秒間隔，客戶也能承受這個間隔，我們來看結果
1) 我還不知道哪個服務器不支持長連接，如果你下載100G的文件，難道不行嗎？中間非得斷開n次？
2) 你的每個客戶端需要在10秒之內，發出新的請求，讓服務器進行響應，我的則不需要
3) 輪詢操作要注意并發問題，也就是同步訪問問題，你的數據得保存在application或者其它自定義全局數據結構里面，而多線程不存在這個問題
4) 輪詢屬于單線程，統一處理，而長連接為多線程
5) 客戶端每次請求刷新后斷開連接，可以減少占用服務器的連接數，提高并發數，但相對增加了每次請求的負擔。
4 關鍵區別：如果要求在0.1秒內必須做出精確反應，發現連接斷開要馬上進行處理，我想我的多線程方案會更有效，因為瀏覽器很難在那么短的時間內發出10次請求的。而長連接則只需要減少發送數據的間隔就可以。

總結：
需求決定應用。
系統要求的判斷超時的時間越短，長連接的方案優勢越大，時間越長，輪詢的可用性越強。具體需要根據應用做抉擇。
對于一般的B/S判斷，大部分聊天室和在線人數統計都是臨行輪詢操作的。一個人離開聊天室，不會立即更新在線列表，但IM程序(QQ/MSN)等則會相對非常精確的更新。

如果需要精確判斷，我想長連接是我能想到的解決方案之一；另一個就是客戶端插件，比如applet,Flash，ActiveX等使用socket進行了，不過機制和長連接沒有區別。
兩點小建議

1。做到0.1反應可以，但做到0.1秒“精確”反應不行。TCP協議雖然是長連接，但沒規定CS中一端掉線時，另一端迅速可知（否則也不會有后來TCP不太標準的“心跳”協議），這關乎中間網絡硬件的支持。現實中也是如此。當然，我不知道版主這篇文章的可能還有上文，所以不知這系統準備運行在什么網上。

2。文章既然提到“前面頁面”。看來這個系統就不應該是QQ或游戲服務器了，后臺很可能就是運行一個普通的WEB服務器，IIS或APACHE。。它們的設計目標明確，所以都會有最大連接數限制。表面上，數千人同時在線，沒關系，由于采用短連接，同一時間的并發數通常夠用。但如果就算客戶不活動，連接也要保持，那這個數目就很快有個死限了。

上一篇：仿163填寫郵件地址自動顯示下拉（無優化）

下一篇：js Clip的奇思妙想之文字拼接效果