http1.0協議不支援長連線，從http1.1協議以後，連線預設都是長連線
http協議是基於請求/響應模式的，因此只要服務端給了響應，本次http連線就結束了
之所以網路上說http分為長連線和短連線，其實本質上是說的tcp連線。tcp連線是乙個雙向的通道，它是可以保持一段時間不關閉的，因此tcp連線才有真正的長連線和短連線這一說。
http協議說到底是應用層的協議，而tcp才是真正的傳輸層協議，只有負責傳輸的這一層才需要建立連線。
為了能很好得明白，乙個形象的例子就是，拿你在網上購物來說，http協議是指的那個快遞單，你寄件的時候填的單子就像是發了乙個http請求，等貨物運到地方了，快遞員會根據你發的請求把貨物送給相應的收貨人。而tcp協議就是中間運貨的那個大貨車，也可能是火車或者飛機，但不管是什麼，它是負責運輸的，因此必須要有路，不管是地上還是天上。那麼這個路就是所謂的tcp連線，也就是乙個雙向的資料通道。
實際上，說http請求和http響應會更準確一些，而http請求和http響應，都是通過tcp連線這個通道來回傳輸的。
之前的疑惑
1、怎麼樣把http變成長連線，是不是只要設定connection為keep-alive就行了？
當然是的，但要伺服器和客戶端都設定。
2、如果是的話，那都說http1.1預設是長連線，而觀察我們平時開發的web應用的http頭部，connection也確實是keep-alive，那就是說我們大部分都是用的長連線？
是的，確實說明我們大部分都是用的長連線
3、長連線不是一般用於互動比較頻繁的應用嗎？像這種普通的web應用，如這種，或者我的個人部落格這種，長連線有什麼用？
長連線是為了復用，長連線指的是tcp連線，也就是說復用的是tcp連線。長連線情況下，多個http請求可以復用同乙個tcp連線，這就節省了很多tcp連線建立和斷開的消耗。
舉個例子，比如你請求了的乙個網頁，這個網頁裡肯定還包含了css、js等等一系列資源，如果你是短連線（也就是每次都要重新建立tcp連線）的話，那你每開啟乙個網頁，基本要建立幾個甚至幾十個tcp連線。但如果是長連線的話，那麼這麼多次http請求（這些請求包括請求網頁內容，css檔案，js檔案，等等），其實使用的都是乙個tcp連線，很顯然是可以節省很多消耗的。
4、如果使用長連線，像開啟乙個網頁用乙個tcp連線的話，是不是頁面響應很慢？？
會有點慢，所以http2.0就應運而生,多路復用即多個請求通過乙個tcp鏈結併發完成。
5、長連線是不是永久連線的？
長連線並不是永久連線的。如果一段時間內（具體的時間長短，是可以在header當中進行設定的，也就是所謂的超時時間），這個連線沒有http請求發出的話，那麼這個長連線就會被斷掉。這一點其實很容易理解，否則的話，tcp連線將會越來越多，直到把伺服器的tcp連線數量撐爆到上限為止。
為了方便說明先舉個例子：商品詳情的頁面中要展示庫存量。而這個庫存量需要實時的變化，保持和伺服器裡實際的庫存一致。這個時候，你會怎麼做？
短輪詢：最簡單的一種方式，就是你用js寫個死迴圈，不停的去請求伺服器中的庫存量是多少，然後重新整理到這個頁面當中，這其實就是所謂的短輪詢。這種方式有明顯的壞處，那就是你很浪費伺服器和客戶端的資源。客戶端還好點，現在pc機配置高了，你不停的請求還不至於把使用者的電腦整死，但是伺服器就很蛋疼了。如果有1000個人停留在某個商品詳情頁面，那就是說會有1000個客戶端不停的去請求伺服器獲取庫存量，這顯然是不合理的。
長輪詢：長輪詢這個時候就出現了，其實長輪詢和短輪詢最大的區別是，短輪詢去服務端查詢的時候，不管庫存量有沒有變化，伺服器就立即返回結果了。而長輪詢則不是，在長輪詢中，伺服器如果檢測到庫存量沒有變化的話，將會把當前請求掛起一段時間（這個時間也叫作超時時間，一般是幾十秒）。在這個時間裡，伺服器會去檢測庫存量有沒有變化，檢測到變化就立即返回，否則就一直等到超時為止。
對於客戶端來說，不管是長輪詢還是短輪詢，客戶端的動作都是一樣的，就是不停的去請求，不同的是服務端，短輪詢情況下服務端每次請求不管有沒有變化都會立即返回結果，而長輪詢情況下，如果有變化才會立即返回結果，而沒有變化的話，則不會再立即給客戶端返回結果，直到超時為止。
長輪詢的弊端：因為把請求掛起同樣會導致資源的浪費，假設還是1000個人停留在某個商品詳情頁面，那就很有可能伺服器這邊掛著1000個執行緒，在不停檢測庫存量，這依然是有問題的。
因此，從這裡可以看出，不管是長輪詢還是短輪詢，都不太適用於客戶端數量太多的情況，因為每個伺服器所能承載的tcp連線數是有上限的，這種輪詢很容易把連線數頂滿。之所以舉這個例子，只是因為大家肯定都會網購，所以這個例子比較通俗一點。
第乙個區別是決定的方式，乙個tcp連線是否為長連線，是通過設定http的connection header來決定的，而且是需要兩邊都設定才有效。而一種輪詢方式是否為長輪詢，是根據服務端的處理方式來決定的，與客戶端沒有關係。
第二個區別就是實現的方式，連線的長短是通過協議來規定和實現的。而輪詢的長短，是伺服器通過程式設計的方式手動掛起請求來實現的。
客戶端：長連線→http1.1 請求頭預設connection: keep-alive，不需處理；短連線→請求頭設定connection: close
服務端：**設定下請求頭connection值為 keep-alive/close
Http 長連線 短連線 長輪詢 短輪詢
短連線 每次http請求都會建立tcp連線，管理容易 長連線 只需要建立一次tcp連線，以後http請求重複使用同乙個tcp連線，管理難 http1.1規定了預設保持長連線 http persistent connection 也有翻譯為持久連線 資料傳輸完成了保持tcp連線不斷開 不發rst包 不...
HTTP 長連線 短連線 長輪詢 短輪詢
http 1.0需要使用keep alive引數來告知伺服器端要建立乙個長連線，而http1.1預設支援長連線，http的長連線很容易在空閒後自動斷開，一般來說這個時間是300s左右。http是基於tcp ip協議的，建立乙個tcp連線是需要經過三次握手的,有一定的開銷，如果每次通訊都要重新建立連線...
HTTP協議中的短輪詢 長輪詢 長連線和短連線
http1.0協議不支援長連線，但都是基於tcp連線來說的 http1.1協議預設是長連線，但都是基於tcp連線來說的，http頭部，connection是keep alive，但要伺服器和客戶端都設定，則可長連線。http協議是基於請求 響應模式的，因此只要服務端給了響應，本次http連線就結束了...