HTTP1.0協(xié)議不支持長連接
從HTTP1.1協(xié)議以后，連接默認(rèn)都是長連接

網(wǎng)絡(luò)上說HTTP分為長連接和短連接，其實(shí)本質(zhì)上是說的TCP連接。TCP連接是一個(gè)雙向的通道襟齿，它是可以保持一段時(shí)間不關(guān)閉的，因此TCP連接才有真正的長連接和短連接這一說枕赵。
HTTP協(xié)議說到底是應(yīng)用層的協(xié)議猜欺，而TCP才是真正的傳輸層協(xié)議，只有負(fù)責(zé)傳輸?shù)倪@一層才需要建立連接拷窜。

這里要強(qiáng)調(diào)一下开皿，HTTP協(xié)議是基于請求/響應(yīng)模式的，因此只要服務(wù)端給了響應(yīng)篮昧，本次HTTP連接就結(jié)束了赋荆，或者更準(zhǔn)確的說，是本次HTTP請求就結(jié)束了懊昨，根本沒有長連接這一說窄潭。那么自然也就沒有短連接這一說了。

只要設(shè)置Connection為keep-alive就算是長連接酵颁？
是的嫉你，但要服務(wù)器和客戶端都設(shè)置。長連接意味著連接會被復(fù)用

我們平時(shí)用的是不是長連接躏惋？
現(xiàn)在用的基本上都是HTTP1.1協(xié)議均抽，你觀察一下就會發(fā)現(xiàn)，基本上Connection都是keep-alive其掂。而且HTTP協(xié)議文檔上也提到了油挥，HTTP1.1默認(rèn)是長連接，也就是默認(rèn)Connection的值就是keep-alive

長連接好處是什么款熬？
長連接意味著連接會被復(fù)用
長連接情況下深寥，多個(gè)HTTP請求可以復(fù)用同一個(gè)TCP連接，這就節(jié)省了很多TCP連接建立和斷開的消耗贤牛。

比如你請求了博客園的一個(gè)網(wǎng)頁惋鹅，這個(gè)網(wǎng)頁里肯定還包含了CSS、JS等等一系列資源殉簸，如果你是短連接（也就是每次都要重新建立TCP連接）的話闰集，那你每打開一個(gè)網(wǎng)頁，基本要建立幾個(gè)甚至幾十個(gè)TCP連接般卑，這浪費(fèi)了資源武鲁。
但如果是長連接的話，那么這么多次HTTP請求（這些請求包括請求網(wǎng)頁內(nèi)容蝠检，CSS文件沐鼠，JS文件，圖片等等），其實(shí)使用的都是一個(gè)TCP連接饲梭，很顯然是可以節(jié)省很多消耗的乘盖。

長連接并不是永久連接的。如果一段時(shí)間內(nèi)（具體的時(shí)間長短憔涉，是可以在header當(dāng)中進(jìn)行設(shè)置的订框，也就是所謂的超時(shí)時(shí)間），這個(gè)連接沒有HTTP請求發(fā)出的話兜叨，那么這個(gè)長連接就會被斷掉

長輪詢和短輪詢

短輪詢
比如你現(xiàn)在要做一個(gè)電商中商品詳情的頁面布蔗，這個(gè)詳情界面中有一個(gè)字段是庫存量（相信這個(gè)大家都不陌生，隨便打開淘寶或者京東都能找到這種頁面）浪腐。而這個(gè)庫存量需要實(shí)時(shí)的變化纵揍，保持和服務(wù)器里實(shí)際的庫存一致。
這個(gè)時(shí)候议街，你會怎么做泽谨？
最簡單的一種方式，就是你用JS寫個(gè)死循環(huán)特漩，不停的去請求服務(wù)器中的庫存量是多少吧雹，然后刷新到這個(gè)頁面當(dāng)中，這其實(shí)就是所謂的短輪詢涂身。
這種方式有明顯的壞處雄卷，那就是你很浪費(fèi)服務(wù)器和客戶端的資源「蚴郏客戶端還好點(diǎn)丁鹉，現(xiàn)在PC機(jī)配置高了，你不停的請求還不至于把用戶的電腦整死悴能，但是服務(wù)器就很蛋疼了揣钦。如果有1000個(gè)人停留在某個(gè)商品詳情頁面，那就是說會有1000個(gè)客戶端不停的去請求服務(wù)器獲取庫存量漠酿，這顯然是不合理的冯凹。
長輪詢就出現(xiàn)了
長輪詢這個(gè)時(shí)候就出現(xiàn)了，其實(shí)長輪詢和短輪詢最大的區(qū)別是炒嘲，短輪詢?nèi)シ?wù)端查詢的時(shí)候宇姚，不管庫存量有沒有變化，服務(wù)器就立即返回結(jié)果了夫凸。而長輪詢則不是浑劳，在長輪詢中，服務(wù)器如果檢測到庫存量沒有變化的話寸痢，將會把當(dāng)前請求掛起一段時(shí)間（這個(gè)時(shí)間也叫作超時(shí)時(shí)間呀洲，一般是幾十秒）紊选。在這個(gè)時(shí)間里啼止，服務(wù)器會去檢測庫存量有沒有變化道逗，檢測到變化就立即返回，否則就一直等到超時(shí)為止献烦。
這樣一來滓窍，客戶端的請求次數(shù)將會大量減少（這也就意味著節(jié)省了網(wǎng)絡(luò)流量，畢竟每次發(fā)請求巩那，都會占用客戶端的上傳流量和服務(wù)端的下載流量）吏夯，而且也解決了服務(wù)端一直疲于接受請求的窘境。
但是長輪詢也是有壞處的即横，因?yàn)榘颜埱髵炱鹜瑯訒?dǎo)致資源的浪費(fèi)噪生，假設(shè)還是1000個(gè)人停留在某個(gè)商品詳情頁面，那就很有可能服務(wù)器這邊掛著1000個(gè)線程东囚，在不停檢測庫存量跺嗽，這依然是有問題的。
因此页藻，從這里可以看出桨嫁，不管是長輪詢還是短輪詢，都不太適用于客戶端數(shù)量太多的情況份帐，因?yàn)槊總€(gè)服務(wù)器所能承載的TCP連接數(shù)是有上限的璃吧，這種輪詢很容易把連接數(shù)頂滿。之所以舉這個(gè)例子废境，只是因?yàn)榇蠹铱隙ǘ紩W(wǎng)購畜挨，所以這個(gè)例子比較通俗一點(diǎn)。
哪怕輪詢解決不了獲取庫存這個(gè)問題噩凹，但只要大家明白了長短輪詢的區(qū)別朦促，這就足夠了。實(shí)際上栓始，據(jù)LZ自己平日里購物的觀察务冕，那個(gè)庫存量應(yīng)該是不會變的，這個(gè)例子純屬LZ個(gè)人的意淫幻赚，-_-禀忆。

長短輪詢和長短連接的區(qū)別

第一個(gè)區(qū)別是決定的方式，一個(gè)TCP連接是否為長連接落恼，是通過設(shè)置HTTP的Connection Header來決定的箩退，而且是需要兩邊都設(shè)置才有效。而一種輪詢方式是否為長輪詢佳谦，是根據(jù)服務(wù)端的處理方式來決定的戴涝，與客戶端沒有關(guān)系。
第二個(gè)區(qū)別就是實(shí)現(xiàn)的方式，連接的長短是通過協(xié)議來規(guī)定和實(shí)現(xiàn)的啥刻。而輪詢的長短奸鸯，是服務(wù)器通過編程的方式手動掛起請求來實(shí)現(xiàn)的.