曾經我面試過一位學生，剛好問到HTTP的長短鏈接，于是我問他短連接的適用場景，他跟我說，WEB網站一般都使用短連接。這讓我很驚訝，同時我上網查了不少資料，發現不少人的博客都是這么說的。

而像WEB網站的http服務一般都用"短鏈接"，因為長連接對于服務端來說會耗費一定的資源，而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發量大，但每個用戶無需頻繁操作情況下需用短連好。

我一直覺得這是一種錯誤的誤導，我們先看一下什么是長短鏈接。

長短鏈接

短連接就是每次都建立鏈接-->數據傳輸-->關閉鏈接。
長連接（持久鏈接）就是 建立鏈接-->數據傳輸-->..保持鏈接..-->數據傳輸-->關閉鏈接

但是每次建立鏈接都是需要TCP三次握手的，也就是需要1.5個RTT，如果我們都是用短連接，那么每次都要進行握手。我們來看一下。

傳輸文件

假設客戶端與服務器之間的延遲是28ms，我們要傳輸2個很小的文件（一個服務器響應時間40ms,一個20ms），如果我們都是用TCP短連接的話，那么第一個要152ms，第二個需要132ms，總共284ms。

持久鏈接

但是，如果我們使用持久鏈接，那么在傳輸第二個文件就不需要握手，直接傳輸，可以減少一個RTT時間，只要228ms。假如客戶端與服務器之間只有一個TCP鏈接的話，我們使用持久鏈接傳輸n個文件，可以減少(n-1)個RTT。
所以為了優化WEB性能，我們通常使用的是長鏈接。

12306

為了印證這個推論，我看了好幾個網站，發現的確如此。大部分的HTTP請求都是長連接，帶有Connection:keep-alive參數（HTTP/1.1默認有該參數）。好了，長鏈接是會消耗服務器性能的，服務器是怎么解決這個問題的呢，那就是每個長鏈接其實都有一個超時時間，一旦超過這個時間服務器就關閉該鏈接。另外，原則上客戶端最后一次請求會帶一個close的參數（也只是原則上。。哈哈）