1.什麼是長連線、短連線？

　　在HTTP/1.0中，預設使用的是短連線。也就是說，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連線，任務結束就中斷連線。如果客戶端瀏覽器訪問的某個HTML或其他型別的 Web頁中包含有其他的Web資源，如JavaScript檔案、影象檔案、CSS檔案等，每遇到這樣一個Web資源，就會建立一個HTTP會話。

      從HTTP/1.1起，預設使用的是長連線，用以保持連線特性。使用長連線的HTTP協議，會在響應頭有加入：Connection:keep-alive。在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸HTTP資料的 TCP連線不會關閉，如果客戶端再次訪問這個伺服器上的網頁，會繼續使用這一條已經建立的連線。Keep-Alive不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間。

為什麼這麼說呢？

我們知道，HTTP協議是基於請求/響應模式的，因此只要服務端給了響應，本次HTTP連線就結束了，或者更準確的說，是本次HTTP請求就結束了，根本沒有長連線這一說。那麼自然也就沒有短連線這一說了。

而人們常說HTTP分為長連線和短連線，其實本質上是說的TCP連線。因為TCP連線是一個雙向的通道，它是可以保持一段時間不關閉的，所以TCP連線才有真正的長連線和短連線這一說。畢竟HTTP協議說到底是應用層的協議，而TCP才是真正的傳輸層協議，只有負責傳輸的這一層才需要建立連線。

對於HTTP連線來說，本帥博主覺得用HTTP請求和HTTP響應來表示會更準確一些，而HTTP請求和HTTP響應，都是通過TCP連線這個通道來回傳輸的。

知道了HTTP長連線、短連線的實質是TCP連線之後，很多地方我們就很好解釋了。

2.相關問題

第一個問題是，是不是隻要設定Connection為keep-alive就算是長連線了？

當然是的，但要伺服器和客戶端都設定，畢竟，如果雙方想要保持好的聯絡，那麼當然要雙方都同意才行呀。

第二個問題是，我們平時用的是不是長連線？

這個也毫無疑問，當然是的。上文說到HTTP1.1預設長連線，而我們現在大多用的就是HTTP1.1。

第三個問題，長連線的作用是什麼？

如果我們找個網頁按F12檢視一下，我們會發現它用的也是長連線。如下圖：

那用長連線有啥好處？需不需要關掉長連線而使用短連線？

好處當然是有的。首先，長連線就是為了複用。上文說到長連線是指的TCP連線，也就是說複用的是TCP連線。那這就很好解釋了，也就是說，長連線情況下，多個HTTP請求可以複用同一個TCP連線，這就節省了很多TCP連線建立和斷開的消耗。

比如你請求了CSDN的一個網頁，這個網頁裡肯定還包含了CSS、JS等等一系列資源，如果你是短連線（也就是每次都要重新建立TCP連線）的話，那你每開啟一個網頁，基本要建立幾個甚至幾十個TCP連線，這浪費了多少資源就不用LZ去說了吧。

但如果是長連線的話，那麼這麼多次HTTP請求（這些請求包括請求網頁內容，CSS檔案，JS檔案，圖片等等），其實使用的都是一個TCP連線，很顯然是可以節省很多消耗。

第四個問題，長連線是不是永久連線的呢？

當然不是啦！長連線並不是永久連線的。如果一段時間內（具體的時間長短，是可以在header當中進行設定的，也就是所謂的超時時間），這個連線沒有HTTP請求發出的話，那麼這個長連線就會被斷掉。

原因也很容易理解，你想，如果長連線是永久連線的，那麼TCP連線將會越來越多，直到把伺服器的TCP連線數量撐爆到上限為止。

3.長輪詢和短輪詢

短輪詢相信大家都不難理解，比如你現在要做一個電商中商品詳情的頁面，這個詳情介面中有一個欄位是庫存量（相信這個大家都不陌生，隨便開啟淘寶或者京東都能找到這種頁面）。而這個庫存量需要實時的變化，保持和伺服器裡實際的庫存一致。

這個時候，你會怎麼做？

最簡單的一種方式，就是你用JS寫個死迴圈，不停的去請求伺服器中的庫存量是多少，然後重新整理到這個頁面當中，這其實就是所謂的短輪詢。

這種方式有明顯的壞處，那就是你很浪費伺服器和客戶端的資源。客戶端還好點，現在PC機配置高了，你不停的請求還不至於把使用者的電腦整死，但是伺服器就很蛋疼了。如果有1000個人停留在某個商品詳情頁面，那就是說會有1000個客戶端不停的去請求伺服器獲取庫存量，這顯然是不合理的。

那怎麼辦呢？長輪詢這個時候就出現了。

而對於客戶端來說，不管是長輪詢還是短輪詢，客戶端的動作都是一樣的，就是不停的去請求，不同的是服務端的處理方式。

短輪詢情況下，服務端對於每次請求不管有沒有變化都會立即返回結果，而長輪詢情況下，如果有變化才會立即返回結果，而沒有變化的話，則不會給客戶端返回結果，直到超時為止。

這樣一來，客戶端的請求次數將會大量減少，這也就意味著節省了網路流量，畢竟每次發請求，都會佔用客戶端的上傳流量和服務端的下載流量。當然，這也解決了服務端一直疲於接受請求的窘境。

但是長輪詢也是有壞處的，因為把請求掛起同樣會導致資源的浪費，假設還是1000個人停留在某個商品詳情頁面，那就很有可能伺服器這邊掛著1000個執行緒，在不停檢測庫存量，這也是不好的。

因此，從這裡可以看出，不管是長輪詢還是短輪詢，都不太適用於客戶端數量太多的情況，因為每個伺服器所能承載的TCP連線數是有上限的，這種輪詢很容易把連線數頂滿。（以上僅為舉例，不必糾結與實際情況）

4.長短輪詢和長短連線的區別

• 第一個區別是決定的方式，一個TCP連線是否為長連線，是通過設定HTTP的Connection Header來決定的，而且是需要兩邊都設定才有效。而一種輪詢方式是否為長輪詢，是根據服務端的處理方式來決定的，與客戶端沒有關係。
• 第二個區別就是實現的方式，連線的長短是通過協議來規定和實現的。而輪詢的長短，是伺服器通過程式設計的方式手動掛起請求來實現的。

好啦，以上就是關於Http長連線短連線以及長短輪詢的相關知識總結，如果大家有什麼不明白的地方或者發現文中有描述不好的地方，歡迎大家留言評論，我們一起學習呀。

Biu~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~pia！

參考文章：https://www.jianshu.com/p/3fc3646fad80

https://www.cnblogs.com/cswuyg/p/3653263.html