HTTP協議學習總結五（持久鏈接）

##一條http請求的消耗 http協議是創建在tcp/ip協議之上的，當客戶端請求服務端資源時，雙方會創建一個tcp鏈接。tcp鏈接的代價是比較大的，一次鏈接客戶端和服務器總共要發三次包。 若是一次請求多個資源時，那麼消耗會至關的大，時間也會好久

---

http持久鏈接Connection：keep-alive

在前面講請求頭時，我提到過http請求頭Connection：keep-alive，經過這個請求頭，客戶端就能夠告訴服務器，暫時不要關閉tcp鏈接，下一個請求利用這個tcp鏈接繼續傳輸數據. 固然了，tcp鏈接是會浪費必定的服務器資源的，因此tcp鏈接也不會一直保持鏈接，客戶端和服務端均可以經過Connection：close顯示的告訴對方，鏈接已經關閉。若是沒有告訴的話，服務器通常會有一個超時時間，在指定的timeout時間裏，若是沒有新的數據經過這個tcp鏈接傳輸進來的話，服務器就當這個鏈接已經結束，會關閉鏈接。

---

##web應用的資源請求方式 每每咱們經過瀏覽器去訪問一個web應用，一般服務器會返回一個html頁面，客戶端解析html頁面，而後繼續請求javascript腳本、css樣式、圖片等資源。若是一個資源一個資源的去請求，那麼客戶端可能須要很長時間才能看到加載完成後的頁面，這對於一個資源比較多的web應用是不能接受的，這麼慢的瀏覽器客戶端也不會有人使用。那麼瀏覽器是用什麼方式提升加載速度的呢？

---

##並行鏈接 現代的瀏覽器每每採用並行鏈接的方式，在同一個時間點內打開多個tcp鏈接，並行的加載資源。那麼並行的打開多少個鏈接合適呢？ 可能有人會說，有多少個資源請求就打開多少個tcp鏈接應該是最快的。事實狀況卻不是這樣的，由於打開的不是門，而是tcp鏈接，3次握手也是須要時間消耗的，因此打開多也不必定響應快，同時tcp鏈接也是消耗服務器資源的，一個客戶端一次就打開N個鏈接，那麼訪問量大了，服務器的負載能力也就慢了，響應時間確定也就長了。 一般瀏覽器只會並行打開少許的tcp鏈接（不會超過5個）。

---

##持久鏈接+並行鏈接 既然並行鏈接不必定是最快的，那麼現代瀏覽器通常採用什麼方式呢？通用的方式是這樣的，當用戶輸入想要訪問的資源後，客戶端先打開一條持久鏈接獲取html資源，而後解析html，獲取須要繼續請求的資源（js，css，img等），併發的打開少許持久鏈接，請求一部分資源，剩下的資源會在上面請求的資源到達後，再利用這些尚未關閉的tcp鏈接，繼續請求資源。 經過結合持久鏈接和並行鏈接可讓資源請求速度更快，也讓服務器負載不是那麼大。