tcp長連線，短連線，http短輪詢，長輪詢
短連線和長連線：
長輪詢和短輪詢
所謂輪詢，即是在一個迴圈週期內不斷髮起請求來得到資料的機制。只要有請求的地方，都可以實現輪詢，譬如各種事件驅動模型。它的長短是在於請求的返回週期。
短輪詢
短輪詢指的是在迴圈週期內，不斷髮起請求，每一次請求都立即返回結果，根據新舊資料對比決定是否使用這個結果。
具體實現：
前端使用定時器，每間隔一段時間傳送請求來獲取資料是否更新，這種方式可相容ie和支援高階瀏覽器。通常採用 setInterval 或者 setTimeout 實現。
缺點：
- 頁面會出現假死 -setTimeout 在等到每次 EventLoop 時，都要判斷是否到指定時間，直到時間到再執行函式，一旦遇到頁面有大量任務或者返回時間特別耗時，頁面就會出現‘假死’
- 無用的網路傳輸 -當客戶端按固定頻率向伺服器發起請求，資料可能並沒有更新，浪費伺服器資源。
- 重複傳送Http請求，查詢目標事件是否完成，優點：編寫簡單，缺點：浪費頻寬和伺服器資源
長輪詢
長輪詢即是在請求的過程中，若是伺服器端資料並沒有更新，那麼則將這個連線掛起，直到伺服器推送新的資料，再返回，然後進入迴圈週期。
具體實現：
客戶端像傳統輪詢一樣從服務端請求資料，服務端會阻塞請求不會立刻返回，直到有資料或超時才返回給客戶端，然後關閉連線，客戶端處理完響應資訊後再向伺服器傳送新的請求。
缺點：
- 保持連線會消耗資源
- 伺服器沒有返回有效資料，程式超時
- 在服務端hold住Http請求（死迴圈或者sleep等等方式），等到目標時間發生，返回Http響應。優點：在無訊息的情況下不會頻繁的請求，缺點：編寫複雜
對於客戶端來說，不管是長輪詢還是短輪詢，客戶端的動作都是一樣的，就是不停的去請求，不同的是服務端，短輪詢情況下服務端每次請求不管有沒有變化都會立即返回結果，而長輪詢情況下，如果有變化才會立即返回結果，而沒有變化的話，則不會再立即給客戶端返回結果，直到超時為止。 這樣一來，客戶端的請求次數將會大量減少（這也就意味著節省了網路流量，畢竟每次發請求，都會佔用客戶端的上傳流量和服務端的下載流量），而且也解決了服務端一直疲於接受請求的窘境。 但是長輪詢也是有壞處的，因為把請求掛起同樣會導致資源的浪費，假設還是1000個人停留在某個商品詳情頁面，那就很有可能伺服器這邊掛著1000個執行緒，在不停檢測庫存量，這依然是有問題的。 因此，從這裡可以看出，不管是長輪詢還是短輪詢，都不太適用於客戶端數量太多的情況，因為每個伺服器所能承載的TCP連線數是有上限的，這種輪詢很容易把連線數頂滿。之所以舉這個例子，只是因為大家肯定都會網購，所以這個例子比較通俗一點。
長短輪詢和長短連線的區別
- 第一個區別是決定的方式，一個TCP連線是否為長連線，是通過設定HTTP的Connection Header來決定的，而且是需要兩邊都設定才有效。而一種輪詢方式是否為長輪詢，是根據服務端的處理方式來決定的，與客戶端沒有關係。
- 第二個區別就是實現的方式，連線的長短是通過協議來規定和實現的。而輪詢的長短，是伺服器通過程式設計的方式手動掛起請求來實現的。