HTTP 連線管理

關於 TCP 是什麼就不多說了(回去翻網路概論吧),重點在於TCP如何影響 HTTP Performance ? 承上一篇,這本書列出五項 TCP 重點 :

我們先定義一個 HTTP transaction 表示一個 request command 跟對應的 response result。

TCP connection setup handshake

在真正傳輸資料前,TCP必須先發SYN及等待SYN+ACK回覆來建立連線,因此小的 HTTP transctions(大部分的 HTTP request 如 GET 用一個 IP 封包就裝的下了 ) 花在建立連線就佔了一半的時間。

http1.jpg

TCP slow-start congestion control

TCP 在建立連線後,會先用比較慢的速度,等收到下個ACK之後才乘2加快直到上限。

TCP’s delayed acknowledgment algorithm for piggybacked acknowledgments

因為ACK封包很小,為了有效率地使用網路,TCP會弄個 buffer 來讓ACK等著跟資料封包一起發送,若在 100~200 milliseconds 中等不到才會ACK單獨發送。不過在HTTP的 request-replay 的架構下,降低了等到有相同方向資料封包要送的機會,因此造成了HTTP重大delay。

Nagle’s algorithm for data aggregation

TCP 允許一個封包不用裝滿就可以發送,因此會有封包很多但是都很小的情況發生。為了有效率地使用網路,因此這個 Nagle’s algorithm 會使用 buffer 來等資料滿了或等到別的封包都有了ACK回覆時才發送封包。但是這個演算法會讓HTTP delay因為 HTTP request 常裝不滿呀,而且若還有 delayed ack algorithm 的話會很糟(那邊也等),所以通常HTTP application會關閉這個演算法( TCP_NODELAY )。

TIME_WAIT delays and port exhaustion

這問題在 benchmarking 時比較常發生,一般使用比較不會有這個問題。首先了解到在關閉連線後,記憶體仍會保留用過的雙方 port 跟 IP 紀錄,避免有迷路的封包進來,混亂了下一個使用相同Port的軟體。通常會保留2分鐘,稱作 2MSL。

而在benchmarking的時候,會對server port 80建立很多連線,但是client的ports有限(就說 60000好了),而關閉的連線在2MSL內仍會保留port,也就是說 60000/120 = 500 transactions/sec。因此這會變成不能再快了。要真正測到server,必須多用幾台client或讓server用virtual IP來增加connection的組合。

接著討論HTTP如何最佳化連線,在這之前,先知道 HTTP 在兩個相鄰的 HTTP application 中會用 header 的 connect 參數來傳遞設定值,因此在hop-by-hop的環境中,在forward之前這個參數必須修掉。

HTTP 要面對的delay就是 Serial Tansaction Delays 問題,如果只有先載入HTML,然後依序再傳圖片一圖片二的話,這樣很慢啊,所以這裡有幾招可以處理 :

Parallel Connections : 用多個 connections 同步發送 HTTP requests

在收到HTML頁面之後,再同時發送多個連線拿其他的東西。但是注意到如果client的頻寬不夠大,那麼用這招並不會比較快,另外過大的連線也讓記憶體不夠用,尤其對server來說更不樂見,因此通常設成最多4個,而且server可以自由關閉特定client過度的連線。

http2.jpg

Persistent Connections : 重複使用 TCP connections 降低 connect/close delay

因為HTML跟圖片常在同一個站,有很高的 site locality,因此HTTP/1.1允許跨HTTP transactions保持open狀態直到client或sever決定close。大大降低 TCP setup和 slow-start的delay問題。

因此光有 Parallel 是不行的,因為每個連線都還有TCP setup跟slow-start的問題,所以必須用Persistent來搭配,但是這招用要小心,不然容易浪費資源。Persistent又分兩種: HTTP/1.0+ “keep-alive” 跟 HTTP/1.1 “persistent”

HTTP/1.0+ (HTTP 1.0後來的擴充) 的 keep-alive 在 header 中使用 Connection: Keep-Alive 表示下一次HTTP transaction仍在同一個connection,因此一但沒了這個參數,就表示要 close connection(所以每個request跟respond都要有 Connection: Keep-Alive 才行)。不過這也不保證client 或 server一定會保持連線。另外 Content-Length 也必須正確計算,不然會失敗。

keep-alive 最大問題出在 Dumb proxy,在舊型或簡單的proxy環境中會有blind relays的問題,書是有詳加解釋,在此略過。重點就是在 HTTP/1.0+ 的環境中,只有在中間沒有 proxy 的情況下,keep-alive 才會開啟。

HTTP/1.1 正式制定Persistent,而且預設就是 persistent connections,所以跟keep-alive剛好相反,是在 header 中使用 Connection: close 表示將關閉連線,同樣也不保證誰一定在收到close之後才close,任何時間都有可能 close。也同樣 Content-Langth 要正確,不然失效。HTTP/1.1 proxy 可以正確支援 persistent connections,但是不對 1.0+ 的 keep-alive 作用。RFC規格中單一client對某server或proxy最多兩個 persistent connections 避免server負擔(因此IE跟Firefox預設就是2)。

Pipelined Connections : 在一個connection 中同步發送 HTTP requests

HTTP 1.1 允許在 persistent connections使用 Pipelining,在 response 回來前,就先發送多個request,在 high-latency 的網路環境中可以大大改善效能。這限定在 persistent 中使用,而且server的 responses 必須依照當初發送的順序回到client(因為HTTP messages沒有記序號啊)。

piplelined的最大挑戰在於server可能在任意時間中斷連線,因此已經發送出來的一大串 requests 必須重新在發送,但是問題在於某些request是有side-effects的(新增修改等),亦無法得知server已經處理了哪些,所以只限定具有 idempotent (無side-effects) 性質的可以用 pipelined (如GET,HEAD),像POST是不應該用pipelined的,且送 nonidempotent request 之前,必須等之前所有request都有response。

http3.jpg

另外 Connection Close 又分成 full close 跟 half close。為了Graceful Connection Close,會先關閉 output channel,然後等對方output也關閉之後才關閉自己的input channel (但這也不保證一定會這樣啦)。這是因為如果對方送request來的時候,碰到sever的 input channel 關閉,client 會發生TCP RESET的錯誤,這會讓client清除所有還沒讀取的 buffered data(即使它已經成功從server回來了) ,這在pipelined中特別嚴重。

最後補充一下那篇加速文 :

建議打開 Pipelined : 我查了一下IE系列似乎並沒有實作這個功能(而不是預設關閉),我想是因為比較保守吧(或是偷懶?),在Firefox中也必需手動開啟,我猜想可能還是有不少風險吧(在某些網站GET也是有side-effect啊,要看網站開發者是否堅持GET的本意啊)。另外關於pipelines的功效,早在 1999年W3C 就有實驗證明快很多。其它參考連結 :

註: 本文插圖引用自 HTTP: The Definitive Guide 一書,版權屬於 O’Reilly Media, Inc.。

參與討論

5 則留言

  1. 自動引用通知: -TMA-1- » links for 2006-11-16

發佈留言

發表迴響