WWW 的運作,基本上,是倚靠名為HTTP(HyperText Transfer Protocol)的通訊協定,此協定的第一版為HTTP/1.0,但在 1999 年做了一些改進之後,制定該協定規格的 IETF,將此改版命名為HTTP/1.1。而1999年問世的HTTP/1.1協定,可以說是主宰了整個Internet的流量至今,而且,成為了 Internet 最重要的應用層通訊協定之一。

但即使HTTP有著如此的重要性,而且伴隨著Web 的應用持續不斷的壯大,幾乎可以說它就是 Internet 的主角了,但是它本身並非毫無缺點,事實上它的缺點還挺明顯的。HTTP就跟許多取得主宰性地位的協定一樣,其之所以能取得支配性的地位,不在其協定本身設計之優勢,而是有著其他的時空因素。HTTP簡單易用、伴隨著Web的快速成長而成長,最終得到了今天的地位。

但這組沿用許久未改版的協定,也因為網路生態的改變,而使其缺點影響層面愈來愈大,這些缺點主要集中在效能部份。因為HTTP主宰了Internet 的流量,因此,任何一點效能問題,都足以產生巨大的影響。

在制定、設定HTTP時,可能也沒料想到今天應用的榮景。以今日瀏覽器所瀏覽的網頁來說,其中伴隨著的各種檔案不僅數量多,而且檔案長度也大,和十幾年前的情況相比又大有所不同了。

HTTP既有版本的問題

綜觀這十幾年來的應用,HTTP被觀察出那些傳輸效率上的缺點呢?首先,要先指出來,傳輸效率的不彰不見得單靠頻寬的擴增就能夠解決。的確,今日的頻寬和十幾年前也是大幅成長、無法相提並論,因此,網路的基礎設施足以支持大檔案的應用。但是,增加頻寬可以降低傳輸大檔案的時間,卻無法解決HTTP協定本質上所造成的「延遲(latency)」。

HTTP 底層的協定是TCP,因此,當HTTP的客戶端想要取得一個檔案資源時,就必須在一個TCP連線上發出請求。HTTP是一個基於「請求-回應」的協定,也是說,總是由客戶端發出請求,而伺服器端對應一個回應。

在HTTP的伺服器端收到請求資訊後,會開始處理該請求,在完成請求的處理之後,開始回傳回應的內容。當HTTP伺服器端在處理請求時,整個TCP連線其實處於一個閒置的情況,此外,客戶端所能做的事也只有等待。

而且,通常一個要能夠在瀏覽器中瀏覽完整的網頁內容,這中間涉及許多的檔案需要透過HTTP去取得,而單一個TCP連線只能同時間處理一個檔案,為此,瀏覽器通常都會同時建立多個連線,以利更快的取得多個檔案的內容。否則,以HTTP的天性,必須逐一等待伺服器傳輸完前一個檔案後,才能夠再繼續取得下一個檔案。

面對傳輸效率不佳的狀況

在最早的HTTP/1.0協定中,每次發出一個HTTP的請求都需要重新建立一個TCP連線,當該請求的回應內容傳輸完畢之後,該TCP連線即會被切斷,而這是一個非常沒有效率的事情,怎麼說呢?

第一個原因,是TCP在建立連線時,連線的兩方需要完成一個所謂3-Way Handshaking的動作,這會造成不小的延遲。對於一些每建立一個TCP連線,就會持續使用很長一段時間的應用來說,這個初始建立連線的延遲一點也不重要。例如,透過telnet協定連往BBS站時,只會建立一個TCP連線,卻可以使用很長一段時間,這段建立連線所造成的延遲,就不影響整個大局。

但是,對基於「請求-回應」模式的HTTP來說,如果透過HTTP回傳的檔案不夠大時,例如一個只有幾十 KB的HTML檔案,它可能不需要太多時間就可以完成傳輸,那麼花在建立TCP連線上的延遲,佔整體的比例就會高出很多。

在HTTP/1.0中更糟的是,一旦完成傳輸後,就會切斷TCP連線,之後倘若要請求另一個檔案,又必須重新建立一個全新的TCP連線,這使得每次都需要反覆不斷花費高昂的代價,在建立 TCP 連線之上,但每個TCP連線,卻又可能只傳輸少許的資料,就又被切斷了。

為此,在HTTP/1.1中,增加了讓連線「保持存活(Keep Alive)」的標頭(header),讓客戶端及伺服器端可以協調重複運用同一個TCP連線,每當客戶端接收完來自伺服器端的回應內容後,可以繼續在同一 TCP 連線裡發出下一個請求。

但這樣的設計可以讓情況好轉,但並沒有辦法完全解決,因為這個「保持存活」的情況,若是客戶端在一段時間內,並沒有繼續在TCP連線中發出下一個請求,此TCP連線亦會被切斷。

讓我們想想網頁瀏覽的行為模式,通常都是在載入完諸多檔案完畢後,使用者開始花時間瀏覽。在載入諸多檔案時,「保持存活」的特性,可以避免重新建立太多TCP連線,但是當使用者在瀏覽網頁時,瀏覽器常不會再發送太多的請求至伺服器端,此時,先前已建立的TCP連線就會被切斷。等待使用者再連結到下一個網頁時,瀏覽器仍然必須重新建立若干個全新的TCP連線。

建立TCP連線的額外負擔當中,除了上述的3-Way Handshaking之外,還有一個部分,就是 TCP 的「緩起步( slow start)」特性。

TCP本身是一個具有流量控制(flow control),以及擁塞控制(congestion control)能力的協定,因此,它會試著估算單位時間內要傳輸多少資料量最有效率。當頻寬本身不足時,若是單位時間內試著傳輸太多的資料量至另一端,但卻無法即時傳輸完成,就會造成擁塞。另一方面,若是頻寬充足,但卻傳輸的太少,又會造成效率不彰、無法善用頻寬的情況。

因此,TCP的演算法會盡量優化此事,而緩起步正是其演算法中的一環。TCP會逐步視情況擴展單位時間內所傳輸的資料量,但在網路連線剛建立之際,它會試著從很小的傳輸量開始嘗試,這使得在連線剛建立的初期,無法善用實際上可能十分充足的頻寬。

會產生很多短命的TCP連線

就和 3-Way Handshaking 一樣,對於那種生命期很短的TCP連線來說,所造成的延遲影響比例就相對高出許多。但HTTP協定本身,就傾向於製造出諸多生命期很短的TCP連線,因此,我們可以說,因為 HTTP 的天性,使得這些延遲產生出比較大的負面效應。

此外,同時間多個TCP連線並行傳輸的情況,也可能讓 TCP 演算法在做流量及擁塞控制時的估算失準,造成了無法在 TCP 之上進行高效傳輸的結果。而每個客戶端都會同時和伺服器端建立多個 TCP 連線的行為,也使得伺服器必須配置更多的網路連線資源來處理,例如佔用更多的sockets及作業系統中的資源。而為了處理更多的連線請求,在多執行緒或程序的資源負擔,也變得更重。

所以總的來看,同時間多連線及短生命期傾向的TCP連線,正是HTTP在效率上打折扣的原因。而這樣的觀察,也正一步一步的導引著、觸發著 HTTP改版的契機,其中影響最深遠的,莫過於 Google 的SPDY了。而有了SPDY協定,才催生了之後改版的HTTP/2。

在這一回裡,我們談了舊有HTTP的問題,而在下一回,我將介紹HTTP/2的內容,以及所做的改進,是如何的解決舊有HTTP的毛病。

作者簡介


Advertisement

更多 iThome相關內容