HTTP持續鏈接和管道化鏈接

持續鏈接

重用已對目標服務器打開的空閒鏈接，就能夠避開緩慢的鏈接創建階段。並且，已經打開的鏈接還能夠避免慢啓動的擁塞適應階段，以便更快速地進行數據的傳輸。

創建持續鏈接keep-alive

HTTP/1.0 keep-alive鏈接的客戶端能夠經過包含Connection: Keep-Alive首部請求將一條鏈接保持在打開狀態。
HTTP/1.1客戶端默認Keep-Alive是打開的

keep-alive參數

1. 參數timeout是在Keep-Alive響應首部發送的。它估計了服務器但願將鏈接保持在活躍狀態的時間。這並非一個承諾值。
2. 參數max是在Keep-Alive響應首部發送的。它估計了服務器還但願爲多少個事務保持此鏈接的活躍狀態。這並非一個承諾值。

Keep-Alive鏈接的限制和規則

1. 發送了Connection: close請求首部以後，客戶端就沒法在那條鏈接上發送更多的請求了。
2. 只有響應報文的主體長度（Content-Length）肯定或者能夠肯定響應報文何時能發送完（Transfer-Encoding），這樣才能創建持續鏈接，不然不能
3. 每一個持久鏈接都只適用於一跳傳輸。
4. 除非請求有反作用，不然若是請求在完成以前鏈接關閉了，瀏覽器會自動從新發送該請求
5. 一個用戶客戶端對任何服務器或代理最多隻能維護兩條持久鏈接，以防服務器過載

管道化鏈接

HTTP/1.1容許在持久鏈接上可選地使用請求管道。這是相對於keep-alive鏈接的又一性能優化。在響應到達以前，能夠將多條請求放入隊列。當第一條請求經過網絡流向地球另外一端的服務器時，第二條和第三條請求也能夠開始發送了。在高時延網絡條件下，這樣作能夠下降網絡的環回時間，提升性能。

管道化的限制

1. 若是HTTP客戶端沒法確認鏈接是持久的，就不該該使用管道。
2. 必須按照與請求相同的順序回送HTTP響應
3. HTTP客戶端必須作好鏈接會在任意時刻關閉的準備，還要準備好重發全部未完成的管道化請求。若是客戶端打開了一條持久鏈接，並當即發出了10條請求，服務器可能在只處理了，比方說，5條請求以後關閉鏈接。剩下的5條請求會失敗，客戶端必須可以應對這些過早關閉鏈接的狀況，從新發出這些請求。
4. HTTP客戶端不該該用管道化的方式發送會產生反作用的請求（好比POST）。出錯的時候，管道化方式會阻礙客戶端了解服務器執行的是一系列管道化請求中的哪一些。因爲沒法安全地重試POST這樣的非冪等請求，因此出錯時，就存在某些方法永遠不會被執行的風險。

注意點和一些名詞解釋

http持續鏈接關閉時的一些問題

HTTP應用程序要作好正確處理非預期關閉的準備。若是在客戶端執行事務的過程當中，傳輸鏈接關閉了，那麼，除非事務處理會帶來一些反作用，不然客戶端就應該從新打開鏈接，並重試一次。對管道化鏈接來講，這種狀況更加嚴重一些。客戶端能夠將大量請求放入隊列中排隊，但源端服務器能夠關閉鏈接，這樣就會留下大量未處理的請求，須要從新調度。

事務反作用

反作用是很重要的問題。若是在發送出一些請求數據以後，收到返回結果以前，鏈接關閉了，客戶端就沒法百分之百地肯定服務器端實際激活了多少事務。有些事務，好比GET一個靜態的HTML頁面，能夠反覆執行屢次，也不會有什麼變化。而其餘一些事務，好比向一個在線書店POST一張訂單，就不能重複執行，否則會有下多張訂單的危險。

事務冪等性

若是一個事務，不論是執行一次仍是不少次，獲得的結果都相同，這個事務就是冪等的。實現者們能夠認爲GET、HEAD、PUT、DELETE、TRACE和OPTIONS方法都共享這一特性。客戶端不該該以管道化方式傳送非冪等請求（好比POST）。不然，傳輸鏈接的過早終止就會形成一些不肯定的後果。