HTTP連線管理(2) – HTTP Connection Handling

本篇文章延續前一篇文章,重點整理 HTTP: The Definitive Guide一書的內容,主要著重在 HTTP Connection 的種類以及對於效能的影響。

Serial Connections

每一個 Request 會重新建立一個 Connection,根據之前所提到的影響 TCP 效能的因素(ex: slow start),可能會讓使用者覺得很緩慢。另一個是心理因素,實驗證明,雖然一次載入一個圖片比同時載入多個圖片來的快,但是使用者還是偏好同時載入多個圖片。

Parallel Connections

使用多個 TCP 連線來同時發送 HTTP request。由於 serial connection 會有 TCP setup 和slow-start的問題,所以使用 parallel connection可以讓延遲的時間重疊。但是 parallel connection並非總是很快。當遇到有限的頻寬時,每個 connection會競爭有限的頻寬,導致每個 HTML 上的物件載入速度相對變慢,整體下來在效能上並沒有太多的改善。另一個問題是,過多的connection會消耗大量的記憶體進而影響效能,因此瀏覽器通常會限制 parallel connection 的數量,而server也可以在任何時間關閉任何client的connection。瀏覽器的最大parallel connection數量根據每家公司的實作而有所不同,相關的討論可見StackOverflow的文章: http://goo.gl/b4Nwn, http://goo.gl/M8z9y

Parallel connection的問題:

1.需要開啟和關閉連線,浪費時間和效能

2.TCP slow-start的特性會降低效能

3.不同的瀏覽器允許的同時間parallel connection是有限的

Persistent Connections

由於大多數網站的資料或圖片都是放在同一個網站上,因此我們可以預期某個client發出了一個HTTP request,會有很大的機會發出另外的HTTP request到同一台伺服器上,這個特性稱為site locality。然而有鑑於parallel connection的問題,persistent connection用同一個TCP連線來傳送多個request,降低連線的延遲,因此大多數的web應用程式開啟的parallel connection同時也都是persistent connection。然而persistent connection在使用上需注意連線的管理,避免累積過多idle的連線,造成client和server資源的浪費。Persistent connection有兩種:HTTP/1.0 + Keep-Alive Connection和 HTTP/1.1 Persistent Connection

Pipelined Connections

利用同一個persistent connection,在前一個request的response尚未回來前,就馬上送出下一個request。可降低傳輸的延遲。但是使用Pipelined Connection有一些注意事項:

1.必須要是persistent connection

2.因為HTTP訊息並沒有sequence number,所以response必須要依序回傳。

3.client必須準備隨時retry,因為連線可能隨時在任何時間被中斷

4.有副作用的request(POSTs)不能被pipeline

發佈留言