搞懂什麼是”服務器推送”，長連接，長輪詢，Comet，htmlfile

Comet：基於純瀏覽器的“服務器推”技術開始受到較多關注，Alex Russell（Dojo Toolkit 的項目 Lead）稱這種基於 HTTP 長連接、無須在瀏覽器端安裝插件的“服務器推”技術爲“Comet”。目前已經出現了一些成熟的 Comet 應用以及各種開源框架；一些 Web 服務器如 Jetty 也在爲支持大量併發的長連接進行了很多改進。

 

1.實例參考java實現
  https://blog.csdn.net/xxd851116/article/details/10022015

服務器端：
  用for循環保持連接
  用response.flushBuffer() 向客戶端返回（緩存）數據（示例中返回javascript,客服端收到收到就會執行，實現了互動）
  （php的話使用ob_flush()和flush() ）

客戶端:
  用iframe來接受到服務器的響應，這樣子就不影響客戶端的操作

   IE裏用htmlfile來實現。
   與直接來個隱藏iframe讀一個長連接相比這種做法在功能沒區別
   其主要的好處是這麼新建一個htmlfile再把iframe寫到裏面，建立一個長連接時
    IE就不會在下面的狀態欄一直顯示 "正在打開XXXXXXXXXXXXXXXX頁面" 
  htmlfile實現參考https://www.cnblogs.com/my_life/articles/2749709.html

使用 iframe 請求一個長連接有一個很明顯的不足之處：IE、Morzilla Firefox 下端的進度欄都會顯示加載沒有完成，而且 IE 上方的圖標會不停的轉動，表示加載正在進行。Google 的天才們使用一個稱爲“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問題，並將這種方法用到了 gmail+gtalk 產品中。Alex Russell 在 “What else is burried down in the depth's of Google's amazing JavaScript?”文章中介紹了這種方法。Zeitoun 網站提供的 comet-iframe.tar.gz，封裝了一個基於 iframe 和 htmlfile 的 JavaScript comet 對象，支持 IE、Mozilla Firefox 瀏覽器，可以作爲參考。（請參見 參考資源）

 

2.Ajax實現
  基於 AJAX 的長輪詢（long-polling）方式
  https://www.ibm.com/developerworks/cn/web/wa-lo-comet/

  Ajax調用 XMLHttpRequest 對象發出 HTTP 請求 ，由於請求是異步的，不會阻塞客戶端頁面的操作，所以不需要iframe。
  客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息後，再次發出請求，重新建立連接。這樣子不停的循環。

在這種長輪詢方式下，客戶端是在 XMLHttpRequest 的 readystate 爲 4 時，數據傳輸結束，連接已經關閉。
readystate 爲 3 時（數據仍在傳輸中），客戶端可以讀取數據，從而無須關閉連接，就能讀取處理服務器端返回的信息。這種方式被稱爲Streaming AJAX 。
readyState等於3時，XMLHttpRequest的responseText返回的內容，不是本次變化新增的內容，而是之前接受到的內容+本次變化新增的內容。
IE 在 readystate 爲 3 時，不能讀取服務器返回的數據，目前 IE 不支持基於 Streaming AJAX

正在上傳…重新上傳取消
readystate 爲 4 時的循環方式

readystate 爲 3 時的Streaming AJAX

 

注意：不要在同一客戶端同時使用超過兩個的 HTTP 長連接

我們使用 IE 下載文件時會有這樣的體驗，從同一個 Web 服務器下載文件，最多隻能有兩個文件同時被下載。第三個文件的下載會被阻塞，直到前面下載的文件下載完畢。這是因爲 HTTP 1.1 規範中規定，客戶端不應該與服務器端建立超過兩個的 HTTP 連接， 新的連接會被阻塞。而 IE 在實現中嚴格遵守了這種規定。

HTTP 1.1 對兩個長連接的限制，會對使用了長連接的 Web 應用帶來如下現象：在客戶端如果打開超過兩個的 IE 窗口去訪問同一個使用了長連接的 Web 服務器，第三個 IE 窗口的 HTTP 請求被前兩個窗口的長連接阻塞。

 

 

---

其他心得

1. HTTP協議是基於請求/響應模式的，因此只要服務端給了響應，本次HTTP連接就結束了，換而言之，HTTP請求就沒有長連接的說法，所以就沒有短連接了。
2. 網上所說的HTTP分爲長連接和短連接，其本質是TCP連接。由於TCP連接是一個雙向的通道，它是可以保持一段時間不關閉的，所以TCP連接纔有真正的長連接和短連接這一說法。

長連接，短連接：

1. 短連接： 每次HTTP請求都會建立TCP連接，管理容易。
2. 長連接： 只需要建立一次TCP連接，以後的HTTP請求重複使用同一個TCP連接，可是不易於管理。

 

長短連接的應用場景：

1. 一般長連接主要是應用於實時性高的場景。
2. 類似於WEB網站的HTTP服務一般都是使用短連接，爲了方便於資源的回收。

長輪詢，短輪詢：

1. 短輪詢：重複發送HTTP請求，一般是死循環，我就是這麼做的。
2. 長輪詢：CLIENT 和 SERVER 端一直建立着連接，等待目標響應。

 

 

參考文獻：
數據同步筆記-長短輪詢
  https://www.jianshu.com/p/4c241bea5836

Comet：基於HTTP長連接的“服務器推”技術
  https://www.cnblogs.com/rainman/archive/2011/11/28/2266193.html

基於 AJAX 的長輪詢（long-polling）方式
  https://www.ibm.com/developerworks/cn/web/wa-lo-comet/

java實現
  https://blog.csdn.net/xxd851116/article/details/10022015

推技術ActiveXobject("htmlfile") 長連接
https://www.cnblogs.com/my_life/articles/2749709.html