原文：
那就是一直認為，http連線分為長連線和短連線，而我們現在常用的都是http1.1，因此我們用的都是長連線。
這句話其實只對了一半，我們現如今的http協議，大部分都是1.1的，因此我們平時用的基本上都是長連線。但是前半句是不對的，http協議根本沒有長短連線這一說，也正因為誤解了這個，導致對於長連線一直不明不白，始終不得其要領，具體下面一段會說到。
網路上很多文章都是誤人子弟，根本沒有說明白這個概念。這裡要強調一下，http協議是基於請求/響應模式的，因此只要服務端給了響應，本次http連線就結束了，或者更準確的說，是本次http請求就結束了，根本沒有長連線這一說。那麼自然也就沒有短連線這一說了。
之所以網路上說http分為長連線和短連線，其實本質上是說的tcp連線。tcp連線是乙個雙向的通道，它是可以保持一段時間不關閉的，因此tcp連線才有真正的長連線和短連線這一說。
其實知道了以後，會覺得這很好理解。http協議說到底是應用層的協議，而tcp才是真正的傳輸層協議，只有負責傳輸的這一層才需要建立連接。
乙個形象的例子就是，拿你在網上購物來說，http協議是指的那個快遞單，你寄件的時候填的單子就像是發了乙個http請求，等貨物運到地方了，快遞員會根據你發的請求把貨物送給相應的收貨人。而tcp協議就是中間運貨的那個大貨車，也可能是火車或者飛機，但不管是什麼，它是負責運輸的，因此必須要有路，不管是地上還是天上。那麼這個路就是所謂的tcp連線，也就是乙個雙向的資料通道。
因此，lz現在甚至覺得，「http連線」這個詞就不應該出現，它只是乙個應用層的協議，根本就沒有所謂的連線這一說，就像ftp也是應用層的協議，但是你有聽說過ftp連線嗎？（恩，好像是聽過，-_-，但你現在知道了，其實所謂的ftp連線，嚴格來說，依舊是tcp連線）
實際上，說http請求和http響應會更準確一些，而http請求和http響應，都是通過tcp連線這個通道來回傳輸的。
不管怎麼說，一定要務必記住，長連線是指的tcp連線，而不是http連線。之前lz一直對一件事有些模糊不清，首先是怎麼樣就算是把http變成長連線了，是不是只要設定connection為keep-alive就算是了？
如果是的話，那都說http1.1預設是長連線，而觀察我們平時開發的web應用的http頭部，connection也確實是keep-alive，那就是說我們大部分都是用的長連線，但是長連線不是一般用於互動比較頻繁的應用嗎？像我們這種普通的web應用，比如這種，或者我的個人部落格這種，長連線有什麼用？
如果有用那用處到底是什麼，我們又不是客戶端與伺服器互動頻繁的那種應用（畢竟你開啟網頁肯定要半天才開啟另外乙個吧），如果沒用的話，那到底應不應該把connection為keep-alive這個header值給改掉，從而改成短連線？
這個疑問，在lz明白了長連線其實是指的tcp連線之後，基本上就明白了。而這個疑問，也正是lz在「以前的誤解」那一段所提到的，那個因為誤解導致lz一直搞不明白的問題。
為什麼解決了上面那個誤解之後，前面所說的這些疑問lz都明白了？
因為長連線意味著連線會被復用，畢竟一直保持著連線不就是為了重複使用嘛。但如果長連線是指的http的話，那就是說http連線可以被重複利用，這個話聽起來就感覺很彆扭。之所以覺得彆扭，其實就是lz的一種直覺，沒什麼理論依據。而這種彆扭的根源就在於，之前一直沒有融會貫通的感覺，所以總感覺缺少點什麼。不過這點疑惑，並沒有影響lz的工作，因此也就沒深究過。
但現在好了，明白了長連線實際上是指的tcp連線，lz瞬間自己就想明白了上面的那些問題。
第乙個問題是，是不是只要設定connection為keep-alive就算是長連線了？
當然是的，但要伺服器和客戶端都設定。
第二個問題是，我們平時用的是不是長連線？
這個也毫無疑問，當然是的。（現在用的基本上都是http1.1協議，你觀察一下就會發現，基本上connection都是keep-alive。而且http協議文件上也提到了，http1.1預設是長連線，也就是預設connection的值就是keep-alive）
第三個問題，也是lz之前最想不明白的問題，那就是我們這種普通的web應用（比如，我的個人部落格這種）用長連線有啥好處？需不需要關掉長連線而使用短連線？
這個問題lz現在終於明白了，問題的答案是好處還是有的。
好處是什麼？
首先，剛才已經說了，長連線是為了復用，這個在之前lz就明白。那既然長連線是指的tcp連線，也就是說復用的是tcp連線。那這就很好解釋了，也就是說，長連線情況下，多個http請求可以復用同乙個tcp連線，這就節省了很多tcp連線建立和斷開的消耗。
比如你請求了的乙個網頁，這個網頁裡肯定還包含了css、js等等一系列資源，如果你是短連線（也就是每次都要重新建立tcp連線）的話，那你每開啟乙個網頁，基本要建立幾個甚至幾十個tcp連線，這浪費了多少資源就不用lz去說了吧。
但如果是長連線的話，那麼這麼多次http請求（這些請求包括請求網頁內容，css檔案，js檔案，等等），其實使用的都是乙個tcp連線，很顯然是可以節省很多消耗的。
這樣一解釋，就很明白了，不知道大家看了這些解釋感覺如何，反正lz在自己想明白以後，有種豁然開朗的感覺。
另外，最後關於長連線還要多提一句，那就是，長連線並不是永久連線的。如果一段時間內（具體的時間長短，是可以在header當中進行設定的，也就是所謂的超時時間），這個連線沒有http請求發出的話，那麼這個長連線就會被斷掉。
這一點其實很容易理解，否則的話，tcp連線將會越來越多，直到把伺服器的tcp連線數量撐爆到上限為止。現在想想，對於伺服器來說，伺服器裡的這些個長連線其實很有資料庫連線池的味道，大家都是為了節省連線重複利用嘛，對不對？
前面基本上lz已經把長短連線說的差不多了，接下來說說長短輪詢，今天也正是為了研究長短輪詢，lz才順便研究了下長短連線這回事。
短輪詢相信大家都不難理解，比如你現在要做乙個電商中商品詳情的頁面，這個詳情介面中有乙個欄位是庫存量（相信這個大家都不陌生，隨便開啟**或者京東都能找到這種頁面）。而這個庫存量需要實時的變化，保持和伺服器裡實際的庫存一致。
這個時候，你會怎麼做？
最簡單的一種方式，就是你用js寫個死迴圈，不停的去請求伺服器中的庫存量是多少，然後重新整理到這個頁面當中，這其實就是所謂的短輪詢。
這種方式有明顯的壞處，那就是你很浪費伺服器和客戶端的資源。客戶端還好點，現在pc機配置高了，你不停的請求還不至於把使用者的電腦整死，但是伺服器就很蛋疼了。如果有1000個人停留在某個商品詳情頁面，那就是說會有1000個客戶端不停的去請求伺服器獲取庫存量，這顯然是不合理的。
那怎麼辦呢？
長輪詢這個時候就出現了，其實長輪詢和短輪詢最大的區別是，短輪詢去服務端查詢的時候，不管庫存量有沒有變化，伺服器就立即返回結果了。而長輪詢則不是，在長輪詢中，伺服器如果檢測到庫存量沒有變化的話，將會把當前請求掛起一段時間（這個時間也叫作超時時間，一般是幾十秒）。在這個時間裡，伺服器會去檢測庫存量有沒有變化，檢測到變化就立即返回，否則就一直等到超時為止。
而對於客戶端來說，不管是長輪詢還是短輪詢，客戶端的動作都是一樣的，就是不停的去請求，不同的是服務端，短輪詢情況下服務端每次請求不管有沒有變化都會立即返回結果，而長輪詢情況下，如果有變化才會立即返回結果，而沒有變化的話，則不會再立即給客戶端返回結果，直到超時為止。
但是長輪詢也是有壞處的，因為把請求掛起同樣會導致資源的浪費，假設還是1000個人停留在某個商品詳情頁面，那就很有可能伺服器這邊掛著1000個執行緒，在不停檢測庫存量，這依然是有問題的。
因此，從這裡可以看出，不管是長輪詢還是短輪詢，都不太適用於客戶端數量太多的情況，因為每個伺服器所能承載的tcp連線數是有上限的，這種輪詢很容易把連線數頂滿。之所以舉這個例子，只是因為大家肯定都會網購，所以這個例子比較通俗一點。
哪怕輪詢解決不了獲取庫存這個問題，但只要大家明白了長短輪詢的區別，這就足夠了。實際上，據lz自己平日裡購物的觀察，那個庫存量應該是不會變的，這個例子純屬lz個人的意淫，-_-。
這裡簡單說一下它們的區別，lz這裡只說最根本的區別。
第乙個區別是決定的方式，乙個tcp連線是否為長連線，是通過設定http的connection header來決定的，而且是需要兩邊都設定才有效。而一種輪詢方式是否為長輪詢，是根據服務端的處理方式來決定的，與客戶端沒有關係。
第二個區別就是實現的方式，連線的長短是通過協議來規定和實現的。而輪詢的長短，是伺服器通過程式設計的方式手動掛起請求來實現的。
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連線是需要經過三次握手的,有一定的開銷，如果每次通訊都要重新建立連線...
長輪詢 短輪詢
長輪詢 客戶端向伺服器傳送ajax請求，伺服器接收到請求後hold住連線，直到有新訊息才返回響應資訊並關閉連線，客戶端處理完響應資訊後再向伺服器傳送新的請求。優點 在無訊息的情況下不會頻繁請求，消耗資源小。缺點 伺服器hold住連線會消耗資源，返回的資料順序無保證，難以管理維護。function a...