參考：《http權威指南》
http允許客戶端和最終源端伺服器之間存在一串http中間實體（**、快取記憶體等）。可以從客戶端開始，逐跳地將http報文經過這些中間裝置，**到源端伺服器上。（或者進行方向傳輸）
在某些情況下，兩個相鄰的http應用程式會為它們共享的連線應用一組選項，http的connection首部欄位中有乙個由逗號分隔的連線標籤列表，這些標籤為此連線指定了一些不會傳播到其他連線中的選項。
connection首部承載3種不同型別的標籤
1）http首部欄位名，列出了只與此連線有關的首部；
2）任意標籤值，用於描述此連線的非標準選項
3）值close，說明操作完成之後需關閉這條持久連線
如果連線標籤中包含了乙個http首部欄位的名稱，那麼這個首部欄位就包含了與一些連線有關的資訊，不能將其**出去。在將報文**之前，必須刪除connection首部列出的所有首部字段。也即是，http應用程式收到一條帶有connection首部的報文時，接收端會解析傳送端請求的所有選項，並將其應用，然後會將此報文**給下一跳位址之前，刪除connection首部以及connection中列出的所有首部。二期額，可能還會有少量沒有作為connection首部值列出，但一定不能被****的逐跳首部，其中包括proxy-authenticate,proxy-connection,transfer-encoding 和 upgrade。
序列事務處理時延
如果每個事務都需要一條新的連線，那麼連線時延和慢啟動時延就會疊加起來。序列載入另乙個缺點是，有些瀏覽器在物件載入完畢之前，無法獲取物件尺寸，而且它們可能需要尺寸資訊來決定物件放在螢幕的什麼位置上，所有載入了足夠多的物件之前，無法在螢幕上顯示任何內容。
可以提高http連線效能的方法：
並行連線
通過多條連線發起併發的http請求。並行連線可以提高復合頁面的傳輸速度，但其連線也有一些缺點
每個事務都會開啟/關閉一條新的連線，會耗費時間和頻寬。
由於tcp慢啟動特性存在，每條連線的效能都會有所降低。
可開啟的並行連線數量實際上是有限的
持久化連線
web客戶端經常會開啟到同乙個站點的連線。比如，乙個web頁面上的大部分內嵌通常來自同乙個web站點，而且相當一部分指向其他物件的超鏈通常都指向同乙個站點。初始化了對某伺服器http請求的應用程式很可能會不久的將來對那台伺服器發起更多的請求，這種性質稱為站點區域性性。
因此，http/1.1允許http裝置在事務處理結束之後將tcp連線保持在開啟狀態，以便為未來的http請求重用現存的連線。在事務處理借宿之後仍然保持在開啟狀態的tcp連線稱之為持久連線。持久連線會在不同事務之間保持開啟狀態，知道客戶端或伺服器決定其關閉為之。重用已對目標伺服器開啟的空閒持久連線，就可以避開緩慢的連線建立階段。而且，已經開啟的連線還可以避免慢啟動的擁塞適應階段，以便更快速地進行資料傳輸。所以，，持久連線降低了時延和連線建立的開銷，將連線保持在已調諧狀態，而且減少了開啟連線的潛在數量。
持久連線和並行連線配合使用可能是最高效的方式。很多web應用程式都會開啟少量的並行連線，其中每個都是持久連線。持久連線有兩種型別
1）http/1.0 + keep-alive 連線
2) http/1.1 + persistent 連線
http/1.0 + keep-alive 連線
實現http/1.0 keep-alive連線的客戶端可以通過包含connection：keep-alive 首部請求將一條連線保持在開啟狀態。
如果伺服器願意為下一條請求將連線保持在開啟狀態，就在響應中包含相同的首部。如果響應中沒有connection：keep-alive首部，客戶端就認為伺服器不支援keep-alive，會在發回響應報文之後關閉連線。可以用 keep-alive通用首部中指定的、由逗號分隔的選項處理事務的數量。keep-alive首部完全是可選的，但是只有在提供connection:keep-alive時才能使用它。比如
connection: keep-alive
keep-alive: max=5,timeout=120
http/1.0中，keep-alive並不是預設使用的。客戶端必須傳送乙個connection：keep-alive請求首部來啟用keep-alive連線。
通過檢測響應中是否connection：keep-alive響應首部，客戶端可以判斷伺服器是否會發出響應之後關閉連線。**和閘道器必須執行connection首部的規則。不應該與無法確定是否支援connection首部的**伺服器建立keep-alive連線，以防止出現啞**問題。
哪些不理解connection首部，而且不知道沿著**鏈路將其傳送出去之前將該首部刪除的**，就叫盲中繼。盲中繼會是瀏覽器一直處於掛起狀態，知道客戶端或伺服器將連線超時，並將其關閉為止。為此，引入乙個名為proxy-connection的新首部，解決在客戶端後面緊跟著乙個盲中繼所帶來的問題。在顯示配置了**的情況下，現代瀏覽器都實現了proxy-connection，很多**都能理解它。對多層次**情況，proxy-connection仍然無法解決問題。
http/1.1逐漸停止了對keep-alive連線的支援，用一種名為持久連線的改進型設計取代了它。持久連線的目的與keep-alive連線的目的相同，但是工作機制更優些。http/1.1就吃連線在預設情況下是啟用的，除非特別指明，否則http/1.1假定所有的連線都是持久的，要在事務處理結束之後將連線關閉，http/1.1應用程式必須向報文中顯示地新增乙個connection：close首部。
http1.1客戶端載入在收到響應後，除非響應中包含了connection：close首部，不然http/1.1連線就仍然維持在開啟狀態。但是，客戶端和伺服器仍然可以隨時關閉空閒的連線。不傳送connection：close並不意味這伺服器承諾永遠將連線保持在開啟狀態。
只有當連線所有的報文都有正確的、自定義報文長度時，也就是說，實體主體部分的長度都和相應的content-length一致，或者用分塊傳輸編碼方式編碼的，連線誒才能持久保持。
乙個使用者客服端對任何伺服器或**最多只能維護兩條持久連線，以防伺服器過載。**可能需要更多到伺服器的連線來支援併發使用者的通訊，所有如果有n個使用者試圖反問伺服器的話，**最多要維護2n條任意伺服器或父**的連線。
管道化連線
http/1.1允許在持久連線上可選的使用請求管道。是相對於keep-alive連線的又一效能優化。在響應到達之前，可以將多條請求放入佇列，當第一條請求通過網路流向伺服器時，第二條和第三條請求也可以開始傳送了。在高時延網路條件下，這樣做可以降低網路的環迴時間，提高效能。
對管道連線的說明：
1）如果http客戶端無法確認連線是持久的，就不應該使用管道
2）必須按照與請求相同的順序回送http效應。
3）http客戶端必須做好連線會在任意時刻關閉的準備，還要準備好重發所有未完成管道化的請求。
4）出錯的時候，管道連線會阻礙客戶端了解伺服器執行的是一些列管道化請求中的哪一些。由於無法安全地重試post這樣的非冪請求，所以出錯時，就存在某些方法永遠不會被執行的風險。
http連線優化
http連線的效能優化 並行連線 能夠同一時候和多台server建立http連線 持久連線 管道化連線 復用的連線 並行連線 長處 並行連線能夠在頻寬資源充足的情況下同一時候建立多個http連線，加快頁面的載入速度。缺點 並行連線在頻寬資源不足的情況下會是連線競爭資源。效率反而下降。同一時候建立多條...
HTTP的基本優化
影響乙個 http 網路請求的因素主要有兩個 頻寬和延遲。http1.x就是基於spdy協議 http2.0可以說是spdy的公升級版 其實原本也是基於spdy設計的 但是，http2.0 跟 spdy 仍有不同的地方，如下 http2.0和spdy的區別 http2.0的多路復用和http1.x中...
HTTP1 1優化和HTTP2的優化
通過管道技術，在乙個tcp連線中，傳送多個http請求，不需要等待伺服器端對前乙個請求的響應之後，再傳送下乙個請求，但是伺服器端在響應時，要嚴格按照接收請求的順序傳送，即先接收到的請求，需要先傳送其響應，客戶端瀏覽器也是如此，接收響應的順序要按照自己傳送請求的順序來。隊首阻塞問題 如果前面收到的乙個...