http的持久連線和非持久連線區別
阿新 • • 發佈：2019-01-16
HTTP 協議概要 非持久連線
“非持久連線”的概念
某網頁由最基本的 HTML 和10個JPEG 影象構成，10個JPEG 影象檔案存放在同一臺伺服器中。設這個網頁的URL為www.server.com/somepath/index.html。如果使用者請求該網頁並採用“非持久連線”，那麼在HTTP 客戶（通常是使用者瀏覽器）和伺服器之間將發生以下操作：
1． HTTP 客戶端初始化一個與伺服器主機www.server.com中的HTTP伺服器的TCP 連線。伺服器使用預設埠80監聽來自HTTP客戶的建立連線請求。
2． HTTP客戶端經由與TCP關聯的本地Socket發出一個HTTP請求訊息（Request）。這個訊息中包含路徑名/somepaht/index.html。
3． HTTP伺服器經由與TCP關聯的本地Socket接收到這個請求訊息，再從伺服器主機的記憶體或者硬碟中取出檔案/somepath/index.html，經由同一Socket向 HTTP客戶端傳送包含該檔案的響應訊息(Response Message)。
4． HTTP伺服器通知TCP服務層關閉這個TCP連線；TCP服務層並不立即關閉這個連線，而是在客戶收到剛才那個響應訊息後才會真正終止這個連線。
5． HTTP客戶端經由同一Socket接收這個響應訊息(Response Message)。TCP連線隨後終止。客戶端所收到的訊息中封裝了客戶端所請求的 HTML檔案。客戶端瀏覽器從中取出這個檔案，加以分析後發現這個檔案中還有有10個JPEG物件引用。
6． 對每個引用到的JPEG物件重複步驟1～4。
上述步驟之所以稱為使用非持久連線，原因是每次伺服器傳送一個物件後相關的TCP連線就被關閉，也就是說每個連線沒有持續到可以傳輸其他物件。每個TCP連線只能傳送一個請求訊息和響應訊息。就上述例子，使用者請求的那個Web頁面就產生了11個TCP連線（1個網頁請求連線和10個圖象請求連線）。
在上述的例子中，並沒有明確指出客戶是依次開啟10 逐一取得每個JPEG 物件，還是同時開啟多個 TCP連線同時取得多個 JPEG物件。實際上，現今的瀏覽器允許使用者通過配置來控制並行連線的程度。大多數瀏覽器預設可以開啟5～10個並行TCP連線，每個連線處理一個請求/響應事務。如果把並行連線數設定為1，那樣的話這個傳送JPEG的10個連線是序列建立的。使用並行連線可以縮短響應時間。
從客戶請求基本HTML檔案到它收到這個檔案所經歷的時間為往返時間（Round Trip Time - RTT）。它是一個小分組從客戶端遊動到伺服器在返回客戶端所花費的時間。RTT包括分組傳播延遲、在中間路由器和交換機上的分組排隊延遲以及分組處理延遲。下面考慮使用者點選某個超連結時會發生什麼。使用者的點選導致瀏覽器發起建立一個與Web伺服器的TCP連線；這裡涉及“三次握手”過程。首先是客戶向伺服器傳送一個小的冗餘訊息，接著是伺服器向客戶確認並以一個小的TCP訊息作為響應，最後是客戶向伺服器回送確認。“三次握手”過程的前兩次握手結束時流逝的時間為1個RTT。此時客戶把HTTP請求訊息傳送到TCP連線中，接著，客戶將第三次握手過程最後一次的確認訊息捎帶在這個請求資料分組中傳送出去。伺服器收到來自TCP的請求訊息後，把相應的HTML檔案傳送到TCP連線中，伺服器接著把對早先收到的客戶請求訊息中的確認捎帶資料包含在該HTML檔案的資料分組中傳送出去。這輪HTTP請求/響應也花費了1個RTT時間。因此，總的響應時間粗略的算是2個RTT加上伺服器傳送這個HTML檔案的時間。
持久連線
非持久連線缺點。
缺點（一）客戶得為每個待請求的物件建立並維護一個新得連線。對於每個這個的連線，TCP必須同時在客戶端和伺服器端分配TCP緩衝區，並維護TCP變數。對於有可能同時為來自數百個不同客戶的請求提供服務的Web伺服器來說，這會嚴重增加伺服器的負擔；
缺點（二）對每個物件請求都有2個RTT的響應延遲：一個RTT用於建立TCP連線，另一個RTT用於請求和接收物件；
缺點（三）每個物件都要經歷 TCP 緩啟動，因為每個TCP連線都要起始於slow start 階段。並行TCP連線的使用能夠部分減輕RTT延遲和緩啟動的影響。
在持久連線情況下，伺服器在發出響應後保持TCP連線繼續開啟著。同一客戶/伺服器之間的後續請求和響應可以通過這個連線傳遞。整個Web頁面上，比如 1個基本HTML和10個JPEG物件的頁面，可以通過單個的持久TCP連線傳送。甚至存放在同一個伺服器中的多個Web頁面也可以通過單個持久TCP連線傳送。通常，HTTP伺服器在某個連線閒置了一段時間後就關閉它，而這段時間通常是可以配置的。持久連線分為不帶流水線（without pipeline）和帶流水線（with pipeline）兩個版本。如果是步帶流水線的版本，那麼客戶只能在接收到前一個請求的響應後才會傳送新的請求。這種情況下，Web頁面所引用的每個物件（上例中的10個JPEG影象）都經歷1個RTT延遲用於請求和接收該物件。於非持久連線中每個物件需要2個RTT相比，不帶流水線的持久連線已經有所改善。不過，帶流水線的持久連線還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，伺服器送出一個物件後開始等待下一個請求，而這個新的請求卻不能馬上到達。這段時間伺服器資源便閒置了。
HTTP/1.1的預設模式是使用帶流水線的持久連線。這種情況下，HTTP客戶每遇到一個物件引用就立即發出一個請求，因而HTTP客戶可以一個接一個連續發出各個引用物件的請求。伺服器收到這些請求後，也可以一個接一個連續傳送各個物件。如果所有的請求和響應都連續傳送的，那麼所有引用到的物件供給經歷1個RTT延遲，而不是像不帶流水線版本那樣，每個引用都必須有1個RTT延遲。另外，帶流水線的持久連線中伺服器空等待時間比較少。與非持久連線相比，持久連線，無論是否帶流水線降低了1個RTT延遲外，緩啟動延遲也比較小。其原因在於既然各個物件都使用同一個TCP連線，伺服器傳送第一個物件後就不必再以一開始的緩慢速率傳送後續物件了。相反，伺服器可以按照第一個物件傳送完畢後的速率傳送下一個物件。
“非持久連線”的概念
某網頁由最基本的 HTML 和10個JPEG 影象構成，10個JPEG 影象檔案存放在同一臺伺服器中。設這個網頁的URL為www.server.com/somepath/index.html。如果使用者請求該網頁並採用“非持久連線”，那麼在HTTP 客戶（通常是使用者瀏覽器）和伺服器之間將發生以下操作：
1． HTTP 客戶端初始化一個與伺服器主機www.server.com中的HTTP伺服器的TCP 連線。伺服器使用預設埠80監聽來自HTTP客戶的建立連線請求。
2． HTTP客戶端經由與TCP關聯的本地Socket發出一個HTTP請求訊息（Request）。這個訊息中包含路徑名/somepaht/index.html。
3． HTTP伺服器經由與TCP關聯的本地Socket接收到這個請求訊息，再從伺服器主機的記憶體或者硬碟中取出檔案/somepath/index.html，經由同一Socket向 HTTP客戶端傳送包含該檔案的響應訊息(Response Message)。
4． HTTP伺服器通知TCP服務層關閉這個TCP連線；TCP服務層並不立即關閉這個連線，而是在客戶收到剛才那個響應訊息後才會真正終止這個連線。
5． HTTP客戶端經由同一Socket接收這個響應訊息(Response Message)。TCP連線隨後終止。客戶端所收到的訊息中封裝了客戶端所請求的 HTML檔案。客戶端瀏覽器從中取出這個檔案，加以分析後發現這個檔案中還有有10個JPEG物件引用。
6． 對每個引用到的JPEG物件重複步驟1～4。
上述步驟之所以稱為使用非持久連線，原因是每次伺服器傳送一個物件後相關的TCP連線就被關閉，也就是說每個連線沒有持續到可以傳輸其他物件。每個TCP連線只能傳送一個請求訊息和響應訊息。就上述例子，使用者請求的那個Web頁面就產生了11個TCP連線（1個網頁請求連線和10個圖象請求連線）。
在上述的例子中，並沒有明確指出客戶是依次開啟10 逐一取得每個JPEG 物件，還是同時開啟多個 TCP連線同時取得多個 JPEG物件。實際上，現今的瀏覽器允許使用者通過配置來控制並行連線的程度。大多數瀏覽器預設可以開啟5～10個並行TCP連線，每個連線處理一個請求/響應事務。如果把並行連線數設定為1，那樣的話這個傳送JPEG的10個連線是序列建立的。使用並行連線可以縮短響應時間。
從客戶請求基本HTML檔案到它收到這個檔案所經歷的時間為往返時間（Round Trip Time - RTT）。它是一個小分組從客戶端遊動到伺服器在返回客戶端所花費的時間。RTT包括分組傳播延遲、在中間路由器和交換機上的分組排隊延遲以及分組處理延遲。下面考慮使用者點選某個超連結時會發生什麼。使用者的點選導致瀏覽器發起建立一個與Web伺服器的TCP連線；這裡涉及“三次握手”過程。首先是客戶向伺服器傳送一個小的冗餘訊息，接著是伺服器向客戶確認並以一個小的TCP訊息作為響應，最後是客戶向伺服器回送確認。“三次握手”過程的前兩次握手結束時流逝的時間為1個RTT。此時客戶把HTTP請求訊息傳送到TCP連線中，接著，客戶將第三次握手過程最後一次的確認訊息捎帶在這個請求資料分組中傳送出去。伺服器收到來自TCP的請求訊息後，把相應的HTML檔案傳送到TCP連線中，伺服器接著把對早先收到的客戶請求訊息中的確認捎帶資料包含在該HTML檔案的資料分組中傳送出去。這輪HTTP請求/響應也花費了1個RTT時間。因此，總的響應時間粗略的算是2個RTT加上伺服器傳送這個HTML檔案的時間。
持久連線
非持久連線缺點。
缺點（一）客戶得為每個待請求的物件建立並維護一個新得連線。對於每個這個的連線，TCP必須同時在客戶端和伺服器端分配TCP緩衝區，並維護TCP變數。對於有可能同時為來自數百個不同客戶的請求提供服務的Web伺服器來說，這會嚴重增加伺服器的負擔；
缺點（二）對每個物件請求都有2個RTT的響應延遲：一個RTT用於建立TCP連線，另一個RTT用於請求和接收物件；
缺點（三）每個物件都要經歷 TCP 緩啟動，因為每個TCP連線都要起始於slow start 階段。並行TCP連線的使用能夠部分減輕RTT延遲和緩啟動的影響。
在持久連線情況下，伺服器在發出響應後保持TCP連線繼續開啟著。同一客戶/伺服器之間的後續請求和響應可以通過這個連線傳遞。整個Web頁面上，比如 1個基本HTML和10個JPEG物件的頁面，可以通過單個的持久TCP連線傳送。甚至存放在同一個伺服器中的多個Web頁面也可以通過單個持久TCP連線傳送。通常，HTTP伺服器在某個連線閒置了一段時間後就關閉它，而這段時間通常是可以配置的。持久連線分為不帶流水線（without pipeline）和帶流水線（with pipeline）兩個版本。如果是步帶流水線的版本，那麼客戶只能在接收到前一個請求的響應後才會傳送新的請求。這種情況下，Web頁面所引用的每個物件（上例中的10個JPEG影象）都經歷1個RTT延遲用於請求和接收該物件。於非持久連線中每個物件需要2個RTT相比，不帶流水線的持久連線已經有所改善。不過，帶流水線的持久連線還能進一步降低響應延遲。不帶流水線版本的另一個缺點是，伺服器送出一個物件後開始等待下一個請求，而這個新的請求卻不能馬上到達。這段時間伺服器資源便閒置了。
HTTP/1.1的預設模式是使用帶流水線的持久連線。這種情況下，HTTP客戶每遇到一個物件引用就立即發出一個請求，因而HTTP客戶可以一個接一個連續發出各個引用物件的請求。伺服器收到這些請求後，也可以一個接一個連續傳送各個物件。如果所有的請求和響應都連續傳送的，那麼所有引用到的物件供給經歷1個RTT延遲，而不是像不帶流水線版本那樣，每個引用都必須有1個RTT延遲。另外，帶流水線的持久連線中伺服器空等待時間比較少。與非持久連線相比，持久連線，無論是否帶流水線降低了1個RTT延遲外，緩啟動延遲也比較小。其原因在於既然各個物件都使用同一個TCP連線，伺服器傳送第一個物件後就不必再以一開始的緩慢速率傳送後續物件了。相反，伺服器可以按照第一個物件傳送完畢後的速率傳送下一個物件。