平時大家在查看chrome調試工具network時經常會看到Response headers和Request headers中的Connection: keep-alive。想必還是有一小部分前端的同學并不知道這個是干嘛的吧。此外keep-alive是在http 1.1的時候提出的，但在http 2.0時又不再適用。所以關于keep-alive的談論是基于http1.1的。接下來就我自己的認知來和大家簡單聊下持久連接。
一、連接耗時（開啟keep-alive的必要性）
如果你用 Chrome 的來分析 network 的話，你就會發現小文件如 JS/CSS 瓶頸其實在延時。舉個例子假設你有個 JS 大小是 100KB，然后你在用 2Mbps 的 ADSL(下載速度： 2000 / 8 = 250KB/s)，帶寬耗時是 400ms。
在開始傳輸這 100KB 前,還需要在以下三個地方耗費一定時間：
1. DNS 查詢要 1 個 RTT（Round Trip Time往返時間，即 ping 時間）
2. 建立 TCP 連接要 1 個 RTT
3. 再建立 SSL 要 3 個 RTT
4. 之后 HTTP 發請求又 1 個 RTT
假設你的 ping 是 25ms，6 個 RTT 就是 150ms。總和 550ms，延時占總和的 27.27%(150 / 550)。這絕對不是個小數字，可以有很大的優化空間。
二、常用設置
1.開啟：http 1.1中默認啟用Keep-Alive，目前大部分瀏覽器都是用http1.1協議，也就是說默認都會發起Keep-Alive的連接請求。
2. 關閉：在http頭中設置Connection: close，即可關閉。
3.設置連接時間： 在http header中設置Keep-Alive: timeout=5, max=1000
timeout是超時時間，單位秒，超過這個時間后就斷開連接
max是最多的連接次數，若超過這個次數就強制斷開連接
三、延伸：TCP Keep-Alive（三個參數：超時：tcp_keepalive_time，再次發送偵測包時間間隔：tcp_keepalive_intvl，探測次數：tcp_keepalive_probes）
????? TCP Keep-Alive是tcp的一種檢測tcp連接狀況的保鮮機制。其原理大概如下：
????? 當網絡兩端建立了TCP連接之后，雙方沒有任何數據流發送往來tcp_keepalive_time時間后，服務器內核就會嘗試向客戶端發送偵測包，來判斷TCP連接狀況(客戶端崩潰、強制關閉應用等等情況)。如果沒有收到對方的回答，會在tcp_keepalive_intvl時間后再次發送偵測包，直到收到對方的回復，若一直沒收到回復，則在嘗試tcp_keepalive_probes次后丟棄該tcp連接。
