長連線和短連線

大多數人都知道HTTP1.0不支援長連線，知道HTTP1.1支援長連線。這是業界的一個常識。然而這樣的描述導致了一些不做網路底層開發的開發者都下意識的認為HTTP1.1是一個可以建立長連線的的協議。（其實TCP協議才是）

“HTTP是一種應用層的網路協議”，長連線是存在於網路層的一種連線狀態，而實現它則需要在傳輸層進行開發，因為它是基於對真實資料的收發，需要在底層進行管控。那麼作為應用層的HTTP協議，如何能實現“長連線呢“？

HTTP作為應用層協議，其實它的生命週期在伺服器返回結果時就已經結束了，而所謂的支援長連線，其實是基於'Keep-Alive'請求頭所約定，從而向下進行長連線發起的一種機制。該長連線依然是基於TCP的。因此：*所謂HTTP1.1及以上支援長連線，並不是HTTP1.1可以建立長連線，而是它支援以請求頭的方式進行長連線發起（並且要求客戶端與服務端都要具備 ‘Keep-Alive: true’ ，意思就是客戶端與服務端都要支援長連線）。

• 短連線所謂短連線，及連線只保持在資料傳輸過程，請求發起，連線建立，資料返回，連線關閉。它適用於一些實時資料請求，配合輪詢來進行新舊資料的更替。
• 長連線長連線便是在連線發起後，在請求關閉連線前客戶端與服務端都保持連線，實質是保持這個通訊管道，之後便可以對其進行復用。它適用於涉及訊息推送，請求頻繁的場景（直播，流媒體）。連線建立後，在該連線下的所有請求都可以重用這個長連線管道，避免了頻繁了連線請求，提升了效率。
  容易混淆的長短連線長短輪詢
  所謂輪詢，即是在一個迴圈週期內不斷髮起請求來得到資料的機制。只要有請求的的地方，都可以實現輪詢，譬如各種事件驅動模型。它的長短是在於某次請求的返回週期。
• 短輪詢短輪詢指的是在迴圈週期內，不斷髮起請求，每一次請求都立即返回結果，根據新舊資料對比決定是否使用這個結果。
• 長輪詢而長輪詢及是在請求的過程中，若是伺服器端資料並沒有更新，那麼則將這個連線掛起，直到伺服器推送新的資料，再返回，然後再進入迴圈週期。
  由上可以看到，長短輪詢的理想實現都應當基於長連線，否則若是迴圈週期太短，那麼伺服器的荷載會相當重；當然，即便是在長連線下，訪問人數過多，長短輪詢都有可能造成伺服器的瞬時訪問量龐大，這就需要一些相應的優化實踐了。