1）長連線能儘量減少tcp握手、揮手的次數，從而提公升效能。
2）短鏈結為每乙個http請求進行tcp握手、揮手，效能損耗大。
http （0.9/1.0）協議是個非常簡單的協議，通訊過程採用了簡單的「請求 - 應答」方式。
它底層的資料傳輸基於 tcp/ip，每次傳送請求前需要先與伺服器建立連線，客戶端收到響應報文後會[ 立即關閉tcp連線 ]。客戶端與伺服器的整個連線過程很短暫，所以就被稱為"短連線"（shortlived connections）。短連線的缺點相當嚴重，因為在 tcp 協議裡，建立連線和關閉連線都是非常"昂貴"的操作。
http 1.1協議就提出了「長連線」的通訊方式，也叫"持久連線"（persistentconnections）、「連線保活」（keep alive）、「連線復用」（connection reuse）。思路上，用的就是"成本均攤"的思路，既然 tcp 的連線和關閉非常耗時間，那麼就把這個時間成本由原來的乙個"http請求 - http應答"均攤到多個"http請求 - http應答"上。雖然不能改善 tcp 的連線效率，但每個"http請求 - http應答"的無效時間就會降低不少，整體效率也就提高了。長連線的效果如下圖所示：
因為 tcp 連線長時間不關閉，伺服器必須在記憶體裡儲存連線的狀態，其實就是占用了伺服器的資源。如果有大量的空閒長連線只連不發，就會很快耗盡伺服器的資源。
所以，長連線需要[ 在恰當的時間 ]關閉 。關閉長連線，這在客戶端或者伺服器都能做到。
在客戶端側，可以在請求頭里加上"connection: close"字段，告訴伺服器：「這次通訊完成後就關閉tcp連線」。伺服器看到這個字段，就知道客戶端要主動關閉連線，於是在響應報文裡也加上這個"connection: close"字段，響應傳送完畢後則呼叫socket api關閉該tcp連線。
伺服器端通常不會主動關閉tcp連線，但具備一些關閉長連線的策略。拿 nginx 這種伺服器來舉例，它有兩種方式：
使用"keepalive_timeout"指令，設定長連線的超時時間，如果在一段時間內tcp連線上沒有任何資料流動則主動斷開該tcp連線，從而避免空閒tcp連線占用伺服器資源。
使用"keepalive_requests"指令，設定乙個長連線上可傳送的最大http請求次數。比如設定成 n，那麼當 nginx 在這個連線上處理了 n個請求後，也會主動斷開該長連線。
http/1.1中的連線都會預設啟用長連線。客戶端不需要用頭字段指定，只要向伺服器傳送了第一次請求，後續的http請求都會重複利用第一次開啟的tcp連線，直到這個tcp連線被關閉。當然，也可在請求頭里明確地要求使用長連線機制，使用的頭字段是connection: 「keep-alive」。不過不管客戶端是否顯式要求長連線，如果伺服器支援長連線，它總會在響應報文裡放乙個connection: "keep-alive"頭欄位，告訴客戶端: 「我伺服器是支援長連線的，接下來的http請求就復用這個tcp連線。」
長短輪詢，長短連線
長短輪詢 相對於 客戶端動作來講是沒有區別的，都是不停的去請求，區別在於後端的反應和前端的行為。由於都比較占用服務端資源，就不說這些缺點了 短輪詢 是前端不停的請求，後端有沒有資料都會返回，前端拿到的是否為空資料也都繼續請求，因此，前端的資料不太好。長輪詢 也是前端不停的請求，後端去判斷 有資料返回...
TCP長短連線
tcp 長短連線 1 什麼是 tcp長連線 從應用層來看，就是 client 到server 建立一次連線，傳送多個資料報，直到不再與 server 通訊時關閉連線。connect send recv send recv close。從傳輸層來看，使用的是 keep alive timer 實現 t...
TCP報文結構和長短連線
一 報文結構介紹 在開始講tcp連線過程時，還是先看看tcp報文的格式如圖1所示。ip資料報此時由ip頭部 tcp頭部 tcp資料組成。不帶選項的tcp頭部是20位元組長，而帶選項的，tcp頭部最長可達60位元組。常見的選項包括最大的大小 mss 時間戳 傳輸控制時使用 視窗縮放 流量控制時使用 選...