長鏈接、短鏈接

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 協議的長鏈接和短鏈接，實質上是 TCP 協議的長鏈接和短鏈接。

 

2.長鏈接、短鏈接的優缺點

  

         由上能夠看出，長鏈接能夠省去較多的TCP創建和關閉的操做，減小浪費，節約時間。對於頻繁請求資源的客戶來講，較適用長鏈接。不過這裏存在一個問題，存活功能的探測週期太長，還有就是它只是探測TCP鏈接的存活，屬於比較斯文的作法，遇到惡意的鏈接時，保活功能就不夠使了。在長鏈接的應用場景下，client端通常不會主動關閉它們之間的鏈接，Client與server之間的鏈接若是一直不關閉的話，會存在一個問題，隨着客戶端鏈接愈來愈多，server遲早有扛不住的時候，這時候server端須要採起一些策略，如關閉一些長時間沒有讀寫事件發生的鏈接，這樣可 以免一些惡意鏈接致使server端服務受損；若是條件再容許就能夠以客戶端機器爲顆粒度，限制每一個客戶端的最大長鏈接數，這樣能夠徹底避免某個蛋疼的客戶端連累後端服務。

        短鏈接對於服務器來講管理較爲簡單，存在的鏈接都是有用的鏈接，不須要額外的控制手段。但若是客戶請求頻繁，將在TCP的創建和關閉操做上浪費時間和帶寬。

       長鏈接和短鏈接的產生在於client和server採起的關閉策略，具體的應用場景採用具體的策略，沒有十全十美的選擇，只有合適的選擇。

 

3.何時用長鏈接、短鏈接？

       長鏈接多用於操做頻繁，點對點的通信，並且鏈接數不能太多情的況。每一個TCP鏈接都須要三次握手，這須要時間，若是每一個操做都是長鏈接，再操做的話處理速度會下降不少，因此每一個操做完後都不斷開，次處理時直接發送數據包就OK了，不用創建TCP鏈接。例如：數據庫的鏈接用長鏈接，若是用短鏈接頻繁的通訊會形成socket錯誤，並且頻繁的socket建立也是對資源的浪費。

       像WEB網站的http服務通常都用短鏈接，由於長鏈接對於服務端來講會耗費必定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的鏈接用短鏈接會更省一些資源。若是用長鏈接，並且同時有上萬用戶，若是每一個用戶都佔用一個鏈接的話，那可想而知。因此併發量大，但每一個用戶無需頻繁操做狀況下用短鏈接最好。