HTTP 1.0/1.1是最為人所知的網(wǎng)際網(wǎng)路通訊協(xié)定,，然而,，該標準最后一次修訂是在十幾年前,，面對當前龐大的網(wǎng)頁應用需求,，它有那些不合時宜的地方呢?

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

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

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

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

　　HTTP既有版本的問題

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

　　HTTP 底層的協(xié)定是TCP，因此,，當HTTP的客戶端想要取得一個檔案資源時,，就必須在一個TCP連線上發(fā)出請求。HTTP是一個基于“請求-回應”的協(xié)定,，也是說,，總是由客戶端發(fā)出請求，而伺服器端對應一個回應,。

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

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

　　面對傳輸效率不佳的狀況

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

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

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

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

　　為此,，在HTTP/1.1中,，增加了讓連線“保持存活(Keep Alive)”的標頭(header)，讓客戶端及伺服器端可以協(xié)調(diào)重復運用同一個TCP連線,，每當客戶端接收完來自伺服器端的回應內(nèi)容后,，可以繼續(xù)在同一 TCP 連線里發(fā)出下一個請求。

　　但這樣的設計可以讓情況好轉,，但并沒有辦法完全解決,，因為這個“保持存活”的情況，若是客戶端在一段時間內(nèi),，并沒有繼續(xù)在TCP連線中發(fā)出下一個請求,，此TCP連線亦會被切斷。

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

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

　 　TCP本身是一個具有流量控制(flow control),，以及擁塞控制(congestion control)能力的協(xié)定，因此,，它會試著估算單 位時間內(nèi)要傳輸多少資料量最有效率,。當頻寬本身不足時，若是單位時間內(nèi)試著傳輸太多的資料量至另一端,，但卻無法即時傳輸完成,，就會造成擁塞。另一方面,，若 是頻寬充足,，但卻傳輸?shù)奶伲謺斐尚什徽?、無法善用頻寬的情況,。

　　因此,，TCP的演算法會盡量優(yōu)化此事，而緩起步正是其演算法中的一環(huán),。TCP會逐步視情況擴展單位時間內(nèi)所傳輸?shù)馁Y料量,，但在網(wǎng)路連線剛建立之際，它會試著從很小的傳輸量開始嘗試,，這使得在連線剛建立的初期,，無法善用實際上可能十分充足的頻寬。

　　會產(chǎn)生很多短命的TCP連線

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

　　此外,，同 時間多個TCP連線并行傳輸?shù)那闆r，也可能讓 TCP 演算法在做流量及擁塞控制時的估算失準,，造成了無法在 TCP 之上進行高效傳輸?shù)慕Y果,。而每個客 戶端都會同時和伺服器端建立多個 TCP 連線的行為，也使得伺服器必須配置更多的網(wǎng)路連線資源來處理,，例如占用更多的sockets及作業(yè)系統(tǒng)中的資 源,。而為了處理更多的連線請求，在多執(zhí)行緒或程序的資源負擔,，也變得更重,。

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

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